Thursday, September 21, 2023

, , , , , ,

It's all about the structure! Creating YARA rules by clicking

Since we made our (extended) vt module available for LiveHunt YARA rules we understand it is not easy for analysts to keep in mind all the new potential possibilities - too many of them! Our goal is to make YARA rule creation as easy as possible while providing security experts everything they need to make even more powerful rules. Our recently published new YARA editor, which incorporates full syntax coloring and auto-complete while you develop your rule, is a first step.
However, we wanted to go further. We already discussed how you can use predefined templates (additionally you can check our Threat Hunting with VirusTotal - Episode 4 for further examples and ideas), but in this post we want to focus on a terrific new feature when creating rules using the “Structure” of any given object (file, URL, domain or IP).
“Structure” provides the full JSON containing all details VirusTotal knows for any given indicator. For instance, you can paste a file hash and you will get full details about its behaviour and metadata. What is better, you can simply click on any field you are interested in, and it will automatically included in a fresh new YARA rule in the editor - no need to remember how to get that particular field in the VT module anymore.
In case you are wondering, this also deals with all kinds of loops. If any of the selected fields needs to be iterated, the correct syntax will automatically be added to your rule.
Let’s check the different object types.


For a file object you will find two different branches in the resulting JSON - behaviour and metadata.
The behaviour key is based on the sample execution in the sandbox. For example, you can create rules based on files written by the malware, files dropped, mutexes created, processes created, sigma results or ATT&CK MITRE results, among others.
Let’s suppose that we are interested in creating a new detection logic focused on some specific file written. In that case, we want to open the files_written section and then click on the file that we have observed as suspicious for our rule. Automatically, a new rule pops up with that condition (note that the loop condition was conveniently created for us too).
We can keep editing the rule to adapt it to our needs, like adding additional conditions to detect a specific string or path, another file name, etc.
If your security posture takes into account the ATT&CK MITRE matrix, maybe you want to create rules adding these fields in your logic, available under the key mitre_attack_techniques branch.
In addition to vt.behaviour, it is also possible to use vt.metadata to create a rule based on file metadata. Under the metadata key, we have a lot of interesting information that we can use to create our rule.
Probably one of the most interesting fields is "itw". Under this key, we can create rules based on ITW communications that we are interested in detecting whether related to IPs, domains or URLs.
For example, we may be interested in files that were downloaded ITW with response code 200, from the Discord CDN and that download binaries but more specifically DLLs.
Another interesting approach could be to hunt for files that are downloaded ITW, but with characteristics that could interest us in the whois of the domain from which it was downloaded. This could be interesting if we are monitoring certain domains that are being registered.
Metadata gives us multiple ways to play to create livehunt rules. From more complex rules using ITW applying filters related to domains, IPS or URLs to more basic things where we can include information from exiftool, submitters, fuzzy hashing, etc.
Combining the power of metadata and behaviour will result in a quality YARA rule!


For URLs, under the “net” section in the VT module, you have the possibility to use the keys url, ip and domain as shown on the Netloc summary table. Any field available under these keys can be used to create your URL hunting rule.
Some of the features you can use to create your rule include URL response headers, downloaded and communicating files, URL path, domain whois, IP ASN, among others. Just by clicking on the fields you are interested in and adapting them to your needs, you can create a robust rule that helps you follow a campaign you are interested in investigating.
A use case could be that we were interested in discovering new URLs seen in VirusTotal, where the path meets a certain pattern, resolves to a certain network block and the domain registry is a registry known as commonly used to register malicious domains. Finally, to avoid noise we are interested just in new URLs.
Last rule can match for example an URL used by Gamaredon threat actor.


The fields available for the IP entity can be found under the the ip key in Here you can play with fields such as IP whois, communicating files, netblocks and others.
From here, we can add as much information as we are interested in to identify new ip addresses from suspicious campaigns. The following image is the result of a few clicks on fields containing a specific IP address.
Let’s suppose we want to identify new IP addresses that belong to a certain ASN (here we explain how to calculate a network range) and have some type of communication with PEEXE binaries.
This type of use case could even be used to monitor certain network ranges that may belong to our organization or customers to identify if a new IP address has any files that carry out communications.


Last but not least, we can also use the new Structure functionality with domains. In this case, domains include information about both the domain itself and the IP address it resolves.
And the same process that we have followed with the other entities that we have taken as an example, it would only be enough to click on the fields that interest us and shape our rule.
Within the information that we can find within the domains, there is an interesting field called categories. Within these categories we can identify if the domain could be linked to malware, phishing, spyware...
To create a use case with this field, let's say that we want to discover new domains that are related to phishing, and that the value of the not_before field of the HTTPS certificate is greater than a specific date that we want to search for information.
Another case that we can do also related to phishing is to monitor a specific favicon that is using our brand image. Subsequently, we are also interested in whether it includes a pattern in the domain name or in the alternative name in the certificate.

Wrapping up

At VirusTotal we continue trying to include the greatest number of functionalities that are useful for analysts for threat hunting. Our goal is to make work easier and spend time intelligently when using the platform.
The idea of this new feature is to continue to add new fields that can be consumed through VirusTotal intelligence to make livehunt rule creation more powerful. It is not easy to remember or know which fields are available within the files to create livehunt rules, so the new "Structure" functionality can help us.
We want livehunt rules to be a great tool to detect campaign patterns and to be able to track players more powerfully.
We would also like to announce that we have opened a GitHub where the community can publish their YARA rules and contribute! During the following weeks we will be posting new rules
We hope you liked this functionality. Happy hunting!