Rootkits and Bootkits Guide: Boot Integrity, Detection and Recovery

A host compromised below the operating system can no longer be trusted to report on itself, and every credential, token and log it holds becomes suspect. Rootkits and bootkits are the class of malware that aims for exactly that position: in the kernel, in the boot chain or in system firmware. This guide is written from the defender's and platform owner's side. It covers the boot integrity controls that keep that position out of reach (UEFI Secure Boot, measured boot, TPM attestation, driver signing, memory integrity and the vulnerable driver blocklist), the Secure Boot certificate renewal under way in 2026, how to detect integrity failures, and how to recover when a host has failed them. It is for endpoint, platform and incident response teams; the deeper firmware and boot chain mechanics are in the Firmware and Boot Security Guide.

Key takeaways

• Treat boot integrity as a platform baseline, not a malware product. Secure Boot, measured boot with a TPM, kernel driver signing and memory integrity together close most of the paths to persistent low-level compromise.
• Verify from outside the host. Microsoft notes that malware hiding from the operating system means a PC cannot reliably report its own health; remote attestation of a TPM-signed boot log is the trustworthy signal.
• Patching is not finished until revocation is applied. BlackLotus kept working on patched machines because vulnerable signed boot managers had not been added to the revocation list (DBX).
• Plan the 2026 Secure Boot certificate renewal now. Microsoft's 2011 Secure Boot certificates expire between June and October 2026, and devices that are not moved to the 2023 certificates lose future boot-level security updates.
• Recovery means reimage, firmware check and credential rotation. Removing a low-level implant is not cleaning a file: assume every secret used on the host is exposed, and replace hardware when firmware cannot be verified.

How the attack works

Conceptually, a rootkit gains a privileged position (kernel, boot loader or firmware) that runs before or beneath the security tools meant to observe it, so it can survive reboots and, for firmware implants, even operating system reinstalls. That is the whole defensive point: the higher the code runs in the boot sequence, the less the operating system and EDR can see, and the more the defence has to rely on cryptographic checks made at boot and verified elsewhere. The mapping below uses ATT&CK technique IDs and names only.

Where it shows up

• Windows boot chain: BlackLotus, reported by ESET in March 2023 as the first in-the-wild UEFI bootkit able to bypass Secure Boot on fully updated systems, was sold on forums from at least October 2022. It exploited CVE-2022-21894 (Baton Drop).
• Motherboard firmware: Kaspersky documented CosmicStrand in July 2022, a firmware rootkit found in Gigabyte and ASUS boards using the H81 chipset, which persisted through operating system reinstallation. ESET identifies LoJax (2018) as the first UEFI firmware implant seen in the wild.
• Linux servers: loadable kernel modules are the usual route, which is why module signature enforcement and kernel lockdown matter. Hunting on Linux hosts is covered in the Linux Detection and Response Guide.
• Virtual machines: virtual firmware has the same Secure Boot databases, and Google Cloud has published guidance on the Microsoft certificate expiry for its images.

Impact

NSA records that BlackLotus could disable memory integrity (HVCI), BitLocker and Microsoft Defender. Three consequences follow.

• Telemetry is unreliable: agents and logs inside the operating system may report a healthy machine; absence of alerts proves nothing.
• Disk encryption is undermined: BitLocker protects data at rest, but code that runs before or beneath the OS can reach the unlocked volume. See the Disk Encryption Guide.
• Every identity on the host is exposed: covered next.

Where identity fits

A low-level compromise turns one host into a credential source. Interactive user sessions, cached domain credentials, Kerberos tickets, browser session cookies, primary refresh tokens, service account passwords, API keys in configuration files, SSH keys and machine certificates should all be treated as known to the attacker. A TPM-protected key cannot be exported, but code with kernel control can still use it while it runs. Conditional access policies that trust a "compliant" device are only as good as the attestation behind that verdict. For the credential theft side, see the Credential Dumping Guide; for the response, see the Identity Incident Response Playbook.

Detection

Microsoft's boot process documentation describes the model: measured boot records each component into the TPM, the signed log is sent to a remote attestation service, and unhealthy devices can be quarantined. Detection therefore works best when the verdict is made off the host.

NSA notes that a TPM can detect a boot-level compromise on the next reboot but cannot prevent it; pairing TPM attestation with network access control is what turns detection into containment. For EDR blind spots generally, see the EDR Evasion and Defence Guide.

Metrics that show it is working

• Secure Boot coverage: percentage of UEFI-capable endpoints and servers with Secure Boot enabled in standard mode (target close to 100%, exceptions documented).
• Attestation coverage: percentage of devices whose compliance verdict comes from TPM-backed attestation rather than self-reported settings.
• Certificate renewal progress: percentage of devices with the Windows UEFI CA 2023 in DB and the 2023 KEK applied.
• Memory integrity coverage: percentage of Windows devices with HVCI running, with a list of blocking drivers.
• Revocation status: percentage of devices with the CVE-2023-24932 mitigations applied.

Prevention and hardening

Windows

• UEFI Secure Boot: on, in standard mode. NSA advises against custom Secure Boot key sets except for experienced administrators, because a broken custom configuration is worse than the default.
• Trusted Boot and ELAM: Windows verifies its kernel and boot drivers, and Early Launch Anti-Malware starts before other boot drivers.
• Memory integrity (HVCI): uses virtualisation-based security to enforce kernel code integrity. Enable it in pilot rings first, because incompatible drivers can block it.
• Microsoft vulnerable driver blocklist: blocks signed drivers with known vulnerabilities. Keep it on and supplement it with App Control for Business (WDAC) policy where kernel exposure is high.
• Driver signing: 64-bit Windows refuses unsigned kernel drivers; never leave test signing on in production.
• Compliance policy: in Intune, the Device Health settings "Require Secure Boot to be enabled on the device", "Require code integrity" and "Require BitLocker" use attestation. Baseline guidance is in the Windows Endpoint Hardening Guide and the Device Trust and Posture Guide.

Linux

• Module signing: the kernel documentation describes CONFIG_MODULE_SIG, CONFIG_MODULE_SIG_FORCE and the module.sig_enforce=1 boot parameter; in permissive mode unsigned modules load but taint the kernel.
• Kernel lockdown: available since Linux 5.4, lockdown restricts access to /dev/mem, /dev/kmem and /dev/kcore, unsigned module loading and kexec of unsigned images, and logs attempts to use restricted features.

All platforms

• Remove the precondition: loading kernel code needs administrator rights, so standing local admin removal and fast patching of privilege escalation flaws (T1068) cut the path. See the Endpoint Privilege Management Guide and the Patch Management Guide.
• Firmware updates: treat UEFI updates as security patches with an owner and an SLA.

The 2026 Secure Boot certificate renewal

Microsoft's Secure Boot certificates issued in 2011 are expiring. Microsoft states that devices that do not receive the new certificates keep booting, but can no longer receive new boot-level protections such as boot manager updates and DB or DBX updates.

Dates are as stated by Microsoft and Google Cloud guidance; check Microsoft's page for the current status of the rollout, since by the date of this guide all three dates have passed.

BlackLotus: the patching and revocation lesson

BlackLotus exploited a boot manager flaw that had already been patched. According to NSA, it worked because older, vulnerable boot managers remained validly signed and were not in DBX, so they could be substituted on patched machines. Microsoft's fix for the related bypass, CVE-2023-24932, illustrates what a complete response involves.

1. Install the updates: mitigations shipped from 9 July 2024 but are not enabled by default.
2. Add the new certificate: add Windows UEFI CA 2023 to DB and update the boot manager to one signed by it, then verify.
3. Revoke the old one: add Windows Production PCA 2011 to DBX, then apply the Secure Boot Version Number (SVN) update.
4. Test per device class: Microsoft recommends testing at least one device of each hardware class, and lists known issues with some HP Sure Start, Arm64 and VMware virtual machine configurations and with older boot media.
5. Protect recovery: back up BitLocker recovery keys first, because recovery prompts are possible, and update recovery and installation media, which will stop booting once the old certificate is revoked.
6. Understand roll-back limits: Microsoft states the revocations cannot be undone while Secure Boot is enabled and survive disk reformatting; its recovery route involves disabling Secure Boot, resetting keys to factory defaults and reinstalling.

Microsoft said the enforcement phase would come no earlier than January 2026, with six months' notice. CVE-2023-24932 needs administrative or physical access, so treat it like a privilege escalation flaw, not a low priority. See the Zero-Day and Exploited Vulnerabilities Guide.

Recovery

1. Contain off-host: isolate with network controls and revoke the device's access in identity and MDM, since the on-host agent may be compromised.
2. Preserve evidence: capture disk images and, where possible, a firmware dump before rebuilding. See the Windows Forensic Artefacts Guide.
3. Rotate credentials from a clean device: reset passwords of every user who signed in, revoke refresh tokens and sessions, rotate service account passwords, API keys, SSH keys and machine certificates used on the host, and change the local administrator password. See the LAPS Guide.
4. Rebuild and re-attest: after reimage and firmware update, readmit the host only once attestation reports a healthy boot.
5. Scope the fleet: check other hosts for the same indicators. Broader handling is in the Incident Response Guide.

Framework mapping

Common failure patterns

• Patching without revoking: installing the boot manager update but never applying the DBX revocation, leaving the old signed binaries usable, as BlackLotus showed.
• Trusting self-reported health: compliance built on settings the device reports about itself, rather than TPM-backed attestation.
• Secure Boot disabled "temporarily": switched off for a driver or Linux install and never re-enabled, with no inventory to notice.
• Cleaning instead of rebuilding: running a scanner, declaring the host clean and leaving credentials unrotated.
• Ignoring the certificate renewal: devices left on 2011 certificates, silently losing future boot-level fixes, and recovery media that stops booting once revocations land.

Practitioner checklist

• Inventory Secure Boot state, TPM presence and firmware version for every endpoint, server and VM template.
• Require TPM-backed attestation in device compliance and use it in conditional access for sensitive resources.
• Enable memory integrity and the vulnerable driver blocklist through pilot rings, tracking blocking drivers.
• On Linux, enforce module signing and kernel lockdown where Secure Boot is in use, and review enrolled MOKs.
• Complete the CVE-2023-24932 mitigations, including DBX revocation and the SVN update, after backing up BitLocker keys.
• Track the 2023 Secure Boot certificate rollout to completion and refresh all recovery and installation media.
• Alert on EFI system partition changes outside patch windows and on attestation failures.
• Document a recovery runbook: off-host containment, reimage, firmware reflash, credential rotation and hardware replacement criteria.

Standards and references

• NSA: BlackLotus Mitigation Guide
• Microsoft: How to manage the Windows Boot Manager revocations for Secure Boot changes associated with CVE-2023-24932
• Microsoft: Windows Secure Boot certificate expiration and CA updates
• Microsoft Learn: Secure the Windows boot process
• Linux kernel documentation: Kernel module signing facility
• Linux man-pages: kernel_lockdown(7)
• ESET: BlackLotus UEFI bootkit, myth confirmed
• Kaspersky Securelist: CosmicStrand UEFI firmware rootkit

Related NHI Mgmt Group resources: Firmware and Boot Security Guide · Endpoint Security Guide · Endpoint Hardening Checklist · Malware Guide