Parag Mali - tag: security-boundary

Windows Downdate: When the Update Itself Is the Attack

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

**Windows Update was designed to verify the integrity of files, not the monotonicity of versions.** In August 2024 at Black Hat USA, Alon Leviev (SafeBreach Labs) showed that an Administrator-context process can hijack Windows Update's own post-reboot servicing path by writing a single registry value, and use it to roll fully-patched Windows 11 system files back to historically vulnerable but legitimately Microsoft-signed versions [@safebreach-2024-aug]. Once the components VBS, HVCI, Credential Guard, and the Secure Kernel rely on have been replaced by their own past selves, the protections built on top of them quietly fail open. Microsoft has shipped a per-component revocation policy (`SkuSiPolicy.p7b` in KB5042562) and the substantive CVE-2024-38202 fix (KB5044284, October 2024), but maintains that the underlying primitive is not a security vulnerability because the Windows Security Servicing Criteria does not enumerate Administrator-to-kernel as a security boundary [@kb5042562; @kb5044284; @safebreach-2024-oct; @msft-servicing-criteria].

1. "Up to Date" Means Less Than It Says

Imagine a Windows 11 machine that has installed every cumulative update Microsoft has released this year. Settings says You're up to date. The Authenticode signature on every system DLL validates against Microsoft's root. HVCI is on. Credential Guard is on. VBS is on with the UEFI lock engaged. Disk Cleanup is empty. The Servicing Stack reports a healthy state. And somewhere in C:\Windows\System32, a two-year-old ci.dll is happily enforcing the code-integrity policy on a kernel that thinks it is current.

This machine was the demo on the SafeBreach blog in October 2024, and it is not a misconfiguration [@safebreach-2024-oct; @thehackernews-downdate]. The version on disk is 10.0.22621.1376, a build from before May 2024, when Microsoft patched Gabriel Landau's False File Immutability race in ci.dll [@elastic-ffi; @landau-itsnotasecurityboundary-repo]. The signature on that older build is legitimately Microsoft's. The hash matches a Microsoft-issued security catalog. Windows is perfectly happy to load it.

The Driver Signature Enforcement policy, the Authenticode chain, the catalog trust path, the WinSxS component store, and the post-reboot servicing engine were all built on the same shared assumption. Windows Downdate is what happens when you stop assuming it.

The author of that demo is Alon Leviev, a researcher then at SafeBreach Labs. On August 7, 2024 he presented Windows Downdate: Downgrade Attacks Using Windows Updates at Black Hat USA, followed by a more detailed walk-through at DEF CON 32 four days later [@safebreach-2024-aug; @bh-leviev-slides].

The technique he published does one thing and does it well: it takes Administrator-level access on a fully-patched Windows machine and converts it into Microsoft-signed historical code, running in the kernel, inside the Secure Kernel, inside the hypervisor, inside Credential Guard's isolated user-mode process. The OS does not notice. EDR does not notice. sfc /scannow does not notice. Settings reports the system as patched, because in every sense Windows can express, it is.

Leviev framed his goal as a four-property objective. The attack had to be undetectable to endpoint security, invisible to the user, persistent across future updates, and irreversible by repair tooling. The rest of this article will measure each piece of the attack against those four properties, but it is worth pausing on what they imply. They do not require defeating a single Microsoft mitigation. They require defeating all of them simultaneously, and Leviev's claim is that one registry write is enough.

Note: Every Microsoft mitigation since 2015 implicitly assumed that the OS being protected was the current one. None of them declared "the current one" as a security boundary.

That sentence is the spine of the article. To understand why nobody noticed for so long, we have to start somewhere unexpected: with a TLS bug from 2014.

2. A History of Downgrade Attacks (Before Windows Knew the Name)

If you can convince a system to do something old, you can convince it to do something dangerous. Bodo Möller, Thai Duong, and Krzysztof Kotowicz figured that out first, at least in the public literature. In October 2014 their This POODLE Bites advisory described an attack on the way browsers retry failed TLS handshakes [@google-poodle-pdf; @nvd-poodle]. A man-in-the-middle could induce a connection failure, the browser would silently retry at a lower protocol version, and the server would accept SSL 3.0, where a CBC padding oracle let the attacker decrypt session cookies one byte at a time. SSL 3.0 had been broken for years, but it remained in the negotiation envelope for backwards compatibility, and the negotiation envelope was where the protocol was weakest.

POODLE established the pattern. A protocol that retains legacy modes for compatibility creates a downgrade primitive unless the protocol explicitly enforces "highest version available."

Five months later, in March 2015, Karthikeyan Bhargavan and the miTLS team at INRIA found a near-identical pattern with FREAK: a stripped-down "export-grade" RSA cipher suite from the 1990s was still negotiable, and a fast attacker could factor the 512-bit key during the handshake [@freak-attack-site]. That same April, Möller and Adam Langley shipped RFC 7507 to standardise the first explicit in-band signal that a TLS client was deliberately falling back, so that the server could refuse [@rfc7507]. Three years after that, Eric Rescorla's TLS 1.3 (RFC 8446) baked downgrade resistance directly into the ServerHello.random nonce -- a structural fix, not a hint [@rfc8446]. The same period gave us SLOTH from Bhargavan and Gaétan Leurent: a transcript-collision attack on TLS, IKE, and SSH whose mitigation pushed TLS 1.3 to bind downgrade resistance into the transcript hash, making it impossible to rewrite the negotiation without breaking the integrity check [@sloth-ndss].

The Microsoft UEFI CA 2023 rollout began in February 2024 with a phased deployment that runs through 2026, replacing the Windows Production 2011 CA in firmware databases worldwide [@msft-uefi-ca-2023]. This rollout is the firmware-layer analogue of TLS 1.3's binding: each rotation is intended to retire trust in the older signer, but the rotation only matters if the consumer enforces it.

Meanwhile, four years before POODLE, a small group of NYU and Tor researchers wrote the academic-canonical paper on what happens when an attacker controls a software update repository instead of a network. Justin Samuel, Nick Mathewson, Justin Cappos, and Roger Dingledine published Survivable Key Compromise in Software Update Systems at ACM CCS 2010. They formalised three update-specific threats nobody had named before: rollback attacks (the repository serves an older, vulnerable copy of metadata), freeze attacks (the repository serves the same copy forever, preventing a client from ever learning about patches), and replay attacks (the repository serves a stale snapshot to a victim selected by network position) [@tuf-spec; @tuf-security].

The companion specification, now stewarded by the CNCF, says it plainly: "An attacker presents files to a software update system that are older than those the client has already seen. With no way to tell it is an obsolete version that may contain vulnerabilities, the user installs the software" [@tuf-security]. That is The Update Framework. Sigstore, Docker Notary, PyPI's PEP 458, and in-toto all inherit its threat model.

So by 2015 the academic and protocol communities had named the problem, given it a vocabulary, written a specification, and started shipping standards. Three years later the mobile world followed.

From protocols to operating systems

In August 2017, Android 8.0 shipped Verified Boot 2.0 (AVB), the first widely-deployed operating-system rollback defence. AVB stamps a rollback_index into each signed partition and stores per-slot maxima in TrustZone or in RPMB-backed storage; the bootloader refuses any image whose index is below the stored maximum [@aosp-avb]. The Android source page summarises the design goal: "AVB's key features include delegating updates for different partitions, a common footer format for signing partitions, and protection from attackers rolling back to a vulnerable version of Android" [@aosp-avb].

Three years after Android, Apple shipped the Signed System Volume on macOS Big Sur (November 2020). SSV seals the entire system volume into a single Merkle tree whose root is signed by Apple; on iOS and iPadOS the user cannot disable it [@apple-ssv]. The IETF Software Updates for Internet of Things working group standardised the same threat model in RFC 9019 (April 2021) for embedded firmware: "The firmware image is authenticated and integrity protected. Attempts to flash a maliciously modified firmware image or an image from an unknown, untrusted source must be prevented" [@rfc9019].

By 2022, every major mobile platform, every IoT firmware standard, and every modern image-based update system had named rollback as a primary threat and shipped a structural fix. Then came BlackLotus.

gantt title Downgrade attacks and defences, 2010-2024 dateFormat YYYY-MM axisFormat %Y section Protocol downgrade POODLE (SSL 3.0) :done, 2014-10, 60d FREAK (RSA_EXPORT) :done, 2015-03, 30d RFC 7507 (TLS Fallback SCSV):done, 2015-04, 30d SLOTH (transcript collision):done, 2016-01, 30d TLS 1.3 (RFC 8446) :done, 2018-08, 30d section Update systems TUF / CCS 2010 :done, 2010-10, 30d RFC 9019 (IETF SUIT) :done, 2021-04, 30d section OS rollback defence Android AVB 2.0 :done, 2017-08, 30d Apple Sealed System Volume :done, 2020-11, 30d section Windows precedent BlackLotus in the wild :crit, 2022-10, 150d BlackLotus public :crit, 2023-03, 30d Windows Downdate disclosure :crit, 2024-08, 30d

The Windows precedent

Martin Smolar's BlackLotus UEFI Bootkit: Myth Confirmed arrived in March 2023, and it was the direct precedent Leviev would cite. BlackLotus was a UEFI bootkit that had been on sale on hacking forums since October 2022 [@welivesecurity-blacklotus]. Its key trick was to ship its own copy of a legitimately Microsoft-signed but vulnerable bootmgfw.efi -- specifically, a build still affected by CVE-2022-21894, the "Baton Drop" Secure Boot bypass that Microsoft had patched in January 2022.

Smolar wrote: "Although the vulnerability was fixed in Microsoft's January 2022 update, its exploitation is still possible as the affected, validly signed binaries have still not been added to the UEFI revocation list. BlackLotus takes advantage of this, bringing its own copies of legitimate -- but vulnerable -- binaries to the system in order to exploit the vulnerability" [@welivesecurity-blacklotus]. The NSA shipped a BlackLotus Mitigation Guide in June 2023 [@nsa-blacklotus-guide]; Microsoft began the laborious process of populating dbx, the UEFI Secure Boot revocation list, with the offending hashes [@uefi-revocation-list].

The point that anchors this section: Microsoft did patch downgrade extensively at the firmware and boot-loader layer in response to BlackLotus. They updated dbx. They rolled the UEFI Production CA in February 2024 [@msft-uefi-ca-2023]. The architectural lesson -- if you have not declared which version of a signed binary is current, your signature is not enough -- had been internalised at the bottom of the stack. Whether anybody closed the same gap at the OS-component layer was a question only Leviev seems to have asked.

3. The Vista Bargain -- Component-Based Servicing and the Fourth Principal

If you sit down at a Windows 11 machine right now, open an elevated PowerShell as a local Administrator, and try to overwrite C:\Windows\System32\ntoskrnl.exe, Windows will refuse. The error is Access is denied. That is unexpected, because you are an Administrator, and on every Windows since NT 3.1 Administrators have been the highest principal on the box. The reason has a date.

In November 2006, Windows Vista shipped a fourth Windows security principal: NT SERVICE\TrustedInstaller. Its well-known SID is the long numeric string S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464, and its job is to be the only identity permitted to write into most of System32 [@safebreach-2024-aug; @ms-learn-servicing-stack-updates]. Administrators can take ownership of files there and grant themselves write access, but the default ACL excludes them. The change accompanied two other Vista deliverables that, taken together, became the contract that Windows servicing has obeyed for two decades.

A Windows security principal introduced in Vista that owns most of the system files under `C:\Windows\System32`. Its job is to mediate component-based servicing operations: when you install a Windows Update, the work runs in TrustedInstaller's context, not the Administrator's. Direct writes to TrustedInstaller-owned files by other principals (including Administrators) are denied at the ACL.

The first deliverable was Component-Based Servicing (CBS), the replacement for the self-extracting Update.exe installers that had defined patch delivery from Windows NT 4.0 through Windows XP. CBS reshaped a Windows update from "a small executable that scribbles into your system directory" into "a manifest-driven transaction over a versioned component store." The second deliverable was WinSxS -- the side-by-side store under C:\Windows\WinSxS\ that holds every version of every CBS-managed component the system has ever installed [@safebreach-2024-aug; @ms-learn-servicing-stack-updates].

The Windows servicing architecture introduced in Vista that replaced self-extracting update installers. A CBS package contains a Microsoft-signed security catalog (`.cat`) whose hashes cover the package's manifest files (`.mum`, `.manifest`). The manifests, transitively trusted via the signed catalog, describe which files belong to which component and how those files should be installed. CBS operations are mediated by the TrustedInstaller service.

The third deliverable was the manifest-and-catalog signing model that knit the first two together. A CBS package contains a security catalog (.cat) signed directly by Microsoft. The catalog's hashes cover the package's manifest files (.mum and .manifest); the manifests, in turn, name the package's payload files and describe their installation. The manifest files are not signed individually, but their hashes appear in the signed catalog, so they are transitively trusted [@safebreach-2024-aug]. The payload files are also not individually signed; their hashes appear in the manifests, which are themselves catalog-covered. The chain of custody runs catalog -> manifest -> payload, and at the root is Microsoft's signing key.

What this gives you is an elegant, declarative contract for system integrity. Microsoft signs a catalog. The catalog vouches for a manifest. The manifest vouches for a file. The file lands on disk. TrustedInstaller is the only principal allowed to write it, and TrustedInstaller has its own protected service that runs the install transactionally.

Note: Signed file + TrustedInstaller-only write = system integrity. Microsoft built the Vista servicing stack around this contract in 2006-2007. The contract is true on its face. It is also silent about one thing: which version of a signed file is allowed to land on disk.

That silence is older than CBS. It traces back through the related 2005-2007 file-integrity work. Kernel Patch Protection, marketed as PatchGuard, shipped in x64 Windows Server 2003 SP1 in March 2005 and watches for tampering with running kernel structures [@msft-patchguard-advisory]. KMCS, the Kernel-Mode Code Signing Walkthrough Microsoft published in July 2007, defined the Driver Signature Enforcement policy that kernel-mode code on x64 Vista and later had to satisfy [@kmcs-walkthrough; @msdocs-kmcs-policy].

The Microsoft Learn descendant page is more direct: "The kernel-mode driver signing policy for 64-bit versions of Windows Vista and later versions of Windows specifies that a kernel-mode driver must be signed for the driver to load" [@msdocs-driver-signing]. Each of these primitives bound trust to a Microsoft signature. None of them bound trust to a Microsoft-asserted version.

This was reasonable in 2007. Update.exe had been the threat: tampering with system files mid-flight, racing the installer, replacing a DLL while the system was rebooting. Vista's reply was to put the entire operation behind a principal that admins could not impersonate. The threat model said "the attacker is some Administrator-context tool that will try to overwrite system files." The reply said "only TrustedInstaller writes system files, and TrustedInstaller will only write files the catalog says are theirs." It was a complete answer to the question that had been asked.

It was an incomplete answer to a question nobody asked: which version of which file goes through that door, and is "which version" a property anyone actually checks?

Eighteen years later, the answer was: no, "which version" is not a property anyone checks at the file layer. The catalog says "this file belongs to this package." It does not say "this file is the current member of this component family."

The Vista bargain locked the door. It signed the keys. It named a single person who could turn the lock. What it did not do -- and was not designed to do -- was care whether the box behind the door was on the latest update or on the build from two years ago. That decision would land on three later generations of Windows integrity walls, and none of them caught it.

4. Generation by Generation -- The Walls That Weren't Walls of Time

Between 2007 and 2022, Microsoft built four more integrity walls on top of the Vista bargain. Each one was a generation forward. None of them added the dimension Windows Downdate needed them to add.

Generation 1: Kernel-Mode Code Signing / DSE (Vista x64, 2007)

The first wall. The kernel refused to load any driver that was not Authenticode-signed by a Microsoft-cross-signed CA [@kmcs-walkthrough; @msdocs-kmcs-policy; @msdocs-driver-signing]. DSE was enforced at driver load time by the kernel loader; non-signed drivers failed to load with an unmissable error. This was the first architectural assertion that "a Microsoft-signed binary is the unit of trust at the kernel boundary."

What it said: a kernel driver must be signed by Microsoft.

What it did not say: which Microsoft-signed driver. The catalog-trust model treats any Microsoft-signed version of a file as equally legitimate. That assumption is the one Windows Downdate exploits seventeen years later: signature validity is preserved across version rollback, because the catalog of the older version is still a Microsoft-signed catalog and the hash chain still resolves.

Generation 2: UEFI Secure Boot (Windows 8, 2012)

The second wall pushed the same idea down into firmware. The platform firmware refused to load a boot manager that was not signed by a key in the UEFI signature database (db), and refused to load any binary whose hash was in the forbidden-signature database (dbx) [@welivesecurity-blacklotus; @msft-uefi-ca-2023]. For the first time, Windows had a version-specific revocation primitive at the platform layer: dbx could enumerate specific binaries known to be unsafe.

But dbx had two problems. The first was rollout latency: BlackLotus demonstrated in 2023 that vulnerable, validly-signed bootmgfw.efi binaries were still trusted by firmware a full year after Microsoft patched them in source [@welivesecurity-blacklotus]. The second was scope: dbx covered boot-time binaries, not run-time OS components. A revocation primitive that only fires before ntoskrnl.exe loads is not a defence against rolling back ntoskrnl.exe itself.

The Microsoft UEFI CA 2023 rollout is on a multi-year phased schedule starting February 13, 2024 and running into 2026 [@msft-uefi-ca-2023]. The phased rollout exists precisely because retiring trust in older signers is slow and operationally risky -- the same shape of problem that SkuSiPolicy.p7b now faces at the OS layer.

Generation 3: VBS + HVCI + Credential Guard (Windows 10, 2015)

The third wall changed the threat model itself. Virtualization-Based Security used the Hyper-V hypervisor to create a higher-privilege isolation domain, called Virtual Trust Level 1 (VTL1), beneath the NT kernel's normal VTL0. Microsoft's own documentation states the new assumption directly: "VBS uses hardware virtualization and the Windows hypervisor to create an isolated virtual environment that becomes the root of trust of the OS that assumes the kernel can be compromised" [@msdocs-vbs].

Virtual Trust Level 1 is the higher-privilege half of the Hyper-V-managed split that VBS introduces. VTL0 holds the normal NT kernel and user-mode processes. VTL1 holds the Secure Kernel (`securekernel.exe`), the kernel-mode Code Integrity policy enforcement (`skci.dll`), and Isolated User Mode trustlets such as the LSA isolation process (`LsaIso.exe`). VTL0 cannot read VTL1 memory; transitions between the two go through a narrow set of hypercalls.

HVCI moved the kernel-mode code integrity check inside VTL1: a malicious kernel could no longer disable the check, because the check ran in a memory space the kernel could not write [@msdocs-vbs-hvci]. Credential Guard moved LSA secrets into an Isolated User Mode trustlet, LsaIso.exe, so a kernel-level attacker could not directly read NTLM hashes or Kerberos TGTs from LSASS memory [@msdocs-credguard]. The explicit, written threat model said: assume the NT kernel can be compromised, and provide a higher-privilege isolation domain for security-critical state.

That sentence is doing all the work. It says VBS is a defence against a compromised kernel, which means VBS is a defence against an attacker who has reached kernel code execution by any means. And one of the ways an attacker reaches kernel code execution -- one of the obvious ones, on a single-user Windows machine -- is to be an Administrator. The whole point of VBS was that Administrator code execution is the threat. That fact will matter again in section eight.

The unsaid assumption in 2015 was that VTL1 components -- securekernel.exe, skci.dll, LsaIso.exe, and the hypervisor binaries hvix64.exe and hvax64.exe -- were loaded from on-disk files using CBS+catalog trust, and that CBS+catalog trust was version-agnostic. Microsoft was building a higher trust boundary, but the integrity check for the binaries that lived on the other side of that boundary still ran through the Vista contract.

Generation 4: The Microsoft Vulnerable Driver Blocklist (2020 opt-in, default-on November 2022)

The fourth wall finally introduced a generic version-revocation primitive for kernel-loaded code. The Microsoft Vulnerable Driver Blocklist was the answer to a class of attacks that had emerged in the 2010s: bring-your-own-vulnerable-driver, where a malware loader installed a legitimately-signed, third-party driver with a known kernel exploit and used it as a bridge to kernel execution [@msft-driver-blocklist-blog]. The blocklist's Microsoft Learn page is direct about scope: the policy targets non-Microsoft-developed drivers across the Windows software environment, and since the Windows 11 2022 update the blocklist is enabled by default for all devices [@msdocs-driver-blocklist].

Read that sentence again, slowly. Non-Microsoft-developed drivers. The blocklist is the right mechanism -- a Microsoft-signed list of hashes of known-vulnerable signed binaries that the kernel refuses to load -- but it is pointed at the wrong inventory. First-party Microsoft binaries, including the very VBS components VBS depends on, are out of scope. The same Microsoft team that built the only generic version-revocation primitive Windows ships chose, by policy, not to apply it to themselves.

flowchart TD A["Vista CBS + TrustedInstaller (2007)
Signed file + restricted writer"] --> B["KMCS / DSE (2007)
Kernel rejects unsigned drivers"] B --> C["UEFI Secure Boot (2012)
Firmware rejects unsigned boot binaries
dbx revokes specific hashes"] C --> D["VBS + HVCI + Credential Guard (2015)
VTL1 isolation, assume-kernel-compromised
CI policy enforced inside Secure Kernel"] D --> E["Vulnerable Driver Blocklist (2020-2022)
Microsoft-signed hash revocation
Third-party drivers only"] E --> F["Gap: First-party VBS components
still load by catalog signature alone"] The shape of `dbx` and the shape of `SkuSiPolicy.p7b` are the same: a Microsoft-signed list of hashes a loader refuses. `dbx` lives in UEFI firmware variables and is consulted by the platform boot manager. `SkuSiPolicy.p7b` is a Microsoft-signed Code Integrity policy that lives in the EFI System Partition (when the opt-in UEFI lock is applied) or in the boot session (the default-enabled variant), and is consulted by the Windows kernel loader. The conceptual lineage runs *firmware-layer hash revocation in 2012 -> OS-layer hash revocation in 2024*. The intervening twelve years were spent assuming the OS layer did not need it.

By 2022, Microsoft had built every primitive a Downdate defence would have used. A Microsoft-signed hash-revocation list (the Driver Blocklist). A firmware-rooted enforcement chain (Secure Boot + dbx). A hypervisor-isolated integrity check (HVCI inside VTL1). What had not been built was a first-party hash-revocation list -- one that named the historical versions of ci.dll, ntoskrnl.exe, securekernel.exe, hvix64.exe, and LsaIso.exe and refused to load them.

Key idea: Recall the thesis from §1: every Microsoft mitigation since 2015 implicitly assumes the OS being protected is the current one. The mechanism for declaring it -- hash revocation -- had existed since 2012, but it was always pointed at somebody else's code. The Driver Blocklist proves Microsoft can ship a first-party hash-revocation list. It just had not been pointed inward.

So Microsoft had built every primitive it needed by 2022: a hash-revocation list, a firmware-rooted enforcement chain, a hypervisor-isolated integrity check. Why, in 2024, is a fully-patched Windows 11 machine still capable of loading a 2022 ci.dll?

5. The Breakthrough -- Where the Integrity Boundary Moves

Leviev started with a simple specification. He wanted a downgrade that satisfied four properties [@safebreach-2024-aug]:

Undetectable by endpoint security tooling.
Invisible in winver, Settings, and the system's own self-reported state.
Persistent across future Windows Update installations.
Irreversible by sfc /scannow, DISM /Online /Cleanup-Image /RestoreHealth, and other repair tooling.

The "undetectable" requirement disqualified almost every obvious approach. Disabling Authenticode checking is detectable. Replacing the catalog signing root is detectable. Booting into Safe Mode and overwriting files is detectable. Loading a vulnerable driver is detectable. Whatever the attack ended up looking like, it had to run through the legitimate Windows Update path, because that path is the one EDR is least suspicious of.

Reading Leviev's August 2024 SafeBreach write-up is a study in patient state-machine reverse engineering. He had to discover the architecture of CBS, where TrustedInstaller fits into it, how pending.xml action lists are written, where the integrity boundary of each phase lies, and which registry values are TrustedInstaller-protected versus which are merely Administrator-protected. Most of the answer turned out to be hidden in plain sight.

The Windows Update state machine

A Windows Update flows through a small state machine, and Leviev's contribution is to draw it precisely.

A client process in Administrator context calls into the Windows Update Agent COM interfaces. Those interfaces transfer the update folder -- a Microsoft-signed package containing a .cat, several .mum and .manifest files, and the new payload binaries -- to a TrustedInstaller-context server (TrustedInstaller.exe). The server verifies the catalog signature, walks the manifests, and constructs an action list. The action list is the work order that explains exactly which files will be renamed, hardlinked, deleted, or written, and which registry values will be set, when the system reboots. Microsoft stores it in a file called pending.xml under a TrustedInstaller-only directory (C:\Windows\WinSxS\pending.xml) [@safebreach-2024-aug; @ms-learn-servicing-stack-updates].

On reboot, before the user logs in, a small program named poqexec.exe reads pending.xml and applies it. POQ stands for "Primitive Operations Queue." The program is the post-reboot transactional engine that performs work the running OS could not safely do while it was running (such as overwriting ntoskrnl.exe).

The post-reboot primitive-operations-queue executor. Reads the action list (`pending.xml`) at next boot, before normal services start, and applies its verbs -- hardlinks, file moves, registry writes -- to complete the previous boot's pending update operations. `poqexec.exe` has no notion of "current version" versus "older version"; it executes whatever action list its configuration points it at.

So far, nothing is wrong. The catalog is signed. The manifests are catalog-covered. The action list lives in a TrustedInstaller-only directory. The executor that consumes it is part of the Windows servicing stack. The chain of custody runs from Microsoft's signing key through to the on-disk binaries the executor produces.

The action list integrity model -- and where it breaks

The catch is this. The pointer to pending.xml is not in a TrustedInstaller-only registry key. It is in HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide\Configuration\PoqexecCmdline. The DACL on that value allows Administrator write. There is a parallel value, HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\PendingXmlIdentifier, that carries a nonce binding the action list to the boot-session identity; that value is also Administrator-writable [@safebreach-2024-aug; @splunk-downdate-detection].

The XML work order that describes the file and registry operations a Windows Update will apply at next boot. It uses a small set of POQ verbs (`HardlinkFile`, `MoveFile`, `CreateFile`, `SetFileInformation`, `DeleteFile`, `CreateDirectory`, `CreateKey`, `SetKeyValue`, `SetKeySecurity`, `DeleteKeyValue`, `DeleteKey`). The default copy lives in a TrustedInstaller-only directory. Which copy `poqexec.exe` parses on next boot is determined by an Administrator-writable registry value, `PoqexecCmdline`.

The Administrator who initiates an update can choose which action list poqexec.exe parses. The integrity check on the update folder happened at the start of the transaction, in a different phase, with TrustedInstaller doing the parsing. Once the action list has been produced, the chain of custody depends on Windows believing that pending.xml came from a Microsoft-signed package. The mechanism by which Windows believes that is a registry value that an Administrator can rewrite.

Differential update files are not individually signed -- their hashes appear in the catalog-covered manifest, so they inherit catalog trust by reference. This is a perfectly sensible design if you also assert that the manifest you are using is the manifest for the latest update, which Windows does not.

That is the architectural error, and it has a name. The integrity boundary moves between phases of the update. The update folder is verified pre-action-list-creation. The action list is verified by being in a TrustedInstaller directory. But the pointer to the action list is in admin-writable territory. The same identity (Administrator) that can legitimately initiate an update can choose which action list poqexec.exe parses, and poqexec.exe was never built to ask "is this list the one I made?"

sequenceDiagram participant Admin as Admin process participant TI as TrustedInstaller participant Reg as Registry (PoqexecCmdline) participant POQ as poqexec.exe (next boot) participant FS as System32 files Note over Admin,FS: Legitimate Windows Update Admin->>TI: Submit signed update folder over COM TI->>TI: Verify catalog and manifests TI->>FS: Write pending.xml to WinSxS (TI-only) TI->>Reg: Set PoqexecCmdline to default pending.xml Admin->>Admin: Reboot POQ->>Reg: Read PoqexecCmdline POQ->>FS: Read default pending.xml POQ->>FS: Apply verbs, install new files Note over Admin,FS: Windows Downdate Admin->>FS: Write crafted pending.xml to attacker dir Admin->>Reg: Overwrite PoqexecCmdline to crafted path Admin->>Reg: Overwrite PendingXmlIdentifier to matching nonce Admin->>Admin: Reboot POQ->>Reg: Read PoqexecCmdline (now attacker path) POQ->>FS: Read crafted pending.xml POQ->>FS: Hardlink older Microsoft-signed binaries over current ones

Once you can choose which action list poqexec.exe parses, and poqexec.exe was never built to ask "is this list the one I made?", the consequences write themselves. The crafted pending.xml can issue any verb the executor supports. It can hardlink an older ci.dll over the current one. It can hardlink an older ntoskrnl.exe over the current one. It can hardlink an older securekernel.exe over the current one. The hashes of those older files appear in the Microsoft-signed catalogs of their original packages, which are still on disk in WinSxS. Every signature the kernel loader and the Secure Kernel will ever check resolves to a Microsoft key.

Key idea: The bug is structural: the integrity boundary moves between phases of the update. The catalog signature verifies one phase; the directory ACL verifies the next; the registry pointer crosses the boundary in the wrong direction. The fix has to declare a new boundary that does not move.

6. The Downdate Attack End-to-End

What does python windows_downdate.py --config-xml downgrade.xml actually do on the wire? The tool's GitHub repository, SafeBreach-Labs/WindowsDowndate, ships a documented schema and eight example chains, from a generic ItsNotASecurityBoundary-Patch-Downgrade to a fully-formed VBS-UEFI-Locks-Bypass [@windowsdowndate-repo]. Read alongside Leviev's blog, the procedure is, in machine terms, embarrassingly small. Eight steps.

6.1 The attack sequence

Parse the config XML. Each <UpdateFile source="..." destination="..."/> element names one file to downgrade. If the source file does not exist locally, the tool retrieves the base version from the WinSxS component store [@windowsdowndate-repo].
Build a crafted pending.xml. For each target, emit a <HardlinkFile> verb that creates a hardlink from the older file's location to the current file's location, plus the other POQ verbs needed to set ACLs, register the new file with the component store, and update the on-disk manifest hash where needed.
Deposit pending.xml in an attacker-writable directory. The Administrator does not need TrustedInstaller-write privilege to do this; the tool stores the crafted action list outside the TrustedInstaller-only directories.
Compute a matching PendingXmlIdentifier nonce. This is the value that poqexec.exe cross-checks against the action list at parse time.
Write the two registry values. PoqexecCmdline is set to point at the attacker's pending.xml. PendingXmlIdentifier is set to the nonce computed in step 4.
Trigger a reboot. This can be a graceful shutdown /r /t 0 or any reboot-causing event.
At next boot, poqexec.exe reads PoqexecCmdline and parses the attacker pending.xml. It applies the verbs in order. The current ci.dll is replaced (via hardlink) with 10.0.22621.1376. The current ntoskrnl.exe is replaced with whichever version the operator chose. The current securekernel.exe is replaced. The current hvix64.exe is replaced. The current LsaIso.exe is replaced.
Persistence and irreversibility. Two further verbs replace poqexec.exe with a patched copy that NOPs future updates, and replace sfc.exe with a patched copy that does not flag the downgraded files. Leviev's claim in the SafeBreach blog is that poqexec.exe and sfc.exe are not Authenticode-signed in the affected builds, so substituting modified versions does not require a code-signing bypass [@safebreach-2024-aug].

The full set of POQ XML verbs that poqexec.exe understands, taken from Leviev's documentation: HardlinkFile, MoveFile, CreateFile, SetFileInformation, DeleteFile, CreateDirectory, CreateKey, SetKeyValue, SetKeySecurity, DeleteKeyValue, and DeleteKey. The verb that does most of the work in a Downdate is HardlinkFile, because it lets the attacker replace a file in System32 without ever calling WriteFile against a TrustedInstaller-owned path.

flowchart TD A["Operator config XML
UpdateFile source dest pairs"] --> B["Fetch source files
from WinSxS or attacker storage"] B --> C["Emit crafted pending.xml
HardlinkFile + ACL verbs"] C --> D["Write pending.xml
to attacker dir"] D --> E["Compute PendingXmlIdentifier nonce"] E --> F["Write PoqexecCmdline registry value
point at crafted pending.xml"] F --> G["Write PendingXmlIdentifier"] G --> H["Reboot"] H --> I["poqexec.exe reads PoqexecCmdline"] I --> J["Apply HardlinkFile verbs:
ci.dll, ntoskrnl.exe, securekernel.exe,
hvix64.exe, LsaIso.exe replaced"] J --> K["Optional: patch poqexec.exe NOP
and sfc.exe to NOP"] K --> L["System boots: every signature valid,
every component historic"]

6.2 What got downgraded

Each Downdate target is a different layer of the threat model.

Afd.sys is the Ancillary Function Driver -- a kernel-mode networking driver. In the Black Hat USA demo, Leviev paired the Downdate of Afd.sys with CVE-2023-21768 to demonstrate Administrator-to-kernel code execution on a fully patched Windows 11 system [@windowsdowndate-repo].

ntoskrnl.exe is the NT kernel image itself. Downgrade to a build with a public elevation-of-privilege chain and the resulting kernel is still Microsoft-signed but is also still vulnerable.

securekernel.exe is the VTL1 Secure Kernel. It is the keystone of VBS: the Secure Kernel is what HVCI and Credential Guard rely on for isolation. Replace it with an older build that contains a kernel-side bug, and every protection that runs in VTL1 is now running on top of compromised infrastructure.

hvix64.exe and hvax64.exe are the Intel and AMD Hyper-V hypervisor binaries. Downgrade the hypervisor and the entire VBS trust root has moved beneath you.

LsaIso.exe is the Credential Guard Isolated User Mode trustlet [@msdocs-credguard]. It holds the LSA secrets that Credential Guard protects. An older LsaIso.exe is, by Microsoft's own threat model, a known-bad binary running inside the security-feature-of-record.

ci.dll is the keystone of the October 2024 follow-up. The kernel-mode Code Integrity module enforces DSE: it is the gate that asks "is this driver signed?" Roll it back to 10.0.22621.1376 and Gabriel Landau's False File Immutability bypass works again on a fully-patched Windows 11.

6.3 Bypassing VBS UEFI locks without physical access

Microsoft's "VBS UEFI lock" feature, intended to be the strongest configuration of VBS, copies the VBS configuration registry settings into a UEFI non-volatile, boot-services-only variable called VbsPolicy [@msdocs-vbs-hvci]. Once set, the lock survives reboots, reinstalls, and most ordinary attacks against the registry, because the firmware re-applies it on every boot. Before Windows Downdate, the canonical advice for the highest-security configuration was: turn on VBS with the UEFI lock. The lock was the moat.

Leviev's framing of what he showed was direct: "to my knowledge, this is the first time VBS's UEFI locks have been bypassed without physical access" [@safebreach-2024-aug].

To my knowledge, this is the first time VBS's UEFI locks have been bypassed without physical access. -- Alon Leviev, SafeBreach Labs, August 2024 [@safebreach-2024-aug]

The mechanism is the cleanest possible illustration of the architectural error. The UEFI lock pins configuration (VbsPolicy). It does not pin implementation (securekernel.exe, hvix64.exe, LsaIso.exe, ci.dll). Downgrade the implementation and the configuration is still happy. From Windows's point of view, VBS is on, the lock is engaged, the configuration variable is in firmware, everything checks out. The components doing the actual work are simply not the ones the configuration was checked against. Nobody asked it to check.

6.4 ItsNotASecurityBoundary, revived

On May 14, 2024, Microsoft shipped KB5037771 for Windows 11 22H2 and 23H2 [@landau-itsnotasecurityboundary-repo]. The preview build had landed on April 23, 2024 as KB5036980. The fix closed a False File Immutability TOCTOU on ci.dll that Gabriel Landau of Elastic Security Labs had disclosed in February [@elastic-ffi]. Landau's exploit, which he titled ItsNotASecurityBoundary, used the FFI race to swap an Authenticode catalog mid-verification, getting an unsigned driver loaded with Microsoft's blessing.

A bug class identified by Gabriel Landau (Elastic Security Labs) in 2024. Windows treats files mapped as `SEC_IMAGE` as immutable while a view exists, but the kernel does not always honor that immutability across separate reads of the same file. A verifier that reads the file, then re-reads it after a working-set flush, can be served different bytes the second time. On Authenticode catalogs, this becomes a TOCTOU race that lets the attacker swap the catalog between the verifier's read and the loader's load.

The October 26, 2024 SafeBreach follow-up [@safebreach-2024-oct], titled An Update on Windows Downdate, combined the two. It used Windows Downdate to roll ci.dll back to the pre-May build (10.0.22621.1376) and re-enabled the FFI bypass on a fully patched Windows 11 23H2 machine [@thehackernews-downdate]. The Hacker News confirmed the chain: "The DSE bypass is achieved by making use of the downgrade tool to replace the 'ci.dll' library with an older version (10.0.22621.1376) to undo the patch put in place by Microsoft" [@thehackernews-downdate]. The name of Landau's exploit became, in retrospect, the most pointed commentary on Microsoft's servicing policy that anyone has written.

ItsNotASecurityBoundary's name is an homage to MSRC's policy that 'Administrator-to-kernel is not a security boundary.' -- Gabriel Landau, Elastic Security Labs [@landau-itsnotasecurityboundary-repo]

6.5 What Microsoft shipped, and when

Microsoft's response unfolded over roughly eleven months. Here is the cadence, anchored to the canonical KB and CVE pages.

Date	Event	Source
Aug 7, 2024	CVE-2024-21302 and CVE-2024-38202 published; Black Hat USA 2024 talk	[@nvd-cve-2024-21302; @nvd-cve-2024-38202; @safebreach-2024-aug]
Aug 11, 2024	DEF CON 32 talk	[@safebreach-2024-aug]
Aug 13, 2024	KB5042562: opt-in `SkuSiPolicy.p7b` revocation policy with optional UEFI lock, plus default-enabled boot-session CI policy on Win10 1507+	[@kb5042562]
Oct 8, 2024	KB5044284: substantive code fix for CVE-2024-38202 in Windows 11 24H2 (OS Build 26100.2033); per-SKU equivalents on the same date	[@kb5044284; @nvd-cve-2024-38202]
Oct 26, 2024	SafeBreach follow-up "An Update on Windows Downdate" -- ItsNotASecurityBoundary revival via `ci.dll` downgrade	[@safebreach-2024-oct; @thehackernews-downdate]
Jul 8-10, 2025	CVE-2024-21302 mitigations completed across Windows 10 1507, 1607, 1809, Windows Server 2016, and Windows Server 2018	[@nvd-cve-2024-21302]

KB5042562 is the more interesting of the two artifacts. It introduces two mechanisms.

The first is an opt-in SkuSiPolicy.p7b policy: an administrator copies the Microsoft-signed .p7b file from %windir%\System32\SecureBootUpdates\ to the EFI System Partition's \EFI\Microsoft\Boot\ directory; on boot, Windows reads the policy and refuses to load any binary whose version is listed as revoked [@kb5042562].

The second is a default-enabled boot-session CI policy that ships to every Windows 10 1507+ device and, per the KB, "will be loaded during boot and the enforcement of this policy will prevent rollback of VBS system files during that boot session" [@kb5042562]. On Windows 11 24H2 and Server 2022/23H2, DRTM (Dynamic Root of Trust for Measurement) binds the VBS-protected encryption keys to the policy version, so a downgraded boot does not unseal the keys.

A Microsoft-signed Code Integrity policy file shipped in KB5042562 that lists revoked versions of VBS system files (`securekernel.exe`, `hvix64.exe`/`hvax64.exe`, `LsaIso.exe`, `ci.dll`, and others). When deployed to the EFI System Partition with the optional UEFI lock, it survives reformats and binds version-revocation enforcement to a Microsoft signature in firmware-stored state. A trusted-launch mechanism, available on Windows 11 24H2 and Server 2022/23H2, that uses CPU SMI / SKINIT instructions to establish a measured execution environment after the OS has begun booting. In KB5042562's context, DRTM binds Virtual Secure Mode's protected encryption keys to the version of the active CI policy, so a rolled-back boot session cannot unseal the keys.

{` // Simulate the construction of the WindowsDowndate config XML for a ci.dll downgrade. // This shows the structure the tool consumes, not the action list it emits. // Nothing here writes to a real system or runs a real attack.

const configEntries = [ { source: "C:\\Windows\\WinSxS\\amd64_microsoft-windows-codeintegrity_31bf3856ad364e35_10.0.22621.1376_none\\ci.dll", destination: "C:\\Windows\\System32\\ci.dll", component: "Code Integrity (kernel DSE enforcement)", targetVersion: "10.0.22621.1376", rationale: "Pre-May-2024 build, before the FFI/ItsNotASecurityBoundary fix" } ];

function buildConfigXml(entries) { const lines = ['', '']; for (const e of entries) { lines.push( ' <UpdateFile source="' + e.source + '"', ' destination="' + e.destination + '" />' ); } lines.push(''); return lines.join('\n'); }

const xml = buildConfigXml(configEntries); console.log(xml);

// What the tool would emit into the crafted pending.xml on next boot: console.log('\nResulting POQ verb (illustrative):'); console.log(' <HardlinkFile source="' + configEntries[0].source + '"'); console.log(' destination="' + configEntries[0].destination + '" />'); `}

The mitigation does not patch the primitive. It patches the components Leviev demonstrated against, one at a time, with a Microsoft-signed list of historical hashes. That choice is deliberate, and the next two sections are about why.

7. Competing Approaches -- How Other Platforms Closed the Gap

Android made the opposite design decision in 2017. Apple did so in 2020. The TLS working group did so in 2018. The IETF SUIT working group did so in 2021. By the time Leviev presented at Black Hat USA 2024, every major adjacent platform had treated rollback as a primary threat and shipped a structural fix. Windows was the outlier.

Android Verified Boot 2.0: per-partition rollback indices

AVB stamps a 64-bit rollback_index into the signed footer of each partition. On each successful boot of a partition image, the bootloader updates a per-slot stored maximum in TrustZone or in eMMC Replay Protected Memory Block storage. On the next boot, the bootloader refuses any image whose rollback_index is below the stored maximum [@aosp-avb; @avb-readme].

The check happens in firmware, before the kernel loads. There is no opt-in. There is no enterprise toggle. There is no operational risk warning about the lock being irreversible. The rollback index is a structural part of the trust architecture, not a policy file that ships through the same update channel that an attacker would compromise.

Apple Sealed System Volume: a Merkle seal over the OS

Apple's Signed System Volume (Big Sur, November 2020) takes the Android approach and pushes it further. SSV computes a SHA-256 hash of every file in the system volume, builds a Merkle tree over those hashes, and signs the root with an Apple key [@apple-ssv].

The Apple Platform Security guide describes it precisely: "SSV features a kernel mechanism that verifies the integrity of the system content at runtime and rejects any data -- code and noncode -- without a valid cryptographic signature from Apple" and "Each SSV SHA-256 hash is stored in the main file-system metadata tree, which is itself hashed. Because each node of the tree recursively verifies the integrity of the hashes of its children -- similar to a binary hash (Merkle) tree -- the root node's hash value, called a seal, encompasses every byte of data in the SSV" [@apple-ssv]. On iOS and iPadOS, "Users aren't allowed to turn off the protection of a signed system volume" [@apple-ssv]. The check is structural and mandatory.

IETF SUIT: rollback in the IoT firmware threat model

RFC 9019 standardised the firmware-update threat model the IoT industry now treats as canonical. The document does not mince words: "The firmware image is authenticated and integrity protected. Attempts to flash a maliciously modified firmware image or an image from an unknown, untrusted source must be prevented" [@rfc9019]. The Update Framework's CCS 2010 paper and its present-day specification share the same vocabulary: "Rollback attacks. An attacker presents files to a software update system that are older than those the client has already seen. With no way to tell it is an obsolete version that may contain vulnerabilities, the user installs the software" [@tuf-security]. TUF, now a CNCF graduated project, is the academic-canonical reference [@tuf-spec].

TLS 1.3: rollback baked into the protocol

The protocol world's answer is in RFC 8446 section 4.1.3 [@rfc8446]. A TLS 1.3 server that detects a downgrade attempt -- a client that supports TLS 1.3 but is being routed through a man-in-the-middle that strips it back to TLS 1.2 -- writes a specific magic constant into the last 8 bytes of ServerHello.random. A genuine TLS 1.3 client, completing the handshake, checks those bytes and aborts the connection if the magic is present. The integrity check is bound into the transcript hash, so a network attacker cannot rewrite it without breaking the handshake. The mitigation is part of the protocol, not a guideline operators can apply.

flowchart LR A["Android AVB 2.0"] --> A1["TrustZone / RPMB
per-slot rollback_index"] B["Apple SSV"] --> B1["Secure Enclave / T2
signed Merkle root"] C["IETF SUIT (RFC 9019)"] --> C1["Spec-defined
device-side state"] D["TLS 1.3 (RFC 8446)"] --> D1["In-protocol
ServerHello.random bytes"] E["TUF"] --> E1["Snapshot + timestamp roles
monotonic version numbers"] F["Windows SkuSiPolicy.p7b"] --> F1["EFI System Partition
opt-in UEFI lock"] F --> F2["Boot session only
default-enabled CI policy"]

The differences between these designs are not cosmetic. They are decisions about where the rollback state lives and who is authorised to write it. Read the table below row by row and the contrast is uncomfortable.

Dimension	Windows `SkuSiPolicy.p7b`	Android AVB 2.0	Apple SSV	IETF SUIT	TUF	TLS 1.3
Initiation	Opt-in (strong) / default-enabled (boot-session)	Mandatory	Mandatory	Adopter-defined	Adopter-defined	Mandatory
Protected unit	Per-component hash list	Per-partition signed image	Whole system volume	Per-firmware image	Per-package metadata	Per-handshake nonce
Version-state storage	EFI System Partition + optional UEFI lock	TEE / RPMB rollback index	Secure Enclave / signed root	Device-side spec	Snapshot + timestamp roles	In-protocol
Hardware-root binding	Optional via UEFI lock; DRTM on Win11 24H2+	TrustZone / RPMB	Apple silicon / T2	Spec abstract	Spec abstract	None required
Coverage gaps	First-party components not in the policy still load	Slots not covered by AVB	None on iOS/iPadOS; SSV must remain on macOS	Adopter-defined	Out-of-spec metadata roles	None within scope

Key idea: Every other major platform's modern update architecture treats rollback as a primary threat baked into the trust architecture. Windows treats it as a privilege-boundary question -- and the answer it picked, "Administrator-to-kernel is not a security boundary," excludes the most common attacker.

If Apple, Google, and the IETF have all figured out the answer, why hasn't Microsoft?

8. Theoretical Limits -- "Admin-to-Kernel Is Not a Boundary"

Microsoft's answer is that they have no need to.

8.1 The Microsoft position

The Windows Security Servicing Criteria is the public document where Microsoft enumerates which Windows interfaces it treats as security boundaries [@msft-servicing-criteria]. The document defines the concept: a security boundary provides a logical separation between the code and data of security domains with different levels of trust, with kernel-mode versus user-mode as the canonical example.

It then asks the servicing test: "Does the vulnerability violate the goal or intent of a security boundary or a security feature?" [@msft-servicing-criteria]. If the answer is yes, Microsoft commits to ship a security update. If the answer is no, the issue can still be fixed -- in a quality update, in a refactor, in a future feature -- but it does not get a CVE and the standardised servicing cadence does not apply.

The boundaries Microsoft enumerates in that document include network boundaries (machine-to-machine), kernel-mode-to-user-mode separation, hypervisor-to-VM separation, and several others. Administrator-to-kernel is not on the list. By the document's own logic, an Administrator who reaches kernel code execution has not crossed a boundary, because the document does not declare a boundary there for them to cross. That is the policy position Landau's exploit title was named after.

The two CVEs that were assigned are the boundary-crossing parts of the chain.

CVE-2024-21302 is the Secure Kernel Mode Elevation of Privilege (VTL0-to-VTL1) -- a downgrade-induced compromise of securekernel.exe does cross a defined boundary, because the kernel-to-Secure-Kernel separation is on the list [@nvd-cve-2024-21302]. CVE-2024-38202 is the basic-user-to-Administrator elevation via the restore-point flow -- a basic user induced into authorising a system restore can be parked into a state that triggers a downgrade, which crosses the user-to-admin boundary [@nvd-cve-2024-38202]. Both CVEs were assigned and patched from August 7, 2024 onward; CVE-2024-38202 received its substantive code fix on October 8, 2024 [@kb5044284; @nvd-cve-2024-38202].

Note: Microsoft assigned CVE-2024-21302 (Secure Kernel EoP) and CVE-2024-38202 (basic-user-induced restore-point EoP) on August 7, 2024 and patched both. What Microsoft has not committed to fix as a security vulnerability is the underlying Downdate primitive itself -- the Administrator-context modification of PoqexecCmdline. Per the Servicing Criteria, that primitive does not cross a declared boundary [@safebreach-2024-oct; @msft-servicing-criteria].

Leviev quoted Microsoft's framing of this distinction in his October 2024 follow-up:

CVE-2024-21302 was patched because it crossed a defined security boundary, the Windows Update takeover which was reported to Microsoft as well, has remained unpatched, as it did not cross a defined security boundary. Gaining kernel code execution as an Administrator is not considered as crossing a security boundary (not a vulnerability). -- Alon Leviev, summarising the Microsoft position, October 2024 [@safebreach-2024-oct]

8.2 The internal tension

That position has an obvious problem. The VBS documentation says VBS assumes the kernel can be compromised [@msdocs-vbs]. The Secure Kernel exists because the NT kernel is, in the threat model VBS publishes, untrusted. If the kernel is the attacker, then anyone who can compromise the kernel is the attacker VBS is designed to mitigate. On a single-user Windows machine, the obvious path to kernel compromise is to be an Administrator and load a vulnerable signed driver, or to be an Administrator and exploit a kernel race, or to be an Administrator and downgrade ci.dll.

Leviev makes the point directly in the same blog post: "the reason VBS was created is because the kernel is assumed compromised, and there was a need for a secure place to implement security features" [@safebreach-2024-aug]. If the kernel is assumed compromised in VBS's threat model, then the Administrator who can compromise the kernel is precisely the attacker VBS was built to mitigate -- which makes Microsoft's servicing-criteria position and VBS's threat model load-bearing on opposite sides of the same boundary.

This is the article's most argumentative sentence: the position is not a security decision (the primitive is not a vulnerability) but a resourcing decision (we will not CVE the primitive, but we will harden it). The per-component SkuSiPolicy.p7b rollout, the default-enabled boot-session CI policy, DRTM on Win11 24H2+, and the multi-quarter cleanup across Windows 10 1507 through Windows Server 2018 are exactly what one would expect from an organisation patching a class one component at a time, while declining to declare the class.

8.3 What a hardened position would look like

The fixes are not conceptually hard. Microsoft could:

Sign poqexec.exe and sfc.exe with HVCI-enforced integrity. That removes the persistence and irreversibility steps of the chain.
Move PoqexecCmdline under a TrustedInstaller-only DACL with a UEFI-bound mirror. That removes the registry pivot.
Introduce a monotonic update-generation counter in the TPM, bound to a transcript hash of the cumulative-update history, consulted by the boot manager and the Secure Kernel. That is the architectural fix -- the version of the answer Apple and Android shipped.

The current SkuSiPolicy.p7b mechanism is the first step on the third path. It is per-component and opt-in for the strong variant, but the conceptual shape is right: a Microsoft-signed list of historical hashes, consulted by the kernel loader, with a UEFI-bound anchor for the strong configuration [@kb5042562]. The work is real, and it is well-executed within the constraints Microsoft has set itself. The question is whether the constraints will give. Whether the policy will eventually cover every Microsoft-shipped binary with a known EoP. Whether the strong variant will become the default. Whether Administrator-to-kernel will be declared a security boundary in the published criteria.

The one VBS configuration that Leviev has not bypassed is the "Mandatory" flag (the `HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Mandatory` REG_DWORD value, mirrored into the `VbsPolicy` UEFI variable on next boot). When set in combination with the UEFI lock, the flag causes boot failure if any VBS-protected binary is corrupted -- so the "invalidate `securekernel.exe`, boot without VBS, downgrade `ci.dll`" trick that defeats the ordinary UEFI lock no longer works. Leviev's October 2024 follow-up is blunt: *"I have not found a way around this"* [@safebreach-2024-oct].

The catches are operational. The Mandatory flag is not set by default when the UEFI lock is enabled; it has to be set manually. Once set with the UEFI lock, the VBS configuration cannot be modified -- the lock must be deleted via SecConfig.efi, the flag set, and the lock re-enabled.

There is also a real boot-reliability risk: any update that corrupts a VBS-protected binary on a Mandatory-flagged machine will brick the boot, with no error displayed beyond the firmware silently moving to the next boot option [@safebreach-2024-oct; @kb5042562]. Microsoft documented the Mandatory flag in September 2024, after Leviev's findings, but has not made it the default [@msdocs-vbs-hvci]. Few production machines run with it.

These are not conceptually hard. They are organisationally hard, because they require Microsoft to ship a new security boundary, declared as such, after declining to do so for nearly two decades.

9. Open Problems -- What the August 2024 Cadence Left Open

If you are reading this in 2026, the parts of Windows Downdate that Microsoft chose to call vulnerabilities have been patched. The parts they chose not to call vulnerabilities are exactly as exploitable today as they were on August 7, 2024.

The general primitive remains. The Administrator-context modification of PoqexecCmdline is, by Microsoft's stated policy, intentionally unpatched [@safebreach-2024-oct]. Every cumulative update Microsoft ships will continue to flow through the same servicing-stack path that Leviev hijacked, because that path is the path everything else depends on. The fix has to come from somewhere else.

Components not yet in the revocation policy

SkuSiPolicy.p7b covers the VBS-protected components Leviev demonstrated against -- securekernel.exe, hvix64.exe, hvax64.exe, LsaIso.exe, ci.dll, and others. It does not cover every Microsoft-shipped DLL or driver with a public EoP history [@kb5042562]. Each Microsoft binary outside the policy that has a known kernel-relevant vulnerability is, in principle, a Downdate target. The inventory is open. Microsoft does not publish "the set of historical hashes of ntoskrnl.exe that we consider unsafe to load" -- and the absence of that list is the absence of the version-monotonicity boundary at scale.

Hot Patching as a parallel servicing surface

Hot Patching is the Windows servicing variant that applies code-level updates to running processes without a reboot. It reached general availability on Windows Server 2022 Datacenter: Azure Edition in February 2022 (Server Core) and July 2023 (Desktop Experience), and on Windows 11 Enterprise 24H2 in April 2025 via Microsoft Autopatch and Intune [@msdocs-hotpatch-server; @msdocs-hotpatch-win11].

Its threat model is forward-delta application: how do we apply a code patch to a running binary safely? It does not consider rollback prevention as a separate concern. Whether the hot-patch path admits its own rollback primitive -- whether you can roll back a hot patch, restoring the older code into the running process, by abusing the hot-patch infrastructure the same way Downdate abuses CBS -- is an open question that nobody has publicly answered.

WinRE as adjacent surface

Leviev's Black Hat USA 2025 talk, with Netanel Ben Simon of Microsoft's MORSE team, did not extend Downdate. It went sideways. BitUnlocker: Leveraging Windows Recovery to Extract BitLocker Secrets targeted the Windows Recovery Environment, demonstrating four CVEs that together permit a physical-access attacker to extract BitLocker keys from the WinRE servicing surface [@itnews-bitunlocker; @infocondb-defcon33-bitunlocker]. The bugs were patched in the July 2025 Patch Tuesday cumulative updates.

The corrected CVE-to-file mapping, per the iTnews coverage and the independent garatc/BitUnlocker proof-of-concept, is: - **CVE-2025-48804**: SDI / `Boot.sdi` parsing -- the boot-manager downgrade keystone that garatc's PoC chains to access BitLocker-encrypted disks in under five minutes on fully patched Windows 11 [@itnews-bitunlocker; @garatc-bitunlocker]. - **CVE-2025-48800**: Offline Scanning -- abuses the legitimately-signed time-travel debugger `tttracer.exe` to proxy-execute `cmd.exe` against BitLocker-encrypted volumes without triggering the recovery-mode re-lock. - **CVE-2025-48003**: `SetupPlatform.exe` and the Shift+F10 path via `ReAgent.xml`. - **CVE-2025-48818**: BCD-store complete-chain exploit.

BitUnlocker is not a continuation of Windows Downdate. It is the same meta-pattern in a different servicing surface: WinRE is a servicing path inherited from a less hostile era, and Microsoft is now patching its threat model. The shape of the work is identical.

Alon Leviev now works on the Microsoft Offensive Research and Security Engineering (MORSE) team alongside Netanel Ben Simon. Leviev's institutional follow-up to Downdate is therefore happening from inside Microsoft -- a notable signal about how seriously Microsoft is taking the surface even as it declines to declare the boundary [@infocondb-defcon33-bitunlocker].

Two revocation policies, one product

The Microsoft Vulnerable Driver Blocklist (for third-party kernel code) and SkuSiPolicy.p7b (for first-party VBS system files) are two separate revocation policies that ship on different cadences, in different formats, and through different update channels. The Driver Blocklist updates quarterly and via monthly cumulative updates [@msdocs-driver-blocklist]; SkuSiPolicy.p7b is shipped as part of major mitigation rollouts and is opt-in for the strong variant [@kb5042562]. Whether Microsoft unifies them -- whether the eventual answer is one unified hash-revocation policy covering all kernel-loaded code, Microsoft-shipped or not -- is an open architectural question.

Linux desktop coverage

The image-based Linux distributions (Fedora Silverblue, Ubuntu Core, openSUSE MicroOS) have all moved toward AVB-style or SSV-style architectures. Classical dpkg- and rpm-based distributions have not. Apt's package authentication is signature-based and largely version-aware via the Release file's Date and Valid-Until headers, but the security guarantees rely on a trusted repository and a TUF-style snapshot role that most distributions do not yet ship. The Windows lesson generalises: any update mechanism that can write into a higher-privilege domain has to enforce version monotonicity in the same domain that performs the write.

There is one open problem the rest depend on. Will Microsoft declare a version-monotonicity security boundary? The answer to that question -- whether by a future revision of the Windows Security Servicing Criteria, by a default-on Mandatory flag, by an exhaustive first-party Driver Block List equivalent, or by something nobody has prototyped yet -- is the substantive resolution of the story. The August 2024 patches were not it.

10. A Practical Guide for Defenders, Detection Engineers, and System Designers

Three audiences, three concrete tracks.

10.1 Defenders

If you operate Windows 10 or 11 endpoints, the first thing to do is apply the cumulative updates that contain the substantive code fix for CVE-2024-38202. On Windows 11 24H2, that is KB5044284 (October 8, 2024, OS Build 26100.2033) [@kb5044284]. On older SKUs, the equivalent updates landed on the same date or in the multi-quarter sweep that completed July 8-10, 2025 across Windows 10 1507, 1607, 1809, Server 2016, and Server 2018 [@nvd-cve-2024-21302]. Apply them in your normal patch ring with no special handling.

The second thing to do is keep HVCI / memory integrity enabled so the default-enabled boot-session CI policy and the Vulnerable Driver Blocklist both fire [@msdocs-driver-blocklist; @msdocs-vbs-hvci]. On Windows 11 22H2 and later, both are on by default. On older SKUs, they are not, and the gap is meaningful.

The third thing -- the one that requires care -- is to consider deploying SkuSiPolicy.p7b with the optional UEFI lock where your operational risk tolerance allows.

Note: Microsoft's own KB is unambiguous about what happens if you apply the UEFI lock and later try to roll back: "If the UEFI lock is applied and the policy is removed or replaced with an older version, the Windows boot manager will not start, and the device will not start... Even reformatting the disk will not remove the UEFI lock of the mitigation if it has already been applied" [@kb5042562]. Disable Secure Boot to remove the lock. Test on a pilot ring before deploying broadly. Back up BitLocker recovery keys first. Verify that the Windows Recovery Environment is updated to the latest Safe OS Dynamic Update (released July 8, 2025) before applying [@kb5042562].

Note: A safe deployment plan: (1) pick a pilot ring of representative hardware; (2) verify each pilot machine has the July 8, 2025 WinRE Safe OS Dynamic Update applied; (3) back up BitLocker recovery keys to a secondary store you control; (4) deploy SkuSiPolicy.p7b from %windir%\System32\SecureBootUpdates\ to the EFI System Partition's \EFI\Microsoft\Boot\ directory without the UEFI lock first; (5) verify boot integrity for several reboot cycles; (6) apply the UEFI lock; (7) confirm no other CI policy is being shipped that conflicts; (8) graduate the policy to the wider fleet.

Finally: the VBS "Mandatory" flag (HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Mandatory) is the only configuration Leviev has not bypassed [@safebreach-2024-oct]. Set it where boot reliability is acceptable and you have rehearsed the recovery procedure (SecConfig.efi to delete the lock, the flag set, the lock re-enabled). Inventory the count of Administrator accounts on each machine -- the Downdate primitive's blast radius is bounded by the number of identities that can write PoqexecCmdline. Every reduction in that count is a direct reduction in the attack surface.

10.2 Detection engineers

The detection signature is the registry pivot. Authenticode-based file-integrity tooling will not catch Windows Downdate, because the downgraded files are legitimately Microsoft-signed [@safebreach-2024-aug]. The Splunk Security Content windows_downdate_registry_activity analytic is the canonical reference detection [@splunk-downdate-detection]. The logic is:

Consume Sysmon EventIDs 12, 13, and 14 (Registry creation, set-value, and rename).
Match TargetObject against *PoqexecCmdline or *COMPONENTS\PendingXmlIdentifier.
Suppress writes whose calling ProcessPath is under *:\Windows\WinSxS\* (the legitimate-update path).
Map to MITRE ATT&CK T1112 (Modify Registry, Defense Impairment) and T1689 (Downgrade Attack, Persistence/Exploitation/Installation).

The Splunk detection is disabled by default in Splunk Enterprise Security. Operators must enable it explicitly [@splunk-downdate-detection]. The point of attack on the EDR side is the registry pivot, not the file substitution -- the substitution looks like a normal update because, by every check Windows performs, it is one.

{` // Demonstrates the decision logic of the windows_downdate_registry_activity detection. // Not a real Sysmon parser -- the inputs would be Event 12/13/14 records in production.

function isLegitimateUpdatePath(processPath) { // Legitimate Windows Update operations run under WinSxS. return processPath.toLowerCase().includes('\\windows\\winsxs\\'); }

function classifyRegistryWrite(event) { const sensitiveValues = [ 'PoqexecCmdline', 'COMPONENTS\\PendingXmlIdentifier' ];

const matchesSensitive = sensitiveValues.some(v => event.TargetObject.endsWith(v) );

if (!matchesSensitive) return 'ignore'; if (isLegitimateUpdatePath(event.ProcessPath)) return 'allow'; return 'alert'; }

const sample = [ { TargetObject: 'HKLM\\...\\PoqexecCmdline', ProcessPath: 'C:\\Windows\\WinSxS\\amd64_x\\TrustedInstaller.exe' }, { TargetObject: 'HKLM\\...\\PoqexecCmdline', ProcessPath: 'C:\\Users\\alice\\Desktop\\windows_downdate.exe' }, { TargetObject: 'HKLM\\...\\COMPONENTS\\PendingXmlIdentifier', ProcessPath: 'C:\\tools\\suspicious.exe' } ];

for (const ev of sample) { console.log(classifyRegistryWrite(ev), '<-', ev.ProcessPath); } `}

The Splunk detection only watches the two registry pivots. A more aggressive variant also watches for unexpected `pending.xml` files appearing outside `C:\Windows\WinSxS\` and for file integrity changes against expected hashes of `poqexec.exe` and `sfc.exe`. The trade-off is false positives: enterprise patch tooling and configuration-management agents touch the servicing path more often than you would expect, and an aggressive variant requires tuning before it is fleet-ready.

10.3 System designers

If you are building a new operating system in 2026, you do not have an excuse. The architectural takeaway from Windows Downdate is general: any update mechanism that can write into a higher-privilege domain must enforce version monotonicity in the same domain that performs the write. If the update is processed by a TrustedInstaller-context service, version monotonicity has to be enforced by TrustedInstaller (or by something even further from the attacker -- the boot manager, the firmware, the TPM). If the version-state pointer lives in a registry value an Administrator can rewrite, the boundary moves and the design is broken.

Concrete reference patterns are available:

TPM-stored generation counters. Bind the counter to a transcript hash of the cumulative-update history; the boot manager and Secure Kernel refuse to load components older than the stored counter [@tuf-spec]. This is the Apple SSV / Android AVB pattern translated into Windows-shaped trust roots.
Monotonic catalog versions. Sign the per-component catalog with an explicit <min-version> field; the kernel loader refuses to load any catalog whose <min-version> is below the loader's stored maximum. This is the TUF snapshot-role pattern [@tuf-spec].
In-protocol monotonicity at the update edge. Use the IETF SUIT envelope format and the seq-num field defined in RFC 9019 [@rfc9019]. The receiver tracks the highest sequence number it has seen and refuses lower ones at the spec level, not the policy level.

The reference designs exist. TUF [@tuf-spec], IETF SUIT [@rfc9019], and AOSP AVB [@aosp-avb] are open. Pick one. Adapt it. Ship it. The hard part is not the engineering. The hard part is the institutional commitment to declaring a security boundary you did not declare last year.

If you are building a new OS in 2026, you do not have an excuse.

11. Misconceptions, Corrections, and What Comes Next

Windows Downdate spawned a press cycle that got several things wrong. Here is what is actually true.

No. The substantive code fix for CVE-2024-38202 (the basic-user-induced restore-point variant) shipped on **October 8, 2024** as KB5044284 for Windows 11 24H2 and OS Build 26100.2033, with per-SKU equivalents on the same date [@kb5044284; @nvd-cve-2024-38202]. The earlier mitigation guidance, KB5042562 (the opt-in `SkuSiPolicy.p7b` policy and the default-enabled boot-session CI policy), shipped on August 13, 2024 [@kb5042562]. There is no November 2024 anchor. The multi-quarter cleanup across older SKUs completed July 8-10, 2025 [@nvd-cve-2024-21302]. No. *Secure Boot* bypass via downgrade is BlackLotus (CVE-2022-21894, "Baton Drop"), which used a vulnerable Microsoft-signed `bootmgfw.efi` that was not in the UEFI `dbx` revocation list [@welivesecurity-blacklotus]. Windows Downdate bypasses *VBS UEFI locks* and downgrades the VBS-protected components (`securekernel.exe`, `hvix64.exe`, `LsaIso.exe`, `ci.dll`) along with the NT kernel itself [@safebreach-2024-aug]. The two attacks operate at different layers: BlackLotus at the firmware/boot manager, Downdate at the OS component layer. The mechanism shape is similar; the targets are distinct. No. *ItsNotASecurityBoundary* is Gabriel Landau's (Elastic Security Labs) exploit name for a False File Immutability TOCTOU on `ci.dll`, disclosed in early 2024 and patched in **May 14, 2024 (KB5037771)** with a preview build on April 23, 2024 (KB5036980) [@landau-itsnotasecurityboundary-repo; @elastic-ffi]. Leviev's October 26, 2024 SafeBreach follow-up *revived* Landau's exploit by using Windows Downdate to roll `ci.dll` back to the pre-May build [@safebreach-2024-oct]. Leviev's actual Black Hat USA 2025 talk, with Netanel Ben Simon, was **BitUnlocker**, on Windows Recovery Environment attacks -- patched in July 2025 Patch Tuesday [@itnews-bitunlocker; @infocondb-defcon33-bitunlocker]. No. Microsoft assigned and patched both CVEs from disclosure day (August 7, 2024) onward [@nvd-cve-2024-21302; @nvd-cve-2024-38202]. The position that Microsoft *has* taken is narrower: the underlying *primitive* (the Administrator-context modification of `PoqexecCmdline` that the Downdate technique relies on) has remained unpatched because it does not cross a defined security boundary in the published Windows Security Servicing Criteria [@safebreach-2024-oct; @msft-servicing-criteria]. The two assigned CVEs are the *boundary-crossing parts* of the chain. The unassigned primitive is the part that runs on each side of the boundary that nobody declared. No. Authenticode does what it says: it verifies that a binary was signed by a specific certificate (and that the certificate chains to a trusted root). The older `ci.dll` that Windows Downdate installs is legitimately signed by Microsoft. Authenticode never claimed to assert "and is the current version" -- it is a *signature* check, not a *staleness* check [@safebreach-2024-aug; @msdocs-driver-signing]. The mistake is in the design above Authenticode that treats signature validity as equivalent to current-version-validity, not in Authenticode itself. Per Leviev's claim in the August 2024 SafeBreach blog, `poqexec.exe` is not Authenticode-signed in the affected Windows builds, and neither is `sfc.exe` [@safebreach-2024-aug]. The persistence step of Windows Downdate exploits this directly: replacing `poqexec.exe` with a patched copy that NOPs future updates does not require a code-signing bypass. The hardening suggested in section 8 -- sign both binaries, enforce HVCI on them -- removes the persistence and irreversibility steps, but signing alone is not sufficient: the `PoqexecCmdline` registry pivot survives signing, because the pivot points the *legitimately signed* `poqexec.exe` at an attacker-chosen action list. EDR coverage focuses on the known indicators: registry writes to `PoqexecCmdline` and `PendingXmlIdentifier` by processes that are not under `C:\Windows\WinSxS\`, and unexpected `pending.xml` files outside the TrustedInstaller-only directories [@splunk-downdate-detection]. The downgrade itself, once executed, is by design indistinguishable from a legitimate update at the file-signature layer. Whether a given EDR product has shipped a detection for the registry pivot is product-specific; the Splunk Security Content analytic referenced above is the cleanest published reference signature [@splunk-downdate-detection]. Microsoft Defender for Endpoint operators should verify with their account team that an equivalent detection is enabled in their tenant.

Microsoft built a security boundary in 2007 that depended on the assumption that updates only move forward. We now know they do not. The work of declaring the new boundary -- one component, one SKU, one cumulative update at a time -- is what Microsoft is doing right now. Whether the boundary will eventually be declared in the Windows Security Servicing Criteria, rather than implemented quietly as a per-component policy, is the question whose answer we will know in 2027.

For now, the lesson is portable. The shape of Windows Downdate generalises: every signed-update system needs a version-monotonicity primitive co-located with the trust root that enforces signatures. The reason it took until 2024 to demonstrate this on Windows is not that the bug was deep. It is that nobody, in eighteen years of Windows servicing engineering, had been asked to declare the boundary the bug crossed. Once Leviev asked the question, the answer wrote itself.

Protected Process Light: When the Administrator Isn't Enough

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

**Windows Protected Process Light (PPL) re-asks the question of who can touch whom one level below the token model.** A single byte in `EPROCESS` packs a process's protection type, audit bit, and signer rung; the kernel's lattice check inside `NtOpenProcess` rejects memory-read attempts from below the target's rung even when the caller is SYSTEM with `SeDebugPrivilege` enabled. Every public bypass since 2018 lives in one structural class -- the kernel verifies the channel by which code enters a PPL, not the behaviour of that code once mapped -- which is why Microsoft classifies PPL as defense in depth rather than a security boundary, and why Credential Guard / `LsaIso.exe` is its necessary VBS-anchored companion.

1. Mimikatz on a Protected Box

A red team operator has done everything right. The shell is SYSTEM-integrity. SeDebugPrivilege is enabled in the token. whoami /priv shows every privilege Windows defines. The operator types mimikatz.exe, then privilege::debug -- OK. Then sekurlsa::logonpasswords -- and Mimikatz answers:

ERROR kuhl_m_sekurlsa_acquireLSA ; Handle on memory : (0x00000005) Access is denied

The mechanism that just denied them is not a privilege check at all. It is not an ACL decision. It is not the integrity-level mediator. itm4n recreated exactly this failure in 2021 against a vanilla Windows install with one registry value set [@itm4n-runasppl]. The error code 0x00000005 is ERROR_ACCESS_DENIED -- the Win32 surface that GetLastError exposes for the kernel's NTSTATUS STATUS_ACCESS_DENIED = 0xC0000022. The kernel returns the NTSTATUS out of NtOpenProcess before the security descriptor of lsass.exe has been consulted; RtlNtStatusToDosError then maps it to the Win32 0x5 that surfaces in kuhl_m_sekurlsa.c.

A kernel-enforced gating model that decorates a process with a *protection level* -- a structured byte combining a type field, an audit bit, and a signer rung -- and rejects `OpenProcess` requests from callers whose protection level is below the target's, regardless of token privileges or security-descriptor ACLs.

Picture the scenario concretely. A 2026 red-team engagement against a hardened Windows 11 24H2 endpoint. RunAsPPL audit-mode is on by default after the Windows 11 22H2 rollout extended audit-default to consumer SKUs [@learn-runasppl]. A third-party EDR daemon is already running, signed at the Antimalware rung via the vendor's Microsoft Virus Initiative enrollment. The operator owns local administrator. The operator has SYSTEM. The operator holds every privilege Windows defines. They still cannot read a single byte of LSASS memory.

The denial trace, walked carefully, looks like this. Mimikatz calls OpenProcess(PROCESS_VM_READ | PROCESS_QUERY_INFORMATION, FALSE, lsass_pid). The Win32 thunk lands on NtOpenProcess, which dispatches to the object-manager callback PspProcessOpen. That callback calls PspCheckForInvalidAccessByProtection, which calls RtlTestProtectedAccess against the caller's EPROCESS.Protection byte and the target's EPROCESS.Protection byte. The lattice test fails. The kernel strips PROCESS_VM_READ from the requested mask. With the surviving limited mask, the request continues into SeAccessCheck, but Mimikatz never wanted the limited mask; it wanted to read memory. The handle returned (or the failure path taken) gives Mimikatz exactly the path that produces 0x00000005 in kuhl_m_sekurlsa.cThe relevant commit is fe4e98405589e96ed6de5e05ce3c872f8108c0a0, cited by itm4n as the source for the exact failure path that yields 0x00000005 [@mimikatz-sekurlsa]..

sequenceDiagram participant Mim as Mimikatz (SYSTEM, SeDebugPrivilege) participant K32 as kernel32 / OpenProcess participant NtOP as NtOpenProcess participant PsPO as PspProcessOpen participant CHK as PspCheckForInvalidAccessByProtection participant Lat as RtlTestProtectedAccess participant SAC as SeAccessCheck

Mim->>K32: OpenProcess(PROCESS_VM_READ, lsass)
K32->>NtOP: syscall NtOpenProcess
NtOP->>PsPO: object-manager callback
PsPO->>CHK: check caller.Protection vs target.Protection
CHK->>Lat: lattice rule (signer rungs)
Lat-->>CHK: full mask denied
CHK-->>PsPO: strip PROCESS_VM_READ
PsPO->>SAC: residual mask (limited only)
SAC-->>NtOP: limited handle (read denied)
NtOP-->>Mim: STATUS_ACCESS_DENIED (NTSTATUS 0xC0000022, Win32 GetLastError = 5)

Note: If every privilege Windows defines is held by the caller, what is doing the denying? The answer is a kernel structure that the token model does not see and the security descriptor does not influence -- a byte in EPROCESS named Protection, mediating a lattice the access check consults before it ever asks SeAccessCheck about privileges.

This is not a workaround pattern. It is a new dimension. The token model is unchanged. The integrity level is unchanged. The security descriptor on lsass.exe is unchanged. What changed is that the kernel now answers a question it did not ask before: what kind of trust does the caller have to manipulate the address space of the callee?

PPL re-asks the question of who can touch whom one level below the token model.

That mechanism has a name (Protected Process Light), an encoding (a single UCHAR), and a history that does not begin where you would expect. To understand the byte, we have to understand why Microsoft built it in the first place. The next section starts where the history starts: a 2006 Microsoft whitepaper about Hollywood.

2. Historical Origins -- Vista, DRM, and the First Protected Process

The kernel mechanism that today denies admins access to LSASS was invented in 2006 to keep Hollywood happy. The cover page of Microsoft's process_vista.doc whitepaper opens with a sentence almost no one quotes today:

The Microsoft Windows Vista operating system introduces a new type of process known as a protected process to enhance support for Digital Rights Management functionality in Windows Vista.

The whitepaper was published November 27, 2006, two months before Vista's GA, and it is the architectural seed of the byte we will be staring at for the rest of this article [@vista-process-doc]. The motivation was not credential theft. It was HD-DVD and Blu-ray content protection. Studio licensing agreements required that even an administrator on the local machine could not read the audio device graph isolation host's memory while protected content was playing. The Protected Media Path required a kernel-enforced barrier between admin user-mode and the media pipeline.

The Vista-era set of components that decrypt and render high-definition video and audio content under DRM. PMP requires kernel-enforced isolation of `audiodg.exe` and a small set of related processes so that local administrators cannot dump intermediate content keys from process memory.

The Vista design was minimal. A single bit in EPROCESS marks a process as protected. At NtCreateUserProcess, the kernel parses the main image's Authenticode signature and looks for a specific Microsoft EKU OID that only the PMP signing root can issue [@forshaw-2018-10]. If the EKU is present and the chain resolves to that root, the kernel flips the bit. On every subsequent NtOpenProcess against that process, the kernel strips a fixed set of access rights from the mask, no matter who is asking.

Alex Ionescu, then a Windows internals researcher and now CrowdStrike's Chief Technology Innovation Officer, enumerated the denials in 2007 [@ionescu-pp-bad-idea]:

A typical process cannot perform operations such as the following on a protected process: Inject a thread into a protected process; Access the virtual memory of a protected process; Debug an active protected process; Duplicate a handle from a protected process; Change the quota or working set of a protected process.

Five denials. One bit. One certificate root. Ionescu's same essay, titled "Why Protected Processes Are A Bad Idea," made a structural argument that aged well: putting a DRM mechanism in the kernel is a category error. The mechanism is too narrow for non-DRM use because the only certificate accepted is Microsoft's PMP signing root, and the only operations gated are the ones Hollywood cared about. Third parties cannot opt in, and Microsoft itself cannot graduate the level of trust.Ionescu's 2007 critique remains worth reading on its own merits. The argument that DRM-shaped kernel features tend to be reused for security mitigations and that this reuse changes their threat-model semantics is exactly what plays out over the next seven years [@ionescu-pp-bad-idea].

The seven-year pause is its own story. Vista shipped, Vista was followed by Windows 7, and Windows 7 was followed by Windows 8 -- and through all of it, the access-check primitive that protects audiodg.exe from administrators remained a DRM artefact. The primitive existed; the graduated trust dimension did not. Two parallel failures pushed Microsoft toward widening the encoding.

The first was Mimikatz. Benjamin Delpy's tool was first released in May 2011 and refined through 2013 [@mimikatz-wikipedia]; it made it trivial for an administrator to extract NTLM hashes and Kerberos session keys from lsass.exe. The countermeasure of restricting SeDebugPrivilege was useless; an attacker who has SYSTEM has every privilege. What Mimikatz exploited was a primitive gap: the kernel had no way to say "lsass is protected against administrators but reachable from privileged Microsoft services."

The second was Mateusz Jurczyk's CSRSS jailbreak of Windows 8 RT in 2013. Jurczyk (who writes as j00ru) catalogued more than seventy Win32k system calls that the kernel guarded with the pattern if (PsGetCurrentProcess() != gpepCsrss) return STATUS_ACCESS_DENIED; [@j00ru-1393]. That gating mechanism worked only as long as nobody could inject code into csrss.exe. On Windows 8 RT, an attacker who could inject into csrss.exe could bypass Microsoft's locked-down Surface RT shell. Ionescu later observed that "In Windows 8.1 RT, this jailbreak is 'fixed', by virtue that code can no longer be injected into Csrss.exe for the attack" [@ionescu-part2]. The fix made csrss.exe a PPL at the WinTcb rung, and the same machinery was generalised to lsass.exe and the Antimalware tier.

Note: Mimikatz proved Microsoft needed a graduated trust dimension for lsass.exe. The j00ru CSRSS jailbreak proved Microsoft needed it for csrss.exe too. The same widening of the encoding answered both.

flowchart LR subgraph Vista2006[Vista 2006 -- single bit] V1[EPROCESS protected = 0 or 1] V2[Certificate root: PMP only] V3[Access denials: hardcoded 5-tuple] end subgraph Win81[Windows 8.1 -- _PS_PROTECTION byte] W1[Type: 3 bits] W2[Audit: 1 bit] W3[Signer rung: 4 bits] W4[Certificate roots: per-EKU sub-OIDs] W5[Access denials: lattice over signer] end V1 --> W1 V2 --> W4 V3 --> W5 The DRM-to-credentials repurposing is not unique to PPL. The same pattern shows up in HVCI (originally a Hyper-V kernel-mode integrity feature, later repurposed for general code-integrity enforcement) and in Trustlets (originally an enterprise feature for Credential Guard, later generalised). Kernel mechanisms born in one threat model rarely stay confined to it.

Microsoft already had the access-check primitive. What it didn't have, in 2007, was a way to ask "how much trust does this process carry?" The fix would not arrive until Windows 8.1 in October 2013, and when it arrived, it would fit in a single byte.

3. `_PS_PROTECTION` -- The Single-Byte Encoding

The 8.1 fix is so compact it fits in a single byte. Ionescu's Part 1 of the "Evolution of Protected Processes" series, published November 22, 2013, gives the kernel structure verbatim [@ionescu-part1]:

typedef struct _PS_PROTECTION {
    union {
        UCHAR Level;
        struct {
            UCHAR Type   : 3;
            UCHAR Audit  : 1;
            UCHAR Signer : 4;
        };
    };
} PS_PROTECTION, *PPS_PROTECTION;

Three fields. One byte. The union with Level:UCHAR exists so that two _PS_PROTECTION values can be compared with a single byte load and a single byte compare. The kernel does this on every NtOpenProcess. Speed matters; this is the hot path of the security model.

The kernel structure that encodes a process's protection state in eight bits: three bits of Type (`None`, `ProtectedLight`, `Protected`), one bit of Audit (intended as a forensic side-channel hint, although the exact runtime semantics are not enumerated in the public sources cited here), and four bits of Signer rung. Stored as `EPROCESS.Protection`.

The Type field has three values. PsProtectedTypeNone = 0 marks a regular process. PsProtectedTypeProtectedLight = 1 marks a PPL -- the graduated path introduced in 8.1. PsProtectedTypeProtected = 2 marks a "heavy" Vista-style PP. Heavy PPs still exist; they retain the original DRM semantics where almost nothing from below the protection level may touch them. PPLs are the new general-purpose path where the signer rung mediates a graduated lattice.

The Audit bit is the least documented of the three fields. Ionescu Part 1 lists it as Audit : Pos 3, 1 Bit with no semantic gloss; itm4n's RunAsPPL header annotates it as // Reserved; Microsoft Learn enumerates CodeIntegrity events 3033, 3063, 3065, and 3066, but those are triggered by the AuditLevel configuration under Image File Execution Options\LSASS.exe and concern DLL-load failures, not per-process OpenProcess denials [@ionescu-part1] [@itm4n-runasppl] [@learn-runasppl]. The field's name implies a forensic side-channel, and the bit-position is reserved; the precise runtime emission shape is not enumerated in the public sources cited here.

The Signer field is the structurally interesting one. Ionescu's 2013 enumeration names eight values [@ionescu-part1]:

Signer constant	Value	Used for
`PsProtectedSignerNone`	0	Non-protected (no rung)
`PsProtectedSignerAuthenticode`	1	Generic third-party Authenticode (early PPL guests)
`PsProtectedSignerCodeGen`	2	.NET native runtime code generators
`PsProtectedSignerAntimalware`	3	EDR / AV daemons admitted via ELAM
`PsProtectedSignerLsa`	4	`lsass.exe` under `RunAsPPL`
`PsProtectedSignerWindows`	5	Microsoft Windows components below TCB
`PsProtectedSignerWinTcb`	6	`csrss.exe`, `smss.exe`, `services.exe` -- the inbox TCB
`PsProtectedSignerMax`	7	Sentinel value (enumeration upper bound)

Note: Ionescu's 2013 list is the authoritative baseline enumeration. It is not a permanent enumeration. By 2018, James Forshaw's PowerShell tooling (NtApiDotNet) was enumerating an additional App = 8 signer used for AppContainer / TruePlay scenarios [@forshaw-2018-10]. Newer builds of Windows extend the enumeration further. The article will name WinTcb (Microsoft's documented inbox-TCB rung) and Antimalware (the only non-Microsoft-admissible rung) repeatedly, because they are the load-bearing ones. The intermediate values evolve.

Adjacent to EPROCESS.Protection are two related fields, EPROCESS.SignatureLevel and EPROCESS.SectionSignatureLevel, which Ionescu introduces in Part 3 [@ionescu-part3]. These fields encode the binary integrity the kernel demands at process creation and at every subsequent section load, and they are filled in from a 16-entry Signing Level table that runs from Unchecked = 0 up to Windows TCB = 14. The Signer rung in Protection answers "what kind of trust does this process hold?" The SignatureLevel pair answers "what binaries is this process allowed to map?" They are not the same question.

Now the worked decode. Given the byte value 0x41, the encoding falls out by hand:

Low three bits (Type): 0x41 & 0x07 = 0x01 -- PsProtectedTypeProtectedLight.
Bit 3 (Audit): (0x41 >> 3) & 0x01 = 0 -- Audit off.
High four bits (Signer): (0x41 >> 4) & 0x0F = 0x04 -- PsProtectedSignerLsa.

A process with EPROCESS.Protection = 0x41 is a PPL signed at the Lsa rung. That is exactly what lsass.exe looks like on a host with RunAsPPL = 1. Ionescu's blog explicitly states: "it's easy to read 0x41 as Lsa (0x4) + PPL (0x1)" [@ionescu-part1]. The Defender service MsMpEng.exe, signed at the Antimalware rung, has Protection = 0x31. The session manager csrss.exe, signed at WinTcb, has Protection = 0x61.

flowchart TD B[byte: 8 bits] B --> F1[bits 0..2: Type] B --> F2[bit 3: Audit] B --> F3[bits 4..7: Signer] F1 --> T0[0 = None] F1 --> T1[1 = ProtectedLight PPL] F1 --> T2[2 = Protected PP] F3 --> S0[0 None] F3 --> S1[1 Authenticode] F3 --> S2[2 CodeGen] F3 --> S3[3 Antimalware] F3 --> S4[4 Lsa] F3 --> S5[5 Windows] F3 --> S6[6 WinTcb]

{` function decodeProtection(byteValue) { const type = byteValue & 0x07; const audit = (byteValue >> 3) & 0x01; const signer = (byteValue >> 4) & 0x0F; const typeNames = ['None', 'ProtectedLight', 'Protected']; const signerNames = [ 'None', 'Authenticode', 'CodeGen', 'Antimalware', 'Lsa', 'Windows', 'WinTcb', 'Max' ]; return { raw: '0x' + byteValue.toString(16).padStart(2, '0'), type: typeNames[type] || 'unknown(' + type + ')', audit: audit ? 'on' : 'off', signer: signerNames[signer] || 'unknown(' + signer + ')' }; }

// Worked examples from real Windows processes console.log('MsMpEng.exe (Defender):', decodeProtection(0x31)); console.log('lsass.exe under RunAsPPL:', decodeProtection(0x41)); console.log('csrss.exe (WinTcb):', decodeProtection(0x61)); `}

Note: One byte, three fields, eight signer rungs. The kernel reads it on every OpenProcess, before any token check, before any ACL evaluation. The encoding is the entire vocabulary the kernel has for asking how trusted a process is.

The encoding tells the kernel what kind of trust a process holds. It says nothing about who can touch whom across rungs. That rule -- the lattice -- is the structure imposed on top of the bytes. The next section is the lattice.

4. The Signer Lattice -- Who Can Open Whom

itm4n's 2021 walkthrough states the three rules verbatim, and they have the rare quality of being short enough to memorise [@itm4n-scrt]:

A PP can open a PP or a PPL with full access if its signer type is greater or equal. A PPL can open a PPL with full access if its signer type is greater or equal. A PPL cannot open a PP with full access, regardless of its signer type.

Three rules. They settle every cross-process access question PPL gates. Let us name them and then read off their consequences.

Rule 1. A PP at signer $S_c$ may open with full access a PP or PPL at signer $S_t$ if and only if $S_c \ge S_t$.

Rule 2. A PPL at signer $S_c$ may open with full access a PPL at signer $S_t$ if and only if $S_c \ge S_t$.

Rule 3. A PPL cannot open a PP with full access, regardless of signer.

The qualifier "with full access" is load-bearing. PPL's lattice gates the full mask -- PROCESS_VM_READ, PROCESS_VM_WRITE, PROCESS_CREATE_THREAD, PROCESS_DUP_HANDLE, PROCESS_ALL_ACCESS. A separate limited mask (SYNCHRONIZE, PROCESS_QUERY_LIMITED_INFORMATION, PROCESS_SET_LIMITED_INFORMATION, PROCESS_SUSPEND_RESUME, and -- for callers below the Authenticode/CodeGen/Windows tier -- PROCESS_TERMINATE) is allowed when the security descriptor permits. The tier matters. Ionescu's verbatim RtlProtectedAccess[] table widens the deny mask from 0xFC7FE to 0xFC7FF at the Antimalware, Lsa, and WinTcb rungs -- one extra bit, bit 0, which is PROCESS_TERMINATE [@ionescu-part2]. So an administrator can still call OpenProcess(PROCESS_QUERY_LIMITED_INFORMATION, ...) against a protected lsass.exe to enumerate threads, but cannot terminate a PPL/Antimalware, PPL/Lsa, or PPL/WinTcb daemon via a direct kill. The lattice does not lock the process; it locks the interesting access, and for the top-tier rungs it also locks the kill.

Caller signer \ Target signer	None	Authenticode (1)	Antimalware (3)	Lsa (4)	Windows (5)	WinTcb (6)
None (admin, integrity SYSTEM)	full	denied	denied	denied	denied	denied
PPL/Authenticode (1)	full	full	denied	denied	denied	denied
PPL/Antimalware (3)	full	full	full	denied	denied	denied
PPL/Lsa (4)	full	full	full	full	denied	denied
PPL/Windows (5)	full	full	full	full	full	denied
PPL/WinTcb (6)	full	full	full	full	full	full

Where "denied" means the full mask is rejected; the limited mask continues to apply per the target's security descriptor.

flowchart BT None[None / unprotected] Auth[Authenticode] CG[CodeGen] AM[Antimalware] Lsa[Lsa] Win[Windows] Tcb[WinTcb] None --> Auth Auth --> CG CG --> AM AM --> Lsa Lsa --> Win Win --> Tcb

The Enhanced Key Usage side of the design holds the lattice together. Microsoft's EKU OID arc 1.3.6.1.4.1.311.10.3.* defines sub-OIDs per signer rung [@iana-pen311] [@oid-base-eku-arc], and at process creation the kernel parses the main image's Authenticode signature and walks its EKU extensions to determine which rung the binary is entitled to claim. If the certificate chain resolves cleanly to a Microsoft-issued root and carries the rung's sub-OID, the kernel records the rung. Otherwise the process either starts unprotected or refuses to start at all.

An X.509 v3 certificate extension that asserts what specific purposes a certificate is allowed to certify. Microsoft uses sub-OIDs under `1.3.6.1.4.1.311.10.3.*` to encode protected-process signer rungs as EKU values [@iana-pen311] [@oid-base-eku-arc]. The kernel checks the EKU at process creation; the certificate chain anchors which Microsoft-issued sub-CA may issue at each rung.The IANA Private Enterprise Number `311` is registered to Microsoft under the PEN prefix `1.3.6.1.4.1.` [@iana-pen311], so `1.3.6.1.4.1.311.*` is the catch-all namespace for Microsoft-specific X.509 extensions; the `10.3.*` arc within it is the Microsoft Enhanced Key Usage (purpose) sub-tree [@oid-base-eku-arc], and `10.3.` slots map to specific signer purposes including protected-process rungs.

The most important property of this design is the resolution point. The kernel parses the EKU exactly once, at NtCreateUserProcess. It stores the resulting rung in EPROCESS.Protection. On every subsequent OpenProcess against that process, the kernel consults the byte, not the certificate. This makes the access check fast (one byte load, one byte compare) and decouples policy at runtime from policy at signing time. It also creates the structural seam that every public bypass since 2018 has exploited, because the kernel's confidence in the byte is exactly the confidence it had in the certificate at process-create time, projected forward indefinitely.

Ionescu's Part 2 names the implementation directly. The lattice is not code; it is a data table named RtlProtectedAccess[] baked into ntoskrnl.exe [@ionescu-part2]. Each row of that table corresponds to a (signer, target-type) pair and encodes which access bits are allowed in the full mask. The relevant runtime routines are PspProcessOpen and PspThreadOpen (the object-manager open callbacks), PspCheckForInvalidAccessByProtection (which performs the check), RtlTestProtectedAccess (which applies the lattice row), and RtlValidProtectionLevel (which sanity-checks the encoded byte for consistency).

Note: The decision of who can touch whom is encoded in a table inside ntoskrnl.exe. Changing the lattice means changing a table; widening or narrowing it does not require new code. This is why Microsoft can add App = 8 to the enumeration over time without touching the access-check routine.

Note one symmetry that becomes important later. "Greater or equal" means that within a rung, every PPL can read every other PPL. Two co-resident PPL/Antimalware daemons -- Microsoft Defender's MsMpEng.exe and a third-party EDR's agent -- can call PROCESS_VM_READ on each other. Within-rung peers leak to each other by design. The lattice prevents escalation, not peer access.

The lattice settles the rule. The next question is admission: who decides which binaries are allowed to claim the Antimalware rung, and how does Microsoft admit third-party code into it at all? The answer is a driver.

5. The Antimalware Rung -- ELAM and Third-Party Code at PPL

PPL is interesting only if it admits non-Microsoft code at some rung. The Vista PP design admitted nobody; it required a Microsoft PMP root certificate, full stop. PPL inherited that constraint at every rung except one. The Antimalware rung -- signer value 3 -- is the only rung where third-party vendors can ship their own user-mode binaries as protected processes. The admission mechanism is the Early Launch Anti-Malware driver.

A specially signed Microsoft-certified kernel driver shipped by an anti-malware vendor that loads before any other boot-start driver. The ELAM driver participates in trusted-boot measurement, vouches for follow-on drivers, and -- critical to PPL -- carries an embedded resource section enumerating the vendor's user-mode signing certificate hashes. The kernel uses that resource section to admit the vendor's user-mode daemon binaries to `PPL/Antimalware` at service start.

Microsoft Learn's "Protecting Anti-Malware Services" page describes the boot-time admission flow in two sentences [@learn-am-services]:

The driver must have an embedded resource section containing the information of the certificates used to sign the user mode service binaries. During the boot process, this resource section will be extracted from the ELAM driver to validate the certificate information and register the anti-malware service.

Two consequences. First, the third-party signer set is bounded by a kernel-readable resource section, not by an open EKU. Microsoft, not the vendor, controls which user-mode binaries are admissible. Second, the certificate hashes are baked into the driver at signing time and re-validated at every service start. A vendor cannot widen the admissible set after the fact; an attacker cannot drop in their own user-mode binary unless its hash is already listed.

The gate that decides which vendors get ELAM drivers in the first place is the Microsoft Virus Initiative. Microsoft Learn's MVI criteria page enumerates the requirement explicitly [@learn-mvi]:

Your security solution must be certified within the last 12 months by at least one of the organizations listed below: AV-Comparatives, AVLab Cybersecurity Foundation, AV-Test, MRG Effitas, SE Labs, SKD Labs, VB 100, West Coast Labs.

The same page requires "use of Trusted Signing," Microsoft's cloud-managed code signing service. The implications are operational. To ship code at PPL/Antimalware, a vendor must (a) hold MVI membership, (b) maintain independent-lab certification, (c) author an ELAM driver, (d) get the driver through Microsoft WHQL and have it Microsoft co-signed, and (e) embed the user-mode certificate hashes in the driver's resource section.

A Microsoft program for anti-malware vendors that gates access to ELAM driver signing and to specific Defender APIs. Membership requires independent-lab certification (renewed annually) and Trusted Signing usage; in practical terms, MVI membership is the entry ticket to deploying user-mode binaries at `PPL/Antimalware`. The implication of MVI is that an indie security tool, however technically sound, cannot deploy as `PPL/Antimalware`. The gate is not technical but commercial: independent-lab certification fees, annual renewals, and the engineering investment of building a production-grade ELAM driver. The signer rung is *signed*; the signing program is *gated*. sequenceDiagram participant BM as Boot manager participant K as Windows kernel participant ELAM as Vendor ELAM driver (.sys) participant SCM as Service Control Manager participant CI as ci.dll (CodeIntegrity) participant Svc as Vendor service (e.g. EDR daemon) BM->>K: load boot drivers K->>ELAM: load ELAM driver early K->>ELAM: read embedded ELAM resource section K->>K: cache vendor user-mode cert hashes Note over K,SCM: Boot continues, OS initialises SCM->>Svc: start vendor service Svc->>CI: validate service binary signature CI->>K: lookup vendor cert against cached hashes K-->>CI: match -- admit at PPL/Antimalware CI-->>Svc: launch as PPL/Antimalware (Protection = 0x31)

By 2024, every major commercial EDR ships through this path. Microsoft Defender's MsMpEng.exe uses the inbox WdBoot.sys ELAM driverWdBoot.sys ("Windows Defender Boot Driver") is Microsoft's inbox first-party ELAM driver; it ships in every Windows install and is loaded before any third-party ELAM driver. The canonical reference implementation of the ELAM resource-section pattern is Microsoft's Windows-driver-samples/security/elam repository [@ms-elam-sample], which also documents the Early Launch EKU 1.3.6.1.4.1.311.61.4.1 verbatim.. Third-party members of Microsoft's Virus Initiative -- the cohort gated by the MVI criteria quoted above [@learn-mvi] -- ship their own vendor ELAM drivers and run their main user-mode daemons at PPL/Antimalware. Microsoft Learn's "Early Launch Antimalware" page is the canonical confirmation [@learn-elam]:

Because an ELAM service runs as a PPL (Protected Process Light), you need to debug using a kernel debugger.

One Microsoft-signed sentence and a billion endpoints. EDR vendors get protection against administrator-level tampering for free, on top of the kernel telemetry their drivers already collect. Microsoft gets a viable third-party security market without widening the EKU gates beyond a controllable set of vendors.

ELAM admits the daemon. The next operational question is what Microsoft does for lsass.exe itself -- the canonical credential store, the original Mimikatz target. The mechanism is called RunAsPPL.

6. RunAsPPL -- Hardening LSASS

The registry value that produced the Mimikatz failure in Section 1 is a single DWORD. itm4n's walkthrough names it verbatim [@itm4n-runasppl]:

Open the key HKLM\SYSTEM\CurrentControlSet\Control\Lsa; add the DWORD value RunAsPPL and set it to 1; reboot.

After reboot, lsass.exe launches at PPL/Lsa, signer rung 4, protection byte 0x41. Mimikatz running with full SYSTEM-integrity and SeDebugPrivilege then receives 0x00000005 on OpenProcess(PROCESS_VM_READ, lsass.exe). The registry knob is one DWORD; the consequences are large.

The Windows user-mode process that holds NTLM password hashes, Kerberos Ticket Granting Tickets, MSV1_0 credential caches, DPAPI master keys, and (on legacy builds before Microsoft's 2014 KB2871997 update [@ms-kb2871997]) WDigest plaintext passwords. The canonical target of credential-theft tooling since 2011.

The threat being mitigated is simple. Mimikatz reads LSASS memory via OpenProcess(PROCESS_VM_READ, lsass.exe), walks the internal key-store structures, and extracts NTLM hashes, Kerberos session keys, and (on older configurations) cached plaintext. Restricting SeDebugPrivilege does not work, because an attacker with SYSTEM has every privilege. Restricting the security descriptor on lsass.exe does not work either, because legitimate services need to interact with it. PPL is the right primitive: it gates the full mask irrespective of token state, and the kernel admits only Microsoft-signed code into the Lsa rung.

RunAsPPL = 1 is the stronger form of the setting on Secure Boot-capable machines. On the next boot, the kernel automatically mirrors the policy into a Secure Boot-anchored UEFI variable; once set, the protection survives registry rollback. An attacker who removes the registry key finds that LSASS still launches as PPL on the next boot. The only path to remove the protection is to disable Secure Boot at the firmware level, which requires physical access and which trips other defences. Microsoft Learn's documentation describes it verbatim [@learn-runasppl]:

You can achieve further protection when you use Unified Extensible Firmware Interface (UEFI) lock and Secure Boot. When these settings are enabled, disabling the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa registry key has no effect.

This is RunAsPPL = 1. For environments that need admin-removable protection without the UEFI lock, RunAsPPL = 2 (available on Win11 22H2 and later) omits the UEFI variable. The policy lives in the registry only and is removable by any administrator (or by malware running as administrator) who simply deletes the registry value before reboot.

`RunAsPPL` value	Behaviour	Removable by?	Persistence
`0` (or absent)	LSASS runs unprotected	n/a	none
`1`	LSASS runs as PPL/Lsa; policy mirrored to UEFI variable on Secure Boot machines	Physical access + Secure Boot disable	Firmware-anchored
`2`	LSASS runs as PPL/Lsa; registry only (Win11 22H2+ only)	Any admin who deletes the key	Registry only

Note: The RunAsPPL = 1 setting is the practical answer to "what stops an attacker who is willing to reboot?" Once the UEFI variable is set, neither registry rollback nor PE-based offline attacks on the registry hive can disable LSA protection on the next boot.

The deployment cost of RunAsPPL is compatibility with third-party authentication modules. LSASS hosts a set of plug-ins: smart-card middleware, third-party Cryptographic Service Providers (CSPs), password-filter DLLs, alternative authentication packages. Under RunAsPPL, the kernel demands that every DLL loaded into LSASS be Microsoft-signed at the LSA level (signer rung 4). Vendor DLLs that lack the right EKU are rejected at section creation. The rejections surface as CodeIntegrity events in the system event log. Microsoft Learn enumerates the two relevant event IDs [@learn-runasppl]:

Event 3065 occurs when a code integrity check determines that a process, usually LSASS.exe, attempts to load a driver that doesn't meet the security requirements for shared sections.

Event 3066 occurs when a code integrity check determines that a process, usually LSASS.exe, attempts to load a driver that doesn't meet the Microsoft signing level requirements.

This is why Microsoft recommends running the setting in audit mode before enforcement. Audit mode is enabled by setting a separate AuditLevel DWORD to 8, but -- critically -- under a different registry key from the one that hosts RunAsPPL. Microsoft Learn places AuditLevel under the Image File Execution Options hive for LSASS.exe and names the path verbatim [@learn-runasppl]:

Open the Registry Editor, or enter RegEdit.exe in the Run dialog, and then go to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\LSASS.exe registry key. Open the AuditLevel value. Set its data type to dword and its data value to 00000008.

Note: RunAsPPL sits under HKLM\SYSTEM\CurrentControlSet\Control\Lsa. AuditLevel = 8 sits under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\LSASS.exe. A defender who edits "the same key" silently sets the wrong value and audit mode never engages. The deployment looks correct from the registry; the log surface is empty; the rollout breaks production on enforcement day. Two values. Two hives. Read this twice.

In audit mode, the kernel emits the same 3065 / 3066 events for would-be load rejections but allows the loads to proceed. Two months of audit-mode telemetry typically surfaces every smart-card middleware DLL, every password-filter, every third-party CSP on a corporate fleet. Once the audit log is clean (every vendor's modules have been re-signed at the LSA level or replaced), enforcement mode can be turned on without breaking production logins.

Note: Skipping audit mode is the most common cause of LSA protection rollouts being rolled back after a wave of authentication failures. See §11 Item 1 for the full audit-then-enforce-then-UEFI-lock recipe.

The deployment cadence has been deliberately glacial. RunAsPPL shipped in Windows 8.1 in October 2013 -- opt-in. It remained opt-in for nine years. Microsoft Learn records the inflection [@learn-runasppl]:

Audit mode for added LSA protection is enabled by default on devices running Windows 11 version 22H2 and later.

Audit mode default-on. Not enforcement. The Windows 11 24H2 release expanded the audit-mode rollout further. Eleven years from opt-in to effective default. The pace reflects the compatibility risk: every domain with a single non-Microsoft-signed LSASS plug-in would have surfaced as a support call.

The registry knob is simple. The kernel check that enforces it is not. The next section walks the access-check pipeline in detail, because the structural reason SeDebugPrivilege cannot help an attacker is the order in which the kernel asks its questions.

7. The Kernel Access Check -- What Happens Inside `NtOpenProcess`

Recall the trace from Section 1. The denial happens before SeAccessCheck runs. The reason SeDebugPrivilege does not help is not that the kernel decided to override the privilege; it is that the kernel never asked about the privilege. The order matters. Let us walk it.

The Win32 caller invokes OpenProcess, which thunks through kernel32.dll to the syscall NtOpenProcess. NtOpenProcess does its handle-lookup and dispatches to the process-type object-manager open callback, PspProcessOpen. Ionescu's Part 2 names the path verbatim [@ionescu-part2]:

Access to protected processes (and their threads) is gated by the PspProcessOpen and PspThreadOpen object manager callback routines, which perform two checks. The first, done by calling PspCheckForInvalidAccessByProtection (which in turn calls RtlTestProtectedAccess and RtlValidProtectionLevel) ...

PspCheckForInvalidAccessByProtection does two things. First, it splits the caller's requested access mask into two subsets:

The limited mask -- a fixed set of bits (SYNCHRONIZE, PROCESS_QUERY_LIMITED_INFORMATION, and a small handful of others) that the lattice never forbids. The limited mask is subject only to the standard SeAccessCheck against the target's DACL.
The full mask -- everything else, including PROCESS_VM_READ, PROCESS_VM_WRITE, PROCESS_CREATE_THREAD, PROCESS_DUP_HANDLE, and PROCESS_ALL_ACCESS. The full mask is subject to the lattice rule.

The subset of `PROCESS_*` access rights that the PPL lattice always allows the standard `SeAccessCheck` to evaluate. Includes `SYNCHRONIZE`, `PROCESS_QUERY_LIMITED_INFORMATION`, `PROCESS_SET_LIMITED_INFORMATION`, and `PROCESS_SUSPEND_RESUME`. `PROCESS_TERMINATE` is included for callers below the Antimalware tier (deny mask `0xFC7FE`), but the kernel widens the deny mask to `0xFC7FF` at the `Antimalware`, `Lsa`, and `WinTcb` rungs -- bit 0, `PROCESS_TERMINATE` -- making those three rungs unkillable except from peers or higher.

Second, it indexes into RtlProtectedAccess[] using the caller's signer rung and the target's type, retrieves the row of permissible access bits, and ANDs the row with the full mask. If the result is non-empty, the access proceeds; if the result is zero, the kernel strips the full-mask bits from the request and returns either the limited subset (if the caller asked for any limited bits) or STATUS_ACCESS_DENIED. RtlValidProtectionLevel runs alongside as a sanity check on the encoded byte to catch malformed EPROCESS.Protection values that would otherwise let the lattice walk off the end of the table.

sequenceDiagram participant App as Caller (any token) participant Nt as NtOpenProcess participant PsPO as PspProcessOpen participant Chk as PspCheckForInvalidAccessByProtection participant Rtl as RtlTestProtectedAccess + RtlValidProtectionLevel participant Tab as RtlProtectedAccess[] table participant SAC as SeAccessCheck App->>Nt: NtOpenProcess(DesiredAccess) Nt->>PsPO: dispatch PsPO->>Chk: protection check Chk->>Rtl: lookup caller / target rungs Rtl->>Tab: index row, retrieve allowed bits Tab-->>Rtl: row of allowed access bits Rtl-->>Chk: full mask allowed or stripped Chk-->>PsPO: residual mask (full or limited) PsPO->>SAC: residual mask vs DACL + token SAC-->>Nt: final mask Nt-->>App: handle or STATUS_ACCESS_DENIED

Key idea: The protection check runs before SeAccessCheck. Privileges are evaluated by SeAccessCheck. The reason SeDebugPrivilege does not help is structural -- it is not consulted at the moment of denial.

Four worked traces make this concrete.

Case (a): admin -> lsass with PROCESS_ALL_ACCESS. The caller has no EPROCESS.Protection.Type (it is None). The target is PPL/Lsa. The lattice forbids the full mask. The kernel strips every bit of PROCESS_ALL_ACCESS except the limited subset. The caller wanted to write memory; the limited subset cannot write memory; the operation effectively fails. This is the Mimikatz scenario.

Case (b): admin -> lsass with PROCESS_QUERY_LIMITED_INFORMATION. Same caller, same target, but the requested mask sits entirely in the limited subset. The lattice does not gate the limited mask. SeAccessCheck evaluates the DACL on lsass.exe, finds that administrators are permitted to query basic process information, and the call succeeds. This is why Process Explorer can still enumerate lsass.exe and show its threads even when LSA protection is enabled.

Case (c): MsMpEng.exe (PPL/Antimalware, rung 3) -> lsass.exe (PPL/Lsa, rung 4) with PROCESS_VM_READ. The lattice rule: caller rung 3 < target rung 4, so the full mask is denied. Defender cannot read LSASS memory. Defender does not need to; the cross-rung isolation prevents one Microsoft service from reading another Microsoft service's secrets even within the same trusted system.

Case (d): hypothetical PPL/WinTcb (rung 6) -> lsass.exe (PPL/Lsa, rung 4) with PROCESS_VM_READ. The lattice rule: caller rung 6 >= target rung 4, so the full mask is allowed. A process signed at the WinTcb rung can read LSASS memory by design. This is how Service Control Manager and Windows Error Reporting can still interact with protected lsass.exe.

Caller	Target	Mask	Lattice rule	Outcome
Admin, no Protection	PPL/Lsa	PROCESS_ALL_ACCESS	Caller has no rung	Full mask stripped (denied)
Admin, no Protection	PPL/Lsa	PROCESS_QUERY_LIMITED_INFORMATION	Limited mask	Allowed (DACL permitting)
PPL/Antimalware (3)	PPL/Lsa (4)	PROCESS_VM_READ	3 < 4	Denied
PPL/WinTcb (6)	PPL/Lsa (4)	PROCESS_VM_READ	6 >= 4	Allowed

The Audit bit revisits the table from a different angle. The bit is annotated Reserved in itm4n's public structure definition and named without semantic gloss in Ionescu Part 1; the precise runtime emission shape on an OpenProcess denial is not enumerated in any of Ionescu Part 1, Forshaw 2018, itm4n's RunAsPPL writeup, or Microsoft Learn's RunAsPPL page (whose CodeIntegrity events 3033/3063/3065/3066 are scoped to AuditLevel under IFEO\LSASS.exe and to DLL-load failures, not per-process Audit-bit denials) [@ionescu-part1] [@itm4n-runasppl] [@learn-runasppl]. The field name and bit position imply a forensic side-channel; the exact event shape is not in the public record.Two adjacent kernel mechanisms exist in the same neighbourhood but mediate different threat models. PROCESS_TRUST_LABEL_ACE (a Trust SID ACL entry, introduced in Windows 8.1 alongside PPL) is an ACL-side companion that runs inside SeAccessCheck -- it adds a token-style trust label that interacts with the security descriptor in the standard way. Code Integrity Guard (ProcessSignaturePolicy) is a per-process signed-image enforcer settable at CreateProcess time via the PROC_THREAD_ATTRIBUTE_MITIGATION_POLICY attribute. Neither is part of PPL; both interact with the same problem space.

The kernel verifies who is asking, what they are asking for, and at what rung the target sits. What the kernel cannot verify is the behaviour of code that arrives through a signed channel and then executes against attacker-controlled data. That structural seam is the entire premise of the bypass arms race, and it is the next section.

8. The Bypass Arms Race -- Forshaw, itm4n, Landau

If the kernel only verifies the channel by which code enters a PPL, every bypass should attack the seam between channel and behaviour. Test that prediction against the public record. Since 2018, four named bypass acts have hit major Microsoft research blogs. All four sit in the same structural class.

Key idea: The kernel verifies the channel. It does not verify the behaviour. Every public PPL bypass since 2018 attacks the seam between what the channel proves (a signature, an EKU, a section identity) and what the code does once mapped.

Act I (2018) -- Forshaw and JScript-into-PPL

James Forshaw, then at Google Project Zero, published "Injecting Code into Windows Protected Processes Using COM" in October 2018 [@forshaw-2018-10]. The mechanism: a PPL can be made to instantiate a COM object whose CLSID resolves to scrobj.dll, the Microsoft-signed Windows Script Component scripting host. Once loaded into the PPL, the script object accepts attacker-supplied source code and executes it inside the protected process. The DLL is signed. The kernel admits it. The kernel cannot reason about the JScript source it then runs.

Microsoft's fix in Windows 10 1803 (April 2018, deployed broadly through that year) was a hardcoded deny-list in CI.DLL. Forshaw's own writeup gives the source verbatim [@forshaw-2018-10]:

UNICODE_STRING g_BlockedDllsForPPL[] = {
    DECLARE_USTR("scrobj.dll"),
    DECLARE_USTR("scrrun.dll"),
    DECLARE_USTR("jscript.dll"),
    DECLARE_USTR("jscript9.dll"),
    DECLARE_USTR("vbscript.dll")
};

NTSTATUS CipMitigatePPLBypassThroughInterpreters(
    PEPROCESS Process, LPBYTE Image, SIZE_T ImageSize)
{
    if (!PsIsProtectedProcess(Process)) return STATUS_SUCCESS;
    // walk g_BlockedDllsForPPL; if any match, return STATUS_DYNAMIC_CODE_BLOCKED
    ...
}

Five DLLs, hardcoded. Microsoft Learn corroborates the policy on the user-facing side [@learn-am-services]:

The following scripting DLLs are forbidden by CodeIntegrity inside a protected process: scrobj.dll, scrrun.dll, jscript.dll, jscript9.dll, and vbscript.dll.

Channel: a Microsoft-signed DLL. Behaviour: arbitrary attacker script. The fix narrows the channel by name-listing the five DLLs known to admit attacker behaviour. The class survives.The mechanism was previewed at Recon Montreal 2018 in the joint Forshaw-Ionescu talk "Unknown Known DLLs and other Code Integrity Trust Violations" (June 15-17, 2018) [@recon-mtl-2018]. Forshaw's August 2017 "Bypassing VirtualBox Process Hardening" essay [@forshaw-2017-vbox] is the structural precursor -- it makes the same channel-vs-behaviour argument against a different kernel-supported process-hardening regime.

Act II (2018-2021) -- DefineDosDevice and PPLdump

In his August 2018 post on object-directory exploits [@forshaw-2018-08], Forshaw added a single throwaway sentence that the security community would spend three years productising. itm4n quotes it verbatim in his 2021 SCRT walkthrough [@itm4n-scrt]:

Abusing the DefineDosDevice API actually has a second use, it's an Administrator to Protected Process Light (PPL) bypass.

The mechanism, fully worked out by itm4n in April 2021, is structural and uses that same primitive. As an administrator, call DefineDosDevice to create a symbolic link in \KnownDlls\ (the object-directory subkey that the loader uses for fast known-DLL lookups). The call is dispatched via RPC to csrss.exe, which runs at PPL/WinTcb (rung 6) and so has the lattice authority to write into protected directories. The administrator gets a \KnownDlls\ entry pointing at an attacker-controlled section. Now start a PPL. The PPL's loader resolves DLL names through \KnownDlls\ and finds the administrator's entry. The PPL maps the attacker's section without re-validating its on-disk signature, because \KnownDlls\ is the kernel's vouched-for fast path.

itm4n's PPLdump tool, published April 2021, automated the attack. The README test matrix lists every Windows version it ran against [@ppldump-repo]. For fifteen months, an administrator could dump any PPL's memory, including lsass.exe, despite RunAsPPL.

Microsoft's fix arrived in build 19044.1826 (the July 2022 update to Windows 10 21H2). itm4n's "End of PPLdump" writeup describes the patch and the BinDiff diff verbatim [@itm4n-end-of-ppldump]:

The conclusion is that PPLs now appear to be behaving just like PPs and therefore no longer rely on Known DLLs.

The fix patched LdrpInitializeProcess in NTDLL to skip \KnownDlls\ for PPL processes, behind a Velocity feature flag (Feature_Servicing_2206c_38427506__private_IsEnabled). PPLdump's repository README now opens with [@ppldump-repo]:

2022-07-24 - As of Windows 10 21H2 10.0.19044.1826 (July 2022 update), the exploit implemented in PPLdump no longer works. A patch in NTDLL now prevents PPLs from loading Known DLLs.

itm4n's structural finding -- that *PPLs honoured \KnownDlls\ while PPs did not* -- is the most interesting failure in the eight-year run, because the asymmetry sat in plain sight from 2013 to 2022 and nobody had asked "why are PPs and PPLs loading sections differently?" The fix closes one asymmetry. The structural class survives.PPLdump's substitution chain uses NTFS transactions and Forrest Orr's "phantom DLL hollowing" technique to materialise the attacker-controlled section on disk in a way the kernel section creator will accept [@forrest-orr-hollow]. Orr's writeup is the original publication of the hollowing primitive; PPLdump composes it with the \KnownDlls\ redirection trick.

Act III (2022-2024) -- Landau's PPLFault CI TOCTOU

Gabriel Landau, then at Elastic, presented "PPLdump Is Dead. Long Live PPLdump!" at Black Hat Asia 2023 [@bh-asia-2023-pdf]. The mechanism is a Time-Of-Check / Time-Of-Use bug at the section-creation layer.

A class of bug in which a security property is verified at one point in time but the underlying object is mutable between the check and the use. The protected resource passes its check, then changes between check and access, and the operation proceeds against the changed state without re-verification.

The TOCTOU here is subtle. When a PPL calls NtCreateSection on a Microsoft-signed DLL, the kernel's memory manager calls MiValidateSectionCreate, which calls into ci.dll to verify the file's Authenticode signature. The check succeeds. The section is created. But the memory manager does not page in the file contents at section-create time; it pages them in lazily, on demand, when threads first touch the mapped pages. If an attacker can keep the section's backing file unsubstituted during the signature check and substituted during the lazy page-in, the kernel will execute attacker bytes through a section whose signature it already verified.

Landau's exploit uses Windows' CloudFilter API. An attacker holds an exclusive oplock on a Microsoft-signed DLL during the section-create signature check. After the check passes, the attacker's CloudFilter FetchDataCallback provides different bytes (the payload) when the kernel pages in the section. The PPL maps and executes the payload. Landau's Elastic post documents the chain verbatim [@elastic-pplfault]:

The internal memory manager function MiValidateSectionCreate relies on the Code Integrity module ci.dll to handle the requisite cryptography and PKI policy.

Microsoft's fix shipped in Windows Insider Canary build 25941 on September 1, 2023 [@elastic-pplfault]:

On September 1, 2023, Microsoft released a new build of Windows Insider Canary, version 25941 ... Build 25941 includes improvements to the Code Integrity (CI) subsystem that mitigate a long-standing issue that enables attackers to load unsigned code into Protected Process Light (PPL) processes.

The fix narrows the immediate channel by extending page-hash validation to PPL-loaded images that reside on remote (SMB redirector) paths -- the precise surface that PPLFault required to drive its CloudFilter FetchDataCallback substitution [@elastic-pplfault]. Locally-cached PPL DLL loads continue to rely on the section-create signature check, so the structural seam survives. The GA patch shipped on February 13, 2024 [@pplfault-repo]:

2024-02 UPDATE: Microsoft patched PPLFault on 2024-02-13.

Channel: a signed Microsoft DLL whose hash matched at section create. Behaviour: attacker payload mapped via the lazy page-in. The fix narrows the channel by widening the verification surface from "the file at section-create time" to "every page at fault time." The class survives.

Act IV (2022-2024) -- BYOVDLL and itm4n's KeyIso chain

Bring Your Own Vulnerable DLL. Coined by Gabriel Landau on Twitter in October 2022 (itm4n screenshots the original tweet [@itm4n-ghost-part1]; tweet status 1580067594568364032). Productised by itm4n in August 2024 in "Ghost in the PPL Part 1."

A bypass class against any signature-gated security mechanism in which the attacker loads a *legitimately signed but historically vulnerable* binary and exploits the known vulnerability inside it. The signature check passes; the vulnerability does the work. The structural property that makes the class hard to fix is that the kernel cannot deny-list legitimately signed older Microsoft DLLs without breaking the deployments that still depend on them.

itm4n's specific chain targets the CNG Key Isolation service ("KeyIso"), which runs in lsass.exe and so inherits its PPL/Lsa protection. The chain is precise [@itm4n-ghost-part1]:

As administrator, stop the KeyIso service.
Set HKLM\SYSTEM\CurrentControlSet\Services\KeyIso\Parameters\ServiceDll to point at an older keyiso.dll extracted from Microsoft update KB5023778. This DLL is Microsoft-signed; the kernel admits it.
Restart the KeyIso service. The older keyiso.dll loads into LSASS at PPL/Lsa.
Trigger CVE-2023-36906, an out-of-bounds read information disclosure in the older keyiso.dll, to leak an address.
Trigger CVE-2023-28229, one of six use-after-frees in the same DLL, to obtain control of a CALL target via the RAX register.
Execute attacker code at PPL/Lsa.

The CVEs are real and tracked. k0shl's writeup is the primary root-cause analysis [@k0shl-keyiso]:

Microsoft patched vulnerabilities I reported in CNG Key Isolation service, assigned CVE-2023-28229 and CVE-2023-36906, the CVE-2023-28229 included 6 use after free vulenrabilities with similar root cause and the CVE-2023-36906 is a out of bound read information disclosure.

NVD records both [@nvd-2023-28229] [@nvd-2023-36906]. Y3A's GitHub repository [@y3a-cve-poc] provides a public PoC for CVE-2023-28229 that itm4n's chain composes.

Channel: an actually-Microsoft-signed DLL. Behaviour: the memory-safety vulnerability inside it. There is no general fix announced. Microsoft fixed the specific CVEs by shipping a newer keyiso.dll, but the older DLL remains in circulation (it ships inside every patched cumulative update bundle), and a kernel that has to admit every legitimately signed older Microsoft DLL has no general defense against the next CVE-of-the-month.

Note: BYOVDLL has no general patch. Microsoft fixes each underlying CVE on the standard cumulative-update cadence. The class persists for as long as the kernel admits older signed Microsoft DLLs into PPLs, which is for as long as legitimately deployed software depends on the older DLLs.

timeline title PPL Bypass Arms Race (2018-2024) 2018-10 : Forshaw JScript-into-PPL : Fix 1803 Apr 2018 : g_BlockedDllsForPPL deny-list 2021-04 : itm4n PPLdump (KnownDlls) : Fix Jul 2022 build 19044.1826 : LdrpInitializeProcess patch 2022-09 : Landau PPLFault (TOCTOU) : Fix Feb 2024 13 GA : CI page-hash for PPLs 2024-08 : itm4n BYOVDLL KeyIso chain : No general fix : CVEs patched piecewise

Act	Year	Channel verified	Behaviour exploited	Microsoft fix	Fix date
I	2018	Microsoft-signed `scrobj.dll`	JScript source executed by COM object	`g_BlockedDllsForPPL` deny-list of 5 DLLs	Apr 2018 (1803)
II	2021	`\KnownDlls\` symlink (CSRSS-blessed)	Attacker section mapped without re-validation	NTDLL `LdrpInitializeProcess` patch	Jul 2022 (19044.1826)
III	2023	Signed DLL passed `MiValidateSectionCreate`	CloudFilter substitutes bytes on lazy page-in	`/INTEGRITYCHECK` page hashes for PPLs	Feb 2024 (GA)
IV	2024	Legitimately-signed older `keyiso.dll`	Use-after-free + OOB read (CVE-2023-28229, CVE-2023-36906)	None (CVE-by-CVE)	open

flowchart TD A[Admin stops KeyIso service] B[Repoint ServiceDll to older keyiso.dll
from KB5023778] C[Restart KeyIso service] D[Older keyiso.dll loads
into lsass.exe PPL/Lsa] E[Trigger CVE-2023-36906
OOB read for info leak] F[Trigger CVE-2023-28229
UAF for RAX control] G[Code execution at PPL/Lsa] A --> B --> C --> D --> E --> F --> G itm4n explicitly attributes the BYOVDLL framing to Landau's October 2022 tweet, even though itm4n's KeyIso chain is the first public productisation. The attribution chain matters because it documents how a one-line research observation (Twitter status 1580067594568364032, screenshot preserved in [@itm4n-ghost-part1]) became a working exploit two years later. The pattern repeats in this domain: Forshaw's one-sentence DefineDosDevice comment to PPLdump (3 years); Landau's BYOVDLL tweet to itm4n's KeyIso chain (2 years). The structural class outlives its discoverer.

Four acts, one class. Every public bypass since 2018 has lived in the same narrow shape: code that becomes part of a PPL through a signed channel and executes attacker-influenced data once mapped. Each generation of fix narrows what the channel admits -- name-list five DLLs; ignore \KnownDlls\; page-hash every section; CVE-patch every vulnerable older DLL. The class survives because the kernel cannot reason about behaviour. By Rice's theorem it cannot reason about behaviour in general; in practice, it has nowhere even to start.

If lsass.exe code execution is reachable through BYOVDLL, where are the actual secrets? Not in lsass.exe. Not anywhere the kernel can read at all. The next section is the companion boundary.

9. The Companion Boundary -- Credential Guard, VBS, and `LsaIso.exe`

itm4n opens his RunAsPPL walkthrough with a warning [@itm4n-runasppl]:

I noticed that this protection tends to be confused with Credential Guard, which is completely different.

The confusion is understandable. Both run on Windows. Both protect LSASS. Both are configured by domain administrators. Both yield "ACCESS_DENIED" to Mimikatz when working correctly. They are nonetheless answering different questions, and they stack rather than replace each other.

PPL stops an administrator from reading kernel-trusted user-mode memory. It does nothing against a kernel-mode attacker who can simply zero the Protection byte in the target EPROCESS. The kernel-mode attacker is the next threat-model rung up, and the kernel-mode attacker is the threat that Credential Guard answers, by moving the credentials themselves out of lsass.exe entirely.

A Hyper-V-based isolation regime in which the Windows hypervisor partitions the system into Virtual Trust Levels (VTLs). VTL0 contains the normal Windows kernel and user-mode processes. VTL1 contains the Secure Kernel and a small set of user-mode trustlets. Memory in VTL1 is inaccessible to VTL0, even from VTL0 kernel-mode code. A user-mode process running inside VTL1. Trustlets are Microsoft-signed at a specific protected-process equivalent rung within VTL1 and serve as the user-mode hosts for VBS-isolated functionality. `LsaIso.exe` is the trustlet that holds the actual credential material on Credential Guard-enabled hosts.

The architecture is, at the highest level, three layers: VTL0 user-mode, VTL0 kernel, and VTL1 (Secure Kernel plus trustlets). On a Credential Guard-enabled host, lsass.exe still exists in VTL0 user-mode, still protects itself with PPL/Lsa, and still answers authentication requests. But it no longer holds the NTLM hashes, Kerberos TGT keys, or Cred Manager domain credentials. Those secrets live in LsaIso.exe, a trustlet in VTL1. When LSASS needs to authenticate a credential, it makes a hypercall into VTL1, and LsaIso.exe performs the cryptographic operation entirely within VTL1 memory, returning only the result. The keys never leave VTL1.

Microsoft's documentation states the threat model directly [@learn-cg]:

Credential Guard prevents credential theft attacks by protecting NTLM password hashes, Kerberos Ticket Granting Tickets (TGTs), and credentials stored by applications as domain credentials.

Credential Guard uses Virtualization-based security (VBS) to isolate secrets so that only privileged system software can access them.

Malware running in the operating system with administrative privileges can't extract secrets that are protected by VBS.

The third sentence is the load-bearing one. Malware running with administrative privileges maps cleanly to a PPL bypass that achieves code execution at PPL/Lsa. Even from inside lsass.exe, the secrets are not there.

flowchart TD subgraph VTL0[VTL0 normal world] Admin[Admin / SYSTEM token] Lsass[lsass.exe at PPL/Lsa] Kern0[VTL0 kernel] end subgraph VTL1[VTL1 secure world] SK[Secure Kernel] Iso[LsaIso.exe trustlet] Secrets[NTLM hashes, Kerberos TGT keys] end Admin -- "PPL barrier (lattice)" --x Lsass Lsass -- hypercall --> Iso Kern0 -- "VBS barrier (VTL boundary)" --x Iso Iso --> Secrets

The two mechanisms stack rather than overlap. PPL prevents an admin from OpenProcess(PROCESS_VM_READ, lsass) at the user-mode lattice level. Credential Guard prevents a kernel-mode attacker who succeeds against PPL from finding the keys, because the keys are in VTL1 memory that the VTL0 kernel cannot read at all. itm4n's "complementary" framing in the RunAsPPL writeup is the right operational summary [@itm4n-runasppl]: deploy both, always both.

Note: PPL gates user-mode admins out of LSASS code memory. Credential Guard gates everything else (kernel-mode attackers, BYOVDLL execution-at-PPL/Lsa) out of the secrets themselves by moving the secrets to VTL1. Each mechanism answers a layer of the threat model the other does not.

Dimension	PPL (LSA protection)	Credential Guard
Threat model	Administrator -> user-mode LSASS	VTL0 kernel + admin -> credential material
Layer	VTL0 user-mode lattice	VTL0 / VTL1 VBS boundary
Kernel-mode attacker	Cannot stop them	Stops them (VBS-isolated memory)
MSRC classification	Defense in depth	Security boundary
Default-on (consumer)	Audit mode, Win11 22H2	n/a (enterprise)
Default-on (enterprise)	Audit mode, Win11 22H2	Enabled, Win11 22H2 / Win Server 2025 (domain-joined non-DC)

The architecture of `LsaIso.exe`, its trustlet ID, its IUM EKU, and the hypercall plumbing between LSASS and the trustlet are the subject of a separate article in this series ("VBS Trustlets: What Actually Runs in the Secure Kernel"). The cross-link is deliberate: PPL and Credential Guard are paired in practice, but the architectural depth of VTL1 is its own subject.

Credential Guard's default-on rollout, recorded in Microsoft Learn [@learn-cg]:

Starting in Windows 11, 22H2 and Windows Server 2025, Credential Guard is enabled by default on domain-joined, non-DC systems that meet hardware requirements.

Two stacked mechanisms; one classified as a security boundary, one not. The next section asks what the classification means.

10. Where PPL Isn't a Security Boundary -- Microsoft's Servicing Criteria

Gabriel Landau's "Inside Microsoft's Plan to Kill PPLFault" essay states the classification in one sentence [@elastic-pplfault]:

Microsoft does not consider PPL to be a security boundary, meaning they won't prioritize security patches for code-execution vulnerabilities discovered therein, but they have historically addressed some such vulnerabilities on a less-urgent basis.

Microsoft's "Windows Security Servicing Criteria" defines the term security boundary directly [@msrc-servicing]:

A security boundary provides a logical separation between the code and data of security domains with different levels of trust. For example, the separation between kernel mode and user mode is a classic [...] security boundary.

A logical separation between code and data of security domains with different levels of trust. Microsoft commits to servicing security boundary violations with out-of-band patches when the severity bar is met. The kernel-mode / user-mode separation is the canonical example. Per Microsoft's published servicing criteria, PPL is *not* on the security-boundary list. A security feature that raises the cost of an attack without guaranteeing prevention. Microsoft treats defense-in-depth features as servicing targets on the standard cumulative-update cadence, not as out-of-band patch priorities. PPL falls into this category per Microsoft's published classification.

The relevant excerpts of the criteria page enumerate which surfaces are and are not boundaries. The live MSRC page renders that enumeration table client-side via JavaScript; the raw HTML returned by automated fetchers contains only the React shell. The text of the enumeration is preserved in the Wayback Machine capture at archive date 2023-05-06 [@msrc-criteria-archive], and Landau's follow-on Elastic post quotes the relevant administrative-process row verbatim [@elastic-byovd-admin]:

Administrative processes and users are considered part of the Trusted Computing Base (TCB) for Windows and are therefore not strong[ly] isolated from the kernel boundary.

The corresponding row for PPL is the same shape: administrative-process-to-PPL is not isolated as a security boundary. Landau filed VULN-074311 with MSRC in September 2022 disclosing both an admin-to-PPL and a PPL-to-kernel zero-day. The Elastic post records MSRC's classification of the disclosure verbatim [@elastic-byovd-admin]:

MSRC similarly does not consider admin-to-PPL a security boundary, instead classifying it as a defense-in-depth security feature.

The MSRC servicing-criteria page's *definition* of "security boundary" is retrievable from raw HTML and verified against the live page. The *enumeration* of which Windows surfaces are or are not boundaries lives in a client-side rendered table and is not present in the raw HTML payload. The verifiable trail for "PPL is excluded from the boundary list" is the Wayback Machine capture combined with Elastic's verbatim quotation of MSRC's classification.

The operational consequence is direct. A published PPL bypass does not trigger an out-of-band patch. It is fixed on the next major-release cadence, sometimes faster if Microsoft has internal motivation. The disclosure-to-fix half-lives are public record:

Bypass	Disclosed	Microsoft fix	Disclosure-to-fix
Forshaw 2018 JScript-into-PPL	Oct 2018	Apr 2018 (1803, pre-disclosure)	~0 months (Microsoft fixed first)
itm4n 2021 PPLdump (KnownDlls)	Apr 2021	Jul 2022 (build 19044.1826)	~15 months
Landau 2023 PPLFault (CI TOCTOU)	Apr-Sep 2023	Feb 2024 (GA)	~5-11 months
itm4n 2024 BYOVDLL (KeyIso chain)	Aug 2024	none (open, CVE-by-CVE)	open

Note: A correctly classified PPL bypass is fixed on the standard cumulative-update cadence, not out-of-band. The implication for defenders is operational: PPL is exactly as strong as the engineering velocity Microsoft chooses to invest in it. Treat detection (Section 11) and the Credential Guard companion (Section 9) as load-bearing.

The reader takeaway is the third Aha moment of the article. PPL is real, kernel-enforced, structurally elegant, and demonstrably effective against the threat it was designed for (administrator-from-user-mode reads of LSASS). It is also explicitly not a security boundary per Microsoft's own published servicing policy, and that classification is the most important fact about it. Plan for bypasses. Stack with Credential Guard. Treat detection as primary, not secondary.

11. Practical Guide -- Configuring, Verifying, and Monitoring PPL

If you are deploying PPL on a corporate fleet, run this checklist. The order is deliberate: audit before enforce, verify before trust the verifier, and detect because no static control survives unmotivated.

Deploy

Note: Enable AuditLevel = 8 under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\LSASS.exe for two months [@learn-runasppl]. This is a different registry hive from RunAsPPL (which lives under HKLM\SYSTEM\CurrentControlSet\Control\Lsa); mixing the two values up is the most common Stage 0 deployment error (see §6). Collect CodeIntegrity events 3065 and 3066 to enumerate every LSASS plug-in that would fail enforcement (smart-card middleware, third-party CSPs, password-filter DLLs). Re-sign or replace the failing modules. Set RunAsPPL = 1 on Secure Boot-capable machines; the kernel automatically stores the policy in a UEFI variable. RunAsPPL = 2 (Win11 22H2+) is the softer option that omits the UEFI variable for environments requiring admin-removable protection.

Note: For third-party EDR, confirm the agent daemon runs at PPL/Antimalware (signer rung 3, byte 0x31). Process Explorer exposes this via View -> Select Columns -> Protection. System Informer (the modern Process Hacker fork that itm4n recommends in his BYOVDLL writeup [@itm4n-ghost-part1]) shows the same field in its process list. If your EDR is not running at PPL/Antimalware, it does not have the kernel's protection against admin tampering even when its vendor claims "protected" in marketing material. Process Explorer's "Protection" column ships in the canonical Sysinternals distribution [@sysinternals-procexp]; it reads EPROCESS.Protection via the NtQueryInformationProcess entry point [@learn-ntqueryinfoproc], although the specific ProcessProtectionInformation information-class value is not enumerated in the public Learn PROCESSINFOCLASS table -- the value is community-documented from Windows headers and reverse engineering rather than from a Microsoft Learn API reference.

Verify

Note: On a host you suspect of misconfiguration, attach WinDbg to the kernel and run !process 0 7 lsass.exe. The output includes the _PS_PROTECTION byte. Decode it with the formula from §3 above: ((value & 0xF0) >> 4) is the signer rung; value & 0x07 is the type; (value >> 3) & 1 is the audit bit. A RunAsPPL = 1 host yields 0x41 (PPL + Lsa). The Defender service yields 0x31 (PPL + Antimalware). csrss.exe yields 0x61 (PPL + WinTcb). If lsass.exe shows 0x00, the registry policy did not take effect on this boot.

{function decode(b) { const t = b & 0x07, a = (b >> 3) & 0x01, s = (b >> 4) & 0x0F; const tn = ['None', 'ProtectedLight', 'Protected']; const sn = ['None','Authenticode','CodeGen','Antimalware', 'Lsa','Windows','WinTcb','Max']; return '0x' + b.toString(16).padStart(2,'0') + ' = ' + (sn[s] || s) + '-' + (tn[t] || t) + (a ? ' (Audit on)' : ''); } // Three benchmark values you should be able to recognise by sight console.log(decode(0x31)); // MsMpEng.exe (Defender at PPL/Antimalware) console.log(decode(0x41)); // lsass.exe under RunAsPPL=1 console.log(decode(0x61)); // csrss.exe (PPL/WinTcb)}

Monitor

Note: The CodeIntegrity provider emits three event IDs that matter for PPL monitoring [@learn-runasppl]: | Event ID | Provider | What it tells you | |---|---|---| | 3033 | Microsoft-Windows-CodeIntegrity | A DLL load was blocked by CI (PPL or otherwise) | | 3063 | Microsoft-Windows-CodeIntegrity | Enforcement-mode: LSASS plug-in failed the shared-section security requirement (complement of audit-mode event 3065) | | 3065 | Microsoft-Windows-CodeIntegrity | LSASS plug-in failed the shared-section requirement | | 3066 | Microsoft-Windows-CodeIntegrity | LSASS plug-in failed the Microsoft signing level requirement | Sysmon Event 10 (ProcessAccess) captures OpenProcess denials with the requested access mask and is the cheapest detection for a Mimikatz-shaped attempt against an RunAsPPL-protected lsass.exe. A burst of 3033 events from a non-Microsoft process targeting lsass.exe is the canonical signal that a PPL bypass attempt is under way.

Note: PPL prevents admin-from-user-mode reads of LSASS. Credential Guard prevents kernel-mode reads of the credentials themselves (and BYOVDLL-style execution at PPL/Lsa). Deploy both. itm4n's "complementary" framing in his RunAsPPL writeup [@itm4n-runasppl] is the right operational model. On Win11 22H2 and Windows Server 2025, Credential Guard is default-on for domain-joined non-DC systems with VBS-capable hardware [@learn-cg]; on older fleets, enable it explicitly via Group Policy or the Device Guard / Credential Guard configuration script. Always both -- either alone leaves a layer of the threat model uncovered.

Note: If you are an EDR vendor wanting your daemon to run at PPL/Antimalware, the path is fixed [@learn-mvi] [@learn-am-services]: 1. Hold Microsoft Virus Initiative membership; maintain independent-lab certification (AV-Comparatives, AV-Test, SE Labs, MRG Effitas, SKD Labs, VB 100, West Coast Labs, AVLab Cybersecurity Foundation). 2. Author an ELAM driver with an embedded <ELAM> resource section enumerating your user-mode binary signing-certificate hashes. 3. Submit the driver through WHQL for Microsoft co-signing. 4. Use Trusted Signing for your user-mode binaries. 5. Verify with Process Explorer that the service launches at PPL/Antimalware after install.

Practitioners who follow the checklist still need to know the common misconceptions. The next section catalogues them.

12. FAQ -- Common Misconceptions

Seven questions practitioners ask after their first PPL deployment.

Yes for full-access termination via `OpenProcess(PROCESS_TERMINATE, ...)`; an admin without a higher signer rung cannot terminate a `PPL/Antimalware` daemon by a direct kill. No for legitimate uninstall: the vendor's MSI installer (or equivalent) typically signals the daemon to shut itself down through its own service-control path, which is gated by ACL and not by the PPL lattice. Operationally, expect administrators to be able to uninstall your EDR but not to terminate its main process from outside the vendor toolchain. No. itm4n's verbatim warning is worth repeating [@itm4n-runasppl]: "I noticed that this protection tends to be confused with Credential Guard, which is completely different." PPL protects `lsass.exe` *as a process* from admin-from-user-mode reads. Credential Guard moves the *credentials themselves* into VTL1 memory via VBS. PPL is a VTL0 user-mode lattice control. Credential Guard is a VTL0 / VTL1 hypervisor boundary. They stack; see Section 9 for the layering and Section 11 Item 5 for the deployment recommendation. Because Microsoft has not classified PPL as a security boundary. The Windows Security Servicing Criteria define a security boundary as a logical separation between security domains at different levels of trust, and Microsoft's published enumeration excludes administrative-process-to-PPL from that list [@msrc-servicing] [@elastic-byovd-admin]. PPL is treated as a defense-in-depth feature. The operational implication is that PPL bypasses are fixed on the next major release cadence rather than out-of-band, with disclosure-to-fix half-lives ranging from approximately five to fifteen months historically (see Section 10 for the data). Practically no for non-AV applications. The protected-process EKU OIDs are gated by Microsoft's certificate authorities; only the Antimalware rung admits third-party certificates, and admission is mediated by ELAM driver + Microsoft Virus Initiative membership [@learn-mvi]. Hobbyist tooling cannot opt in. There is no public path for a non-AV third-party application to claim a PPL rung. If your application requires PPL-style anti-tampering, the realistic options are (a) become an MVI member if your application is an AV/EDR, (b) use Process Mitigation Policies such as Code Integrity Guard for code-injection resistance, or (c) deploy your sensitive operations inside a separate Microsoft-signed service. "Protected service" is informal terminology for a Windows service whose host process runs as a PPL, with the Service Control Manager configured to launch it at a specific signer rung. The deployment plumbing (SCM service configuration, service-DLL packaging, the signing of the host binary) is what makes a service "protected." The PPL machinery is what makes the host process actually resistant to tampering. The two terms describe the same thing from different angles -- one from the SCM-management view, one from the kernel-access-check view. Only if the smart-card middleware DLL is not signed at the LSA level (signer rung 4). Most major smart-card vendors have updated their middleware to be Microsoft-signed at the required level, but legacy or in-house middleware frequently fails enforcement. The recommended workflow is to run `AuditLevel = 8` for two months [@learn-runasppl], collect CodeIntegrity 3065 / 3066 events, enumerate the failing modules, re-sign or replace them, and only then switch to `RunAsPPL = 1`. Skipping the audit period is the single most common cause of authentication outages during LSA protection rollouts. Because the threat model PPL answers is *administrator-from-user-mode*, not *administrator-from-kernel-mode*. PPL is a kernel-enforced gate in the access-check pipeline, but a kernel-mode driver that can write to `EPROCESS.Protection` can zero the byte and disable the gate for any process. The defense against the kernel-mode attacker is a different mechanism: VBS-isolated credentials in VTL1 (Credential Guard), with HVCI / kernel-mode integrity controls preventing arbitrary kernel-mode code from running in the first place. PPL stops one threat; Credential Guard stops the threat one rung up; and the two are intended to be deployed together (Section 9, Section 11 Item 5).

The arc has run from a single Mimikatz error code to a kernel-enforced lattice, a third-party admission path mediated by ELAM and MVI, an arms race shaped by a single structural insight that the kernel verifies the channel and not the behaviour, and a stacked companion boundary that lives in VTL1 because VTL0 has run out of places to hide a key. PPL is not a security boundary. That classification is not a footnote; it is the most important fact about it, because it tells defenders that the mechanism is exactly as strong as the engineering velocity Microsoft chooses to invest. Deploy it. Stack it with Credential Guard. Monitor for the next bypass.

Key idea: The kernel verifies the channel. It does not verify the behaviour. Every PPL bypass since 2018 has lived in that seam, every fix has narrowed the channel, and the seam survives because behaviour is, by Rice's theorem, structurally outside what static signature verification can reason about.