Contemporary UEFI Bootkits by Blackhat Pakistan 2023

Ahmad Khan January 13, 2023January 13, 2023 0 Comments black hat pakistan, Contemporary UEFI Bootkits, Ethical hacking, Learn all about 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 kernelmode 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.

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.

Note: If you’re interested in reading more about legacy BIOS reverse engineering and architecture, we recommend the book BIOS Disassembly Ninjutsu Uncovered by Darmawan Mappatutu Salihun, also known as pinczakko. The electronic copy of the book can be downloaded for free from the author’s GitHub account (https://github .com/pinczakko/BIOS-Disassembly-Ninjutsu-Uncovered).

Also read:IPL Bootkits :Rovnix and Carberp-by Blackhat Pakistan 2023

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.

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.

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 rootkitrelevant 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:

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.

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 (ESP\EFI\Microsoft\Boot\ bootmgfw.efi or ESP\EFI\ BOOT\bootx64.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.

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.

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.

After the release of the Thunderstrike PoC, some vendors, including Apple, have become more aggressive about blocking all unsigned or thirdparty 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.

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.

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.

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.

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.

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!