www.welivesecurity.com Open in urlscan Pro
2a02:26f0:11a::6867:4831 Public Scan

Back to summary

URL:
https://www.welivesecurity.com/2023/03/01/blacklotus-uefi-bootkit-myth-confirmed/
Submission: On March 02 via api (March 2nd 2023, 3:27:31 pm UTC) from IN — Scanned from DE

Form analysis
5 forms found in the DOM

GET https://www.welivesecurity.com/

<form action="https://www.welivesecurity.com/" class="basic-searchform imc dark col-md-12 col-sm-10 col-xs-12" method="get" role="search">
  <div class="search-input clearfix">
    <input type="text" name="s" value="" placeholder="Search..." class="imc">
    <button class="imc">
      <span class="icomoon icon-icon_search imc"></span>
    </button>
  </div>
</form>

GET https://www.welivesecurity.com/

<form action="https://www.welivesecurity.com/" class="basic-searchform imc dark col-md-12 col-sm-10 col-xs-12" method="get" role="search">
  <div class="search-input clearfix">
    <input type="text" name="s" value="" placeholder="Search..." class="imc">
    <button class="imc">
      <span class="icomoon icon-icon_search imc"></span>
    </button>
  </div>
</form>

GET https://www.welivesecurity.com/

<form action="https://www.welivesecurity.com/" class="basic-searchform imc  col-md-12 col-sm-10 col-xs-12" method="get" role="search">
  <div class="search-input clearfix">
    <input type="text" name="s" value="" placeholder="Search..." class="imc">
    <button class="imc">
      <span class="icomoon icon-icon_search imc"></span>
    </button>
  </div>
</form>

POST https://enjoy.eset.com/pub/rf

<form action="https://enjoy.eset.com/pub/rf" class="basic-searchform col-md-12 col-sm-12 col-xs-12 no-padding newsletter" method="post" role="search">
  <div class="search-input clearfix">
    <input type="text" name="EMAIL_ADDRESS_" value="" placeholder="Email...">
    <input type="hidden" name="TOPIC" value="We Live Security Ukraine Newsletter">
    <input type="hidden" name="_ri_" value="X0Gzc2X%3DAQpglLjHJlTQGgXv4jDGEK4KW2uhw0qgUzfwuivmOJOPCgzgo9vsI3VwjpnpgHlpgneHmgJoXX0Gzc2X%3DAQpglLjHJlTQGzbD6yU2pAgzaJM16bkTA7tOwuivmOJOPCgzgo9vsI3">
    <input type="hidden" name="_ei_" value="Ep2VKa8UKNIAPP_2GAEW0bY">
    <input type="hidden" name="_di_" value="m0a5n0j02duo9clmm4btuu5av8rdtvqfqd03v1hallrvcob47ad0">
    <input type="hidden" name="EMAIL_PERMISSION_STATUS_" value="O">
    <input type="hidden" name="CONTACT_SOURCE_MOST_RECENT" value="WLS_Subscribe_Form">
    <button class="button-flag"> Submit </button>
  </div>
</form>

POST https://enjoy.eset.com/pub/rf

<form action="https://enjoy.eset.com/pub/rf" class="basic-searchform col-md-12 col-sm-12 col-xs-12 no-padding newsletter" method="post" role="search">
  <div class="search-input clearfix">
    <input type="text" name="EMAIL_ADDRESS_" value="" placeholder="Email...">
    <input type="hidden" name="NEWSLETTER" value="We Live Security">
    <input type="hidden" name="_ri_" value="X0Gzc2X%3DAQpglLjHJlTQGgXv4jDGEK4KW2uhw0qgUzfwuivmOJOPCgzgo9vsI3VwjpnpgHlpgneHmgJoXX0Gzc2X%3DAQpglLjHJlTQGzbD6yU2pAgzaJM16bkTA7tOwuivmOJOPCgzgo9vsI3">
    <input type="hidden" name="_ei_" value="Ep2VKa8UKNIAPP_2GAEW0bY">
    <input type="hidden" name="_di_" value="m0a5n0j02duo9clmm4btuu5av8rdtvqfqd03v1hallrvcob47ad0">
    <input type="hidden" name="EMAIL_PERMISSION_STATUS_" value="O">
    <input type="hidden" name="CONTACT_SOURCE_MOST_RECENT" value="WLS_Subscribe_Form">
    <button class=""> Submit </button>
  </div>
</form>

Text Content

In English
* Em Português
* En français
* En Español
* In Deutsch

Menu toggle menu

* All Posts
* Ukraine Crisis – Digital Security Resource Center
* We Live Progress
* Research
* How To
* Videos
* Conference Materials
* White Papers
* Threat Reports
* Our Experts

* Em Português
* En français
* En Español
* In Deutsch

Award-winning news, views, and insight from the ESET security community

BLACKLOTUS UEFI BOOTKIT: MYTH CONFIRMED

The first in-the-wild UEFI bootkit bypassing UEFI Secure Boot on fully updated
UEFI systems is now a reality
Martin Smolár
1 Mar 2023 - 11:30AM
Share

The first in-the-wild UEFI bootkit bypassing UEFI Secure Boot on fully updated
UEFI systems is now a reality

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 6th, 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 summarizing 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:

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

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.

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

FolderFilenameDescription ESP:\EFI\Microsoft\Bootgrubx64.efiBlackLotus bootkit,
malicious self-signed UEFI application. bootload.efiLegitimate Microsoft-signed
shim binary (temporary name, later replaces bootmgfw.efi after CVE-2022-21894
exploitation). bootmgfw.efiLegitimate, but vulnerable (CVE-2022-21894) Windows
Boot Manager binary, embedded in the installer or downloaded directly from the
Microsoft Symbol Store. BCDAttackers’ custom Boot Configuration Data (BCD) store
used in CVE-2022-21894 exploitation chain. BCDRBackup of victim’s original BCD
store. ESP:\system32hvloader.efiLegitimate, but vulnerable (CVE-2022-21894)
Windows Hypervisor Loader binary, embedded inside an installer or downloaded
directly from the Microsoft Symbol Store. bootmgr.efiLegitimate, but vulnerable
(CVE-2022-21894) Windows Boot Manager binary, embedded inside an installer or
downloaded directly from the Microsoft Symbol Store.
mcupdate_AuthenticAMD.dllMalicious 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). mcupdate_GenuineIntel.dllMalicious 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). BCDAttackers’
custom BCD used in CVE-2022-21894 exploitation chain.

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

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.

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

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

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

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

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

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

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

8. 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.
9. 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.

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

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.

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

6. 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.
7. 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\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" }
1
2
3
4
5
6
7
8
9
10
11
12
13
14
{
"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.

Table 2. C&C commands

Command TypeCommand Description 1Download and execute a kernel driver, DLL, or a
regular executable 2Download a payload, uninstall the bootkit, and execute the
payload – likely used to update the bootkit 3Uninstall the bootkit and exit

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.

ESET Research offers private APT intelligence reports and data feeds. For any
inquiries about this service, visit the ESET Threat Intelligence page.

IOCS

FILES

SHA-1FilenameDetectionDescription
05846D5B1D37EE2D716140DE4F4F984CF1E631D1N/AWin64/BlackLotus.ABlackLotus
installer.
A5A530A91100ED5F07A5D74698B15C646DD44E16N/AWin64/BlackLotus.ABlackLotus
installer.
D82539BFC2CC7CB504BE74AC74DF696B13DB486AN/AWin64/BlackLotus.ABlackLotus
installer.
16B12CEA54360AA42E1120E82C1E9BC0371CB635N/AWin64/BlackLotus.ABlackLotus
installer.
DAE7E7C4EEC2AC0DC7963C44A5A4F47D930C5508N/AWin64/BlackLotus.ABlackLotus
installer.
45701A83DEC1DC71A48268C9D6D205F31D9E7FFBN/AWin64/BlackLotus.ABlackLotus
installer. 2CE056AE323B0380B0E87225EA0AE087A33CD316N/AEFI/BlackLotus.BBlackLotus
UEFI bootkit.
5A0074203ABD5DEB464BA0A79E14B7541A033216N/AEFI/BlackLotus.BBlackLotus UEFI
bootkit. 5DC9CBD75ABD830E83641A0265BFFDDD2F602815N/AEFI/BlackLotus.BBlackLotus
UEFI bootkit.
97AEC21042DF47D39AC212761729C6BE484D064DN/AEFI/BlackLotus.BBlackLotus UEFI
bootkit. ADCEEC18FF009BED635D168E0B116E72096F18D2N/AEFI/BlackLotus.BBlackLotus
UEFI bootkit.
DBC064F757C69EC43517EFF496146B43CBA949D1N/AEFI/BlackLotus.BBlackLotus UEFI
bootkit. 06AF3016ACCDB3DFE1C23657BF1BF91C13BAA757N/AWin64/BlackLotus.BBlackLotus
HTTP downloader.
0C0E78BF97116E781DDE0E00A1CD0C29E68D623DN/AWin64/BlackLotus.BBlackLotus HTTP
downloader.
6D8CEE28DA8BCF25A4D232FEB0810452ACADA11DN/AWin64/BlackLotus.BBlackLotus HTTP
downloader.
74FF58FCE8F19083D16DF0109DC91D78C94342FAN/AWin64/BlackLotus.BBlackLotus HTTP
downloader.
ACC74217CBE3F2E727A826B34BDE482DCAE15BE6N/AWin64/BlackLotus.BBlackLotus HTTP
downloader.
111C4998F3264617A7A9D9BF662D4B1577445B20N/AWin64/BlackLotus.BBlackLotus HTTP downloader.
17FA047C1F979B180644906FE9265F21AF5B0509N/AWin64/BlackLotus.CBlackLotus kernel
driver. 1F3799FED3CF43254FE30DCDFDB8DC02D82E662BN/AWin64/BlackLotus.CBlackLotus
kernel driver.
4B882748FAF2C6C360884C6812DD5BCBCE75EBFFN/AWin64/BlackLotus.CBlackLotus kernel
driver. 91F832F46E4C38ECC9335460D46F6F71352CFFEDN/AWin64/BlackLotus.CBlackLotus
kernel driver.
994DC79255AEB662A672A1814280DE73D405617AN/AWin64/BlackLotus.CBlackLotus kernel
driver. FFF4F28287677CAABC60C8AB36786C370226588DN/AWin64/BlackLotus.CBlackLotus
kernel driver.
71559C3E2F3950D4EE016F24CA54DA17D28B9D82N/AEFI/BlackLotus.CBlackLotus Boot
Configuration Data (BCD) store dropped by BlackLotus installer.
D6D3F3151B188A9DA62DEB95EA1D1ABEFF257914N/AEFI/BlackLotus.CBlackLotus Boot
Configuration Data (BCD) store dropped by BlackLotus installer.
547FAA2D64B85BF883955B723B07635C0A09326BN/AEFI/BlackLotus.ABlackLotus
CVE-2022-21894 exploitation payload loader.
D1BBAA3D408E944C70B3815471EED7FA9AEE6425N/AEFI/BlackLotus.ABlackLotus
CVE-2022-21894 exploitation payload loader.
0E6DD7110C38464ECAA55EE4E2FA303ADA0EDEFBN/AEFI/BlackLotus.ABlackLotus
CVE-2022-21894 exploitation payload – MokInstaller EFI app.
D6BB89D8734B3E49725362DAE9A868AE681E8BD6N/AEFI/BlackLotus.ABlackLotus
CVE-2022-21894 exploitation payload – MokInstaller EFI app.
164BB587109CFB20824303AD1609A65ABB36C3E9N/AWin64/BlackLotus.DBlackLotus
installer UAC bypass module.

CERTIFICATES

Serial number570B5D22B723B4A442CC6EEEBC2580E8
ThumbprintC8E6BF8B6FDA161BBFA5470BCC262B1BDC92A359 Subject CNWhen They Cry CA
Subject ON/A Subject LN/A Subject SN/A Subject CN/A Valid from2022-08-13
17:48:44 Valid to2032-08-13 17:58:44

NETWORK

IPDomainHosting providerFirst seenDetails
N/Axrepositoryx[.]nameN/A2022‑10‑17BlackLotus C&C.
https://xrepositoryx[.]name/network/API/hpb_gate.php
N/Amyrepositoryx[.]comN/A2022‑10‑16BlackLotus C&C.
https://myrepositoryx[.]com/network/API/hpb_gate.php
104.21.22[.]185erdjknfweklsgwfmewfgref[.]comCloudflare, Inc.2022‑10‑06BlackLotus
C&C.
https://erdjknfweklsgwfmewfgref[.]com/API/hpb_gate.php
164.90.172[.]211harrysucksdick[.]comDigitalOcean, LLC2022‑10‑09BlackLotus C&C.
https://harrysucksdick[.]com/API/hpb_gate.php 185.145.245[.]123heikickgn[.]com
frassirishiproc[.]comSIA VEESP2022‑10‑12BlackLotus C&C.
https://heikickgn[.]com/API/hpb_gate.php
https://frassirishiproc[.]com/API/hpb_gate.php
185.150.24[.]114myrepository[.]nameSkyLink Data Center BV2022‑10‑14BlackLotus
C&C.
myrepository[.]name/network/API/hpb_gate.php
190.147.189[.]122egscorp[.]netTelmex Colombia S.A.2022‑08‑24BlackLotus 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.

TacticIDNameDescription Resource DevelpmentT1587.002Develop Capabilities: Code
Signing CertificatesSome BlackLotus samples are signed with self-signed
certificate. T1588.005Obtain Capabilities: ExploitsBlackLotus used publicly
known exploit to bypass UEFI Secure Boot. ExecutionT1203Exploitation for Client
ExecutionBlackLotus installers can exploit CVE-2022-21894 to achieve arbitrary
code execution on the systems with UEFI Secure Boot enabled. T1559Inter-Process
CommunicationBlackLotus HTTP downloader uses named section to pass commands to
the kernel-mode component. T1106Native APIBlackLotus HTTP downloader uses
various native Windows APIs to achieve code execution on the compromised
machine. T1129Shared ModulesBlackLotus HTTP downloader can load and execute DLLs
received from the C&C server. PersistenceT1542.003Pre-OS Boot: BootkitBlackLotus
bootkit is deployed on the EFI System Partition and executed during the boot.
Privilege EscalationT1548.002Abuse Elevation Control Mechanism: Bypass User
Account ControlBlackLotus installer attempts to escalate privileges by bypassing
User Account Control. T1134.002Access Token Manipulation: Create Process with
TokenBlackLotus HTTP downloader can use WTSQueryUserToken and
CreateProcessAsUserW to execute downloaded payloads within a new process with
local system privileges. Defense Evasion T1622Debugger EvasionBlackLotus
components use various techniques to detect whether a kernel-mode or user-mode
debugger is running on a victim. T1574Hijack Execution FlowBlackLotus 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 T1562Impair DefensesBlackLotus components can disable BitLocker and
Windows Defender to avoid detection. T1070.004Indicator Removal: File
DeletionBlackLotus 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. T1070.009Indicator Removal: Clear
PersistenceBlackLotus can uninstall itself by removing all bootkit files from
the ESP and restoring original victim’s Windows Boot Manager.
T1036.005Masquerading: Match Legitimate Name or LocationBlackLotus 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).
T1112Modify RegistryBlackLotus installer modifies Windows registry to disable
Windows HVCI security feature. T1027Obfuscated Files or InformationAlmost all
embedded strings in BlackLotus components are encrypted using a custom combined
cipher and decrypted only when needed. T1027.007Obfuscated Files or Information:
Dynamic API ResolutionBlackLotus components use dynamic API resolution while
using API names’ hashes instead of names. T1027.009Obfuscated Files or
Information: Embedded PayloadsAlmost all embedded files in BlackLotus components
are encrypted using AES. T1542.003Pre-OS Boot: BootkitBlackLotus 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. T1055.012Process Injection: Dynamic-link Library InjectionBlackLotus
HTTP downloader can inject a DLL into a newly created svchost.exe process using
process hollowing. T1055.002Process Injection: Portable Executable
InjectionBlackLotus driver injects the HTTP downloader portable executable into
a winlogon.exe process. T1014RootkitBlackLotus kernel driver protects the
bootkit files on the ESP from removal. T1497.001Virtualization/Sandbox Evasion:
System ChecksBlackLotus employs various system checks including checking
sandbox-specific registry values, to detect and avoid virtualization and
analysis environments. DiscoveryT1622Debugger EvasionBlackLotus components use
various techniques to detect whether a kernel-mode or user-mode debugger is
running on a victim. T1082System Information DiscoveryBlackLotus collects system
information (IP, GPU, CPU, memory, OS version) on a compromised host.
T1614System Location DiscoveryBlackLotus 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. T1016System Network Configuration DiscoveryBlackLotus HTTP
downloader can determine the public IP of a compromised host by requesting
api.ipify[.]org service. T1016.001System Network Configuration Discovery:
Internet Connection DiscoveryBlackLotus HTTP downloader checks the internet
connection by querying Microsoft’s www.msftncsi[.]com/ncsi[.]txt
T1497.001Virtualization/Sandbox Evasion: System ChecksBlackLotus employs various
system checks including checking sandbox-specific registry values, to detect and
avoid virtualization and analysis environments. Command and
ControlT1071.001Application Layer Protocol: Web ProtocolsBlackLotus uses HTTPS
for communication with its C&C. T1132.001Data Encoding: Standard
EncodingBlackLotus encodes encrypted data in C&C communication with URL-safe
base64. T1573.001Encrypted Channel: Symmetric CryptographyBlackLotus uses
256-bit AES in CBC mode to decrypt messages received from its C&C.
T1573.002Encrypted Channel: Asymmetric CryptographyBlackLotus uses an embedded
RSA public key to encrypt messages sent to C&C.

Martin Smolár
1 Mar 2023 - 11:30AM

SIGN UP TO RECEIVE AN EMAIL UPDATE WHENEVER A NEW ARTICLE IS PUBLISHED IN OUR
UKRAINE CRISIS – DIGITAL SECURITY RESOURCE CENTER

Submit

NEWSLETTER

Submit

www.welivesecurity.com Open in urlscan Pro 2a02:26f0:11a::6867:4831 Public Scan

Form analysis 5 forms found in the DOM

GET https://www.welivesecurity.com/

GET https://www.welivesecurity.com/

GET https://www.welivesecurity.com/

POST https://enjoy.eset.com/pub/rf

POST https://enjoy.eset.com/pub/rf

Text Content

www.welivesecurity.com Open in urlscan Pro
2a02:26f0:11a::6867:4831 Public Scan

Form analysis
5 forms found in the DOM