TDL4 rebooted

ESET researchers have been tracking the TDL4 botnet for a long time, and now we have noticed a new phase in its evolution. Based on the analysis of its components we can say that some of those components have been rewritten from scratch (kernel-mode driver, user-mode payload) while some (specifically, some bootkit components) remain the same as in the previous versions. These changes might suggest one of the following: either the team developing the botnet has been changed, or TDL4 developers have started selling a bootkit builder to other cybercrime groups.

The dropper (Win32/Olmasco.R) that we have analyzed sends copious tracing information to the C&C (Command & Control server) during the installation of the rootkit onto the system. In the event of any error, it sends a comprehensive error message which gives the malware developers enough information to determine the cause of the fault. All this suggests that this bot is still under development.

We also found a form of countermeasure against bot trackers based on virtual machines: during the installation of the malware it checks on whether the dropper is being run in a virtual machine environment and this information is sent to the C&C. Of course, malware that checks on whether it is running in a virtual environment is far from unusual in modern malware, but in this form it’s kind of novel for TDL.

Among the latest TDSS modifications that have attracted our attention are the way the rootkit infects the system, and changes in the hidden file system layout.

Order of the Boot

The bootkit part of the malware has been changed since the previous modification of TDL4. In contrast to its previous incarnation, where the MBR (Master Boot Record) was overwritten and space was reserved at the end of the bootable hard drive for storing malicious components, this version of TDL4 employs rather a different approach in order to infect the system.

Firstly, it creates a partition at the end of the bootable hard drive. If we look at the partition table of a hard drive with Vista or a later Windows operating system installed, we can see that there is some unpartitioned (or unallocated) space at the end. Usually this space is large enough to hold a rootkit’s components. Sometimes there is even more free space available, enough for the rootkit’s own partition. In such a case, the size of the malicious partition is limited to 50 GB. The malware creates a hidden partition by modifying a free partition table entry in the MBR partition table.

Bear in mind that the MBR contains a partition table at offset 0x1BE from its beginning in the first sector of the disk. This table consists of four 16-bytes entries, each describing a corresponding partition on the hard drive. Thus there are, at most 4 primary partitions on the hard drive and there is exactly one partition marked as active, which means that it is partition from which the OS will be booted. The malware overwrites an empty entry in the partition table with the parameters for the malicious partition, marks it as active and initializes the VBR (Volume Boot Record) of the newly created partition, as shown in this figure:

If there is no free entry in the partition table then the malware reports to the C&C server and terminates. You can see what happens with the partition table after the system is infected with TDL4 in the figure below.

As a result of these manipulations, the MBR code remains untouched. The only thing to be changed is the partition table. When the infected machine is next booted control is passed to the malicious VBR (the VBR of the TDL4 partition) right after execution of the MBR code and before the OS bootloader components are loaded. This allows the malware to gain control before the operating system does.

When the malicious VBR receives control it reads a file with the name “boot” from the root directory of TDL4’s file system, and transfers control to it. This “boot” component plays the same role as ldr16 module in the previous incarnation of TDL4: it hooks the BIOS interrupt 13h handler to patch the BCD and OS bootloader, and loads the VBR of the originally active partition. The bootkit components of the malware are the same as in the previous modification of TDL4 except that their names in the malicious file system have been changed.

New

Old

VBR of malicious partition

Infected MBR

boot

ldr16

dbg32,dbg64

ldr32/ldr64

The following diagram depicts the boot process of the infected machine.

Hidden file system

The layout of the hidden file system has been changed also. In contrast to the previous version, which was capable of storing at most 15 files – regardless of the size of reserved space – the capacity of the new file system is limited by the length of the malicious partition.

The file system presented by the latest modification of the malware is more advanced than previously. For instance, the malware is able to detect corruption of the files stored in the hidden file system by calculating its CRC32 checksum and comparing it with the value stored in the file header. In the event that a file is corrupted it is removed from the file system.

"the size of the malicious partition is limited to 50 GB": did you mean 50MB? Even on today's disks, 50GB would be a sizeable chunk to go missing.

David Harley

I’ll check, but I think that refers to a system limitation. No-one is suggesting that malware is about to start routinely eating 50Gb of disk: that would be counterproductive from the blackhat’s point of view.

ivan

I like the way Russian letter "yo" shows for 0xF0 on your binary print out on figure 1. Kudos to Alexander Matrosov. :)

David

Question is, if the VBR is infected than can the malware disable the NOD32 software, thus leaving it infected?

Nauip

Seems to me the best prevention is to not have any un-partitioned space? Or is this bugger smart enough to shrink a volume assuming there's free space?

Ajay

Any special removal tool for this type of nasty infection from Eset guys….?

David Harley

There are a number of removal tools available from the downloads/utilities page on the main web site, including tools for Olmarik/TDL4. However, they obviously aren’t updated on a daily basis like the regular scanner, and there’s no guarantee that they’ll work correctly with a particular example of malware as adaptive as TDSS. If you aren’t an ESET customer, you could try the ESET online scanner, of course.

Rafa Rodríguez

Is this new version of the bot still using Kad network to receive the C&C messages? And more in general, in which cases TDL-4 decides to comunicate via HTTP C&C or P2P C&C?

David Harley

Eugene says:
We didn’t notice any payload communicating with C&C over P2P protocol and specifically KAD in this modification of TDL4.
As to the second question, in fact, there are two independent plugins (cmd.dll and kad.dll) in some examples of TDL4, each communicating with C&C according to implemented protocols: HTTP(S) and KAD correspondingly. Thus, there is no decision making as such.

Reza

Based on your answer to Rada, It seems that TDL4 not a kind of P2P Botnet so far? right?

David Harley

Reza, no, that’s not it.

Where TDL4 uses kad.dll that does involve P2P. What you shouldn’t do is think of TDL4 as _either_ P2P _or_ C&C. The malware is highly adaptive and changes frequently.

Would not be a good idea to implement this system for / in the antivirus? And so "beat HAND" A malware?
-That is, the installed antivirus created hidden so that partition. and so on., etc. and work from there. etc. and from there connects to the server for updates.
– Adding of course their action to prevent any similar attempt by any other means.
– HOW WOULD THE ANTIVIRUS INDESTRUCTIBLE, right?

David Harley

I’m afraid that antivirus implemented within a hidden partition would be no more “indestructible” in principle than TDSS. Which certainly isn’t indestructible…

Cybrhelp

How does one get past this hidden partition to boot the system?

PCTech20

[Comment approved as some people may find it interesting: note, however, that I haven’t tested the techniques or resources described here in this context, they aren’t endorsed in any way by ESET, and we can’t be held responsible for any problems that arise from using them: caveat lector. This was actually edited down from three comments by the same poster.]

I don't think there is a way to bypass the hidden partition. What I have found is to use the management console in a different computer and "slave" the infected hard drive into it in order to look at the partitions on the drive. This is possible in Windows Vista or Windows 7. If there is a "strange" partition, it is usually at the end of the hdd and Windows identifies it as "Unknown" and shows it has been made active. Typically, you can then delete that partition after making active the true boot partition. Then I would suggest putting the hdd back into its original PC and booting the system into the recovery console. When in there, I would then use bootrec /fixboot, bootrec /fixmbr, and in some extreme cases bootrec /rebuildbcd. Once the system is booting properly, then I would boot the system to safe mode with networking and run ComboFix. After this, I would run full scans with the usual antimalware programs, also in safe mode. I personally use CCleaner or other good temp file cleaner first. Then I use Malware Bytes and Super AntiSpyware. If you have an antivirus that can do a boot-time scan, then run the boot-time scan after the previous 3 or 4 programs have been run. This usually cleans up the system pretty well. As for ComboFix, I only trust the version that is developed by BleepingComputer.com.

In some instances, the above procedure can work with Windows XP, too, but do not use bootrec. Also, rebuildbcd does not exist in XP. So the commands to use would be only fixboot and fixmbr for XP systems.

Wonder if you will see this post? I have an unallocated 2.95 partition that is not flagged as boot or shown as hidden by gparted. I would like to know if I can safely delete this without worry of boot problems? The last pc I had in my office gparted showed that it had a 1MB hidden boot partition and I unflagged and unhid it then deleted it.

David Harley

I’m afraid I can’t give you an unequivocal answer to that without direct access to the machine.

daniel

I got a new variant of this TDL virus, low level format HDD erase.exe, MHDD.exe HDPARM HDAT2 impossible to remove it. The pest created the hidden partition inside the DCO and possibly it add a password and then you could not remove it because of the password I have try evrything this pest is a mess ….
I try on my Seagate a firmware update no result and Western Digital indicate tham no firmware is available and buy a new drive. Possibly a new virus to make people buy new stuff. Note the virus work best on XP and 32 bit system on 64 bit I got lessporiblem for now, until it got through it. The virus comn ethroug a USB key possibly formating did not remove any virus since it go to the Protected Area

Format is useless SD Pendrive Har disk Hawker are srtonger than manufacturer and antivurs manufacturer. Only a company which do partitioning tool, HPA dco editor, could manage this threat, I beleive no comapny have the following requirement… Any Suggestion???