Rootkit Removal (Part 2: Excision)

I had found the mechanism that the rootkit was using to hook itself into the system, which was a registry Run key. The rootkit monitored the key and if you ever tried to remove the entry, it would add it right back.

Programmers often fail to deal with permissions problems -- that is they can deal with a resource not being present, but not so well with a resource being inaccessible because the user doesn't have the right permissions. With this in mind, I tried removing write permissions on the Run registry key. This created a chicken-and-egg problem, since in order to remove the malicious entry I needed write permissions, but if I removed the entry the rootkit would change it back before I could change the permissions. I tried this a few times, including other permissions permutations involving other users. No luck.



Running out of options trying to delete the registry key, I looked at other alternatives. If I could find the installation media I could have booted into a recovery console and hacked the registry from there, but I don't think Dell even ships installation media.  I tried booting into safe mode, but safe mode bluescreened. This may have been the rootkit or may have been some other driver that didn't like safe mode. At any rate, safe mode was out.

The safe-mode bluescreen pointed to a kernel-mode rootkit , which can be much more devious since it doesn't really have to abide by any rules. I would have tried a kernel debugger, but if the rootkit was smart enough to crash safemode, I figured it would be smart enough to have some kind of anti-debugging support as well. If the rootkit had a driver that wasn't cloaking itself, it should show up as an unsigned driver (it is unlikely a rootkit would pass windows signing process but you never know .. did they sign the sony rootkit?). I ran verifier.exe to list the unsigned drivers, but nothing was suspicious (except how much crap comes preinstalled on laptops... but that is another rant). This was a longshot, however, since a kernel-mode rootkit could hide itself from enumeration.  In that case,  "Rootkit revealer" from sysinternals should be able to find things that are hiding from the system.  It didn't find anything either -- pointing to a user-mode-only rootkit (or an especially devious one).

If the virus/rootkit was smart enough to repair the registry key that activated it and to evade Windows Defender and Rootkit Revealer, perhaps it was time to call in the professionals -- antivirus software. However, having a virus on the system makes you paranoid --"how do I know that I'm actually downloading what I think I'm downloading if somebody else has control over my computer?" For the truly paranoid, that is what md5 hashes are for. Since I'm only semi-paranoid, I used curl.exe to do the download directly.

It was good that I was at least a little bit paranoid, since when I searched for "antivirus download" in firefox, I got redirected to a bogus site. I have a pet peeve about antivirus software -- it is like the TSA -- it is there to make people feel secure by protecting against things that bad people have already tried, but the smart ones are going to be able to get around it pretty easily.

Given that I already knew I had a virus, I was willing to swallow my pride and installed Spyware Doctor free edition through the Google Pack (I was reasonably sure that this is what I really downloaded since it downloaded through the google updater).  All of my mistrust of antivirus software seemed justified when Spyware Doctor came back with a clean bill of health. True, this was the free edition, but if you can't detect a virus with some pretty obvious traits -- like write notifications on the Run key in the registry -- then what's the use?

Frustrated,  I gave up on detection tools and turned my attention back to getting rid of the rootkit myself. The obvious first step was to delete the file that was being run on startup (%windir%\system32\.dll. Access denied. I'm pretty sure I did an attrib -r -s -h on it and still got access denied, but in retrospect I think I might have just assumed that the rootkit was doing something funny to prevent the deletion of the file (see blog title). Here, the permissions trick worked -- I used cacls.exe to add a "Deny Everyone" ACL. After a reboot, the malicious Run entry couldn't run because the file couldn't be accessed, and the rootkit couldn't re-hook itself.  

After running google searches from firefox again and verifying that I actually could navigate to the links I expected,  I declared "mission accomplished" and told my wife her computer was fixed*.

*unfortunately, this was a bit premature