Some Side Points on rules and detections

I'm sandwiching this in-between talking about the PE File Header & Structure because it seems an appropriate item to cover since we talked about detection, classification and rules earlier.  How you employ rules and how many you deploy depend on the situation.  For example, in a monitoring situation you need rules to be small and fast.  Especially in heavy duty traffic situations or when you are building rules to detect inline network traffic.  Get into your lab or in a situation where this demanding you can deploy any number of rules to classify and detect.

So, just to summarize, know when you need a light touch or can be heavy handed.  That elaborate, 80-rule combination you use to iterate through the three main types of PlugX should probably be kept in your lab and not on virustotal or in your active monitoring suite.  The five rule set that picks up 90% without getting into typing versions is probably your best bet in a situation like that.

While I'm  on the topic, let's address rule length and condition complexity.  While it seems like the number of strings you may employ in a Yara rule seems endless, it does have a breaking point where it becomes either 1) too slow or 2) too unwieldy to understand.  Its better to break this logic up as discretely as possible in those instances, especially when you are matching on combinations of said strings (2 of this, 3 of that, 1 of those, etc.).  Here's an example (abbreviated for space) where we have 400 lines of strings and some complex condition logic.  Its a good candidate for breaking into smaller chunks.

rule TooBig {
strings:
//...assume 399 lines precede this one, in chunks of 50 runing z-h
$h50 = "I am number 400"
condition:
(6 of ($a*) and 9 of ($b*) and 15 of ($d*) and 4 of ($h*)) or
(all of ($c*) and all of ($e*) and not ($f15 or $f18 or $h48)) or
(all of ($b*) and all of ($d*) and all of ($g*)) }

Absolute nonsense, of course as a rule but it does okay for an example.  If you get into a situation like the above, you need to decomplicate the rule.  Try to break the rule into smaller chunks.  Don't forget that Yara supports private rules.  These rules match but don't report; however they can be used in the condition lines of other rules.  This lets you put somethings into one rule that by itself should never alert but in conjunction with others should.

Condition complexity is where you get into very difficult to understand or to implement actions.  Usually this is where employing a logic structure in Yara or breaking the logic into smaller rules assists.  Remember, Yara supports all the Boolean operators and, or and not and relational operators >=, <=, <, >, == and !=. Also, the arithmetic operators (+, -, *, \, %) and bitwise operators (&, |, <<, >>, ~, ^) can be used on numerical expressions.  Use them.  Don't forget about being able to count matches and the ability to look at specific offsets (very useful).