This post will explain the process you can follow to create a VT Livehunt rule from a VT Intelligence query. Something typical in threat hunting and threat intelligence operations.
Let’s assume that, as a threat hunter, you created robust VT intelligence (VTI) queries getting you reliable results without false positives. Your queries are so good that you run them daily to obtain fresh new samples, which is a tedious job to do manually (pro tip - you can automate using the API).
A good alternative would be converting your VTI query into a LiveHunt rule, so you will be immediately notified every time any uploaded indicator matches your criteria. Unfortunately, there is not an automated way to convert intelligence queries into LiveHunt rules (and vice versa), and in some cases it is not even possible to obtain exactly the same results (technical tldr - due to limitations of the stored data structure).
But do not despair. In this post we are going to show many practical cases showing LiveHunt rules based on VT intelligence queries, how you can do it yourself, and pros, cons and limitations for this approach.
The perfect query ̶d̶o̶e̶s̶n̶’̶t̶ exist
Bitter APT
Bitter APT is a suspected South Asian cyber espionage threat group. Security researchers like StopMalvertisin, among others, regularly publish information about this actor in both X and VirusTotal community.
To start hunting for files related to Bitter APT, you probably want to subscribe to any attributed VirusTotal collection or the threat actor profile itself.
You can also search for what the community is discussing about this APT directly by searching on community comments. For example, the next query returns samples related to Bitter APT.
entity:file comment:"Bitter APT"
When checking these samples’ behavior we can find interesting patterns that can be used to hunt for other similar ones. For instance, Bitter seems to specially like the "chm" file format, as seen in the initial Twitter/X reference and when calculating Commonalities among these files, along with the use of scheduled tasks to achieve persistence on targeted systems, and run the %comspec% environment variable through the scheduled task created to execute msiexec.exe followed by an URL.
All these behavioral characteristics will help us create good LiveHunt rules and queries to detect additional samples. For example:
behavior_processes:"%Comspec%" behavior_processes:"schtasks.exe" tag:chm
The query returns 39 different samples, most of them apparently related to Bitter based on behavior similarities.
Now it's time to translate our query into a LiveHunt rule. Certain functionalities available for VTI queries are not ready (yet) in VT LiveHunt and vice versa. We are working to maximize the integration between both systems, and we will get back with more details as we progress in this.
As we published, we can create a LiveHunt rule from a sample by simply clicking - we are going to create a rule based on 7829b84b5e415ff682f3ef06b9a80f64be5ef6d1d2508597f9e0998b91114499.
First, we are interested in identifying the use of the process “schtasks.exe” during sample detonation. In the behaviour details of this sample, we can find “schtasks.exe” in the “Process Tree” and “Shell Commands” sections.
At the moment, it is not possible to use "Process Tree" in LiveHunt rules, however we can search for processes in "Shell Commands" and "Processes Created" sections to start creating the logic of our rule. In future updates, we will integrate more fields to be used in the creation of LiveHunt YARA rules.
There is no "Processes Created" section, maybe sandboxes were unable to extract such information. But this does not mean it will be the same for future uploaded samples. We will add both the "Shell Commands" and "Processes Created" fields to the condition.
We will follow the same steps to detect the use of the environment variable “%comspec%” in the command line during detonation.
We look for the same information in the two sections (shell and processes) and in two different ways as Bitter used upper and lower case letters to spell %coMSPec%. We can simplify this with the "icontains" condition to enforce case insensitiveness.
Finally, we want to add two extra conditions. The first is that samples have the "chm" tag since it is the format we look for. The second is to get notifications exclusively for new uploaded files.
And that’s it! You can download and use this YARA rule from our public GitHub, to be integrated into our Crowdsourced YARA Hub in the future.
RomCom RAT
BlackBerry Threat Research and Intelligence team published about Targeting Politicians in Ukraine using the RomCom RAT. During the campaign, threat actors used a trojanized version of Remote Desktop Manager.
Taking a look at the behavior of the samples provided in this publication, we can find interesting behavioral indicators to generate a VTI query.
Different samples related to RomCom RAT seem to usually drop DLL files in the path “C:\Users\Public\Libraries” with different extensions, and execute them using “rundll32.exe”. That means there are also file creation events in the same path.
All of these indicators, along with others used by RomCom RAT in different intrusions, can be used to create a potential query that can later be translated into a LiveHunt.
These samples export up to three different functions:
- fwdTst
- #1
- Main
“Main” is probably the most common function exported by many other legitimate DLLs, so we will ignore it. The VTI query we use is as follows:
((behavior_processes:".dll,fwdTst") OR (behavior_processes:"dll\",#1" behavior_processes:"\\Public\\Libraries\\") OR (behavior_processes:*.dll0* behavior_processes:"\\Public\\Libraries\\")) AND ((behaviour_files:*\\Public\\Libraries\\*) AND (behavior:*rundll32.exe*))
Even if you don't know that the "Main" function is common in the use of DLLs, when building our query we would observe a large number of samples matching our logic. For this reason, it is important that before creating a rule we use a query when possible to understand if results align with our expectations, and iterate the condition until we are satisfied with it.
The last query provides samples related both to RomCom RAT and Mustang Panda. This might indicate that both threat actors are using similar procedures during their campaigns.
To convert this query to LiveHunt, we will split the original query into different sections and adapt them to the rule. As previously explained, the rule will be slightly different from the original query for compatibility reasons.
- First, we only want DLLs, EXE or MSI files.
- As a precaution to minimize false positives, we want to skip samples that are not detected as malicious by AntiVirus vendors.
- Something that we can’t do in VT intelligence queries is determine behavioral activity related to file write actions. VTI behavior_files modifier performs a generic search for any literal within file activity, including creation, modification, writing, deletion… LiveHunt gives us more precision to specify our search only for written files during detonation.
- Rundll32.exe is used during execution since this DLL should be executed along this sample's process. We will search for it in different fields.
- Finally, we are interested in obtaining the functions exported by the observed DLLs, which are written in the command lines. We are also interested in the existence of a .DLL extension, which will indicate that there is some type of activity involving libraries.
You can also find this rule in our public Github repository. Feel free to modify it based on your needs!
Gamaredon
Our last example is related to the Gamaredon threat actor. As per MITRE “Gamaredon Group is a suspected Russian cyber espionage threat group that has targeted military, NGO, judiciary, law enforcement, and non-profit organizations in Ukraine”.
The use of the remote template injection technique is common by this threat actor. This feature involves making connections to a remote resource to load a malicious template. The external domains used to host it generally use some URL pattern. According to publications from different vendors, this actor usually registers domains in the “.ru” TLD.
Gamaredon also uses the DLL “davclnt.dll” with the “DavSetCookie” function. This behavior is related to flags that may be connected to exfiltration or use of WebDav to launch code. In other words, this is used to load the remote template. We can quickly check this with the following query:
threat_actor:"Gamaredon Group" behavior:"DavSetCookie"
Putting all this information together, we can create the next VT intelligence query to get samples related to Gamaredon:
(behavior_processes:*.ru* and behavior_processes:*DavSetCookie* and behavior_processes:*http*) and (behavior_network:*.ru* or embedded_domain:*.ru* or embedded_url:*.ru*) (type:document)
The query is designed to discover file-type documents where the following strings are found during execution:
Behavior_processes:
- First we want to identify the use of the string “.ru” in the command line. This will be related to domains with this TLD.
- Another string that we want to match in the command line is “DavSetCookie”, since it was used by Gamaredon to accomplish remote template loading.
- Finally the string “http” must be in the command line as well.
Behavior_network:
- See if there are communications established with domains having the “.ru” TLD.
Embedded_domain:
- Domains embedded within the document containing the TLD “.ru”. It is not necessary that a connection has existed. We do it this way in case our sandboxes have had problems communicating or the sample has simply decided not to communicate.
Embedded_url:
- URLs embedded within the document containing the TLD “.ru”. It is not necessary that a connection has existed. We do it this way in case our sandboxes have had problems communicating or the sample has simply decided not to communicate
This VT intelligence query provides results that seem to be consistent with known Gamaredon samples, based on the previously discussed patterns. It is always possible we get false positives among the results.
Let's convert this VT intelligence query to a LiveHunt to receive notifications for new interesting files.
- First, we want to make sure the exported DLL function is found for any command line or process-related behavior, as well as finding traces of the “.ru” TLD is found for http communication. It is important to mention that we look for information about the TLD ".ru" and the string "http" in the command lines because it could be the case that the connection is not established, but there was an intention to establish it.
- Communications are important, for that reason we need to check if there were connections established with domains having the TLD .ru. Remember the next block will match only if communications existed
- And for this example, we are just interested in document files, although you can change it to any other file type to adapt it to your needs.
As usual, you can find and download the YARA rule in our public repository.
Actual limitations
We are aware of the limitations that currently exist when translating fields from VT intelligence to LiveHunt rule and vice versa, and we are working to obtain maximum compatibility between both systems. However, for the moment this could be an advantage as they complement each other.
VTI modifiers such as behavior_processes, behavior_created_processes or even behavior are somewhat more generic than the possibilities that LiveHunt currently offers, allowing us to specify whether we want information about the processes created, completed or commands executed.
However, something that cannot be used yet in LiveHunt rules is the process tree. On some occasions, dynamic executions of our sandboxes only offer information at the process tree level, which means that this information is not available for our rules. But if you want to search information within the process tree with VT intelligence queries, you can use the “behavior” file modifier. The "behavior" modifier the process tree could be consulted to find information.
Wrapping up
Converting VT intelligence queries to LiveHunt rules is getting easier. The recently added "structure" feature in LiveHunt allows creating rules in a much simpler way by clicking on the interesting fields, creating the rule conditions for you and eliminating the need to know all available fields in the VT module.
This post describes with examples a potential approach that analysts might use for their hunting and monitoring. In particular, using VT Intelligence queries before starting working on a YARA rule is really helpful during the initial fine tuning stage of our condition. This practice minimizes noise and ensures we get quality results before we go for our LiveHunt rule. Finally, a quality VTI query can be translated into a YARA with just a few minor changes.
We hope you find this useful, and as always we are happy to hear from you any ideas or feedback you would like to share. Happy hunting!
References that could be interesting
- IP address search modifiers: https://developers.virustotal.com/docs/ip-address-search-modifiers
- Domain search modifiers: https://developers.virustotal.com/docs/domain-search-modifiers
- File search modifiers: https://developers.virustotal.com/docs/file-search-modifiers
- Network hunting: Writing YARA rules for Livehunt: https://developers.virustotal.com/docs/nethunt
- File hunting: Writing YARA rules for Livehunt: https://developers.virustotal.com/docs/writing-yara-rules-for-livehunt
0 comments:
Post a Comment