Malware Forensics at Large Firms

The malware forensics work-cycle is fairly tight at the day job.  It focuses more on answering questions like:

·    What are we dealing with?  (e.g. an adware like Monkif, or an information stealer like Zeus?)
·    Grab a sample to submit to the AV vendor
·    Identify network behavior so we can identify infected machines on the wire
·    How did it get in?

Depending on the workload, resources, etc. we don’t always get to answer all of the questions before the demands of keeping the business running or more severe incidents reallocates the response staff.
 

Smells Like Zeus

Last week, a sharp-eyed user noticed that their on-line bank was asking more questions than they usually do when they log in.   During the initial triage I noted that it “smelled like Zeus.”  Once we had got onto the box with EnCase we immediately looked for, and found, c:windowssystem32sdra64.exe on the system.  Sure, case-closed.  Submit the sample to AV to get them to update their signatures, examine the user’s proxy logs to identify the phone-home behavior and make signatures from that.  There, the organization is protected.
 

But How Did It Get In?

The final-step in incident handling and the most-often ignored is the root-cause analysis or lessons-learned.  With this particular case, I had a timestamp of when sdra64.exe was dropped on the box (if I trusted the MAC times) and could start digging through the web proxy logs for that machine at that time.  That sounds like a lot of something-that-isn’t-much-fun.

You know what sounds like more fun?  Timeline analysis.
 
(For more on doing your own Timeline Analysis in your environment, I recommend starting here: http://blogs.sans.org/computer-forensics/2010/03/19/digital-forensic-sifting-super-timeline-analysis-and-creation/)

In EnCase it’s not too hard to organize the view of the file system to track what files were modified or added around the time of sdra64.exe.  I was at first interested in the files in the Temporary Internet Folders location of the user, since it will help me narrow down what website was hosted the exploit.
 

Java Applet Cache Files

In addition to the HTML and image files in the Temporary Internet Folders there were also files created in c:Documents and Settings[victim]Application DataSunJavaDeploymentcache[numbers]

There were files that had hash-like names, some with no extension, some with .idx, some with .hst.

The extentionless file is a zip archive of the .class files or bytecode of the java applets downloaded to the system.  The .idx file looks suspiciously like the HTTP session used to pull it down, and .hst was the IP of the source.

That’s pretty handy information to have on hand.  But what is the significance of java applet?  On a whim, I submitted it to virustotal and it tells me that it’s an exploit for CVE-2009-3867.  Neat, now I know how it got in and where it came in from.
 

Prefetch Files

With the tight deadlines, and the rushed process of identifying the process generating the bot-net traffic, or what dll is getting injected into iexplore.exe I know that I’m missing a lot of the other files that get dropped onto the system.  If we’re lucky enough to get a memory snapshot of the system while it’s doing its evil I can use something like volatility to tell me what files a process has open.  If it’s after-the-fact, I can glean some of that information from the prefetch files.  In our zeus case while jumping into look directly for sdra64.exe I also saw SDRA64.EXE-[hash].pf.

The normal forensic value of prefetch files is it will tell you how many times an executable has been run and the last time that it was executed (I refer you to Harlan Carvey’s “Windows Forensic Analysis DVD Toolkit” pp 226 in the first edition, pp296 in 2nd ed)  The real purpose of a prefetch file is to improve the efficiency of the OS so it tracks what files are opened by the executable.  Using something like BinText you can see the list of files open by the application.  This gives me an additional list of files to check against the whitelist for.  In this particular example the .pf file also had a bit of HTML in there that looked like an iframe, I’m not sure if that’s a fluke or not, but it held additional clues about the exploit.