UEFI Bootkits: The Malware That Lives Below Your Operating System

You wipe the hard drive. You reinstall Windows. You even swap in a new SSD. The malware is still there — waiting patiently in the firmware, untouched, ready to reload itself the moment the machine powers on.

This is not a hypothetical. This is what UEFI bootkits do, and they are becoming a mainstream threat actor tool.

TL;DR

UEFI bootkits live in firmware or the EFI System Partition — below the OS, invisible to AV and EDR

They survive OS reinstalls and hard drive replacements

BlackLotus (2023) became the first bootkit to bypass Secure Boot on fully-patched Windows 11

CVE-2024-7344 (patched January 2025) exposed virtually every UEFI-based system to bootkit installation

Detection requires firmware-level tooling (CHIPSEC, TPM attestation) — OS-level tools won’t see them

Why This Matters to You

Nation-state actors have used UEFI-level implants since at least 2018. What changed is that the capability is no longer exclusive to elite APT groups. BlackLotus was sold on cybercriminal forums for around $5,000. Proof-of-concept bootkits now target Linux. And a vulnerability patched in January 2025 exposed the majority of UEFI systems to bootkit-level compromise.

If you operate endpoints, servers, or OT equipment — and if those assets run UEFI firmware (everything built after 2012 does) — UEFI bootkits are a real part of your threat model.

What Is UEFI and Why Does It Matter?

UEFI — Unified Extensible Firmware Interface — is the software that runs the moment you press the power button, before any operating system loads. Think of it as the building’s foundation: the OS is the house built on top. If you compromise the foundation, you own everything above it.

UEFI replaced the older BIOS standard and brought significant improvements: support for drives larger than 2TB, faster boot times, a graphical interface, and critically — Secure Boot, a mechanism designed to ensure only signed, trusted code runs during startup.

The UEFI boot chain works like this:

Power on
  → UEFI firmware (stored in SPI flash chip on motherboard)
    → Boot manager (reads EFI System Partition on disk)
      → OS bootloader (e.g., bootmgfw.efi on Windows)
        → OS kernel
          → Your software

Each step is supposed to verify the next. The problem is that attackers have found ways to break that chain of trust — at multiple points.

Where Bootkits Hide

A “bootkit” is malware that persists in the boot process, before the OS starts. UEFI bootkits operate at one of two levels:

Level 1 — EFI System Partition (ESP) The ESP is a small FAT-formatted partition on your disk that contains bootloaders and EFI binaries. Bootkits like BlackLotus and ESPecter modify or replace files here. Because this happens before the OS loads its security controls, most endpoint protection never sees it.

Level 2 — SPI Flash Firmware The deeper, more dangerous variant. The UEFI firmware itself — stored in a dedicated chip on the motherboard — is modified directly. Bootkits like LoJax, CosmicStrand, and MoonBounce operate at this level. Replacing the hard drive does nothing. The only way to remove them is to reflash the firmware chip — and most defenders don’t even think to check there.

The Bootkit Family Tree

The threat has been evolving for over a decade:

Bootkit	Year	Level	Notable trait
LoJax	2018	SPI flash	First UEFI rootkit found in the wild; Sednit/APT28
ESPecter	2021	ESP	Active since 2012; patches Windows Boot Manager
CosmicStrand	2022	SPI flash	Chinese-speaking APT; targets Gigabyte/ASUS H81 boards
MoonBounce	2022	SPI flash	Kaspersky discovery; modifies core firmware tables
BlackLotus	2023	ESP	First to bypass Secure Boot on patched Windows 11
Bootkitty	2024	ESP	First UEFI bootkit targeting Linux; proof-of-concept

This is not an exhaustive list. These are the ones that researchers found and disclosed. Operational intelligence suggests nation-state actors have been running undisclosed variants for years.

How Attackers Install a Bootkit

Getting a bootkit installed requires elevated access — typically SYSTEM-level on Windows or root on Linux. Attackers usually achieve this through a combination of:

Initial access — phishing, exposed RDP, supply chain compromise
Privilege escalation — kernel exploits, BYOVD (Bring Your Own Vulnerable Driver)
Disabling security controls — kill EDR, disable HVCI, stop Windows Defender
Writing to ESP or SPI flash — drop malicious EFI binaries or patch firmware

BlackLotus is a good case study. Once an attacker has admin rights, the installer:

Drops a copy of a vulnerable (but legitimately signed) Windows bootloader
Exploits CVE-2022-21894 (“Baton Drop”) — a Secure Boot bypass that was patched in January 2022 but Microsoft hadn’t yet revoked the vulnerable binaries
Uses the old signed binary to load the malicious bootkit, bypassing Secure Boot’s signature checks
Disables BitLocker, HVCI, and Windows Defender
Installs a kernel driver and HTTP-based C2 downloader that loads on every boot

The result: every time the machine starts, the bootkit loads before Windows, re-establishes control, and defeats any security tooling the OS tries to run.

Why Secure Boot Isn’t a Silver Bullet

Secure Boot is the main defense mechanism against boot-level attacks. It uses cryptographic signatures to verify that each component in the boot chain — from firmware to bootloader to OS — is trusted.

The problem is that Secure Boot’s trust is only as strong as its revocation list. If a vulnerability is patched but the old, vulnerable signed binary is never revoked, an attacker can still use it. This is exactly what BlackLotus exploited.

CVE-2024-7344 made this even more alarming. Discovered by ESET researchers and disclosed in January 2025, this vulnerability affected the majority of UEFI-based systems. The flaw was in a UEFI application signed by Microsoft’s own third-party certificate. The application used a custom PE loader — essentially its own code to load EFI binaries — that bypassed UEFI’s standard LoadImage and StartImage functions, skipping signature verification entirely. An attacker could place a malicious binary in a file called cloak.dat and have it executed during boot.

The vulnerable application had been signed and distributed for years. It was revoked in Microsoft’s January 2025 Patch Tuesday — but only if systems actually applied the update and received the revocation.

HybridPetya, a ransomware variant that emerged afterward, was observed exploiting this vulnerability to install a bootkit before encrypting the MFT (Master File Table) — combining firmware-level persistence with destructive ransomware.

The 2026 Certificate Rotation: A Necessary Reset

In June 2026, Microsoft’s original Secure Boot certificates — in use since 2011 — expire and are being replaced with new 2023-era certificates. This is the first major chain-of-trust refresh in Secure Boot’s history, and it has direct implications for both attackers and defenders.

The security upside is significant. The expiring Microsoft Corporation UEFI CA 2011 certificate is the same trust anchor that made BlackLotus and CVE-2024-7344 possible — attackers could abuse it because old, vulnerable binaries were still signed under it. When the new certificate chain takes over, those old binaries lose their trust. Future bootkit authors cannot rely on the decade-old signing infrastructure that made so many bypasses possible.

The transition risk is real. Systems that don’t receive the update by the deadline lose the ability to install future Secure Boot security updates. For Linux dual-boot configurations, the timing matters: the Windows-side certificate update must land before the Linux shim (which also relies on the old Microsoft certificate) gets updated, or the boot chain may break. Most major Linux distributions — Red Hat, Ubuntu, Arch-based distros — are coordinating shim re-signing for the new certificate, but the rollout window is tight.

If you manage endpoints or run dual-boot systems, verify that Windows Update is deploying the new certificates and monitor your Linux distribution for shim updates through mid-2026.

Why Your EDR Won’t Catch This

Standard endpoint security tools — AV, EDR, XDR — operate inside the operating system. They hook into OS APIs, scan file system paths, and monitor process behavior.

A UEFI bootkit runs before any of that exists. By the time Windows has loaded its security tools, the bootkit has already:

Loaded its own kernel driver
Patched critical OS functions in memory
Disabled or blinded the security tools

It’s like trying to secure a building by putting locks on the doors — when the attacker already built a tunnel under the foundation. The EDR layer simply doesn’t see what’s happening below it.

For ESP-level bootkits, OS-level file access controls can help during the installation phase — most ESPs are not actively monitored. But once installed, the bootkit can hide from OS-level inspection entirely.

Detection: What Actually Works

Detecting UEFI bootkits requires operating outside or below the OS. Here’s what defenders have at their disposal:

CHIPSEC

CHIPSEC is an open-source Python framework from Intel for platform security assessment. It can dump the SPI flash firmware, check for known-bad configurations, and validate firmware integrity. Run it from a live USB or pre-OS environment for accurate results — running it from inside a compromised OS gives unreliable output.

# Dump SPI flash firmware for offline analysis
python chipsec_main.py -m tools.uefi.uefivar_fuzz
python chipsec_main.py -m common.bios_wp  # Check firmware write protection

TPM Measured Boot

The Trusted Platform Module (TPM) records cryptographic hashes of each boot component into PCR (Platform Configuration Registers). This creates a tamper-evident log of exactly what ran during boot.

If your baseline TPM measurements are known, any deviation — such as a modified bootloader — produces a different hash. Remote attestation can verify these measurements against a known-good state from a central server.

ESP Monitoring

Since most bootkits touch the EFI System Partition, monitoring that partition for unexpected file changes is a practical detection layer. The ESP doesn’t change often — a new file or a modified bootloader binary is a high-signal alert.

Velociraptor provides a built-in Windows.Forensics.UEFI artifact that parses the ESP and flags anomalies without requiring a reboot or specialized hardware.

Firmware Integrity Verification

Many enterprise laptop vendors (Lenovo, HP, Dell) offer firmware verification tools that compare installed firmware against vendor-signed baselines. These can be integrated into endpoint management pipelines.

What You Can Do Today

You won’t catch everything, but you can significantly raise the bar:

Keep UEFI firmware updated. Firmware updates patch SPI flash vulnerabilities and add new revocations. Most organizations skip these.
Apply Microsoft’s UEFI revocations. These are distributed via Windows Update. Ensure Patch Tuesday updates are applied promptly — this is what closed the CVE-2024-7344 window.
Enable Secure Boot and TPM. Even though Secure Boot has been bypassed, it remains a meaningful barrier against most threats. Combined with TPM-measured boot, it raises the cost of attack significantly.
Monitor the EFI System Partition. Add file integrity monitoring (FIM) rules for the ESP. Baseline it now while the system is clean.
Treat firmware-level compromise as a board replacement scenario. If you suspect SPI flash compromise, reflashing may not be enough — a hardware replacement may be the only reliable remediation path.
Include UEFI threats in incident response playbooks. Most IR teams don’t consider firmware when scoping a breach. If an APT-level threat actor is involved, look below the OS.

The Trend Line

In 2018, UEFI rootkits were exotic weapons in nation-state toolkits. In 2023, they were being sold to cybercriminals for $5,000. In 2024, they hit Linux for the first time. In 2025, a single vulnerability exposed nearly every UEFI system manufactured in the past decade.

The attack surface is real, the tooling is maturing, and most organizations have no visibility below the OS layer. UEFI-level security is no longer just a hardware vendor problem — it’s a core part of enterprise defense.

BYOVD — Bring Your Own Vulnerable Driver Attacks — BlackLotus uses BYOVD techniques during installation to gain kernel-level access
APT Groups: Nation-State Hackers Guide 2026 — state-sponsored actors pioneered UEFI implants and continue to operate at firmware level
AV vs EDR vs XDR — What’s the Difference? — explains why OS-resident security tools have fundamental blind spots against firmware-level threats