BlackLotus UEFI bootkit: Myth confirmed
🃏

BlackLotus UEFI bootkit: Myth confirmed

📅 [ Archival Date ]
Mar 19, 2023 1:40 PM
🏷️ [ Tags ]
UEFIBootkitBlackLotusCTI
✍️ [ Author ]

Martin Smolár

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.

image

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). ✅

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:

  1. 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.
  2. 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.
  3. 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).
image

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).

image

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.

image

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.

image

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 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, 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:

  1. Exploiting CVE-2022-21894 to bypass the Secure Boot feature and install the bootkit. This allows arbitrary code execution in early boot phases, where the platform is still owned by firmware and UEFI Boot Services functions are still available. This allows attackers to do many things 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.
  2. Setting persistence by writing its own MOK to the MokList, Boot-services-only NVRAM variable. By doing this, it can use a legitimate Microsoft-signed shim for loading its self-signed (signed by the private key belonging to the key written to MokList) UEFI bootkit instead of exploiting the vulnerability on every boot. 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.

image

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 the truncatememory BCD boot option.
  • This allows attackers to use other dangerous BCD options like 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 it can be exploited to make the legitimate hvloader.efi load an arbitrary, self-signed mcupdate_<platform>.dll binary (where <platform> can be GenuineIntel or AuthenticAMD, 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):

  1. 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 the ESP:/EFI/Microsoft/Boot folder on the ESP. This time, instead of executing the original victim’s bootmgfw.efi (which was previously renamed winload.efi by the installer), the firmware executes the vulnerable one – deployed by the installer.
  2. 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.
  3. 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 vulnerable ESP:\system32\bootmgr.efi, with the avoidlowmemory BCD element set to value 0x10000000 and the custom:22000023 BCD element pointing to another attackers’ BCD stored in ESP:\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.

image

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

  1. In the next step, the executed ESP:\system32\bootmgr.efi loads that additional BCD located in ESP:\system32\bcd. Parsed content of this additional BCD is shown in Figure 8.
image

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

  1. 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):
    1. truncatememory with value set to 0x10000000
    2. nointegritychecks set to Yes
    3. 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.

  1. To do this, the same trick as described in the PoC is used: during its execution, the legitimate hvloader.efi loads and executes the mcupdate_{GenuineIntel| AuthenticAMD}.dll native binary from the <device>:\<SystemRoot>\system32\ directory. Commented Hex-Rays decompiled code of the function from hvloader.efi responsible for loading this mcupdate*.dll binary is shown in Figure 9. Note that hvloader.efi would normally load this legitimate mcupdate*.dll binary from the <OS_partition>:\Windows\system32, but this time the malicious attackers’ self-signed mcupdate*.dll is executed from a custom ESP directory previously created by the installer (ESP:\system32). It’s caused by the BCD options device and systemroot used in the BCD from Figure 8 specifying the current device as boot – meaning the ESP – and also specifying SystemRoot to be the root (\) directory on this device.
image

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

  1. 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.
image

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.

image

Figure 11. MOK boot process overview (image source)

  1. 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:
    1. 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 the ESP:\system32\bootload.efi by the installer.
    2. 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 type EFI_SIGNATURE_LIST – as defined in the UEFI Specification.
    3. Deleting all files involved in exploitation from the attackers‘ ESP:\system32\ folder.
  2. 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 a shim on x86-64 systems).

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

image

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.

image

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):

  1. 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 signed shim.
  2. When the shim is executed, it reads the MokList 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.
  3. When verified, the shim executes the bootkit.
  4. 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.
  5. 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:
    1. ImgArchStartBootApplication in bootmgfw.efi or bootmgr.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.
    2. BlImgAllocateImageBuffer in winload.efi: Used to allocate an additional memory buffer for the malicious kernel driver.
    3. OslArchTransferToKernel in winload.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.
    4. WdBoot.sys and WdFilter.sys: BlackLotus patches 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.
    5. disk.sys: The bootkit hooks the entry point of the disk.sys driver to execute the BlackLotus kernel driver in the early stages of system initialization.
image

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

  1. 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 original disk.sys to allow the system to function properly and waits until the winlogon.exe process starts.
  2. 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.

image

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\Z01c1b: for the named event – same as for the Section, but the first digit of the MAC address is replaced with Z

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.

image

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.