TDSS. TDL-4

Contents

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.

Components

Importantly, TDL-4 has a different set of components to TDL-3. Here is a list of the components included in TDL-4:

bckfg.tmp
cfg.ini
cmd.dll
cmd64.dll
drv32
drv64
ldr16
ldr32
ldr64
mbr

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.

Structures of the rootkits file system after decryption
Structures of the rootkit's file system after decryption

As with previous versions, the rootkit makes use of a configuration file.

Sample data in a TDL-4 configuration file
Sample data in a TDL-4 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.

Infection and loading

MBR

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.

Infected and encrypted MBR code
Infected and encrypted MBR code

Decrypted MBR code with the ldr16 string shown
Decrypted MBR code with the ldr16 string shown

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.

Searching for ldr16 loading it into RAM and passing control to it
Searching for ldr16, loading it into RAM and passing control to it

LDR16

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.

Hooked BIOS 13h interrupt
Hooked BIOS 13h interrupt

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.

rusakov_tdl4_pic09
Signature-based search for kdcom.dll

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.

Searching for values and replacing them in BCD
Searching for values and replacing them in BCD

The TDL-4 rootkit searches the BCD for the BcdLibraryBoolean_EmsEnabled key, which has the signature "16000020", and then replaces it with the "26000022"

Related Articles

Leave a Reply

Your email address will not be published. Required fields are marked *