What Is a Bootkit? UEFI Boot Attacks Explained

In early 2023, ESET published the dissection of BlackLotus: the first bootkit seen in the wild that defeats UEFI Secure Boot on a fully patched Windows 11 machine. It does it by carrying its own copy of a legitimate, validly signed but vulnerable Windows boot manager, then exploiting CVE-2022-21894, a flaw nicknamed "Baton Drop." Microsoft had already patched the bug in January 2022. It did not matter. The signed binaries were never added to the UEFI revocation database, so the bootkit drops an old one and rolls the machine back to a version that still has the hole. Once running, it disables BitLocker, HVCI, and Microsoft Defender, installs a kernel driver, and a user-mode downloader phones home. All of this happens before Windows finishes loading, which means before any of the security tools that would catch it have started.

That is the whole point of a bootkit. It is malware that wins by going first. This guide covers what a bootkit is, the boot chain it subverts, how it differs from a rootkit, the move from MBR-era boot sector viruses to modern UEFI implants, the real cases on record (LoJax, ESPecter, MoonBounce, BlackLotus) with their dates, and what detection and remediation actually take when the malware lives below the operating system. It is written for the SOC analysts and DFIR responders who have to answer "is this thing still on the disk after we reimaged?"

What is a bootkit?

A bootkit is malware that infects the early boot process so it loads before the operating system and the security stack that runs on top of it. MITRE ATT&CK catalogs it as technique T1542.003, Bootkit, a sub-technique of T1542, Pre-OS Boot, and defines it as a "malware variant that modifies the boot sectors of a hard drive, allowing malicious code to execute before a computer's operating system has loaded." On older BIOS systems that meant the Master Boot Record (MBR) and Volume Boot Record (VBR). On modern UEFI systems it means files placed in or loaded from the EFI System Partition (ESP), or in the worst case the firmware itself.

The mechanism matters because it dictates everything else about the threat. Code that executes first controls what runs after it. A bootkit that owns the boot stage can patch the operating system kernel as it loads, switch off integrity checks, hide its own files, and load drivers the OS would otherwise refuse. Antivirus, EDR, and the kernel's own self-protection all start later, on a platform the bootkit has already shaped. The defender is auditing a house whose foundation was poured by the attacker.

Bootkits are rare and expensive to build, which is why almost every documented case is the work of a well-resourced espionage group or a commercial malware operation, not commodity crimeware. The payoff is persistence that survives the responses defenders reach for first: reinstalling the operating system, and in the firmware cases, even replacing the hard drive.

Bootkit vs rootkit: what actually differs

The two terms get used interchangeably, and the confusion is understandable because their goals overlap: both hide, both persist, both want control below the level where defenders normally look. The difference is where they live and when they run.

A rootkit operates within or just beneath the running operating system. A kernel-mode rootkit loads as a driver and tampers with the OS from inside it, hiding processes, files, and network connections by intercepting the calls that would reveal them. It is powerful, but it still depends on the OS booting normally and on the rootkit's component being loaded during or after that boot. Reinstall the OS cleanly and a disk-resident rootkit usually goes with it.

A bootkit operates below the operating system, in the boot chain that runs before the OS exists. That is the sharper line. A bootkit does not need the OS to load it, because the bootkit is what loads the OS. It can install a kernel-mode rootkit as one of its payloads, but the bootkit itself sits earlier in the sequence. The practical consequence is durability: a bootkit in the ESP survives an OS reinstall, and a bootkit in the SPI flash firmware survives wiping or replacing the disk entirely. Many real samples are both at once, a bootkit for the early foothold and a rootkit component for runtime stealth, which is why the labels blur in incident reports.

The boot chain a bootkit subverts

To see where a bootkit injects, follow what a modern machine does between power-on and login. Each stage hands control to the next, and a bootkit's job is to insert itself into one of those handoffs so everything downstream trusts it.

On a UEFI system the order is: the platform firmware (UEFI, stored in the SPI flash chip on the motherboard) initializes hardware, then reads the EFI System Partition on disk and runs the bootloader it finds there (on Windows, the boot manager bootmgfw.efi). The bootloader loads the operating system kernel. The kernel brings up drivers and services. Only then do user sessions, antivirus, and EDR start. Security tools live at the far right of that line. A bootkit installs at the far left.

The earlier the injection point, the more the bootkit controls and the harder it is to remove:

• Bootloader / ESP (T1542.003). The bootkit replaces or adds a malicious bootloader in the EFI System Partition. This is the BlackLotus and ESPecter pattern. It survives an OS reinstall because the ESP is a separate partition, but it can be cleaned by rewriting the ESP and restoring a trusted bootloader.
• System firmware / SPI flash (T1542.001, System Firmware). The bootkit writes itself into the UEFI firmware on the motherboard chip. This is the LoJax and MoonBounce pattern. It survives disk wiping and disk replacement, because it is not on the disk at all. Removing it means reflashing the firmware, and in the worst cases replacing the motherboard.

Secure Boot is the control designed to break this chain, by refusing to run any bootloader that is not signed by a trusted key. The documented bootkits are interesting precisely because of how they get around it.

MBR-era bootkits versus modern UEFI bootkits

Boot-stage malware is not new. The earliest PC viruses, Stoned and Brain in the late 1980s, were boot sector infectors. The modern bootkit lineage runs through MBR threats like the TDL4/TDSS family around 2011, which overwrote the Master Boot Record to load before Windows and defeat driver signing on the 64-bit systems of the day. These were real and effective, but they had a structural weakness: the MBR is a known, fixed location on the disk, and rewriting it with a clean copy removed the infection.

UEFI replaced the BIOS-and-MBR boot model on essentially all hardware shipped in the last decade, and bootkits followed the platform. The shift changed the threat in two ways. First, the attack surface moved from a 512-byte disk sector to the EFI System Partition and the firmware itself, both larger and more capable targets. Second, and the reason firmware bootkits are the high end of the threat, code written into the SPI flash is not on the disk, so none of the disk-level responses touch it. An MBR bootkit was a disk problem. A firmware bootkit is a hardware problem.

Why bootkits are stealthy and persistent

Two properties make a bootkit harder to deal with than almost any other malware, and both come from the same fact: it runs first.

It is stealthy because the tools that would detect it are not running yet when it acts. Antivirus and EDR are processes that the operating system starts. A bootkit has already executed, patched the kernel, and hidden its files before any of that happens, so a live scan of the running system sees a clean machine. This is also why a bootkit pairs naturally with fileless malware techniques at runtime: once the boot stage has loaded a malicious kernel driver into memory, the on-disk footprint can be minimal and the rest of the operation lives in memory the scanner cannot easily reach.

It is persistent because it lives outside the operating system's lifecycle. The standard incident response move for a badly infected host is to reimage it. That reinstalls the OS from a known-good image and is supposed to return the machine to a trusted state. A bootkit in the ESP or the firmware is untouched by that process. The reimaged, "clean" machine boots through the bootkit again on the first restart. For the firmware-resident cases, the malware also survives a full disk swap, which removes the last disk-level option a responder has. That durable foothold is frequently the launch point for a backdoor: the bootkit guarantees the access survives, and the backdoor it deploys is what the operators actually use day to day.

Real bootkits on record, with dates

Four cases define the modern bootkit, and they map cleanly onto the boot chain above.

LoJax (2018). Found by ESET in 2018 on a target of the Sednit group (APT28, the Russian state actor also called Fancy Bear). LoJax was the first UEFI firmware rootkit confirmed in the wild. It wrote a malicious module into the SPI flash, which is why it could survive operating system reinstallation and even hard drive replacement. It set the bar: firmware was now a real-world attack surface, not a research demo.

ESPecter (2021). Documented by ESET in 2021. ESPecter is a UEFI bootkit that persists on the EFI System Partition and bypasses Windows Driver Signature Enforcement to load its own unsigned driver for espionage. ESET traced its roots back to at least 2012, when it ran as a legacy-BIOS bootkit, and showed it had been quietly upgraded to UEFI and survived undocumented for years.

MoonBounce (2021, disclosed 2022). Found by Kaspersky, first appearing in spring 2021, and attributed with high confidence to APT41, a Chinese-speaking espionage group. MoonBounce was the third known firmware bootkit and the most advanced at the time, hiding in the SPI flash and modifying existing firmware components rather than adding obvious new ones, which made it even harder to spot.

BlackLotus (2023). Analyzed by ESET in early 2023 and the most significant of the four for defenders, because it was the first in-the-wild bootkit to defeat UEFI Secure Boot on a fully updated system. It exploited CVE-2022-21894 ("Baton Drop") to roll the boot manager back to a vulnerable signed version, then disabled HVCI, BitLocker, and Microsoft Defender and installed its payload. It was sold on criminal forums for around USD 5,000, which moved Secure Boot bypass out of nation-state-only territory. The NSA published a BlackLotus mitigation guide in June 2023.

How Secure Boot, UEFI, and TPM defend, and how bootkits bypass them

The platform has three relevant defenses, and the documented bootkits each tell you something about their limits.

UEFI Secure Boot is the front-line control. It requires every bootloader to be signed by a key in the firmware's trusted database, and refuses to run anything that is not. In principle this stops a malicious bootloader cold. BlackLotus shows the gap between principle and practice: the binary it loads is signed, by a key Secure Boot trusts, it is just an old version with a known vulnerability. Because Microsoft had not added those vulnerable-but-signed boot managers to the Secure Boot revocation list (the DBX), Secure Boot happily ran the rolled-back binary. The fix for the vulnerability existed; the revocation that would have made the fix enforceable did not. Bypassing Secure Boot did not require breaking the signature, only abusing one it still accepts.

TPM (Trusted Platform Module) is the hardware chip that supports measured boot: it records cryptographic measurements of each boot component into platform configuration registers (PCRs) as the machine starts. A TPM does not block a bootkit from running. What it provides is evidence: if a boot component changes, the measurements change, and a remote attestation system can detect that the machine no longer matches its known-good boot state. The catch is that this only helps if someone is checking the attestation. A TPM by itself records the tampering; it does not stop it or alert on it.

Firmware write protection is the defense for the SPI flash cases. Hardware features that lock the flash against writes, when the platform vendor implements and enables them, are what stop a LoJax or MoonBounce from writing into the firmware in the first place. The firmware bootkits that exist are, in part, evidence of machines where that protection was absent or misconfigured.

The pattern across all three: the controls work as designed, and the bootkits succeed by finding the seam, an un-revoked signed binary, an attestation nobody reads, a flash chip that was never locked.

Detection and remediation when malware lives below the OS

Detecting a bootkit means looking from outside the compromised boot path, because a tool running on top of it inherits the lie. Three approaches do real work:

• Firmware and boot integrity comparison. Dump the UEFI firmware and the contents of the EFI System Partition and compare them against a known-good baseline for that hardware. Unexpected modules, an altered bootloader, or a firmware image that does not match the vendor's are the signal. This is offline or out-of-band analysis, not a live scan.
• UEFI-aware scanning. Some endpoint tools now include a firmware scanner that reads the SPI flash and the ESP specifically. ESET's firmware scanner is the one that surfaced LoJax. These catch known-bad modules and known patterns, with the usual limit that a novel implant may not match a signature.
• TPM measured boot and remote attestation. Where it is deployed and actually monitored, attestation flags a host whose boot measurements have changed. This is the scalable detection: it does not require pulling each machine apart, but it requires the infrastructure to collect and check the measurements.

Remediation depends on where the bootkit lives, and this is the part that surprises responders. A bootkit in the ESP is removed by rewriting the EFI System Partition and restoring a trusted bootloader, then applying the revocations (for BlackLotus, the DBX updates and the boot policy mitigations Microsoft shipped in 2023) so the rolled-back binary cannot be reloaded. Reimaging the OS alone does not do this; the ESP has to be explicitly cleaned. A bootkit in the firmware is worse: it requires reflashing the SPI flash with a clean vendor image, often using external hardware (an SPI programmer), and in cases where reflashing cannot be trusted to fully clear it, replacing the motherboard. The blunt rule for a SOC: if you genuinely suspect a bootkit, "we reimaged it" is not remediation, and you have to decide whether the disk, the firmware, or the whole board is the unit of trust you are willing to keep.

The bottom line

A bootkit is malware that wins by loading first. It subverts the boot chain, UEFI firmware to bootloader to kernel to OS, so it runs before the operating system and before the security tools that would catch it, which is what makes it both stealthy and persistent. That distinguishes it from a rootkit, which lives within the running OS and usually dies with a clean reinstall. The modern lineage moved from MBR boot sectors to the EFI System Partition (BlackLotus, ESPecter) and into the SPI flash firmware itself (LoJax, MoonBounce), and the firmware cases survive disk replacement entirely.

For a defender, the operational facts are the ones to keep. Secure Boot, TPM, and firmware write protection work, and bootkits succeed by finding the seam each one leaves: an un-revoked signed binary, an attestation nobody reads, a flash chip never locked. Detection has to come from outside the boot path, through firmware integrity comparison and measured-boot attestation, not a live scan. And remediation is dictated by where the malware lives: reimaging clears nothing if the bootkit is in the ESP or the firmware. When you genuinely suspect one, the question stops being "did we reimage the host" and becomes "do we still trust the disk, the firmware, or the board."