Like changing the locks but leaving a master key in the flowerpot for four years
CVE-2022-21894 ("Baton Drop") is a Secure Boot Security Feature Bypass in the Windows boot chain. An attacker with local administrator or physical access can deploy legitimately signed but vulnerable Windows bootloaders (bootmgfw.efi, hvloader.efi) to the EFI System Partition, then manipulate Boot Configuration Data to strip the serialized Secure Boot policy from memory using the truncatememory BCD option. This enables testsigning and nointegritychecks flags, allowing arbitrary unsigned code execution before the OS kernel loads. Every UEFI Secure Boot–enabled Windows version is affected: Windows 10 (20H2 through 21H2), Windows 11 21H2+, and Windows Server 2012 through 2022. The January 2022 patch (KB5009543/KB5009555/KB5009557/KB5009566) addressed the code flaw, but the vulnerable signed bootloader binaries were never revoked from the UEFI Forbidden Signature Database (DBX). Microsoft's KB5025885 rollout has been painfully slow — phased from May 2023 through a final enforcement phase that was not scheduled before January 2026 — and most enterprises have not manually applied the registry flags and scheduled tasks required to activate DBX revocation.
Microsoft rated this MEDIUM 4.4, and in isolation the CVSS vector (AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:N) is technically defensible — local attack vector, high privileges required, integrity-only impact. But the vendor score catastrophically undersells reality. The BlackLotus UEFI bootkit (criminal market, ~$5,000, confirmed ITW by ESET in March 2023) and BlackX (APT41/FishMonger campaign against Central Asian diplomatic targets, discovered early 2026 by Kaspersky) both weaponize this exact CVE to plant firmware-resident implants that survive OS reinstallation, disable BitLocker, HVCI, VBS, and Windows Defender, and evade every OS-level EDR. The NSA published a dedicated mitigation guide (CSI U/OO/167397-23) — an extraordinary step for a "medium" CVE. When nation-state actors are actively exploiting a bug whose four-year-old patch doesn't actually work, a 4.4 is not just conservative; it's dangerously misleading.
5 steps from start to impact.
Gain local administrator access
googleupdate.exe (OxiDLLRunner) to achieve admin on diplomatic network hosts.- Local administrator or SYSTEM privileges on the target
- Write access to the EFI System Partition (requires admin)
- Requires a prior compromise chain — this is not an initial-access vulnerability
- Physical-access-only scenarios limit exposure to insider threat or supply-chain interdiction
Deploy vulnerable signed bootloaders to ESP
bootmgfw.efi, hvloader.efi, shim) to the EFI System Partition alongside modified BCD files. Because these binaries carry valid Microsoft signatures and the DBX has not been updated on most systems, Secure Boot trusts them. The BlackLotus installer automates this step entirely.- EFI System Partition is writable (always true with admin)
- DBX revocation for vulnerable bootloaders not applied (default on most enterprise fleets)
- Enterprises that have manually applied KB5025885 Phase 3+ with registry flag and DBX update block this step
- Firmware-level write protections on some OEM hardware (rare in practice)
mountvol S: /s) for unexpected file modifications. NSA guide recommends integrity monitoring of \EFI\Microsoft\Boot\ directory. Eclypsium and Binarly FwHunt can detect known vulnerable bootloader hashes.Exploit CVE-2022-21894 via BCD manipulation
truncatememory option removes the Secure Boot policy from memory, then testsigning and nointegritychecks flags are enabled. This allows the bootkit's unsigned self-signed UEFI application to execute in the pre-boot environment with full firmware-level privileges. The exploit is 100% reliable — no heap spray, no race condition, no ASLR bypass needed.- System reboots with the attacker-controlled BCD active
- Secure Boot policy not hardened with custom DBX entries
- Systems with custom Secure Boot policies or Linux shim-based lockdown may resist
- Reboot requirement creates a small detection window (Event Logs capture unexpected reboots)
bcdedit /enum all for suspicious entries with truncatememory or testsigning.Enroll attacker Machine Owner Key (MOK)
.efi binary. This persistence survives OS reinstallation, disk wipes of the OS partition, and most incident response playbooks because the MOK lives in NVRAM, not on disk.- UEFI NVRAM is writable (standard on all modern UEFI implementations)
- No Secure Boot custom policy blocking MOK enrollment
- Hardware TPM attestation with remote verification (rare outside high-security environments) would detect MOK changes
- UEFI firmware with MOK enrollment password protection (uncommon)
mokutil --list-enrolled (Linux) or check NVRAM variables. Microsoft's April 2023 blog provides specific forensic indicators for MOK tampering.Disable OS security stack and establish C2
DisableKeyProtectors), HVCI (registry modification), VBS (VbsPolicyDisable NVRAM variable), and Windows Defender (driver entry point patching). It then injects an HTTP downloader into winlogon.exe for command-and-control. BlackX additionally deploys a .NET RAT using Google Drive, OneDrive, and Yandex.Disk as C2 channels. The host is now fully compromised below the OS with all defensive telemetry blind.- Bootkit successfully loaded via MOK chain
- Network connectivity for C2 (HTTP/HTTPS to cloud storage providers)
- Network-level monitoring of cloud storage API calls may detect C2 traffic
- Hardware-based remote attestation (Intel TXT, AMD SEV) with external verifier would detect boot chain compromise
manage-bde -protectors -get C:), HVCI/VBS disabled unexpectedly, Defender service in degraded state. Check for HTTP downloader DLL injection in winlogon.exe process memory.HKLM\SYSTEM\CurrentControlSet\Control\Secureboot → AvailableUpdates = 0x30 followed by running the SecureBootDBXUpdateTask scheduled task. This adds the vulnerable bootloader hashes to the UEFI Forbidden Signature Database, blocking the Baton Drop exploit chain at Step 2. WARNING: Test on dual-boot systems first — this may break Linux GRUB configurations. Deploy within 30 days per the noisgate mitigation SLA for HIGH severity.\EFI\Microsoft\Boot\ on the ESP, alerting on any unauthorized modifications. This detects Step 2 (bootloader deployment) in near-real-time. Pair with Windows Event Log monitoring for BCD changes (Events 1001/1006). Deploy within 30 days.mokutil --list-enrolled (Linux) or UEFI NVRAM inspection tools to inventory all enrolled Machine Owner Keys. Any MOK not matching your organization's known-good list indicates potential compromise. On Windows, check NVRAM variables via PowerShell or Eclypsium. This detects Step 4 (MOK enrollment) post-compromise. Deploy within 30 days.- OS-level patching alone — Installing the January 2022 security update (KB5009543 etc.) fixes the code path but does NOT revoke the vulnerable signed bootloaders. An attacker simply brings their own copy of the old, legitimately signed, vulnerable binary. The patch without DBX revocation provides zero protection.
- Standard EDR/AV — Once the bootkit is loaded, it operates below the OS and patches Defender driver entry points to return immediately. EDR agents that load after the kernel cannot detect or prevent a bootkit that loaded before them. EDR may detect the *installer* but not the *implant* post-reboot.
- OS reinstallation / disk reimaging — The bootkit persists via MOK enrollment in UEFI NVRAM and files on the EFI System Partition. Standard OS reimaging does not touch NVRAM or the ESP. The host will be reinfected on next boot from the same firmware state.
- BitLocker without TPM+PIN — BlackLotus suspends BitLocker protectors via WMI before reboot. TPM-only BitLocker provides no additional resistance because the bootkit modifies the boot chain before the TPM unseals the volume key.
The supporting signals.
| In-the-Wild Exploitation | Confirmed active. BlackLotus bootkit (criminal market, ESET confirmed March 2023, sold for ~$5,000 on underground forums). BlackX bootkit (APT41/FishMonger, Kaspersky, early 2026) targeting diplomatic agencies in Tajikistan, Uzbekistan, and Turkmenistan. Microsoft published dedicated investigation guidance in April 2023. |
|---|---|
| PoC Availability | Public and mature. Wack0/CVE-2022-21894 on GitHub (~342 stars) — full Baton Drop implementation. Also Wack0/batondrop_armv7 for ARM. BlackLotus source code is believed to have been leaked or reverse-engineered (per Kaspersky analysis of BlackX). The exploit is deterministic — no brute-forcing or memory corruption involved. |
| EPSS | 0.06567 (6.6th percentile) — EPSS significantly underweights this because the exploit is local/post-compromise and not scannable from the internet, but the active nation-state exploitation makes EPSS misleading here. |
| KEV Status | Not listed on CISA KEV as of October 2026. This is a notable gap given confirmed ITW exploitation by both criminal and APT actors. CVE-2023-24932 (the related Secure Boot bypass addressed by KB5025885) *is* KEV-listed. |
| CVSS Vector | CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:N — 4.4 MEDIUM. The vector correctly captures local/high-privilege prerequisites but fails to model cascading impact: Scope should arguably be Changed (S:C) because the bootkit breaks out of the OS trust boundary into firmware, and the Confidentiality impact is effectively HIGH once Defender/EDR are disabled and a RAT is deployed. |
| Affected Versions | All UEFI Secure Boot–enabled Windows: Windows 10 (20H2, 21H1, 21H2), Windows 11 (21H2+), Windows Server 2012/2012 R2, 2016, 2019, 2022. Any system that has not applied DBX revocation via KB5025885 enforcement phase remains exploitable regardless of OS patch level. |
| Fix Status | Code patch: January 2022 (KB5009543/KB5009555/KB5009557/KB5009566). Effective fix (DBX revocation): KB5025885, phased rollout from May 2023. Final enforcement phase not before January 2026. Most enterprise fleets have NOT completed revocation due to dual-boot breakage fears and manual registry-flag requirements. UEFI CA 2011 expires June 27, 2026; Windows Production PCA 2011 expires October 19, 2026. |
| Scanning / Exposure | Not remotely scannable (local exploit). No GreyNoise/Shodan/Censys signatures applicable. Detection requires host-level inspection of DBX state, EFI System Partition integrity, and MOK enrollment status. Eclypsium and Binarly provide firmware-level scanning; most EDR vendors added BlackLotus hash-based detections by mid-2023. |
| Government Advisories | NSA Cybersecurity Information Sheet CSI U/OO/167397-23 (June 2023) — dedicated mitigation guide, extremely rare for a MEDIUM-rated CVE. Microsoft published BlackLotus campaign investigation guidance (April 2023). |
| Researcher / Disclosure | Original Baton Drop research by Wack0 (GitHub). BlackLotus analysis by ESET (Martin Smolár, March 2023). Firmware-level analysis by Binarly (Alex Matrosov). BlackX/APT41 attribution by Kaspersky (early 2026). |
Sources.
- ESET — BlackLotus UEFI bootkit: Myth confirmed
- Microsoft — Guidance for investigating attacks using CVE-2022-21894: The BlackLotus campaign
- NSA — BlackLotus Mitigation Guide (CSI U/OO/167397-23)
- Kaspersky/SecurityOnline — APT41 Deploys BlackX UEFI Bootkit Against Central Asian Diplomatic Agencies
- Binarly — The Untold Story of the BlackLotus UEFI Bootkit
- Microsoft — Revoking vulnerable Windows boot managers (KB5025885)
- Eclypsium — BlackLotus: A Threat Coming to a System Near You
- NVD — CVE-2022-21894
Why this verdict
- Active nation-state exploitation (2026): APT41's BlackX campaign against Central Asian diplomatic targets in early 2026 confirms this CVE is under active, sophisticated exploitation — not a theoretical risk. Combined with BlackLotus criminal-market exploitation from 2022-2023, this bug has a proven track record across threat actor tiers.
- Patch is functionally broken: Microsoft shipped a code fix in January 2022, but the vulnerable signed bootloader binaries remain trusted by Secure Boot on the vast majority of enterprise systems. KB5025885's DBX revocation requires manual registry flags and a scheduled task that most organizations have not deployed. The patch creates a false sense of security.
- Below-OS persistence defeats incident response: The bootkit survives OS reinstallation, disk wipes, and standard reimaging workflows. It disables BitLocker, HVCI, VBS, and Windows Defender from firmware, rendering all OS-level security telemetry blind. This fundamentally changes the cost of remediation from 'reimage the host' to 'reflash firmware and clear NVRAM.'
- NSA published dedicated mitigation guidance: The NSA does not issue standalone CSIs for routine MEDIUM vulnerabilities. CSI U/OO/167397-23 specifically warns that 'even fully patched Windows systems may remain vulnerable' — an extraordinary statement that directly contradicts the vendor's implied risk posture.
- Role multiplier: On Domain Controllers (Windows Server is affected; DCs represent ~2-5% of enterprise Windows deployments), an attacker who has achieved DA can install the bootkit for undetectable, persistent access to the identity tier that survives incident response — blast radius is domain→fleet. On Hyper-V hosts, the bootkit subverts the hypervisor trust chain — blast radius is all VMs on that host. On any Windows endpoint, it provides EDR-blind persistence. The component (Windows Secure Boot) runs on 100% of UEFI Windows machines, and the high-value-role population (DCs, hypervisors, backup servers) is well above the 1% threshold. Floor: HIGH.
- Deterministic exploit with public PoC: Unlike memory corruption bugs, Baton Drop is 100% reliable — it manipulates BCD policy, not memory. The Wack0 PoC is mature and publicly available. BlackLotus source appears to have been shared or reverse-engineered for BlackX, indicating commoditization of the exploit chain.
Why not higher?
The exploit requires existing local administrator or SYSTEM privileges (PR:H), making it strictly a post-compromise persistence and defense-evasion tool, not an initial-access vector. An attacker who can install the bootkit has *already* fully compromised the host at the OS level. The vulnerability amplifies and entrenches an existing compromise rather than enabling a new one. The Scope:Unchanged designation, while debatable, reflects that the attacker's initial privilege boundary was already admin-level.
Why not lower?
Active exploitation by a named APT group (APT41) in 2026, combined with a criminal-market bootkit (BlackLotus) and a functionally broken patch, makes any rating below HIGH indefensible. The capability to survive OS reinstallation and blind all OS-level security tools fundamentally changes incident response economics — a compromised host cannot be recovered by standard reimaging, requiring firmware-level remediation that most enterprises cannot perform at scale. The NSA's dedicated advisory is a strong signal that the real-world risk exceeds the vendor's CVSS assessment.
Crowdsourced verification payload.
Run on each target Windows host with Administrator privileges. Execute: powershell -ExecutionPolicy Bypass -File .\Check-CVE202221894.ps1. The script checks Secure Boot status, DBX revocation state, and KB5025885 enforcement registry flags. Outputs VULNERABLE, PATCHED, or UNKNOWN.
#Requires -RunAsAdministrator
<#
.SYNOPSIS
Check-CVE202221894.ps1 - Checks whether the host is protected against CVE-2022-21894 (Baton Drop)
.DESCRIPTION
Verifies: (1) Secure Boot is enabled, (2) KB5025885 DBX revocation enforcement flags are set,
(3) The AvailableUpdates registry value indicates revocation has been applied.
Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN
#>
$ErrorActionPreference = 'Stop'
$result = 'UNKNOWN'
$findings = @()
try {
# Check 1: Is Secure Boot enabled?
try {
$sbState = Confirm-SecureBootUEFI
if (-not $sbState) {
$findings += 'Secure Boot is DISABLED - system is inherently unprotected by Secure Boot'
} else {
$findings += 'Secure Boot is ENABLED'
}
} catch {
$findings += 'Unable to query Secure Boot state (may not be UEFI system)'
}
# Check 2: KB5025885 registry enforcement flag
$regPath = 'HKLM:\SYSTEM\CurrentControlSet\Control\Secureboot'
$regValue = 'AvailableUpdates'
try {
$avail = (Get-ItemProperty -Path $regPath -Name $regValue -ErrorAction Stop).$regValue
if (($avail -band 0x30) -eq 0x30) {
$findings += "KB5025885 enforcement flags are SET (AvailableUpdates = 0x$($avail.ToString('X')))"
} else {
$findings += "KB5025885 enforcement flags NOT fully set (AvailableUpdates = 0x$($avail.ToString('X')), need 0x30)"
}
} catch {
$findings += 'KB5025885 registry key not found - revocation NOT configured'
$avail = $null
}
# Check 3: Check if SVN (Secure Version Number) has been updated (indicates DBX was applied)
$svnPath = 'HKLM:\SYSTEM\CurrentControlSet\Control\Secureboot'
try {
$props = Get-ItemProperty -Path $svnPath -ErrorAction Stop
if ($props.PSObject.Properties.Name -contains 'SetupMode') {
$findings += "Secure Boot SetupMode = $($props.SetupMode)"
}
} catch {
$findings += 'Unable to read additional Secure Boot registry state'
}
# Check 4: Look for the scheduled task that applies DBX
try {
$task = Get-ScheduledTask -TaskName 'SecureBootDBXUpdateTask' -ErrorAction Stop
$taskState = $task.State
$findings += "SecureBootDBXUpdateTask exists, state: $taskState"
if ($task.LastRunTime) {
$findings += "Last DBX update task run: $($task.LastRunTime)"
}
} catch {
$findings += 'SecureBootDBXUpdateTask NOT found - DBX update has not been configured'
}
# Check 5: Verify installed KB
$hotfixes = Get-HotFix -ErrorAction SilentlyContinue | Where-Object { $_.HotFixID -match 'KB5025885|KB5009543|KB5009555|KB5009557|KB5009566' }
if ($hotfixes) {
$kbList = ($hotfixes | Select-Object -ExpandProperty HotFixID) -join ', '
$findings += "Relevant KB(s) installed: $kbList"
} else {
$findings += 'No relevant KBs detected via Get-HotFix (may be superseded by later CU)'
}
# Determine overall verdict
$secureBootOn = $false
try { $secureBootOn = Confirm-SecureBootUEFI } catch { }
$enforcementSet = ($null -ne $avail) -and (($avail -band 0x30) -eq 0x30)
if ($secureBootOn -and $enforcementSet) {
$result = 'PATCHED'
} elseif (-not $secureBootOn) {
$result = 'VULNERABLE'
} elseif (-not $enforcementSet) {
$result = 'VULNERABLE'
} else {
$result = 'UNKNOWN'
}
} catch {
$findings += "Error during check: $_"
$result = 'UNKNOWN'
}
Write-Host ''
Write-Host '=== CVE-2022-21894 (Baton Drop) Assessment ===' -ForegroundColor Cyan
foreach ($f in $findings) {
Write-Host " [*] $f"
}
Write-Host ''
switch ($result) {
'PATCHED' { Write-Host "RESULT: PATCHED - DBX revocation enforcement is active" -ForegroundColor Green; exit 0 }
'VULNERABLE' { Write-Host "RESULT: VULNERABLE - DBX revocation NOT enforced, exploit chain viable" -ForegroundColor Red; exit 1 }
'UNKNOWN' { Write-Host "RESULT: UNKNOWN - Could not determine protection status" -ForegroundColor Yellow; exit 2 }
}