TDL4 removal leads to Windows 7 64-bit stop error on boot

I’m proud to say that it’s been literally two years since I’ve reformatted a PC due to malware, and I’ve disinfected many hundreds in that time period. But yesterday, I encountered a PC infected with TDL4 (which I’ve dealt with many times), however this one was a Windows 7 64-bit machine. Following removal of the rootkit offline via TDSSKiller in WinPE (set to scan Boot Sectors only), the PC began crashing on every boot, even when Safe Mode was attempted. The typical invasive offline procedures I use to rectify these issues — such as the disabling of nearly all third-party filesystem and NDIS filter drivers — did nothing to correct the issue. Restoring a previous System Restore point and even manually restoring the registry hives from the RegBack folder also accomplished nothing.

Finally, I decided to backup/restore the BCD. To do this, I used a Windows 7 recovery disc (in my case, ERD/MS DART) and opened a command prompt. From there, I (mostly) just followed the Microsoft guidelines for restoring a corrupted BCD:

c:
bcdedit /export C:\BCD_Backup
attrib -s -h c:\boot\bcd
ren c:\boot\bcd bcd.old
bootrec /fixmbr
C:\boot\bootsect.exe /nt60 all /force
bootrec /RebuildBcd
bootrec /FixBoot

(Note that C: must be replaced with the relevant Windows drive.)

This corrected the issue on this PC. I hope this helps someone in the future!

TDL4

In keeping with tradition, this year has seen a great number of TDSS (Win32/Alureon) rootkit infections, many of which go undiagnosed by the average tech. Although the numbers have dropped off some, the difference now is that those who are infected face a much more difficult diagnosis, as TDSS (a.k.a. Win32/Alureon) has continued to evolve.

The latest of these iterations is TDL4 (referred to here as DOS/Alureon), which manages to infect the MBR, as well as in some cases, a kernel-mode driver. This technically classifies it as both a bootkit and a kernel-mode rootkit (although theoretically these are wholly separate infections), making detection and removal extremely difficult and risky.

Even worse is the fact that TDL4 stores its primary rootkit code in an encrypted virtual file system. In cases where a combination infection is present, if the bootkit is removed, the kernel-mode rootkit can seemingly resume activities regardless.

Symptoms and diagnosis

The purpose of TDSS is to provide control over an infected PC so that it can be administered by an attacker (generally, a customer of the malware authors), who can then use the PC for whatever they choose: generation of web page hits, advertising, spam, or information theft.

The primary symptom of a TDSS infection has not changed: most often, the infected computer will redirect internet searches to pages of its own choosing. The mechanism behind this works on the HTTP protocol level; typically, the infected computer’s network traffic is also routed through a fake network proxy which actually redirects all network application traffic first through the rootkit. Attempts to remove this proxy setting will, of course, be reversed if the rootkit is not first dealt with.

One way to diagnose whether or not a system is under the control of TDL4 is to open a Command Prompt and type diskpart, followed by lis dis. If you receive the response there are no fixed disks to show, it is likely you are dealing with a TDL4 rootkit.

A wealth of utilities exist which claim to be able to diagnose and remove this threat. Most of them work quite well, but all of them are risky. Since TDSS is updated on a very regular basis, new variants adjust their strategies. As a result, running one of these utilities without a full system drive image can occasionally result in an unbootable computer. The only way to correct this if it occurs is to find the offending patched system file from offline and replace it with a known good copy.

Personally, I have written a script to search for patched system files and replace them automatically to ensure I do not miss any kernel-mode rootkits when suspected.

My most recent encounter

Although I generally still encounter TDSS on a weekly basis, the most recent version of the infection I saw was a combination of the TDL4 bootkit and the TDL3 random system driver rootkit. It was not clear whether the TDL3 rootkit was still active in any way following the TDL4 infection; naturally, I didn’t allow it to stick around long enough to find out.

Regardless, the bootkit was first removed, after which the system file, isapnp.sys in this example, was replaced offline with a known good copy (in this case, found in the computer’sdllcache folder). Afterwards, I removed the conventional fake network proxy to restore internet connectivity, as well as cleaned up some NTFS mount points which were probably left by another unrelated infection (possibly the max++ rootkit from last year).

And, of course, the final step was to kill a boring old rogue antivirus application that just wouldn’t go away with TDSS’ protection behind it. Good riddance!

If you’re looking for computer help in the Louisville area, look no further.  Call me today and get it done right!