Bootkits are firmware-level malware that load before the operating system, surviving OS reinstalls and bypassing antivirus entirely.
How Bootkits Work
A bootkit is malware that compromises the system boot process before the operating system kernel loads. The boot process on a modern computer follows a defined sequence: power-on self-test, firmware initialization, boot loader execution, kernel load, operating system startup. A bootkit inserts malicious code into one of the early stages — typically the firmware (UEFI) or the boot loader — so that the malicious code executes with the highest possible system privileges and is in place before any operating system security mechanisms become active.
UEFI Bootkits
UEFI bootkits modify the firmware itself, embedding malicious code into the EFI System Partition or directly into the SPI flash chip on the motherboard. Because UEFI runs before any operating system component, a UEFI bootkit operates with privileges higher than any kernel-mode rootkit and persists across complete operating system reinstallation. The 2022 BlackLotus bootkit was the first publicly documented UEFI bootkit capable of bypassing Secure Boot on fully patched Windows 11 systems and was sold on cybercrime forums for approximately $5,000.
MBR and VBR Bootkits
On legacy BIOS systems and modern systems running in compatibility mode, bootkits can target the Master Boot Record (MBR) or Volume Boot Record (VBR). MBR bootkits replace the boot sector code with malicious instructions that load before the operating system. The TDL4 / Alureon family was the most prolific MBR bootkit, infecting an estimated 4.5 million machines at its peak in 2011. While MBR-based attacks are less effective against modern UEFI Secure Boot configurations, many enterprise environments retain BIOS compatibility for legacy software support — and those systems remain exposed.
How Bootkits Achieve Persistence
The defining characteristic of bootkits is their persistence model. A bootkit installed in firmware survives every standard remediation action a security team would attempt against a compromised endpoint. Wiping the disk does not remove a UEFI bootkit. Replacing the disk does not remove it. Reinstalling the operating system does not remove it. Even physically replacing the entire computer is required only if the bootkit has propagated to peripherals with their own firmware — which advanced bootkits like LoJax (the Fancy Bear UEFI implant) and MoonBounce have demonstrated.
This persistence model has direct implications for incident response. The standard response playbook for a compromised endpoint — disconnect, reimage, redeploy — does not work against a confirmed bootkit. The asset must be removed from service and physically reflashed at the firmware level, often by sending the device back to the manufacturer or using specialized hardware reflashing tools.
Why Bootkits Are an Executive Risk Category
For most of the past two decades, bootkits were treated as a niche concern handled by deep technical specialists. That treatment is no longer adequate. Three developments have moved bootkits from rare-event status to standing threat in 2025-2026.
The Detection Capability Gap
Standard endpoint detection and response (EDR) tools operate inside the operating system. They monitor processes, file modifications, network activity, and registry changes — all of which occur after the kernel has loaded. A bootkit operating below the kernel is, by design, invisible to EDR. Microsoft Defender, CrowdStrike Falcon, SentinelOne, and Carbon Black all have limited or no native UEFI inspection capability. The detection gap is not a product deficiency; it is structural to the architecture of in-OS endpoint security.
Closing the gap requires specialized firmware integrity tooling — Microsoft Defender for Endpoint UEFI scanning (limited to a subset of devices and configurations), Intel's open-source CHIPSEC framework, Eclypsium, Binarly's enterprise firmware analysis platform — none of which is universally deployed across mid-market environments. The honest assessment for most organizations is that bootkit infections, if they occurred, would not be detected by the current security stack.
The Commoditization Curve
BlackLotus changed the commercial trajectory of UEFI bootkits. Prior to BlackLotus, UEFI bootkit deployment required nation-state-level operational capability. After BlackLotus, working UEFI bootkit code was available to any criminal actor with $5,000 and a forum account. Subsequent variants have followed the standard commoditization curve: source code leaks, copycat implementations, and integration into broader malware-as-a-service offerings. The threat model is no longer limited to government targets.
The Supply Chain Vector
Several recent bootkit incidents have entered environments through compromised firmware update tooling rather than through traditional endpoint compromise. The 2018 LoJax incident involved Fancy Bear (APT28) exploiting LoJack's anti-theft firmware update mechanism. The 2021 MoonBounce attribution suggested a similar supply chain vector for the SPI flash modification. Organizations whose firmware update processes do not include integrity verification of the update payload are exposed to bootkit installation through what looks operationally like a routine firmware patch.
Recent Bootkit Incidents
BlackLotus (2022) — Commercial UEFI bootkit bypassing Secure Boot on Windows 11. Sold for ~$5,000 on cybercrime forums. ESPectre (2023) — Discovered targeting Windows 11 systems with bootkit-style EFI persistence. MoonBounce (2021-2022) — UEFI implant attributed to APT41, demonstrating SPI flash modification at nation-state operational scale. FinSpy (2021) — Commercial bootkit sold to government customers, used in surveillance operations against journalists and dissidents.
How to Defend Against Bootkits
Hardware-Level Defenses
Secure Boot — properly configured and enforced — prevents unsigned bootloader code from executing during system startup. Trusted Platform Module (TPM) measured boot creates a cryptographic record of every component loaded during boot, which can be remotely attested to verify that no unexpected code was executed. BIOS/UEFI passwords prevent unauthorized configuration changes that would disable these protections. For modern enterprise environments, these three controls are the floor — and many mid-market deployments have at least one of them disabled or unconfigured.
Verifying that Secure Boot is enabled and that the TPM is being used for boot attestation should be part of every endpoint configuration baseline. The verification is operationally simple — Group Policy reports, Microsoft Endpoint Manager compliance policies, MDM platform attestation features — but the configuration discipline must be applied consistently across the fleet, including remote workers and BYOD-class assets.
Firmware Update Discipline
Firmware updates from manufacturer-verified sources, applied on a published cadence with integrity verification, are the second-tier control. The discipline matters: firmware updates released to address security vulnerabilities in UEFI implementations need to be deployed within a defined window, just as operating system patches are. Most organizations' firmware update programs are substantially less mature than their OS patching programs — frequently absent of automated rollout, frequently dependent on individual user action, and frequently ignored entirely for systems that are functioning normally.
Forensic Imaging During Incident Response
When the threat model includes possible bootkit infection — high-value individuals, executive devices, systems handling sensitive data, post-incident asset review — incident response must include firmware acquisition alongside standard disk imaging. Tools like CHIPSEC, Binarly, and Eclypsium provide the technical capability; the organizational commitment is to scope this work into the IR runbook for the relevant asset classes rather than treating it as an exotic out-of-scope investigation.
Related Reading
- What is Endpoint Security? — the layer above bootkit defense
- What is Threat Hunting? — the proactive technique that surfaces dormant bootkit infections
- What is Lateral Movement? — what an attacker does after gaining persistent access
- What is DFIR? — the discipline that includes firmware-level forensic acquisition
Bootkits execute before the operating system kernel loads — outside the visibility of every EDR product that operates inside the OS.
How Cloudskope Can Help
Cloudskope's incident response engagements include firmware-level forensic acquisition for cases where standard endpoint forensics fails to explain the observed adversary behavior. Our Microsoft 365 and Azure Security Assessment validates that endpoint Secure Boot and TPM-based measured boot are properly configured across the asset inventory, surfacing the boot-layer controls most organizations have left in a default state.
.png)