Rootkit and Antirootkit developments have always been a cat-and-mouse game and it has become more widespread since rootkits have started being the right friend for trojans, backdoors and other nasty infections used to steal user credentials or to get access to infected PCs.
While writing trojans or backdoors is not bringing any new technique - all new samples we analyze are often just using old and known tricks - rootkit development is the real field where malware writers could show their skills, their potential, their fantasy.
While at the beginning writing rootkits was more a pure exercise and a way to show how the system could be easily compromised, now they are strongly playing along with trojans and backdoors to help them subverting user's systems.
Malware writers are now sending a "catch me, if you can" message to antivirus companies in a hide-and-seek game where rootkit techniques are always a step ahead to security countermeasures and they open wide the road to every other malware which don't mind using even old and known tricks - they are just invisible to everyone, they are free to do as they please. Key word is money.
Tdss rootkit 3rd variant is the last member of Tdss rootkit family that is quickly spreading around the world. While a number of rootkits are just developed as a proof of concept, this is not the case. Tdss rootkit is well known to antivirus companies because of its goal to get total control of the infected PCs and using them as zombies for its botnet.
During these years it has always shown a team of skilled people behind it, who always applied advanced techniques often able to bypass antirootkit softwares. Actually, this last variant could be easily named as the stealthiest rootkit in the wild.
This infection is bringing all together the best of MBR rootkit, the best of Rustock.C and the experience of old Tdss variants. Result is an infection that is quickly spreading on the net and it is undetected by almost every security software and 3rd party anti rootkit software.
The infection comes from the usual dropper spread by peer to peer networks or by crack and keygen websites, and it needs administrator privileges to run its payload. If UAC is disabled or the user voluntarily gives admin permissions, this infection can run even on Windows Vista and Windows 7. This is likely to be the usual scenario, where a user looks for specific cracks and don't mind if UAC warnings him, he gives admin privileges to the wanted crack.
When run, the infection is using a similar technique applied by MBR rootkit: all kernel mode and user mode components are stored to the last sectors of the hard drive, outside the file system. By doing so, they appear to be only raw bytes, bypassing every security check. Tdss rootkit bring this trick to a more advanced level, by encoding its components before they are written to the disk. Files are encoded and decoded on the fly.
Then, to be loaded at Windows startup, Tdss rootkit uses a technique we have seen applied by Rustock.C rootkit - and other rootkits like Neprodoor: infecting Windows system drivers. Tdss rootkit walks back the chain of drivers that handle hard drive I/O looking for last miniport driver object. When found, it infects driver's PE file by overwriting 824 bytes of the resource section. By doing so, it evades a simple check that some antirootkits usually use to detect hidden rootkits: file size cross check. Usually rootkits that infect files can hide their presence by showing the original file instead of the infected one. Antirootkits which are using raw disk reading techniques could read below the filter applied by these kind of rootkits and could cross check file sizes looking for discrepances.
This time is different, because of two evident reasons: currently no antirootkit is able to bypass disk filtering technique used by Tdss rootkit but, even if it was possible, this rootkit could not be detected by file size cross check because file size of the original and infected files are exactly the same.
When the infected driver runs, it executes the 824 bytes loader which then runs the kernel mode component of the infection. It creates a fake driver object, its relative device object, and hijacks every disk I/O communication at the level of drivers's chain where the infected driver was located (i.e. infected driver could be atapi.sys, or iastor.sys).
The rootkit intecepts every communication and filters out IRP_MJ_SCSI packets that have specific SRB flags set. By doing so, it hides patched driver on the disk and all disk sectors where its components are located. This is a really effective technique of disk hiding.
Tdss rootkit then sets up a Load Image notify routine to intercept every process that loads kernel32.dll library. When intercepted, it injects inside the specified process its user mode components of the infection, tdlwsp.dll, tdlcmd.dll. They are able to turn infected PC in a botnet's zombie. Config.ini, one of the components of the infection, contains settings of the botnet, commands to be executed, bot ID and C&C servers addresses. Communication with C&C servers is SSL encrypted, to evade HTTP filters.
Tdss rootkit is indeed a really worrying infection, it is in the wild and it's quickly spreading without being intercepted and detected by almost anyone. Some antiviruses may throw up a warning about the presence of tdlcmd.dll or tdlwsp.dll, without being able to do anything. Most of times users won't be warned at all, they just don't know their PC is part of a botnet and it is under the control of malware writers which can use their PC as they please.
We heartily recommend to not download and use cracks or keygens, they are often vector for very nasty infections.
Despite the complexity of the infection we are able to detect and clean the infection and we will update Prevx with appropriate detection and cleanup routines. In the meanwhile, every Prevx customer who has been affected by this infection can contact our technical support who will remove the infection by remote assistance.
12 comments so far
- Subhro on Nov 21 6:48, 2009
- Subhro Bhandari on Nov 21 8:25, 2009
- Phantasm on Nov 21 11:01, 2009
- Philip on Nov 23 16:04, 2009
- Randy on Dec 2 1:22, 2009
- Josh on Dec 2 22:44, 2009
- Daniel on Feb 13 18:49
- carl on Feb 17 20:36
- Doug on Feb 20 22:36
- Mickets on Feb 23 16:34
- Bill on Feb 26 17:06
Thanks for the News, keep the good work up!
Thanks for the news, hope you guys will provide more such news!
Ultra nice, i learnt a lot there!
My project today was to get rid of this tdlcmd.dll that kept coming back. Downloaded and ran your software and so far we're clean. Hope it stays that way. Great article.
I wonder if one could just boot to a Linux boot CD like Puppy and remove the infected dll files. That's what I ended up doing when I removed AVG and installed Microsoft Security Essentials. Immediately MSE picked up on com4.q something I can't remember now. MSE saw its actions, but couldn't see it to remove it. I booted to Puppy and removed the file. The computer was fine after I rebooted.
MSE called it LinkOptomizer. I assume it was a rootkit because I couldn't find the file using Explorer in Windows.
According to its file date, it was on that computer since May of 08. Two thumbs down for AVG. :)
Thanks for the info,
So, Is their really any possible way to remove once infected?
I have a hard drive that's encrypted and their is no way of botting into an ultimate boot cd and i have tried loading the drivers into recovery console.
Can somebody translate it to German please?? I can't understand this Report about the Rootkit... :D
what if one runs an infected exe in a sandbox like sandboxie. does that prevent infection?
If one shreds his free disk space with a program like fileshredder, does that also erase the last sector of the hard drive, outside the file system?
Could a disinfectant program be made that wipes spaces (like PE files' resource sections) that are vital to the rootkit's propagation?
Sandbox: I have a virtual machine running inside Virtualbox. That's where I install/run suspect things. I keep a "clean" copy of the virtual machine, and can always go back to it once I find the one I was using got in to something nasty.
Wonder if it could be stopped by editing the dll.
Thats what fixed Hypertrm32.dll, opened with notepad typed x and saved.
Originally Avast found C:\Windows\System32\Hypertrm32.dll and deleted but came right back, also deleting in registry it came right back.
After dll edit, deleted it in registry along with associated file, dpcrypt32.dll.
After reboot Avast found Hypertrm32.dll in C:\Windows\System32 and deleted it.


Nice wright up Marco thanks for the info!
TH