If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

TDL3: The Rootkit of All Evil?

TDL-3's been "in the wild" for some time (2008?) from everything I can tell,
but this weekend was the first time I've run across it. I'm posting this
because I was altogether unable to get a handle on this thing until I got
this client's desktop on the bench, and to make others aware there are
increasingly sophisticated rootkits out there.

My SOP (standard operating procedure, aka SOB) simply was not fixing this
thing. I'd run Spybot and Malwarebytes only to have them come up clean.
Antivir would clean malicious files, a dozen in one day at one point, but also
seemed unable to get to the root (no pun intended) of what was going on.
Basically what was occurring was this client's PC would get reinfected, and
was running slow as well as suffering redirects from a Google search page (a
primary symptom it turns out).

Combofix, my "last resort" app found it, supposedly removed it on a reboot,
only to have the thing return. There's a dropper in there somewhere. Finally
I found a Kaspersky tool, which is available here:

Running TDSSkiller turned up the rootkit as HD0, which is unusual to say the
least. I did run a system file check ("sfc /scannow" from the Windows shell)
after finally getting this thing cleaned out as insurance. The computer I was
working on was a 32 bit XP install, but this also infects 64 bit systems supposedly.

ESET's got a whitepaper out on the rootkit and how it works. It apparently
disguises itself as hardware.

UAC is by no means bulletproof though, although setting it to its highest
level appears to help (what a pain). Microsoft backed off on the UAC
setting with Win7, defaulting the security level lower than it is in Vista.
And of course, this does nothing on XP installs. TDL-3 appears to have
been circulating since August of this year. There are two previous versions.

However, on x64 platforms kernel-mode rootkits do not feel so at ease, both on x86 systems. This is one of the factors to choose the method of infection computer - infected MBR. Another factor is that most modern anti-virus technologies, primarily anti-rootkit technology, not ready to deal with threats to the x64 platform, and it strongly makes life easier for virus writers.

"Armed to the teeth» TDL-4 is a very serious danger to users - and continues to evolve. Antivirus companies urgently need to build upon their own anti-rootkit components, as in the case of a rootkit infection data for ordinary users will simply leave no chances.

Question: does formatting a HDD overwrite the MBR? Anybody know? This client
had an MBR virus a couple of months back, and I used a utility called MBRfix from
a PE disk to restore it. I've seen a few posts on the forums I've been thru that seem
to indicate it is not unusual for a computer to become reinfected after formatting.

It has the ability to pick up an IP from a DHCP source and then download our latest signature file and scan.

Just remember that it is extremely difficult for AV vendors to mess around with the MBR and rootkits in general because one incorrect disinfection can corrupt the partition this forcing a format of the HDD.

I will ask the manager at Panda Labs to give me some more information on this malware and will pass it onto you.

EDIT

This is what my LAB guys came back with.

TDSS is a very complex rootkit. When it is loaded and hooks are installed on the system, is very difficult to attack it For this reason we decided the best way to attack this rootkit is attacking it before it was fully installed.The rootkit use lot of tricks to hide itself: it hides itself in disk sectors, it hooks dispatch routines of the miniport driver of the hard disk that is infected to hide the sectors, some versions infects system drivers instead of install its own driver to stay alive after rebooting, ...

Some versions of the virus install a boot driver and other versions infects disk drivers: atapi.sys, iastor.sys,... This piece of code is responsible for loading the rest of the rootkit (stored in disk sectors). If we stop the rootkit before it was able to load the part stored in disk sectors, we will be able to clean the system from user mode.

TDSS needs to wait until the file system was loaded to get the code stored in disk sectors. Sometimes it installs a file system notify routine with IoRegisterFsRegistrationChange. Other times (when it infects atapi, iastor,...) it hooks MJ_DEVICE_IO_CONTROL handler of the infected driver for waiting a io control (when that iocontrol is received TDSS knows the file system is loaded).

How can we attack TDSS? We install a boot driver and try to load it as soon as possible (using SYSTEM\CurrentControlSet\Control\ServiceGroupOrder for example). We also install a callback with PsSetLoadImageNotifyRoutine so that we can analyze entrypoint of the loaded images searching for the rootkit code. If we find the code, we stop the execution at that moment (by overwriting the code in the entry point, or restoring the execution to the old entrypoint,...). Doing that the rootkit is out and we will be able to clean the system from user mode.

Last edited by Cider; December 21st, 2010 at 01:18 PM.

The world is a dangerous place to live; not because of the people who are evil, but because of the people who don't do anything about it.Albert Einstein