YARA: Incident response host prioritization
Your Intrusion Detection System (IDS) fires off an alert implying that your Domain Controller may have been compromised by malware XYZ and your network logs show connections with fifteen other hosts on your network. Where do you turn for help? How do you prioritize which boxes to analyze? Fortunately, there’s an awesome tool available that will be there to have your back and help you sort things out.
Why YARA is the bizness
YARA is a tool used by malware researchers to quickly identify key textual and binary patterns of interest. This tool is useful for aiding in the decision about which potentially compromised hosts should be investigated first, and thus can help prioritization, discovery, and ultimately quicker remediation.
During the initial part of the Incident Response (IR), all hosts flagged by the IDS are usually quarantined and have their memory dumped. This occurs to preserve the forensic information of what was stored in memory.
As the IR team continues their investigation, from current or previous attacks, they will discover IOCs (indicators of compromise). YARA rules can be written from IOCs to scan memory dumps and can be run against all suspected hosts to see if they contain artifacts present in memory to imply compromise.
It’s important to note that a host could still be compromised even if YARA does not find a match. The specific rule may not contain a pattern that can be matched by what was running in memory during the memory dump.
Let’s look at an example
In this compromise scenario, we’re going to use an old favorite and pretend that the IDS alerted to a Poison Ivy (PIVY) Remote Administration Trojan (RAT) activity on the network. As this RAT has been heavily researched by malware researchers in the past, we have access to a variety of IOC’s we can use to write our YARA rules with.
In this example, for our first YARA rule we are going to create it using the most well known PIVY mutex as our IOC. Shown below:
To start the YARA rule, we begin by setting the rule name:
This is now where we can define our pattern. In this instance it’s just a string, but YARA provides us with the capability to use regular expressions to match complex patterns.
Lastly, we define what strings need to match for the rule to find. YARA has a very extensive capability list in this department, which enables the rule creator to have the rule only fire, for example, when all or three out of a group of seven strings match. In our case, we only have one string for this basic rule so far, so we will go with that.
Now, we combine them together in a text file that we will call “pivy.yar”:
With our “pivy.yar” rule created, we can now run this against our memory dump.
If the mutex is detected, this command should output something similar to the following:
Congrats, we now have a working YARA rule.
Now, using this rule we can scan all the boxes using it to see which ones we know to contain this suspect PIVY mutex string (assuming hostname_mem.dump.str):
This information can help you prioritize your investigation around the hosts you know to contain strings associated with suspect or malicious activity.
If you’re interested in learning more about the capabilities of YARA, you can head over to their documentation site. If you would like to acquire additional rules or contribute your own work to the YARA community YARA rules github is a good place to do that. The primary download link for YARA can be found here.
HAPPY HUNTING!
About Hurricane Labs
Hurricane Labs is a dynamic Managed Services Provider that unlocks the potential of Splunk and security for diverse enterprises across the United States. With a dedicated, Splunk-focused team and an emphasis on humanity and collaboration, we provide the skills, resources, and results to help make our customers’ lives easier.
For more information, visit www.hurricanelabs.com and follow us on Twitter @hurricanelabs.
