Chapter 198

Bootkit and UEFI Malware

UEFI bootkits are the highest tier of persistence: they execute before the OS loader, before Secure Boot enforcement (if bypassed), before any security software, and survive OS reinstalls because they live in the EFI System Partition or the UEFI firmware flash. BlackLotus (2022–2023) was the first public in-the-wild UEFI bootkit targeting Windows 11 with Secure Boot bypass, proving that this class of threat has moved from nation-state toolkits to crimeware. Detection requires firmware integrity monitoring and ESP file auditing.

Scenario

You need persistence on a target that gets its OS reimaged quarterly by IT. A standard registry or scheduled task persistence won't survive the reimage. You need an implant that survives OS reinstallation, executes before Windows Security Center initializes, and can disable Secure Boot verification of the OS bootloader — enabling permanent kernel-level control across re-images.

UEFI Boot Chain

WINDOWS SECURE BOOT CHAIN ═══════════════════════════════════════════════════════════════════════ Power On │ ▼ UEFI Firmware (in SPI flash) │ verifies → bootloader signature against db/dbx in NVRAM ▼ EFI\Microsoft\Boot\bootmgfw.efi ← on EFI System Partition (ESP) │ Windows Boot Manager │ verifies → winload.efi signature (Microsoft Secure Boot CA) ▼ winload.efi → loads kernel (ntoskrnl.exe) + boot drivers │ Kernel verifies driver signatures (DSE) ▼ ntoskrnl.exe → KPP, HVCI, VBS, EDR minifilter loads BOOTKIT INSERTION POINTS: [A] Replace bootmgfw.efi on ESP (requires boot-order UEFI override or direct write) [B] Add malicious EFI application to boot entry list in NVRAM [C] Flash malicious UEFI module to SPI flash (survives ESP format) [D] Exploit UEFI firmware bug to run unsigned EFI code before Secure Boot check ═══════════════════════════════════════════════════════════════════════

BlackLotus Analysis

BLACKLOTUS (CVE-2022-21894 — "Baton Drop") ═══════════════════════════════════════════════════════════════════════ Vulnerability: bootmgr.efi < Jan 2022 can be placed on ESP and will be trusted by Secure Boot (Microsoft's certificate had not revoked the old bootloader via DBX update on all systems at time of discovery) Attack chain: 1. Write old (vulnerable) bootmgfw.efi to ESP (signed → passes Secure Boot) 2. Old bootmgr loads without verifying its own code integrity properly 3. Old bootmgr → loads BlackLotus UEFI module from ESP 4. BlackLotus patches HVCI (disables hypervisor code integrity) 5. Loads unsigned kernel driver → full Ring 0 control 6. Deploys user-mode HTTP downloader (httprecon.exe equivalent) Persistence: BlackLotus files on EFI System Partition: /EFI/Microsoft/Boot/bootmgfw.efi (replaced with old vulnerable copy) /EFI/Microsoft/Boot/grub (BlackLotus module directory) /EFI/Microsoft/Boot/grub/grubx64.efi (main UEFI bootkit) Detection: BCDEdit shows unusual boot entries; ESP audit finds extra files. ═══════════════════════════════════════════════════════════════════════

ESP File Implant

// The EFI System Partition (ESP) is typically mounted at hidden/locked path.
// An attacker with SYSTEM access can mount it, modify files, and unmount.
// Modifying bootmgfw.efi or adding a new boot entry requires the EFI partition
// to be mounted — normally it is not; Windows mounts it only during update.

// Mount ESP (requires admin, works without driver):
// mountvol X: /s   → mounts ESP at X:\
// After mount: ESP is at X:\EFI\Microsoft\Boot\

VOID MountESP(WCHAR driveLetter) {
    WCHAR cmd[64];
    swprintf_s(cmd, L"mountvol %c: /s", driveLetter);
    ShellExecuteW(NULL, L"open", L"cmd.exe",
        cmd, NULL, SW_HIDE);
}

// Malicious EFI application (.efi = PE with EFI subsystem) written to ESP:
// X:\EFI\Backdoor\loader.efi
// Add boot entry: bcdedit /copy {bootmgr} /d "System Recovery"
// Modify entry to point to loader.efi via UEFI NVRAM (requires privileged NVRAM write)

// Add UEFI NVRAM boot entry from Win32 (SetFirmwareEnvironmentVariableExW):
BOOL AddUEFIBootEntry(LPCWSTR efiPath) {
    // Build EFI_LOAD_OPTION structure
    // Variable name: "Boot####" where #### is next available hex number
    // Requires SE_SYSTEM_ENVIRONMENT_PRIVILEGE
    LUID luid;
    LookupPrivilegeValueW(NULL, SE_SYSTEM_ENVIRONMENT_NAME, &luid);
    TOKEN_PRIVILEGES tp = {1, {{luid, SE_PRIVILEGE_ENABLED}}};
    HANDLE hTok;
    OpenProcessToken(GetCurrentProcess(), TOKEN_ADJUST_PRIVILEGES, &hTok);
    AdjustTokenPrivileges(hTok, FALSE, &tp, 0, NULL, NULL);

    // SetFirmwareEnvironmentVariableExW("Boot0002",
    //   "{8be4df61-93ca-11d2-aa0d-00e098032b8c}",
    //   efiLoadOptionBytes, cbBytes, VARIABLE_ATTRIBUTE_NON_VOLATILE | ...)
    return TRUE;  // Full EFI_LOAD_OPTION construction: see UEFI spec section 3.1.3
}

Secure Boot Bypass Techniques

TechniqueRoot causePatched?Example
Un-revoked bootloader replayOld signed bootloader not in DBXPartially — requires DBX update pushed to all systemsBlackLotus CVE-2022-21894
UEFI firmware vulnerabilityParsing bug in UEFI code before Secure Boot checkPer-vendor fix, often unpatched on older hardwareLogoFAIL (2023) — image parsing in UEFI DXE
Secure Boot policy bypassCustom policy allows test-signed code via EFI policy variablePatched (MS15-006) but policy files still circulateEquation Group "DoubleAgent"
Physical SPI flash writePhysical access to SPI chipNot software-patchableEvil Maid attacks
UEFI update mechanism abuseVendor UEFI update executed in OS; insufficient signature checkVendor-specificThinkPwn, AMI modules

Detection Engineering

title: EFI System Partition Write — Unexpected Process Writing ESP Files
logsource:
  product: windows
  category: file_event
detection:
  selection:
    EventID: 11  # Sysmon FileCreate
    TargetFilename|contains: '\EFI\'
  not_legit:
    Image|endswith:
      - '\TrustedInstaller.exe'
      - '\wuauclt.exe'
      - '\svchost.exe'
  condition: selection and not not_legit
level: critical
tags: [attack.persistence, T1542.003]

title: mountvol Used to Mount EFI Partition
logsource:
  product: windows
  category: process_creation
detection:
  selection:
    Image|endswith: '\mountvol.exe'
    CommandLine|contains: '/s'
  condition: selection
level: high

title: UEFI NVRAM Write — SetFirmwareEnvironmentVariable
logsource:
  product: windows
  category: process_access
detection:
  selection:
    EventID: 10
    CallTrace|contains: 'SetFirmwareEnvironmentVariable'
  condition: selection
level: critical

-- MDE KQL: ESP write or mountvol to hidden EFI partition
DeviceProcessEvents
| where Timestamp > ago(1d)
| where FileName =~ "mountvol.exe"
| where ProcessCommandLine has "/s"
| project Timestamp, DeviceName, AccountName,
    InitiatingProcessFileName, ProcessCommandLine

DeviceFileEvents
| where Timestamp > ago(1d)
| where FolderPath has @"\EFI\"
| where ActionType in ("FileCreated","FileModified")
| where InitiatingProcessFileName !in~ (
    "TrustedInstaller.exe","WinStore.App.exe","svchost.exe")
| project Timestamp, DeviceName, FileName, FolderPath,
    InitiatingProcessFileName, InitiatingProcessCommandLine

-- Firmware integrity: compare ESP bootmgfw.efi SHA256 against known-good
-- PowerShell (scheduled task or Defender AV scan at boot):
-- $hash = Get-FileHash "X:\EFI\Microsoft\Boot\bootmgfw.efi" -Algorithm SHA256
-- if ($hash.Hash -ne "KNOWN_GOOD_HASH") { Alert-SOC "ESP bootloader modified" }

Q&A

If an organization fully patches all systems (DBX updated, firmware patched), what detection controls give the best coverage against UEFI bootkit activity, and why is network-level telemetry specifically important for this threat class?

After patching, the remaining detection controls in order of reliability: (1) ESP integrity monitoring: schedule a hash comparison of all files on the EFI System Partition against a known-good baseline captured right after OS installation. Any new or modified EFI file is anomalous. This can be implemented as a scheduled task that runs at boot before the OS fully loads, or via Microsoft Defender for Endpoint's tamper protection alerts for boot-time file changes. Limitation: if the bootkit loads before Windows, it may intercept and fake the file read. (2) UEFI Secure Boot log (TPM measured boot): modern systems with TPM 2.0 record a cryptographic measurement of every component loaded during boot in the TPM's Platform Configuration Registers (PCRs). If the bootkit modified bootmgfw.efi, PCR[4] will differ from the expected value. Remote Attestation (via Microsoft Azure Attestation or Intune device compliance) can compare PCR values against policy — a mismatch flags a compromised boot chain. This is currently the most reliable control because the TPM measurement happens in hardware before any software can lie. (3) Event Tracing for Windows (ETW) boot events: Windows logs Secure Boot validation failures in the System event log (EventID 1795, BootTrigger). (4) Network telemetry: UEFI bootkits typically need to fetch payloads or communicate with C2. BlackLotus deployed an HTTP downloader that contacted its C2 from within the UEFI context before the OS started — but this traffic still traverses the network and appears in firewall/proxy logs and NDR. Network-level telemetry is specifically valuable because: the UEFI/bootkit environment has no host-based EDR, no kernel-level hooks, and no Defender — the only visibility layer that functions before OS boot is the network. An unusual HTTP connection at 3 AM during a reboot cycle, from a machine that normally only contacts Windows Update servers, to an unknown IP, is a detectable anomaly in network logs even if every host-based sensor is blind.