← Back to Feed CACHED · 2026-10-22 13:08:54 · CACHE_KEY CVE-2022-21894
CVE-2022-21894 · CWE-863 · Disclosed 2022-01-11

Microsoft Windows Secure Boot policy bypass via BCD truncatememory manipulation

ASSESSED — NOISGATE
Vendor
—
—
—
Reassessed
—
—
—
Verdict: —
Do you agree?
01 · The Real Story

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.

"Patched in 2022 but still exploitable in 2026 — the bootkit that broke incident response"
02 · The Attack Path

5 steps from start to impact.

STEP 01

Gain local administrator access

The attacker obtains SYSTEM or local admin privileges on the target Windows host through a separate initial-access chain — phishing, credential theft, lateral movement, or physical access. BlackLotus was distributed as a standalone installer requiring admin execution; BlackX/APT41 used spear-phishing and DLL sideloading via googleupdate.exe (OxiDLLRunner) to achieve admin on diplomatic network hosts.
Conditions required:
  • Local administrator or SYSTEM privileges on the target
  • Write access to the EFI System Partition (requires admin)
Where this breaks in practice:
  • 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
Detection/coverage: EDR/XDR alerts on privilege escalation, suspicious EFI partition writes. Microsoft Defender for Endpoint has detections for BlackLotus installer hashes (since April 2023).
STEP 02

Deploy vulnerable signed bootloaders to ESP

The attacker writes legitimately Microsoft-signed but vulnerable boot manager binaries (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.
Conditions required:
  • EFI System Partition is writable (always true with admin)
  • DBX revocation for vulnerable bootloaders not applied (default on most enterprise fleets)
Where this breaks in practice:
  • 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)
Detection/coverage: Monitor EFI System Partition (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.
STEP 03

Exploit CVE-2022-21894 via BCD manipulation

On reboot, the manipulated BCD triggers the Baton Drop exploit: the 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.
Conditions required:
  • System reboots with the attacker-controlled BCD active
  • Secure Boot policy not hardened with custom DBX entries
Where this breaks in practice:
  • 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)
Detection/coverage: Windows Event Log 1001/1006 for unexpected boot configuration changes. Check bcdedit /enum all for suspicious entries with truncatememory or testsigning.
STEP 04

Enroll attacker Machine Owner Key (MOK)

The bootkit enrolls a self-signed Machine Owner Key into UEFI NVRAM, establishing firmware-level persistence. On all subsequent boots, the Microsoft UEFI shim trusts the attacker's MOK and loads their malicious .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.
Conditions required:
  • UEFI NVRAM is writable (standard on all modern UEFI implementations)
  • No Secure Boot custom policy blocking MOK enrollment
Where this breaks in practice:
  • Hardware TPM attestation with remote verification (rare outside high-security environments) would detect MOK changes
  • UEFI firmware with MOK enrollment password protection (uncommon)
Detection/coverage: Compare enrolled MOK list against known-good baseline: mokutil --list-enrolled (Linux) or check NVRAM variables. Microsoft's April 2023 blog provides specific forensic indicators for MOK tampering.
STEP 05

Disable OS security stack and establish C2

With firmware-level code execution on every boot, the bootkit disables BitLocker (via WMI 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.
Conditions required:
  • Bootkit successfully loaded via MOK chain
  • Network connectivity for C2 (HTTP/HTTPS to cloud storage providers)
Where this breaks in practice:
  • 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
Detection/coverage: Look for disabled BitLocker protectors (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.
03 · Compensating Control

1
HIGH 7.5→LOW 2.5
SEVERITY REDUCED
Apply KB5025885 DBX revocation with enforcement registry flags — Deploy the KB5025885 update *and* set the registry flag 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.
2
HIGH 7.5→MEDIUM 5.0
SEVERITY REDUCED
Enable firmware-level integrity monitoring on EFI System Partition — Deploy tooling (Eclypsium, Binarly REscan, or custom SCCM/Intune compliance scripts) to hash and monitor all files in \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.
3
HIGH 7.5→MEDIUM 5.5
SEVERITY REDUCED
Audit and baseline MOK enrollment across fleet — Use 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.
4
HIGH 7.5→LOW 2.0
SEVERITY REDUCED
Harden Secure Boot with custom DBX policy — For high-value assets (Domain Controllers, Hyper-V hosts, backup servers), deploy a custom Secure Boot Forbidden Signature Database that explicitly blocks all known vulnerable bootloader hashes, independent of Microsoft's rollout schedule. The NSA mitigation guide provides the specific SHA-256 hashes to revoke. This is the gold-standard control that blocks the exploit at the firmware level. Deploy within 30 days for Tier-0 assets.
5
HIGH 7.5→LOW 1.5
SEVERITY REDUCED
Deploy hardware TPM remote attestation for Tier-0 assets — For Domain Controllers and critical infrastructure, implement TPM-based measured boot with remote attestation (e.g., Microsoft Azure Attestation, or keylime for Linux). This cryptographically verifies the boot chain on every startup and detects any bootkit modification, including Baton Drop. This is the only control that provides detection confidence against firmware-level persistence. Deploy within 30 days for Tier-0 assets.
What doesn't work
  • 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.
04 · Intelligence Metadata

The supporting signals.

In-the-Wild ExploitationConfirmed 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 AvailabilityPublic 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.
EPSS0.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 StatusNot 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 VectorCVSS: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 VersionsAll 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 StatusCode 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 / ExposureNot 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 AdvisoriesNSA 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 / DisclosureOriginal 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.

  1. ESET — BlackLotus UEFI bootkit: Myth confirmed
  2. Microsoft — Guidance for investigating attacks using CVE-2022-21894: The BlackLotus campaign
  3. NSA — BlackLotus Mitigation Guide (CSI U/OO/167397-23)
  4. Kaspersky/SecurityOnline — APT41 Deploys BlackX UEFI Bootkit Against Central Asian Diplomatic Agencies
  5. Binarly — The Untold Story of the BlackLotus UEFI Bootkit
  6. Microsoft — Revoking vulnerable Windows boot managers (KB5025885)
  7. Eclypsium — BlackLotus: A Threat Coming to a System Near You
  8. NVD — CVE-2022-21894
05 · The Call

Final Verdict
↑ UPGRADED to HIGH (7.5/10)

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.

06 · Verification

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.

noisgate-verify.ps1
POWERSHELLREAD-ONLYSAFE
#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 }
}