A long time ago I’ve noticed that there is no single best YARA rule for a given sample, but different best solutions depending on the user’s requirements and use case. I noticed that I often create 2 to 3 YARA rules for a single sample that I process, while each of them serves a different purpose.
In this blog post, I’d like to describe the three most common rule types.
While looking at the strings extracted by yarGen, you’ll notice that it contains a lot of interesting strings. In my past tutorials (1, 2, 3) I’ve always distinguished between “Highly Specific” and “Suspicious” strings (see Part 3 of the blog post series). Today I’d like to show you a more purpose oriented approach.
The following screenshots shows what types of strings I see while looking at these strings:
The strings that are marked with yellow look very specific. I’d use them as “Highly Specific” strings ($x*) of which only a single one is required to trigger the rule: 1 of ($x*)
The strings marked green will be used in combination with other green strings. A reasonable set of these strings is required to trigger the rule: $u1 and 1 of ($f*)
The strings marked with red color could serve in a rule that tracks the C2 addresses used by this sample and the strings marked blue could be used for a generic detection of malicious samples that can be completely unrelated.
The different rule categories are:
- Regular Rules: Detect a certain malware or malware family
- Threat Intel Tracking Rules: Detect specific indicators that relate to a certain actor
- Method Detection Rules: Detect methods or anomalies
The following table describes these three different types of rules and gives some string examples.
In the case of the “Regular Rules” I distinguish between two different flavors:
- Threat Detection Rules
- Threat Hunting Rules
The difference between these flavors is based on a different level of strictness in the conditions and not on the different selection of strings. While a “threat detection” rule may require “6 of them”, a “threat hunting” rule may be satisfied with “3 of them”, accepting some false positives.
The reason why someone distinguishes between “threat detection” and “threat hunting” rules is that the response to matches can be very different. Antivirus solutions that respond to matches with “delete” or “disinfect” reactions do not accept false positives and avoid false positives by any means.
In “threat hunting” use cases which include direct destructive reactions to signatures matches are rare. Typically analysts investigate such an event, classify and react to it manually. In “threat hunting” scenarios analysts try to avoid “false negatives” by all means.
(Source: Chris Gerritz @gerritzc)
Threat Intel Tracking
In threat intel, we can use YARA rules to track the activity of certain actors in cases in which there are certain characteristics or keywords that persist over longer periods and campaigns.
A very convenient form of tracking without having access to the telemetry data of OS and AV vendors is offered in the form of YARA match notification services as provided by VirusTotal or ReversingLabs.
Method Detection Rules
During the past year I focussed on the last rule type “Method Detection” whenever I had the opportunity as it allows me to provide very generic rules that produce amazing results with a minimum of false positives.
However, those rule matches lack a reference like a malware name or an adversary group that used the detected method in their samples. Here is an example with one of the few public YARA rules published in the “signature-base” repository:
These are the reasons why the analysis of a single sample often results in 2-3 different YARA rules.
Using this method the coverage is exceptionally good as the set of rules covers specific samples of the same family and the different malware families the use the same methods.