YARA Shenanigans and Other Jokes


If it hasn’t become obvious, I have a great appreciation for YARA. So I keep my eye on articles about it, both good and bad. It’s rare that you see a bad one, since it’s tough not to appreciate what it can do. Occasionally, though something profound and funny comes running to your door to say hello – kinda of like the neighbor’s puppy when it gets off leash. In this case, Trend Micro published a great article on a file they found earlier this month (May 11 to be specific). It was a great chuckle because someone went to the trouble to poke fun at security researchers. (Here’s the article about how YARA was used to RickRoll Security Researchers.)

It’s funny, both for the joke and the prank played on security researchers. It should be a humbling warning, too. Trend Micro made his point in their article, but just to echo it again – never blindly trust any alert. They made a plug for their product in the article as the answer to verification, but I’m more of a process fan than a product one. Very little can replace solid methodology to provides the gas (knowledge, experience) to fuel cognition. Specifically, alerts should be verified, no matter the source and not via re-occurring heroic effort but documented process that provides a repeatable, sustainable process.

Consider, for a second, where that doesn’t exist. Where alerts, YARA or otherwise, are used to fuel whether you call in your incident response team or start a high severity incident process in your SOC. Dwell on the cost, effort, frustration and loss of resources that could invite if it led to performing the entire process. There’s a cost that exists in each of these exercises that can be exorbitant, especially if uncalled for in the case of a false positive.

Now take a second and think about a situation where an adversary may want to bait you into responding so they can observe how you react. How better to get a read on someone than to watch them in action? If an adversary desired to evaluate your ability to impede their operations, baiting you with something to get you to respond is one tactic to make that determination. Let’s say the adversary baits you for a response by introducing malware into your enterprise environment. They could then watch and monitor for how fast or slow you detected it. What you used to find it might be observable depending on their insight into your network. What you did immediately and then as time progressed to respond to it may be visible as well.

Let’s say they delivered malware malware via drive-by download into your enterprise. That successful infection tells them that they can enter via that attack vector. If they land and beachhead on a single device and are able to successfully elude detection and maintain a presence, that’s even more information. Let’s say they just sit an hour and are still undetected. Now 6 hours. Then 24 hours. Still nothing. That’s good information to know from an adversary perspective. Now they come alive and download tools to understand and explore your network. If they remain undetected, then it’s even more informative. In fact, the amount of information grows explosively until they reach the point where they do become detected. Then, a completely different stream of valuable information becomes available. The point in time where an action is taken against them that can be detected constitutes the (from the adversary’s perspective) moment of detection.

That’s when they start documenting your response.

Did you cut the one or all of the infected machines off the network? Was it simultaneously or staggered in time? Taking one offline might be a normal practice and overlooked. A flag, you might say, but not a signal of outright detection to the adversary. Bringing all the infected machines offline at once would be a complete signal of detection. If C2 was interrupted or completely stopped — this too is an indicator. In effect, consider what could observed from the other end, the adversary’s side of the wheel well and assume it can be and is being watched and recorded.

In many cases, it’s going to be okay if they can observe actions taken on your part to counter or react to an attack. In others, you want the fog of war to dominate.

Alerts, detections (and YARA) are necessary and desired. Having a process of verification and reinforcement of any single alert is just as required and needed. Equally, keeping a thought towards what you expose to attackers by reacting is also important and prudent. It can assist in the prevention of opening easy avenues of attack into your enterprise.


Monty St John is a seasoned expert in Threat Intelligence, and offers cybersecurity intelligence classes–even on YARA!–at www.cyberdefenses.wpengine.com/academy/

About the author

Monty St John

Monty is a security professional with more than two decades of experience in threat intelligence, digital forensics, malware analytics, quality services, software engineering, development, IT/informatics, project management and training. He is an ISO 17025 laboratory auditor and assessor, reviewing and auditing 40+ laboratories. Monty is also a game designer and publisher who has authored more than 24 products and 35 editorial works.