What Is a Bootkit? Persistence Below the Operating System
A bootkit infects the boot process so it loads before the OS and survives reinstalls. How boot and UEFI-level malware works, and how Secure Boot defends.
When you press the power button, a lot happens before the operating system exists. Firmware initialises the hardware, finds a bootloader, and hands control up the chain until the OS finally loads and its defenses come online. Every one of those steps runs on trust. Each stage assumes the stage before it was honest. A bootkit breaks that assumption at the root. It plants itself early in the boot chain so that it runs first, and everything that loads afterward, including your antivirus, inherits a machine that was already compromised before it woke up.
This is the deepest kind of persistence most defenders will ever have to think about. A rootkit hides inside a running operating system. A bootkit sits underneath the operating system entirely, which is what makes it both powerful and stubborn to remove.
Why "before the OS" is the whole point
Security software is code. Code has to be loaded and run, and on a normal machine that happens well into the boot sequence. Anything that runs earlier can prepare the ground: patch the kernel as it loads, disable a protection, or hide its own files from the tools that will later come looking.
A bootkit takes the earliest position it can reach and uses it to control what loads next. Because it establishes itself before the operating system, it maps to the Pre-OS Boot technique, Pre-OS Boot (T1542) on MITRE ATT&CK, and its purpose is twofold: run first, and survive.
Survival is the striking part. Most malware dies when you reinstall the operating system. A bootkit does not, because the boot components it infects are not part of the operating-system install. Reformat the disk, reinstall Windows or Linux, and a firmware-resident bootkit is still there, waiting to load your fresh system on its terms.
Legacy boot versus the UEFI era
Bootkits are as old as the boot sector, but the ground has shifted.
The legacy era. Old machines used a BIOS that read a Master Boot Record from the very start of the disk. Classic bootkits overwrote the MBR or the volume boot record so their code ran before the bootloader. This was effective for years, and it is why the boot sector became a defended asset.
The UEFI era. Modern systems replaced BIOS with UEFI firmware and a structured boot process. That closed the old MBR trick but opened new surfaces. UEFI bootkits target the firmware itself, or the bootloader files stored on the EFI system partition, a small partition on disk that the firmware reads to start the OS. The most serious variants write into the SPI flash chip on the motherboard, which means even replacing the hard drive does not remove them.
| Property | Legacy MBR bootkit | UEFI bootkit |
|---|---|---|
| Target | Master Boot Record on disk | Firmware flash or EFI system partition |
| Survives OS reinstall | Sometimes | Yes |
| Survives disk replacement | No | Yes, when resident in firmware flash |
| Primary defense | Boot sector monitoring | Secure Boot and firmware integrity |
| Relative prevalence today | Declining | The current focus |
The direction of travel is clear. As Secure Boot and firmware protections matured, the highest-end implants moved deeper, into the firmware where trust originates.
What a bootkit does once it loads
Running first is a means, not an end. With that position a bootkit typically:
- Tampers with the boot chain so later stages load a modified or unsigned component without complaint.
- Patches the OS kernel in memory as it loads, to disable a protection or install a hook, without changing any file on disk.
- Deploys or protects a payload higher in the stack, often a rootkit or backdoor, and keeps it hidden.
- Re-infects on every boot, so removing the OS-level payload alone is pointless. The next startup restores it.
A firmware-resident bootkit lives outside the operating system and outside the disk. Wiping the drive and reinstalling the OS leaves it untouched, and it will re-establish its payload on the next boot. Remediation may require a verified firmware reflash or, in the worst case, hardware replacement.
How bootkits get installed
Like rootkits, bootkits are a late-stage capability. Reaching the boot chain or firmware needs high privilege, so a bootkit sits at the end of an intrusion, not the start:
- Initial access and escalation to administrator or system level through the usual routes.
- Access to the boot surface, writing to the EFI system partition or, for the deepest implants, to firmware flash.
- Persistence established below the OS.
- Payload protected, with the bootkit ensuring the operator's tools reload every boot.
Writing to firmware flash is often gated by hardware protections, which is why firmware update authentication and flash write-protection matter so much. The delivery that starts the whole chain is still ordinary: a malicious file the user or a service runs. The abused formats behind that first step are catalogued in our File-Format Abuse Atlas, and the actors who deploy firmware-level implants are the kind tracked in our Threat Groups directory, since this level of capability usually belongs to well-resourced groups.
How Secure Boot defends the chain
The core defensive idea is to make every stage verify the next before running it, so trust is checked rather than assumed.
Secure Boot is the UEFI feature that enforces this. At each step the firmware checks the digital signature of the component it is about to load against a set of trusted keys. A bootloader that is unsigned, or signed by a key that is not trusted, does not run. This directly blocks the classic bootkit move of substituting a tampered boot component.
Verified and measured boot goes further. Each stage measures the next into a hardware security chip, building a record of exactly what loaded. That record can be checked, locally or by a remote attestation service, so a tampered boot chain fails verification even if it managed to run.
Firmware update signing and flash protection defend the deepest layer. If the firmware only accepts signed updates and the flash chip is write-protected against unauthorised changes, planting a firmware-resident implant becomes far harder. For the wider picture of protecting this layer, see UEFI Firmware Security Explained.
How to defend against bootkits
The controls stack from the hardware up.
- Enable Secure Boot and keep it on. It is the front-line block against tampered boot components, and it should be enforced, not merely available.
- Keep firmware updated. Firmware patches close the escalation flaws that let attackers reach the boot surface in the first place. Treat firmware like any other patch stream.
- Enforce least privilege. Reaching the boot chain needs high privilege. Denying administrator access to everyday accounts removes the ladder.
- Use a hardware root of trust. A TPM or equivalent enables measured boot and attestation, so a modified boot chain can be detected rather than trusted.
- Attest before trusting. Where the platform supports it, check boot integrity through attestation before granting a device access to sensitive resources.
- Prepare firmware remediation. Know the verified reflash procedure for your hardware in advance, because for a confirmed firmware implant an OS reinstall is not enough.
On-OS antivirus loads after the bootkit and can be blinded by it. Real assurance comes from boot integrity: Secure Boot enforced, measured boot recorded to a TPM, and attestation checked. If the boot chain verifies clean from the hardware up, the layers above it stand on solid ground.
The boot chain, stage by stage
To understand where a bootkit inserts itself, it helps to lay out the stages a modern machine passes through between power-on and a running operating system, because each handoff is a point where trust is passed forward.
Power reaches the board and the firmware begins executing from the SPI flash chip on the motherboard. This firmware initialises memory, the processor, and the buses, and it is the earliest software the machine runs. An implant here is the deepest possible, because it precedes everything and survives disk changes entirely.
The firmware then locates a bootloader. On a UEFI system it reads the EFI system partition, a small partition on the disk holding the bootloader files, and prepares to execute the one it is configured to use. An implant that modifies or replaces a bootloader file on this partition runs after firmware but still before the operating system, and it survives an OS reinstall that does not clean the partition.
The bootloader loads the operating-system kernel and the early drivers it needs. This is the stage a bootkit most wants to influence, because patching the kernel as it loads lets the implant disable a protection or install a hook in memory without changing any file the OS will later scan.
Finally the kernel initialises, brings up its own security features, and starts the services and, eventually, the security software that most people think of as the machine's defenses. Everything at this level runs on a foundation the earlier stages already established. If any of those earlier stages was dishonest, the defenses here inherit a compromised machine and may be blinded to the very thing that subverted them.
Read the chain top to bottom and the design goal of a bootkit is obvious: get as early in that sequence as capability allows, because each stage controls what the stages after it see. The same logic explains why defenders invest so heavily in the earliest links. A check placed at the firmware level governs everything downstream of it, while a check placed only in the operating system governs almost nothing below itself. Security applied late in the chain protects a small slice, and security applied early protects the whole thing, which is why the boot process is defended from the hardware upward rather than from the software down.
What Secure Boot checks at each handoff
Secure Boot maps directly onto that chain by turning each handoff into a verification. Before the firmware runs the bootloader, it checks the bootloader's digital signature against a set of trusted keys held in firmware. A bootloader that is unsigned, or signed by a key that is not trusted, does not run. The trusted bootloader in turn is expected to verify the components it loads, extending the check up the chain so that a tampered stage fails at the point it would otherwise take control.
Measured boot adds a second, complementary record. Rather than only permitting or refusing each stage, it measures each component into a hardware security chip such as a TPM, building a log of exactly what loaded in what order. That record can be evaluated locally or sent to a remote attestation service, so even a boot chain that somehow ran can be judged after the fact against a known-good measurement. Permit-or-deny stops the obvious substitution. Measurement catches the subtler case and gives you something to attest against.
Detection signals
Bootkits are built to be invisible from inside the running operating system, which is exactly why detection leans on evidence from below and beside the OS. Concrete indicators worth collecting:
- Secure Boot reporting disabled or in setup mode when policy says it should be enforced. An endpoint whose firmware settings show Secure Boot off, or its key store cleared, is either misconfigured or has had a protection deliberately removed to allow a tampered component to run.
- Boot measurements that do not match a known-good baseline. When measured boot records components into a TPM, a change in those measurements between boots, with no firmware update or configuration change to explain it, indicates the boot chain loaded something different.
- Attestation failures for a device that previously passed. A platform that supports remote attestation and suddenly fails it has a boot chain that no longer verifies clean.
- Unexpected changes to the EFI system partition. New, modified, or renamed bootloader files on that partition, especially outside an OS or firmware update, are a direct sign of tampering at the bootloader stage.
- Firmware version or configuration that reverts or does not match inventory. A firmware image that does not match what was deployed, or settings that reset themselves, can indicate implant activity in flash.
- Security software that loads late, is blinded, or reports inconsistent early-boot state. When on-OS tools disagree with firmware-level or hardware-level evidence about what happened during boot, trust the lower layer and investigate.
A bootkit runs before the operating system, so evidence gathered from inside that operating system can be manipulated by the very implant you are hunting. When on-OS tooling and firmware or hardware measurements disagree about the boot, the lower layer is the more trustworthy witness. Genuine assurance comes from Secure Boot state, TPM measurements, and attestation, checked from outside the software the implant controls.
How bootkits compare to related threats
Bootkits are one point on a spectrum of below-the-surface threats, and separating them clarifies both the risk and the remedy.
| Threat | Where it lives | Survives OS reinstall | Survives disk replacement | Primary defense |
|---|---|---|---|---|
| Standard malware | Files and processes in the OS | Rarely | No | Endpoint protection, patching |
| Rootkit | Inside the running OS or kernel | Sometimes | No | Kernel integrity, EDR, reinstall |
| Bootloader bootkit | EFI system partition on disk | Yes | No | Secure Boot, partition integrity |
| Firmware bootkit | SPI flash on the motherboard | Yes | Yes | Signed firmware, flash write-protection, attestation |
The table shows why depth changes the remediation. A rootkit hides in the operating system, so a clean reinstall usually clears it. A bootloader bootkit on the EFI system partition survives a naive reinstall that leaves that partition intact, so remediation has to explicitly clean or recreate it. A firmware bootkit in flash survives even a disk swap, which is why its remedy escalates to a verified firmware reflash or, in the worst case, board replacement. Each step deeper removes a remediation option that worked one layer up, and that escalation is the whole reason firmware protections matter so much.
Common misconceptions
Several intuitions about bootkits are wrong in ways that lead to inadequate response.
- "Reinstalling the operating system removes it." A firmware-resident bootkit lives outside the OS and outside the disk, so a wipe and reinstall leave it untouched and it re-establishes its payload on the next boot. Even a bootloader bootkit on the EFI system partition can survive a reinstall that does not clean that partition.
- "Our antivirus would see it." On-OS security software loads after the bootkit and can be actively blinded by it. Assurance about the boot has to come from Secure Boot state, TPM measurements, and attestation, which are evaluated below or beside the software the implant controls.
- "Secure Boot being available means we are protected." Secure Boot only protects when it is actually enforced. A machine where it is available but disabled, or where its key store has been cleared, gets none of its benefit. It is a setting to verify across the fleet, not merely a capability to own.
- "Bootkits are just old MBR viruses." The legacy Master Boot Record trick is largely closed by UEFI and Secure Boot. The current focus is UEFI firmware and the EFI system partition, with the most serious implants residing in SPI flash. Treating the threat as a solved legacy problem misses where it actually operates now.
- "This is only a concern for high-security environments." The capability skews toward well-resourced actors, but the defenses, Secure Boot enforced, firmware patched, least privilege, a hardware root of trust, are ordinary hygiene that every fleet benefits from and that also raise the cost of the whole class of attack.
Frequently asked questions
What is the difference between a bootkit and a rootkit? A rootkit hides inside a running operating system, often in the kernel, to conceal activity and maintain access. A bootkit sits underneath the operating system in the boot process, so it runs before the OS loads and can control what the OS and its defenses see. Bootkits achieve deeper persistence, because the boot components they infect are not touched by an OS reinstall, and the deepest ones survive a disk replacement.
Can a bootkit survive reinstalling Windows or Linux? Yes, in general. A firmware-resident bootkit lives in the motherboard flash, outside the disk entirely, so reinstalling the OS does not remove it. A bootloader bootkit on the EFI system partition can also survive a reinstall that leaves that partition intact. This survival is a defining property of the threat and the reason an OS reinstall is not sufficient remediation for a confirmed firmware implant.
Does Secure Boot stop all bootkits? Secure Boot blocks the classic move of substituting an unsigned or untrusted boot component, which stops a large part of the bootloader-level threat when it is enforced. It is strongest combined with measured boot and attestation, which catch tampering that manages to run, and with signed firmware updates and flash write-protection, which defend the deepest layer. It has to be actually enforced, and its trusted keys kept sound, to deliver that protection.
How do you detect something that runs before the operating system? You rely on evidence from below and beside the OS rather than from inside it. Secure Boot state, boot measurements recorded to a TPM, and remote attestation give a view of what loaded that the implant cannot easily forge. On-disk signals such as unexpected changes to the EFI system partition, and firmware that does not match inventory, add to the picture. When on-OS tools disagree with these lower-layer measurements, the lower layer is the more trustworthy source.
How does a bootkit get installed in the first place? It is a late-stage capability. Reaching the boot chain or firmware needs high privilege, so a bootkit typically sits at the end of an intrusion that already achieved administrator or system access through ordinary means. From there the attacker writes to the EFI system partition or, for the deepest implants, to firmware flash. Writing to flash is often gated by hardware protections, which is why firmware update authentication and flash write-protection are such important controls.
What maps a bootkit to MITRE ATT&CK? Bootkit behaviour falls under Pre-OS Boot (T1542) and its sub-techniques, including System Firmware (T1542.001) for implants in firmware and the related sub-techniques covering bootloader and boot-component tampering. These describe adversary techniques for establishing themselves in the boot process below the operating system.
What should remediation look like for a confirmed firmware implant? An OS reinstall is not enough. Remediation may require a verified firmware reflash using a known-good image, performed through a trusted process, and in the worst case hardware replacement when the flash cannot be trusted to be cleaned. Knowing your hardware's verified reflash procedure in advance is part of being prepared, because it is difficult to improvise during an active incident.
Bootkits matter because they attack the assumption every defense rests on: that the machine started honestly. Get the boot chain right, with Secure Boot enforced, firmware patched, and a hardware root of trust checking each stage, and you take away the position a bootkit needs. Leave it unverified, and no amount of security software above it can be fully trusted, because something got there first.
Related guides
Sources & further reading
Related guides
- Malware Persistence Techniques: How Malware Survives Reboot
How malware survives a reboot using autostart, services, scheduled tasks, and registry keys, plus the process-chain and event-log signals that hunt each one.
- What Is a Backdoor? Hidden Access and Web Shells Explained
A backdoor is a hidden way back into a system that skips normal authentication. How backdoors and web shells work, how they persist, and how to detect them.
- What Is a Rootkit? Kernel and User-Mode Stealth Explained
A rootkit hides other malware by tampering with the operating system itself. How kernel and user-mode rootkits work, the hiding tricks, and how to detect them.