In our previous blog post we started discussing how important it is to have relevant context when doing any investigation and how at VirusTotal, we are working hard to provide as much context as possible. Indeed, there are many new features we have already implemented and that we want to share with all of you. Today we will discuss Crowdsourced Sigma rules.
What are Sigma rules? Probably at this point you are already familiar with YARA: in essence, a rule-based engine to detect certain patterns in files. YARA became a de-facto standard in Threat Intelligence sharing, widely used for static detection, attribution, monitoring and hunting.
With this same idea in mind, Sigma was developed as a “YARA for logs”, allowing the creation of generic rules that could be later used in most SIEMs. Given Sigma rules match against System event logs, one of the main differences with YARA is that rules will be behaviour-based instead of matching static patterns in files.
Now, at VirusTotal our sandboxes store all event logs during detonation, which are later used to match Crowdosourced Sigma rules. In particular, we are importing rules from the following public repositories (big thanks to all of them for their help):
If you are curious, you can even check the full list of rules and the number of matches for each of them in our documentation.
Relevant additional context for file reports
Sigma matches help researchers and investigators get more context about a given file. It is also an additional and quick way of finding potentially related files based on the same behaviour. Similar to Crowdsourced YARA rules, VirusTotal Intelligence users will find the list of Sigma rules matching a given file in the Detection tab:
From there you can View the rule itself, check what events made this file to match this rule in particular, as well as finding other files matching this Sigma rule. Remember that for finding all the files matching a given Sigma rule you can always use the “sigma_rule” modifier followed by its ID as shown in the Sigma rules list documentation (or by simply clicking on them).
For example, the following search returns all matches for the “Milum malware detection” Sigma rule (based on WildPressure APT)”:
sigma_rule:30fcf3924a898a9d1747e89068ab2990c77ca3914a94aa78466d28a9d9da32bb
When opening some of the search results in a Graph, we can see there are relationships among them:
Keep in mind that you can add more search modifiers to your Sigma rule search. For instance, we can add to our previous rule a filter to get the results that also matched any Crowdsourced YARA rule, probably this will help us to quickly identify the subset of results we are interested in as well as serve as a double check:
sigma_rule:30fcf3924a898a9d1747e89068ab2990c77ca3914a94aa78466d28a9d9da32bb have:crowdsourced_yara_rule
From here we can further pivot and select just the subset that additionally matches a particular set of YARA rules. All this context helps us to save time and adds a very relevant source of information when determining a file’s maliciousness.
Context for detection
Sigma matches can be used as a nice addition to AV detections. For instance, we can quickly find undetected files having Sigma matches:
have:sigma_rule p:0
It is also possible to filter by rule severity by using the sigma_<severity> search operator. To search undetected files having no detections and matching high severity rules we can do:
p:0 sigma_high:1+
Since the sigma_<severity> operator accepts integer values, it is possible to set a minimum severity for the matching rules. The aforementioned previous search query will find files matching Sigma rules with at least severity 1 or higher.
For instance, as a result of searching “p:0 sigma_high:5+”, the following file is returned:
Even though it has no AV detections, its bundled files have:
Fooled by context?
A final thought about adding more context.
We believe the more relevant information we have around any set of activities or IOC, the better. However, sometimes different pieces of information can contradict each other: what to do then? It really depends, the previous example is a good one in this direction as it shows how some malware was not detected given some technicality (was packing other malware inside) but when run in the sandbox the Sigma rule fired up.
We do a great effort in trying to keep all the crowdsourced elements we add as relevant as possible, carefully selecting the sources. But there might always be clashes, especially when it comes to aspects such as attribution where different security companies might have different mappings for APT groups.
Still, we find all these additions of great value for Threat Intelligence practitioners. As we all know, Intelligence is not bought but produced: we keep working hard to provide you with all the relevant signals you can use to make your own informed decisions.
0 comments:
Post a Comment