{
	"id": "7e4abf55-1ef2-41a1-b305-95a26d415ed6",
	"created_at": "2026-04-06T00:06:18.418917Z",
	"updated_at": "2026-04-10T03:21:06.241169Z",
	"deleted_at": null,
	"sha1_hash": "02a621ef55e355eeee9801f663b69f23ac0d6559",
	"title": "BlackLotus UEFI bootkit: Myth confirmed",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1736541,
	"plain_text": "BlackLotus UEFI bootkit: Myth confirmed\r\nBy Martin Smolár\r\nArchived: 2026-04-05 17:08:03 UTC\r\nThe number of UEFI vulnerabilities discovered in recent years and the failures in patching them or revoking vulnerable\r\nbinaries within a reasonable time window hasn’t gone unnoticed by threat actors. As a result, the first publicly known UEFI\r\nbootkit bypassing the essential platform security feature – UEFI Secure Boot – is now a reality. In this blogpost we present\r\nthe first public analysis of this UEFI bootkit, which is capable of running on even fully-up-to-date Windows 11 systems with\r\nUEFI Secure Boot enabled. Functionality of the bootkit and its individual features leads us to believe that we are dealing\r\nwith a bootkit known as BlackLotus, the UEFI bootkit being sold on hacking forums for $5,000 since at least October 2022.\r\nUEFI bootkits are very powerful threats, having full control over the OS boot process and thus capable of disabling various\r\nOS security mechanisms and deploying their own kernel-mode or user-mode payloads in early OS startup stages. This\r\nallows them to operate very stealthily and with high privileges. So far, only a few have been discovered in the wild and\r\npublicly described (e.g., multiple malicious EFI samples we discovered in 2020, or fully featured UEFI bootkits such as our\r\ndiscovery last year – the ESPecter bootkit – or the FinSpy bootkit discovered by researchers from Kaspersky).\r\nUEFI bootkits may lose on stealthiness when compared to firmware implants – such as LoJax; the first in-the-wild UEFI\r\nfirmware implant, discovered by our team in 2018 – as bootkits are located on an easily accessible FAT32 disk partition.\r\nHowever, running as a bootloader gives them almost the same capabilities as firmware implants, but without having to\r\novercome the multilevel SPI flash defenses, such as the BWE, BLE, and PRx protection bits, or the protections provided by\r\nhardware (like Intel Boot Guard). Sure, UEFI Secure Boot stands in the way of UEFI bootkits, but there are a non-negligible\r\nnumber of known vulnerabilities that allow bypassing this essential security mechanism. And the worst of this is that some\r\nof them are still easily exploitable on up-to-date systems even at the time of this writing – including the one exploited by\r\nBlackLotus.\r\nOur investigation started with a few hits on what turned out to be the BlackLotus user-mode component – an HTTP\r\ndownloader – in our telemetry late in 2022. After an initial assessment, code patterns found in the samples brought us to the\r\ndiscovery of six BlackLotus installers (both on VirusTotal and in our own telemetry). This allowed us to explore the whole\r\nexecution chain and to realize that what we were dealing with here is not just regular malware.\r\nFollowing are the key points about BlackLotus and a timeline summarizing the series of events related to it:\r\nIt’s capable of running on the latest, fully patched Windows 11 systems with UEFI Secure Boot enabled.\r\nIt exploits a more than one year old vulnerability (CVE-2022-21894) to bypass UEFI Secure Boot and set up\r\npersistence for the bootkit. This is the first publicly known, in-the-wild abuse of this vulnerability.\r\nAlthough the vulnerability was fixed in Microsoft’s January 2022 update, its exploitation is still possible as the\r\naffected, validly signed binaries have still not been added to the UEFI revocation list. BlackLotus takes advantage of\r\nthis, bringing its own copies of legitimate – but vulnerable – binaries to the system in order to exploit the\r\nvulnerability.\r\nIt’s capable of disabling OS security mechanisms such as BitLocker, HVCI, and Windows Defender.\r\nOnce installed, the bootkit’s main goal is to deploy a kernel driver (which, among other things, protects the bootkit\r\nfrom removal), and an HTTP downloader responsible for communication with the C\u0026C and capable of loading\r\nadditional user-mode or kernel-mode payloads.\r\nBlackLotus has been advertised and sold on underground forums since at least October 6th, 2022. In this blogpost, we\r\npresent evidence that the bootkit is real, and the advertisement is not merely a scam.\r\nInterestingly, some of the BlackLotus installers we have analyzed do not proceed with bootkit installation if the\r\ncompromised host uses one of the following locales:\r\nRomanian (Moldova), ro-MD\r\nRussian (Moldova), ru-MD\r\nRussian (Russia), ru-RU\r\nUkrainian (Ukraine) , uk-UA\r\nBelarusian (Belarus), be-BY\r\nArmenian (Armenia), hy-AM\r\nKazakh (Kazakhstan), kk-KZ\r\nhttps://www.welivesecurity.com/2023/03/01/blacklotus-uefi-bootkit-myth-confirmed/\r\nPage 1 of 26\n\nThe timeline of individual events related to BlackLotus is shown in Figure 1.\r\nFigure 1. Timeline of major events related to BlackLotus UEFI bootkit\r\nAs already mentioned, the bootkit has been sold on underground forums since at least October 6th, 2022. At this point, we\r\nhave not been able to identify, from our telemetry, the exact distribution channel used to deploy the bootkit to victims. The\r\nlow number of BlackLotus samples we have been able to obtain, both from public sources and our telemetry, leads us to\r\nbelieve that not many threat actors have started using it yet. But until the revocation of the vulnerable bootloaders that\r\nBlackLotus depends on happens, we are concerned that things will change rapidly should this bootkit gets into the hands of\r\nthe well-known crimeware groups, based on the bootkit’s easy deployment and crimeware groups’ capabilities for spreading\r\nmalware using their botnets.\r\nIs this really BlackLotus?\r\nThere are several articles or posts summarizing information about BlackLotus (here, here and here and many more…), all\r\nbased on the information provided by the bootkit developer on underground hacking forums. So far, no one has confirmed or\r\ndisproved these claims.\r\nHere is our summary of the claims from the available publications compared with what we discovered while reverse\r\nengineering the bootkit samples:\r\nBlackLotus’s advertisement on hacking forums claims that it features integrated Secure Boot bypass. Adding\r\nvulnerable drivers to the UEFI revocation list is currently impossible, as the vulnerability affects hundreds of\r\nbootloaders that are still used today. ✅\r\nTrue: It exploits CVE-2022-21894 in order to break Secure Boot and achieve persistence on UEFI-Secure-Boot-enabled systems. Vulnerable drivers it uses are still not revoked in the latest dbx, at the time of writing.\r\nBlackLotus’s advertisement on hacking forums claims that the bootkit has built-in Ring0/Kernel protection\r\nagainst removal. ✅\r\nTrue: Its kernel driver protects handles belonging to its files on the EFI System Partition (ESP) against\r\nclosing. As an additional layer of protection, these handles are continuously monitored and a Blue Screen Of\r\nDeath (BSOD) triggered if any of these handles are closed, as described in the Protecting bootkit files on the\r\nESP from removal section.\r\nBlackLotus’s advertisement on hacking forums claims that it comes with anti-virtual-machine (anti-VM), anti-debug, and code obfuscation features to block malware analysis attempts. ✅\r\nTrue: It contains various anti-VM, anti-debug, and obfuscation techniques to make it harder to replicate or\r\nanalyze. However, we are definitely not talking about any breakthrough or advanced anti-analysis techniques\r\nhere, as they can be easily overcome with little effort.\r\nBlackLotus’s advertisement on hacking forums claims that its purpose is to act as an HTTP downloader. ✅\r\nTrue: Its final component acts as an HTTP downloader, as described in the HTTP downloader section\r\nBlackLotus’s advertisement on hacking forums claims that the HTTP downloader runs under the SYSTEM\r\naccount within a legitimate process. ✅\r\nTrue: Its HTTP downloader runs within the winlogon.exe process context.\r\nhttps://www.welivesecurity.com/2023/03/01/blacklotus-uefi-bootkit-myth-confirmed/\r\nPage 2 of 26\n\nBlackLotus’s advertisement on hacking forums claims it is a tiny bootkit with an on-disk size of only 80 kB. ✅\r\nTrue: Samples we were able to obtain really are around 80 kB.\r\nBlackLotus’s advertisement on hacking forums claims that it can disable built-in Windows security\r\nprotections such as HVCI, Bitlocker, Windows Defender, and bypass User Account Control (UAC). ✅\r\nTrue: It can disable HVCI, Windows Defender, BitLocker, and bypass UAC.\r\nBased on these facts, we believe with high confidence that the bootkit we discovered in the wild is the BlackLotus UEFI\r\nbootkit.\r\nAttack overview\r\nA simplified scheme of the BlackLotus compromise chain is shown in Figure 2. It consists of three main parts:\r\n1. It starts with the execution of an installer (step 1 in Figure 2), which is responsible for deploying the bootkit’s files to\r\nthe EFI System partition, disabling HVCI and BitLocker, and then rebooting the machine.\r\n2. After the first reboot, exploitation of CVE-2022-21894 and subsequent enrollment of the attackers’ Machine Owner\r\nKey (MOK) occurs, to achieve persistence even on systems with UEFI Secure Boot enabled. The machine is then\r\nrebooted (steps 2–4 in Figure 2) again.\r\n3. In all subsequent boots, the self-signed UEFI bootkit is executed and deploys both its kernel driver and user-mode\r\npayload, the HTTP downloader. Together, these components are able to download and execute additional user-mode\r\nand driver components from the C\u0026C server and protect the bootkit against removal (steps 5–9 in Figure 2).\r\nhttps://www.welivesecurity.com/2023/03/01/blacklotus-uefi-bootkit-myth-confirmed/\r\nPage 3 of 26\n\nFigure 2. BlackLotus simplified execution overview\r\nInteresting artifacts\r\nEven though we believe this is the BlackLotus UEFI bootkit, we did not find any reference to this name in the samples we\r\nanalyzed. Instead, the code is full of references to the Higurashi When They Cry anime series, for example in individual\r\ncomponent names, such as higurashi_installer_uac_module.dll and higurashi_kernel.sys, and also in the self-signed\r\ncertificate used to sign the bootkit binary (shown in Figure 3).\r\nhttps://www.welivesecurity.com/2023/03/01/blacklotus-uefi-bootkit-myth-confirmed/\r\nPage 4 of 26\n\nFigure 3. Self-signed certificate used by the BlackLotus bootkit\r\nAdditionally, the code decrypts but never uses various strings containing messages from the BlackLotus author (as shown in\r\nFigure 4 – note, that hasherezade is a well-known researcher and author of various malware-analysis tools), or just some\r\nrandom quotes from various songs, games, or series.\r\nFigure 4. Example of messages left in the code by the BlackLotus author\r\nInstallation process\r\nWe start with analysis of the BlackLotus installers. The bootkit seems to be distributed in a form of installers that come in\r\ntwo versions – offline and online. The difference between these two is in the way they obtain legitimate (but vulnerable)\r\nWindows binaries, later used for bypassing Secure Boot.\r\nIn offline versions, Windows binaries are embedded in the installer\r\nIn online versions, Windows binaries are downloaded directly from the Microsoft symbol store. So far, we’ve seen\r\nthe following Windows binaries being abused by the BlackLotus bootkit:\r\nhttps://msdl.microsoft.com/download/symbols/bootmgfw.efi/7144BCD31C0000/bootmgfw.efi\r\nhttps://msdl.microsoft.com/download/symbols/bootmgr.efi/98B063A61BC000/bootmgr.efi\r\nhttps://msdl.microsoft.com/download/symbols/hvloader.efi/559F396411D000/hvloader.efi\r\nThe goal of the installer is clear – it’s responsible for disabling Windows security features such as BitLocker disk encryption\r\nand HVCI, and for deployment of multiple files, including the malicious bootkit, to the ESP. Once finished, it reboots the\r\ncompromised machine to let the dropped files do their job – to make sure the self-signed UEFI bootkit will be silently\r\nexecuted on every system start, regardless of UEFI Secure Boot protection status.\r\nStep 0 – Initialization and (potential) elevation\r\nWhen the installer is executed, it checks whether it has enough privileges (at least admin required) to deploy the rest of the\r\nfiles to the ESP and perform other actions requiring elevated process – like turning off HVCI or disabling BitLocker. If it’s\r\nnot the case, it tries to elevate by executing the installer again by using the UAC bypass method described in detail here:\r\nUAC bypass via Program Compatibility assistant.\r\nWith the necessary privileges, it continues, checking the UEFI Secure Boot status by reading the value of the SecureBoot\r\nUEFI variable using an available Windows API function, and determining the Windows version by directly accessing the\r\nKUSER_SHARED_DATA structure fields NtMajorVersion and NtMinorVersion in memory. It does so to decide whether or\r\nhttps://www.welivesecurity.com/2023/03/01/blacklotus-uefi-bootkit-myth-confirmed/\r\nPage 5 of 26\n\nnot bypassing UEFI Secure Boot is necessary to deploy the bootkit on the victim’s system (since Secure Boot support was\r\nfirst added in Windows 8 and might not be enabled on any given machine).\r\nBefore proceeding to the next steps, it renames the legitimate Windows Boot Manager (bootmgfw.efi) binary located in the\r\nESP:\\EFI\\Microsoft\\Boot\\ directory to winload.efi. This renamed bootmgfw.efi backup is later used by the bootkit to launch\r\nthe OS, or to recover the original boot chain if the “uninstall” command is received from the C\u0026C server – more in the C\u0026C\r\ncommunication section.\r\nStep 1 – Deploying files\r\nIf UEFI Secure Boot is enabled, the installer proceeds with dropping multiple files into the ESP:/EFI/Microsoft/Boot/ and\r\nESP:/system32/ directories. While the former is a standard directory used by Windows, the latter is a custom folder created\r\nby the installer.\r\nA list of files dropped by the installer with a short explanation of the role of each file in the execution chain is provided in\r\nTable 1. We will explain in detail how the execution chain works later; now just note that several legitimate Microsoft-signed files are dropped along with the malicious ones.\r\nTable 1. Files deployed by the BlackLotus installer on systems with UEFI Secure Boot enabled\r\nFolder Filename Description\r\nESP:\\EFI\\Microsoft\\Boot\r\ngrubx64.efi\r\nBlackLotus bootkit, malicious self-signed UEFI\r\napplication.\r\nbootload.efi\r\nLegitimate Microsoft-signed shim binary (temporary\r\nname, later replaces bootmgfw.efi after CVE-2022-21894\r\nexploitation).\r\nbootmgfw.efi\r\nLegitimate, but vulnerable (CVE-2022-21894) Windows\r\nBoot Manager binary, embedded in the installer or\r\ndownloaded directly from the Microsoft Symbol Store.\r\nBCD\r\nAttackers’ custom Boot Configuration Data (BCD) store\r\nused in CVE-2022-21894 exploitation chain.\r\nBCDR Backup of victim’s original BCD store.\r\nESP:\\system32\r\nhvloader.efi\r\nLegitimate, but vulnerable (CVE-2022-21894) Windows\r\nHypervisor Loader binary, embedded inside an installer\r\nor downloaded directly from the Microsoft Symbol Store.\r\nbootmgr.efi\r\nLegitimate, but vulnerable (CVE-2022-21894) Windows\r\nBoot Manager binary, embedded inside an installer or\r\ndownloaded directly from the Microsoft Symbol Store.\r\nmcupdate_AuthenticAMD.dll\r\nMalicious self-signed native PE binary. This file is\r\nexecuted by the hvloader.efi after successful CVE-2022-\r\n21894 exploitation (on systems using an AMD CPU).\r\nmcupdate_GenuineIntel.dll\r\nMalicious self-signed native PE binary. This file is\r\nexecuted by the hvloader.efi after successful CVE-2022-\r\n21894 exploitation (on systems using an Intel CPU).\r\nBCD\r\nAttackers’ custom BCD used in CVE-2022-21894\r\nexploitation chain.\r\nIn cases when the victim is running a Windows version not supporting UEFI Secure Boot, or in the case when it’s disabled,\r\nthe deployment is quite straightforward. The only thing that is needed to deploy the malicious bootkit is to replace the\r\nexisting Windows Boot Manager (bootmgfw.efi) binary in the ESP:\\EFI\\Microsoft\\Boot\\ directory, with the attackers’ own\r\nself-signed malicious UEFI application. Since UEFI Secure Boot is disabled (and thus no integrity verification is performed\r\nduring the boot), exploitation is not necessary and the UEFI firmware simply executes the malicious boot manager without\r\ncausing any security violations.\r\nhttps://www.welivesecurity.com/2023/03/01/blacklotus-uefi-bootkit-myth-confirmed/\r\nPage 6 of 26\n\nStep 2 – Disabling Hypervisor-protected Code Integrity (HVCI)\r\nTo be able to run custom unsigned kernel code later, the installer has to make sure that HVCI is disabled on the system. One\r\nof our ESET colleagues wrote a very informative blogpost on this topic in 2022 (Signed kernel drivers – Unguarded gateway\r\nto Windows’ core):\r\nVirtualization-based security (VBS) offers several protection features with the most prominent one being Hypervisor-Protected Code Integrity (HVCI), which also comes as a standalone feature. HVCI enforces code integrity in the kernel and\r\nallows only signed code to be executed. It effectively prevents vulnerable drivers from being abused to execute unsigned\r\nkernel code or load malicious drivers (regardless of the exploitation method used) and it seems that malware abusing\r\nvulnerable drivers to load malicious code was one of the main motivations behind Microsoft implementing this feature.\r\nAs shown in Figure 5, to disable this feature, the installer sets the Enabled registry value under the\r\nHypervisorEnforcedCodeIntegrity registry key to zero.\r\nFigure 5. Hex-Rays decompiled code of BlackLotus installer function responsible for disabling HVCI\r\nStep 3 – Disabling BitLocker\r\nThe next feature deactivated by the installer is BitLocker Drive Encryption. The reason for this is that BitLocker can be used\r\nin a combination with Trusted Platform Module (TPM) to ensure that various boot files and configurations, including Secure\r\nBoot, haven’t been tampered with since BitLocker drive encryption was configured on the system. Considering that the\r\ninstaller modifies the Windows boot chain on a compromised machine, keeping BitLocker on for systems with TPM support\r\nwould lead to a BitLocker recovery screen at the next bootup and would tip the victim off that the system had been\r\ncompromised.\r\nTo disable this protection, the BlackLotus installer:\r\nwalks through all volumes under the Root\\CIMV2\\Security\\MicrosoftVolumeEncryption WMI namespace and\r\nchecks their protection status by calling the GetProtectionStatus method of the Win32_EncryptableVolume WMI\r\nclass\r\nfor those protected by BitLocker, it calls the DisableKeyProtectors method with the DisableCount parameter set to\r\nzero, meaning that the protection will be suspended until it is manually enabled\r\nWith the necessary protections disabled and all files deployed, the installer registers itself to be deleted during the next\r\nsystem restart and reboots the machine to proceed to the exploitation of CVE-2022-21894.\r\nBypassing Secure Boot and establishing persistence\r\nIn this part, we take a closer look at how BlackLotus achieves persistence on systems with UEFI Secure Boot enabled. As\r\nthe execution chain we are about to describe is quite complex, we will first explain basic principles and then dig deeper into\r\ntechnical details.\r\nIn a nutshell, this process consists of two key steps:\r\nhttps://www.welivesecurity.com/2023/03/01/blacklotus-uefi-bootkit-myth-confirmed/\r\nPage 7 of 26\n\n1. Exploiting CVE-2022-21894 to bypass the Secure Boot feature and install the bootkit. This allows arbitrary code\r\nexecution in early boot phases, where the platform is still owned by firmware and UEFI Boot Services functions are\r\nstill available. This allows attackers to do many things that they should not be able to do on a machine with UEFI\r\nSecure Boot enabled without having physical access to it, such as modifying Boot-services-only NVRAM variables.\r\nAnd this is what attackers take advantage of to set up persistence for the bootkit in the next step. More information\r\nabout exploitation can be found in the Exploiting CVE-2022-21894 section.\r\n2. Setting persistence by writing its own MOK to the MokList, Boot-services-only NVRAM variable. By doing this, it\r\ncan use a legitimate Microsoft-signed shim for loading its self-signed (signed by the private key belonging to the key\r\nwritten to MokList) UEFI bootkit instead of exploiting the vulnerability on every boot. More about this in the Bootkit\r\npersistence section.\r\nTo make the detailed analysis in the next two sections easier, we will follow the steps shown in the execution diagram,\r\nFigure 6.\r\nhttps://www.welivesecurity.com/2023/03/01/blacklotus-uefi-bootkit-myth-confirmed/\r\nPage 8 of 26\n\nFigure 6. Bypassing Secure Boot and setting up persistence using MOK\r\nExploiting CVE-2022-21894\r\nhttps://www.welivesecurity.com/2023/03/01/blacklotus-uefi-bootkit-myth-confirmed/\r\nPage 9 of 26\n\nTo bypass Secure Boot, BlackLotus uses the baton drop (CVE-2022-21894): Secure Boot Security Feature Bypass\r\nVulnerability. Despite its high impact on system security, this vulnerability did not get as much public attention as it\r\ndeserved. Although the vulnerability was fixed in Microsoft’s January 2022 update, its exploitation is still possible because\r\nthe affected binaries have still not been added to the UEFI revocation list. As a result, attackers can bring their own copies of\r\nvulnerable binaries to their victims’ machines to exploit this vulnerability and bypass Secure Boot on up-to-date UEFI\r\nsystems.\r\nMoreover, a Proof of Concept (PoC) exploit for this vulnerability has been publicly available since August 2022.\r\nConsidering the date of the first BlackLotus VirusTotal submission (see Figure 1), the malware developer has likely just\r\nadapted the available PoC to their needs without any need of deep understanding of how this exploit works.\r\nLet’s start with a brief introduction to the vulnerability, mostly summarizing key points from the write-up published along\r\nwith the PoC on GitHub:\r\nAffected Windows Boot Applications (such as bootmgr.efi, hvloader.efi, winload.efi…) allow removing a serialized\r\nSecure Boot policy from memory – before it gets loaded by the application – by using the truncatememory BCD boot\r\noption.\r\nThis allows attackers to use other dangerous BCD options like bootdebug, testsigning, or nointegritychecks, thus\r\nbreaking Secure Boot.\r\nThere are various ways to exploit this vulnerability – three of them are published in the PoC repository.\r\nAs an example, one of the PoCs shows how it can be exploited to make the legitimate hvloader.efi load an arbitrary,\r\nself-signed mcupdate_\u003cplatform\u003e.dll binary (where \u003cplatform\u003e can be GenuineIntel or AuthenticAMD, based on the\r\nmachine’s CPU.).\r\nNow, we continue with describing how BlackLotus exploits this vulnerability (numbers in the list below describe\r\ncorresponding steps in Figure 6):\r\n1. After the installer reboots the machine, the UEFI firmware proceeds with loading a first boot option. For Windows\r\nsystems, the first boot option is by default bootmgfw.efi located in the ESP:/EFI/Microsoft/Boot folder on the ESP.\r\nThis time, instead of executing the original victim’s bootmgfw.efi (which was previously renamed winload.efi by the\r\ninstaller), the firmware executes the vulnerable one – deployed by the installer.\r\n2. After bootmgfw.efi is executed, it loads the BCD boot options, previously modified by the installer. Figure 7 shows a\r\ncomparison of the legitimate BCD and the modified one.\r\n3. As you can see in Figure 7 (path underlined with green), the legitimate Windows Boot Manager would normally load\r\nthe Windows OS loader (\\WINDOWS\\system32\\winload.efi) as a default boot application. But this time, with the\r\nmodified BCD, it continues with loading the vulnerable ESP:\\system32\\bootmgr.efi, with the avoidlowmemory BCD\r\nelement set to value 0x10000000 and the custom:22000023 BCD element pointing to another attackers’ BCD stored\r\nin ESP:\\system32\\bcd. The explanation of using these elements can be found in the published PoC:\r\nThe attacker needs to ensure the serialised Secure Boot Policy is allocated above a known physical address.\r\n[…]\r\nThe avoidlowmemory element can be used to ensure all allocations of physical memory are above a specified physical\r\naddress.\r\n • Since Windows 10, this element is disallowed if VBS is enabled, but as it is used during boot application initialisation,\r\nbefore the serialised Secure Boot policy is read from memory, loading bootmgr and specifying a custom BCD path (using\r\nbcdfilepath element aka custom:22000023) can be used to bypass this.\r\nhttps://www.welivesecurity.com/2023/03/01/blacklotus-uefi-bootkit-myth-confirmed/\r\nPage 10 of 26\n\nFigure 7. Legitimate BCD store (BEFORE) vs the one used by the BlackLotus installer (AFTER)\r\n4. In the next step, the executed ESP:\\system32\\bootmgr.efi loads that additional BCD located in ESP:\\system32\\bcd.\r\nParsed content of this additional BCD is shown in Figure 8.\r\nFigure 8. Second BCD dropped by the BlackLotus installer – used to exploit CVE-2022-21894\r\n5. Because of options loaded from the BCD file shown in Figure 8, bootmgr.efi continues with loading another\r\nvulnerable Windows Boot Application deployed by the installer – ESP:\\system32\\hvloader.efi – which is the\r\nWindows Hypervisor Loader. More importantly, additional BCD options are specified in the same BCD file (see\r\nFigure 8):\r\n1. truncatememory with value set to 0x10000000\r\n2. nointegritychecks set to Yes\r\n3. and testsigning, also set to Yes\r\nAnd this is where the magic happens. As the serialized Secure Boot policy should be loaded in physical addresses above\r\n0x10000000 (because of avoidlowmemory used in previous steps), specifying the truncatememory element will effectively\r\nremove it – thus, break the Secure Boot and allow the use of dangerous BCD options like nointegritychecks or testsigning.\r\nBy using these options, the attackers can make the hvloader.efi execute their own, self-signed code. \r\nhttps://www.welivesecurity.com/2023/03/01/blacklotus-uefi-bootkit-myth-confirmed/\r\nPage 11 of 26\n\n6. To do this, the same trick as described in the PoC is used: during its execution, the legitimate hvloader.efi loads and\r\nexecutes the mcupdate_{GenuineIntel| AuthenticAMD}.dll native binary from the \u003cdevice\u003e:\\\r\n\u003cSystemRoot\u003e\\system32\\ directory. Commented Hex-Rays decompiled code of the function from hvloader.efi\r\nresponsible for loading this mcupdate*.dll binary is shown in Figure 9. Note that hvloader.efi would normally load\r\nthis legitimate mcupdate*.dll binary from the \u003cOS_partition\u003e:\\Windows\\system32, but this time the malicious\r\nattackers’ self-signed mcupdate*.dll is executed from a custom ESP directory previously created by the installer\r\n(ESP:\\system32). It’s caused by the BCD options device and systemroot used in the BCD from Figure 8 specifying\r\nthe current device as boot – meaning the ESP – and also specifying SystemRoot to be the root (\\) directory on this\r\ndevice.\r\nFigure 9. Hex-Rays decompilation of the BtLoadUpdateDll function from the legitimate hvloader.efi, responsible for loading\r\nmcupdate_*.dll\r\n7. Now, as the attackers’ own self-signed mcupdate*.dll is loaded and executed, it continues with executing the final\r\ncomponent in this chain – an embedded MokInstaller (UEFI Application) – see Figure 10 for details about how it’s\r\ndone.\r\nhttps://www.welivesecurity.com/2023/03/01/blacklotus-uefi-bootkit-myth-confirmed/\r\nPage 12 of 26\n\nFigure 10. Hex-Rays decompiled code of the malicious self-signed mcupdate*.dll binary\r\nBootkit persistence\r\nNow, the MokInstaller can proceed with setting up persistence by enrolling the attackers’ MOK into the NVRAM variable\r\nand setting up the legitimate Microsoft-signed shim binary as a default bootloader. Before proceeding to details, a little\r\ntheory about shim and MOK.\r\nshim is a first stage UEFI bootloader developed by Linux developers to make various Linux distributions work with UEFI\r\nSecure Boot. It’s a simple application and its purpose is to load, verify, and execute another application – in case of Linux\r\nsystems, it’s usually the GRUB bootloader. It works in a way that Microsoft signs only a shim, and the shim takes care of the\r\nrest – it can verify the integrity of a second-stage bootloader by using keys from db UEFI variable, and also embeds its own\r\nlist of “allowed” or “revoked” keys or hashes to make sure that components trusted by both – platform and shim developer\r\n(e.g. Canonical, RedHat, etc.,) – are allowed to be executed. In addition to these lists, shim also allows the use of an external\r\nkeys database managed by the user, known as the MOK list. Figure 11 nicely illustrates how UEFI Secure Boot with MOK\r\nworks.\r\nThis MOK database is stored in a Boot-only NVRAM variable named MokList. Without exploiting a vulnerability like the\r\none described above, physical access is required to modify it on a system with UEFI Secure Boot enabled (it’s available only\r\nduring boot, before the OS loader calls the UEFI Boot Services function ExitBootServices). However, by exploiting this\r\nvulnerability, attackers are able to bypass UEFI Secure Boot and execute their own self-signed code before a call to\r\nExitBootServices, so they can easily enroll their own key (by modifying the MokList NVRAM variable) to make the shim\r\nexecute any application – signed by that enrolled key – without causing a security violation.\r\n8. Continuing with describing the flow from Figure 6 – step 8… The MokInstaller UEFI application continues with\r\nsetting up persistence for the BlackLotus UEFI bootkit and covering the tracks of exploitation by:\r\n1. Restoring the victim’s original BCD store from the backup created by the installer and replacing the efi with\r\nthe legitimate Microsoft-signed shim, previously dropped to the ESP:\\system32\\bootload.efi by the installer.\r\n2. Creating a MokList NVRAM variable containing the attackers’ self-signed public key certificate. Note that\r\nthis variable is formatted in the same way as any other UEFI signature database variables (such as db or dbx)\r\nand it can consist of zero or more signature lists of type EFI_SIGNATURE_LIST – as defined in the UEFI\r\nSpecification.\r\n3. Deleting all files involved in exploitation from the attackers‘ ESP:\\system32\\ folder.\r\n9. In the end, it reboots the machine to make the deployed shim execute the self-signed bootkit dropped to\r\n\\EFI\\Microsoft\\Boot\\grubx64.efi by the installer (grubx64.efi is usually the default second-stage bootloader executed\r\nby a shim on x86-64 systems).\r\nCode performing the actions described in the last two steps is shown in Figure 12.\r\nhttps://www.welivesecurity.com/2023/03/01/blacklotus-uefi-bootkit-myth-confirmed/\r\nPage 13 of 26\n\nFigure 12. Hex-Rays decompiled code – MokInstaller UEFI app setting up persistence for the BlackLotus bootkit\r\nBlackLotus UEFI bootkit\r\nOnce the persistence is configured, the BlackLotus bootkit is executed on every system start. The bootkit’s goal is to deploy\r\na kernel driver and a final user-mode component – the HTTP downloader. During its execution, it tries to disable additional\r\nWindows security features – Virtualization-Based Security (VBS) and Windows Defender – to raise the chance of successful\r\ndeployment and stealthy operation. Before jumping to the details about how that is done, let’s summarize the basics about\r\nthe kernel driver and HTTP downloader:\r\nThe kernel driver is responsible for\r\nDeploying the next component of the chain – an HTTP downloader.\r\nKeeping the loader alive in case of termination.\r\nProtecting bootkit files from being removed from ESP.\r\nExecuting additional kernel payloads, if so instructed by the HTTP downloader.\r\nUninstalling the bootkit, if so instructed by the HTTP downloader.\r\nThe HTTP downloader is responsible for:\r\nCommunicating with its C\u0026C.\r\nExecuting commands received from the C\u0026C.\r\nDownloading and executing payloads received from the C\u0026C (supports both kernel payloads and user-mode\r\npayloads).\r\nThe full execution flow (simplified), from the installer to HTTP downloader, is shown in Figure 13. We describe these\r\nindividual steps in more detail in the next section.\r\nhttps://www.welivesecurity.com/2023/03/01/blacklotus-uefi-bootkit-myth-confirmed/\r\nPage 14 of 26\n\nhttps://www.welivesecurity.com/2023/03/01/blacklotus-uefi-bootkit-myth-confirmed/\r\nPage 15 of 26\n\nFigure 13. Diagram showing execution of the BlackLotus UEFI bootkit\r\nBlackLotus execution flow\r\nExecution steps are as follows (these steps are shown in Figure 13):\r\n1. As a first step, the UEFI firmware executes the default Windows boot option, which is the file usually stored in\r\n\\EFI\\Microsoft\\Boot\\bootmgfw.efi. As we described earlier (Bootkit persistence section, 8 .a), the MokInstaller\r\nbinary replaced this file with a legitimate signed shim.\r\n2. When the shim is executed, it reads the MokList NVRAM variable, and uses the certificate previously stored inside\r\nby the attackers to verify the second-stage bootloader – the self-signed BlackLotus UEFI bootkit located in\r\n\\EFI\\Microsoft\\Boot\\grubx64.efi.\r\n3. When verified, the shim executes the bootkit.\r\n4. The bootkit starts with creating the Boot-only VbsPolicyDisable NVRAM variable. As described here, this variable is\r\nevaluated by the Windows OS loader during boot and if defined, the core VBS features, such as HVCI and Credential\r\nGuard will not be initialized.\r\n5. In the following steps (5. a–e), the bootkit continues with a common pattern used by UEFI bootkits. It intercepts the\r\nexecution of components included in the typical Windows boot flow, such as Windows Boot Manager, Windows OS\r\nloader, and Windows OS kernel, and hooks some of their functions in memory. As a bonus, it also attempts to disable\r\nWindows Defender by patching some of its drivers. All this to achieve its payload’s execution in the early stages of\r\nthe OS startup process and to avoid detection. The following functions are hooked or patched:\r\n1. ImgArchStartBootApplication in bootmgfw.efi or bootmgr.efi:\r\nThis function is commonly hooked by bootkits to catch the moment when the Windows OS loader\r\n(winload.efi) is loaded in the memory but still hasn’t been executed – which is the right moment to perform\r\nmore in-memory patching.\r\n2. BlImgAllocateImageBuffer in winload.efi:\r\nUsed to allocate an additional memory buffer for the malicious kernel driver.\r\n3. OslArchTransferToKernel in winload.efi:\r\nHooked to catch the moment when the OS kernel and some of the system drivers are already loaded in the\r\nmemory, but still haven’t been executed – which is a perfect moment to perform more in-memory patching.\r\nThe drivers mentioned below are patched in this hook. The code from this hook responsible for finding\r\nappropriate drivers in memory is shown in Figure 14.\r\n4. WdBoot.sys and WdFilter.sys:\r\nBlackLotus patches the entry point of WdBoot.sys and WdFilter.sys – the Windows Defender ELAM driver\r\nand the Windows Defender file system filter driver, respectively – to return immediately.\r\n5. disk.sys:\r\nThe bootkit hooks the entry point of the disk.sys driver to execute the BlackLotus kernel driver in the early\r\nstages of system initialization.\r\nhttps://www.welivesecurity.com/2023/03/01/blacklotus-uefi-bootkit-myth-confirmed/\r\nPage 16 of 26\n\nFigure 14. Hex-Rays decompiled code of OslArchTransferToKernel hook – patching Windows Defender drivers and\r\nsearching for the disk.sys entry point\r\n6. Next, when the OS kernel executes the disk.sys driver’s entry point, the installed hook jumps to the malicious kernel\r\ndriver entry point. The malicious code in turn restores the original disk.sys to allow the system to function properly\r\nand waits until the winlogon.exe process starts.\r\n7. When the malicious driver detects that the winlogon.exe process has started, it injects and executes the final user-mode component – the HTTP downloader – into it.\r\nKernel driver\r\nThe kernel driver is responsible for four main tasks:\r\nInjecting the HTTP downloader into winlogon.exe and reinjecting it in case the thread terminated.\r\nProtecting bootkit files deployed on the ESP from being removed.\r\nDisarming the user-mode Windows Defender process MsMpEngine.exe.\r\nCommunicating with the HTTP downloader and if necessary, performing any commands.\r\nLet’s look at them one by one.\r\nHTTP downloader persistence\r\nThe kernel driver is responsible for deployment of the HTTP downloader. When the driver starts, it waits until the process\r\nnamed winlogon.exe starts, before taking any other actions. Once the process has started, the driver decrypts the HTTP\r\ndownloader binary, injects it into winlogon.exe’s address space, and executes it in a new thread. Then, the driver keeps\r\nperiodically checking whether the thread is still running, and repeats the injection if necessary. The HTTP downloader won’t\r\nbe deployed if a kernel debugger is detected by the driver.\r\nProtecting bootkit files on the ESP from removal\r\nTo protect the bootkit’s files located on the ESP, the kernel driver uses a simple trick. It opens all files it wants to protect,\r\nduplicates and saves their handles, and uses the ObSetHandleAttributes kernel function specifying the ProtectFromClose\r\nflag inside HandleFlags (OBJECT_HANDLE_FLAG_INFORMATION) parameter to 1 – thus protecting the handles from\r\nbeing closed by any other processes. This will thwart any attempts to remove or modify the protected files. The following\r\nfiles are protected:\r\nESP:\\EFI\\Microsoft\\Boot\\winload.efi\r\nESP:\\EFI\\Microsoft\\Boot\\bootmgfw.efi\r\nhttps://www.welivesecurity.com/2023/03/01/blacklotus-uefi-bootkit-myth-confirmed/\r\nPage 17 of 26\n\nESP:\\EFI\\Microsoft\\Boot\\grubx64.efi\r\nShould a user try to delete these protected files, something like what is shown in Figure 15 will occur.\r\nFigure 15. An attempt to delete the files protected by BlackLotus driver\r\nAs another layer of protection, in case the user or security software would be able to unset the protection flag and close the\r\nhandles, the kernel driver continuously monitors them, and causes a BSOD by calling the\r\nKeBugCheck(INVALID_KERNEL_HANDLE) function if any of the handles don’t exist anymore.\r\nDisarming the main Windows Defender process\r\nThe kernel driver also tries to disarm the main Windows Defender process – MsMpEng.exe. It does so by removing all\r\nprocess’s token privileges by setting the SE_PRIVILEGE_REMOVED attribute to each of them. As a result, the Defender\r\nprocess should not be able to do its job – such as scanning files – properly. However, as this functionality is poorly\r\nimplemented, it can be made ineffective by restarting the MsMpEng.exe process.\r\nCommunication with the HTTP downloader\r\nThe kernel driver is capable of communicating with the HTTP downloader by using a named Event and Section. Names of\r\nthe named objects used are generated based on the victim’s network adapter MAC address (ethernet). If a value of an octet is\r\nlower than 16, then 16 is added to it. The format of the generated objects names might vary in different samples. As an\r\nexample, in one of the samples we analyzed, for the MAC address 00-1c-0b-cd-ef-34, the generated names would be:\r\n\\BaseNamedObjects\\101c1b: for the named section (only the first three octets of the MAC are used)\r\n\\BaseNamedObjects\\Z01c1b: for the named event – same as for the Section, but the first digit of the MAC address is\r\nreplaced with Z\r\nIn case the HTTP downloader wants to pass some command to the kernel driver, it simply creates a named section, writes a\r\ncommand with associated data inside, and waits for the command to be processed by the driver by creating a named event\r\nand waiting until the driver triggers (or signals) it.\r\nThe driver supports the following self-explanatory commands:\r\nInstall kernel driver\r\nUninstall BlackLotus\r\nA careful reader might notice the BlackLotus weak point here – even though the bootkit protects its components against\r\nremoval, the kernel driver can be tricked to uninstall the bootkit completely by creating the abovementioned named objects\r\nand sending the uninstall command to it.\r\nHTTP downloader\r\nThe final component is responsible for communication with a C\u0026C server and execution of any C\u0026C commands received\r\nfrom it. All payloads we were able to discover contain three commands. These commands are very straightforward and as\r\nthe section name suggests, it’s mostly about downloading and executing additional payloads using various techniques.\r\nC\u0026C communication\r\nhttps://www.welivesecurity.com/2023/03/01/blacklotus-uefi-bootkit-myth-confirmed/\r\nPage 18 of 26\n\nTo communicate with its C\u0026C, the HTTP loader uses the HTTPS protocol. All information necessary for the communication\r\nis embedded directly in the downloader binary – including C\u0026C domains and HTTP resource paths used. The default\r\ninterval for communication with a C\u0026C server is set to one minute, but can be changed based on the data from the C\u0026C.\r\nEach communication session with a C\u0026C starts with sending a beacon HTTP POST message to it. In samples we analyzed,\r\nthe following HTTP resource paths can be specified in the HTTP POST headers:\r\n/network/API/hpb_gate[.]php\r\n/API/hpb_gate[.]php\r\n/gate[.]php\r\n/hpb_gate[.]php\r\nThe beacon message data is prepended with a checkin= string, containing basic information about the compromised machine\r\n– including a custom machine identifier (referred to as HWID), UEFI Secure Boot status, various hardware information, and\r\na value that seems to be a BlackLotus build number. HWID is generated from the machine MAC address (ethernet) and a\r\nsystem volume serial number. The format of the message before encryption is as seen in Figure 16\r\n{\r\n \"HWID\":\"%s\",\r\n \"Session\":\"%lu\",\r\n \"Owner\":\"%s\",\r\n \"IP\":\"%s\",\r\n \"OS\":\"%s\",\r\n \"Edition\":\"%s\",\r\n \"CPU\":\"%s\",\r\n \"GPU\":\"%s\",\r\n \"RAM\":\"%lu\",\r\n \"Integrity\":\"%lu\",\r\n \"SecureBoot\":\"%i\",\r\n \"Build\":\"%lu\"\r\n}\r\nFigure 16. Format of beacon message\r\nBefore sending the message to the C\u0026C, the data is first encrypted using an embedded RSA key, then URL-safe base64\r\nencoded. During the analysis, we found two different RSA keys being used in the samples. An example of such an HTTP\r\nbeacon request is shown in Figure 17.\r\nFigure 17. Example of a beacon HTTP POST message (generated by a sample from VirusTotal – the one with local IPs\r\ninstead of real C\u0026C addresses)\r\nhttps://www.welivesecurity.com/2023/03/01/blacklotus-uefi-bootkit-myth-confirmed/\r\nPage 19 of 26\n\nData received from the C\u0026C as a response to the beacon message should start with the two-byte magic value HP; otherwise,\r\nthe response is not processed further. If the magic value is correct, the data following the magic value is decrypted using\r\n256-bit AES in CBC mode with abovementioned HWID string used as the key.\r\nAfter decryption, the message is similar to the beacon, a JSON-formatted string, and specifies a command identifier\r\n(referred to as Type) and various additional parameters such as:\r\nC\u0026C communication interval\r\nExecution method to use\r\nPayload filename\r\nPayload type based on file extension(.sys, .exe, or .dll supported)\r\nAuthentication token that is supposed to be used to request download of payload data\r\nAES key used for decrypting the payload data\r\nAll supported commands and their descriptions are listed in Table 2.\r\nTable 2. C\u0026C commands\r\nCommand Type Command Description\r\n1 Download and execute a kernel driver, DLL, or a regular executable\r\n2\r\nDownload a payload, uninstall the bootkit, and execute the payload – likely used to update the\r\nbootkit\r\n3 Uninstall the bootkit and exit\r\nIn these commands, the C\u0026C can specify, whether the payload should first be dropped to disk before executing it, or be\r\nexecuted directly in memory. In cases involving dropping the file to disk, the ProgramData folder on the OS volume is used\r\nas the destination folder and filename and extension are specified by the C\u0026C server. In the case of executing files directly\r\nin memory, svchost.exe is used as an injection target. When the C\u0026C sends a command requiring kernel driver cooperation,\r\nor an operator wants to execute code in kernel-mode, the mechanism described in the Communication with the HTTP\r\ndownloader section is used.\r\nAnti-analysis tricks\r\nTo make detection and analysis of this piece of malware harder, its author tried to limit visibility of standard file artifacts,\r\nsuch as text strings, imports, or other unencrypted embedded data to a minimum. Below is a summary of the techniques\r\nused.\r\nString and data encryption\r\nAll strings used within the samples are encrypted using a simple cipher.\r\nAll embedded files are encrypted using 256-bit AES in CBC mode.\r\nEncryption keys for individual files can vary from sample to sample.\r\nIn addition to AES encryption, some files are also compressed using LZMS.\r\nRuntime-only API resolution\r\nIn all samples (when applicable), Windows APIs are always resolved exclusively during runtime and function\r\nhashes instead of function names are used to find the desired API function addresses in memory.\r\nIn some cases, a direct syscall instruction invocation is used to invoke the desired system function.\r\nNetwork communication\r\nCommunicates using HTTPS.\r\nAll messages sent to the C\u0026C by the HTTP downloader are encrypted using an embedded RSA public key.\r\nAll messages sent from the C\u0026C to the HTTP downloader are encrypted using a key derived from the victim’s\r\nmachine environment or using an AES key provided by the C\u0026C.\r\nAnti-debug and anti-VM tricks – if used, usually placed right at the beginning of the entry point. Only casual\r\nsandbox or debugger detection tricks are used.\r\nFirst of all, of course, keeping your system and its security product up to date is a must – to raise a chance that a\r\nthreat will be stopped right at the beginning, before it’s able to achieve pre-OS persistence.\r\nThen, the key step that needs to be taken to prevent usage of known vulnerable UEFI binaries for bypassing UEFI\r\nSecure Boot is their revocation in the UEFI revocation database (dbx) – on a Windows systems, dbx updates should\r\nhttps://www.welivesecurity.com/2023/03/01/blacklotus-uefi-bootkit-myth-confirmed/\r\nPage 20 of 26\n\nbe distributed using Windows Updates.\r\nThe problem is that revocation of broadly used Windows UEFI binaries can lead to making thousands of outdated\r\nsystems, recovery images, or backups unbootable – and therefore, revocation often takes too long.\r\nNote that revocation of the Windows applications used by BlackLotus would prevent installation of the bootkit, but\r\nas the installer would replace the victim’s bootloader with the revoked one, it could make the system unbootable. To\r\nrecover in this case, an OS reinstall or just ESP recovery would resolve the issue.\r\nIf the revocation would happen after BlackLotus persistence is set, the bootkit would remain functional, as it uses a\r\nlegitimate shim with custom MOK key for persistence. In this case, the safest mitigation solution would be to\r\nreinstall Windows and remove the attackers’ enrolled MOK key by using the mokutil utility (physical presence is\r\nrequired to perform this operation due to necessary user interaction with the MOK Manager during the boot).\r\nTakeaways\r\nMany critical vulnerabilities affecting security of UEFI systems have been discovered in the last few years. Unfortunately,\r\ndue the complexity of the whole UEFI ecosystem and related supply-chain problems, many of these vulnerabilities have left\r\nmany systems vulnerable even a long time after the vulnerabilities have been fixed – or at least after we were told they were\r\nfixed. For a better image, here are some examples of the patch or revocation failures allowing UEFI Secure Boot bypasses\r\njust from the last year:\r\nFirst of all, of course, CVE-2022-21894 – the vulnerability exploited by BlackLotus. One year since the vulnerability\r\nwas fixed, vulnerable UEFI binaries are still not revoked, allowing threats such as BlackLotus to stealthily operate on\r\nsystems with UEFI Secure Boot enabled, thus providing victims a false sense of security.\r\nEarly in 2022, we disclosed several UEFI vulnerabilities that allow, among other things, disabling UEFI Secure Boot.\r\nMany devices affected are not supported by the OEM anymore, thus not fixed (even though these devices were not so\r\nold – like 3-5 years at the time of vulnerability disclosure). Read more in our blogpost: When “secure” isn’t secure at\r\nall: High‑impact UEFI vulnerabilities discovered in Lenovo consumer laptops\r\nLater in 2022, we discovered a few other UEFI vulnerabilities, whose exploitation would also allow attackers to\r\ndisable UEFI Secure Boot very easily. As pointed out by fellow researchers from Binarly, several devices listed in the\r\nadvisory were left unpatched, or not patched correctly, even few months after the advisory – leaving the devices\r\nvulnerable. Needless to say, similar to the previous case, some devices will stay vulnerable forever, as they have\r\nreached their End-Of-Support date.\r\nIt was just a matter of time before someone would take advantage of these failures and create a UEFI bootkit capable of\r\noperating on systems with UEFI Secure Boot enabled. As we suggested last year in our RSA presentation, all of this makes\r\nthe move to the ESP more feasible for attackers and a possible way forward for UEFI threats – the existence of BlackLotus\r\nconfirms this.\r\nESET Research offers private APT intelligence reports and data feeds. For any inquiries about this service, visit the ESET\r\nThreat Intelligence page.\r\nIoCs\r\nFiles\r\nSHA-1 Filename Detection Description\r\n05846D5B1D37EE2D716140DE4F4F984CF1E631D1 N/A Win64/BlackLotus.A BlackLotus installer.\r\nA5A530A91100ED5F07A5D74698B15C646DD44E16 N/A Win64/BlackLotus.A BlackLotus installer.\r\nD82539BFC2CC7CB504BE74AC74DF696B13DB486A N/A Win64/BlackLotus.A BlackLotus installer.\r\n16B12CEA54360AA42E1120E82C1E9BC0371CB635 N/A Win64/BlackLotus.A BlackLotus installer.\r\nDAE7E7C4EEC2AC0DC7963C44A5A4F47D930C5508 N/A Win64/BlackLotus.A BlackLotus installer.\r\n45701A83DEC1DC71A48268C9D6D205F31D9E7FFB N/A Win64/BlackLotus.A BlackLotus installer.\r\n2CE056AE323B0380B0E87225EA0AE087A33CD316 N/A EFI/BlackLotus.B BlackLotus UEFI bootkit.\r\n5A0074203ABD5DEB464BA0A79E14B7541A033216 N/A EFI/BlackLotus.B BlackLotus UEFI bootkit.\r\nhttps://www.welivesecurity.com/2023/03/01/blacklotus-uefi-bootkit-myth-confirmed/\r\nPage 21 of 26\n\nSHA-1 Filename Detection Description\r\n5DC9CBD75ABD830E83641A0265BFFDDD2F602815 N/A EFI/BlackLotus.B BlackLotus UEFI bootkit.\r\n97AEC21042DF47D39AC212761729C6BE484D064D N/A EFI/BlackLotus.B BlackLotus UEFI bootkit.\r\nADCEEC18FF009BED635D168E0B116E72096F18D2 N/A EFI/BlackLotus.B BlackLotus UEFI bootkit.\r\nDBC064F757C69EC43517EFF496146B43CBA949D1 N/A EFI/BlackLotus.B BlackLotus UEFI bootkit.\r\n06AF3016ACCDB3DFE1C23657BF1BF91C13BAA757 N/A Win64/BlackLotus.B BlackLotus HTTP downloader.\r\n0C0E78BF97116E781DDE0E00A1CD0C29E68D623D N/A Win64/BlackLotus.B BlackLotus HTTP downloader.\r\n6D8CEE28DA8BCF25A4D232FEB0810452ACADA11D N/A Win64/BlackLotus.B BlackLotus HTTP downloader.\r\n74FF58FCE8F19083D16DF0109DC91D78C94342FA N/A Win64/BlackLotus.B BlackLotus HTTP downloader.\r\nACC74217CBE3F2E727A826B34BDE482DCAE15BE6 N/A Win64/BlackLotus.B BlackLotus HTTP downloader.\r\n111C4998F3264617A7A9D9BF662D4B1577445B20 N/A Win64/BlackLotus.B BlackLotus HTTP downloader.\r\n17FA047C1F979B180644906FE9265F21AF5B0509 N/A Win64/BlackLotus.C BlackLotus kernel driver.\r\n1F3799FED3CF43254FE30DCDFDB8DC02D82E662B N/A Win64/BlackLotus.C BlackLotus kernel driver.\r\n4B882748FAF2C6C360884C6812DD5BCBCE75EBFF N/A Win64/BlackLotus.C BlackLotus kernel driver.\r\n91F832F46E4C38ECC9335460D46F6F71352CFFED N/A Win64/BlackLotus.C BlackLotus kernel driver.\r\n994DC79255AEB662A672A1814280DE73D405617A N/A Win64/BlackLotus.C BlackLotus kernel driver.\r\nFFF4F28287677CAABC60C8AB36786C370226588D N/A Win64/BlackLotus.C BlackLotus kernel driver.\r\n71559C3E2F3950D4EE016F24CA54DA17D28B9D82 N/A EFI/BlackLotus.C\r\nBlackLotus Boot\r\nConfiguration Data (BCD)\r\nstore dropped by BlackLotus\r\ninstaller.\r\nD6D3F3151B188A9DA62DEB95EA1D1ABEFF257914 N/A EFI/BlackLotus.C\r\nBlackLotus Boot\r\nConfiguration Data (BCD)\r\nstore dropped by BlackLotus\r\ninstaller.\r\n547FAA2D64B85BF883955B723B07635C0A09326B N/A EFI/BlackLotus.A\r\nBlackLotus CVE-2022-21894\r\nexploitation payload loader.\r\nD1BBAA3D408E944C70B3815471EED7FA9AEE6425 N/A EFI/BlackLotus.A\r\nBlackLotus CVE-2022-21894\r\nexploitation payload loader.\r\n0E6DD7110C38464ECAA55EE4E2FA303ADA0EDEFB N/A EFI/BlackLotus.A\r\nBlackLotus CVE-2022-21894\r\nexploitation payload –\r\nMokInstaller EFI app.\r\nD6BB89D8734B3E49725362DAE9A868AE681E8BD6 N/A EFI/BlackLotus.A\r\nBlackLotus CVE-2022-21894\r\nexploitation payload –\r\nMokInstaller EFI app.\r\n164BB587109CFB20824303AD1609A65ABB36C3E9 N/A Win64/BlackLotus.D\r\nBlackLotus installer UAC\r\nbypass module.\r\nCertificates\r\nSerial number 570B5D22B723B4A442CC6EEEBC2580E8\r\nThumbprint C8E6BF8B6FDA161BBFA5470BCC262B1BDC92A359\r\nhttps://www.welivesecurity.com/2023/03/01/blacklotus-uefi-bootkit-myth-confirmed/\r\nPage 22 of 26\n\nSerial number 570B5D22B723B4A442CC6EEEBC2580E8\r\nSubject CN When They Cry CA\r\nSubject O N/A\r\nSubject L N/A\r\nSubject S N/A\r\nSubject C N/A\r\nValid from 2022-08-13 17:48:44\r\nValid to 2032-08-13 17:58:44\r\nNetwork\r\nIP Domain Hosting provider First seen Details\r\nN/A xrepositoryx[.]name N/A 2022‑10‑17\r\nBlackLotus C\u0026C.\r\nhttps://xrepositoryx[.]name/network/API/hpb\r\nN/A myrepositoryx[.]com N/A 2022‑10‑16\r\nBlackLotus C\u0026C.\r\nhttps://myrepositoryx[.]com/network/API/hp\r\n104.21.22[.]185 erdjknfweklsgwfmewfgref[.]com Cloudflare, Inc. 2022‑10‑06\r\nBlackLotus C\u0026C.\r\nhttps://erdjknfweklsgwfmewfgref[.]com/API\r\n164.90.172[.]211 harrysucksdick[.]com DigitalOcean, LLC 2022‑10‑09\r\nBlackLotus C\u0026C.\r\nhttps://harrysucksdick[.]com/API/hpb_gate.p\r\n185.145.245[.]123\r\nheikickgn[.]com\r\nfrassirishiproc[.]com\r\nSIA VEESP 2022‑10‑12\r\nBlackLotus C\u0026C.\r\nhttps://heikickgn[.]com/API/hpb_gate.php\r\nhttps://frassirishiproc[.]com/API/hpb_gate.ph\r\n185.150.24[.]114 myrepository[.]name\r\nSkyLink Data\r\nCenter BV\r\n2022‑10‑14\r\nBlackLotus C\u0026C.\r\nmyrepository[.]name/network/API/hpb_gate.\r\n190.147.189[.]122 egscorp[.]net\r\nTelmex Colombia\r\nS.A.\r\n2022‑08‑24\r\nBlackLotus C\u0026C.\r\nhttps://egscorp[.]net/API/hpb_gate.php\r\nMITRE ATT\u0026CK techniques\r\nThis table was built using version 12 of the MITRE ATT\u0026CK framework.\r\nTactic ID Name Description\r\nResource\r\nDevelpment\r\nT1587.002\r\nDevelop Capabilities:\r\nCode Signing Certificates\r\nSome BlackLotus samples are signed with self-signed\r\ncertificate.\r\nT1588.005\r\nObtain Capabilities:\r\nExploits\r\nBlackLotus used publicly known exploit to bypass UEFI\r\nSecure Boot.\r\nExecution\r\nT1203\r\nExploitation for Client\r\nExecution\r\nBlackLotus installers can exploit CVE-2022-21894 to\r\nachieve arbitrary code execution on the systems with\r\nUEFI Secure Boot enabled.\r\nT1559\r\nInter-Process\r\nCommunication\r\nBlackLotus HTTP downloader uses named section to\r\npass commands to the kernel-mode component.\r\nT1106 Native API\r\nBlackLotus HTTP downloader uses various native\r\nWindows APIs to achieve code execution on the\r\ncompromised machine.\r\nhttps://www.welivesecurity.com/2023/03/01/blacklotus-uefi-bootkit-myth-confirmed/\r\nPage 23 of 26\n\nTactic ID Name Description\r\nT1129 Shared Modules\r\nBlackLotus HTTP downloader can load and execute\r\nDLLs received from the C\u0026C server.\r\nPersistence T1542.003 Pre-OS Boot: Bootkit\r\nBlackLotus bootkit is deployed on the EFI System\r\nPartition and executed during the boot.\r\nPrivilege\r\nEscalation\r\nT1548.002\r\nAbuse Elevation Control\r\nMechanism: Bypass User\r\nAccount Control\r\nBlackLotus installer attempts to escalate privileges by\r\nbypassing User Account Control.\r\nT1134.002\r\nAccess Token\r\nManipulation: Create\r\nProcess with Token\r\nBlackLotus HTTP downloader can use\r\nWTSQueryUserToken and CreateProcessAsUserW to\r\nexecute downloaded payloads within a new process with\r\nlocal system privileges.\r\nDefense\r\nEvasion    T1622 Debugger Evasion\r\nBlackLotus components use various techniques to detect\r\nwhether a kernel-mode or user-mode debugger is running\r\non a victim.\r\nT1574 Hijack Execution Flow\r\nBlackLotus bootkit hijacks various components included\r\nin the early Windows boot process stages (Windows Boot\r\nManager, Windows OS loader, Windows kernel and\r\nspecific drivers) to avoid detection by deactivating\r\nvarious Windows security features (VBS, Windows\r\nDefender) and stealthily execute its kernel-mode and\r\nuser-mode components\r\nT1562 Impair Defenses\r\nBlackLotus components can disable BitLocker and\r\nWindows Defender to avoid detection.\r\nT1070.004\r\nIndicator Removal: File\r\nDeletion\r\nBlackLotus installer deletes itself after successfully\r\ndeploying files to the EFI System partition. Also after\r\nsuccessful CVE-2022-21894 exploitation, BlackLotus\r\nremoves traces of exploitation by deleting all files\r\nincluded in exploitation chain from EFI System Partition.\r\nT1070.009\r\nIndicator Removal: Clear\r\nPersistence\r\nBlackLotus can uninstall itself by removing all bootkit\r\nfiles from the ESP and restoring original victim’s\r\nWindows Boot Manager.\r\nT1036.005\r\nMasquerading: Match\r\nLegitimate Name or\r\nLocation\r\nBlackLotus attempts to hide its files deployed on the ESP\r\nby using legitimate filenames, such as grubx64.efi (if\r\nUEFI Secure Boot is enabled on compromised machine)\r\nor bootmgfw.efi (if UEFI Secure Boot is disabled on\r\ncompromised machine).\r\nT1112 Modify Registry\r\nBlackLotus installer modifies Windows registry to\r\ndisable Windows HVCI security feature.\r\nT1027\r\nObfuscated Files or\r\nInformation\r\nAlmost all embedded strings in BlackLotus components\r\nare encrypted using a custom combined cipher and\r\ndecrypted only when needed.\r\nT1027.007\r\nObfuscated Files or\r\nInformation: Dynamic API\r\nResolution\r\nBlackLotus components use dynamic API resolution\r\nwhile using API names’ hashes instead of names.\r\nT1027.009\r\nObfuscated Files or\r\nInformation: Embedded\r\nPayloads\r\nAlmost all embedded files in BlackLotus components are\r\nencrypted using AES.\r\nhttps://www.welivesecurity.com/2023/03/01/blacklotus-uefi-bootkit-myth-confirmed/\r\nPage 24 of 26\n\nTactic ID Name Description\r\nT1542.003 Pre-OS Boot: Bootkit\r\nBlackLotus bootkit is deployed on the EFI System\r\nPartition and executed during the early OS boot stages,\r\nand thus is capable of controlling the OS boot process\r\nand evading detection.\r\nT1055.012\r\nProcess Injection:\r\nDynamic-link Library\r\nInjection\r\nBlackLotus HTTP downloader can inject a DLL into a\r\nnewly created svchost.exe process using process\r\nhollowing.\r\nT1055.002\r\nProcess Injection: Portable\r\nExecutable Injection\r\nBlackLotus driver injects the HTTP downloader portable\r\nexecutable into a winlogon.exe process.\r\nT1014 Rootkit\r\nBlackLotus kernel driver protects the bootkit files on the\r\nESP from removal.\r\nT1497.001\r\nVirtualization/Sandbox\r\nEvasion: System Checks\r\nBlackLotus employs various system checks including\r\nchecking sandbox-specific registry values, to detect and\r\navoid virtualization and analysis environments.\r\nDiscovery\r\nT1622 Debugger Evasion\r\nBlackLotus components use various techniques to detect\r\nwhether a kernel-mode or user-mode debugger is running\r\non a victim.\r\nT1082\r\nSystem Information\r\nDiscovery\r\nBlackLotus collects system information (IP, GPU, CPU,\r\nmemory, OS version) on a compromised host.\r\nT1614\r\nSystem Location\r\nDiscovery\r\nBlackLotus can exit if one of the following system\r\nlocales is identified on the compromised host: ro-MD, ru-MD, ru-RU, uk-UA, be-BY, hy-AM, kk-KZ.\r\nT1016\r\nSystem Network\r\nConfiguration Discovery\r\nBlackLotus HTTP downloader can determine the public\r\nIP of a compromised host by requesting api.ipify[.]org\r\nservice.\r\nT1016.001\r\nSystem Network\r\nConfiguration Discovery:\r\nInternet Connection\r\nDiscovery\r\nBlackLotus HTTP downloader checks the internet\r\nconnection by querying Microsoft’s\r\nwww.msftncsi[.]com/ncsi[.]txt\r\nT1497.001\r\nVirtualization/Sandbox\r\nEvasion: System Checks\r\nBlackLotus employs various system checks including\r\nchecking sandbox-specific registry values, to detect and\r\navoid virtualization and analysis environments.\r\nCommand\r\nand Control\r\nT1071.001\r\nApplication Layer\r\nProtocol: Web Protocols\r\nBlackLotus uses HTTPS for communication with its\r\nC\u0026C.\r\nT1132.001\r\nData Encoding: Standard\r\nEncoding\r\nBlackLotus encodes encrypted data in C\u0026C\r\ncommunication with URL-safe base64.\r\nT1573.001\r\nEncrypted Channel:\r\nSymmetric Cryptography\r\nBlackLotus uses 256-bit AES in CBC mode to decrypt\r\nmessages received from its C\u0026C.\r\nT1573.002\r\nEncrypted Channel:\r\nAsymmetric Cryptography\r\nBlackLotus uses an embedded RSA public key to encrypt\r\nmessages sent to C\u0026C.\r\nhttps://www.welivesecurity.com/2023/03/01/blacklotus-uefi-bootkit-myth-confirmed/\r\nPage 25 of 26\n\nSource: https://www.welivesecurity.com/2023/03/01/blacklotus-uefi-bootkit-myth-confirmed/\r\nhttps://www.welivesecurity.com/2023/03/01/blacklotus-uefi-bootkit-myth-confirmed/\r\nPage 26 of 26",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA",
		"Malpedia",
		"MITRE"
	],
	"references": [
		"https://www.welivesecurity.com/2023/03/01/blacklotus-uefi-bootkit-myth-confirmed/"
	],
	"report_names": [
		"blacklotus-uefi-bootkit-myth-confirmed"
	],
	"threat_actors": [],
	"ts_created_at": 1775433978,
	"ts_updated_at": 1775791266,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/02a621ef55e355eeee9801f663b69f23ac0d6559.pdf",
		"text": "https://archive.orkl.eu/02a621ef55e355eeee9801f663b69f23ac0d6559.txt",
		"img": "https://archive.orkl.eu/02a621ef55e355eeee9801f663b69f23ac0d6559.jpg"
	}
}