In our most recent rule pack, amongst the 39 new rules were two very important rules that may require a bit of analyst work when you see them alert.
The two rules I am referring to are:
* 1:25041 <-> ENABLED <-> EXPLOIT-KIT Java User-Agent flowbit set (exploit-kit.rules)
* 1:25042 <-> ENABLED <-> EXPLOIT-KIT Java User-Agent downloading Portable Executable - Possible Exploit Kit (exploit-kit.rules)
25041 looks for a Java User-Agent outbound from your network in the User-Agent string of the http header. While it's not totally unusual for Java itself to form http requests on the network, this will happen from time to time, that's not what we are focusing on.
25042 looks for an executable being downloaded onto the system, first checking to see if the flowbit from 25041 is set. Meaning, that it's not a browser downloading an executable, it's actually Java.
From my continuing work on the "exploit-kit" category of rules, I've noticed that almost every single time a Java exploit is used to bring download an executable onto a compromised box, (which is almost every exploit kit I've seen so far) it's malicious. In fact, we've had these rules in our test systems for about a month and we've seen zero false positives.
Now we know that every network is unique and while we didn't experience any false positives in the test systems that we have, I am sure they will occur in real life, so let me give you a hint of what to look for.
#1 -- Look at the URL that was the referrer for the download.
In the Sourcefire interface, we show you the hostname and URL that prompted the initial download of the file. In this case, it's not so obvious to tell if this one is malicious, but if we look at the http header of the file being actually downloaded:
#2 -- Look at the header:
You can see the file is plainly named "calc.exe". So a couple things indicate that this is bad. "calc.exe" is the name of the built in calculator program that is installed on every Windows machine in the world. There's no way that this file needs to be downloaded from the internet. Second thing is, the name of the file being downloaded is different from the name of the file being requested. Third, this is an indicator of the Blackholev2 Exploit Kit.
Let's look at another example.
While not obvious to the common observer, this is also an indicator of the Blackholev2 Exploit Kit downloading its payload. If you'll noticed, it almost looks like there is a "mac address" in the url. (It looks like a mac address, even though it's clearly not, we detect this as well with another rule shipped recently: 25043). If you look at the header on this one:
You can see "readme.exe" right there under filename.
While it may be an extra layer of protection to write rules that look for these known bad files in the blackholev2 exploit kit, the way I wrote 25041 and 25042 will catch much more.
Here's an example of another exploit kit that was simply caught by these rules:
...and the header:
Now, even if you don't have a Sourcefire device you can still dump out the "extra data" fields from your unified2 logs and see exactly which url's prompted these downloads like I show above. More information about how to use these fields can be found here: http://manual.snort.org/node255.html.
Happy hunting!