The investigation was going well until it stopped making sense. The malware had been removed, the infected system reimaged, the hard drive replaced just to be safe. Two weeks later, the same indicators reappeared on the same machine. It was neither a network reinfection nor a backup restore gone wrong. The machine itself was still compromised, at a layer nobody had checked, in storage that survives disk replacement just as stubbornly.

cover

This is the scenario that firmware implants and UEFI bootkits are built for: persistence so deep that the normal DFIR playbook of acquiring the disk, imaging the memory, analyzing, remediating, and reimaging simply does not reach it. It is not a new problem. The first UEFI rootkit documented in the wild appeared in 2018. What has changed is that the technique has moved from nation-state novelty to something approaching a tradecraft standard, and the forensic community’s response has not quite kept up.

In brief

  • UEFI bootkits and firmware implants persist below the operating system, in EFI System Partition boot components or in SPI flash memory on the motherboard itself.
  • Known implants include BlackLotus (EFI bootkit, bypasses Secure Boot on patched Windows 11), CosmicStrand and MosaicRegressor (firmware-resident, survives disk replacement), and FinSpy bootkit (commercial spyware with pre-OS component).
  • Standard DFIR tools (Volatility, disk imaging, EDR agents) are structurally blind to firmware-layer persistence.
  • Detection requires a different toolkit: CHIPSEC for SPI flash analysis, UEFITool for EFI binary inspection, boot log analysis, and PCR value attestation via TPM.
  • Remediation is non-trivial: EFI-resident implants may require ESP cleaning and Secure Boot re-enrollment; firmware implants may require a full BIOS reflash or, in extreme cases, hardware replacement.
  • Forensic readiness for this threat class requires pre-incident baselines of firmware hashes and PCR values, artifacts you cannot reconstruct after the fact.

The firmware layer and why it matters

Before cataloging what is exploitable, it helps to be precise about the architecture. UEFI (Unified Extensible Firmware Interface) replaced legacy BIOS on mainstream hardware from around 2010 onward. It is a complete pre-OS environment with its own networking stack, drivers, a file system (the EFI System Partition, or ESP), and a shell. It runs before any operating system component loads, which means anything it executes inherits an environment where no EDR agent, no AV engine, and no kernel patch guard exist yet.

The boot sequence on a modern UEFI system proceeds roughly like this: UEFI firmware (stored in SPI flash on the motherboard) initializes hardware, reads the ESP on the boot disk, loads the boot manager (\EFI\Microsoft\Boot\bootmgfw.efi on Windows), which in turn loads the OS loader, which loads the kernel. A bootkit can insert itself at any stage of this chain. The two most relevant levels for practical forensics are:

  • ESP-resident: the implant lives on the EFI System Partition as a modified or additional EFI binary. It persists across OS reinstalls if the ESP is not explicitly wiped, and it can survive drive imaging if the ESP is not included in the acquisition scope.
  • Firmware-resident: the implant is written directly to SPI flash on the motherboard. It persists across disk replacement, OS reinstall, and every other remediation step short of physically reflashing the chip.

The distinction matters for both detection and remediation. What these two classes have in common is that they are structurally invisible to anything that runs after the firmware has already executed, which includes every tool in a conventional DFIR toolkit.

ESP and firmware implants at a glance

Dimension ESP-resident implant Firmware-resident implant
Persistence scope Survives OS reinstall if ESP is not wiped Survives OS reinstall and disk replacement
Typical storage location EFI System Partition (FAT32) SPI flash on motherboard
Typical artifacts Unexpected EFI binaries, modified boot files, anomalous ESP paths Modified DXE modules, altered firmware volumes, SPI write-protection anomalies
Visibility from endpoint tools Low, usually visible only with targeted ESP acquisition Very low, usually invisible to OS-level telemetry
Detection approach ESP imaging, hash/signature checks, Secure Boot and DBX validation CHIPSEC checks, SPI dump diff against baseline, firmware module analysis
Remediation complexity Medium: clean ESP and rebuild trusted boot chain High: reflash, verify integrity, and in some cases replace hardware

Known implants in the wild

The forensic understanding of UEFI-level threats is not theoretical. Several real-world implants have been analyzed in enough detail to guide forensic work.

BlackLotus is the most significant recent case, first publicly documented by ESET in March 2023. It is a UEFI bootkit sold as a crimeware product (not exclusively nation-state) that can bypass Secure Boot on fully patched Windows 11 systems by exploiting a vulnerability in the Windows Boot Manager (CVE-2022-21894, also known as Baton Drop). BlackLotus installs a malicious EFI binary to the ESP, disables kernel protections including HVCI and Windows Defender, and deploys a kernel driver and a user-mode HTTP downloader. Even after Microsoft patched the underlying boot manager vulnerability, systems with a valid but vulnerable bootloader version still installed in their Secure Boot database remained exploitable, because the Secure Boot revocation list (the UEFI Forbidden Signature Database, or DBX) was not automatically updated.

The forensic artifacts of a BlackLotus infection on the ESP are reasonably concrete:

\EFI\Microsoft\Boot
├── bootmgfw.efi   # legitimate, but may be replaced
├── grubx64.efi    # BlackLotus drops this as its loader
├── winload.efi    # may be patched
└── system32\drivers
  └── [randomized].sys   # kernel driver

ESET documented the directory \EFI\Microsoft\Boot\system32\ as a BlackLotus artifact on the ESP, a path that has no legitimate reason to exist in a standard Windows installation.

CosmicStrand is an order of magnitude more serious. Kaspersky’s analysis published in 2022 describes a UEFI firmware rootkit attributed to a Chinese-speaking threat actor, found embedded in the firmware images of consumer-grade ASUS and Gigabyte motherboards. CosmicStrand hooks the CSMCORE DXE driver (a UEFI component) to intercept the Windows boot process, injects a shellcode kernel patch, and ultimately deploys a user-mode agent, all before Windows has loaded a single driver. From the OS’s perspective, the system looks clean. The implant is in the SPI flash chip soldered to the motherboard.

MosaicRegressor (attributed to APT41, documented by Kaspersky in 2020) used a modified version of the leaked Hacking Team UEFI implant source code, embedded in the UEFI firmware of victim laptops. It was found on systems used by organizations connected to North Korea-focused research. The infection vector involved physical access or supply-chain compromise. The implant drops a downloader component during the boot process.

MoonBounce (Kaspersky, 2022), attributed to APT41, went further than any of its predecessors by targeting the CORE_DXE component of the firmware, a component that is mapped into virtual memory when the OS starts, and injecting shellcode there. The injection is clean enough that the surrounding legitimate code still functions normally. MoonBounce left no files on disk; the entire attack chain ran from firmware through injected code in the kernel’s own memory.

FinSpy, the commercial spyware sold by FinFisher, was found in 2021 to include a UEFI bootkit component. Its ESET analysis documented infection of the Windows Boot Manager with a component that loaded the FinSpy trojan before the OS kernel initialized. This was significant because it confirmed that commercial surveillance vendors, beyond nation-state operators, had incorporated firmware-level persistence.

The forensic toolkit below Volatility

Volatility does not analyze UEFI firmware. Memory forensics tools analyze RAM, which is populated after the firmware has already handed off execution. By the time Volatility sees anything, a firmware implant has long since done its work.

If you are planning a workflow that mixes memory and firmware analysis, this boundary is worth revisiting alongside my notes on Volatility migration pitfalls and how Windows memory structures shape forensic visibility.

The toolkit for this threat class is different.

CHIPSEC (github.com/chipsec/chipsec) is the primary open-source framework for UEFI security analysis, maintained by Intel. It can read SPI flash contents, check write-protection status, verify firmware integrity against known-good baselines, and detect a range of UEFI vulnerability classes. On a live Windows system:

# Install and run CHIPSEC from PowerShell (requires admin)
python chipsec_main.py -m common.bios_wp
# Checks whether SPI flash write protection is enabled
# A disabled write protection is a prerequisite for most firmware implants

python chipsec_main.py -m common.uefi.access_uefispec
# Checks for UEFI variables with suspicious permissions

# Dump the full SPI flash to a file for offline analysis
python chipsec_util.py spi dump firmware.bin

The firmware.bin dump can then be analyzed offline. A meaningful analysis requires a known-good baseline of the same motherboard model and firmware version, something you need to have collected before the incident. This is one of the fundamental constraints of firmware forensics: unlike memory where you can reason about anomalies without a baseline, firmware analysis almost always requires a reference image to compare against.

UEFITool (github.com/LongSoft/UEFITool) parses UEFI firmware images and EFI binaries into DXE modules, PE images, and volumes. It can extract individual modules from a firmware dump for further analysis. Combined with a disassembler or Ghidra, it becomes the primary path for analyzing suspected firmware modifications:

# Extract all PE32 images from a firmware dump using UEFIExtract (CLI companion)
./UEFIExtract firmware.bin all

# The output directory structure mirrors the firmware layout
# Each extracted PE can be hashed and compared against vendor baselines
# or submitted to static analysis

For ESP-level analysis, the tools are closer to conventional DFIR work. The ESP is a FAT32 partition that is straightforward to image with standard tools. What requires attention is ensuring it is actually included in the acquisition:

# On Linux, identify the ESP and image it specifically
lsblk -o NAME,PARTTYPE,MOUNTPOINT
# Look for partition type EFI System (UUID c12a7328-f81f-11d2-ba4b-00a0c93ec93b)

# Image the ESP directly
dd if=/dev/sda1 of=esp.img bs=4M status=progress

# Mount read-only for examination
mkdir /mnt/esp
mount -o ro,loop esp.img /mnt/esp
ls -la /mnt/esp/EFI/

Once mounted, unexpected directories or EFI binaries can be identified. The expected contents of a clean Windows ESP are well-documented. Anything in \EFI\Microsoft\Boot\ that is not in the standard Windows boot file list warrants examination. File timestamps on the ESP can be informative, though they can also be manipulated.

Authenticode analysis of EFI binaries on the ESP can reveal unsigned or unusually-signed components:

# Using pefile to check EFI binary signatures
import pefile
import hashlib

efi_path = "/mnt/esp/EFI/Microsoft/Boot/grubx64.efi"
pe = pefile.PE(efi_path)

# Check for SECURITY_DIRECTORY (Authenticode signature)
if hasattr(pe, 'DIRECTORY_ENTRY_SECURITY'):
    print("Signed binary")
    # Extract and verify the certificate chain
else:
    print("UNSIGNED - flag for review")

# Hash for comparison against known-good databases
with open(efi_path, 'rb') as f:
    sha256 = hashlib.sha256(f.read()).hexdigest()
print(f"SHA256: {sha256}")

TPM PCR values are the most powerful forensic signal for detecting pre-OS tampering when they are collected in advance. The TPM’s Platform Configuration Registers record measurements of every component in the boot chain: firmware, boot manager, OS loader. If an implant modified any of these components, the PCR values change. Comparing current PCR values against a trusted baseline from initial enrollment is definitive evidence of boot chain tampering.

On Windows, BitLocker stores a PCR profile at enrollment time. On Linux, tpm2-tools provides access:

# Read current PCR values
tpm2_pcrread sha256

# PCR 0: UEFI firmware
# PCR 2: UEFI firmware data
# PCR 4: Boot manager (MBR or UEFI boot application)
# PCR 7: Secure Boot policy
# PCR 8-9: GRUB measurements (if applicable)

# Any deviation from a known-good baseline in PCR 0, 4, or 7
# is a strong indicator of boot chain interference

The forensic limitation: if you do not have a pre-incident PCR baseline, the current values still tell you the state of the boot chain today, but you cannot say definitively when tampering occurred or what the original values were.

Secure Boot limits and caveats

Secure Boot is the primary defense against ESP-resident bootkits. When properly configured, it requires every EFI binary in the boot chain to be signed by a certificate in the UEFI Signature Database (DB). A bootkit binary that is not signed, or whose signing certificate is not trusted, will fail to load.

BlackLotus broke this model not by defeating the cryptographic verification, but by exploiting the fact that the Secure Boot revocation process is slow and optional. The Windows Boot Manager binary it exploited (CVE-2022-21894) was patched, but the vulnerable version remained in the DB as trusted. Booting from a vulnerable but signed bootloader allowed the bootkit to load before Windows could enforce any of its own integrity checks.

The forensic implication is that Secure Boot status is necessary but not sufficient evidence of a clean boot chain:

# Check Secure Boot status on Windows
Confirm-SecureBootUEFI

# Check which certificates are enrolled in DB, DBX, KEK, PK
# Using PowerShell with Get-SecureBootPolicy or native UEFI variable access
[System.Text.Encoding]::ASCII.GetString(
    (Get-SecureBootUEFI db).bytes
) | Select-String "Microsoft"

# Also check DBX (revocation list) - an outdated DBX is a vulnerability
# Microsoft periodically publishes updated DBX through Windows Update
# Compare the current DBX hash against Microsoft's published values:
# https://uefi.org/revocationlistfile

An outdated DBX combined with a Secure Boot status of “Enabled” gives a false sense of security. This is exactly the configuration that BlackLotus exploits in the wild.

What remediation actually requires

Once a firmware-level implant is confirmed, the remediation path depends on where exactly the implant lives.

For ESP-resident implants (BlackLotus class), the steps are:

  1. Image the ESP before any remediation, for evidentiary preservation
  2. Boot from external trusted media (not the compromised disk)
  3. Wipe and reformat the ESP
  4. Reinstall Windows Boot Manager using bootrec /fixboot or a Windows recovery environment
  5. Update the DBX to the latest Microsoft-published version
  6. Re-enroll Secure Boot certificates from a known-good state

For firmware-resident implants (CosmicStrand/MosaicRegressor class), the options narrow considerably:

  1. Obtain the latest clean firmware image from the motherboard vendor for the exact board revision
  2. Flash using a hardware SPI programmer if the board is unbootable, or via vendor tools (ASUS EZ Flash, Gigabyte Q-Flash) from a trusted USB drive
  3. Verify the flashed image hash against the vendor’s published checksum
  4. In cases of confirmed nation-state-grade implants in production systems, hardware replacement is often the operationally cleaner choice because reflashing cannot guarantee the absence of implants in components beyond the main UEFI flash (Embedded Controller firmware, NIC firmware, drive firmware)

The article on wiper disk evolution noted that each generation of destructive malware removes a recovery option. The same logic applies in reverse here: each layer of firmware the attacker reaches is a layer where the defender’s standard tools provide no visibility.

Common false positives in firmware triage

Firmware triage has a high false-positive rate when baseline discipline is weak. The most common cases are:

  • Legitimate firmware updates that alter DXE modules and hashes without any malicious activity.
  • Normal OEM variance across board revisions that causes mismatches when analysts compare against the wrong reference image.
  • Secure Boot key rotation and DBX updates that legitimately change boot measurements and PCR values.
  • Dual-boot or recovery tooling that introduces additional EFI binaries in the ESP.

The practical mitigation is procedural: tie every finding to the exact hardware revision, exact firmware version, and a trusted baseline captured for that specific asset class. Without that context, firmware anomalies are easy to overstate.

The first 60 minutes of firmware-aware triage

When firmware persistence is plausible, the initial response window is decisive. A practical workflow for the first hour is:

  1. Isolate the host from the network and preserve power state decisions in the case log.
  2. Capture volatile context that may disappear after reboot, including current boot configuration, Secure Boot state, and event logs tied to boot integrity.
  3. Acquire the full disk with explicit ESP inclusion, then acquire a dedicated ESP image for fast triage.
  4. Hash all EFI binaries in \EFI\Microsoft\Boot\ and compare against known-good baselines for that OS build.
  5. Validate Secure Boot material, including DB and DBX currency, and record the exact firmware version and motherboard revision.
  6. Run CHIPSEC checks focused on SPI write protections and UEFI variable access controls.
  7. If suspicion remains high, schedule an SPI flash dump and offline module comparison against a clean firmware reference.

This sequence does not replace deep analysis. It reduces the chance of losing decisive evidence while the case is still fluid.

Forensic readiness for a threat most teams are not ready for

The operational reality of firmware forensics is that it is almost entirely reactive to decisions made before the incident. The difference between a thorough firmware investigation and an investigation that produces a shrug depends almost entirely on whether someone collected firmware baselines, TPM PCR values, and ESP snapshots before the attack.

Most organizations have not done this. The threat intelligence community documented CosmicStrand in 2022, MoonBounce in 2022, BlackLotus in 2023, and still the vast majority of enterprise IR teams have no firmware baseline collection in their standard asset onboarding process. Part of this is tooling immaturity: CHIPSEC is powerful but not a polished enterprise product. Part of it is a threat model problem: firmware implants have historically been associated with nation-state APTs targeting high-value individuals, not broad-based ransomware campaigns. That association is eroding. BlackLotus was sold on criminal forums.

The operational gap mirrors a broader readiness problem discussed in DFIR always on: teams often optimize for speed during incidents, but underinvest in baseline collection that makes deep investigations possible.

A minimal firmware forensic readiness posture looks like this:

  • At asset enrollment: run chipsec_util.py spi dump on each new system and store the resulting firmware image with the asset record. Hash it. Note the motherboard model and firmware version.
  • Continuously: monitor DBX update status as part of patch management. An outdated DBX is a concrete, measurable risk.
  • On critical systems: enable measured boot and record TPM PCR baselines in a trusted attestation store. Remote attestation via TPM 2.0 allows continuous monitoring of boot chain integrity without manual forensic intervention.
  • On incident: always include the ESP in forensic acquisition scope. “Full disk image” must mean the full disk, including the FAT32 partition that your imaging tool might skip if not explicitly configured.

The field of firmware forensics has been niche by necessity: the tools are harder to use, the hardware is less forgiving than RAM or disk, and the evidence is often only interpretable against a baseline that was never collected. As bootkits move down-market and the gap between nation-state TTPs and criminal tooling continues to shrink, treating the firmware layer as out-of-scope in DFIR work stops being pragmatism and becomes a genuine operational gap.

FAQ

What is a UEFI bootkit and how does it differ from a traditional rootkit? A UEFI bootkit persists in firmware or EFI System Partition components below the operating system, surviving OS reinstallation, hard drive replacement, and conventional antivirus scans. Traditional rootkits operate within the OS kernel or userspace and are removed by reinstalling the system.

Can a UEFI bootkit survive a full disk wipe or OS reinstallation? Yes. Firmware-resident implants like CosmicStrand or MosaicRegressor are stored in SPI flash memory on the motherboard and survive disk replacement entirely. EFI System Partition bootkits like BlackLotus can survive OS reinstallation if the ESP is not wiped and Secure Boot is bypassed.

What tools can detect UEFI firmware tampering during incident response? CHIPSEC is the primary open-source tool for firmware integrity analysis, capable of detecting write-protection bypass and unauthorized firmware modifications. For EFI binaries, tools like UEFITool, efifs, and Binwalk support parsing and extraction. Volatility 3 does not analyze firmware directly.