BlackLotus UEFI bootkit: Fable confirmed

The variety of UEFI vulnerabilities found in recent times and the failures in patching them or revoking weak binaries inside an inexpensive time window hasn’t gone unnoticed by risk actors. Consequently, 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 methods with UEFI Safe Boot enabled. Performance of the bootkit and its particular person options leads us to imagine 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 least October 2022.

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

UEFI bootkits could lose on stealthiness when in comparison with firmware implants – equivalent to LoJax; the primary in-the-wild UEFI firmware implant, found by our crew in 2018 – as bootkits are positioned 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 enable bypassing this important safety mechanism. And the worst of that is that a few of them are nonetheless simply exploitable on up-to-date methods 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 had 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, totally patched Home windows 11 methods with UEFI Safe Boot enabled.
• It exploits a a couple of yr 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 continues 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 weak – binaries to the system with the intention to exploit the vulnerability.
• It’s able to disabling OS safety mechanisms equivalent to BitLocker, HVCI, and Home windows Defender.
• As soon as put in, the bootkit’s fundamental 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 extra user-mode or kernel-mode payloads.
• BlackLotus has been marketed and offered on underground boards since at the least October 6^th, 2022. On this blogpost, we current proof that the bootkit is actual, and the commercial isn’t merely a rip-off.
• Curiously, a few of 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 least October 6^th, 2022. At this level, we now have not been capable of establish, from our telemetry, the precise distribution channel used to deploy the bootkit to victims. The low variety of BlackLotus samples we now have been capable of receive, each from public sources and our telemetry, leads us to imagine that not many risk actors have began utilizing it but. However till the revocation of the weak bootloaders that BlackLotus depends upon occurs, we’re involved that issues will change quickly ought to this bootkit will get into the arms of the well-known crimeware teams, based mostly 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 lots of extra…), all based mostly on the data offered by the bootkit developer on underground hacking boards. Thus far, nobody has confirmed or disproved these claims.

Right here is our abstract of the claims from the accessible 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 weak drivers to the UEFI revocation checklist is at the moment unattainable, because the vulnerability impacts a whole lot of bootloaders which are nonetheless used as we speak. ✅
  • True: It exploits CVE-2022-21894 with the intention to break Safe Boot and obtain persistence on UEFI-Safe-Boot-enabled methods. Weak 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 constantly monitored and a Blue Display 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 incorporates varied anti-VM, anti-debug, and obfuscation strategies to make it more durable to copy or analyze. Nevertheless, we’re undoubtedly 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 goal is to behave as an HTTP downloader. ✅
  • True: Its remaining 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 measurement of solely 80 kB. ✅
  • True: Samples we had been capable of receive actually are round 80 kB.
• BlackLotus’s commercial on hacking boards claims that it might disable built-in Home windows safety protections equivalent to HVCI, Bitlocker, Home windows Defender, and bypass Person Account Management (UAC). ✅

Based mostly on these info, we imagine 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 fundamental 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 methods 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 capable of obtain and execute extra user-mode and driver parts from the C&C server and defend the bootkit in opposition to elimination (steps 5–9 in Determine 2).

Determine 2. BlackLotus simplified execution overview

Fascinating artifacts

Despite the fact that we imagine that is the BlackLotus UEFI bootkit, we didn’t discover any reference to this identify 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, equivalent to higurashi_installer_uac_module.dll and higurashi_kernel.sys, and in addition 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 varied strings containing messages from the BlackLotus writer (as proven in Determine 4 – word, that hasherezade is a well known researcher and writer of assorted malware-analysis instruments), or simply some random quotes from varied 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 weak) 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 straight from the Microsoft image retailer. Thus far, 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 safety features equivalent 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 shall 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 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 technique 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 accessible Home windows API operate, and figuring out the Home windows model by straight accessing the KUSER_SHARED_DATA construction fields NtMajorVersion and NtMinorVersion in reminiscence. It does so to resolve whether or not or not bypassing UEFI Safe Boot is important 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 positioned 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 rationalization of the position 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 word that a number of reputable Microsoft-signed recordsdata are dropped together with the malicious ones.

Desk 1. Recordsdata deployed by the BlackLotus installer on methods 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 kind of simple. The one factor that’s wanted to deploy the malicious bootkit is to exchange the present Home windows Boot Supervisor (bootmgfw.efi) binary within the ESP:EFIMicrosoftBoot listing, with the attackers’ personal self-signed malicious UEFI software. Since UEFI Safe Boot is disabled (and thus no integrity verification is carried out through the boot), exploitation isn’t crucial 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 ensure that HVCI is disabled on the system. One in every of our ESET colleagues wrote a really informative blogpost on this matter in 2022 (Signed kernel drivers – Unguarded gateway to Windows’ core):

Virtualization-based safety (VBS) affords a number of safety options with essentially the most outstanding 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 weak drivers from being abused to execute unsigned kernel code or load malicious drivers (whatever the exploitation technique used) and plainly malware abusing weak 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 mixture with Trusted Platform Module (TPM) to make sure that varied 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, holding BitLocker on for methods 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 way of all volumes underneath the RootCIMV2SecurityMicrosoftVolumeEncryption WMI namespace and checks their safety standing by calling the GetProtectionStatus technique of the Win32_EncryptableVolume WMI class
• for these protected by BitLocker, it calls the DisableKeyProtectors technique with the DisableCount parameter set to zero, that means that the safety shall be suspended till it’s manually enabled

With the required protections disabled and all recordsdata deployed, the installer registers itself to be deleted through 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 more in-depth have a look at how BlackLotus achieves persistence on methods with UEFI Safe Boot enabled. Because the execution chain we’re about to explain is kind of advanced, we’ll 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 permits arbitrary code execution in early boot phases, the place the platform continues to be owned by firmware and UEFI Boot Providers capabilities are nonetheless accessible. This permits attackers to do many issues that they shouldn’t be capable of do on a machine with UEFI Safe Boot enabled with out having bodily entry to it, equivalent to modifying Boot-services-only NVRAM variables. And that is what attackers benefit from to arrange persistence for the bootkit within the subsequent step. Extra details about exploitation might 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 might use a reputable Microsoft-signed shim for loading its self-signed (signed by the non-public 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’ll comply with 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 influence 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 continues to be potential as a result of the affected binaries have nonetheless not been added to the UEFI revocation list. Consequently, attackers can convey their very own copies of weak binaries to their victims’ machines to use this vulnerability and bypass Safe Boot on up-to-date UEFI methods.

Furthermore, a Proof of Idea (PoC) exploit for this vulnerability has been publicly accessible since August 2022. Contemplating the date of the primary BlackLotus VirusTotal submission (see Determine 1), the malware developer has probably simply tailored the accessible 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 (equivalent to bootmgr.efi, hvloader.efi, winload.efi…) enable eradicating a serialized Safe Boot coverage from reminiscence – earlier than it will get loaded by the appliance – by utilizing the truncatememory BCD boot possibility.
• This permits 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 example, 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> might be GenuineIntel or AuthenticAMD, based mostly 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 possibility. For Home windows methods, the primary boot possibility is by default bootmgfw.efi positioned 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 weak one – deployed by the installer.
2. After bootmgfw.efi is executed, it hundreds 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 software. However this time, with the modified BCD, it continues with loading the weak 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 parts might be discovered within the revealed PoC:

The attacker wants to make sure the serialised Safe Boot Coverage is allotted above a identified bodily deal with.
[…]
The avoidlowmemory ingredient can be utilized to make sure all allocations of bodily reminiscence are above a specified bodily deal with.
 • Since Home windows 10, this ingredient is disallowed if VBS is enabled, however as it’s used throughout boot software 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. Respectable BCD retailer (BEFORE) vs the one utilized by the BlackLotus installer (AFTER)

4. Within the subsequent step, the executed ESP:system32bootmgr.efi hundreds that extra BCD positioned 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 weak Home windows Boot Software deployed by the installer – ESP:system32hvloader.efi – which is the Home windows Hypervisor Loader. Extra importantly, extra 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 needs 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 using harmful BCD choices like nointegritychecks or testsigning. By utilizing 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 hundreds and executes the mcupdate_ AuthenticAMD.dll native binary from the <gadget>:<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. Notice 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 gadget and systemroot used within the BCD from Determine 8 specifying the present gadget as boot – that means the ESP – and in addition specifying SystemRoot to be the foundation () listing on this gadget.

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 Software) – see Determine 10 for particulars about the way it’s achieved.

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 movement from Determine 6 – step 8… The MokInstaller UEFI software continues with establishing persistence for the BlackLotus UEFI bootkit and overlaying the tracks of exploitation by:
   1. Restoring the sufferer’s authentic 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. Notice that this variable is formatted in the identical manner as every other UEFI signature database variables (equivalent to db or dbx) and it might encompass zero or extra signature lists of sort 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 methods).

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 remaining user-mode element – the HTTP downloader. Throughout its execution, it tries to disable extra Home windows safety features – Virtualization-Based mostly Safety (VBS) and Home windows Defender – to boost the possibility of profitable deployment and stealthy operation. Earlier than leaping to the small print about how that’s achieved, 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 extra kernel payloads, in that case instructed by the HTTP downloader.
  • Uninstalling the bootkit, in that 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 complete execution movement (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 displaying execution of the BlackLotus UEFI bootkit

BlackLotus execution movement

1. As a primary step, the UEFI firmware executes the default Home windows boot possibility, 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 positioned 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, equivalent 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 movement, equivalent 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 levels 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 often 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 precise 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 a few of 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 levels 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 fundamental 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 crucial, 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 every other actions. As soon as the method has began, the motive force decrypts the HTTP downloader binary, injects it into winlogon.exe’s deal with house, and executes it in a brand new thread. Then, the motive force retains periodically checking whether or not the thread continues to be operating, and repeats the injection if crucial. The HTTP downloader received’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 positioned 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 every other processes. It will 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 person 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 person or safety software program would be capable to unset the safety flag and shut the handles, the kernel driver constantly 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 primary Home windows Defender course of

The kernel driver additionally tries to disarm the primary 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. Consequently, the Defender course of shouldn’t be capable of do its job – equivalent 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 isn’t processed additional. If the magic worth is appropriate, the information 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 Kind) and varied extra parameters equivalent to:

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

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 straight 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 straight 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 more durable, its writer tried to restrict visibility of normal file artifacts, equivalent to textual content strings, imports, or different unencrypted embedded knowledge to a minimal. Beneath is a abstract of the strategies used.

• String and knowledge 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 range 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 search 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 setting or utilizing an AES key offered by the C&C.
• Anti-debug and anti-VM methods – if used, normally positioned proper in the beginning of the entry level. Solely informal sandbox or debugger detection methods are used.

Mitigations and remediation

• To begin with, after all, holding your system and its safety product updated is a should – to boost an opportunity {that a} risk shall be stopped proper in the beginning, earlier than it’s capable of obtain pre-OS persistence.
• Then, the important thing step that must be taken to forestall utilization of identified weak UEFI binaries for bypassing UEFI Safe Boot is their revocation within the UEFI revocation database (dbx) – on a Home windows methods, dbx updates needs 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 methods, restoration photographs, or backups unbootable – and due to this fact, revocation typically takes too lengthy.
• Notice that revocation of the Home windows functions utilized by BlackLotus would stop set up of the bootkit, however because the installer would substitute the sufferer’s bootloader with the revoked one, it might 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 answer 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 on account of crucial person interplay with the MOK Supervisor through the boot).

Takeaways

Many crucial vulnerabilities affecting safety of UEFI methods 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 methods weak even a very long time after the vulnerabilities have been mounted – or at the least after we had been informed they had been mounted. For a greater picture, listed below are some examples of the patch or revocation failures permitting UEFI Safe Boot bypasses simply from the final yr:

• To begin with, after all, CVE-2022-21894 – the vulnerability exploited by BlackLotus. One yr for the reason that vulnerability was mounted, weak UEFI binaries are nonetheless not revoked, permitting threats equivalent to BlackLotus to stealthily function on methods with UEFI Safe Boot enabled, thus offering victims a false sense of safety.
• Early in 2022, we disclosed a number of UEFI vulnerabilities that enable, amongst different issues, disabling UEFI Safe Boot. Many gadgets affected will not be supported by the OEM anymore, thus not mounted (though these gadgets 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 enable attackers to disable UEFI Safe Boot very simply. As identified by fellow researchers from Binarly, a number of gadgets listed within the advisory had been left unpatched, or not patched appropriately, even few months after the advisory – leaving the gadgets weak. For sure, just like the earlier case, some gadgets will keep weak perpetually, as they’ve reached their Finish-Of-Help date.

It was only a matter of time earlier than somebody would benefit from these failures and create a UEFI bootkit able to working on methods with UEFI Safe Boot enabled. As we advised final yr in our RSA presentation, all of this makes the transfer to the ESP extra possible for attackers and a potential manner ahead for UEFI threats – the existence of BlackLotus confirms this.

IoCs

Recordsdata

Certificates

Community

MITRE ATT&CK strategies

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