Every incident response framework assumes at some point that reimaging a compromised machine returns it to a known-good state. Firmware rootkits invalidate this assumption entirely. When malware lives in the SPI flash on the motherboard — below the operating system, below the bootloader, below any software security control — no OS-level remediation is sufficient. The infection survives a Windows reinstall, a Linux install over Windows, a full drive replacement, and even a BitLocker wipe. The only remediation is reflashing the firmware from a trusted image or replacing the motherboard.

This threat is no longer theoretical. Four distinct firmware-level malware families have been documented in active use by nation-state actors between 2018 and 2023, with capabilities escalating from simple persistence to Secure Boot bypass on fully patched Windows 11 systems.

The UEFI Attack Surface

SPI Flash and the Firmware Stack

Modern PC firmware (UEFI) is stored on a Serial Peripheral Interface (SPI) flash chip — a small non-volatile memory component soldered to the motherboard. The SPI flash is divided into regions with different access permissions enforced by the Platform Controller Hub (PCH):

RegionContentsAccess
Flash DescriptorRegion layout, access permissionsRead by all
BIOS RegionUEFI firmware modules, NVRAMCPU (restricted writes)
ME RegionIntel Management Engine firmwareME only
GbE RegionGigabit Ethernet configurationCPU read
PDR RegionPlatform dataCPU read

Under normal operation, the BIOS region write protection is enforced by the BIOS Write Protect (BIOSWE) bit and Protected Range Registers (PRR). An attacker with SYSTEM-level OS privileges can sometimes bypass these protections:

  1. Directly via vulnerable UEFI update mechanisms (drivers or EFI modules that disable write protection)
  2. Via vulnerable UEFI/BIOS update utilities provided by motherboard vendors
  3. Via Intel Management Engine vulnerabilities that permit SPI flash access
  4. Via physical access (SPI flash programmer — CH341A and similar hardware)

The UEFI Boot Chain

Understanding where firmware implants live requires understanding the boot sequence:

  1. SEC phase — Security initialization, CPU cache-as-RAM setup
  2. PEI phase — Pre-EFI Initialization, memory controller init, board initialization
  3. DXE phase — Driver Execution Environment — UEFI drivers load, hardware initialization
  4. BDS phase — Boot Device Selection — selects the boot target
  5. OS Bootloader — Windows Boot Manager, GRUB, etc.
  6. OS Kernel — Windows NT kernel, Linux kernel
  7. OS Userspace

Firmware rootkits typically insert malicious modules in the DXE phase, where they run with full hardware access before any OS-level security controls are active. They can patch boot components, disable Secure Boot validation, or install hooks that persist into the OS environment.

LoJax — The First UEFI Rootkit in the Wild (2018)

Discovery: ESET researchers published their analysis in September 2018 after investigating APT28 (Fancy Bear, Russian GRU Unit 26165) intrusions across Eastern European targets.

Technical architecture:

LoJax is derived from modified LoJack (formerly Computrace) firmware — legitimate anti-theft software from Absolute Software that installs a small UEFI module to survive reimaging. APT28 repurposed this concept for malicious persistence.

The LoJax attack toolkit consists of three components:

  1. SPI flash reader: Reads and dumps the existing UEFI firmware from SPI flash
  2. UEFI modifier: Patches the dumped firmware image to insert a malicious DXE driver
  3. SPI flash writer: Reflashes the modified firmware image to the SPI chip

The malicious DXE module (the implant itself) runs during the DXE phase on every boot. It drops a Windows user-mode payload to disk and executes it, providing persistent access even after OS reinstallation.

Write protection bypass: LoJax exploited systems where the BIOS write protect bits (BIOSWE in the BC register, and PRRs) were not properly configured — a condition common on older consumer and business laptops. On protected systems, the SPI flash writer component failed, suggesting APT28 selectively deployed LoJax only against vulnerable targets.

Detection at the time: Antivirus tools at the time had no capability to scan SPI flash contents. ESET’s detection relied on identifying the known-malicious UEFI module hash within firmware dumps obtained via chipsec.

MoonBounce — Winnti Group (2022)

Discovery: Kaspersky published analysis in January 2022 after identifying MoonBounce in an investigation of Winnti Group (also tracked as APT41, BARIUM) operations.

Key technical advancement over LoJax:

LoJax added a new DXE driver to the firmware image. MoonBounce modified an existing UEFI component — specifically hooks within the CORE_DXE firmware module. This approach is significantly more subtle: the total number of firmware modules does not change, making basic “count the modules” detection methods ineffective.

MoonBounce hooks three DXE functions:

  • AllocatePool: Modifies memory allocation to redirect execution
  • CreateEventEx: Hooks event handling to ensure execution at the right phase
  • ExitBootServices: Hooks the OS handoff to inject into the kernel boot process

The implant’s payload is stored in NVRAM variables (non-volatile UEFI storage) rather than as a separate firmware module, further complicating detection. Once the OS begins loading, MoonBounce injects shellcode into the Windows kernel image in memory, which then downloads the next-stage payload from a C2 server.

Attribution: Kaspersky attributed MoonBounce to the Winnti umbrella based on C2 infrastructure and code overlaps with other Winnti tooling including ShadowPad.

CosmicStrand — Origins Uncertain (2022)

Discovery: Kaspersky published analysis in July 2022. The malware had been circulating since at least 2016 based on C2 infrastructure analysis, making it one of the longest-undetected firmware implants known.

Targeting: Consumer-grade Gigabyte and ASUS motherboards, primarily targeting individuals in China, Vietnam, Iran, and Russia — suggesting either cyber-espionage against dissidents or an unknown criminal operation.

Technical approach:

CosmicStrand modifies the CSMCORE DXE driver, which handles compatibility support module (legacy BIOS emulation) initialization. Its hook chain:

  1. Hooks within CSMCORE modify a pointer to execute attacker code
  2. Sets up a hook on the SetupEntryPoint function
  3. Eventually hooks the OS loader in memory
  4. Injects a kernel shellcode payload into the Windows boot process
  5. The kernel shellcode connects to a C2 server to download and execute the final implant

What distinguished CosmicStrand was its apparent focus on consumer hardware — implying either a supply chain compromise (malicious firmware pre-installed on motherboards) or remote delivery via a compromised update mechanism.

BlackLotus — First UEFI Bootkit Bypassing Secure Boot on Windows 11 (2023)

Discovery: ESET published analysis in March 2023. BlackLotus had been advertised on underground forums since October 2022 for approximately $5,000.

CVE: CVE-2022-21894 (CVSS 8.4) — “Baton Drop” — a Secure Boot Security Feature Bypass vulnerability in the Windows Boot Manager.

Technical mechanism:

BlackLotus is technically a bootkit (targets EFI System Partition files) rather than a firmware rootkit (targets SPI flash). However, its Secure Boot bypass capability places it in a different threat category from conventional bootkits.

The attack exploits the fact that the UEFI Secure Boot DB (allowed signatures database) contains valid signatures for all versions of bootmgfw.efi (Windows Boot Manager) that Microsoft has ever released. Including versions with known vulnerabilities.

Attack flow:

  1. BlackLotus is installed with administrator privileges on a running Windows system
  2. It copies a specifically vulnerable version of bootmgfw.efi (signed legitimately by Microsoft) to the EFI System Partition
  3. On the next boot, UEFI Secure Boot validates the boot manager signature — which is valid, because it’s genuinely signed by Microsoft
  4. The vulnerable boot manager is exploited (CVE-2022-21894) to disable Secure Boot policy enforcement
  5. BlackLotus’s own unsigned bootloader executes without Secure Boot verification
  6. An HVCI (Hypervisor-Protected Code Integrity) bypass allows loading an unsigned kernel driver
  7. A user-mode component provides HTTP C2 communication and payload execution

Why Secure Boot revocation is complex: Microsoft could revoke the vulnerable boot manager via the UEFI Secure Boot DB Forbidden List (dbx). However, doing so would break Windows installations that haven’t been updated to replace the vulnerable boot manager with a patched version — a chicken-and-egg problem for organizations with offline or rarely updated systems. Microsoft issued the full dbx update in May 2023 (KB5025885), but deployment has been intentionally slow to avoid breaking systems.

Detection note: BlackLotus stores components in \EFI\Microsoft\Boot\ and creates a hidden volume mount. Legitimate files in that directory with unexpected sizes or dates are indicators of compromise.

Detection

CHIPSEC Firmware Analysis

CHIPSEC (Intel’s open-source platform security assessment framework) is the primary tool for firmware integrity analysis.

 1# Install CHIPSEC (Linux — requires kernel module build)
 2git clone https://github.com/chipsec/chipsec
 3cd chipsec
 4pip install .
 5
 6# Load kernel driver (required for hardware access)
 7sudo python chipsec_main.py
 8
 9# Dump SPI flash to file for analysis
10sudo python chipsec_util.py spi dump firmware.bin
11
12# Analyze UEFI firmware structure
13sudo python chipsec_util.py uefi decode firmware.bin
14
15# Check UEFI firmware for known vulnerabilities
16sudo python chipsec_main.py -m common.bios_smi        # BIOS SMI Handler check
17sudo python chipsec_main.py -m common.bios_wp          # BIOS write protection
18sudo python chipsec_main.py -m common.bios_ts          # BIOS lock (top-swap)
19sudo python chipsec_main.py -m common.secureboot.variables  # Secure Boot variable check
20sudo python chipsec_main.py -m common.uefi.s3bootscript    # S3 Boot Script checks
21
22# Run full test suite
23sudo python chipsec_main.py --ignore_platform
24
25# Compare firmware dump against known-good baseline
26# (Requires previously captured clean firmware image)
27sudo python chipsec_util.py spi dump current_firmware.bin
28diff <(python chipsec_util.py uefi decode baseline_firmware.bin 2>/dev/null) \
29     <(python chipsec_util.py uefi decode current_firmware.bin 2>/dev/null)

 1#!/usr/bin/env python3
 2"""
 3uefi_module_audit.py — Parse UEFI firmware dump and enumerate all DXE drivers
 4Compare against a whitelist of expected modules to detect unauthorized additions.
 5Uses the uefi-firmware-parser library.
 6"""
 7import uefi_firmware
 8import hashlib
 9import json
10import sys
11
12KNOWN_GOOD_HASHES_FILE = "baseline_module_hashes.json"
13
14def enumerate_modules(firmware_path):
15    with open(firmware_path, 'rb') as f:
16        data = f.read()
17
18    parser = uefi_firmware.AutoParser(data)
19    parsed = parser.parse()
20
21    modules = {}
22    if parsed:
23        for obj in parsed.iterate_objects():
24            if hasattr(obj, 'data') and obj.data:
25                h = hashlib.sha256(obj.data).hexdigest()
26                name = getattr(obj, 'name', 'unknown')
27                guid = getattr(obj, 'guid', 'unknown')
28                modules[str(guid)] = {
29                    "name": name,
30                    "sha256": h,
31                    "size": len(obj.data)
32                }
33    return modules
34
35def compare_with_baseline(current_modules, baseline_path):
36    with open(baseline_path) as f:
37        baseline = json.load(f)
38
39    added = set(current_modules.keys()) - set(baseline.keys())
40    removed = set(baseline.keys()) - set(current_modules.keys())
41    modified = {
42        guid for guid in set(current_modules.keys()) & set(baseline.keys())
43        if current_modules[guid]['sha256'] != baseline[guid]['sha256']
44    }
45
46    if added:
47        print(f"[ALERT] New modules found (not in baseline):")
48        for guid in added:
49            print(f"  GUID={guid} name={current_modules[guid]['name']} "
50                  f"sha256={current_modules[guid]['sha256']}")
51
52    if modified:
53        print(f"[ALERT] Modified modules (hash mismatch):")
54        for guid in modified:
55            print(f"  GUID={guid} name={current_modules[guid]['name']}")
56            print(f"    baseline: {baseline[guid]['sha256']}")
57            print(f"    current:  {current_modules[guid]['sha256']}")
58
59    if not added and not modified:
60        print("[OK] No unauthorized firmware modifications detected.")
61
62if __name__ == "__main__":
63    current = enumerate_modules(sys.argv[1])
64    compare_with_baseline(current, KNOWN_GOOD_HASHES_FILE)

CHIPSEC SPI Flash Region Analysis

 1# Check SPI flash write protection status
 2# Critical: BIOS region should have write protection enabled
 3sudo python chipsec_util.py spi info
 4
 5# Expected output should show:
 6# [*] SPI Flash Region Access Permissions
 7# BIOS region: BLOCKED (write protected)
 8# If BIOS region writes are NOT blocked, firmware can be modified by OS software
 9
10# Check Protected Range Registers
11sudo python chipsec_main.py -m common.bios_wp
12
13# Check if SPI flash descriptor write protection is enabled
14# FLOCKDN bit in HSFS register should be 1
15sudo python chipsec_util.py mmio SPIBAR
16
17# Read specific SPI flash regions
18sudo python chipsec_util.py spi read 0x0 0x1000 descriptor_region.bin  # Flash descriptor

Secure Boot Validation

 1# Windows — Check Secure Boot status
 2Confirm-SecureBootUEFI
 3
 4# Check Secure Boot databases
 5# DB (allowed), DBX (forbidden), KEK (key exchange key), PK (platform key)
 6$secureBootVars = @('PK', 'KEK', 'db', 'dbx')
 7foreach ($var in $secureBootVars) {
 8    $val = Get-SecureBootUEFI -Name $var -ErrorAction SilentlyContinue
 9    if ($val) {
10        Write-Host "$var is present (size: $($val.Bytes.Length) bytes)"
11    } else {
12        Write-Host "$var is NOT present"
13    }
14}
15
16# Check Windows Secure Boot policy
17Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\State" |
18  Select-Object UEFISecureBootEnabled, SecureBootCapable
19
20# Detect BlackLotus indicators on EFI System Partition
21# Mount ESP (if not already mounted as S:)
22mountvol S: /S
23
24# Check for suspicious files in EFI boot directory
25Get-ChildItem -Path "S:\EFI\Microsoft\Boot\" | Sort-Object LastWriteTime -Descending
26
27# BlackLotus indicator: bootkitx64.efi or unexpected .efi files
28# Also check for hidden volume mounts
29Get-WmiObject -Class Win32_Volume | Where-Object { $_.DeviceID -like "*\\?\Volume*" }

TPM Attestation for Boot Integrity

 1# Linux — Read TPM PCR values (PCR0 = firmware measurement)
 2# tpm2-tools required
 3tpm2_pcrread sha256:0,1,2,3,4,5,6,7
 4
 5# PCR0: BIOS/UEFI firmware
 6# PCR1: BIOS/UEFI configuration
 7# PCR4: Boot Manager
 8# PCR7: Secure Boot state
 9
10# Compare current PCR0 against known-good baseline
11CURRENT_PCR0=$(tpm2_pcrread sha256:0 --output=- | xxd -p | tr -d '\n')
12BASELINE_PCR0="<your_baseline_value_here>"
13
14if [ "$CURRENT_PCR0" != "$BASELINE_PCR0" ]; then
15    echo "ALERT: PCR0 mismatch — firmware may have been modified"
16    echo "Current:  $CURRENT_PCR0"
17    echo "Baseline: $BASELINE_PCR0"
18fi
19
20# Create a sealed TPM quote for remote attestation
21# Generate attestation key
22tpm2_createak -C 0x81000000 -c ak.ctx -u ak.pub -r ak.priv
23
24# Create a quote (signed attestation of PCR values)
25tpm2_quote -c ak.ctx -l sha256:0,1,2,4,7 \
26  -q $(openssl rand -hex 20) \  # Nonce from verifier
27  -m quote.msg -s quote.sig -o pcrs.out
28
29# The quote can be sent to a remote verifier who validates:
30# 1. The signature is from a valid AIK (Attestation Identity Key)
31# 2. The PCR values match expected baseline
32# 3. The nonce prevents replay attacks

Windows Event Log — Secure Boot Violations

 1# Event ID 1795 (Microsoft-Windows-Kernel-Boot): Secure Boot policy violation
 2Get-WinEvent -FilterHashtable @{
 3    LogName = 'Microsoft-Windows-Kernel-Boot/Operational'
 4    Id      = 1795
 5} | Select-Object TimeCreated, Message | Format-List
 6
 7# Event ID 4 (Microsoft-Windows-Kernel-Boot): Measured Boot log
 8Get-WinEvent -FilterHashtable @{
 9    LogName = 'Microsoft-Windows-Kernel-Boot/Operational'
10    Id      = 4
11} | Select-Object -First 5 | Select-Object TimeCreated, Message
12
13# UEFI variable modification events (Windows Security log)
14Get-WinEvent -FilterHashtable @{
15    LogName = 'System'
16    Provider = 'Microsoft-Windows-Kernel-General'
17} | Where-Object { $_.Message -like "*UEFI*" } | Select-Object TimeCreated, Message

Defense

1. Enforce Secure Boot and Keep DBX Updated

 1# Verify Secure Boot is in enforcing mode (not setup/audit mode)
 2(Get-UEFISecureBootStatus).SecureBootEnabled  # Should be True
 3
 4# Apply Microsoft's Secure Boot update for BlackLotus remediation (KB5025885)
 5# This updates dbx to revoke the vulnerable boot manager binaries
 6# Apply only after verifying all managed systems are on a current OS version
 7
 8# Check if the BlackLotus-related dbx update has been applied
 9# (The update adds specific hashes to the dbx forbidden list)
10$dbx = Get-SecureBootUEFI -Name dbx
11Write-Host "DBX entries: $($dbx.Bytes.Length) bytes"
12# A recently updated dbx will be larger than a factory default

2. Enable Intel Boot Guard (Hardware Root of Trust)

Intel Boot Guard, if enabled by the OEM at manufacture time, cryptographically verifies the initial boot firmware block before execution. A tampered IBB (Initial Boot Block) causes a boot failure rather than executing malicious code.

Important: Boot Guard must be enabled by the OEM during manufacturing. It cannot be enabled by end users or administrators after the fact. When procuring hardware for sensitive deployments, verify that Boot Guard (or AMD Platform Secure Boot equivalent) is configured.

1# Check Boot Guard status via chipsec
2sudo python chipsec_main.py -m common.bios_wp
3
4# Check if Boot Guard is enabled (bit checking in MSR)
5sudo python chipsec_util.py msr 0x13A  # IA32_FEATURE_CONTROL MSR
6# Bit 32 (Boot Guard Enable) should be 1 on protected systems
7
8# Alternatively via chipsec module
9sudo python chipsec_main.py -m platform.bootguard

3. Firmware Update Policy

 1# Monitor for firmware updates from your hardware vendor
 2# Keep firmware updated — vendors patch vulnerabilities in BIOS/UEFI
 3
 4# Linux — check current firmware version and available updates
 5fwupdmgr get-devices
 6fwupdmgr get-updates
 7fwupdmgr update  # Apply updates (verify vendor signatures)
 8
 9# fwupd verifies firmware update signatures before applying
10# DO NOT flash firmware from unverified sources
11
12# Check firmware version
13dmidecode -t bios | grep -E "Version|Release Date|Vendor"
14
15# Windows — check firmware via PowerShell
16Get-WmiObject -Class Win32_BIOS | Select-Object Manufacturer, Version, ReleaseDate

4. Disable DMA Before OS Boot

DMA (Direct Memory Access) from peripherals (Thunderbolt, PCIe) can be used to attack the system before OS DMA protections activate. Pre-boot DMA access can compromise memory containing UEFI code.

 1# Enable Kernel DMA Protection (requires hardware support)
 2# Check if hardware supports DMAR (IOMMU)
 3Get-WmiObject -Namespace root\WMI -Class MS_SystemInformation |
 4  Select-Object KernelDmaProtection
 5
 6# Via GPO: Computer Config → Admin Templates → System → Kernel DMA Protection
 7# Enable "Kernel DMA Protection"
 8
 9# Disable Thunderbolt DMA in firmware settings (set to "No Security" vs "User Authorization")
10# This is a UEFI setting, not configurable from the OS
11
12# BitLocker with pre-boot authentication (PIN + TPM) provides some DMA protection
13# because the drive is encrypted until the user authenticates

5. Firmware Integrity Monitoring

For enterprise deployments, establish a firmware baseline and monitor for changes:

 1# Baseline collection (run on new, clean machines)
 2sudo python chipsec_util.py spi dump /secure/baseline/$(hostname)_firmware_$(date +%Y%m%d).bin
 3sudo tpm2_pcrread sha256:0,1,2,3,4,5,6,7 > /secure/baseline/$(hostname)_pcrs_$(date +%Y%m%d).txt
 4
 5# Periodic integrity check script
 6#!/bin/bash
 7HOSTNAME=$(hostname)
 8BASELINE_PCR0=$(cat /secure/baseline/${HOSTNAME}_pcrs_initial.txt | grep "0 :" | awk '{print $3}')
 9CURRENT_PCR0=$(tpm2_pcrread sha256:0 | grep "0 :" | awk '{print $3}')
10
11if [ "$CURRENT_PCR0" != "$BASELINE_PCR0" ]; then
12    logger -p security.crit "FIRMWARE INTEGRITY ALERT: PCR0 mismatch on $HOSTNAME"
13    echo "ALERT: PCR0 mismatch" | mail -s "Firmware Integrity Alert: $HOSTNAME" security@corp.example.com
14fi

MITRE ATT&CK Mapping

  • T1542.001 — Pre-OS Boot: System Firmware
  • T1542.003 — Pre-OS Boot: Bootkit (BlackLotus)
  • T1542.004 — Pre-OS Boot: ROMMONkit (network device equivalent)
  • T1014 — Rootkit (kernel-level component delivery)
  • T1601.001 — Modify System Image: Patch System Image

Summary

Firmware rootkits represent the highest-persistence tier of malware, surviving OS reinstallation, drive replacement, and most enterprise remediation procedures. Four distinct firmware-level malware families have been documented in active use by nation-state actors between 2018 and 2023: LoJax (APT28, 2018), MoonBounce (Winnti, 2022), CosmicStrand (unknown, 2016+), and BlackLotus (commercial, 2022–2023). The trajectory is clear — capabilities previously limited to intelligence agencies are now commercially available. Detection requires specialized tooling (CHIPSEC, TPM attestation) rather than conventional endpoint security. Prevention requires hardware root of trust (Intel Boot Guard), properly configured Secure Boot with current DBX, UEFI write protection enforcement, and firmware integrity baselines. Organizations dealing with nation-state adversaries must treat firmware integrity as a measurable, monitored security control — not an implicit assumption.

References