Parag Mali - tag: secure-boot

Below the OS: The Pre-Boot Trust Chain Where Secure Boot Inherits Its Trust From

noreply@paragmali.com (Parag Mali) — Wed, 03 Jun 2026 00:00:00 GMT

**Secure Boot is not where trust begins on a modern PC.** It is the fifth rung in an eleven-rung pre-OS chain that starts with a one-time-programmable fuse inside the chipset and travels through Intel Boot Guard or AMD Platform Secure Boot, through an on-die security processor (Intel CSME on MINIX 3, or AMD's ARM Cortex-A5 Secure Processor), through UEFI and Measured Boot, before it ever loads `winload.efi`. Every rung's verifier inherits the trust of the rung below it -- and the chain's revocation surface narrows monotonically as you descend. The April 2023 MSI / Money Message OEM-key leak [@binarly-msi] and the May 9, 2023 KB5025885 boot-manager revocation programme [@kb5025885] are the two worked examples that make the asymmetric-revocation argument concrete: at the fuse layer, there is no revocation primitive at all. flowchart TD R0["Rung 0: CPU reset vector at 0xFFFFFFF0"] subgraph IL["Intel path"] I1["Rung 1: Microcode loads from SPI patch area"] I2["Rung 2: Authenticated Code Module verified vs silicon-fused Intel key"] I3["Rung 3: ACM reads Field Programmable Fuse, verifies KM and BPM"] I4["Rung 4: Initial Boot Block hashed and compared to BPM"] end subgraph AL["AMD path"] A1["Rung 1: ARM Cortex-A5 PSP comes out of reset before x86 cores"] A2["Rung 2: PSP boot ROM verifies PSP firmware vs AMD root key hash"] A3["Rung 3: PSP reads OEM-key fuse, verifies signed BIOS image"] A4["Rung 4: PSP releases x86 BSP from reset"] end R5["Rung 5: SEC and PEI phases, memory init, cache as RAM"] R6["Rung 6: DXE drivers loaded, UEFI variable services online"] R7["Rung 7: Secure Boot evaluates Authenticode against PK, KEK, db, dbx"] R8["Rung 8: Boot Device Selection picks bootmgfw.efi"] R9["Rung 9: Boot Manager loads, Measured Boot extends PCR 4 through 7"] R10["Rung 10: bootmgfw.efi verifies winload.efi"] R11["Rung 11: Hand-off to winload.efi"] R0 --> I1 R0 --> A1 I1 --> I2 --> I3 --> I4 --> R5 A1 --> A2 --> A3 --> A4 --> R5 R5 --> R6 --> R7 --> R8 --> R9 --> R10 --> R11

1. Permanently Downgraded to a Weaker Trust Model

On April 6, 2023, the Money Message ransomware actor published roughly 1.5 TB of MSI source code to a TOR-hosted leak site after MSI declined to pay a reported $4M ransom [@helpnet-msi-leak]. A month later, on May 5, Binarly's efiXplorer team opened the archive. Inside, they found something worse than source code. They found the Intel Boot Guard Key Manifest and Boot Policy Manifest private keys covering roughly 116 MSI systems, plus image-signing keys for 57 more products, with cross-OEM contamination across HP, Lenovo, AOPEN, CompuLab, and Star Labs [@binarly-msi] [@helpnet-msi-leak] [@register-msi-alt]. The affected platform generations spanned Tiger Lake, Alder Lake, and Raptor Lake [@register-msi-alt]. Binarly published a per-device impact catalogue in their SupplyChainAttacks repository for triage by the affected vendors [@binarly-supply-chain].

Those private keys correspond to public-key hashes that have already been burned, one-time-programmably, into a fuse inside the chipset of every affected machine. There is no revocation primitive at that fuse layer. Intel cannot patch this. MSI cannot patch this. Microsoft cannot patch this.

Note: Every Intel system whose Field Programmable Fuse holds the hash of a leaked MSI OEM public key is now in a permanent state of reduced assurance against firmware tampering. The leak does not require a successful in-the-wild exploit to count as damage. The capability transfer happened the moment Money Message published the archive [@binarly-msi].

This story matters because most public writing about "the boot security chain on a Windows PC" stops at Secure Boot. The popular framing -- that the Platform Key (PK) is the trust anchor and the rest of the chain hangs from it -- is not just incomplete. It is upside down. Secure Boot's PK is a tenant of UEFI authenticated NVRAM stored in the SPI flash chip soldered next to the chipset [@uefi-specs]. PK's integrity depends on the SPI flash being unwritable to attackers. That property is what the rung below Secure Boot enforces. Without the lower-rung silicon-fused verifier, PK is just bytes in flash.

A bootkit is malware that survives in the pre-OS firmware boot path. It runs before the kernel exists and outlives both reboots and clean OS installs. Two recent ones bracket the operational threat.

BlackLotus [@eset-blacklotus]. Analysed by ESET researcher Martin Smolar on March 1, 2023, sold on hacking forums since October 2022. It was the first public UEFI bootkit observed bypassing Secure Boot on fully-patched Windows 11, via CVE-2022-21894 [@cve-2022-21894-nvd].
Bootkitty [@bootkitty] [@helpnet-bootkitty]. Disclosed by ESET on November 27, 2024. It was the first analogue for Linux.

These are the threats the pre-boot chain exists to defeat. And the pre-boot chain works only as well as the layer below it.

Why is the most permanent layer of the trust chain also the layer with no recovery surface?

To answer that question, we have to walk down from the rung you know -- Secure Boot -- to the rung you probably do not: the fuse.

That walk is the article. The eleven-rung diagram in the TLDR is the map. Along the way we will visit Intel Boot Guard, AMD Platform Secure Boot, the Intel Converged Security and Management Engine, and the AMD Platform Security Processor. We will see what gets verified, by what, and against what trust anchor. And we will see, three times at three increasing levels of compression, why the chain's revocation surface narrows monotonically as you descend, until at the bottom there is no revocation at all. Companion articles on Secure Boot, Measured Boot, Pluton, ACPI Tables, and Secured-core PCs cover the rungs above this one. This article's lane is everything below them.

2. From "BIOS Is Trusted Because Nobody Can Write to It" to "BIOS Has Its Own SoC"

On September 13, 2011, Symantec analyst Liam Ge published an early analysis of Trojan.Mebromi on Symantec Connect [@symantec-bios-threat]; Liam O'Murchu's contemporaneous Symantec Threat Intelligence writeup is the source MITRE catalogues at ATT&CK ID S0001 as the canonical primary [@mitre-mebromi-s0001]. Mebromi was the first in-the-wild BIOS rootkit observed on shipping consumer PCs. It rewrote the Award BIOS Master Boot Record code so that it reinjected itself into the OS on every boot. The Wikipedia BIOS security section preserves the same provenance [@wiki-bios-security].

Four months earlier, in April 2011, NIST had published SP 800-147 ("BIOS Protection Guidelines") attempting to mandate the cure: signed BIOS updates with an authenticated update mechanism rooted in immutable code [@nist-sp-800-147]. The cure arrived just as the disease made its in-the-wild debut. That four-month gap captures the entire history of pre-boot security on the PC platform: the defensive architecture always lags the attacker by roughly one generation, and each generation moves the trust anchor one layer closer to the silicon.

Generation 1 -- Trust by physical inaccessibility (pre-2011)

The implicit model from the IBM PC through the late 2000s was that nobody could write to the BIOS ROM, so the BIOS was trusted because it was unreachable. That model held only as long as nobody bothered. By 2011 the protections that had compensated for writable flash (the BIOSWE, BLE, SMM_BWP, and FLOCKDN chipset configuration bits described in the contemporary CHIPSEC literature [@c7zero-chipsec]) were widely misconfigured on shipping platforms. Academic SPI-rewrite research predated Mebromi by nearly a decade. Mebromi simply demonstrated that the field had caught up.

Generation 2 -- Signed BIOS updates anchored in BIOS (2011-2013)

NIST SP 800-147 [@nist-sp-800-147] and OEM responses to Mebromi produced a generation of platforms that signed BIOS updates and verified the signature before flashing. The structural flaw was immediate: the verifier lived in the region it was verifying. Burn the verifier with the update payload and you owned the next boot. Seven years later NIST SP 800-193 ("Platform Firmware Resiliency Guidelines") explicitly raised the bar from Protection alone to Protection plus Detection plus Recovery [@nist-sp-800-193], implicitly conceding that Gen 2 had not closed the loop.

Generation 3 -- The trust anchor moves into silicon (2013-2015)

In the second quarter of 2013, Intel shipped Boot Guard alongside the Haswell CPU family. In the first half of 2014, AMD shipped the Platform Security Processor with the Family 16h "Beema" and "Mullins" mobile parts [@wiki-amd-psp]. The Wikipedia entry for AMD PSP records the architecture cleanly: "The PSP itself represents an ARM core (ARM Cortex-A5) with the TrustZone extension ... inserted into the main CPU die as a coprocessor" [@wiki-amd-psp]. With Gen 3, the trust anchor moved out of mutable storage entirely. The verifier was no longer a region of flash; it was a piece of silicon that could not be rewritten without replacing the chip.

In 2015, the Skylake CPU family shipped with ME 11, the first ME generation built on the Intel Quark x86 core (replacing the ARC-based predecessors) and running a modified MINIX 3 microkernel as its on-die runtime [@wiki-ime] [@wiki-ime-history]. The Converged Security and Management Engine (CSME) brand name folded ME, TXE, and SPS into a single architectural label.

In November 2017, Andrew S. Tanenbaum -- the creator of MINIX 3 -- published an open letter to Intel that read in part: *"Thanks for putting a version of MINIX inside the ME-11 management engine chip used on almost all recent desktop and laptop computers in the world"* [@tanenbaum-letter]. The hosted letter at cs.vu.nl carries no explicit publication date; the early-November dating derives from contemporaneous press coverage. Intel had never consulted him; he learned about MINIX's role only when independent researchers reverse-engineered the ME runtime.

The cultural moment mattered because it surfaced something the architecture had hidden: every modern Intel PC ships a second operating system, on a second processor, that boots before yours does. The trust chain you are reading about exists in part because that second OS exists.

ME 11 ran MINIX. Earlier ME generations (ME 1 through ME 10) ran ThreadX on ARC cores. Later CSME generations from Ice Lake forward moved to a Tremont-class x86 core but kept the MINIX 3 runtime [@wiki-ime] [@wiki-ime-history].

Thanks for putting a version of MINIX inside the ME-11 management engine chip used on almost all recent desktop and laptop computers in the world. -- Andrew S. Tanenbaum, November 2017 [@tanenbaum-letter]

A month after Tanenbaum's letter, on December 7, 2017, Mark Ermolov and Maxim Goryachy presented "How to Hack a Turned-Off Computer" at Black Hat Europe 2017 [@ermolov-goryachy-2017]. The talk demonstrated unsigned-code execution in the CSME via the JTAG / Direct Connect Interface chain that became Intel security advisory INTEL-SA-00086 [@intel-sa-00086]. Intel's CSME security white paper postdates the disclosure and treats the same architecture from the vendor side [@intel-csme-whitepaper]. A year later, in 2018, Yuriy Bulygin presented "A Tale of Disappearing SPI and the Intel Boot Guard Enchanted Dance" at Black Hat Europe 2018 [@eclypsium-publications], the canonical reverse engineering of the Boot Guard IBB-verification flow.

flowchart LR G1["Gen 1: Trust by physical inaccessibility, pre-2011"] G2["Gen 2: Signed BIOS update anchored in BIOS, 2011 to 2013"] G3["Gen 3: Silicon root of trust via Boot Guard and PSP, 2013 onward"] G4["Gen 4: Secure Boot and discrete TPM, 2012 onward"] G5["Gen 5: fTPM on CSME and PSP, 2015 onward"] G6["Gen 6: Microsoft Pluton, 2020 onward"] G7["Gen 7: Open multi-signer root of trust via Caliptra, prospective"] G1 --> G2 --> G3 --> G4 --> G5 --> G6 --> G7

The genealogy is a chain of trades, not a chain of unambiguous improvements. Gen 2 added a revocation surface and unanchored it. Gen 3 anchored the chain in silicon and removed the revocation surface. Gen 4 (Secure Boot, parallel to Gen 3) restored revocation above the firmware layer via the dbx deny-list but did not extend revocation to the fuse. Every move from one generation to the next migrated the failure surface to a different layer. The chain that ships in 2026 is the live composition of Gens 3 through 7, not a clean replacement.

If the trust anchor is now a silicon fuse, what exactly does the silicon do at boot -- and why does Intel's path differ from AMD's?

3. The Two-Vendor Stack: Intel Boot Guard plus CSME, AMD PSP plus PSB

Here is a fact that surprises most x86 engineers the first time they read it carefully. On a modern AMD desktop, an ARM Cortex-A5 with TrustZone boots before the x86 cores are released from reset. The x86 bootstrap processor (BSP) only comes out of reset after the on-die ARM core has verified the BIOS image in SPI flash and decided the platform is allowed to start [@wiki-amd-psp] [@amd-psb-whitepaper]. The "x86 PC" is, at boot, an ARM system-on-chip pretending to be an x86 PC for the first few hundred milliseconds.

Intel takes the opposite architectural shape. On an Intel system the BSP comes out of reset first, but the very first instructions it executes are an Intel-signed binary called the Authenticated Code Module (ACM) which runs inside the CPU package itself, gated by microcode that verifies the ACM signature against a public-key hash that has been fused into the silicon at manufacturing time [@eclypsium-publications]. The first thing your CPU does is verify a manifest signed by Intel that tells it where the OEM's keys live.

A small, Intel-signed binary that the CPU loads from a known SPI region into the CPU cache as private memory and executes before any unsigned code can run. The ACM is verified against a public key whose hash is fused into the chipset Field Programmable Fuse at silicon manufacturing time. The Boot Guard ACM is the verifier that walks the OEM-signed Key Manifest and Boot Policy Manifest. The TXT SINIT ACM is a separate, later-stage ACM used by Intel TXT for dynamic root-of-trust measurement. An array of one-time-programmable polysilicon fuses inside Intel's PCH (or, on Skylake and later, integrated into the CPU package) that the OEM blows during board manufacturing to record the hash of the OEM's Boot Guard public key, the chosen Boot Guard profile (verified-only, measured-only, or both), and the lock state. Once blown, the FPF cannot be unblown. The FPF is the bottom of the OEM-controlled portion of the Intel trust chain; below it sits the silicon-fused Intel public key that authenticates the ACM itself. An OEM-signed manifest that tells the Boot Guard ACM which SPI regions form the Initial Boot Block, what cryptographic hash to expect over those regions, which Boot Guard profile to enforce, and (on profile 4 or 5) what to do on verification failure. The BPM is signed with the OEM Boot Policy Key, which is itself authenticated against the Key Manifest, which is itself authenticated against the FPF. An ARM Cortex-A5 with TrustZone, integrated as a coprocessor on the AMD CPU die from Family 16h forward, that boots before the x86 cores are released from reset [@wiki-amd-psp]. The PSP runs its own boot ROM (immutable silicon), loads PSP firmware from a known SPI directory, verifies that firmware against the AMD root-key hash, and (on platforms with PSB enforced) verifies the OEM-signed BIOS image before releasing the x86 BSP from reset. The AMD architectural feature that has the PSP measure and verify the BIOS image against an OEM-key fuse before releasing the x86 cores [@amd-psb-whitepaper]. PSB ships in two activation states: PSB-capable (PSP runs but does not enforce verification) and PSB-enforced (the OEM has burned the OEM-key hash into the PSP fuse, and the PSP will halt the platform on verification failure). PSB-enforced on EPYC is widely deployed; on Ryzen it has historically been opt-in per platform.

Intel: Boot Guard, CSME, and the manifest chain

Inside an Intel platform the verifier walk is precise enough to render as a list:

The Boot Guard ACM loads into a protected region of CPU cache and executes inside the CPU package.
It reads the FPF for the OEM key hash and the active profile bits.
It pulls the Key Manifest (KM) from SPI and verifies the KM signature against the FPF-stored hash.
It pulls the Boot Policy Manifest (BPM) and verifies the BPM signature against the KM public key.
It hashes the SPI regions declared by the BPM as the Initial Boot Block (IBB) and compares the hash against the BPM-declared expected value.
On a match, it transfers control to the IBB and the chain proceeds.
On a mismatch, it halts (profile 4 and profile 5) or extends PCR 0 with the measurement and continues (profile 3) [@eclypsium-publications].

The Bulygin BH EU 2018 reverse engineering remains the most readable primary on the actual code path [@eclypsium-publications].

Separately, while the CPU is doing the Boot Guard walk, the CSME runs its own startup sequence on its own core, with its own MINIX 3 runtime [@intel-csme-whitepaper]. Once stable, it exposes three optional services [@intel-csme-whitepaper]:

Intel Active Management Technology (AMT). Out-of-band management; only on systems where the OEM has enabled it in firmware.
Intel Platform Trust Technology (PTT). A TPM 2.0 endpoint implemented in CSME firmware, so the platform does not need a discrete TPM chip.
Intel Identity Protection Technology (IPT). Hardware-rooted one-time-password generation.

Each service depends on CSME being trustworthy. And CSME's own runtime is verified, at boot, by the chain we have just walked.

AMD: PSP boot ROM, PSP firmware, and the OEM-key fuse

The AMD walk is structurally simpler and architecturally cleaner. The PSP boot ROM is silicon -- it cannot be modified after fabrication. It reads the PSP directory from a known SPI offset, validates the directory header, loads the PSP firmware image, and verifies that image against the AMD root-key hash that is part of the PSP boot ROM itself [@amd-psb-whitepaper]. On a PSB-enforced platform, the PSP then loads the OEM PSB key, verifies it against the OEM-key hash fused in the PSP, and uses the OEM PSB key to verify the OEM-signed BIOS image before releasing the x86 BSP from reset.

The "separate core boots first" architectural primitive is a different kind of isolation than Intel's "microcode plus signed ACM." Intel's verifier runs in the CPU package but inside a protected cache region. AMD's verifier runs on a physically separate core with its own memory map. Neither is obviously better. Both shift the trust anchor out of writable storage and into silicon.

The ARM Cortex-A5 implements ARMv7-A and ships TrustZone. TrustZone partitions execution into a Non-Secure World (the Rich Execution Environment, REE) and a Secure World (the Trusted Execution Environment, TEE) with hardware-enforced isolation. The PSP runs its boot ROM and firmware in the Secure World [@wiki-amd-psp].

CSME generation	Core	Runtime	Era
ME 1 -- ME 10	ARC	ThreadX	2006 -- 2014
ME 11 (Skylake)	Intel Quark x86	MINIX 3	2015 -- 2018
CSME (Ice Lake+)	Tremont-class x86	MINIX 3	2019 -- present

Sources: [@wiki-ime] [@wiki-ime-history].

The generational table for the Intel side has been the source of several recurring errors in secondary literature: claims that "every CSME runs MINIX" are wrong (the ARC-based ME 1 through ME 10 ran ThreadX), and claims that "CSME still runs on Quark" are equally wrong (Ice Lake and later moved to a Tremont-class x86 core but kept the MINIX 3 runtime) [@wiki-ime] [@wiki-ime-history].

AMD has not published a complete PSP architectural document. The PSB whitepaper [@amd-psb-whitepaper] covers the PSB-flow at a marketing-architecture level; the PRO security whitepaper [@amd-pro-whitepaper] is the broadest vendor primary. Everything else about the PSP -- the runtime, the directory layout, the soft-fuses, the glitch surface -- flows through community reverse engineering. The most useful primaries are Buhren and Werling's voltage-glitching corpus at TU Berlin (now indexed via the Fraunhofer publication record) [@fraunhofer-amd], the Buhren / Jacob / Krachenfels / Seifert "One Glitch to Rule Them All" CCS 2021 paper [@one-glitch-2021], the Jacob / Werling / Buhren / Seifert "faulTPM" USENIX Security 2024 paper (arXiv v1 submitted April 28, 2023) [@faultpm-2023], the open PSPReverse toolchain on GitHub [@pspreverse-org] [@psp-glitch-repo], and Matthew Garrett's 2022 reverse engineering of the PSP directory entry 0xB BIT36 "soft fuse" that gates Pluton on Ryzen 6000 [@garrett-pluton-2022]. The "AMD has not published" caveat travels with every architectural claim about the PSP in this article.

The hedge matters for one specific premise: the ARM Cortex-A5 + TrustZone architectural claim is well-attested for Family 15h and Family 17h via the Buhren / Werling / Jacob / Seifert reverse-engineering corpus [@one-glitch-2021] [@faultpm-2023] [@wiki-amd-psp]. The specific core in Family 19h+ is not publicly documented. The widely-repeated "Cortex-A7" claim is unsupported by any vendor primary I could verify. This article uses "Cortex-A5 with TrustZone" only where Family 15h / 17h is in scope and says "the PSP" generically elsewhere.

Now that we know who the verifiers are, let us watch them work -- one rung at a time -- from CPU reset to winload.efi.

4. The Chain Walk: From CPU Reset to winload.efi

Eleven rungs. We will walk each one in order. By the end you will know exactly what gets verified, by what, against what trust anchor, and what happens when that verification fails.

flowchart TD R["CPU reset, vector at 0xFFFFFFF0"] subgraph IB["Intel Boot Guard"] I1["Microcode loads ACM from SPI"] I2["ACM verified vs silicon-fused Intel key"] I3["ACM reads FPF: OEM key hash plus profile bits"] I4["KM signature verified vs FPF hash"] I5["BPM signature verified vs KM public key"] I6["IBB regions hashed and compared to BPM"] I7["Profile 4 or 5 halts on mismatch, Profile 3 extends PCR 0"] I1 --> I2 --> I3 --> I4 --> I5 --> I6 --> I7 end subgraph AP["AMD PSP plus PSB"] A1["PSP boot ROM (silicon, immutable) executes"] A2["PSP firmware loaded from SPI PSP directory"] A3["PSP firmware verified vs AMD root key hash"] A4["OEM PSB key loaded from SPI"] A5["OEM PSB key verified vs OEM-key fuse"] A6["BIOS image verified vs OEM PSB key"] A7["x86 BSP released from reset"] A1 --> A2 --> A3 --> A4 --> A5 --> A6 --> A7 end R --> I1 R --> A1 I7 --> H["Hand-off to IBB and SEC phase"] A7 --> H

4.1 Reset and microcode bootstrap

The x86 CPU starts executing at physical address 0xFFFFFFF0 per the Intel SDM Volume 3A §9.1.4 ("First Instruction Executed") specification [@intel-sdm-vol3a], which the chipset aliases into the SPI flash region containing the reset vector.That address is sixteen bytes below the top of 32-bit physical memory; the first instruction is typically a near jump down into the bulk of the firmware. The very first action is a microcode load: the CPU executes its built-in microcode, which then loads any microcode patches from a known SPI region. On Intel platforms the microcode patch is itself signed against an Intel public key burned into silicon. On AMD platforms the equivalent step is the PSP boot ROM execution, which happens slightly earlier in wall-clock time because the PSP starts before the x86 BSP is released [@wiki-amd-psp].

4.2 Intel ACM execution and AMD PSP first-stage boot

The Intel ACM is signed by Intel and stored in SPI. The microcode loader verifies the ACM signature against the silicon-fused Intel public key and runs the ACM inside a protected region of cache. The AMD analogue is the PSP boot ROM, which is silicon and therefore cannot be modified after fabrication. Both architectures share the invariant: the first executable code path is anchored in silicon, not flash.

4.3 FPF and OEM-fuse policy read

On Intel, the ACM reads the FPF to learn the hash of the OEM Boot Guard public key and the active Boot Guard profile. It then verifies the Key Manifest (KM) signature against the FPF hash, and the Boot Policy Manifest (BPM) signature against the KM public key. The KM and BPM together form a two-level OEM signing structure: the KM authenticates a set of permitted Boot Policy signing keys, and the BPM names the IBB regions and their expected hash.

On AMD, the PSP reads the PSP directory from a known SPI offset, authenticates the directory entries against the AMD root key, and (on PSB-enforced platforms) authenticates the OEM PSB public key against the PSP-fused OEM-key hash before validating the BIOS image [@amd-psb-whitepaper].

4.4 IBB verification and SEC phase

The first chunk of UEFI firmware that the lower-rung silicon verifier cryptographically covers. On Intel platforms with Boot Guard, the IBB regions are declared by the BPM and hashed by the ACM. On AMD platforms with PSB, the equivalent role is played by the PSP-verified BIOS image as a whole. The IBB is where UEFI's own code path begins.

After IBB verification succeeds, control transfers to the IBB itself. The IBB executes the SEC (Security) phase of the EDK II firmware lifecycle: it sets up the cache as RAM, enables initial CPU features, and prepares to hand off to PEI.

Intel's umbrella term, introduced with Skylake (ME 11) in 2015, for the on-die security processor that runs alongside the x86 cores and provides services to the platform: firmware TPM (PTT), AMT, identity protection, secure storage, and the runtime verifier for some pre-OS measurements [@intel-csme-whitepaper] [@wiki-ime]. CSME runs its own RTOS on its own core and is the single most complex piece of pre-OS firmware on a modern Intel platform.

4.5 PEI and DXE phases

The PEI (Pre-EFI Initialization) phase completes memory controller initialisation and discovers the platform's DRAM. The DXE (Driver eXecution Environment) phase then loads UEFI drivers (storage, USB, network, video, and platform-specific drivers) and brings the UEFI services online. The TianoCore EDK II reference UEFI implementation [@edk2-repo] is the canonical open-source codebase for studying PEI and DXE in detail, and every commercial vendor BIOS is structurally a fork of EDK II with proprietary platform code.

"SPI flash" on a modern platform is not one trust domain. The main BIOS SPI region is what Boot Guard / PSB verify. But a modern PC may also have separate SPI or NVRAM regions for the Embedded Controller (keyboard, battery, lid sensor), the Thunderbolt controller, the fingerprint reader, and on servers the baseboard management controller (BMC). Each of those has its own update mechanism, its own verifier (if any), and its own attack surface. The article will revisit this in section 8.

4.6 DXE Secure Boot variable evaluation

During DXE the UEFI runtime brings the Secure Boot variable services online. The Platform Key (PK), Key Exchange Keys (KEK), Authorized Signature Database (db), and Forbidden Signature Database (dbx) are stored as UEFI authenticated variables in NVRAM, per UEFI Specification §8 [@uefi-specs]. When DXE loads a UEFI binary, the verifier compares the binary's Authenticode signature against db entries, refuses to load binaries whose hash appears in dbx, and (in the default policy) refuses to load binaries that do not match any db entry.

The companion article on Secure Boot covers the PK / KEK / db / dbx model and the SBAT generation-number deny-list in detail. The point for this chain walk is that Secure Boot itself does not start until DXE has set up the UEFI variable services, and DXE itself only runs because the IBB verified by Boot Guard / PSB executed correctly.

Note: This is rung 5 of 11. The rungs above this one -- Secure Boot policy, TPM PCR semantics, Pluton silicon enumeration, ACPI table integrity, Secured-core PC configuration -- are covered in the companion articles. The lane of this article is the rungs below Secure Boot. From here forward we summarise the upper rungs only enough to show where the trust chain hands off.

4.7 Boot Device Selection and bootmgfw.efi

After DXE completes, the BDS (Boot Device Selection) phase enumerates the boot variables stored in NVRAM, finds the first valid EFI_LOAD_OPTION, and loads the EFI binary it points to. On Windows that is \EFI\Microsoft\Boot\bootmgfw.efi. On Linux estates running shim it is \EFI\<distro>\shimx64.efi, which is the first non-Microsoft binary the chain consents to load and which then verifies a distro-signed second-stage loader (GRUB2 in most cases) [@garrett-shim-19448].

4.8 Boot Manager verifies winload.efi; Measured Boot extends PCR 0 through 7

The Windows Boot Manager (bootmgfw.efi) verifies winload.efi against its built-in trust anchor, then asks the TPM to extend a sequence of PCR measurements covering the chain it has just walked. Per the TCG PC Client Platform Firmware Profile, PCRs 0 through 7 cover (0) the platform SRTM and firmware, (1) host platform configuration, (2) UEFI drivers and option ROMs, (3) UEFI driver and application configuration, (4) the boot manager code and boot attempts, (5) boot manager configuration and the GPT, (6) host-platform-manufacturer-specific events, and (7) the Secure Boot policy [@tcg-tpm-lib]. The companion article on Measured Boot covers the PCR semantics in detail.

4.9 Hand-off to winload.efi

winload.efi loads the NT kernel, the early-launch antimalware drivers, and the Code Integrity policy. The Windows OS-side trust chain takes over from here. This article ends its lane at the hand-off.

{// Toy SHA-256 substitute (NOT cryptographically real -- demonstrates the extend chain only). function hashHex(s) { let h = 2166136261; for (const c of s) h = ((h ^ c.charCodeAt(0)) * 16777619) >>> 0; return h.toString(16).padStart(8, '0').repeat(8); } function extend(pcr, measurement) { return hashHex(pcr + measurement); } const pcr0 = '00'.repeat(32); const afterAcm = extend(pcr0, 'ACM-binary@SPI:0x10000'); const afterIbb = extend(afterAcm, 'IBB-region@SPI:0x100000'); const afterDxe = extend(afterIbb, 'DXE-driver-set-vendor-A'); const afterSb = extend(afterDxe, 'SecureBoot-policy:PK=hashA,KEK=hashB,db=hashC,dbx=hashD'); const afterBm = extend(afterSb, 'bootmgfw.efi:authenticode=hashE'); const afterLoad = extend(afterBm, 'winload.efi:authenticode=hashF'); console.log('PCR0 after ACM ->', afterAcm.slice(0, 32) + '...'); console.log('PCR0 after IBB ->', afterIbb.slice(0, 32) + '...'); console.log('PCR0 after DXE ->', afterDxe.slice(0, 32) + '...'); console.log('PCR7 after PolicyB->', afterSb.slice(0, 32) + '...'); console.log('PCR4 after BootMgr->', afterBm.slice(0, 32) + '...'); console.log('PCR4 after WinLoad->', afterLoad.slice(0, 32) + '...'); console.log(); console.log('Change ANY measurement and the chain hash diverges from quote-expected value.');}

Eleven rungs. Each rung's verifier inherits the trust of the rung below it. That single property -- inheritance -- is what makes the next section's argument inevitable.

5. The Breakthrough: The Hardware Fuse as Root of Trust, and the Asymmetric Revocation Surface

The strongest layer in the chain is the layer you cannot fix. That is not a bug. It is the definition of a hardware root of trust -- and it is also why the MSI 2023 leak is permanent.

The architectural insight is structural. Trust must be anchored somewhere, and the only place that survives an OS reinstall, a BIOS reflash, an SPI chip swap, and a malicious bootloader is a piece of silicon that the attacker cannot rewrite without replacing the chip. One-time-programmable polysilicon fuses give exactly that property. Burn the OEM key hash into the FPF at manufacturing time, and from that point forward only OEM-signed firmware will run on that board. The fuse is "the bottom" by construction.

The cost is symmetric. One-time programmable means one-way trust. Once an OEM's public key hash is burned, it cannot be removed without replacing the chip. If the OEM later loses control of the corresponding private key, the public-key hash that authenticates everything signed by that private key is still in the fuse. The fuse layer has no revocation primitive.

Key idea: Trust strength and revocation expressiveness move in opposite directions as you descend the pre-boot trust chain. The fuse layer is the strongest because nothing can change it -- which is exactly why nothing can revoke it. Permanence is the source of both properties, not a side effect of one.

This is the article's load-bearing observation, and it is worth making concrete. Going up the chain from the fuse, the revocation surface gets progressively more expressive.

A monotonically increasing version number embedded in a signed firmware artifact (boot manager, ACM, microcode patch). When the platform's stored SVN floor is bumped, the platform refuses to load any artifact whose embedded SVN is below the floor. SVN bumps are an alternative to per-hash revocation that scales better as the number of bad artifacts grows, but they require the firmware vendor to maintain an SVN namespace and to bump it on every revocation event. A generation-number revocation model introduced by the rhboot shim project to replace per-hash dbx revocation for shim and downstream components [@sbat-md]. Each shim, GRUB2 build, and second-stage component embeds a vendor-specific SBAT generation. When a vulnerability is found, the vendor publishes a new shim with an incremented generation. The shim verifier on the running platform refuses to load any component with a generation lower than the platform's stored floor. As the SBAT documentation notes, "This single revocation event consumes 10kB of the 32kB, or roughly one third, of revocation storage typically available on UEFI platforms" [@sbat-md], which is exactly the dbx exhaustion problem SBAT is designed to solve.

At the top of the chain, on a Pluton-equipped platform, Microsoft can ship Pluton firmware updates through Windows Update [@pluton-learn]. That is the most expressive revocation surface on the chain: software cadence, OS-mediated delivery, no OEM gating on the runtime channel after initial enrolment. (The SPI-resident Pluton firmware loaded at every boot is still updated through the OEM's UEFI capsule pipeline; the OS-mediated runtime channel sits on top of it [@pluton-learn].)

Below Pluton, SBAT denies entire classes of vulnerable shim binaries with one generation bump [@sbat-md]. Below SBAT, dbx denies individual bootloader hashes (with the ~32 KB capacity constraint that SBAT exists to relieve). Below dbx, KEK and PK are progressively more permanent because they sit at the root of UEFI's variable-authentication structure, and any change requires a Platform Key signature. Below the UEFI variables, the OEM Boot Policy Manifest is replaced only by an OEM-signed firmware update. And below the BPM, the FPF / OEM-key fuse is unrecoverable.

flowchart TD L0["Pluton firmware via Windows Update: software cadence"] L1["SBAT generation bump: revoke an entire class with one entry"] L2["dbx hash list: revoke per-binary, capped at roughly 32 KB"] L3["KEK and PK: revoke only via Platform Key signature"] L4["OEM Boot Policy Manifest: replaced by OEM-signed firmware update"] L5["FPF / OEM-key fuse: NO REVOCATION PRIMITIVE"] L0 --> L1 --> L2 --> L3 --> L4 --> L5

MSI 2023 as the worked example

The April 2023 MSI leak is the existence proof. The FPF on every affected Intel platform stores the SHA-256 hash of the OEM Boot Guard public key. The corresponding private key is now public. There is no operational path to revoke that hash at the fuse layer without physical chip replacement. The only "revocation" surfaces available to a platform owner are upper-layer compensations, and each one has a structural limit:

An OS-level driver block list does not apply at boot, because the OS does not exist yet.
A dbx update can deny specific malicious firmware images by hash, but the attacker can sign a new image with the leaked key and rotate around the deny-list, exactly the way per-hash deny-lists always fail against an attacker who controls the signing oracle.
An Intel BIOS Guard SVN bump can raise the SVN floor, but the OEM has to sign the updated firmware -- using the same Boot Guard signing infrastructure that has been compromised. The leaked key signs the SVN bump too.

Help Net Security's contemporaneous reporting captured the counts that make the impact concrete: "private code signing keys for firmware images used on 57 MSI products, and private signing keys for Intel Boot Guard used on 116 MSI products ... one of the leaked keys has been detected on devices from HP, Lenovo, AOPEN, CompuLab, and Star Labs" [@helpnet-msi-leak]. The Register confirmed the affected platform generations as Tiger Lake, Alder Lake, and Raptor Lake [@register-msi-alt]. Binarly's per-device catalogue lists the affected SKUs in detail [@binarly-supply-chain].

Every Intel chip with the leaked OEM key hash burned in is permanently downgraded to a weaker trust model -- and nothing in the layers above can recover what the fuse layer lost.

SBAT exists for exactly the kind of revocation expressiveness the fuse layer lacks [@sbat-md]. SBAT is the negative-space comparator: this is what fuse-layer revocation could look like if it existed. It does not exist. That is the breakthrough -- and the limit -- of Gen 3 silicon roots of trust on commodity client platforms in 2026.

If the fuse is unrecoverable, what does the rest of the modern stack do to compensate?

6. State of the Art: What a Modern Pre-Boot Trust Chain Looks Like in 2026

In 2026 the chain has settled into a recognisable shape on Secured-core PCs and EPYC servers. Here is what is shipping, and what each piece is for.

The current best-practice configuration is roughly: Boot Guard or PSB enforced at the silicon verifier rung; BIOS Guard for runtime SPI write protection; SMM locked down via Intel TXT or AMD SKINIT; Measured Boot extending PCRs into a TPM 2.0 endpoint (discrete TPM, Intel PTT, AMD fTPM, or Microsoft Pluton); Windows DRTM enabled (extending PCR 17 through PCR 22); and the KB5025885 boot-manager revocation programme applied as it rolls out across 2025 and 2026 [@kb5025885].

KB5025885: db plus dbx plus SVN, not "PK rotation"

A late-launch primitive (Intel TXT via the SINIT ACM, or AMD SKINIT via the SLB) that re-anchors the trust chain after the static root has done its work. DRTM allows the OS to enter a measured launch environment in which a small, trusted hypervisor or secure kernel is loaded and measured into PCRs 17 through 22, independent of the firmware boot chain. Windows DRTM uses TXT or SKINIT to bring the Secure Kernel and Hypervisor Code Integrity online with a fresh chain of measurements.

Note: Press coverage frequently described KB5025885 as a "PK rotation" or "Microsoft rotating the Platform Key." It is neither. The Microsoft support article spells out the actual mechanism: KB5025885 adds the Windows UEFI CA 2023 certificate (PCA2023) to the Database Key (DB) and adds the hashes of vulnerable boot manager binaries to the Forbidden Signature Key (DBX) [@kb5025885]. The Platform Key itself is not modified by KB5025885. The MSRC blog framing is consistent: KB5025885 is a staged-rollout programme for managing the revocation of vulnerable Windows boot manager binaries associated with CVE-2023-24932 [@msrc-blog-2023-24932] [@msrc-cve-2023-24932].

KB5025885 was originally published on May 9, 2023 as part of May 2023 Patch Tuesday, in response to CVE-2023-24932 (a Secure Boot Security Feature Bypass) [@cve-2023-24932-nvd] [@kb5025885]. The CVE was the underlying vulnerability that the BlackLotus bootkit had exploited via CVE-2022-21894 several months earlier [@eset-blacklotus] [@cve-2022-21894-nvd]. Microsoft's response was structurally cautious: a multi-year staged rollout, rather than an immediate forced revocation, because forcing a dbx update that would brick any unpatched Windows install or any third-party EFI loader still in distribution would have been operationally catastrophic.

gantt dateFormat YYYY-MM-DD title KB5025885 boot manager revocation programme section Disclosure CVE-2023-24932 published :2023-05-09, 7d KB5025885 initial publication :2023-05-09, 7d section Deployment Manual deployment phase :2023-07-11, 270d Evaluation phase :2024-04-09, 90d Automatic enrollment phase :2024-07-09, 540d section Cutover Automatic certificate replacement :2026-01-01, 150d PCA2011 expiration window :2026-06-01, 30d

The rollout dates above follow the Microsoft KB5025885 article timeline [@kb5025885]: manual deployment beginning July 11, 2023; evaluation phase beginning April 9, 2024; automatic enrolment of mitigations beginning July 9, 2024; automatic certificate replacement on Windows 11 beginning January 2026; and the PCA2011 / UEFI CA 2011 / KEK CA 2011 expiration window in June 2026. The mechanism throughout is db + dbx + SVN, not Platform Key rotation.

Pluton's structural role in the modern chain

Microsoft Pluton was announced on November 17, 2020 as a "chip-to-cloud" security processor co-designed with AMD, Intel, and Qualcomm Technologies [@pluton-blog]. The current Microsoft Learn enumeration of Pluton silicon as of 2024 reads: "AMD: Ryzen 6000, 7000, 8000, 9000 and Ryzen AI Series processors; Intel: Core Ultra 200V Series, Ultra Series 3 and Series 3 processors; Qualcomm: Snapdragon 8cx Gen 3 and Snapdragon X Series processors. ... Pluton platforms in 2024 AMD and Intel systems will start to use a Rust-based firmware foundation" [@pluton-learn].

Pluton's structural contribution to the chain is the firmware-update channel. Discrete TPMs cannot be patched after manufacturing in any meaningful way. CSME PTT firmware ships through OEM BIOS updates with all the latency that implies. Pluton firmware reaches devices through two channels: the traditional OEM UEFI capsule that updates the SPI-resident Pluton image at boot, and an OS-mediated runtime channel through which Microsoft can ship new firmware via Windows Update [@pluton-learn] [@garrett-pluton-2022-update]. The second channel is the one no other shipping silicon root-of-trust has, and the one that closes the patch-latency gap.

Silicon comparison

Property	Intel Boot Guard	AMD PSB	Apple Silicon Boot ROM	Google Titan-M2	Microsoft Pluton
Trust anchor	FPF in PCH or package	OEM-key fuse in PSP / FCH	Mask ROM on the AP	On-die in Titan-M2 chip	On-die in SoC fabric
Revocation surface	None at fuse layer	None at fuse layer	Vendor seed (Apple)	Vendor seed (Google)	Microsoft via Windows Update
FW update channel	OEM BIOS	OEM BIOS	macOS updates	Android updates	Windows Update [@pluton-learn]
OS attestation API	TPM 2.0 quote (PTT)	TPM 2.0 quote (fTPM)	DeviceAttestationKey	KeyMint attestation	TPM 2.0 + Pluton-specific
Deployment posture	Widespread, OEM-gated	EPYC widespread, Ryzen opt-in	All Apple Silicon Macs	All Pixel 6 and later	Ryzen 6000+, Core Ultra, X-series

The asymmetry that matters for the article's argument is the third row. Apple, Google, and Microsoft control the firmware update channel for their respective trust anchors. Intel and AMD do not -- the OEM does, and the OEM's release cadence varies by vendor, by product line, and (for end-of-life models) drops to zero.

Bootkit comparison: same invariant, different break

Bootkit / vuln class	CVE	Vulnerable layer	Primitive	dbx state at disclosure	Fix mechanism
BlackLotus	CVE-2022-21894	Windows Boot Manager	baton drop on unpatched bootmgfw [@eset-blacklotus]	unpatched bootmgfw hashes not yet in dbx	KB5025885 dbx + db + SVN programme [@kb5025885]
BootHole	CVE-2020-10713 [@cve-2020-10713-nvd]	GRUB2 BootHole buffer overflow	GRUB2 cfg parser overflow [@eclypsium-boothole]	initial dbx update exhausted 10 KB of capacity	dbx hash list bump (SBAT later introduced to solve scale) [@sbat-md]
LogoFAIL	multiple in 2023	UEFI DXE image-parsing libraries	malicious BMP / PNG / JPEG in boot logo region	Boot Guard verifier passed; DXE parser exploited	per-OEM firmware update + library fixes [@binarly-logofail]
Bootkitty	(PoC, 2024)	User-controlled trust posture	Self-signed bootkit plus in-memory GRUB integrity-check patches before kernel hand-off [@bootkitty]	dbx unchanged for Bootkitty PoC	Keep Secure Boot enabled; audit MOK enrolments; SBAT is not the corrective surface for this class [@bootkitty]

The common pattern is the same invariant -- "the chain is only as strong as the rung that was broken" -- with four different break points:

BlackLotus broke at rung 9 (Boot Manager); the fix lived at rung 7 (Secure Boot policy via dbx).
BootHole broke at rung 10 (the chain-loaded GRUB2); the fix lived at rung 7 again (dbx, until SBAT replaced the per-hash approach).
LogoFAIL broke at rung 6 (a DXE image-parsing library); the fix had to live at rung 6 as well, because the verifier at rung 7 had already approved the binary.
Bootkitty did not break at shim or GRUB2; it operated alongside them, under the assumption Secure Boot was either disabled or the attacker's certificate had been pre-enrolled into MOK. ESET's primary disclosure confirms it is self-signed and patches GRUB integrity-check functions in memory after being loaded [@bootkitty].

The LogoFAIL story is especially instructive. Binarly's December 6, 2023 disclosure showed that Boot Guard validates the firmware image, but the image then parses attacker-controlled logo data through CVE-laden image parsers, executing attacker code in DXE without crossing any signature boundary [@binarly-logofail] [@binarly-logofail-slides] [@hackernews-logofail] [@darkreading-logofail].

Pluton is the most aggressive structural answer to the asymmetric-revocation problem on shipping silicon. But Pluton is not the only structural answer -- and even Pluton inherits one rung of OEM trust. The next section is the competing-approaches map.

7. Competing Approaches: Microsoft Pluton vs the Chipset Fuse Model

Pluton and Boot Guard are not competing for the same rung. They compose. Pluton sits in the SoC fabric on supported silicon and provides a TPM 2.0 service plus a Microsoft-controlled firmware-update channel; Boot Guard and PSB continue to verify the BIOS image at the silicon-verifier rung [@pluton-learn]. The interesting design fight is not Pluton-versus-Boot-Guard, it is Pluton-versus-the-OEM-controlled-fuse for the role of trust anchor of last resort.

Pluton's value proposition

Pluton's pitch, as Microsoft has articulated it since the November 2020 announcement, is to cycle the trust anchor from the OEM's fuse to a Microsoft-controlled root of trust that also lives in silicon but whose firmware can ship through Windows Update [@pluton-blog].

The trade is explicit: trust goes from "OEM, with no Microsoft visibility into key-management hygiene" to "Microsoft, with the platform integrated into Microsoft's signing infrastructure and update cadence."

The shift cuts two ways:

For organisations whose threat model treats OEM-key-management hygiene as the weakest link (and the MSI 2023 leak makes a strong empirical case for that view), Pluton is a structural improvement.
For organisations whose threat model treats Microsoft as a higher-risk root than the OEM, Pluton makes things worse on net.

The Pluton-present-is-not-Pluton-enabled trap

On April 11, 2022, Matthew Garrett published a reverse engineering of the ROG Zephyrus G14, an AMD Ryzen 6000 laptop, showing that "PSP directory entry 0xB BIT36 have the highest priority... If bit 36 is set, the PSP tells Pluton to turn itself off" [@garrett-pluton-2022].

The procurement consequence is easy to miss. Pluton-equipped silicon ships from AMD with Pluton present in the die, but the OEM can flip a single bit in the PSP firmware directory at manufacturing time that gates Pluton entirely. The platform passes "Pluton-equipped" advertising checks while Pluton is functionally disabled.

Garrett's December 2022 follow-up documented that Lenovo's ThinkPad Z13 shipped with Pluton default-disabled and exposed two ACPI device IDs (MSFT0101 and MSFT0200) that platform tooling could use to detect the configuration [@garrett-pluton-2022-update]. The operational lesson: "Has Pluton" is not the same question as "Pluton is enabled and acting as the TPM 2.0 endpoint."

Note: On Windows, Get-Tpm | Select-Object ManufacturerIdTxt, ManufacturerVersion returns the TPM 2.0 endpoint vendor and version. A Pluton-active platform reports MSFT as the manufacturer; a CSME PTT platform reports INTC; an AMD fTPM platform reports AMD; a discrete TPM reports the dTPM vendor (Infineon, Nuvoton, STMicroelectronics, etc.). This is the simplest field-confirmable check for which endpoint is actually serving as the TPM.

AMD PSB on EPYC versus Ryzen

AMD Platform Secure Boot has a deployment split that maps onto the consumer-versus-datacenter market structure. On EPYC, PSB-enforced is widely deployed: the datacenter customer wants the silicon-rooted verifier and is willing to accept the cost.

The cost on EPYC is sharp. Once an OEM has burned its key hash into the PSP fuse on a given CPU, that CPU is irreversibly locked to that OEM. The chip cannot be resold into another OEM's platform that uses a different OEM key. Secondary-market liquidity for fused EPYC parts is essentially zero. This is not a hypothetical liability. Datacenter operators who refresh hardware on a 3-5 year cycle find that PSB-fused EPYC parts have markedly lower resale value than equivalent non-fused parts. The "right answer" depends on the customer's threat model, but the trade is real.

On Ryzen client parts, PSB has historically been opt-in per platform; many consumer Ryzen systems ship with PSB unfused and Pluton (where present) gated by the soft-fuse [@amd-psb-whitepaper] [@garrett-pluton-2022].

Caliptra: the open multi-signer answer

The most ambitious structural answer to the MSI-leak problem currently in active development is Caliptra, a CHIPS Alliance project announced on December 13, 2022 [@chipsalliance-caliptra]. Caliptra is "the specification, silicon logic, ROM and firmware for implementing a Root of Trust for Measurement (RTM) block inside an SoC" [@caliptra-repo]. The full RTL is open at chipsalliance/caliptra-rtl [@caliptra-rtl] and the firmware at chipsalliance/caliptra-sw [@caliptra-sw], both under Apache 2.0. The founding members include AMD, Google, Microsoft, and NVIDIA.

The structural properties Caliptra targets, which neither Boot Guard, PSB, nor Pluton currently provide on commodity client silicon, are: (1) open RTL so the trust anchor's silicon implementation is auditable gate-by-gate; (2) multi-signer support so a single OEM key compromise does not unilaterally compromise the trust chain; (3) datacenter-class scope first, with the design choices that follow from that target. Caliptra is not yet on shipping client silicon. It is the negative-space answer to the MSI leak: the structural fix that the chipset-fuse model does not have, but that the architecture community has now spent four years designing in the open.

Pluton closes the patch-latency gap. Caliptra closes the single-signer gap. Neither closes the supply-chain-of-silicon gap. That is the next section.

8. Theoretical Limits: Where the Chain Cannot Reach

Every defensive chain has a payload at the bottom -- the thing the chain ultimately protects against. The pre-boot trust chain protects against five attack classes. Here are the five it does not.

Key idea: The chain closes three threat classes well (OS-level rootkit persistence; signed-but-revoked bootloader chain-loading; remote firmware reflash without physical access) and structurally cannot close two others (physical-SPI-access before the platform is fused and locked; leaked OEM key on already-shipped silicon). Naming both sets is the precondition for any honest threat-model claim.

Limit 1 -- Physical SPI access bypasses everything above it

Even with Boot Guard or PSB enforced, an attacker who can write to SPI flash before the platform is fused and locked can overwrite the IBB and the BPM and own the next boot. Access vectors: manufacturing, repair, or certain integrated circuits that expose SPI on a debug header.

CHIPSEC [@chipsec-repo] [@chipsec-page] -- originated by Bulygin and colleagues at CanSecWest 2014 [@c7zero-chipsec] -- is the canonical pre-deployment audit framework for verifying the chipset write-protect bits on shipping platforms. Trammell Hudson's Thunderstrike, presented at 31C3 in December 2014 [@thunderstrike] [@ccc-31c3], is the canonical real-world demonstration: SPI substitution via a Thunderbolt Option ROM on Apple Mac EFI. It is the existence proof that "physical access plus the right bus" can bypass the silicon-rooted verifier when the platform's write-protections are not fully engaged.

Limit 2 -- A leaked OEM key cannot be revoked at the fuse layer

The MSI 2023 incident, recompressed: the FPF stores the hash of the OEM Boot Guard public key, not a revocation list against that hash. There is no fuse-layer primitive for marking the hash as "revoked." Once the corresponding private key leaks, every chip carrying that hash is permanently downgraded to a model in which the attacker can sign new Boot Guard firmware that the platform will accept [@binarly-msi] [@helpnet-msi-leak] [@register-msi-alt].

The structural fix is per-batch key derivation or multi-signer trust anchors; on commodity client silicon in 2026 this fix exists only as a design specification (Caliptra) and not as a shipped product [@caliptra-repo] [@chipsalliance-caliptra]. Eclypsium's "Vulnerable Boot Guard implementations" series [@eclypsium-blog] documents that the MSI leak is the third or fourth such incident across the Boot Guard vendor space. Lenovo, HP, Compal, and Quanta have all experienced similar leaks; MSI is simply the most extensively catalogued.

Limit 3 -- The trust chain cannot defend against malicious silicon

If the verifier chip itself is malicious -- substituted upstream of the customer's supply chain -- the chain's invariants do not hold, because the bottom of the chain is what defines the trust model. Defending against this class is the supply-chain-of-silicon problem and is out of scope for this article. The open-RTL property of Caliptra is partial mitigation in the sense that the customer can at least verify that the silicon matches the specification, but verifying that a fabricated die corresponds to its RTL is an entirely separate research programme.

Limit 4 -- Thunderbolt SPI is a separate SPI region

Bjorn Ruytenberg's Thunderspy disclosure on May 10, 2020 [@thunderspy-report] [@thunderspy-site] targeted firmware vulnerabilities in the Thunderbolt controller chip on PCs with Thunderbolt 1 / 2 / 3 ports. The controller has its own firmware in its own SPI region, distinct from the main BIOS SPI region that Boot Guard / PSB verify.

Thunderspy let an attacker with physical access to the port flash modified Thunderbolt controller firmware, weakening the DMA isolation Thunderbolt 3 was supposed to provide. Thunderspy did not bypass Boot Guard, PSB, or Secure Boot. It bypassed a different verifier in a different SPI region for a different protocol.

The conflation -- "Thunderspy broke Secure Boot" -- appeared in early press coverage and persists in some secondary writing. The primary report is unambiguous that the target was Thunderbolt controller firmware [@thunderspy-report].

The structural lesson generalises beyond Thunderbolt: "SPI" on a modern PC is not a single trust domain. The main BIOS region, the Thunderbolt controller, the Embedded Controller, the fingerprint reader, and (on servers) the BMC each have their own SPI regions, their own update mechanisms, and their own verifier (if any). A vulnerability in one does not necessarily affect the others; but inventorying which regions are independently verified is a non-trivial procurement exercise.

Limit 5 -- The ME and PSP are themselves attack surface

The CSME and PSP exist to verify the platform's trust chain, but they are themselves programs running on processors. They have bugs. The disclosure record is sobering:

INTEL-SA-00086 (November 2017). Remote code execution in CSME via CVE-2017-5705, CVE-2017-5706, CVE-2017-5708, and CVE-2017-5712, pre-disclosed by the Ermolov / Goryachy BH EU 2017 work [@intel-sa-00086] [@ermolov-goryachy-2017].
CVE-2020-8705. A Boot Guard ACM vulnerability in the S3-resume code path that Trammell Hudson wrote up [@cve-2020-8705-nvd] [@trmm-sleep].
One Glitch to Rule Them All (CCS 2021). Buhren, Jacob, Krachenfels, and Seifert demonstrated voltage-glitching attacks against the AMD PSP on Zen 1, Zen 2, and Zen 3 [@one-glitch-2021], with open tooling at PSPReverse/amd-sp-glitch [@psp-glitch-repo].
faulTPM (USENIX Security 2024). The follow-up paper (arXiv v1 April 28, 2023) showed the same primitive could extract sealed TPM blobs from AMD fTPM, enabling BitLocker key recovery on devices using AMD fTPM-as-TPM [@faultpm-2023].

The faulTPM hardware cost is in the low hundreds of US dollars (commodity microcontroller plus voltage-glitching circuit). The capability the cost buys is full extraction of fTPM-sealed blobs. The "expensive nation-state-grade attack" framing does not apply here.

These attacks do not break the concept of a silicon-rooted trust chain. They break specific implementations of it. The conceptual chain is sound; the engineering surface inside each implementation has bugs that, once disclosed, get patched and shifted up the cadence. The pattern is structurally similar to OS kernel CVE disclosures. The existence of bugs does not mean the kernel concept fails; it means kernels need patch cadence. The difference at the firmware layer is that patch cadence at the CSME or PSP runs through the OEM BIOS update pipeline, which is slower than the OS pipeline by a factor of roughly ten.

Five limits. The first three are deep. The last two are open research.

9. Open Problems: What Is Still Being Researched

Five open problems. Three are about the chain. Two are about who gets to see inside it.

OEM key-management hygiene at industry scale. The Eclypsium series on leaked Boot Guard keys covers Compal, Quanta, Lenovo, and MSI across multiple disclosures [@eclypsium-blog]. The structural fix -- per-batch keys, multi-signer trust anchors, hardware-bound signing services -- exists as Caliptra in specification [@caliptra-repo] but not in shipping client silicon. The 2026 research question is not "do we know how to solve this" but "when and on which silicon families does Caliptra (or an equivalent) actually ship to consumer platforms."

Pluton firmware-runtime transparency. Microsoft has committed to a "Rust-based firmware foundation" for Pluton on 2024+ AMD and Intel systems [@pluton-learn] but has not publicly named the specific runtime. Community speculation around Tock OS [@tockos] (an embedded Rust kernel designed for security-critical microcontrollers) remains speculation; the connection has not been confirmed by Microsoft. Microsoft also has not published gate-level documentation of the Pluton silicon. The accountability gap -- "we asked you to trust this runtime; what is it" -- is itself an open problem and is the single most-cited objection to Pluton in the open-firmware community.

The Linux side of the KB5025885 transition. Shim distributions must coordinate with the PCA2011 to PCA2023 cutover or face boot failures on enforced-Secure-Boot multi-OS estates [@garrett-shim-19448] [@garrett-shim-17872] [@sbat-md]. Matthew Garrett's 2012 first-hand description of shim remains the cross-vendor architectural reference, and his 2022 / 2023 follow-ups document the operational hazards. The risk is not theoretical: a distribution that ships a shim signed only by PCA2011 and does not coordinate the migration to PCA2023 will not boot on Windows 11 systems that have completed the KB5025885 cutover.

Vendor-level attestation incompatibility. TCG TPM 2.0 quotes [@tcg-tpm-lib] are widely supported, but vendor-level attestation (Intel SGX DCAP [@sgx-dca], AMD SEV-SNP attestation, Pluton attestation) remain three incompatible schemes with three sets of root certificates, three quote formats, and three verifier libraries. A relying party that wants to attest a Confidential VM running on a mixed-vendor fleet must integrate against all three. The TPM 2.0 quote covers only the rungs visible to the TPM; it does not attest the CSME runtime, the PSP runtime, or the Pluton runtime in a vendor-neutral way.

DRTM deployment and revocation maturity. Windows 11 Secured-core requires DRTM via Intel TXT or AMD SKINIT, but mature revocation for DRTM-measured payloads is nascent. AMD fTPM glitch resistance on Zen 4+ is not yet publicly gate-level documented; the faulTPM team explicitly left Zen 4+ for future work [@faultpm-2023], and the absence of vendor disclosure leaves the question open at the level of public knowledge.

That is the research frontier. What follows is the practitioner's manual.

10. Practical Guide: How to Audit, Configure, and Reason About the Chain

Three audiences. Three checklists. One decision tree.

For the procurement architect: the seven-question silicon checklist

flowchart TD Q1{"Boot Guard enforced (profile 4 or 5) on Intel, or PSB-enforced on AMD?"} Q2{"PSB-fused to the correct OEM (not another OEM's key)?"} Q3{"Pluton present AND not gated by the OEM soft fuse?"} Q4{"DRTM-capable, Intel TXT or AMD SKINIT?"} Q5{"KB5025885 cumulative update applied?"} Q6{"PCA2023 present in db?"} Q7{"dbx SVN current per Microsoft January 2026 baseline?"} OK[Procurement-grade Secured-core posture] BAD[Reject or remediate before deployment] Q1 -- yes --> Q2 Q1 -- no --> BAD Q2 -- yes --> Q3 Q2 -- no --> BAD Q3 -- yes --> Q4 Q3 -- no --> BAD Q4 -- yes --> Q5 Q4 -- no --> BAD Q5 -- yes --> Q6 Q5 -- no --> BAD Q6 -- yes --> Q7 Q6 -- no --> BAD Q7 -- yes --> OK Q7 -- no --> BAD

For the firmware engineer: SBAT versus dbx revocation capacity

The asymmetric-revocation point gets sharper when you run it as code. The shim SBAT documentation makes the capacity claim concrete: "This single revocation event consumes 10kB of the 32kB, or roughly one third, of revocation storage typically available on UEFI platforms" [@sbat-md]. The block below shows what a single SBAT generation bump replaces in dbx storage.

{const DBX_CAPACITY_BYTES = 32 * 1024; const SHA256_HASH_BYTES = 32; const SBAT_ENTRY_BYTES = 40; const dbxCapacityHashes = Math.floor(DBX_CAPACITY_BYTES / SHA256_HASH_BYTES); const sbatCapacityEntries = Math.floor(DBX_CAPACITY_BYTES / SBAT_ENTRY_BYTES); console.log('dbx capacity in SHA-256 hashes :', dbxCapacityHashes); console.log('Equivalent SBAT generation rows :', sbatCapacityEntries); console.log(); const vulnerableShimBuilds = 256; const dbxBytesForShim = vulnerableShimBuilds * SHA256_HASH_BYTES; const dbxFractionUsed = (dbxBytesForShim / DBX_CAPACITY_BYTES * 100).toFixed(1); const sbatBytesForShim = 1 * SBAT_ENTRY_BYTES; const sbatFractionUsed = (sbatBytesForShim / DBX_CAPACITY_BYTES * 100).toFixed(1); console.log('Revoking', vulnerableShimBuilds, 'distinct vulnerable shim builds:'); console.log(' via dbx hashes :', dbxBytesForShim, 'bytes -', dbxFractionUsed + '% of capacity'); console.log(' via SBAT bump :', sbatBytesForShim, 'bytes -', sbatFractionUsed + '% of capacity'); console.log(); console.log('SBAT is roughly 256x more capacity-efficient at revoking entire vulnerability classes.');}

For the detection engineer: CHIPSEC modules per chain rung

Chain rung	CHIPSEC module	What it audits
SPI access policy (rung 1-2)	`common.spi_access`	SPI controller access permissions and region descriptors
SPI descriptor lockdown	`common.spi_desc`	SPI flash descriptor lock bit (FLOCKDN)
BIOS write-protect	`common.bios_wp`	BIOSWE / BLE / SMM_BWP configuration
BIOS timestamp	`common.bios_ts`	BIOS update timestamp consistency
SMM lockdown	`common.smm`	System Management Mode protections including SMM_BWP
SPI controller lockdown	`spi.spi_lock`	Per-region SPI write-protect and SPI controller lock

The full CHIPSEC module catalogue is in the chipsec/modules directory of the project repository [@chipsec-repo] [@chipsec-page]. A typical pre-deployment audit runs chipsec_main with the platform-specific module set and produces a per-module pass / fail report; any FAIL on the modules above maps directly to a known CVE class.

On a CHIPSEC-supported platform (Linux or Windows, with the kernel driver installed), `sudo chipsec_main` runs the full default module set against the current platform and prints a per-module PASS / FAIL summary. To restrict to the SPI / BIOS protection subset above, use `sudo chipsec_main -m common.bios_wp -m common.spi_desc -m common.spi_access -m spi.spi_lock -m common.smm -m common.bios_ts`. Read the CHIPSEC manual at [@chipsec-page] before running on production hardware; some modules touch SMI handlers and can wedge a misconfigured platform.

For the threat-model architect: three closed, three open

The chain closes three threat classes:

OS-level rootkit persistence below the kernel (Mebromi-class attacks against unprotected SPI).
Signed-but-revoked bootloader chain-loading (BlackLotus-class attacks against bootmgfw + Secure Boot).
Remote firmware reflash without physical access (driver-class attacks against poorly-locked SPI controllers).

The chain does not close three other classes:

Physical-SPI-access before the platform is fused and locked (Thunderstrike-class attacks via debug headers or controller ports).
Leaked OEM key on already-shipped silicon (MSI 2023-class capability transfers).
Supply-chain compromise of the silicon itself (the most-cited but operationally rarest class).

Practitioner alternative stacks

Note: If the OEM trust chain does not meet your threat model, the open-firmware community has an alternative for many platforms. - coreboot [@coreboot-org] [@wiki-coreboot] (originated as LinuxBIOS at Los Alamos National Laboratory in 1999) is the most widely deployed open firmware, shipping by default on every Chromebook. - Heads [@heads-repo] (Trammell Hudson's payload) runs on top of coreboot to provide TPM-measured boot with second-factor attestation (typically a YubiKey). It is the high-assurance Linux deployment baseline of choice for several investigative-journalism shops. - EDK II [@edk2-repo] is the reference open-source UEFI implementation if you need UEFI semantics rather than coreboot semantics. None of these magically restore revocation at the fuse layer, but they remove the OEM signing infrastructure as a single point of failure for everything above the fuse.

You now have the chain, the limits, and the controls. The FAQ kills the recurring misconceptions.

11. Frequently Asked Questions

Secure Boot in the abstract protects against unsigned-bootloader execution; it does not by itself protect against signed-but-vulnerable bootloader execution. BlackLotus exploited CVE-2022-21894 against a Microsoft-signed boot manager [@cve-2022-21894-nvd] [@eset-blacklotus]. The vulnerable binary was still signed -- and "patched" is not the same as "revoked." Until Microsoft adds the vulnerable binary's hash to dbx (which is what KB5025885 does, on a multi-year staged rollout to avoid bricking unpatched systems [@kb5025885]), Secure Boot will continue to load and execute the vulnerable binary. No -- see §6 Callout. KB5025885 modifies DB (PCA2023 added) and DBX (vulnerable bootmgfw hashes added); the Platform Key is untouched [@kb5025885]. This is a threat-model question, not a factual one. The Intel ME (now CSME on Skylake and later) runs MINIX 3 [@wiki-ime] [@tanenbaum-letter] and provides a set of services that the OEM may or may not have enabled: Active Management Technology, PTT firmware TPM, and Identity Protection Technology, among others [@intel-csme-whitepaper]. Whether you call that "a backdoor" depends on whether you consider remote attestation, hardware-rooted identity, and out-of-band management to be services or threats. The factual content is that the CSME runs, has its own runtime, has had CVEs (INTEL-SA-00086 [@intel-sa-00086] [@ermolov-goryachy-2017]), and ships on essentially every consumer Intel platform since Skylake. No. The name appears to be a confabulation that does not correspond to any verifiable primary research. The real SPI-write research bases for the pre-boot chain are Thunderstrike (Trammell Hudson, 31C3, December 2014 [@thunderstrike] [@ccc-31c3]), CHIPSEC (Bulygin et al., CanSecWest 2014 [@c7zero-chipsec]), and LogoFAIL post-exploitation (Binarly, December 2023 [@binarly-logofail]). If you see "Hudson Hammer" cited, treat it as a hallucinated reference. No -- Thunderspy targets a separate SPI region for the Thunderbolt controller. See §8 Limit 4 for the full mechanism [@thunderspy-report]. Cortex-A5 with TrustZone is the well-attested answer for Family 15h and Family 17h (see §3 hedge for the reverse-engineering corpus). Cortex-A7 is unsupported by any vendor primary or community reverse engineering. Family 19h and later is not publicly documented. No -- pre-Skylake ME (1 through 10) ran ThreadX on ARC; ME 11 (Skylake) introduced MINIX 3 on Intel Quark; Ice Lake and later CSME moved to Tremont-class x86 but kept MINIX 3. See the §3 generational table [@wiki-ime]. Because capability transfer is permanent regardless of when it gets operationalised. The leaked keys correspond to public-key hashes that have already been burned into the FPF on every affected chip [@binarly-msi] [@helpnet-msi-leak]. There is no fuse-layer revocation primitive [@register-msi-alt]. The chips are permanently downgraded to a model in which an attacker who has the leaked keys can sign new Boot Guard firmware that the platform will accept. The waiting time between disclosure and operationalisation is the only variable; the structural condition is not recoverable.

Closing thought

You came in believing Secure Boot was the trust anchor. You leave knowing it is the fifth rung. The four rungs below it -- microcode, ACM or PSP boot ROM, FPF or OEM-key fuse policy read, IBB verification -- are the ones that actually anchor the chain. The most permanent of those is the bottom rung, and the most permanent rung is also the one with no revocation surface. Read those two sentences together and you have the whole article in a paragraph. Read them with the MSI 2023 leak in mind and you have the reason this article needed to exist.

Mimikatz and the Credential-Theft Decade: The Windows Security Wars Part 3 (2009-2014)

noreply@paragmali.com (Parag Mali) — Sun, 31 May 2026 00:00:00 GMT

**2009-2014 was Windows security's parallel-revolution decade.** Microsoft shipped AppLocker, Secure Boot, ELAM, AppContainer, and in-box Defender [@ms-applocker; @ms-secure-boot; @ms-elam], retiring the rootkit class and the unsigned-bootloader class. In the same window, Stuxnet burned four Windows zero-days [@symantec-stuxnet-dossier-v14] against Iranian centrifuges and Benjamin Delpy released Mimikatz, which extracted every cached credential from LSASS in one command [@mimikatz-github; @greenberg-mimikatz-wired]. The defensive playbook closed per-binary attack surface while attackers pivoted up the trust stack to the credential layer that hardened binaries still had to trust. By November 11, 2014, Microsoft had acknowledged in product (Restricted Admin RDP, LSA Protected Process, KB2871997's WDigest opt-out) [@kb2871997; @ms-lsa-protection] and in print (the Mitigating Pass-the-Hash whitepaper v1 December 2012 and v2 July 2014) [@ms-pth-v1-landing; @ms-pth-v2] that the in-VTL0 LSASS model was structurally indefensible against an admin-privileged attacker on the same host. The architectural answer -- Virtualisation-Based Security and Credential Guard in Windows 10 1507 [@ms-credential-guard] -- ships eight months outside the window and opens Part 4.

1. Two Continents, Eleven Months Apart

Prerequisites. This article assumes the reader has the pre-2009 Windows-security context covered by Part 1 and Part 2, a working mental model of the Windows process / token / privilege-ring architecture (LSASS, NTLM, Kerberos AS-REQ/TGS-REQ, NTFS DACLs, EPROCESS internals, PCRs, SLAT, VTL0/VTL1), and familiarity with MS-NLMP section 3.3.2 NTLMv2 if you have not seen the construction before [@ms-nlmp-ntlmv2]. The graduate-seminar baseline is Windows Internals 6e Parts 1 and 2 [@windows-internals-6e-p1; @windows-internals-6e-p2].

June 17, 2010. An antivirus analyst at VirusBlokAda in Minsk named Sergey Ulasen receives a sample from an Iranian customer whose Windows boxes are rebooting on their own [@zetter-countdown-to-zero-day]. The dropper carries valid Authenticode signatures from Realtek Semiconductor and JMicron Technology [@symantec-stuxnet-dossier-v14]. The worm propagates via a previously unknown LNK shortcut bug that fires when Windows merely displays the icon of a crafted file [@ms-bulletin-ms10-046]. Eleven months later, in May 2011, a French government IT engineer named Benjamin Delpy publishes a closed-source proof-of-concept called Mimikatz that pulls NT hashes and Kerberos tickets out of the LSASS process memory of every Windows box he has ever logged into and prints them to the operator's console in one command [@greenberg-mimikatz-wired; @wikipedia-mimikatz]. The conventional history puts these two events on different pages of different books. This article argues they are the two visible faces of a single structural shift.

The shift is easy to state and easy to underrate. Defensive success at one layer reliably produces attacker innovation at the next layer up. Microsoft spent the 2009-2014 window shipping the most ambitious per-binary hardening programme of any commercial operating system in history -- AppLocker, ASLR improvements, BitLocker To Go, UEFI Secure Boot, Measured Boot, Early Launch Antimalware, AppContainer, the WinRT sandbox, and in-box Windows Defender [@ms-applocker; @ms-secure-boot; @ms-elam; @windows-internals-6e-p1]. The programme worked. It killed the unsigned-bootloader rootkit class, the pre-antivirus-launch malware class, and the in-process Internet Explorer rendering pwnage class. None of those primitives stopped Stuxnet on a Windows 7 host with USB enabled, and none of them stopped Mimikatz on any host where an administrator opened a console.

The reason is structural, not engineering. Every per-binary mitigation prevents the wrong code from running. Stuxnet's win32k.sys kernel exploit and Mimikatz's sekurlsa::logonpasswords command did not need to be wrong code. They needed to be the right code -- code an administrator chose to run, or a signed driver Microsoft itself had allowed to load -- running where the credentials lived. The credentials lived in the memory of a long-lived user-mode service called LSASS, and they lived there by design because the single sign-on contract requires the operating system to re-authenticate the user to network servers without re-prompting [@ms-credentials-processes]. The mitigation surface and the attack surface were not at the same layer.

timeline title 2009-2014 Windows Security Split Screen section Defender Oct 22 2009 : Windows 7 GA: AppLocker, ASLR improvements, BitLocker To Go Oct 26 2012 : Windows 8 GA: Secure Boot, ELAM, AppContainer, in-box Defender Oct 17 2013 : Windows 8.1: Restricted Admin RDP, LSA Protected Process May 13 2014 : KB2871997: WDigest opt-out, Restricted Admin back-port Nov 11 2014 : MS14-066 Schannel patch closes the window section Attacker Jan 12 2010 : Operation Aurora disclosed (single IE 0-day, espionage) Jun 17 2010 : VirusBlokAda identifies Stuxnet from an Iranian customer sample Dec 27 2010 : Dang and Ferrie present Stuxnet analysis at 27C3 Berlin May 2011 : Delpy releases Mimikatz (closed source) Aug 1 2013 : Duckwall and Campbell BlackHat USA Pass-the-Hash 2 Apr 6 2014 : Mimikatz GitHub repository created Aug 7 2014 : Delpy and Duckwall BlackHat USA Golden Ticket reveal

If both events were faces of the same shift, what was the shift? To see it, we have to start with what Microsoft was actually shipping.

2. The Hardening Decade: What Microsoft Was Doing 2009-2014

The popular story of 2009-2014 is that Microsoft was asleep while the Russians ate their lunch. That story is wrong. Microsoft shipped, in a single five-year window, more new platform-security primitives than the company had shipped in the previous decade combined. The problem was not the engineering. The problem was that the entire programme was orthogonal to the credential layer.

2.1 Windows 7 (October 22, 2009): per-binary control, finally

Windows 7 was the first Microsoft client operating system shipped after the Trustworthy Computing memo had finished one full Secure Development Lifecycle revolution. The headline platform addition was AppLocker, an application-control framework that let administrators allow or deny executables, scripts, MSI installers, DLLs, and packaged apps by publisher, file hash, or path [@ms-applocker]. Rules were authored in Group Policy and enforced by the Application Identity service. The rule-collection design was the first time a Microsoft Windows shipped a coherent allowlisting story rather than a bag of registry knobs.

AppLocker carried two structural gaps that took years to live down. First, the DLL rule collection was off by default. Enabling it broke application compatibility on almost every real estate. Second, the Application Identity service ran as a normal Windows service, which meant an attacker who reached LocalSystem could sc stop AppIDSvc and degrade enforcement open until the next reboot.This admin-stoppable-service gap is the design lesson that becomes the brief for Windows Defender Application Control's kernel-enforced policy model in Part 4 of this series. A third structural gap matters for the credential-theft era this article documents. AppLocker's publisher- and path-rule design decisions assume the file-system DACL stack enforces a clean read-allow / write-deny split for low-privileged users [@ms-applocker-design]. It does not.

The well-known operator bypass on a default Windows 7 install proceeds in four steps. Step one: identify a directory whose path matches the AppLocker default %WINDIR%\* allow rule for non-administrators (%WINDIR%\Tasks is the canonical example because it ships with permissive ACLs to let the Task Scheduler service write child files). Step two: drop the unsigned payload binary into that directory. Step three: invoke the binary by full path. Step four: observe that AppLocker's path-rule engine consults the configured policy rather than the file's actual DACL stack and permits execution because the parent directory matches the allow-rule glob. The bypass exists because AppLocker's rule evaluation and NTFS's DACL stack live on two independent rails that disagree about which paths a non-administrator may write; the cleanup that closes this class of bypass landed in Windows Defender Application Control, which is the Part 4 story.

AppLocker killed the per-binary "double-click an unsigned EXE on a managed desktop" attack class on every estate that deployed it, which turned out to be a strikingly small fraction of the Fortune 500.

Windows 7 also tightened the in-process mitigation surface. Address Space Layout Randomisation got a new opt-in ForceASLR flag callable via the loader's MitigationOptions field, letting administrators force randomisation even on EXEs and DLLs that had been compiled without the /DYNAMICBASE linker switch [@windows-internals-6e-p1].

BitLocker To Go for removable media finally gave administrators a defensible answer to the lost-USB-stick incident report. The on-disk format is a Full Volume Encryption v2 (FVE2) volume encrypted with plain AES-CBC; unlike fixed-disk BitLocker on Vista and original-release Windows 7, BitLocker To Go disables the Elephant Diffuser on removable drives so the small unencrypted discovery volume at the start of the device can ship BitLockerToGo.exe, the Windows XP / Vista BitLocker To Go Reader that supports plain AES-CBC only [@ms-bitlocker-configure]. The Reader prompts for one of three key protectors: a password, a smart card, or an automatic-unlock recovery key escrowed by Group Policy to Active Directory. The discovery-volume design is the operational concession that lets a 2009 administrator hand a BitLocker-To-Go stick to a vendor running Windows XP SP3 without giving the vendor a usable plaintext copy; the diffuser drop is the cryptographic concession that makes the Reader compatibility story possible. The threat-model concession that BitLocker To Go does not cover is the unattended-laptop / cold-boot attack class against the primary disk's TPM-released VMK [@ms-bitlocker-countermeasures], which is the Evil-Maid territory Joanna Rutkowska and Alex Tereshkin demonstrated against TrueCrypt full-disk encryption in October 2009 [@rutkowska-evil-maid-2009] and which BitLocker would not fully answer until pre-boot PIN enforcement matured.

DirectAccess shipped as an always-on, certificate-anchored, IPsec-over-IPv6 tunnelled successor to traditional VPNs. The architectural design used a dual-tunnel model [@ms-directaccess-design-guide]: an infrastructure tunnel established at machine boot using a machine certificate, which gave the client reach-back to domain controllers, DNS, and management infrastructure before any user had logged on; and an intranet tunnel established at user logon using user credentials, which carried application traffic to the internal corporate network.

Because DirectAccess required end-to-end IPv6 in an era when public IPv6 was a rounding error, the design layered three transition technologies in priority order: 6to4 (for clients with a public IPv4 address), Teredo (for clients behind NAT), and IP-HTTPS (a TLS-encapsulated IPv6 transport that worked across any environment that allowed outbound HTTPS, included specifically as the fallback for hotel and conference networks that blocked native IPv6 and UDP-Teredo). The always-on-before-logon property is what made DirectAccess operationally distinct from a traditional VPN: a help-desk-recoverable password reset, a Group Policy push, or a software-distribution job could reach a remote machine the instant it had Internet connectivity, with no user action required.DirectAccess was later quietly deprecated in favour of Always On VPN and Microsoft Tunnel; the architectural lesson it carries is that certificate-anchored client trust scales operationally only when the certificate lifecycle is automated end-to-end.

What this killed: the per-binary "unsigned EXE on a managed desktop" class. What it did not touch: anything inside an LSASS-holding process tree.

2.2 Windows 8 (October 26, 2012): the boot chain and the sandbox

Windows 8 is the year the per-binary playbook reached architectural maturity. Four primitives shipped at once, and they all aim at distinct points on the trust stack.

UEFI Secure Boot anchors the boot chain in firmware. The Platform Key, signed Key Exchange Keys, and the signature database db together require the firmware to verify the signature of every UEFI driver, every option ROM, and the operating-system loader before transferring control [@ms-secure-boot; @ms-bulletin-ms10-046]. A revocation database dbx lets Microsoft retire keys and binaries that have been compromised. Windows 8 was the first Microsoft client operating system whose Logo certification required Secure Boot enablement by default; the chain is anchored to the UEFI 2.3.1 Errata C specification (June 2012).

Measured Boot complements Secure Boot. Each stage of the boot chain extends a SHA-256 measurement into Platform Configuration Registers 0 through 7 of the Trusted Platform Module, and the TPM event log records what was measured [@windows-internals-6e-p1]. BitLocker can then bind its Volume Master Key release to a specific PCR profile, so a tampered bootloader will not yield the disk key on next boot. Secure Boot decides whether the code is allowed to run; Measured Boot decides whether to release secrets to the code that ran.

Early Launch Antimalware (ELAM) is the first boot-start driver loaded after the kernel. ELAM gets to inspect, classify, and refuse subsequent boot-start drivers via the BDCB_CLASSIFICATION enumeration, which returns Good, Bad, Unknown, or BadButCritical [@ms-elam].Microsoft's own ELAM driver, WdBoot.sys, ships with Windows Defender; third-party antivirus vendors such as McAfee, Symantec, CrowdStrike, and SentinelOne ship their own ELAM drivers post-2014. ELAM services themselves run as a Protected Process Light, which prevents lower-signer-level code from injecting into the antimalware engine. ELAM killed the rootkit-loaded-before-AV class that had defined kernel-mode malware tradecraft since the early 2000s.

AppContainer introduces the LowBox access token. Each Modern (Metro) Windows Runtime app receives a token with a per-package security identifier and a vector of capability SIDs; resource access checks intersect the capability set with the resource's discretionary access control list [@windows-internals-6e-p1]. The model is structurally similar to iOS entitlements: the kernel refuses any access the manifest did not declare. Windows 8 also ships the in-box Windows Defender (replacing the optional Microsoft Security Essentials), and Internet Explorer 10 runs Enhanced Protected Mode inside an AppContainer, killing the in-process IE-rendering pwnage class that had dominated browser-borne malware for a decade.

A word on branding discipline. Windows 8's sandbox is correctly named WinRT plus AppContainer plus Modern (Metro) apps. UWP (Universal Windows Platform) is the Windows 10 brand introduced July 29, 2015; calling any Windows 8 deliverable UWP is a category error.

What this killed: unsigned-bootloader rootkits (Secure Boot), pre-AV-launch malware (ELAM), in-process IE-rendering pwnage (AppContainer plus Enhanced Protected Mode). What it did not touch: LSASS.

2.3 Windows 8.1 and Server 2012 R2 (October 17, 2013): the first counter-pivot

Windows 8.1 is where Microsoft first lands product-level controls that directly answer credential-replay tradecraft.

Restricted Admin RDP changes the protocol so that the client never sends the user's plaintext password to the server's LSASS [@kb2871997]. Instead, the server issues a network challenge that the client signs with its local NT hash. The classic credential-disclosure-at-server failure mode (a foothold on the RDP server learns every administrator's plaintext password as they log in) is closed. The replay failure mode is not, but Section 6 evaluates that honestly.

LSA Protected Process loads the LSASS process as a Protected Process Light with the signer level PsProtectedSignerLsa. Once Protected, even a process running as NT AUTHORITY\SYSTEM cannot call OpenProcess(PROCESS_VM_READ) against LSASS [@ms-lsa-protection]. The flag is enabled by setting HKLM\SYSTEM\CurrentControlSet\Control\Lsa\RunAsPPL to 1. The architectural intuition is right; the bypass class lives in kernel mode and gets evaluated in Section 6.

Note: Restricted Admin RDP and LSA Protected Process are the first product-level Microsoft acknowledgements that the credential layer needed its own defensive rail, distinct from the per-binary playbook. Together they foreshadow the architectural pivot that ships in Windows 10 1507 as Virtualisation-Based Security and Credential Guard [@ms-credential-guard]. The full evaluation of both controls -- what they accomplish, what they leave open, and why -- is the subject of Section 6.

Every primitive above stops the wrong code from running. The threat model is about to move on.

3. Stuxnet: The Nation-State Zero-Day Reveal

3.1 Discovery timeline

Sergey Ulasen's June 17, 2010 sample at VirusBlokAda is the public discovery date [@zetter-countdown-to-zero-day]. The worm had been operating in the wild since at least 2009. Within weeks, Kaspersky, Symantec, and ESET independently confirmed the family. By September 2010, Ralph Langner at Langner Communications had identified the payload's specific target: Siemens Step 7 industrial-control software running on S7-300 programmable logic controllers, programmed to manipulate the rotor speeds of cascade-mounted gas centrifuges at the Natanz uranium enrichment facility in Iran [@langner-to-kill-a-centrifuge].

On December 27, 2010, Bruce Dang of Microsoft's Security Response Center and Peter Ferrie co-presented "Adventures in Analyzing Stuxnet" at the 27th Chaos Communication Congress (27C3) in Berlin [@dang-ferrie-27c3].The venue is 27C3, not 29C3, and Dang's affiliation is Microsoft MSRC, not Symantec; the talk is the canonical engineering primary for the win32k.sys keyboard-layout kernel exploit. Their first-hand engineering walkthrough of the win32k.sys kernel exploit is the canonical record of how Stuxnet escalated privilege on patched Windows 7 systems. In February 2011, Nicolas Falliere, Liam O Murchu, and Eric Chien of Symantec Security Response published the v1.4 W32.Stuxnet Dossier, which enumerated the four Windows zero-days, the two stolen Authenticode certificates, and the Step 7 / S7-300 payload [@symantec-stuxnet-dossier-v14]. Ralph Langner's November 2013 "To Kill a Centrifuge" closed the analytical loop by identifying not one but two distinct centrifuge-attacks bundled into the same worm: an earlier rotor-overpressure attack and the later rotor-speed manipulation attack [@langner-to-kill-a-centrifuge].

3.2 The four zero-days

The Symantec dossier's accounting of Stuxnet's Windows zero-days is the canonical inventory. There were four, used across the worm's propagation and escalation surfaces, not chained in a single sequential exploit.

Bulletin	CVE	Role in the worm	Patch date
MS10-046	CVE-2010-2568	LNK shortcut RCE; propagation via USB without autorun [@ms-bulletin-ms10-046]	August 2, 2010
MS10-061	CVE-2010-2729	Print Spooler RCE; network-layer propagation [@ms-bulletin-ms10-061]	September 14, 2010
MS10-073	CVE-2010-2743	win32k.sys keyboard-layout local privilege escalation [@ms-bulletin-ms10-073]	October 12, 2010
MS10-092	CVE-2010-3338	Task Scheduler local privilege escalation [@ms-bulletin-ms10-092]	December 14, 2010

The LNK bug (MS10-046) is the propagation-by-USB primitive that gave Stuxnet its air-gap-jumping reputation: merely displaying the icon of a crafted shortcut, which Windows Explorer did automatically when the user opened the USB drive, triggered code execution [@ms-bulletin-ms10-046]. The Print Spooler RCE (MS10-061) addressed a Spooler permissions-validation bug that let Stuxnet propagate over the network as a printer-share request [@ms-bulletin-ms10-061].The Print Spooler attack surface returned a decade later as CVE-2021-34527 PrintNightmare, demonstrating that a sufficiently complex local-privilege-escalation surface tends to be re-discoverable across architectural rewrites. The keyboard-layout LPE (MS10-073) was the one Dang and Ferrie walked at 27C3 -- the kernel indexed a table of function pointers when loading a keyboard layout from disk, and Stuxnet supplied a layout that pointed the index at attacker memory [@ms-bulletin-ms10-073]. The Task Scheduler LPE (MS10-092) corrected the way Task Scheduler conducted integrity checks to validate that tasks ran with their intended user privileges [@ms-bulletin-ms10-092]. Stuxnet also re-used the older MS08-067 NetAPI worm bug on unpatched hosts as a non-zero-day propagation path [@ms-bulletin-ms08-067] -- this is the Conficker bug from October 2008, not a 2010 zero-day, and any four-zero-day count that includes it is wrong.

flowchart LR subgraph Propagation A["LNK shortcut RCE
MS10-046 / CVE-2010-2568"] B["Print Spooler RCE
MS10-061 / CVE-2010-2729"] end subgraph Escalation C["win32k.sys keyboard-layout LPE
MS10-073 / CVE-2010-2743"] D["Task Scheduler LPE
MS10-092 / CVE-2010-3338"] end subgraph Payload E["Siemens Step 7 / S7-300 PLC
centrifuge rotor manipulation"] end A --> C A --> D B --> C B --> D C --> E D --> E

3.3 The stolen Authenticode certificates

The worm's dropper was signed by two real, valid Authenticode certificates issued to Realtek Semiconductor and JMicron Technology [@symantec-stuxnet-dossier-v14]. Both certificates were revoked within weeks of disclosure, but during the operational window of Stuxnet, every signature check Windows performed against the dropper returned a clean verdict.The Realtek and JMicron certificates were not merely stolen out of an email inbox; the corresponding hardware security modules were almost certainly accessed in person at the original equipment manufacturers' facilities in the Hsinchu Science Park, Taiwan -- the long-form reconstruction in Kim Zetter's Countdown to Zero Day lays out the physical-access logistics that the wire-only theft hypothesis cannot satisfy [@zetter-countdown-to-zero-day]. This prefigured the supply-chain attack class that becomes SolarWinds a decade later. This was the first publicly analyzed kinetic-effect proof that the code-signing trust root -- Authenticode and the kernel-mode driver signing PKI that depended on it -- was an adversary target rather than a structural defence.

3.4 Architectural lessons

Two structural lessons emerged from the disclosure cycle. First, USB as an attack surface acquired its own discipline. In February 2011, Microsoft re-released the autorun update covered by Microsoft Security Advisory 967940 / KB971029 as an automatic update via Windows Update, having previously offered it as an optional patch in February 2009 [@krebs-autorun-2011]. Second, IT and operational-technology (OT) cross-domain trust collapsed as a defensible perimeter -- Natanz was an air-gapped network that a USB stick crossed, and every CISO with operational-technology assets had to re-ask the question of whether a nation-state would burn a Windows zero-day to break their plant.

3.5 Did Stuxnet defeat any defender primitive Windows 7 shipped?

The narrow answer is no, the worm did not need to. Stuxnet's propagation primitives carried their own attack code -- the LNK bug ran from Explorer, the Spooler bug ran from the printer-share RPC interface -- so they did not need to defeat AppLocker (AppLocker only blocks executions a configured rule denies; an explorer.exe rendering a crafted shortcut was not a denied execution) or ASLR or DEP. The win32k.sys local privilege escalation, however, foreshadowed the Section 5 argument neatly: the per-binary mitigations Windows 7 shipped (AppLocker, ASLR, DEP, ForceASLR) did nothing for a kernel-mode bug, because kernel-mode is where those mitigations are enforced from.

3.6 Was Stuxnet really the first nation-state Windows zero-day operation?

Only with two qualifiers. Operation Aurora -- the espionage campaign Google publicly disclosed on January 12, 2010 [@google-aurora-blog; @google-aurora-wayback] -- pre-dates Stuxnet's June 2010 public identification by roughly five months and used a single Windows / Internet Explorer zero-day, the IE use-after-free catalogued as CVE-2010-0249 [@nvd-cve-2010-0249], for cyber-espionage. Google's own disclosure stated that "at least twenty other large companies from a wide range of businesses -- including the Internet, finance, technology, media and chemical sectors -- have been similarly targeted" [@google-aurora-wayback]. The publicly named subset that emerged across the January 12-15, 2010 disclosure window included Adobe Systems (acknowledged on the Adobe corporate blog January 12, 2010) [@adobe-aurora-disclosure], Juniper Networks, Rackspace [@wikipedia-operation-aurora], plus Yahoo, Symantec, Northrop Grumman, Dow Chemical, and Morgan Stanley named in Ariana Eunjung Cha and Ellen Nakashima's Washington Post coverage on January 14, 2010 [@wapo-aurora-cha-nakashima]. Dmitri Alperovitch of McAfee Labs named the campaign "Operation Aurora" on January 14, 2010 based on a \..\Aurora_Src\AuroraVNC\ file-path string recovered from the malware binaries [@mcafee-aurora-alperovitch]. Microsoft patched the IE bug out-of-band as MS10-002 on January 21, 2010 [@ms-bulletin-ms10-002].

Aurora is the necessary disambiguation. The popular framing of Stuxnet as the first nation-state Windows zero-day operation is *false* without qualifiers. Aurora used one zero-day for espionage in January 2010; Stuxnet used four zero-days for kinetic effect in June 2010. The defensible framing is: *Stuxnet is the first publicly analyzed nation-state Windows operation that burned multiple zero-days for kinetic, physical effect* [@symantec-stuxnet-dossier-v14; @google-aurora-blog; @nvd-cve-2010-0249]. Both qualifiers ("multi-zero-day" and "kinetic / physical") are load-bearing. Drop either and Aurora falsifies the framing.

Stuxnet showed nation-states would burn four Windows zero-days for a single operation. But four zero-days is an expensive way to compromise a credential, and as it turned out, a French engineer was about to make zero-days irrelevant for the credential-theft problem.

4. Mimikatz: The Credential Layer Demolition

Benjamin Delpy describes Mimikatz, in Andy Greenberg's Wired profile, as "a side project to learn C" [@greenberg-mimikatz-wired]. The reader's natural reaction -- a side project that broke a decade of Microsoft's most ambitious hardening programme? -- is precisely the point.

4.1 Delpy, LSASS, and the May 2011 release

Delpy was at the time an IT manager at a French government institution he declines to name [@greenberg-mimikatz-wired]. He had become curious about an architectural quirk: Windows could prompt for his password at logon, then later authenticate him to remote IIS and SMB servers using HTTP Digest without ever asking again. Something inside the OS had to hold a recoverable form of his password. He started reverse-engineering the Local Security Authority Subsystem Service (LSASS) and the credential-provider tree behind it.

A long-lived user-mode Windows process that holds the secrets the operating system needs to satisfy single sign-on across SMB, RPC, HTTP, RDP, IIS, and MS-SQL without re-prompting the user. By design, LSASS caches NT hashes, Kerberos Ticket-Granting Tickets, and (depending on the loaded security packages) recoverable plaintext credentials [@ms-credentials-processes]. It is the load-bearing target of every credential-extraction tool the next decade produces.

The architectural quirk was structural, not accidental. The single sign-on contract requires the operating system to re-authenticate the user to network services, and the network protocols of the 1990s and 2000s (NTLM, Kerberos, HTTP Digest, MS-CHAP) all required either a hash, a ticket, or a recoverable plaintext to do that re-authentication [@ms-credentials-processes]. LSASS held all three. There was no way to satisfy the contract without holding the secret in some recoverable form inside an LSASS-controlled memory region.

Delpy released the first version of Mimikatz in May 2011 as closed-source software [@greenberg-mimikatz-wired; @wikipedia-mimikatz].Delpy describes Mimikatz as "a side project to learn C" in the Wired profile; the framing matters because it underlines that breaking Windows credential security at this depth did not require nation-state resources -- a single engineer with a debugger could do it. Microsoft's response to his initial private disclosure had been, in his telling, that "you don't want to fix it"; he made the tool public to force the conversation. The GitHub repository gentilkiwi/mimikatz was created on April 6, 2014 at 18:30:02 UTC -- the API-verifiable timestamp [@mimikatz-github]. Any "Mimikatz first released in 2007" claim refers to Delpy's pre-release private experimentation, not a public release.

4.2 Four primitives that broke the credential layer

The Mimikatz module set Delpy authored over 2011-2014 contains four primitives that together explain why every per-binary mitigation Microsoft had shipped was insufficient.

Replay an NT hash as a bearer credential against any service that accepts NTLM authentication, *without* ever knowing the user's plaintext password [@mimikatz-github; @duckwall-campbell-bh2013]. The NTLM protocol authenticates by proof-of-possession of the NT hash, not proof-of-knowledge of the password.

Pass-the-Hash is the load-bearing primitive. NTLM authentication on the wire authenticates by proof-of-possession of the NT hash, not proof-of-knowledge of the password. The plaintext password is computed exactly once, at logon, to derive the NT hash via MD4(UTF16LE(password)). After that the operating system does not need the cleartext again for NTLM. Anyone holding the hash can authenticate as the user without ever knowing the password. The real NTLMv2 protocol per MS-NLMP §3.3.2 is a two-stage HMAC-MD5 construction [@ms-nlmp-ntlmv2]: stage 1 derives an intermediate NTOWFv2 = HMAC_MD5(NT_hash, UTF16LE(UPPERCASE(user) || domain)); stage 2 computes NTProofStr = HMAC_MD5(NTOWFv2, ServerChallenge || ClientChallengeBlob). The bearer-credential invariant survives both stages -- the function consumes the NT hash directly and never references the cleartext -- which is the exact property Pass-the-Hash exploits.

{` // Illustrative -- the real NTLMv2 protocol is a two-stage HMAC-MD5 // construction (see MS-NLMP section 3.3.2): // Stage 1: NTOWFv2 = HMAC_MD5(NT_hash, UPPERCASE(user) || domain) // Stage 2: NTProofStr = HMAC_MD5(NTOWFv2, ServerChallenge || temp) // The Pass-the-Hash invariant -- that the NT hash is the bearer // credential because the protocol consumes it without ever needing // the cleartext password -- survives the simplification below. const crypto = require('crypto');

function ntlmResponse(ntHash, serverNonce, clientNonce) { // Simplified single-stage HMAC-MD5 keyed on the NT hash. // The plaintext password is never used by the protocol after logon. const hmac = crypto.createHmac('md5', Buffer.from(ntHash, 'hex')); hmac.update(Buffer.concat([serverNonce, clientNonce])); return hmac.digest('hex'); }

const stolenHash = '8846f7eaee8fb117ad06bdd830b7586c'; const serverNonce = Buffer.from('0123456789abcdef', 'hex'); const clientNonce = Buffer.from('fedcba9876543210', 'hex');

console.log('NTLM response:', ntlmResponse(stolenHash, serverNonce, clientNonce)); console.log('No plaintext password was used. The hash IS the credential.'); `}

Note: The plaintext password is not the secret. Once the operating system has derived the hash at logon, anyone who reaches LSASS and reads that hash can authenticate as the user against any NTLM-accepting service for as long as that hash remains valid -- which is until the user next changes the password. The credential-replay class is a corollary of this single insight applied to different bearer credentials.

Extract a Kerberos Ticket-Granting Ticket or service ticket from LSASS and re-import it into another logon session for replay. Mimikatz exposes both halves: `sekurlsa::tickets /export` extracts; `kerberos::ptt` re-imports [@mimikatz-github].

Pass-the-Ticket is the Kerberos analogue of Pass-the-Hash. A Kerberos TGT is a bearer credential by design -- it proves the holder authenticated to the Key Distribution Center -- and like the NT hash, anyone holding the ticket can replay it. Mimikatz's kerberos::ptt injects a ticket blob into the local session's ticket cache; the next call to klist shows it as if the local logon had earned it.

Use a stolen NT hash to request a *fresh* Kerberos TGT from the Key Distribution Center -- the bridge from an NTLM-recovered hash to a Kerberos-issued ticket. Defeats estates that have disabled NTLM but trust Kerberos pre-authentication keys derived from the same password hash [@mimikatz-github].

Overpass-the-Hash is the bridge primitive. Estates that disabled NTLM in 2012-2014 in response to early Pass-the-Hash discussion believed they had closed the credential-replay door. Overpass-the-Hash re-opened it by re-using the NT hash to compute the Kerberos pre-authentication value, then sending a normal Kerberos AS-REQ. The KDC issued a TGT keyed on the same secret the NTLM stack had used. From there, every subsequent Kerberos service ticket request was a legitimate Kerberos exchange backed by a stolen secret.

WDigest plaintext-in-memory is the fourth primitive, and the one that surprised even Microsoft's own teams when Delpy demonstrated it. Microsoft's WDigest Security Support Provider, which implemented HTTP Digest authentication on the server side and Digest single sign-on on the client side, held the user's plaintext password in LSASS memory by design, recoverable as long as the user's session was active.WDigest predates the modern web; HTTP Digest authentication had been essentially deprecated by the time Mimikatz operationalised the plaintext-recovery primitive, which is why the KB2871997 opt-out has near-zero operational downside on any post-2010 estate. Mimikatz's sekurlsa::logonpasswords enumerated the loaded credential-providers, walked the LSASS heap structures, and printed every cached secret it could decrypt -- including, on most pre-2014 estates, the user's plaintext password in clear text.

(One discipline note. Skeleton Key is not one of the Part 3 Mimikatz primitives. Skeleton Key was disclosed by Dell SecureWorks Counter Threat Unit on January 12, 2015 [@secureworks-skeleton-key] and Delpy added misc::skeleton to Mimikatz on January 17, 2015, both outside the Part 3 window. It opens Part 4.)

sequenceDiagram participant Op as Operator (Admin) participant Mim as mimikatz.exe participant Krn as Windows Kernel participant LSA as LSASS.exe Op->>Mim: privilege::debug Mim->>Krn: AdjustTokenPrivileges (SeDebugPrivilege) Krn-->>Mim: TRUE Op->>Mim: sekurlsa::logonpasswords Mim->>Krn: OpenProcess (PROCESS_VM_READ on LSASS PID) Krn-->>Mim: process handle Mim->>LSA: ReadProcessMemory (walk security-package list) LSA-->>Mim: encrypted credential blobs Mim->>Krn: BCryptDecrypt (LSA master key from same address space) Krn-->>Mim: cleartext NT hashes, TGTs, WDigest plaintexts Mim-->>Op: print every cached secret

4.3 The 2013 inflection: graph-walking offensive Active Directory

In August 2013, Skip Duckwall and Chris Campbell delivered "Pass-the-Hash 2: The Admin's Revenge" at Black Hat USA [@duckwall-campbell-bh2013]. The talk did not invent the primitives Mimikatz had already shipped. It made offensive Active Directory tradecraft a public, named discipline by formalising the graph-walking insight: every Windows host an administrator logs into caches a credential for that administrator; every credential cached on a compromised host is a stolen credential; every stolen credential is a new starting node for the next lateral movement. The attack graph closes on the domain controller within hops measured in single digits on almost every real enterprise estate.

The discipline decomposes into a four-step iterative loop on any Windows estate with cached domain credentials [@duckwall-campbell-bh2013]. Step one: enumerate active sessions on the compromised host -- NetSessionEnum returns inbound SMB sessions, NetWkstaUserEnum returns the logged-on user list (pre-KB4480964 without admin rights), and quser / qwinsta enumerate interactive logons. The output is the (user, host) tuple set representing every credential cached in the host's LSASS. Step two: identify a reachable administrator -- cross-reference each enumerated user against local Administrators group membership and against the domain groups that grant administrative access to a higher-tier host. The output is a set of (harvested-user, target-host) tuples where the harvested credential can be replayed against the target with administrative privilege. Step three: Pass-the-Hash to the higher-tier host -- inject the harvested NT hash into a new logon session via sekurlsa::pth /run:... and execute remote commands against the target as the harvested user, with no need for the cleartext password [@mimikatz-github]. Step four: harvest the new host's LSASS and repeat -- sekurlsa::logonpasswords against the new beachhead dumps every credential that host has cached, each becoming a new starting node for the next iteration. The loop terminates when one harvested credential is a Domain Admin.

This four-step loop is the implicit graph the article's diagram illustrates: vertices are users and hosts, edges are MemberOf (user is a group member), AdminTo (user has administrative access to a host), and HasSession (a host currently caches a credential for a user). Three years later, Andy Robbins, Will Schroeder, and Rohan Vazarkar productized this graph at DEF CON 24 in Las Vegas on August 6, 2016 as BloodHound, which uses the SharpHound collector to enumerate every vertex and edge, loads them into a Neo4j database, and runs Cypher shortest-path queries from any compromised principal to the Domain Admins group [@bloodhound-defcon24]. BloodHound is a 2016 artifact and properly belongs to Part 4; for the 2009-2014 Part 3 window, the graph existed only in operator notebooks and on Duckwall and Campbell's whiteboard, but every Windows estate already had it -- the attacker just had to walk it.

4.4 The 2014 inflection: the Golden Ticket

In August 2014, Benjamin Delpy and Skip Duckwall jointly presented "Abusing Microsoft Kerberos: Sorry You Guys Don't Get It" at Black Hat USA [@delpy-duckwall-bh2014].The dual authorship matters: Delpy and Duckwall presented the talk together, and any single-author attribution misses the collaboration that produced the Golden Ticket walkthrough. The headline reveal was the Golden Ticket: a forged Kerberos Ticket-Granting Ticket signed with the stolen NT hash of the domain's krbtgt account.

A forged Kerberos Ticket-Granting Ticket signed with the stolen NT hash of the domain's krbtgt service account. Grants arbitrary user, arbitrary group, and arbitrary lifetime impersonation across every domain controller in the Active Directory forest. Survives every password reset *except* the krbtgt account's own [@delpy-duckwall-bh2014; @metcalf-golden-ticket].

The krbtgt account is the master signing key for the domain's Kerberos infrastructure. Every TGT a domain controller issues is signed with the krbtgt NT hash, and the domain trusts any TGT that verifies against that hash. If an attacker holding domain-admin privileges has ever extracted the krbtgt hash from a domain controller's LSASS, they can forge a TGT for any user, with any group membership, with any lifetime they choose -- and the domain controllers will accept it as if it had been legitimately issued. The forged ticket survives every routine password reset on the domain because routine password resets do not rotate the krbtgt account. Sean Metcalf's ADSecurity walkthrough remains the practitioner-grade canonical reference [@metcalf-golden-ticket].

4.5 What this proved

By the end of 2014, the Mimikatz codebase had operationalised pass-the-hash, pass-the-ticket, overpass-the-hash, WDigest plaintext recovery, and the Golden Ticket on a default-configured modern Windows host. Every credential the LSA process held in memory in a recoverable form was structurally exposed.

The scope of that claim matters. TPM-bound keys, smart-card private keys behind a hardware boundary, and Kerberos service keys on Windows servers whose LSASS the attacker had not yet compromised were not exposed by Mimikatz. The precise statement is every credential the LSA process held in memory in a recoverable form, not "every Windows credential primitive ever," and the precise statement is the one Microsoft eventually acknowledged in the Mitigating Pass-the-Hash whitepaper series [@ms-pth-v2].

Mimikatz did not need to defeat AppLocker, ASLR, DEP, or Authenticode. It ran as an administrator, called OpenProcess on LSASS, and walked away with every cached credential the operating system would ever hold. The defender's playbook had been answering the wrong question.

Stuxnet was a four-zero-day operation that ran once. Mimikatz was a free, open-source command that ran every time. The offensive economics of attacking Windows fleets shifted decisively away from zero-day-burning and toward credential replay. Why did this happen, and what does it mean for the next decade of Windows defence?

5. The Causal Link: Hardening Birthed the Credential-Theft Class

After two parallel narratives, the reader has the evidence to follow the argument. This is the article's intellectual centre.

5.1 The pivot up the trust stack

While Microsoft was closing per-binary attack surface -- Authenticode, kernel-mode code signing, ASLR, DEP, AppLocker, AppContainer, ELAM, Secure Boot -- attackers pivoted up the trust stack to what those hardened binaries still had to trust: the credentials in LSASS memory, the Kerberos tickets in the LSA cache, and the LSA process address space itself. The mitigation surface and the attack surface are not at the same layer. This is the article's structural insight, and it is the single sentence the rest of the argument exists to defend.

flowchart TD A["Hardware root: TPM, UEFI Secure Boot db/dbx"] B["Bootloader signature chain (Secure Boot, Measured Boot)"] C["Kernel-mode code (KMCS, ELAM as first boot-start driver, PatchGuard)"] D["User-mode signed binaries (Authenticode, AppLocker rules)"] E["Sandboxed renderers (AppContainer, EPM, WinRT)"] F["LSASS process memory: NT hashes, Kerberos TGTs, krbtgt key"] G["Attacker primitive: Mimikatz sekurlsa::logonpasswords"] A --> B --> C --> D --> E --> F G -.reads.-> F style F fill:#fde68a,stroke:#b45309,color:#5f370e style G fill:#fecaca,stroke:#991b1b,color:#7f1d1d

The diagram makes the asymmetry visible. Every defender control protects a layer below LSASS. Mimikatz attacks LSASS directly. None of the per-binary controls is in the attack path because Mimikatz does not need to defeat them -- it runs as a process the per-binary controls approved.

5.2 The Mimikatz codebase as a single causal node

Every credential-replay class that defines the next decade of red-team tradecraft traces to one 2011 codebase. Pass-the-Hash, Pass-the-Ticket, Overpass-the-Hash, Golden Ticket -- all four landed in gentilkiwi/mimikatz. After the GitHub repository creation on April 6, 2014 [@mimikatz-github], the same codebase later grew the post-Part-3 modules (Skeleton Key and DCSync; see §11 FAQ) [@secureworks-skeleton-key; @metcalf-dcsync]. There is no comparable single codebase on the defender side. Microsoft's countermeasures landed across at least three product teams (Active Directory, Windows Defender, Hyper-V), and the architectural answer required a hypervisor.

Because you don't want to fix it, I'll show it to the world to make people aware of it. -- Benjamin Delpy [@greenberg-mimikatz-wired]

Delpy's framing converted a defender's blind spot into a public, weaponised primitive. Microsoft's initial dismissal of his private disclosure -- that the credential model was "by design" -- was true, in the most damaging possible sense. The model was by design. The single sign-on contract required it. Closing the gap required a different design.

5.3 The economic argument

The shift was economic as much as architectural. A reliable Windows zero-day exploit chain commanded a substantial unit price on the early-2010s grey market and burned on first use: once a sample was disclosed and patched, the exploit was worthless to a serious operator. A Mimikatz invocation, by contrast, is free, reusable indefinitely on any pre-Credential-Guard estate, leaves no on-disk footprint, and runs as the operator the attacker already compromised. The asymmetry is not subtle.

Property	Stuxnet (June 2010)	Mimikatz (May 2011 onward)
Attacker cost	Four Windows zero-days + two stolen Authenticode certificates + ICS payload [@symantec-stuxnet-dossier-v14]	Free open-source tool [@mimikatz-github]
Reusability	Single-use; zero-days patched within months [@ms-bulletin-ms10-046; @ms-bulletin-ms10-061; @ms-bulletin-ms10-073; @ms-bulletin-ms10-092]	Indefinite on any pre-Credential-Guard host
On-disk footprint	Multi-megabyte signed dropper + Step 7 / S7 payloads	Single executable; can run in memory
Detection footprint	Symantec / Kaspersky / ESET signatures within weeks of disclosure [@symantec-stuxnet-dossier-v14]	Initially evades signature-based AV; later detected via ProcessAccess masks on LSASS
Target population	Specific ICS estate (Natanz)	Every Windows AD estate
Threat-model implication	Nation-states will burn zero-days for kinetic effect	Anyone with admin can replay every cached credential

Key idea: Defensive success at one layer reliably produces attacker innovation at the next layer up. The 2009-2014 window proves it: Microsoft killed the rootkit, bootkit, and unsigned-bootloader classes; attackers responded by reading the credentials in LSASS memory that every hardened binary still had to trust. The mitigation surface and the attack surface were not at the same layer.

If the credential layer was structurally broken, why didn't Microsoft just fix it? They tried. The next section is the honest evaluation of Microsoft's counter-pivot through November 2014.

6. Microsoft's Counter-Pivot: 2013-2014

Microsoft was not asleep. By Windows 8.1 General Availability on October 17, 2013, three controls landed that were directly a response to Mimikatz. They were partial wins, all of them; the architectural acknowledgement that LSASS-in-VTL0 was unsalvageable would arrive only with Virtualisation-Based Security and Credential Guard in Windows 10 1507 [@ms-credential-guard], outside this article's window. This section is the honest evaluation of what shipped, what it accomplished, and why none of it was enough.

6.1 Restricted Admin RDP

Restricted Admin RDP changes the Remote Desktop Protocol so that the client never sends the user's plaintext password to the server's LSASS [@kb2871997]. Instead, the server issues a Network Level Authentication challenge that the client signs using its local NT hash; the user authenticates to the remote desktop session as a network logon rather than an interactive logon. Critical credential material is never present on the RDP server.

The bug Restricted Admin closes is the credential-disclosure failure mode: a foothold on the RDP server used to learn every administrator's plaintext password as they logged in. The bug it leaves open is replay. A Restricted Admin RDP session is a network logon, and an attacker holding the NT hash for an administrative account can invoke sekurlsa::pth /run:"mstsc /restrictedadmin" from a compromised host and authenticate to the target RDP server using only the hash. Restricted Admin reduced disclosure; it did not close replay.

sequenceDiagram participant C as RDP Client participant S as RDP Server (LSASS) Note over C,S: Classic RDP (credential delegation) C->>S: TLS handshake plus plaintext credentials S->>S: LSASS caches plaintext password for session Note over S: Foothold on server reveals every admin password Note over C,S: Restricted Admin RDP (post-KB2871997) C->>S: Network Level Authentication challenge request S->>C: server nonce C->>C: sign nonce with local NT hash C->>S: signed response S->>S: verify against domain controller Note over S: Server never sees plaintext Note over C: Attacker with NT hash can still run mstsc with restrictedadmin

Server-side Restricted Admin shipped at Windows 8.1 / Server 2012 R2 General Availability on October 17, 2013. The client-side back-port to Windows 7, Server 2008 R2, Windows 8, and Server 2012 followed via KB2871997 on May 13, 2014 [@kb2871997], which is also where the WDigest opt-out and TokenLeakDetectDelaySecs primitives shipped.

6.2 LSA Protected Process (RunAsPPL)

LSA Protected Process loads LSASS as a Protected Process Light with the signer level PsProtectedSignerLsa. Once Protected, the Windows kernel refuses any OpenProcess(PROCESS_VM_READ) call against LSASS from a process running at a lower signer level -- including a process running as NT AUTHORITY\SYSTEM with SeDebugPrivilege [@ms-lsa-protection]. The flag is enabled by setting HKLM\SYSTEM\CurrentControlSet\Control\Lsa\RunAsPPL to 1. RunAsPPL is the strongest credential-protection primitive Microsoft shipped inside Windows 8.1.

A kernel-enforced signer level that prevents OpenProcess(PROCESS_VM_READ) and CreateRemoteThread against the protected process from any process running at a lower signer level, regardless of token privileges or session [@itm4n-lsa-protection; @ms-lsa-protection]. The Lsa variant requires every LSA plug-in DLL (SSP, AP, custom credential providers) to itself be signed at a compatible signer level, which is why enabling RunAsPPL on real estates requires an LSA plug-in audit.

The bypass class is Bring Your Own Vulnerable Driver. A malicious kernel-mode driver, loaded through a vulnerable but Microsoft-signed third-party driver that the attacker has placed on disk, can clear the Protection byte in the kernel EPROCESS structure for LSASS, after which the OpenProcess(PROCESS_VM_READ) call succeeds. Mimikatz ships its own kernel driver, mimidrv.sys, that performs exactly this manipulation [@mimikatz-github]. The structural problem is that RunAsPPL is enforced by the same kernel an attacker is compromising to bypass it; the protection cannot be made strictly stronger inside the same privilege ring than the kernel that enforces it.

A common misreading is that PPL is a partial Credential Guard, or that Credential Guard replaces PPL. The most useful framing is itm4n's: *"I noticed that this protection tends to be confused with Credential Guard, which is completely different"* [@itm4n-lsa-protection]. PPL is a same-privilege gate inside VTL0 -- both LSASS and the attacker live in the same kernel address space, and the kernel decides whether to grant a process handle. Credential Guard is a cross-privilege isolation between VTL0 and VTL1 (the Virtual Trust Levels Hyper-V introduces in Windows 10 1507) [@ms-credential-guard]: the credential material lives in a Virtual Secure Mode trustlet (LSAISO) that the VTL0 kernel cannot read because the hypervisor's Second-Level Address Translation tables deny the mapping. The two controls are complementary -- PPL hardens LSASS against in-VTL0 attackers; Credential Guard moves the high-value secret out of VTL0 entirely. §8.3 develops the cross-privilege isolation argument formally.

6.3 The Mitigating Pass-the-Hash whitepaper series

Microsoft published the Mitigating Pass-the-Hash and Other Credential Theft whitepaper in two versions: v1 in December 2012 from the Trustworthy Computing group [@ms-pth-v1-landing] and v2 in July 2014 [@ms-pth-v2]. There is no v3. Post-2014 guidance migrated into the Securing Privileged Access online documentation rather than appearing as a numbered v3 PDF, and any "v3 2017" reference is incorrect.

The v1 paper introduced the tier 0 / tier 1 / tier 2 administrative-account model: separate the accounts that manage the forest (tier 0: domain controllers, AD), the accounts that manage server applications (tier 1: file servers, Exchange, SQL), and the accounts that manage end-user workstations (tier 2: helpdesk, desktop support). The rule is that a tier-N credential must never be exposed on a tier-(N+1) host. The model is sound. The problem is that v1 was recommendations-only with no enforcement primitive inside the operating system, and operators routinely violated tiering (the helpdesk technician fixing the CEO's laptop with a tier-2 credential and then RDPing to a tier-1 file server exposes the credential at the laptop's LSASS). The v2 paper integrated the technical D5 controls (RunAsPPL, Restricted Admin, KB2871997) precisely because v1 alone could not move the needle on real estates.

6.4 KB2871997 and the WDigest opt-out

The May 13, 2014 update KB2871997 is the single most operationally impactful credential-protection control of the entire window [@kb2871997]. It carried three deliverables. First, the Restricted Admin client back-port to Windows 7 / Server 2008 R2 / Windows 8 / Server 2012, which Section 6.1 covers. Second, the HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest\UseLogonCredential = 0 registry default that disabled WDigest plaintext credential storage in LSASS memory on a freshly patched system. Third, the HKLM\SYSTEM\CurrentControlSet\Control\Lsa\TokenLeakDetectDelaySecs (default 30 seconds) cleanup of leaked logon-session credentials.

Note: The WDigest opt-out (UseLogonCredential = 0) has zero operational downside on any post-2010 estate -- HTTP Digest authentication is essentially extinct in the enterprise -- and removes the most-cited credential-recovery primitive Mimikatz used through 2014 [@kb2871997]. It ships with the same back-port that brings Restricted Admin to down-level Windows. There is no defensible argument for not applying it on any supported Windows from 2014 onward.

The WDigest opt-out was buried in the KB2871997 bulletin because the headline framing was Restricted Admin RDP; many 2014-era administrators applied the patch for the RDP fix without realising the WDigest default had also changed [@kb2871997].

6.5 The seeds of Credential Guard

By late 2014 Microsoft was already prototyping the Hyper-V-as-security-boundary architecture that becomes Virtualisation-Based Security, Credential Guard, and Hypervisor-protected Code Integrity in Windows 10 1507 on July 29, 2015 [@ms-credential-guard]. For the Part 3 reader, the key observation is that Microsoft had already concluded by mid-2014 that no amount of in-VTL0 hardening could close the credential-replay gap structurally, and that the architectural answer required moving the credential cache to a different privilege domain than the kernel attackers compromise.

Key idea: Restricted Admin reduced disclosure but not replay. RunAsPPL stopped a Mimikatz invocation only until BYOVD. The Pass-the-Hash tiering model named the problem but had no enforcement primitive inside the operating system. Microsoft's counter-pivot in the Part 3 window was correct in direction and insufficient by construction -- because the architecture was the problem, not the engineering.

Microsoft shipped the right primitives. None of them was sufficient by construction, because the architecture was the problem. To see why, we have to look at the one structural thing the window left open: the SChannel attack surface, and the impossibility argument behind it.

7. The SChannel Coda: WinShock (MS14-066, November 11, 2014)

The window closes on November 11, 2014 with the last great pre-cloud TLS-stack remote code execution in Windows. WinShock is a counterpoint that reinforces the article's thesis rather than contradicting it: even with every credential-layer control of 2013-2014 deployed, an unrelated per-binary defect in the Schannel TLS stack could still hand an attacker remote code execution before any application code ran. The credential-layer hardening Microsoft spent the year shipping could not have prevented this bug, and the bug's existence is part of the evidence that hardening one layer leaves orthogonal layers exposed.

A note up front, because the popular framing got this wrong. The bulletin itself was not silent. MS14-066 was published on the November 11, 2014 Patch Tuesday with a Critical severity rating, an explicit CVE assignment (CVE-2014-6321), contemporary Brian Krebs coverage [@krebs-ms14-066], and public proof-of-concept walkthroughs within months [@nvd-cve-2014-6321]. The "silent" framing applies only to the additional Schannel hardening fixes Microsoft bundled into the same update without separate disclosures.

7.1 The mechanism

A crafted TLS handshake triggered a memory-corruption path inside schannel.dll, the Windows Secure Channel security package that implements TLS for every in-box TLS consumer [@ms-bulletin-ms14-066; @nvd-cve-2014-6321]. The bug allowed remote code execution before any application code ran -- the handshake itself was the attack. The NVD entry catalogues the affected platforms as Windows Server 2003 SP2, Windows Vista SP2, Windows Server 2008 SP2 and R2 SP1, Windows 7 SP1, Windows 8, Windows 8.1, Windows Server 2012 Gold and R2, and Windows RT Gold and 8.1 -- essentially every supported Windows of the era [@nvd-cve-2014-6321].

The attack surface was universal across the Windows enterprise estate of late 2014. Every IIS host terminating HTTPS, every SMB-over-HTTPS endpoint, every RDP-over-TLS listener, every Exchange ActiveSync endpoint, every Active Directory Federation Services endpoint terminating TLS in Schannel was exposed. A defensible writer-side abstraction (which this article takes) is that a crafted handshake triggered a memory-corruption path; the precise internal type and function family Microsoft fixed are not safely attributable without a primary-source walkthrough beyond the bulletin's published abstract.

7.2 The bundled extras

Microsoft bundled additional Schannel hardening into MS14-066 without separate bulletins. The article does not name specific CVE IDs for those bundled extras because prior pipeline runs found such attributions factually wrong (those CVE IDs belong to other bulletins or are REJECTED in NVD). The defensible framing is that Microsoft bundled additional Schannel hardening into the same update without separate bulletins, anchored to contemporary coverage of the patch cycle [@krebs-ms14-066]. The substantive point survives without speculative CVE attribution.

The "no public exploitation" framing of MS14-066 is wrong. BeyondTrust's "Triggering MS14-066" blog post and the SecuritySift "Exploiting MS14-066 (CVE-2014-6321) aka 'Winshock'" walkthrough are both referenced from the NVD entry as Exploit Third Party Advisory [@nvd-cve-2014-6321]. The CVE was patched, and the exploitation tradecraft was public; only the bundled hardening extras went unannotated.

7.3 Strategic significance

WinShock is the bookend on an era when the Windows Schannel stack was the front door of every enterprise. After 2014, TLS termination for major Windows estates increasingly happened at Azure Front Door, Akamai, Cloudflare, or AWS Application Load Balancer rather than at the Windows Schannel layer. Microsoft's own first-party services -- Exchange Online, SharePoint Online, the Office 365 ingress fleet -- terminated TLS at Azure-managed edge appliances, the topology documented in Microsoft's Microsoft 365 network connectivity principles as the recommended "connect locally to the Microsoft global network" architecture in which the customer's traffic enters Microsoft's network as close to the user as possible and TLS is terminated at the nearest edge node [@ms-365-network-principles]. The architectural lesson is not that Schannel was uniquely fragile; it is that monolithic TLS stacks across hundreds of in-box consumers were a brittle design that the industry stopped accepting as the default deployment topology for enterprise services.

WinShock closed the window with a per-binary patch. But the bigger story -- the credential layer Microsoft had spent the year trying to close -- was structurally broken in a way no patch could fix. To see why, we have to make the impossibility argument formally.

8. Theoretical Limits: Why No Per-Binary Hardening Could Fix the Credential Layer

A reframe. Every section so far has narrated evidence. This section turns that evidence into an argument from architecture -- a structural reason the per-binary playbook could not have fixed the credential layer, regardless of how good Microsoft's engineering was.

8.1 The trusted-computing-base argument

Every authenticated Windows process must, at some point, hold a verifiable secret. As §4.1 established, the single sign-on contract forces LSASS to hold a recoverable secret in memory [@ms-credentials-processes]. As long as that secret lives in a memory space the OS can read, an attacker who reaches that memory space can read it too.

AppLocker, ASLR, DEP, AppContainer, ELAM, and Secure Boot are all per-binary mitigations [@ms-applocker; @ms-elam; @ms-secure-boot]. They prevent the wrong code from running. They do not prevent the right code (an administrator-launched Mimikatz; a Microsoft-signed but vulnerable third-party kernel driver) from reading LSASS memory through documented Win32 APIs. The per-binary playbook is a code-execution control, not a memory-access control, and the credential-theft attack is not a code-execution attack.

8.2 The asymmetry

The defender must close 100% of the per-binary attack surface to prevent a single piece of attacker code from running. The attacker needs only one credential primitive to remain extractable to win. The two budgets are not comparable. The defender's job is exponentially harder by construction, and any single residual gap -- one unsigned plug-in, one cached WDigest plaintext, one stolen NT hash -- gives the attacker domain-wide replay. This is not a Microsoft engineering failure. It is an architectural inevitability of the in-VTL0 LSASS model.

8.3 The VTL0-symmetry argument

In any single-privilege-ring operating system, no protection mechanism implemented inside that ring can structurally defend a memory region against an attacker who reaches that ring. This is the formal statement of the limit Microsoft hit in 2014.

RunAsPPL is the strongest 2014-era expression of this bound. As §6.2 documented, a BYOVD-loaded kernel driver can clear the Protection byte on the LSASS EPROCESS and OpenProcess(PROCESS_VM_READ) succeeds [@itm4n-lsa-protection; @ms-lsa-protection]; the protection is enforced by the same kernel the attacker is compromising; the kernel cannot enforce a protection against itself.

The architectural way to state it: $\text{Protection}{\text{in-ring}}(M) \lt \text{Adversary}{\text{in-ring}}(M)$ for any memory region $M$ in the same privilege ring as the adversary. The protection function and the adversary function operate on the same domain, and the adversary always wins by construction. The algebraic notation is informal; the formal capture is the Bell-LaPadula / Lampson confinement bound, which states that in a single-privilege-ring system an adversary who reaches that ring can read any memory the kernel can map [@wikipedia-bell-lapadula]. Closing the gap requires moving $M$ to a privilege domain $\text{D}'$ such that the in-ring adversary cannot map $\text{D}'$ at all.

That is exactly what Virtualisation-Based Security does in Windows 10 1507 [@ms-credential-guard]. Hyper-V boots before the Windows kernel and creates two Virtual Trust Levels: VTL0 is the normal Windows kernel attackers compromise; VTL1 is Virtual Secure Mode, an isolated execution domain whose memory the VTL0 kernel cannot read because the hypervisor's Second-Level Address Translation tables deny the mapping. Credential Guard hosts an LSA Isolated trustlet (LSAISO) in VTL1 that holds the high-value credential material; the VTL0 LSASS process holds only obfuscated references that LSAISO can resolve. A Mimikatz invocation in VTL0 can still extract the references, but the references no longer dereference to a credential the VTL0 kernel can read.

As long as the kernel that protects LSASS executes in the same privilege ring as the kernel an attacker compromises, every protection inside that ring is bypassable. The credential cache must live in a different privilege domain than the kernel that the attacker can compromise.

8.4 The way out, foreshadowed

Hardware-rooted isolation of the credential cache is the only structural answer. Virtualisation-Based Security, Credential Guard, and the LSAISO trustlet in VTL1 -- the spine of Part 4 -- are the architectural answer to the architectural problem the Part 3 window proves cannot be closed inside VTL0 [@ms-credential-guard]. The article closes the Part 3 argument by naming the problem precisely so Part 4 can name the solution precisely.

Key idea: Hardware-rooted isolation of the credential cache -- the LSAISO trustlet in a VTL1 the VTL0 kernel cannot read -- is the only structural answer. Part 4 ships it. Part 3 names why it had to.

The architecture was the problem. What did practitioners do with this evidence at the end of 2014?

9. Open Problems at the End of 2014

Picture a Fortune-500 security operations centre on a Friday afternoon in early December 2014. The team has applied every Microsoft patch through MS14-066 [@ms-bulletin-ms14-066], deployed AppLocker on Enterprise SKUs [@ms-applocker], set RunAsPPL = 1 after a careful LSA plug-in audit [@ms-lsa-protection], applied KB2871997 to disable WDigest plaintext storage [@kb2871997], and read the Mitigating Pass-the-Hash v2 whitepaper cover to cover [@ms-pth-v2]. They run an internal red-team exercise the following Monday. Mimikatz still works. Why?

The credential layer is still essentially open. WDigest plaintext storage is now opt-out by default on freshly patched hosts, which closes the single most embarrassing primitive Delpy's 2011 demonstration exposed [@kb2871997]. But the cached NT hashes that NTLM authentication needs, the Kerberos Ticket-Granting Tickets the SSO contract holds in the LSA ticket cache, and the krbtgt master signing key on any domain controller whose LSASS the attacker can OpenProcess against all remain extractable [@mimikatz-github; @ms-credentials-processes]. RunAsPPL stops a Mimikatz invocation from user mode, but it does not stop Mimikatz from invoking its own mimidrv.sys driver (or any other vulnerable signed third-party driver) to clear the protection byte from kernel mode and proceed [@itm4n-lsa-protection; @mimikatz-github]. The same sekurlsa::logonpasswords that worked in May 2011 still works in December 2014 on every estate that has not stripped its third-party drivers down to a zero-BYOVD baseline -- which is no real estate at all.

One open problem the security community debated through 2014 deserves a sharper treatment because it surfaces the structural limit of any in-LSASS hardening strategy: why does Microsoft not simply relocate or obfuscate the LSA secret structures whose offsets Mimikatz hard-codes? The Mimikatz codebase carries an explicit, per-Windows-build signature table in mimikatz/modules/sekurlsa/kuhl_m_sekurlsa_utils.c that maps every supported Windows kernel / lsasrv.dll / livessp.dll / wdigest.dll build to the byte offsets and signature byte sequences Mimikatz scans for at run time [@mimikatz-sekurlsa-source]. The maintenance cost on the offensive side is one row per shipped Windows build per quarter. The proposed defensive response -- shuffle the struct layouts each cumulative update, randomise the symbol offsets, swap the byte signatures -- fails as a defence for three independent reasons. First, cost asymmetry. Microsoft would commit the test, validation, and Windows Hardware Quality Labs re-certification cost of every layout shuffle across every supported Windows SKU, language pack, and architecture every quarter; Mimikatz's maintainers would commit one pull request and one signature-table row per build. Second, defender-side fragility. The same LSASS structures the offsets index are consumed by Microsoft's own security tooling, by every third-party Endpoint Detection and Response agent, and by Windows Error Reporting; randomising the layout breaks the defender's own dependencies first and the attacker's last. Third, adversary-side robustness. Mimikatz already supports pattern-based signature scanning that finds the target structures even when their absolute offsets move; the offset hard-coding is a performance optimisation, not a requirement. The only structural defence is the one the engineering pipeline is already building: lift the credential cache out of the VTL0 user-mode process space entirely and into a Virtualisation-Based Security trustlet whose memory the VTL0 kernel cannot read. Alex Ionescu's Black Hat USA 2015 "Battle of SKM and IUM" talk lays out the VTL1 / IUM architecture in operator-facing detail and forward-references the Credential Guard design that ships in Windows 10 1507 [@ionescu-skm-ium-bhusa15]. The Part 3 community could see the answer; the architectural prerequisites simply had not yet shipped.

Microsoft is prototyping Virtualisation-Based Security and Credential Guard, but the architectural answer ships outside this article's window [@ms-credential-guard]. Even after it ships, Credential Guard requires Windows 10 Enterprise, UEFI 2.3.1, Secure Boot, a 64-bit CPU with virtualisation extensions, and -- on most estates -- a hardware refresh cycle that costs years and millions. The deployment surface that needs the protection most cannot adopt it until well into 2017.

AppLocker still carries its Windows 7 structural gaps in late 2014: the Application Identity service can be stopped by any process running as LocalSystem, after which enforcement degrades open until reboot, and the dual-DACL bypass class (rules that pass both Publisher and Path checks but reach a different binary at runtime) remains unaddressed [@ms-applocker; @ms-applocker-design]. Windows Defender Application Control -- the kernel-enforced policy successor that closes both gaps -- is still a Windows 10 enterprise feature in the Part 4 window. Secure Boot has its first dbx revocation politics in this window: Microsoft's revocation list has to retire compromised UEFI bootloaders without bricking dual-boot Linux installations on the millions of OEM machines that ship with Secure Boot enabled, and the cadence and scope of dbx updates becomes a recurring operational point of friction between Microsoft, OEMs, and the Linux distribution community [@ms-secure-boot; @mjg59-shim-signed]. The Pass-the-Hash v2 tiering recommendations are aspirational for the vast majority of 2014 deployments -- a complete tier 0 / tier 1 / tier 2 administrative-account programme is a multi-year project that requires Active Directory restructuring, change-management governance, and operator retraining at scale, and most estates that read the v2 paper applied KB2871997 and stopped there [@ms-pth-v2].

Mimikatz's post-Part-3 modules (Skeleton Key and DCSync; see §11 FAQ) sit in the same codebase, are anchor events in the Part 4 window, and define the credential-replay horizon the Part 3 reader is staring at [@secureworks-skeleton-key; @metcalf-dcsync].

The defining open question at the end of 2014 is how Microsoft isolates a long-lived user-mode process (LSASS) holding the most valuable secrets in the operating system from an administrator-privileged attacker on the same host, without breaking the hundreds of in-tree dependencies LSASS has accumulated since NT 3.1. The answer -- Virtualisation-Based Security plus the trustlet model -- is the spine of Part 4. It requires a hypervisor, a hardware-rooted boot chain, a re-architected LSA plug-in protocol that splits sensitive operations into LSAISO trustlet calls, and an operational deployment story that took Microsoft from late 2014 prototypes to general availability in 2015 and broad enterprise adoption only by 2018-2019.

Note: At the end of 2014, WDigest plaintext storage is closed by default. NT hashes, Kerberos TGTs, the krbtgt master key, and every other secret LSASS holds in recoverable form remain extractable by any administrator on the same host who can load a kernel driver. The architectural answer -- Credential Guard in Windows 10 1507 -- ships eight months later [@ms-credential-guard]. The Part 3 window proves the problem is real; Part 4 ships the answer.

Even at end-of-2014, with every Microsoft control available, the dominant Fortune-500 estate had applied the WDigest opt-out [@kb2871997] and almost nothing else. Tiering [@ms-pth-v2] is a multi-year programme. RunAsPPL [@ms-lsa-protection] requires an LSA plug-in audit that breaks any custom credential provider not yet re-signed at the PPL signer level. The architectural answer -- Credential Guard in 2015 [@ms-credential-guard] -- arrives to a deployment surface still struggling to deploy the 2013 controls. The gap between *the security primitive Microsoft shipped* and *the security primitive a Fortune-500 estate actually had running* was the largest it had ever been, and it grew through the Windows 10 1507 General Availability window.

Eight open problems. None of them admits a Part 3-era technical solution. So how does a practitioner read the 2009-2014 primitives against a 2026 Windows 11 baseline?

10. Practical Guide: Reading the 2009-2014 Primitives Against a 2026 Windows 11 Baseline

The previous nine sections built the structural argument. This section answers the operator's question: which of these 2009-2014 primitives are still load-bearing in 2026, and which were superseded?

10.1 Which Part 3 primitives are still load-bearing in 2026

Primitive (Part 3)	Still in use 2026?	Superseded by
AppLocker (Win 7+) [@ms-applocker]	Yes, on Windows 10/11 Enterprise estates	App Control for Business (WDAC) for new deployments
ELAM (Win 8+) [@ms-elam]	Yes, load-bearing for the boot chain on every supported Windows	Unchanged primitive; Defender's WdBoot.sys is the in-box ELAM driver
UEFI Secure Boot (Win 8+) [@ms-secure-boot]	Yes; mandatory for Windows 11 hardware certification	Strengthened with mandatory dbx revocation enforcement
AppContainer (Win 8+) [@windows-internals-6e-p1]	Yes; substrate for MSIX, Edge renderers, Win32 App Isolation, Recall trustlet	Generalised across all packaged Win32 apps via App Isolation
LSA Protected Process (Win 8.1+) [@ms-lsa-protection]	Yes; on by default on new installations of Windows 11 22H2 and later (upgraded systems retain default-off and require manual or GPO enablement)	Complemented by Credential Guard on enterprise hardware
Restricted Admin RDP (Win 8.1+) [@kb2871997]	Yes; still recommended	Remote Credential Guard (Win 10 1607+) for high-tier environments
WDigest plaintext disablement (KB2871997) [@kb2871997]	Default on every supported Windows since 2014	Unchanged primitive; WDigest itself is essentially deprecated
Mitigating Pass-the-Hash tiering model [@ms-pth-v2]	Yes; lives on as Privileged Access Workstations and Enterprise Access Model	Securing Privileged Access online documentation

Two surprises in the table. First, LSA Protected Process is on by default on new installations of Windows 11 22H2 and later -- which closes the gap for newly-shipped devices, though estates that upgraded from earlier Windows versions still require the manual or GPO enablement step that defined the 2014-2020 period. Second, AppLocker is still in production on enterprise estates ten-plus years after Windows 7 General Availability; the WDAC successor is the recommendation for new deployments, but the installed AppLocker base did not get replaced.

10.2 Mimikatz tradecraft as the floor of red-team capability

On any pre-Credential-Guard Windows estate -- and that is still a non-trivial fraction of the 2026 install base -- Mimikatz's 2011-2014 module set defines the floor of red-team capability. sekurlsa::logonpasswords reads every LSA-cached credential the operator's privileges allow [@mimikatz-github]. sekurlsa::tickets /export extracts every Kerberos ticket from the LSA cache. lsadump::secrets reads LSA private secrets. lsadump::sam reads local SAM hashes. kerberos::ptt re-imports tickets for replay. kerberos::golden forges Golden Tickets given a stolen krbtgt hash [@metcalf-golden-ticket]. The Part 3 window's primitives are the foundation any practitioner reasoning about lateral movement in a Windows-AD estate uses every day, and the conceptual model Sean Metcalf documented on ADSecurity.org remains the canonical operator-grade reference.

10.3 Detection

Where to look. Sysmon ProcessAccess events on LSASS (event ID 10) with Granted Access masks of 0x1010, 0x1410, or 0x143A correspond to the read-and-decrypt access pattern Mimikatz's sekurlsa::logonpasswords requires; the masks decompose into PROCESS_VM_READ + PROCESS_QUERY_LIMITED_INFORMATION (0x1010), plus PROCESS_VM_OPERATION (0x1410), plus PROCESS_VM_WRITE + PROCESS_CREATE_THREAD (0x143A), and are widely-attested operator-grade detection lore catalogued across EDR vendor blogs and MITRE ATT&CK T1003.001 (OS Credential Dumping: LSASS Memory) sub-techniques [@mitre-t1003-001]. Windows Security event 4673 (sensitive privilege use) on SeDebugPrivilege fires when a process adjusts its token to enable debug privileges -- the prerequisite for privilege::debug -- which is interesting in itself when the actor is not a known debugger. System Access Control Lists on the krbtgt account, paired with Domain Controller audit subcategories for Kerberos AS-REQ and TGS-REQ, surface the AS-REQ-without-corresponding-logon anomalies that Golden Ticket use produces [@metcalf-golden-ticket]. Microsoft Defender for Identity raises Suspected Golden Ticket and Suspected Skeleton Key alerts on its analysis of domain-controller telemetry (the Skeleton Key alert is a Part 4 forward reference).

{` // Conceptual classifier for Sysmon event ID 10 (ProcessAccess) targeting LSASS. // The canonical "read-and-decrypt" mask pattern Mimikatz needs to call // OpenProcess + ReadProcessMemory + BCryptDecrypt against LSASS. function isMimikatzLikely(event) { if (event.id !== 10) return false; if (!/lsass.exe$/i.test(event.targetImage)) return false; const interesting = new Set(['0x1010', '0x1410', '0x143A']); return interesting.has(event.grantedAccess.toLowerCase().toUpperCase()); }

const sample = { id: 10, targetImage: 'C:\\Windows\\System32\\lsass.exe', grantedAccess: '0x1410', sourceImage: 'C:\\tools\\mimikatz.exe' };

console.log('Alert?', isMimikatzLikely(sample)); console.log('SOCs combine this with allow-listed debugger paths and PPL state.'); `}

Note: The same Restricted Admin flag that closes the disclosure-at-server gap [@kb2871997] also enables a Pass-the-Hash operator to invoke sekurlsa::pth /run:"mstsc /restrictedadmin" from a compromised host and authenticate to the target RDP server using only the stolen NT hash [@mimikatz-github]. Restricted Admin is a disclosure mitigation, not a replay mitigation. Combine it with Remote Credential Guard (Windows 10 1607+) on tier 0 administrative paths.

1. Apply KB2871997 with `UseLogonCredential = 0` on every supported Windows. Zero downside. 2. Enable `RunAsPPL = 1` after a one-cycle LSA plug-in audit. Plan a rollback for any custom credential provider not yet re-signed at the PPL signer level [@ms-lsa-protection]. 3. Adopt the Pass-the-Hash v2 tiering model as planning vocabulary, then operationalise it as Microsoft's *Securing Privileged Access* / Enterprise Access Model documentation. Multi-year programme; treat as a roadmap [@ms-pth-v2]. 4. Use Restricted Admin for administrative RDP; promote to Remote Credential Guard on tier 0 paths. 5. Run AppLocker on every Enterprise SKU you have not yet migrated to WDAC [@ms-applocker]. Lock down `AppIDSvc` start-type to disabled-but-set-by-policy. 6. Enable Secure Boot, Measured Boot, and BitLocker (TPM + PIN) on every laptop [@ms-secure-boot]. Microsoft's default platform validation profile on native UEFI + Secure Boot systems is PCR 7 (Secure Boot State) and PCR 11 (BitLocker access control), which is the *correct* profile to use when Secure Boot is on and the platform's option ROMs are trusted [@ms-bitlocker-configure]. For hardened estates that want to detect tampering with the UEFI firmware itself, the option-ROM configuration, or the boot-manager binary independent of Secure Boot's signature check, expand the profile to PCRs 0, 2, 4, 7, 11 -- adding PCR 0 (UEFI firmware code), PCR 2 (option-ROM code), and PCR 4 (boot-manager binary measurements) on top of the default [@ms-bitlocker-countermeasures]. The hardened profile generates more BitLocker recovery-key prompts after legitimate firmware updates, so the operational cost is real and the choice between the two profiles is the standard balance between detection coverage and help-desk load. 7. Enable Credential Guard (Windows 10 1607+) on every estate whose hardware supports it [@ms-credential-guard]. This is the architectural answer; everything above is harm reduction.

The 2009-2014 primitives are still here. So is Mimikatz. Part 4 explains why, and what Microsoft did about it.

11. Frequently asked questions

No. The four zero-days -- MS10-046 (LNK shortcut RCE), MS10-061 (Print Spooler RCE), MS10-073 (win32k.sys keyboard-layout LPE), and MS10-092 (Task Scheduler LPE) -- were used across the worm's propagation and escalation surfaces, *not* chained in a single sequential exploit [@symantec-stuxnet-dossier-v14; @ms-bulletin-ms10-046; @ms-bulletin-ms10-061; @ms-bulletin-ms10-073; @ms-bulletin-ms10-092]. Different hosts encountered different combinations depending on patch level, USB usage, network shape, and whether the local user already had administrative privileges. Only with two qualifiers -- multi-zero-day and kinetic-physical effect. Operation Aurora (January 12, 2010) used a single Internet Explorer 0-day (CVE-2010-0249) against Google and at least twenty other named victims including Adobe, Juniper, Yahoo, Symantec, Northrop Grumman, Dow Chemical, and Morgan Stanley (full sourcing and the verbatim Google wording in §3.6) [@google-aurora-wayback; @nvd-cve-2010-0249]; Stuxnet (June 17, 2010) used four zero-days for kinetic effect [@symantec-stuxnet-dossier-v14]. Drop either qualifier and Aurora falsifies the framing. No. The Pass-the-Hash concept dates to Paul Ashton's 1997 NTBugtraq post [@wikipedia-pth] and was operationalised by Hernan Ochoa's 2008 Pass-the-Hash Toolkit (`iam.exe` / `whosthere.exe`) at Core Security Corelabs [@core-ptht-2008]. What Mimikatz did was make the primitive operational on a default-configured modern Windows host without requiring custom NTLM client code [@greenberg-mimikatz-wired; @mimikatz-github]. It turned a known protocol weakness into a one-line operator tool that ran against any LSASS the operator could `OpenProcess` against, and it added the Kerberos primitives (Pass-the-Ticket, Overpass-the-Hash, Golden Ticket) that previous Pass-the-Hash toolchains had not addressed. Skip Duckwall and Chris Campbell's *Pass-the-Hash 2: The Admin's Revenge* at Black Hat USA 2013 formalised the graph-walking discipline that ties Mimikatz primitives together into the lateral-movement operating model the rest of the decade inherits [@duckwall-campbell-bh2013]. Partially. The headline CVE (CVE-2014-6321) was patched on a published Patch Tuesday bulletin on November 11, 2014 [@ms-bulletin-ms14-066; @nvd-cve-2014-6321] with contemporary KrebsOnSecurity coverage [@krebs-ms14-066] and public proof-of-concept walkthroughs within months. The "silent" framing applies only to the additional Schannel hardening fixes Microsoft bundled into the same bulletin without separate disclosures. This article deliberately does not name specific CVE IDs for those bundled extras, because prior pipeline runs found such attributions factually wrong. It wasn't, because Microsoft published v1 in December 2012 [@ms-pth-v1-landing] and v2 in July 2014 [@ms-pth-v2] and then migrated subsequent guidance into the post-2014 *Securing Privileged Access* online documentation rather than producing a numbered v3 PDF. Any "v3 2017" reference in secondary sources is incorrect; the canonical documentation chain after v2 is the *Securing Privileged Access* and *Enterprise Access Model* pages on Microsoft Learn. No. The Symantec dossier was authored by Nicolas Falliere, Liam O Murchu, and Eric Chien of Symantec Security Response, v1.4, February 2011 [@symantec-stuxnet-dossier-v14]. Bruce Dang was at Microsoft's Security Response Center and co-presented "Adventures in Analyzing Stuxnet" with Peter Ferrie at the 27th Chaos Communication Congress (27C3) in Berlin on December 27, 2010 [@dang-ferrie-27c3], which is a separate primary covering the win32k.sys CVE-2010-2743 kernel exploit walkthrough (the 27C3-not-29C3 venue correction is documented in the §3.1 sidenote). Dang's affiliation is Microsoft MSRC, not Symantec. No. Mimikatz's first public release was May 2011 (closed source) [@greenberg-mimikatz-wired; @wikipedia-mimikatz]. The GitHub repository `gentilkiwi/mimikatz` was created on April 6, 2014 at 18:30:02 UTC -- a timestamp anyone can verify via the GitHub API [@mimikatz-github]. Any "2007" date refers to Delpy's pre-release private experimentation, not a public release. No. Both anchor events post-date the Part 3 window. Dell SecureWorks Counter Threat Unit disclosed the Skeleton Key malware family on January 12, 2015 [@secureworks-skeleton-key], and Delpy added the corresponding `misc::skeleton` module to Mimikatz on January 17, 2015. Skeleton Key, DCSync, and the Credential Guard architectural pivot are the spine of Part 4 [@metcalf-dcsync; @ms-credential-guard].

Skeleton Key. Virtualisation-Based Security. Credential Guard. Part 4 opens on January 17, 2015, with the same Mimikatz codebase and a new technique.

BitUnlocker: When Microsoft's Recovery Environment Becomes the Master Key

noreply@paragmali.com (Parag Mali) — Sun, 24 May 2026 00:00:00 GMT

**In July 2025, Microsoft's own internal red team disclosed a four-CVE chain called BitUnlocker that bypasses TPM-only BitLocker in under five minutes from a USB stick, regardless of whether the device uses a discrete TPM, fTPM, or Pluton.** The attack works because the Windows Recovery Environment is given the BitLocker auto-unlock state legitimately during repair operations, and STORM found four parsers inside that trust boundary whose flaws let an attacker *be* the recovery environment. Patches shipped in KB5062553, but until the Secure Boot revocation infrastructure removes the pre-patch boot manager from the trust set, the chain remains exploitable on most fielded Windows 11 devices. The only mitigation that changes the threat model independently of patch state is the same recommendation Microsoft has been making since Vista: enable a pre-boot PIN.

1. Hold Shift, click Restart, lose your disk

Hold Shift. Click Restart. Plug in a USB stick carrying a pre-patch boot manager [@ms-winre-ref] [@garatc-poc]. Under five minutes later, on any device whose Secure Boot trust set still includes the 2011 root, the encrypted drive that protected your laptop is mounted in plaintext. No PIN ever entered. The TPM none the wiser. The researchers who showed how to do this work at Microsoft.

This is not a hypothetical. The proof of concept is on GitHub [@garatc-poc]. The end-to-end attack takes less than five minutes against a fully patched Windows 11 device that has not yet deployed the Secure Boot revocation infrastructure -- which is to say, most of them.

The attack is called BitUnlocker. It is a four-CVE chain disclosed and patched by Microsoft on July 8, 2025 in cumulative update KB5062553 [@kb5062553], then presented to the public a month later at Black Hat USA 2025 and DEF CON 33 with a Microsoft Security Blog write-up published August 13 to 14, 2025 [@ms-bitunlocker]. The four vulnerabilities are CVE-2025-48804 (System Deployment Image parsing) [@nvd-cve-2025-48804], CVE-2025-48800 (tttracer.exe offline scanning) [@nvd-cve-2025-48800], CVE-2025-48003 (SetupPlatform.exe and a Shift+F10 hotkey) [@nvd-cve-2025-48003], and CVE-2025-48818 (Boot Configuration Data target-OS impersonation) [@nvd-cve-2025-48818].

The researchers are Netanel Ben Simon and Alon Leviev of STORM, Microsoft's internal red team [@itnews-bitunlocker]. Leviev is the same researcher who disclosed Windows Downdate at Black Hat USA 2024 [@safebreach-downdate], so the line of work has provenance: a Microsoft engineer who understands the Windows update pipeline well enough to undo it, now turned on the recovery pipeline that runs when the update pipeline fails.

A five-minute physical bypass against BitLocker is not a research curiosity in 2026. ShrinkLocker, the BitLocker-as-ransomware-payload family disclosed by Kaspersky in May 2024, was used to extort organisations in Mexico, Indonesia, and Jordan [@kaspersky-shrinklocker]. APT41 paired ProxyLogon access with BitLocker as the workstation-encryption layer of a 2021 ransomware operation [@cymulate-apt41]. Romania's national water authority lost about 1,000 systems to a BitLocker-based ransomware incident over a December 2025 weekend [@therecord-romania-water]. BitLocker's installed base is where the defensive stakes live. BitUnlocker is what the offensive stakes look like.

STORM stands for Security Testing and Offensive Research at Microsoft [@itnews-bitunlocker]. It is the internal red team that publishes coordinated disclosures against Microsoft's own products.

The default BitLocker configuration on Windows 11 consumer and most enterprise installs. The Trusted Platform Module releases the Volume Master Key automatically at boot when the Platform Configuration Registers match an expected profile, with no human interaction. There is no pre-boot PIN, no startup key, no challenge -- the only authentication is the boot chain's measurement.

The pre-boot PIN configuration -- TPM+PIN, in Microsoft's terminology -- defeats every attack in this article, including BitUnlocker. Microsoft has been recommending TPM+PIN in some form since BitLocker shipped with Windows Vista on its January 30, 2007 consumer general-availability date [@ms-bitlocker-countermeasures] [@ms-vista-launch]. Eighteen years later, that recommendation has not changed.

What has changed is the consequence of ignoring it.

Key idea: TPM-only BitLocker assumes the boot chain is trustworthy. The boot chain has been the dominant BitLocker attack surface for three years and counting. The Windows Recovery Environment is part of the boot chain.

Note: The July 8, 2025 patches close the four code paths inside WinRE. They do not, by themselves, revoke the pre-patch boot manager that BitUnlocker downgrades to. Until the Secure Boot revocation under KB5025885 (the "REVISE" rollout) is deployed on a device, the BitUnlocker entry vector remains usable [@neodyme-bitpixie-no-fix] [@kb5025885].

To understand why a four-CVE chain inside the recovery environment is enough to mount the entire encrypted volume in plaintext, we have to go back to a design decision Microsoft made in 2006. That decision is still shipping in every copy of Windows.

2. Why the recovery environment has the keys

BitLocker shipped with Windows Vista on its consumer general-availability date, January 30, 2007 [@ms-bitlocker-countermeasures] [@ms-vista-launch]. Niels Ferguson's August 2006 cipher specification described the cryptographic core -- AES in CBC mode plus a custom diffuser called Elephant, designed to resist exactly the kind of disk-sector chosen-plaintext games that an attacker with full-disk read/write access could otherwise play [@ms-ferguson-cipher] [@archive-ferguson]. Four protector modes shipped with Vista: TPM-only, TPM+PIN, TPM plus a USB startup key, and TPM plus startup key plus PIN [@ms-bitlocker-countermeasures]. Each successive mode added a pre-boot human-presence check that the TPM-only default deliberately omitted.

The cipher specification is the public part of the design. The part that mattered for the rest of the story is the part that is barely documented at all: how recovery works.

The key-encrypting key that wraps the Full Volume Encryption Key. When a user changes their password or recovery configuration, only the VMK wrapping changes -- the entire volume does not need re-encryption. The TPM seals the VMK to a profile of boot-time measurements. The symmetric key that encrypts each sector of the BitLocker-protected volume. The FVEK is never directly handled by the user; it sits behind the VMK and is rewrapped only during operations like algorithm change or full re-encryption. A small bootable image, based on Windows PE, that the boot manager hands off to when normal Windows fails. WinRE provides Push Button Reset, Startup Repair, System Image Recovery, Reset This PC, and the offline scanning tools that the rest of this article will treat as a trust boundary [@ms-winre-ref].

The recovery problem Microsoft was solving in 2006 was unromantic but unavoidable. If full-disk encryption is to be default-on for an operating system that ships on a billion devices, the recovery environment has to read the OS volume during a repair pass without re-prompting the user for a recovery key every time a Windows update hiccups. The 24x7 help desk for a Fortune 500 cannot dispatch a forty-eight-character recovery key to every user whose system needs Startup Repair. So the Windows boot manager passes the unlock state along to WinRE, which inherits the ability to mount the encrypted volume during legitimate recovery operations [@ms-winre-ref].

The behavior is documented in every WinRE technical reference Microsoft has shipped since Vista. The rationale -- the original engineering memo about why auto-unlock is the right answer, given the help-desk requirement -- is not public. That gap matters because the rationale is the load-bearing wall of the threat model. The choice is consistent with every Microsoft document about WinRE; the engineering decision itself is folk knowledge.

The trade-off that runs through this entire article is simple to state. If the recovery environment can mount the volume without user input, the recovery environment is part of the encryption's trust boundary. If the recovery environment requires user authentication on every entry, you have effectively re-implemented the pre-boot PIN -- you have just moved its name. Microsoft picked the first option in 2006 because the second option breaks help-desk recoverability. Eighteen years later, that is still the choice. BitUnlocker is what the bill looks like.

Windows 8 removed the Elephant diffuser but kept AES-CBC alone. XTS-AES did not become BitLocker's default for new fixed drives until Windows 10 v1511 in November 2015 [@ms-bitlocker-configure]. The two-key VMK/FVEK hierarchy survived every cipher transition. So did WinRE's auto-unlock behavior.

Twenty months after Vista shipped, a Princeton research group would discover that "powered off" did not actually mean "key gone." The published attack literature against BitLocker was about to begin.

3. Eighteen years, six generations, one recommendation

The first attack specifically demonstrated against BitLocker as the named target appeared in 2008, the year after Vista's general availability -- though earlier generic memory primitives like FireWire DMA (Ruxcon 2006) became applicable to BitLocker as soon as Vista shipped. The most recent pre-2022 BitLocker bypass appeared in February 2024, when a four-dollar microcontroller pulled the keys off a Lenovo ThinkPad in 43 seconds [@hackaday-pico]. Between those two endpoints sit six attack generations. Each one moved one layer up the trust stack. Each one was answered by Microsoft with the same operational recommendation.

gantt title BitLocker bypass generations, 2006-2025 dateFormat YYYY-MM axisFormat %Y

section Hardware-adjacent
Cold boot (Halderman et al)        :2008-07, 60d
FireWire/PCI DMA (Boileau, Inception) :2006-10, 1825d
TPM bus sniff (marcan, Andzakovic)   :2019-01, 365d
Pi Pico TPM sniff (StackSmashing)    :2024-02, 30d
TPM+PIN bus bypass (SCRT, Compass)   :2024-02, 270d

section Software boot chain
Stoned, Vbootkit 2                   :2009-07, 90d
Self-Encrypting Deception (Meijer)   :2018-11, 180d
Bitpixie discovery (Rairii)          :2022-08, 30d
Bitpixie disclosure (CVE-2023-21563) :2023-02, 30d
BlackLotus (CVE-2022-21894)          :2023-03, 90d
BitUnlocker (KB5062553)              :2025-07, 60d

section Paradigms
Evil Maid framing (Rutkowska)        :2009-10, 30d

The structural reading of that timeline matters more than any individual entry, so here is the layer-by-layer walk:

Generation 1 -- Cold boot (2008). J. Alex Halderman and collaborators at Princeton and the EFF showed that DRAM retains its contents for seconds to minutes after power loss, longer if chilled with canned air. The AES key schedule has enough redundancy to be reconstructed from a partial dump, which means a powered-off BitLocker laptop with a still-warm DIMM is not actually at rest [@halderman-coldboot] [@halderman-coldboot-pdf]. Microsoft's structural answer was the Memory Overwrite Request (MOR) bit [@ms-bitlocker-countermeasures] and the eventual move to DDR generations that lose state faster. The user-facing answer was a pre-boot PIN [@ms-bitlocker-countermeasures].

Generation 2 -- FireWire and PCI DMA (2006 onward). Adam Boileau demonstrated at Ruxcon 2006 -- in a talk titled Hit By A Bus: Physical Access Attacks With Firewire -- that any host with an active FireWire port would let an unauthenticated peripheral read or write physical memory without involving the CPU [@boileau-ruxcon-2006]. Carsten Maartmann-Moe productionised the primitive as Inception, extending it to Thunderbolt, ExpressCard, and any other PCI-bus port that did not gate DMA behind the IOMMU [@inception-readme]. Microsoft's structural answer accumulated in stages: DMA-related Group Policy controls during the Windows 8.1 era, then a named Kernel DMA Protection feature shipped with Windows 10 1803 -- with the explicit exclusion that 1394 FireWire is not covered by KDP, so the legacy bus has to be disabled in firmware [@ms-kdp]. The user-facing answer was a pre-boot PIN.

Generation 3 -- Classical bootkits (2009). Peter Kleissner's Stoned and the Kumar brothers' Vbootkit 2, both presented at Black Hat USA 2009, showed that a Master Boot Record bootkit could load above the BitLocker pre-boot environment, hook the key-release path, and never trip the TPM's Platform Configuration Registers because nothing had measured the MBR yet [@wack0-taxonomy]. Microsoft's structural answer was UEFI Secure Boot plus Measured Boot's PCR 7, which moved the trust anchor from the MBR into the firmware. The user-facing answer was a pre-boot PIN.

Threat-model rename -- Evil Maid (2009). Joanna Rutkowska and Alex Tereshkin published a one-minute USB-stick infector against TrueCrypt that established a threat-model name rather than a primitive [@rutkowska-evilmaid]. Rutkowska's earlier January 2009 post had already named BitLocker as the disk encryption she missed after moving to macOS [@rutkowska-miss-bitlocker]; her October 2009 follow-up named the category of attacks that everybody now calls Evil Maid. The Microsoft Countermeasures page now uses the same threat-model tier she articulated.

Generation 4 -- Self-Encrypting Deception (2018-2019). Carlo Meijer and Bernard van Gastel showed at IEEE S&P 2019 that BitLocker had been silently delegating cryptography to the SSD firmware on self-encrypting drives -- and that the firmware was broken across several major vendor families, with Samsung 840/850 EVO and Samsung T3/T5 among the affected lines [@meijer-sed] [@researchr-meijer]. Microsoft's structural answer (KB4516071) was to stop delegating. This is the rare frontier Microsoft closed rather than mitigated incrementally: software encryption became the default again, and the "trust the drive" path was retired.

Generation 5 -- TPM bus sniffing (2019-2024). On a discrete TPM, the LPC or SPI bus between the CPU and the TPM chip carries the unsealed VMK in cleartext for a few microseconds. Hector Martin (marcan) first demonstrated extraction in January 2019 [@syss-tpm-sniffer]; Denis Andzakovic published the first written technical account later in 2019 [@andzakovic-tpmsniff] [@zdnet-bitlocker-attack] [@wack0-taxonomy]. StackSmashing's February 2024 Raspberry Pi Pico kit reproduced the same primitive against a Lenovo ThinkPad X1 Carbon for under ten dollars of hardware in 43 seconds of wall clock [@hackaday-pico] [@stacksmashing-pico]. Microsoft's structural answer was firmware TPM (AMD fTPM, Intel PTT) on modern CPUs and Pluton on Pluton-equipped chipsets [@ms-pluton]. The user-facing answer was a pre-boot PIN.

The Pi Pico reproduction reduced the hardware cost by an order of magnitude from Andzakovic's 2019 FPGA setup [@andzakovic-tpmsniff] [@hackaday-pico]. Same primitive; different price point.

Generation 5.5 -- TPM+PIN hardware bypass (2024). SCRT in Switzerland and Compass Security independently published that even with TPM+PIN configured, the Intermediate Key released after PIN validation still traverses the bus in clear on discrete-TPM hardware [@scrt-tpm-pin] [@compass-2024]. The structural defeat is Pluton, where the bus does not exist on-die [@ms-pluton]. The user-facing answer for everyone else stayed: a pre-boot PIN, plus discrete-TPM replacement or BIOS-level TPM bus protection.

By default, Microsoft BitLocker protected OS drives can be accessed by sniffing the LPC bus, retrieving the volume master key when it's returned by the TPM, and using the retrieved VMK to decrypt the protected drive. -- Denis Andzakovic, Pulse Security, 2019 [@andzakovic-tpmsniff]

Six generations. One recommendation. Pre-boot PIN. Microsoft has shipped real structural mitigations -- MOR, IOMMU, Secure Boot, Measured Boot, fTPM, Pluton, dbx revocation -- but the user-facing recommendation has not changed for eighteen years.

All six generations attack the layer below the boot manager. The boot manager itself, signed by Microsoft, has been treated as the trust anchor. In 2022, the first attack to make the boot manager itself the surface arrived. Its name was Bitpixie, and it is BitUnlocker's immediate ancestor.

4. The boot manager itself becomes the surface (2022-2025)

In August 2022, an independent researcher posting under the handle Rairii discovered that the Microsoft-signed Windows boot manager itself had a logic flaw: under a specific PXE soft-reboot sequence, the BitLocker Volume Master Key remained in physical memory and was never zeroed when control transferred [@rairii-mastodon] [@martanne-bitpixie]. The bug was assigned CVE-2023-21563. The patch shipped in the January 10, 2023 Patch Tuesday cumulative [@nvd-cve-2023-21563] [@msrc-cve-2023-21563]; Rairii made the discovery public on Mastodon the following month [@rairii-mastodon]. The old signed binary remained chain-loadable. It still is.

Thomas Lambertz of Neodyme published the canonical technical write-up of "Bitpixie" in late 2024, then presented the work at 38C3 in December 2024 [@neodyme-bitpixie] [@38c3-bitpixie]. His follow-up post asked an uncomfortable question -- why no fix? -- and answered it: the patch closed the code path, but the pre-patch boot manager was signed under Microsoft's Windows Production CA 2011, and that certificate was still in the Secure Boot allow-list (db) on most fielded Windows devices [@neodyme-bitpixie-no-fix]. A physically present attacker could supply an old, signed, vulnerable copy of bootmgfw.efi and the firmware would still load it.

This article uses "REVISE" as a convenience handle for Microsoft's verbosely-named "Windows Boot Manager revocations for Secure Boot changes associated with CVE-2023-24932" rollout. Microsoft does not market the work under the REVISE name -- the technical content here is what matters. The UEFI `db` is the allow-list of trusted signing certificates and signed binary hashes; the `dbx` is the corresponding deny-list. KB5025885's current (April 2024+) approach is certificate-based: it adds the Windows Production PCA 2011 signing certificate to `dbx`, which untrusts every boot manager signed by it, and ships a new UEFI CA 2023 certificate to replace the 2011 root. (The original May 2023 mitigations used a hash-by-hash strategy against specific boot manager binaries that was superseded for being too narrow.) The rollout is opt-in across multiple phases (currently five) because pushing a `dbx` change at scale can brick devices [@kb5025885]. Microsoft Windows Production CA 2011. The intermediate certificate that signs the Windows boot manager and every other Microsoft-trusted EFI binary loaded under Secure Boot. The 2011 root is set to expire in waves starting June 2026, which is the structural reason REVISE / UEFI CA 2023 must complete before then [@kb5062553].

The REVISE rollout under KB5025885 ships across opt-in phases (currently five: Initial Deployment, Second Deployment, Evaluation, Deployment, Enforcement), each gated by a registry-bitmask AvailableUpdates opt-in.Within the currently-active Evaluation and Deployment phases, the mitigations roll out in three actions: (1) install the new UEFI CA 2023 cert into db and trust-roll to the 2023-signed boot manager; (2) push the Windows Production PCA 2011 signing certificate into dbx -- the moment that "patched" becomes "revoked" on that device; (3) write a Secure Version Number into the firmware so the boot manager can self-revoke older copies of itself [@kb5025885]. The named Phase 1 (Initial Deployment, May 9, 2023) used a now-superseded hash-by-hash revocation approach against specific boot manager binaries. Each phase is an irreversible state change once Secure Boot stays on, which is why Microsoft has gated the schedule on operator readiness rather than calendar pressure.

Compass Security's May 2025 follow-up reproduced the Bitpixie exploit in a WinPE-based variant signed entirely by Microsoft components -- replacing the third-party Linux shim that secured-core PCs disable by default -- end-to-end in roughly five minutes via PXE [@compass-bitpixie-winpe]. Five minutes is a useful benchmark because BitUnlocker's USB-deliverable PoC clocks at the same number against the same chain-load downgrade primitive, with a different post-exploitation strategy and a different delivery vector.

Two other 2022-2024 bootkits frame the era. ESET disclosed BlackLotus in March 2023, the first in-the-wild UEFI bootkit observed bypassing Secure Boot on a fully patched Windows 11 by abusing CVE-2022-21894 "Baton Drop" [@eset-blacklotus] [@msrc-cve-2022-21894]. ESET's November 2024 Bootkitty disclosure brought the first publicly analysed UEFI bootkit aimed at Linux, although ESET's follow-up note clarified the artefact was a Korean Best of Best student project rather than in-the-wild malware [@eset-bootkitty]. Both used the same observation that underwrites Bitpixie and BitUnlocker: a Microsoft-signed binary with a logic flaw stays trusted until Microsoft adds it to dbx, which is a multi-year programme.

flowchart TD A["Microsoft-signed binary
with a logic flaw"] --> B["Stays trusted
until dbx revokes its cert
or its hash"] B --> C1["Bitpixie (CVE-2023-21563)
PXE soft-reboot leaks VMK
from physical memory"] B --> C2["BlackLotus (CVE-2022-21894)
Baton Drop drops a
UEFI bootkit"] B --> C3["BitUnlocker (4 CVEs)
Downgrade boot manager,
be the recovery environment"] C1 --> D["Patched is not revoked"] C2 --> D C3 --> D D --> E["REVISE / UEFI CA 2023
is the structural fix"]

Note: Each of Bitpixie, BlackLotus, and BitUnlocker depends on the same lemma. Microsoft can ship a patch that fixes a Microsoft-signed binary. Until that binary's signing certificate lands in dbx, the old signed copy keeps working on every Windows device whose Secure Boot policy still trusts PCA 2011 -- which, in mid-2026, is most of them. The dbx update is a separate, opt-in, multi-phase operation that has to complete before June 2026 because that is when PCA 2011 starts to expire on its own terms.

Same researcher, two pipelines: Leviev disclosed Windows Downdate at Black Hat USA 2024 and co-disclosed BitUnlocker at Black Hat USA 2025 [@safebreach-downdate]. Update pipeline one year, recovery pipeline the next.

Bitpixie scavenges the VMK from RAM after a buggy soft reboot. BlackLotus drops a UEFI bootkit. Both depend on the same observation: a Microsoft-signed binary with a logic flaw stays trusted until Microsoft revokes it. In July 2025, four Microsoft engineers asked a sharper question. What if you do not have to find a logic flaw at all? What if the recovery environment is given the keys legitimately, and all you have to do is be the recovery environment?

5. Four parsers, one trust boundary

WinRE already has the keys. That is the design.

STORM's insight was not to attack the seal. It was to observe that every parser inside WinRE sits inside the BitLocker auto-unlock trust boundary, and to ask which of those parsers is buggy. Once you reframe the problem from "find a way to make the TPM release the key" to "the recovery environment is given the key by design, so make me the recovery environment," the question stops being cryptographic and becomes a code-audit question. STORM found four answers. There are almost certainly more.

The four CVEs map to four parsers. The first is the entry vector; the next two are escalations inside the boundary; the fourth is the unconditional decryption finisher that turns the chain from a privileged shell into a permanently disabled BitLocker volume. Each subsection below follows the same template: what gets parsed, where the integrity check goes wrong, what falls out of the parser, why that primitive ends the chain.

sequenceDiagram participant U as Attacker (USB) participant FW as UEFI firmware participant BM as Pre-patch bootmgfw.efi (PCA 2011) participant SDI as Boot.sdi parser participant WRE as Malicious WinRE participant V as BitLocker volume U->>FW: Boot USB stick FW->>BM: Loads Microsoft-signed boot manager (downgraded) BM->>SDI: Hash-and-execute SDI image SDI-->>SDI: Hash covers original bytes SDI-->>SDI: Execution targets appended WIM SDI->>WRE: Hands control to malicious WinRE WRE->>V: Inherits auto-unlock from boot context WRE->>U: Shell on the cleartext volume

5.1 CVE-2025-48804 -- SDI parsing as the entry vector

WinRE boots from a System Deployment Image (Boot.sdi) bundled with a Windows Imaging file (.wim). The boot manager hashes the SDI for integrity before transferring control. STORM noticed that the integrity check covered the on-disk original bytes of the SDI, but the runtime that consumed the image followed an internal offset pointer that the attacker could shift to point at appended bytes after the hashed region [@nvd-cve-2025-48804] [@itnews-bitunlocker]. Append a malicious WIM at the tail of a legitimate SDI, manipulate the offset, and the hash still passes -- but execution targets your bytes.

The garatc proof of concept assembles this into a USB-bootable payload that downgrades to a pre-patch bootmgfw.efi signed under PCA 2011 (still trusted on most fielded devices), then parses an SDI of its own construction. Total prerequisites listed in the PoC README: physical access, TPM-only protector, PCR 7 plus PCR 11 trusted, and Microsoft Windows PCA 2011 in the Secure Boot db [@garatc-poc]. The wall clock for end-to-end exploitation: under five minutes.

{` // Schematic of the CVE-2025-48804 integrity-vs-execution split. // The hash covers the on-disk SDI bytes; execution follows an // offset pointer that the attacker can move past the hashed region.

const sdi = readFromDisk("Boot.sdi"); const hash = sha256(sdi); // integrity check sees ORIGINAL bytes if (hash !== expectedHash) throw "abort";

const offset = readOffsetFromHeader(sdi); // attacker-controlled in malicious SDI const wim = sdi.slice(offset); // points PAST the hashed region executeWim(wim); // runs appended malicious WIM

// Lesson: the hashed range and the executed range are not the same range. // The fix in KB5062553 binds them so that execution can only target // bytes that the integrity hash actually covered. `}

Once the malicious WinRE is running, it inherits the BitLocker auto-unlock state from the boot context. The encrypted volume is now mountable. The remaining three CVEs are about what an attacker can do from within WinRE that the original threat model did not expect WinRE to enable.

5.2 CVE-2025-48800 -- tttracer.exe as a proxy executor

WinRE's Offline Scanning operation invokes antivirus tooling from within the recovery environment. The set of trusted binaries WinRE will execute during scan is enumerated in ReAgent.xml -- WinRE's app-registry equivalent -- and includes Microsoft-signed diagnostic utilities. Among them is tttracer.exe, Microsoft's Time Travel Tracing debugger, included because it is occasionally invoked during diagnostics [@nvd-cve-2025-48800].

tttracer.exe is a proxy executor: by design, it launches an arbitrary process under tracing instrumentation. The LOLBAS project documents the exact invocation as tttracer.exe {PATH_ABSOLUTE:.exe}, mapped to MITRE ATT&CK technique T1127, with the launched process running as a child of tttracer.exe [@lolbas-tttracer]. Inside the WinRE auto-unlock boundary, with the live OS volume mounted, "arbitrary process" is the same primitive as "shell on the cleartext volume." Combine an attacker-controlled ReAgent.xml with tttracer.exe's proxy-execution semantics and Offline Scanning becomes Offline Pwning.

Time Travel Tracing is a Microsoft debugger most readers will not have seen named. It records process execution as a deterministic replayable trace and is a standard tool inside Microsoft's reliability engineering. Being on the WinRE trusted-app registry is a reasonable choice when the threat model is "diagnose a broken boot," not "an attacker is in the recovery environment."

5.3 CVE-2025-48003 -- SetupPlatform.exe and Shift+F10

SetupPlatform.exe, the Windows Setup host, remains on the WinRE trusted-app registry after upgrades and registers a Shift+F10 hotkey that opens cmd.exe. The Shift+F10 chord has been a long-standing Windows Setup feature for OEM imaging and unattended diagnostics, where it is harmless because there is no encrypted volume mounted yet [@nvd-cve-2025-48003] [@hackacademy-bitunlocker].

Inside WinRE, after auto-unlock has happened, Shift+F10 opens cmd.exe on the cleartext OS volume. STORM observed that manipulating the WinRE Apps Scheduled Operation entries in ReAgent.xml creates an unbounded trigger window -- the hotkey stays armed long enough for an attacker to use it. The shell that opens has the privileges of SetupPlatform under WinRE, with the OS volume mounted underneath it.

5.4 CVE-2025-48818 -- BCD target-OS impersonation

The first three CVEs assume the attacker has gotten WinRE to boot. The fourth one closes the loop and turns the access from a privileged shell on the volume into an unconditional, persistent decryption -- without any further interaction.

WinRE enumerates disk volumes in a specific order when deciding which Boot Configuration Data (BCD) store to consume as the description of the "operating system to recover." STORM placed an attacker-controlled BCD store on the recovery partition that gets enumerated before the legitimate one [@nvd-cve-2025-48818] [@hackacademy-bitunlocker]. WinRE treats the attacker volume as the trusted OS to recover, then invokes Push Button Reset with the DecryptVolume directive -- a legitimate sub-operation of PBR that disables BitLocker entirely. After Push Button Reset completes, BitLocker is not bypassed; it is off.

A legitimate WinRE sub-operation invoked during recovery when the target volume must be fully decrypted before being re-imaged or returned to a clean state. The directive removes the BitLocker protectors and rewrites every sector of the volume in plaintext. When invoked by a legitimately-recovered OS, this is correct behavior. When invoked by an impersonated target-OS BCD entry, it is a permanent encryption removal.

5.5 The structural pattern

flowchart TD subgraph WB["WinRE auto-unlock trust boundary"] WP["Boot.sdi parser"] RP["ReAgent.xml parser"] BP["BCD store enumerator"] TP["Trusted-app registry"] end C1["CVE-2025-48804
SDI offset confusion"] --> WP C2["CVE-2025-48800
tttracer.exe proxy"] --> RP C2 --> TP C3["CVE-2025-48003
SetupPlatform Shift+F10"] --> RP C3 --> TP C4["CVE-2025-48818
BCD impersonation"] --> BP WB --> VMK["BitLocker VMK released
to whatever runs inside"]

Four parsers; one boundary. The structural pattern reads:

Key idea: Every CVE attacks a different parser. Every parser sits inside the same auto-unlock trust boundary. Patching individual parsers does not close the boundary; it shrinks it. The boundary is the bug class.

Note: TPM bus sniffing fails against fTPM and Pluton because there is no exposed bus to sniff -- the seal is computed and released on-die. BitUnlocker does not attack the seal. The seal works exactly as designed: PCR 7 plus PCR 11 match the expected boot-chain measurements, and the TPM releases the VMK to the boot manager. The boot manager passes the unlock state into WinRE. WinRE then runs an attacker's code because one of its parsers had a bug. Nothing about fTPM or Pluton intervenes, because the entire attack is upstream of the silicon that the seal would protect.

Microsoft shipped patches for all four CVEs in KB5062553 on July 8, 2025 [@kb5062553]. The patches fixed the four code paths. They did not change the trust boundary. They did not, by themselves, even revoke the pre-patch boot manager that the chain depends on. To see what the July patches actually changed, and what they did not, we have to look at REVISE.

6. What KB5062553 changed, and what REVISE will

On the same Patch Tuesday that fixed BitUnlocker, Microsoft also reminded administrators that the Secure Boot certificate underwriting the entire Windows boot chain begins to expire in June 2026 [@kb5062553]. The two facts are not independent.

KB5062553 closed the four BitUnlocker code paths inside the Windows 11 24H2 build 26100.4652 cumulative. The SDI parser was bound so that the integrity hash and the execution range now agree. The trusted-app registry semantics for tttracer.exe and SetupPlatform.exe were tightened so neither acts as a proxy executor inside WinRE. The BCD enumeration order was reworked so the recovery partition cannot present a target-OS impersonator before the legitimate one. Those are real fixes for real bugs.

What KB5062553 did not change is the trust set. The pre-July-2025 bootmgfw.efi is still signed under PCA 2011, and PCA 2011 is still in the Secure Boot db on most fielded Windows devices. A physically present attacker can supply that old, signed, vulnerable boot manager from a USB stick. The firmware will load it. The four code paths are fixed in the new boot manager, but the old boot manager is still on the trust list. This is the same downgrade pattern that keeps Bitpixie exploitable [@neodyme-bitpixie-no-fix].

The structural defence is REVISE, shipped under KB5025885 and the CVE-2023-24932 advisory [@kb5025885]. REVISE adds the Windows Production PCA 2011 signing certificate to the Secure Boot dbx, which untrusts every boot manager signed by it, and ships a new UEFI CA 2023 certificate to replace the 2011 root. After REVISE deploys, the firmware refuses to load the pre-patch boot manager. The rollout is opt-in across multiple phases (currently five) because a dbx update at fleet scale carries real brick risk: any device that ends up trying to boot a binary whose signing certificate has just been moved to the deny-list will not boot. KB5025885 explicitly warns that once the mitigation is enabled on a device, it cannot be reverted while Secure Boot remains on.

This lemma appears in three places already in this article -- Bitpixie, BlackLotus, and BitUnlocker -- and it is worth stating once explicitly.

A Microsoft-signed binary stays in the trust set as long as its signing certificate is in db and neither its hash nor its signing certificate sits in dbx. Microsoft can ship a code-path patch that supersedes the old binary, but nothing in the trust set changes automatically. The dbx push is a separate operation, gated on a separate update, with its own opt-in semantics because pushing a wrong dbx value bricks devices.

The result is that "the bug is patched in the latest cumulative" and "an attacker with physical presence can no longer load the vulnerable signed binary" are not the same statement. The first is true after KB5062553. The second is true only after REVISE, only on devices where REVISE's dbx-revocation phase has run -- the phase that moves the PCA 2011 signing certificate into dbx so the deny-list overrides the allow-list. The June 2026 PCA 2011 expiration is the natural backstop -- after that date, the certificate no longer signs anything new, and the migration completes on its own timetable.

Until then, BitUnlocker's entry vector remains usable on every TPM-only device whose REVISE phase has not advanced.

flowchart LR A["Pre-July-2025 bootmgfw.efi
(PCA 2011 signed)"] --> B["KB5062553 patches
the four CVEs in the NEW
boot manager"] A --> C["REVISE adds PCA 2011
signing cert to dbx"] B --> D["New devices: closed code paths"] C --> E["Firmware refuses to load
the vulnerable signed binary"] D --> F["BitUnlocker fixed on patched device"] E --> G["BitUnlocker entry vector blocked
across the fleet"]

Note: PCA 2011 begins to expire in waves starting June 2026 [@kb5062553]. The UEFI CA 2023 migration must complete before then. Administrators of devices that have not yet reached REVISE's dbx-revocation phase should treat the June 2026 date as a hard deadline, not a goal: any device that misses the migration risks losing Secure Boot trust entirely on its next firmware update.

Patches close code paths. REVISE closes trust. Neither closes the WinRE auto-unlock surface itself. That is a different question, and the comparison Microsoft never likes to make is what other desktop operating systems chose to do about it.

7. How other platforms make the same trade-off

Windows is the only major desktop operating system that ships an auto-unlocking recovery environment on a TPM-sealed key. The other three -- macOS, ChromeOS, and Linux with LUKS -- make different choices at the same trade-off point. Looking at those choices shows what is actually possible.

Platform	Recovery primitive	Key availability during recovery	Auto-unlock from physical-presence path	Failure mode if compromised
Windows + BitLocker + WinRE	Push Button Reset, Startup Repair, Reset This PC	VMK released by TPM, inherited by WinRE	Yes -- Shift+Restart -> recovery menu	BitUnlocker class: parser bugs leak the cleartext volume to attacker code running inside WinRE
macOS + FileVault + macOS Recovery	macOS Recovery (boot to recovery partition)	Data Volume NOT mounted; user password or recovery key required	No	Recovery cannot read user data without authentication
ChromeOS + Verified Boot + Powerwash	Recovery USB / `chrome://recovery`	None -- recovery wipes user data	No	Recovery destroys the protected data set
Linux + LUKS / dm-crypt	initramfs / rescue shell	None -- every boot prompts for passphrase	No	Recovery cannot proceed without passphrase

Windows + BitLocker + WinRE is the only row in that table where the recovery environment can read user data without re-prompting the user. BitUnlocker is what the trade-off looks like once that property gets weaponised.

macOS chose a different recovery model. FileVault encrypts the Data Volume; the signed System Volume Snapshot does not. macOS Recovery boots into the signed system volume and presents a Disk Utility view of the Data Volume that requires a user password or recovery key to mount. The recovery environment is not given the keys. A macOS-side analogue of CVE-2025-48804 would still need to coerce Recovery into surfacing authentication UI -- the recovery primitive does not run with the user volume already mounted.

ChromeOS chose the most aggressive recovery model. Verified Boot enforces signature chains all the way to the kernel; recovery from a corrupted state means powerwash, which wipes the user partition. There is no equivalent of WinRE that needs to read the encrypted volume. The trade-off is enforced by sacrificing the data, which is acceptable because user data on ChromeOS is mostly remote.

LUKS / dm-crypt is the simplest model. Every boot, including recovery, prompts for the passphrase. There is no auto-unlock state to inherit. The trade-off is help-desk burden: a forgotten passphrase is a wiped drive. This is the model that the Microsoft Countermeasures page implicitly recommends for the "skilled attacker with lengthy physical access" threat tier when it suggests TPM+PIN [@ms-bitlocker-countermeasures].

Windows defines recovery as *transparent repair*. macOS defines it as *authenticated rebuild*. ChromeOS defines it as *wipe and restart*. LUKS defines it as *the same authentication you would do on a normal boot*. Each is internally consistent with the rest of its security model. None of them is wrong in isolation. They differ in what trade-off they make between fleet recoverability and recovery-environment exposure -- and BitUnlocker is what the most-usable-recovery choice costs.

Recovery-key escrow to Microsoft Entra ID, Active Directory, or a local user account is a separate confidentiality boundary from the BitUnlocker surface. Forbes reported in January 2026 on a Guam FBI warrant served to Microsoft for BitLocker recovery keys, illustrating the legal-process pathway [@forbes-guam-bitlocker]. Different threat surface; same product.

The trade-off Microsoft made in 2006 was the right one for a fleet that needs help-desk recoverability and the wrong one for a threat model with physical access. Eighteen years and seven attack generations later, the trade-off has not been revisited. The next section asks whether it can be.

8. Why patching cannot close the surface

In complexity theory, an impossibility result tells you what cannot be done no matter how hard you try. BitUnlocker is not that kind of result. It is the next thing over: a structural consequence of the threat model that no quantity of parser patches can close.

State the recovery-versus-confidentiality dilemma carefully. As long as a system auto-unlocks an encrypted volume for repair purposes without user-presence verification at the moment of recovery, the recovery environment's trust boundary equals the encryption's trust boundary. This is not a theorem in the published literature. It is the structural reading of the Microsoft Countermeasures threat-model tiers [@ms-bitlocker-countermeasures], and it follows almost mechanically from how the WinRE auto-unlock state is inherited.

The dilemma admits exactly two engineering exits. The first is to deprecate WinRE auto-unlock and require a recovery key for every WinRE entry. Microsoft has not done this and will not do this, because the help-desk recoverability story collapses without it -- fleet administrators rely on WinRE entry being silent for routine repair. The second is to make TPM+PIN the default for non-Entra-enrolled devices, which forces a pre-boot human-presence check that WinRE structurally cannot satisfy. Microsoft has not done this either, presumably because of the help-desk cost of forgotten PINs at consumer scale.

Until one of those two changes, the next BitUnlocker is a question of when, not whether. The four CVEs are an existence proof for the bug class "Microsoft-signed binary on the WinRE trusted-app registry whose parsing of unsigned configuration data can be coerced." The cardinality of that bug class is not four. STORM found four. There are more.

Key idea: As long as a system auto-unlocks an encrypted volume for repair purposes without user-presence verification at the moment of recovery, the recovery environment's trust boundary equals the encryption's trust boundary. The bug class is not the parsers. The bug class is the boundary that contains them.

Note: You cannot have unattended recovery and confidentiality at the same time against an attacker with physical presence. Every desktop operating system that has tried has either added authentication to recovery (macOS) or has been broken at recovery (BitUnlocker, multiple times). The choice is a product decision, not a software bug.

Microsoft is not unaware of this. Quick Machine Recovery -- the cloud-orchestrated recovery primitive that reached general availability in 2025 -- extends the WinRE-equivalent surface rather than retracting it [@ms-qmr]. The trade-off pricing is ongoing. So is the audit.

The next section is the question that follows from the boundary framing: what else is inside the boundary that STORM did not get to?

9. What STORM did not audit

STORM published four CVEs. The Windows Recovery Environment contains more than four parsers.

Four open questions follow directly from the boundary framing:

The remaining WinRE trusted-app surface. STORM exploited tttracer.exe and SetupPlatform.exe. The WinRE Apps Scheduled Operation in ReAgent.xml registers other Microsoft-signed binaries. None of those binaries was written under the assumption that an attacker would be the one calling them with the OS volume mounted. How many similar inheritances remain unaudited is unknown, and the population is the unstated denominator of every subsequent BitUnlocker-class CVE.

PCA 2011 trust on most fielded devices. Until REVISE deploys at fleet scale, the pre-July-2025 bootmgfw.efi remains chain-loadable on any device that still trusts PCA 2011. The June 2026 PCA 2011 expiration is the structural milestone [@kb5062553]. Between mid-2025 and mid-2026, the BitUnlocker entry vector is a deployment question, not a code question.

Quick Machine Recovery extending the WinRE-equivalent surface. Cloud-orchestrated recovery on encrypted volumes occupies the same trust boundary as WinRE -- by design, since the point of QMR is to do silent fleet repair on devices that cannot reach a desk [@ms-qmr]. No published security audit comparable to STORM's BitUnlocker work has appeared for QMR. The next BitUnlocker-shaped CVE may live there.

Pluton hardware bypass. No published practical hardware attack on Pluton exists in the open literature as of mid-2026. The SCRT/Compass-class TPM+PIN bypasses are limited to discrete-TPM hardware where the bus between CPU and TPM is exposed [@scrt-tpm-pin] [@compass-2024] [@ms-pluton]. Whether Pluton admits decapping, laser-fault-injection, or microarchitectural side-channel attacks is an open question that nobody outside Microsoft and a handful of three-letter agencies has the budget to answer at scale.

Quick Machine Recovery's 2025 general availability puts it inside the BitUnlocker disclosure timeline [@ms-qmr]. Microsoft is expanding the WinRE-equivalent attack surface in the same calendar year that STORM is publishing the four CVEs.

And one orthogonal question that every BitLocker survey is asked: who has the recovery key? A serious defender has to think about the recovery-key escrow surface too -- see below.

Note: Cloud escrow of the BitLocker recovery key is a confidentiality surface that BitUnlocker does not touch. BitUnlocker is a parser-level chain that gives a physically-present attacker the cleartext volume without ever needing the recovery key. The keyholder question is orthogonal. Both surfaces exist; both are worth thinking about; neither closes the other.

The open-problems list above is what is unaudited as of mid-2026. The actionable question -- what do I, as an administrator, do tomorrow? -- is the subject of the next section.

10. Six things defenders should do this week

If you administer a Windows fleet, six concrete actions change the threat model. They are listed here in priority order, not severity order. The first one is the structural mitigation; the others are patch hygiene around it.

1. Enable TPM+PIN. The PowerShell-equivalent invocation is manage-bde -protectors -add C: -tpmandpin [@ms-manage-bde]. This is the only mitigation that changes the threat model independently of patch state -- it forces a pre-boot human-presence check that WinRE structurally cannot satisfy. The honest trade-off: users forget PINs and help-desk burden goes up. The honest counterpoint: the recommendation has been in the Microsoft Countermeasures page in some form since Vista, and BitUnlocker is what eighteen years of ignoring it has produced [@ms-bitlocker-countermeasures].

Note: manage-bde -protectors -add C: -tpmandpin -- one PowerShell command, one PIN per user, one threat model permanently changed. This defeats Bitpixie, BitUnlocker, and any future BitUnlocker-class attack that lives upstream of the TPM seal. It does not defeat hardware TPM+PIN bus-sniff attacks on discrete TPMs [@scrt-tpm-pin] [@compass-2024], which are a separate class.

2. Apply KB5062553 or any later cumulative. The July 8, 2025 cumulative closes the four BitUnlocker code paths [@kb5062553]. By the time you read this, several later cumulatives have shipped; deploy the latest. This addresses the post-entry portion of the chain but not the entry vector.

3. Deploy REVISE / migrate Secure Boot to UEFI CA 2023. This is the dbx-side defence that revokes the pre-patch bootmgfw.efi [@kb5025885]. Until REVISE has run on a device, "patched" is not "revoked." The deployment is opt-in across multiple phases (currently five) because a bad dbx push at scale bricks devices; the June 2026 PCA 2011 expiration is the hard deadline.

4. Restrict WinRE access where the threat model permits. On kiosks, lab machines, lights-out servers, and other devices where there is no fleet-recovery requirement, reagentc /disable closes the WinRE entry surface entirely. This costs you Push Button Reset and Startup Repair on those devices, which is acceptable for devices that are re-imaged centrally [@hackacademy-bitunlocker].

5. Harden the firmware delivery surface. Enable Secure Boot, set a firmware password, disable USB and PXE boot in firmware on devices that are not expected to be re-imaged in the field [@hackacademy-bitunlocker]. This closes the delivery vector independently of the WinRE patch state. It does nothing against an attacker who can boot from internal disk, which is why this is one of six items rather than the first one.

6. Surface BitLocker protection state in management telemetry. Intune, Microsoft Defender for Endpoint, and Entra ID can all report on whether a device has a TPM-only or TPM+PIN protector and whether the CVE-2023-24932 dbx revocation has applied (the per-device Secure Boot dbx update status field surfaced in Intune / Defender for Endpoint). Make those fields first-class in your fleet dashboards. PIN-on / PIN-off and dbx-revoked / not-revoked should both be visible at the fleet level, not buried inside a per-device drill-down.

{` // Logical equivalent of: manage-bde -protectors -get C: // Run this against the parsed output to confirm the // device is using TPM+PIN rather than TPM-only.

function classifyProtectors(protectorTypes) { const hasPIN = protectorTypes.includes('TpmPin') || protectorTypes.includes('TpmPinStartupKey'); const hasTPM = protectorTypes.some((t) => t.startsWith('Tpm')); if (!hasTPM) return 'NoTPM -- not in scope of BitUnlocker'; if (hasPIN) return 'TPM+PIN -- defeats BitUnlocker entry vector'; return 'TPM-only -- vulnerable to BitUnlocker entry vector'; }

// Example: the default Windows 11 consumer configuration console.log(classifyProtectors(['Tpm', 'RecoveryPassword'])); // -> "TPM-only -- vulnerable to BitUnlocker entry vector" `}

If you genuinely cannot deploy TPM+PIN (kiosks running unattended, OT workloads, accessibility-driven exemptions), the partial mitigation stack is REVISE's dbx-revocation phase + firmware password + USB/PXE disabled in firmware + Kernel DMA Protection. Together these close the BitUnlocker entry vector on the patched code paths *and* the downgrade path *and* the firmware delivery channel. None of them changes the WinRE auto-unlock boundary -- only TPM+PIN does that -- so the next BitUnlocker-class CVE may still be exploitable on these devices until the corresponding patch ships. Treat this stack as a temporary mitigation, not a permanent answer.

None of these are new recommendations. The pre-boot PIN line in particular has been in the Microsoft Countermeasures page in some form since Vista [@ms-bitlocker-countermeasures]. What has changed is the operational consequence of not following it. BitUnlocker is what the consequence looks like today.

11. Frequently asked questions

BitUnlocker has produced a predictable list of misconceptions. Each question below names a common misconception about BitUnlocker and gives the correct framing -- because the wrong answers are where threat models get built quietly.

Yes against both -- the attack is upstream of the TPM seal, so the bus-elimination property of fTPM and Pluton does not help here. See §5.5 for the full mechanism and the contrast with TPM bus sniffing, which *does* fail against fTPM and Pluton because there is no exposed bus to sniff. No. BitUnlocker was *patched* on July 8, 2025 in KB5062553 [@kb5062553]. It was *disclosed* at Black Hat USA 2025 and DEF CON 33 in early August 2025, with the Microsoft Security Blog write-up published August 13 to 14, 2025 [@ms-bitunlocker]. Coordinated disclosure timelines mean the patch ships before the talk. Useful date to remember: KB5062553 = fix, August 2025 = public technical detail. Only against an attacker who cannot chain-load the pre-July-2025 `bootmgfw.efi`. Until REVISE / KB5025885 is deployed on a given device, the old signed boot manager remains trusted [@kb5025885] and the BitUnlocker entry vector remains usable from a USB stick. The patch closes the code paths in the new boot manager; the dbx update closes the old one's trust. They are different operations on different schedules. Yes against the BitUnlocker CVE class. A pre-boot PIN forces a human-presence check that WinRE structurally cannot satisfy from a boot-time recovery context. The Compass Security and SCRT TPM+PIN bypasses [@compass-2024] [@scrt-tpm-pin] are a separate, hardware-physical class that targets the bus between CPU and discrete TPM; they do not apply to fTPM or Pluton. For a TPM+PIN on Pluton or fTPM, none of the published attacks in this article succeed. No. The chain uses Microsoft-signed binaries throughout. The pre-patch `bootmgfw.efi` is Microsoft-signed under PCA 2011. `tttracer.exe`, `SetupPlatform.exe`, and the WinRE binaries inside the trust boundary are all Microsoft-signed. The bug class is logic flaws in the parsing of *unsigned data* (Boot.sdi, ReAgent.xml, BCD) by signed binaries. Secure Boot is doing exactly what it is designed to do; the boundary it enforces is not the boundary BitUnlocker crosses. No. Bitpixie scavenges the VMK from RAM via a soft-reboot bug in the pre-patch `bootmgfw.efi` (CVE-2023-21563, discovered August 2022 by Rairii, disclosed February 2023) [@neodyme-bitpixie]. BitUnlocker boots a malicious WinRE that inherits auto-unlock on the live volume. The shared structural pattern is that both are upstream of the TPM seal, both are defeated by TPM+PIN, and both work against fTPM and Pluton. The mechanism is different; the lesson is identical. STORM is the *Security Testing and Offensive Research at Microsoft* team -- Microsoft's internal red team. Alon Leviev, one of the BitUnlocker co-authors, also disclosed Windows Downdate at Black Hat USA 2024 [@safebreach-downdate]. The Downdate research showed that the Windows update pipeline could be coerced into installing older, vulnerable code paths. BitUnlocker is a different mechanism by the same researcher, one year later, on the recovery pipeline rather than the update pipeline.

The Shift+Restart chord ships in every copy of Windows. The recommendation that defeats it -- enable a pre-boot PIN -- has been on the Microsoft Countermeasures page since Vista. STORM's contribution is not that they found four bugs. It is that they made what happens when the recommendation is ignored impossible to look away from. The next move is the reader's.

To defend against malicious reset attacks, BitLocker uses the TCG Reset Attack Mitigation, also known as MOR bit. -- Microsoft Learn, BitLocker Countermeasures [@ms-bitlocker-countermeasures]

Secure Boot in Windows: The Chain From Sector Zero to Userinit, and Every Place It Has Broken

noreply@paragmali.com (Parag Mali) — Sat, 09 May 2026 00:00:00 GMT

Windows boots through a chain of verifications and measurements that runs from CPU reset to your desktop. UEFI Secure Boot signs the boot manager; Trusted Boot extends the signature check to every kernel-mode component; Measured Boot extends a parallel hash of every step into the TPM's PCR 0-7 and PCR 11, with DRTM later seeding PCR 17-22 from a CPU-vendor-signed late-launch anchor. After fifteen years of BIOS rootkits, MBR bootkits, and ESP-resident bootkits, that chain holds -- but every public Secure Boot break since 2022 (BlackLotus, Bitpixie, Bootkitty, LogoFAIL) has exploited the same gap: between patching a vulnerable Microsoft-signed binary and revoking it in dbx. Pluton-rooted firmware on Microsoft's update cadence is the planned escape.

1. Eight seconds in 2010, and everything that could already be wrong

Picture a small business owner in December 2010. She unplugs her three-year-old Dell, drives it home, and powers it on. The fan spins. The BIOS chimes. The Windows 7 logo appears. By the time she types her password and the desktop loads, eight seconds have passed.

In those eight seconds, a TDL-4 bootkit that has been on disk for two weeks has already done its work. The infected master boot record patched the operating system loader in memory before the kernel finished initialising. Driver Signature Enforcement, the policy that was supposed to keep unsigned kernel drivers out, was disabled before the kernel checked for it. A ring-0 rootkit is now staged inside ntoskrnl.exe. Kaspersky's June 2011 analysis counted 4,524,488 infected machines in the first three months of 2011 alone [@kaspersky-tdl4]. The owner notices nothing. By the time she authenticates, the operating system that authenticates her is loading code the operating system never agreed to load.

The structural question raised by that scene is the question this article exists to answer: what would it take for Windows to know, by the time the user types a password, that the machine has not been tampered with since power-on?

The answer Microsoft began designing in 2011-2012 is a chain. UEFI Platform Initialization brings up the firmware. UEFI Secure Boot verifies the boot manager. Trusted Boot extends the signature check through winload.efi, the kernel, and every boot-start driver. Early Launch Anti-Malware classifies subsequent drivers. The Secure Kernel comes up in a hardware-isolated execution mode. Through every one of those rungs, a parallel rail -- Measured Boot -- writes a tamper-evident hash log into the TPM's Platform Configuration Registers, so that what was loaded can be proven later, even if the verifier itself was bypassed.

That chain is the spine of this article. We will walk it rung by rung. We will see where it has been broken in the wild. And we will see why every successful break since 2022 has exploited the same operational invariant -- the gap between patched and revoked -- rather than any flaw in the cryptography.

flowchart TD SEC["SEC -- CPU reset, immutable ROM"] --> PEI["PEI -- platform init"] PEI --> DXE["DXE -- Secure Boot verifier lives here"] DXE --> BDS["BDS -- pick boot variable"] BDS --> BMGR["bootmgfw.efi (Microsoft-signed)"] BMGR --> WLOAD["winload.efi (Microsoft-signed)"] WLOAD --> NT["ntoskrnl.exe + boot-start drivers"] NT --> ELAM["ELAM (Defender, signed AM)"] NT --> SK["securekernel.exe (VTL1) + Trustlets"] ELAM --> SMSS["smss.exe -> wininit -> winlogon"] SK --> SMSS SMSS --> USR["userinit.exe -> explorer.exe"] TPM[("TPM PCR 0-7, PCR 11")] DXE -. extend .-> TPM BMGR -. extend .-> TPM WLOAD -. extend .-> TPM NT -. extend .-> TPM ELAM -. extend .-> TPM

Before there was a chain to walk, there was no chain at all.

2. Before Secure Boot: sector zero and the fiction of OS-level security

Ask what was actually verified during a 2011 PC boot, and the answer is: one byte pair. The 0x55AA magic at the end of the 512-byte master boot record. That is a format check, not an authenticity check. The 16-bit BIOS power-on self test loaded sector zero of the boot device into memory at 0000:7C00 and jumped [@wp-mbr]. No signature. No measurement. Whatever was at sector zero, ran.

That architectural fact had been the structural lesson of computer-security history for a quarter century. Stoned, the boot sector virus written by an unknown student in Wellington, New Zealand in 1987, demonstrated it without malicious intent: the virus was a prank that displayed "Your PC is now Stoned!" and propagated by writing itself to the boot sector of every disk a victim machine touched [@wp-stoned]. Brain (Pakistan, 1986) [@wp-brain] and Michelangelo (1991) [@wp-michelangelo] were the same lesson at scale. The lesson was not that those particular authors were dangerous. It was that any code reaching sector zero ran with implicit privilege.

A class of malware that survives operating-system reinstallation and antivirus scanning by infecting code that runs *before* the operating system loads -- traditionally the master boot record or the partition's volume boot record, more recently the EFI System Partition or the firmware itself. A bootkit's defining property is that the operating system it boots is one the bootkit itself chooses to load.

The modern bootkit family arrived in 2005 and ran undefended for the next seven years. Derek Soeder and Ryan Permeh of eEye published BootRoot at Black Hat USA 2005 [@bhusa05-bootroot], a proof of concept that hooked the BIOS interrupt 13h disk-read service before any operating system loaded and intercepted Windows kernel images on the way to memory. Vbootkit (Vipin and Nitin Kumar) followed in 2007, demonstrating the same primitive on Vista [@vbootkit-archive]. Mebroot (the malware family Sinowal/Torpig used) compiled in November 2007 according to early infection telemetry, weaponised the technique against actual victim populations [@wp-mebroot]. By 2011, TDL-3 and TDL-4 had pushed the lineage into the millions of infected hosts [@kaspersky-tdl4].

The category took its final structural step on 13 September 2011, when Marco Giuliani at Webroot's threat lab disclosed Mebromi, the first BIOS rootkit found in the wild. Mebromi targeted Award BIOS firmware. It used the legitimate Phoenix CBROM.EXE utility -- a tool the BIOS vendor itself shipped for assembling firmware images -- to splice malicious code into the firmware ROM image, then flashed the modified ROM through System Management Mode. On every subsequent boot, the firmware itself reinstalled the rootkit's MBR before any operating system existed to scan for it.The Mebromi reuse of the legitimate CBROM.EXE firmware-assembly utility is the canonical illustration of the architectural problem. The defender's tools and the attacker's tools were the same tools. The firmware-update path had no signature, no measurement, and no policy gate; CBROM was just an executable that knew the Award ROM image format. The fix was not better antivirus. The fix was a hardware root that the OS itself could not rewrite.

The structural argument that Mebromi made unanswerable: there was no measurement endpoint and no signature verifier anywhere below the operating system. Every operating-system-level defence was rhetorical against this layer. Kernel-Mode Code Signing, the policy Windows Vista x64 had introduced in 2006 [@app-identity-sibling], was enforced by code that the bootkit could rewrite before the kernel started checking. Driver Signature Enforcement was a setting the operating system wrote into a memory location the operating system could not yet defend.

Trust must be rooted in something the operating system cannot rewrite. That means the chain has to start before the operating system exists. The next rung is firmware itself.

3. UEFI Platform Initialization: SEC, PEI, DXE, BDS, and where Secure Boot actually lives

If Secure Boot starts at the operating-system loader, which exact piece of firmware decides whether the operating-system loader is allowed to run, and what verifies that piece? The answer is a four-phase pipeline that almost no Windows engineer ever writes about. It is also where every modern firmware attack lands.

The Unified Extensible Firmware Interface Platform Initialization specification defines the internal architecture firmware uses to bring a system up. It splits boot into four phases: Security (SEC), Pre-EFI Initialization (PEI), Driver Execution Environment (DXE), and Boot Device Selection (BDS). Standard Windows usage of "UEFI" almost always means the externally-visible behaviour exposed by BDS and the EFI runtime services, not the multi-phase internal pipeline the firmware uses to get there.

The four phases, per the TianoCore reference flow [@tianocore-pi-flow]:

SEC. The Security phase begins at processor reset. Code runs from immutable on-die ROM or a locked region of SPI flash before main memory is even initialised. SEC's job is to establish the root of trust in the firmware -- before any flexible code path can be taken, the firmware has committed to an instruction stream the operating system cannot influence.
PEI. Pre-EFI Initialization brings up DRAM, configures the memory controller, populates Hand-Off Blocks (HOBs) the later phases consume, and dispatches the small drivers needed to reach a state where general firmware code can run. SEC and PEI together are the part of firmware that fits in the few hundred kilobytes of cache-as-RAM the CPU offers before main memory is up.
DXE. The Driver Execution Environment hosts most of what we think of as firmware: the disk drivers, the network stack, the human-interface drivers, the USB stack, and Secure Boot's image verifier. This is where LoadImage() runs db/dbx checks against incoming PE/COFF binaries. DXE phase code is several megabytes on a modern x86 platform.
BDS. Boot Device Selection reads the BootOrder UEFI variable, picks a boot entry, hands the platform off to the operating system loader, and -- in normal operation -- never runs again until the next reboot.

flowchart LR BG["Boot Guard / AMD PSB
(microcode, OTP fuses)"] --> SEC["SEC
immutable ROM"] SEC --> PEI["PEI
DRAM init"] PEI --> DXE["DXE
Secure Boot LoadImage()"] DXE --> BDS["BDS
read BootOrder"] BDS --> OS["bootmgfw.efi"]

There is one rung below SEC. Intel Boot Guard verifies the firmware via a CPU-microcode-loaded Authenticated Code Module signed by Intel [@wp-txt]; AMD Platform Secure Boot performs the same role from the AMD Platform Security Processor (PSP), an ARM-based co-processor embedded on the SoC [@ioactive-psb, @wp-amd-psp]. Both run before SEC can begin. Intel introduced Boot Guard on platforms based on the Haswell processor family (4th-generation Core, Lynx Point PCH) in 2013 [@eset-lojax, @wp-txt]; the actual root-of-trust fuses live in the PCH (on Haswell through Skylake-era platforms; from Ice Lake (2019+) onward, Intel placed the fuses on the CPU die itself) [@eset-lojax], and the OEM commits the verification key at provisioning, so Boot Guard support is a chipset-and-OEM property rather than a bare CPU-model property [@eset-lojax, @ioactive-psb]. AMD's PSB followed on EPYC server parts and was rolled out to Ryzen Pro platforms over the next several years; the PSP itself has been present on AMD client and server parts since around 2013 [@wp-amd-psp], but PSB is a distinct firmware-signing flow that uses it [@ioactive-psb].The Windows Hardware Compatibility Program codified UEFI 2.3.1 as the firmware floor for Windows 10 security features [@ms-oem-uefi]. Anything below 2.3.1 cannot host a Secure Boot configuration that Microsoft will certify. The keys that anchor those verifications are burned into one-time-programmable fuses inside the package, so the OEM commits to a public key when the part ships and cannot rotate it later [@eset-lojax, @ioactive-psb]. ESET's 2018 LoJax disclosure recommended Boot Guard explicitly: "if possible, have a processor with a hardware root of trust as is the case with Intel processors supporting Intel Boot Guard (from the Haswell family of Intel processors onwards)" [@eset-lojax].Boot Guard's OTP fuses are the canonical example of why hardware-rooted verification cannot have a software-only escape hatch [@eset-lojax, @ioactive-psb]. If the OEM's signing key leaks, the fuses cannot be reprogrammed in the field; an attacker with the leaked key can produce firmware that the silicon will accept. This is the structural argument behind moving the root one more rung down -- into Pluton, where Microsoft, not the OEM, owns the update cadence.

The conclusion is the part most engineers skip. By the time bootmgfw.efi is verified, several megabytes of DXE-phase code have already executed. Anything that compromises the DXE compromises Secure Boot from below: the verifier itself is now the attacker's code. That is the precondition that LogoFAIL exploits, and it is the reason "Secure Boot starts at the OS loader" is the wrong mental model.

NIST recognised the structural problem early. NIST Special Publication 800-147 BIOS Protection Guidelines (April 2011) [@nist-sp-800-147] articulated the BIOS-update-signing baseline two years before Boot Guard shipped a hardware-rooted answer. SP 800-147 said only that firmware updates must be signed; it did not say who must verify the signing key. Boot Guard and PSB were the hardware-rooted answer to that gap, with the OEM holding the verification key in OTP fuses.

Now we have a place to put a verifier. The next question is what it verifies, and who signed the allowlist.

4. Secure Boot itself: PK, KEK, db, dbx, and the Microsoft monoculture

Secure Boot is four UEFI variables, one Authenticode hash per binary, and one centralised root of trust. The technical content of this section is not the hard part. The social and operational content -- who holds which key, and what happens when a signed binary becomes vulnerable -- is the rest of the article.

The four authenticated UEFI variables, defined in UEFI 2.3.1 (April 2011) and refined through the current 2.11 specification (December 16, 2024) [@oem-secure-boot]:

PK -- the Platform Key. The OEM holds the private half. Whoever holds PK can rewrite KEK, db, and dbx; whoever holds PK can turn Secure Boot off by replacing PK with a key it does not actually own.
KEK -- the Key Exchange Key. Both the OEM and Microsoft hold KEKs. KEK is the trust anchor for db and dbx updates. A KEK-signed update can add or remove entries in db and dbx without touching PK.
db -- the signature database. This is the allowlist: hashes the firmware will accept, plus certificates whose signers it will accept. db typically contains a small handful of entries.
dbx -- the forbidden signatures database. The denylist: hashes and certs the firmware must refuse, even if they would otherwise pass db.

Four EFI variables defined by the UEFI specification that together form Secure Boot's trust hierarchy. Each variable is *authenticated*: any update must be signed by a key one rung up the hierarchy. PK signs updates to KEK, db, and dbx; KEK signs updates to db and dbx. Microsoft requires the Microsoft Corporation KEK CA to be present in KEK on every Windows-certified PC, so that Microsoft can push db and dbx updates without OEM cooperation per device.

The verification algorithm runs every time UEFI calls LoadImage() on a PE/COFF binary, in this order:

Hash the PE/COFF image. The Authenticode digest excludes the signature directory and the checksum field, so the hash is computed over the parts of the image that should not change between signing and loading [@ms-pe-format].
If the hash matches a hash in dbx, reject.
Else if the signer's certificate chains to a certificate in dbx, reject.
Else if the hash matches an entry in db, accept. Else if the signer chains to a certificate in db, accept.
Else, reject.

Microsoft's WHCP requires firmware components to be signed with at least RSA-2048 and SHA-256 [@oem-secure-boot]. That floor is generous by 2026 standards but has held without serious controversy since the original UEFI 2.3.1 release.

flowchart TD L["LoadImage(image)"] --> H["Compute Authenticode hash"] H --> D1{"Hash in dbx?"} D1 -- yes --> R["REJECT"] D1 -- no --> D2{"Signer chains to dbx cert?"} D2 -- yes --> R D2 -- no --> D3{"Hash in db, OR signer chains to db cert?"} D3 -- yes --> A["ACCEPT (load image)"] D3 -- no --> R

The de facto roots for x86 PCs are two Microsoft-rooted certificate authorities, both pre-trusted in db on essentially every certified Windows-class system: the Microsoft Windows Production PCA 2011, which signs Microsoft's own Windows boot binaries (bootmgfw.efi, bootmgr.efi, winload.efi), and the Microsoft Corporation UEFI CA 2011, which signs third-party UEFI binaries -- Linux's shim, option ROMs, and third-party firmware drivers [@sbat-shim, @oem-secure-boot]. The rhboot/shim project documents the arrangement: every certified PC is "typically configured to trust 2 authorities for signing UEFI boot code, the Microsoft UEFI Certificate Authority (CA) and Windows CA" [@sbat-shim]. The fact that both are Microsoft-rooted is the reason Secure Boot, as deployed, and "Microsoft is the gatekeeper of which operating systems may boot" are operationally the same thing. The UEFI Forum's specification did not require that monoculture. The economics did. There are exactly two certificate authorities every OEM is willing to trust by default, and both belong to the operating-system vendor whose installer media every OEM ships.

The X.509 certificate authorities Microsoft uses for Secure Boot. Two CAs from the 2011 family ship pre-installed in db on essentially every Windows-certified PC: the **Microsoft Windows Production PCA 2011** signs Microsoft's own Windows boot binaries, and the **Microsoft Corporation UEFI CA 2011** signs third-party UEFI binaries (Linux's `shim`, option ROMs, third-party firmware drivers). Both 2011 certificates begin expiring in late June 2026. The **Windows UEFI CA 2023** is their successor; its industry-wide enrolment began in May 2023 with the KB5025885 program responding to CVE-2023-24932 and is still rolling out under phased automatic enrolment via monthly Windows Updates as of 2026. Linux's path through Secure Boot runs through `shim.efi`, a small bootloader Matthew Garrett released on November 30, 2012 -- his last day at Red Hat. The trick is structural: Microsoft signs `shim` itself; `shim` is shipped on the install media of every major Linux distribution; once running, `shim` validates a distribution-signed `grubx64.efi` (or kernel) using a key the distribution embeds, *or* a Machine Owner Key (MOK) the user has enrolled at install time. Garrett credits the MOK design to engineers at SUSE. The arrangement is the open-source community's pressure valve against the Microsoft monoculture: Linux still boots on Secure Boot hardware because Microsoft signs one bootloader that delegates trust to a community-managed key store. It also explains why Linux dual-boot installs began breaking after May 2023 -- the certificates that signed older copies of `shim` are being rotated out.

The dbx variable carries the operational weight of the system. If a signed bootloader is found to be vulnerable, the only blocking remedy is to add its hash to dbx. dbx lives in NV-RAM; on commodity Windows PCs the storage budget is roughly 32 KB total [@sbat-shim].The 32 KB figure comes from the rhboot/shim project's SBAT documentation, which notes that the BootHole disclosure of July 2020 -- a single GRUB vulnerability requiring revocation of three certificates and roughly 150 image hashes -- consumed approximately 10 KB of dbx in one event. That is one third of the available capacity, used up by one CVE. Linux distributions and Windows share the same dbx region. A botched update can refuse to validate a bootloader that the platform actually needs, and there is no remote rollback for a brick-on-write to dbx. Section 9 will show what happens when dbx revocation lags behind a CVE.

The CA-2023 transition is therefore not a routine certificate rotation. The original 2011 certificates begin expiring in late June 2026. Microsoft's industry-wide Windows UEFI CA 2023 rollout started May 2023 with KB5025885, the patch advisory that paired with CVE-2023-24932, and is on track to be, in Microsoft's own framing, one of the largest coordinated security maintenance efforts the Windows install base has ever seen [@kb5025885]. The phasing, as published: enrol the new CA in db; sign new bootloaders with it; enrol new dbx entries to revoke older signed-but-vulnerable binaries; finally, revoke the 2011 CA. The published cautionary text is unambiguous: once the irreversible mitigation step is enabled on a device, "it cannot be reverted if you continue to use Secure Boot on that device. Even reformatting of the disk will not remove the revocations if they have already been applied" [@kb5025885].

{` // Sketch of what UEFI does for every PE/COFF binary it loads. function loadImage(image, db, dbx) { const hash = authenticodeHash(image); const signerCert = parseSignerCert(image);

if (dbx.hashes.includes(hash)) return { ok: false, reason: "dbx hash" }; if (signerCert && chainsTo(signerCert, dbx.certs)) { return { ok: false, reason: "dbx cert" }; } if (db.hashes.includes(hash)) return { ok: true, reason: "db hash" }; if (signerCert && chainsTo(signerCert, db.certs)) { return { ok: true, reason: "db cert" }; } return { ok: false, reason: "not in db" }; }

const decision = loadImage( { hash: "abc", signer: "Microsoft Windows Production PCA 2011" }, { hashes: [], certs: ["Microsoft Windows Production PCA 2011", "Microsoft Corporation UEFI CA 2011"] }, { hashes: [], certs: [] } ); console.log(decision); `}

Verification is a one-shot signature check at firmware boundaries. The chain still has to extend all the way to userland. Microsoft's name for what comes next is Trusted Boot. And here is the thing the patch-cadence narrative fails to convey: patched is not revoked. Microsoft can ship a fixed bootmgfw.efi next month. It cannot delete the old, vulnerable, validly-signed copy from every machine in the world. As long as the old binary's hash is not in dbx, Secure Boot will load it.

5. Trusted Boot: bootmgfw.efi, winload.efi, and the Windows-specific chain

Secure Boot can answer "is this .efi file in our allowlist?" It cannot answer "is every kernel-mode driver loaded after this .efi file in our allowlist?" That second question is what Trusted Boot exists to answer.

Microsoft's term for the post-firmware portion of the verified boot chain. UEFI Secure Boot validates `bootmgfw.efi`. `bootmgfw.efi` validates `winload.efi`. `winload.efi` validates `ntoskrnl.exe`, the Hardware Abstraction Layer, every boot-start driver, and the ELAM driver. `ntoskrnl.exe` validates every driver loaded thereafter against the active code-integrity policy. Trusted Boot is therefore the Microsoft policy enforcement chain layered *on top of* Secure Boot's firmware-side verifier; it is what extends the signature check past the operating-system loader into kernel mode.

The mechanics, after the firmware hands control to bootmgfw.efi: the boot manager reads the Boot Configuration Data store, locates winload.efi (or winresume.efi for resuming from hibernation), and enforces the boot-time integrity policy on every component it loads [@ms-trusted-boot]. The verifier handoff, however, is more interesting than the Microsoft Learn paragraph suggests. It runs in three stages.

Stage A: winload's in-image bootlib verifier. winload.efi does not call kernel-mode ci.dll to validate boot images. It carries its own boot-time code-integrity verifier inside the bootlib boot library shared with bootmgr. Reverse-engineering work on the Elysium bootkit research framework reconstructed the call chain inside winload.efi: OslLoadDrivers -> OslLoadImage -> LdrpLoadImage -> BlImgLoadPEImageEx -> ImgpLoadPEImage, with ImgpValidateImageHash performing the Authenticode digest check against the trusted boot policy embedded in winload itself [@elysium-bootkit]. Boot-start drivers, ntoskrnl.exe, the Hardware Abstraction Layer, and the ELAM driver all flow through this chain before kernel mode is alive to do anything about it.

Stage B: handoff via LOADER_PARAMETER_EXTENSION. When winload.efi is done validating, it has to hand the validated state across the loader-kernel boundary. The mechanism is LOADER_PARAMETER_EXTENSION (LPE), the under-documented structure that hangs off the LOADER_PARAMETER_BLOCK whose address the loader passes to the kernel.The LPE structure has been Microsoft-internal in every shipping Windows release; the public reference Geoff Chappell maintains is the canonical third-party reverse-engineering of its layout across Windows builds. New fields are added at the tail of the structure when shipping features need to communicate state across the loader/kernel boundary. The fact that Smart App Control's CI state needed two new LPE fields is a small but telling indicator of how much policy state Trusted Boot now carries. Geoff Chappell's reference describes the LPE as "part of the mechanism through which the kernel and HAL learn the initialisation data that was gathered by the loader" [@geoffchappell-lpe]. The structure has grown across Windows builds; with Smart App Control on Windows 11 22H2, two new fields -- CodeIntegrityData and CodeIntegrityDataSize -- were added so that the loader-validated CI state, including the active SiPolicy and the pre-validated boot-start driver list, would survive the handoff intact [@n4r1b-sac].

Stage C: kernel-mode ci.dll continuation. Only after ntoskrnl.exe is itself running does the kernel-mode ci.dll come into play. It picks up the SiPolicy state from the LPE and continues the same code-integrity policy enforcement on every kernel-mode image loaded after the loader's window closes -- principally via the Se-prefixed validation routines that the kernel's image-load notification routines call into. From that point, every subsequent driver load goes through the same code-integrity gate. The bootlib -> LPE -> kernel-mode ci.dll decomposition is the underlying mechanism Microsoft's high-level documentation collapses into a single sentence:

The Windows bootloader verifies the digital signature of the Windows kernel before loading it. The Windows kernel, in turn, verifies every other component of the Windows startup process, including boot drivers, startup files, and your anti-malware product's early-launch anti-malware (ELAM) driver. -- Microsoft Learn [@ms-trusted-boot]

Trusted Boot is therefore the Windows-specific extension of the verifier into kernel mode. UEFI Secure Boot is platform-agnostic; it ships in db on every certified PC. Trusted Boot is the policy engine that reuses the firmware-side trust anchor and walks it forward into ntoskrnl.exe. The mechanism for how SiPolicy is parsed, how publisher rules are evaluated, and how the kernel's code-integrity state machine handles attempts to load binaries outside policy, lives in this article's App Identity sibling and is not redefined here [@app-identity-sibling].

There is a failure mode you can see coming. If the trusted boot manager itself is signed but vulnerable, the chain still validates, the policy still enforces, and the entire defence is bypassed. The signature is correct; the code path is what is wrong. Section 9 will show what happens when an older bootmgfw.efi revision contains a memory-map manipulation flaw that lets attacker-controlled data flow before the SiPolicy enforcement engine is up. That is the BlackLotus failure. For now, hold the framing: Trusted Boot's guarantee is "every kernel-mode component has a valid Microsoft signature." It is not "every Microsoft signature in this chain corresponds to a binary that is itself secure."

Verification can stop loading bad code. It cannot prove that good code was loaded. For that we need a parallel rail.

6. Measured Boot: SRTM, the TPM event log, and PCR 0-7+11 in order

Verification stops bad code from running. Measurement makes sure you can prove, after the fact, what code did run. The two rails do not protect against the same thing. This is the article's mechanism-densest section, and the place a few key terms have to be exactly right.

A boot-time chain of cryptographic measurements anchored in a Core Root of Trust for Measurement (CRTM): a code segment in the platform's flash that is implicitly trusted because it is immutable and is *measured by construction* into the TPM before any flexible code runs. SRTM extends one PCR per component as the chain unfolds, producing a tamper-evident log of exactly which firmware, boot manager, and kernel the platform launched. The measurement does not stop bad code; it records what code ran so a verifier can decide later.

The TPM extend primitive is the cryptographic core. The TPM never overwrites a PCR. When the platform asks the TPM to extend PCR N with a measurement m, the TPM does:

$$\mathrm{PCR}[N] := H\bigl(\mathrm{PCR}[N] ,\Vert, m\bigr)$$

where H is the bank's hash algorithm (SHA-1 on TPM 1.2; SHA-1 and SHA-256 banks both required by the TCG PC Client Platform Firmware Profile on TPM 2.0; SHA-384 and SHA3 banks optional and present on some newer parts) and || is byte concatenation [@syss-bitpixie]. The TPM 2.0 specification was finalised by the Trusted Computing Group on 9 April 2014 [@wp-tpm]. The mechanism guarantees that any later PCR value is a function of every prior measurement in the order it was extended -- you cannot rewind, and you cannot reorder. The TPM 2.0 PC Client profile specifies at least 24 PCRs, the first 16 of which are append-only and non-resettable until the platform itself is reset [@syss-bitpixie]. The full TPM extend mechanics are covered in this article's TPM sibling; we do not redefine them here [@tpm-sibling].

The PCR allocation, per the TCG PC Client Platform Firmware Profile, corroborated against the SySS Bitpixie writeup [@syss-bitpixie] and Microsoft Learn [@ms-secure-boot-process]:

PCR	Extended by	What it measures
0	CRTM, SEC, PEI	SRTM core firmware code (BIOS/UEFI)
1	PEI / DXE	Host platform configuration (CPU microcode, NVRAM settings)
2	DXE	UEFI driver and application code (option ROMs)
3	DXE	UEFI driver and application configuration / data
4	DXE / BDS	Hashes of all boot managers in the boot path; `bootmgfw.efi` lands here
5	BDS	Boot manager code config and data; GPT; boot attempts
6	DXE / OEM	Host platform manufacturer specific
7	DXE	State of Secure Boot: PK, KEK, db, dbx hashes; the `SecureBoot` variable; signing certificate of every loaded image
11	`bootmgfw.efi`	BitLocker access control: locked after VMK is obtained

sequenceDiagram participant CRTM participant SEC participant DXE participant BMGR as bootmgfw.efi participant TPM as TPM PCRs CRTM->>TPM: extend PCR[0] with SRTM hash SEC->>TPM: extend PCR[1] with platform config DXE->>TPM: extend PCR[2] with option-ROM code DXE->>TPM: extend PCR[7] with Secure Boot state DXE->>TPM: extend PCR[4] with bootmgfw.efi hash BMGR->>TPM: extend PCR[4] with winload.efi hash BMGR->>TPM: extend PCR[7] with signer cert of winload BMGR->>TPM: extend PCR[11] with BitLocker access flag

PCR[7] deserves a section of its own. On modern Windows, PCR[7] is the canonical seal target for BitLocker. A protector sealed to PCR[7] unwraps cleanly across firmware updates, microcode revisions, and option-ROM changes, because PCR[7] reflects only the Secure Boot state -- the keys in PK, KEK, db, dbx, the SecureBoot variable, and the signing certificates of loaded images. PCR[0..4] are too volatile for sealing on a real fleet because every BIOS update changes them. PCR[7] changes only when Secure Boot policy itself changes [@syss-bitpixie, @ms-system-guard]. The full BitLocker key hierarchy is covered in this article's BitLocker sibling [@bitlocker-sibling]; here we are placing PCR[7] in the chain.

Key idea: Verification stops bad code. Measurement records what code ran. Neither rail is sufficient alone. Modern Windows boot integrity needs both rails reaching the same place -- the kernel and the Secure Kernel -- before user-mode runtime defences take over.

The TCG event log makes the measurement chain useful for more than sealing. Every extend is logged through the TCG2 EFI Protocol with the hash, the algorithm, and a description of what was measured. A verifier (BitLocker locally; an attestation service remotely) can replay the log to recover which binary hashed to which PCR value, and -- if the replay does not match the live PCRs -- detect tampering. Microsoft Learn describes exactly that path: "the PC's firmware logs the boot process, and Windows can send it to a trusted server that can objectively assess the PC's health" [@ms-secure-boot-process].

There is a second root of measurement that sidesteps the firmware-trust regress entirely. DRTM -- Dynamic Root of Trust for Measurement -- is late-launched after firmware boot, via Intel TXT's GETSEC[SENTER] instruction or AMD's SKINIT. It resets PCR[17..22] at locality 4 and re-anchors a measurement chain in a vendor-controlled allowlistable module that does not depend on the DXE phase having been clean [@wp-txt, @ms-system-guard]. Microsoft documents the motivation in plain language:

There are thousands of PC vendors that produce many models with different UEFI BIOS versions. This creates an incredibly large number of SRTM measurements upon bootup. [@ms-system-guard]

The argument: SRTM measurements are platform-specific. An attestation service that wants to know whether a given device booted clean must hold an allowlist of SRTM measurements covering N OEMs * M models * K firmware revisions. The allowlist explodes; the blocklist is asymmetric in the attacker's favour. DRTM collapses the allowlist by defining one small, well-known late-launched measurement chain that the attestation service can recognise across every Secured-core PC.

A late-launched measurement chain that re-anchors trust *after* firmware boot, by using a CPU instruction (`GETSEC[SENTER]` on Intel, `SKINIT` on AMD) to reset a designated set of PCRs and execute a small, vendor-controlled measured launch module. DRTM is Microsoft's answer to the SRTM allowlist explosion. It powers System Guard Secure Launch, which Windows 10 1809 introduced; on supported hardware, the late-launched module brings up the hypervisor and Secure Kernel from a trust anchor that the firmware cannot influence.

The DRTM PCR allocation is parallel to SRTM but lives in a separate range, PCR[17..22], reset only by the late-launch event. Per the TCG PC Client Platform Firmware Profile (corroborated against the Wikipedia Trusted Execution Technology mirror, since TCG returns HTTP 403 to non-browser fetches) and Microsoft's System Guard documentation [@wp-txt, @ms-system-guard]:

PCR	Reset by	What it measures
17	`GETSEC[SENTER]` / `SKINIT` at locality 4	DRTM-event measurement and Launch Control Policy hash extended by the SINIT ACM (Intel TXT) or the Secure Loader block hash (`SKINIT` on AMD)
18	locality 4	Trusted-OS start-up code (the Measured Launch Environment itself)
19	locality 4	Trusted-OS measurement, e.g., OS configuration
20	locality 4	Trusted-OS measurement, e.g., OS kernel and other code
21	locality 4	Reserved for and defined by the Trusted OS
22	locality 4	Reserved for and defined by the Trusted OS

The reset semantics are the load-bearing detail. PCR[0..16] are append-only after platform reset; they cannot be cleared without rebooting the box. PCR[17..22] are different: they can be reset during runtime, but only by an atomic late-launch event. That asymmetry is what makes DRTM's anchor verifiable [@wp-txt, @syss-bitpixie].

The mechanism that enforces it is TPM locality. Locality is a side-channel attribute on every TPM command identifying which entity issued the request. Locality 0 is general OS and application traffic. Locality 4 is assertable only by the CPU itself, during the atomic GETSEC[SENTER] (Intel TXT) or SKINIT (AMD) sequence. The TPM accepts a Reset of PCR[17..22] only when the request arrives tagged with locality 4. No software running outside the late-launch instruction can forge that tag. That is the structural reason DRTM's late-launch is verifiable rather than forgeable [@wp-txt].

The asymmetry pays off for an attestation service. If a remote verifier reads PCR[17] and finds it equal to zero, DRTM did not happen on this boot. If it reads PCR[17] and finds it equal to the iterated extend $\mathrm{PCR}[17] := H\bigl(0 ,\Vert, H(\text{SINIT_ACM_hash} ,\Vert, \text{LCP_hash})\bigr)$ (or, more accurately, the chain of extends the SINIT ACM logged), a CPU-vendor-signed SINIT Authenticated Code Module seeded the chain, and the value is recomputable by the verifier from the published, signed SINIT ACM and the platform's Launch Control Policy [@wp-txt, @ms-system-guard]. The verifier's allowlist for DRTM measurements is bounded by the small set of CPU-vendor-signed measured-launch modules in circulation (SINIT ACMs on Intel TXT; the Secure Loader block measured directly by SKINIT on AMD) -- not by the cross-product of OEMs, models, and firmware revisions.

{` // Demonstrates the PCR extend formula: // PCR[N] := H( PCR[N] || measurement ) // Run it to see how PCR[4] would evolve as bootmgfw, winload, and ntoskrnl // hashes are extended one after another.

const sha256 = (buf) => createHash('sha256').update(buf).digest();

function extend(pcrHex, measurementHex) { const pcr = Buffer.from(pcrHex, 'hex'); const m = Buffer.from(measurementHex, 'hex'); return sha256(Buffer.concat([pcr, m])).toString('hex'); }

// Real PCRs start as 32 bytes of zero on a TPM 2.0 reset. let pcr4 = '00'.repeat(32);

const measurements = [ { name: 'bootmgfw.efi', hash: 'aa'.repeat(32) }, { name: 'winload.efi', hash: 'bb'.repeat(32) }, { name: 'ntoskrnl.exe', hash: 'cc'.repeat(32) }, ];

for (const m of measurements) { pcr4 = extend(pcr4, m.hash); console.log(`after ${m.name}: PCR[4] = ${pcr4.slice(0, 16)}...`); } `}

We now have two rails of trust ready to converge in the kernel. The next thing the kernel has to do is hand control to defenders that can keep the chain alive into runtime.

7. ELAM, the kernel, and the Secure Kernel bring-up: where the chain ends

Trusted Boot has signed every kernel-mode binary along the path. Then what? The chain still has to outlive the boot.

A specially-signed driver class introduced in Windows 8 (2012) that loads as the *first* boot-start driver -- ahead of every other boot-start driver -- and classifies each subsequent boot-start driver as *Good*, *Bad*, *Unknown*, or *BadButCritical* before the operating-system loader allows it to load [@ms-elam, @ms-elam-driver-requirements]. ELAM's classification influences whether Windows loads the driver. The ELAM driver itself is a Microsoft-signed binary in the `Early-Launch` service-start group and is itself measured into the SRTM chain; the user-mode anti-malware service that consumes its classification events runs as a Protected Process Light (PPL).

ELAM exists for a specific reason. The boot-start group includes anti-malware, device, and disk drivers that have to load before the rest of the operating system. Before Windows 8, those drivers all loaded in an undefined order, with no anti-malware product running yet. A bootkit that survived the kernel's signature check (or a driver that was signed but malicious) had a window in which nothing was watching. ELAM closed that window by ordering one driver -- a Microsoft-signed AM driver -- as the first boot-start driver, and giving it the right to classify those drivers as they loaded [@ms-elam]. ELAM is itself a boot-start driver; the Microsoft documentation specifies the INF requirement plainly: "An ELAM Driver advertises its group as 'Early-Launch'" [@ms-elam-driver-requirements]. The associated user-mode anti-malware service runs as a Protected Process Light (PPL), so even SYSTEM-privileged user-mode code cannot inject into it [@ms-elam, @app-identity-sibling].The classification surface ELAM exposes is the four-element set Good / Bad / Unknown / BadButCritical, enumerated in Microsoft's BDCB_CLASSIFICATION reference (ntddk.h) as BdCbClassificationKnownGoodImage, BdCbClassificationKnownBadImage, BdCbClassificationUnknownImage, and BdCbClassificationKnownBadImageBootCritical (the ELAM driver requirements page itself only enumerates three classes in prose; the fourth lives in the enum reference) [@ms-elam-driver-requirements]. The fourth category exists because some drivers are required for the system to boot; the AM driver's verdict on those is advisory rather than blocking. Defender ships the ELAM driver in Windows; Microsoft's interface allows third-party AM products to ship their own [@ms-elam].

The kernel itself does the next set of jobs. ntoskrnl.exe initialises memory protections and DMA defences. Kernel DMA Protection enables the IOMMU (Intel VT-d or AMD-Vi) so that PCIe peripherals either DMA only to memory their compatible driver has assigned (DMA-Remapping-compatible drivers, enumerated and started normally) or are blocked from starting and performing DMA entirely until an authorised user signs in or unlocks the screen (DMA-Remapping-incompatible drivers, the user-presence-gated default); both regimes block the drive-by-DMA pattern that targets arbitrary kernel memory and defend against malicious Thunderbolt peripherals [@ms-kernel-dma-protection]. The Driver Block List, enforced at code-integrity load time, refuses to load a recognised set of vulnerable signed drivers (the canonical example is gdrv2.sys); details in this article's App Identity sibling [@app-identity-sibling]. HVCI (Hypervisor-Enforced Code Integrity, also called Memory Integrity) is loaded inside the Secure Kernel and enforces W^X on all kernel-mode memory; details in the Secure Kernel sibling [@secure-kernel-sibling].

Then the Secure Kernel comes up. securekernel.exe and skci.dll initialise in Virtual Trust Level 1 -- a Hyper-V-managed isolation domain that the normal Windows kernel in VTL0 cannot read or write. The first Trustlet is LSAIso, the isolated process Credential Guard uses to hold NTLM hashes and Kerberos tickets out of reach of any kernel-mode attacker [@secure-kernel-sibling]. Control returns to the normal kernel; the user-mode tail begins.

flowchart TD WL["winload.efi"] --> NT["ntoskrnl.exe (VTL0)"] NT --> SK["securekernel.exe (VTL1)"] SK --> LSA["LSAIso (Credential Guard Trustlet)"] NT --> ELAM["ELAM driver"] ELAM --> BS["boot-start drivers (classified by ELAM)"] BS --> SMSS["smss.exe"] SMSS --> WI["wininit.exe"] WI --> WL2["winlogon.exe"] WL2 --> UI["userinit.exe -> explorer.exe"]

The user-mode tail is not security-cryptographic per se. SMSS (the Session Manager) loads system DLLs and starts the first Win32 subsystem session. wininit.exe initialises the LSA, the Service Control Manager, and the Local Session Manager. winlogon.exe paints the credential UI, calls into Windows Hello [@no-secrets-to-steal-sibling] if applicable, and authenticates the user. userinit.exe runs the logon scripts and launches explorer.exe [@ms-trusted-boot]. From the boot-integrity perspective, userinit is the moment the static-time guarantees of Trusted Boot end and the runtime defences -- Defender, EDR, attestation -- take over.

We have walked the chain end to end. The next question is: when did this chain actually start working?

8. The breakthroughs that made the chain land (2014-2024)

Secure Boot existed in 2012. Secure Boot worked (in the sense of defending most of what it claims to defend) only after roughly a decade of operational fixes that almost nobody outside Microsoft and a handful of OEMs ever wrote about. Four breakthroughs deserve naming. The matrix below collates them by layer fixed and fix-delivery vehicle before the prose treatments that follow.

#	Breakthrough	Year	Layer it fixed	Fix-delivery vehicle
B1	PCR[7] becomes the canonical BitLocker seal target	~2014-2016	Sealing brittleness; PCR[0..4] churn vs. firmware-revision cadence	Windows servicing + BitLocker policy default change [@syss-bitpixie, @ms-system-guard]
B2	Forced retirement of the Microsoft UEFI CA 2011	May 2023 - June 2026	Revocation gap (BlackLotus / Baton Drop)	KB5025885 / CVE-2023-24932 multi-year, opt-in dbx push and CA-2023 enrolment [@kb5025885]
B3	Secure Kernel becomes the launch destination	Win10 2015 - Win11 2021	"Kernel signed" is insufficient (TDL-4 lesson)	OS feature ship and WHCP requirement; HVCI / Driver Block List default-on by 2024 [@ms-trusted-boot, @secure-kernel-sibling]
B4	Pluton arrives as a Microsoft-firmware-authored RoT	Nov 2020 announcement; Q1 2022 first silicon	LPC/SPI bus-sniffing class against discrete TPMs; OEM patch-cadence latency for fTPM/PTT firmware	Windows-Update-delivered Pluton firmware (alongside UEFI capsule), Rust-based on 2024+ AMD/Intel parts [@ms-pluton]

The first row is operational, not architectural: PCR[7] becoming the canonical BitLocker seal target, somewhere between Windows 8.1 and Windows 10 1607 [@syss-bitpixie, @ms-system-guard]. Before PCR[7], BitLocker sealed against PCR[0..4]: firmware code, platform configuration, option ROMs, option-ROM configuration, and boot-manager hashes. Every UEFI update -- and on real fleets they happen monthly -- changed PCR[0..4] and forced BitLocker into recovery, which forced an IT staffer to find the recovery key, which was annoying enough to make people turn BitLocker off. PCR[7] sealing decoupled the BitLocker protector from the firmware-revision churn and made Measured Boot durable in practice. This is the operational fix that made Measured Boot actually worth running on a fleet of thousands of laptops with monthly UEFI capsule updates.

The second row is the forced retirement of the Microsoft UEFI CA 2011, which began in May 2023 with KB5025885 and CVE-2023-24932 and is on track to complete in late 2026 [@kb5025885]. This was the first serious dbx housekeeping in a decade. The relevant point: the fix had to be a programme, not a hotfix, because dbx is too small to handle a one-shot revocation of a CA-rooted set without bricking either some Linux dual-boots or some Windows machines. The CA-2023 rollout phases the work across four years.

The third was VBS and the Secure Kernel becoming the launch target the boot chain was actually defending. Without the Secure Kernel as a destination, Trusted Boot's guarantee ended at "the kernel is signed", which TDL-4 had already shown was insufficient -- a signed kernel is of limited use if the SYSTEM-privileged user-mode code that follows can rewrite kernel memory through a vulnerable signed driver. The Secure Kernel arrived in Windows 10 1507 (2015) and matured into its enforced-by-default form in Windows 11 (2021), at which point the chain had a hardware-isolated destination that even a SYSTEM-level attacker could not reach without a hypervisor exploit [@secure-kernel-sibling].

The fourth is still landing. Pluton, the cryptoprocessor whose firmware Microsoft (not the OEM) ships and updates, was announced in November 2020 and reached its first silicon -- AMD Ryzen 6000 -- in Q1 2022 [@ms-pluton]. Pluton is not yet ubiquitous, and its Secure Boot story is pending: as of 2026, Pluton ships as a TPM 2.0 implementation [@ms-pluton-as-tpm], not as a replacement verifier. Section 10 unpacks why the Microsoft-firmware-on-silicon-Microsoft-doesnt-own model matters more than the part numbers do.

These were the operational fixes. The architectural breaks they were responding to are the next section.

9. The boot-chain attacks that actually worked

There has never been a public Secure Boot attack that broke the cryptographic primitive. Every successful attack has exploited the same gap: between fixing a vulnerability and revoking the signed binaries that carried it. The CVE numbers change. The structure does not.

Scope note: LoJax (ESET, September 2018) was the first real-world UEFI rootkit deployed in the wild, but it operates at the SPI flash layer -- below Secure Boot's signature verification chain -- and is therefore outside the scope of this table. The table focuses on attacks on the Secure Boot signature-enforcement chain itself.

Attack	Year	Rung broken	Prerequisite	dbx state at disclosure	Fix path
ESPecter	2021	ESP-resident bootmgr replacement	Secure Boot disabled	n/a	Enable Secure Boot
FinSpy UEFI	2021	bootmgfw.efi replaced on ESP	Secure Boot disabled	n/a	Enable Secure Boot
BlackLotus / CVE-2022-21894 (Baton Drop)	2022-23	Signed-but-vulnerable older bootmgfw	Patched but unrevoked old binaries	Old binaries not revoked	dbx update via KB5025885
Bitpixie / CVE-2023-21563	2022-24	PXE soft-reboot leaks BitLocker VMK	TPM-only BitLocker; LAN + keyboard	n/a (no signature break)	Pre-boot PIN; KB5025885
LogoFAIL / CVE-2023-39539 et al.	2023	DXE-phase image-parser RCE	UEFI logo customisation accepting attacker BMP	n/a	OEM UEFI updates
Bootkitty	2024	Self-signed PoC; Secure Boot disabled or LogoFAIL	Linux target	n/a	Enable Secure Boot; patch LogoFAIL
WinRE / CVE-2024-20666 family	2024	Recovery Environment downgrade	TPM-only BitLocker; reachable WinRE	n/a	Servicing stack updates

ESPecter (ESET, October 2021) [@eset-especter] is the simplest case. It is an ESP-resident bootkit that bypasses Driver Signature Enforcement to load its own unsigned kernel driver -- but only on systems with Secure Boot disabled. ESPecter is in the table to make the category visible: the ESP is a writable FAT partition with no signature on the contents, and any malware that can write to the ESP and persuade the firmware to boot from a different bootmgfw path can win on a non-Secure-Boot system. The fix is to turn Secure Boot on.

FinSpy (Kaspersky, September 2021) [@kaspersky-finspy] is the same attack family carrying an actual nation-state-grade payload. Kaspersky's GReAT analysis names the mechanism plainly: "All machines infected with the UEFI bootkit had the Windows Boot Manager (bootmgfw.efi) replaced with a malicious one." The malicious bootmgfw injected code into winlogon.exe for persistence. Again, Secure Boot disabled was the precondition. FinSpy was the proof that the ESP-resident category had real-world tradecraft attached, not just academic interest.

BlackLotus (advertised on hacking forums from at least October 2022 [@eset-blacklotus]; ESET writeup 1 March 2023) is the case that defines the modern era [@eset-blacklotus, @wack0-batondrop]. BlackLotus does not disable Secure Boot. It chain-loads a legitimately-signed but vulnerable older bootmgfw.efi revision. The vulnerability is CVE-2022-21894, nicknamed Baton Drop: an older boot manager honoured a truncatememory setting that removed blocks of memory containing serialised data structures from the memory map. The Wack0 PoC repository describes the primitive: "Windows Boot Applications allow the truncatememory setting to remove blocks of memory containing 'persistent' ranges of serialised data from the memory map, leading to Secure Boot bypass" [@wack0-batondrop]. The chain: boot the legitimately-signed older bootmgfw; trigger Baton Drop; install a malicious SiPolicy that disables further checks; load an unsigned kernel driver; persistently disable HVCI, BitLocker, and Defender from below the trusted-boot horizon. Microsoft's incident-response guide for BlackLotus enumerates six classes of detection artefact: recently-written ESP files, staging directories, registry entries, event-log evidence of policy changes, network indicators, and BCD-log modifications [@ms-blacklotus-guidance]. The NSA and CISA published a joint mitigation guide on 22 June 2023 [@nsa-blacklotus]. ESET's epitaph is the article's recurring quote:

Exploitation is still possible as the affected, validly signed binaries have still not been added to the [UEFI revocation list]. -- Martin Smolar, ESET, March 2023 [@eset-blacklotus] sequenceDiagram participant Attacker participant ESP as EFI System Partition participant FW as UEFI firmware participant BMGR as bootmgfw (older signed) participant OS as Windows kernel Attacker->>ESP: drop legit but old signed bootmgfw FW->>BMGR: LoadImage() -- signature OK, hash NOT in dbx Attacker->>BMGR: trigger CVE-2022-21894 (truncatememory) BMGR->>BMGR: install malicious SiPolicy BMGR->>OS: load unsigned driver OS->>OS: disable HVCI, BitLocker, Defender

The "disables HVCI / BitLocker / Defender from below the trusted-boot horizon" framing in the caption is verbatim from the ESET disclosure and is reinforced by Microsoft's own incident-response guide [@eset-blacklotus, @ms-blacklotus-guidance].

Bitpixie / CVE-2023-21563 [@neodyme-bitpixie, @syss-bitpixie] is BlackLotus' twin in BitLocker space. The vulnerability was discovered by Rairii in August 2022; Thomas Lambertz of Neodyme published a public PoC at 38C3 in December 2024. The mechanism is a downgrade. The attacker boots the target machine into Windows' PXE network-recovery soft-reboot path, which loads a Microsoft-signed but older bootmgfw.efi revision. That older revision does not erase the BitLocker VMK from physical memory before the PXE soft-reboot hands off, leaving the VMK in RAM where the chained payload (a signed Linux PE or downgraded WinPE) can dump it. The combination of TPM-only BitLocker (no pre-boot PIN), a Microsoft-Account-defaulted Windows 11 install (which biases toward TPM-only encryption), and physical access to a network port and keyboard, decrypts the disk in minutes. Lambertz' framing: "All an attacker needs is the ability to plug in a LAN cable and keyboard to decrypt the disk" [@neodyme-bitpixie]. Bitpixie does not break Secure Boot. It exploits the same operational invariant -- old-but-signed binaries still validate -- in a different protection domain.

Note: TPM-only BitLocker is no longer a defensible default on Windows 11 once Bitpixie's PoC is public; the attack reduces to a LAN cable and a keyboard. See Section 11's Replace TPM-only BitLocker bullet for the pre-boot-factor fix list [@neodyme-bitpixie, @kb5025885].

Bootkitty (ESET, 27 November 2024) [@eset-bootkitty] closes a symmetry. Twelve years after Andrea Allievi's September 2012 PoC -- the first UEFI bootkit designed for Windows 8 [@theregister-allievi] -- Bootkitty is the first UEFI bootkit aimed at Linux. Bootkitty was uploaded as a self-signed PoC, so on systems with Secure Boot enabled, it does not load unless the attacker's certificate has been enrolled in the Machine Owner Key (MOK) list -- either by a user via mokutil (the ordinary Linux path), by a prior compromise enrolling the cert, or by chaining LogoFAIL (CVE-2023-40238) to inject a rogue MOK certificate from a malicious BMP, as Binarly demonstrated [@binarly-logofail-bootkitty]. Bootkitty patches kernel-image-integrity functions and pre-loads ELF binaries via init. ESET later updated the attribution: an analysis posted in early December 2024 traced the build to a Korean Best of the Best (BoB) student project. The structural lesson is platform-orthogonal -- Secure Boot's gaps live in the firmware and revocation surfaces, not in any one operating system.

The Allievi 2012 ITSEC PoC was *the first UEFI bootkit*, full stop -- a research artefact that demonstrated, on Windows 8, the same trick BootRoot had demonstrated on the Windows NT/2000/XP MBR seven years earlier. Twelve years later, Bootkitty is the first UEFI bootkit *for Linux*, also a research artefact. The arc closes a symmetry: UEFI's verifier is platform-agnostic, so its weaknesses are too. A LogoFAIL-style image-parser bug in DXE compromises Secure Boot whether the operating system above it is Windows or Ubuntu. The attacker community needed twelve years to apply the technique to the second platform, but only because the second platform's market share for boot-chain attacks was smaller, not because the verifier was structurally any safer.

LogoFAIL (Binarly REsearch, Black Hat EU 2023; CVE-2023-39539, CVE-2023-40238, CVE-2023-5058; advisory BRLY-2023-006) is the most architectural of the breaks because it compromises the verifier itself. The DXE phase parses a customisable boot logo image -- the OEM splash screen displayed on power-on -- and the parser is a piece of firmware code accepting an attacker-controlled input. Binarly demonstrated parser bugs in the BMP, GIF, JPEG, PCX, and TGA decoders shipped in reference code by all three major Independent BIOS Vendors -- AMI, Insyde, and Phoenix -- across roughly six hundred enterprise device models. A successful exploit gives the attacker code execution at the DXE phase, which is below Secure Boot's LoadImage() verifier. From DXE, the attacker can do whatever they want before the operating-system loader runs. Bootkitty later carried a LogoFAIL exploit (CVE-2023-40238) to inject a rogue MOK certificate from a malicious BMP, demonstrating the chain end to end [@binarly-logofail-bootkitty].

Finally, the WinRE / ReAgent.xml downgrade family (CVE-2024-20666 and successors) is the smaller cousin of the bigger story [@nvd-cve-2024-20666]. The Recovery Environment is a Windows partition with its own boot path; older WinRE images that contain unrevoked vulnerable bootmgr.efi revisions can be persuaded to mount the encrypted volume under attacker control. The attack does not break the Secure Boot chain; it routes around it. The point of including it in this catalogue: it is another instance of the dbx-revocation-by-hash limit. As long as an older signed binary exists and is reachable, Secure Boot's verifier will validate it.

Every attack here exploits the same operational invariant: the gap between patched and revoked is wide, and dbx is too small to close it. The next section examines whether anything can.

10. Theoretical limits, open problems, and the Pluton pivot

If every break has been operational, why has nobody fixed the operations? Because the operational bounds are themselves theoretical.

Six structural limits.

The verifier-of-verifiers regress. Secure Boot's verifier is firmware code that itself must be trusted. Boot Guard and AMD PSB push that root one rung deeper, into silicon ROM and OTP fuses [@ioactive-psb, @wp-txt]. Pluton arguably pushes it one rung deeper still, into silicon Microsoft directly updates. There is no software-only bottom turtle. Every architecture in the field has some layer that is trusted because there is no further layer to which trust can be deferred. The engineering question is which party owns that layer -- OEM, Intel, AMD, or Microsoft via Pluton -- and on whose update cadence the layer can be patched. IOActive's 2024 review of AMD PSB found that "various major vendors fail to" configure PSB correctly [@ioactive-psb], which is the kind of operational failure mode no cryptographic primitive can fix.

Why dbx revocation is hard. dbx is small, shared with Linux, vendor-implemented, and a brick-risk if mismanaged. The list stayed nearly empty for a decade until BlackLotus forced KB5025885's multi-year program [@nvd-cve-2023-24932]. SBAT (Secure Boot Advanced Targeting), the partial answer in the rhboot/shim project [@sbat-shim], revokes by generation number rather than by image hash. SBAT works by embedding a CSV-formatted vendor-and-component-version table in every shim-signed binary; when the firmware-side SBAT policy variable says "minimum acceptable shim generation is 4", every older shim hashes correctly but is refused for being too old. SBAT collapses tens of revocation events that would each consume hundreds of bytes of dbx into a single small metadata bump. The UEFI Forum has, since 2024, deferred to the canonical Microsoft-managed secureboot_objects GitHub repository [@ms-secureboot-objects] as the source of truth for KEK, db, and dbx contents.

A revocation scheme designed by the rhboot/shim project to address dbx capacity exhaustion. Instead of revoking each vulnerable signed binary by Authenticode hash (which consumes ~32 bytes of dbx per binary), SBAT revokes by *generation number*: each signed component carries a CSV-formatted version table; a small SBAT policy variable in firmware specifies the minimum generation accepted; older builds are refused without consuming dbx capacity. SBAT is the project's structural answer to the cohort-revocation problem the §4 Sidenote quantifies.

The SBAT generation-number scheme is also the model the Microsoft UEFI CA 2023 rollout extends across the wider Windows install base. KB5025885's mitigation strategy combines a small set of dbx hash revocations with a CA rotation, because no single mechanism by itself can revoke a decade's worth of signed bootloaders within the dbx storage budget [@kb5025885, @sbat-shim].

The signed-but-vulnerable problem. As long as Microsoft-signed bootloaders with known flaws exist on the install media of any production Windows installation, Secure Boot must revoke by hash, by SVN, by SiPolicy, or by certificate -- each with collateral damage. Hash revocation does not cover binaries the attacker has not yet seen. SVN revocation forces a rebuild of every signed binary across the install base. SiPolicy revocation depends on the SiPolicy update reaching every machine. CA rotation breaks PXE recovery, recovery USBs, dual-boot Linux, and custom WinPE images.

Supply chain at the firmware level. LogoFAIL, BMC-resident attacks against rack servers, Boot Guard key leaks (which OTP fuses cannot recover from), and OEM ME/PSP fuse misconfiguration are the categories Secure Boot cannot, by construction, defend against. The verifier sits above these layers; if these layers are compromised, the verifier is running on a base it cannot trust.

SRTM allowlist explosion. N OEMs, M models, K firmware revisions; the allowlist of "good SRTM measurements" explodes; the blocklist is asymmetric in the attacker's favour. DRTM late-launch is the only known way to collapse the allowlist. As Microsoft puts it, "DRTM lets the system freely boot into untrusted code initially, but shortly after launches the system into a trusted state" [@ms-system-guard].

Bus interception of discrete TPMs. A discrete TPM on the LPC or SPI bus can be sniffed by a physical attacker. This is what motivates the move to Pluton: the TPM moves on-die, the bus disappears, and the BitLocker VMK no longer crosses a sniffable wire [@tpm-sibling].

Key idea: Every public Secure Boot break has exploited the gap between patched and revoked, not the cryptographic primitive. The dbx revocation half-life is the article's invariant. Pluton closes the cadence gap on the verifier-update side. It does not close the gap between patched and revoked.

The Pluton pivot. Pluton's pitch, for the boot chain, is to re-anchor both the verification root (long term) and the measurement endpoint (today) in silicon Microsoft can patch [@ms-pluton, @ms-pluton-as-tpm]. Pluton implements TPM 2.0 on the CPU die, so the existing measurement chain plugs in unchanged. What changes is the firmware update cadence -- Pluton firmware ships through Windows Update as an additional channel alongside existing UEFI capsule updates; the key difference is that Microsoft authors and controls the firmware, and the Windows Update path enables Microsoft to deliver fixes independent of OEM release scheduling. The bus disappears: Pluton's interface is on-die--there is no external LPC or SPI bus crossing a package boundary that can be physically tapped, eliminating bus-sniffing as an attack class. And on 2024+ AMD and Intel parts, the Pluton firmware itself is written in Rust, addressing the memory-safety class of bugs that has historically dominated firmware CVEs [@ms-pluton].

flowchart LR subgraph Discrete["Discrete TPM"] CPU1["CPU"] -- LPC/SPI bus
(sniffable) --> dTPM["dTPM (Infineon, STM)"] end subgraph PlutonTopo["Pluton"] CPU2["CPU"] -- on-die mailbox --> PL["Pluton"] end The first reaction to "dbx is too small" is always: make it bigger. Three constraints stop that. First, dbx is implemented by hundreds of OEM firmware vendors against a UEFI specification floor; raising the floor would invalidate every shipped UEFI implementation. Second, dbx is shared between Windows, Linux, ESXi, and other operating systems, so growing it requires coordination across vendors with different incentives. Third -- and the real blocker -- the variable lives in NV-RAM with limited write cycles; a runaway revocation update can brick a board if the write fails partway through. The realistic fix is SBAT for image-version bumps and CA rotation for cohort-scale revocation. Both are partial. Pluton's design only makes sense against the contrast with the two endpoints of the design space.

At one endpoint sits Apple. Apple authors the silicon, the Boot ROM, the iBoot bootloader, the kernel, and the Secure Enclave Processor's sepOS firmware. The Apple Boot ROM holds the Apple Root certificate authority public key directly; it verifies iBoot before iBoot loads anything else; on older A-series parts an additional Low-Level Bootloader stage is verified by the Boot ROM and in turn loads and verifies iBoot [@apple-boot]. The Secure Enclave Processor is "a dedicated secure subsystem integrated into Apple SoC", isolated from the main processor and reachable only over a mailbox interface; sepOS is an L4 microkernel Apple ships and updates [@apple-sep]. Every stage of secure boot is signed by the same vendor that ships the operating system, and "secure boot begins in silicon and builds a chain of trust through software" [@apple-system]. The cadence is the iOS / iPadOS / macOS update cadence -- Apple-cadence -- because the same release pipeline ships everything from the Boot ROM update vehicle to the user-facing apps.

At the other endpoint sits Trusted Firmware-A on Armv7-A and Armv8-A platforms. TF-A is the reference secure-world software stack with a Secure Monitor at Exception Level 3 [@tfa-home]. The Trusted Board Boot feature implements Arm's TBBR-CLIENT specification (DEN0006D): "The Trusted Board Boot (TBB) feature prevents malicious firmware from running on the platform by authenticating all firmware images up to and including the normal world bootloader" [@tfa-tbb]. The chain runs BL1 -> BL2 -> BL31 / BL32 -> BL33, anchored on a ROTPK (Root of Trust Public Key) fused per silicon family. Because TBBR is a specification rather than a single shipping product, the actual signing keys and update cadence are the OEM's choice. The silicon vendor sets the fuse policy; the platform vendor signs the boot images; the operating-system vendor sees a verified BL33 handoff and trusts whatever ROTPK the silicon was fused with. There is no monoculture, and there is no single update cadence -- which is exactly what makes the security guarantees uneven across Arm devices in practice.

Pluton sits between Apple and TF-A. Microsoft authors the firmware (vendor-monopoly trust anchor) on silicon Microsoft does not own (AMD, Intel, Qualcomm fabricate it) [@ms-pluton]. The contrast is sharpest at the firmware-update cadence. Apple-cadence ships everything as one. OEM-UEFI-capsule-cadence is what discrete TPMs and PCH-isolated fTPM/PTT firmware are stuck with -- which is why a known-bad fTPM firmware can take months to land on every customer device after Microsoft posts a fix. Windows-Update-cadence is what Pluton offers: a Microsoft-authored firmware update riding the same channel that ships kernel patches. The same axis -- who owns the trust anchor and on whose schedule it ships -- is the axis on which the article's main Pluton argument turns.

There are honest residual limits. Pluton is a TPM, not a verification chain; the rest of Secure Boot still runs in DXE-phase firmware that LogoFAIL can compromise. Adoption is non-universal -- as of 2026, Pluton ships on Microsoft Surface, AMD Ryzen 6000-9000/AI series, a subset of Intel Core Ultra (200V / Series 3) parts, and Qualcomm Snapdragon 8cx Gen 3 / X parts powering Copilot+ PCs, with many enterprise PCs still on discrete TPMs [@ms-pluton]. The OEM still owns PK and the firmware update path outside Pluton, so the dbx-revocation problem and the OEM-key-leak problem are unaddressed by Pluton alone. Attestation infrastructure -- Device Health Attestation, Intune device-health Conditional Access -- is still maturing, and the policies that consume attestation outcomes are still hand-rolled per organisation.

Pluton closes the cadence gap. It does not close the gap between patched and revoked -- nothing yet does, and that is the next decade's problem.

11. Practical guide, FAQ, and where the chain goes next

This is the part you do today, on whatever Windows machine is in front of you, before this article ages another year.

Verify Secure Boot state. Open an elevated PowerShell prompt and run Confirm-SecureBootUEFI. The cmdlet returns True only if Secure Boot is currently enforcing. msinfo32 shows BIOS Mode (UEFI vs Legacy) and Secure Boot State on its System Summary page. Get-SecureBootPolicy reveals which Secure Boot policy GUID is in force; the default Microsoft policy on a healthy modern install is {77fa9abd-0359-4d32-bd60-28f4e78f784b} (the Microsoft owner GUID for the canonical KEK/db/dbx variables) [@ms-secureboot-objects]. Get-Tpm and tpmtool getdeviceinformation confirm that the TPM is present, owned, and ready [@ms-trusted-boot, @ms-secure-boot-process].

Read the TPM event log. tpmtool gatherlogs collects the WBCL files into a working folder you can inspect; Get-WinEvent -LogName Microsoft-Windows-TPM-WMI exposes the boot and provisioning events. On a healthy boot, the WBCL and the live PCR state replay to the same digest; mismatch is the attestation signal a remote verifier looks for.

The following one-liner gathers the basic state in elevated PowerShell:

"" |
  Select-Object @{n='SecureBoot'; e={ Confirm-SecureBootUEFI }},
                @{n='SBPolicy';  e={ (Get-SecureBootPolicy).Publisher }},
                @{n='TPMReady';  e={ (Get-Tpm).TpmReady }},
                @{n='UEFI/BIOS'; e={ (Get-CimInstance Win32_BIOS).SMBIOSBIOSVersion }} |
  Format-List

If SecureBoot is False, your boot chain has no firmware-side allowlist. If TPMReady is False, BitLocker is sealing to nothing -- recovery-key escrow is your only protector.

Verify your Windows UEFI CA 2023 enrolment. KB5025885 is a phased deployment; the relevant deployment phase is recorded in the registry under HKLM\SYSTEM\CurrentControlSet\Control\Secureboot\AvailableUpdates (or the equivalent CSV in the support article) [@kb5025885]. The current UEFI db can be inspected with Get-SecureBootUEFI db and Format-SecureBootUEFI. The 2023 CA's certificate has subject CN Windows UEFI CA 2023. If you do not see it in db and you are running a Windows install that has been online during 2025-2026, the deployment programme has not reached your device; consult the KB article for the next steps.

Note: The 2011 CA expires in late June 2026. After that, signed-but-old bootloaders that depend on the 2011 CA will not validate without explicit dbx housekeeping. If your install media is older than May 2023 and you have not run a full set of cumulative updates, you may end up with a machine that boots today but cannot boot a future Windows recovery image. The fix is to apply the KB5025885 updates and verify the 2023 CA is enrolled before that deadline [@kb5025885].

Enable DRTM / System Guard Secure Launch where the silicon supports it. The control surfaces are:

MDM CSP: DeviceGuard/ConfigureSystemGuardLaunch.
Group Policy: Computer Configuration > Administrative Templates > System > Device Guard > Turn On Virtualization Based Security > Secure Launch Configuration.
Registry: HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\SystemGuard\Enabled = 1.

Verify via msinfo32: under System Summary the Virtualization-based Security Services Configured / Running line should include Secure Launch [@ms-system-guard].

Replace TPM-only BitLocker. After Bitpixie, TPM-only BitLocker is no longer a defensible default. Add a pre-boot PIN (manage-bde -protectors -add C: -tpmAndPin), a USB key, or use device encryption with pre-boot authentication [@neodyme-bitpixie, @syss-bitpixie].

{` // JavaScript analogue of the PowerShell one-liner above. The real cmdlets // query NV variables and the TPM driver directly; this just shows the shape // of what a remote attestation collector would assemble.

function healthCheck(state) { return { secureBoot: state.secureBoot === true, sbPolicyGuid: state.policyGuid ?? 'unknown', tpmReady: state.tpmReady === true, pcr7: state.pcr7, caEnrolled: state.dbCerts.includes('Windows UEFI CA 2023'), notes: [] }; }

const live = healthCheck({ secureBoot: true, policyGuid: '{77fa9abd-0359-4d32-bd60-28f4e78f784b}', tpmReady: true, pcr7: '0xab4c...', dbCerts: ['Microsoft Windows Production PCA 2011', 'Microsoft Corporation UEFI CA 2011', 'Windows UEFI CA 2023'] });

console.log(live); `}

No. Secure Boot defends the boot chain. Ransomware targets user data after the operating system is up and the user is logged in, so it sees a signed Windows kernel exactly as it should. The defences against ransomware are runtime: Defender, EDR, Controlled Folder Access, and offline backups. Secure Boot is a precondition for trusting the operating system that hosts those runtime defences, but it is not a runtime defence itself. Yes, via the Microsoft-signed `shim`. The maintenance burden: keep `shim` current under the Windows UEFI CA 2023 rollout (`shim-signed`, `shim-x64`, `mokutil` packages on most distributions) or your Linux install will lose its boot path when older `shim` builds are revoked. See `The shim escape hatch` Aside in §4 for the underlying mechanism [@sbat-shim]. Yes. Pluton replaces the TPM, not the signature-verification chain. Pluton is a cryptoprocessor: it implements TPM 2.0 on the CPU die, holds keys, performs `extend` operations, and signs attestations [@ms-pluton-as-tpm]. Secure Boot is the firmware-side `LoadImage()` allowlist check. The two rails are complementary, not substitutes -- Pluton makes Measured Boot's endpoint better; it does not replace Secure Boot's verifier. The 2011 CA is being revoked. You need a `shim` signed by the 2023 CA. Update from your distribution's secure-boot package (the canonical names are `shim-signed`, `shim-x64`, or `mokutil`). If your installation media is older than May 2023 and you have not run distribution updates, expect breakage somewhere between your next dbx update and the June 2026 expiry [@kb5025885, @sbat-shim]. Not as a default. After Bitpixie / CVE-2023-21563, TPM-only BitLocker can be defeated with a LAN cable and a keyboard on a Windows 11 install with Microsoft Account defaults. See `Replace TPM-only BitLocker` in Section 11 for the fix list [@neodyme-bitpixie]. Trusted Boot is *signature-policy enforcement*: `bootmgfw.efi` and `winload.efi` refuse to load any kernel-mode binary whose Authenticode hash or signer is not in the trusted-boot policy, and the kernel-mode `ci.dll` continues that enforcement after handoff. Measured Boot is *hash-into-PCR recording*: every binary that loads is also extended into a TPM PCR so a verifier (BitLocker locally, an attestation service remotely) can later prove what code ran. Trusted Boot stops bad code; Measured Boot records what code ran. They run in parallel, not in sequence [@ms-trusted-boot, @ms-secure-boot-process].

The chain is longer than it has ever been. It is not yet long enough.

The next article in this series picks up where userinit ends. Once Windows is running, the question shifts from which code loaded? to what does this device look like to a remote verifier right now? Device Health Attestation, runtime measurement of the running kernel and Secure Kernel, and Conditional Access decisions tied to attestation outcomes are the runtime continuation of everything we walked through here. Pluton on the boot chain feeds Pluton-rooted attestation at runtime. Secure Boot ends at the desktop. The runtime chain begins there.