BlackLotus UEFI bootkit: Fantasy confirmed

The variety of UEFI vulnerabilities found lately and the failures in patching them or revoking susceptible binaries inside an inexpensive time window hasn’t gone unnoticed by risk actors. In consequence, the primary publicly identified UEFI bootkit bypassing the important platform safety characteristic – UEFI Safe Boot – is now a actuality. On this blogpost we current the primary public evaluation of this UEFI bootkit, which is able to operating on even fully-up-to-date Home windows 11 programs with UEFI Safe Boot enabled. Performance of the bootkit and its particular person options leads us to consider that we’re coping with a bootkit referred to as BlackLotus, the UEFI bootkit being sold on hacking forums for $5,000 since at the very least October 2022.

UEFI bootkits are very highly effective threats, having full management over the OS boot course of and thus able to disabling numerous OS safety mechanisms and deploying their very own kernel-mode or user-mode payloads in early OS startup phases. This enables them to function very stealthily and with excessive privileges. Up to now, only some have been found within the wild and publicly described (e.g., a number of malicious EFI samples we found in 2020, or absolutely featured UEFI bootkits comparable to our discovery final 12 months – the ESPecter bootkit – or the FinSpy bootkit found by researchers from Kaspersky).

UEFI bootkits might lose on stealthiness when in comparison with firmware implants – comparable to LoJax; the primary in-the-wild UEFI firmware implant, found by our staff in 2018 – as bootkits are situated on an simply accessible FAT32 disk partition. Nevertheless, operating as a bootloader provides them nearly the identical capabilities as firmware implants, however with out having to beat the multilevel SPI flash defenses, such because the BWE, BLE, and PRx safety bits, or the protections offered by {hardware} (like Intel Boot Guard). Certain, UEFI Safe Boot stands in the way in which of UEFI bootkits, however there are a non-negligible variety of identified vulnerabilities that permit bypassing this important safety mechanism. And the worst of that is that a few of them are nonetheless simply exploitable on up-to-date programs even on the time of this writing – together with the one exploited by BlackLotus.

Our investigation began with just a few hits on what turned out to be the BlackLotus user-mode element – an HTTP downloader – in our telemetry late in 2022. After an preliminary evaluation, code patterns discovered within the samples introduced us to the invention of six BlackLotus installers (each on VirusTotal and in our personal telemetry). This allowed us to discover the entire execution chain and to understand that what we have been coping with right here is not only common malware.

Following are the important thing factors about BlackLotus and a timeline summarizing the sequence of occasions associated to it:

• It’s able to operating on the newest, absolutely patched Home windows 11 programs with UEFI Safe Boot enabled.
• It exploits a a couple of 12 months outdated vulnerability (CVE-2022-21894) to bypass UEFI Safe Boot and arrange persistence for the bootkit. That is the primary publicly identified, in-the-wild abuse of this vulnerability.
• Though the vulnerability was mounted in Microsoft’s January 2022 replace, its exploitation remains to be potential because the affected, validly signed binaries have nonetheless not been added to the UEFI revocation list. BlackLotus takes benefit of this, bringing its personal copies of reputable – however susceptible – binaries to the system to be able to exploit the vulnerability.
• It’s able to disabling OS safety mechanisms comparable to BitLocker, HVCI, and Home windows Defender.
• As soon as put in, the bootkit’s principal objective is to deploy a kernel driver (which, amongst different issues, protects the bootkit from elimination), and an HTTP downloader accountable for communication with the C&C and able to loading further user-mode or kernel-mode payloads.
• BlackLotus has been marketed and offered on underground boards since at the very least October 6^th, 2022. On this blogpost, we current proof that the bootkit is actual, and the commercial is just not merely a rip-off.
• Curiously, among the BlackLotus installers we now have analyzed don’t proceed with bootkit set up if the compromised host makes use of one of many 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 particular person occasions associated to BlackLotus is proven in Determine 1.

Determine 1. Timeline of main occasions associated to BlackLotus UEFI bootkit

As already talked about, the bootkit has been offered on underground boards since at the very least October 6^th, 2022. At this level, we now have not been in a position to determine, from our telemetry, the precise distribution channel used to deploy the bootkit to victims. The low variety of BlackLotus samples we now have been in a position to receive, each from public sources and our telemetry, leads us to consider that not many risk actors have began utilizing it but. However till the revocation of the susceptible bootloaders that BlackLotus will depend on occurs, we’re involved that issues will change quickly ought to this bootkit will get into the arms of the well-known crimeware teams, primarily based on the bootkit’s simple deployment and crimeware teams’ capabilities for spreading malware utilizing their botnets.

Is that this actually BlackLotus?

There are a number of articles or posts summarizing details about BlackLotus (here, here and here and plenty of extra…), all primarily based on the data offered by the bootkit developer on underground hacking boards. Up to now, nobody has confirmed or disproved these claims.

Right here is our abstract of the claims from the out there publications in contrast with what we found whereas reverse engineering the bootkit samples:

• BlackLotus’s commercial on hacking boards claims that it options built-in Safe Boot bypass. Including susceptible drivers to the UEFI revocation checklist is at the moment inconceivable, because the vulnerability impacts a whole bunch of bootloaders which can be nonetheless used as we speak. ✅
  • True: It exploits CVE-2022-21894 to be able to break Safe Boot and obtain persistence on UEFI-Safe-Boot-enabled programs. Susceptible drivers it makes use of are nonetheless not revoked within the newest dbx, on the time of writing.
• BlackLotus’s commercial on hacking boards claims that the bootkit has built-in Ring0/Kernel safety in opposition to elimination. ✅
  • True: Its kernel driver protects handles belonging to its recordsdata on the EFI System Partition (ESP) in opposition to closing. As an extra layer of safety, these handles are repeatedly monitored and a Blue Display screen Of Dying (BSOD) triggered if any of those handles are closed, as described within the Protecting bootkit files on the ESP from removal part.
• BlackLotus’s commercial on hacking boards claims that it comes with anti-virtual-machine (anti-VM), anti-debug, and code obfuscation options to dam malware evaluation makes an attempt. ✅
  • True: It comprises numerous anti-VM, anti-debug, and obfuscation strategies to make it tougher to duplicate or analyze. Nevertheless, we’re positively not speaking about any breakthrough or superior anti-analysis strategies right here, as they are often simply overcome with little effort.
• BlackLotus’s commercial on hacking boards claims that its objective is to behave as an HTTP downloader. ✅
  • True: Its closing element acts as an HTTP downloader, as described within the HTTP downloader part
• BlackLotus’s commercial on hacking boards claims that the HTTP downloader runs underneath the SYSTEM account inside a reputable course of. ✅
  • True: Its HTTP downloader runs throughout the winlogon.exe course of context.
• BlackLotus’s commercial on hacking boards claims it’s a tiny bootkit with an on-disk dimension of solely 80 kB. ✅
  • True: Samples we have been in a position to receive actually are round 80 kB.
• BlackLotus’s commercial on hacking boards claims that it may well disable built-in Home windows safety protections comparable to HVCI, Bitlocker, Home windows Defender, and bypass Person Account Management (UAC). ✅

Based mostly on these info, we consider with excessive confidence that the bootkit we found within the wild is the BlackLotus UEFI bootkit.

Assault overview

A simplified scheme of the BlackLotus compromise chain is proven in Determine 2. It consists of three principal elements:

1. It begins with the execution of an installer (step 1 in Determine 2), which is accountable for deploying the bootkit’s recordsdata to the EFI System partition, disabling HVCI and BitLocker, after which rebooting the machine.
2. After the primary reboot, exploitation of CVE-2022-21894 and subsequent enrollment of the attackers’ Machine Owner Key (MOK) happens, to realize persistence even on programs with UEFI Safe Boot enabled. The machine is then rebooted (steps 2–4 in Determine 2) once more.
3. In all subsequent boots, the self-signed UEFI bootkit is executed and deploys each its kernel driver and user-mode payload, the HTTP downloader. Collectively, these parts are in a position to obtain and execute further user-mode and driver parts from the C&C server and shield the bootkit in opposition to elimination (steps 5–9 in Determine 2).

Determine 2. BlackLotus simplified execution overview

Attention-grabbing artifacts

Although we consider that is the BlackLotus UEFI bootkit, we didn’t discover any reference to this title within the samples we analyzed. As an alternative, the code is filled with references to the Higurashi When They Cry anime sequence, for instance in particular person element names, comparable to higurashi_installer_uac_module.dll and higurashi_kernel.sys, and likewise within the self-signed certificates used to signal the bootkit binary (proven in Determine 3).

Determine 3. Self-signed certificates utilized by the BlackLotus bootkit

Moreover, the code decrypts however by no means makes use of numerous strings containing messages from the BlackLotus writer (as proven in Determine 4 – observe, that hasherezade is a well known researcher and writer of varied malware-analysis instruments), or simply some random quotes from numerous songs, video games, or sequence.

Determine 4. Instance of messages left within the code by the BlackLotus writer

Set up course of

We begin with evaluation of the BlackLotus installers. The bootkit appears to be distributed in a type of installers that are available in two variations – offline and on-line. The distinction between these two is in the way in which they receive reputable (however susceptible) Home windows binaries, later used for bypassing Safe Boot.

• In offline variations, Home windows binaries are embedded within the installer
• In on-line variations, Home windows binaries are downloaded immediately from the Microsoft image retailer. Up to now, we’ve seen the next Home windows binaries being abused by the BlackLotus bootkit:
  • https://msdl.microsoft.com/obtain/symbols/bootmgfw.efi/7144BCD31C0000/bootmgfw.efi
  • https://msdl.microsoft.com/obtain/symbols/bootmgr.efi/98B063A61BC000/bootmgr.efi
  • https://msdl.microsoft.com/obtain/symbols/hvloader.efi/559F396411D000/hvloader.efi

The objective of the installer is evident – it’s accountable for disabling Home windows security measures comparable to BitLocker disk encryption and HVCI, and for deployment of a number of recordsdata, together with the malicious bootkit, to the ESP. As soon as completed, it reboots the compromised machine to let the dropped recordsdata do their job – to ensure the self-signed UEFI bootkit will probably be silently executed on each system begin, no matter UEFI Safe Boot safety standing.

Step 0 – Initialization and (potential) elevation

When the installer is executed, it checks whether or not it has sufficient privileges (at the very least admin required) to deploy the remainder of the recordsdata to the ESP and carry out different actions requiring elevated course of – like turning off HVCI or disabling BitLocker. If it’s not the case, it tries to raise by executing the installer once more by utilizing the UAC bypass methodology described intimately right here: UAC bypass via Program Compatibility assistant.

With the required privileges, it continues, checking the UEFI Safe Boot standing by studying the worth of the SecureBoot UEFI variable utilizing an out there Home windows API operate, and figuring out the Home windows model by immediately accessing the KUSER_SHARED_DATA construction fields NtMajorVersion and NtMinorVersion in reminiscence. It does so to determine whether or not or not bypassing UEFI Safe Boot is critical to deploy the bootkit on the sufferer’s system (since Safe Boot assist was first added in Home windows 8 and may not be enabled on any given machine).

Earlier than continuing to the following steps, it renames the reputable Home windows Boot Supervisor (bootmgfw.efi) binary situated within the ESP:EFIMicrosoftBoot listing to winload.efi. This renamed bootmgfw.efi backup is later utilized by the bootkit to launch the OS, or to recuperate the unique boot chain if the “uninstall” command is acquired from the C&C server – extra within the C&C communication part.

Step 1 – Deploying recordsdata

If UEFI Safe Boot is enabled, the installer proceeds with dropping a number of recordsdata into the ESP:/EFI/Microsoft/Boot/ and ESP:/system32/ directories. Whereas the previous is a regular listing utilized by Home windows, the latter is a customized folder created by the installer.

A listing of recordsdata dropped by the installer with a brief clarification of the function of every file within the execution chain is offered in Desk 1. We are going to clarify intimately how the execution chain works later; now simply observe that a number of reputable Microsoft-signed recordsdata are dropped together with the malicious ones.

Desk 1. Information deployed by the BlackLotus installer on programs with UEFI Safe Boot enabled

In instances when the sufferer is operating a Home windows model not supporting UEFI Safe Boot, or within the case when it’s disabled, the deployment is sort of simple. The one factor that’s wanted to deploy the malicious bootkit is to switch the prevailing Home windows Boot Supervisor (bootmgfw.efi) binary within the ESP:EFIMicrosoftBoot listing, with the attackers’ personal self-signed malicious UEFI utility. Since UEFI Safe Boot is disabled (and thus no integrity verification is carried out in the course of the boot), exploitation is just not vital and the UEFI firmware merely executes the malicious boot supervisor with out inflicting any safety violations.

Step 2 – Disabling Hypervisor-protected Code Integrity (HVCI)

To have the ability to run customized unsigned kernel code later, the installer has to guarantee that HVCI is disabled on the system. One among our ESET colleagues wrote a really informative blogpost on this subject in 2022 (Signed kernel drivers – Unguarded gateway to Windows’ core):

Virtualization-based safety (VBS) gives a number of safety options with probably the most distinguished one being Hypervisor-Protected Code Integrity (HVCI), which additionally comes as a standalone characteristic. HVCI enforces code integrity within the kernel and permits solely signed code to be executed. It successfully prevents susceptible drivers from being abused to execute unsigned kernel code or load malicious drivers (whatever the exploitation methodology used) and evidently malware abusing susceptible drivers to load malicious code was one of many main motivations behind Microsoft implementing this feature.

As proven in Determine 5, to disable this characteristic, the installer units the Enabled registry worth underneath the HypervisorEnforcedCodeIntegrity registry key to zero.

Determine 5. Hex-Rays decompiled code of BlackLotus installer operate accountable for disabling HVCI

Step 3 – Disabling BitLocker

The following characteristic deactivated by the installer is BitLocker Drive Encryption. The explanation for that is that BitLocker can be utilized in a mix with Trusted Platform Module (TPM) to make sure that numerous boot recordsdata and configurations, together with Safe Boot, haven’t been tampered with since BitLocker drive encryption was configured on the system. Contemplating that the installer modifies the Home windows boot chain on a compromised machine, conserving BitLocker on for programs with TPM assist would result in a BitLocker restoration display screen on the subsequent bootup and would tip the sufferer off that the system had been compromised.

To disable this safety, the BlackLotus installer:

• walks by means of all volumes underneath the RootCIMV2SecurityMicrosoftVolumeEncryption WMI namespace and checks their safety standing by calling the GetProtectionStatus methodology of the Win32_EncryptableVolume WMI class
• for these protected by BitLocker, it calls the DisableKeyProtectors methodology with the DisableCount parameter set to zero, which means that the safety will probably be suspended till it’s manually enabled

With the required protections disabled and all recordsdata deployed, the installer registers itself to be deleted in the course of the subsequent system restart and reboots the machine to proceed to the exploitation of CVE-2022-21894.

Bypassing Safe Boot and establishing persistence

On this half, we take a better have a look at how BlackLotus achieves persistence on programs with UEFI Safe Boot enabled. Because the execution chain we’re about to explain is sort of complicated, we are going to first clarify fundamental ideas after which dig deeper into technical particulars.

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

1. Exploiting CVE-2022-21894 to bypass the Safe Boot characteristic and set up the bootkit. This enables arbitrary code execution in early boot phases, the place the platform remains to be owned by firmware and UEFI Boot Companies capabilities are nonetheless out there. This enables attackers to do many issues that they shouldn’t be in a position to do on a machine with UEFI Safe Boot enabled with out having bodily entry to it, comparable to modifying Boot-services-only NVRAM variables. And that is what attackers reap the benefits of to arrange persistence for the bootkit within the subsequent step. Extra details about exploitation could be discovered within the Exploiting CVE-2022-21894 part.
2. Setting persistence by writing its personal MOK to the MokList, Boot-services-only NVRAM variable. By doing this, it may well use a reputable Microsoft-signed shim for loading its self-signed (signed by the personal key belonging to the important thing written to MokList) UEFI bootkit as an alternative of exploiting the vulnerability on each boot. Extra about this within the Bootkit persistence part.

To make the detailed evaluation within the subsequent two sections simpler, we are going to observe the steps proven within the execution diagram, Determine 6.

Determine 6. Bypassing Safe Boot and establishing persistence utilizing MOK

Exploiting CVE-2022-21894

To bypass Safe Boot, BlackLotus makes use of the baton drop (CVE-2022-21894): Secure Boot Security Feature Bypass Vulnerability. Regardless of its excessive impression on system safety, this vulnerability didn’t get as a lot public consideration because it deserved. Though the vulnerability was mounted in Microsoft’s January 2022 replace, its exploitation remains to be potential as a result of the affected binaries have nonetheless not been added to the UEFI revocation list. In consequence, attackers can convey their very own copies of susceptible binaries to their victims’ machines to use this vulnerability and bypass Safe Boot on up-to-date UEFI programs.

Furthermore, a Proof of Idea (PoC) exploit for this vulnerability has been publicly out there since August 2022. Contemplating the date of the primary BlackLotus VirusTotal submission (see Determine 1), the malware developer has seemingly simply tailored the out there PoC to their wants with none want of deep understanding of how this exploit works.

Let’s begin with a short introduction to the vulnerability, principally summarizing key factors from the write-up revealed together with the PoC on GitHub:

• Affected Home windows Boot Functions (comparable to bootmgr.efi, hvloader.efi, winload.efi…) permit eradicating a serialized Safe Boot coverage from reminiscence – earlier than it will get loaded by the appliance – by utilizing the truncatememory BCD boot choice.
• This enables attackers to make use of different harmful BCD choices like bootdebug, testsigning, or nointegritychecks, thus breaking Safe Boot.
• There are numerous methods to use this vulnerability – three of them are revealed within the PoC repository.
• For instance, one of many PoCs exhibits how it may be exploited to make the reputable hvloader.efi load an arbitrary, self-signed mcupdate_<platform>.dll binary (the place <platform> could be GenuineIntel or AuthenticAMD, primarily based on the machine’s CPU.).

Now, we proceed with describing how BlackLotus exploits this vulnerability (numbers within the checklist beneath describe corresponding steps in Determine 6):

1. After the installer reboots the machine, the UEFI firmware proceeds with loading a primary boot choice. For Home windows programs, the primary boot choice is by default bootmgfw.efi situated within the ESP:/EFI/Microsoft/Boot folder on the ESP. This time, as an alternative of executing the unique sufferer’s bootmgfw.efi (which was beforehand renamed winload.efi by the installer), the firmware executes the susceptible one – deployed by the installer.
2. After bootmgfw.efi is executed, it masses the BCD boot choices, beforehand modified by the installer. Determine 7 exhibits a comparability of the reputable BCD and the modified one.
3. As you possibly can see in Determine 7 (path underlined with inexperienced), the reputable Home windows Boot Supervisor would usually load the Home windows OS loader (WINDOWSsystem32winload.efi) as a default boot utility. However this time, with the modified BCD, it continues with loading the susceptible ESP:system32bootmgr.efi, with the avoidlowmemory BCD ingredient set to worth 0x10000000 and the customized:22000023 BCD ingredient pointing to a different attackers’ BCD saved in ESP:system32bcd. The reason of utilizing these components could be discovered within the revealed PoC:

The attacker wants to make sure the serialised Safe Boot Coverage is allotted above a identified bodily tackle.
[…]
The avoidlowmemory ingredient can be utilized to make sure all allocations of bodily reminiscence are above a specified bodily tackle.
 • Since Home windows 10, this ingredient is disallowed if VBS is enabled, however as it’s used throughout boot utility initialisation, earlier than the serialised Safe Boot coverage is learn from reminiscence, loading bootmgr and specifying a customized BCD path (utilizing bcdfilepath ingredient aka customized:22000023) can be utilized to bypass this.

Determine 7. Authentic BCD retailer (BEFORE) vs the one utilized by the BlackLotus installer (AFTER)

4. Within the subsequent step, the executed ESP:system32bootmgr.efi masses that further BCD situated in ESP:system32bcd. Parsed content material of this extra BCD is proven in Determine 8.

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

5. Due to choices loaded from the BCD file proven in Determine 8, bootmgr.efi continues with loading one other susceptible Home windows Boot Utility deployed by the installer – ESP:system32hvloader.efi – which is the Home windows Hypervisor Loader. Extra importantly, further BCD choices are laid out in the identical BCD file (see Determine 8):
   1. truncatememory with worth set to 0x10000000
   2. nointegritychecks set to Sure
   3. and testsigning, additionally set to Sure

And that is the place the magic occurs. Because the serialized Safe Boot coverage ought to be loaded in bodily addresses above 0x10000000 (due to avoidlowmemory utilized in earlier steps), specifying the truncatememory ingredient will successfully take away it – thus, break the Safe Boot and permit the usage of harmful BCD choices like nointegritychecks or testsigning. Through the use of these choices, the attackers could make the hvloader.efi execute their very own, self-signed code. 

6. To do that, the identical trick as described within the PoC is used: throughout its execution, the reputable hvloader.efi masses and executes the mcupdate_ AuthenticAMD.dll native binary from the <machine>:<SystemRoot>system32 listing. Commented Hex-Rays decompiled code of the operate from hvloader.efi accountable for loading this mcupdate*.dll binary is proven in Determine 9. Word that hvloader.efi would usually load this reputable mcupdate*.dll binary from the <OS_partition>:Windowssystem32, however this time the malicious attackers’ self-signed mcupdate*.dll is executed from a customized ESP listing beforehand created by the installer (ESP:system32). It’s brought on by the BCD choices machine and systemroot used within the BCD from Determine 8 specifying the present machine as boot – which means the ESP – and likewise specifying SystemRoot to be the basis () listing on this machine.

Determine 9. Hex-Rays decompilation of the BtLoadUpdateDll operate from the reputable hvloader.efi, accountable for loading mcupdate_*.dll

7. Now, because the attackers’ personal self-signed mcupdate*.dll is loaded and executed, it continues with executing the ultimate element on this chain – an embedded MokInstaller (UEFI Utility) – see Determine 10 for particulars about the way it’s executed.

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

Bootkit persistence

Determine 11. MOK boot course of overview (image source)

8. Persevering with with describing the move from Determine 6 – step 8… The MokInstaller UEFI utility continues with establishing persistence for the BlackLotus UEFI bootkit and protecting the tracks of exploitation by:
   1. Restoring the sufferer’s unique BCD retailer from the backup created by the installer and changing the efi with the reputable Microsoft-signed shim, beforehand dropped to the ESP:system32bootload.efi by the installer.
   2. Making a MokList NVRAM variable containing the attackers’ self-signed public key certificates. Word that this variable is formatted in the identical approach as some other UEFI signature database variables (comparable to db or dbx) and it may well encompass zero or extra signature lists of kind EFI_SIGNATURE_LIST – as outlined within the UEFI Specification.
   3. Deleting all recordsdata concerned in exploitation from the attackers‘ ESP:system32 folder.
9. In the long run, it reboots the machine to make the deployed shim execute the self-signed bootkit dropped to EFIMicrosoftBootgrubx64.efi by the installer (grubx64.efi is normally the default second-stage bootloader executed by a shim on x86-64 programs).

Determine 12. Hex-Rays decompiled code – MokInstaller UEFI app establishing persistence for the BlackLotus bootkit

BlackLotus UEFI bootkit

As soon as the persistence is configured, the BlackLotus bootkit is executed on each system begin. The bootkit’s objective is to deploy a kernel driver and a closing user-mode element – the HTTP downloader. Throughout its execution, it tries to disable further Home windows security measures – Virtualization-Based mostly Safety (VBS) and Home windows Defender – to lift the possibility of profitable deployment and stealthy operation. Earlier than leaping to the main points about how that’s executed, let’s summarize the fundamentals in regards to the kernel driver and HTTP downloader:

• The kernel driver is accountable for
  • Deploying the following element of the chain – an HTTP downloader.
  • Preserving the loader alive in case of termination.
  • Defending bootkit recordsdata from being faraway from ESP.
  • Executing further kernel payloads, if that’s the case instructed by the HTTP downloader.
  • Uninstalling the bootkit, if that’s the case instructed by the HTTP downloader.
• The HTTP downloader is accountable for:
  • Speaking with its C&C.
  • Executing instructions acquired from the C&C.
  • Downloading and executing payloads acquired from the C&C (helps each kernel payloads and user-mode payloads).

The total execution move (simplified), from the installer to HTTP downloader, is proven in Determine 13. We describe these particular person steps in additional element within the subsequent part.

Determine 13. Diagram exhibiting execution of the BlackLotus UEFI bootkit

BlackLotus execution move

1. As a primary step, the UEFI firmware executes the default Home windows boot choice, which is the file normally saved in EFIMicrosoftBootbootmgfw.efi. As we described earlier (Bootkit persistence section, 8 .a), the MokInstaller binary changed this file with a reputable signed shim.
2. When the shim is executed, it reads the MokList NVRAM variable, and makes use of the certificates beforehand saved inside by the attackers to confirm the second-stage bootloader – the self-signed BlackLotus UEFI bootkit situated in EFIMicrosoftBootgrubx64.efi.
3. When verified, the shim executes the bootkit.
4. The bootkit begins with creating the Boot-only VbsPolicyDisable NVRAM variable. As described here, this variable is evaluated by the Home windows OS loader throughout boot and if outlined, the core VBS options, comparable to HVCI and Credential Guard won’t be initialized.
5. Within the following steps (5. a–e), the bootkit continues with a standard sample utilized by UEFI bootkits. It intercepts the execution of parts included within the typical Home windows boot move, comparable to Home windows Boot Supervisor, Home windows OS loader, and Home windows OS kernel, and hooks a few of their capabilities in reminiscence. As a bonus, it additionally makes an attempt to disable Home windows Defender by patching a few of its drivers. All this to realize its payload’s execution within the early phases of the OS startup course of and to keep away from detection. The next capabilities are hooked or patched:
   1. ImgArchStartBootApplication in bootmgfw.efi or bootmgr.efi:
      This operate is usually hooked by bootkits to catch the second when the Home windows OS loader (winload.efi) is loaded within the reminiscence however nonetheless hasn’t been executed – which is the suitable second to carry out extra in-memory patching.
   2. BlImgAllocateImageBuffer in winload.efi:
      Used to allocate an extra reminiscence buffer for the malicious kernel driver.
   3. OslArchTransferToKernel in winload.efi:
      Hooked to catch the second when the OS kernel and among the system drivers are already loaded within the reminiscence, however nonetheless haven’t been executed – which is an ideal second to carry out extra in-memory patching. The drivers talked about beneath are patched on this hook. The code from this hook accountable for discovering applicable drivers in reminiscence is proven in Determine 14.
   4. WdBoot.sys and WdFilter.sys:
      BlackLotus patches the entry level of WdBoot.sys and WdFilter.sys – the Home windows Defender ELAM driver and the Home windows Defender file system filter driver, respectively – to return instantly.
   5. disk.sys:
      The bootkit hooks the entry level of the disk.sys driver to execute the BlackLotus kernel driver within the early phases of system initialization.

Determine 14. Hex-Rays decompiled code of OslArchTransferToKernel hook – patching Home windows Defender drivers and trying to find the disk.sys entry level

6. Subsequent, when the OS kernel executes the disk.sys driver’s entry level, the put in hook jumps to the malicious kernel driver entry level. The malicious code in flip restores the unique disk.sys to permit the system to operate correctly and waits till the winlogon.exe course of begins.
7. When the malicious driver detects that the winlogon.exe course of has began, it injects and executes the ultimate user-mode element – the HTTP downloader – into it.

Kernel driver

The kernel driver is accountable for 4 principal duties:

• Injecting the HTTP downloader into winlogon.exe and reinjecting it in case the thread terminated.
• Defending bootkit recordsdata deployed on the ESP from being eliminated.
• Disarming the user-mode Home windows Defender course of MsMpEngine.exe.
• Speaking with the HTTP downloader and if vital, performing any instructions.

Let’s have a look at them one after the other.

HTTP downloader persistence

The kernel driver is accountable for deployment of the HTTP downloader. When the motive force begins, it waits till the method named winlogon.exe begins, earlier than taking some other actions. As soon as the method has began, the motive force decrypts the HTTP downloader binary, injects it into winlogon.exe’s tackle area, and executes it in a brand new thread. Then, the motive force retains periodically checking whether or not the thread remains to be operating, and repeats the injection if vital. The HTTP downloader gained’t be deployed if a kernel debugger is detected by the motive force.

Defending bootkit recordsdata on the ESP from elimination

To guard the bootkit’s recordsdata situated on the ESP, the kernel driver makes use of a easy trick. It opens all recordsdata it desires to guard, duplicates and saves their handles, and makes use of the ObSetHandleAttributes kernel operate specifying the ProtectFromClose flag inside HandleFlags (OBJECT_HANDLE_FLAG_INFORMATION) parameter to 1 – thus defending the handles from being closed by some other processes. This can thwart any makes an attempt to take away or modify the protected recordsdata. The next recordsdata are protected:

• ESP:EFIMicrosoftBootwinload.efi
• ESP:EFIMicrosoftBootbootmgfw.efi
• ESP:EFIMicrosoftBootgrubx64.efi

Ought to a consumer attempt to delete these protected recordsdata, one thing like what’s proven in Determine 15 will happen.

Determine 15. An try to delete the recordsdata protected by BlackLotus driver

As one other layer of safety, in case the consumer or safety software program would be capable of unset the safety flag and shut the handles, the kernel driver repeatedly screens them, and causes a BSOD by calling the KeBugCheck(INVALID_KERNEL_HANDLE) operate if any of the handles don’t exist anymore.

Disarming the principle Home windows Defender course of

The kernel driver additionally tries to disarm the principle Home windows Defender course of – MsMpEng.exe. It does so by eradicating all course of’s token privileges by setting the SE_PRIVILEGE_REMOVED attribute to every of them. In consequence, the Defender course of shouldn’t be in a position to do its job – comparable to scanning recordsdata – correctly. Nevertheless, as this performance is poorly applied, it may be made ineffective by restarting the MsMpEng.exe course of.

Communication with the HTTP downloader

HTTP downloader

C&C communication

Determine 17. Instance of a beacon HTTP POST message (generated by a pattern from VirusTotal – the one with native IPs as an alternative of actual C&C addresses)

Knowledge acquired from the C&C as a response to the beacon message ought to begin with the two-byte magic worth HP; in any other case, the response is just not processed additional. If the magic worth is appropriate, the info following the magic worth is decrypted utilizing 256-bit AES in CBC mode with abovementioned HWID string used as the important thing.

After decryption, the message is just like the beacon, a JSON-formatted string, and specifies a command identifier (known as Sort) and numerous further parameters comparable to:

• C&C communication interval
• Execution methodology to make use of
• Payload filename
• Payload kind primarily based on file extension(.sys, .exe, or .dll supported)
• Authentication token that’s supposed for use to request obtain of payload information
• AES key used for decrypting the payload information

All supported instructions and their descriptions are listed in Desk 2.

Desk 2. C&C instructions

In these instructions, the C&C can specify, whether or not the payload ought to first be dropped to disk earlier than executing it, or be executed immediately in reminiscence. In instances involving dropping the file to disk, the ProgramData folder on the OS quantity is used because the vacation spot folder and filename and extension are specified by the C&C server. Within the case of executing recordsdata immediately in reminiscence, svchost.exe is used as an injection goal. When the C&C sends a command requiring kernel driver cooperation, or an operator desires to execute code in kernel-mode, the mechanism described within the Communication with the HTTP downloader part is used.

Anti-analysis methods

To make detection and evaluation of this piece of malware tougher, its writer tried to restrict visibility of ordinary file artifacts, comparable to textual content strings, imports, or different unencrypted embedded information to a minimal. Under is a abstract of the strategies used.

• String and information encryption
  • All strings used throughout the samples are encrypted utilizing a easy cipher.
  • All embedded recordsdata are encrypted utilizing 256-bit AES in CBC mode.
  • Encryption keys for particular person recordsdata can differ from pattern to pattern.
  • Along with AES encryption, some recordsdata are additionally compressed utilizing LZMS.
• Runtime-only API decision
  • In all samples (when relevant), Home windows APIs are at all times resolved completely throughout runtime and performance hashes as an alternative of operate names are used to seek out the specified API operate addresses in reminiscence.
  • In some instances, a direct syscall instruction invocation is used to invoke the specified system operate.
• Community communication
  • Communicates utilizing HTTPS.
  • All messages despatched to the C&C by the HTTP downloader are encrypted utilizing an embedded RSA public key.
  • All messages despatched from the C&C to the HTTP downloader are encrypted utilizing a key derived from the sufferer’s machine surroundings or utilizing an AES key offered by the C&C.
• Anti-debug and anti-VM methods – if used, normally positioned proper initially of the entry level. Solely informal sandbox or debugger detection methods are used.

Mitigations and remediation

• To begin with, after all, conserving your system and its safety product updated is a should – to lift an opportunity {that a} risk will probably be stopped proper initially, earlier than it’s in a position to obtain pre-OS persistence.
• Then, the important thing step that must be taken to stop utilization of identified susceptible UEFI binaries for bypassing UEFI Safe Boot is their revocation within the UEFI revocation database (dbx) – on a Home windows programs, dbx updates ought to be distributed utilizing Home windows Updates.
• The issue is that revocation of broadly used Home windows UEFI binaries can result in making hundreds of outdated programs, restoration photographs, or backups unbootable – and subsequently, revocation usually takes too lengthy.
• Word that revocation of the Home windows purposes utilized by BlackLotus would forestall set up of the bootkit, however because the installer would substitute the sufferer’s bootloader with the revoked one, it may make the system unbootable. To recuperate on this case, an OS reinstall or simply ESP restoration would resolve the difficulty.
• If the revocation would occur after BlackLotus persistence is about, the bootkit would stay useful, because it makes use of a reputable shim with customized MOK key for persistence. On this case, the most secure mitigation resolution can be to reinstall Home windows and take away the attackers’ enrolled MOK key by utilizing the mokutil utility (bodily presence is required to carry out this operation because of vital consumer interplay with the MOK Supervisor in the course of the boot).

Takeaways

Many vital vulnerabilities affecting safety of UEFI programs have been found in the previous few years. Sadly, due the complexity of the entire UEFI ecosystem and associated supply-chain issues, many of those vulnerabilities have left many programs susceptible even a very long time after the vulnerabilities have been mounted – or at the very least after we have been advised they have been mounted. For a greater picture, listed here are some examples of the patch or revocation failures permitting UEFI Safe Boot bypasses simply from the final 12 months:

• To begin with, after all, CVE-2022-21894 – the vulnerability exploited by BlackLotus. One 12 months for the reason that vulnerability was mounted, susceptible UEFI binaries are nonetheless not revoked, permitting threats comparable to BlackLotus to stealthily function on programs with UEFI Safe Boot enabled, thus offering victims a false sense of safety.
• Early in 2022, we disclosed a number of UEFI vulnerabilities that permit, amongst different issues, disabling UEFI Safe Boot. Many units affected usually are not supported by the OEM anymore, thus not mounted (despite the fact that these units weren’t so outdated – like 3-5 years on the time of vulnerability disclosure). Learn extra in our blogpost: When “secure” isn’t secure at all: High‑impact UEFI vulnerabilities discovered in Lenovo consumer laptops
• Later in 2022, we found a few other UEFI vulnerabilities, whose exploitation would additionally permit attackers to disable UEFI Safe Boot very simply. As identified by fellow researchers from Binarly, a number of units listed within the advisory have been left unpatched, or not patched accurately, even few months after the advisory – leaving the units susceptible. Evidently, just like the earlier case, some units will keep susceptible endlessly, as they’ve reached their Finish-Of-Help date.

It was only a matter of time earlier than somebody would reap the benefits of these failures and create a UEFI bootkit able to working on programs with UEFI Safe Boot enabled. As we prompt final 12 months in our RSA presentation, all of this makes the transfer to the ESP extra possible for attackers and a potential approach ahead for UEFI threats – the existence of BlackLotus confirms this.

IoCs

Information

Certificates

Community

MITRE ATT&CK strategies

This desk was constructed utilizing version 12 of the MITRE ATT&CK framework.