In the past several years, we have seen an increase in bootkit usage. Variants of Alureon/TDL4, Popureb, Hasta La Vista, ZeroAccess, and many others began to appear more frequently in malware payloads. These rootkits abuse driver trust chains (i.e., layered drivers that rely on implicit contracts to operate correctly) by hooking the port and miniport drivers, which are at the bottom of the disk driver stack.
TDL4 modifies the miniport’s DRIVER_OBJECT.DriverStartIo and DEVICE_OBJECT.DriverObject pointers to point to its own hooking functions. After installing its hooks, TDL4 filters I/O requests in various ways to hide its rootkit file system, as well as return a clean Master Boot Record (MBR) when the first sector of the drive is requested. For more information, refer to the ESET whitepaper1 and related research.
Using either of the techniques described on this website, it’s possible to side-step this infection by reading the data from the drive through the crash I/O path instead of the normal I/O path.
The screenshot below is the MBR from a TDL4-infected system – this is the “clean” MBR the rootkit is returning, since the real MBR is modified to transfer control to the rootkit’s own loader just after POST on system boot-up. This MBR data was retrieved through a hex editor program, which like all applications, uses the normal I/O path to obtain data from the disk drive.
The screenshot below is the MBR of the same system but as retrieved from the crash I/O path. Notice the strings “Invalid partition table” and “Error loading operating system” are partially overwritten by the rootkit loader.
An excerpt from the IDA disassembly of the bootkit loader in this dump is shown below. This excerpt contains the decryption routine, as the loader is stored XOR’d.