Detecting Secure Boot Bypass

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).
• Linux tooling:

  sudo apt install mokutil efitools sbsigntool dbxtool      # Debian/Ubuntu
  sudo dnf install mokutil efitools sbsigntools dbxtool     # Fedora/RHEL
  

• CHIPSEC (run from a live USB or controlled host; loads a kernel driver):

  pip install chipsec        # or build from https://github.com/chipsec/chipsec
  

• Windows tooling: PowerShell (built-in Confirm-SecureBootUEFI, Get-SecureBootUEFI), and optionally the UEFI dbx update package from Microsoft.
• The current dbxupdate files from https://uefi.org/revocationlistfile to compare against.

Objectives

• Confirm Secure Boot is enabled and in user (not setup) mode.
• Enumerate db, dbx, KEK, and PK contents and assess freshness of dbx.
• Verify the relevant CVE revocations are present in dbx.
• Validate Secure Boot EFI variables are authenticated and protected (CHIPSEC).
• Hash ESP boot binaries and check them against dbx and known-bad hash sets.
• Identify bootkit artifacts and report exploitable gaps with remediation.

MITRE ATT&CK Mapping

Workflow

1. Confirm Secure Boot state (Linux)

A disabled or setup-mode platform offers no protection.

…