{
	"id": "b20f03b8-69f4-49e1-836d-7bf469a8a0ce",
	"created_at": "2026-04-06T00:22:31.710754Z",
	"updated_at": "2026-04-10T03:21:16.309572Z",
	"deleted_at": null,
	"sha1_hash": "d9e31afd38277cd042462f3867a6aba61908f53e",
	"title": "Guidance for investigating attacks using CVE-2022-21894: The BlackLotus campaign | Microsoft Security Blog",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1268604,
	"plain_text": "Guidance for investigating attacks using CVE-2022-21894: The\r\nBlackLotus campaign | Microsoft Security Blog\r\nBy Microsoft Incident Response\r\nPublished: 2023-04-11 · Archived: 2026-04-05 14:03:34 UTC\r\nThis guide provides steps that organizations can take to assess whether users have been targeted or compromised\r\nby threat actors exploiting CVE-2022-21894 via a Unified Extensible Firmware Interface (UEFI) bootkit called\r\nBlackLotus. UEFI bootkits are particularly dangerous as they run at computer startup, prior to the operating\r\nsystem loading, and therefore can interfere with or deactivate various operating system (OS) security mechanisms\r\nsuch as BitLocker, hypervisor-protected code integrity (HVCI), and Microsoft Defender Antivirus. Though this\r\ncould impede investigations and threat hunting efforts, several artifacts can still be leveraged to identify affected\r\ndevices. This document covers:\r\nTechniques to determine if devices in an organization are infected\r\nRecovery and prevention strategies to protect your environment\r\nIt is critical to note that a threat actor’s use of this bootkit is primarily a persistence and defense evasion\r\nmechanism. It is not a first-stage payload or an initial access vector and can only be deployed to a device to which\r\na threat actor has already gained either privileged access or physical access. The malware uses CVE-2022-21894\r\n(also known as Baton Drop) to bypass Windows Secure Boot and subsequently deploy malicious files to the EFI\r\nSystem Partition (ESP) that are launched by the UEFI firmware. This allows the bootkit to:\r\nAchieve persistence by enrolling the threat actor’s Machine Owner Key (MOK)\r\nTurn off HVCI to allow deployment of a malicious kernel driver\r\nLeverage the kernel driver to deploy the user-mode HTTP downloader for command and control (C2)\r\nTurn off Bitlocker to avoid tamper protection strategies on Windows\r\nTurn off Microsoft Defender Antivirus to avoid further detection\r\nFor a comprehensive analysis of the BlackLotus installation process and follow-on actions, read this blog by\r\nESET.\r\nDetection opportunities\r\nMicrosoft Incident Response (previously known as Microsoft Detection and Response Team – DART), through\r\nforensic analysis of devices infected with BlackLotus, has identified multiple opportunities for detection along\r\nseveral steps in its installation and execution processes. The artifacts analyzed include:\r\nRecently written bootloader files\r\nStaging directory artifacts created\r\nRegistry key modified\r\nWindows Event logs entries generated\r\nhttps://www.microsoft.com/en-us/security/blog/2023/04/11/guidance-for-investigating-attacks-using-cve-2022-21894-the-blacklotus-campaign/\r\nPage 1 of 10\n\nNetwork behavior\r\nBoot Configuration log entries generated\r\nAs threat hunters begin examining environments, it is crucial to adopt a comprehensive hunting strategy across\r\nthese artifacts to down-filter false positives and surface true positives. Many of these artifacts, when observed in\r\nisolation, are low fidelity. Observing them in tandem with others, however, increases their significance in\r\ndetermining if a device has been infected.\r\nRecently created and locked bootloader files\r\nBlackLotus writes malicious bootloader files to the EFI system partition (ESP) and subsequently locks them to\r\nprotect them from deletion or tampering. If recently modified and locked files are identified in the ESP on a\r\ndevice, especially those matching known BlackLotus bootloader filenames, these should be considered highly\r\nsuspect and the devices should be removed from the network to be examined for further evidence of BlackLotus\r\nor follow-on activity.\r\nTo determine if such files exist in the ESP, threat hunters can mount the boot partition (with the mountvol\r\ncommand-line utility, for example) to examine the creation dates of the files within. Files with mismatched\r\ncreation times, as well as those with names matching those protected by the BlackLotus kernel driver, should be\r\nconsidered suspicious (Figure 1). The LastModified timestamps of the files in the ESP should be compared to each\r\nother; the timestamps and filenames can also be compared against those in the OS partition under\r\nC:\\Windows\\Boot\\EFI.\r\nThe files protected by the driver include, as originally listed by ESET:\r\nESP:\\EFI\\Microsoft\\Boot\\winload.efi\r\nESP:\\EFI\\Microsoft\\Boot\\bootmgfw.efi\r\nESP:\\EFI\\Microsoft\\Boot\\grubx64.efi\r\nFigure 1: Evidence of recent modification dates and matching filenames of BlackLotus-associated\r\nfiles on a BlackLotus infected device.\r\nTo further confirm if any files with matching filenames or mismatched modification times are suspect, threat\r\nhunters can leverage the local CertUtil command-line utility to attempt to calculate the hash of a suspected\r\nbootloader file in the ESP. In Figure 1, winload.efi does NOT have a mismatched modified time, yet matches the\r\nfilename protected by the BlackLotus kernel driver.\r\nhttps://www.microsoft.com/en-us/security/blog/2023/04/11/guidance-for-investigating-attacks-using-cve-2022-21894-the-blacklotus-campaign/\r\nPage 2 of 10\n\nSince these protected bootloader files are locked by BlackLotus, any attempt to access these files generates an\r\nERROR_SHARING_VIOLATION error with the message “The process cannot access the file because it is being\r\nused by another process”. Figure 2 depicts this error being generated when attempting to hash winload.efi on the\r\ninfected device from Figure 1, further confirming that it is BlackLotus-related in this scenario.\r\nFigure 2: CertUtil reporting an ERROR_SHARING_VIOLATION message upon attempting to\r\nhash winload.efi in the ESP of a BlackLotus infected device.\r\nIf the malware is active, CertUtil reports the sharing violation error as in Figure 2; if not, CertUtil reports the hash\r\nof the file. Files in the ESP that return this error should be considered highly suspicious, especially those matching\r\nthe protected filenames listed above.\r\nBlackLotus staging directory presence\r\nDuring the installation process, BlackLotus creates a custom directory under ESP:/system32/. Though the files\r\nwithin are deleted following successful installation, the directory itself is not deleted. Additionally, forensic\r\nanalysis of the ESP may reveal the historical presence of the files previously contained in this directory (Figure 3).\r\nFigure 3: Evidence of deleted files in ESP:\\system32\\ associated with BlackLotus, in a custom\r\nstaging directory still present post-installation.\r\nRegistry modification\r\nTo turn off HVCI, the installer modifies the registry key\r\nHKLM:\\SYSTEM\\CurrentControlSet\\Control\\DeviceGuard\\Scenarios\\HypervisorEnforcedCodeIntegrity by\r\nsetting the value Enabled to “0” – but only if the key already exists. Threat hunters should examine their\r\nenvironment for this registry key modification (Figure 4).\r\nFigure 4: RegEdit depiction of the modified registry key to disable HVCI\r\nEvent logs entries\r\nhttps://www.microsoft.com/en-us/security/blog/2023/04/11/guidance-for-investigating-attacks-using-cve-2022-21894-the-blacklotus-campaign/\r\nPage 3 of 10\n\nBlackLotus disables Microsoft Defender Antivirus as a defense evasion method by patching its drivers and\r\nstripping the main process’s privileges.\r\nThis behavior may produce entries in the Microsoft-Windows-Windows Defender/Operational log in Windows\r\nEvent Logs. Relevant log entries will indicate that Antimalware security intelligence has stopped functioning for\r\nan unknown reason (see Figure 5).\r\nFigure 5: Event Log indicating Microsoft Defender Antivirus real-time protection has stopped\r\nfunctioning\r\nThe disabling of Microsoft Defender Antivirus may also result in the service stopping unexpectedly, producing an\r\nEvent ID 7023 in the System event log (with Service Control Manager as the Provider Name). Relevant log\r\nentries will name the Microsoft Defender Antivirus Service as the affected service (Figure 6).\r\nhttps://www.microsoft.com/en-us/security/blog/2023/04/11/guidance-for-investigating-attacks-using-cve-2022-21894-the-blacklotus-campaign/\r\nPage 4 of 10\n\nFigure 6: System event log entry indicating the Microsoft Defender Antivirus service has been\r\nterminated with an error\r\nNetwork logging\r\nOutbound network connections from winlogon.exe, particularly to port 80, should be considered highly\r\nsuspicious. This is the result of the injected HTTP downloader function of BlackLotus connecting to the C2 server\r\nor performing network configuration discovery. Microsoft Incident Response observed this connection with\r\nSysmon monitoring on an infected device. Figure 7 depicts winlogon.exe attempting to communicate to the\r\napi.ipify.org service to determine the public IP address of the compromised device.\r\nhttps://www.microsoft.com/en-us/security/blog/2023/04/11/guidance-for-investigating-attacks-using-cve-2022-21894-the-blacklotus-campaign/\r\nPage 5 of 10\n\nFigure 7: Sysmon event entry indicating winlogon.exe attempting to communicate outbound on port\r\n80\r\nThis entry was captured with a simple modification to the SwiftOnSecurity Sysmon configuration (see Figure 8).\r\nFigure 8: Modified Sysmon configuration to detect winlogon.exe network connection behavior\r\nAnalysis of netstat output on an affected device may also reveal winlogon.exe maintaining a network connection\r\non port 80. Given the configuration capabilities of the implant, the connection may be intermittent.\r\nhttps://www.microsoft.com/en-us/security/blog/2023/04/11/guidance-for-investigating-attacks-using-cve-2022-21894-the-blacklotus-campaign/\r\nPage 6 of 10\n\nBoot configuration log analysis\r\nTrusted Computing Group (TCG) logs, also known as MeasuredBoot logs, are Windows Boot Configuration Logs\r\nthat contain information about the Windows OS boot process. To retrieve these logs, the device must be running at\r\nleast Windows 8 and have the Trusted Platform Module (TPM) enabled.\r\nFrom How Windows uses the Trusted Platform Module: “Windows 8 introduced Measured Boot as a way for the\r\noperating system to record the chain of measurements of software components and configuration information in\r\nthe TPM through the initialization of the Windows operating system.” “For software, Measured Boot records\r\nmeasurements of the Windows kernel, Early-Launch Anti-Malware drivers, and boot drivers in the TPM.”\r\nThe BlackLotus bootkit has boot drivers that are loaded in the boot cycle. MeasuredBoot logs list the BlackLotus\r\ncomponents as EV_EFI_Boot_Services_Application.\r\nThese logs are in the C:\\Windows\\Logs\\MeasuredBoot directory, which contains multiple files with the extension\r\n.log – one for each reboot of the system. These logs can be compared to one another to identify deltas in\r\ncomponents added or removed from each boot.\r\nIn the case of BlackLotus installation, two components are added when BlackLotus becomes active on a system:\r\nthe grubx64.efi driver and winload.efi driver (see Figure 9).\r\nFigure 9: BlackLotus components visible in MeasuredBoot logs after parsing to XML\r\nOn live machines, the active MeasuredBoot log files are stored in system memory and can be read either via the\r\nTPM base services API or via the PowerShell shown below. Alternatively, they can be acquired from a forensic\r\nimage. The log files must then be decoded and converted to XML/JSON. A sample script to extract and parse\r\nthese logs is presented here, based on GitHub – mattifestation/TCGLogTools: A set of tools to retrieve and parse\r\nTCG measured boot logs.\r\n1\r\n2\r\n3\r\n4\r\n$TCGLogBytes = Get-TCGLogContent -LogType SRTMCurrent\r\n$TCGLog = ConvertTo-TCGEventLog -LogBytes $TCGLogBytes\r\n$PCR4 = $TCGLog.Events.PCR4\r\nforeach ($Event in $PCR4) {\r\nhttps://www.microsoft.com/en-us/security/blog/2023/04/11/guidance-for-investigating-attacks-using-cve-2022-21894-the-blacklotus-campaign/\r\nPage 7 of 10\n\n5\r\n6\r\n7\r\n8\r\n9\r\n10\r\n11\r\n12\r\n13\r\n14\r\n15\r\n16\r\n17\r\n18\r\nif ($Event.EventType -eq \"EV_EFI_BOOT_SERVICES_APPLICATION\") {\r\n$DevicePath = $Event.Event.DevicePath\r\nif ($DevicePath -is [array]) {\r\nforeach ($Device in $DevicePath) {\r\nif (($Device.Type -eq \"MEDIA_DEVICE_PATH\") -and ($Device.SubType -eq\r\n\"MEDIA_FILEPATH_DP\")) {\r\nWrite-Host \"Boot application:\", $Device.DeviceInfo.PathName\r\n}\r\n}\r\n} else {\r\n$PathName = $DevicePath.DeviceInfo.PathName\r\nWrite-Host \"Boot application:\", $PathName\r\n}\r\n}\r\n}\r\nExample output of this script from an infected device can be seen in Figure 10.\r\nFigure 10: Example output of the TCG parsing script to enumerate boot components\r\nDetection details\r\nhttps://www.microsoft.com/en-us/security/blog/2023/04/11/guidance-for-investigating-attacks-using-cve-2022-21894-the-blacklotus-campaign/\r\nPage 8 of 10\n\nMicrosoft Defender Antivirus detects threat components as the following malware (note that these signatures\r\ntrigger on hashes of known BlackLotus samples):\r\nTrojan:Win32/BlackLotus\r\nTrojan:Win64/BlackLotus\r\nMicrosoft Defender for Endpoint alerts on known BlackLotus activity and/or post-exploitation activity. The\r\nfollowing alert title can indicate threat activity on your network:\r\nPossible vulnerable EFI bootloader \r\nNetwork protection in Microsoft Defender for Endpoint blocks connections to known indicators associated with\r\nBlackLotus C2 servers.\r\nRecovery and prevention guidance\r\nIf a device is determined to have been infected with BlackLotus, the device should be removed from the network\r\nand reformatted (both the OS partition and EFI partition) or restored from a known clean backup that includes the\r\nEFI partition.\r\nTo prevent infection via BlackLotus or other variants abusing CVE-2022-21894, organizations should:\r\nPractice the principle of least privilege and maintain credential hygiene. Avoid the use of domain-wide,\r\nadmin-level service accounts. Restricting local administrative privileges can help limit installation of\r\nremote access trojans (RATs) and other unwanted applications.\r\nThis is key to preventing threat actors looking to deploy BlackLotus, which requires either remote administrative\r\nprivileges on a target machine or physical access to the device. Organizations should implement defense-in-depth\r\nstrategies to minimize the risk of threat actors gaining access and an administrative foothold in the environment.\r\nThis can include detection and/or prevention at multiple stages prior to deployment of BlackLotus:\r\nA threat actor gaining initial access via phishing, perimeter device compromise, or other vectors\r\nA threat actor compromising user or service account credentials on the network\r\nA threat actor moving laterally through the network using unusual or unauthorized accounts, abusing\r\nremote access software, or other mechanisms\r\nA threat actor escalating and gaining domain or local administrative privileges\r\nA threat actor creating malicious files on disk, including the BlackLotus installers or EFI files\r\nCustomers should keep antimalware products up to date. Customers utilizing automatic updates for\r\nMicrosoft Defender Antivirus do not need to take additional action. Enterprise customers managing\r\nupdates should select the detection build 383.1029.0 or newer and deploy it across their environments.\r\nRemove the Microsoft 3rd Party UEFI CA from your system’s UEFI Secure boot configuration if this is\r\nnot required for your system to boot. Performing this step blocks BlackLotus from working but does not\r\neliminate the vulnerability.\r\nReferences \r\nhttps://www.microsoft.com/en-us/security/blog/2023/04/11/guidance-for-investigating-attacks-using-cve-2022-21894-the-blacklotus-campaign/\r\nPage 9 of 10\n\nBlackLotus UEFI bootkit: Myth confirmed (ESET)\r\nMalware dev claims to sell BlackLotus new Windows UEFI bootkit (BleepingComputer)\r\nSecure Boot Security Feature Bypass Vulnerability\r\nSource: https://www.microsoft.com/en-us/security/blog/2023/04/11/guidance-for-investigating-attacks-using-cve-2022-21894-the-blacklotus-c\r\nampaign/\r\nhttps://www.microsoft.com/en-us/security/blog/2023/04/11/guidance-for-investigating-attacks-using-cve-2022-21894-the-blacklotus-campaign/\r\nPage 10 of 10",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia",
		"MITRE"
	],
	"references": [
		"https://www.microsoft.com/en-us/security/blog/2023/04/11/guidance-for-investigating-attacks-using-cve-2022-21894-the-blacklotus-campaign/"
	],
	"report_names": [
		"guidance-for-investigating-attacks-using-cve-2022-21894-the-blacklotus-campaign"
	],
	"threat_actors": [],
	"ts_created_at": 1775434951,
	"ts_updated_at": 1775791276,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/d9e31afd38277cd042462f3867a6aba61908f53e.pdf",
		"text": "https://archive.orkl.eu/d9e31afd38277cd042462f3867a6aba61908f53e.txt",
		"img": "https://archive.orkl.eu/d9e31afd38277cd042462f3867a6aba61908f53e.jpg"
	}
}