Malware Forensics at Large Firms
The malware forensics work-cycle is fairly tight at the day job. It focuses more on answering questions like:
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.
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]
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.
Apr 30th 2010
9 years ago