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:
- It’s capable of running on the latest, fully patched Windows 11 systems with UEFI Secure Boot enabled.
- It exploits a more than one year old vulnerability (CVE-2022-21894) to bypass UEFI Secure Boot and set up persistence for the bootkit. This is the first publicly known, in-the-wild abuse of this vulnerability.
- Although the vulnerability was fixed in Microsoft’s January 2022 update, its exploitation is still possible as the affected, validly signed binaries have still not been added to the UEFI revocation list. BlackLotus takes advantage of this, bringing its own copies of legitimate – but vulnerable – binaries to the system in order to exploit the vulnerability.
- It’s capable of disabling OS security mechanisms such as BitLocker, HVCI, and Windows Defender.
- Once installed, the bootkit’s main goal is to deploy a kernel driver (which, among other things, protects the bootkit from removal), and an HTTP downloader responsible for communication with the 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 blogpost, we present evidence that the bootkit is real, and the advertisement is not merely a scam.
- Interestingly, some of the BlackLotus installers we have analyzed do not proceed with 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
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.
Is this really BlackLotus?
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:
- BlackLotus’s advertisement on hacking forums claims that it features integrated Secure Boot bypass. Adding vulnerable drivers to the UEFI revocation list is currently impossible, as the vulnerability affects hundreds of bootloaders that are still used today. ✅
- True: It exploits CVE-2022-21894 in order to break Secure Boot and achieve persistence on UEFI-Secure-Boot-enabled systems. Vulnerable drivers it uses are still not revoked in the latest dbx, at the time of writing.
- BlackLotus’s advertisement on hacking forums claims that the bootkit has built-in Ring0/Kernel protection against removal. ✅
- True: Its kernel driver protects handles belonging to its files on the EFI System Partition (ESP) against closing. As an additional layer of protection, these handles are continuously monitored and a Blue Screen Of Death (BSOD) triggered if any of these handles are closed, as described in the Protecting bootkit files on the ESP from removal section.
- BlackLotus’s advertisement on hacking forums claims that it comes with anti-virtual-machine (anti-VM), anti-debug, and code obfuscation features to block malware analysis attempts. ✅
- True: It contains various anti-VM, anti-debug, and obfuscation techniques to make it harder to replicate or analyze. However, we are definitely not talking about any breakthrough or advanced anti-analysis techniques here, as they can be easily overcome with little effort.
- BlackLotus’s advertisement on hacking forums claims that its purpose is to act as an HTTP downloader. ✅
- True: Its final component acts as an HTTP downloader, as described in the HTTP downloader section
- BlackLotus’s advertisement on hacking forums claims that the HTTP downloader runs under the SYSTEM account within a legitimate process. ✅
- True: Its HTTP downloader runs within the
winlogon.exe
process context. - BlackLotus’s advertisement on hacking forums claims it is a tiny bootkit with an on-disk size of only 80 kB. ✅
- True: Samples we were able to obtain really are around 80 kB.
- BlackLotus’s advertisement on hacking forums claims that it can disable built-in Windows security protections such as HVCI, Bitlocker, Windows Defender, and bypass User Account Control (UAC). ✅
- True: It can disable HVCI, Windows Defender, BitLocker, and bypass UAC.
Based on these facts, we believe with high confidence that the bootkit we discovered in the wild is the BlackLotus UEFI bootkit.
Attack overview
A simplified scheme of the BlackLotus compromise chain is shown in Figure 2. It consists of three main parts:
- It starts with the execution of an installer (step 1 in Figure 2), which is responsible for deploying the bootkit’s files to the EFI System partition, disabling HVCI and BitLocker, and then rebooting the machine.
- After the first reboot, exploitation of CVE-2022-21894 and subsequent enrollment of the attackers’ Machine Owner Key (MOK) occurs, to achieve persistence even on systems with UEFI Secure Boot enabled. The machine is then rebooted (steps 2–4 in Figure 2) again.
- In all subsequent boots, the self-signed UEFI bootkit is executed and deploys both its kernel driver and user-mode payload, the HTTP downloader. Together, these components are able to download and execute additional user-mode and driver components from the C&C server and protect the bootkit against removal (steps 5–9 in Figure 2).
Figure 2. BlackLotus simplified execution overview
Interesting artifacts
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
Installation process
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.
- In offline versions, Windows binaries are embedded in the installer
- In online versions, Windows binaries are downloaded directly from the Microsoft symbol store. So far, we’ve seen the following Windows binaries being abused by the BlackLotus bootkit:
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 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.
Step 0 – Initialization and (potential) elevation
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.
Step 1 – Deploying files
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.
Folder | Filename | Description |
ESP:\EFI\Microsoft\Boot | grubx64.efi | BlackLotus bootkit, malicious self-signed UEFI application. |
ESP:\EFI\Microsoft\Boot | bootload.efi | Legitimate Microsoft-signed shim binary (temporary name, later replaces bootmgfw.efi after CVE-2022-21894
exploitation). |
ESP:\EFI\Microsoft\Boot | bootmgfw.efi | Legitimate, but vulnerable (CVE-2022-21894) Windows Boot Manager binary, embedded in the installer or downloaded directly from the Microsoft Symbol Store. |
ESP:\EFI\Microsoft\Boot | BCD | Attackers’ custom Boot Configuration Data
(BCD) store used in CVE-2022-21894
exploitation chain. |
ESP:\EFI\Microsoft\Boot | BCDR | Backup of victim’s original BCD store. |
ESP:\system32 | hvloader.efi | Legitimate, but vulnerable (CVE-2022-21894) Windows Hypervisor Loader binary, embedded inside an installer or downloaded directly from the Microsoft Symbol Store. |
ESP:\system32 | bootmgr.efi | Legitimate, but vulnerable (CVE-2022-21894) Windows Hypervisor Loader binary, embedded inside an installer or downloaded directly from the Microsoft Symbol Store. |
ESP:\system32 | mcupdate_AuthenticAMD.dll | Malicious self-signed native PE binary. This file is executed by the hvloader.efi after successful CVE-2022-21894
exploitation (on systems using an AMD CPU). |
ESP:\system32 | mcupdate_GenuineIntel.dll | Malicious self-signed native PE binary. This file is executed by the hvloader.efi after successful CVE-2022-21894
exploitation (on systems using an Intel CPU). |
ESP:\system32 | BCD | Attackers’ custom BCD used in CVE-2022-21894 exploitation chain. |
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.
Step 2 – Disabling Hypervisor-protected Code Integrity (HVCI)
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
Step 3 – Disabling BitLocker
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:
- walks through all volumes under the
Root\CIMV2\Security\MicrosoftVolumeEncryption
WMI namespace and checks their protection status by calling theGetProtectionStatus
method of theWin32_EncryptableVolume
WMI class - for those protected by BitLocker, it calls the
DisableKeyProtectors
method with theDisableCount
parameter set to zero, meaning that the protection will be suspended until it is manually enabled
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.
Bypassing Secure Boot and establishing persistence
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:
- 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 that 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. More information about exploitation can be found in the Exploiting CVE-2022-21894 section.
- Setting persistence by writing its own MOK to the
MokList
, Boot-services-only NVRAM variable. By doing this, it can use a legitimate Microsoft-signedshim
for loading its self-signed (signed by the private key belonging to the key written toMokList
) UEFI bootkit instead of exploiting the vulnerability on every boot. More about this in the Bootkit persistence section.
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
Exploiting CVE-2022-21894
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:
- Affected Windows Boot Applications (such as
bootmgr.efi
,hvloader.efi
,winload.efi
…) allow removing a serialized Secure Boot policy from memory – before it gets loaded by the application – by using thetruncatememory
BCD boot option. - This allows attackers to use other dangerous BCD options like
bootdebug
,testsigning
, ornointegritychecks
, 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 it can be exploited to make the legitimate
hvloader.efi
load an arbitrary, self-signedmcupdate_<platform>.dll
binary (where<platform>
can beGenuineIntel
orAuthenticAMD
, based on the machine’s CPU.).
Now, we continue with describing how BlackLotus exploits this vulnerability (numbers in the list below describe corresponding steps in Figure 6):
- After the installer reboots the machine, the UEFI firmware proceeds with loading a first boot option. For Windows systems, the first boot option is by default
bootmgfw.efi
located in theESP:/EFI/Microsoft/Boot
folder on the ESP. This time, instead of executing the original victim’sbootmgfw.efi
(which was previously renamedwinload.efi
by the installer), the firmware executes the vulnerable one – deployed by the installer. - After
bootmgfw.efi
is executed, it loads the BCD boot options, previously modified by the installer. Figure 7 shows a comparison of the legitimate BCD and the modified one. - As you can see in Figure 7 (path underlined with green), the legitimate Windows Boot Manager would normally load the Windows OS loader (
\WINDOWS\system32\winload.efi
) as a default boot application. But this time, with the modified BCD, it continues with loading the vulnerableESP:\system32\bootmgr.efi
, with theavoidlowmemory
BCD element set to value0x10000000
and thecustom:22000023
BCD element pointing to another attackers’ BCD stored inESP:\system32\bcd
. The explanation of using these elements can be found in the published PoC:
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)
- In the next step, the executed
ESP:\system32\bootmgr.efi
loads that additional BCD located inESP:\system32\bcd
. Parsed content of this additional BCD is shown in Figure 8.
Figure 8. Second BCD dropped by the BlackLotus installer – used to exploit CVE-2022-21894
- Because of options loaded from the BCD file shown in Figure 8,
bootmgr.efi
continues with loading another vulnerable Windows Boot Application deployed by the installer –ESP:\system32\hvloader.efi
– which is the Windows Hypervisor Loader. More importantly, additional BCD options are specified in the same BCD file (see Figure 8): truncatememory
with value set to0x10000000
nointegritychecks
set to Yes- and
testsigning
, also set to Yes
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.
- To do this, the same trick as described in the PoC is used: during its execution, the legitimate
hvloader.efi
loads and executes themcupdate_{GenuineIntel| AuthenticAMD}.dll
native binary from the<device>:\<SystemRoot>\system32\
directory. Commented Hex-Rays decompiled code of the function fromhvloader.efi
responsible for loading thismcupdate*.dll
binary is shown in Figure 9. Note thathvloader.efi
would normally load this legitimatemcupdate*.dll
binary from the<OS_partition>:\Windows\system32
, but this time the malicious attackers’ self-signedmcupdate*.dll
is executed from a custom ESP directory previously created by the installer (ESP:\system32
). It’s caused by the BCD optionsdevice
andsystemroot
used in the BCD from Figure 8 specifying the current device asboot
– meaning the ESP – and also specifying SystemRoot to be the root (\
) directory on this device.
Figure 9. Hex-Rays decompilation of the BtLoadUpdateDll
function from the legitimate hvloader.efi
, responsible for loading mcupdate_*.dll
- Now, as the attackers’ own self-signed
mcupdate*.dll
is loaded and executed, it continues with executing the final component in this chain – an embedded MokInstaller (UEFI Application) – see Figure 10 for details about how it’s done.
Figure 10. Hex-Rays decompiled code of the malicious self-signed mcupdate*.dll
binary
Bootkit persistence
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)
- Continuing with describing the flow from Figure 6 – step 8… The MokInstaller UEFI application continues with setting up persistence for the BlackLotus UEFI bootkit and covering the tracks of exploitation by:
- Restoring the victim’s original BCD store from the backup created by the installer and replacing the efi with the legitimate Microsoft-signed
shim
, previously dropped to theESP:\system32\bootload.efi
by the installer. - Creating a
MokList
NVRAM variable containing the attackers’ self-signed public key certificate. Note that this variable is formatted in the same way as any other UEFI signature database variables (such as db or dbx) and it can consist of zero or more signature lists of typeEFI_SIGNATURE_LIST
– as defined in the UEFI Specification. - Deleting all files involved in exploitation from the attackers‘
ESP:\system32\
folder. - In the end, it reboots the machine to make the deployed shim execute the self-signed bootkit dropped to
\EFI\Microsoft\Boot\grubx64.efi
by the installer (grubx64.efi
is usually the default second-stage bootloader executed by ashim
on x86-64 systems).
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
BlackLotus UEFI 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 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).
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
BlackLotus execution flow
Execution steps are as follows (these steps are shown in Figure 13):
- As a first step, the UEFI firmware executes the default Windows boot option, which is the file usually stored in
\EFI\Microsoft\Boot\bootmgfw.efi
. As we described earlier (Bootkit persistence section, 8 .a), the MokInstaller binary replaced this file with a legitimate signedshim
. - When the
shim
is executed, it reads theMokList
NVRAM variable, and uses the certificate previously stored inside by the attackers to verify the second-stage bootloader – the self-signed BlackLotus UEFI bootkit located in\EFI\Microsoft\Boot\grubx64.efi
. - When verified, the
shim
executes the bootkit. - The bootkit starts with creating the Boot-only
VbsPolicyDisable
NVRAM variable. As described here, this variable is evaluated by the Windows OS loader during boot and if defined, the core VBS features, such as HVCI and Credential Guard will not be initialized. - In the following steps (5. a–e), the bootkit continues with a common pattern used by UEFI bootkits. It intercepts the execution of components included in the typical Windows boot flow, such as Windows Boot Manager, Windows OS loader, and Windows OS kernel, and hooks some of their functions in memory. As a bonus, it also attempts to disable Windows Defender by patching some of its drivers. All this to achieve its payload’s execution in the early stages of the OS startup process and to avoid detection. The following functions are hooked or patched:
ImgArchStartBootApplication
inbootmgfw.efi
orbootmgr.efi
: This function is commonly hooked by bootkits to catch the moment when the Windows OS loader (winload.efi
) is loaded in the memory but still hasn’t been executed – which is the right moment to perform more in-memory patching.BlImgAllocateImageBuffer
inwinload.efi
: Used to allocate an additional memory buffer for the malicious kernel driver.OslArchTransferToKernel
inwinload.efi
: Hooked to catch the moment when the OS kernel and some of the system drivers are already loaded in the memory, but still haven’t been executed – which is a perfect moment to perform more in-memory patching. The drivers mentioned below are patched in this hook. The code from this hook responsible for finding appropriate drivers in memory is shown in Figure 14.WdBoot.sys
andWdFilter.sys
: BlackLotus patches the entry point ofWdBoot.sys
andWdFilter.sys
– the Windows Defender ELAM driver and the Windows Defender file system filter driver, respectively – to return immediately.disk.sys
: The bootkit hooks the entry point of thedisk.sys
driver to execute the BlackLotus kernel driver in the early stages of system initialization.
Figure 14. Hex-Rays decompiled code of OslArchTransferToKernel hook – patching Windows Defender drivers and searching for the disk.sys entry point
- Next, when the OS kernel executes the
disk.sys
driver’s entry point, the installed hook jumps to the malicious kernel driver entry point. The malicious code in turn restores the originaldisk.sys
to allow the system to function properly and waits until thewinlogon.exe
process starts. - When the malicious driver detects that the
winlogon.exe
process has started, it injects and executes the final user-mode component – the HTTP downloader – into it.
Kernel driver
The kernel driver is responsible for four main tasks:
- Injecting the HTTP downloader into
winlogon.exe
and reinjecting it in case the thread terminated. - Protecting bootkit files deployed on the ESP from being removed.
- Disarming the user-mode Windows Defender process
MsMpEngine.exe
. - Communicating with the HTTP downloader and if necessary, performing any commands.
Let’s look at them one by one.
HTTP downloader persistence
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.
Protecting bootkit files on the ESP from removal
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:
ESP:\EFI\Microsoft\Boot\winload.efi
ESP:\EFI\Microsoft\Boot\bootmgfw.efi
ESP:\EFI\Microsoft\Boot\grubx64.efi
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.
Disarming the main Windows Defender process
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.
Communication with the HTTP downloader
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:
\BaseNamedObjects\101c1b
: for the named section (only the first three octets of the MAC are used)\BaseNamedObjects\
Z
01c1b
: for the named event – same as for the Section, but the first digit of the MAC address is replaced withZ
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:
- Install kernel driver
- Uninstall BlackLotus
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.
HTTP downloader
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.
C&C communication
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:
/network/API/hpb_gate[.]php
/API/hpb_gate[.]php
/gate[.]php
/hpb_gate[.]php
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
{
"HWID":"%s",
"Session":"%lu",
"Owner":"%s",
"IP":"%s",
"OS":"%s",
"Edition":"%s",
"CPU":"%s",
"GPU":"%s",
"RAM":"%lu",
"Integrity":"%lu",
"SecureBoot":"%i",
"Build":"%lu"
}
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:
- C&C communication interval
- Execution method to use
- Payload filename
- Payload type based on file extension(
.sys
,.exe
, or.dll
supported) - Authentication token that is supposed to be used to request download of payload data
- AES key used for decrypting the payload data
All supported commands and their descriptions are listed in Table 2.
Command Type | Command Description |
1 | Download and execute a kernel driver, DLL, or a regular executable |
2 | Download a payload, uninstall the bootkit, and execute the payload – likely used to update the bootkit |
3 | Uninstall the bootkit and exit |
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.
Anti-analysis tricks
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.
- String and data encryption
- All strings used within the samples are encrypted using a simple cipher.
- All embedded files are encrypted using 256-bit AES in CBC mode.
- Encryption keys for individual files can vary from sample to sample.
- In addition to AES encryption, some files are also compressed using LZMS.
- Runtime-only API resolution
- In all samples (when applicable), Windows APIs are always resolved exclusively during runtime and function hashes instead of function names are used to find the desired API function addresses in memory.
- In some cases, a direct
syscall
instruction invocation is used to invoke the desired system function. - Network communication
- Communicates using HTTPS.
- All messages sent to the C&C by the HTTP downloader are encrypted using an embedded RSA public key.
- All messages sent from the C&C to the HTTP downloader are encrypted using a key derived from the victim’s machine environment or using an AES key provided by the C&C.
- Anti-debug and anti-VM tricks – if used, usually placed right at the beginning of the entry point. Only casual sandbox or debugger detection tricks are used.
Mitigations and remediation
- First of all, of course, keeping your system and its security product up to date is a must – to raise a chance that a threat will be stopped right at the beginning, before it’s able to achieve pre-OS persistence.
- Then, the key step that needs to be taken to prevent usage of known vulnerable UEFI binaries for bypassing UEFI Secure Boot is their revocation in the UEFI revocation database (
dbx
) – on a Windows systems,dbx
updates should be distributed using Windows Updates. - The problem is that revocation of broadly used Windows UEFI binaries can lead to making thousands of outdated systems, recovery images, or backups unbootable – and therefore, revocation often takes too long.
- Note that revocation of the Windows applications used by BlackLotus would prevent installation of the bootkit, but as the installer would replace the victim’s bootloader with the revoked one, it could make the system unbootable. To recover in this case, an OS reinstall or just ESP recovery would resolve the issue.
- If the revocation would happen after BlackLotus persistence is set, the bootkit would remain functional, as it uses a legitimate shim with custom MOK key for persistence. In this case, the safest mitigation solution would be to reinstall Windows and remove the attackers’ enrolled MOK key by using the
mokutil
utility (physical presence is required to perform this operation due to necessary user interaction with the MOK Manager during the boot).
Takeaways
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:
- First of all, of course, CVE-2022-21894 – the vulnerability exploited by BlackLotus. One year since the vulnerability was fixed, vulnerable UEFI binaries are still not revoked, allowing threats such as BlackLotus to stealthily operate on systems with UEFI Secure Boot enabled, thus providing victims a false sense of security.
- Early in 2022, we disclosed several UEFI vulnerabilities that allow, among other things, disabling UEFI Secure Boot. Many devices affected are not supported by the OEM anymore, thus not fixed (even though these devices were not so old – like 3-5 years at the time of vulnerability disclosure). Read more in our blogpost: When “secure” isn’t secure at all: High‑impact UEFI vulnerabilities discovered in Lenovo consumer laptops
- Later in 2022, we discovered a few other UEFI vulnerabilities, whose exploitation would also allow attackers to disable UEFI Secure Boot very easily. As pointed out by fellow researchers from Binarly, several devices listed in the advisory were left unpatched, or not patched correctly, even few months after the advisory – leaving the devices vulnerable. Needless to say, similar to the previous case, some devices will stay vulnerable forever, as they have reached their End-Of-Support date.
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.
IoCs
Files
SHA-1 | Detection | Description |
05846D5B1D37EE2D716140DE4F4F984CF1E631D1 | Win64/BlackLotus.A | BlackLotus installer. |
A5A530A91100ED5F07A5D74698B15C646DD44E16 | Win64/BlackLotus.A | BlackLotus installer. |
D82539BFC2CC7CB504BE74AC74DF696B13DB486A | Win64/BlackLotus.A | BlackLotus installer. |
16B12CEA54360AA42E1120E82C1E9BC0371CB635 | Win64/BlackLotus.A | BlackLotus installer. |
DAE7E7C4EEC2AC0DC7963C44A5A4F47D930C5508 | Win64/BlackLotus.A | BlackLotus installer. |
45701A83DEC1DC71A48268C9D6D205F31D9E7FFB | Win64/BlackLotus.A | BlackLotus installer. |
2CE056AE323B0380B0E87225EA0AE087A33CD316 | EFI/BlackLotus.B | BlackLotus UEFI bootkit. |
5A0074203ABD5DEB464BA0A79E14B7541A033216 | EFI/BlackLotus.B | BlackLotus UEFI bootkit. |
5DC9CBD75ABD830E83641A0265BFFDDD2F602815 | EFI/BlackLotus.B | BlackLotus UEFI bootkit. |
97AEC21042DF47D39AC212761729C6BE484D064D | EFI/BlackLotus.B | BlackLotus UEFI bootkit. |
ADCEEC18FF009BED635D168E0B116E72096F18D2 | EFI/BlackLotus.B | BlackLotus UEFI bootkit. |
DBC064F757C69EC43517EFF496146B43CBA949D1 | EFI/BlackLotus.B | BlackLotus UEFI bootkit. |
06AF3016ACCDB3DFE1C23657BF1BF91C13BAA757 | Win64/BlackLotus.B | BlackLotus HTTP downloader. |
0C0E78BF97116E781DDE0E00A1CD0C29E68D623D | Win64/BlackLotus.B | BlackLotus HTTP downloader. |
6D8CEE28DA8BCF25A4D232FEB0810452ACADA11D | Win64/BlackLotus.B | BlackLotus HTTP downloader. |
74FF58FCE8F19083D16DF0109DC91D78C94342FA | Win64/BlackLotus.B | BlackLotus HTTP downloader. |
ACC74217CBE3F2E727A826B34BDE482DCAE15BE6 | Win64/BlackLotus.B | BlackLotus HTTP downloader. |
111C4998F3264617A7A9D9BF662D4B1577445B20 | Win64/BlackLotus.B | BlackLotus HTTP downloader. |
17FA047C1F979B180644906FE9265F21AF5B0509 | Win64/BlackLotus.C | BlackLotus kernel driver. |
1F3799FED3CF43254FE30DCDFDB8DC02D82E662B | Win64/BlackLotus.C | BlackLotus kernel driver. |
4B882748FAF2C6C360884C6812DD5BCBCE75EBFF | Win64/BlackLotus.C | BlackLotus kernel driver. |
91F832F46E4C38ECC9335460D46F6F71352CFFED | Win64/BlackLotus.C | BlackLotus kernel driver. |
994DC79255AEB662A672A1814280DE73D405617A | Win64/BlackLotus.C | BlackLotus kernel driver. |
FFF4F28287677CAABC60C8AB36786C370226588D | Win64/BlackLotus.C | BlackLotus kernel driver. |
71559C3E2F3950D4EE016F24CA54DA17D28B9D82 | EFI/BlackLotus.C | BlackLotus Boot Configuration Data (BCD) store dropped by BlackLotus installer. |
D6D3F3151B188A9DA62DEB95EA1D1ABEFF257914 | EFI/BlackLotus.C | BlackLotus Boot Configuration Data (BCD) store dropped by BlackLotus installer. |
547FAA2D64B85BF883955B723B07635C0A09326B | EFI/BlackLotus.A | BlackLotus CVE-2022-21894 exploitation payload loader. |
D1BBAA3D408E944C70B3815471EED7FA9AEE6425 | EFI/BlackLotus.A | BlackLotus CVE-2022-21894 exploitation payload loader. |
0E6DD7110C38464ECAA55EE4E2FA303ADA0EDEFB | EFI/BlackLotus.A | BlackLotus CVE-2022-21894 exploitation payload – MokInstaller EFI app. |
D6BB89D8734B3E49725362DAE9A868AE681E8BD6 | EFI/BlackLotus.A | BlackLotus CVE-2022-21894 exploitation payload – MokInstaller EFI app. |
164BB587109CFB20824303AD1609A65ABB36C3E9 | Win64/BlackLotus.D | BlackLotus installer UAC bypass module. |
Certificates
Serial number | 570B5D22B723B4A442CC6EEEBC2580E8 |
Thumbprint | C8E6BF8B6FDA161BBFA5470BCC262B1BDC92A359 |
Subject CN | When They Cry CA |
Subject O | N/A |
Subject L | N/A |
Subject S | N/A |
Subject C | N/A |
Valid from | 2022-08-13 17:48:44 |
Valid to | 2032-08-13 17:58:44 |
Network
IP | Domain | Hosting provider | First seen | Details |
N/A | xrepositoryx[.]name | N/A | 2022‑10‑17 | BlackLotus C&C.
https://xrepositoryx[.]name/network/API/hpb_gate.php |
N/A | myrepositoryx[.]com | N/A | 2022‑10‑16 | BlackLotus C&C.
https://myrepositoryx[.]com/network/API/hpb_gate.php |
104.21.22[.]185 | erdjknfweklsgwfmewfgref[.]com | Cloudflare, Inc. | 2022‑10‑06 | BlackLotus C&C.
https://erdjknfweklsgwfmewfgref[.]com/API/hpb_gate.php |
164.90.172[.]211 | harrysucksdick[.]com | DigitalOcean, LLC | 2022‑10‑09 | BlackLotus C&C.
https://harrysucksdick[.]com/API/hpb_gate.php |
185.145.245[.]123 | heikickgn[.]com frassirishiproc[.]com | SIA VEESP | 2022‑10‑12 | BlackLotus C&C.
https://heikickgn[.]com/API/hpb_gate.php https://frassirishiproc[.]com/API/hpb_gate.php |
185.150.24[.]114 | myrepository[.]name | SkyLink Data Center BV | 2022‑10‑14 | BlackLotus C&C.
myrepository[.]name/network/API/hpb_gate.php |
190.147.189[.]122 | egscorp[.]net | Telmex Colombia S.A. | 2022‑08‑24 | BlackLotus C&C.
https://egscorp[.]net/API/hpb_gate.php |
MITRE ATT&CK techniques
This table was built using version 12 of the MITRE ATT&CK framework.
Tactic | ID | Name | Description |
Resource Develpment | T1587.002 | Develop Capabilities: Code Signing Certificates | Some BlackLotus samples are signed with self-signed certificate. |
Resource Develpment | T1588.005 | Obtain Capabilities: Exploits | BlackLotus used publicly known exploit to bypass UEFI Secure Boot. |
Execution | T1203 | Exploitation for Client Execution | BlackLotus installers can exploit CVE-2022-21894 to achieve arbitrary code execution on the systems with UEFI Secure Boot enabled. |
Execution | T1559 | Inter-Process Communication | BlackLotus HTTP downloader uses named section to pass commands to the kernel-mode component. |
Execution | T1106 | Native API | BlackLotus HTTP downloader uses various native Windows APIs to achieve code execution on the compromised machine. |
Execution | T1129 | Shared Modules | BlackLotus HTTP downloader can load and execute DLLs received from the C&C server. |
Persistence | T1542.003 | Pre-OS Boot: Bootkit | BlackLotus bootkit is deployed on the EFI System Partition and executed during the boot. |
Privilege Escalation | T1548.002 | Abuse Elevation Control Mechanism: Bypass User Account Control | BlackLotus installer attempts to escalate privileges by bypassing User Account Control. |
Privilege Escalation | T1134.002 | Access Token Manipulation: Create Process with Token | BlackLotus HTTP downloader can use WTSQueryUserToken and CreateProcessAsUserW to execute downloaded payloads within a new process with local system privileges. |
Defense Evasion | T1622 | Debugger Evasion | BlackLotus components use various techniques to detect whether a kernel-mode or user-mode debugger is running on a victim. |
Defense Evasion | T1574 | Hijack Execution Flow | BlackLotus bootkit hijacks various components included in the early Windows boot process stages (Windows Boot Manager, Windows OS loader, Windows kernel and specific drivers) to avoid detection by deactivating various Windows security features (VBS, Windows Defender) and stealthily execute its kernel-mode and user-mode components |
Defense Evasion | T1562 | Impair Defenses | BlackLotus components can disable BitLocker and Windows Defender to avoid detection. |
Defense Evasion | T1070.004 | Indicator Removal: File Deletion | BlackLotus installer deletes itself after successfully deploying files to the EFI System partition. Also after successful CVE-2022-21894 exploitation, BlackLotus removes traces of exploitation by deleting all files included in exploitation chain from EFI System Partition. |
Defense Evasion | T1070.009 | Indicator Removal: Clear Persistence | BlackLotus can uninstall itself by removing all bootkit files from the ESP and restoring original victim’s Windows Boot Manager. |
Defense Evasion | T1036.005 | Masquerading: Match Legitimate Name or Location | BlackLotus attempts to hide its files deployed on the ESP by using legitimate filenames, such as grubx64.efi (if UEFI Secure Boot is enabled on compromised machine) or bootmgfw.efi (if UEFI Secure Boot is disabled on compromised machine). |
Defense Evasion | T1112 | Modify Registry | BlackLotus installer modifies Windows registry to disable Windows HVCI security feature. |
Defense Evasion | T1027 | Obfuscated Files or Information | Almost all embedded strings in BlackLotus components are encrypted using a custom combined cipher and decrypted only when needed. |
Defense Evasion | T1027.007 | Obfuscated Files or Information: Dynamic API Resolution | BlackLotus components use dynamic API resolution while using API names’ hashes instead of names. |
Defense Evasion | T1027.009 | Obfuscated Files or Information: Embedded Payloads | Almost all embedded files in BlackLotus components are encrypted using AES. |
Defense Evasion | T1542.003 | Pre-OS Boot: Bootkit | BlackLotus bootkit is deployed on the EFI System Partition and executed during the early OS boot stages, and thus is capable of controlling the OS boot process and evading detection. |
Defense Evasion | T1055.012 | Process Injection: Dynamic-link Library Injection | BlackLotus HTTP downloader can inject a DLL into a newly created svchost.exe process using process hollowing. |
Defense Evasion | T1055.002 | Process Injection: Portable Executable Injection | BlackLotus driver injects the HTTP downloader portable executable into a winlogon.exe process. |
Defense Evasion | T1014 | Rootkit | BlackLotus kernel driver protects the bootkit files on the ESP from removal. |
Defense Evasion | T1497.001 | Virtualization/Sandbox Evasion: System Checks | BlackLotus employs various system checks including checking sandbox-specific registry values, to detect and avoid virtualization and analysis environments. |
Discovery | T1622 | Debugger Evasion | BlackLotus components use various techniques to detect whether a kernel-mode or user-mode debugger is running on a victim. |
Discovery | T1082 | System Information Discovery | BlackLotus collects system information (IP, GPU, CPU, memory, OS version) on a compromised host. |
Discovery | T1614 | System Location Discovery | BlackLotus can exit if one of the following system locales is identified on the compromised host: ro-MD, ru-MD, ru-RU, uk-UA, be-BY, hy-AM, kk-KZ. |
Discovery | T1016 | System Network Configuration Discovery | BlackLotus HTTP downloader can determine the public IP of a compromised host by requesting api.ipify[.]org service. |
Discovery | T1016.001 | System Network Configuration Discovery: Internet Connection Discovery | BlackLotus HTTP downloader checks the internet connection by querying Microsoft’s www.msftncsi[.]com/ncsi[.]txt |
Discovery | T1497.001 | Virtualization/Sandbox Evasion: System Checks | BlackLotus employs various system checks including checking sandbox-specific registry values, to detect and avoid virtualization and analysis environments. |
Command and Control | T1071.001 | Application Layer Protocol: Web Protocols | BlackLotus uses HTTPS for communication with its C&C. |
Command and Control | T1132.001 | Data Encoding: Standard Encoding | BlackLotus encodes encrypted data in C&C communication with URL-safe base64. |
Command and Control | T1573.001 | Encrypted Channel: Symmetric Cryptography | BlackLotus uses 256-bit AES in CBC mode to decrypt messages received from its C&C. |
Command and Control | T1573.002 | Encrypted Channel: Asymmetric Cryptography | BlackLotus uses an embedded RSA public key to encrypt messages sent to C&C. |