Anatomy of a rootkill: Hunting down and destroying undetectable malware
by Chris Bequeath
(The following is a true story, documented during an actual detection and removal of an unknown rootkit)
A computer arrived in my shop with the usual symptoms of malware – running slow, website redirections. It was running Windows Live OneCare for antivirus, and Webroot Spysweeper. The customer had already tried tools like Spybot S&D to fix the problem. When that didn’t fix their problem they took it to one of the big box stores, where they said the only way to fix it was to wipe the drive and reload the data. This was unacceptable to the customer, and that’s how I ended up with the PC.
A quick inspection in Safe Mode revealed one of the newer smitfraud variants, along with other malware of various sorts. A quick run through of the registry and filesystem took care of those. Opening HiJackThis to clean up any leftovers showed a suspicious entry under WinLogon named frvemmei. Killing it and rerunning HJT showed the entry re-spawning instantly.
So I opened up the trusty windows registry editor and searched out all entries for frvemmei. Unfortunately, the malware had locked the entry so it couldn’t be deleted. I tried changing permissions, and even tried regedt32 just in case.
A quick boot to UBCD4Win to delete the files and registry entries showed the registry entry, but no sign of the file ‘ccbaccb.dll’ in system32 where it was visible, but unable to delete while Windows was running. Rebooting windows showed both the file and the registry entries were back. So figuring this machine had a rootkit I ran RootkitRevealer, Sophos antirootkit and a few other tools, all which showed clean. I removed the Webroot and OneCare software, then installed AVG virus and spyware software. Surfing to the system32 folder and doing a shell scan on ccbaccb.dll with AVG showed obfustat.vyg, but it was unable to clean.
Researching the registry entry, the dll file and the AVG result turned up no information. So this looked like an unknown rootkit. Now the fun begins!
First off I had to find what was loading the files. Firing up Process Explorer from Sysinternals
( http://www.microsoft.com/technet/sysinternals/ProcessesAndThreads/ProcessExplorer.mspx ) and searching for the file ccbaccb.dll came up with the following:
So now we can see the rootkit has hooked into the kernel at bootup in the explorer.exe file, meaning it has complete control over the OS and how software operates – including antivirus software. Any machine that is compromised in this fashion, either from a system file, a driver dll or any other file loaded before the operating system boots cannot be trusted with scans that run on the machine. This includes online scans which load applets, file definitions and other things needed for the test onto the host PC.
It’s a sure bet that the explorer file is what is reloading the frvemmei and ccbaccb.dll. So this will be a fairly easy one to fix not only the infection but the corrupted Windows files.
But now that we know how to kill the rootkit, it’s a good idea to find out what first infected it in the first place. Booting into normal mode and running regmon and filemon (available at Sysinternals site) shows something unusual. Every few seconds a file is loaded called lighthouse.wma. At the same time a registry entry is created. Searching the registry shows only the one instance of the file. Searching the PC shows the file is located in the LimeWire Shared directory. The registry entry it creates is for our old friend frvemmei in the RUN key. So it appears the lighthouse.wma file was the progenitor. Once run, it created keys in the registry and created the ccbaccb.dll file. Upon reboot the dll file (really an exe disguised) modified explorer.exe which would ensure that it was always recreated if it was deleted.
Now for the cleaning. Boot to your favorite boot disk with a remote registry editor. Find all instances of ccbaccb.dll, frvemmei, and lighthouse.wma on the drive and in the registry and delete them. Also delete explorer.exe from the drive. Insert the correct Windows disk (or use system recovery) and perform a system repair. This will replace explorer.exe with a clean copy, along with any other modified windows files. Retest the PC, check with HJT to make sure there are no rogue entries and your done!
This process if performed straight through, would take a couple of hours with the longest time for the repair install of Windows. While researching this issue to make sure that no software would detect it, I ran Trend Micro’s Housecall, PandaScan, F-Secure, BitDefender, SpySweeper, AVG and AVGAS, McAfee, Spybot S&D, AdAware, SuperAntiSpyware and some standalone tools such as CWS Shredder. All tested the PC as being clean after the initial malware removal of smitfraud, vundo and other minor malware infections. The PC was put through at least 30 reboots to make sure the processes didn’t return.
Copyright 2007 Chris Bequeath. All rights reserved