# Bootkit's development overview and trend AVAR2012 / by nEINEI && Jason Zhou **Keywords: bootkit, MBR, DBR, VBR, NTFS, Windows Kernel** **Abstract** Windows bootkit’s development speed is rapid. It has developed from initial POC (Proof-of-Concept) stage to current having several stable virus families. Bootkit’s infection measures also extended to BIOS chips, disk MBR, VBR and etc. All these have brought challenges for the security of system boot and kernel entrance. So how to find advantages in the confrontation with bootkit is the problem we have to face in the future. **Introduction** In 2005, the company, eEye Digital, first brought in the idea of bootkit, which stands for boot rootkit, in their project, ‘BootRoot’ [1]. Generally speaking, one rootkit which is loaded earlier than Windows kernel could be considered as a bootkit. So in this paper, all the mentioned Bootkit viruses use this definition. After Phanta, also known as _GhostShadow, first generation bootkit appeared in China in_ March 2010, Chinese bootkits entered a period of development. So far we already found 5 kinds of relative Phanta variations. Their infection measures, code obfuscation tricks and self-protection approaches have big improvements. As with the development of global bootkit viruses, such as TDSS and Rovnix bootkit families, the trend of bootkit learning from each other becomes more obvious. So in this paper, we will first review the development status of bootkits all over the word from 2010. Then we will have a targeted introduction of Chinese bootkits. **1. Technical overview of bootkits for last three year** **1.1 Bootkits in 2010** **1.1.1 Phanta 1 As we mentioned above, Phanta 1 should be considered as the first bootkit virus** in China. After system is infected by Phanta 1, the malicious MBR copies virus data to the end of real-mode memory and hooks int 13h interruption. Then copies the original MBR code to the address 0x7c00 then passes the control to it. When the boot code reads the file _ntldr by invoking int 13h interruption, Phanta 1 gets the_ control. It searches for the signature, 0x74f685f0 and 0x3d80, in the function _BILoadBootDrivers of_ _ntldr. If the signature is found, Phanta 1 hooks the next line of code_ below the signature. ----- Fig.1 Phanta 1 hooks ntldr When function off_97400 is called, Phanta 1 gets the image base of ntoskrnl and parses its PE structure to find the section with the parameter 0x20000000. After the section is found, Phanta 1 copies its 4 sectors’ virus codes to that area. Then Phanta 1 parses the Export Table to address the function PsCreateSystemProcess to hook the function PspCreateProcess. Fig.2 hook PsCreateProcess After a new process is being created, Phanta 1 gets the control again. It checks the PID of created process. If the PID equals 4, meaning the process is system.exe, Phanta 1 then loads its virus driver. On the whole, Phanta 1 is an imitation of Mebroot, specifically in the malicious MBR code, the way to patch ntldr and load virus driver. For example, Phanta 1 uses the same signature as _Mebroot to search for the address to patch ntldr. (0x74f68f50 and 0x3d80 are the signatures)_ ----- Fig.3 Mebroot’s MBR code Fig. 4 Phanta 1’s MBR code In code layout aspect, Phanta 1 also imitates Mebroot’s structure. ----- Fig. 5 contrast between the code layouts of Mebroot and Phanta 1. Like Mebroot, Phanta 1 only infects 32-bit Windows XP. **1.1.2 TDL-4 Also known as Alureon and Olmarik, TDL-4 is the 4[th] generation of TDSS bootkit** family. Compared with earlier versions, TDL-4 has big improvements and indeed brings an evolution in bootkit development process. TDL-4 firstly came into our eyes in August, 2010. Then it has been consistently in the wild until the end of year 2011. But the main functions keep almost the same except the payload. As with previous versions, TDL-4 makes use of a configuration file, _cfg.ini, to handle the_ communications between user mode and kernel mode. Below is the cfg.ini we found at the very beginning when TDL-4 was found. Fig. 6 TDL-4 Found in August 2010 TDL-4 takes advantage of a lot of first seen techniques. It’s the first rootkit virus compatible with all versions of Windows, including 64-bit Windows 7. Below is the TDL-4’s boot process. ----- Fig. 7 TDL-4 boot process In order to bypass _PatchGuard in 64-bit systems and avoid being debugged, TDL-4’s_ real-mode loader module, ldr16, hijacks kdcom.dll with ldr32 or ldr64, depending on Windows platform. After ldr32/64 is loaded and the exported function, KdDebuggerInitialize1, is called, an image notification routine is set by calling _PsSetLoadImageNotifyRoutine. In this routine,_ TDL-4 uses an undocumented function, IoCreateDriver, to create a driver object. In this driver object’s _DriverEntry function, a PnP notification routine is registered by calling_ _IoRegisterPlugPlayNotification. When this PnP notification routine is invoked, TDL-4 searches_ its own file system for its main rootkit driver module, drv32/64 and then load them. Fig. 8 set an image notification routine Fig. 9 a driver object is created in the routine TDL-4’s self-protection approaches are complicated, including adding system callbacks, ----- hijacking Dr0, hooking DriverStartIo routine of Atapi driver, using kernel work item thread to protect hooked functions. This makes it difficult to clean TDL-4 completely. **1.2 Bootkits in 2011** 2011 is the year of concentrated outbreak of bootkits. There are several important bootkit families coming out, including ZeroAccess, Phanta and TDSS. **1.2.1 Phanta 2 Phanta 2 first appeared in March 2011. Compared with Phanta 1, Phanta 2 has** below major changes: 1. Malicious MBR code is obfuscated so that it becomes more difficult to analyze statically. 2. Virus data written to disk’s first 6 sectors is encrypted. 3. Directly overwrite %systemroot%system32/drivers/fips.sys instead of hooking _PspCreateProcess to load virus driver._ **1.2.2 Phanta 3 Phanta 3 appeared in May, 2011. Compared with Phanta 2, Phanta 3 pays** attention to protect the malicious MBR. It learns from TDL-4’s framework. But it implements these functions in a simplified way. 1. Phanta 3 encrypts and stores original MBR and the code of patching ntldr at the end of disk. It stores nothing in the first 64 sectors of the disk any more. 2. It hooks _DriverStartIo dispatch function of the driver Atapi or SCSI to protect_ malicious MBR instead of hooking reading and writing dispatch function of _disk.sys which_ _Mebroot used._ 3. It replaces beep.sys with malicious driver, hello_tt.sys. Fig. 10 replace beep.sys **1.2.3 TDL-4 version 0.31. We captured TDL-4’s upgraded variations in August 2011. Its main** module’s version is 0.03. And the payload’s version is 0.31. Still, compared with earlier variations, nothing big changed except payload. ----- Fig. 11 TDL-4 variation found in May 2011 Fig. 12 TDL-4 variation found in September 2011 Fig. 13 image notification routine is changed into thread notification routine. **1.2.4 ZeroAccess ZeroAccess, also known as Max++, firstly came into our eyes in August 2011.** Till now while this paper is being written, we could still hear ZeroAccess’s traces in the wild. ZeroAccess is different from other bootkits mentioned in this paper because it doesn’t ----- modify system’s bootstrap code. ZeroAccess’s dropper chooses a random driver between _classpnp.sys and win32k.sys to infect in overwriting way. Then use_ _ZwLoadDriver to load the_ driver. This driver is obfuscated and packed. This is quite rare among the virus drivers we’ve ever seen as packing in kernel mode might cause unpredictable issues. The original virus driver is stored in the packed driver’s body. After decompressed into the memory, we could see the original driver’s file image. Fig. 14 decompress original driver’s body After maping the file image into memory, the packed driver will search the PE structure to find the entry point of the original driver. ----- Fig. 15 memory relocation Fig.16 get the entry point After entering the original virus driver’s code space, ZeroAccess creates a device object to store its virus components and communicate with user mode. Fig.17 create the device object (22h stands for FILE_DEVICE_UNKNOWN) Then it creates an IRP hooking driver to hijack disk.sys. Fig. 18 create IRP hooking driver ----- Fig.19 hook disk.sys Besides these, ZeroAccess also creates other system threads, APC calls and timers. All these together make it difficult to remove ZeroAccess completely. **1.2.5 TDL-MaxSS TDL-MaxSS came out in November 2011. It’s considered as the upgraded** version of TDL-4. Compared with TDL-4, MaxSS improves the way to infect MBR. It no longer overwrites original MBR directly. Instead, it modifies DPT (Disk Partition Table) and points it to virus code. In other words, MaxSS forges a new boot partition. Fig. 20 contrast between normal DPT and MaxSS infected DPT This is a creation in bootkit development process. As a result, security tools could not only use simple signature matching to check for MBR infection. **1.2.6 Phanta 4 Phanta 4 is also known as Bioskit or Win32/Wapomi.e. Before 2011, Bioskit yet** remained in the conceptual stage. Although some researchers provided ways to attack BIOS in Blackhat 07 [2] and CanSecWest 09 [3], there are difficulties in actual operation. In September 2011, a bioskit virus which targeted Award BIOS appeared in China. That’s Phanta 4. ----- For Award BIOS computers, Phanta 4 infects BIOS by inserting a malicious ISA module. For non-Award BIOS ones, Phanta 4 modifies MBR in common bootkit way. First, Phanta 4 makes use of cbrom.exe to insert the malicious ISA module, hook.rom, into Award BIOS. Fig. 21 use cbrom.exe to insert hook.rom Second, Phanta 4 replaces beep.sys with its virus driver to check BIOS type, backup original BIOS and flash BIOS. Fig. 22 virus driver’s device control dispatch routine When the compromised system restarts, malicious hook.rom runs before MBR. It first checks ----- whether MBR is infected. Fig. 23 check MBR infection If the MBR is not infected, hook.rom infects it. The malicious MBR code loads DBR (DOS Boot Record) to the address 0x7c00 and checks the file system format of disk’s boot partition. Then parse the boot partition to search for _winlogon.exe or_ _wininit.exe. Afterwards, patch_ _winlogon.exe/wininit.exe and print ‘Find it OK!’_ ----- Fig. 24 print ‘Find it ok!’ **1.3 Bootkits in 2012** **1.3.1 Rovnix.** Earlier Rovnix variations looked like a fully upgraded version of TDL-4. Its inside modules are designed separately to infect 32-bit and 64-bit Windows. Rovnix infectes VBR(Volume Boot Record). In malicious VBR code, Rovnix hooks int 13h interruption function to patch ntldr or bootmgr. After patching, it injects malicious codes into _ntoskrnl.exe’s memory to load virus driver._ ----- Fig. 25 patch ntldr/bootmgr Rovnix’s boot loader is highly obfuscated. Its code is divided into many small blocks. Each snippet is connected with others with _jmp or a meaningless_ _call function. And Rovnix’s each_ variation’s boot loader is different from others. This makes it difficult to analyze and detect. Fig. 26 Rovnix’s boot loader code snippet ----- Fig. 27 Rovnix’s boot loader real working flow **1.3.2 Plite** Plite is a special bootkit family. After infecting MBR, Plite parses FAT/NTFS file system to locate and overwrite _explorer.exe. This is nothing new as Phanta 4 behaves in the_ same way. Why Plite is special is because its modules are developed in several different languages. Its dropper is written in C#. The dropped file is developed in Delphi. And the boot loader module is compiled with Microsoft FORTRAN compiler. We could see some debugging information in boot loader. Fig. 28 boot loader code snippet ----- Fig. 29 boot loader compilation information **1.3.3 Phanta 5 (Phanta’s latest version, also known as** _Win32/Wapomi.f) In July 2012,_ several new variations of Phanta family quickly came out in China. Phanta 5 encrypts and stores its malicious modules in its resource section. Below we could see the differences between two variations we captured in July 2012. Fig. 30 Phanta 5 module differences Compared with earlier versions, Phanta 5 has below major improvements: 1. Dropper injects explorer.exe process to drop a random driver file, x_random.sys. Then hijacks below services to load virus driver. Fig. 31 hijacked service list 2. Driver x_random.sys hooks _DriverStartIO dispatch routine of Atapi/SCSI driver to_ protect MBR. ----- 3. MBR loads another driver to hook reading and writing dispatch routines of disk.sys in order to protect MBR doubly. 4. X_random.sys hooks SSDT functions to stop AV services. Fig. 31 kill AV services 5. Phanta 5 stores original MBR, boot loader, fake sfc_os.dll and x_random.sys at the end of disk partition, without encryption. Below is Phanta 5’s boot process. Fig. 32 Phanta 5 boot process ----- **2. Bootkit in China** Chinese bootkit has developed for some time. Early in May 2007, the Chinese developer, _icelord, released a tool, named ICLord Bioskit [4], which could infect Award main board. In_ November 2008, the developer, _inghu, published a bootkit idea to patch_ _ntldr. The Chinese_ researcher, mj0011, published bootkit tophet[5] in Xcon2008. But all these are only technology researches. Bootkit viruses didn’t spread widely until March 2010. And afterwards, Chinese bootkit entered a period of development. So below sections will describe the characteristics of bootkit viruses in China. **2.1 Anti-static-detection for MBR** In order to prevent detecting malicious MBR, bootkit viruses are always looking for new methods. Phanta 1 has tiny improvements. It no longer operates BIOS’s data at address 0x413 directly. Instead, it substitutes the equivalent instructions to achieve the same goal. Fig. 33 0x413 substitution Phanta 2 and Phanta 3 insert junk codes to interfere analysis. Also their malicious MBR and virus data are encrypted. Fig. 32 junk code in Phanta 2/3 MBR Phanta 5 doesn’t hook int 13h interruption as other bootkits do. Instead, it repeatedly calls a function cs:dword_2580. ----- Fig. 33 Phanta 5 calls cs:dword_2580 repeatedly But the beginning of the function cs:dword_2580 is incorrect. Fig. 34 begginging of cs:dword_2580 The truth is while running, Phanta 5 overwrites the first 8 bytes of _cs:dword_2580 with_ 0xe3fe and 0xf000 which stand for int 13h interruption function’s original address in BIOS. Fig. 35 cs:dword_2580 while running **2.2 Virus data storage Both Phanta 1 and Phanta 2 store their virus data in the first 63 sectors** of disk. The only difference is that Phanta 2 encrypts the data before writing. Phanta 3 stores its virus data at the end of disk with encryption. Phanta 5 also puts its virus modules at end of disk but without encryption. ----- We could see that Chinese bootkit virus authors’ data protection consciousness is not that strong. They prefer to protect their ‘babies’ by driver rather than designing custom file system as TDL-4 does. **2.3 Self-protection** Phanta 1 installs several filter callback functions by calling _PsLoadImageNotifyRoutine,_ _PsCreateProcessNotifyRoutine and_ _PsCreateThreadNotifyRoutine._ Then enumerate processes to kill AV. Phanta 2 also kills AV. It hooks PsLoadImageNotifyRoutine. When a kernel module is being loaded, Phanta 2 checks the module’s digital signature whether the module is an AV module. If yes, Phanta 2 patches the module’s entry point and make it return failure. Phanta 3 protects MBR by hooking DriverStartIo dispatch routine of Atapi/SCSI driver. Fig. 36 Phanta 3 hooks DriverStartIo Phanta 4 uses malicious BIOS rom to protect MBR. Phanta 5 prevents AV driver from loading. (Fig. 31) And it protects MBR doubly. Fig. 37 double protection for MBR ----- **2.4 Interesting findings From above aspects, we can see that Chinese bootkits virus authors are** making efforts to do better. They learnt from other bootkits and improved their own. During analysis for Phanta 4, we found that Phanta 4 drew ICLord’s way to infect BIOS. Fig. 38 contrast between ICLord and Phanta 4. One thing similar happened in Phanta 5. We found earlier Phanta 5’s code to parse FAT/NTFS file system is very similar to Stoned Bootkit’s open source.[6] Fig. 39 contrast between Phanta 5 and Stoned Bootkit But soon, we found newer Phanta 5 removed this code block. Instead, it uses another way to parse file system. We’re not sure whether it’s original. But it’s better indeed. ----- Fig. 40 new code snippet to parse file system in Phanta 5 **3 Windows bootkit attack trend forecast** In recent years, bootkit had continuous improvements on means of attack. The improvements specifically embody in below aspects: **3.1 Hardware level infection** Starting from eEye’s BootRoot project, BIOS infection is not generated as a concept. Afterwards, more researches were stimulated in this direction. _Peter_ _Kleissner demonstrated using bootkit to bypass Windows 8’s UAC in MalCon Assembly in_ November 2011. Although the targeted Windows 8 system is booted based on BIOS, this indicates that traditional bootkit threat won’t die before we enter the UEFI era. On the other hand, researchers and hackers have never stopped the discussion on UEFI security. In 2012, we saw several technological breakthroughs, such as Loukas’s EFI Rootkit for Mac in Black Hat USA 2012, Jonathan Brossard’s UEFI rootkit, Rakshasa. These provide the basis of underlying technology for the development of bootkit. When the time comes, they will be transformed into the reality of attacks. **3.2 Obfuscation in 16-bit boot loader** In order to escape static detection, bootkits began to obfuscate their boot loaders, such as encryption, inserting junk code, etc. Rovnix.b’s boot loader is polymorphic. ----- Fig. 41 Rovnix.b’s boot loader code Take a look at function _run_obs_code. You could see the inside_ _push and_ _pop instructions_ don’t match. The number of push is one more than pop. So when ret is executed, the flow will not go to the next instruction after run_obs_code. We got troubles while debugging before we were aware of this traps. Phanta 5 seems to draw this experience. Although Phanta 5’s boot loader code is not polymorphic, the confusing jmp instructions indeed make analysis more difficult. **3.3 Protection of virus data In order to strengthen protection of virus data, TDL-4 designed its** own file system. Except malicious MBR, all the other modules of TDL-4 are stored in its custom file system. Fig. 42 TDL-4’s file system After wards, we could see the similar way is widely used in newly coming bootkit viruses. Bootkit could make this even more complicated, because this only depends on the strength of encryption algorithm and the complexity of the file structure. Theoretically, any kernel module could be put into this file system. It’s up to bootkit to decide when and which to load. If so, this ----- will be the worst thing. **4 Problems of prevention and detection** The biggest difference between bootkit virus and other types of virus is that bootkit virus obtains control earlier than Windows. Thus, it could make any change to the system at the same time hiding itself. Once a bootkit is installed successfully, the subsequent cleanup work will be very complicated. The prevention of bootkit includes protecting disk’s reading and writing, monitoring driver loading. Most AVs already paid attention to these aspects. But bootkit authors are keeping digging the weakness and missing corners of security tools. This also becomes one of the defense problems. **4.1 Dangerous API Current HIPS systems are based on the trust mechanism of process chain,** meaning that if a process is to be trusted, any operation of this process is trusted, including creating a new child process. TDL-4 uses AddPrintProvidor to load its virus driver because the printer process spoolsv.exe is trusted. Also in Phanta 5, we saw the use of ‘vulnerability’ of functions LoadKeyboardLayoutA and _ZwQueryValueKey._ When we call _PostMessage_ to post a WM_INPUTLANGCHANGEREQUEST message to _explorer’s window,_ _explorer will load a_ new keyboard layout. Phanta 5 hooks ZwQueryValueKey to modify the IME file which explorer is to load. Thus, explorer loads a virus module. As _explorer.exe is a trusted process, Phanta 5_ could do anything in explorer’s memory, including loading virus driver. These three functions have one thing in common. Although they’re only called in their own processes, they affect the whole system. We name them ‘dangerous API’. Finding the vulnerabilities of dangerous APIs is the easiest way to bypass HIPS. **4.2 Alternative penetration of disk Protection of disk’s boot section has already attracted the** attention of many security tools. HIPS tools also monitor disk’s reading and writing operations by checking the access to path \\.\PhysicalDrive0 or \DEVICE\HARDDISK\DR0. But recently we found a new way to bypass such protection. First you send a SCSI_PASS_THROUGH instruction to the disk, which is a standard SCSI instruction. When current physical disk’s corresponding bus device symbol link is found, you need to fill in the SCSI_PASS_THROUGH structure and send a _DeviceIoControl code, 0x4D014, which stands_ for METHOD_BUFFERED, to disk driver. Then you could bypass above disk protection approaches and modify the disk. ----- Fig. 43 bypass disk protection During our tests, most HIPS tools could not prevent such attack. **4.3 Once again-What’s bootkit? Above we described several complicated bootkit families. We** mentioned their development and their differences. We also predict their development trend. Now we want to raise the question again. How to define a bootkit’s technical characteristic? We believe that a bootkit overall consists of three stages. Fig. 44 Bootkit composition _Boot stage’s purpose is to obtain control before system startups. It might lie in UEFI, BIOS,_ MBR, VBR, Bootstrap code, ntldr, bootmgr, and etc. _Patch kernel code stage is mainly to bypass system protection and load virus driver._ Searching where to patch is just like looking for _Zero Day vulnerabilities in system kernel._ Although we saw several different kinds of bootkit family, their boot process have many similarities. Bootkit authors do not want to spend their time on digging where to patch, as long as one stable patching way is enough. _Load driver stage is easy to understand. Once the kernel is patched, bootkit could load its_ virus driver in kernel. Thus virus driver is loaded earlier than other drivers. ----- **Summary** We believe bootkit threat will still continue to persist and evolve. Meanwhile, as the cost of developing a stable bootkit virus family is much higher than other types of virus, we guess there won’t be many new bootkit families coming out. And we believe Secure Boot or UEFI would relieve bootkit attack. Currently, our terminal defense system has inherent weakness. Client’s AV products could not protect both software and hardware. Even the cleanup work for bootkit could not be put into AV’s engine. So we advise to back up the core data in system boot phase plus defense in application layer. **References** [1] Derek Soeder, Ryan Permeh: eEye BootRoot on [http://www.blackhat.com/presentations/bh-usa-05/bh-us-05-soeder.pdf (Blackhat 2005)](http://www.blackhat.com/presentations/bh-usa-05/bh-us-05-soeder.pdf) [2] John Heasman: Hacking firmware on [https://www.blackhat.com/presentations/bh-usa-07/Heasman/Presentation/bh-usa-07-hea](https://www.blackhat.com/presentations/bh-usa-07/Heasman/Presentation/bh-usa-07-heasman.pdf) [sman.pdf](https://www.blackhat.com/presentations/bh-usa-07/Heasman/Presentation/bh-usa-07-heasman.pdf) (Blackhat 2007) [3] Anibal L. Sacco, Alfredo A. Ortega: Persistent BIOS Infection on [http://www.coresecurity.com/files/attachments/Persistent_BIOS_Infection_CanSecWest](http://www.coresecurity.com/files/attachments/Persistent_BIOS_Infection_CanSecWest09.pdf) 09.pdf (CanSecWest09) [4] IceLord, BIOS RootKit: Welcome Home, My Lord! On [http://www.xfocus.net/articles/200705/918.html](http://www.xfocus.net/articles/200705/918.html) (Xfocus 2007) [5] [MJ0011: Advanced Bootkit-Tophet on http://xcon.xfocus.org/XCon2008/index.html](http://xcon.xfocus.org/XCon2008/index.html) (XCon 2008) [6] Peter Kleissner: Stoned Bootkit on [http://www.blackhat.com/presentations/bh-usa-09/KLEISSNER/BHUSA09-Kleissner-St](http://www.blackhat.com/presentations/bh-usa-09/KLEISSNER/BHUSA09-Kleissner-StonedBootkit-PAPER.pdf) [onedBootkit-PAPER.pdf (Blackhat 2009)](http://www.blackhat.com/presentations/bh-usa-09/KLEISSNER/BHUSA09-Kleissner-StonedBootkit-PAPER.pdf) -----