Detect UEFI Secure Boot bypasses and bootkits such as BlackLotus and Bootkitty by verifying Secure Boot state, checking dbx revocation currency, and hashing EFI boot binaries against known-bad sets using mokutil, efi-readvar/dbxtool, CHIPSEC, sbverify/pesign, and Windows Confirm-SecureBootUEFI. Use when auditing fleet dbx rollout after a bootkit advisory or hunting for pre-OS persistence on a suspected-compromised endpoint.
Detect UEFI Secure Boot bypasses and bootkits such as BlackLotus and Bootkitty by verifying Secure Boot state, checking dbx revocation currency, and hashing EFI boot binaries against known-bad sets using mokutil, efi-readvar/dbxtool, CHIPSEC, sbverify/pesign, and Windows Confirm-SecureBootUEFI. Use when auditing fleet dbx rollout after a bootkit advisory or hunting for pre-OS persistence on a suspected-compromised endpoint.
Legal Notice: Firmware and Secure Boot assessment must only be performed on systems you own or are explicitly authorized to test. CHIPSEC's write/modify modes and EFI variable manipulation can brick hardware. Run destructive checks only in a lab. This skill is for defensive verification and authorized assessment.
Overview
UEFI Secure Boot is the firmware-enforced trust chain that only permits boot components signed by keys in the platform's allow-list (db) and not present in the revocation list (dbx). Bootkits defeat this layer to gain pre-OS, persistent, kernel-level control that survives OS reinstalls and disk wipes. BlackLotus (2023) was the first publicly observed UEFI bootkit to bypass Secure Boot on fully patched Windows 11, abusing CVE-2022-21894 ("baton drop") in a vulnerable, signed Windows boot manager to neutralize Secure Boot and disable BitLocker, HVCI, and Defender. Bootkitty (2024) was the first PoC UEFI bootkit targeting Linux. Microsoft's CVE-2023-24932 addressed a related Secure Boot bypass that required a phased dbx (revocation) rollout because revoking the vulnerable boot managers can render systems unbootable if applied carelessly.
The core defensive insight is that patching the OS is not sufficient — the platform remains exploitable until the vulnerable, signed binaries are revoked in dbx. Detection therefore combines: (1) confirming Secure Boot is actually enabled, (2) verifying dbx is current and contains the relevant revocations, (3) checking the integrity and protection of Secure Boot EFI variables with CHIPSEC, (4) hashing on-disk EFI boot binaries and comparing them against the revocation list and known-bad sets, and (5) inspecting firmware/ESP for bootkit artifacts. This skill provides a cross-platform (Linux + Windows) workflow using mokutil, efi-readvar/dbxtool, chipsec, sbverify/pesign, and Windows Confirm-SecureBootUEFI / Get-SecureBootUEFI.
When to Use
Verifying that an estate's Secure Boot configuration is enabled, locked, and current after the CVE-2023-24932 / BlackLotus advisories.
Hunting for UEFI bootkit indicators on a suspected-compromised endpoint.
Validating that dbx revocations (e.g., vulnerable Windows boot managers, Kaspersky/other vulnerable bootloaders) have actually applied across the fleet.
Auditing firmware integrity and Secure Boot variable protections during a hardware security assessment.
Building a recurring measured/baseline check for boot-chain tampering.
Prerequisites
Root/administrator on the target (firmware reads require privilege).
Adjacent: firmware modification used to persist or weaken Secure Boot.
T1014
Rootkit
Bootkits provide rootkit-level concealment and persistence.
T1562.001
Impair Defenses: Disable or Modify Tools
BlackLotus disables BitLocker/HVCI/Defender after bypassing Secure Boot.
Workflow
1. Confirm Secure Boot state (Linux)
A disabled or setup-mode platform offers no protection.
mokutil --sb-state # "SecureBoot enabled" expected
bootctl status | grep -i "secure boot"# systemd-boot view# 6 = enabled+user mode on the EFI SecureBoot/SetupMode vars:od -An -t u1 /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c
2. Confirm Secure Boot state (Windows)
Confirm-SecureBootUEFI # $true if enabled
# Inspect the raw dbx variable from Windows:
[System.BitConverter]::ToString((Get-SecureBootUEFI dbx).bytes) | Out-File dbx.hex
3. Enumerate the Secure Boot databases
List db (allowed), dbx (revoked), KEK, and PK.
efi-readvar # dumps PK, KEK, db, dbx
efi-readvar -v dbx -o dbx.esl # export dbx to a file for offline analysis
mokutil --list-enrolled # MOK (shim) enrolled keys
mokutil --db # platform db entries via shim
4. Assess dbx freshness and applied revocations
Compare on-system dbx to the current official UEFI revocation list.
dbxtool --list # current dbx entries + count# Download latest dbxupdate from uefi.org/revocationlistfile, then:
dbxtool --dbx ./DBXUpdate.bin --apply --dry-run # show what WOULD be added (no write)
A low dbx entry count or absence of recent revocations indicates the platform is behind and likely still vulnerable to known bypasses.
5. Check Secure Boot variable protection with CHIPSEC
Verify the SB key variables are authenticated and not freely writable.
# Verify Secure Boot is enabled and the SB variables are properly protected:sudo chipsec_main -m common.secureboot.variables
# Check S3 resume boot-script protections (an SMM/firmware bypass vector):sudo chipsec_main -m common.uefi.s3bootscript
# Dump SPI flash for offline firmware diffing:sudo chipsec_util spi dump rom.bin
6. Hash ESP boot binaries and check signatures
Verify bootloaders are signed and not present in dbx.
# Locate and hash EFI boot binaries
find /boot/efi -iname '*.efi' -execsha256sum {} \;
# Validate a binary's signature against the platform db
sbverify --list /boot/efi/EFI/BOOT/bootx64.efi
sbverify --cert /etc/secureboot/db.crt /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi
# pesign equivalent on RHEL-family:
pesign -S -i /boot/efi/EFI/BOOT/bootx64.efi
# Example: confirm a binary's SHA-256 is NOT one of the revoked CVE-2022-21894 boot managerssha256sum /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi
# Compare against the hash list extracted from the latest dbxupdate / advisory.
8. Inspect for bootkit artifacts
Look for unauthorized ESP modifications and self-deployment markers.
# Unexpected files / recently modified binaries on the ESPls -laR /boot/efi/EFI/
find /boot/efi -newermt "-30 days" -iname '*.efi'# On Windows, examine the EFI partition for rogue \EFI\Microsoft\Boot entries.
