UEFI Bootkits vs Firmware Implants: Persistence and Detection

Replacing an infected disk and repairing compromised firmware solve different problems. Before choosing either, establish where the persistence lives: the disk’s EFI System Partition or the motherboard’s SPI flash memory.

TL;DR

• An ESP bootkit such as BlackLotus persists through files on a boot partition. It is not a motherboard firmware implant.
• A firmware implant such as LoJax can survive disk replacement because its persistent component resides off the disk.
• Boot-level execution complicates detection, but does not make malware universally invisible to endpoint tools.
• Secure Boot needs maintained trust databases and revocations. Certificate expiration alone does not erase old trust.

Correction — September 19, 2026: Separated ESP persistence from firmware implants, removed universal invisibility and disk-replacement claims, corrected the certificate-expiration explanation, and removed a fuzzing command incorrectly labeled as a firmware dump.

Where the Persistence Lives

A simplified UEFI startup path is:

Motherboard firmware in SPI flash
  → Boot application on the EFI System Partition
    → Operating-system loader
      → Kernel and security services

ESET’s BlackLotus analysis distinguishes disk-based UEFI bootkits from firmware implants. An ESP bootkit depends on boot files on storage; replacing that storage removes those files. Other compromised components, restored backups or an unresolved entry point can still cause reinfection.

In the LoJax investigation, ESET found a malicious module written into SPI flash that could restore malware to the Windows partition. Recovery required clean firmware specific to the motherboard, or motherboard replacement. ESET also corrected its original advice: Secure Boot alone would not have prevented that particular firmware implant.

The operational question is therefore specific: which persistent component have we identified, and does our recovery procedure replace or verify it? “Reinstall Windows” is not a complete answer.

BlackLotus and the Signed-Binary Problem

ESET reported BlackLotus in March 2023 using CVE-2022-21894 to bypass Secure Boot. Although Microsoft had patched the vulnerability in January 2022, an attacker could bring an older signed bootloader that remained trusted on the systems described in the research.

That is a historical finding about the patch and revocation state at the time. It is not evidence that BlackLotus bypasses every fully updated Windows device today. A patched OS and a boot policy that rejects vulnerable older binaries address different parts of the problem.

Microsoft describes deployment as requiring prior privileged or physical access, rather than treating the bootkit itself as the initial intrusion vector. Investigating how that access was obtained remains part of recovery. Microsoft’s investigation guidance documents both the prerequisites and observable artifacts.

CVE-2024-7344: Scope Matters

ESET’s January 16, 2025 report on CVE-2024-7344 describes a vulnerable third-party signed UEFI application whose custom loader could execute unsigned code. Exploitation required elevated access to place files on the ESP, and a platform trusting the relevant Microsoft third-party UEFI certificate without the applicable revocation.

Attackers could bring the vulnerable application themselves; the associated recovery product did not have to be installed beforehand. Microsoft revoked the vulnerable binaries on January 14, 2025. ESET identified Secured-core PCs with third-party trust disabled by default as an important exception to broad exposure claims.

The right inventory question is whether a device has the relevant trust configuration and revocation state. A claim that virtually every UEFI machine remains vulnerable omits both conditions.

Detection: Use More Than One Layer

Microsoft’s BlackLotus guidance identifies evidence that defenders can collect:

• Unexpected or locked boot files and staging directories on the ESP.
• Changes disabling HVCI and unusual Defender service failures.
• Suspicious outbound traffic associated with winlogon.exe.
• Boot-component changes recorded in MeasuredBoot logs.

These are investigation leads, not standalone verdicts. Legitimate updates also change boot files and measurements. Correlate timestamps, maintenance records and endpoint activity before drawing a conclusion. Microsoft also documents Defender detections for known components, contradicting the claim that all AV and EDR products are blind to the threat.

For suspected SPI flash compromise, involve personnel equipped for platform-specific acquisition and analysis. Do not substitute a UEFI-variable fuzzer for evidence collection. Establish supported hardware, trusted tools and a recovery plan before running low-level firmware utilities.

What the 2026 Certificate Transition Changes

Microsoft’s 2011 Secure Boot certificates began reaching expiration in June 2026. Its expiration guidance says devices missing the newer certificates can continue normal startup and ordinary Windows updates, but lose access to new early-boot security protections that require the updated trust.

Expiration is not the same operation as revoking every previously signed binary. Keep certificate deployment, boot-manager updates and revocation state as separate checks. Microsoft’s certificate and CA update guidance explains the roles of the allowed-signature database (db) and the forbidden-signature database (dbx).

For dual-boot and recovery environments, verify compatibility against the relevant OS and OEM guidance. Do not assume a universal update order across distributions or disable Secure Boot to avoid maintaining it.

A Recovery Checklist for Defenders

1. Scope before rebuilding. Record whether evidence points to ESP files, firmware, or both. Preserve the required evidence through your incident-response process.
2. Close the access path. Investigate privileged-account compromise and other ways the attacker could reinstall persistence.
3. Choose the matching recovery procedure. Include boot partitions in disk recovery; use vendor-supported firmware recovery or replacement where firmware compromise is established.
4. Verify the resulting state. Check firmware version, Secure Boot configuration, certificate deployment and revocations against the device’s support guidance.
5. Retest recovery media. A boot-trust change is not operationally complete until the supported recovery path also works.

Build these checks into the endpoint recovery runbook now. During an incident, uncertainty about what the rebuild actually replaces is expensive.

Related Posts

• BYOVD: How Attackers Use Legitimate Drivers to Kill Your Security Tools — examine paths to privileged hardware access.
• Antivirus vs EDR vs XDR — What’s the real difference in 2026? — understand the role of endpoint telemetry alongside other evidence.

Sources

• ESET: BlackLotus UEFI bootkit — March 1, 2023.
• ESET: LoJax — September 27, 2018, corrected October 9.
• Microsoft: Investigating BlackLotus — April 11, 2023.
• ESET: CVE-2024-7344 — January 16, 2025.
• Microsoft: Secure Boot certificate expiration — current update guidance.