On the 5th Day of Christmas my True Love Gave to Me... 5 YARA RULES!!

Ok so maybe not, but I wanted to talk about YARA rules and the power they give to an analyst. You can grab Yara over on its GoogleCode page.

So let's go over an example then write one of our own (and test it of course). I am using my Remnux ISO, and I opened the default YARA rules which are at /usr/etc/local/capabilities.yara (I added the line numbers to make it easier)

1 rule embedded_exe
2  {
3     meta:
4     description = "Detects embedded executables"
5    
6     strings:
7     $a = "This program cannot be run in DOS mode"
8    
9     condition:
10     $a in (1024..filesize)
11  }

Line 1 is mandatory for every YARA rule. Basically this is saying "HEY! I am the start of a rule and my name is embedded_exe." This way when the rule triggers (based on its conditions) it can alert the analyst that the 'embedded_exe' rule was hit on. Now of course, it makes sense to be smart when naming your rules. Calling a rule "toot" or "honk" is not very descriptive.. unless of course you are looking for toot or honk....  There are of course some rules:

• Cannot start with a number
• Can contain numbers, letters, and underscores
• Case sensitive
• Limit to 128 characters (this isn't a eulogy, sheesh!)
• Cannot use reserved words (see the Users Manual for the list)

Lines 2 and 11 indicate to us that inbetween the braces is the meat of the rule embedded_exe. This is where we will focus!

Metatdata (lines 3 & 4) are optional but they are useful when there could be confusion as to why an analyst wrote a rule, and can provide background as well. Line 4 is providing some insight to the rule, which really is not necessary in this case but its a good practice to use them.

Line 6 delimits the start of the strings section. This is where you write out what exactly you want YARA to be searching for. There are 3 different types of 'Strings' in YARA, hexadecimal strings, text strings, and regular expression. The one seen on line 7 is a text string. This line is seen in every PE file.

Lines 9 and 10 tell YARA when the rule can be triggered. So in this example its saying "If you see $a (which we told you about in Strings:) anywhere from the 1024 byte offset to the end of the file... please let me know". Why you may ask? Well this is trying to find embedded executables, not just any ol executable. So this avoids us getting false positives of normal executables. Of course, if you want to find any and all executables that's fine too.. that's the power of YARA!

Ok, so enough of this, let's write a rule! (I know this rule has been written before and much better too, this is a learning experience remember!)

So one of the ways malware tries to hide itself is that it will pack itself using some program (UPX in our example). This means that normal AV cannot see whats inside because its packed and therefore its true contents is obfuscated. So let's write a YARA rule to detect for this! I open up VIM and start typing.

rule packed_with_YARA
{
        meta:
                description = "UPX string discovered"
        strings:
                $a = "UPX"
        condition:
                $a
}

I would also recommend before integrating this with your other YARA rules to test it on its own (so there are no conflicts to worry about). In remnux to test simply:

# yara /usr/local/etc/YARA_rule_to_test.yara (test_file)

If all is well (and your sample IS packed of course), the rule should trigger!

How can we make this better? Well I would first ensure that we are only looking at header/section portions of the file, maybe UPX is mentioned somewhere else in the file but actually has nothing to do with the packer? Also, one must also take into consideration the different versions of UPX and any potential difference between them that would cause this rule to miss. As I mentioned previously, this rule has already been written, which brings me to another case in point:  Check and see what the community already has out there! I should also point out anohter great way to learn is to walk thru other users rules and try to understand what they did. They may have a trick or two which you can use in your own practice! A good place to start is here. I will admit I do not use YARA as much as I should... a New Years Resolution maybe?

YARA can be run on files, packet captures,  and even memory dumps. Read the manual-- I barely scratched the surface here. There is even a Yara-Editor for those who like a bit more structure and seeing all options when writing rules.Test your rules, make them better... and keep testing!

Note: Anyone who is a fan of MAC probably also knows the handy ClamAV to YARA script, which adds more robustness to a fledgling YARA rule creators ruleset. Get the book, or check out this link.