UEFI Firmware Security: Secure Boot, TPMs and Bootkits

Every security control on a computer assumes the layer beneath it is honest. The antivirus trusts the kernel, the kernel trusts the bootloader, the bootloader trusts the firmware, and the firmware trusts whatever verified it, if anything did.

Firmware sits at the bottom of that stack. Code that runs there executes before the operating system exists, can modify the kernel as it loads, and lives in a flash chip on the motherboard rather than on the disk. Reinstalling the operating system does not remove it. Replacing the disk does not remove it. The EDR agent that would detect it runs on top of it and can be lied to.

This guide covers how the boot chain is protected, what the pieces of Secure Boot actually do, where measured boot fits, what real implants have done, and the practical steps that matter.

Scope: What Is a Bootkit owns the malware category, What Is a Rootkit owns kernel-level stealth, and Encryption Explained owns disk encryption. This page owns the firmware layer and its protections.

The boot chain

Roughly, on a modern x86 platform:

1. Power on. The CPU begins executing firmware from the SPI flash chip.
2. Hardware root of trust. On platforms with Intel Boot Guard or the AMD equivalent, keys fused into the chipset verify the initial boot block before it runs. This is the only layer that can check the firmware itself, because everything above it is the firmware.
3. Platform initialisation. Memory, PCIe, and the rest of the hardware are brought up. Option ROMs from add-in cards may execute here.
4. DXE and boot device selection. Drivers load, the firmware locates a bootloader on the EFI system partition.
5. Bootloader. Verified by Secure Boot if enabled, then loads the kernel.
6. Kernel and operating system. Now the familiar controls exist.

Steps 1 through 4 happen before any security software you installed. That is the entire reason firmware matters.

Secure Boot

Secure Boot verifies signatures at each load. The policy lives in four firmware variables.

Variable	Role
PK (Platform Key)	The root. Controls who may modify KEK. Usually the manufacturer's, replaceable in setup mode.
KEK (Key Exchange Keys)	Controls who may modify db and dbx. Typically includes the manufacturer and Microsoft.
db	Allow list: certificates and hashes permitted to load.
dbx	Deny list: revoked certificates and hashes.

A binary loads if it matches something in db and matches nothing in dbx. The deny list wins, which is what makes revocation possible.

For Linux, most distributions ship a small first-stage loader called shim, signed by the Microsoft UEFI certificate that appears in db on nearly all consumer hardware. Shim then verifies the distribution's own bootloader against a key it carries, and supports enrolling additional keys locally through the Machine Owner Key mechanism. That is how a distribution boots on hardware whose firmware has never heard of it.

Where Secure Boot fails:

• A validly signed but vulnerable binary. If a trusted bootloader has a flaw that lets it load arbitrary code, an attacker ships that old signed binary and exploits it. Signature verification passes, because the signature is real. This is the mechanism behind the most significant bypasses, and the fix is revocation rather than patching, because the vulnerable version keeps its valid signature forever.
• Revocation lag. Adding a hash to dbx requires that the update reach every machine's firmware variables, and dbx updates have historically been slow and cautious because a mistaken revocation bricks the ability to boot.
• Physical access. Firmware settings can be changed at the console unless a firmware password is set, and Secure Boot can simply be turned off.
• It only covers load time. Code that passes verification and is then exploited at runtime is not re-checked.

Measured boot and the TPM

Measured boot answers a different question. Instead of deciding what may load, it records what did.

As each component loads, its hash is extended into a platform configuration register in the TPM. Extension is one-way: the new register value is a hash of the old value concatenated with the new measurement, so the sequence cannot be forged or rewound by later code. Different registers hold different parts of the boot: firmware code and configuration, option ROMs, the boot manager, and Secure Boot policy state among them.

Two ways to use those measurements:

Sealing. A secret is encrypted such that the TPM will only release it when the registers hold specific values. Full disk encryption uses this: the volume key is sealed to a set of measurements, so a machine whose boot chain has been modified does not unseal the key and the disk stays encrypted. This is what converts a passive record into an enforcement mechanism, and it is the reason a TPM-bound disk encryption setup is meaningfully stronger than a password-only one.

Attestation. The TPM signs a quote of the register values with a key that can be verified remotely, letting a server decide whether a machine's boot state is acceptable before granting access. This is the firmware-level input to the device posture signals described in Zero Trust Architecture Explained.

Adding a PIN to a TPM-sealed volume key closes the gap where an attacker with the physical machine simply boots it and lets the TPM release the key to an unmodified but attacker-controlled session.

What real implants have done

The category is genuinely rare, and the examples that exist are instructive.

LoJax (2018). Documented by ESET and attributed to the Sednit group. It wrote a malicious module into the SPI flash on systems whose flash protections were misconfigured or absent, giving persistence that survived operating system reinstallation and disk replacement. It was the first UEFI rootkit confirmed in the wild.

MosaicRegressor (2020) and MoonBounce (2022). Firmware implants used in targeted espionage, both delivering a payload into the operating system from below it.

CosmicStrand. An implant found in modified firmware images on specific motherboard models, hooking the boot process to inject code into the Windows kernel.

BlackLotus (2023). Different in character because it was sold on criminal forums rather than used by one actor, and because it bypassed Secure Boot on fully patched systems by shipping a signed, vulnerable Windows binary and exploiting it. That combination, commodity availability plus a bypass that patching did not fix, is why it drew the attention it did. Two qualifications matter: it is not an initial access vector, since deploying it requires privileged or physical access to the machine first, and the response was revocation of the vulnerable boot managers, which is slower and riskier than patching.

The pattern across all of them: firmware compromise is expensive to develop, extremely persistent once achieved, and mostly used against targets worth that investment. Ordinary criminal operations still find it cheaper to phish somebody.

System Management Mode

One more layer worth knowing about. SMM is an execution mode more privileged than the kernel or a hypervisor, entered through a system management interrupt, running code from a memory region the operating system cannot read. It exists for power management, hardware emulation and error handling.

Its properties make it a valuable target: code running there is invisible to the operating system, and vulnerabilities in SMM handlers have repeatedly allowed escalation from the kernel into the most privileged context on the machine. The protections are the firmware vendor's job, delivered through firmware updates, which is one more reason updates matter at this layer.

Practical defenses

For an individual machine, roughly in order of value per unit of effort:

• Apply firmware updates. The single most useful action, and the most neglected. Vendor tools handle this on Windows; on Linux, fwupd with the Linux Vendor Firmware Service covers a wide range of hardware.
• Enable Secure Boot and leave it enabled. Enroll your own keys if you need to run unsigned code, rather than disabling verification.
• Set a firmware password so settings cannot be changed at the console, and disable boot from external media where it is not needed.
• Enable full disk encryption bound to boot measurements, with a PIN. This is what makes a stolen or tampered machine useless rather than merely inconvenient.
• Enable memory integrity and virtualisation-based security where the platform supports them, which raises the cost of the kernel-level step an implant usually needs.
• Keep revocations current, meaning let the platform apply dbx updates rather than deferring them indefinitely.
• Physical control. Every attack in this space that does not start with kernel-level code starts with someone touching the machine.

For a fleet:

• Buy hardware with a hardware root of trust and firmware resiliency features, and record which models have them.
• Track firmware versions as an inventory attribute, so "which machines are on the vulnerable version" is a query rather than a project.
• Use attestation where the identity provider supports it, so boot state becomes an access decision input.
• Verify flash protections on a sample of machines. CHIPSEC tests whether the SPI flash write protections are actually enabled, which on some hardware they are not.
• Have a policy for suspected firmware compromise, which is a different procedure from ordinary remediation: reimaging does not fix it, and the realistic responses are vendor-supported firmware reflashing or replacing the hardware.

Detection, honestly

Detecting firmware compromise from the operating system is fundamentally limited, because the thing you are asking is running beneath the thing asking. The available approaches:

• Attestation against known-good measurements, which detects changes to what loaded.
• Dumping and comparing the flash contents against a vendor image, which requires the ability to read the flash reliably.
• Platform assessment tools such as CHIPSEC, which check configuration and protection state rather than searching for implants.
• Behavioural signals from above, such as unexplained kernel modifications, which is indirect and late.

The realistic posture for most organisations is prevention and hygiene rather than detection: keep firmware current, keep Secure Boot on, bind disk encryption to measurements, and control physical access.

The verdict

Firmware is the layer where compromise outlives every response an organisation normally makes. That is what makes it worth understanding and what makes the protections worth enabling, even though the threat is rare for most people.

Secure Boot enforces at load time and is defeated by signed vulnerable binaries, which is why revocation matters. Measured boot detects change and becomes an enforcement mechanism when a secret is sealed to the measurements. Hardware roots of trust check the layer nothing else can. All three are on by default on current hardware, and the thing most likely to be missing on any given machine is a current firmware version.

Related guides

• What Is a Bootkit
• What Is a Rootkit
• Malware Persistence Techniques
• Encryption Explained
• Zero Trust Architecture Explained