Windows - Security - Mitigate BlackLotus

What the BlackLotus mitigation Worklet does

This Automox Worklet™ applies Microsoft's Secure Boot revocation steps (KB5025885, tracked as CVE-2023-24932) that block the BlackLotus UEFI bootkit on Windows endpoints. BlackLotus weaponizes the Baton Drop flaw (CVE-2022-21894) in older Windows boot loaders to bypass Secure Boot, then installs itself in the EFI system partition where it survives operating system reinstalls and disk replacements.

The Worklet mounts the EFI system partition to drive letter Q:, copies the SKUSiPolicy.p7b revocation file from C:\Windows\System32\SecureBootUpdates\ to Q:\EFI\Microsoft\Boot\, and writes the AvailableUpdates value under HKLM:\SYSTEM\CurrentControlSet\Control\Secureboot. That registry flag tells the firmware to write the new vulnerable boot loader hashes into the Secure Boot DBX (Forbidden Signatures Database) at the next boot.

After staging the payload, the Worklet schedules a restart with a 60-second warning. Microsoft's guidance for KB5025885 requires a second restart to finalize the DBX commit; that restart is intentionally left to a follow-up policy or a manual reboot so administrators control the maintenance window.

Why mitigate BlackLotus across the fleet

BlackLotus runs before the operating system loads, which means traditional antivirus and EDR agents cannot see it. A standard OS-volume wipe leaves it intact because the bootkit lives in the EFI system partition; removing it requires reformatting the EFI partition or applying the Secure Boot DBX revocations this Worklet stages. The bootkit disables BitLocker, Hypervisor-protected Code Integrity (HVCI), and Windows Defender from below the kernel, then establishes a persistent foothold in the EFI partition. The only durable fix is to revoke the vulnerable boot loaders themselves by updating the Secure Boot DBX, which is what KB5025885 stages and what this Worklet activates.

CVE-2022-21894 (Baton Drop) is the original Secure Boot bypass that enabled the BlackLotus UEFI bootkit, the first publicly documented bootkit to run on patched Windows 11. Microsoft tracks the revocation rollout itself as CVE-2023-24932 and ships the payload in KB5025885. Boot-level DBX revocations cannot be rolled back, so the apply step has to be auditable, gated by evaluation checks, and consistent across every UEFI endpoint in scope. This Worklet writes the Microsoft-published Secure Boot DBX revocations on every Windows endpoint in scope and verifies the revocation took effect on each evaluation pass.

Important warning: once the DBX revocations commit, they cannot be reversed on a Secure Boot-enabled endpoint. Reformatting the disk does not remove the revocations. Older Windows recovery media and unsigned boot loaders will stop booting after this Worklet completes both restarts, so confirm your recovery and imaging media are updated before deployment.

How BlackLotus DBX revocation works

1. Evaluation phase: The Worklet runs Confirm-SecureBootUEFI to verify Secure Boot is enabled and checks for the revocation payload at C:\Windows\System32\SecureBootUpdates\SKUSiPolicy.p7b, which is staged by KB5025885. It searches the System event log for messages matching "Secure Boot Dbx update applied successfully" to detect a prior DBX commit. When prior events are present, it mounts the EFI partition to Q: with mountvol and looks for an existing Q:\EFI\Microsoft\Boot\SKUSiPolicy.p7b. Endpoints that are not UEFI, do not have Secure Boot enabled, are missing the May 2023 update, or already show a successful DBX update exit cleanly as out of scope.

2. Remediation phase: The Worklet mounts the EFI partition to Q:, copies SKUSiPolicy.p7b into Q:\EFI\Microsoft\Boot\, and writes the AvailableUpdates value under HKLM:\SYSTEM\CurrentControlSet\Control\Secureboot using Set-ItemProperty. Microsoft's documented value for AvailableUpdates is 0x10 (REG_DWORD) to enable the Secure Boot UEFI Forbidden List update on the next boot. The endpoint then receives a shutdown /r /t 60 restart with a user-visible warning. A second restart, applied through a follow-up policy or a normal maintenance reboot, finalizes the DBX commit and locks the revocations into firmware.

BlackLotus mitigation requirements

• UEFI firmware with Secure Boot enabled. Legacy BIOS and CSM-only endpoints are not in scope and exit cleanly.

• Windows 10, Windows 11, or Windows Server with the May 2023 cumulative update (KB5025885) installed so the SKUSiPolicy.p7b revocation payload is staged on disk.

• Revocation payload present at C:\Windows\System32\SecureBootUpdates\SKUSiPolicy.p7b. The Worklet does not download the file; it copies what KB5025885 provided.

• Administrative privileges so the Automox agent can mount the EFI system partition with mountvol and write to HKLM:\SYSTEM\CurrentControlSet\Control\Secureboot.

• Restart settings configured to allow the Worklet's scheduled reboot. Disable the automatic post-Worklet restart in the policy, because the script handles the first restart itself.

• Updated recovery and imaging media. Older Windows installation media that uses revoked boot loaders will fail Secure Boot after both restarts complete.

• A second restart, applied separately, to commit the DBX update to firmware.

Expected Secure Boot DBX state after remediation

After both restarts complete, the endpoint enforces the updated Secure Boot DBX and refuses to load any of the vulnerable boot loaders BlackLotus relies on for CVE-2022-21894. SKUSiPolicy.p7b is present at Q:\EFI\Microsoft\Boot\, and the System event log records a "Secure Boot Dbx update applied successfully" message from the SecureBoot source. A subsequent Worklet evaluation marks the endpoint compliant and takes no further action.

Verification: Mount the EFI partition with mountvol Q: /S and confirm SKUSiPolicy.p7b exists under Q:\EFI\Microsoft\Boot\. Run Confirm-SecureBootUEFI in PowerShell to confirm Secure Boot remains enabled. Filter the System event log for the DBX commit message the evaluation script looks for using Get-EventLog -LogName System | Where-Object { $_.Message -like '*Secure Boot Dbx update applied successfully*' } to confirm the DBX commit. Re-run the Worklet to confirm a compliant exit. Endpoints reporting out of scope typically lack Secure Boot, run legacy BIOS, or are missing KB5025885.

If you also manage Linux endpoints with shim-based Secure Boot, the parallel operation is a mokutil --import of the corresponding DBX update; that work belongs to a separate Linux Worklet and is out of scope here.