Aleksandr Matrosov and Eugene Rodionov have documented an interesting variation on techniques used for x64 bootkit infections. Over to you, gentlemen...

During the first half of 2011 we have witnessed a significant growth in malware targeting 64-bit platforms, the most interesting examples of which are bootkits. There are now several malware families in the wild:

  • Win64/Olmarik, an MBR (Master Boot Record) bootkit
  • Win64/Rovnix, a VBR (Volume Boot Record) bootkit
  • Win64/TrojanDownloader.Necurs
  • Win64/Spy.Banker

Of course, compared to the volume of families that target x86 platforms, those numbers don’t look much. But the percentage of new x64 families emerging in this year shows a significant increase. Looking at relative detection ratios for x64 platform families, there is an upward trend with a significant spike in the summer of 2010. This is connected with the emergence of a new version of Win64/Olmarik (TDL4) and its active distribution at that time.

They all use tricks to bypass the digital signature checks that can be divided into two groups. The first works entirely within user mode, and the second group targets the process of booting the operating system in order to manipulate kernel-mode memory:

Bypassing integrity checks techniques

We have already described in detail the techniques used to bypass MBR modification in our research report “The Evolution of TDL: Conquering x64”, so here we will focus more on the technique of VBR modification. Recently we encountered a malware sample – Win64/Rovnix – of which the dropper is detected as Win32/Papras. This malware employs quite an unusual technique to infect the system: instead of overwriting the MBR sector as bootkits usually do this malware infects the NTFS bootstrap code of the bootable hard drive’s active partition. (NTFS stands for New Technology File System, the file system that replaces FAT (File Allocation Table) for NT-derived Windows versions up to and including Windows 7.)

Bypassing kernel-mode code signing policy via VBR

Before speaking about the method of bypassing integrity checking, let’s first describe some of the basic notation we will use, and the basic concepts of loading the operating system (OS). At the very beginning of the boot process the BIOS code reads the first sector of the bootable hard drive, the so-called Master Boot Record, to which it transfers control. The MBR consists of the code and a partition table which describe the hard drive’s partitioning scheme. The main purpose of the MBR code is to locate an active partition on the disk and read its very first sector – the Volume Boot Record. The VBR contains file-system-specific boot code which is necessary to load the OS boot loader’s components. In fact, there are 15 consecutive sectors following the VBR and these contain bootstrap code for the NTFS partition. The bootstrap code parses the NTFS file system and locates OS boot loader components (for instance, BOOTMGR, the Windows Boot Manager, in the case of Windows Vista OS). The boot process is depicted in the following figure where we can see that Win64/Rovnix targets the bootstrap code.

The boot process in Windows Vista

Instead of overwriting the MBR, as often happens with bootkits, Win64/Rovnix infects the NTFS bootstrap code. It reads the 15 sectors following the VBR and containing bootstrap code. These sectors are compressed and appended to malicious bootstrap code which Win64/Rovnix extracts from its own resources. The resulting code is then written to the 15 sectors following the VBR as shown on the figure below. Thus, on the next system startup the malicious bootstrap code receives control.

Bootstrap code infection process

When the malicious bootstrap code is executed it hooks the int 13h handler in order to patch ntldr/bootmgr to gain control after the boot loader components are loaded. After that it decompresses and returns control to the original bootstrap code. In order to load its malicious unsigned driver into kernel-mode address space and bypass kernel-mode code signing policy, Win64/Rovnix employs a few rather unusual techniques. Firstly, in order to propagate itself through processor execution mode switching (from real mode into protected mode) it uses the IDT (Interrupt Descriptor Table). This is a special system structure which is used in protected mode and consists of interrupt handler descriptors. The malware copies itself over the second half of the IDT, which is not used by the system. Secondly, it hooks the int 1h protected mode handler and sets hardware breakpoints so as to be able to receive control at specific points of the OS kernel loading process.

Surviving processor mode switching

By means of using debugging registers dr0-dr7, which are an essential part of x86 and x64 architectures, the malware gets control at some point during the kernel initialization and manually loads its own malicious driver, thus bypassing the kernel-mode code integrity check.

The distinguishing feature of the method described above is its complexity and high system dependence. The malicious boot code works in close collaboration with the OS boot loader components. It follows the execution flow from the very beginning of the system booting process, carrying itself over during processor execution mode switching until the OS kernel is loaded. It relies heavily on platform debugging facilities and binary representation of the OS boot loader components.

Obviously developing this code is a rather expensive and time consuming process which involves skilled developers. Although this technique is highly system-specific and quite complex it works on 32-bit Windows OS versions as well as on 64-bit systems.

Aleksandr Matrosov, Eugene Rodionov, David Harley