Rootkits & Bootkits

The whole story is the boot stack

To understand rootkits you have to understand where they install. Malware that runs as a normal user can only see what a normal user can see — the OS will happily report it to any process that asks. Malware that installs deeper into the stack can intercept those questions and lie about the answers.

User-mode vs kernel-mode rootkits

A "rootkit" is a tool that hides the attacker's presence on a system. The name comes from Unix — "kit of tools to keep root access" — and predates the malware era. The dividing line that matters: which side of the user/kernel boundary the rootkit installs on.

The user-mode/kernel-mode line is why Microsoft made Windows kernel driver signing mandatory in 2007 (and tightened it repeatedly since). To install a kernel rootkit on modern Windows you either need an Authenticode-signed driver (and most reputable CAs won't sign one for unknown developers), a stolen / leaked signing key, a privilege-escalation vulnerability that lets you load an unsigned driver, or a "bring your own vulnerable driver" attack (load an old, signed-but-buggy driver, then exploit it from user mode).

Bootkits — rootkits that run before the OS does

A bootkit installs in the bootloader (or, in the BIOS era, the Master Boot Record). It runs before the OS kernel does and has the opportunity to patch the kernel as it loads — defeating kernel-level integrity checks because the integrity checks themselves are now compromised before they get to run.

The classic 2010s bootkits (TDL3, TDL4, Mebroot) targeted the MBR. Microsoft killed the MBR vector by requiring UEFI + Secure Boot starting with Windows 8. UEFI Secure Boot checks the signature of the bootloader before running it; an unsigned bootkit can't even start.

That worked for about ten years. Then came the next generation:

• BlackLotus (2022) — the first publicly documented UEFI bootkit that bypassed Secure Boot on fully-patched Windows 11. Sold on Russian forums for $5,000. Exploited a year-old vulnerability in a Microsoft-signed bootloader (CVE-2022-21894) that wasn't on the UEFI revocation list because the list isn't easy to update at scale.
• CosmicStrand (Kaspersky, 2022) — UEFI implant that lived inside motherboard firmware itself, surviving OS reinstalls and hard-drive replacements. Origin unclear; victims clustered in China and Iran.
• MoonBounce (Kaspersky, 2022) — APT41-attributed UEFI implant in the SPI flash chip. Persisted across OS reinstalls.

UEFI implants — the deep end

A UEFI implant lives in the motherboard's flash chip, which contains the firmware the CPU runs the moment it powers on. From there it can do anything — load malicious bootloaders, patch the OS kernel, hide itself from any operating-system-level scanner. It survives OS reinstalls (the OS doesn't touch flash) and even hard-drive replacements (the implant isn't on the disk).

Notable UEFI implants:

• LoJax (ESET, 2018) — first publicly documented in-the-wild UEFI rootkit. Attributed to Sednit / Fancy Bear (Russia, GRU). Repurposed a legitimate anti-theft tool (Computrace's LoJack) to call out to attacker C2.
• MosaicRegressor (2020) — Chinese-attributed UEFI implant deployed against diplomatic targets. Hijacked Hacking Team's leaked UEFI code from the 2015 Hacking Team breach.
• ESPecter (2021) — bootkit that patched the Windows kernel from the ESP (EFI System Partition).
• BlackLotus, CosmicStrand, MoonBounce — as above.

The defensive story for UEFI is grim. Detection requires extracting the flash chip's contents (hardware tooling or trusted-OS access). Removal requires re-flashing — which itself might be intercepted by the implant. For high-stakes environments the only reliable answer is "replace the motherboard."

The Sony BMG case — the rootkit that taught the public the word

In 2005, Sony BMG shipped audio CDs that — when inserted into a Windows computer — silently installed a copy-protection tool called XCP. XCP used kernel-level rootkit techniques to hide its own files and processes from the user, so they couldn't easily disable or remove the DRM.

The hiding mechanism turned out to be exploitable: any malicious software could hide itself by simply naming its files with the magic prefix XCP looked for ("$sys$"). Multiple actual malware families used this. Class-action lawsuits, U.S. FTC settlement, ~22 million CDs recalled. Sony's chief executive eventually issued a public apology.

The cultural impact was bigger than the technical one. The phrase "rootkit" entered mainstream press for the first time, and the precedent — that a major corporation might willfully ship rootkit-style software to its customers — made the term ominous in a way that purely criminal rootkits never had.

Modern defenses

• Secure Boot (UEFI) — the firmware refuses to run an unsigned bootloader. Required for Windows 10/11; available on most Linux distros.
• Measured Boot — the firmware records cryptographic measurements of every stage as it boots, stored in the TPM. Remote attestation can verify those measurements match a known-good configuration.
• Driver signing — the OS refuses to load unsigned kernel drivers. Microsoft enforces this on Windows x64; macOS enforces system-extension signing; Linux supports Lockdown mode.
• HVCI / Virtualization-Based Security — the OS runs the kernel inside a hypervisor and uses hardware to prevent the kernel from making arbitrary changes to its own code. Defeats most kernel rootkits even if loaded.
• Anti-rootkit scanners that boot from external media — the only way to detect deep rootkits is to ask the question from outside the compromised system.
• Firmware update discipline — OEMs ship UEFI firmware updates; most users never apply them. Patch your firmware.
• For nation-state threat models — assume any device that was out of your physical control could have a firmware implant. Treat it as suspect.