Stealthy UEFI malware bypassing Secure Boot enabled by unpatchable Windows flaw

Researchers on Wednesday announced a major cybersecurity find—the world’s first-known instance of real-world malware that can hijack a computer’s boot process even when Secure Boot and other advanced protections are enabled and running on fully updated versions of Windows.

Dubbed BlackLotus, the malware is what’s known as a UEFI bootkit. These sophisticated pieces of malware target the UEFI—short for Unified Extensible Firmware Interface—the low-level and complex chain of firmware responsible for booting up virtually every modern computer. As the mechanism that bridges a PC’s device firmware with its operating system, the UEFI is an OS in its own right. It’s located in an SPI-connected flash storage chip soldered onto the computer motherboard, making it difficult to inspect or patch. Previously discovered bootkits such as CosmicStrand, MosaicRegressor, and MoonBounce work by targeting the UEFI firmware stored in the flash storage chip. Others, including BlackLotus, target the software stored in the EFI system partition.

Because the UEFI is the first thing to run when a computer is turned on, it influences the OS, security apps, and all other software that follows. These traits make the UEFI the perfect place to launch malware. When successful, UEFI bootkits disable OS security mechanisms and ensure that a computer remains infected with stealthy malware that runs at the kernel mode or user mode, even after the operating system is reinstalled or a hard drive is replaced.

As appealing as it is to threat actors to install nearly invisible malware that has kernel-level access, there are a few formidable hurdles standing in their way. One is the requirement that they first hack the device and gain administrator system rights, either by exploiting one or more vulnerabilities in the OS or apps or by tricking a user into installing trojanized software. Only after this high bar is cleared can the threat actor attempt an installation of the bootkit.

The second thing standing in the way of UEFI attacks is UEFI Secure Boot, an industry-wide standard that uses cryptographic signatures to ensure that each piece of software used during startup is trusted by a computer's manufacturer. Secure Boot is designed to create a chain of trust that will prevent attackers from replacing the intended bootup firmware with malicious firmware. If a single firmware link in that chain isn’t recognized, Secure Boot will prevent the device from starting.

While researchers have found Secure Boot vulnerabilities in the past, there has been no indication that threat actors have ever been able to bypass the protection in the 12 years it has been in existence. Until now.

On Wednesday, researchers at security firm ESET presented a deep-dive analysis of the world’s first in-the-wild UEFI bootkit that bypasses Secure Boot on fully updated UEFI systems running fully updated versions of Windows 10 and 11. While there are no strings or other indicators directly showing the name of the creators or the bootkit, ESET researchers have concluded that it almost certainly corresponds to a bootkit, known as BlackLotus, that has been advertised in underground cybercrime forums since last year. The price: $5,000, and $200 thereafter for updates.

A brief history of BlackLotus.

Credit: ESET

To defeat Secure Boot, the bootkit exploits CVE-2022-21894, a vulnerability in all supported versions of Windows that Microsoft patched in January 2022. The logic flaw, referred to as Baton Drop by the researcher who discovered it, can be exploited to remove Secure Boot functions from the boot sequence during startup. Attackers can also abuse the flaw to obtain keys for BitLocker, a Windows feature for encrypting hard drives.

CVE-2022-21894 has proven to be especially valuable to the BlackLotus creators. Despite Microsoft releasing new patched software, the vulnerable signed binaries have yet to be added to the UEFI revocation list that flags boot files that should no longer be trusted. Microsoft has not explained the reason, but it likely has to do with hundreds of vulnerable bootloaders that remain in use today. If those signed binaries are revoked, millions of devices will no longer work. As a result, fully updated devices remain vulnerable because attackers can simply replace patched software with the older, vulnerable software.

In an email, Jean-Ian Boutin, ESET’s director of threat research, wrote:

The ultimate takeaway is that UEFI bootkit BlackLotus is able to install itself on up-to-date systems using the latest Windows version with secure boot enabled. Even though the vulnerability is old, it is still possible to leverage it to bypass all security measures and compromise the booting process of a system, giving the attacker control over the early phase of the system startup. It also illustrates a trend where attackers are focusing on the EFI System Partition (ESP) as opposed to firmware for their implants—sacrificing stealthiness for easier deployment—but allowing a similar level of capabilities.

BlackLotus is written in the assembly and C programming languages, allowing the developers to cram a full suite of powerful features into a file that takes just 80 kb of storage space. It can reliably disable not just Secure Boot but several other OS security mechanisms, including Bitlocker, Hypervisor-protected Code Integrity (HVCI), and Windows Defender. Once BlackLotus is fully installed, the bootkit deploys a custom kernel driver that, among other things, protects the bootkit from being removed from the ESP. It also installs an HTTP downloader that communicates with an attacker-operated command-and-control server and can load additional user-mode or kernel-mode payloads.

As ESET’s Boutin alluded to above, rather than getting bogged down in the complexities of UEFI firmware and having to defeat various memory detections built into the SPI-connected flash chip that stores it, BlackLotus developers deploy standard binary files to the EFI system partition. The ESP, as it’s abbreviated, is a traditional disk partition that’s much easier to access. Unlike the flash chip, the ESP doesn’t have protections such as BIOS Write Enable, BIOS Lock Enable, and SPI Protected Ranges, which make it difficult to write or modify stored data.

In Wednesday’s deep dive, ESET researcher Martin Smolár wrote:

Running as a bootloader gives them almost the same capabilities as firmware implants, but without having to overcome the multilevel SPI flash defenses, such as the BWE, BLE, and PRx protection bits, or the protections provided by hardware (like Intel Boot Guard). Sure, UEFI Secure Boot stands in the way of UEFI bootkits, but there are a non-negligible number of known vulnerabilities that allow bypassing this essential security mechanism. And the worst of this is that some of them are still easily exploitable on up-to-date systems even at the time of this writing—including the one exploited by BlackLotus.

The following graphic illustrates a simplified overview of the BlackLotus execution chain:

A flow chart showing the brief history of BlackLotus.

Credit: ESET

There are three main sections in the chain:

1. An installer deploys files to the ESP, as shown in step 1 in the above figure. The installer then disables HVCI and BitLocker and reboots the device. The installer appears to have two versions—one with embedded vulnerable binaries and another that downloads them directly from Microsoft. The latter installer version downloads binaries, including:

• https://msdl.microsoft.com/download/symbols/bootmgfw.efi/7144BCD31C0000/bootmgfw.efi
• https://msdl.microsoft.com/download/symbols/bootmgr.efi/98B063A61BC000/bootmgr.efi
• https://msdl.microsoft.com/download/symbols/hvloader.efi/559F396411D000/hvloader.efi

If the installer doesn’t already have administrator system permissions, it tries to elevate its current permissions by using this method for bypassing the Microsoft User Account Control, a security protection designed to prevent unauthorized changes to the OS unless they’re approved by an account with administrative rights.

The installer disables HVCI by setting the enabled registry value under the HypervisorEnforcedCodeIntegrity registry key to zero, as described here. The HVCI ensures that all kernel-mode drivers and binaries are signed before they can run. The installer disables it so that the custom unsigned kernel mentioned earlier can be installed later in the execution chain.

The installer must also disable BitLocker because it can be used in combination with a Trusted Platform Module to ensure that Secure Boot hasn't been tampered with. To do this, the installer calls the DisableKeyProtectors method, with the DisableCount parameter set to zero.

The MOK process.

2. Once the device restarts, BlackLotus gains persistence, meaning it will run each time the device starts. The malware does this by exploiting CVE-2022-21894 and, when Secure Boot is enabled, registering an attacker-designated machine owner key (MOK). A MOK allows owners of devices running non-Windows OSes to generate keys that sign non-Microsoft components during the boot process. The MOK is used in combination with what's known as a shim loader, which is signed by various Linux distributors. This MOK process is illustrated in the image to the right.

Steps 2 through 4 of the figure above show this fits into the overall BlackLotus execution chain. The image below shows the self-signed certificate corresponding to the MOK.

A self-signed certificate for the BlackLotus malware. Note the Issuer NM "When they cry CA," a reference to the Higurashi When They Cry anime series.

Credit: ESET

ESET’s Smolár explained:

In a nutshell, this process consists of two key steps:

1. Exploiting CVE-2022-21894 to bypass the Secure Boot feature and install the bootkit. This allows arbitrary code execution in early boot phases, where the platform is still owned by firmware and UEFI Boot Services functions are still available. This allows attackers to do many things they should not be able to do on a machine with UEFI Secure Boot enabled without having physical access to it, such as modifying Boot-services-only NVRAM variables. And this is what attackers take advantage of to set up persistence for the bootkit in the next step.
2. Setting persistence by writing its own MOK to the MokList, [in the] boot-services-only NVRAM variable. By doing this, it can use a legitimate Microsoft-signed shim for loading its self-signed (signed by the private key belonging to the key written to MokList) UEFI bootkit instead of exploiting the vulnerability on every boot.

The ESET post provides more granular descriptions of the exploitation of CVE-2022-21894 and gaining persistence here and here.

3. From then on, each time the device boots, the attacker’s self-signed bootkit is executed. As explained earlier, the bootkit ensures that both the kernel driver preventing file deletion and the HTTP downloader are installed (steps 5 through 9). From the post:

The kernel driver is responsible for:

• Deploying the next component of the chain—an HTTP downloader
• Keeping the loader alive in case of termination
• Protecting bootkit files from being removed from ESP
• Executing additional kernel payloads, if so instructed by the HTTP downloader
• Uninstalling the bootkit, if so instructed by the HTTP downloader

The HTTP downloader is responsible for:

• Communicating with its C&C
• Executing commands received from the C&C
• Downloading and executing payloads received from the C&C (supports both kernel payloads and user-mode payloads)

Here is a diagram showing the execution of the UEFI bootkit:

Diagram showing the execution of the BlackLotus bootkit.

Credit: ESET

It’s not known who is behind BlackLotus. One clue, however, may be in the restrictions found in some of the samples that prevent execution if a device is located in:

• Moldova (Romanian), ro-MD
• Moldova (Russian), ru-MD
• Russia (Russian), ru-RU
• Ukraine (Ukrainian), uk-UA
• Belarus (Belarusian), be-BY
• Armenia (Armenian), hy-AM
• Kazakhstan (Kazakh), kk-KZ

Often, attackers in one of these countries take pains not to infect devices there to prevent being arrested and prosecuted since these places have treaties allowing for extradition, though they generally don’t have extradition treaties with the US and other Western countries.

It’s also not clear how many devices have been infected by BlackLotus or how it gets installed. As mentioned earlier, the installer must gain administrator permissions to run. That’s a high bar that means a computer is already fully compromised. In a statement, Microsoft officials wrote, “This technique [for exploiting CVE-2022-21894] requires administrative access for remote attacks or physical access for local attacks. We are investigating further and will do what is necessary to help keep our customers safe and protected.”

For now, the only way to prevent infections by BlackLotus is to ensure that all available OS and app patches have been installed. This won’t prevent the bootkit from running, but it will make it harder for the installer to gain the administrative privileges it needs. Antivirus products that monitor firmware for malicious tampering might also provide some level of protection.

Despite the high bar, BlackLotus could prove useful as an alternative to more traditional forms of backdoor malware, which also require administrator permissions. BlackLotus is harder to detect than many pieces of traditional malware. Fortunately, unlike many UEFI bootkits, it can be removed by reinstalling the OS, Boutin.

The handful of previously discovered bootkits in the wild—including FinSpy and ESPecter—provide the same benefits, but they were easily defeated by enabling Secure Boot. BlackLotus represents a major milestone in the continuing evolution of UEFI bootkits and signals the world’s continuing susceptibility to them.

Post corrected to reflect BlackLotus can be removed by reinstalling Windows.