The article describes the first known case of a UEFI bootkit capable of bypassing UEFI Secure Boot protection. For the first time, researchers at ESET have published an analysis of this bootkit, which is capable of running even on the latest fully updated Windows 11 systems with UEFI Secure Boot enabled. BlackLotus, which has been selling for $5,000 on hacker forums since October 2022, is a powerful threat because it has full control over the OS boot process, can disable various OS security mechanisms, and deploy its own payloads during the early stages of OS startup. This allows him to operate very covertly and with high privileges.
Disclaimer: This article is intended for educational purposes. It describes the workings of the BlackLotus UEFI bootkit, to show how such threats can bypass Secure Boot protection, and to help you understand how to better defend against such attacks.
The number of UEFI vulnerabilities discovered in recent years and the failure to patch them or recall vulnerable binaries within a reasonable period of time has not gone unnoticed by threat actors. As a result, the first well-known UEFI bootkit that bypasses an important security feature of the platform – UEFI Secure Boot – became a reality. In this blog post, we present the first public analysis of this UEFI bootkit, which can work even on fully upgraded Windows 11 systems with UEFI Secure Boot enabled. The functionality of the bootkit and its individual features lead us to believe that we are dealing with a bootkit known as BlackLotus, a UEFI bootkit that has been selling on hacker forums for $5,000 since at least October 2022.
UEFI bootkits are very powerful threats that have full control over the OS boot process and are thus capable of disabling various OS security mechanisms and deploying their own kernel-mode or user-mode payloads during the early stages of OS startup. 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 (such as the numerous malicious EFI samples we discovered in 2020, or full-featured UEFI bootkits such as our discovery last year – the ESPecter bootkit – or the FinSpy bootkit discovered by Kaspersky researchers ).
UEFI bootkits can lose stealth compared to firmware implants like LoJax; the first UEFI firmware implant in the wild 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 multi-layered security of SPI flash, such as the BWE, BLE, and PRx security bits, or hardware-provided security (e.g. Intel Boot Guard). ). Of course, UEFI Secure Boot stands in the way of UEFI bootkits, but there are a small number of known vulnerabilities that bypass this important security mechanism. And the worst part is that some of them are still easy to use on updated systems even at the time of this writing, including the one used by BlackLotus.
Our investigation began with several calls to what turned out to be a BlackLotus user mode component – an HTTP loader – in our late 2022 telemetry. After initial evaluation, the code patterns found in the samples led us to discover six BlackLotus installers (both on VirusTotal and in our own telemetry). This allowed us to investigate the entire chain of execution and understand that we are dealing with no ordinary malware.
Below are the key points about BlackLotus and the timeline of the series of events surrounding it:
It is capable of running on the latest, fully patched Windows 11 systems with UEFI Secure Boot enabled.
It uses a vulnerability from over a year ago (CVE-2022-21894) to bypass UEFI Secure Boot and configure persistence for the bootkit. This is the first publicly known exploitation of this vulnerability in the wild.
Although the vulnerability was fixed in Microsoft’s January 2022 update, it is still possible to exploit it because the affected properly signed binaries have not yet been added to the UEFI revocation list. BlackLotus exploits this by delivering its own copies of legitimate, but vulnerable, binaries to the system to exploit the vulnerability.
It is capable of disabling OS security mechanisms such as BitLocker, HVCI and Windows Defender.
Once installed, the main purpose of the bootkit is to deploy a kernel driver (which, among other things, protects the bootkit from being deleted) and an HTTP loader responsible for communicating with C&C and capable of loading additional user-mode or kernel-mode payloads. .
BlackLotus has been advertised and sold on underground forums since at least October 6, 2022. In this blog post, we provide proof that the bootkit is real and the ad is not just a scam.
Interestingly, some of the BlackLotus installers we analyzed do not proceed with the bootkit installation if the compromised host uses one of the following locales:
Romanian (Moldova), ro-MD
Russian (Moldova), ru-MD
Russian (Russia), ru-RU
Ukrainian (Ukraine) , uk-UA
Belarusian (Belarus), be-BY
Armenian (Armenia), hy-AM
Kazakh (Kazakhstan), kk-KZ
A timeline of individual events related to BlackLotus is shown in Figure 1.
As already mentioned, the bootkit has been sold on underground forums since at least October 6, 2022. At this time, we are unable to determine from our telemetry the exact distribution channel used to deploy the bootkit to victims. The small number of BlackLotus samples we were able to obtain from both public sources and our telemetry lead us to believe that not many threat actors have started using it yet. But until the vulnerable bootloaders that BlackLotus depends on are withdrawn, we are concerned that the situation will change quickly if this bootkit gets into the hands of known malware groups, based on the ease of deployment of the bootkit and the capabilities of malware groups to distribute malware , which uses their botnets.
There are several articles or posts summarizing information about BlackLotus all of which are based on information provided by the bootkit developer on underground hacking forums. So far, no one has confirmed or denied these claims.
Here’s our summary of the claims from the available publications compared to what we found when reverse-engineering sample bootkits:
BlackLotus is advertised on hacking forums as having a built-in bypass of Secure Boot . Adding vulnerable drivers to the UEFI recall list is currently not possible because the vulnerability affects hundreds of bootloaders still in use. ✅
Truth: It uses CVE-2022-21894 to break Secure Boot and achieve persistence on UEFI-Secure-Boot enabled systems. The vulnerable drivers it uses are still not patched in the latest version of dbx at the time of writing.
BlackLotus advertising on hacker forums claims that the bootkit has built-in Ring0/Kernel protection against deletion. ✅
True: Its kernel driver protects the descriptors belonging to its files in the EFI system partition (ESP) from being closed. As an additional layer of protection, these descriptors are constantly monitored and a blue screen of death (BSOD) is triggered if any of these descriptors are closed, as described in the section “Protecting Boot Package Files on ESP from Deletion”.
BlackLotus is advertised on hacker forums as being equipped with anti-virtual machine (anti-VM), anti-debugging, and code obfuscation features to block malware analysis attempts. ✅
Truth: It contains various VM protection, anti-debugging, and obfuscation techniques to make copying or analysis difficult. However, we are definitely not talking about any breakthrough or advanced anti-analysis techniques, as they can be easily overcome with little effort.
BlackLotus is advertised on hacker forums as claiming that its purpose is to act as an HTTP loader. ✅
True: Its last component acts as an HTTP loader, as described in the HTTP loader section
BlackLotus’ ads on hacker forums claim that the HTTP loader runs under the SYSTEM account in a legitimate process. ✅
True: Its HTTP loader runs in the context of the winlogon.exe process.
BlackLotus is advertised on hacking forums as a tiny bootkit with a disk size of only 80KB. ✅
Truth: The samples we were able to obtain are indeed around 80KB.
BlackLotus is advertised on hacking forums as claiming that it can disable built-in Windows defenses such as HVCI, Bitlocker, Windows Defender and bypass User Account Control (UAC). ✅
Truth: It can disable HVCI, Windows Defender, BitLocker and bypass UAC.
Based on these facts, we believe with high confidence that the bootkit we found in the wild is the BlackLotus UEFI bootkit.
A simplified diagram of the BlackLotus compromise chain is shown in Figure 2. It consists of three main parts:
It starts by running the installer (step 1 in Figure 2), which is responsible for deploying the boot package files to the EFI system partition, disabling HVCI and BitLocker, and then rebooting the machine.
After the first reboot, exploits CVE-2022-21894 and subsequently registers the attackers’ machine owner key (MOK) to achieve persistence even on systems with UEFI Secure Boot enabled. After that, the computer restarts again (steps 2-4 in Figure 2).
During all subsequent boots, the self-signed UEFI bootkit executes and deploys both the kernel driver and the user-mode payload, the HTTP bootloader. Together, these components can download and execute additional user mode and driver components from the C&C server and protect the bootkit from being deleted (steps 5–9 in Figure 2).
Although we believe this to be 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 anime series Higurashi When They Cry, such as in the names of individual components such as higurashi_installer_uac_module.dll and higurashi_kernel.sys, and in the self-signed certificate used to sign the bootkit binary (shown in Figure 3).
Also, the code decodes but never uses various lines containing messages from the author of BlackLotus (as shown in Figure 4 – note that Hasherezada is a well-known researcher and author of various malware analysis tools), or just some random quotes from various songs, games or TV shows.
Let’s start with the analysis of BlackLotus installers. It seems that the bootkit is distributed in the form of installers, which are available in two versions – offline and online. The difference between the two is how they obtain legitimate (but vulnerable) Windows binaries that are later used to bypass Secure Boot.
In offline versions, the Windows binaries are built into the installer
The online versions download Windows binaries directly from the Microsoft Symbol Store. So far we have observed the following Windows binaries exploiting the BlackLotus bootloader:
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
The installer’s purpose is clear – it is responsible for disabling Windows security features such as BitLocker and HVCI disk encryption, and for deploying several files, including a malicious bootloader, to the ESP. Once complete, it reboots the compromised machine to allow the deleted files to do their work – to ensure that the self-signed UEFI boot package will execute silently every time the system boots, regardless of the UEFI Secure Boot protection status.
When the installer runs, it checks that it has sufficient privileges (at least administrator rights are required) to deploy the rest of the files to the ESP and perform other actions that require an elevated process, such as disabling HVCI or BitLocker. If it doesn’t, it tries to level up by re-running the installer using the UAC bypass method detailed here: Bypassing UAC with the Application Compatibility Assistant.
With the necessary privileges, it continues by checking the UEFI Secure Boot state, reading the value of the SecureBoot UEFI variable using an available Windows API function, and determining the Windows version by directly accessing the NtMajorVersion and NtMinorVersion fields of the KUSER_SHARED_DATA structure in memory. This is done to decide if a UEFI Secure Boot bypass is required to deploy the bootkit on the victim system (since support for Secure Boot was first added in Windows 8 and may not be enabled on any machine).
It renames the legitimate Windows Boot Manager binary (bootmgfw.efi) located in the ESP:\EFI\Microsoft\Boot\ directory to winload.efi before proceeding to the next steps. This renamed bootmgfw.efi backup is later used by bootkit to boot the OS or to restore the original boot chain if a “remove” command is received from the C&C server – see C&C communication for details.
If UEFI Secure Boot is enabled, the installer continues to move several files to the ESP:/EFI/Microsoft/Boot/ and ESP:/system32/ directories. While the former is a standard directory used by Windows, the latter is a special folder created by the installer.
A list of files removed by the installer, with a brief explanation of each file’s role in the execution chain, is shown in Table 1. We’ll explain in detail how the execution chain works later; now just note that several legitimate files signed by Microsoft are deleted along with the malicious ones.
Files deployed by the BlackLotus installer on systems with UEFI Secure Boot enabled
ESP:\EFI\Microsoft\Bootgrubx64.efi – BlackLotus bootkit, a malicious self-signed UEFI program.
bootload.efi – A legitimate Microsoft-signed shim file that replaces bootmgfw.efi after exploiting CVE-2022-21894.
bootmgfw.efi – A vulnerable Windows boot loader file (CVE-2022-21894).
BCD – The attackers’ special repository for CVE-2022-21894.
BCDR – A backup of the victim’s original BCD.
ESP:\system32hvloader.efi – Vulnerable Windows Hypervisor Loader File (CVE-2022-21894).
bootmgr.efi – Vulnerable Windows Boot Manager File (CVE-2022-21894).
mcupdate_AuthenticAMD.dll – Malicious file for CVE-2022-21894 (AMD).
mcupdate_GenuineIntel.dll – Malicious file for CVE-2022-21894 (Intel).
BCD – Attacker-specific BCD for CVE-2022-21894.
In cases where the victim is using a version of Windows that does not support UEFI Secure Boot, or if it is disabled, the deployment is fairly straightforward. All it takes to deploy a malicious bootkit is to replace the existing Windows Boot Manager binary (bootmgfw.efi) in the ESP:\EFI\Microsoft\Boot\ directory with the attackers’ own self-signed UEFI malware. Since UEFI Secure Boot is disabled (and thus no integrity checks are performed during boot), no exploit is required and the UEFI firmware simply runs the malicious boot manager without causing any security breaches.
To be able to run custom unsigned kernel code later, the installer must ensure that HVCI is disabled on the system. One of our colleagues at ESET wrote a very informative blog post on this topic in 2022 (Signed Kernel Drivers – An Insecure Gateway to the Windows Kernel):
Virtualization-based security (VBS) offers several protection features, the most notable of which is Hypervisor-Protected Code Integrity (HVCI), which is also delivered as a separate feature. HVCI enforces code integrity in the kernel and allows only signed code to be executed. This effectively prevents exploiting vulnerable drivers to execute unsigned kernel code or download malicious drivers (regardless of the exploit method used), and it appears that malware exploiting vulnerable drivers to download malicious code was one of Microsoft’s main motivations for implementing this feature .
As shown in Figure 5, to disable this feature, the installer sets the Enabled registry value in the HypervisorEnforcedCodeIntegrity registry key to zero.
The next feature that the installer disables is BitLocker Drive Encryption. The reason for this is that BitLocker can be used in conjunction with the Trusted Platform Module (TPM) to ensure that various boot files and configurations, including Secure Boot, have not been tampered with because BitLocker disk encryption has been configured on the system. Given that the installer modifies the Windows boot chain on the compromised machine, enabling BitLocker for TPM-enabled systems will cause the BitLocker recovery screen to appear on the next boot and inform the victim that the system has been compromised.
To disable this protection, the BlackLotus installer:
looks at all volumes in the WMI namespace Root\CIMV2\Security\MicrosoftVolumeEncryption and checks their protection status by calling the GetProtectionStatus method of the Win32_EncryptableVolume WMI class
for those protected by BitLocker, it calls the DisableKeyProtectors method with the DisableCount parameter set to zero, which means that protection will be suspended until it is manually enabled
When the required protection is disabled and all files are deployed, the installer registers itself for removal at the next system reboot and reboots the machine to switch to using CVE-2022-21894.
In this installment, we’ll take a closer look at how BlackLotus achieves stability on systems with UEFI Secure Boot enabled. Since the execution chain we are going to describe is quite complex, we will first explain the basic principles and then delve into the technical details.
In a nutshell, this process consists of two key steps:
Exploitation of CVE-2022-21894 to bypass the Secure Boot feature and install a bootkit. This allows arbitrary code to be executed in the early stages of boot when the platform is still in firmware and UEFI Boot Services features are still available. This allows attackers to do many things they shouldn’t on a computer with UEFI Secure Boot enabled without having physical access to it, such as changing NVRAM variables for boot services only. And this is what attackers use to set up persistence for the bootkit in the next step. See CVE-2022-21894 Usage for more information on usage.
Setting up persistence by writing your own MOK to MokList, an NVRAM variable for boot services only. By doing this, it can use a legitimate Microsoft-signed patch to load its self-signed (signed with a private key that belongs to a key recorded in the MokList) UEFI bootkit instead of exploiting the vulnerability on every boot. More on this in the Bootkit storage section.
To facilitate the detailed analysis in the next two sections, we follow the steps shown in the execution diagram, Figure 6.
To bypass Secure Boot, BlackLotus uses a bug (CVE-2022-21894): Secure Boot Security Feature Bypass Vulnerability. Despite the large impact on system security, this vulnerability has not received the public attention it deserves. Although the vulnerability was patched in Microsoft’s January 2022 update, it is still possible to exploit it because the affected binaries have not yet been added to the UEFI recall list. As a result, attackers can transfer their own copies of the vulnerable binaries to their victims’ computers in order to exploit the vulnerability and bypass Secure Boot on the latest UEFI systems.
Additionally, a Proof of Concept (PoC) exploit for this vulnerability was publicly available as of August 2022. Considering the date of BlackLotus’ first submission to VirusTotal (see Figure 1), the malware developer likely just adapted the available PoC to their needs without any need for a deep understanding of how the exploit works.
Let’s start with a quick introduction to the vulnerability, mostly recapitulating the key points from the description shared with the PoC on GitHub:
Affected Windows bootloaders (eg bootmgr.efi, hvloader.efi, winload.efi…) allow the serialized secure boot policy to be removed from memory – before the program loads it – using the truncatememory BCD boot option.
This allows attackers to use other dangerous BCD options, such as bootdebug, testsigning, or nointegritychecks, thus breaking Secure Boot.
There are various ways to exploit this vulnerability – three of them are published in the PoC repository.
As an example, one of the PoCs shows how this can be used to force a legitimate hvloader.efi to load an arbitrary self-signed mcupdate_<platform>.dll binary (where <platform> can be GenuineIntel or AuthenticAMD, based on the computer’s CPU.).
We now continue with a description of how BlackLotus exploits this vulnerability (the numbers in the list below describe the corresponding steps in Figure 6):
After the installer reboots the machine, the UEFI firmware will load the first boot option. For Windows systems, the default first boot option is bootmgfw.efi located in the ESP:/EFI/Microsoft/Boot folder on the ESP. This time, instead of executing the victim’s initial bootmgfw.efi (which the installer had previously renamed to winload.efi), the firmware executes the vulnerable file – deployed by the installer.
After bootmgfw.efi is executed, the BCD boot options previously modified by the installer are loaded. Figure 7 shows a comparison between the legal BCD and the modified one.
As you can see in Figure 7 (the path highlighted in green), a legitimate Windows boot manager usually loads the Windows bootloader (\WINDOWS\system32\winload.efi) as the default boot program. But this time, with the changed BCD, it continues to load the vulnerable ESP:\system32\bootmgr.efi, with the Avoidlowmemory BCD value 0x10000000 and the custom:22000023 BCD element pointing to another attacker’s BCD stored in ESP:\system32 \bcd. An explanation of the usage of these elements can be found in the published PoC:
An attacker must ensure that the serialized secure boot policy is placed over a known physical address. […] The Avoidlowmemory element can be used to ensure that all physical memory allocations exceed the specified physical address.
Starting with Windows 10, this element is disabled if VBS is enabled, but because it is used during bootloader initialization, before the serialized secure boot policy is read from memory, bootmgr loads and specifies a custom BCD path (using the bcdfilepath element, also known as custom: 22000023 ) can be used to work around this.
In the next step, the executed ESP:\system32\bootmgr.efi loads the additional BCD located in ESP:\system32\bcd. The parsed contents of this additional BCD are shown in Figure 8.
Through the parameters loaded from the BCD file shown in Figure 8, bootmgr.efi proceeds to load another vulnerable Windows bootloader deployed by the installer – ESP:\system32\hvloader.efi – which is the Windows hypervisor loader. More importantly, additional BCD parameters are specified in the same BCD file (see Figure 8):
truncatememory with a value of 0x10000000
nointegritychecks is set to Yes
and testsigning is also set to Yes
And this is where the magic happens. Since the serialized safeload policy must be loaded to physical addresses higher than 0x10000000 (due to the Avoidlowmemory parameter applied in the previous steps), specifying the truncatememory element will effectively remove it – thus breaking the safeload and allowing unsafe BCD options such as nointegritychecks or testsigning. By using these options, attackers can force hvloader.efi to execute their own self-signed code.
This uses the same trick described in the PoC: when it executes, the legitimate hvloader.efi downloads and executes the mcupdate_{GenuineIntel| AuthenticAMD}.dll binary from the <device>:\<SystemRoot>\system32\ directory. The decompiled Hex-Rays code of the function from hvloader.efi responsible for loading this mcupdate*.dll binary is shown in Figure 9. Note that hvloader.efi normally loads this legitimate mcupdate*.dll binary from <OS_partition>: \ Windows\system32, but this time the attackers’ self-signed mcupdate*.dll is executed from a special ESP directory pre-created by the installer (ESP:\system32). This is because the BCD options device and systemroot used in BCD in Figure 8 specify the current device as the boot device – that is, ESP – and also specify that SystemRoot is the root (\) directory on that device.
Now that the attackers own self-signed mcupdate*.dll file is loaded and executed, it continues the execution of the last component in this chain – the built-in MokInstaller (a UEFI application) – see Figure 10 to see how this is done.
MokInstaller can now proceed with the persistence setup by registering the attackers’ MOK in the NVRAM variable and setting a legitimate Microsoft-signed patch binary as the default bootloader. Before we get into the details, a bit of theory about gasketing and MOK.
shim is a first-stage UEFI bootloader designed by Linux developers to enable various Linux distributions to work with UEFI Secure Boot. It’s a simple program that aims to load, verify, and run another program – usually the GRUB bootloader in the case of Linux systems. The way it works is that Microsoft only signs the shim and the shim takes care of the rest – it can check the integrity of the second-stage bootloader using keys from the UEFI db variable, and it also inserts its own list of “allowed” or “revoked” keys or hashes to make sure , that components trusted by both platforms and shim developers (eg Canonical, RedHat, etc.) are allowed to run. In addition to these lists, shim also allows the use of an external user-managed key database known as the MOK list. Figure 11 illustrates well how UEFI Secure Boot works with MOK.
This MOK database is stored in a load-only NVRAM variable called MokList. Without exploiting a vulnerability like the one described above, physical access is required to change it on a system with UEFI Secure Boot enabled (it’s only available at boot time, before the OS bootloader calls the UEFI Boot Services ExitBootServices function). However, by exploiting this vulnerability, attackers can bypass UEFI Secure Boot and execute their own self-signed code before calling ExitBootServices, so they can easily register their own key (by modifying the MokList NVRAM variable) to perform padding. any application signed with this registered key without compromising security.
Continuing the flow description from Figure 6 – Step 8… The MokInstaller UEFI program continues the storage setup for the BlackLotus UEFI bootkit and covers the exploit paths by doing:
Restoring the victim’s original BCD storage from the backup created by the installer and replacing the efi with a legitimate Microsoft signed pad previously dumped by the installer to ESP:\system32\bootload.efi .
Creating a MokList NVRAM variable containing the attacker’s self-signed public key certificate. Note that this variable is formatted like any other UEFI signature database variable (such as db or dbx) and can consist of zero or more signature lists of type EFI_SIGNATURE_LIST as defined in the UEFI Specification.
Deleting all files involved in the exploit from the attackers’ ESP:\system32\ folder.
Finally, it reboots the machine to force the deployed bootkit to execute the self-signed bootkit that the installer dumped into \EFI\Microsoft\Boot\grubx64.efi (grubx64.efi is usually the default second-stage bootloader that does the bootkit on x86-64 systems).
The code that performs the steps described in the last two steps is shown in Figure 12.
After setting the save, the BlackLotus bootloader is launched every time the system starts. The purpose of the bootkit is to deploy the kernel driver and the final user mode component, the HTTP loader. At runtime, it attempts to disable additional Windows security features – Virtualization-Based Security (VBS) and Windows Defender – to increase the likelihood of successful deployment and stealth. Before we get into the details of how this is done, let’s recap the basics of the kernel driver and HTTP loader:
Let’s deploy the next component of the chain – the HTTP loader.
Keeping the loader alive in case of termination.
Protect bootkit files from being deleted from ESP.
Execution of additional kernel payloads if specified by the HTTP loader.
Remove the bootkit if specified by the HTTP loader.
Communicating with your C&C.
Execution of commands received from C&C.
Load and execute C&C derived payloads (supports both kernel and user mode payloads).
The complete execution flow (simplified) from the installer to the HTTP loader is shown in Figure 13. We describe these individual steps in more detail in the next section.
The execution stages are as follows (these steps are shown in Figure 13):
In the first step, the UEFI firmware executes the default Windows boot option, which is usually stored in the \EFI\Microsoft\Boot\bootmgfw.efi folder. As we described earlier (the Bootkit preservation section, 8 .a), the MokInstaller binary replaced this file with a legitimate signed patch.
When the shim is executed, it reads the MokList NVRAM variable and uses a certificate previously stored by the attackers to verify the second-stage bootloader, a self-signed BlackLotus UEFI bootloader located in \EFI\Microsoft\Boot\grubx64.efi.
Once verified, the gasket executes the bootkit.
The bootkit starts by creating a Boot-only VbsPolicyDisable NVRAM variable. As described here , this variable is evaluated by the Windows bootloader at boot time, and if defined, core VBS features such as HVCI and Credential Guard will not be initialized.
In the following steps (5. a–e), the bootkit follows the general pattern used by UEFI bootkits. It intercepts the execution of components included in the typical Windows boot flow, such as the Windows Boot Manager, the Windows Bootloader, and the Windows OS Kernel, and intercepts some of their functions in memory. As a bonus, it also tries to disable Windows Defender by fixing some of its drivers. All of this is to ensure that the payload is executed early in the OS startup process and avoid detection. The following features have been added or fixed:
ImgArchStartBootApplication in bootmgfw.efi or bootmgr.efi: This function is usually picked up by bootkits to catch the moment when the Windows bootloader (winload.efi) is loaded into memory but still not running – the right moment to perform more memory fixes ‘yati
BlImgAllocateImageBuffer in winload.efi:Used to allocate an additional memory buffer for the malicious kernel driver.
OslArchTransferToKernel in winload.efi: Added to catch the moment when the OS kernel and some system drivers are already loaded into memory but not yet executed – a perfect moment to perform additional in-memory fixes. The drivers mentioned below are fixed in this hook. The code for this hook, which is responsible for searching for the appropriate drivers in memory, is shown in Figure 14.
WdBoot.sys and WdFilter.sys: BlackLotus fixes the entry point of WdBoot.sys and WdFilter.sys – the Windows Defender ELAM driver and the Windows Defender file system filter driver, respectively – to return immediately.
disk.sys: The bootkit hijacks the disk.sys driver entry point to execute the BlackLotus kernel driver during the early stages of system initialization.
Then, when the OS kernel executes the disk.sys driver entry point, the installed hook goes to the malicious kernel driver entry point. The malicious code in turn restores the original disk.sys to ensure proper system operation and waits for the winlogon.exe process to start.
When the malicious driver detects that the winlogon.exe process has started, it injects and executes the last user mode component, the HTTP loader, into it.
The kernel driver is responsible for four main tasks:
Implementing an HTTP loader in winlogon.exe and reintroducing it if the thread has terminated.
Protect bootkit files deployed on ESP from being deleted.
Disable Windows Defender process in user mode MsMpEngine.exe.
Communicating with the HTTP loader and, if necessary, executing any commands.
The kernel driver is responsible for deploying the HTTP loader. When the driver starts, it waits for a process called winlogon.exe to start before doing anything else. After the process starts, the driver decrypts the HTTP loader binary, inserts it into the winlogon.exe address space, and executes it in a new thread. The driver then continues to periodically check to see if the thread is still running and retry the input if necessary. The HTTP loader will not be deployed if the driver detects the kernel debugger.
To protect the bootkit files located on the ESP, the kernel driver uses a simple trick. It opens all the files it wants to protect, duplicates and saves their handles, and uses the ObSetHandleAttributes kernel function to set the ProtectFromClose flag inside the HandleFlags (OBJECT_HANDLE_FLAG_INFORMATION) parameter to 1 – thus protecting the handles from being closed by any other processes. This will prevent any attempts to delete or modify protected files. The following files are protected:
ESP:\EFI\Microsoft\Boot\winload.efi
ESP:\EFI\Microsoft\Boot\bootmgfw.efi
ESP:\EFI\Microsoft\Boot\grubx64.efi
If the user tries to delete these protected files, something like Figure 15 will happen.
As another layer of protection, if the user or security software is able to remove the security flag and close the handles, the kernel driver continuously monitors them and BSODs by calling KeBugCheck(INVALID_KERNEL_HANDLE) if any of the handles no longer exist.
The kernel driver also attempts to disable the main Windows Defender process, MsMpEng.exe. This is done by removing all process token privileges by setting the SE_PRIVILEGE_REMOVED attribute for each one. As a result, the Defender process will not be able to perform its work properly, such as scanning files. However, since this feature is poorly implemented, it can be rendered ineffective by restarting the MsMpEng.exe process.
The kernel driver is able to communicate with the HTTP loader using a named event and section. The names of the named objects used are generated based on the MAC address of the victim’s network adapter (ethernet). If the octet value is less than 16, then 16 is added to it. The format of generated object names may vary between 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:
\BaseNamedObjects\101c1b: For a named partition (only the first three octets of the MAC are used)
\BaseNamedObjects\ Z 01c1b: For Named Event – same as partition but first digit of MAC address is replaced with Z
If the HTTP loader wants to pass some command to the kernel driver, it simply creates a named section, writes the command with the associated data inside, and waits for the command to be processed by the driver, creating a named event and waiting for the driver to fire (or signal) about it.
The driver supports the following clear commands:
Install the kernel driver
Remove BlackLotus
A careful reader may notice a weakness of BlackLotus here—even if the bootkit protects its components from deletion, the kernel driver can be tricked into completely deleting the bootkit by creating the aforementioned named objects and sending it a delete command.
The latter component is responsible for communicating with the C&C server and executing any C&C commands received from it. All payloads we were able to detect contain three commands. These commands are very simple, and as the title of the section suggests, they mostly deal with loading and executing additional payloads using various techniques.
The HTTP loader uses the HTTPS protocol to communicate with its C&C. All information required for communication is built directly into the bootloader binary, including C&C domains used and HTTP resource paths. The default interval for communicating with the C&C server is set to one minute, but can be changed based on data from C&C. Each communication session with C&C begins by sending an HTTP POST beacon message to it. In the samples we analyzed, the following HTTP resource paths can be specified in the HTTP POST headers:
/network/API/hpb_gate[.]php
/API/hpb_gate[.]php
/gate[.]php
/hpb_gate[.]php
The beacon message data is preceded by a checkin= string containing basic information about the compromised machine, including a special machine identifier (referred to as HWID), UEFI secure boot status, various hardware information, and a value that appears to be a BlackLotus build number. The HWID is generated from the MAC address of the machine (ethernet) and the serial number of the system volume. The format of the message before encryption is as shown in Figure 16.
Before sending the message to C&C, the data is first encrypted using an embedded RSA key and then encoded using a secure base64 URL. During analysis, we found that the samples used two different RSA keys. An example of such an HTTP beacon request is shown in Figure 17.
Data received from C&C in response to a beacon message must begin with a two-byte magic HP value; 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 using the above HWID string as the key.
Once decoded, the message is like a beacon, a string in JSON format, and specifies the command identifier (referred to as Type ) and various optional parameters such as:
C&C communication interval
Use the execution method
The name of the payload file
Payload type based on file extension ( .sys , .exe , or .dll supported )
The authentication token that should be used for the payload request
The AES key used to decrypt the payload
All supported commands and their descriptions are listed in Table 2.
C&C commands
Command Type 1 — Load and run a kernel driver, DLL, or regular executable.
Command Type 2 — Load payload, remove bootkit, and run payload (probably used to update bootkit).
Command Type 3 — Remove bootkit and exit.
In these commands, C&C can specify whether the payload should first be flushed to disk before executing it, or whether it should be executed directly in memory. In cases where the file is moved to disk, the ProgramData folder on the OS volume is used as the destination folder, and the file name and extension are specified by the C&C server. When executing files directly in memory, svchost.exe is used as the injection target. When C&C sends a command that requires kernel driver interaction, or the operator wants to execute code in kernel mode, the mechanism described in the HTTP Loader Communication section is used.«Зв’язок із завантажувачем HTTP» .
To make this malware more difficult to detect and analyze, its author tried to minimize the visibility of standard file artifacts such as text strings, imports, or other unencrypted embedded data. Below is a short list of the methods used.
String and data encryption
All strings used in the samples are encrypted using a simple cipher.
All embedded files are encrypted with 256-bit AES in CBC mode.
Encryption keys for individual files may vary from sample to sample.
In addition to AES encryption, some files are also compressed using LZMS.
API resolution at runtime only
In all samples (where applicable), Windows APIs are always resolved exclusively at runtime, and function hashes instead of function names are used to find the required API function addresses in memory.
In some cases, a direct call to the system call instruction is used to call the desired system function.
Network connection
Communicates using HTTPS.
All messages sent to C&C by the HTTP loader are encrypted using the embedded RSA public key.
All messages sent from C&C to the HTTP loader are encrypted with a key obtained from the victim’s machine environment or with an AES key provided by C&C.
Anti-debugging and anti-virtual machine protection tricks – if used, are usually placed right at the beginning of the entry point. Only the usual sandbox or debugger detection tricks are used.
First and foremost, of course, you need to keep your system and its security product up-to-date to increase the likelihood that a threat will be stopped in its tracks before it can reach OS resistance.
Then, a key step to prevent known vulnerable UEFI binaries from being used to bypass UEFI Secure Boot is to revoke them in the UEFI Revocation Database (dbx) – on Windows systems, dbx updates should be distributed via Windows Updates.
The problem is that recalling commonly used Windows UEFI binaries can make thousands of legacy systems, recovery images, or backups unbootable, and therefore the recall often takes too long.
Note that revoking the Windows programs used by BlackLotus will prevent the bootkit from being installed, but since the installer will replace the victim’s bootloader with the revoked one, this may result in the system being unable to boot. To restore in this case, reinstall the OS or simply restore ESP.
If a recall occurs after installing a BlackLotus save, the bootkit will remain functional because it uses a legitimate pad with a special MOK key for the save. In this case, the safest mitigation solution would be to reinstall Windows and remove the MOK key registered by the attackers using the mokutil utility (this operation requires physical presence due to the required user interaction with the MOK Manager during boot).
Over the past few years, many critical vulnerabilities affecting the security of UEFI systems have been discovered. Unfortunately, due to the complexity of the entire UEFI ecosystem and related supply chain issues, many of these vulnerabilities have left many systems vulnerable long after the vulnerabilities have been patched – or at least after we’ve been told they’ve been patched. To give you a better picture, here are some examples of patching or recall bugs that bypass UEFI Secure Boot from just the last year:
First and foremost, of course, is CVE-2022-21894, the vulnerability exploited by BlackLotus. A year after the vulnerability was patched, the vulnerable UEFI binaries have still not been retracted, allowing threats like BlackLotus to run undetected on systems with UEFI Secure Boot enabled, thus giving victims a false sense of security.
In early 2022, we disclosed several UEFI vulnerabilities that could, among other things, disable UEFI Secure Boot. Many of the affected devices are no longer supported by the OEM and therefore not patched (although these devices were not that old at around 3-5 years old when the vulnerability was disclosed). Read more in our blog: When ‘secure’ isn’t secure at all: Serious UEFI vulnerabilities found in Lenovo consumer laptops
Later in 2022, we discovered several other UEFI vulnerabilities, exploiting which would also allow attackers to disable UEFI secure boot very easily. As fellow researchers at Binarly noted, several devices listed in the advisory remained unpatched or were not properly patched even months after the advisory, leaving the devices vulnerable. Needless to say, as in the previous case, some devices will remain vulnerable forever because of their end-of-support date.
It was only a matter of time before someone took advantage of these flaws and created a UEFI bootpack capable of running on systems with UEFI Secure Boot enabled. As we suggested last year in our RSA presentation , all of this makes the move to ESP more feasible for attackers and a possible way forward for UEFI threats – the existence of BlackLotus confirms this.
ESET Research offers private APT reports and data feeds. If you have any questions about this service, please visit the ESET Threat Intelligence page.
912 
1355 
542