Aditya Sharma

Posted on Oct 11

What Is a Bootkit? How Can Malware Run Before Your Operating System Even Starts?

#cybersecurity #infosec #security

Reinstalling Windows does not always remove a sufficiently sophisticated attacker from a compromised machine.

That statement deserves a second read. We tend to think of reinstalling an operating system as wiping the slate clean. But the operating system is not the first thing that runs when a computer powers on. Before Windows loads, before any security software initializes, before even the user's login screen appears, a chain of software components executes. If an attacker can implant code into that earlier chain, reinstalling the OS above it may change very little. A typical Windows reinstall replaces the OS files but may leave the EFI System Partition and its boot components untouched. Restoring a truly clean boot chain requires ensuring those earlier components are also known-good, not just the OS above them.

Malware that achieves this is called a bootkit. Its defining characteristic is not sophistication or stealth alone, but position: it executes before the software that is supposed to protect the system has any chance to run.

Before the Operating System: What Actually Happens

To understand why this matters, the boot process needs to be concrete rather than abstract.

When a modern computer powers on, the first software to execute lives in the firmware, a low-level program stored in a chip on the motherboard. On systems built in the past decade or so, this firmware implements the Unified Extensible Firmware Interface, or UEFI. UEFI initializes hardware, performs basic hardware checks, then looks for a bootable storage device.

What it finds there is not Windows directly. UEFI looks for a special disk partition called the EFI System Partition, a small FAT32-formatted area that contains executable files for boot management. On a Windows system, this partition holds the Windows Boot Manager, a signed EFI binary typically at \EFI\Microsoft\Boot\bootmgfw.efi. UEFI hands control to the Boot Manager.

The Boot Manager then finds and launches the Windows OS loader (winload.efi), which loads the Windows kernel, its early drivers, and the initial components of the operating system environment. Only after all of that is in place does Windows begin enforcing its own security controls, loading antivirus software, initializing user sessions, and doing the work we associate with a running operating system.

The sequence matters:

UEFI firmware
    ↓
Windows Boot Manager (EFI System Partition)
    ↓
Windows OS Loader
    ↓
Windows Kernel
    ↓
Operating system security controls

Each component executes in this order, and each stage depends on the integrity of what came before.

Execution Order as a Security Boundary

This sequence establishes a security hierarchy. Any component that runs earlier in the chain has the opportunity to shape the environment for everything that follows. That is not a flaw in the design; it is inherent to how a staged boot process works.

The critical implication: if an attacker can insert code into an early stage of this chain, that code executes before the operating system's security controls exist. It runs with privileges that no user-level malware possesses. It can modify memory, intercept system calls, alter the kernel's view of the filesystem, or disable security components before those components have initialized. By the time Windows is fully running and security software starts scanning for threats, the bootkit has already established itself.

This is qualitatively different from a rootkit that hides in the operating system itself. A bootkit does not need to defeat Windows security; it operates before Windows security is even a concept.

It is also distinct from threats that implant directly into the motherboard's UEFI firmware chip. A firmware implant modifies the UEFI program itself, surviving even a complete disk replacement. A bootkit, in the sense discussed here, operates at the level of the EFI System Partition and boot components on disk, which is still deeply persistent but is not the same category of threat. The distinction matters for understanding what remediation looks like.

How a Bootkit Gets Installed

A bootkit does not arrive on a system through magic. Installing one requires an existing foothold and typically elevated privileges. The attacker needs administrative access to write to the EFI System Partition, modify boot configuration, or install a machine owner key into firmware variables.

The attack lifecycle generally looks like this: the attacker gains initial access through some conventional means, a phishing email, an exploited vulnerability, or compromised credentials. From that position, they escalate privileges if necessary, then execute a bootkit installer. The installer places malicious components on the EFI System Partition and modifies boot configuration so that the malicious component executes during startup.

On subsequent reboots, the bootkit executes before the operating system. It may load a kernel driver that tampers with the operating system as it initializes, intercept system functions, hide files or registry keys associated with the attacker's infrastructure, or disable security components entirely. The operating system that eventually loads appears to function normally, but it is operating under conditions the attacker has already arranged.

Persistence is the key advantage. Conventional malware can often be removed by cleaning infected files, scanning and disinfecting the system, or reinstalling the OS. A bootkit that has embedded itself in the boot chain survives all of those steps, provided the EFI System Partition and its components are not also cleaned and restored. Even a fresh OS installation is loaded by the same compromised boot components if the partition they live on is left intact.

Secure Boot: What It Is and What It Guarantees

Secure Boot was designed specifically to address this category of threat. Understanding it requires distinguishing it from related but distinct technologies.

Secure Boot is a mechanism in UEFI firmware that verifies the cryptographic signature of each component before executing it. When a system with Secure Boot enabled starts, the firmware checks whether the Windows Boot Manager's signature validates against a database of trusted keys stored in the firmware. If the signature is invalid or the component is not trusted, the firmware refuses to execute it.

This extends through the chain: the Boot Manager verifies the OS loader, and the OS loader verifies kernel components. The idea is that at each step, trust is explicitly established through cryptographic signatures before execution proceeds.

The Trusted Platform Module, or TPM, is a separate but related component. A TPM is a dedicated security chip that can store cryptographic keys and support platform integrity measurements. Measured Boot is a feature that uses the TPM to record cryptographic hashes of each boot component as it executes. Windows itself, working with the TPM, logs these measurements to a record called the Boot Configuration Log. Those measurements can be checked later to detect whether any boot component differed from what was expected. Measured Boot does not necessarily prevent a compromised component from running, but it creates a record that can be audited.

Neither Secure Boot nor TPM-based Measured Boot is the same as Windows Defender or conventional endpoint protection software. Antivirus tools operate within the running operating system. Before the kernel initializes, they have no visibility into what has occurred in earlier boot stages, which means a bootkit that acts before that point can potentially disable or evade them before they load. That said, endpoint protection can still observe artifacts after the OS is running: changes to EFI System Partition files, unexpected kernel drivers, registry modifications, and event log entries that reflect what the bootkit did during setup or installation.

Secure Boot's protection rests on a fundamental premise: only code signed by trusted keys should run during boot. The question of who holds those trusted keys, and how the trust decisions are made, turns out to be where the complexity lives.

BlackLotus: When Secure Boot Was Not Enough

In March 2023, researchers at ESET published an analysis of a bootkit they named BlackLotus. It was, as the researchers documented, the first publicly confirmed in-the-wild bootkit capable of bypassing UEFI Secure Boot on fully patched Windows 11 systems.

The critical word is "bypassing," but the mechanism requires precise explanation.

BlackLotus did not break the cryptography of Secure Boot. It did not directly modify UEFI firmware. Instead, it exploited a vulnerability in legitimate, Microsoft-signed Windows boot components to subvert the Secure Boot policy from within the trusted environment.

The specific vulnerability is CVE-2022-21894, known as "Baton Drop." Microsoft issued a patch for this vulnerability in January 2022. The patch addressed the flaw in future versions of the Windows Boot Manager. But Secure Boot's trust model contains a structural challenge: the list of revoked, no-longer-trusted components, called the Secure Boot DBX database, must also be updated to exclude old vulnerable versions. In the period when BlackLotus was operating in the wild, those older signed Windows Boot Manager binaries had not yet been added to the revocation list.

This created an opening. BlackLotus's installer brought its own copies of the older, vulnerable-but-validly-signed boot manager binaries onto the target system. Because Secure Boot still trusted those older signatures, they were permitted to execute. The vulnerable code could then be exploited to truncate the Secure Boot policy, effectively stripping its enforcement. With Secure Boot policy neutralized, BlackLotus enrolled its own Machine Owner Key into the firmware's key database, allowing its self-signed malicious components to be trusted on subsequent reboots.

In May 2023, Microsoft released CVE-2023-24932, a separate Secure Boot bypass vulnerability that addresses the attack path BlackLotus used to circumvent the earlier CVE-2022-21894 patch. The fix updates the Windows Boot Manager and adds the vulnerable binaries to the DBX revocation list. Importantly, the initial update shipped with protections disabled by default, because enabling it requires irreversible changes to the boot environment that can render older boot media, recovery drives, and installation media unbootable. Microsoft deployed the full mitigations in a staged rollout across several phases. Simply installing Windows updates was not sufficient to close the attack path; administrators had to follow explicit configuration guidance to enable and complete the protections.

The attack chain, documented by ESET and independently confirmed by Eclypsium, required:

Running an installer with administrative privileges on the target system.
The installer placing malicious files on the EFI System Partition and placing old vulnerable Boot Manager binaries alongside them.
On first reboot: exploiting CVE-2022-21894, enrolling the attacker's key, then rebooting again.
On all subsequent reboots: the self-signed bootkit executing early in the boot process, loading a kernel driver and a user-mode HTTP downloader for command-and-control communication. The bootkit was capable of disabling BitLocker, Hypervisor-Protected Code Integrity (HVCI), and Windows Defender. The NSA and CISA released a mitigation guide specifically addressing the threat.

This is not a claim that every Windows computer was or is vulnerable to BlackLotus. The attack required administrative access to install. The specific bypass depended on the revocation state of firmware databases, which has since been addressed through security updates and the staged CVE-2023-24932 remediation process. But the case is instructive because it demonstrated a specific and documented mechanism by which Secure Boot could be undermined using trusted, signed components rather than by breaking cryptography.

Remediation was also more complex than removing malware files. Simply deleting the bootkit's components from the EFI System Partition would not restore a clean boot chain. Defenders needed to verify the integrity of boot components, apply the CVE-2023-24932 mitigations including DBX revocation updates to block the vulnerable signed binaries, and in some cases rebuild the system from trusted media to establish a known-good starting state.

Why Signed Does Not Mean Safe

BlackLotus illustrates a principle that goes beyond that specific bootkit: the integrity of Secure Boot depends not just on whether components are signed, but on whether the list of trusted and revoked components is accurate and up to date.

Secure Boot's DBX revocation database is the mechanism for excluding previously trusted but now-dangerous components. If revocation is not applied promptly, validly signed but vulnerable binaries remain usable as attack tools even after patches are issued for the underlying vulnerability. This creates a gap between "software vulnerability patched" and "attack vector actually closed" that can persist for as long as revocation updates are delayed or not fully enabled.

It is also worth distinguishing between a bootkit that operates on the EFI System Partition and a threat that modifies the UEFI firmware chip itself. LoJax, documented by ESET in 2018 and attributed to an APT group, was the first publicly documented in-the-wild UEFI rootkit to achieve persistence by modifying firmware modules on the chip. Such a threat survives disk replacement and potentially requires specialized tools to detect and remediate. BlackLotus did not operate at that layer, which, while still serious, placed it in a different and somewhat more remediable category.

Detection and Recovery

Detecting a bootkit is inherently difficult because the threat operates in an environment that most security tools cannot inspect during startup. Endpoint protection software that runs within Windows has no visibility into what happened before the kernel initialized. However, it can observe artifacts after the fact: unexpected files or timestamps in the EFI System Partition, registry changes that reflect bootkit installation, event log entries showing that Defender or HVCI was disabled, and the presence of unauthorized kernel drivers. Microsoft Defender for Endpoint can generate alerts for known BlackLotus indicators, though a bootkit that successfully disables Defender before those detections fire will reduce or eliminate that visibility. TPM-backed Measured Boot matters here precisely because its logs record what happened before the OS loaded, and those records exist outside the environment the bootkit can easily tamper with.

Indicators that defenders may be able to observe include:

Unexpected files in the EFI System Partition, particularly in directories that legitimate Windows boot processes do not use. BlackLotus, for example, stored components in a directory that is not part of the normal Windows boot file layout.

Changes to UEFI firmware variables, including unexpected entries in the Machine Owner Key database or Boot Services key list.

Disabled security features that were previously enabled, including HVCI or Windows Defender, without a corresponding user action.

Network activity from early boot components or kernel drivers that would not normally communicate externally.

For suspected boot-chain compromise, the appropriate response is not simply to run an antivirus scan. Restoring a clean boot environment involves verifying the integrity of boot components, applying firmware variable updates including DBX revocation updates, and potentially rebuilding the system from trusted installation media to establish a known-clean starting state. Guidance from CISA, the NSA, and Microsoft should inform incident response in cases where bootkit infection is suspected.

Preventive measures are clearer:

Keep UEFI firmware and operating system boot components updated, and follow the specific configuration steps Microsoft published for CVE-2023-24932. Applying the Windows update alone does not automatically enable all Secure Boot protections; the staged rollout requires deliberate action.

Maintain Secure Boot in its enabled configuration. Disabling Secure Boot to accommodate other use cases removes this protection. Review whether those tradeoffs are necessary.

Apply Windows security updates promptly. CVE-2022-21894 was patched in January 2022; systems that had applied that update and subsequently completed the CVE-2023-24932 mitigations were in a substantially better position when BlackLotus appeared in the wild.

Consider TPM-backed Measured Boot where appropriate, and review whether platform integrity measurements are being logged and monitored.

Limit administrative privileges. BlackLotus required administrative access to install. Reducing unnecessary administrative access limits the opportunities for initial installation.

The Chain of Trust Is Only as Strong as Its Weakest Link

The Windows boot process is built as a chain of trust. Each component verifies the next before passing control. The chain is supposed to ensure that by the time Windows is running, every step that preceded it has been verified as legitimate.

Bootkits attack this model by compromising an early link. Once a malicious component has executed and established its position in the startup sequence, it can shape every subsequent stage. Security controls that the operating system relies on can be disabled, hidden, or subverted before they initialize.

Secure Boot addresses this threat by requiring cryptographic verification at each step. But, as BlackLotus demonstrated, the value of that verification depends on whether the trusted component list is accurate, current, and correctly maintained. A vulnerability in a signed boot component that remains trusted because revocation has not been applied is an opening that can be exploited without breaking any cryptographic primitive.

The deeper lesson is about where security boundaries actually exist. We tend to locate security in the operating system, in the software layer that users interact with. But an operating system that loads on top of compromised boot components is building on an untrustworthy foundation. Security must begin before the operating system. When the mechanism that starts the OS cannot be trusted, everything built on top of it is suspect too.

DEV Community