C HINA C OMMUNICATIONS

A Survey on the Evolution of Bootkits Attack and Defense

Techniques

Yilin Zhou1,2 , Guojun Peng1,2,* , Zichuan Li1,2 , Side Liu1,2

1
Key Laboratory of Aerospace Information Security and Trust Computing, Ministry of Education, Wuhan 430072, China
2
School of Cyber Science and Engineering, Wuhan University, Wuhan 430072, China
*
The corresponding author, email: guojpeng@whu.edu.cn

Abstract: According to the boot process of mod- bootloader [1–3]. But bootkit is not new technology.
ern computer systems, whoever boots first will gain On the contrary, they appeared very early. Moreover,
control first. Taking advantage of this feature, a ma- their techniques have also been evolving with the evo-
licious code called bootkit can hijack the control be- lution of the modes computers boot and corresponding
fore the OS bootloader and bypass security mecha- security mechanisms. Before discussing bootkits tech-
nisms in boot process. That makes bootkits difficult niques in detail, we first introduce similar but better-
to detect or clean up thoroughly. With the improve- known malicious code called ”rootkit.” Their names
ment of security mechanisms and the emergence of are similar, and their techniques also have something
UEFI, the attack and defense techniques for bootkits in common. Rootkits have plagued many computer
have constantly been evolving. We first introduce two systems and IoT devices for many years. A rootkit is
boot modes of modern computer systems and present a kind of malicious code designed to provide an at-
an attack model of bootkits by some sophistical sam- tacker with privileged access to a device without vic-
ples. Then we discuss some classic attack techniques tim awareness [4–6]. The original design intention
used by bootkits from their initial appearance to the of rootkits and bootkits is basically the same. They
present on two axes, including boot mode axis and at- were all designed to allow the attacker to stay in the
tack phase axis. Next, we evaluate the race to the bot- victim system concealed to remain in control of the
tom of the system and the evolution process between victim system for a long time. TDL3 is a typical
bootkits and security mechanisms. At last, we present rootkit distributed through a PPI (i.e., Pay-Per-Install)
the possible future direction for bootkits in the context business model via the affiliates Dogma Millions and
of continuous improvement of OS and firmware secu- GangstaBucks [7]. It has a hook module as an infec-
rity mechanisms. tor and an independently developed hidden file system.
Keywords: bootkit; hook; security mechanisms; The way it achieves long-term persistence is to se-
legacy BIOS; UEFI lect a boot-start driver randomly, inject malicious code
into its resource section and modify the undocumented
I. INTRODUCTION structure KLDR DATA TABLE ENTRY in the Dri-
verSection field. The EntryPoint field then points to
Recently, some novel bootkits have caught the atten- the code of the injected resource section. Every time
tion of security researchers by showing huge attack the OS (i.e., Operating System) boots, all boot-start
surfaces of ESP (i.e., EFI system partition) and EFI drivers will be loaded into the kernel space, and the
malicious code of TDL3 will be executed. Therefore,
Received: Oct. 26, 2022 TDL3 has achieved the goal of automatically execut-
Revised: Jan. 30, 2023 ing every time the system boots.
Editor: Xinbing Wang

China Communications 1
 This situation changed after Microsoft Windows such as Secure Boot and Boot Guard to ensure that
released the kernel-mode code signing policy [8]. the firmware would not be tampered with by attackers.
Kernel-Mode Code Signing Policy verifies the driver’s Bootkits have also begun to utilize SMM vulnerabil-
signature in kernel mode and prevents drivers with- ities [14, 18, 19], S3 scripts vulnerabilities [20–23],
out legal signatures from being loaded into the kernel. BMC vulnerabilities [24], Intel AMT vulnerabilities
Therefore, the self-starting rootkits similar to TDL3 [25, 26] and Intel ME vulnerabilities [27–30] to attack
could not work in the version after Windows XP by UEFI firmware so as to achieve the initial mission of
simply and directly modifying the boot-start drivers. permanent residence and maintain the control.
The first modern bootkit was considered BootRoot This work mainly focuses on the evolution of
[9]. This concept was first mentioned by eEye Digital bootkit’s attack techniques and corresponding security
in their ”BootRoot” project in 2005. The most sig- mechanisms. However, we will mainly focus on the
nificant difference between bootkits and rootkits lies attack techniques of bootkits, supplemented by the se-
in how they realize automatic startup. Rootkits’ self- curity mechanisms for the related attacks. As illus-
starting techniques do not destroy the integrity of the trated in Figure 1, we summarize 12 classic bootkits
control flow of OS booting. Bootkits usually execute attack techniques (i.e., A1 -A12 ) and six representative
before the OS and then disable the verification of the defense techniques (i.e., D1 -D6 ), which are the most
driver signature by patching the OS bootloader. This discussed in various security conferences and papers,
method disrupts the system boot sequence and mod- and also the most characteristic of bootkit attacks. For
ifies the OS component simultaneously. So bootkits every attack technique, we annotate a few typical in-
can break through the restriction that the kernel-mode stances. They are not comprehensive, and some bootk-
code signing policy puts on rootkits. its involve multiple attack techniques at the same time,
With the emergence of UEFI (i.e., Unified Exten- but each of them is representative of its category. We
sible Firmware Interface) [10], bootkits attack tech- divide all the above techniques into four parts by our
niques have also changed. In 2018, ESET released proposed two axes. On attack phase axis, we divide
an analysis report on LoJax [11], which made more techniques into infection phase and boot phase. Tech-
security researchers pay attention to the bootkits tech- niques in infection phase focus on how to attack or
niques in UEFI boot mode. In fact, open-source UEFI protect the storage media bootkits need to implant,
bootkits such as DreamBoot [12], ThunderStrike [13], while techniques in boot phase focus on how to pro-
SMMbackdoor [14], etc., have appeared for research mote or prevent bootkits from hijacking the control
purposes since 2013. These open-source bootkits did earlier than the OS bootloader or bypassing the in-
not attract widespread attention at the time. How- tegrity check. The closer it is to the arrow, the later
ever, on the other hand, it has promoted the devel- the attack or defense technique works during the boot
opment of malicious bootkit techniques in the wild process. If an attack technique is below a defense tech-
[15]. Many malicious bootkits captured in the wild nique in Figure 1, it often means the attack technique
have been analyzed and confirmed to be based on the can bypass or undermine the defense technique, and
open-source bootkit and improved after partial module vice versa (e.g., D6 can protect RoT from A7 , but may
reuse [16, 3]. Compared with legacy BIOS, UEFI did be undermined by A9 ). On boot mode axis, we di-
not leave bootstrap code like MBR, VBR (i.e., Volume vide techniques into legacy BIOS and UEFI. The boot
Boot Record), or IPL (i.e., Initial Program Loader) on mode axis is sort of like a timeline, but not quite. It
the disk but stored the UEFI firmware code responsi- divides techniques into legacy BIOS and UEFI. Some
ble for booting and initializing the platform hardware techniques (e.g., A8 , D2 and D3 ) works in both boot
in the SPI (i.e., Serial Peripheral Interface) flash mem- modes, so we put them across the axis in Figure 1.
ory [17]. Modifying the firmware was far more diffi- As can be seen from the distribution of attack and
cult than modifying the disk. Cleaning the bootkits in defense techniques in Figure 1, techniques in legacy
the firmware was also far more challenging. So bootk- BIOS are mainly distributed in boot phase. In con-
its needed to develop a new technique to counter the trast, techniques in UEFI are mainly distributed in in-
OEM/ODM manufacturers’ security mechanism for fection phase. This is primarily because legacy BIOS
firmware. Intel has introduced security mechanisms relies a lot on the OS boot security mechanisms against

2 China Communications
 Attack phase axis

Boot phase
Rovnix
Obfuscation and anti-dynamic- Festi
analysis technologies (A4) TDL3

Replace the S3 Darth Venamis

Early Launch Anti- Microsoft Kernel-mode boot script (A12) Thunderstrike 2

Malware (D1) Code Signing Policy (D2)

Virtual Secure Mode (D3)

IceLord
Hook BIOS interrupt Mebromi
handlers (A3) Rakshasa

TDL4 SmmBackdoor
Tamper with Manipulate SMM
Gapz Memory Sinkhole
bootstrap code (A2) Olmasco
modules (A11) ThinkPwn

Boot mode axis

Legacy BIOS Stoned x64 UEFI
Break through physical FinSpy
Vbootkit2 Tamper with ESP (A5)
disk protections (A1) Mebroot
ESPecter

UEFI Firmware Protections (D4)

LightEater
Break through UEFI Lojax
firmware protections (A6) MosaicRegressor

UEFI Secure Boot (D5)

PoC by Bulygin et al.

Compromise Secure Boot (A7)
Kon-Boot

Intel Boot Guard (D6)

MoonBounce
Pollute the supply chain (A8) Netfilter
Undermine Intel Boot Guard (A9) Safeguarding
Infection phase

Utilize Intel Management AMT case by PLATINUM

Engine (A10)

Figure 1. Bootkit attack techniques classified by two axes. The red box represents the attack techniques used by bootkits,
and the blue box represents the defense techniques associated with bootkit.

bootkits, while UEFI does a lot of work to verify the tion III is organized along the attack phase axis. We
integrity of the firmware storage media. Each of these present an attack model of a bootkit and its vital func-
attack or defense techniques will be described in detail tional modules in infection phase and boot phase. It
in the following sections. is based on our summary and generalization of several
typical bootkits analysis reports. Section IV mainly
The rest of this paper is organized as follows. Sec-
focuses on bootkits in legacy BIOS boot mode, and
tion II is organized along the boot mode axis. It
Section V focuses on bootkits in UEFI boot mode. In
presents two mainstream boot modes of the computer
each section, we introduce the attack techniques of
system named legacy BIOS and UEFI, as well as the
bootkits from the perspective of infection phase and
points where bootkits attacks often occur. We believe
boot phase, as well as a summary of corresponding se-
it will be more helpful to understand the malicious be-
curity mechanisms. For bootkits in legacy BIOS, we
havior of bootkits in two different boot modes. Sec-

China Communications 3
introduce four approaches they used to hijack the con- the authors of bootkits will make legalized use of
trol before OS booting, the hook method they utilized their techniques to produce legalized commercial
to transfer the control, and OS vendors’ countermea- software (e.g., Computrace [35], and Kon-Boot
sures against these attacks. For bootkits in UEFI, we [36]) and sell them publicly.
introduce the process that they used various state-of-
the-art attack methods to tamper with RoT (i.e., Root II. TWO MAINSTREAM BOOT MODES OF
of Trust) and executed malicious code under the strict COMPUTER SYSTEM
firmware security mechanisms by utilizing vulnerabil-
ities in multiple components in firmware, as well as The boot mode of the computer system is critical for
the process that firmware manufacturers moved RoT bootkits, and the first axis we propose to characterize
from the DXE stage to the hardware [31–33] in order bootkits is boot mode. Both bootkit developers and se-
to mitigate such security issues. In Section VI, we dis- curity mechanisms developers hope to gain control at
cuss the process of co-evolution between the bootkit an earlier stage of the boot process. Nowadays, there
attack techniques and the security mechanisms. We are two mainstream boot modes (i.e., legacy BIOS
also analyze the possible attack surface and direction and UEFI). Legacy BIOS was born in the CP/M com-
of development for bootkits in the future firmware sys- puter in 1975 [16]. Nevertheless, it was an advanced
tem dominated by UEFI. Finally, we make our conclu- technique and an indispensable part of the system at
sion in Section VII. that time. With the development of computer soft-
In general, our main contributions can be summa- ware and hardware, the defects of legacy BIOS have
rized as follows: also been exposed. Problems such as low efficiency,
• We comprehensively review the construction of poor scalability, and poor security have made legacy
bootkits and summarize the first bootkit attack BIOS gradually challenging to meet the needs of mod-
model based on many typical bootkits cases. ern computers. The predecessor of UEFI was the In-
Compared to previous work [15, 5, 6, 34], the tel Boot Initiative developed by Intel in 1998 and was
model we propose is the first comprehensive, later renamed UEFI (i.e., Unified Extensible Firmware
structured attack model for bootkits. Interface). UEFI has gradually replaced the domi-
nant position of legacy BIOS. Modern computers ba-
• We provide a new perspective by evaluating the
sically use the UEFI boot mode, but there are still lots
techniques used by bootkits along two axes. On
of older computers that utilize the legacy BIOS boot
boot mode axis, we divide bootkits into legacy
mode. Bootkits have also gone through the process
BIOS and UEFI. On attack phase axis, we discuss
from legacy BIOS to UEFI. Next, we will discuss the
bootkits techniques from infection phase and boot
processes and characteristics of these two boot modes.
phase, respectively. Currently, the research on
Simultaneously, we will also briefly outline the possi-
bootkits is mainly scattered in the analysis report
ble attack points for bootkits in their boot processes.
of each sample, lacking a systematic and compre-
We mainly take Windows operating system as an ex-
hensive review, especially the review of bootkits
ample. However, the boot process of Linux and other
techniques in UEFI. And our research fills this
IoT devices is basically the same before their operat-
gap.
ing system officially runs.
• We analyze the co-evolution of bootkits attack
and defense techniques in the past few years. 2.1 Legacy BIOS Boot Mode
Based on these, we propose the future attack
surface and possible development direction for System booting in legacy BIOS mode can be briefly
bootkits. We believe bootkit attacks will have to summarized as the following steps:
rely on the latest underlying software vulnerabil- 1. After powering on, the ROM BIOS code performs
ities or OEM manufacturers’ flaws in the imple- POST (i.e., power-on self-test) and hardware ini-
mentation of security mechanisms, and the attack tialization operations.
targets will change from PCs to IoT devices. Si- 2. Read the data in the first sector of the hard disk
multaneously, for the sake of economic interests, (i.e., MBR) into the physical memory address

4 China Communications
 0x7C00. then executes it. After that, the bootmgr will read the
3. Execute the first 446 bytes of MBR as code, an- BCD (i.e., Boot Configuration Data), checks the in-
alyze the MBR partition table to find the active tegrity of itself, and calls winload.exe to load the OS
partition, and transfer the control to the first sec- kernel.
tor of the active partition (i.e., VBR). The boot process in legacy BIOS mode is critical
for bootkits and security developers. Attack of bootk-
4. Execute the code in the VBR and the 15 sectors its often happens in the bootstrap code and bootloader
immediately after the VBR to complete the anal- because it’s too late for bootkits to launch an attack
ysis of the active partition file system. after the OS kernel has been loaded.
5. Look for the OS bootloader in the active parti-
tion, such as bootmgr in Windows. Then run the 2.2 UEFI Boot Mode
bootloader, switch the CPU mode from 16-bit to
32/64-bit, and load the OS kernel until OS runs System booting in UEFI mode is very different from
normally. it in legacy BIOS mode. UEFI specification has stipu-
Bootmgr is a part of OS. So bootkit must hijack the lated that the code responsible for hardware self-check
control before bootmgr execution. Most bootkits in and initialization were all stored in the firmware lo-
legacy BIOS attack the bootstrap code, which means cated in the SPI flash memory chip. So there is no
the code is executed before the OS component. Fig- bootstrap code on the hard disk for bootkits to tamper
ure 2 shows the structure of MBR, VBR, and the con- with.
trol flow of bootstrap code. As shown in Fig. 3 [37], the boot process in UEFI
MBR mainly consists of MBR code and partition ta- mode consists of five stages, which are SEC (i.e., Se-
ble. Only one of the partition table entries is marked curity), PEI (i.e., Pre EFI Initialization), DXE (i.e.,
active. For example, we assume that the third entry in Driver Execution Environment), BDS (i.e., Boot De-
Figure 2 is active. MBR will read and calculate the be- vice Select), and TSL (i.e., Transient System Load).
ginning address of the active partition. Then the con- The RT (i.e., Run Time) provides some runtime ser-
trol is transferred to the first sector of the active parti- vices for OS running. The AL (i.e., After Life) is for
tion called VBR. Both MBR and VBR are 512 bytes. the situation where the system is catastrophically dam-
The first three bytes of VBR are a ”JMP” instruction, aged and whose specific actions have not been spec-
which skips the BPB (i.e., BIOS Parameter Block) ified in UEFI specifications. Both RT and AL have
structure and executes the VBR code. The VBR code nothing to do with the boot process, so we will not
reads the BPB and locates the IPL (i.e., Initial Pro- discuss them in detail here.
gram Loader) according to the offset in the structure of The five stages of the UEFI boot mode have their
the BPB. IPL’s mission is to access the file system of division of labor:
the current partition and transfer the control to the OS 1. SEC: Verify the RoT and utilize Cache-as-RAM
bootloader, such as bootmgr. The red crosses in Fig- before the main RAM is activated.
ure 2 represent possible bootkit attack points, which 2. PEI: Prepare the environment and HOB (i.e.,
will be discussed in detail in Section 4.2.1. Hand-Off Block) list for DXE. The PEI dispatcher
The process described above is the control flow of will schedule PEIM (i.e., PEI Module) to init the
the bootstrap code independent of the type of OS. CPU, chipset, and board.
Bootstrap code will transfer the control to the OS
bootloader. The original OS bootloader in Windows 3. DXE: The main module to execute the UEFI
was called NTLDR. After Windows Vista, the legacy drivers and modules. The DXE dispatcher ex-
NTLDR was split into two modules: bootmgr and win- ecutes each driver according to the list named
load.exe (or winresume.exe if the OS is loaded from mDiscoveredList, which records the drivers that
hibernation). Bootmgr also consists of two modules: were important to initialize the essential devices.
the code in 16-bit and a compressed PE image. The 4. BDS: Execute boot items according to a particu-
16-bit code switches the CPU from the real mode to lar policy by reading UEFI variables in NVRAM
the protected mode, and decompresses the PE image, (i.e., Non-Volatile RAM), which is equivalent to

China Communications 5
 MBR (Master Boot Record) VBR (Volume Boot Record)
0x0
MBR code 0x0 0x3 0x54 0x19C 0x1FE 0x200
0x1BE
Table entry 1 BPB (BIOS
0x1CE Parameterr VBR code Test strings 0x55AA
JMP
Table entry 2
0x1DE Block)
Table entry 3
0x1EE
Table entry 4
0x1FE
0x55AA
0x200

Bootkit Attack Points

IPL (Initial Program Loader)

0x1E00 0x0

Figure 2. Control flow of bootstrap code.

Pre Bootkit Attack Points

PEIM
Verifier
OS-Absent App
verify

CPU Init
Transient OS
Device, Bus, Environment
Chipset Init or Service
Driver Transient OS
Boot Loader
Board Init

EFI Driver Boot OS-Present

HOB App
Dispatcher Manager

Intrinsic Final OS Final OS

?
Services Boot Loader Environment

Pre EFI Driver Execution Boot Device Transient

Security Run Time After Life
Initialization Environment Select System Load
(SEC) (RT) (AL)
(PEI) (DXE) (BDS) (TSL)

Power on […Platform initialization…] […OS boot…] Shutdown

Figure 3. The architecture execution flow of UEFI. The red arrows represent the integrity verification processes, the blue
arrows represent the control flow transfers during UEFI system initialization, and the green arrows represent the control
flow transfers after the system boot.

selecting the OS to boot in most instances. OS kernel.

5. TSL: The first stage that the OS bootloader exe- From the functional division of these stages, it can
cutes as a UEFI application. If any severe error be inferred that there are some stages that are critical
happens or the user intervenes, it would enter the to the security of the UEFI boot process. The SEC,
UEFI shell. After the OS loader calls the Exit- PEI, and DXE stages are all vital points where the
BootServices function, the TSL stage ends, and bootkit will try to attack and tamper. The attacks to
the system enters the RT stage. All the system re- Boot Guard and ME (i.e., A9 and A10 ) even happen
source begins to transfer from UEFI core to the before the SEC stage. PEI and DXE are the main

6 China Communications
stages of the UEFI boot process where UEFI drivers The second axis we propose to characterize bootk-
and applications are executed, so many bootkits will its is attack phase. In this section, we summarize and
inject the payload into these two stages. Also, replac- present a bootkit attack model from the perspective of
ing the OS bootloader between BDS and TSL stages attack phase. On attack phase axis, bootkit attacking
is also a common attack vector for bootkits. The de- can be divided into infection phase and boot phase. In-
tails and other bootkit attack techniques in UEFI will fection phase occurs when a bootkit infects the target
be discussed in Section V. system for the first time. And it will not exhibit ma-
Compared with legacy BIOS, UEFI boot mode is licious behavior until the next reboot. Boot phase oc-
faster and safer. Their main difference is shown in Ta- curs every time the system reboots after the infection
ble 1. From the perspective of bootkit developers, the phase. In boot phase, bootkits hijack the control and
differences between legacy BIOS and UEFI mode sys- tamper with the OS loader to perform malicious func-
tems are as follows: tions. According to the characteristics of these two
• UEFI only loads the drivers necessary for ini- phases, we divide a bootkit into four components (i.e.,
tializing the essential hardware in the boot pro- an infector, a hidden file system, a malicious boot-
cess rather than initializing all the hardware in loader, and malicious kernel drivers). As illustrated
legacy BIOS. Bootkits need to select the appro- in Figure 4, the infector and the hidden file system are
priate hook driver in a targeted manner. corresponding to the infection phase, while the mali-
cious bootloader and malicious kernel drivers are cor-
• Utilizing the larger physical memory, most UEFI
responding to the boot phase. Both phases have their
code runs in 32/64-bit mode rather than the 16-
own goals to achieve. In infection phase, bootkits must
bit mode in legacy BIOS. Larger address space
break through the restriction of modifying the data on
means increased attack difficulty.
the hard disk or SPI flash and hide attack payloads in
• In legacy BIOS, the disk I/O and bootloader in- the victim system. In boot phase, bootkits have to hi-
teraction are implemented by BIOS interrupts. In jack the control earlier than the OS bootloader, bypass
UEFI, these are all implemented by UEFI ser- the integrity check, and load the malicious code into
vices. Bootkits must adopt a different control hi- memory.
jacking strategy.
From the security development point of view, legacy 3.1 Infection Phase
BIOS does not have a dedicated safety mechanism to
protect the boot process from bootkit attacks because Infection is the first step for bootkits to control the tar-
its architecture was designed a long time ago and was get system persistently. The infector and the hidden
never changed. Bootmgr can verify itself, but it is exe- file system will come into play during this phase. The
cuted after the bootstrap code, which can be modified infector will utilize vulnerabilities to write malicious
by bootkits without verification or warning. Secure data into the hard disk or SPI flash, while the hidden
Boot in UEFI guarantees that every stage in the boot file system will protect the malicious payload from de-
process will verify the code integrity of the next stage, tection by OS or security software.
such as SEC will verify the integrity of PEI before it
transfers the control to it. Therefore, Secure Boot can 3.1.1 Infector
theoretically ensure the integrity of the entire UEFI The infector, also called dropper in some articles [7,
boot process under the condition of RoT credibility. 41, 8], is an essential component of a bootkit. The
infector modifies the data on the hard disk or SPI flash
III. ATTACK MODEL OF BOOTKITS to drop the main function modules.
In legacy BIOS, modifying the bootstrap code is rel-
After summarizing the analysis reports of some so- atively more straightforward. The infector needs the
phistical bootkit samples [38, 39, 13, 12, 11, 40–43], privilege to read and write the hard disk. If the in-
we found that they had something in common in the fector does not have the privilege, it needs to utilize
structure that applied to most of the bootkits in legacy the privilege escalation vulnerabilities to do this. The
BIOS and some of the bootkits in UEFI. bootkit Olmasco’s [43] infector utilized MS10-092,

China Communications 7
 Table 1. The main difference between legacy BIOS and UEFI.

legacy BIOS UEFI

Unspecified firmware development Unified specification for firmware
Development process process, all BIOS vendors independently development and Intel reference code
support their own codebase (e.g., EDKI/EDKII)
Phoenix, AMI, etc. are not
Compatibility Most are compatible with each other
compatible with each other
Implementation Mostly assembly language C/C++
Memory model 16-bit real mode 32/64-bit protected mode
Bootstrap code MBR, VBR, and IPL None
Attack surface Mostly on the disk Mostly in the SPI flash
Partition scheme MBR partition table Guid Partition Table (i.e., GPT)
Security mechanism None Secure Boot and Boot Guard
Disk I/O BIOS Interrupts UEFI services
Bootloaders Bootmgr and winload.exe bootmgfe.efi and winload.efi
POST scheme Test every device every boot Only test the essential devices for booting
OS interaction BIOS Interrupts UEFI services
Boot configuration CMOS memory UEFI NVRAM variable

Victim Computer System

Attack Model of Bootkits
Device Storage
Infection Phase
Legacy BIOS or UEFI
Infector Firmware (Flash)

Hidden File System Bootstrap Code and OS Bootloader

Boot Phase
File System (Disk)
Malicious Bootloader

Malicious Kernel Driver Kernel Space User Space

Inject & Execute Operating System

Tamper & Parasitize

Figure 4. Attack model of bootkits.

which was the vulnerability utilized by Stuxnet [44] In UEFI, the infector’s goals are more challenging
to escalate privilege, and then wrote malicious boot- to achieve because reading and writing operations in
loader, dbg64, ldr64, and drv64 to the disk. These files SPI flash can not be performed directly. It must go
were executed sequentially during the boot process. through three steps to modify the firmware. It first

8 China Communications
needs to dump the local firmware. The infector usu- port device object. The lowest level of the driver stack
ally utilizes a particular driver to read and analyze the is the storage port diver, which provides an interface
firmware. LoJax is a typical UEFI bootkit exposed between a hardware-independent class driver and an
in 2018 whose infector utilized the RwDrv.sys, which HBA-specific (i.e., host-based architecture) miniport
was the kernel driver component of a benign software driver, such as the SCSI miniport.
named RWEverything [11]. RwDrv.sys supported In the era when legacy BIOS was the mainstream,
some IOCTL code to perform reading and writing op- the security software merely cared about the low-
erations to memory-mapped I/O space or a given PCI level drivers. The kernel-mode hooks were set up
configuration register. Second, it needs to patch the at the lowest hardware-independent level in the stor-
dumped firmware. LoJax’s approach was to replace age device driver stack by TDL3 sophistically, which
Ip4Dxe and NtfsDxe with a malicious compressed sec- made it bypass any monitoring tools or security soft-
tion that contained a PE image. Third, it has to break ware at the upper level of the file system or stor-
through the BIOS write protections. With the signed age class driver. Firstly, TDL3 got a pointer to the
normal kernel driver RwDrv.sys and a race condition miniport driver object of the corresponding device
vulnerability proposed by Corey Kallenberg and Rafal object. Then it created a new malicious driver ob-
Wojtczuk [45], LoJax’s infector eventually wrote the ject to overwrite the DriverObject field in the mini-
patched firmware back to the SPI flash and completed port driver object with the pointer to a newly created
the infection process. field. The malicious driver object had an array named
MajorFunction in the DRIVER OBJECT structure.
3.1.2 Hidden File System The IRP major handler pointers in the MajorFunction
array can intercept IRP MJ INTERNAL CONTROL
The hidden file system is another feature of bootkits. and IRP MJ DEVICE CONTROL for the following
Due to the fact that scanning the file system has been IOCTL (i.e., Input/Output Control) code in order to
a primary function of some security software, storing monitor and modify read/write requests to the hard
the malicious driver or PE image in the native OS file drive. So when a read operation is encountered, TDL3
system is a dangerous way for bootkits. Many ad- zeros out the return buffer on completion of the I/O
vanced bootkits have their own file systems, which are operation, and it skips the whole read operation in the
independent of the native file system. Simultaneously, event of a write data request. This hooking technique
the bootkit’s file system is not visible to OS by means does not touch any of the frequently protected and
of sophistical hooks. monitored areas. Many classic hooking techniques,
TDL3 is the first one to store its configuration files including hooking the SSDT (i.e., System Service De-
and payloads in a hidden file system. Its successor scriptor Table) [46] and the IDT (i.e., Interrupt De-
TDL4 and other bootkits, such as Rovnix, Gapz, etc., scriptor Table) [47] are much more eye-catching by
also utilized this technique. Figure 5 is the architec- the security software.
ture of the storage device driver stack in Microsoft The physical space of the hard drive occupied by
Windows. There are three levels of drivers in the stor- the hidden file system is designed to grow from the
age device driver stack. The file system drivers are on end forward. And all the data is encrypted by XOR
the top of the stack. The processing of an IRP (i.e., with 0x54. More advanced Rovnix [48] uses RC6
I/O request packet) structure that is addressed to some to encrypt the hidden file system. A very important
object located on a storage device. This storage de- point of the design concept of the hidden file sys-
vice begins at the file system driver’s level. The spe- tem is that the hidden file system can be accessed
cific device of the storage object (i.e., the disk parti- by Windows APIs like CreatFile, ReadFile, WriteFile,
tion, which is a contiguous storage area initially re- etc. Bootkits reused the upper-level logic of Windows
served for a file system) is determined by the corre- APIs and performed hooking operations at the bottom
sponding file system driver, which issues another IRP driver level. This approach could minimize the im-
to a storage class driver’s device object that is the plementation cost of bootkit developers and maximize
middle level of the stack. The storage class driver the stability of the system due to the fact that the more
transfers the I/O request into a corresponding mini- changes to the OS, the more unstable the system will

China Communications 9
 Original
Filesystem drivers IRP
(e.g., ntfs.sys, fastfat.sys)
IRP by
file system Miniport
drivers Storage class drivers
(e.g., disk.sys) device
object

Storage port drivers

(e.g., scsiport.sys, storport.sys) Malicious
driver
SCSI Storport ATA IDE object
miniport miniport miniport miniport

Bootkit Attack Points

Hardware

Figure 5. Microsoft Windows storage device driver stack.

be. developers.
Table 2 [16] shows the hidden file systems charac-
teristics of four classic bootkits. Except that Rovnix’s 3.2.1 Malicious Bootloader
file system is modified based on FAT16, the other three
have their own customized file systems. They all en- After successfully infecting the system, the bootkit
crypt the contents with different algorithms, and some will function next boot. The malicious bootloader is
are even compressed after encryption. Therefore, it is the first component executed during the boot process
not easy to analyze the attack load inside the hidden of a bootkit. It has mainly three duties:
file systems. • Hijack the control before the OS bootloader.
However, Rodionov et al. [15] developed a tool for Modifying the OS kernel to perform malicious be-
analyzing the hidden file systems named ’HiddenF- havior after the OS completely boot is unrealistic
sReader’ to recover the contents of bootkits’ hidden due to the fact that the kernel-mode code sign-
storage. It consists of two modules which are a kernel- ing policy will verify the signature of every driver
mode driver and a user-mode application. The kernel- loaded into the kernel space. So the infector must
mode driver is responsible for disabling rootkit/bootkit execute earlier to patch the bootloader to disable
self-defense mechanisms, and the user-mode applica- the corresponding security mechanisms [7, 49].
tion provides the user with an interface to access the • Transfer the control to a certain point to regain
hard drive in a low level of the driver stack. But it the control. Considering that a malicious boot-
could not apply to most cases. In general, the exis- loader will transfer control to the original boot-
tence of a hidden file system dramatically increases loader to boot the OS, the bootkit must be able
the difficulty of bootkit detection. to regain the control after the original bootloader
gets the control. Bootkits usually used the hook
3.2 Boot Phase method to hook the INT 13h handler to regain
Boot phase is the crucial manifestation of bootkits dif- control every time when the disk services were
ferent from other malicious code. In boot phase, the used [38, 50, 51].
malicious bootloader and the malicious kernel drivers • Bypass the security mechanisms and load the
come into play. The malicious bootloader will destroy malicious module into memory. This is the crit-
the integrity of the control flow of OS booting, while ical step for bootkits. Due to the security mech-
malicious kernel drivers will perform corresponding anisms like Kernel-Mode Code Signing Policy,
malicious behavior according to the purpose of bootkit rootkits were not able to function. Booting be-

10 China Communications
 Table 2. Hidden file system implementations of four classic bootkits.

Functionality/malware TDL4 Rovnix Olmasco Gapz

File system type Custom FAT16 modification Custom Custom
Encryption XOR/RC4 Custom (i.e., XOR+ROL) RC6 modification RC4
Compression # ! # !

fore the original bootloader gives the bootkit the • Implement the network communication mod-
advantage of disabling security mechanisms in ules. Some bootkits are designed to create a bot-
time. The following sections introduce the ways net for attackers. Such bootkits often need to
to disable such security mechanisms by their log- communicate with the C&C servers to download
ical loophole. Once the kernel-mode code signing the malicious payloads or get commands to exe-
policy is disabled, the malicious bootloader loads cute [53]. Festi [52] and Gapz [41] implemented
malicious kernel drivers into memory, and the du- the customized TCP/IP stack protocols in kernel
ties of the malicious bootloader are accomplished mode based on the miniport adapter driver, which
[41–43]. made them bypass firewalls and network monitor-
ing tools running on the infected machine. Gapz
even encrypted the messages exchanged between
3.2.2 Malicious Kernel Driver the botnet and the C&C server and verified the au-
Malicious kernel drivers contain the major functions thenticity of the source of the messages to prevent
that the bootkit developers want to implement. The them from being analyzed [15].
functions of the malicious kernel drivers depend on
• Implement the self-defense mechanisms
the goals of the bootkits. They were loaded by either
against the security software and analysts.
replacing the normal kernel driver or directly loading
Firstly, bootkits have to take action to protect
into kernel space after disabling the integrity check
their core data structure from being modified
transitorily. We classify the functions of the malicious
by security software. Festi protected its registry
kernel drivers into the following categories. A bootkit
keys by hooking the SSDT function ZwEnumer-
malicious kernel driver may have one or more of these
ateKey to prevent them from being enumerated
functions.
by OS [52]. Secondly, since bootkits had been
• Implement the kernel driver hooks. Hide the utilized as commercial tools, advanced bootkits
file system of the bootkit, intercept all the read- developers have considered the confrontation
/write requests and protect critical areas from be- with analysis and debugging tools. The next
ing read or overwritten. The bootkits with the section will introduce the anti-debugging and
hidden file systems (e.g., TDL4, Gapz, Olmasco, anti-emulating techniques of bootkits.
Rovnix, etc.) often have such modules in their
The four components of the bootkit attack model
kernel drivers.
make a bootkit just like a small OS parasitic on the
• Inject the payloads into processes. Bootkits native OS. The ”parasitic” OS has its malicious boot-
often have some payloads that are stored in the loader corresponding to the native bootloader, the hid-
hidden file system or downloaded from the C&C den file system corresponding to the native file system,
server. Festi’s way is downloading the malicious and the malicious kernel driver corresponding to the
function modules from the C&C server to the native OS kernel. The red arrows in Figure 4 show
memory and executing them [52], while Rovnix’s that infection phase of a bootkit can be regarded as the
way is looking for the signature ”JFA” in its hid- process that the infector installs a small OS on the na-
den file system and injecting the modules which tive OS. And boot phase of a bootkit can be regarded
contain the signature into the normal processes as the process that an OS normally boots. As for IoT
[49]. devices that utilize the cropped Linux kernel or other

China Communications 11
simpler systems, the bootkit threats they face are more calation) has become a necessary part of bootkits in
superficial, which means the bootkit attacks for IoT infection phase.
devices are more straightforward. Many vulnerabilities have been utilized to achieve
In the next two sections, we will discuss bootkit at- LPE in the past few years. Olmasco, TDL4, and
tack techniques on the proposed two axes. On boot Stuxnet have been confirmed to utilize MS10-092 to
mode axis, Section IV and Section V respectively in- escalate privileges [43, 7, 44], while Gapz leveraged
troduce the bootkit attack techniques in legacy BIOS CVE-2010-4398 [54] and CVE-2011-3402 [55] for
and UEFI. On attack phase axis, we discuss the at- LPE. Huang et al. showed that the essence of LPE
tack techniques in infection phase and boot phase in in Windows is actually the abnormal interactions be-
each section. Techniques in infection phase focus on tween high-privilege processes and user-controllable
the methods to gain read/write access to the medium files [56], and the situations in other operating systems
that stores the code that bootkits need to attack. Tech- (e.g., Linux and Android) are also similar [57, 58].
niques in boot phase focus on the methods to attack Kujanpää et al. summarized this interactions model
the system boot mechanisms and perform malicious and utilized reinforcement learning to automatically
behavior. However, we also discuss the security mech- escalate privilege in an emulated Windows 7 environ-
anisms in each boot mode and the co-evolution of ment [59]. However, Scott et al. conducted a survey
bootkits and security mechanisms. about techniques to prevent LPE, but they concluded
that no single technique was found to effectively mit-
igate all known and potential attack vectors with rea-
IV. BOOTKIT TECHNIQUES IN LEGACY
sonable performance cost overhead. In general, it is
BIOS
feasible to achieve LPE under the condition of ex-
In this section, we will illustrate some attack tech- ploitable vulnerabilities and interactions model be-
niques in our attack model (i.e., A1 -A4 ), as well as tween high-privilege processes and user-controllable
the security mechanisms (i.e., D1 -D3 ) applied in the files. So we think the infection phase is an indispens-
boot process and their implementation logic flaws in able but not the most valuable part of bootkit attacks
legacy BIOS. in legacy BIOS. The most valuable part of bootkits in
legacy BIOS is the techniques in boot phase.

4.1 Infection Phase in Legacy BIOS 4.2 Boot Phase in Legacy BIOS
Infection phase for bootkits in legacy BIOS is much In legacy BIOS, the primary duties of bootkits for boot
easier than it is in UEFI. All the targets the infector phase were to gain the control before OS bootloader
needs to attack are on the disk. So bootkits infectors and maintain the control until malicious function mod-
just need to break through physical disk protections ules were executed. Next, we will discuss the tech-
and gain the read/write access to a specific physical niques bootkits used to achieve this goal.
location on the disk. Then they can easily tamper with
the bootstrap code and write malicious function mod- 4.2.1 Tamper with Bootstrap Code (A2 )
ules into the disk.
One of the malicious bootloader’s duties is hijacking
the control before the OS bootloader. In legacy BIOS,
4.1.1 Break through Physical Disk Protections (A1 )
it is primarily achieved by tampering with bootstrap
In most systems, reading or writing in insensitive par- code. In general, the attacks to bootstrap code can be
titions in the file system does not need high privilege classified into the following four categories. We will
(e.g., administrator privilege in Windows, root privi- illustrate their strengths and weaknesses in Figure 6.
lege in Android, and Linux). But reading or writing • Replace the whole MBR [7]. MBR is the first
to a specific address on the hard disk always requests code executed on the hard disk. TDL4 backed
higher privileges. For bootkits in legacy BIOS, infec- up the original MBR and replaced the first sec-
tion is based on the ability to modify the disk by phys- tor with its own code. The bootkit code that oc-
ical address. Therefore, LPE (i.e., local privilege es- cupied the first sector of the disk would jump to

12 China Communications
 Original MBR

Partition 4
Partition 1
Partition 2
Partition 3
(active)
MBR Original
code … VBR
Filesystem data

Before infection
After infection Ś ř

Bootkit Original Original Bootkit

code … VBR
Filesystem data
MBR partition

(a) Replace the whole MBR.

Original MBR
Partition 4
Partition 1
Partition 2
Partition 3
(active)

MBR Original
code … VBR
Filesystem data

Before infection
After infection ř
Ś
漏active漐
Partition 1
Partition 2
Partition 3
Partition 4

MBR Original Bootkit

code … VBR
Filesystem data
partition

(b) Modify the partition table.

Original Original Original

MBR … VBR IPL
Filesystem data

Before infection Ř ř

After infection ś decompress and execute

Original Original Bootkit Compressed Bootkit

MBR … VBR code IPL
Filesystem data
partition

Ř ř Ś

(c) Compress and insert code before IPL.

Hidden sectors

Original Original Original

MBR … VBR IPL
Filesystem data

Ř ř
Before infection
After infection Ś

Original Modified Original Bootkit

MBR … VBR IPL
Filesystem data
partition

Ř
Hidden sectors
ř

(d) Modify the BPB in VBR.

Figure 6. Four categories of methods to hijack the control before the bootloader. The black arrows represent normal control
flow transfers, while the red arrows represent control flow transfers that were hijacked after bootkit attacks.

China Communications 13
 the bootkit partition, which has been created dur- out touching MBR, but the decompression of the
ing the infection process. After finishing the job IPL must be accomplished in the 16-bit real mode,
of patching the OS bootloader, the original MBR which is time-consuming and needs more code to
would be recovered, and the normal boot process implement.
would carry on. As illustrated in Figure 6a, this • Modify the BPB in VBR [41]. The ideal ap-
approach is the simplest and most direct. How- proach to hijack the control is to modify the data
ever, replacing the whole MBR is too obvious for in the bootstrap code as little as possible. Gapz
security software to ignore. The bootkit code in modified the variable ”hidden sectors” in BPB,
the first sector does not have the MBR code or which is a structure in VBR. The value of hid-
partition table entry. If security software notice den sectors indicates the number of sectors before
the MBR is obviously abnormal and recovers the IPL on the disk. VBR code locates the IPL and
MBR, the bootkit will fail to execute. transfers the control according to this value. As
• Modify the partition table [43]. Under normal illustrated in Figure 6d, Gapz changed the hidden
conditions, MBR has only one partition marked as sectors to a relatively large value which was cal-
active. We assume the active partition is partition culated to just offset to the bootkit partition. Af-
3 in Figure 6b. Rather than replacing the whole ter that, the bootkit transfers the control back to
MBR, Olmasco only modified the partition table. the original IPL to boot normally. This approach
It selected an unoccupied partition and marked it is relatively hard to detect by scanning the disk.
active instead (i.e., partition 4). The selected par- However, with the strengthening of security soft-
tition in the partition table pointed to the bootkit ware’s awareness of bootstrap code backup and
partition, which made the bootkit hijack the con- scanning, it has become increasingly difficult to
trol. After that, the bootkit would mark the origi- modify the data on the disk to hijack the control
nal active partition (i.e., partition 3) as active and flow.
make the boot process carry on. This approach is
more concealed than the previous one due to the 4.2.2 Hook BIOS Interrupt Handlers (A3 )
fact that the partition table of each computer is
In legacy BIOS, before OS has totally booted, the
different. So the security software can not deter-
BIOS interrupts implemented the interaction with the
mine whether the MBR has been attacked directly
system resource (e.g., disk I/O, debug registers). Nev-
based on the value of the partition table. However,
ertheless, the interrupt handlers are executed in mem-
the weakness is also obvious. MBR partition ta-
ory and could be hooked. The most common hook
ble only has four entries. If the entries have been
approaches for bootkits are hooking the INT 13h, INT
used up, this approach will fail.
19h, and INT 1h.
• Compress and insert code before IPL [49, 42]. INT 13h is the direct disk service supported by
Since the MBR has been focused on by security legacy BIOS. Before the OS disk driver is loaded into
software, modifying any part of MBR was ob- the memory, any access to the disk must rely on INT
vious for bootkits. Thus IPL became the attack 13h. The INT 13h functions from the bootstrap code
target. As illustrated in Figure 6c, Rovnix modi- to the OS bootloader. Even bootmgr and winload.exe
fied the IPL by compressing it with the aPlib com- still use the INT 13h to read and write the disk. There
pression library [60] and putting the compressed were many bootkits in legacy BIOS whose analysis re-
IPL at the end of the place that the IPL occupied ports [38, 42, 43, 41, 34, 7] have shown that they uti-
originally. The bootkit code was placed in front lized the hook at INT 13h handler to regain the con-
of the compressed IPL, and all 15 sectors would trol every time the disk service is called. At the same
be encrypted (the original IPL occupied 15 sec- time, hooking INT 13h can make the bootkit monitor
tors). Thus VBR would transfer the control to every read and write operation to the disk. The hook
the bootkit code, and the bootkit would decom- process often happens when the bootkits firstly hijack
press the IPL and execute it to boot normally at the control in a malicious bootloader that locates the
last. This approach intercepts the control with- IVT (i.e., Interrupt Vector Table) entry of the INT 13h

14 China Communications
handler and inserts a ”JMP” instruction ahead of the vices to get the manufacturer names of the BIOS, disk,
handler code [9]. controller, etc., to determine if it was in a virtual ma-
INT 19h is the Bootstrap Loader Service supported chine. On the other hand, Olmasco could identify the
by legacy BIOS. This interrupt attempts to load the company of the infected machine by the system name
sector at head 0, track 0, and sector one on the first and domain name and deploy a customized payload
diskette into memory at 0:7C00h. Bootkits can hook that explicitly targets that company [43].
INT 19h handler and recall INT 19h to hijack the con- Anti-debugging is also a feature of some bootkits.
trol before the original MBR [6]. However, INT 19h A common and straightforward approach to detect the
would only be called once in the boot process, so this debugging environment is checking the value of Kd-
method is often used with hooking INT 13h. DebuggerEnabled by some Windows APIs [63]. Festi
The INT 1h handler is called when debugging event utilized a more violent method [52]: clearing the de-
occurs. The dr0 through dr7 registers are used to trace bug registers dr0 through dr4 periodically, which made
and set hardware breakpoints. Rovnix utilized a so- the hardware breakpoints invalid.
phistical way to implement hooks by these debugging
registers [49]. Rovnix only needs to hook the INT 1h 4.3 Evaluation for Related Security Mecha-
handler, write the address of the hooking target to the nisms in Legacy BIOS
dr0 through dr4 registers, and set the bitmask in dr7
to enable the hardware breakpoints. When the target 4.3.1 Early Launch Anti-Malware (D1 )
address receives the control, it will be stuck in debug- The ELAM (i.e., Early Launch Anti-Malware) module
ging event, and the hooked INT 1h handler will get the was a kernel driver designed to allow the third-party
control. This approach achieves hooking any address security software’s drivers to execute before any other
with only a few code changes. third-party drivers. It has an ELAM database of known
benign and known malicious driver signatures [64].
4.2.3 Obfuscation and Anti-dynamic-analysis Tech- ELAM verifies the hash and certificate of each driver
niques (A4 ) image to be loaded. So it could prevent attackers from
loading a malicious kernel driver after the OS kernel
As a category of advanced malware, some bootk-
was initialized. However, the implementation of the
its were even sold on a private underground forum
ELAM was not perfect. The default policy of ELAM
[16]. Thus the developers have adopted some tech-
is PNP INITIALIZE BAD CRITICAL DRIVERS,
niques to prevent security researchers from analyzing
which means loading known benign, unknown, and
the bootkits statically and dynamically. Like context-
known bad but critical drivers. It is a relatively loose
aware malware, some bootkits have utilized obfusca-
policy because ELAM must ensure the system can
tion, anti-VM, and anti-debugging techniques. Branco
boot successfully firstly. Also, the design of ELAM
et al. [61] summarized the techniques of anti-dynamic
determines that it could not prevent the bootkits from
analysis that the malware often used. However, some
infecting the system due to the time that ELAM works
bootkits utilized other clever ways to make analysts
being too late. A bootkit attack often happens before
harder to analyze them on this basis.
the OS bootloader, but ELAM works after the OS
As shown in Section 4.2.1, Rovnix needs to decrypt
kernel is initialized as a kernel driver. ELAM could
the whole IPL to execute the malicious code. The de-
work against rootkits relatively effectively, but it
cryptor Rovnix adopted is polymorphic [49]. Rovnix
could not stop bootkits, which is the most significant
developers split the decryptor into many basic blocks
difference between bootkits and rootkits.
randomly, upset their order, and connected them with
”JMP” instruction. This obfuscation approach makes
4.3.2 Microsoft Kernel-mode Code Signing Policy
the decrypting processes different in each instance of
(D2 )
Rovnix.
WMI (i.e., Windows Management Instrumentation) Microsoft kernel-mode code signing policy requires
could be used to detect the virtual machine environ- that each driver be verified before it is loaded into the
ment [62]. Olmasco utilized the WMI IWBemSer- kernel. In the old version of Windows in 32-bit mode,

China Communications 15
it is optional. However, in the modern 64-bit Windows and granted solely through the hypervisor. The con-
version, it is mandatory. The reason why bootkits need tainers in VSM are kind of similar to the enclave in
to be executed before OS is to bypass or disable the Intel SGX [68]. When the VSM is in place, the con-
security mechanisms like this. If bootkits execute af- tainers will still be secure under the condition of the
ter OS booted, the kernel-mode code signing policy kernel having been compromised since virtual con-
will block this malicious execution. Moreover, indeed, tainers are separated from each other. To the best of
the kernel-mode code signing policy has some weak- our knowledge, no bootkit has succeeded in compro-
nesses for bootkits to bypass [16]. mising the Windows VSM that has been spotted in the
• In Microsoft Windows 7 and Vista, whether the wild ever. However, the performance overhead and re-
integrity checks were enforced depended on a source consumption of VSM is large, which causes it
variable in kernel space named nt!g CiEnabled. to be unused in most cases.
Turla utilized the vulnerability of VBoxDrv.sys to
accurately clear the value of the nt!g CiEnabled
V. BOOTKIT TECHNIQUES IN UEFI
in the kernel space [65], thus the malicious kernel
drivers could be loaded into memory later. In this section, we also introduce the attack (i.e., A5 -
• If OS boots into WinPE (i.e., Windows prein- A12 ) and defense techniques (i.e., D4 -D6 ) in UEFI
stallation) mode, the nt!g CiEnabled would be from infection phase and boot phase. Different from
set to false, and the integrity checks would be the focus of techniques in legacy BIOS, the most valu-
disabled briefly. TDL4 utilized this characteris- able part for bootkits in UEFI is the techniques in in-
tic to load its malicious kernel driver in WinPE fection phase.
mode [7]. TDL4 searched the value 16000020
and modified it to 26000022, which meant Bc- 5.1 Infection Phase in UEFI
dOSLoaderBoolean WinPEMode. When boot-
mgr read the BCD, the OS booted into WinPE Section 4.1 has shown that the key for bootkits to
mode and loaded the TDL4 malicious driver. infect in legacy BIOS was high-privileged access to
• If OS did not boot into WinPE mode, there was hard disk physical addresses. Bootkits resided in ar-
another and last chance to disable the integrity eas on the disk that were not aware by the OS, which
checks: the TESTSIGNING option, which was made them survive after reboots or even system re-
intended to be used for debugging the developing install. Formatting the hard disk can completely re-
benign drivers. If it is set to TRUE, a driver could move such bootkits. But if the UEFI firmware stored
be loaded into the kernel with an invalid signa- in the SPI flash is infected with bootkits, it is much
ture. Necurs utilized the TESTSIGNING to load harder to remove them. Infection phase in UEFI
the malicious kernel driver with a custom certifi- mainly refers to the phase that bootkits try to mod-
cate [66]. ify binaries in firmware or tamper with the execution
Since Windows 8, the integrity checks did not rely on process of firmware in memory. We will discuss some
a single variable anymore but utilized more fields for techniques used by bootkits to achieve this goal.
additional callback functions to verify the signatures
of the PE images. However, for bootkit developers, 5.1.1 Tamper with ESP (A5 )
they can still achieve the same goal in a similar way,
ESP (i.e., EFI System Partition) is a segment of stor-
but with more reverse engineering effort.
age space on the disk. Usually, an ESP contains the
bootloaders (e.g., bootmgfw.efi and bootx64.efi) or
4.3.3 Virtual Secure Mode (D3 )
kernel images (e.g., kdstub.dll) for all installed oper-
VSM (i.e., Virtual Secure Mode) is a relatively new ating systems and configuration or log files (e.g., BCD
technique based on Microsoft’s Hyper-V in Windows and BCD.log). At the end of the UEFI firmware code
10 [67]. VSM makes the OS and critical system mod- execution (i.e., the BDS stage), the control is trans-
ules execute in many isolated containers protected by ferred to the bootloader of the chosen OS located in
Hyper-V. Access to these isolated regions is controlled ESP.

16 China Communications
 As the connection between UEFI and OS on the condition of proper configuration of BLE. And BLE
disk, ESP has become a critical attack vector for will soonly make BIOSWE set to 0 during a periodic
bootkits. FinSpy [2] replaces the bootmgfw.efi with check, which causes a short time for attackers to uti-
a malicious bootloader in ESP and encrypts its ma- lize. In this way, with enough attempts, an attacker
licious kernel drivers with RC4. The decryption key can write arbitrary malicious code into the firmware
is the unique GUID of the EFI partition, so it is dif- and stay there for a long time. LoJax used this vul-
ferent in every infected machine. When the UEFI nerability to create two threads; one repeatedly tried
code transfers the control to bootmgfw.efi, FinSpy hi- to set BIOSWE to 1, and the other tried to write mali-
jacks the execution and hooks the kernel functions cious code into the SPI flash [11].
to drop the attack payloads. Similarly, ESPecter [1]
adds new PE sections and modifies the entrypoint of Attacking the Update Process of the Firmware.
bootmgfw.efi and bootx64.efi to refer to the malicious The first attack to the BIOS update process was pre-
code. The modification of both FinSpy and ESPecter sented by Wojtczuk et al. [72]. After that, the up-
will patch the OS bootloader (i.e., winload.efi). The date process of the firmware has been a critical attack
patched OS bootloader will further patch the OS ker- surface for attackers. According to the UEFI speci-
nel (i.e., ntoskrnl.exe) to perform malicious behaviors. fication, only signed UEFI capsule-based updates are
In UEFI, attacking ESP is a relatively easier way to allowed to be written to the firmware. Bashun et al.
tamper with the boot process than attacking firmware summarized the attack vectors of the update of the
in SPI flash. But this method only works when Secure UEFI variables and signature database in firmware,
Boot is turned off. The modified bootloader in ESP and they found many update processes did not ver-
can not pass the integrity check of the previous stage. ify the signatures of the binaries [73]. Matrosov et al.
found that the DerStarke could use the PeiLoader (i.e.,
5.1.2 Break through UEFI Firmware Protections (A6 ) PL.efi) to hook the firmware update process on the fly
and inject the implant named DxeInjector (i.e., DI.efi)
The goal of breaking through UEFI firmware pro-
to the modified firmware binaries [74]. In Summary,
tections for bootkits is similar to the goal of break-
the main reason for the update process being attacked
ing through physical disk protections in Section 4.1.1.
is that the user-mode update program did not perform
Most manufacturers have implemented some protec-
signature verification on the binaries to be updated, or
tion schemes [69–71] to protect the firmware from be-
the signature verification mechanism itself has vulner-
ing tampered with. Nevertheless, some of them had
abilities.
weaknesses in logic. Attacks to firmware protections
can be classified into two categories, which aim at the
BIOS control bits protection and the update process of 5.1.3 Compromise UEFI Secure Boot (A7 )
the firmware. Secure Boot is a critical security characteristic of
UEFI. It establishes a chain of trust from the RoT dur-
Attacking the BIOS Control Bit Protection. The ing the boot process. Similar to ELAM, there are two
BIOS CNTL register is designed to protect the UEFI critical databases in Secure Boot architecture named
BIOS from unauthorized modification. But its im- db and dbx. The db records a list of trusted public keys
plementation had logically flawed. The BIOS CNTL certificates authorized to authenticate signatures, and
register has three critical bits (i.e., BIOSWE, BLE, the dbx records a list of certificates of public keys and
and SMM BWP) involved with writing operations to hashes of UEFI executables that are prohibited from
the firmware. The firmware is allowed to be written executing at boot time. Matrosov et al. proposed two
when BIOSWE is set to 1. BLE is used to ensure approaches to attack Secure Boot based on the con-
BIOSWE is 0, which prevents BIOSWE from an ac- dition that protections of SPI flash have already been
cidental flip. Kallenberg et al. found that the imple- broken [16].
mentation of BIOS CNTL had a race condition vul- • Patch PI firmware to disable Secure Boot [75].
nerability [45]. When the SMM tries to set BIOSWE Before the Verified Boot and Measured Boot [76]
to 1, the BIOSWE is set to 1 shortly indeed under the were adopted, Secure Boot relied on PI firmware

China Communications 17
 (i.e., SEC, PEI, and DXE dispatcher) and PK (i.e., hardware developers when they hand over laptops for
Public Key) stored in SPI flash as RoT. Since a security check or leave them in the hotel. On the
EDK II has been widely used among firmware other hand, Vu et al. have shown that attackers could
vendors, it was not a secret that the source code also infiltrate into the internal network of developers
of the routine DxeImageVerificationHandler for and add malicious code to the source code repository
verifying the signatures was located in Securi- or build server [84]. These scenarios could happen
tyPkg/Library/DxeImageVerificationLib folder in in APT (i.e., Advanced Persistent Threat) attacks [85]
EDK II. Attackers could patch that routine to re- and would cause large-scale damage once successful.
turn EFI SUCCESS every time. Thus they could Ibdah et al. demonstrated an attack that leveraged
load and execute the malicious code as they want. tampered firmware and system management cycles to
• Modify the UEFI variables to bypass security covertly collect data from the application layer [86],
checks [77, 78]. Most implementations of Secure which showed the huge threat of untrusted firmware
Boot are stored in UEFI NVRAM variables. At- to upper-layer system applications. Attacking the sup-
tackers can add the hash of the malicious modules ply chain makes bootkits infection phase easier; in
to db or remove it from the dbx. They can even turn some bootkits have been confirmed to be used for
replace the PK with their own certificates and con- supply chain attacks. MoonBounce was considered a
trol the RoT permanently. bootkit used for supply chain attack [3]. The sample
However, the two attack approaches were ineffective found was only three functions hooked away from the
since Intel introduced the Verified Boot and Measured original firmware. It utilized open-source components,
Boot. But there were still many machines vulnerable targeted the MSI E7846IMS.M30, and was released on
to these attacks due to whose manufacturers did not the same day as the MSI firmware patch [87]. There-
configure or implement the security mechanisms prop- fore, we believe that supply chain attack will be an in-
erly [20, 74, 79, 80]. creasingly important technique for bootkit developers,
especially APT groups.
5.1.4 Pollute the Supply Chain (A8 )
5.1.5 Undermine Intel Boot Guard (A9 )
SUNBURST in SolarWinds event [81] has shown the
high destructiveness and stealth of supply chain attack. Section 5.2.1 shows that firmware binaries in the SPI
In fact, supply chain attacks have appeared in legacy flash could not be trusted due to the fact that many
BIOS [82, 83]. But from a bootkit developer’s per- SMM attacks could compromise them. Intel intro-
spective, supply chain attacks make more sense for duced the Boot Guard to use signed ACM (i.e., Au-
breaking through security mechanisms in UEFI. For thenticated Code Module) to verify the UEFI BIOS
bootkits in UEFI, the purpose of infection phase is to binaries before executing them. The RoT was also
break through the protections of firmware and modify moved from the DXE to the hardware inside the In-
or insert their malicious function modules into the vic- tel microarchitecture. The hash of an OEM public key
tim systems. Polluting the supply chain of firmware is locked within the FPF (i.e., Field Programmable
vendors is a relatively convenient method for bootkit Fuse), which can be programmed only one time by
developers because it lightens the workload for utiliz- the end of the manufacturing process. The ACM code
ing other post-exploitation techniques to complete the is parsed and verified by the CPU’s microcode which
infection phase. will not be tampered with by attackers. Then verified
Supply chain attack in firmware often happens dur- ACM will verify the signature of UEFI BIOS binaries,
ing the firmware development process. Attackers can which makes the boot process can be trusted even if
introduce misconfigurations to the security mecha- the firmware protections have been broken.
nisms (e.g., the policy of Secure Boot and the flag of But in implementation, Matrosov et al. found that
manufacturing mode for FPF) implemented by OEM some vendors have not written their hashes in the FPF,
hardware vendors. It could be performed through or they did so but did not subsequently disable the
physical contact or remotely. Attackers can get phys- manufacturing mode that still allows a write operation
ical access to the personal computers of firmware or for attackers to write FPF keys of their own and then

18 China Communications
lock the system, which makes them control the RoT and BMC (i.e., Baseboard Management Controller), in
forever [79]. At the same time, the FPF could also which some attacks have been implemented [93, 24].
be modified by Intel ME as its memory regions when These chips are also the ideal attack objects for bootk-
the ME is still in the manufacturing mode, and ME its at the same time. Although they are relatively safe
in that mode can be accessed from the OS for both inside, the boundary interfaces of them are vulnerable
reads and writes in turn [16]. On the other hand, some to attackers.
CPU debugging interfaces were not disabled before
they left the factory (e.g., Intel DCI), which made at- 5.2 Boot Phase in UEFI
tackers destroy as they wished with physical access to
Different from infection phase, boot phase in UEFI
the CPU[80].
and boot phase in legacy BIOS have a lot in common.
Because even though the boot process of the BIOS
5.1.6 Utilize Intel Management Engine (A10 ) and the storage location of the firmware have changed,
Intel ME (i.e., Management Engine) is a special and the process of loading the OS kernel has not changed
critical part for both firmware vendors and attackers. much. The methods that malicious bootloaders used
ME has a separated x86-based CPU and an embedded to bypass security checks and load the malicious ker-
real-time operating system on a separate 32-bit mi- nel drivers in legacy BIOS were confirmed that they
crocontroller which is totally independent of the main were still utilized by many recently appeared bootkits
CPU [88]. It is an ideal attack vector for bootkits de- in UEFI [1, 3, 2, 94]. However, there are some new
velopers to insert their malicious code to attack the techniques worth noting that appeared in UEFI, and
RoT due to the power of ME to execute in SMM. ME we will supplement these techniques below.
code is executed on its own chip, but it needs to com-
municate with other components on the board, which 5.2.1 Manipulate SMM Modules (A11 )
would be an essential attack surface for bootkits. ME SMM (i.e., System Management Mode) is the highest
uses HECI (i.e., Host-Embedded Controller Interface) privileged execution mode in x86 processors, and it
to communicate with the OS kernel. If ME does not implements platform-specific management functions
verify the input from OS, it could be compromised independently of the OS. OS software can raise an
when the attacker has taken over the OS kernel. SMI (i.e., System Management Interrupt) to enter the
Goryachy et al. found vulnerabilities to execute ar- SMM, which is also called Ring -2. The high privilege
bitrary code in ME’s OS [89–91]. And they showed means that attacks in this mode will cause great harm
that the Booktit could attack the RoT to bypass or dis- to the system. Yao et al. [71] classified the attacks to
able the security mechanisms (e.g., Intel Boot Guard) SMM into five categories: unlocking SMRAM [95],
[28]. Cache Poisoning [96], SMRAM remap [97], branch
Intel AMT (i.e., Active Management Technology) outside of SMRAM [98] and SMM communication at-
platform is implemented as an application in ME’s tack [70]. For bootkits, the main purpose of attacking
OS [26]. AMT can communicate with another sys- SMM is that SMM is closely related to the update pro-
tem over the network in ME environment, even if the cess of SPI flash. So we focus on the last two cate-
central system has not booted. It can also access the gories of attacks.
memory independently of the main CPU. Tereshkin et The communication between the SMRAM and
al. first focused on AMT security and proposed ways other physical memory has to obey strict verification.
to inject code into AMT to make ME perform bootkit However, the C language used to implement the UEFI
functions [29]. Kovah et al. found a channel named does not help track the regions to which a pointer has
SOL (i.e., Serial-over-LAN) in AMT [25], and Mi- ever pointed. For instance, the ValidateBufferIsOut-
crosoft found the bootkit instance, which utilized the sideSmram is used to judge whether a pointer points
SOL to bypass the OS-level firewall to communicate to a memory buffer outside the SMRAM range. But it
with the C&C servers [92]. Nowadays, chips on the can not accurately detect the situation that the pointer
board independently of the main CPU are common, to be judged points to a structure that has a field as a
such as Intel ME, EC (i.e., Embedded Controller), pointer to another buffer outside SMRAM. A vulner-

China Communications 19
ability numbered CVE-2021-26943 on ASUS laptops anism clearer to bootkit developers. Intel has intro-
[99] showed that an attacker could repeatedly trigger duced a mechanism named LockBox to protect the S3
an error code (i.e., 0x7) to construct a physical address boot script from any modifications outside of SMM
0x07070707 in SMRAM, and then put the malicious [102]. However, SMM itself also has many vulner-
code in address 0x07070707. SMM would consume abilities for attackers to utilize, which makes the S3
the data outside the SMRAM, thus causing arbitrary boot script still vulnerable.
code execution in SMM. The privilege escalation from
root (i.e., ring 0) to SMM (i.e., ring -2) has become 5.3 Evaluation for Related Security Mecha-
one of the most critical attack surfaces for bootkits in nisms in UEFI
SMM. ThinkPwn [100] was a typical bootkit that ma-
nipulated the data consumed by SMI handlers to es- 5.3.1 UEFI Firmware Protections (D4 )
calate privileges in a similar way. Yin et al. [101] The UEFI firmware protection is the basic security
proposed a protocol-centric static analysis method and guarantee against UEFI bootkits for PCs. Unlike in-
found 36 SMM privilege escalation vulnerabilities. It fection phase in legacy BIOS which has few special-
means that vulnerabilities in SMM remain an exten- ized security mechanisms to protect physical disks
sive and severe issue for bootkit attacks. from tampering, UEFI firmware is protected by spe-
cial registers and security mechanisms. Moreover,
5.2.2 Replace the S3 Boot Script (A12 ) breaking through UEFI firmware protections is the
first and inevitable step in a successful bootkits at-
The S3 resume process has been a vital attack surface
tack. In Section 5.1.2, we introduced two ways to
since Wojtczuk et al. showed the vulnerability of the
break through UEFI firmware protections. However,
S3 boot script (i.e., CVE-2014-8274) in 2014 [23]. S3
attack and defense techniques are always in a process
boot script is a series of opcodes interpreted by the
of co-evolution. After the disclosure of Lojax, security
boot script executor firmware module at the end of PEI
mechanisms against this type of race condition vulner-
to be used by BIOS to wake from sleep mode [102].
ability were also proposed. To prevent BIOS control
The platform can skip the DXE to reduce the time to
bit protection attack, the firmware manufacturers only
wake from the S3 sleep state by the S3 boot script [21].
need to configure the SMM BWP properly, which en-
Since the S3 boot script is stored in memory and can
sures that the BIOS region is writable only if all the
be executed before many security mechanisms are ac-
cores are running in SMM (i.e., System Management
tivated, locating and replacing the memory of the S3
Mode) and BIOSWE is set to 1. However, Matrosov et
boot script is feasible for bootkits. One approach pro-
al. [74] have shown that many manufacturers did not
posed by Wojtczuk et al. to execute arbitrary code in
configure the BIOS CNTL correctly due to the con-
an S3 boot script is as follows [22]:
sideration of convenience.
• Get the S3 boot script pointer from the UEFI
As for attacks to the process of firmware update,
variable AcpiGlobalVariable and copy the origi-
Intel proposed BIOS Guard, which is a BIOS flash
nal UEFI boot script table to restore the original
update hardening technology [125]. BIOS Guard
state after the attack.
changes the situation that SMM controls the MSR
• Use the modification dispatch code (i,e,m Model-Specific Register) and the flash updates.
EFI BOOT SCRIPT DISPATCH OPCODE Instead, it creates a small trust boundary for the
to add the record into the UEFI boot script table firmware update process in the flash. BIOS Guard
as the first boot script opcode command, which will replace SMI handlers to control MSR for read and
points to the malicious code to execute. write operations on SPI flash by an Intel-signed and
• Wait or trigger the S3 sleep mode to execute the hardware-verified BIOS Guard Authenticated Code
malicious boot script by other malicious code in Module. Simultaneously, update authentication is also
the OS. performed by BIOS Guard module. So Intel BIOS
The MdeModulePkg/Library/PiDxeS3BootScriptLib/, Guard greatly reduces the attack surface for firmware
which is also open-source in EDK II shows the imple- update process attacks and provides a much more de-
mentation of the S3 resume. That makes the mech- fensible environment from which to perform flash op-

20 China Communications
 Table 3. Summary of bootkits and samples with bootkits techniques.

Name Time Type Attack vector Discovered way

WinCIH [103] 1998 Legacy BIOS Attack BIOS from OS In the wild
eEye BootRoot [9] 2005 Legacy BIOS Attack MBR Proof of concept
APCI rootkit [104] 2006 Legacy BIOS Attack ACPI firmware Proof of concept
Mebroot [51] 2007 Legacy BIOS Attack MBR In the wild
Vbootkit [50] 2007 Legacy BIOS Abuse Windows Vista Proof of concept
PCI OptRom rootkit [74] 2007 Legacy BIOS Attack Option ROM for PCI Proof of concept
IceLord [105] 2007 Legacy BIOS Attack BIOS from OS Proof of concept
SMM rootkit [18] 2007 Legacy BIOS Attack SMM Proof of concept
Mebratix [106] 2008 Legacy BIOS Attack MBR In the wild
SMM rootkit 2 [19] 2008 Legacy BIOS Control USB devices by SMM Proof of concept
Vbootkit2 x64 [39] 2009 Legacy BIOS Bypass the digital signature checks on Windows 7 Proof of concept
Stoned [38] 2009 Legacy BIOS Attack MBR Proof of concept
BIOS patching [107] 2009 Legacy BIOS Attack BIOS from OS Proof of concept
Computrace [35] 2009 Legacy BIOS Modify BIOS for business purposes Commercial software
TDL4 [7] 2010 Legacy BIOS Attack MBR In the wild
Stoned x64 [15] 2011 Legacy BIOS Attack MBR Proof of concept
Olmasco [43] 2011 Legacy BIOS Modify MBR partition table In the wild
Evil Core [108] 2011 Legacy BIOS Use SMP to boot into protected mode Proof of concept
Rovnix [49] 2011 Legacy BIOS Compress and tamper with the IPL In the wild
Mebromi [109] 2011 Legacy BIOS Attack BIOS similarly to IceLord In the wild
VGA [110] 2012 Legacy BIOS Install itself in the VGA firmware Proof of concept
Gapz [41] 2012 Legacy BIOS Attack VBR In the wild
Rakshasa [111] 2012 Legacy BIOS Attack BIOS Proof of concept
Kon-Boot [36] 2012 UEFI Bypass Secure Boot and Windows password authentication Commercial software
DreamBoot [12] 2013 UEFI Hook bootloaders in UEFI Proof of concept
BadBIOS [112] 2013 Legacy BIOS Attack BIOS In the wild
X86 Memory Bootkit [113] 2013 UEFI Exploit all available memory above 4 GB by PAE Proof of concept
PoC by Bulygin et al. [75] 2013 UEFI Bypass Seure Boot on Windows 8 Proof of concept
PoC by Zaddach et al. [114] 2013 UEFI Hook the firmware for hard-drive operation Proof of concept
OldBoot [115] 2014 Android Attack the update process In the wild
Darth Venamis [23] 2014 UEFI Attack S3 boot script Proof of concept
Thunderstrike [13] 2014 UEFI Attack the thunderbolt port with a malicious Option ROM Proof of concept
LightEater [116] 2015 UEFI Expose sensitive information from firmware memory Proof of concept
Vector EDK [117] 2015 UEFI Implant rkloader by inserting an USB device Partially leaked source code
SmmBackdoor [14] 2015 UEFI Attack SMM Proof of concept
Thunderstrike 2 [118] 2015 UEFI Attack S3 resume and thunderbolt port simultaneously Proof of concept
Memory Sinkhole [119] 2015 UEFI Utilize the APIC to attack SMM Proof of concept
PoC by Gorobets et al. [20] 2015 UEFI Expose memory regions protected by VMM Proof of concept
Safeguarding [120] 2016 UEFI Rewrite the FPF and control the RoT Proof of concept
PeiBackdoor [121] 2016 UEFI Execute malicious code in PEI Proof of concept
ThinkPwn [100] 2016 UEFI Utilize a privilege escalation vulnerability in SMM Proof of concept
AMT case by PLATINUM [92] 2017 UEFI Utilize Intel AMT SOL for communication In the wild
LoJax [11] 2018 UEFI Utilize the Speed Racer to insert a DXE module In the wild
MosaicRegressor [94] 2020 UEFI Utilize a DXE driver to download payload from C&C servers In the wild
FinSpy [2] 2021 UEFI Modify OS bootloader in ESP to load unsigned drivers In the wild
Netfilter [122] 2021 UEFI Communicate with C&C servers as a Microsoft signed driver In the wild
ESPecter [1] 2021 UEFI Replace bootmgfw.efi in ESP and decrypt malicious code dynamically In the wild
MoonBounce [3] 2022 UEFI Utilize DXE implant to hook three critical function In the wild
CosmicStrand [123] 2022 UEFI Patch bootgmr to load malicious kernel driver In the wild
Black Lotus [124] 2022 UEFI Disable HVCI and Windows Defender to load unsigned drivers In the wild

China Communications 21
erations. However, again, Matrosov et al. [79] have Boot Guard creates a more secure chain of trust. The
shown that many OEM vendors did not enable this RoT in dedicated hardware ensures the integrity of Se-
technology due to performance or cost issues. It means cure Boot. Meanwhile, Secure Boot ensures the in-
that bootkits still have the potential to break through tegrity of UEFI firmware. In theory, this set of secu-
firmware protections on many older machines. rity mechanisms can effectively resist bootkit attacks if
fully implemented. However, Section 5.1.5 has shown
5.3.2 UEFI Secure Boot (D5 ) that there are still many flaws in the OEM vendor’s
Boot Guard implementation, which leaves Boot Guard
There is another difference in infection phase between
still vulnerable to bootkit attacks.
legacy BIOS and UEFI, which is that even bootkit has
successfully broken through the firmware protections
and injected malicious code into UEFI firmware, it VI. SUMMARY AND FUTURE FOR
still could not be executed directly because of UEFI BOOTKITS
Secure Boot. In order to build a trusted Boot chain
during UEFI boot process, Secure Boot first chooses 6.1 Summary of the Co-evolution of Bootkits
a security anchor as RoT (i.e., PI firmware, in most and Security Mechanisms
cases), and then ensures that each UEFI stage is vali-
Table 3 shows the classification and evolution of clas-
dated by the previous stage before it is executed [32].
sic bootkits according to the time they were exposed.
So if bootkits want to succeed in gaining control at
Some of them are not ”standard” bootkits, but the
UEFI firmware level, they have to bypass Secure Boot
techniques they utilized and the intent their behaviors
integrity check besides successfully writing data to the
showed are similar to typical bootkits. We also illus-
SPI flash. As mentioned in Section 5.1.3, the security
trate all the attack and defense techniques discussed
of UEFI Secure Boot largely depends on the integrity
in Section IV and Section V by two axes in Figure 1.
of its key data structures (i.e., db, dbx and RoT). Both
From the perspective of bootkit attack techniques, the
attacking the key data structures of Secure Boot and
attack surface has been getting wider on boot mode
patching routines are used to verify signatures can by-
axis, and the attack position has been getting deeper
pass Secure Boot. Therefore, relying on Secure Boot
in the opposite direction of the attack phase axis. In
alone can not protect UEFI firmware from bootkit at-
legacy BIOS, techniques in infection phase were rel-
tacks. On the other hand, Sanwald et al. have shown
atively single. Many sophistical bootkits developers
that more than 50% of the OEMs specify not to enable
focused on the techniques in boot phase to bypass
Secure Boot, disable certain functionality, or crypto-
the OS-level security mechanisms. In UEFI, many
graphic secrets, and around 30% of the OEMs do not
techniques in boot phase in legacy BIOS were still
explicitly define a countermeasure in case the authen-
adopted. However, changes in boot process and en-
tication fails [33]. This phenomenon also facilitates
hancements to firmware security have forced bootkits
bootkit attacks.
developers to concentrate on techniques in infection
phase. In general, the transition from legacy BIOS to
5.3.3 Intel Boot Guard (D6 )
UEFI not only brings about an overall improvement of
Section 5.3.2 has shown the original RoT of Secure PC, including security, but also brings a larger attack
Boot is not secure enough. In most cases, hardware surface to bootkits (e.g., ESP, Intel ME, Secure Boot,
is more reliable than software. Intel proposed Boot and Boot Guard).
Guard to shift the RoT to dedicated hardware to ensure As for the perspective of security mechanisms, from
the integrity of UEFI Secure Boot. Boot Guard utilizes the ELAM against rootkits to the kernel-mode code
the CPU mirocode and signed ACM to perform Veri- signing policy against legacy BIOS bootkits, the secu-
fied Boot and Measured Boot. The former checks if rity mechanisms are also evolving at the same time.
the PI firmware has been altered or modified. The lat- With the prevalence of UEFI, the bootkits have turned
ter computes cryptographic hashes of key data struc- their attention to UEFI firmware attacks since 2013.
tures and stores them in TPM PCRs (i.e., Trusted Plat- The firmware and hardware manufacturers also intro-
form Module Platform Configuration Registers) [76]. duced some techniques to protect the boot process

22 China Communications
(e.g., Intel Secure Boot and Boot Guard). On the Numbers of firmware-related CVEs Numbers of all CVEs

other hand, the attack surface is wider but attacking 45000

Number
500 40000

is harder since manufacturers have introduced more 400

35000
30000

and more complicated security mechanisms to pro- 300 25000

20000

tect firmware. The RoT in Secure Boot was in DXE 200 15000
10000
100
when it was first proposed by Intel. It was unsafe be- 0
5000
0

cause DXE was a relatively late phase in the UEFI 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021

Year
boot process. The Verified and Measured Boot that
(a) The numbers of firmware-related CVEs.
was later introduced made the RoT shift to the hard-
ware, which made bootkits hard to tamper with [76]. Numbers of BIOS-related CVEs Numbers of all CVEs

Due to the long firmware supply chain, manufacturers 45000

Number
50 40000

sometimes have a disconnect (i.e., some OEM man- 40

35000
30000

ufacturers simplify or misconfigure the parameters of 30 25000

20000

security mechanisms for performance or convenience) 20 15000

10000
10
in the implementation of security mechanisms [126]. 5000
0 0
Simultaneously, more advanced security mechanisms 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021
Year
such as VSM [67], STM [127], etc., have not been
(b) The numbers of BIOS-related CVEs.
widely used due to performance overhead or complex
configuration. So the security of UEFI firmware still Numbers of UEFI-related CVEs Numbers of all CVEs

faces many challenges today. Before LoJax was dis- 45000

Number

18
40000
16
covered in 2018, no typical UEFI bootkit had been 14
35000
30000
12
found in the wild. Most UEFI bootkits were presented 10 25000
20000
by researchers as PoC for research, and some of them 8
6 15000

did not implement the whole function of a bootkit but 4

2
10000
5000

just proved an attack approach was feasible. However, 0

2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021
0

Year
the emergence of LoJax and the later discovered UEFI
bootkits meant that UEFI bootkits have been lurking (c) The numbers of UEFI-related CVEs.
in the wild for many years, which shows that bootkit
Numbers of Windows kernel-related CVEs Numbers of all CVEs
is still a massive threat in the wild.
Number

140 45000
40000
120
35000
100
30000
80 25000

6.2 Future Directions for Bootkits 60

40
20000
15000
10000
20
5000
In recent years, as major manufacturers have gradually 0
2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021
0

deepened their understanding of security, the security Year

of the boot process has been gradually improved. As a (d) The numbers of Windows kernel-related CVEs.
result, it is more and more difficult to implant a bootkit
Numbers of Linux kernel-related CVEs Numbers of all CVEs
on a standard PC directly. More often, it is necessary
Number

600 45000

to rely on the latest underlying software vulnerabili- 500

40000
35000

ties to complete the tampering of the firmware. Simul- 400 30000

25000
300
taneously, the development of technology like edge- 20000
200 15000
assisted IoT [128] makes the embedded IoT device 100
10000
5000
more and more valuable for attackers to invade. And 0
2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021
0

some commercial software, such as Kon-Boot that uti- Year

lize bootkit techniques has also been iterated with the (e) The numbers of Linux kernel-related CVEs.
update of the operating systems. So we classify the
Figure 7. The numbers of CVEs with keywords ”firmware”,
future direction of development for bootkits into three
”BIOS”, ”UEFI”, ”Windows kernel” and ”Linux kernel”.
categories:

China Communications 23
 With the latest vulnerability. Unlike the time flash protections or Secure Boot directly [130], which
when the system was designed without safety in mind has been identified by Lenovo as vulnerabilities in its
(e.g., attackers could tamper with the bootstrap code products. This is also a factor that may have led to a
by directly programming without utilizing any vulner- large number of bootkit attacks.
ability in the legacy BIOS stage), the firmware sys- With different platform. Secure Boot on PC has
tems and operating systems have been much harder to been widely adopted these years, while there is still
undermine since the popularity of UEFI. As we men- a lack of protection on embedded systems due to
tioned above, the difficulty of implanting bootkits in the limitation of hardware resources. On the other
a PC is increasing due to major security companies hand, the number of connected devices, from appli-
having paid more and more attention to the security of ances to smart homes, has increased dramatically with
underlying software. However, according to Eclyp- the prevalence of IoT while also increasing the poten-
sium’s report [129], there has been a significant in- tial profit in IoT attacks. The cropped kernel, rela-
crease in firmware vulnerabilities from 2016 to 2019. tively simple security mechanism, and limited hard-
Furthermore, it reported that 80% of enterprises had ware resources make bootkit implantation on IoT de-
experienced at least one firmware exploits in the last vices relatively easy. There are already existing cap-
two years. The number of vulnerabilities disclosed can tured rootkits for IoT devices that are used in APT at-
partly reflect the popularity of a security research field. tacks [131]. It is possible that these mechanisms could
As shown in Figure 7, we collect the numbers of CVEs involve bootkits, or maybe there are already existing
with keywords ”firmware,” ”BIOS,” ”UEFI,” ”Win- uncaptured bootkits. Moreover, the benefit of under-
dows kernel,” and ”Linux kernel” from 2005 to 2021. mining IoT devices with bootkits is excellent for at-
For comparison, we also collected the total number of tackers. Cisco predicted that the data generated by
CVEs disclosed each year. We chose 2005 to start be- IoT devices would reach 507.5 zettabytes per year by
cause it was the point at which the first bootkit first ap- 2019 [132], and the number is still growing up today.
peared. It is obvious that since the popularity of UEFI Once an IoT device is implanted by a bootkit, it will
in 2013, the number of underlying software (e.g., key- be controlled by the attacker for a long time. The com-
words ”firmware,” ”BIOS,” and ”UEFI”) related vul- munication module of a bootkit enables the attacker to
nerabilities began to rise sharply. From Table 3, we monitor or even manipulate the sensitive physical data
can see that it was just the time point when UEFI of users. Microsoft also introduced the Windows 10
bootkits started popping up. It is very likely that some IoT edition to support the IoT devices in UEFI [133],
of these vulnerabilities have been used in bootkit at- but it is a cropped edition and has fewer security fea-
tacks. Simultaneously, we cross-referenced the num- tures. Therefore, from a multi-faceted perspective, we
bers of vulnerability disclosures in other mainstream believe that IoT will be the next main battlefield for
security research areas (i.e., OS kernel security). Fig- bootkits.
ure 7d and Figure 7e show the trend in the number With different purpose. Different from some
of vulnerabilities disclosed for Windows kernel and bootkits that intend to perform malicious behaviors
Linux kernel over the past decade. In the context of or even APT attacks in target systems, some intelli-
a continued rise in the number of CVEs disclosures gent software has utilized bootkit techniques to pro-
overall (i.e., every black line in Figure 7), from the per- vide convenience to users. Computrace, also known
spective of the number of CVEs, research interest in as LoJack [35], was a proprietary laptop theft recov-
OS kernels peaked in 2017 but has since declined. In ery software developed by Absolute Software. It was
contrast, the number of CVEs in the field of underlying legitimately installed in the laptop’s firmware and uti-
software security has continued to rise in recent years, lized the bootkit techniques in boot phase to run itself
indicating that underlying software security is becom- every time system booted. LoJax, found in 2018, was
ing a research hotspot. Besides, some OEM vendors the malicious variant of LoJack developed by Sednit.
might deliberately leave backdoors in the firmware for But before LoJax was discovered, LoJack had been
debugging or other non-malicious purposes. Martin sold as commercial software for many years. Another
found that ChgBootDxeHook and SecureBackDoor in typical instance is Kon-Boot. We conducted a reverse
Lenovo laptops firmware could be used to disable SPI analysis of its implementation mechanism and found

24 China Communications
that it has no malicious behavior beyond its declara- and bootkit threat issues.
tion. Kon-Boot is executed by choosing to boot from
a USB flash disk in the UEFI shell. Then it sets hooks
ACKNOWLEDGEMENT
and directly loads kon64.bin into memory and exe-
cutes it to bypass the password authentication, which This work was supported by NSFC under Grant
is a typical bootkit technique in boot phase. Although 62172308, Grant U1626107, Grant 61972297 and
Microsoft regarded Kon-Boot as a virus, Kon-Boot is Grant 62172144.
still sold publicly and legally and even supports the
latest Windows 11 [134]. We believe that it will be a
References
trend to apply some bootkit techniques to legitimate
commercial software for profit, and there will be more [1] Uefi threats moving to the esp: Introducing
non-malicious bootkits like Kon-Boot in the future. especter bootkit[EB/OL]. 2021. https://www.
welivesecurity.com/2021/10/05/uefi-threats-m
VII. CONCLUSION oving-esp-introducing-especter-bootkit/.
[2] Finspy: Unseen findings[EB/OL]. 2021.
This work comprehensively reviewed the techniques https://securelist.com/finspy-unseen-findings/
that bootkits used to hijack the control and execute 104322/.
malicious code before OS was in place. We pro- [3] Moonbounce: the dark side of uefi
posed two axes to classify bootkit techniques system- firmware[EB/OL]. 2022. https:
atically. To this end, we first introduced two main- //securelist.com/moonbounce-the-dark-sid
stream boot processes. Further, we summarized an at- e-of-uefi-firmware/105468/.
tack model based on many classic bootkits instances [4] KUZMINYKH I, YEVDOKYMENKO M.
and discussed the functions of each component. We Analysis of security of rootkit detection meth-
classified bootkits into two modes (i.e., legacy BIOS ods[C/OL]//2019 IEEE International Confer-
and UEFI) on the boot mode axis. In each category, ence on Advanced Trends in Information The-
we also divided the attack techniques into two phases ory (ATIT). Kyiv, Ukraine: IEEE, 2019: 196-
(i.e., infection phase and boot phase) on the attack 199. DOI: 10.1109/ATIT49449.2019.9030428.
phase axis. For bootkits in legacy BIOS, we evalu- [5] LI X, WEN Y, HUANG M H, et al.
ated the LPE techniques, the four approaches bootk- An overview of bootkit attacking approaches
its utilized to hijack the control before OS, the hook [C/OL]//2011 Seventh International Conference
methods, the self-defense techniques, and the security on Mobile Ad-hoc and Sensor Networks. 2011:
mechanisms to counter these attacks. As for bootkits 428-431. DOI: 10.1109/MSN.2011.19.
in the UEFI stage, we introduced the security mecha- [6] GAO H, LI Q, ZHU Y, et al. Research on the
nisms as well as the corresponding attack techniques working mechanism of bootkit[C]//2012 8th In-
in the complicated firmware system. We analyzed the ternational Conference on Information Science
co-evolution of bootkits and security mechanisms and and Digital Content Technology (ICIDT2012):
concluded that it was harder and harder for bootkits volume 3. IEEE, 2012: 476-479.
to compromise the boot process directly in UEFI. Fi- [7] RODIONOV E, MATROSOV A. The evolution
nally, we summarized and proposed the future direc- of tdl: Conquering x64[J]. ESET, June, 2011.
tion for bootkits based on the trend of firmware vulner- [8] MATROSOV A, RODIONOV E.
abilities in recent years, the potential profit in attack- Defeating x64: Modern trends of
ing the embedded systems and IoT devices, and the kernel-mode rootkits[J]. 2011-10-21).
legal as well as non-malicious usage of bootkit tech- http://go.eset.com/us/resources/white-
niques. We hope that this survey could help the com- papers/Ekoparty2011 preso.pdf, 2011.
munity focus on bootkits, which have been an enor- [9] SOEDER D, PERMEH R. Eeye bootroot[J].
mous threat applied in firmware and OS security, and Black Hat USA, 2005.
even APT attacks. Moreover, prioritize research ef- [10] ABD EL-AZIZ M, TAREK A, ELDEFRAWY
forts to address the emerging firmware security issues A. Introduction to uefi technology[Z]. 2013.

China Communications 25
[11] Lojax - first uefi rootkit found in the wild cour- CanSecWest Conf.(CanSecWest). 2015.
tesy of the sednit group[EB/OL]. Nov 2018. [24] PÉRIGAUD F, GAZET A, CZARNY J. Sub-
https://www.welivesecurity.com/wp-content/u verting your server through its bmc: the hpe ilo4
ploads/2018/09/ESET-LoJax.pdf. case[J]. Recon Brussels, 2018.
[12] KACZMAREK S. Uefi and dreamboot[C]// [25] KOVAH X, KALLENBERG C. How many mil-
Hack in the Box Security Conference, Kuala lion bioses would you like to infect?[J]. Van-
Lumpur, Malasia. 2013. couver, BC, Canada). CanSecWest, 2015.
[13] HUDSON T, RUDOLPH L. Thunderstrike: Efi [26] EVDOKIMOV D, ERMOLOV A, MALYUTIN
firmware bootkits for apple macbooks[C/OL]// M. Intel amt stealth breakthrough[J]. Black Hat,
NAOR D, HEISER G, KEIDAR I. Proceedings 2017.
of the 8th ACM International Systems and Stor- [27] SKOCHINSKY I. Intel me secrets[J]. Code
age Conference, SYSTOR 2015, Haifa, Israel, Blue, 2014.
May 26-28, 2015. ACM, 2015: 15:1-15:10. [28] ERMOLOV M, GORYACHY M. How to hack
DOI: 10.1145/2757667.2757673. a turned-off computer, or running unsigned
[14] OLEKSIUK D. Building reliable smm back- code in intel management engine[J]. Black Hat
door for uefi based platforms[J]. URL: Europe, 2017.
http://blog. cr4. sh/2015/07/building-reliable- [29] TERESHKIN A, WOJTCZUK R. Introducing
smm-backdoorfor-uefi. html, 2015. ring-3 rootkits[J]. Black Hat USA, 2009.
[15] RODIONOV D E, MATROSOV A, HARLEY [30] OGOLYUK A, SHEGLOV A, SHEGLOV K.
D. Bootkits: Past, present and future[C]//VB Uefi bios and intel management engine attack
Conference. Citeseer, 2014. vectors and vulnerabilities[Z].
[16] MATROSOV A, RODIONOV E, BRATUS S. [31] DIETRICH K, WINTER J. Secure boot revis-
Rootkits and bootkits: Reversing modern mal- ited[C]//2008 The 9th International Conference
ware and next generation threats[M]. No Starch for Young Computer Scientists. IEEE, 2008:
Press, 2019. 2360-2365.
[17] NIKOLOV N. Research firmware update over [32] WILKINS R, RICHARDSON B. Uefi se-
the air from the cloud[C]//2018 IEEE XXVII cure boot in modern computer security solu-
International Scientific Conference Electronics- tions[C]//UEFI forum. 2013.
ET. IEEE, 2018: 1-4. [33] SANWALD S, STÖTTINGER M, KANETI L,
[18] BSDAEMON C. D0nand0n. system manage- et al. Secure boot revisited: Challenges for se-
ment mode hack: Using smm for other purposes cure implementations in the automotive domain
[J]. Phrack Magazine, 2008, 12: 65. [J]. SAE Int. J. Transp. Cyber. & Privacy, 2020.
[19] EMBLETON S, SPARKS S, ZOU C C. Smm [34] GRILL B, BACS A, PLATZER C, et al. ”nice
rootkit: A new breed of os independent mal- boots!” - a large-scale analysis of bootkits and
ware[J]. Security and Communication Net- new ways to stop them[C/OL]//ALMGREN M,
works, 2013, 6(12): 1590-1605. GULISANO V, MAGGI F. Lecture Notes in
[20] GOROBETS M, BAZHANIUK O, MA- Computer Science: volume 9148 Detection
TROSOV A, et al. Attacking hypervisors via of Intrusions and Malware, and Vulnerability
firmware and hardware[J]. Black Hat USA, Assessment - 12th International Conference,
2015. DIMVA 2015, Milan, Italy, July 9-10, 2015,
[21] YAO J, ZIMMER V. S3 resume[M]//Building Proceedings. Springer, 2015: 25-45. DOI:
Secure Firmware. Springer, 2020: 313-333. 10.1007/978-3-319-20550-2 2.
[22] WOJTCZUK R, KALLENBERG C. Attacking [35] Computrace by absolute software now sup-
uefi boot script[C]//31st Chaos Communication ported in firmware of getac computers[EB/OL].
Congress (31C3). 2014. 2009. https://www.absolute.com/company/pre
[23] WOJTCZUK R, KALLENBERG C. Attacks ss-releases/2009/computrace-by-absolute-sof
on uefi security, inspired by darth venamis’s tware-now-supported-in-firmware-of-getac-c
misery and speed racer[C]//Proc. 15th Annu. omputers/.

26 China Communications
 [36] Forgot windows password? bypass it with kon- [51] FLORIO E, KASSLIN K. Your computer is
boot![EB/OL]. 2022. https://kon-boot.com/. now stoned (... again!)[J]. Virus Bulletin, April,
[37] Edk ii build specification[EB/OL]. 2021. 2008.
https://edk2-docs.gitbook.io/edk-ii-build-speci [52] MATROSOV A, RODIONOV E. Festi botnet
fication. analysis and investigation[C]//Proc. 15th AVAR
[38] KLEISSNER P. Stoned bootkit[J]. Black Hat Conf. 2011: 12-14.
USA, 2009: 5-7. [53] WÜCHNER T, OCHOA M, GOLAGHA M,
[39] KUMAR N, KUMAR V. Vbootkit 2.0- et al. Malflow: Identification of c&c servers
attacking windows 7 via boot sectors[C]// through host-based data flow profiling[C]//
Proceedings of the Hack In The Box Confer- Proceedings of the 31st Annual ACM Sympo-
ence (HITBSecConf). 2009. sium on Applied Computing. 2016: 2087-2094.
[40] GRILL B. Bootkits revisited: Detecting, [54] Cve-2010-4398[EB/OL]. 2010.
analysing and mitigating bootkit threats[D]. https://cve.mitre.org/cgi-bin/cvename.cgi
Wien, 2016. ?name=CVE-2010-4398.
[41] RODIONOV E, MATROSOV A. Mind [55] Cve-2011-3402[EB/OL]. 2011.
the gapz: The most complex bootkit https://cve.mitre.org/cgi-bin/cvename.cgi
ever analyzed?[EB/OL]. 2013. ?name=CVE-2011-3402.
https://www.welivesecurity.com/wp-content/u [56] HUANG C, HAN X, YU G. Lpet – mining ms-
ploads/2013/04/gapz-bootkit-whitepaper.pdf. windows software privilege escalation vulnera-
[42] DOLMANS R, KATZ W. Rp1: Carberp mal- bilities by monitoring interactive behavior[C]//
ware analysis[Z]. 2013. Proceedings of the 2020 ACM SIGSAC Confer-
[43] MATROSOV A. Olmasco bootkit: Next circle ence on Computer and Communications Secu-
of tdl4 evolution (or not?).[EB/OL]. 2012. rity. 2020: 2089-2091.
https://www.welivesecurity.com/2012/10/18/ol [57] O’LEARY M. Privilege escalation in linux[M]//
masco-bootkit-next-circle-of-tdl4-evolution-o Cyber Operations. Springer, 2019: 419-453.
r-not-2/. [58] HUTCHINSON S, VAROL C. A survey of priv-
[44] BAEZNER M, ROBIN P. Stuxnet[R]. ETH ilege escalation detection in android[C]//2018
Zurich, 2017. 9th IEEE Annual Ubiquitous Computing, Elec-
[45] KALLENBERG C, WOJTCZUK R. Speed tronics & Mobile Communication Conference
racer: Exploiting an intel flash protection race (UEMCON). IEEE, 2018: 726-731.
condition[J]. Bromium Labs (January 2015), [59] KUJANPÄÄ K, VICTOR W, ILIN A. Au-
2015. tomating privilege escalation with deep rein-
[46] ALZAIDI M. The study of ssdt hook through forcement learning[C]//Proceedings of the 14th
comparative analysis between live response and ACM Workshop on Artificial Intelligence and
memory image[Z]. 2012. Security. 2021: 157-168.
[47] WANG Y, GU D, LI W, et al. Virus analysis [60] PARÓCZI Z. Lz based compression benchmark
on idt hooks of rootkits trojan[C]//2009 Interna- on pe files[J]. Acta Cybernetica, 2019, 24(1):
tional Symposium on Information Engineering 121-129.
and Electronic Commerce. IEEE, 2009: 224- [61] BRANCO R R, BARBOSA G N, NETO
228. P D. Scientific but not academical overview of
[48] RODIONOV E, MATROSOV A. Defeating malware anti-debugging, anti-disassembly and
anti-forensics in contemporary complex threats anti-vm technologies[J]. Black Hat, 2012, 1: 1-
[M]//ESET. 2012. 27.
[49] MATROSOV A. Eset-rovnix bootkit frame- [62] MADURANGA K. Investigate windows man-
work updated[Z]. 2012. agement instrumentation (wmi) attacks in win-
[50] KUMAR N, KUMAR V. Vbootkit: Compro- dows operating systems[D]. 2017.
mising windows vista security[J]. Black Hat [63] ZHANG B. Research summary of anti-
Europe, 2007, 2007. debugging technology[C]//Journal of Physics:

China Communications 27
 Conference Series: volume 1744. IOP Publish- X, et al. Setup for failure: Defeating secure
ing, 2021: 042186. boot[C]//The Symposium on Security for Asia
[64] MILENKOSKI A. Elam: The windows de- Network (SyScan)(April 2014). 2014.
fender elam driver[D]. ERNW Enno Rey Net- [79] MATROSOV A. Betraying the bios: Where the
zwerke GmbH, 2019. guardians of the bios are failing[J]. Black Hat
[65] KORKIN I. Hypervisor-based active data pro- USA 2017, 2017.
tection for integrity and confidentiality of dy- [80] ERMOLOV M, GORYACHY M. Intel visa:
namically allocated memory in windows kernel Through the rabbit hole[J]. Black Hat Asia,
[A]. 2018. 2019.
[66] KESSEM L. The necurs botnet: A pandora’s [81] WOLFF E D, GROWLEY K M, GRUDEN
box of malicious spam[Z]. 2019. M G. Navigating the solarwinds supply chain
[67] MILENKOSKI A, PHILLIPS D. Virtual secure attack[M]. HeinOnline, 2021.
mode: Architecture overview[D]. ERNW Enno [82] ROHRET D, WILLMANN J. Supply chain at-
Rey Netzwerke GmbH, 2019. tacks: Basic input output systems (bios), mux
[68] COSTAN V, DEVADAS S. Intel sgx explained. multiplexers and field programmable gate ar-
[J]. IACR Cryptol. ePrint Arch., 2016, 2016 rays (fpga)[C]//International Conference on Cy-
(86): 1-118. ber Warfare and Security. Academic Confer-
[69] FUKAI T, TAKEKOSHI S, AZUMA K, et al. ences International Limited, 2012: 254.
Bmcarmor: A hardware protection scheme for [83] HEINBOCKEL W J, LADERMAN E R, SER-
bare-metal clouds[C]//2017 IEEE International RAO G J. Supply chain attacks and resiliency
Conference on Cloud Computing Technology mitigations[J]. The MITRE Corporation, 2017:
and Science (CloudCom). IEEE, 2017: 322- 1-30.
330. [84] VU D L, PASHCHENKO I, MASSACCI F,
[70] YAO J, ZIMMER V J, ZENG S. A tour beyond et al. Towards using source code repositories
bios: Using iommu for dma protection in uefi to identify software supply chain attacks[C]//
firmware[Z]. 2017. Proceedings of the 2020 ACM SIGSAC Con-
[71] YAO J. Smm protection in edk ii[J]. UEFI ference on Computer and Communications Se-
Plugfest 2017, 2017. curity. 2020: 2093-2095.
[72] WOJTCZUK R, TERESHKIN A. Attacking in- [85] YEBOAH-OFORI A, ISLAM S. Cyber security
tel bios[J]. BlackHat, Las Vegas, USA, 2009. threat modeling for supply chain organizational
[73] BASHUN V, SERGEEV A, MINCHENKOV V, environments[J]. Future Internet, 2019, 11(3):
et al. Too young to be secure: Analysis of uefi 63.
threats and vulnerabilities[C/OL]//14th Confer- [86] IBDAH D, LACHTAR N, ELKHAIL A A, et al.
ence of Open Innovation Association FRUCT. Dark firmware: A systematic approach to ex-
Espoo, Finland: IEEE, 2013: 16-24. DOI: ploring application security risks in the pres-
10.1109/FRUCT.2013.6737940. ence of untrusted firmware[C]//23rd Interna-
[74] MATROSOV A, RODIONOV E. Uefi firmware tional Symposium on Research in Attacks, In-
rootkits: Myths and reality[J]. Black Hat Asia, trusions and Defenses (RAID 2020). 2020:
2017. 413-426.
[75] BULYGIN Y, FURTAK A, BAZHANIUK O. A [87] A deeper uefi dive into moonbounce[EB/OL].
tale of one software bypass of windows 8 secure 2022. https://www.binarly.io/posts/A deeper
boot[J]. Black Hat USA, 2013. UEFI dive into MoonBounce/index.html.
[76] YAO J, ZIMMER V. Trusted boot[M]//Building [88] ZHOU L, ZHANG F, XIAO J, et al. A
Secure Firmware. Springer, 2020: 197-255. coprocessor-based introspection framework via
[77] BULYGIN Y, LOUCAIDES J, FURTAK A, intel management engine[J]. IEEE Transactions
et al. Summary of attacks against bios and se- on Dependable and Secure Computing, 2021
cure boot[J]. Proceedings of the DefCon, 2014. (01): 1-1.
[78] KALLENBERG C, CORNWELL S, KOVAH [89] Cve-2017-5705[EB/OL]. 2017.

28 China Communications
 https://cve.mitre.org/cgi-bin/cvename.cgi [103] Virus.win9x.cih[EB/OL]. 2002. https://threats.
?name=CVE-2017-5705. kaspersky.com/en/threat/Virus.Win9x.CIH/.
[90] Cve-2017-5706[EB/OL]. 2017. [104] HEASMAN J. Implementing and detecting an
https://cve.mitre.org/cgi-bin/cvename.cgi acpi bios rootkit[J]. Black Hat Federal, 2006,
?name=CVE-2017-5706. 368.
[91] Cve-2017-5707[EB/OL]. 2017. [105] YANG L K, CHEN D, MEI J, et al. Research on
https://cve.mitre.org/cgi-bin/cvename.cgi malicious behavior of firmware based on hard-
?name=CVE-2017-5707. ware resources access control[C]//Applied Me-
[92] Platinum continues to evolve, find ways chanics and Materials: volume 340. Trans Tech
to maintain invisibility[EB/OL]. 2017. Publ, 2013: 737-743.
https://www.microsoft.com/security/blog/ [106] Are mbr infections back in fash-
2017/06/07/platinum-continues-to-evolve-fin ion? (infographic)[EB/OL]. 2011.
d-ways-to-maintain-invisibility/. https://www.kashifali.ca/2011/08/are-mbr-i
[93] MATROSOV A, GAZET A. Breaking through nfections-back-in-fashion-infographic/.
another side[J]. Blackhat US 2019. [107] ORTEGA A, SACCO A, et al. Deactivate the
[94] Mosaicregressor: Lurking in the shadows of rootkit: Attacks on bios anti-theft technologies
uefi[EB/OL]. 2020. https://securelist.com/m [M]. Citeseer, 2009.
osaicregressor/98849/. [108] ETTLINGER W, VIEBÖCK S. Evil core
[95] ZHOU L, XIAO J, LEACH K, et al. Nighthawk: bootkit: Pwning multiprocessor systems
Transparent system introspection from ring- [EB/OL]. 2011. http://downloads.ninjacon.net
3[C]//European Symposium on Research in /downloads/proceedings/2011/Ettlinger Viehb
Computer Security. Springer, 2019: 217-238. oeck-Evil Core Bootkit.pdf.
[96] WANG D, DONG W Y. Attacking intel uefi by [109] GIULIANI M. Mebromi: the first
using cache poisoning[C]//Journal of Physics: bios rootkit in the wild[J]. blog.
Conference Series: volume 1187. IOP Publish- http://blog.webroot.com/2011/09/13/mebromi-
ing, 2019: 042072. thefirst-bios-rootkit-in-the-wild/. Retrieved,
[97] ZHAO L, LIE D. Is hardware more secure than 2011: 09-19.
software?[J]. IEEE Security & Privacy, 2020, [110] ECONOMOU N A, JUAREZ D. Vga
18(5): 8-17. persistent rootkit[EB/OL]. 2012.
[98] FURTAK A, BULYGIN Y, BAZHANIUK O, https://www.coresecurity.com/sites/default/fil
et al. Bios and secure boot attacks uncovered es/private-files/publications/2016/05/corelabs
[C]//The 10th ekoparty Security Conference. -ekoparty-2012-VGA Persistent Rootkit.pdf.
2014. [111] ANTHONY S. Rakshasa: The hard-
[99] Cve-2021-26943[EB/OL]. 2021. ware backdoor that china could embed
https://cve.mitre.org/cgi-bin/cvename.cgi in every computer[EB/OL]. 2012.
?name=CVE-2021-26943. https://www.extremetech.com/computing/
[100] OLEKSIUK D. Exploring and exploiting 133773-rakshasa-the-hardware-backdoor-tha
lenovo firmware secrets[M]. June, 2016. t-china-could-embed-in-every-computer.
[101] YIN J, LI M, WU W, et al. Finding [112] GOODIN D. Meet ”badbios,” the mysterious
smm privilege-escalation vulnerabilities in uefi mac and pc malware that jumps airgaps[J]. ars
firmware with protocol-centric static analysis technica, 2013, 31(10).
[C]//2022 IEEE Symposium on Security and [113] X86 memory bootkit[EB/OL]. 2013.
Privacy (SP). IEEE Computer Society, 2022: https://github.com/AaLl86/retroware/tree/mas
1570-1570. ter/MemoryBootkit.
[102] A tour beyond bios implementing s3 re- [114] ZADDACH J, KURMUS A, BALZAROTTI D,
sume with edk ii[EB/OL]. 2015. https: et al. Implementation and implications of a
//docplayer.net/32893451-A-tour-beyond-bio stealth hard-drive backdoor[C]//Proceedings of
s-implementing-s3-resume-with-edkii.html. the 29th annual computer security applications

China Communications 29
 conference. 2013: 279-288. rity in edge-assisted internet of things: Chal-
[115] XIAO Z, DONG Q. Oldboot: The first lenges and solutions[J]. Science China Infor-
bootkit on android[EB/OL]. 2014. mation Sciences, 2020, 63(12): 1-14.
http://blogs.360.cn/360mobile/2014/01/17/ [129] Nist kicks the can: Why we need to address
oldboot-the-first-bootkit-on-android/. firmware security now[EB/OL]. 2021.
[116] KOVAH X, KALLENBERG C. Are you giving https://eclypsium.com/2021/07/09/nist-kicks-t
firmware attackers a free pass?[C]//Proceedings he-can-why-we-need-to-address-firmware-sec
of the RSA Conference, San Francisco, CA, urity-now/.
USA. 2015: 20-24. [130] SMOLáR M. When ”secure” isn’t secure at
[117] Vector edk[EB/OL]. 2015. https://github.com all: High-impact uefi vulnerabilities discovered
/hackedteam/vector-edk. in lenovo consumer laptops[EB/OL]. 2022.
[118] HUDSON T, KOVAH X, KALLENBERG C. https://www.welivesecurity.com/2022/04/19/
Thunderstrike 2: Sith strike[J]. Black Hat USA when-secure-isnt-secure-uefi-vulnerabilities-l
Briefings, 2015. enovo-consumer-laptops/.
[119] DOMAS C. The memory sinkhole[J]. BlackHat [131] Drovorub linux rootkit iocs[EB/OL]. 2020.
USA, 2015. https://threatravens.com/drovorub-linux-rootk
[120] ERMOLOV A. Safeguarding rootkits: Intel it-iocs/.
boot guard[J]. Zeronights 2016. [132] NI J, LIN X, SHEN X S. Toward edge-assisted
[121] MYTKÄNIEMI A. Riskiarvio työpöytä-ja mo- internet of things: From security and efficiency
biilialustojen käynnistyslaiteohjelmistojen ky- perspectives[J]. IEEE Network, 2019, 33(2):
beruhista[Z]. 2021. 50-57.
[122] Microsoft admits to signing rootkit malware [133] Windows 10 iot[EB/OL]. 2021. https://develo
in supply-chain fiasco[EB/OL]. 2021. per.microsoft.com/en-us/windows/iot/.
https://www.bleepingcomputer.com/news/secu [134] MICROSOFT. Virtool:dos/konboot
rity/microsoft-admits-to-signing-rootkit-mal threat description[EB/OL]. 2017.
ware-in-supply-chain-fiasco/. https://www.microsoft.com/en-us/wdsi/thr
[123] GREAT. Cosmicstrand: the discovery of eats/malware-encyclopedia-description?name=
a sophisticated uefi firmware rootkit[EB/OL]. VirTool:DOS/Konboot&threatid=2147624111.
2022. https://securelist.com/cosmicstrand-uef
i-firmware-rootkit/106973/.
[124] PAGANINI P. New uefi rootkit black lotus Biographies
offered for sale at $5,000[EB/OL]. 2022. Yilin Zhou received the B.S. degree from
https://securityaffairs.co/wordpress/137252/ma Wuhan University (WHU) in 2020. He is
lware/black-lotus-uefi-rootkit.html. currently a PhD student in School of Cy-
[125] INTEL®. Intel® hardware shield - ber Science and Engineering, WHU. His
current research interests include system
below-the-os security[EB/OL]. 2021. security, cyber security, and firmware se-
https://www.intel.com/content/dam/www/cent curity.
ral-libraries/us/en/documents/below-the-os-sec
urity-white-paper.pdf.
[126] Repeatable firmware security failures: 16 Guojun Peng is currently a professor
at the School of Cyber Science and En-
high impact vulnerabilities discovered gineering, Wuhan University. He received
in hp devices[EB/OL]. 2022. https: the Ph.D. degree from Wuhan University
//www.binarly.io/posts/Repeatable Firmw in 2008. His research interests are sys-
are Security Failures 16 High Impact Vulnera tem security and trust computing. He is
bilities Discovered in HP Devices/index.html. a member of CCF and CSAC.

[127] MYERS E D. Using the intel stm for protected

execution[Z]. 2018.
[128] SHEN S, ZHANG K, ZHOU Y, et al. Secu-

30 China Communications
 Zichuan Li is currently a second-year
master student in School of Cyber Sci-
ence and Engineering, WHU. His research
interests include vulnerability detection,
vulnerability exploitation and firmware
security.

Side Liu received the B.S. degree from

Wuhan University (WHU) in 2019. He is
currently a PhD student in School of Cy-
ber Science and Engineering, WHU. His
research interests include malware analy-
sis and system security.

China Communications 31