Malware Season Pt. 1

Like I said last week, I'm going to write up my experience from last week with taking some "0h-day" malware (read: undetected by IDS or AV) from log finding back to analysis of the dropper and binary. This is a 2-parter, the first part covers from discovery through the dropper to getting a copy of the binary.

If you're aware of what's been going on in the malware arena for the past few years, and has visibly worsened over the last 6-9mos, then you know that you can't rely on your AV vendor to catch it all. (Remember all of that 'defense-in-depth' stuff from the Information Assurance "awakening" 4-5 years ago? Yeah, this is where it should be saving your bacon.) So one thing I've taken to doing is looking at firewall logs for outbound web requests that end in ".exe". I found one that was a "http://IP:PORT/bin.exe" It would be nice if the FQDN were captured here, but it's not. And as such, that file is just out of reach.

Using ArcSight, it was pretty easy to give that download some context by pulling up all of the Internet traffic to and from that workstation for 30 minutes before and 30 minutes after. After digging around, I found one of the web sites the user had visited that contained a single line of JavaScript on each page that contained an unescape() call that looked glaringly suspicious.


In addition to the unescape call, there's also another function named dF() that has a whole mess of obfuscated code in it. The first step is to find out what the unescape function will actually do. I used Rhino JavaScript shell:


The unescape creates a second set of script tags and defines the dF function. Now I can define dF in Rhino's shell and see what that does:


Oops. I needed to replace document.write with print in order to actually see output of the dF function:


There, that should work:


Now I've got a human-readable VBScript dropper with a URL. Grabbing the binary malware at this point is as easy as using wget. Despite the fact that the malware URL can easily be read, there's still obfuscation at work here. Check out the a1,a2,a3,a4 variables and then str1 = a1&a2&a3&a4 used to hide the string "Adodb.Stream." I wonder why. Like I said, both the JavaScript payload and the binary went undetected by the workstation's antivirus. Our IDS fired on both, but they were fairly generic detects - one for the JavaScript unescape function and another for the packed executable download.

Tomorrow I'll write up the basic analysis of the binary that I did along with some info on the type of external follow-up.