Looking at a Rootkit

Having an anti-virus device on the edge of your email network is important, but you can’t rely on it entirely. If you’ve got your AV doing hourly updates, that means you’ve got a 1 hour window for someone to exploit.  In my case, any executable files are forwarded to my account for manual review. Most of these are obvious phishing attempts or viruses.  This week, I caught one that looked real, and decided to dig into it a bit more.

This attachment, batch.scr, came from a valid email address, for a company we do buisness with, and addressed to a person I’ve had to forward executable files to before.  The name sounded genuine, and the grammar was coherent.  I checked with the addressee, and she wasn’t expecting any files from this person.  I decided to run it thru VirusTotal (a great free scanning service) and Norman Sandbox (reports what the file does when it is run).  VT came back with only 1 engine flagging it as suspicious, but the Norman report showed that it did create a dummy csrss.scr file.  I saved the file for later review at home.

I fired up a clean, patched WinXP VM and downloaded the file I had intercepted.  The first time I ran it with the network disabled, it threw a false ‘program error’ message and left a 0kb csrss.scr file.  I deleted that file, reenabled the network, and ran it again.  It immediately phoned home, downloaded some modules, and attempted to open a malformed PDF file.  My VM had been rooted.

So, here is the step-by-step breakdown of what happened.  You can follow along by downloading the Wireshark capture.  Note that this was done with full packet captures, so technically it does contain the rootkit, just in a non-assembled form.  So if your AV freaks out, that’s why.  Future captures will be done with the 68 byte limit to avoid this.

1-277: Reaches out to a compromised server and downloads ‘pdf_100.scr’, make a note of the ID 11071 parameter
8: Not entirely sure what this packet is for, possibly the kit trying to HTTP ping a command server
278-321: Downloads a valid PDF file from the State of California regarding unauthorized charges by AT&T. At this point, Adobe opened automatically.
322-1029: Downloads ‘install.exe’, which appears to be the bulk of the rootkit, and flags as W32.Delf on many scanners. The host is a compromised b2evolution CMS install.
1030-1293: Grabs a Zip file library written in Delphi, used in the next step
1294-2422: Grabs kit.zip from the same blog. It is an encrypted zip file which contains another zip file.
2423-2457: The rootkit phones home. The first 2 attempts appear to fail.  The 3rd one works.
2451: Apparently, my machine is assigned ID 11071, as that number popped up again.  It is not idle, and is awaiting commands.

Every time I open IE since this, there are a couple of phone-home packets with that ID number. You can take a look at the Hijack This log and see a couple of oddities now, a svchost.exe and csrss.exe running out of the c:\Windows\inf folder.  Rootkit Revealer refuses to run now (it shows up 3 times in the log but bombed out after freezing the machine for a couple of minutes)

So there you have it, from safe to a fully compromised system in under 45 seconds. If this were a corporate environment, you’d be in the same situation as if someone plugged an open AP into your network.  In addition to up-to-date AV and local admin restrictions, you should have some seperation between your user network and server network.  This will help limit damage from something like this to non-mission critical systems.