What is in a Rootkit : The TDL3 Case Study Chapter 1 Part 1
In this chapter, we’ll introduce rootkits with TDL3. This Windows rootkit provides a good example of advanced control and data flow– hijacking techniques that leverage lower layers of the OS architecture. We’ll look at how TDL3 infects a system and how it subverts specific OS interfaces and mechanisms in order to survive and remain undetected. TDL3 uses an infection mechanism that directly loads its code into the Windows kernel, so it has been rendered ineffective by the kernel integrity measures Microsoft introduced on the 64-bit Windows systems. However, the techniques TDL3 uses for interposing code within the kernel are still valuable as an example of how the kernel’s execution can be hooked reliably and effectively once such integrity mechanisms have been bypassed.
As is the case with many rootkits, TDL3’s hooking of the kernel code paths relies on key patterns of the kernel’s own architecture. In a sense, a rootkit’s hooks may be a better guide to the kernel’s actual structure than the official documentation, and certainly they’re the best guide to understanding the undocumented system structures and algorithms. Indeed, TDL3 has been succeeded by TDL4, which shares much of the evasion and antiforensic functionality of TDL3 but has turned to bootkit techniques to circumvent the Windows Kernel-Mode Code Signing mechanism in 64-bit systems (we will describe these techniques in Chapter 7). Throughout this chapter, we’ll point out specific OS interfaces and mechanisms that TDL3 subverts. We’ll explain how TDL3 and similar rootkits are designed and how they work, and then in Part 2, we’ll discuss the methods and tools with which they can be discovered, observed, and analyzed.
Related Article:AutoLOG Keylogger download 2023
History of TDL3 Distribution in the Wild
First discovered in 2010,1 the TDL3 rootkit was one of the most sophisticated examples of malware developed up to that time. Its stealth mechanisms posed a challenge to the entire antivirus industry (as did its bootkit successor, TDL4, which became the first widespread bootkit for the x64 platform). N ote This family of malware is also known as TDSS, Olmarik, or Alureon. This profusion of names for the same family is not uncommon, since antivirus vendors tend to come up with different names in their reports. It’s also common for research teams to assign different names to different components of a common attack, especially during the early stages of analysis. TDL3 was distributed through a Pay-Per-Install (PPI) business model via the affiliates DogmaMillions and GangstaBucks (both of which have since been taken down).
The PPI scheme, popular among cybercrime groups, is similar to schemes commonly used for distributing browser toolbars. Toolbar distributors track their use by creating special builds with an embedded unique identifier (UID) for each package or bundle made available for download via different distribution channels. This allows the developer to calculate the number of installations (number of users) associated with a UID and therefore to determine the revenue generated by each distribution channel. Likewise, distributor information was embedded into the TDL3 rootkit executable, and special servers calculated the number of installations associated with—and charged to—a distributor.
The cybercrime groups’ associates received a unique login and password, which identified the number of installations per resource. Each affiliate also had a personal manager who could be consulted in the event of any technical problems. To reduce the risk of detection by antivirus software, the affiliates repacked the distributed malware frequently and used sophisticated
defensive techniques to detect the use of debuggers and virtual machines, confounding analysis by malware researchers.2 Partners were also forbidden to use resources like VirusTotal to check if their current versions could be detected by security software, and they were even threatened with fines for doing so. This was because samples submitted to VirusTotal were likely to attract the attention of, and thus analysis from, security research labs, effectively shortening the malware’s useful life. If the malware’s distributors were concerned about the product’s stealthiness, they were referred to malware developer–run services that were similar to VirusTotal but could guarantee that submitted samples would be kept out of the hands of security software vendors .
Also read:BitRAT HVNC RAT Cracked free download 2023
Infection Routine
Once a TDL3 infector has been downloaded onto a user’s system through one of its distribution channels, it begins the infection process. In order to survive a system reboot, TDL3 infects one of the boot-start drivers essential to loading the OS by injecting malicious code into that driver’s binary. These boot-start drivers are loaded with the kernel image at an early stage of the OS initialization process. As a result, when an infected machine is booted, the modified driver is loaded and the malicious code takes control of the startup process. So, when run in the kernel-mode address space, the infection routine searches through the list of boot-start drivers that support core operating system components and randomly picks one as an infection target. Each entry in the list is described by the undocumented KLDR_DATA_TABLE_ENTRY structure, shown in Listing 1-1, referenced by the DriverSection field in the DRIVER_OBJECT structure. Every loaded kernel-mode driver has a corresponding DRIVER_OBJECT structure.
typedef struct _KLDR_DATA_TABLE_ENTRY {
LIST_ENTRY InLoadOrderLinks;
LIST_ENTRY InMemoryOrderLinks;
LIST_ENTRY InInitializationOrderLinks;
PVOID ExceptionTable;
ULONG ExceptionTableSize;
PVOID GpValue;
PNON_PAGED_DEBUG_INFO NonPagedDebugInfo;
PVOID ImageBase;
PVOID EntryPoint;
ULONG SizeOfImage;
UNICODE_STRING FullImageName;
UNICODE_STRING BaseImageName;ULONG Flags;
Source code
USHORT LoadCount;
USHORT Reserved1;
PVOID SectionPointer;
ULONG CheckSum;
PVOID LoadedImports;
PVOID PatchInformation;
} KLDR_DATA_TABLE_ENTRY, *PKLDR_DATA_TABLE_ENTRY;
Once it chooses a target driver, the TDL3 infector modifies the driver’s image in the memory by overwriting the first few hundred bytes of its resource section, .rsrc, with a malicious loader. That loader is quite simple: it merely loads the rest of the malware code it needs from the hard drive at boot time. The overwritten original bytes of the .rsrc section—which are still needed for the driver to function correctly—are stored in a file named rsrc.dat within the hidden filesystem maintained by the malware. (Note that the infection doesn’t change the size of the driver file being infected.) Once it has made this modification, TDL3 changes the entry point field in the driver’s Portable Executable (PE) header so that it points to the malicious loader. Thus, the entry point address of a driver infected by TDL3 points to the resource section, which is not legitimate under normal conditions. Figure 1-1 shows the boot-start driver before and after infection, demonstrating how the driver image is infected, with the Header label referring to the PE header along with the section table.
This pattern of infecting the executables in the PE format—the primary binary format of Windows executables and dynamic link libraries (DLLs)—is typical of virus infectors, but not so common for rootkits. Both the PE header and the section table are indispensable to any PE file. The PE header contains crucial information about the location of the code and data, system metadata, stack size, and so on, while the section table contains information about the sections of the executable and their location.
To complete the infection process, the malware overwrites the .NET metadata directory entry of the PE header with the same values contained in the security data directory entry. This step was probably designed to thwart static analysis of the infected images, because it may induce an error during parsing of the PE header by common malware analysis tools. Indeed, attempts to load such images caused IDA Pro version 5.6 to crash—a bug that has since been corrected. According to Microsoft’s PE/COFF specification, the .NET metadata directory contains data used by the Common Language Runtime (CLR) to load and run .NET applications.
However, this directory entry is not relevant for kernel-mode boot drivers, since they are all native binaries and contain no system-managed code. For this reason, this directory entry isn’t checked by the OS loader, enabling an infected driver to load successfully even if its content is invalid. Note that this TDL3 infection technique is limited: it works only on 32-bit platforms because of Microsoft’s Kernel-Mode Code Signing Policy, which enforces mandatory code integrity checks on 64-bit systems. Since the driver’s content is changed while the system is being infected, its digital signature is no longer valid, thereby preventing the OS from loading the driver on 64-bit systems. The malware’s developers responded with TDL4.
