Running Malware Below the OS – The State of UEFI Firmware Exploitation

By Adam Paulina, Threat Researcher Intern

Usually when we think of malware infections, we think of malicious programs running on top of the operating system, usually Windows. These programs might use techniques like privilege escalation, running in memory only, injecting code into other processes, and obfuscating their code and activities. All of these techniques are used with the end goal of compromising a system, achieving persistence, and remaining undetected.

In response to the rising prevalence of these modern mitigations, attackers have been taking a different approach. The easiest way to circumvent a protection is to disable it before it ever runs. As a result, attackers have been increasingly driven to attacking the boot process, often before the OS even launches.  

This methodology has a few strong benefits for an attacker: By infecting the device firmware, they can survive OS reinstallations and even hard drive replacements. Additionally, this method opens an entirely new attack vector in the supply chain – if a manufacturer can be compromised before the victim even receives the product, they could be infected the second they first touch the device and have absolutely no idea. Detection of these threats is still an area of active research.  

Further, attacking the boot process so early allows an attacker to completely disable all of the mitigations and protections described above, without even alerting the victim that they are disabled. Since the attacker is working below the operating system level, nothing the operating system says can be trusted. For this reason, bootkits make up some of the most dangerous malware in existence due to their capabilities, their persistence, and their high difficulty of detection.  

In part one of this blog series, we will explain the boot process of modern UEFI machines, as well as some of its built-in protections, and we will explore the techniques used by various real-world bootkits to circumvent these protections and hijack the boot process. Bootkits in this blog will be classified by the techniques they use.

The UEFI boot process 

Nearly all modern computers have firmware conforming to the UEFI open standard. UEFI was introduced to replace the older BIOS standard nearly 17 years ago and has been widely adopted for more than 10 years. BIOS is obsolete and should not be used on modern computers. As a result, BIOS is outside of the scope of this article and will not be mentioned beyond this point. 

The primary purpose of UEFI is to initialize device hardware and bring the machine to a bootable state. UEFI is an open standard, and it is also designed to be comprehensive. The intent is that any motherboard that uses UEFI will have the exact same behavior, even across different manufacturers.  

UEFI is also designed to be secure from the ground up. It incorporates a complex string of verifications and security measures, creating a chain of trust from the first instructions to run all the way to the final OS boot. Assuming the chain is implemented correctly (meaning all the verifications at each stage work properly), is still can’t be implicitly trusted, unless the code that initializes the chain is trusted. If malicious code starts the chain, the verification steps are pointless as they can be easily bypassed or spoofed. This initial state of trust is what’s usually referred to as the “root-of-trust”.  

The root-of-trust used in UEFI is dependent on which specific security technologies are enabled. Without any security features enabled (such as when in Compatibility Support Mode (CSM)*), there’s obviously no root-of-trust at all as there is no chain-of-trust. With UEFI Secure Boot enabled, the root-of-trust is centered in the platform initialization firmware, the first code to run on the computer. Unfortunately, this isn’t the best choice as under the right conditions it can be modifiable with software, breaking the entire chain. A better root-of-trust is available with technologies that implement verified boot, such as Intel Boot Guard – where the root-of-trust is moved into immutable hardware logic and cannot be attacked without physical access. 

The rest of this blog post will primarily focus on machines with UEFI Secure Boot enabled, but without Intel Boot Guard, as these are what most bootkits target. There have been a couple leaks in the past year that resulted in exposure of some Intel Boot Guard private keys, which could potentially open the door for some attacks that can circumvent it, but at the time of writing there are currently no bootkits in the wild that do so. 

The root-of-trust of UEFI Secure Boot is primarily implemented by the platform initialization firmware, which consists of some of the earliest code to run on the computer. Intel processors start by running some routines to check for updates for their microcode, updating if necessary, retrieving the microcode, verifying its signature, and running it. If we had Intel Boot Guard enabled, the hardware verification steps would occur now, but since that is disabled, the primary job of the microcode is simply to jump to the reset vector, which begins execution of the UEFI firmware. 

The UEFI firmware is divided into three main stages: 

• Security (SEC) 
• Pre-EFI Initialization (PEI) 
• Driver Execution Environment (DXE) 

The SEC stage covers the code that runs immediately upon jumping to the reset vector. The code is executed directly out of the SPI flash. It’s first job is to switch from real mode to protected mode, which opens proper memory addressing instead of having to deal with segmentation. Next, it sets up a temporary emulation of RAM using the CPU caches. This allows it to run code that requires memory access beyond the registers, without having actually initialized DRAM yet. Finally, the Security stage’s final job is to verify the PEI stage before running it. This verification step implements the core functionality of Secure Boot, which we will see again implemented at various stages throughout the boot process and will explore in more detail later in this post. 

Once execution switches over to the PEI stage, its primary job is to initialize the essential hardware necessary for the system to operate. More specifically, it configures the memory controller to enable DRAM, switches from using the emulated RAM with the CPU caches to using true DRAM and initializes the chipset. If waking from sleep instead of booting for the first time, it also restores the contents of the CPU registers to what they were before it was asleep. Whether restoring from sleep or booting from scratch, its last step is always to verify and launch the final DXE stage, in a very similar manner to how the PEI stage was verified and launched. 

DXE is the final stage of the UEFI firmware, and the longest. Its main job is to initialize all the rest of the hardware. Since hardware is vendor specific and UEFI is supposed to be a platform-agnostic specification, it is designed so that all of the hardware initialization is done by separate DXE drivers. A system can have as many or as few DXE modules as is necessary to initialize all the hardware. This stage is also responsible for initializing System Management Mode (SMM). It also sets up boot and runtime EFI services. Once all that is done, it enumerates all UEFI-compatible bootloaders on the PCI bus and chooses one to boot. Lastly, it performs the boot by consulting with NVRAM variables to find the location of the EFI System Partition (ESP), finding the location of the boot manager on it, and then verifying and launching that bootloader. On Windows machines the bootloader is called bootmgfw.efi and is stored at \EFI\Microsoft\Boot\. The UEFI firmware is able to access filesystems at this point thanks to hard drive access now being initialized, and it does so using its GUID Partition Table (GPT).  

After the Windows bootloader is called, it performs a variety of steps. Before doing anything, it must first decompress its embedded PE file and hand over execution to it. Once this is done, it reads system parameters from the Boot Configuration Data (BCD) store, which controls many Windows security features (this is a common target for bootkits once they compromise the firmware). Then, bootmgr handles boot option selection screens (such as enabling safe mode), and then it calls winload to boot with whatever selected options. 

Winload is responsible for enabling paging in protected mode, and for loading the OS kernel image and its dependencies: 

• bootvid.dll : library for VGA support at boot time 
• ci.dll : code integrity library 
• clfs.dll : common logging filesystem driver 
• hal.dll : hardware abstraction layer driver 
• kdcom.dll : kernel debugger protocol communications library 
• pshed.dll : platform specific hardware error driver 

Additionally, winload loads boot-start drivers, the Early Launch Anti Malware (ELAM) service, and the registry. Assuming code integrity checks are enabled, it attempts to verify every module that it loads. 

Types of UEFI Bootkits 

Now that we have a fundamental understanding of UEFI and its security mechanisms, we can start exploring the malicious software that attempts to break it. 

There are different methodologies that UEFI bootkits can take. Some are very basic and only make a couple changes to the pre-existing code, completely ignoring Secure Boot. Some write their own modules and drivers. Some actually attempt to bypass Secure Boot via the weakness we explained in the last section. We will explore all of these methods below: 

ESP only: 

The earliest known technique is also the simplest. The basic premise is to modify the ESP partition on the hard drive, which only requires kernel access to write to. By modifying or replacing the existing bootmgfw.efi and winload.efi files, or by modifying the NVRAM variables that point to their location, it is possible to run a malicious bootloader instead of the real one.

This technique only works with Secure Boot disabled, because the modified/replaced efi files will no longer pass verification and therefore won’t boot at all. 

ESP-only bootkits are fairly limited in what they can do as a consequence of running so late in the boot chain. They don’t execute until after the UEFI firmware is finished, when most security features are already initialized. Further, they have lower persistence than other bootkits as they wouldn’t survive hard drive wiping/replacement. They were only really viable threats in the early 2010s.  

Consequently, even the ones that were discovered recently like FinSpy and ESPecter appear to have been developed close to 2012, and just went undetected for a few years due to the stealth of bootkits in general. 

DreamBoot (POC published by QuarksLab in 2013):

• While only being a proof of concept, DreamBoot is notable because it was the first public attempt at a UEFI bootkit.  
• The idea of DreamBoot is relatively simple, all it does is modify the two Windows bootloader files on the ESP (bootmgfw.efi and winload.efi) in order to make them do malicious things (for the proof of concept, the two are made to implement a Windows privilege escalation functionality).  
• The original presentation claims that the POC could only be deployed with physical access using a CD, even providing the release as an ISO image to be burned to a disc. It turns out that this is completely unnecessary, and it is entirely possible to deploy the attack remotely. 

QuarkMatter (developed by CIA, docs leaked online in 2016):

• QuarkMatter is a UEFI bootkit whose existence was revealed by WikiLeaks in 2016. The leaks included several documents describing the tool, and instructions for installing it and using it. They did not however include the tool itself, and they also aren’t terribly specific about how it works under the hood. From what can be gathered, the tool operated similarly to other ESP-only bootkits, except that it targeted macOS instead of Windows. 

FinSpy (discovered by Kaspersky in 2021):

• FinFisher is the UEFI bootkit component of the FinFisher spyware suite, a collection of software tools marketed and sold to governments and law enforcement agencies. While it is unknown exactly when FinSpy’s UEFI bootkit component was first used in the wild, the FinSpy spyware suite itself was first seen in the wild in 2011, and it was known to have a legacy BIOS bootkit since 2014. As a result, the UEFI bootkit could have been developed any time between 2011 and 2021, but it’s not out of the question that it was developed early in the range and went undetected for years. It’s also possible that it reuses code from the legacy BIOS version, in which case it dates back to at least 2014. 
• FinSpy’s UEFI bootkit component works very similarly to DreamBoot, except that it only replaces bootmgfw.efi, and instead of doing a basic privilege escalation it installs the spyware into the OS by dropping it as a trojan.  

ESPecter (discovered by ESET in 2021):

• ESPecter is a UEFI bootkit made by an unknown threat actor, possibly Chinese speaking. The bootkit shares code with a previous legacy BIOS bootkit that dated all the way back to 2012.   
• Under the hood, ESPecter operates very similarly to FinSpy, but instead of using a trojan, it installs a kernel driver to do its spyware work instead. It is able to do this because the bootkit can disable driver signing enforcement. 

DXE only:

The next steps in bootkit complexity are those that go one step further back in the boot chain. DXE-only bootkits are much stealthier than their ESP-only counterparts because they don’t modify any pre-existing files. Instead, they add malicious DXE drivers that are executed during the DXE stage.

These are much harder to find as there are hundreds of DXE drivers on any given system, although the existence of unverified DXE modules means it’s still not possible to boot with Secure Boot enabled. They are also more persistent than ESP-only threats, as they are stored on the SPI flash, and would persist through hard drive replacements. 
 
These bootkits are also harder to install than the ESP-only ones. In order to get direct access to the SPI flash, an attacker would require System Management Mode (SMM) access. ESP-only bootkit installers only ever require kernel access. However, it is also possible that a DXE-only bootkit could be installed via a compromised update mechanism instead. 

VectorEDK (developed by Hacking Team, leaked online in 2015):

• VectorEDK is a UEFI bootkit created by the Italian company Hacking Team as part of a suite of tools that they sold to governments and law enforcement agencies. Unlike the previous bootkits we have talked about so far, VectorEDK doesn’t touch the EFI files directly, instead loading itself earlier in the process during the DXE phase. VectorEDK is made up of multiple DXE drivers, as well as a custom EFI file similar to the ones in the ESP-only bootkits we’ve discussed before. However, unlike the previous ones, this malicious EFI is not executed from the ESP, rather the malicious DXE drivers register a callback for EFI_EVENT_GROUP_READY_TO_BOOT which calls the EFI bootloader before the OS bootloader gets run. 
• While this does execute earlier than its ESP-only peers, it still doesn’t pass Secure Boot because the DXE drivers are not signed. 
• Hacking Team suggested to their clients that deployment required physical access using a USB drive, although it is potentially possible to deploy remotely.  

DerStarke (developed by CIA, leaked online in 2016):

• DerStarke is a UEFI bootkit whose existence was revealed by WikiLeaks in 2016. Similarly to QuarkMatter, the leaks included documents describing the tool, and instructions for installing it and using it. They did not however include the tool itself, and they also aren’t terribly specific about how it works under the hood. From what can be gathered, the tool operated similarly to other DXE-only bootkits, except that it targeted macOS instead of Windows. 

Spy Trojan (谍影木马) (discovered by Qihoo360 in 2017):

• Spy Trojan is a UEFI bootkit developed by an unknown Chinese-speaking threat actor. It was discovered by Qihoo360 in 2017, though mostly missed by English-speaking researchers. It was later widely reported on in 2022 when Kaspersky named it as an ancestor of CosmicStrand. 
• Spy Trojan uses a technique involving the Compatibility Support Module, a UEFI component that allows booting from old MBR disks instead of modern GPT ones. The bootkit replaces the DXE driver intended to locate the bootable system partition from the MBR drive, and hooks some functions in order to copy its rootkit components into the Windows kernel during boot. As it involves unsigned DXE drivers, Spy Trojan does not bypass Secure Boot. 
• Spy Trojan’s published research goes into detail about the infection vector of the sample they analyzed: a customer of theirs bought a used motherboard online that shipped with the malware preinstalled. It was only noticed by the user after the computer would repeatedly automatically create a suspicious user account. 

MosaicRegressor (discovered by Kaspersky in 2020):

• MosaicRegressor is a UEFI bootkit developed by an unknown Chinese-speaking threat actor, based on the leaked source code for VectorEDK. MosaicRegressor uses the exact same callback registration method to load its malicious DXE drivers that VectorEDK uses. The main difference with MosaicRegressor was not in its bootkit component, but in the spyware malware that it bootstraps after infection. As MosaicRegressor uses the same techniques as VectorEDK, it also does not pass Secure Boot thanks to having unsigned DXE drivers. 
• Kaspersky never determined the infection vector before publishing their research (they said that they noticed no suspicious events before detection of the malicious code), but speculated that it could have been physical access like described by the Hacking Team leak, or that it could have also been remotely deployed. 

MoonBounce (discovered by Kaspersky in 2021):

• MoonBounce is a bootkit believed to have been developed by the APT Wicked Panda. Since Kasperspky discovered the infection after it was already in place, they didn’t have much to reveal about its infection method, though they believed it to have been installed remotely.  
• MoonBounce operates a little differently than other DXE bootkits. Instead of simply adding more DXE drivers, it works by hooking some of the EFI Boot Services functions in order to inject more malware into the Windows kernel during boot.  

CosmicStrand (discovered by Kaspersky in 2022):

• CosmicStrand is a UEFI bootkit developed by an unknown Chinese-speaking threat actor. It is a direct descendant of the earlier Spy Trojan bootkit discovered by Qihoo360 in 2017. Very similar to Spy Trojan, it works via patching the CSMCORE DXE driver in order to inject rootkit code into the windows bootloader.  
• Once again, as an unsigned DXE driver CosmicStrand is unable to pass SecureBoot.