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 affordable 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 techniques 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 generally known 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 varied OS safety mechanisms and deploying their very own kernel-mode or user-mode payloads in early OS startup phases. 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 resembling 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 – resembling LoJax; the primary in-the-wild UEFI firmware implant, found by our group in 2018 – as bootkits are positioned on an simply accessible FAT32 disk partition. Nonetheless, operating as a bootloader offers them virtually 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). Positive, 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 techniques 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 part – 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 appreciate that what we had been coping with right here isn’t just common malware.

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

• It’s able to operating on the newest, totally patched Home windows 11 techniques with UEFI Safe Boot enabled.
• It exploits a multiple 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 attainable 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 professional – however weak – binaries to the system so as to exploit the vulnerability.
• It’s able to disabling OS safety mechanisms resembling BitLocker, HVCI, and Home windows Defender.
• As soon as put in, the bootkit’s essential aim is to deploy a kernel driver (which, amongst different issues, protects the bootkit from removing), and an HTTP downloader chargeable 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 will not be merely a rip-off.
• Apparently, 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 very least October 6^th, 2022. At this level, we now have not been capable of 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 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 is determined by occurs, we’re involved that issues will change quickly ought to this bootkit will get into the palms 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 plenty 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 obtainable 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 record is presently unattainable, because the vulnerability impacts a whole bunch of bootloaders which might be nonetheless used right now. ✅
  • True: It exploits CVE-2022-21894 so as to break Safe Boot and obtain persistence on UEFI-Safe-Boot-enabled techniques. 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 removing. ✅
  • True: Its kernel driver protects handles belonging to its information 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 Loss of life (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 varied anti-VM, anti-debug, and obfuscation methods to make it more durable to duplicate or analyze. Nonetheless, we’re undoubtedly not speaking about any breakthrough or superior anti-analysis methods right here, as they are often simply overcome with little effort.
• BlackLotus’s commercial on hacking boards claims that its function is to behave as an HTTP downloader. ✅
  • True: Its last part 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 professional 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 will possibly disable built-in Home windows safety protections resembling HVCI, Bitlocker, Home windows Defender, and bypass Consumer Account Management (UAC). ✅

Based mostly on these details, 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 essential components:

1. It begins with the execution of an installer (step 1 in Determine 2), which is chargeable for deploying the bootkit’s information 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 techniques 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 elements are capable of obtain and execute further user-mode and driver elements from the C&C server and defend the bootkit in opposition to removing (steps 5–9 in Determine 2).

Determine 2. BlackLotus simplified execution overview

Fascinating artifacts

Though 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 stuffed with references to the Higurashi When They Cry anime collection, for instance in particular person part names, resembling 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 varied strings containing messages from the BlackLotus creator (as proven in Determine 4 – be aware, that hasherezade is a well known researcher and creator of varied malware-analysis instruments), or simply some random quotes from varied songs, video games, or collection.

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

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 two variations – offline and on-line. The distinction between these two is in the way in which they receive professional (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 instantly 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 aim of the installer is evident – it’s chargeable for disabling Home windows security measures resembling BitLocker disk encryption and HVCI, and for deployment of a number of information, together with the malicious bootkit, to the ESP. As soon as completed, it reboots the compromised machine to let the dropped information do their job – to ensure the self-signed UEFI bootkit can 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 information 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 through the use of the UAC bypass methodology described intimately right here: UAC bypass via Program Compatibility assistant.

With the mandatory privileges, it continues, checking the UEFI Safe Boot standing by studying the worth of the SecureBoot UEFI variable utilizing an obtainable Home windows API operate, and figuring out the Home windows model by instantly 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 help was first added in Home windows 8 and won’t be enabled on any given machine).

Earlier than continuing to the subsequent steps, it renames the professional 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 obtained from the C&C server – extra within the C&C communication part.

Step 1 – Deploying information

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

A listing of information dropped by the installer with a brief rationalization of the position of every file within the execution chain is offered in Desk 1. We’ll clarify intimately how the execution chain works later; now simply be aware that a number of professional Microsoft-signed information are dropped together with the malicious ones.

Desk 1. Information deployed by the BlackLotus installer on techniques 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 software. Since UEFI Safe Boot is disabled (and thus no integrity verification is carried out throughout the boot), exploitation will not be mandatory 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 make it possible for HVCI is disabled on the system. One in every of 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) provides a number of safety options with essentially 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 weak drivers from being abused to execute unsigned kernel code or load malicious drivers (whatever the exploitation methodology used) and evidently 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 chargeable for disabling HVCI

Step 3 – Disabling BitLocker

The following characteristic deactivated by the installer is BitLocker Drive Encryption. The rationale for that is that BitLocker can be utilized in a mix with Trusted Platform Module (TPM) to make sure that varied boot information 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 techniques with TPM help would result in a BitLocker restoration display 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 methodology of the Win32_EncryptableVolume WMI class
• for these protected by BitLocker, it calls the DisableKeyProtectors methodology with the DisableCount parameter set to zero, that means that the safety can be suspended till it’s manually enabled

With the mandatory protections disabled and all information deployed, the installer registers itself to be deleted throughout 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 take a look at how BlackLotus achieves persistence on techniques with UEFI Safe Boot enabled. Because the execution chain we’re about to explain is sort of advanced, we’ll first clarify primary rules 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 Companies features are nonetheless obtainable. 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, resembling modifying Boot-services-only NVRAM variables. And that is what attackers make the most of 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 will possibly use a professional Microsoft-signed shim for loading its self-signed (signed by the personal key belonging to the important thing written to MokList) UEFI bootkit as a substitute 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 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 continues to be attainable as a result of the affected binaries have nonetheless not been added to the UEFI revocation list. In consequence, attackers can deliver their very own copies of weak binaries to their victims’ machines to take advantage of this vulnerability and bypass Safe Boot on up-to-date UEFI techniques.

Furthermore, a Proof of Idea (PoC) exploit for this vulnerability has been publicly obtainable since August 2022. Contemplating the date of the primary BlackLotus VirusTotal submission (see Determine 1), the malware developer has probably simply tailored the obtainable 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, largely summarizing key factors from the write-up printed together with the PoC on GitHub:

• Affected Home windows Boot Functions (resembling bootmgr.efi, hvloader.efi, winload.efi…) enable eradicating a serialized Safe Boot coverage from reminiscence – earlier than it will get loaded by the applying – through the use of 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 take advantage of this vulnerability – three of them are printed within the PoC repository.
• For instance, one of many PoCs reveals how it may be exploited to make the professional 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 record under 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 techniques, the primary boot possibility is by default bootmgfw.efi positioned within the ESP:/EFI/Microsoft/Boot folder on the ESP. This time, as a substitute 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 reveals a comparability of the professional BCD and the modified one.
3. As you may see in Determine 7 (path underlined with inexperienced), the professional 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 component set to worth 0x10000000 and the customized:22000023 BCD component pointing to a different attackers’ BCD saved in ESP:system32bcd. The reason of utilizing these parts might be discovered within the printed PoC:

The attacker wants to make sure the serialised Safe Boot Coverage is allotted above a identified bodily tackle.
[…]
The avoidlowmemory component can be utilized to make sure all allocations of bodily reminiscence are above a specified bodily tackle.
 • Since Home windows 10, this component 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 component aka customized:22000023) can be utilized to bypass this.

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

4. Within the subsequent step, the executed ESP:system32bootmgr.efi hundreds that further 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 take advantage of 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, 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 must be loaded in bodily addresses above 0x10000000 (due to avoidlowmemory utilized in earlier steps), specifying the truncatememory component will successfully take away it – thus, break the Safe Boot and permit using 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 professional hvloader.efi hundreds 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 chargeable for loading this mcupdate*.dll binary is proven in Determine 9. Be aware that hvloader.efi would usually load this professional 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 attributable to the BCD choices machine and systemroot used within the BCD from Determine 8 specifying the present machine as boot – that means the ESP – and likewise specifying SystemRoot to be the foundation () listing on this machine.

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

7. Now, because the attackers’ personal self-signed mcupdate*.dll is loaded and executed, it continues with executing the ultimate part 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 circulate from Determine 6 – step 8… The MokInstaller UEFI software 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 professional 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. Be aware that this variable is formatted in the identical manner as some other UEFI signature database variables (resembling db or dbx) and it will possibly encompass zero or extra signature lists of sort EFI_SIGNATURE_LIST – as outlined within the UEFI Specification.
   3. Deleting all information 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 often the default second-stage bootloader executed by a shim on x86-64 techniques).

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 aim is to deploy a kernel driver and a last user-mode part – 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 prospect of profitable deployment and stealthy operation. Earlier than leaping to the main points about how that’s achieved, let’s summarize the fundamentals in regards to the kernel driver and HTTP downloader:

• The kernel driver is chargeable for
  • Deploying the subsequent part of the chain – an HTTP downloader.
  • Protecting the loader alive in case of termination.
  • Defending bootkit information from being faraway from ESP.
  • Executing further 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 chargeable for:
  • Speaking with its C&C.
  • Executing instructions obtained from the C&C.
  • Downloading and executing payloads obtained from the C&C (helps each kernel payloads and user-mode payloads).

The total execution circulate (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 circulate

1. As a primary step, the UEFI firmware executes the default Home windows boot possibility, which is the file often saved in EFIMicrosoftBootbootmgfw.efi. As we described earlier (Bootkit persistence section, 8 .a), the MokInstaller binary changed this file with a professional 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, resembling HVCI and Credential Guard is not going to be initialized.
5. Within the following steps (5. a–e), the bootkit continues with a typical sample utilized by UEFI bootkits. It intercepts the execution of elements included within the typical Home windows boot circulate, resembling Home windows Boot Supervisor, Home windows OS loader, and Home windows OS kernel, and hooks a few of their features 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 features 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 correct 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 under are patched on this hook. The code from this hook chargeable 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 part – the HTTP downloader – into it.

Kernel driver

The kernel driver is chargeable for 4 essential duties:

• Injecting the HTTP downloader into winlogon.exe and reinjecting it in case the thread terminated.
• Defending bootkit information 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 mandatory, performing any instructions.

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

HTTP downloader persistence

The kernel driver is chargeable for deployment of the HTTP downloader. When the driving 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 driving force decrypts the HTTP downloader binary, injects it into winlogon.exe’s tackle house, and executes it in a brand new thread. Then, the driving force retains periodically checking whether or not the thread continues to be operating, and repeats the injection if mandatory. The HTTP downloader gained’t be deployed if a kernel debugger is detected by the driving force.

Defending bootkit information on the ESP from removing

To guard the bootkit’s information positioned on the ESP, the kernel driver makes use of a easy trick. It opens all information 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 information. The next information are protected:

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

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

Determine 15. An try and delete the information protected by BlackLotus driver

As one other layer of safety, in case the person or safety software program would be capable of 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 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 capable of do its job – resembling scanning information – correctly. Nonetheless, as this performance is poorly carried out, it may be made ineffective by restarting the MsMpEng.exe course of.

Communication with the HTTP downloader

See Also

Updating GOV.UK’s crown – Inside GOV.UK

• BaseNamedObjects101c1b: for the named part (solely the primary three octets of the MAC are used)
• BaseNamedObjectsZ01c1b: for the named occasion – similar as for the Part, however the first digit of the MAC tackle is changed with Z

In case the HTTP downloader desires to cross some command to the kernel driver, it merely creates a named part, writes a command with related knowledge inside, and waits for the command to be processed by the driving force by making a named occasion and ready till the driving force triggers (or alerts) it.

The driving force helps the next self-explanatory instructions:

• Set up kernel driver
• Uninstall BlackLotus

A cautious reader may discover the BlackLotus weak level right here – though the bootkit protects its elements in opposition to removing, the kernel driver might be tricked to uninstall the bootkit fully by creating the abovementioned named objects and sending the uninstall command to it.

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 a substitute of actual C&C addresses)

Knowledge obtained 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 will not be 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 much like the beacon, a JSON-formatted string, and specifies a command identifier (known as Kind) and varied further parameters resembling:

• C&C communication interval
• Execution methodology 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 instantly 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 information instantly 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 creator tried to restrict visibility of ordinary file artifacts, resembling textual content strings, imports, or different unencrypted embedded knowledge to a minimal. Beneath is a abstract of the methods used.

• String and knowledge encryption
  • All strings used throughout the samples are encrypted utilizing a easy cipher.
  • All embedded information are encrypted utilizing 256-bit AES in CBC mode.
  • Encryption keys for particular person information can range from pattern to pattern.
  • Along with AES encryption, some information are additionally compressed utilizing LZMS.
• Runtime-only API decision
  • In all samples (when relevant), Home windows APIs are all the time resolved solely throughout runtime and performance hashes as a substitute 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 atmosphere or utilizing an AES key offered by the C&C.
• Anti-debug and anti-VM methods – if used, often positioned proper firstly of the entry level. Solely informal sandbox or debugger detection methods are used.

Mitigations and remediation

• Initially, after all, holding your system and its safety product updated is a should – to lift an opportunity {that a} risk can be stopped proper firstly, 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 techniques, dbx updates must 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 techniques, restoration photographs, or backups unbootable – and subsequently, revocation typically takes too lengthy.
• Be aware that revocation of the Home windows purposes 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 may make the system unbootable. To recuperate on this case, an OS reinstall or simply ESP restoration would resolve the problem.
• If the revocation would occur after BlackLotus persistence is about, the bootkit would stay useful, because it makes use of a professional 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 through the use of the mokutil utility (bodily presence is required to carry out this operation as a consequence of mandatory person interplay with the MOK Supervisor throughout the boot).

Takeaways

Many important vulnerabilities affecting safety of UEFI techniques 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 techniques weak even a very long time after the vulnerabilities have been mounted – or at the very least after we had been instructed they had 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 yr:

• Initially, 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 resembling BlackLotus to stealthily function on techniques 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 units affected are usually not supported by the OEM anymore, thus not mounted (though 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 enable attackers to disable UEFI Safe Boot very simply. As identified by fellow researchers from Binarly, a number of units listed within the advisory had been left unpatched, or not patched accurately, even few months after the advisory – leaving the units weak. For sure, much like the earlier case, some units will keep weak eternally, as they’ve reached their Finish-Of-Help date.

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

IoCs

Information

Certificates

Community

MITRE ATT&CK methods

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