We recently published an analysis of the TDSS rootkit, and just as we expected, TDSS continues to evolve. A new variant of the rootkit, TDL-4, which can infect both 32-bit and 64-bit operating systems, appeared sometime between July and August, 2010. In this article, we describe a new loading method used by the rootkit and examine how the rootkit bypasses PatchGuard and the Windows code integrity mechanism, the protection system built into 64-bit Windows operating systems.
Importantly, TDL-4 has a different set of components to TDL-3. Here is a list of the components included in TDL-4:
Like the previous variant, the rootkit uses its own file system that is encrypted using the RC4 algorithm. It stores all of its files in the last sectors of the physical drive.
As with previous versions, the rootkit makes use of a configuration file.
The TDL-4 configuration file is slightly different from that of TDL-3, the main difference being the rootkit version number (version=0.02).
It can be seen from the list of components above that file names include the numbers 32 and 64. This demonstrates that the rootkit should work both on 32-bit and 64-bit operating systems.
This time, a different and already proven method of infection has been chosen for TDSS. Like another notorious rootkit, the bootkit, TDL-4 infects the Master Boot Record (MBR). This enables it to load before the operating system, right at the beginning of the computer's boot-up sequence.
The code in the MBR uses an unsophisticated encryption algorithm, but even small modifications to the algorithm are sufficient to evade signature-based detection by most antivirus products.
The main function of the MBR loader, which is small in size, is to search the rootkit's encrypted partition for the ldr16 component, load it into RAM and pass control to it.
Once loaded, ldr16 hooks BIOS interrupt 13h, which is used for disk input/output. Next, it finds a copy of the original, uninfected MBR, which was saved to the rootkit's encrypted partition during infection, and copies it to memory over the infected MBR. Then it passes control to the original boot record.
The original MBR reads the operating system's boot loader from the hard drive and passes control to it. The boot loader then reads the system kernel and the relevant dependencies. Interrupt 13h, already hooked by the rootkit, is used to read data from the disk.
Every time that the BIOS 13h interrupt is called, the hook installed by the rootkit is also called. It then waits for certain files to be read into memory.
To continue loading, the rootkit requires the kdcom.dll component - a system driver used in the early stages of the operating system kernel's initialization.
Windows debugger component
To find a copy of kdcom.dll which was read into memory, the interrupt hook function scans each sector that was read, looking for a signature matching the file.
When ldr16 finds a matching signature, it searches the rootkit's encrypted partition for the ldr32 or ldr64 component, depending on whether the operating system is 32-bit or 64-bit, reads the relevant file from the hard drive and replaces the original kdcom.dll in memory with the contents of that file. As a result, a malicious component of TDL-4 is loaded into memory instead of the legitimate system component.
The ldr16 component has one more feature: a procedure for changing the Boot Configuration Data (BCD) in memory. BCD is a registry hive that is used by the Windows Boot Manager and is supported by Windows Vista and later operating systems. It replaces the now outdated mechanism which used to use the boot.ini file.
The TDL-4 rootkit searches the BCD for the BcdLibraryBoolean_EmsEnabled key, which has the signature "16000020", and then replaces it with the "26000022"