Threat Level: green Handler on Duty: Xavier Mertens

SANS ISC: InfoSec Handlers Diary Blog InfoSec Handlers Diary Blog

Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
ISC StormCast for Thursday, November 13th 2014

PCRE for malware audits

Published: 2014-11-13
Last Updated: 2014-11-13 00:12:26 UTC
by Daniel Wesemann (Version: 1)
4 comment(s)

When auditing a company for their malware defense savvy, you are likely used to be presented with colorful pie charts of all the malware that their Anti-Virus (AV) product of choice "successfully" intercepted. Odds are that your auditee can show statistics for the past five years, and related "trends" of doom and gloom.

The problem is, we aren't really interested in that. Counting what the AV caught is like counting the number of hits on the final "drop" rule of the Internet firewall: It shows scary numbers, but who cares, given that this is stuff that was STOPPED.  Way more interesting is stuff that managed to sneak by and was missed ... but how do we find it?

One approach that I like to use involves "Perl Compatible Regular Expressions" (PCRE).  You likely encountered PCREs before - Perl has one of the most versatile sets of regular expression language that can be used to match any text pattern imaginable. Snort, for example, supports PCREs in its rule language. Amazing Perl, of course, supports PCRE natively. And .. lo and behold, the lowly Unix "grep" command, on many Unix flavors, supports a "grep -P", which gives it alien PCRE powers.

What to do with them powers, you ask?  Well, in an audit, obtain the last 10 days or so of proxy server logs. Most companies have them, and be prepared that they are HUGE. Plunk them onto a Unix system of your choice that supports "grep -P". Then, if you are reading malware blogs like Kafeine's and Brad's, you have an ample reservoir of URLs for currently active threats. If you "speak" PCRE, turning these URLs into "patterns" is no big deal, and provides good fresh intel. If you don't speak PCRE, you (well, should learn!!) can make use of the "current events" ruleset of Emergingthreats, for example Look for recently added rules that cover trojan activity.

Then, for the analysis, piece the various PCREs together into one big bad*ss PCRE, and run it in a "grep -P" command, like thusly:

daniel@debian$ grep -P "(http:\/\/[^\x2f]+\/[a-z0-9]{6,}_[0-9]+_[a-f0-9]{32}\.html|\/[a-f0-9]{60,66}(?:\x3b\d+){1,4}|\/\??[a-f0-9]{60,}\x3b1\d{5}\x3b\d{1,3}|\/[0-9a-z]{32}.php\?[a-z]{1,3}=[0-9a-z]{32})" bigproxylogfile.txt

Nov 10 11:43:18 squid[20791]: time='2014-11-10 11:43:18'; rc='TCP_MISS/200'; ip='';  head_type='application/x-shockwave-flash'; size='10751'; req='GET'; url=';130000;214';  referrer='';

Yes, it will take a while, but if you get any hits, like the "Fiesta" exploit kit hit shown above, I guarantee that it will be highly entertaining to ask the auditee if and whether they noticed anything amiss on the PC on November 10. The "fresher" your PCRE, the better the results that you will pull out of the log. With a decently up to date PCRE, I have yet to see an auditee who doesn't have several "hits" in ten days worth of proxy logs.

If you have any cool PCRE malware detection tricks up your sleeve, please share via the comments below!



4 comment(s)
Diary Archives