Distributing Logic with YARA Rules

In Part I of the series, Building Blocks of Success with YARA, we introduced YARA and some of its capabilities. That introduction ended with a very short discussion on the distribution of logic across multiple rules and the use of constraints to ensure accuracy.

Let’s expand on that.

While in many cases its appropriate to maintain all the logic needed in one rule, many edge cases exist where you lose accuracy, efficiency, matching, or all three. Let’s consider one of those examples. Take a situation where you have written a bundle of YARA rules to match on a binary: (1) in its wild state, (2) compiled with a key logger, (3) compiled with embedded malicious resources. Viewed standalone, each rule contains logic to detect the core of the binary as well as the individual unique characteristics – key logger, obfuscation, malicious resources – behind each situation. A small amount of comparative analysis–say, using a program like Groom-Porter–will quickly show you are repeating the same logic across each rule. This type of situation is a great candidate for optimization by diversifying the logic across more rules. Since the situation deals with only executable files, extracting that logic and building a global rule to detect only windows binaries makes sense.

[minti_table style=”1″]

[/minti_table]
That allows us to write that logic once and apply it to all rules. It becomes one of the first constraints we can apply to enhance accuracy. After all, candidates we apply the rules against that do not match are not of interest to us for this detection. Secondly, a short amount of comparative analysis will show a high amount of duplication among the rules; after all, the core of the program in each rule is still the same. Since we are only interested in that family of binaries, the same thought process can be applied. Table 2 shows what that rule would look like after isolation of the core logic away from the unique versions is applied.

[minti_table style=”1″]

[/minti_table]

You’ll note that this rule is not a global rule. It is consistent across all of them, but we are going to trap for a version of the binary that deviates from this standard in another rule so we’ll make due by importing it into the condition line.

Now that we have handled isolating detections to executables and to the core of the program, let’s work out the use cases. In the wild, the discovered binaries had a pdb file notation that was consistent in all but the keylogger compiled versions. Let us isolate that into a separate rule. These versions were also all consistent in file size as well, so we’ll take that as a constraint. Table 3 shows that rule.

[minti_table style=”1″]

[/minti_table]

You might have noted that we used a constraint to only apply this to files less than 1MB. PDF matches were randomly sized, but consistently under 1MB. Adding a shortcut constraint of 1MB keeps us only focused on what’s necessary to match. With that defined, all that leaves is the versions with the other three cases. Keylogger versions matched the core rule, but consistently did not have pdb strings and ranged between 1 MB to 2MB in size.
[minti_table style=”1″]

[/minti_table]
To simplify detection, we are going to use the PE module to go through resources to match the malicious resource and then check for the pdb strings by using that rule in the condition line.  That does mean we’ll need to import “pe” at the top of our yara rule file.  So keep that in mind.
[minti_table style=”1″]

[/minti_table]
Lastly, lets cover some use cases where the file doesn’t match on isCore, but does contain either the keylogger string or the pdb strings.
[minti_table style=”1″]

[/minti_table]
We could match plenty more combinations, but this covers the major cases.