BlackLotus UEFI bootkit: Myth confirmed

The number of UEFI vulnerabilities discovered in recent years and the failures in patching them or revoking vulnerable binaries within a reasonable time window hasn’t gone unnoticed by threat actors. As a result, the first publicly known UEFI bootkit bypassing the essential platform security feature – UEFI Secure Boot – is now a reality. In this blogpost we present the first public analysis of this UEFI bootkit, which is capable of running on even fully-up-to-date Windows 11 systems with UEFI Secure Boot enabled. Functionality of the bootkit and its individual features leads us to believe that we are dealing with a bootkit known as BlackLotus, the UEFI bootkit being sold on hacking forums for $5,000 since at least October 2022.

UEFI bootkits are very powerful threats, having full control over the OS boot process and thus capable of disabling various OS security mechanisms and deploying their own kernel-mode or user-mode payloads in early OS startup stages. This allows them to operate very stealthily and with high privileges. So far, only a few have been discovered in the wild and publicly described (e.g., multiple malicious EFI samples we discovered in 2020, or fully featured UEFI bootkits such as our discovery last year – the ESPecter bootkit – or the FinSpy bootkit discovered by researchers from Kaspersky).

UEFI bootkits may lose on stealthiness when compared to firmware implants – such as LoJax; the first in-the-wild UEFI firmware implant, discovered by our team in 2018 – as bootkits are located on an easily accessible FAT32 disk partition. However, 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.

Our investigation started with a few hits on what turned out to be the BlackLotus user-mode component – an HTTP downloader – in our telemetry late in 2022. After an initial assessment, code patterns found in the samples brought us to the discovery of six BlackLotus installers (both on VirusTotal and in our own telemetry). This allowed us to explore the whole execution chain and to realize that what we were dealing with here is not just regular malware.

Following are the key points about BlackLotus and a timeline summarizing the series of events related to it:

The timeline of individual events related to BlackLotus is shown in Figure 1.

Figure 1. Timeline of major events related to BlackLotus UEFI bootkit

As already mentioned, the bootkit has been sold on underground forums since at least October 6th, 2022. At this point, we have not been able to identify, from our telemetry, the exact distribution channel used to deploy the bootkit to victims. The low number of BlackLotus samples we have been able to obtain, both from public sources and our telemetry, leads us to believe that not many threat actors have started using it yet. But until the revocation of the vulnerable bootloaders that BlackLotus depends on happens, we are concerned that things will change rapidly should this bootkit gets into the hands of the well-known crimeware groups, based on the bootkit’s easy deployment and crimeware groups’ capabilities for spreading malware using their botnets.

There are several articles or posts summarising information about BlackLotus (here, here and here and many more…), all based on the information provided by the bootkit developer on underground hacking forums. So far, no one has confirmed or disproved these claims.

Here is our summary of the claims from the available publications compared with what we discovered while reverse engineering the bootkit samples:

Based on these facts, we believe with high confidence that the bootkit we discovered in the wild is the BlackLotus UEFI bootkit.

A simplified scheme of the BlackLotus compromise chain is shown in Figure 2. It consists of three main parts:

Figure 2. BlackLotus simplified execution overview

Even though we believe this is the BlackLotus UEFI bootkit, we did not find any reference to this name in the samples we analyzed. Instead, the code is full of references to the Higurashi When They Cry anime series, for example in individual component names, such as higurashi_installer_uac_module.dll and higurashi_kernel.sys, and also in the self-signed certificate used to sign the bootkit binary (shown in Figure 3).

Figure 3. Self-signed certificate used by the BlackLotus bootkit

Additionally, the code decrypts but never uses various strings containing messages from the BlackLotus author (as shown in Figure 4 – note, that hasherezade is a well-known researcher and author of various malware-analysis tools), or just some random quotes from various songs, games, or series.

Figure 4. Example of messages left in the code by the BlackLotus author

We start with analysis of the BlackLotus installers. The bootkit seems to be distributed in a form of installers that come in two versions – offline and online. The difference between these two is in the way they obtain legitimate (but vulnerable) Windows binaries, later used for bypassing Secure Boot.

The goal of the installer is clear – it’s responsible for disabling Windows security features such as BitLocker disk encryption and HVCI, and for deployment of multiple files, including the malicious bootkit, to the ESP. Once finished, it reboots the compromised machine to let the dropped files do their job – to make sure the self-signed UEFI bootkit will be silently executed on every system start, regardless of UEFI Secure Boot protection status.

When the installer is executed, it checks whether it has enough privileges (at least admin required) to deploy the rest of the files to the ESP and perform other actions requiring elevated process – like turning off HVCI or disabling BitLocker. If it’s not the case, it tries to elevate by executing the installer again by using the UAC bypass method described in detail here: UAC bypass via Program Compatibility assistant.

With the necessary privileges, it continues, checking the UEFI Secure Boot status by reading the value of the SecureBoot UEFI variable using an available Windows API function, and determining the Windows version by directly accessing the KUSER_SHARED_DATA structure fields NtMajorVersion and NtMinorVersion in memory. It does so to decide whether or not bypassing UEFI Secure Boot is necessary to deploy the bootkit on the victim’s system (since Secure Boot support was first added in Windows 8 and might not be enabled on any given machine).

Before proceeding to the next steps, it renames the legitimate Windows Boot Manager (bootmgfw.efi) binary located in the ESP:\EFI\Microsoft\Boot\ directory to winload.efi. This renamed bootmgfw.efi backup is later used by the bootkit to launch the OS, or to recover the original boot chain if the “uninstall” command is received from the C&C server – more in the C&C communication section.

If UEFI Secure Boot is enabled, the installer proceeds with dropping multiple files into the ESP:/EFI/Microsoft/Boot/ and ESP:/system32/ directories. While the former is a standard directory used by Windows, the latter is a custom folder created by the installer.

A list of files dropped by the installer with a short explanation of the role of each file in the execution chain is provided in Table 1. We will explain in detail how the execution chain works later; now just note that several legitimate Microsoft-signed files are dropped along with the malicious ones.

Table 1. Files deployed by the BlackLotus installer on systems with UEFI Secure Boot enabled

In cases when the victim is running a Windows version not supporting UEFI Secure Boot, or in the case when it’s disabled, the deployment is quite straightforward. The only thing that is needed to deploy the malicious bootkit is to replace the existing Windows Boot Manager (bootmgfw.efi) binary in the ESP:\EFI\Microsoft\Boot\ directory, with the attackers’ own self-signed malicious UEFI application. Since UEFI Secure Boot is disabled (and thus no integrity verification is performed during the boot), exploitation is not necessary and the UEFI firmware simply executes the malicious boot manager without causing any security violations.

To be able to run custom unsigned kernel code later, the installer has to make sure that HVCI is disabled on the system. One of our ESET colleagues wrote a very informative blogpost on this topic in 2022 (Signed kernel drivers – Unguarded gateway to Windows’ core):

Virtualization-based security (VBS) offers several protection features with the most prominent one being Hypervisor-Protected Code Integrity (HVCI), which also comes as a standalone feature. HVCI enforces code integrity in the kernel and allows only signed code to be executed. It effectively prevents vulnerable drivers from being abused to execute unsigned kernel code or load malicious drivers (regardless of the exploitation method used) and it seems that malware abusing vulnerable drivers to load malicious code was one of the main motivations behind Microsoft implementing this feature.

As shown in Figure 5, to disable this feature, the installer sets the Enabled registry value under the HypervisorEnforcedCodeIntegrity registry key to zero.

Figure 5. Hex-Rays decompiled code of BlackLotus installer function responsible for disabling HVCI

The next feature deactivated by the installer is BitLocker Drive Encryption. The reason for this is that BitLocker can be used in a combination with Trusted Platform Module (TPM) to ensure that various boot files and configurations, including Secure Boot, haven’t been tampered with since BitLocker drive encryption was configured on the system. Considering that the installer modifies the Windows boot chain on a compromised machine, keeping BitLocker on for systems with TPM support would lead to a BitLocker recovery screen at the next bootup and would tip the victim off that the system had been compromised.

To disable this protection, the BlackLotus installer:

With the necessary protections disabled and all files deployed, the installer registers itself to be deleted during the next system restart and reboots the machine to proceed to the exploitation of CVE-2022-21894.

In this part, we take a closer look at how BlackLotus achieves persistence on systems with UEFI Secure Boot enabled. As the execution chain we are about to describe is quite complex, we will first explain basic principles and then dig deeper into technical details.

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

To make the detailed analysis in the next two sections easier, we will follow the steps shown in the execution diagram, Figure 6.

Figure 6. Bypassing Secure Boot and setting up persistence using MOK

To bypass Secure Boot, BlackLotus uses the baton drop (CVE-2022-21894): Secure Boot Security Feature Bypass Vulnerability. Despite its high impact on system security, this vulnerability did not get as much public attention as it deserved. Although the vulnerability was fixed in Microsoft’s January 2022 update, its exploitation is still possible because the affected binaries have still not been added to the UEFI revocation list. As a result, attackers can bring their own copies of vulnerable binaries to their victims’ machines to exploit this vulnerability and bypass Secure Boot on up-to-date UEFI systems.

Moreover, a Proof of Concept (PoC) exploit for this vulnerability has been publicly available since August 2022. Considering the date of the first BlackLotus VirusTotal submission (see Figure 1), the malware developer has likely just adapted the available PoC to their needs without any need of deep understanding of how this exploit works.

Let’s start with a brief introduction to the vulnerability, mostly summarizing key points from the write-up published along with the PoC on GitHub:

Now, we continue with describing how BlackLotus exploits this vulnerability (numbers in the list below describe corresponding steps in Figure 6):

The attacker needs to ensure the serialised Secure Boot Policy is allocated above a known physical address.[…]

The avoidlowmemory element can be used to ensure all allocations of physical memory are above a specified physical address. • Since Windows 10, this element is disallowed if VBS is enabled, but as it is used during boot application initialisation, before the serialised Secure Boot policy is read from memory, loading bootmgr and specifying a custom BCD path (using bcdfilepath element aka custom:22000023) can be used to bypass this.

Figure 7. Legitimate BCD store (BEFORE) vs the one used by the BlackLotus installer (AFTER)

Figure 8. Second BCD dropped by the BlackLotus installer – used to exploit CVE-2022-21894

And this is where the magic happens. As the serialized Secure Boot policy should be loaded in physical addresses above 0x10000000 (because of avoidlowmemory used in previous steps), specifying the truncatememory element will effectively remove it – thus, break the Secure Boot and allow the use of dangerous BCD options like nointegritychecks or testsigning. By using these options, the attackers can make the hvloader.efi execute their own, self-signed code.

Figure 9. Hex-Rays decompilation of the BtLoadUpdateDll function from the legitimate hvloader.efi, responsible for loading mcupdate_*.dll

Figure 10. Hex-Rays decompiled code of the malicious self-signed mcupdate*.dll binary

Now, the MokInstaller can proceed with setting up persistence by enrolling the attackers’ MOK into the NVRAM variable and setting up the legitimate Microsoft-signed shim binary as a default bootloader. Before proceeding to details, a little theory about shim and MOK.

shim is a first stage UEFI bootloader developed by Linux developers to make various Linux distributions work with UEFI Secure Boot. It’s a simple application and its purpose is to load, verify, and execute another application – in case of Linux systems, it’s usually the GRUB bootloader. It works in a way that Microsoft signs only a shim, and the shim takes care of the rest – it can verify the integrity of a second-stage bootloader by using keys from db UEFI variable, and also embeds its own list of “allowed” or “revoked” keys or hashes to make sure that components trusted by both – platform and shim developer (e.g. Canonical, RedHat, etc.,) – are allowed to be executed. In addition to these lists, shim also allows the use of an external keys database managed by the user, known as the MOK list. Figure 11 nicely illustrates how UEFI Secure Boot with MOK works.

This MOK database is stored in a Boot-only NVRAM variable named MokList. Without exploiting a vulnerability like the one described above, physical access is required to modify it on a system with UEFI Secure Boot enabled (it’s available only during boot, before the OS loader calls the UEFI Boot Services function ExitBootServices). However, by exploiting this vulnerability, attackers are able to bypass UEFI Secure Boot and execute their own self-signed code before a call to ExitBootServices, so they can easily enroll their own key (by modifying the MokList NVRAM variable) to make the shim execute any application – signed by that enrolled key – without causing a security violation.

Figure 11. MOK boot process overview (image source)

Code performing the actions described in the last two steps is shown in Figure 12.

Figure 12. Hex-Rays decompiled code – MokInstaller UEFI app setting up persistence for the BlackLotus bootkit

Once the persistence is configured, the BlackLotus bootkit is executed on every system start. The bootkit’s goal is to deploy a kernel driver and a final user-mode component – the HTTP downloader. During its execution, it tries to disable additional Windows security features – Virtualization-Based Security (VBS) and Windows Defender – to raise the chance of successful deployment and stealthy operation. Before jumping to the details about how that is done, let’s summarize the basics about the kernel driver and HTTP downloader:

The full execution flow (simplified), from the installer to HTTP downloader, is shown in Figure 13. We describe these individual steps in more detail in the next section.

Figure 13. Diagram showing execution of the BlackLotus UEFI bootkit

Execution steps are as follows (these steps are shown in Figure 13):

Figure 14. Hex-Rays decompiled code of OslArchTransferToKernel hook – patching Windows Defender drivers and searching for the disk.sys entry point

The kernel driver is responsible for four main tasks:

Let’s look at them one by one.

The kernel driver is responsible for deployment of the HTTP downloader. When the driver starts, it waits until the process named winlogon.exe starts, before taking any other actions. Once the process has started, the driver decrypts the HTTP downloader binary, injects it into winlogon.exe’s address space, and executes it in a new thread. Then, the driver keeps periodically checking whether the thread is still running, and repeats the injection if necessary. The HTTP downloader won’t be deployed if a kernel debugger is detected by the driver.

To protect the bootkit’s files located on the ESP, the kernel driver uses a simple trick. It opens all files it wants to protect, duplicates and saves their handles, and uses the ObSetHandleAttributes kernel function specifying the ProtectFromClose flag inside HandleFlags (OBJECT_HANDLE_FLAG_INFORMATION) parameter to 1 – thus protecting the handles from being closed by any other processes. This will thwart any attempts to remove or modify the protected files. The following files are protected:

Should a user try to delete these protected files, something like what is shown in Figure 15 will occur.

Figure 15. An attempt to delete the files protected by BlackLotus driver

As another layer of protection, in case the user or security software would be able to unset the protection flag and close the handles, the kernel driver continuously monitors them, and causes a BSOD by calling the KeBugCheck(INVALID_KERNEL_HANDLE) function if any of the handles don’t exist anymore.

The kernel driver also tries to disarm the main Windows Defender process – MsMpEng.exe. It does so by removing all process’s token privileges by setting the SE_PRIVILEGE_REMOVED attribute to each of them. As a result, the Defender process should not be able to do its job – such as scanning files – properly. However, as this functionality is poorly implemented, it can be made ineffective by restarting the MsMpEng.exe process.

The kernel driver is capable of communicating with the HTTP downloader by using a named Event and Section. Names of the named objects used are generated based on the victim’s network adapter MAC address (ethernet). If a value of an octet is lower than 16, then 16 is added to it. The format of the generated objects names might vary in different samples. As an example, in one of the samples we analyzed, for the MAC address 00-1c-0b-cd-ef-34, the generated names would be:

In case the HTTP downloader wants to pass some command to the kernel driver, it simply creates a named section, writes a command with associated data inside, and waits for the command to be processed by the driver by creating a named event and waiting until the driver triggers (or signals) it.

The driver supports the following self-explanatory commands:

A careful reader might notice the BlackLotus weak point here – even though the bootkit protects its components against removal, the kernel driver can be tricked to uninstall the bootkit completely by creating the abovementioned named objects and sending the uninstall command to it.

The final component is responsible for communication with a C&C server and execution of any C&C commands received from it. All payloads we were able to discover contain three commands. These commands are very straightforward and as the section name suggests, it’s mostly about downloading and executing additional payloads using various techniques.

To communicate with its C&C, the HTTP loader uses the HTTPS protocol. All information necessary for the communication is embedded directly in the downloader binary – including C&C domains and HTTP resource paths used. The default interval for communication with a C&C server is set to one minute, but can be changed based on the data from the C&C. Each communication session with a C&C starts with sending a beacon HTTP POST message to it. In samples we analyzed, the following HTTP resource paths can be specified in the HTTP POST headers:

The beacon message data is prepended with a checkin= string, containing basic information about the compromised machine – including a custom machine identifier (referred to as HWID), UEFI Secure Boot status, various hardware information, and a value that seems to be a BlackLotus build number. HWID is generated from the machine MAC address (ethernet) and a system volume serial number. The format of the message before encryption is as seen in Figure 16

Figure 16. Format of beacon message

Before sending the message to the C&C, the data is first encrypted using an embedded RSA key, then URL-safe base64 encoded. During the analysis, we found two different RSA keys being used in the samples. An example of such an HTTP beacon request is shown in Figure 17.

Figure 17. Example of a beacon HTTP POST message (generated by a sample from VirusTotal – the one with local IPs instead of real C&C addresses)

Data received from the C&C as a response to the beacon message should start with the two-byte magic value HP; otherwise, the response is not processed further. If the magic value is correct, the data following the magic value is decrypted using 256-bit AES in CBC mode with abovementioned HWID string used as the key.

After decryption, the message is similar to the beacon, a JSON-formatted string, and specifies a command identifier (referred to as Type) and various additional parameters such as:

All supported commands and their descriptions are listed in Table 2.

Table 2. C&C commands

In these commands, the C&C can specify, whether the payload should first be dropped to disk before executing it, or be executed directly in memory. In cases involving dropping the file to disk, the ProgramData folder on the OS volume is used as the destination folder and filename and extension are specified by the C&C server. In the case of executing files directly in memory, svchost.exe is used as an injection target. When the C&C sends a command requiring kernel driver cooperation, or an operator wants to execute code in kernel-mode, the mechanism described in the Communication with the HTTP downloader section is used.

To make detection and analysis of this piece of malware harder, its author tried to limit visibility of standard file artifacts, such as text strings, imports, or other unencrypted embedded data to a minimum. Below is a summary of the techniques used.

Many critical vulnerabilities affecting security of UEFI systems have been discovered in the last few years. Unfortunately, due the complexity of the whole UEFI ecosystem and related supply-chain problems, many of these vulnerabilities have left many systems vulnerable even a long time after the vulnerabilities have been fixed – or at least after we were told they were fixed. For a better image, here are some examples of the patch or revocation failures allowing UEFI Secure Boot bypasses just from the last year:

It was just a matter of time before someone would take advantage of these failures and create a UEFI bootkit capable of operating on systems with UEFI Secure Boot enabled. As we suggested last year in our RSA presentation, all of this makes the move to the ESP more feasible for attackers and a possible way forward for UEFI threats – the existence of BlackLotus confirms this.

This table was built using version 12 of the MITRE ATT&CK framework.