Most teams commonly utilize a particular set of tools to perform analysis on suspicious files. When reviewing a new tool, the team can see where it will help them in their day-to-day tasks, yet there is always the big “if”. This tool will help me a lot IF I can make it work with my existing tools and processes. No one wants to rebuild everything each time a new tool is introduced. In this blog post I’m going to show you an example where the Malware Analyzer G2, a behavioral analysis tool, can apply a static analysis tool that already exists in most tool kits.
The static analysis tool I am referring to is Yara Rules.
“YARA is a tool aimed at helping malware researchers to identify and classify malware families. With YARA you can create descriptions of malware families based on textual or binary information contained on samples of those families. These descriptions, named rules, consist of a set of strings and a Boolean expression which determines the rule logic.” (Yara User’s Manual 1.6)
Similar to antivirus software, Yara looks for specific information (usually strings) inside a binary to determine if a file is malicious or what type of sample it is. The Malware Analyzer G2 (MAG2), on the other hand uses behavioral patterns to determine if a file is malicious. This is especially effective against 0-days or targeted attacks, but is less effective at naming the sample. Yara Rules and the MAG2 are effective with what they are designed to do, but there is little crossover between them.
With that said, one of the benefits of the MAG2 is that it offers open APIs and encourages users to write their own detection or classification patterns. Patterns are written using JSON, and are pretty straight forward. More information is available through our RAPI documentation on Github, but an example pattern looks like this:
As you can see, it’s pretty easy to follow. One of the things that caught my eye was the ability to search for strings. Now the MAG2 will only do this when a file is active (i.e. actively writing the string to a file). MAG2 is a behavioral analysis tool so it doesn’t run strings through a dead binary. Now compare this to a Yara rule:
(Yara Rule Courtesy of AlienVault Labs)
What prevents me from looking for that string when the file is written? Essentially, if a file recreates itself or drops another file with that string in it, I should be able to create a rule that finds the target string. But if I have lots of rules, and little desire to write a bunch of JSON, I should be able to write some code that does that work for me, right? So what I’m going to do is walk you through what I wrote and why.
Disclaimer: Before I go through this code, there are better ways to write stuff … I am not an expert Python programmer, and don’t pretend to be one, so you don’t need to tell me there are better ways to write it, as I am sure there are. Just take it for what it is, an example of wrapping a tool into the MAG2. If you can write something better, please post it to github to share.
First, I wrote something to open the files and setup some dictionaries for the JSON conversion:
For me, I prefer that the Yara rules be imported under a separate user that is not global. I don’t want to affect current risk scores. I just want to see what the Yara rules will come up with on the same sample set. So I created a user called Yara and will import the rules under that user and set Global to 0 so only that user can use the rules:
Then I have it start parsing the file row by row, essentially looking for keywords (regex is very useful here):
As you can see, first I started looking at the conditions, is it all of or any of? The script as it currently stands only supports files where the strings are in the string section. I know it doesn’t absolutely require it, but some structure helps when parsing a file.
Once it gets down to strings sections it has to determine what strings we are looking at:
First I determine the event type I want to write. I hard-coded it to a single pattern here, mostly as this is a proof of concept. You could use IP_Send and search for patterns in the data (such as GET statements) or other events.
After writing the event of course I need to write the data to the event:
This is essentially filling out the value field. So what you end up with is a JSON File like this:
Then you just import it into the MAG2 and it looks like this in the GUI:
There are a few caveats with the script I wrote, one being a dictionary, it doesn’t like to assign the same name (for example Event_type = FS_Create) to multiple meanings, and it tends to overwrite. Also, it’s setup to just write one rule and then quit. To really make it effective, I would next write a wrapper around it to iterate through an entire group of Yara files.
As you can see, integrating existing tools such as Yara into the MAG2 is pretty straightforward. This example shows how to generate patterns from Yara rules, but you could also integrate in other ways, such as running the sample through Yara before automating submission to the MAG2 (through the APIs), then outputting both sets of data into a single file, or writing scripts that automatically submit the file to the MAG2 if Yara comes back blank. The strength of the Malware Analyzer G2 is its flexibility to fit into your existing infrastructure and integrate other tools to enhance analysis capabilities and increase productivity without requiring a system rebuild.
