TDL2

The TDL2 rootkit does not have its own process in the list of processes running on the computer. Its basic functions are provided by a driver that is automatically downloaded at system startup. Additional malicious functions are provided by standalone DLL modules stored in the Windows folder. The modules are loaded to the address space of the system processes svchost.exe and explorer.exe.

A distinctive feature of the rootkit is presence of the TDL2 identifier which can be found in the rootkit driver dump (Figure 1). The identifier is shown in the debugger while connected to the infected system.

Figure 1. The fragment of the dump in the TDL2 rootkit driver memory

The functions of the rootkit imply the following actions:

• hide the rootkit driver;
• hide the system registry keys responsible for autorun on system boot and rootkit configuration;
• inject the DLL modules listed in the configuration key into the processes from the kernel mode driver;
• provide the malicious program modules with an access to the kernel mode to stop the specified process or thread as well as to install a new DLL; module;
• сounteract anti-rootkits.

To accomplish its aims, the rootkit hooks the following functions using the splicing method:

• IofCallDriver
• IofCompleteRequest
• NTFlushInstuctionCache
• NtSaveKey
• NtSaveKeyEx
• NtEnumerateKey

The functions intercepted by the rootkit can be viewed in Figure 2 illustrating the Windbg debugger and the splicing method based on replacing a definite number of bytes in the original function handler by an agent code bringing to the rootkit body (Figure 3).

Figure 2. The intercepted functions in the Windbg debugger

Figure 3. Splicing in the IofCallDriver, IofCompleteRequest, NTFlushInstuctionCache, NtSaveKey, NtSaveKeyEx functions

The rootkit driver installs a system notifier using PsSetLoadImageNotifyRoutine that tracks loading the executable images into memory. The installed notifier allows the rootkit to stop the modules listed in the rootkit configuration registry key from starting.

In addition, the rootkit driver launches several kernel mode threads which provide a permanent process of driver re-registration and restores hooks installed by the rootkit.

The GMER anti-rootkit allows for successful diagnosis of theTDL2 rootkit infection (Figure 4).

Figure 4. Diagnosing the TDL2 rootkit infection by the GMER anti-rootkit

Apart from tricks to hide its presence in the system, the rootkit is notable for a special algorithm used to counteract anti-rootkit programs. This algorithm is revealed when analyzing the ioCallDriver function hook. The ioCallDriver function is used to send IRP requests to drivers. It has two arguments: pointer to IRP and object-device to which a request is sent. If any driver needs to address another driver device, this function is used (Figure 5).

Figure 5. The fragment of the call stack check algorithm

A fragment of the ioCallDriver hook is presented on Figure 5. The hooking code uses the stdcall convention with a stack frame whose pointer is stored in the ebp register as a result of prolog code execution in the beginning of the function:

push ebp

mov ebp,esp

On a definite stage, a handler code checks which device a request is directed at. If it is PDO of the main hard drive, then the code checks the request type. If it is IRP_MJ_INTERNAL_DEVICE_CONTROL, i.e. a low-level disk operation, a call stack check algorithm is applied. The algorithm analyzes return addresses and checks which drivers they belong to. If a call was received via system drivers specified in the rootkit white list, it is redirected further. If the call was received and initiated by a third party driver (for example, anti-rootkit utility or antivirus program driver), the request is interrupted. 

The algorithm works as follows: a value for the current frame is obtained from the ebp register. Kernel stack limits are then obtained for a thread using the RtlpGetStackLimits call. Then, stack frame property is used. The property allows finding a frame of the previous function. After dereferencing, a stack frame pointer of the current function points to a frame of the previous function, and in turn its stack frame pointer will point to a frame of the function it has been called from, and so on back through the chain of functions that have been called. It is possible to move by the frame pointer until it points to the function frame out of the stack memory area limits. With that, information about return addresses is collected. The rootkit code follows the procedure described above. The return address is stored in the stack frame. It is known that a return address is stored in a stack frame immediately after a pointer to a next function. A return address offset from the beginning of the frame is 4 on the 32-bit version of the Windows OS. The rootkit checks a return addresses to assure their values are within the following range DRIVER_OBJECT.DriverStart to (DRIVER_OBJECT.DriverStart + DRIVER_OBJECT.DriverSize), Figure 6.

Figure 6. The code that gets an address of the start and end points for loading a driver

The values are obtained from the driver kernel objects, included in the white list hard-coded into the rootkit, Figure 7.

Figure 7. The fragment of the code that creates an array of acceptable regions for return addresses

Thus, TDL2 applies a generic technology to counteract antivirus programs and anti-rootkit utilities. It causes antivirus programs and anti-rootkit utilities to crash when the latter try to use a lower level API  to avoid the rootkit hooks.

TDL2 developers continue to investigate and deploy new rootkit techniques when creating new versions of the rootkit. To guarantee loading a driver on the initial phase of the Windows startup, malware creators use the system driver infection methods for the TDL3 rootkit versions. For the TDL4 rootkit versions the Master Boot Record is infected. 

TDL infectors affect legitimate user applications. To counteract antivirus detections, TDL droppers use modern packing algorithms which are continually modified and contain mechanisms to detect when they are executed within virtual machines and sandbox environments.

In the next issue we will give an overview of QVOD worm family which extracts rootkit driver to hide start up registry keys.