15
CONTEMPORARY UEFI BOOTKITS

These days, it’s rare to catch a new and innovative rootkit or bootkit in the wild. Most malware threats have migrated to user mode because modern security technologies have rendered old rootkits and bootkit methods obsolete. Security methods like Microsoft’s Kernel-Mode Code Signing Policy, PatchGuard, Virtual Secure Mode (VSM), and Device Guard create limitations for kernel-mode code modifications and raise the threshold of complexity for kernel-mode rootkit development.

The move to UEFI-based systems and spread of the Secure Boot scheme have changed the landscape of bootkit development, increasing development costs for kernel-mode rootkits and bootkits. In the same way that the introduction of the Kernel-Mode Code Signing Policy drove malware developers to look for new bootkit functionality rather than find ways to evolve rootkits to bypass the code signing protections, the most recent changes have lead security researchers to turn their attention toward BIOS firmware.

From the attacker’s perspective, the next logical step to infecting a system is to move the point of infection down into the software stack, after the boot code is initialized, to get into the BIOS (illustrated in Figure 15-1). The BIOS starts the initial stages for the hardware setup in the boot process, meaning the BIOS firmware level is the last boundary before hardware.

Figure 15-1: Development of rootkits and bootkits in response to developments in security

The persistence level required for the BIOS is very different from anything else we’ve discussed so far in this book. Firmware implants can survive after reinstallation of the operating system and even after replacement of the hard drive, meaning that the rootkit infection potentially stays active for the lifetime of the infected hardware.

This chapter focuses on bootkit infection of the UEFI firmware, because at the time of this writing, most of the system firmware for x86 platforms is based on UEFI specifications. Before we get to those modern UEFI firmware infection methods, though, we’ll discuss some legacy BIOS bootkits for historical perspective.

Overview of Historical BIOS Threats

BIOS malware has always had a reputation for complexity, and with all the modern BIOS features the malware must work with or around, that’s truer today than ever. Even before vendors began taking it seriously, BIOS malware had a rich history. We’ll look at a couple of early examples of BIOS malware in detail, then briefly list the main characteristics of all the threats detected since the first BIOS-infecting malware: WinCIH.

WinCIH, the First Malware to Target BIOS

The virus WinCIH, also known as Chernobyl, was the first malware publicly known to attack the BIOS. Developed by Taiwanese student Chen Ing-hau, it was detected in the wild in 1998 and spread very quickly through pirated software. WinCIH infected Microsoft Windows 95 and 98 executable files; then, once an infected file was executed, the virus stayed in memory and set up filesystem hooks to infect other programs as they were accessed. This method made WinCIH highly effective at propagation, but the most destructive part of the virus was its attempt to overwrite the memory of the flash BIOS chip on the infected machine.

The destructive WinCIH payload was timed to strike on the date of the Chernobyl nuclear disaster, April 26. If the flash BIOS overwrite was successful, the machine was unable to boot unless the original BIOS was recovered. In the resources for this chapter (https://nostarch.com/rootkits/), you can download the original assembly code of WinCIH as distributed by its author.

Mebromi

After WinCIH, the next BIOS-attacking malware discovered in the wild didn’t appear until 2011. It was known as Mebromi, or BIOSkit, and targeted machines with legacy BIOS. By this time, security researchers had produced and released infection ideas and proofs of concept (PoCs) for BIOS attacks at conferences and in e-zines. Most of these ideas were difficult to implement in real-life infectious malware, but BIOS infection was seen as an interesting theoretical direction for targeted attacks that needed to keep up a long-term persistent infection.

Rather than implementing these theoretical techniques, Mebromi used the BIOS infection as a simple way to keep the MBR consistently infected at system boot. Mebromi was able to restore the infection even when the MBR was recovered to its original state or the OS was reinstalled, and even after the hard drive was replaced; the BIOS part of the infection would remain and reinfect the rest of the system.

In its initial stage, Mebromi used the original BIOS update software to deliver malicious firmware updates, specifically on Award BIOS systems, which was one of the most popular BIOS vendors at the time (it was acquired by Phoenix BIOS in 1998). During Mebromi’s lifetime, few protections existed to prevent malicious updates to the legacy BIOS. Similar to WinCIH, Mebromi modified the BIOS update routine’s System Management Interrupt (SMI) handler in order to deliver a modified, malicious BIOS update. Since measures like firmware signing did not exist at the time, infection was relatively easy; you can examine this classic piece of malware for yourself using the resource links at https://nostarch.com/rootkits/.

An Overview of Other Threats and Counters

Let’s now look at the timeline of in-the-wild BIOS threats and the related activities of security researchers. As you can see in Figure 15-2, the most active period of discovery of BIOS rootkits and implants began in 2013 and continues to the present day.

Figure 15-2: Timeline of BIOS threats

To give you a brief idea of the evolution of the BIOS bootkit, we’ve listed the highlights of each threat chronologically in Table 15-1. The left column lists the evolution of PoCs developed by researchers for the purposes of demonstrating security problems, and the middle columns list real BIOS threat samples found in the wild. The third column gives you resources for further reading.

Many of these exploit SMI handlers, which are responsible for interfacing between the hardware and the OS, and are executed in System Management Mode (SMM). For the purposes of this chapter, we provide a brief description of the most frequently exploited SMI handler vulnerabilities used to infect BIOS. We provide a more thorough discussion of different UEFI firmware vulnerabilities in Chapter 16.

Table 15-1: BIOS Rootkits Historical Timeline

PoC BIOS bootkit evolution	BIOS bootkit threat evolution	Further resources
	WinCIH, 1998 The first known malware that attacked the BIOS from OS
APCI rootkit, 2006 The first ACPI-based rootkit (Advanced Configuration and Power Interface), presented at Black Hat by John Heasman		“Implementing and Detecting an ACPI BIOS Rootkit,” Black Hat 2006, https://www.blackhat.com/presentations/bh-europe-06/bh-eu-06-Heasman.pdf
PCI OptRom rootkit, 2007 The first Option ROM rootkit for PCI, presented at Black Hat by John Heasman		“Implementing and Detecting a PCI Rootkit,” Black Hat 2007, https://www.blackhat.com/presentations/bh-dc-07/Heasman/Paper/bh-dc-07-Heasman-WP.pdf
IceLord rootkit, 2007 A Chinese BIOS bootkit PoC; the binaries were released publicly on the researcher’s forum
SMM rootkit, 2007 The first known PoC of an SMM rootkit from Rodrigo Branco, shown at the H2HC conference in Brazil		“System Management Mode Hack Using SMM for ‘Other Purposes,’” http://phrack.org/issues/65/7.html
SMM rootkit, 2008 The second known PoC of an SMM rootkit, shown at Black Hat		“SMM Rootkits: A New Breed of OS Independent Malware,” Black Hat 2008, http://dl.acm.org/citation.cfm?id=1460892; see also http://phrack.org/issues/65/7.html
BIOS patching, 2009 Multiple researchers published papers about BIOS image modifications	Computrace, 2009 The first known research about reverse engineering, published by Anibal Sacco and Alfredo Ortega	“Deactivate the Rootkit,” Black Hat 2009, https://www.coresecurity.com/corelabs-research/publications/deactivate-rootkit/
	Mebromi, 2011 The first BIOS bootkit detected in the wild, Mebromi uses ideas similar to IceLord	“Mebromi: The First BIOS Rootkit in the Wild,” https://www.webroot.com/blog/2011/09/13/mebromi-the-first-bios-rootkit-in-the-wild/
Rakshasa, 2012 The PoC of a persistent BIOS rootkit, presented by Jonathan Brossard at Black Hat
DreamBoot, 2013 The first public PoC of a UEFI bootkit	BadBIOS, 2013 An alleged persistent BIOS rootkit, reported by Dragos Ruiu	“UEFI and Dreamboot,” HiTB 2013, https://conference.hitb.org/hitbsecconf2013ams/materials/D2T1%20-%20Sebastien%20Kaczmarek%20-%20Dreamboot%20UEFI%20Bootkit.pdf “Meet ‘badBIOS,’ the Mysterious Mac and PC Malware That Jumps Airgaps,” https://arstechnica.com/information-technology/2013/10/meet-badbios-the-mysterious-mac-and-pc-malware-that-jumps-airgaps/
x86 Memory bootkit, 2013 UEFI-based in-memory bootkit PoC		“x86 Memory Bootkit,” https://github.com/AaLl86/retroware/tree/master/MemoryBootkit
Secure Boot bypass from BIOS, 2013 The first bypass of Secure Boot for Microsoft Windows 8 made public		“A Tale of One Software Bypass of Windows 8 Secure Boot,” Black Hat 2013, http://c7zero.info/stuff/Windows8SecureBoot_Bulygin-Furtak-Bazhniuk_BHUSA2013.pdf
Implementation and implications of a stealth hard drive backdoor, 2013 Jonas Zaddach et al. demonstrate a PoC of a hard drive firmware backdoor		“Implementation and implications of a stealth hard drive backdoor,” Annual Computer Security Applications Conference (ACSAC) 2013, http://www.syssec-project.eu/m/page-media/3/acsac13_zaddach.pdf
Darth Venamis, 2014 Rafal Wojtczuk and Corey Kallenberg discovered an S3BootSript vulnerability (VU#976132)	First reports of an allegedly state-sponsored SMM-based implant are published	“VU#976132,” https://www.kb.cert.org/vuls/id/976132/
Thunderstrike, 2014 Attack on Apple devices with a malicious Option ROM over the Thunderbolt port, presented by Trammell Hudson at the 31C3 conference		“Thunderstrike: EFI Bootkits for Apple MacBooks,” https://events.ccc.de/congress/2014/Fahrplan/events/6128.html
LightEater, 2015 A UEFI-based rootkit that demonstrates how to expose sensitive information from the memory in firmware, presented by Corey Kallenberg and Xeno Kovah	Hacking Team rkloader, 2015 The first known commercial-grade UEFI firmware bootkit leak, revealed by Hacking Team rkloader
SmmBackdoor, 2015 The first public PoC of a UEFI firmware bootkit, released with source code on GitHub		“Building Reliable SMM Backdoor for UEFI-Based Platforms,” http://blog.cr4.sh/2015/07/building-reliable-smm-backdoor-for-uefi.html
Thunderstrike2, 2015 A demonstration of a mixed attack approach using Darth Venamis and Thunderstrike exploits		“Thunderstrike 2: Sith Strike—A MacBook Firmware Worm,” Black Hat 2015, http://legbacore.com/Research_files/ts2-blackhat.pdf
Memory Sinkhole, 2015 A vulnerability that existed in the Advanced Programmable Interrupt Controller (APIC) and could allow an attacker to target the SMM memory area used by the OS, discovered by Christopher Domas; an attacker could exploit this vulnerability to install a rootkit		“The Memory Sinkhole,” Black Hat 2015, https://github.com/xoreaxeaxeax/sinkhole/
Privilege escalation from SMM to VMM, 2015 A group of Intel researchers presented a PoC of privilege escalation from SMM to hypervisor and demonstrated the PoC for exposing memory regions protected by VMM on MS Hyper-V and Xen		“Attacking Hypervisors via Firmware and Hardware,” Black Hat 2015, http://2015.zeronights.org/assets/files/10-Matrosov.pdf
PeiBackdoor, 2016 The first publicly released PoC of a UEFI rootkit that operated at the PEI (Pre-EFI Initialization) phase of boot; released with source code on GitHub	Cisco router-targeting implant, 2016 Reports of an allegedly state-sponsored implant for Cisco router BIOS	“PeiBackdoor,” https://github.com/Cr4sh/PeiBackdoor/
ThinkPwn, 2016 A privilege escalation vulnerability, promoting to SMM; originally discovered on the ThinkPad series of laptops by Dmytro Oleksiuk, also known as Cr4sh		“Exploring and Exploiting Lenovo Firmware Secrets,” http://blog.cr4.sh/2016/06/exploring-and-exploiting-lenovo.html
	MacBook-targeting implant, 2017 Reports of an allegedly state-sponsored UEFI implant targeting Apple laptops
	Lojax implant, 2018 UEFI rootkit discovered in the wild by ESET researchers	“LOJAX,” https://www.welivesecurity.com/wp-content/uploads/2018/09/ESET-LoJax.pdf

BIOS firmware has always been a challenging target for researchers, due to both lack of information and the difficulty of modifying or instrumenting the BIOS by adding new code to execute during the boot process. But since 2013, we’ve seen a larger effort from the security research community to find new exploits and to demonstrate weaknesses and attacks on recently introduced security features, such as Secure Boot.

Looking at the evolution of real BIOS malware, you may notice that very few BIOS threat PoCs actually became a trend for firmware-based implants, and most were used for targeted attacks. We’ll focus here on approaches to infecting the BIOS with a persistent rootkit that can survive not only reboots of the operating system but also any changes to hardware (except the motherboard) with a flash memory–infected BIOS firmware. Multiple media reports of UEFI implants being available to state-sponsored actors suggest that these implants are a technical reality and have been for a considerable time.

All Hardware Has Firmware

Before we start digging into the specifics of UEFI rootkits and bootkits, let’s take a look at modern x86 hardware and how different kinds of firmware are stored inside. These days, all hardware comes with some firmware; even laptop batteries have firmware that’s updated by the operating system to allow for more accurate measurement of battery parameters and usage.

Each piece of firmware is an area where an attacker can store and execute code and is thus an opportunity for a malicious implant. Most modern desktops and laptops have the following kinds of firmware:

• UEFI firmware (BIOS) Manageability Engine firmware (Intel ME, for instance)
• Hard drive firmware (HDD/SSD)
• Peripheral device firmware (for example, network adapters)
• Graphics card firmware (GPU)

Despite many apparent attack vectors, firmware attacks are not common among cybercrime perpetrators, who tend to prefer attacks that can target a broad range of victims. Because firmware tends to vary from system to system, most known incidents of firmware compromise have been targeted attacks rather than PoCs.

For example, the first hard drive firmware implant found in the wild was discovered by Kaspersky Lab researchers in early 2015. Kaspersky dubbed the creators of this malware the Equation Group and classified them as a state-level threat actor.

According to Kaspersky Lab, the malware they discovered had the ability to infect specific hard drive models, including some very common brands. None of the target drive models had authentication requirements for firmware updates, which is what made such an attack feasible.

In this attack, the hard drive infection module nls933w.dll, detected by Kaspersky as Trojan.Win32.EquationDrug.c, delivered modified firmware over the Advanced Technology Attachment (ATA) storage device connection commands interface. Accessing ATA commands allowed attackers to reprogram or update HDD/SSD firmware, with only weak update verification or authentication required. This kind of firmware implant can spoof the disk sectors at the firmware level or modify data streams by intercepting read or write requests to, for example, deliver modified versions of the MBR. These hard drive firmware implants are low in the firmware stack and therefore very difficult to detect.

Firmware-targeting malware generally delivers firmware implants by reflashing malicious firmware updates via the normal OS update process. This means it mostly affects the hard drives that don’t support authentication for firmware updates, instead just setting up new firmware as is. In the following sections, we’ll focus on UEFI-based rootkits and implants, but it’s useful to know that the BIOS isn’t the only place for developing persistent firmware implants.

UEFI Firmware Vulnerabilities

Discussions and examples of different types of vulnerabilities in modern operating systems are plentiful online, but discussions of UEFI firmware vulnerabilities are much rarer. Here we’ll list the kinds of rootkit-relevant vulnerabilities that have been publicly disclosed over the past few years. Most are memory corruption and SMM callout vulnerabilities that can lead to arbitrary code execution when the CPU is in SMM. An attacker can use these types of vulnerabilities to bypass BIOS protection bits and achieve arbitrary writes to and reads from the SPI flash memory regions on some systems. We’ll go into more detail in Chapter 16, but here are a couple of representative highlights:

ThinkPwn (LEN-8324) An arbitrary SMM code execution exploit for multiple BIOS vendors. This vulnerability allows an attacker to disable flash write protections and modify platform firmware.

Aptiocalypsis (INTEL-SA-00057) An arbitrary SMM code execution exploit for AMI-based firmware that allows an attacker to disable flash write protection bits and modify platform firmware.

Any of these issues can allow an attacker to install persistent rootkits or implants into the victim hardware. Many of these kinds of vulnerabilities rely either on the attacker being able to bypass memory protection bits or on the bits not being enabled or effective.

(In)Effectiveness of Memory Protection Bits

Most common technologies that protect the SPI flash from arbitrary writes are based on memory protection bits, a fairly old defense approach introduced by Intel decade ago. Memory protection bits are the only kind of protection available for cheap UEFI-based hardware used in the Internet of Things (IoT) market. An SMM vulnerability that enables attackers to gain privileges to access SMM and execute arbitrary code will allow the attacker to change those bits. Let’s look at the bits more closely:

BIOSWE The BIOS Write Enable bit, usually set up as 0 and changed to 1 by SMM to authenticate firmware or allow an update.

BLE The BIOS Lock Enable bit, which should be set to 1 by default to protect from arbitrary modification of the SPI flash BIOS regions. This bit can be changed by an attacker with SMM privileges.

SMM_BWP The SMM BIOS Write Protection bit should be set to 1 to protect SPI flash memory from writes outside of SMM. In 2015, researchers Corey Kallenberg and Rafal Wojtczuk found a race condition vulnerability (VU#766164) in which this unset bit could lead to the disabling of the BLE bit.

PRx SPI Protected Ranges (PR registers PR0–PR5) do not protect the entire BIOS region from modifications, but they offer some flexibility for configuring specific BIOS regions with the ability to read or write policies. The PR registers are protected from arbitrary changes by SMM. If all security bits are set and PR registers are configured correctly, it can be incredibly difficult for attackers to modify SPI flash.

These security bits are set up in the DXE stage, which we discussed in Chapter 14. If you’re curious, you can find an example of platform initialization stage code in the Intel EDK2 GitHub repository.

Checks for Protection Bits

We can check whether BIOS protection bits are enabled and effective by using a platform for security assessment named Chipsec, developed and open sourced by the Intel Security Center of Excellence (now known as IPAS, Intel Product Assurance and Security).

We’ll be examining Chipsec from a forensic perspective in Chapter 19, but for now, we’ll use just the bios_wp module (https://github.com/chipsec/chipsec/blob/master/chipsec/modules/common/bios_wp.py), which checks that the protections are correctly configured and protect the BIOS. The bios_wp module reads the actual values of the protection bits and outputs the status of SPI flash protection, warning the user if it is misconfigured.

To use the bios_wp module, install Chipsec and then run it with the following command:

chipsec_main.py -m common.bios_wp

As an example, we performed this check on a vulnerable platform based on MSI Cubi2 with an Intel seventh-generation CPU on board, which was fairly new hardware at the time of this writing. The output from this check is shown in Listing 15-1. The UEFI firmware of Cubi2 is based on AMI’s framework.

   [x][ =======================================================================
   [x][ Module: BIOS Region Write Protection
   [x][ =======================================================================
   [*] BC = 0x00000A88 << BIOS Control (b:d.f 00:31.5 + 0xDC)
   [00] BIOSWE              = 0 << BIOS Write Enable
➊ [01] BLE                 = 0 << BIOS Lock Enable
   [02] SRC                 = 2 << SPI Read Configuration
   [04] TSS                 = 0 << Top Swap Status
➋ [05] SMM_BWP             = 0 << SMM BIOS Write Protection
   [06] BBS                 = 0 << Boot BIOS Strap
   [07] BILD                = 1 << BIOS Interface Lock Down
   [-] BIOS region write protection is disabled!
   [*] BIOS Region: Base = 0x00A00000, Limit = 0x00FFFFFF
   SPI Protected Ranges
   ------------------------------------------------------------
➌ PRx (offset) | Value    | Base     | Limit    | WP? | RP?
   ------------------------------------------------------------
   PR0 (84)     | 00000000 | 00000000 | 00000000 | 0   | 0
   PR1 (88)     | 00000000 | 00000000 | 00000000 | 0   | 0
   PR2 (8C)     | 00000000 | 00000000 | 00000000 | 0   | 0
   PR3 (90)     | 00000000 | 00000000 | 00000000 | 0   | 0
   PR4 (94)     | 00000000 | 00000000 | 00000000 | 0   | 0

   [!] None of the SPI protected ranges write-protect BIOS region

   [!] BIOS should enable all available SMM based write protection mechanisms or
   configure SPI protected ranges to protect the entire BIOS region
   [-] FAILED: BIOS is NOT protected completely

Listing 15-1: Chipsec tool output from the module common.bios_wp

The output shows that the BLE ➊ is not enabled, meaning an attacker can modify any BIOS memory region on the SPI flash chip directly from the kernel mode of a regular OS. Additionally, SMM_BWP ➋ and PRx ➌ are not being used at all, suggesting that this platform does not have any SPI flash memory protections.

If the BIOS updates for the platform tested in Listing 15-1 are not signed, or the hardware vendor doesn’t authenticate updates properly, an attacker can easily modify firmware with a malicious BIOS update. It may seem like an anomaly, but these kinds of simple mistakes are actually fairly common. The reasons vary: some vendors just don’t care about security, while others are aware of security problems but don’t want to develop complex update schemes for cheap hardware. Let’s now look at some other ways of infecting the BIOS.

Ways to Infect the BIOS

We examined the complex and multifaceted UEFI boot process in Chapter 14. The takeaway from that chapter for our current discussion is that, before the UEFI firmware transfers control to the operating system loader and the OS starts booting, there are a lot of places for an attacker to hide or infect the system.

In fact, modern UEFI firmware increasingly looks like an operating system of its own. It has its own network stack and a task scheduler, and it can communicate directly with physical devices outside of the boot process—for example, many devices communicate with the OS via the UEFI DXE drivers. Figure 15-3 shows what a firmware infection might look like through the different boot stages.

Figure 15-3: UEFI firmware boot flow with attack pointers

Over the years, security researchers have identified many vulnerabilities that allow an attacker to modify the boot process with additional malicious code. As of today, most of these have been fixed, but some hardware—even new hardware—can still be vulnerable to those old issues. The following are different ways to infect UEFI firmware with a persistent rootkit or implant:

Modifying an unsigned UEFI Option ROM An attacker can modify a UEFI DXE driver in some add-on cards (used for networks, storage, and so forth) to allow malicious code execution at the DXE stage.

Adding/modifying a DXE driver An attacker can modify an existing DXE driver or add malicious DXE drivers to the UEFI firmware image. As a result, the added/modified DXE driver will be executed at the DXE stage.

Replacing the Windows Boot Manager (fallback bootloader) An attacker can replace the boot manager (fallback bootloader) on the EFI system partition (ESP) of the hard drive (ESPEFIMicrosoftBootootmgfw.efi or ESPEFI BOOTootx64.efi) to take over code execution at the point when the UEFI firmware transfers control to the OS bootloader.

Adding a new bootloader (bootkit.efi) An attacker can add another bootloader to the list of the available bootloaders by modifying the BootOrder/Boot#### EFI variables, which determine the order of OS bootloaders.

Of these methods, the first two are the most interesting in the context of this chapter, as they execute malicious code during the UEFI DXE phase; these are the two we’ll look at in more detail. The last two methods—though related to UEFI boot process—focus on attacking OS bootloaders and executing malicious code after UEFI firmware execution, so we won’t discuss them further here.

Modifying an Unsigned UEFI Option ROM

An Option ROM is PCI/PCIe expansion firmware (ROM) in x86 code located on a PCI-compatible device. An Option ROM is loaded, configured, and executed during the boot process. John Heasman first revealed Option ROMs as an entry point for stealth rootkit infection in 2007 at the Black Hat conference (refer back to Table 15-1). Then, in 2012, a hacker known as Snare introduced a variety of techniques for infecting Apple laptops, including through Option ROMs (http://ho.ax/downloads/De_Mysteriis_Dom_Jobsivs_Black_Hat_Slides.pdf). At Black Hat 2015, presenters Trammell Hudson, Xeno Kovah, and Corey Kallenberg demonstrated an attack named Thunderstrike that infiltrated the Apple Ethernet adapter with modified firmware that loaded malicious code (https://www.blackhat.com/docs/us-15/materials/us-15-Hudson-Thunderstrike-2-Sith-Strike.pdf).

An Option ROM contains a PE image that’s a specific DXE driver for the PCI device. In Intel’s open source EDK2 kit (https://github.com/tianocore/edk2/), you can find code that loads these DXE drivers; in the source code you’ll find the implementation of an Option ROM loader in PciOptionRomSupport.h in the folder PciBusDxe. Listing 15-2 shows the LoadOpRomImage() function of that code.

EFI_STATUS LoadOpRomImage (
     ➊ IN PCI_IO_DEVICE       *PciDevice,    // PCI device instance
     ➋ IN UINT64              RomBase        // address of Option ROM
);

Listing 15-2: The LoadOpRomImage() routine from EDK2

We see that the LoadOpRomImage() function receives two input parameters: a pointer to a PCI device instance ➊ and the address of the Option ROM image ➋. From this we can assume this function maps a ROM image into memory and prepares it for execution. The next function, ProcessOpRomImage(), is shown in Listing 15-3.

EFI_STATUS ProcessOpRomImage (
     IN PCI_IO_DEVICE   *PciDevice    // Pci device instance
);

Listing 15-3: The ProcessOpRomImage() routine from EDK2

ProcessOpRomImage() is responsible for starting the execution process for the specific device driver contained in the Option ROM. The creators of the Thunderstrike attack, which uses an Option ROM as its entry point, made their attack by modifying the Thunderbolt Ethernet adapter so that it would allow the connection of external peripherals. This adapter, developed by Apple and Intel, is based on the GN2033 chip and provides the Thunderbolt interface. A disassembled Thunderbolt Ethernet adapter similar to the one used in the Thunderstrike exploit is shown in Figure 15-4.

Figure 15-4: A disassembled Apple Thunderbolt Ethernet adapter

Specifically, Thunderstrike loaded the original Option ROM driver with additional code that was then executed because the firmware didn’t authenticate the Option ROM’s extension driver during the boot process (this attack was demonstrated on Apple Macbooks but can be applied to other hardware as well). Apple fixed this issue in its hardware, but many other vendors could still be vulnerable to this type of attack.

Many of the BIOS vulnerabilities listed in Table 15-1 have been fixed in modern hardware and operating systems, such as more recent versions of Windows, where Secure Boot is activated by default when hardware and firmware can support it. We’ll discuss Secure Boot implementation approaches and weaknesses in more detail in Chapter 17, but for now it suffices to say that any loaded firmware or extension driver lacking serious authentication requirements can be a security problem. On modern enterprise hardware, third-party Option ROMs are usually blocked by default, but they can be reenabled in the BIOS management interface, as shown in Figure 15-5.

Figure 15-5: Blocking third-party Option ROMs in the BIOS management interface

After the release of the Thunderstrike PoC, some vendors, including Apple, have become more aggressive about blocking all unsigned or third-party Option ROMs. We believe this is the right policy: the circumstances under which you need to load a third-party Option ROM are rare, and blocking all Option ROMs from third-party devices significantly reduces security risks. If you’re using peripheral device extensions with Option ROMs on board, be sure to buy them from the same vendor as the device; buying a random one isn’t worth the risk.

Adding or Modifying a DXE Driver

Now let’s take a look at the second type of attack on our list: adding or modifying a DXE driver in a UEFI firmware image. In essence, this attack is pretty straightforward: by modifying a legitimate DXE driver in the firmware, an attacker is able to introduce malicious code that will be executed in the preboot environment, at the DXE stage. However, the most interesting (and probably the most complicated) part of this attack is adding or modifying the DXE driver, which involves an intricate chain of exploitations of vulnerabilities present in the UEFI firmware, operating system, and user-mode applications.

One way to modify a DXE driver in the UEFI firmware image is to bypass the SPI flash protection bits we talked about earlier in this chapter, by exploiting a privilege escalation vulnerability. Elevated privileges allow the attacker to disable SPI flash protection by turning off the protection bits.

Another way is to exploit a vulnerability in the BIOS update process that allows an attacker to bypass update authentication and write malicious code to SPI flash memory. Let’s take a look at how these approaches are employed to infect BIOS with malicious code.

Understanding Rootkit Injection

Most of the users’ secrets and sensitive information of interest to attackers are either stored at the kernel level of the operation system or protected by code running at that level. This is why rootkits long sought to compromise kernel-mode (“Ring 0”): from this level, a rootkit could observe all the user activity or target specific user-mode (“Ring 3”) applications, including any components these applications loaded.

However, there is one aspect in which a Ring 0 rootkit is at a disadvantage: it lacks the user-mode context. When a rootkit operating from the kernel mode is looking to steal some data held by a Ring 3 application, the rootkit is not getting the most natural view of that data, as the kernel mode is, by design, not supposed to be aware of user-level data abstractions. Thus, a kernel-mode rootkit often has to reconstruct such data by using some trick or other, especially when the data is spread across several memory pages. Thus kernel-mode rootkits would need to skillfully reuse code that implemented user-level abstractions. Still, with just one level of separation, such code reuse was not particularly tricky.

SMM added an even better target into the mix, but also added another level of separation from user-level abstractions. An SMM-based rootkit can control both kernel-level and user-level memory by having control over any physical memory page. Yet this strength of SMM-level malicious code is also a weakness, as that code must reliably reimplement the upper-level abstractions such as virtual memory and handle all the complexity involved in this task.

Luckily for the attacker, an SMM rootkit can inject a malicious Ring 0 rootkit module into the OS kernel in a similar way to bootkits, and not just at boot time. Then it can rely on this code to make use of the kernel-mode structures in the kernel-mode context, while protecting that code from detection by kernel-level security tools. Critically, SMM-based code could choose the point at which the implant was injected.

Specifically, firmware implants can even bypass some Secure Boot implementations—something that straight-up bootkits could not do, by moving the point of infection after the integrity checks were completed. In Figure 15-6, we show how delivery methods evolved from a simple delivery scheme with a user-mode (Ring 3) loader, which exploited a vulnerability to elevate its privilege to install a malicious kernel-mode (Ring 0) driver. Yet the evolution of mitigations caught up with this scheme. Microsoft’s kernel-mode signing policies rendered it ineffective and started the bootkit era, which the Secure Boot technology was in turn introduced to counteract. Then SMM threats arose to undermine Secure Boot.

Figure 15-6: Possible ways of loading a Ring 0 rootkit

As of this writing, SMM threats have succeeded in bypassing Secure Boot on most of the Intel-based platforms. SMM rootkits and implants yet again moved the security boundary down, closer to the physical hardware.

With SMM threats growing in popularity, forensic analysis of the firmware is an emerging and very important area of research.

Injecting Malicious Code via SMM Privilege Escalation

To escalate privileges to the SMM level to be able to modify SPI flash contents, the attacker must use callback interfaces to the operating system that are handled by System Management Interrupt handlers (we’ll cover SMI handlers more in Chapter 16. The SMI handlers responsible for hardware interfaces to an operating system are executed in SMM, so if an attacker can exploit a vulnerability inside an SMM driver, they might be able to gain SMM execution privileges. Malicious code executed with SMM privileges can disable SPI flash protection bits and modify or add a DXE driver to the UEFI firmware on some platforms.

To understand this kind of attack, we need to think about attack tactics for persistent schemes of infection from the operating system level. What does the attacker need to do in order to modify the SPI flash memory? Figure 15-7 depicts the necessary steps.

Figure 15-7: Generic scheme of UEFI rootkit infection

As we can see, the exploitation path is pretty complex and involves exploits at many levels. Let’s break this process down into its stages:

Stage 1, user mode A client-side exploit, such as web browser remote code execution (RCE), drops a malicious installer onto the system. The installer then uses an elevation of privilege exploit to gain access to LOCALSYSTEM and continues execution with these new privileges.

Stage 2, kernel mode The installer bypasses code-signing policies (discussed in Chapter 6) to execute its code in kernel mode. The kernel-mode payload (driver) runs an exploit to gain privileges to SMM.

Stage 3, System Management Mode The SMM code successfully executes, and privileges are elevated to SMM. The SMM payload disables protections of SPI flash memory modifications.

Stage 4, SPI flash All SPI flash protections are disabled, and the flash memory is open to arbitrary writes. The rootkit/implant is then installed into the firmware onto the SPI flash chip. This exploit reaches a very high level of persistence in the system.

This generic scheme of infection in Figure 15-8 actually shows a real case of an SMM ransomware PoC, which we presented at Black Hat Asia 2017. The presentation is called “UEFI Firmware Rootkits: Myths and Reality,” and we recommend reading it if you’d like to know more (https://www.blackhat.com/docs/asia-17/materials/asia-17-Matrosov-The-UEFI-Firmware-Rootkits-Myths-And-Reality.pdf).

Exploiting BIOS Update Process (In)Security

Another way to inject malicious code into BIOS is to abuse the BIOS update authentication process. BIOS update authentication is intended to prevent the installation of BIOS updates whose authenticity cannot be verified, ensuring that only BIOS update images issued by the vendor of the platform are authorized to install. If an attacker manages to exploit a vulnerability in this authentication mechanism, they can inject malicious code into the update image that will subsequently be written to the SPI flash.

In March 2017, Alex Matrosov, one of the authors of this book, demonstrated a UEFI ransomware PoC at Black Hat Asia (https://www.cylance.com/en_us/blog/gigabyte-brix-systems-vulnerabilities.html). His PoC showed how the weak update process implemented by Gigabyte could be exploited. He used a recent platform from Gigabyte, based on the Intel sixth-generation CPU (Skylake) and Microsoft Windows 10, with all protections enabled, including Secure Boot with the BLE bit. Despite these protections, the Gigabyte Brix platform didn’t authenticate updates, thereby allowing an attacker to install any firmware update from the OS kernel (http://www.kb.cert.org/vuls/id/507496/). Figure 15-8 shows the vulnerable process of the BIOS update routine on the Gigabyte Brix hardware.

Figure 15-8: The UEFI ransomware infection algorithm

As we can see, the attacker can use the original kernel-mode driver from the BIOS update software, provided and signed by the hardware vendor, to deliver the malicious BIOS update. The driver communicates with the SWSMI handler SmiFlash, which has write and read interfaces to SPI flash memory. Specifically for this presentation, one of the DXE drivers was modified and executed in SMM to demonstrate the highest level of persistence possible in UEFI firmware and to control the boot process from the earliest boot stages. If infection of the UEFI ransomware is successful, the target machine displays the ransom message shown in Figure 15-9.

Figure 15-9: Active UEFI ransomware infection screen from Black Hat Asia 2017

In legacy BIOS firmware, before UEFI became the industry standard, mainstream hardware vendors didn’t think too much about securing firmware update authentication. This meant they were massively vulnerable to malicious BIOS implants; when those implants began showing up, vendors were forced to care. Nowadays, to militate against such attacks, UEFI firmware updates have a unified format named Capsule Update, described in detail in the UEFI specification. Capsule Update was developed to introduce a better process for delivering BIOS updates. Let’s take a look at it in detail using the Intel EDK2 repository mentioned earlier.

The Capsule Update Improvement

The Capsule Update has a header (EFI_CAPSULE_HEADER in EDK2 notation) and a body to store all information about the update’s executable modules, including DXE and PEI drivers. The Capsule Update image contains a mandatory digital signature of the update data and the code used for authentication and integrity protection.

Let’s look at the layout of Capsule Update image using the UEFITool utility developed by Nikolaj Schlej (https://github.com/LongSoft/UEFITool). This tool allows us to parse UEFI firmware images, including those provided in UEFI Capsule Updates, and to extract different DXE or PEI executable modules as standalone binaries. We will come back to UEFITool in Chapter 19.

Figure 15-10 shows the structure of the UEFI Capsule Update in the output of the UEFITool.

Figure 15-10: The UEFITool interface

The capsule image starts with a header ➊ that describes the general parameters of the update image, such as header size and update image size. Then we see the capsule body, which here consists of a single firmware volume ➋. (Firmware volumes are objects defined in the platform initialization specification and used to store firmware file images, including DXE and PEI modules. We’ll discuss them in more detail in Chapter 19.) This firmware volume contains the actual BIOS update data to be written to SPI flash memory in multiple firmware files: for instance, BootBlockAreas ➌ and RecoveryAreas ➍ contain updates for the PEI phase, while MainAreas ➎ contain updates for the DXE phase.

The important point is that the contents of the firmware volume that holds the BIOS updates are signed (even though UEFITool doesn’t display this information in Figure 15-11). As a result, an attacker is unable to introduce modifications to the updates without invalidating the digital signature. If implemented correctly, Capsule Update militates against attackers leveraging unauthenticated firmware updates.

UEFI Rootkits in the Wild

Since the UEFI malware discovered by Kaspersky Labs in 2015, we’ve seen multiple media reports of even more sophisticated rootkits in the wild, allegedly developed by nation-state actors. In the rest of this chapter, we’ll discuss other examples of UEFI rootkits, including those that have been broadly deployed by commercial organizations, such as Vector-EDK and Computrace.

Hacking Team’s Vector-EDK Rootkit

In 2015, an Italian company developing spyware for law enforcement organizations and other government clients, known as Hacking Team, was breached, and much of the company’s confidential information was exposed, including descriptions of an interesting project called Vector-EDK. Analysis of the breach revealed that Vector-EDK was a UEFI firmware rootkit that installed and executed its malicious components directly in the user-mode NTFS subsystem of Windows.

Alex Matrosov, one of the authors of this book and at the time a member of the Intel Advanced Threat Research (ATR) group, recognized the attack potential of Vector-EDK and published the blog post “Hacking Team’s ‘Bad BIOS’: A Commercial Rootkit for UEFI Firmware?” (https://www.mcafee.com/enterprise/en-us/threat-center/advanced-threat-research/uefi-rootkit.html).

Discovering Vector-EDK

Our investigation took off when we discovered a curious file, named Z5WE1X64.fd, attached to one of the leaked Hacking Team emails inside a compressed file named Uefi_windows_persistent.zip (see Figure 15-11).

Figure 15-11: One of the leaked emails from the Hacking Team archive

After we analyzed the attachment, it became clear that it was a UEFI firmware image, and after reading a few more leaked emails, we could see that we were dealing with a UEFI rootkit. A quick investigation with UEFITool revealed the suggestive name rkloader (implying rootkit loader) in the list of DXE drivers. Figure 15-12 shows our analysis.

Figure 15-12: Hacking Team Vector-EDK detection with UEFITool

This caught our attention because we had never encountered a DXE driver of this name before. We took a more careful look at the leaked archive and discovered the source code of the Vector-EDK project. This is where our technical investigation started in earnest.

Analyzing Vector-EDK

The Vector-EDK rootkit uses the previously discussed UEFI implant (rkloader) delivery methods. This rootkit, however, works only at the DXE stage and can’t survive a BIOS update. Inside the infected Z5WE1X64.fd BIOS image, there were three main modules:

NTFS parser (Ntfs.efi) A DXE driver containing a full parser for the NTFS, for read and write operations.

Rootkit (rkloader.efi) A DXE driver that registers a callback to intercept the EFI_EVENT_GROUP_READY_TO_BOOT event (which signifies that the platform is ready to execute the OS bootloader) and load the fsbg.efi UEFI application before the start of the OS boot.

Bootkit (fsbg.efi) A UEFI application that runs just before the BIOS passes control to the OS bootloaders. This contains the main bootkit functions that parse the NTFS with Ntfs.efi and inject malware agents into the filesystem.

We analyzed the leaked Vector-EDK source code and discovered that the components rkloader.efi and fsbg.efi implement the core functionality of the rootkit.

First, let’s take a look at rkloader.efi, which runs fsbg.efi. Listing 15-4 shows the main routine _ModuleEntryPoint() for the UEFI DXE driver rkloader.

EFI_STATUS
EFIAPI
_ModuleEntryPoint (EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
{
    EFI_EVENT Event;
    DEBUG((EFI_D_INFO, "Running RK loader. "));
    InitializeLib(ImageHandle, SystemTable);
    gReceived = FALSE;    // reset event!

    //CpuBreakpoint();

    // wait for EFI EVENT GROUP READY TO BOOT
 ➊ gBootServices->CreateEventEx( 0x200, 0x10,
                     ➋ &CallbackSMI, NULL, &SMBIOS_TABLE_GUID, &Event );

    return EFI_SUCCESS;
}

Listing 15-4: The _ModuleEntryPoint() routine from the rkloader component

We discovered that the routine _ModuleEntryPoint() does only two things, the first of which is to create a trigger ➊ for the event group EFI_EVENT_GROUP_READY_TO_BOOT. The second task, once the event arrives, is to execute an SMI handler ➋ by CallbackSMI(). The first parameter of the CreateEventEx() routine indicates that the immediate value of EFI_EVENT_GROUP_READY_TO_BOOT is 0x200. This event occurs right before the OS bootloader receives control at the end of the BIOS DXE phase, allowing the malicious payload, fsbg.efi, to take over execution before the operating system can.

Most of the interesting logic is contained inside the CallbackSMI() routine in Listing 15-5. The code for this routine is pretty long, so we’ve included only the most important parts of its flow here.

VOID
EFIAPI
CallbackSMI (EFI_EVENT Event, VOID *Context)
{
   --snip--

➊ EFI_LOADED_IMAGE_PROTOCOL       *LoadedImage;
   EFI_FIRMWARE_VOLUME_PROTOCOL    *FirmwareProtocol;
   EFI_DEVICE_PATH_PROTOCOL        *DevicePathProtocol,
                                   *NewDevicePathProtocol,
                                   *NewFilePathProtocol,
                                   *NewDevicePathEnd;

   --snip--

➋ Status = gBootServices->HandleProtocol( gImageHandle,
                                           &LOADED_IMAGE_PROTOCOL_GUID,
                                           &LoadedImage);
   --snip--

   DeviceHandle = LoadedImage->DeviceHandle;

➌ Status = gBootServices->HandleProtocol( DeviceHandle,
                                           &FIRMWARE_VOLUME_PROTOCOL_GUID,
                                           &FirmwareProtocol);

➍ Status = gBootServices->HandleProtocol( DeviceHandle,
                                           &DEVICE_PATH_PROTOCOL_GUID,
                                           &DevicePathProtocol);

   --snip--
   // copy "VOLUME" descriptor
➎ gBootServices->CopyMem( NewDevicePathProtocol,
                           DevicePathProtocol,
                           DevicePathLength);

   --snip--

➏ gBootServices->CopyMem( ((CHAR8 *)(NewFilePathProtocol) + 4),
                           &LAUNCH_APP, sizeof(EFI_GUID));

   --snip--
➐ Status = gBootServices->LoadImage( FALSE,
                                      gImageHandle,
                                      NewDevicePathProtocol,
                                      NULL,
                                      0,
                                      &ImageLoadedHandle);
   --snip--

done:
   return;
}

Listing 15-5: The CallbackSMI() routine from fsbg component

First we see multiple UEFI protocol initializations ➊, such as:

EFI_LOADED_IMAGE_PROTOCOL Provides information on the loaded UEFI images (image base address, image size, and location of the image in the UEFI firmware).

EFI_FIRMWARE_VOLUME_PROTOCOL Provides an interface for reading from and writing to firmware volumes.

EFI_DEVICE_PATH_PROTOCOL Provides an interface for building a path to a device.

The interesting part here starts with multiple EFI_DEVICE_PATH_PROTOCOL initializations; we can see many variable names prefixed with New, which usually indicates that they are hooks. The LoadedImage variable is initialized ➋ with a pointer to EFI_LOADED_IMAGE_PROTOCOL, after which LoadedImage may be used to determine the device on which the current module (rkloader) is located.

Next the code obtains the EFI_FIRMWARE_VOLUME_PROTOCOL ➌ and EFI_DEVICE_PATH_PROTOCOL ➍ protocols for the device on which rkloader is located. These protocols are necessary for constructing a path to the next malicious module—namely, fsbg.efi—to load from the firmware volume.

Once these protocols are obtained, rkloader constructs a path to the fsbg.efi module to load it from the firmware volume. The first part of the path ➎ is the path to the firmware volume on which rkloader resides (fsbg.efi is located on exactly the same firmware volume as rkloader), and the second part ➏ appends a unique identifier for the fsbg.efi module: LAUNCH_APP = {eaea9aec-c9c1-46e2-9d52432ad25a9b0b}.

The final step is the call to the LoadImage() routine ➐ that takes over execution of the fsbg.efi module. This malicious component contains the main payload with the direct paths to the filesystem it wants to modify. Listing 15-6 provides a list of directories in which the fsbg.efi module drops an OS-level malicious module.

#define FILE_NAME_SCOUT L"\AppData\Roaming\Microsoft\Windows\Start Menu\
Programs\Startup\"
#define FILE_NAME_SOLDIER L"\AppData\Roaming\Microsoft\Windows\Start
Menu\Programs\Startup\"
#define FILE_NAME_ELITE  L"\AppData\Local\"
#define DIR_NAME_ELITE L"\AppData\Local\Microsoft\"
#ifdef FORCE_DEBUG
UINT16 g_NAME_SCOUT[] =   L"scoute.exe";
UINT16 g_NAME_SOLDIER[] = L"soldier.exe";
UINT16 g_NAME_ELITE[]   = L"elite";
#else
UINT16 g_NAME_SCOUT[] =   L"6To_60S7K_FU06yjEhjh5dpFw96549UU";
UINT16 g_NAME_SOLDIER[] = L"kdfas7835jfwe09j29FKFLDOR3r35fJR";
UINT16 g_NAME_ELITE[]   = L"eorpekf3904kLDKQO023iosdn93smMXK";
#endif

Listing 15-6: Hardcoded paths to OS-level components

At a high level, the fsbg.efi module follows these steps:

1. Check if the system is already actively infected via a predefined UEFI variable named fTA.
2. Initialize the NTFS protocol.
3. Look for malicious executables in the BIOS image by looking at predefined sections.
4. Check for existing users on the machine by reviewing the names in the home directory to look for specific targets.
5. Install the malware executable modules scoute.exe (backdoor) and soldier.exe (RCS agent) by writing directly into the NTFS.

The fTA UEFI variable is installed by fsbg.efi at the point of first infection, and each subsequent boot checks for its presence: if the variable fTA is present, it means the active infection is already present on the hard drive and fsbg.efi doesn’t need to deliver the OS-level malicious binary to the filesystem. If malicious components from the OS level (Listing 15-6) are not found in the hardcoded path locations, the fsbg.efi module installs them again in the boot process.

Hacking Team’s Vector-EDK is a very instructive example of a UEFI bootkit. We highly recommend reading its full source code for a better understanding of how it works.

Absolute Software’s Computrace/LoJack

Our next example of a UEFI rootkit is not malicious exactly. Computrace, also known as LoJack, is actually a common proprietary antitheft system developed by Absolute Software that’s found in almost all popular enterprise laptops. Computrace implements a laptop-tracking system over the internet and includes features such as remote locking and remote wiping of hard drives in case of a lost or stolen laptop.

Many researchers have independently claimed that Computrace was technically a rootkit, because the software had behaviors very similar to a BIOS rootkit. The main difference, however, is that Computrace doesn’t try to hide. Its configuration menu can even be found in the BIOS setup menu (Figure 15-13).

Figure 15-13: Computrace menu from the BIOS setup on Lenovo ThinkPad T540p

On non-enterprise computers out of the box, Computrace will usually be disabled by default in the BIOS menu, as shown in Figure 15-13. There is also an option to disable Computrace permanently by setting an NVRAM variable, which disallows reactivation of Computrace and can be programmed only once in the hardware.

Here we’ll analyze implementations of Computrace on Lenovo T540p and P50 laptops. Our conceptual understanding of the Computrace architecture is shown in Figure 15-14.

Computrace has a complex architecture with multiple DXE drivers that include components working in SMM. It also contains an agent, rpcnetp.exe, that executes in the operating system and is responsible for all network communications with the cloud (C&C server).

LenovoComputraceEnableDxe DXE driver that tracks the BIOS menu for Computrace options to trigger the installation phase for LenovoComputraceLoaderDxe.

LenovoComputraceLoaderDxe DXE driver to verify security policies and load AbsoluteComputraceInstallerDxe.

AbsoluteComputraceInstallerDxe DXE driver that installs the Computrace agent into the operating system, via direct filesystem (NTFS) modifications. The agent binary is embedded into the DXE driver image as shown on Figure 15-15. On a modern laptop, ACPI tables are used for agent installation.

Figure 15-14: Computrace high-level architecture

Figure 15-15: AbsoluteComputraceInstallerDxe binary inside Hiew hex editor

LenovoComputraceSmiServices DXE driver that executes inside SMM to support communications with the OS agent and other BIOS components.

Computrace agent (rpcnetp.exe) PE executable image stored inside AbsoluteComputraceInstallerDxe. The Computrace agent executes after the operating system user login.

The main functions of Computrace’s rpcnetp.exe agent are collecting geolocation information and sending it to Absolute Software’s cloud. This is achieved by injecting Computrace’s component rpcnetp.dll into iexplore.exe and svchost.exe processes, as shown on Figure 15-16. The agent also receives commands from the cloud, such as a low-level hard drive wiping action for securely deleting files.

Figure 15-16: The rpcnetp.exe process injection scheme

Computrace is a good example of a technology that clearly looks like a BIOS rootkit but delivers persistent functionality for legitimate purposes, such as theft recovery. This type of persistence allows the main Computrace components to work independently of the OS and to integrate deeply with UEFI firmware. Disabling Computrace requires a lot more work from the attacker than merely stopping its OS agent component!

Conclusion

BIOS rootkits and implants are the next evolution stage for bootkits. As we’ve seen in this chapter, this evolution creates a new level of firmware persistence not yet addressed by antivirus software, meaning that malware that uses these techniques can remain active for years. We’ve tried to give a detailed overview of BIOS rootkits, from the initial PoCs and in-the-wild samples to advanced UEFI implants. However, this topic is complex and would require many more chapters for deeper coverage. We encourage you to follow the links given, read further for yourself, and follow our blogs.

Mitigation approaches for this kind of malware are still weak, but it’s also true that hardware vendors continue to introduce more and more complex secure boot implementations, in which boot integrity checks start from the earlier boot steps, even before the BIOS runs. Chapter 17 will dive deeper into modern implementations of Secure Boot. At the time of this writing, the security industry is only just starting to learn how to forensically investigate firmware, as information about real, in-the-wild cases is unfortunately sparse. We will cover more UEFI firmware forensics in the final chapter.

Chapter 16 explores UEFI vulnerabilities. As far as we know, no other book to date has covered this topic in comparable detail, so hold on to your hats!