Windows - Security - Mitigate BlackLotus

What the BlackLotus mitigation Worklet does

This Automox Worklet™ applies Microsoft's recommended revocation steps to protect against the BlackLotus UEFI bootkit (CVE-2023-24932). BlackLotus can bypass Secure Boot protections and persist even after operating system reinstallation, making it one of the most severe boot-level threats.

The Worklet mounts the EFI system partition and copies the SKUSiPolicy.p7b revocation file from the Windows Security Updates location. It then configures the AvailableUpdates registry value under HKLM:\SYSTEM\CurrentControlSet\Control\Secureboot to enable the Secure Boot Dbx update.

The Worklet examines registry keys including HKLM:\SYSTEM\CurrentControlSet\Control\Secureboot. p7b".

After applying the mitigation, the Worklet triggers an automatic restart with a 60-second warning. Microsoft requires a second restart to finalize the revocation steps, which must be performed separately through another Worklet or manual intervention.

Why protect against BlackLotus

BlackLotus operates below the operating system at the firmware level, making it invisible to traditional antivirus and EDR solutions. When this UEFI bootkit infects an endpoint, it persists across OS reinstalls, disk formatting, and even hard drive replacement because it resides in the EFI system partition. Attackers use BlackLotus to disable security features like BitLocker and Windows Defender, establish persistent backdoors, and maintain command-and-control access that survives complete system wipes.

The vulnerability allows attackers to bypass Secure Boot, disable Windows security features like BitLocker and Windows Defender, and maintain persistence across system reinstalls. Only applying the revocation files can protect endpoints from this attack vector.

Important warning: Once applied, this mitigation cannot be reversed on Secure Boot-enabled endpoints. Even reformatting the disk does not remove the revocations. Test thoroughly before deployment and do not remove the SKUSiPolicy.p7b file after deployment, as this may prevent the endpoint from booting.

How BlackLotus mitigation works

1. Evaluation phase: The Worklet runs Confirm-SecureBootUEFI to verify Secure Boot is enabled. It checks for the revocation payload at C:\Windows\System32\SecureBootUpdates\SKUSiPolicy.p7b (requires May 2023 updates). It searches the System Event Log for Secure Boot Dbx update events and mounts the EFI partition to check for existing revocation files. Endpoints already mitigated or not in scope exit without changes.

2. Remediation phase: The Worklet mounts the EFI partition to Q:, copies SKUSiPolicy.p7b to Q:\EFI\Microsoft\Boot\, and sets the registry key HKLM:\SYSTEM\CurrentControlSet\Control\Secureboot\AvailableUpdates to value 10 (enabling the Secure Boot UEFI Forbidden List). The endpoint receives a restart command with 60-second delay.

BlackLotus mitigation requirements

• Windows 10 or Windows 11, Windows Server with UEFI Secure Boot enabled

• May 2023 Security Updates (KB5025885) installed

• Revocation payload present at C:\Windows\System32\SecureBootUpdates\SKUSiPolicy.p7b

• Administrative privileges to mount EFI partition and modify registry

• Disable automatic restart in the Worklet policy (Worklet handles restart)

• Second restart required to finalize (not triggered by this Worklet)

Expected BlackLotus protection state

After completing both required restarts, the endpoint has protection against BlackLotus through Secure Boot revocations. The SKUSiPolicy.p7b file exists at Q:\EFI\Microsoft\Boot\, and the System Event Log contains entries confirming successful Secure Boot Dbx update.

Verification: Mount the EFI partition using mountvol Q: /S and verify SKUSiPolicy.p7b exists at Q:\EFI\Microsoft\Boot\. Check the System Event Log for Event ID 3040 from source Microsoft-Windows-SecureBoot, which indicates Secure Boot Dbx update success. Run the Worklet again to confirm compliant status. Endpoints without Secure Boot enabled or missing the May 2023 updates are marked out of scope and exit cleanly.

How to validate mitigate blacklotus changes

1. Run this Worklet on a pilot Windows endpoint and review evaluation output for mitigate blacklotus.

2. Confirm Automox activity logs show successful completion and exit code 0.

3. Verify endpoint state using checks aligned to evaluation script logic, such as Get-DeviceEligibility, Get-MitigationEvent, Initialize-Migitation.

4. Validate remediation effects from script operations such as Get-DeviceEligibility, Get-MitigationEvent, Initialize-Migitation, then rerun evaluation for compliance.