A rootkit is malware designed to hide itself or other malicious activity on a system, usually after the operating system has started. A bootkit is a rootkit that targets the boot process so it can load before the operating system and persist more deeply. Defenders look for tampering with boot components, firmware, and early-startup trust chains.
How Rootkits and Bootkits Differ in Where They Persist
A rootkit is built to conceal malicious presence or activity after the operating system is running, so its value comes from hiding in a live system. A bootkit shifts that persistence earlier, into the boot chain, which makes it harder to detect and remove because the system may already be compromised before normal security controls fully load.
The practical difference is not just “early versus late.” A rootkit can often be looked for through running-process tampering, kernel interference, or stealthy hooks in the loaded OS. A bootkit changes the trust boundary by tampering with boot components, boot loaders, or firmware-adjacent stages, so defenders must treat the startup sequence itself as part of the attack surface.
That distinction also affects cleanup. A rootkit removal effort can sometimes start with an offline scan or a known-good boot environment. A bootkit usually demands deeper validation of the boot path, because if the early chain is compromised, the operating system may be reporting from an untrusted starting point. For boot-focused detection and hardening, the Firmware and Boot Security Guide is the most directly relevant internal reference.
Why Bootkits Are Harder to Defend Against Than Ordinary Rootkits
Bootkits are more dangerous in practice because they can sit underneath security tools that expect the operating system to be trustworthy. If the malware runs before the OS, it may influence what the OS sees, what defenders can inspect, and what evidence is left behind. That makes integrity failures in the boot sequence especially important, not just the malware family name.
Rootkits and bootkits also differ in what defenders should trust first. A rootkit is often visible only indirectly through anomalies in running state, while a bootkit can invalidate the entire startup trust chain. That is why defenders should look for tampering with boot loaders, signed boot components, firmware settings, and measured or verified boot evidence. NIST’s control catalog reinforces the need for access control, authentication, and system integrity checks in exactly this kind of scenario, and the NIST SP 800-53 Rev 5 Security and Privacy Controls is a useful external reference point.
For threat modelling and detection, the right mental model is the attacker’s control of startup trust. The MITRE ATT&CK Enterprise Matrix helps map how persistence, defense evasion, and privileged control can combine when malware survives reboots or manipulates the platform before normal visibility exists.
What Defenders Should Check First When They Suspect a Bootkit
When suspicion is high, start with the boot path, not the logged-in desktop. Confirm Secure Boot status, boot order, firmware configuration, and any evidence of unsigned or unexpected boot-stage code. If the platform supports measured boot or TPM-backed attestation, compare the recorded measurements with a known-good baseline before trusting what the operating system reports.
That same first-pass logic applies to recovery. If the system still boots, preserve evidence before remediation, because rebooting or “cleaning” too early can erase the very indicators that show how deeply the compromise reached. If the device cannot be trusted, reimage or restore from known-good media rather than trying to remove every component in place. For broader hardening of startup trust and firmware posture, the Malware Guide provides a useful malware classification anchor, while the boot-specific guide above covers the deeper startup layer.
Risk and Threat Considerations
Bootkits create a higher-impact trust failure than ordinary user-mode malware because they can compromise the platform before security controls, logging, and endpoint tooling are fully active. That makes them especially concerning on systems where a single compromised boot path can undermine later detection, authentication, and recovery assumptions.
Failure mechanism: The attacker persists in the boot chain or firmware-adjacent startup path, so every later layer inherits an untrusted foundation and may be monitored or altered by the malware itself.
Impact: Defenders can lose visibility into the true state of the host, remediation can become unreliable, and the compromise may survive routine OS-level cleanup or reinstallation until the startup trust chain is rebuilt.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Bootkits can survive cleanup when startup trust is not reset. |
| Recommendation — Rebuild the startup path from trusted media before returning the host to service. | ||
| NIST SP 800-53 Rev 5 | SI-7 — Software, Firmware, and Information Integrity | Bootkits directly threaten platform integrity and trusted boot state. |
| Recommendation — Validate boot and firmware integrity before trusting system telemetry. | ||
| MITRE ATT&CK | T1542 — Pre-OS Boot or Logon Autostart Execution | Bootkits persist before the OS and fit pre-OS persistence techniques. |
| Recommendation — Hunt for pre-OS persistence and verify boot-chain integrity evidence. | ||
Practitioner Guidance
What to verify: Verify whether the compromise is confined to the operating system or whether boot components, firmware settings, or pre-OS integrity checks are involved. That distinction determines whether standard malware response is enough or whether you need platform-level recovery.
Decision rule: If you cannot establish trust in the boot path, treat the host as untrusted and rebuild from known-good media rather than relying on in-place cleanup. If boot integrity evidence is intact, you can usually scope the response more narrowly to the OS and runtime layer.
Practitioner takeaway: Rootkits are primarily a concealment problem inside a running system, but bootkits are a trust problem at the foundation of the system, so the response must start by validating the startup chain before you trust anything else.