Parag Mali - tag: credential-guard

Pass-the-Hash to Pass-the-PRT: Twenty-Nine Years of Windows Credential Replay in One Family Tree

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

Twenty-nine years of Windows credential-replay attacks -- Pass-the-Hash, Pass-the-Ticket, Overpass-the-Hash, Pass-the-Certificate, Pass-the-PRT -- are a single lineage, not five techniques. Each generation finds the next long-term authentication artefact that lives outside the latest Microsoft isolation boundary, then commoditises extraction in tooling that runs anywhere with local administrator. Credential Guard (2015) and KB5014754 (2022) bought years but not closure; Pass-the-PRT (Mollema + Delpy, 2020) already defeats both because the Primary Refresh Token lives in the CloudAP plug-in, which is not inside any current isolation scope. The next decade of Windows credential theft turns on whether Microsoft extends hypervisor-based isolation to CloudAP before commodity offensive tooling makes the attack universal.

1. Two Afternoons, Twenty-Nine Years Apart

On the afternoon of Tuesday, April 8, 1997, between 5:27 p.m. and 8:57 p.m. -- a window we can narrow to about three and a half hours from the file timestamps preserved in the patch he posted -- a researcher named Paul Ashton sat down with the Samba source tree and made the smallest possible change to smbclient.The bracketing mtimes Tue Apr 8 17:27:29 1997 and Tue Apr 8 20:57:43 1997 are preserved verbatim in the unified diff's *** and --- header lines on Exploit-DB advisory 19197 [@ashton-exploitdb-19197]. You can still download the diff today and confirm the timestamps yourself. Where the unpatched client computed a network response from a typed-in password, his version read the password's LM hash from smbpasswd on disk and fed it straight to the same encryption primitive, skipping the password entirely.

He posted the diff to NTBugtraq the same evening with a five-line advisory: "A modified SMB client can mount shares on an SMB host by passing the username and corresponding LanMan hash of an account that is authorized to access the host and share. The modified SMB client removes the need for the user to 'decrypt' the password hash into its clear-text equivalent." [@ashton-exploitdb-19197]

Twenty-nine years later, every Windows credential-replay attack in commodity offensive tooling is a direct descendant of that afternoon.

Fast-forward to 2026. A Windows 11 23H2 laptop, hardened to Microsoft's published baseline. Credential Guard on. KB5014754 strong certificate mapping in full enforcement. Conditional Access enabled, with Token Protection where supported. An attacker has local admin -- the same starting position the 1997 attack assumed.

Two commands run on that machine, in the same paragraph. Mimikatz sekurlsa::logonpasswords returns empty NT hash and TGT buffers; Credential Guard has done its job. Then Mimikatz dpapi::cloudapkd /unprotect returns a valid Primary Refresh Token session key and proof-of-possession material [@mollema-prt-digging]. On a different machine across the internet, the attacker pastes that material into Dirk-jan Mollema's roadtx prt, mints an x-ms-RefreshTokenCredential cookie, and authenticates to Entra ID as the laptop's user [@mollema-prt-abusing] [@roadtools-github]. Every Microsoft defense shipped in 2015, 2022, and 2024 is running. The attack still wins.

Note: The empty buffer from sekurlsa::logonpasswords is the artefact of twenty-nine years of architectural lessons. The PRT extraction from dpapi::cloudapkd is the architecture of the next five-to-ten years. Both scenes are the same attack class. The credential changed; the protocol that consumes it changed; the long-term storage location changed; the lineage did not.

You will meet seven people in this article. Paul Ashton (1997, the patch). Hernan Ochoa (2008, the toolkit that put the technique inside Windows itself). Benjamin Delpy (2011, Mimikatz; and the Kerberos generations that followed). Sean Metcalf (2014, who named Overpass-the-Hash and wrote the practitioner reference that taught a generation of red and blue teams).

Will Schroeder and Lee Christensen (2021, "Certified Pre-Owned," the AD CS catalog that became Pass-the-Certificate). Oliver Lyak (2022, Certifried, the CVE that forced Microsoft to ship KB5014754). And Dirk-jan Mollema (2020, the Primary Refresh Token research this article argues is the most consequential credential-theft work since 2008). The cast is small. The lineage they built is the load-bearing structure of every Windows penetration test in 2026.

How is it possible that the same attack works in 1997 and 2026? The answer is structural, not coincidental -- and once you see it, you cannot unsee it.

2. The Architectural Property the Family Shares

NTLM authentication never asks for the password as a string. It asks for a function of the hash. The hash is the password.

That sentence is the article's load-bearing claim, and the rest of this section is its proof.

The Microsoft specification for the NTLM protocol -- [MS-NLMP], sections 3.3.1 and 3.3.2 -- writes the response computation in pseudocode. For NTLMv1, the server sends an 8-byte challenge; the client computes NtChallengeResponse = DESL(ResponseKeyNT, challenge), where ResponseKeyNT = NTOWFv1(password) = MD4(UNICODE(password)) [@ms-nlmp-3-3-1]. DESL is a variant of DES that pads the 16-byte NT hash to 21 bytes with five zero bytes, splits the result into three 7-byte sub-keys, runs DES on the 8-byte challenge under each sub-key, and concatenates the three 8-byte ciphertexts to form a 24-byte response.

NTLMv2 is more elaborate -- the response key is NTOWFv2 = HMAC_MD5(MD4(UNICODE(password)), UNICODE(Uppercase(User) + UserDom)), and the proof string is HMAC_MD5 of the challenge concatenated with a target-info structure -- but the structural property is identical: the cleartext password appears in exactly one place in the entire protocol, the input to the hash function on the client. The verifier performs the same computation against the stored NT hash from the SAM or NTDS.dit, and compares. Neither side ever transmits the password [@ms-nlmp-3-3-2].

This is what Microsoft means when its institutional documentation says Pass-the-Hash "cannot be patched at the protocol level." There is nothing to patch.The same property holds for any challenge-response protocol whose verifier stores a determinable function of the password rather than the password itself: Kerberos with stored long-term keys, CHAP with shared secrets, OAuth client_credentials with shared secrets, every HMAC-based proof-of-possession scheme.

The protocol takes a stored hash and produces a response. Swap the user's hash for the attacker's hash, and the protocol still produces a valid response, signed by the substituted key. The bug is not a bug; it is a documented property.

A family of Windows authentication protocols (NTLMv1 and NTLMv2) in which a server sends a random challenge and the client returns a response computed by applying a keyed cryptographic primitive (DES or HMAC-MD5) to that challenge under a key derived from the user's password. The verifier holds the same key and recomputes the response to confirm. The cleartext password is never transmitted [@ms-nlmp-3-3-1] [@ms-nlmp-3-3-2]. The 16-byte MD4 of the user's password as UTF-16 little-endian (`MD4(UNICODE(Passwd))` in the NLMP pseudocode). Unsalted by design, because NT was originally specified for an offline domain controller that has to verify against a fixed reference value. The NT hash is the long-term symmetric Windows authentication secret for every account, stored locally in the SAM and centrally in the NTDS.dit Active Directory database [@ms-nlmp-3-3-1]. The technique of authenticating to a service that uses NTLM (or any protocol descended from the same family) by feeding a stolen NT hash directly to the response-construction function, instead of typing a password the function would then hash. The terminology and the first working demonstration are due to Paul Ashton, NTBugtraq, April 1997 [@ashton-exploitdb-19197]. sequenceDiagram participant Client participant Server participant Verifier as SAM or NTDS.dit Client->>Server: NTLM_NEGOTIATE Server->>Client: NTLM_CHALLENGE with 8-byte nonce Note over Client: ResponseKeyNT equals NTOWFv1 of stored NT hash Note over Client: NtChallengeResponse equals DESL of ResponseKeyNT and nonce Client->>Server: NTLM_AUTHENTICATE with response Server->>Verifier: Look up stored NT hash for user Verifier-->>Server: Stored NT hash Note over Server: Recompute DESL of stored hash and nonce Server->>Client: Authentication succeeds if responses match

Key idea: The hash is the password. Any long-term authentication artefact reachable by the process that uses it is replayable -- and every credential type the rest of this article discusses (Kerberos TGT, certificate private key, Primary Refresh Token session key) is a different instance of this same property. Defenses can isolate one artefact at a time; the property is intrinsic to the architecture.

Ashton's 1997 patch was the protocol-disclosure proof. He swapped a single function call -- SMBencrypt(pass, cryptkey, pword) became E_P24(p21, cryptkey, pword), where p21 is the user's LM hash read directly from smbpasswd -- and Samba's smbclient authenticated to NT 3.51 and NT 4.0 file servers without ever knowing the user's password [@ashton-exploitdb-19197]. You can read the patch in five minutes. It is also, in a precise sense, the first proof that NTLM's response computation is hash-equivalent: if substituting the hash works, then mathematically the hash is what the protocol wanted all along.

And then nothing happened for eleven years.

That gap deserves its own explanation, because the eleven-year interregnum is the cleanest failure mode in the lineage.

Wikipedia's modern summary of the pre-2008 limitation reads: "even after performing NTLM authentication successfully using the pass the hash technique, tools like Samba's SMB client might not have implemented the functionality the attacker might want to use. This meant that it was difficult to attack Windows programs that use DCOM or RPC. Also, because attackers were restricted to using third-party clients when carrying out attacks, it was not possible to use built-in Windows applications, like Net.exe or the Active Directory Users and Computers tool amongst others, because they asked the attacker or user to enter the cleartext password to authenticate, and not the corresponding password hash value." [@wikipedia-pass-the-hash]

Inside Microsoft the 1997 patch was treated as confirming a known property of LSASS-resident credentials, not as a new attack class. The institutional position was that any compromise yielding the hash already implied SYSTEM-equivalent access, and that the realistic chain was "exfiltrate the hash and crack it offline," not "replay the hash." The architectural counter-claim -- that *replaying* the hash from inside a Windows process bypasses every native-tool obstacle -- took a decade to land in the practitioner literature. The 2012 Duckwall + Campbell Black Hat USA paper named the lag in its title: "Still Passing the Hash 15 Years Later." [@duckwall-campbell-bh2012]

If the obstacle is "built-in Windows tools ask for cleartext," the architectural answer is to put the substituted hash inside the Windows process that those tools rely on. That insight took eleven years to operationalise. The person who operationalised it was Hernan Ochoa, in 2008.

3. From Patch to Toolkit: The Windows-Native Pivot

By 2008, Ashton's 1997 patch had been sitting on NTBugtraq for eleven years. Hernan Ochoa had a different idea: instead of patching the client, patch the credential cache.

The artefact Ochoa shipped at CanSecWest 2008 and Black Hat USA 2008 was called the Pass-the-Hash Toolkit, distributed through Core Security Technologies' open-source projects page [@corelabs-pshtoolkit-wayback]. It contained two executables. IAM.EXE opened the LSASS process with PROCESS_VM_WRITE, located the cached credential block for the current interactive logon session, and overwrote the NT hash and username fields with attacker-supplied values. PTH.EXE spawned a target process under a substituted hash.

Once the substitution was in place, every native Windows SSO consumer -- net.exe, wmic, mstsc once Restricted Admin RDP shipped years later, SMB, RPC, DCOM -- transparently picked up the attacker-supplied hash, because the OS handed them what it believed were the legitimate user's credentials.

Wikipedia summarises the architectural pivot in one paragraph: "It allowed the user name, domain name, and password hashes cached in memory by the Local Security Authority to be changed at runtime after a user was authenticated -- this made it possible to 'pass the hash' using standard Windows applications, and thereby to undermine fundamental authentication mechanisms built into the operating system." [@wikipedia-pass-the-hash] The eleven-year limitation was gone. Pass-the-Hash was now a Windows-native attack that worked against any tool that read its credentials from LSASS -- which in practice meant every Windows tool.

The user-mode Windows process (`lsass.exe`) that handles interactive logon, owns the Security Reference Monitor's policy decisions, and -- relevant to this article -- caches the in-memory credential material that supports Single Sign-On for the duration of each logon session: NT hashes for NTLM, Kerberos TGTs and session keys, certificate handles, and (since Azure AD / Entra ID device join) Primary Refresh Token material in the CloudAP plug-in. Every credential-replay technique in this article reaches its target by reading LSASS in some form.

The 2012 retrospective is where the security industry stopped pretending Pass-the-Hash was solved. Alva Duckwall and Christopher Campbell shipped a Black Hat USA 2012 paper titled, unambiguously, "Still Passing the Hash 15 Years Later." [@duckwall-campbell-bh2012] The title is the load-bearing pull-quote: it named Ashton 1997 as the origin, Ochoa 2008 as the Windows-native pivot, and the industry's continued failure to ship a structural fix as the central fact. From this point onwards Microsoft itself acknowledged Pass-the-Hash as a structural property of NTLM rather than a fixable bug.

Hernan Ochoa's Windows Credentials Editor (WCE), released a year after the Pass-the-Hash Toolkit, developed the same LSASS-injection primitive on a separate code base. Two independent implementations converging on the same memory-access pattern in the same window is the clearest indication that the architectural insight -- "the credential is sitting in a process you can write to" -- was overdetermined once anyone went looking for it.

What did Ashton's 1997 patch leave on the table? The other long-term credentials that LSASS held. The NT hash was the first. There would be more.

If you can read the NT hash from LSASS, you can read the Kerberos TGT from LSASS. The same memory-access primitive that animates IAM.EXE is one commit away from animating sekurlsa::tickets. That commit shipped in May 2011. Its author was a twenty-five-year-old French programmer named Benjamin Delpy.

4. Mimikatz and the Kerberos Turn

In May 2011, Benjamin Delpy posted his first public release of a program he had been writing as a side project to learn C. He was twenty-five, working as an IT manager at an institution he has never publicly named. Andy Greenberg's Wired profile records the date: "He released it publicly in May 2011, but as a closed source program." [@wired-greenberg-mimikatz] Wikipedia corroborates: "He released the first version of the software in May 2011 as closed source software." [@wikipedia-mimikatz] The program was called Mimikatz.

What made Mimikatz architecturally different from Ochoa's toolkit was that it was modular. The credential-extraction primitives lived in named command groups: sekurlsa::logonpasswords dumped NT hashes from LSASS; sekurlsa::tickets dumped Kerberos tickets from LSASS; kerberos::ptt injected a stolen ticket into the current Kerberos cache via the documented LsaCallAuthenticationPackage API with the KerbSubmitTicketMessage message [@ms-lsa-call-auth-package]; lsadump::dcsync (added August 2015, in collaboration with Vincent Le Toux) impersonated a domain controller and asked another DC for the krbtgt hash via the IDL_DRSGetNCChanges replication RPC [@adsec-dcsync-p1729].

Same LSASS, different artefact, different protocol surface. The architectural property section 2 named had two artefacts to work with on Windows: the NT hash, and the Kerberos TGT.

This is Pass-the-Ticket (Generation 2). The stolen TGT plus its session key authenticates the holder as the original principal for the ticket's lifetime, which on a default AD deployment is ten hours, renewable for seven days. Time complexity per replay: O(1). The TGT session key is the load-bearing piece -- without it, the ticket is opaque encrypted bytes that the holder cannot decrypt, sign, or present back to the KDC. Mimikatz's sekurlsa::tickets /export writes the ticket as a .kirbi file on disk; kerberos::ptt <file> re-injects on any machine where the user has a Kerberos credentials cache.

The long-lived Kerberos credential issued by the KDC's Authentication Service (AS-REP) in response to a successful AS-REQ. The TGT is encrypted under the KDC's own krbtgt-account long-term key and contains a session key that the client uses to subsequently request service tickets from the Ticket Granting Service (TGS). Specification: RFC 4120, section 3 [@rfc-4120]. On a Windows Active Directory deployment the default TGT lifetime is 10 hours with renewal up to 7 days. The technique of extracting a Kerberos TGT (and its session key) from one machine's LSASS-resident Kerberos cache and injecting it into another machine's cache, so that subsequent service-ticket requests authenticate as the ticket's original principal. Tool of record: Mimikatz `sekurlsa::tickets` + `kerberos::ptt`; equivalent functionality in Rubeus and Impacket. sequenceDiagram participant Victim as Victim host participant Attacker as Attacker host participant KDC Note over Victim: User logged in, TGT cached in LSASS Kerberos package Attacker->>Victim: mimikatz sekurlsa::tickets export Victim-->>Attacker: TGT.kirbi (ticket plus session key) Note over Attacker: mimikatz kerberos::ptt TGT.kirbi Attacker->>KDC: TGS-REQ presenting injected TGT KDC-->>Attacker: TGS-REP service ticket Attacker->>Attacker: Authenticate to any Kerberos service as the victim

Note: A common shorthand says that Microsoft's Credential Guard isolated NT hashes, so attackers shifted to TGTs. That arrow runs backwards in time. Pass-the-Ticket predates Credential Guard by years -- the Mimikatz Kerberos primitives developed between the May 2011 closed-source release and the April 6, 2014 open-source commit (the earliest verifiable source-level evidence for sekurlsa::tickets and kerberos::ptt), and were presented in detail at Black Hat USA 2014 by Duckwall and Delpy [@infocondb-bh2014-duckwall] [@duckwall-delpy-bh2014-wp]. Pass-the-Ticket exists because TGTs are also in LSASS, not as a defensive response. The shift to a new artefact happened because the architectural property of credential extraction generalised, not because Credential Guard pushed attackers there.

The third generation followed shortly. Overpass-the-Hash observes that for the RC4-HMAC Kerberos encryption type -- the Windows default from Windows 2000 through November 2022 -- the user's long-term Kerberos key is the unchanged NT hash.

RFC 4757, authored by K. Jaganathan, L. Zhu, and J. Brezak of Microsoft and published as informational in December 2006, specifies the RC4-HMAC enctype's long-term key as the existing NT hash without modification [@rfc-4757]. An attacker who holds the NT hash can drive a legitimate Kerberos AS-REQ to the KDC, encrypt the timestamp pre-auth blob with the NT hash as the RC4-HMAC key, and receive a real TGT signed by the real krbtgt.

The economic effect is large. Pass-the-Hash gets you NTLM-based services -- SMB, RPC, and any protocol over them. Overpass-the-Hash gets you the entire Kerberos surface: Kerberos-only services, services that require Kerberos for delegation, services with NTLM disabled at the GPO level. Same NT hash. Different downstream protocol. Strictly larger attack surface.

The technique of presenting a stolen NT hash to the KDC as the user's long-term RC4-HMAC Kerberos key (per RFC 4757 [@rfc-4757]), obtaining a real TGT signed by the real krbtgt, and operating as a real Kerberos client for the ticket's lifetime. Tool of record: Mimikatz `sekurlsa::pth /user: /domain: /ntlm: /run:` and Rubeus `asktgt /user: /rc4:`. Per Sean Metcalf's adsecurity.org reference, the technique is named "over" because the hash is promoted one notch up the protocol stack from NTLM into Kerberos [@adsec-mimikatz-p556] [@adsec-kerberos-p2293]. sequenceDiagram participant Attacker participant KDC participant Service as Kerberos service Note over Attacker: Holds NT hash for user (e.g. from sekurlsa::logonpasswords) Attacker->>KDC: AS-REQ with PA-ENC-TIMESTAMP encrypted under RC4-HMAC(NT hash) KDC->>KDC: Verify PA-ENC-TIMESTAMP decrypts cleanly KDC-->>Attacker: AS-REP with real TGT signed by krbtgt Attacker->>KDC: TGS-REQ for Service KDC-->>Attacker: TGS-REP service ticket Attacker->>Service: AP-REQ authenticate as user Service-->>Attacker: Access granted

The naming has its own story. The Mimikatz capability is Delpy's; the term "Overpass-the-Hash" and the taxonomic framing that distinguishes it from straight Pass-the-Hash spread through the practitioner community via Sean Metcalf's adsecurity.org reference [@adsec-mimikatz-p556] and the Duckwall + Delpy Black Hat USA 2014 talk and whitepaper [@infocondb-bh2014-duckwall] [@duckwall-delpy-bh2014-wp]. The earliest archived snapshot of the adsecurity.org reference is October 1, 2014; the talk timestamp is August 7, 2014. The two sources are essentially contemporaneous, and Metcalf's later "Red vs. Blue" Black Hat USA 2015 whitepaper consolidates the practitioner taxonomy [@metcalf-bh2015-red-vs-blue].

The "Overpass" coinage is a deliberate semantic argument that the technique is one notch above Pass-the-Hash on the protocol stack: the NT hash, which began life as an NTLM response key, is being promoted into Kerberos as a long-term encryption key. The naming credit is socially distributed -- Metcalf, Delpy, Duckwall, and Mimikatz's own command group all carry traces of it -- so this article uses Metcalf's reference as the canonical practitioner explainer rather than as a single inventor citation.

The DigiNotar incident in September 2011 is the first publicly attributed criminal use of Mimikatz, four months after Delpy's first public release. The Dutch certificate authority DigiNotar -- founded 1998, acquired by VASCO in January 2011, hacked in June 2011, declared bankrupt in September 2011 [@wikipedia-diginotar] -- was used to issue hundreds of fraudulent certificates that were then used in man-in-the-middle attacks on Iranian Gmail users [@wikipedia-diginotar] [@fox-it-operation-black-tulip].

Greenberg's Wired profile records that Delpy was told by the breach investigators that Mimikatz had been used during the intrusion [@wired-greenberg-mimikatz]. The single-source attribution warrants a hedge -- Greenberg's source is Delpy himself, quoting investigators -- but the underlying breach timeline is solid.

The decision to open-source Mimikatz on April 6, 2014 is dated by the GitHub repository banner: `mimikatz 2.0 alpha (x86) release "Kiwi en C" (Apr 6 2014 22:02:03)` [@mimikatz-github]. The precipitating event, as Delpy told Wired, was a trip to Moscow: he returned to his hotel room to find a stranger at his laptop; a second man approached him in the lobby that evening and demanded source code on a USB stick. He decided defenders needed the source as much as the attackers already did, and pushed it to GitHub when he got home [@wired-greenberg-mimikatz].

By 2014, the credential-replay family had three generations -- Pass-the-Hash, Pass-the-Ticket, Overpass-the-Hash -- and Microsoft's only documented response was a forty-page PDF. The next section is what that PDF said, and why documentation alone cannot end an attack class.

5. Documentation Is Not Defense

By December 2012, Microsoft had a problem. Duckwall and Campbell had just shipped a Black Hat USA paper titled "Still Passing the Hash 15 Years Later" [@duckwall-campbell-bh2012]. Mimikatz was eighteen months old. The institutional position that Pass-the-Hash was a "post-compromise issue" -- the line Microsoft had held since 1997 -- was no longer survivable in public.

The institutional response came in two waves. Mitigating Pass-the-Hash Attacks and Other Credential Theft, version 1, shipped in late 2012 (most practitioner secondaries place it in December 2012; no primary Microsoft URL with a verifiable v1 timestamp survives today).

Version 2 followed in July 2014, extending the v1 playbook with the new defensive surfaces that shipped in Windows 8.1 and Windows Server 2012 R2: Protected Users as a deployable security group, Restricted Admin RDP as a default-available feature, LSA Protection (RunAsPPL) as a registry-toggleable defense, and Authentication Policies and Silos as KDC-side restrictions [@ms-download-mitigating-pth-v2]. The two whitepapers are the closest thing the industry got to an institutional Microsoft acknowledgment that Pass-the-Hash was a load-bearing operational problem requiring a defensive playbook rather than a patch.

What did the playbook recommend? Three orthogonal stopgaps, each with a published bypass.

Protected Users (Windows Server 2012 R2). A security group whose membership bans, on the DC side, NTLM authentication, DES and RC4 Kerberos pre-authentication, and Kerberos unconstrained delegation; and, on the device side, NTLM caching of the user's plaintext credentials or NTOWF and Kerberos DES/RC4 long-term keys. Member TGTs are capped at 240 minutes (four hours) with no renewal [@ms-protected-users]. Documented bypasses: requires explicit opt-in per account, breaks any service that depended on unconstrained delegation, does not apply to computer accounts or service accounts by default, and has no effect on Kerberos AES-key extraction from LSASS (since AES keys are not banned; only RC4 is).

Restricted Admin RDP (introduced in Windows 8.1 / Server 2012 R2 RTM, October 2013; backported to Windows 7 / Server 2008 R2 / Windows 8 / Server 2012 by KB2871997 on May 13, 2014 [@ms-kb2871997-may2014]). An opt-in RDP mode that authenticates to the target without sending credentials, so a compromised target cannot harvest the RDP user's hash from its own LSASS. Documented bypass: opt-in per session, applies only to RDP, leaves SMB, WMI, and RPC unprotected. And it enables Pass-the-Hash for RDP -- the BloodHound CanRDP edge documents the abuse path with the exact Mimikatz command for injecting a stolen NT hash into mstsc.exe /restrictedadmin [@bloodhound-canrdp].

LSA Protection / RunAsPPL (Windows 8.1). A registry toggle that marks LSASS as a Protected Process Light, so non-PPL processes (including unsigned admin tools) cannot open it with PROCESS_VM_READ. Documented bypass: any signed kernel driver -- including loadable third-party drivers -- can still read PPL memory, and an attacker with local admin can load such a driver. The itm4n analysis includes the verbatim Mimikatz output where sekurlsa::logonpasswords returns access-denied against a PPL-marked LSASS, and shows that an attacker who loads a signed driver via the BYOVD pattern ("bring your own vulnerable driver") or escalates to kernel mode bypasses the marking. itm4n's framing -- "Credential Guard and LSA Protection are actually complementary" [@itm4n-lsass-runasppl] -- is also the prediction: PPL is part of the answer, but only when paired with the architectural pivot still to come.

A Windows Server 2012 R2 security group whose membership applies a set of restrictions, enforced jointly by the device and the domain controller, that block the most commonly extracted long-term credential material: no NTLM, no Kerberos RC4 or DES pre-auth, no unconstrained delegation, no NT-hash caching, and a 240-minute TGT lifetime with no renewal [@ms-protected-users].

The structural point is this. Documentation tells administrators what to do. It does not prevent the underlying LSASS-resident credential extraction. Every defense documented in v1 and v2 of the Mitigating-PtH whitepapers is bypassable, with a known and published technique, on any system where the attacker already has local administrator -- and local administrator is exactly what Pass-the-Hash exploitation already implies. The defender's win condition is to keep the attacker from ever getting to local admin in the first place; once they have it, every documented mitigation is a speed bump rather than a wall.

Note: The 2012-2014 era's load-bearing failure mode was assuming that telling administrators where credentials should live would prevent extraction from where they do live. Protected Users, Restricted Admin RDP, RunAsPPL, and Authentication Silos are all useful, and stacked together they raise the cost of post-admin exploitation. None of them moves the credential out of the address space the attacker can read.

A common secondary characterisation cites a "v3 2017" of the whitepaper alongside v1 and v2. That document does not exist in Microsoft Download Center ID 36036; the page lists Version 2.0; the 2023 Wayback snapshot of the same Download Center page records Date Published 7/7/2014, while the live page now shows a 2024 republication date for the same Version 2.0 PDF without a version bump [@ms-download-mitigating-pth-v2]. The Download Center page carries v2 metadata only -- v1's late-2012 date is sourced through contemporary practitioner literature rather than a primary Microsoft timestamp. After 2014 the post-v2 institutional documentation moves to the Microsoft Learn Credential Guard page rather than to a third whitepaper revision -- a structural choice, because by 2015 the architectural answer has shifted from prose to code.

By mid-2014 Microsoft's institutional position was that the protocol-level fix was unavailable and the architectural answer would need to relocate the credentials. If credentials cannot stay in LSASS where every admin process can read them, the credentials have to be moved to a place admin processes cannot read. That insight produces Credential Guard.

6. Credential Guard and the Architectural Pivot

On July 29, 2015, Microsoft shipped Windows 10 Enterprise [@ms-lifecycle-w10-enterprise]. Hidden in the RTM build was the first defense in the credential-replay lineage that wasn't documentation: hardware-rooted isolation. They called it Credential Guard.

The architecture is worth unpacking carefully, because every later generation of the family is best read as "what does this attack do to the assumptions Credential Guard makes?"

Credential Guard runs on top of Virtualization-Based Security. The Windows hypervisor partitions user mode into two virtual trust levels. VTL0 is the normal user partition: normal user-mode processes, including the normal LSASS, and the normal kernel. VTL1 is the isolated user partition: a small set of trustlets, signed user-mode processes the hypervisor protects from VTL0 inspection. Credential Guard's trustlet is LSAISO ("LSA Isolated"), a stripped-down clone of the LSA credential cache holding the material Microsoft wants out of VTL0. Hypervisor-enforced Code Integrity (HVCI) below enforces W^X on the VTL0 kernel, blocking kernel-mode bypasses that would otherwise read VTL1 memory directly.

The Windows architecture that runs a Type-1 hypervisor below the normal Windows kernel and partitions user mode into VTL0 (the normal partition) and VTL1 (the isolated partition). VTL1 hosts trustlets that the hypervisor protects from VTL0 inspection, even from kernel-mode VTL0 code. VBS is the substrate for Credential Guard, HVCI, the System Guard secure-launch chain, and the secure kernel. The Windows feature that relocates NT hashes, Kerberos TGT session keys, and "credentials stored by applications as domain credentials" from the in-VTL0 LSASS to the in-VTL1 LSAISO trustlet, so that the credential cache is unreadable from any VTL0 process or driver. Shipped in Windows 10 RTM (July 2015); default-enabled on hardware-eligible domain-joined non-DC systems in Windows 11 22H2 (September 2022) [@ms-learn-credential-guard]. The isolated-user-mode LSA process (`lsaiso.exe`) that holds Credential Guard's protected credential material. Runs in VTL1, unreadable from VTL0 kernel or user processes. Communicates with the VTL0 LSASS through a small RPC surface for authorised authentication operations only.

What does Credential Guard isolate? The Microsoft Learn page is unambiguous: "Credential Guard prevents credential theft attacks by protecting NTLM password hashes, Kerberos Ticket Granting Tickets (TGTs), and credentials stored by applications as domain credentials." [@ms-learn-credential-guard] Those three categories are also the three categories the previous three generations of the family targeted. Pass-the-Hash hits NTLM password hashes. Pass-the-Ticket hits Kerberos TGTs. Overpass-the-Hash hits NTLM password hashes promoted into Kerberos. Credential Guard moves all three out of VTL0 LSASS into VTL1 LSAISO. On a hardware-eligible domain-joined Windows 10/11 system with Credential Guard enabled, all three attacks return empty buffers.

The institutional importance of the change is that under Microsoft's own Windows Security Servicing Criteria, Credential Guard is a security boundary -- which means a bypass is a CVE-class vulnerability rather than a documentation gap.

The criteria's load-bearing definitions: "A security boundary provides a logical separation between the code and data of security domains with different levels of trust" and "Does the vulnerability violate the goal or intent of a security boundary or a security feature?" [@msrc-windows-servicing-criteria] Pre-2015 Pass-the-Hash defenses were documentation; Credential Guard is the first defense the criteria treats as CVE-class under the boundary "admin -> VBS (LSAISO trustlet)."

flowchart TD subgraph VTL0[VTL0 normal partition] A[User processes] B[LSASS] K[VTL0 kernel] end subgraph VTL1[VTL1 isolated partition] L[LSAISO trustlet] SK[Secure kernel] end H[Hypervisor] A --> B K --> B B -- authorised RPC only --> L H --> VTL0 H --> VTL1 SK --> L K -. blocked by HVCI .-> L

What does Credential Guard not isolate? This is the load-bearing question for the rest of the article. The same Microsoft Learn page enumerates four caveats, each verbatim.

First, the Active Directory database and the SAM. "Credential Guard doesn't provide protections for the Active Directory database or the Security Accounts Manager (SAM)." [@ms-learn-credential-guard] This is the DCSync gap: an attacker with the right replication privileges can ask a DC to hand over every hash in the directory, and Credential Guard cannot intervene because the data is being released through a legitimate, authorised API rather than being read from LSASS.

Second, domain controllers. "Enabling Credential Guard on domain controllers isn't recommended. Credential Guard doesn't provide any added security to domain controllers." [@ms-learn-credential-guard] The KDC must read the krbtgt account's long-term key in cleartext to issue tickets; the architectural exception is intrinsic to Kerberos rather than a Microsoft oversight.

Third, application credentials outside the "domain credentials" scope. Certificate private keys held by CryptoAPI key containers, third-party authentication package secrets, and -- the one this article eventually argues is the most consequential -- the Primary Refresh Token material held by the CloudAP authentication plug-in, are all out of scope by construction.

Fourth, and most importantly, the institutional acknowledgment of the supersession pattern. Microsoft Learn reproduces it verbatim on the same page, the prophecy the rest of this article spends its time documenting being fulfilled:

While Credential Guard is a powerful mitigation, persistent threat attacks will likely shift to new attack techniques, and you should also incorporate other security strategies and architectures. -- Microsoft Learn, *Credential Guard overview* [@ms-learn-credential-guard]

That sentence, written about the 2015 Credential Guard architecture, accurately predicts the 2021-2022 shift to Pass-the-Certificate and the 2020-present shift to Pass-the-PRT. It is Microsoft's own structural prediction that the family will continue to evolve to the next artefact Credential Guard's verbatim scope does not cover. The rest of this article reads as the unfolding of that prediction.

The Kerberos KDC must read the krbtgt account's long-term key to encrypt the TGT issued in every AS-REP. That key has to be available to the LSA process in cleartext, on every DC, on every ticket issuance, by protocol. Putting krbtgt behind LSAISO would mean issuing every TGT through an inter-trust-level RPC call -- a non-trivial performance penalty on every authentication in an Active Directory forest -- and would not actually close the architectural gap, because the trustlet itself would still need to do the cleartext work that LSASS does today. The exception is honest about an architectural reality rather than concealing it.

PPL and Credential Guard are complementary, not alternatives. itm4n's analysis [@itm4n-lsass-runasppl] makes the case carefully: RunAsPPL raises the bar from "any admin process can read LSASS" to "any signed driver can read LSASS," and Credential Guard closes the signed-driver bypass with hardware-rooted hypervisor isolation. They stack. The 2026 best-practice Windows endpoint has both turned on.

The default-enablement window shows how long this took to land. Credential Guard shipped enabled-by-policy in Windows 10 RTM in 2015, but did not become default-enabled on hardware-eligible domain-joined non-DC systems until Windows 11 22H2 in September 2022 [@ms-learn-credential-guard]. Seven years of uneven deployment.

Note: Four residuals from the Microsoft Learn page: the Active Directory database and the SAM are out of scope; domain controllers are out of scope by recommendation; application credentials outside the "domain credentials" category (certificates, CloudAP material, third-party authentication packages) are out of scope by construction; and persistent threats are expected to shift to new attack techniques. Each residual maps to a later generation of this article: AD database -> DCSync; certificates -> Pass-the-Certificate; CloudAP -> Pass-the-PRT.

Each new credential type needs its own isolation boundary. Credential Guard isolates NT hashes and TGT session keys. It does not isolate certificate private keys, because in 2015 nobody was replaying certificates at scale. And it does not isolate the Primary Refresh Token, because in 2015 the Primary Refresh Token did not yet exist.

Key idea: Each new credential type needs its own isolation boundary. The pattern is reusable but does not transfer automatically -- and the gap between "what fits in the boundary" and "what credentials Windows actually uses" is exactly the territory where the next attack generation grows.

7. Pass-the-Certificate: The Predictable Response

If the NT hash is isolated and RC4-HMAC is banned, what is the next long-term credential Windows accepts? The answer was hiding in plain sight: every Active-Directory-integrated enterprise had been running Microsoft's PKI since 2008, and almost every PKI deployment had at least one template-level catastrophe.

On June 17, 2021, Will Schroeder and Lee Christensen posted "Certified Pre-Owned" on Medium, with the accompanying 143-page whitepaper [@specterops-certified-pre-owned] [@specterops-certified-pre-owned-pdf]. The post named ESC1 through ESC8 in a single document, with paired DETECT and PREVENT recommendations, and shipped three pieces of tooling at the same Black Hat USA 2021 cycle: Certify (offensive enrollment), ForgeCert (golden-certificate forging using a stolen CA private key), and PSPKIAudit (defensive enumeration). The Medium post's tone was unsubtle:

Of note, nearly every environment with AD CS that we've examined for domain escalation misconfigurations has been vulnerable. It's hard for us to overstate what a big deal these issues are. -- Will Schroeder and Lee Christensen, *Certified Pre-Owned* [@specterops-certified-pre-owned]

The ESC catalog organises certificate misconfigurations by the abuse primitive they enable. ESC1 is the canonical example: a published certificate template that allows the enrollee to supply the Subject Alternative Name, contains a client-authentication Extended Key Usage, has permissive enrollment rights, and has no effective approval gates.

An attacker who can enroll for such a template requests a certificate naming a victim principal -- say, the domain administrator -- in the SAN. The certificate's private key is now the attacker's. PKINIT-authenticate to the KDC with that certificate, and the KDC issues a TGT for the named principal. Domain escalation, in three commands.

Microsoft's enterprise PKI. Issues X.509 certificates from administrator-defined templates that pin a certificate's permitted uses (Extended Key Usages), its enrollment authorisation rules, its subject and SAN generation policy, and its revocation behaviour. Ships as a Windows Server role; deployed in essentially every Active-Directory-integrated enterprise. Kerberos pre-authentication using a certificate's private key in place of a long-term symmetric key. Specified by RFC 4556 (L. Zhu and B. Tung, Microsoft and Aerospace, June 2006) [@rfc-4556]. The certificate's UPN SAN (or its dNSHostName for computer accounts) maps the certificate to the principal whose TGT the KDC will issue. PKINIT is the protocol surface most commonly exercised by Pass-the-Certificate against domain controllers that support certificate-based authentication. The Windows TLS implementation. Supports TLS client-certificate authentication, which authenticated LDAPS uses. When a domain controller does not support PKINIT (Schroeder + Christensen documented this case in the original catalog; AlmondOffSec built tooling for it), an attacker can authenticate to LDAPS over Schannel with a stolen client certificate and perform high-privilege LDAP operations without traversing the KDC. The technique of authenticating to Active Directory with a stolen X.509 certificate's private key, via PKINIT to the KDC or via Schannel client-certificate authentication to LDAPS. Named in this form by Yannick Méheut's PassTheCert tool and blog post (May 2022) [@almondoffsec-passthecert-github] [@almondoffsec-passthecert-blog], though the technique class was catalogued by Schroeder and Christensen eleven months earlier [@specterops-certified-pre-owned]. Tool of record: Certify (C#), Certipy (Python, ESC1-ESC16 [@certipy-wiki-privesc]), and Rubeus PKINIT mode. sequenceDiagram participant Atk as Attacker (user) participant CA as Enterprise CA participant KDC Atk->>CA: Enrol for template ESC1, SAN field set to Domain Administrator CA-->>Atk: X.509 certificate plus private key Note over Atk: Now holds a certificate naming the victim principal Atk->>KDC: AS-REQ with PKINIT pre-auth using the stolen private key KDC->>KDC: Validate certificate, map SAN to victim principal KDC-->>Atk: AS-REP with TGT for victim principal Atk->>KDC: TGS-REQ for any service KDC-->>Atk: TGS-REP service ticket

The CVE-class case lands on May 10, 2022. Oliver Lyak of IFCR discloses Certifried, CVE-2022-26923, an Active Directory Domain Services elevation-of-privilege vulnerability in which the combination of three Microsoft defaults -- ms-DS-MachineAccountQuota = 10 (any authenticated user can add up to 10 computer accounts to the domain), the default Machine template (which a computer account can enroll for), and the KDC's permissive dNSHostName-to-SAN binding logic -- lets any authenticated user obtain a certificate for any computer account in the forest, including domain controllers.

PKINIT-authenticate as a domain controller, and the KDC issues you a TGT for the DC; from there, DCSync extracts the krbtgt key and the domain is yours. Domain escalation from any authenticated user, with the only required misconfiguration being Microsoft's defaults [@nvd-cve-2022-26923] [@semperis-cve-2022-26923].

The defensive response shipped the same day. Microsoft published KB5014754 on May 10, 2022 -- coordinated disclosure, with the patch shipping in the same window as the CVE -- introducing a new X.509 extension szOID_NTDS_CA_SECURITY_EXT (OID 1.3.6.1.4.1.311.25.2) that carries the requesting principal's SID at certificate issuance.

The KDC's new strong-mapping logic refuses certificates that fail one of four conditions: the SID extension is present and matches; an issuer-serial mapping is present; a Subject Key Identifier mapping is present; or a SHA1-public-key mapping is present. The KB's load-bearing sentence: "In Full Enforcement mode, if a certificate fails the strong (secure) mapping criteria (see Certificate mappings), authentication will be denied." [@ms-kb5014754]

The KB5014754 change-log preserves a forensic artefact of the coordinated-disclosure timeline that is easy to miss. The current change-log row reads, verbatim: "9/10/2025 - Corrected the Enforcement mode date from September 10, 2025, to September 9, 2025." [@ms-kb5014754] An off-by-one date correction, captured in the public KB. The kind of detail that only shows up when a small team has had to ship a date repeatedly against a multi-year audit-to-enforcement schedule.

The enforcement timeline tells you how long even a CVE-class fix took to drive through deployment. Audit mode (May 10, 2022). Enforcement mode with a registry escape that admins could use to revert to compatibility (February 11, 2025). Final cutover with no escape (September 9, 2025) [@ms-kb5014754]. Three years and four months between the patch and the day Microsoft stopped accepting non-strong certificate mappings. Faster than the Credential Guard default-enablement window, but still measured in years.

The naming history deserves a disambiguation. The catalog -- ESC1 through ESC8, the full taxonomy of AD CS misconfigurations -- is Schroeder and Christensen, June 2021 [@specterops-certified-pre-owned]. The wire-level technique name "Pass-the-Certificate" is popularised by AlmondOffSec's PassTheCert PoC (Yannick Méheut, May 4, 2022), which targets LDAP/S via Schannel client-cert authentication when PKINIT is unavailable, as a fallback path for environments where domain controllers do not support certificate-based Kerberos pre-authentication [@almondoffsec-passthecert-github] [@almondoffsec-passthecert-blog]. The blog post documents the KDC_ERR_PADATA_TYPE_NOSUPP error path that diverts the PKINIT-blocked attacker into Schannel.

The AlmondOffSec blog post acknowledges the social attribution of the term: "Note for Googlers: this tool extends the notion of Pass the Certificate, thus dubbed by @_nwodtuhs in his Twitter thread on AD CS and PKINIT." [@almondoffsec-passthecert-blog] The technique name is socially attributed; the catalog framing is editorial.

Note: A common shorthand says that KB5014754 bound NTOWFs to Kerberos, and that this is what forced attackers to shift to certificates. That arrow runs backwards in time. KB5014754 is the response to Certifried, not the cause of Pass-the-Certificate. The technique class was catalogued by Schroeder and Christensen in June 2021, eleven months before KB5014754 shipped, and the PassTheCert tool that gave the technique its wire-level name appeared six days before Certifried's disclosure. The shift to certificates happened because certificates were the next long-term credential type Credential Guard did not isolate.

What does KB5014754 actually close? Three specific CVEs in the Certifried family: CVE-2022-26923 (the original SID-spoof Certifried disclosure), CVE-2022-26931 (UPN / sAMAccountName collision spoof), and CVE-2022-34691 (the certificate-pre-dating-account-creation case) [@ms-kb5014754]. What does it not close? The broader ESC2 through ESC8 catalog, which is administrative hardening rather than CVE-class control. And it does not close ESC9 through ESC16, which were enumerated after KB5014754 shipped and include cases like the CT_FLAG_NO_SECURITY_EXTENSION template flag that exempts a template from the very SID extension the patch introduced [@specterops-certs-patches-2022] [@certipy-wiki-privesc].

The current state of the catalog: as of the 2025 Certipy 5.x documentation, ESC1 through ESC16 is the practitioner enumeration, with each technique characterised by a template-level, ACL-level, CA-administrator-level, NTLM-relay-level, SID-extension-level, or mapping-level abuse primitive [@certipy-wiki-privesc]. Microsoft Defender for Identity's certificates posture assessment tracks nine distinct ESC numbers as of the 2025 documentation -- ten posture assessments, because ESC4 owner and ESC4 ACL are tracked as separate sub-cases (ESC1, ESC2, ESC3, ESC4 owner, ESC4 ACL, ESC6 preview, ESC7, ESC8, ESC11, ESC15) [@ms-defender-id-certs]. Same pattern as Pass-the-Hash in 2012-2014: documentation tells administrators what to do; the structural exposure is downstream of how each enterprise built its templates years earlier.

ESC ID	Class	Closed by KB5014754
ESC1	Template -- enrollee supplies SAN, client-auth EKU, permissive enrollment	Partial: SID extension binds requester at issuance; ESC1 still works if the SID extension is absent
ESC2	Template -- enrollee supplies SAN, Any-Purpose or no EKU	No -- administrative hardening
ESC3	Template -- Certificate Request Agent enrollment-agent abuse	No -- administrative hardening
ESC4	ACL -- writeable template configuration	No -- administrative hardening
ESC6	CA -- `EDITF_ATTRIBUTESUBJECTALTNAME2` flag set on the CA	No -- CA-level hardening (was MS22-23, separately patched)
ESC8	NTLM relay -- HTTP enrolment endpoints reachable from low-privilege contexts	No -- relay-defence hardening
ESC9	Template -- `CT_FLAG_NO_SECURITY_EXTENSION` exempts template from the SID extension	No -- by design
ESC11	NTLM relay -- ICPR RPC endpoint without sign / seal	No -- relay-defence hardening
ESC16	CA -- security-extension disabled at the CA level	No -- CA-level hardening

Table 1. A representative slice of the ESC1-ESC16 catalog showing what KB5014754 closes and what remains administrative hardening [@specterops-certify-wiki] [@certipy-wiki-privesc] [@specterops-certs-patches-2022].

KB5014754 is a CVE-class fix for one sub-case. The broader ADCS catalog is administrative hardening. And the next credential type -- the one that defeats Credential Guard, Protected Users, and KB5014754 simultaneously -- was already shipping in commodity Mimikatz code by August 2020.

8. Pass-the-PRT: The CloudAP Frontier

By August 2020, Microsoft had two architectural defenses against credential replay that the security industry actually trusted: Credential Guard for local Active Directory credentials, and (eighteen months later) KB5014754 for the certificate-replay class. Then a Dutch security researcher named Dirk-jan Mollema published a 21-minute read that broke both, in the same paragraph, by stealing a different credential type.

The credential is the Primary Refresh Token. The two foundational write-ups are Mollema's "Abusing Azure AD SSO with the Primary Refresh Token" [@mollema-prt-abusing] and its follow-on "Digging further into the Primary Refresh Token" [@mollema-prt-digging], both posted in August 2020. The second post is the single most-cited primary source in the fifth generation of the family. Read it once and you understand why Pass-the-PRT is structurally different from everything that came before.

A PRT is a JSON Web Token refresh token issued by Microsoft Entra ID (formerly Azure AD) to Entra-joined or Hybrid-joined Windows devices, paired with a session key (HMAC-SHA256 secret) and bound to a device key registered at device join.

The Microsoft Entra documentation describes the artefact precisely: "A Primary Refresh Token (PRT) is a key artifact of Microsoft Entra authentication ... Once issued, a PRT is valid for 90 days and is continuously renewed as long as the user actively uses the device." [@ms-entra-concept-prt] On Windows the PRT is renewed every four hours during sign-in. The device-key registration binds the PRT to the device that owns it -- and is what an attacker has to work around to use a stolen PRT on a different device.

The Microsoft Entra-issued long-lived refresh token for SSO on Entra-joined or Hybrid-joined Windows devices. Carries a session key (HMAC-SHA256) used to sign per-request `x-ms-RefreshTokenCredential` cookies, and binds to a device transport key registered at device join. Default lifetime is 90 days with sliding renewal as long as the user actively uses the device; an inactivity timeout governs when an idle PRT must be re-acquired [@ms-entra-concept-prt]. The PRT is the load-bearing artefact for Single Sign-On to every Entra-integrated resource the device's user can reach.

The PRT default lifetime is 90 days per the Microsoft Entra documentation, with renewal every four hours during Windows sign-in [@ms-entra-concept-prt]. The 14-day figure that sometimes appears in secondary references is the inactivity timeout on certain device states, not the PRT lifetime itself; this article uses the Microsoft Entra documentation's value to avoid the conflation.

Where the PRT lives is what makes the rest of the architecture work -- and what makes it vulnerable. The PRT is hybrid: issued and revoked cloud-side by Entra ID, stored and used client-side via the CloudAP authentication plug-in, which is loaded into LSASS like any other Windows authentication package.

The load-bearing structural fact is that CloudAP is in LSASS, not behind the LSAISO trustlet. Credential Guard's classical isolation does not extend to the CloudAP plug-in's working memory, because Credential Guard's scope is the three credential categories its design predates -- NT hashes, Kerberos TGTs, and "domain credentials" -- and the PRT is none of those [@mollema-prt-abusing].

The Windows authentication package (`cloudap.dll`, loaded into LSASS) that handles authentication against Microsoft Entra ID for Entra-joined and Hybrid-joined devices. Holds the device's Primary Refresh Token, its session key, and the derived material used to sign per-request PRT cookies. Sits inside LSASS in VTL0, *not* inside the LSAISO trustlet in VTL1; Credential Guard does not currently extend its isolation to CloudAP's working memory.

The mechanism, as Mollema and Delpy developed it through the second half of 2020, runs as follows. Mimikatz dpapi::cloudapkd /unprotect extracts the PRT (the encrypted-by-Entra refresh-token blob) and the session key from CloudAP's working memory.

The attacker constructs an x-ms-RefreshTokenCredential JWT carrying the PRT in the refresh_token claim, is_primary: true, and a request_nonce obtained by an unauthenticated POST against the Entra ID v1 token endpoint at https://login.microsoftonline.com/common/oauth2/token with form-encoded body grant_type=srv_challenge (the server-challenge nonce pattern used by the ROADtools roadtx prt reference implementation; the response is a JSON object with a Nonce field). The signature is HMAC-SHA256 over the JWT under the session key. The completed cookie is presented to login.microsoftonline.com from any machine, and Entra ID returns access and refresh tokens for any resource the original user can reach. Mollema's second post describes the collaboration that built the tooling:

Around the same time Benjamin Delpy took up my 'challenge' of recovering PRT data from `lsass` with mimikatz. We combined forces and ended up with tooling that is not only able to extract the PRT and associated cryptographic keys (such as the session key) from memory, but can also use these keys to create new SSO cookies or modify existing ones. -- Dirk-jan Mollema, *Digging further into the Primary Refresh Token* [@mollema-prt-digging]

The operational tooling closed quickly. Mollema's roadtx prt (part of ROADtools [@roadtools-github]) automates the full chain end-to-end -- extract the material, mint the cookie, complete the OAuth dance, hand the attacker an access token. The Mimikatz dpapi::cloudapkd command landed in the open-source repository the same window. Pass-the-PRT moved from research artefact to commodity tooling in months, not years.

sequenceDiagram participant Victim as Victim device (Entra-joined) participant Attacker as Attacker device participant Entra as login.microsoftonline.com Note over Victim: PRT plus session key held by CloudAP in LSASS Attacker->>Victim: mimikatz dpapi::cloudapkd /unprotect Victim-->>Attacker: PRT (encrypted blob) plus session key Attacker->>Entra: POST /common/oauth2/token grant_type=srv_challenge (unauthenticated) Entra-->>Attacker: request_nonce Note over Attacker: Build x-ms-RefreshTokenCredential JWT Note over Attacker: Sign HMAC-SHA256 with extracted session key Attacker->>Entra: POST /token with PRT cookie Entra-->>Attacker: Access and refresh tokens Attacker->>Attacker: Authenticate to any Entra resource as victim user

Now the analytical core. Pass-the-PRT defeats three Microsoft defenses simultaneously.

First, Credential Guard is out of scope. The CloudAP material is not an NT hash, not a Kerberos TGT, and not "credentials stored by applications as domain credentials" in the verbatim sense the Credential Guard documentation uses. Credential Guard's VBS-based isolation does not extend to CloudAP. The defense was designed in 2015 against the three credential types the family had then; the PRT is a credential type the family had not yet evolved into [@ms-learn-credential-guard].

Second, KB5014754 is out of scope. The PRT cookie does not traverse the KDC's certificate-mapping logic at all; it is a JWT signed by an HMAC and authenticated at the Entra ID token endpoint. The strong certificate mapping that Microsoft drove through five years of audit-to-enforcement timeline has no relevance to a credential that never touches the KDC [@ms-kb5014754].

Third, Protected Users is out of scope. Protected Users is an Active-Directory-only construct, enforced on Windows Server domain controllers and on AD-joined member devices. Entra ID is a separate identity provider with separate enforcement; the 240-minute TGT cap, the NTLM ban, and the RC4 ban that Protected Users enforces simply do not apply [@ms-protected-users].

The TPM-sealing finding is where the architectural pattern becomes most precise. Microsoft began sealing the PRT session key to a TPM-bound key on TPM-2.0-eligible hardware -- a defense that, in principle, makes the raw session key cryptographically non-exportable. Mollema's finding in the August 2020 second post is that the seal does not close the attack, because CloudAP holds derived PRT-cookie-signing material in its own working memory in LSASS, and the attacker only needs the derived material:

despite the session key of the PRT is stored in the TPM whenever possible, this doesn't prevent us from extracting the PRT and the required information to create SSO cookies. The result of this is that regardless of whether the PRT is protected by the TPM or not, with Administrator access it is possible to extract the PRT from LSASS and use the PRT on a different device than it was issued to. -- Dirk-jan Mollema, *Digging further into the Primary Refresh Token* [@mollema-prt-digging]

The structural reason the standard hardware-rooted defense pattern does not transfer: the attacker does not need the raw session key out of the TPM. They need only the in-memory derived material CloudAP itself uses to sign the cookies, and that derived material lives in the same address space Credential Guard does not isolate.

The TPM seals the key. CloudAP uses the key. Whatever CloudAP can read, an attacker with administrator and a memory-access primitive can also read. The defense pattern that worked for NT hashes (move them out of the address space) has not been applied to CloudAP -- and until it is, the TPM seal is a speed bump rather than a wall.

{` // Pedagogical demonstration of the JWT structure used in Pass-the-PRT // cookie minting. Uses placeholder values throughout; no real PRT material.

const base64url = (buf) => Buffer.from(buf).toString('base64') .replace(/=+$/, '').replace(/\+/g, '-').replace(/\//g, '_');

const header = { alg: 'HS256', ctx: 'AAAAAAAA' }; const payload = { // The PRT itself, an opaque refresh-token string Entra issued to the // device. In a real attack this comes from mimikatz dpapi::cloudapkd. refresh_token: 'AQABAAAAAAA...redacted...', // Marks this cookie as a primary refresh token cookie. is_primary: 'true', // Fresh nonce from an unauthenticated POST against the v1 token endpoint // at login.microsoftonline.com/common/oauth2/token with form body // grant_type=srv_challenge (returns JSON with Nonce field; the canonical // server-challenge pattern used by ROADtools roadtx prt). request_nonce: 'AwABAAEAAAAC...', iat: Math.floor(Date.now() / 1000), };

// HMAC-SHA256 over the JWT under the session key recovered from CloudAP. // Placeholder key for demonstration only. const sessionKey = Buffer.alloc(32); // 32 bytes of zeros (fake) const crypto = require('crypto');

const h = base64url(JSON.stringify(header)); const p = base64url(JSON.stringify(payload)); const sig = base64url( crypto.createHmac('sha256', sessionKey).update(h + '.' + p).digest() );

console.log('Header segment: ' + h); console.log('Payload segment: ' + p); console.log('Signature segment: ' + sig); console.log(); console.log('Full PRT cookie: ' + h + '.' + p + '.' + sig); // In a real attack the attacker would now POST this as the // x-ms-RefreshTokenCredential cookie to login.microsoftonline.com. `}

The current partial mitigations are worth enumerating, because none of them closes the gap.

Token Protection (a Conditional Access session control) attempts to ensure that only device-bound sign-in session tokens are accepted at the Entra ID token endpoint for protected resources. The Microsoft Learn page is explicit about both the design intent and the deployment limits: "Token Protection is a Conditional Access session control that attempts to reduce token replay attacks by ensuring only device bound sign-in session tokens, like Primary Refresh Tokens (PRTs), are accepted by Microsoft Entra ID when applications request access to protected resources." [@ms-entra-token-protection] As of the current documentation the supported resources are five named applications: Exchange Online, SharePoint Online, Microsoft Teams, Azure Virtual Desktop, and Windows 365. Browser applications are out of scope; "Token Protection currently supports native applications only. Browser-based applications are not supported." [@ms-entra-token-protection] Most Entra-integrated SaaS is unbound.

Continuous Access Evaluation (CAE) shortens the window during which a stolen PRT is operationally usable, by allowing the token endpoint to revoke tokens within minutes of a triggering signal (password change, risk-based detection, conditional-access policy update) [@ms-entra-cae]. CAE is evaluation-time, not isolation. It shortens the window between extraction and detection-driven revocation; it does not prevent extraction.

Hybrid-joined PRT renewal binding partially closes the cross-tenant case for hybrid Azure AD Join configurations, but does not address the same-tenant Pass-the-PRT case that Mollema's original 2020 posts described [@ms-entra-hybrid-join-plan].

The institutional acknowledgment of the supersession pattern is the verbatim Microsoft Learn sentence already quoted in section 6 [@ms-learn-credential-guard]: written about the 2015 Credential Guard architecture, it accurately predicts the 2020 Pass-the-PRT shift. The credential-replay family has reached the point where every Microsoft defense in the on-prem stack runs in parallel against an attack the on-prem stack cannot reach.

Key idea: Pass-the-PRT defeats Credential Guard, KB5014754, and Protected Users simultaneously because each defense was designed around a different long-term artefact, and the PRT is none of them. The architectural property -- a long-term authentication artefact reachable from the using process is replayable -- is unchanged. The artefact moved.

Six years after Mollema's disclosure, the TPM-resilience finding still holds. The CloudAP plug-in is still in LSASS. Credential Guard still does not extend its boundary. Pass-the-PRT remains the operational frontier in 2026.

9. The 5x5 Matrix and the Irregular Cadence

Five generations of attack. Five generations of defense. They map onto each other unevenly; the gaps are not five years.

The matrix below consolidates the lineage at a glance. Rows are the attack generations (in the order they entered the practitioner literature). Columns are the defense generations (in the order they shipped). Each cell records whether that defense closes that attack on a fully-deployed hardware-eligible 2026 Windows 11 endpoint with the control turned on. "Closed" means the attack returns empty buffers or fails authentication; "Partial" means the defense increases attacker cost or closes one sub-case; "Open" means the defense's design scope does not include that attack.

Attack \ Defense	Mitigating-PtH whitepapers (2012/2014)	Protected Users + RunAsPPL + Restricted Admin (2013-2014)	Credential Guard / LSAISO (2015)	KB5014754 strong mapping (2022)	Token Protection + CAE (2023-2025)
Pass-the-Hash (Ashton 1997, Ochoa 2008)	Open (documentation)	Partial (Protected Users members)	Closed (on enabled endpoints)	Open (not in scope)	Open (not in scope)
Pass-the-Ticket (Delpy 2011, Duckwall+Delpy 2014)	Open (documentation)	Partial (4-hour TGT cap for Protected Users)	Closed (TGT session key in LSAISO)	Open (not in scope)	Open (not in scope)
Overpass-the-Hash (Delpy / Metcalf 2014)	Open (documentation)	Partial (RC4 banned for Protected Users)	Closed (NT hash in LSAISO)	Open (not in scope)	Open (not in scope)
Pass-the-Certificate (Schroeder + Christensen 2021, Méheut 2022)	Open (documentation)	Open (cert keys outside scope)	Open (cert keys outside scope)	Partial (closes Certifried sub-case; ESC2-ESC16 remain)	Open (not in scope)
Pass-the-PRT (Mollema + Delpy 2020)	Open (Entra ID is separate IDP)	Open (Entra ID is separate IDP)	Open (CloudAP not in LSAISO)	Open (not in scope)	Partial (5 named resources; browser apps out of scope)

Table 2. The 5x5 attack/defense matrix. The union of every cell in the rightmost column of "Closed" entries is the set of attacks Microsoft's published 2026 defenses close on hardware-eligible non-DC endpoints with every control turned on; that set is precisely the first three rows.

The matrix makes the structure visible. No single defense closes all attacks, and no single attack is closed by all defenses. The union of every defense closes Pass-the-Hash, Pass-the-Ticket, and Overpass-the-Hash on hardware-eligible non-DC Windows 10/11 systems with all controls enabled. It partially closes Pass-the-Certificate (for the Certifried sub-case) and partially closes Pass-the-PRT (for five named resources). Both of the most recent generations remain operationally open against any deployment that does not run those specific controls -- which is most deployments.

The cadence is just as uneven as the matrix. The original input that prompted this article claimed "every Windows defense against credential replay buys about five years before the attack class evolves to the next credential type." Memorable. Also wrong. The actual timeline produces gaps from eleven months to eleven years, with one negative interval:

1997 -> 2008 (eleven years) for the Samba-patch -> Windows-native pivot. Pass-the-Hash existed for over a decade as a Unix-side novelty before Ochoa's LSASS-injection insight made it Windows-native.
2008 -> 2011 (three years) for the Mimikatz Pass-the-Ticket extension. The same memory-access primitive that animated IAM.EXE was retargeted at a different artefact.
2012/2014 -> 2015 (one to three years) for the Mitigating-PtH whitepapers -> Credential Guard pivot. Documentation took a year and a half to ship; the architectural counter took another.
2021 -> 2022 (eleven months) for the AD CS catalog -> KB5014754 response. Coordinated disclosure compressed this gap; Certifried's CVE-class status forced a CVE-class response.
2020 -> 2025+ (open-ended) for Pass-the-PRT with no Credential-Guard-equivalent shipped. As of the Windows 11 25H2 cycle there is no public roadmap for VBS-class isolation of CloudAP material.

The most striking gap is the 2020/2021 negative interval. Pass-the-PRT (Mollema, August 2020) and the AD CS catalog (Schroeder + Christensen, June 2021) are siblings rather than sequential; Pass-the-PRT predates Pass-the-Certificate as a named technique by ten months, even though the article treats them as Generation 4 and Generation 5 in narrative order. The Generation N -> N+1 framing is taxonomic, not strictly chronological. The reader needs this distinction to read the lineage accurately: the attack class evolves along the architectural property, not along the calendar.

Note: The "every Windows defense buys five years" framing is what you see if you select the cleanest pairings (Mitigating-PtH 2012/2014 to Credential Guard 2015 plus an artificial 2020-targeted "next attack"). When you look at the actual intervals, you see eleven years (1997-2008), three years (2008-2011), eleven months (2021-2022), and an open-ended interval (2020 onwards). The pattern is the architectural property persisting across artefact changes, not a calendar drumbeat.

The storage-class progression is the cleanest way to see the property hold across the lineage. Each row names the long-term artefact, where it lives, and which defense moved or shielded that storage class.

Generation	Long-term artefact	Storage location	Defense that isolated it	Status 2026
1A (1997 Samba)	NT hash (and LM hash)	Local SAM file on disk	"Do not store LAN Manager hash" policy (Vista default-on); SAM hash extraction still works	LM hash retired; NT hash extraction still works
1B (2008 Windows-native)	NT hash	LSASS credential cache	Credential Guard relocates to LSAISO	Closed on Credential-Guard-enabled endpoints
2 (2011 Mimikatz)	Kerberos TGT plus session key	LSASS Kerberos package	Credential Guard relocates to LSAISO	Closed on Credential-Guard-enabled endpoints
3 (2014)	NT hash promoted to RC4-HMAC Kerberos key	LSASS, same buffer as Pass-the-Hash	Credential Guard relocates to LSAISO; KB5021131 makes AES the default	Closed on Credential-Guard-enabled endpoints; RC4 deprecated in favour of AES [@ms-kb5021131]
4 (2021 AD CS catalog)	X.509 certificate private key	CryptoAPI key container, TPM, or smart card	TPM-resident or VSC-resident keys are cryptographically non-exportable; KB5014754 binds certificates to SIDs at issuance	Partial; ESC2-ESC16 misconfigurations remain administrative hardening
5 (2020 Pass-the-PRT)	PRT session key plus derived signing material	CloudAP plug-in in LSASS (session key optionally TPM-sealed)	None deployed; Token Protection partially shields five resources	Open

Table 3. Storage-class progression. Each attack generation targets the next long-term artefact whose storage location is not isolated by the previous generation's defense.

The matrix and the storage-class table jointly produce the structural prediction: each generation shifts to the next available long-term artefact whose storage class the latest defense does not isolate. The graph-based formalisation of these storage-class transitions is the BloodHound edge catalog -- the HasSession, AdminTo, and CanRDP family that operationalises "which principal can reach which credential from where" as a queryable property of an enterprise's directory [@bloodhound-edges]. The pattern predicts a Generation 6 outside whatever isolation scope arrives next.

The most credible candidate today is Pass-the-DeviceKey: extraction or abuse of the device transport key the PRT binds to, or of the CloudAP-derived material the cookie-signing process produces from it [@mollema-prt-phishing]. Mollema's 2023-2025 continuation work documents the underlying device-transport-key primitives in detail; the September 2025 Actor-tokens disclosure shows that cross-tenant abuse of related Entra-side material is also operational in the wild [@mollema-actor-tokens] [@mollema-federated-credentials].

flowchart TD A1[Pass-the-Hash 1A Samba
Ashton 1997] A2[Pass-the-Hash 1B Windows-native
Ochoa 2008] A3[Pass-the-Ticket
Delpy 2011] A4[Overpass-the-Hash
Delpy / Metcalf 2014] A5[Pass-the-Certificate
Schroeder + Christensen 2021] A6[Pass-the-PRT
Mollema + Delpy 2020] A7[Pass-the-DeviceKey forecast] D1[Mitigating-PtH whitepapers
v1 2012, v2 2014] D2[Protected Users + RunAsPPL + Restricted Admin
2013-2014] D3[Credential Guard / LSAISO
2015, default 2022] D4[KB5014754 strong mapping
2022, enforced 2025] D5[Token Protection + CAE
2023-2025] D6[CloudAP isolation forecast] A1 --> A2 A2 --> A3 A3 --> A4 A4 --> A5 A4 --> A6 A6 --> A7 D1 --> D2 D2 --> D3 D3 --> D4 D4 --> D5 D5 -.- D6 A2 -.- D1 A2 -.- D2 A3 -.- D3 A4 -.- D3 A5 -.- D4 A6 -.- D5 A7 -.- D6

If the pattern holds, Generation 6 is already in research literature. Mollema's 2023-2025 continuation work [@mollema-prt-phishing] [@mollema-federated-credentials] [@mollema-actor-tokens] documents the device-transport-key extraction primitives. The only things missing are the name and the commodity tool. The historical pattern says we probably get both before VBS-class CloudAP isolation ships.

10. Open Problems and the 2026-2030 Forecast

The credential-replay family has six load-bearing open problems in 2026. Each is structural rather than mathematical; the cryptographic primitives that would close them already exist.

The architectural lower bound -- the only configuration that closes the family in principle -- is the union of three things.

Universal hardware-rooted non-extractable keys: every long-term authentication artefact lives in a TPM, secure enclave, FIDO2 authenticator, or smart card, with key attestation, and is never released to software memory. Universal protocol-layer token binding: every issued token (Kerberos service ticket, OAuth refresh token, OIDC ID token, SAML assertion) is cryptographically bound to the device that requested it, and a verifier rejects any presentation from a non-bound device. Universal continuous evaluation: every protected resource queries the issuer in near-real-time and revokes within minutes of a triggering signal. Each component is deployed somewhere; none is deployed everywhere; no single vendor controls all three layers.

The five concrete open problems flow from the lower bound.

The CloudAP isolation problem. When does Microsoft extend VBS-class isolation to the CloudAP plug-in's working memory in LSASS? No public roadmap as of 2026. Until it ships, Pass-the-PRT remains operationally open against every Entra-joined Windows endpoint.

The token-binding adoption problem. Token Protection's verbatim 2026 scope is the five named resources enumerated in section 8 [@ms-entra-token-protection], which covers approximately five percent of typical Entra-integrated SaaS surface area; every other Entra-integrated resource accepts unbound tokens. The OAuth working group's RFC 9449 (DPoP, September 2023) standardises proof-of-possession at the OAuth layer [@rfc-9449], but adoption across SaaS providers and enterprise applications is uneven.

The Pass-the-DeviceKey forecast. Mollema's 2023-2025 continuation work exercises device-transport-key extraction primitives, federated-credential persistence on Entra applications, and cross-tenant Actor-token abuse [@mollema-prt-phishing] [@mollema-federated-credentials] [@mollema-actor-tokens]. The pattern of every previous generation predicts that whichever of these primitives commoditises first will be the next named "Pass-the-X" technique.

The ESC9-ESC16 hardening problem. The AD CS catalog has grown from 8 entries (June 2021) to 16 (current Certipy and Certify wikis [@certipy-wiki-privesc] [@specterops-certify-wiki]); most additions are misconfiguration-class rather than CVE-class. ESC9 specifically describes the CT_FLAG_NO_SECURITY_EXTENSION template flag that exempts a template from the very SID extension KB5014754 introduced -- so administrators who turn that flag on for legacy compatibility reasons silently re-enable the Certifried-class abuse path on those templates.

Hardware-backed identity ubiquity. When does the union of Pluton + FIDO2 + virtual smart cards + TPM key attestation eliminate the long-term software-extractable artefact class? Human interactive sign-in to Entra ID can already be fully passwordless on supported hardware. The long tail of service accounts, scheduled tasks, on-prem AD workflows, and legacy applications resists migration; the migration is a years-long enterprise project, not a feature flag.

The non-Microsoft sibling lineages. The credential-replay family is not Windows-specific. Okta session-cookie theft, Google IDP refresh-token reuse, Apple ASWebAuthSession token replay, and AWS STS session-token theft all face the same architectural property. An enterprise running Microsoft plus Okta plus Google inherits the union of every vendor's residual replay surface. The family generalises beyond Microsoft because the architectural property generalises beyond Microsoft.

Okta's `sessionToken` and OAuth `refresh_token` artefacts live on the device that requested them, and have been used in commodity offensive tooling since at least 2022. Google's IDP refresh tokens face the same exposure surface on managed Chromebooks. Apple's ASWebAuthSession tokens are device-bound at the platform level, which closes the cross-device replay case but not the same-device extraction case. AWS STS session tokens are not device-bound at all. The credential-replay family is a property of long-term software-extractable authentication artefacts in general; this article is Windows-specific only because Windows has the longest documented lineage.

The institutional position is that the protocol-level fix is unavailable -- Microsoft's framing of Pass-the-Hash as a structural property of NTLM generalises directly to every later generation. A universal fix would require replacing every long-term software-extractable artefact globally with hardware-bound primitives, with mandatory token binding at every issuer and every resource server, with continuous evaluation everywhere. Each step is incrementally closable; the union has not yet closed for any deployment.

Note: Universal hardware-rooted non-extractable keys, universal protocol-layer token binding, universal continuous evaluation. Each component is deployed somewhere; none is deployed everywhere. No single vendor controls all three layers.

The architectural property the family shares has held for twenty-nine years; the defensive lineage will not close it without making every long-term artefact live in hardware-rooted isolation that exceeds the host's privilege. Whether that happens in the next five years, the next ten, or the next twenty-five, is the open question the next chapter of this lineage will answer.

11. The 2026 Defender Playbook

Architectural humility does not mean defensive passivity. The 2026 estate is defensible against generations 1 through 3 and partially against generation 4; the playbook is to deploy every available control while reading Mollema's 2025 posts to know what's coming for generation 5 and beyond.

Credential Guard everywhere it can run. Hardware-eligible non-DC Windows 10/11 endpoints, with the four-residual disclosure (AD database, DCs, certificate keys, CloudAP) documented for the SOC so that detection engineering does not assume Credential Guard covers categories it explicitly excludes [@ms-learn-credential-guard].
LSA Protection (RunAsPPL), UEFI-anchored stacked underneath, per itm4n's "complementary" framing [@itm4n-lsass-runasppl]. The UEFI-anchored variant resists the registry-based bypass that a kernel-mode attacker can otherwise apply at boot.
Authentication Silos and Protected Users for Tier-0 accounts. Expect to encounter unconstrained-delegation breakage on legacy services and budget remediation; the 240-minute TGT cap is the lever that prevents long-lived Tier-0 ticket reuse [@ms-protected-users].
KB5014754 strong-mapping enforcement -- fully on by the September 9, 2025 cutover -- plus an annual certificate-template audit cycle against the ESC1-ESC16 catalog using Certipy or PSPKIAudit [@ms-kb5014754] [@certipy-wiki-privesc]. The audit is the load-bearing control because the strong-mapping fix only closes Certifried-class abuses; the template misconfigurations Schroeder and Christensen catalogued are still administrative responsibility.
Conditional Access with Token Protection where supported -- the five resources Microsoft Learn enumerates [@ms-entra-token-protection]. Device-bound sign-ins for privileged accounts; FIDO2 for human interactive sign-in. Know that the long tail of Entra-integrated SaaS does not enforce binding, and that a stolen PRT used against an unbound resource will still authenticate.
PRT-extraction telemetry. Detect CloudAP-plug-in token access from non-CloudAP processes; tie to Endpoint DLP; alert on out-of-band access to cloudap.dll-owned regions of LSASS memory. Mollema's roadtx and BARK produce signal patterns worth modelling.
Mental model: assume the PRT is the next NT hash. Architect today as if Credential Guard for CloudAP shipped tomorrow -- which means TPM-attested device joins as standard, FIDO2 for every human sign-in, hardware-backed identity for service accounts wherever the vendor supports it, and conditional access policies that treat unmanaged or non-attested devices as untrusted by default.

Open PowerShell as administrator and run:

Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard | Format-List

The result of interest is SecurityServicesRunning. A value of 1 in that list means Credential Guard is actively running (per the Win32_DeviceGuard documentation: 1 = Credential Guard, 2 = HVCI, 3 = System Guard secure launch, etc.). SecurityServicesConfigured tells you what the policy intends; SecurityServicesRunning tells you what the hypervisor is actually enforcing right now. The two values disagree more often than you would expect, usually because the hardware did not meet a prerequisite at boot.

Note: The minimum-viable layer: Credential Guard on every hardware-eligible non-DC endpoint, KB5014754 enforcement-mode certificate strong mapping with an annual ESC catalog audit, and PRT-extraction telemetry tied to a real detection workflow. The first two are commodity Microsoft features that close real attack classes today; the third is the only meaningful signal you can get on the attack class that none of the published defenses currently closes.

None of this closes Pass-the-PRT. All of it shortens the dwell time.

12. Frequently Asked Questions

No. The Primary Refresh Token sits in the CloudAP plug-in, which is outside Credential Guard's verbatim three-credential scope -- see section 6 ("What does Credential Guard isolate?") and section 8 ("Pass-the-PRT defeats three Microsoft defenses simultaneously") for the full mechanism. No. The 1997 Ashton patch and the 2008 Ochoa Windows-native pivot are both pre-Mimikatz; see section 1 and section 3 for the full origin story. Mimikatz is the dominant *tool* (May 2011 first release) but it is not the *origin* of Pass-the-Hash. No. The PRT is *hybrid* -- issued and revoked cloud-side by Entra ID, but stored and used client-side via the CloudAP plug-in inside LSASS. See section 8 ("Where the PRT *lives*") for why this hybrid architecture is what makes Pass-the-PRT operationally tractable today. No. It closed the three Certifried-class CVEs (CVE-2022-26923, CVE-2022-26931, CVE-2022-34691) but not the broader ESC2 through ESC16 catalog. See section 7 ("What does KB5014754 actually close?") and Table 1 for the per-template breakdown. For human interactive sign-in to Entra ID, mostly, if the entire enterprise migrates -- the FIDO2 authenticator holds a non-extractable private key in hardware, and the resulting authentication is bound to that key. For service accounts, scheduled tasks, on-prem Kerberos workflows, hybrid identity scenarios, and the long tail of legacy applications, no -- those paths still rely on long-term software-extractable artefacts (passwords, hashes, keys) by construction. The architectural counter is universal hardware-rooted non-extractable keys plus universal token binding plus universal continuous evaluation; the operational reality is partial coverage. No public v3. See section 5 ("The Mitigating-PtH v3 that never shipped") for the source-by-source disambiguation against Microsoft Download Center ID 36036.

13. The Pattern That Outlived Six Defenses

The 1997 patch and the 2026 attack are the same attack because the architectural property the family shares is unchanged. The artefact moved; the property did not.

A long-term authentication artefact reachable by the using process is replayable. The NT hash sat in LSASS on Windows NT 4.0 and replayed against SMB. The Kerberos TGT sat in LSASS on Windows Server 2003 and replayed against Kerberos services. The NT hash sat in LSASS on Windows Server 2008 and replayed against the KDC's RC4-HMAC authentication path as a real Kerberos client.

The X.509 certificate private key sat in a CryptoAPI key container on Windows Server 2012 R2 and replayed against PKINIT-supporting domain controllers as the principal in the SAN. The Primary Refresh Token sits in the CloudAP plug-in inside LSASS on Windows 11 23H2 today, and replays against Entra ID as the device's user from any machine that holds the extracted session key.

Each defense relocated the artefact to a harder-to-reach storage class. The "Do not store LAN Manager hash" policy retired LM. RunAsPPL marked LSASS as a Protected Process Light. Credential Guard moved NT hashes and TGT session keys out of LSASS in VTL0 into the LSAISO trustlet in VTL1. KB5014754 bound certificates to SIDs at issuance, so that a certificate without the SID extension fails strong mapping at the KDC. Token Protection bound PRTs to devices, so that a stolen PRT used against a supported resource from a non-bound device fails.

Each defense was real. Each closed a generation. The family did not close.

The reason the family does not close is structural. Every generation finds the next long-term artefact whose storage class the latest defense did not isolate. Pass-the-Hash worked because the NT hash was reachable. Pass-the-Ticket worked because the TGT was reachable. Overpass-the-Hash worked because the NT hash was reachable and the KDC accepted RC4-HMAC. Pass-the-Certificate worked because certificate templates were misconfigured and the SID extension did not exist. Pass-the-PRT works because CloudAP is in LSASS in VTL0 and Token Protection covers five resources.

The architectural lower bound -- universal hardware-rooted non-extractable keys plus universal token binding plus universal continuous evaluation -- is the only configuration that closes the family, and it is not deployed anywhere as a complete stack.

The playbook in the previous section is what to do today. The forecast in section 10 is what to architect for next. The closing observation is the one this article exists to register: when you read about the next named "Pass-the-X" technique, you already know what it will look like. A long-term authentication artefact, reachable from the process that holds it, replayed from a different machine, defeating the latest defense because that defense was designed for a different artefact.

Generation 6 is already in research literature. The only thing missing is the name.

Above the Kernel: The Windows Security Wars Part 4 (2015-2019)

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

Between July 2015 and December 2019, Windows shipped its largest structural security discontinuity since the NT design itself: Virtualization-Based Security (VBS), which moves the credential store and the kernel code-integrity policy into a Secure Kernel running at a privilege level the NT kernel cannot reach. In the same five-year window, ransomware industrialized from spray-and-pray to double extortion -- WannaCry, NotPetya, Ryuk, REvil, Maze -- and a third axis, Meltdown / Spectre, proved the CPU itself could be the attacker's primitive. The paradox of simultaneity is the whole story: a kernel-isolated 2017 Enterprise laptop and a paralyzed NHS trust both ran "Windows" that May 12, and the difference between them was not architecture but operations -- a missing patch on a network nobody had segmented.

1. Two Scenes, One Five-Year Window

Scene A. A red-team operator, sometime in late 2016, sits in front of a freshly-imaged Windows 10 1607 Enterprise laptop with Credential Guard enabled. They open an elevated PowerShell, drop mimikatz.exe to disk, launch it, type privilege::debug. The prompt returns '20' OK. They type sekurlsa::logonpasswords. Output scrolls. The NTLM and Kerberos fields, where the cached hash and the Ticket Granting Ticket would normally appear, are empty. Not denied. Not access-restricted. Empty. The local LSASS process still exists; it still answers requests; the API surface is intact. But the secrets the operator came to read no longer live in this kernel.

Scene B. 11:00 a.m. UTC, May 12, 2017. The Royal London Hospital's radiology department. A workstation displays a red ransom note in eight languages. By 4:00 p.m., the National Audit Office will later determine, the attack has disrupted at least 34 percent of NHS trusts in England; some 19,000 patient appointments will be cancelled; ambulances will divert; junior doctors will hand-write prescriptions on paper [@nao-wannacry]. The exploit that delivered the worm to that machine, CVE-2017-0144, is one of the SMBv1 remote code execution flaws patched in Microsoft Security Bulletin MS17-010 [@ms-ms17-010] [@nvd-cve-2017-0144]. The patch shipped on March 14, 2017. It is, on May 12, one month and twenty-eight days old [@ms-ms17-010].

Both scenes happened. Both Windows boxes ran versions of the same operating system released in the same five-year window. Neither scene is hyperbole.

How can both be true at once? And what does the answer teach us about architectural defense -- its limits and its genuine accomplishments?

2. The Same-Privilege Paradox (1993-2014)

Here is a sentence to carry through the rest of this article: a defense that lives at the same privilege level as the attacker can always be turned off.

That sentence is the lesson of every Windows defense built between NT 3.51 in 1993 and Windows 8.1 in 2013. It is also the reason VBS had to exist at all.

Consider the pattern. The NT security model rests on access tokens and privileges. The privilege named SeDebugPrivilege lets a holder open any other process and read its memory. Local administrators get it by default; Mimikatz, released by Benjamin Delpy in May 2011, weaponized it [@wired-mimikatz]. Once an attacker reached local SYSTEM, SeDebugPrivilege let them walk into the Local Security Authority Subsystem Service (LSASS) and lift NTLM hashes and Kerberos tickets verbatim. The privilege check was working exactly as designed; the design assumed that whoever had the privilege deserved the data.

In 2005, with x64 versions of Windows Server 2003 SP1 and Windows XP, Microsoft introduced Kernel Patch Protection -- PatchGuard -- alongside Kernel-Mode Code Signing [@ms-patchguard]. PatchGuard's job was to detect modifications to critical kernel structures (the SSDT, the IDT, the GDT) and bugcheck the machine if it saw tampering. It was a watchdog inside the kernel watching the kernel.

By 2007, the indie research journal Uninformed published Skywing's third installment in a public series demonstrating how a kernel-mode attacker could disarm PatchGuard by rewriting its own code paths in-place [@skywing-patchguard]. The bypass was not a clever exploit; it was an inevitability. A monitor running in ring 0 has no privilege the rootkit lacks.

Driver Signing Enforcement followed the same logic and met the same fate [@ms-patchguard] [@skywing-patchguard]. So did Authenticode, AppLocker, and every other gate placed at the attacker's reachable privilege level. James Forshaw's August 2016 Project Zero work on AppContainer escape via shadow object directories rounded out the pattern: even the lowest-privilege sandboxes on Windows could be punctured by symbolic-link redirection executed at the sandbox's own privilege level [@pz-forshaw-shadow].

By 2012, three independent vectors had converged on the same insight. Bromium, co-founded by Xen architect Ian Pratt, shipped vSentry: a Type-1 micro-hypervisor that wrapped every risky task -- a browser tab, an opened document, an email attachment -- in its own micro-VM running underneath the Windows kernel [@wiki-bromium] [@silicon-bromium]. Microsoft's own massive investment in Hyper-V for Server 2012 had matured the company's hypervisor codebase. Intel's broad consumer-silicon rollout of Extended Page Tables and Second-Level Address Translation made hardware-assisted virtualization the default rather than the exception.

The structural observation that any defensive mechanism running at the same CPU privilege level as the attacker can be disabled by the attacker. Gates at ring 3 fall to ring 3 code; gates at ring 0 fall to ring 0 code. The only structural escape is to relocate the defender to a privilege level the attacker cannot reach. gantt title Windows defenses 1993-2014 and what disarmed each one dateFormat YYYY axisFormat %Y section Ring 3 gates SeDebugPrivilege (NT 1993) :done, sedebug, 1993, 2011 Mimikatz weaponization :crit, mimi, 2011, 2012 AppContainer (Win 8 2012) :done, appc, 2012, 2016 Symbolic link bypass (Forshaw) :crit, fshaw, 2016, 2017 LSA Protection (RunAsPPL) :done, ppl, 2013, 2015 mimidrv.sys PPL bit removal :crit, mimidrv, 2015, 2016 section Ring 0 gates PatchGuard (Server 2003 SP1) :done, pg, 2005, 2007 Skywing PatchGuard bypass :crit, sky, 2007, 2008 Driver Signing Enforcement :done, dse, 2007, 2012

The shared pattern in those tracks is not a series of individual failures. It is one structural failure repeated. Each "broken" line is a same-privilege primitive arriving on schedule and turning off the gate above it.

If every same-privilege defense fails the same way, what does a defense that does not live at the same privilege level look like?

3. Why Every Pre-VBS Credential Fix Failed

Picture a penetration tester in early 2015 working on a Windows 8.1 Pro host. The customer has done its homework. LSA Protection is enabled per Microsoft's guidance: the registry key HKLM\SYSTEM\CurrentControlSet\Control\Lsa\RunAsPPL is set to 1, so the operating system launches lsass.exe as a Protected Process Light [@ms-lsa-protection]. The tester opens Mimikatz, types privilege::debug, gets OK, and runs sekurlsa::logonpasswords. Access denied. The user-mode OpenProcess call against a PPL target fails for any non-PPL caller, regardless of how much administrator the caller has.

That looks like a win for the defender. It is not.

The tester drops to disk the signed Mimikatz driver, mimidrv.sys. They load it with a single sc create / sc start pair. From kernel mode, the driver locates the EPROCESS structure for LSASS and clears the Protection bits in the _PS_PROTECTION field. From the same elevated PowerShell, the tester re-runs sekurlsa::logonpasswords. The hashes scroll past.

The PPL bit was a gate. The gate was at the same ring as the lever that opened the gate. The lever was a signed kernel driver shipped by the same project that shipped the dumper.

itm4n, who maintains the most-cited reference write-up on RunAsPPL behavior, puts the point in one sentence: "Credential Guard and LSA Protection are actually complementary" [@itm4n-runasppl]. They are complementary because they live at different privilege boundaries. PPL is a same-privilege gate inside VTL0. Credential Guard, as we will see in Section 5, is something structurally different.

"Credential Guard and LSA Protection are actually complementary." -- itm4n, "Do You Really Know About LSA Protection (RunAsPPL)?"

Microsoft did not stop at PPL. Between 2013 and 2014 the company shipped three credential-theft mitigations, each genuinely useful, none structurally sufficient.

Defense (year)	What it stops	What still works
Restricted Admin RDP (KB2871997, April 2014)	RDP no longer pushes plaintext or NTLM credentials to the destination machine	Lateral movement via pass-the-hash from a locally-captured hash; any local credential extraction on the source machine
Protected Users security group (Server 2012 R2, Oct 2013)	Disables NTLM and CredSSP credential delegation for member accounts; pre-Windows 8.1 cached creds purged	Plaintext credential capture during interactive sign-in; non-member accounts; pass-the-ticket once a TGT is obtained
LSA Protection / RunAsPPL (Win 8.1, Oct 2013) [@ms-lsa-protection]	User-mode `OpenProcess` against `lsass.exe` for non-PPL callers fails; conventional Mimikatz from user-land is blocked	A kernel-mode primitive (`mimidrv.sys`, BYOVD, or a vulnerable signed driver) clears the PPL bits from `_PS_PROTECTION` and the dump proceeds

Read the right-hand column as a single sentence. Every defense in the left column was bypassed by the same class of move: the attacker reached a privilege at or above the privilege of the gate, and then the gate opened.

That is not a flaw in any one of these features. That is the same-privilege paradox arriving in three different costumes.

itm4n's full write-up is worth reading end-to-end if you defend Windows endpoints. The author's PPLdump proof-of-concept builds the BYOVD-against-PPL attack as a single tool, and the post is unambiguous that PPL is a "same-privilege gate" while Credential Guard is a "cross-privilege isolation" -- the exact distinction this section turns on.

The reader who has watched a working defender press-release call any of these features "the answer to Mimikatz" will recognize the move by now. Every fix between 2013 and 2014 was at the attacker's privilege level. Every fix between 2013 and 2014 fell to a primitive at that privilege level. The pattern is not implementation bug. The pattern is structure.

If incremental fixes at the attacker's privilege level cannot work, what does a structural fix look like?

4. Three Generations Toward Cross-Privilege Isolation

The structural answer arrived in three generations, only one of which worked.

Generation A2 -- the kernel monitors the kernel (2005-2014). PatchGuard, KMCS, Driver Signing Enforcement. We have already met this generation. Microsoft did not abandon these defenses; the Windows kernel still bugchecks on PatchGuard violations today. But by 2014 the security research community had collectively documented enough kernel-mode bypasses that nobody serious treated PatchGuard as a primary defense [@ms-patchguard] [@skywing-patchguard]. Its function was to raise the cost of low-skill kernel rootkits, not to stop a SYSTEM-privileged attacker.

Generation A3 -- the process is sandboxed (2008-2015). Internet Explorer's Protected Mode (2006), Chrome's renderer sandbox (2008), and Microsoft's own AppContainer model in Windows 8 (2012) reduced the privilege of risky processes -- the browser tab, the document parser, the network listener -- below that of the parent user [@ms-appcontainer]. The threat model is RCE-in-renderer. The threat model is not SYSTEM-privilege takeover, because a sandbox does not stop credential theft once an attacker is already inside the user's session at full privilege. James Forshaw's August 2016 demonstration of AppContainer escape via shadow object directories closed the chapter [@pz-forshaw-shadow]. Sandboxes remain essential at the edge; they do not solve the post-exploitation problem.

Generation A4 -- cross-privilege isolation (2012-2015). Bromium's vSentry, launched commercially in September 2012, was the first product to deliver the idea that mattered: a Type-1 micro-hypervisor running underneath the Windows kernel, with each risky task placed in its own micro-VM [@silicon-bromium] [@wiki-bromium]. The hypervisor sits at a privilege level the guest kernel cannot reach. If the guest kernel falls, the micro-VM is destroyed and the rest of the host is untouched. By 2015, Microsoft had taken the same architectural idea and built it into the operating system. Generation A4 is the only generation in which the defender's privilege level changes.

flowchart LR A1[Generation A2
2005-2014
Kernel monitors kernel
PatchGuard, KMCS, DSE] A2[Generation A3
2008-2015
Process sandbox
AppContainer, Protected Mode] A3[Generation A4
2012-2015
Cross-privilege isolation
Bromium uVisor, then VBS] A1 --> R1[Outcome
Same ring as attacker
Same-privilege bypass] A2 --> R2[Outcome
Below user privilege
Wrong threat model for SYSTEM-takeover] A3 --> R3[Outcome
Above guest kernel
Defender unreachable from VTL0]

The structural lesson, said plainly: the only escape from the same-privilege paradox is to move the defender's privilege level, not to harden the gate.

HP Inc. acquired Bromium in September 2019 [@wiki-bromium]. The uVisor concept survived as HP Sure Click, a vertical-market product shipped on HP business notebooks. Bromium's contribution to the public story of Windows security is that it shipped the cross-privilege-isolation thesis as a working commercial product three years before Microsoft put it in the box. The reader who sees "Bromium" in a vendor presentation now knows the lineage: same idea, narrower market, earlier ship date.

What did Microsoft actually ship?

5. The Breakthrough: VBS, the Secure Kernel, and Trustlets

On July 29, 2015, Microsoft shipped Windows 10 version 1507, build 10240 [@wiki-win10-versions]. The same release window delivered five components -- Virtualization-Based Security, Credential Guard, Device Guard with Windows Defender Application Control, the Antimalware Scan Interface, and Control Flow Guard. One week later, on August 6, Alex Ionescu walked onto the Black Hat USA stage in Las Vegas and explained the internals in a deck titled Battle of SKM and IUM: How Windows 10 Rewrites OS Architecture [@ionescu-bh2015].

That deck is the load-bearing primary for the rest of this section. Where the prose below cites an internal mechanism -- an EKU OID, a process attribute, a syscall ordinal -- it is reading Ionescu first and Microsoft Learn second.

A Windows security architecture that uses hardware virtualization extensions (Intel VT-x, AMD-V) and Second-Level Address Translation to run two isolated kernel environments on the same physical machine: the conventional NT kernel and a stripped-down Secure Kernel. Microsoft's official framing is that VBS "creates an isolated virtual environment that becomes the root of trust of the OS that assumes the kernel can be compromised" [@ms-vbs].

5.1 Hyper-V as the substrate

VBS does not invent a new hypervisor. It reuses the Hyper-V hypervisor Microsoft had already shipped for Server 2008 and matured through Server 2012 [@ms-tlfs-vsm]. On a machine with VBS enabled, the Windows boot path is: UEFI Secure Boot -> Hyper-V hypervisor -> Hyper-V root partition. Inside that root partition, the NT kernel runs in one Virtual Trust Level and the Secure Kernel runs in another.

A Hyper-V hypervisor abstraction that partitions a single virtual machine into multiple privilege domains. Higher-numbered VTLs are strictly more privileged than lower-numbered ones; lower VTLs cannot read or write higher-VTL memory. The Hyper-V Top-Level Functional Specification reserves up to 16 VTLs, of which only VTL0 (NT kernel) and VTL1 (Secure Kernel) are used in shipped Windows configurations [@ms-tlfs-vsm].

A process running with full SYSTEM privilege in VTL0 sees the conventional NT API surface. It can call NtReadVirtualMemory on any VTL0 process. It cannot read VTL1 memory at all, because the hypervisor's Extended Page Tables for VTL1 simply do not map VTL1 pages into the VTL0 address space. The Mimikatz dumper that read lsass.exe in 2011 is technically still running on the new machine. It is just reading the empty husk of LSASS, because the secret bytes were never copied into VTL0 in the first place.

5.2 The Secure Kernel

securekernel.exe, the binary that backs VTL1, is on the order of a few hundred kilobytes. It has no device drivers. It has no graphics stack. Its scheduler is minimal [@ionescu-bh2015]. Its paging is handled by asking the VTL0 NT kernel for help -- the Secure Kernel treats the NT kernel as an untrusted resource manager that may return a page or not, and signs and encrypts anything it sends out to be paged. The smallness is not aesthetic. Smallness is part of the threat model. The Secure Kernel is small so that its attack surface is enumerable, and so that the team responsible for its correctness can review every line.The audited binary size is also why VBS does not run user applications in VTL1. The Secure Kernel hosts only "trustlets" -- a tightly bounded set of Microsoft-signed processes designed to do one cryptographic or measurement task each. Putting your code in VTL1 is not on the application developer's path; it is a privilege Microsoft grants its own modules.

5.3 Isolated User Mode and trustlets

Above the Secure Kernel, in user-mode VTL1, runs a stripped-down user-mode environment Microsoft calls Isolated User Mode (IUM). The processes hosted by IUM are called trustlets.

The VTL1 user-mode environment in which trustlets execute. IUM provides a deliberately reduced syscall surface compared to VTL0 user mode -- Ionescu's BH 2015 deck enumerates an approximately 48-syscall allow-list, all routed through the Secure Kernel rather than through `ntoskrnl.exe` [@ionescu-bh2015]. A Microsoft-signed process that runs in Isolated User Mode and is protected from VTL0 inspection. A binary becomes a trustlet only by passing five gates at process creation, all enumerated in Ionescu's Black Hat 2015 deck [@ionescu-bh2015]: (1) a process attribute set on the `NtCreateProcessEx` call, (2) two Enhanced Key Usage OIDs in the Authenticode signature at Signature Level 12 -- the Microsoft Windows System Component Verification EKU `1.3.6.1.4.1.311.10.3.6` and the IUM EKU `1.3.6.1.4.1.311.10.3.37`, (3) a `.tpolicy` PE section, (4) a Trustlet Instance GUID, and (5) loading via the trustlet-specific loader that enforces the syscall allow-list.

The two EKU OIDs are worth memorizing because they are the primary way a defender or auditor can tell, by inspecting a signed binary, whether it is permitted to run as a trustlet at all. Ionescu's deck flagged a typographic error in one OID on a slide; cross-cite Microsoft documentation for the canonical form. The OIDs above are the canonical form [@ionescu-bh2015].

The five-gate pattern matters because it explains what an attacker has to do to create a trustlet, and the answer is: forge a Microsoft signature. The five gates are not security in series; they are security in identity. A binary either has the EKUs Microsoft issues or it does not.

5.4 The canonical 1507-era trustlet roster

Three trustlets shipped in the first 1507 wave. Ionescu's deck enumerates their integer IDs [@ionescu-bh2015]:

Trustlet ID 1 -- LSAISO (the Local Security Authority Isolated). The Credential Guard secret-keeper. Holds the NTLM hashes, the Kerberos Ticket Granting Tickets, and any other credentials Credential Guard is protecting.
Trustlet ID 2 -- vTPM. The virtual Trusted Platform Module used by Hyper-V shielded VMs in the Server 2016 timeframe.
Trustlet ID 3 -- the Biometrics trustlet (Windows Hello). Holds biometric template data; in later Windows 11 documentation the same isolation primitive is marketed as Enhanced Sign-in Security (ESS), but that name is a Windows 11-era rebrand and post-dates the 2015 enumeration.

ID 0 in the IUM trustlet table is reserved as a system bootstrap slot per the table's 1-indexing convention; the publicly available 1507-era material -- Ionescu's Black Hat USA 2015 deck and the Windows Internals 7th edition Chapter 7 -- does not separately attest ID 0 as an end-user-deployable trustlet, so it is best read as a system-reserved slot rather than as a named credential-isolation primitive [@ionescu-bh2015] [@mspress-windows-internals-7e].

The trustlet that backs Credential Guard. The conventional LSASS process continues to run in VTL0 and answers the same API calls it always did, but on a Credential Guard-enabled system the NTLM hash and Kerberos TGT are stored inside LSAISO in VTL1. When LSASS needs to use a credential -- for example, to construct a Kerberos pre-authentication response -- it crosses the secure-call channel to LSAISO, which performs the cryptographic operation inside VTL1 and returns only the derived result. The raw secret never crosses the VTL boundary back into VTL0 [@ms-credential-guard].

5.5 The secure-call channel

VTL0 and VTL1 talk via a small set of secure-call ordinals. The canonical primitive Ionescu names is IumSetTrustletInstance at ordinal 0x80000001, paired with a handful of agent-trustlet RPC patterns [@ionescu-bh2015]. The semantic invariant is the same on every call: VTL0 sends a request, VTL1 performs work on protected data, VTL1 returns either a result the requester is permitted to see or a failure. The secret never leaves VTL1.

flowchart TB HW[Hardware
CPU with VT-x/AMD-V
SLAT, IOMMU, TPM 2.0] UEFI[UEFI Secure Boot] HV[Hyper-V hypervisor] HW --> UEFI --> HV subgraph VTL0[VTL0 -- NT environment] NTK[NT kernel
ntoskrnl.exe, drivers] UMP[User-mode processes
LSASS, services, apps] NTK --- UMP end subgraph VTL1[VTL1 -- Secure environment] SK[Secure Kernel
securekernel.exe] IUM[Isolated User Mode
trustlets: LSAISO, vTPM, ESS] SK --- IUM end HV --> VTL0 HV --> VTL1 VTL0 -.secure-call channel.-> VTL1 ATK[Attacker reach
caps at VTL0 SYSTEM] -.-> NTK

The diagram is worth reading twice. The attacker's reachable privilege ceiling is the dashed line into VTL0. Everything above the secure-call channel is, by hardware-enforced page-table convention, unreachable from below.

sequenceDiagram participant App as Caller participant NT as NT kernel participant Loader as Trustlet loader participant SK as Secure Kernel App->>NT: NtCreateProcessEx with trustlet process attribute NT->>Loader: Validate Authenticode signature Loader->>Loader: Check EKU 1.3.6.1.4.1.311.10.3.6 Loader->>Loader: Check EKU 1.3.6.1.4.1.311.10.3.37 Loader->>Loader: Parse .tpolicy PE section Loader->>SK: Assign Trustlet Instance GUID SK->>SK: Install reduced syscall allow-list SK-->>App: Trustlet process handle

5.6 The conceptual hinge

Stop here and reread the architecture. The NT kernel is still compromisable. A driver bug, a BYOVD attack, a kernel race condition -- all of those still pop SYSTEM in VTL0 the same way they did in 2014. VBS does not pretend otherwise. The Microsoft Learn VBS landing page is explicit that VBS "assumes the kernel can be compromised" [@ms-vbs]. The defensive invariant has nothing to do with keeping attackers out of the NT kernel. The defensive invariant is that the secrets they came for are not in the NT kernel.

Key idea: VBS does not protect the NT kernel from compromise. It guarantees that even a fully-compromised NT kernel cannot reach the secrets held in VTL1 trustlets.

That sentence is the entire defensive thesis of Windows 10. Once a reader has it, every component shipped between 1507 and 1909 -- Credential Guard, HVCI, AMSI, CFG, Process Mitigation Policies -- reads as a follow-on instance of the same trust-topology move, modulated by what is hardware-rooted versus software-instrumented.

LSAISO holds the NTLM hash and the Kerberos TGT. That handles credential theft. What about the rest of the attack surface?

6. The 2019 Defensive Stack

By Windows 10 version 1909, shipped November 12, 2019 [@ms-release-info] [@wiki-win10-versions], the VBS architecture had grown a six-feature shipping stack -- Credential Guard, HVCI, WDAC, AMSI, CFG, and Process Mitigation Policies -- plus a cloud-backed endpoint detection and response backend in Defender Advanced Threat Protection. Each closes a specific attack class. Each has a deliberate, named bypass surface. The mature defender's question by the end of 2019 was no longer "is it deployed" but "which class is left."

6.1 Credential Guard

Microsoft's documentation describes Credential Guard's scope precisely: it "prevents credential theft attacks by protecting NTLM password hashes, Kerberos Ticket Granting Tickets (TGTs), and credentials stored by applications as domain credentials" [@ms-credential-guard]. Mechanism: LSA in VTL0 retains the API surface; the secret bytes relocate to LSAISO in VTL1; the secure-call dispatch performs the cryptographic step and returns derived output. The Mimikatz LSASS-scrape family -- sekurlsa::logonpasswords, sekurlsa::tickets, lsadump::secrets -- returns empty fields on a Credential Guard-enabled system because the bytes it scans for are no longer in the address space it can read.

What Credential Guard does not stop is worth naming, because the apologist failure mode is to claim it stops everything. It does not stop pass-the-ticket replay of a TGT captured before Credential Guard was enabled. It does not stop sign-in-time keylogging that scrapes the plaintext password as the user types it. It does not stop a stolen-DC-krbtgt attack that forges Golden Tickets offline. And it does not retroactively scrub credentials presented over RDP outside Restricted Admin mode. Each of those is a meaningful threat. Each lives in a class Credential Guard was not engineered to address.

sequenceDiagram participant App as Application participant LSA as LSA (VTL0) participant SCD as Secure-call dispatch participant ISO as LSAISO (VTL1) App->>LSA: LsaCallAuthenticationPackage LSA->>SCD: secure-call with TGT request SCD->>ISO: forwarded across VTL boundary ISO->>ISO: derive Kerberos session key with stored TGT ISO-->>SCD: derived session key (raw TGT stays in VTL1) SCD-->>LSA: derived result LSA-->>App: success

6.2 HVCI

A Windows VBS feature, also marketed as Memory Integrity, that uses the Hyper-V hypervisor to enforce write-XOR-execute on VTL0 kernel pages via Extended Page Tables. Microsoft's documentation calls HVCI a "critical component that protects and hardens Windows by running kernel mode code integrity within the isolated virtual environment of VBS" [@ms-hvci]. The practical effect is that the classical kernel code-injection attack class -- write shellcode into a kernel page, then execute -- is closed.

HVCI shipped first in Windows 10 1507 in limited form, and rolled out broadly with the 1607 Anniversary Update. Its enforcement is hardware-accelerated by Intel's Mode-Based Execute Control or AMD's equivalent Guest Mode Execute Trap [@ms-hvci]. On supported silicon, the kernel-page W^X check happens in EPT permission bits with no measurable per-page-fault overhead. The attack class HVCI does not close is not "rootkit"; the attack class HVCI does close is "kernel code injection". An attacker can still call existing kernel functions in unintended sequences -- the data-only kernel attack -- and that is a known and acknowledged residual.

6.3 WDAC

Windows Defender Application Control, the rebranded successor to Device Guard's code-integrity component, enforces kernel-mode and user-mode code-integrity policy authored in XML and compiled to a binary .cip file [@ms-wdac]. The policy is consulted at every image load by CI.dll. Signed-policy mode binds the policy to a signing key and rejects updates that are not co-signed by the same key, which is the canonical answer to the "attacker rewrites the policy file from SYSTEM" objection.

WDAC's known weaknesses are not architectural. They are XML-authoring complexity (production policies routinely run to thousands of rules), bring-your-own-vulnerable-driver against permissive driver allow-lists, and abuse of legitimately-signed Living-Off-the-Land binaries -- rundll32.exe, regsvr32.exe, msbuild.exe -- that pass any signature-based allow-list because Microsoft signed them itself. AppLocker, the older peer technology that ships in Pro SKUs, is functionally subsumed; new deployments default to WDAC [@ms-wdac].

6.4 AMSI

The Antimalware Scan Interface is a Component Object Model interface that lets script-host runtimes -- PowerShell, Windows Script Host (JScript and VBScript), Office VBA, and WMI -- hand a freshly-deobfuscated string buffer to the configured anti-malware provider before executing it [@ms-amsi].

A user-mode COM interface introduced in Windows 10 1507 that allows scripting and macro hosts to submit a buffer (typically a deobfuscated script body) to the configured anti-malware provider for inspection before execution. Lee Holmes's June 9, 2015 Microsoft Security Blog post announced AMSI alongside the Windows 10 1507 ship [@ms-leeholmes-amsi]. Microsoft Defender is the default provider; third-party engines register via `IAntimalwareProvider`.

AMSI matters because pre-AMSI, an obfuscated PowerShell command line was opaque to the anti-malware engine until after it had run. AMSI runs the engine on the post-deobfuscation buffer. The engine sees the cleartext.

The bypass class AMSI exposes is a deliberate tradeoff. AMSI is a hook from user-mode script hosts. An attacker who already has code execution in the same user-mode process can patch the AMSI hook out -- the canonical reflection trick sets AmsiUtils.amsiInitFailed to True via .NET reflection, and MDSec's June 2018 PowerShell AMSI evasion write-up walks through the family in detail [@mdsec-amsi-bypass]. AMSI is a hook, not a sandbox. The bypass surface is part of the design tradeoff.

AMSI did not ship as a single event. Windows 10 1507 (July 2015) brought PowerShell 5.0, Windows Script Host, and Office VBA macro coverage. Office 365 client applications integrated AMSI for Office VBA macros in September 2018 per Microsoft's announcement [@ms-office-amsi]. The Windows 10 1903 release in May 2019 added the AMSI-for-WMI provider [@ms-win10-1903]. The same product name covered four very different runtimes, and the runtime that was missing from your endpoint was the runtime an attacker used. Treat "AMSI is enabled" as a question with four sub-questions until 1903.

6.5 Control Flow Guard

Burow, Carr, Nash, Larsen, Brunthaler, Payer, and Franz's 2017 ACM Computing Surveys review Control-Flow Integrity: Precision, Security, and Performance is the academic reference that classifies what CFG actually is [@burow-cfi-csur2017]. In the Burow et al. taxonomy, CFG is forward-edge, coarse-grained, software CFI.

A platform security feature that "was created to combat memory corruption vulnerabilities" by validating indirect call targets against a compile-time-known set of valid functions [@ms-cfg]. The compiler emits a call to `__guard_check_icall_fptr` before every indirect call; the runtime consults an OS-maintained bitmap of valid call targets in the loaded process image; an invalid target traps to the kernel and the process is terminated.

The mechanism is small enough to describe in code. The OS maintains a per-process bitmap indexed by 16-byte-aligned function addresses; each bit indicates whether that address is a valid indirect-call target. Before every indirect call, the compiler emits a bitmap lookup. If the bit is clear, the program is terminated.

{` // Simulated CFG bitmap and indirect-call check const bitmap = new Uint8Array(1024);

function markValidTarget(addr) { // Each bit covers a 16-byte-aligned function address const bitIndex = (addr >> 4); bitmap[bitIndex >> 3] |= (1 << (bitIndex & 7)); }

function guardCheckIcall(targetAddr) { const bitIndex = (targetAddr >> 4); const isValid = (bitmap[bitIndex >> 3] >> (bitIndex & 7)) & 1; if (!isValid) { throw new Error('CFG violation: terminate process'); } }

markValidTarget(0x1400); markValidTarget(0x1500);

guardCheckIcall(0x1400); console.log('Valid call site allowed.');

try { guardCheckIcall(0x1410); } catch (e) { console.log(e.message); } `}

The known limits of CFG are the limits Burow et al. enumerate for forward-edge, coarse-grained, software CFI in general [@burow-cfi-csur2017]. CFG protects only forward edges -- indirect calls and indirect jumps -- so an attacker who corrupts a return address is unaffected by CFG and needs a backward-edge defense (Intel Control-flow Enforcement Technology shadow stacks, in the Part 5 story). CFG's bitmap is coarse: any function whose address is taken is a valid target. And non-CFG-instrumented DLLs in the process create gaps; the bitmap has no bit set for code the compiler did not see.

6.6 Process Mitigation Policies

Per-app process mitigation policies, exposed in 1709 (October 2017) through the Windows Defender Exploit Guard GUI and the PowerShell Set-ProcessMitigation cmdlet [@ms-exploit-protection] [@ms-set-processmitigation], unified the menagerie of legacy Enhanced Mitigation Experience Toolkit settings into a documented, group-policy-deployable per-process opt-in. The kernel-side PROCESS_MITIGATION_POLICY_INFORMATION API shipped in Windows 8; the per-app management surface arrived three years later. Each policy in the 1709 set closes a specific exploitation primitive at the per-process boundary. The ones worth knowing by mechanism:

Arbitrary Code Guard (ACG). ACG refuses to commit a page as PAGE_EXECUTE_READWRITE and refuses any VirtualProtect request that adds executable permission to a page that was previously non-executable. The kernel's MiArbitraryUserPointer and MiAllocateVirtualMemory paths fail those requests with STATUS_DYNAMIC_CODE_BLOCKED. The effect is process-level W^X: an attacker who lands a write primitive cannot turn it into a JIT-the-shellcode-then-execute primitive. The Microsoft Edge content process is the canonical example. Edge's JavaScript JIT runs out-of-process in a separate JIT-only process and ships compiled code to the renderer through a one-way shared-memory channel, so the renderer itself never needs an RWX page. The flag name is PROCESS_CREATION_MITIGATION_POLICY_PROHIBIT_DYNAMIC_CODE_ALWAYS_ON [@ms-set-processmitigation].

Code Integrity Guard (CIG). CIG refuses to load any DLL whose Authenticode signature does not chain to a Microsoft trust root. The PE load path in MiLoadImage validates the signature and fails with STATUS_INVALID_IMAGE_HASH or STATUS_INVALID_SIGNATURE if the policy is violated. This closes the "drop a malicious DLL in the search path and let LoadLibrary find it" exploitation class for a content process. The flag is PROCESS_CREATION_MITIGATION_POLICY_BLOCK_NON_MICROSOFT_BINARIES_ALWAYS_ON. CIG composes with WDAC at the system level: CIG is the per-process narrow case, WDAC is the system policy.

Strict Handle Check. Strict Handle Check terminates the process on the first invalid handle reference rather than returning STATUS_INVALID_HANDLE and recovering. Closes handle-reuse and type-confusion exploitation where the attacker substitutes a handle of a different type and rides the resulting use-after-free, which is a recurring browser-sandbox bug pattern. The flag is PROCESS_CREATION_MITIGATION_POLICY_STRICT_HANDLE_CHECKS_ALWAYS_ON.

Image Load mitigations. Three related policies harden the DLL loader. PreferSystem32Images makes the loader prefer \Windows\System32 before searching the application directory, defeating the classic DLL search-order hijack (a malicious version.dll planted in the app directory). NoLowMandatoryLabelImages refuses to load DLLs whose mandatory integrity label is Low, closing the "browser sandbox creates a Low-IL file, then the parent process loads it" class. NoRemoteImages refuses to load DLLs from UNC paths, defeating cross-machine DLL injection.

Disable Win32k System Calls. Any syscall whose service-table index is in the Win32k range -- the second syscall service table -- is rejected at the entry-stub level. The mitigation removes the GDI and USER attack surface from the process. The Win32k subsystem has historically been the largest source of kernel CVEs, so processes that do not need a window station -- content processes, network services -- can opt out wholesale. The flag is PROCESS_CREATION_MITIGATION_POLICY_WIN32K_SYSTEM_CALL_DISABLE_ALWAYS_ON. Edge content processes ship with it on. Chromium's --disable-win32k-lockdown flag is the dual-use override developers reach for when something downstream breaks.

The 1709 set also keeps the conventional triad -- ASLR with bottom-up randomization, Data Execution Prevention, and a NoCFG-allowed-RWX refusal -- applied per-process.

The Edge content process is the canonical "stack of mitigations" example. It enables almost the full PMP suite simultaneously: ACG, CIG, Disable Win32k, the Image Load mitigations, Strict Handle Check, AppContainer, and an AC sandbox. That stack is what makes an Edge content-process RCE not equivalent to a SYSTEM-level Windows compromise. The attacker has compromised the renderer, but still faces a sandbox escape, then an elevation of privilege, then (depending on the target) a credential-extraction step before reaching anything Credential Guard then closes.

6.7 Defender ATP, later Defender for Endpoint

The cloud-backed endpoint detection and response backend launched as Windows Defender Advanced Threat Protection in 2016 and was renamed Microsoft Defender for Endpoint in September 2020 [@ms-mde-overview].

"Defender ATP" and "Defender for Endpoint" are the same product. The 2020 rename matters only for citation literacy: pre-2020 sources cite ATP, post-2020 sources cite MDE, and confusing the two as separate products is a common reading error.

What MDE actually sees. The sensor consumes a curated set of Event Tracing for Windows providers and file-system and registry events: Microsoft-Windows-Kernel-Process for process create and exit; Microsoft-Windows-Kernel-Image for image load; the file-system minifilter for create, write, and delete; the registry transaction log for create and write; Microsoft-Windows-Kernel-Network for network connections; the LSA and Kerberos authentication providers for authentication events; the AMSI script-content stream for post-deobfuscation script bodies; the Defender behavioral-engine fire events; and the per-process Code Integrity event stream that surfaces HVCI violations. That last stream is the SOC's anchor for HVCI-violation telemetry and is the one piece of integration no third-party EDR can replicate, because it depends on running inside the VBS substrate Microsoft also ships.

Detection latency tiering. The cloud-correlation pipeline operates in two tiers. Single-event high-confidence detections -- a known-malicious hash, an AMSI Mimikatz string match, a Cobalt Strike named-pipe pattern -- fire in seconds to low minutes. Behavioral aggregation across a process tree -- Ryuk-style staging behavior, Big Game Hunting lateral-movement patterns, Emotet-to-TrickBot-to-Ryuk chains -- fires in minutes to low hours. The two-tier architecture is the detection-philosophy distinction MDE held against its 2019 EDR competitors.

The 2019 EDR competitor field. Four credible competitors shipped comparable cloud-correlation architectures by the 2019 cutline. CrowdStrike Falcon was the cloud-native sensor with the heaviest cloud-side intelligence pipeline of the era; CrowdStrike Inc. was founded in 2011 with the cloud-native vision, and the Threat Graph correlation platform debuted with Falcon in June 2013 and has expanded continuously since. Carbon Black carried the legacy Bit9 application-allow-list lineage with a behavioral hybrid layered on top, and was acquired by VMware in October 2019. SentinelOne shipped a lighter kernel agent with on-endpoint behavioral analytics, founded in 2013. Cylance staked out the divergent philosophical position of pre-LLM-era machine-learning static analysis with no behavioral pipeline at all, and was acquired by BlackBerry in February 2019.

All four offered cloud-correlation EDR by the 2019 cutline. MDE's distinguishing feature was OS-native integration with Defender, the ETW providers, and the VBS substrate -- specifically, the per-process Code Integrity event stream the third-party agents could not see.

Together, the six VBS-anchored pillars plus Defender for Endpoint constitute what a 2019 defender meant by "the modern Windows endpoint." A reasonable summary is the head-to-head table:

Pillar	Privilege model	Closes	Known residual
Credential Guard	Cross-VTL isolation	Mimikatz LSASS-scrape family	Pre-CG TGTs, sign-in keyloggers, stolen-DC krbtgt
HVCI	Cross-VTL kernel W^X	Classical kernel code injection	BYOVD, data-only kernel attacks
WDAC	Kernel-enforced CI policy	Unsigned and unauthorized code	LOLBins, BYOVD against permissive policies
AMSI	User-mode COM hook	Post-deobfuscation script visibility	In-process hook patches
CFG	Compiler-inserted forward-edge CFI	ROP gadget chains via indirect call	Return-address corruption, non-CFG DLLs
Process Mitigation Policies	Per-app opt-in mitigations	Per-process exploit primitives	Apps that do not opt in

The Windows kernel performance impact of KVA Shadow on older silicon will preview in Section 10 -- MariaDB's MyISAM workload regressed 37 to 40 percent on Haswell-era CPUs when the Meltdown mitigations landed [@mariadb-kpti]. That is the empirical anchor for "more significant slowdowns" in Terry Myerson's January 2018 tiered guidance [@ms-myerson-meltdown].

This is the stack Microsoft shipped. In the same five years, three other OS communities -- Linux, Apple, and ChromeOS -- shipped their own answers to overlapping problems, and the formal-verification community produced a fourth. How do those four answers compare?

7. Competing Approaches: Linux KPTI, Apple T2, ChromeOS, seL4

Microsoft's VBS is one of four serious architectural answers shipped in the 2015-2019 window. The others made different bets. Reading them side by side is the fastest way to see what VBS chose and what it gave up.

7.1 Linux KPTI vs Windows KVA Shadow

Linux Kernel Page-Table Isolation (KPTI) and Microsoft's KVA Shadow are parallel responses to the same forced architectural change. Both descend from Gruss et al.'s 2017 ESORICS paper "KASLR is Dead: Long Live KASLR," which introduced KAISER -- the technique of stripping kernel mappings out of the user-mode page-table view to defeat side-channel attacks on Kernel Address Space Layout Randomization [@gruss-kaiser]. KAISER landed before Meltdown was public. When the Project Zero coordinated disclosure broke on January 3, 2018, it was the structural retrofit both kernels needed [@pz-meltdown-spectre].

Linux merged KPTI into mainline before the 4.15 release in January 2018, with backports into 4.14, 4.9, and 4.4 LTS branches gated by CONFIG_PAGE_TABLE_ISOLATION [@lwn-kpti] [@kroah-meltdown]. Microsoft shipped KVA Shadow in the January 9, 2018 cumulative update. Both implementations split the per-process page-table into a user-mode shadow and a full kernel-mode view, swap CR3 at every user-kernel transition, and lean on the Process Context Identifier feature in Skylake-and-later silicon to amortize the TLB-flush penalty. The fact that two OSes with very different histories converged on functionally identical code, within days of each other, is the lesson: the x86 page-table format dictated the answer. Neither team designed the mechanism. The hardware bug did.

7.2 Apple T2: a second processor instead of a second privilege level

Apple shipped the T2 chip in the iMac Pro on December 14, 2017, and rolled it across the Mac line through 2018 [@apple-t2]. The T2 is a separate Arm-based co-processor with its own boot ROM, AES engine, Secure Enclave, and Memory Protection Engine that encrypts the enclave's DRAM region with an ephemeral key [@apple-secure-enclave]. Where Microsoft answered the same-privilege paradox by adding a second privilege level on the same CPU, Apple answered it by adding a second physical CPU.

The tradeoff is stark. T2 has no cross-VTL Spectre v2 problem because the secret lives on a different silicon die. T2 also costs an extra SoC in every machine's bill of materials, requires a second firmware-update pipeline, and demanded hardware replacements when the checkm8 bootrom vulnerability hit the T2's A10-derived bootrom in 2020 [@ironpeak-t2].The T2's predecessor in the 2016 Touch Bar MacBook Pro, the T1, was S2-based; the T2 itself derives from the A10 Fusion CPU found in the iPhone 7, per ironpeak's October 2020 analysis. VBS runs on existing Intel and AMD silicon with no incremental hardware cost; T2 requires Apple to ship custom silicon in every box. Both architectures relocate the secret. They relocate it to different places.

7.3 ChromeOS: do not ship a Secure Kernel because you do not ship a general-purpose kernel

ChromeOS does not deploy a Secure Kernel. It deploys verified boot. The architecture is: firmware-write-protected hardware root, signed kernel partition with the dm-verity root hash baked in, and a read-only root filesystem mounted with dm-verity active so every block read is checked against a signed Merkle tree at runtime [@chromeos-verified-boot] [@dm-verity]. The user-facing surface is the Chrome browser, with per-site renderers and utility processes confined by seccomp-bpf sandboxes. There is no LSASS to scrape, no Active Directory TGT to steal, no general-purpose third-party kernel-driver supply to attack.

The architectural lesson is that VBS solves the problem of "we shipped a large general-purpose kernel and we cannot retract that decision." ChromeOS sidesteps the problem by not shipping that kernel in the first place. ChromeOS is the principled alternative for an OS whose threat model assumes a single-application workload.

7.4 seL4: the verification path VBS chose not to take

seL4 is approximately 8,700 lines of C plus 600 lines of assembly, machine-checked against an Isabelle/HOL abstract specification with roughly 200,000 lines of proof script, and verified end-to-end from spec to C to binary [@klein-sel4-sosp2009] [@klein-sel4-cacm] [@sewell-sel4-pldi]. The 2009 SOSP paper established the proof chain, the 2010 CACM Research Highlight recapped it for a wider audience, and the 2013 PLDI follow-on closed the compiler gap by translation-validating GCC output against the C source. The total effort: on the order of 20 person-years for a microkernel one-tenth the size of securekernel.exe.

Microsoft's Secure Kernel is roughly 150 kilobytes of unverified C code [@ionescu-bh2015]. A meaningful verification would require an Isabelle-level specification of the secure-call interface, refinement proofs through the C source, translation validation to the shipped binary, a formal model of Hyper-V's SLAT enforcement, and a credible story for microarchitectural side channels that seL4 in 2009 did not have to address. A plausible order-of-magnitude estimate is 100 to 200 person-years for the structural pieces alone. No shipping general-purpose OS -- macOS, iOS, ChromeOS, or Windows -- has chosen that path. seL4 itself runs in specialized embedded and defense deployments, not on desktops.

Approach	Trust root	Verification	Strengths	Open residuals	Deployment scale
Windows VBS (2015)	Hyper-V hypervisor + UEFI Secure Boot	None (unverified C)	Ships on existing silicon at Windows scale	BYOVD, secure-call bugs, cross-VTL side channels	Hundreds of millions of endpoints
Linux KPTI (2018)	Page-table split per process	None	Forced retrofit; correct in mainline within weeks	Spectre family beyond v3	Server-side and developer workstation majority
Apple T2 (2017)	Second physical processor	None (different threat model)	No cross-VTL side-channel surface	Firmware bugs require hardware fix	All Intel Macs 2018-2022
seL4 (2009)	Microkernel + Isabelle/HOL proof chain	Functional correctness, integrity, non-interference	Formally guaranteed against named bug classes	Outside-TCB hardware and side channels	Specialized embedded / defense

Each of these four answers makes a different tradeoff against the same problem. Windows chose "second privilege level, large attack surface, ship-at-scale." What does that tradeoff leave on the table -- where are VBS's irreducible residuals?

8. What VBS Cannot Defend Against

Every architecturally honest defense names its bypass classes before its critics do. VBS, at the 2019 cutline, has six enumerable bypasses plus one structural caveat about availability. None of them undermines the architectural claim that the LSASS-scrape attack class is closed. All of them shape the operator's deployment decisions.

An attack class in which an adversary loads a legitimately Microsoft-co-signed third-party kernel driver that contains an exploitable bug. The driver passes Driver Signing Enforcement and HVCI's code-integrity check because it is signed; the bug gives the attacker arbitrary kernel-mode primitives (read, write, execute) without requiring a Microsoft-issued signature. BYOVD is the dominant in-the-wild HVCI and Credential Guard bypass class through the 2019 cutline.

Bypass class one -- BYOVD. A vulnerable signed driver provides the same kernel-mode primitives PatchGuard-era rootkits relied on. With kernel-mode arbitrary write, an attacker can disable HVCI on a per-process basis, clear the PPL bits on a target, or hook secure-call dispatch sites. Microsoft formally acknowledged BYOVD as a class with the October 2022 Vulnerable Driver Blocklist update KB5020779 [@ms-vuln-driver-kb], operationalized through the same microsoft-recommended-driver-block-rules document used by Windows Defender Application Control [@ms-vuln-driver-blockrules]. That arrived three years after the cutline of this article, which is part of the lesson: the dominant residual at 2019 was not closed by Windows 10 itself.

Bypass class two -- hypervisor and secure-kernel vulnerabilities. The Secure Kernel is not infallible code. Saar Amar and Daniel King's Black Hat USA 2020 talk "Breaking VSM by Attacking SecureKernel" disclosed CVE-2020-0917 and CVE-2020-0918 in the secure-call interface handlers SkmmUnmapMdl and SkmiReleaseUnknownPTEs [@amar-king-bh2020]. The Amar-King work landed after this article's window, but the bypass-class anchor it establishes -- VTL0 to VTL1 escape via the secure-call interface -- was already known to insiders by 2019. The steady-state finding rate for that class is on the order of one to three critical bugs per year.

Bypass class three -- hardware and DMA attacks. A peripheral device attached over Thunderbolt or PCIe can, in the absence of an Input-Output Memory Management Unit enforcement, read and write physical memory directly. The 2019 NDSS paper "Thunderclap" demonstrated DMA reads of VTL0 and VTL1 memory on machines without Kernel DMA Protection enabled [@markettos-thunderclap]. The Windows mitigation is IOMMU enforcement plus Kernel DMA Protection, both of which require firmware support that mixed-vintage hardware does not always have.

Bypass class four -- microarchitectural side channels. Spectre variant 2 -- branch target injection -- is the only Spectre-family variant whose threat model overlaps the VBS boundary, because mispredicting an indirect call inside a secure-call handler can leak data across the VTL boundary. The mitigation is enabling Indirect Branch Restricted Speculation around the secure-call entry. Section 10 walks the larger story; here it is enough to note that microarchitectural side channels are an open surface against VBS that grows with each new variant.

Bypass class five -- trustlet-signing-root compromise. Every trustlet is identified by two Authenticode EKUs that Microsoft signs at Signature Level 12 [@ionescu-bh2015]. If an attacker controls either the signing key or the issuing infrastructure that hands out the IUM EKU, they can ship a malicious binary that the Secure Kernel admits as a legitimate trustlet -- with the same VTL1 access as LSAISO.

This class was theoretical at the 2019 cutline. Microsoft's July 2023 Storm-0558 disclosure put it on the forward roadmap: an Azure consumer-MSA signing key was used to forge enterprise tokens [@ms-storm-0558], and the September 2023 root-cause investigation traced the original key acquisition to a crash dump that crossed from production into a corporate debugging environment that the actor had already compromised [@msrc-storm-0558-keyacq]. The Storm-0558 incident was a token-signing-key compromise rather than a trustlet-signing-key compromise, but the architectural lesson is identical. A signing root is a single point of trust whose compromise admits arbitrary binaries to the protected privilege level.

Bypass class six -- the VTL0 agent surface. Most VBS features ship a VTL0 process that brokers requests to a VTL1 trustlet. LSA in VTL0 brokers credential operations to LSAISO. The System Guard runtime attestation agent and the Windows Defender Application Guard broker likewise mediate between user-mode applications and their VTL1 counterparts.

Bugs in those agents are still VTL0 bugs. An agent that mishandles user-controlled input before the secure-call dispatch -- a parsing error, a use-after-free, a type confusion -- can leak partial information or trigger unintended VTL1 operations even when the Secure Kernel's API is sound. The failure surface is in VTL0; the consequences can reach into VTL1 by routing through the agent. This is the everyday-engineering residual that shows up in routine MSRC advisories rather than in conference papers.

Caveat -- availability is not a VBS invariant. The Hyper-V Top-Level Functional Specification is explicit on this point [@ms-tlfs-vsm]. VTL0 can deny service to VTL1 by refusing to schedule the Secure Kernel, by refusing to provide pages for paging, or by refusing to dispatch secure-calls. Confidentiality and integrity are protected. Availability is not. A compromised NT kernel can stop a trustlet from running. The VBS designers made that tradeoff deliberately, because guaranteeing availability would require the Secure Kernel to manage its own scheduler and paging, which would balloon its trusted code base out of audit range.

VTL0 can DOS VTL1 by design. -- Microsoft Hyper-V Top-Level Functional Specification, Virtual Secure Mode

Bypass class	Attack family	Residual mitigation at 2019
BYOVD	Vulnerable signed driver as kernel-mode primitive	Microsoft-recommended block rules (manual at 2019; default-on with KB5020779 in Oct 2022)
Hypervisor / Secure Kernel bugs	Secure-call interface vulnerabilities	Patch velocity; reduce secure-call surface; formal verification research
Hardware / DMA	Pre-IOMMU PCIe / Thunderbolt DMA reads	Kernel DMA Protection + IOMMU enforcement (firmware-dependent)
Microarchitectural side channels	Spectre v2 cross-VTL leakage	IBRS on secure-call entry; per-variant microcode mitigations
Trustlet-signing-root compromise	Forged or stolen IUM EKU signing key	Signing-infrastructure hardening; no operator-side control at 2019
VTL0 agent surface	Bugs in LSA, System Guard agent, WDAG broker	Conventional MSRC patching; harden agent input validation

Note: Five observations on the residual map. BYOVD is the dominant in-the-wild residual at the 2019 cutline -- it is what attackers actually used to bypass HVCI and Credential Guard, and the canonical Microsoft mitigation came three years late. The secure-call interface is the quietest residual: most readers had never heard of it before Amar-King in 2020. Microarchitectural side channels are the interaction class that links the bypass map in Section 8 to the third axis in Section 10. Trustlet-signing-root compromise is the forward class -- theoretical at 2019, made concrete by Storm-0558 in 2023. VTL0 agent bugs are the everyday-engineering class that shows up in routine MSRC advisories. Knowing which residual matters for which threat model is half of operational VBS deployment.

Key idea: Every architecturally honest defense names its bypass classes before its critics do. VBS has six: BYOVD, hypervisor secure-call bugs, hardware DMA, microarchitectural side channels, trustlet-signing-root compromise, and the VTL0 agent surface. The architectural gap is small. The deployment gap, as the next section will show, is much larger.

These are the architectural residuals. The operational residuals turned out to be bigger by orders of magnitude. The path from a kernel-isolated 2017 Enterprise laptop to a paralyzed hospital starts with a missed patch.

9. The Offensive Story: Ransomware Industrialization (2017-2019)

Between May 12, 2017 and November 21, 2019, the criminal Windows-attack industry went through five generations of business-model evolution in thirty months. Worm-spray ransomware. State-actor wiper. Targeted enterprise extortion. Ransomware-as-a-Service. Encryption plus exfiltration -- the double-extortion playbook. None of the five required novel exploitation against VBS-class defenses. They required only that VBS-class defenses not be deployed.

The 2017-2019 arc has a predecessor that explains the rest. In September 2013, Symantec Security Response reported a new family of Windows ransomware called CryptoLocker, distributed by Evgeniy Bogachev's peer-to-peer Gameover Zeus botnet, encrypting victim files with per-victim 2048-bit RSA keys and demanding payment in Bitcoin or MoneyPak. Ransom demands ran in the low three figures to low four figures: enough to be commercially viable against consumers, capped by what consumers could pay.

On June 2, 2014, a joint operation -- the FBI, Europol, the UK National Crime Agency, Dutch and German law-enforcement, plus Symantec, Dell SecureWorks, CrowdStrike, F-Secure, Microsoft, Trend Micro, and McAfee -- executed Operation Tovar [@doj-operation-tovar] [@europol-operation-tovar] [@fbi-goz]. The operation seized the Gameover Zeus command-and-control and sinkholed the peer-to-peer overlay; FireEye and Fox-IT used the recovered keypair database to stand up a free decryption portal for CryptoLocker victims.

Operation Tovar disrupted the vector. It did not disrupt the business model. Within months, CryptoWall surpassed CryptoLocker in infection volume under different operators [@secureworks-cryptowall]. The lesson the next five years would teach is that takedown alone does not solve the ransomware problem: the underlying economics -- encryption plus extortion against a Bitcoin-receivable -- are the asset, and the operators are commodity. From CryptoLocker forward, the criminal arc forks into the worm-spray fork (WannaCry, NotPetya, Bad Rabbit) and the targeted-enterprise fork (SamSam, Ryuk, REvil, Maze) that converge at Maze double extortion in November 2019.

9.1 WannaCry (May 12, 2017)

The patch-gap timeline is the spine of the WannaCry story. Microsoft published Security Bulletin MS17-010 on March 14, 2017, patching CVE-2017-0143 through CVE-2017-0148 in the SMBv1 server [@ms-ms17-010] [@nvd-cve-2017-0144]. Thirty-one days later, on April 14, 2017, the Shadow Brokers leaked the NSA Equation Group's "Lost in Translation" toolkit, which included the EternalBlue exploit weaponizing CVE-2017-0144 over SMBv1 and DoublePulsar, a kernel-mode SMB backdoor [@wiki-eternalblue]. Twenty-eight days after that, on May 12, 2017, WannaCry began propagating. Total patch-to-outbreak window: fifty-nine days.

The exploit, mechanically, is two pieces. EternalBlue exploits a race condition in the SMBv1 Transaction2 subcommand processing in srv.sys, achieving controlled kernel-pool corruption that lets the attacker write a controlled SrvNet buffer into a controlled location -- enough to land kernel-mode code execution. DoublePulsar plants a kernel-mode backdoor that listens for follow-on shellcode over SMB. Sean Dillon's RiskSense paper EternalBlue: Exploit Analysis and Port to Microsoft Windows 10 (2018) is the canonical reverse-engineering account [@dillon-risksense-eternalblue].

sequenceDiagram participant Atk as Attacker participant Srv as srv.sys (SMBv1) participant Krn as Kernel pool participant DP as DoublePulsar Atk->>Srv: SMBv1 Trans2 request with crafted parameters Srv->>Krn: pool allocation hits race condition Atk->>Srv: groom SrvNet buffer Srv->>Krn: controlled overwrite, ring 0 execution Krn->>DP: install kernel-mode backdoor Atk->>DP: deliver ransomware payload over SMB DP-->>Atk: payload running as SYSTEM

The propagation halted at 15:03 UTC on May 12, 2017 when Marcus Hutchins, a then-22-year-old British researcher writing as MalwareTech, registered an unregistered domain hard-coded into the WannaCry binary as a kill-switch test. Hutchins thought he was sinkholing for telemetry. He had accidentally stopped the worm [@malwaretech-killswitch].The kill-switch domain registration is well-attested at 15:03 UTC; the moment global propagation visibly slowed lagged the registration by minutes to hours as the sinkhole DNS record propagated through caching resolvers worldwide.

Damage at the National Health Service was severe but not maximal: the National Audit Office's October 2017 investigation reports that the attack disrupted at least 34 percent of trusts in England, NHS England identified 6,912 cancelled appointments, and the estimate of total cancelled appointments was over 19,000 [@nao-wannacry]. The NAO is clear that no NHS organization paid the ransom. The British government and NHS England later attributed the WannaCry outbreak to North Korea, formally on December 19, 2017, in a White House press briefing that coordinated attribution with the United Kingdom, Australia, Canada, New Zealand, and Japan [@wh-wannacry].

CISA, then US-CERT, had issued an alert during the May 12 outbreak window [@cisa-may-2017-ransomware]. Global damage estimates ran to around four billion US dollars across cancelled production, recovery costs, and downtime at Renault-Nissan plants, FedEx, Telefonica, Deutsche Bahn, and the NHS.

The architectural lesson of WannaCry is not that VBS failed. VBS was not running on the affected NHS workstations, which were largely unpatched Windows 7 boxes. The architectural lesson of WannaCry is that patch velocity remained the dominant defense in 2017, and that the deployment-gap problem was, and remains, the larger lever than the architectural-gap problem.

9.2 NotPetya (June 27, 2017)

Six weeks later, on June 27, 2017, the world saw what an actually-state-actor-grade Windows campaign looks like. The vector was a supply-chain compromise of M.E.Doc, the Ukrainian tax-and-accounting software whose update channel pushed the malicious binary to thousands of M.E.Doc-running endpoints [@talos-medoc]. ESET's TeleBots write-up confirmed the operator: the BlackEnergy-lineage Sandworm group [@eset-telebots].

The payload self-propagated using EternalBlue plus EternalRomance plus credential reuse via a bundled Mimikatz-style routine, then encrypted Master File Tables and boot sectors. Kaspersky's analysis -- "Schroedinger's Pet(ya)" -- is the canonical evidence that the malware was a wiper masquerading as ransomware: "After an analysis of the encryption routine of the malware used in the Petya/ExPetr attacks, we have thought that the threat actor cannot decrypt victims' disk, even if a payment was made" [@kaspersky-petya]. The Salsa20 key derivation made decryption impossible by design.

The Maersk story, told most memorably in Andy Greenberg's WIRED feature and at book length in his 2019 Doubleday volume Sandworm: A New Era of Cyberwar and the Hunt for the Kremlin's Most Dangerous Hackers, is the iconic case [@wired-notpetya] [@greenberg-sandworm-book]. Maersk's IT department recovered from a single, accidentally-offline domain controller in Ghana [@wired-notpetya] [@greenberg-sandworm-book].

The aggregate damage estimate from the February 15, 2018 White House attribution statement is "billions of dollars in damage" with the headline language: "In June 2017, the Russian military launched the most destructive and costly cyber-attack in history" [@wh-notpetya]. The UK's National Cyber Security Centre issued parallel attribution to the Russian military [@ncsc-russia-notpetya]. The US Department of Justice indicted six GRU Unit 74455 officers on October 19, 2020 -- Andrienko, Detistov, Frolov, Kovalev, Ochichenko, Pliskin -- for NotPetya, Olympic Destroyer, and related campaigns [@doj-gru-notpetya].

In June 2017, the Russian military launched the most destructive and costly cyber-attack in history. -- White House Press Secretary statement, February 15, 2018 The October 19, 2020 indictment in the Western District of Pennsylvania names the six GRU officers and ties them to NotPetya, Olympic Destroyer, the OPCW intrusion, the 2015 and 2016 Ukrainian power grid attacks, and the 2017 French election hack-and-leak [@doj-gru-notpetya]. The indictment lands three years after this article's primary window closes, but the canonical US attribution record for NotPetya lives in that document.

The architectural lesson of NotPetya is not patch velocity. NotPetya owned its initial victims through a trusted update channel; patch cadence does not help against an installer signed by your software vendor. The lesson is that build-pipeline integrity is the next frontier, and SolarWinds in December 2020 -- the Part 5 chapter of this series -- will make that lesson industry-canonical.

9.3 Bad Rabbit (October 24, 2017)

Bad Rabbit was a four-month-later, smaller-scale cousin. Distribution was via drive-by infection from compromised Russian and Ukrainian media sites, with a payload masquerading as an Adobe Flash Player installer. Lateral movement used EternalRomance, not EternalBlue, and Kaspersky's analysis confirms code overlap with NotPetya [@kaspersky-bad-rabbit]. The blast radius was Slavic-language-region targeted. One paragraph of treatment matches the historical importance: enough to triangulate Sandworm, not enough to change the architectural story.

9.4 The Big Game Hunting Transition (2018-2019)

By the second half of 2018, ransomware crews had decided that mass spray was leaving money on the table. The pattern crystallized into what CrowdStrike named, in late 2018 and early 2019, big game hunting [@crowdstrike-ryuk].

A targeted ransomware business model in which a human operator gains access to a victim network, performs hands-on-keyboard reconnaissance, escalates to Domain Admin, locates backup infrastructure, and deploys ransomware enterprise-wide in a single coordinated event. Ransom demands scale to victim revenue. CrowdStrike's January 2019 write-up of WIZARD SPIDER's Ryuk operations is the standard reference for the term [@crowdstrike-ryuk].

The proto-Big-Game-Hunting predecessor is SamSam, operated from December 2015 through November 2018 by the Iranian operators Faramarz Shahi Savandi and Mohammad Mehdi Shah Mansouri. SamSam combined Internet-facing RDP brute force and JBoss exploitation with manual lateral movement and ransomware-of-the-domain-controller, caused more than $30 million in aggregate damages, and collected more than $6 million in ransom payments, per the November 28, 2018 DOJ indictment of Savandi and Mansouri [@doj-samsam]. The thirty-million figure is the DOJ's damages / losses characterization, not the demanded ransom amount: per-victim SamSam demands ran in the five- to fifty-thousand-dollar range, and the aggregate damages include downtime, recovery, and unrecovered ransom rather than the operators' headline ask. SamSam was the phase from 2016 forward; CrowdStrike named the phase in 2018.

The named-and-canonical Big Game Hunting lineage runs through three families.

Ryuk first appeared in August 2018, operated by CrowdStrike's WIZARD SPIDER (the TrickBot crew). Check Point's first-wave analysis identified the code overlap with the earlier HERMES ransomware, originally attributed to the Lazarus Group, though Check Point notes the toolchain overlap rather than asserting shared operations [@checkpoint-ryuk]. The killchain Cybereason later detailed was the Emotet -> TrickBot -> Ryuk trifecta: a phishing-delivered Emotet loader, TrickBot for credential theft and lateral movement, hands-on-keyboard reconnaissance, and Ryuk for the encryption payload.

REvil -- also called Sodinokibi -- emerged in April 2019. The Talos analysis published April 30, 2019 attributed first observed in-the-wild exploitation of CVE-2019-2725 to a Sodinokibi-deploying campaign active since at least April 17, 2019 [@talos-sodinokibi]; April 30 is the publication date of the Talos write-up, not the first-observed exploitation date. Secureworks attributed the operation to the GOLD SOUTHFIELD group and noted Sodinokibi was "likely associated with the GandCrab ransomware due to similar code and the emergence of REvil as GandCrab activity declined" [@secureworks-revil].

Maze entered the field in May 2019 [@malwarebytes-maze-2020].

flowchart LR A[Spear-phish
Emotet loader] B[TrickBot
credential theft] C[Hands-on-keyboard
lateral movement] D[Domain Admin] E[Backup-network
reconnaissance] F[Mass deployment
SCCM, GPO, PsExec] G[Exfiltration] H[Encryption] I[Leak-site pressure] A --> B --> C --> D --> E --> F --> H E --> G --> I H --> I

9.5 Maze and Double Extortion (November 21, 2019)

The fifth-generation business model arrived in late 2019. Maze's operators attacked the security-staffing firm Allied Universal in November 2019. When Allied Universal refused to pay, Maze threatened to release the stolen files publicly. In December 2019, Maze published a leak site listing victims who had not paid, with sample data to prove possession. Brian Krebs broke the story on December 16, 2019: "Less than 48 hours ago, the cybercriminals behind the Maze Ransomware strain erected a Web site on the public Internet... that changed at the end of last month, when the crooks behind Maze Ransomware threatened Allied Universal that if they did not pay the ransom, they would release their files" [@krebs-maze].

A ransomware business model in which the operator exfiltrates victim data before encrypting it, then threatens public disclosure of the data as a separate pressure axis if the ransom is not paid. Maze, beginning with the November 2019 Allied Universal case and the December 2019 dedicated leak site, is the canonical first systematic deployment [@krebs-maze]. Snatch had threatened similar disclosure earlier in October 2019, but did not operate dedicated leak-site infrastructure [@sophos-snatch].

The economic logic is simple. The ransomware-only business model assumed the victim's only pressure point was the encrypted data -- which meant good backups defeated the extortion. Double extortion adds a second pressure axis (public disclosure) that backups do not address. The pattern propagated industry-wide in 2020; exfil-then-encrypt is now the standard ransomware business model.

9.6 The synthesis: a paradox of layers

Now the synthesis. The Enterprise laptop with Credential Guard enabled, in Scene A of Section 1, sat above the VBS architecture. The unpatched SMBv1 Windows 7 box on the NHS network, in Scene B, sat below it -- on a vintage of Windows that predated Credential Guard entirely and on a network nobody had segmented around the wormable SMBv1 protocol. Both ran "Windows" in the same five-year window. The difference between them was not architectural rigor. The difference was operational rigor: patches applied, segmentation configured, SMBv1 disabled, supported SKUs deployed, VBS enabled.

VBS is a structural defense for the credential store on a properly-configured Enterprise endpoint. Patching is an operational defense for the network-edge attack surface. They protect orthogonal layers of the stack. A correct defense at one layer is consistent with a catastrophic miss at the other.

Key idea: The paradox of simultaneity: Microsoft's largest structural defensive break in twenty years and the criminal and state-actor world's largest operational expansion in twenty years happened in the same five-year window because they live at different layers of the defense stack.

There is one more axis, and it is orthogonal to both VBS and patch velocity. The CPU itself was the attacker's primitive.

10. The Third Axis: Meltdown, Spectre, KVA Shadow, Retpoline (2018-2019)

On January 3, 2018, the security industry's calendar acquired a new entry. Jann Horn at Google Project Zero, Moritz Lipp and colleagues at Graz University of Technology, Paul Kocher independent, and a coordination of six other institutions disclosed that out-of-order execution on every Intel CPU shipped since the mid-1990s could be turned against the kernel-user privilege boundary [@pz-meltdown-spectre]. None of the Windows defenses shipped in the prior thirty months touched the attack class. None could. The attacker's primitive was the CPU.

The Google Project Zero blog post enumerates three variants. Variant 1, bounds check bypass, became CVE-2017-5753. Variant 2, branch target injection, became CVE-2017-5715. Variant 3, rogue data cache load, became CVE-2017-5754 and was named Meltdown [@pz-meltdown-spectre] [@ms-myerson-meltdown]. Variants 1 and 2 together became the family named Spectre. The peer-reviewed papers landed later: Meltdown at USENIX Security 2018 with Lipp as lead author and an authorship list including Schwarz, Gruss, Prescher, Haas, Fogh, Horn, Mangard, Kocher, Genkin, Yarom, and Hamburg [@lipp-meltdown-usenix]; Spectre at IEEE S&P 2019 with Kocher as lead author [@kocher-spectre-ieee].The Meltdown paper's authorship list does not include "Strackx" -- that name belongs to the later Foreshadow / L1TF paper. The audit on this article's research stage flagged the attribution error; the corrected roster is the one cited above [@lipp-meltdown-usenix].

Windows shipped three mitigations in response. KVA Shadow is Microsoft's name for what Linux calls Kernel Page-Table Isolation -- the technique descended from Gruss et al.'s 2017 KAISER paper. The mechanism is to maintain two page tables per process. The "user" page table maps only the user address space and a minimal kernel trampoline. The "kernel" page table maps the full kernel. Every user-mode-to-kernel-mode transition swaps the CR3 register to install the kernel page table; every return swaps it back. The kernel page-table entries that previously sat in the same virtual address space as the user, and that Meltdown exploited speculatively, are no longer mapped during user-mode execution.

sequenceDiagram participant U as User-mode process participant CPU as CPU participant K as Kernel U->>CPU: syscall instruction CPU->>CPU: swap CR3 to kernel page-table CPU->>K: dispatch kernel handler K->>K: execute handler logic K->>CPU: prepare return CPU->>CPU: swap CR3 to user shadow page-table CPU-->>U: return to user mode

Retpoline is the Spectre v2 mitigation. The technique, due to Paul Turner at Google in early 2018, replaces every indirect branch with a return-based thunk that the speculative-execution unit cannot mis-train into the attacker's chosen target. Microsoft backported Retpoline into Windows 10 1809 via the KB4482887 cumulative update on March 1, 2019, and enabled it by default via cloud configuration on May 14, 2019; the canonical write-up sits on the Windows Kernel team's TechCommunity blog (first posted December 6, 2018; updated through May 14, 2019) [@ms-retpoline]. The timing matters because Windows 10 1809 reached RTM on November 13, 2018: on supposedly-Retpoline-protected 1809 boxes there were roughly six months of unprotected Spectre v2 surface between the 1809 RTM and the May 14, 2019 cloud-enable.

IBRS, IBPB, and STIBP -- Indirect Branch Restricted Speculation, Indirect Branch Predictor Barrier, Single Thread Indirect Branch Predictor -- are the CPU-MSR-controlled mitigations delivered through Intel and AMD microcode updates that Windows manages via the kernel.

The performance cost was not uniform. Terry Myerson's January 9, 2018 Microsoft Security Blog post tiers it: Skylake-and-newer client CPUs saw "single-digit slowdowns"; Haswell-era and older systems saw "more significant slowdowns"; Server 2016 and SQL workloads saw "even more significant slowdowns" [@ms-myerson-meltdown]. The MariaDB community published one of the most-cited empirical anchors: on Haswell-era hardware doing MyISAM table scans, KPTI cost 37 to 40 percent in the worst case [@mariadb-kpti]. A 40 percent regression for a SQL workload is an unmistakable signal that the page-table swap dominates short-syscall-heavy code paths.

Note: Operators who use the FeatureSettingsOverride and FeatureSettingsOverrideMask registry knobs to disable KVA Shadow, Retpoline, or IBRS in pursuit of benchmark numbers are running an operationally unpatched Meltdown-vulnerable system. The performance numbers in benchmark blogs that "disable mitigations" are reporting the speed of a hardware configuration whose threat model is January 2018.

The lesson here is structural. VBS does not help against microarchitectural attacks because VBS protects against software primitives; the CPU itself is the attacker's primitive. The only point at which the microarchitectural axis touches VBS is Spectre v2 cross-VTL leakage during secure-call dispatch, and the answer there is to set IBRS on secure-call entry -- the same MSR-level control that protects any indirect branch in privileged code.

VBS, patch velocity, microarchitectural mitigations. Three axes of defense, each addressing a different attack primitive. Where does that leave the operator on December 31, 2019?

11. Operating Windows 10 in the 2017-2019 Threat Environment

A defender at the 2019 cutline who reads only the architecture papers will deploy VBS and feel safe. A defender who reads only the breach reports will assume nothing works. The truth is structurally bounded.

For enterprise administrators. Enable Credential Guard plus HVCI on Enterprise SKUs from 1607 forward [@ms-credential-guard] [@ms-hvci]. Deploy WDAC with audit-mode-first rollout, then enforce [@ms-wdac]. Patch within 30 days of MSRC release -- the WannaCry lesson is fifty-nine days. Disable SMBv1 outright. Inventory unused signed kernel drivers and remove them. Stand up Defender for Endpoint or an equivalent EDR. Treat segmentation between user subnets and server subnets as a deployable security control, not an architectural aspiration.

Note: Production WDAC policies routinely run to thousands of rules. The canonical mitigation for XML-authoring complexity is reference-monitor-mode rollouts: ship the policy in audit mode, collect 7 to 14 days of MicrosoftWindows-CodeIntegrity/Operational events from real users, refine the allow-list against the captured baseline, then move to enforce. Skipping audit mode reliably produces a Tuesday morning of broken business workflows [@ms-wdac].

For application developers. Compile with /guard:cf to opt into CFG instrumentation [@ms-cfg]. Set per-app Process Mitigation Policies via Set-ProcessMitigation [@ms-set-processmitigation], picking the subset (ACG, CIG, Strict Handle Checks, Disable Win32k System Calls) that fits your runtime. Sign your binaries with Authenticode using a hardware-backed key. If your application reads credentials, make sure they never touch LSASS; use the CredUI or Web Account Manager surface, which integrates with Credential Guard cleanly.

For security researchers. Read Ionescu's Black Hat USA 2015 deck plus the Weston-Ionescu OPCDE 2018 "Inside the Octagon" before claiming a "VBS bypass" [@ionescu-bh2015] [@opcde-inside-octagon]. Categorize any bypass you find into one of the six classes named in Section 8 -- BYOVD, hypervisor or secure-call bugs, hardware DMA, microarchitectural side channels, trustlet-signing-root compromise, or VTL0-agent surface. Cross-cite Microsoft Learn for any specification-level claim about VTL semantics. The Yosifovich, Ionescu, Russinovich, and Solomon Windows Internals 7th edition, Part 1 (May 2017) remains the canonical textbook anchor for the 1507-to-1607 era architecture [@mspress-windows-internals-7e].

For SOC analysts. EternalBlue and DoublePulsar signatures are still recurring in unmanaged-edge devices in 2024 and 2025 [@hunterstrategy-eternalblue]. Train detection rules on the SMB signal, not just the WannaCry payload signature.The DoublePulsar implant responds to a specific SMB Trans2 SESSION_SETUP subcommand with a non-zero Multiplex ID, which is the most-cited single-packet network signature for triage. The Emotet -> TrickBot -> Ryuk killchain pattern is the operational anchor for human-operated ransomware detection; the IOCs change every quarter, but the kill-chain stages do not. PrintNightmare, a 2021 Part-5 story, reuses the same SMB-style propagation pattern.

On a Windows 10 or 11 Enterprise host, run `msinfo32.exe`, find the "Virtualization-based security Services Running" row, and confirm it lists `Credential Guard`. From PowerShell, `Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard | Select SecurityServicesRunning` returns an array whose value `1` corresponds to Credential Guard and value `2` to HVCI. If the array is empty, VBS is configured but no isolated services have started, and the LSAISO trustlet is not actually protecting credentials on that machine.

By the end of 2019, the architectural floor is named. The operational floor is named. Three axes are not yet closed.

12. What 2015-2019 Did Not Solve

Five problems leave this window open. Each is a chapter of Part 5 or Part 6, and each is open because the architectural gap and the deployment gap are at different sizes.

Supply-chain integrity. NotPetya proved that build-pipeline compromise is the dominant remaining attack class against well-defended estates [@talos-medoc] [@eset-telebots]. Microsoft's Security Development Lifecycle codifies pre-release secure-engineering practice [@ms-sdl], but SDL stops at the binary the build pipeline emits; it does not certify that the binary any verifier can rebuild matches that binary.

The 2015-2019 window saw two structural answers begin to mature. Debian's reproducible-builds project, in continuous progress since 2013, reached approximately 94 percent reproducibility by mid-2017 [@lwn-debian-reproducible]; the Tor Project's deterministic-builds work in 2014 framed the watering-hole-attack defense the discipline existed to address [@tor-deterministic-builds]. The Linux Foundation's Sigstore project, announced March 9, 2021, finally shipped a free transparency-log signing infrastructure for software artifacts [@lf-sigstore], and the NIST SP 800-218 Secure Software Development Framework codified the practice into a federal expectation in February 2022 [@nist-ssdf]. SolarWinds in December 2020 -- the Part 5 chapter -- forced the industry to take this open problem seriously.

The architectural distinction is between code-signing-as-supply-chain-integrity (signs whatever the build pipeline emits, regardless of pipeline compromise) and reproducible-build-as-supply-chain-integrity (signs only binaries any verifier can independently reproduce from source). At the 2019 cutline, reproducible builds are not the deployment norm; by the mid-2020s they are still not the norm for proprietary Windows-side software.

The hypervisor and secure-call interface. Amar and King's 2020 work on SkmmUnmapMdl and SkmiReleaseUnknownPTEs disclosed two kernel-strong VTL1 bugs reachable from VTL0 -- CVE-2020-0917 and CVE-2020-0918 -- and set the public-disclosure baseline at roughly one to three secure-call interface bugs per year [@amar-king-bh2020] [@msrc-cve-2020-0917].

Microsoft's response posture is enforcement, not formal verification. The Hyper-V Bounty program pays up to $250,000 for a guest-to-host escape, with corresponding lower tiers for partial escapes and architectural vulnerabilities [@ms-hyperv-bounty]. The Microsoft Security Servicing Criteria treats secure-kernel and HVCI bypasses as Servicing Tier 1, meaning they are silently serviced through the normal patch cadence rather than coordinated as headline incidents [@ms-servicing-criteria]. The Saar-Amar-style Hyperseed fuzzer remains the internal-tooling baseline.

The open question is whether a formally-verified secure-call interface is achievable for Microsoft's deployed codebase. seL4 establishes that verification is feasible at roughly nine thousand lines of C [@klein-sel4-sosp2009]; securekernel.exe is approximately 150 kilobytes with substantial integration surface. The 2019 answer is "not yet." The cadence of CVEs since suggests the answer through 2024 remains "not yet."

The BYOVD pipeline. Microsoft's October 2022 default-on Vulnerable Driver Blocklist (KB5020779) blocks known-bad signed drivers reactively, by hash [@ms-vuln-driver-kb] [@ms-vuln-driver-blockrules]. The blocklist is fed by Microsoft's IHV-partnership submission flow, and Windows Defender Application Control consumes the same policy at the system level. The LOLDrivers community catalog tracks several hundred vulnerable signed drivers as of 2024 [@loldrivers], far more than the curated subset KB5020779 covers.

The structural distinction is between known-bad drivers blocked by hash -- the current approach -- and retroactive driver-signing revocation, which would block by certificate. Hash-based blocking handles the dominant in-the-wild surface; certificate-based revocation breaks legitimate deployments that rely on older signed drivers with Authenticode timestamps that pre-date the revocation. Microsoft has not solved that tradeoff at the 2019 cutline. KB5020779 (October 2022) is the partial answer. Full retroactive revocation remains open.

Microarchitectural side channels in cross-VTL boundaries. Spectre v2 leakage across the VTL0 to VTL1 boundary invalidates Credential Guard's confidentiality invariant if VTL0 can poison the indirect branch predictor that VTL1 consumes during a secure-call handler return; IBRS on secure-call entry is the standing mitigation, but every new microarchitectural class re-prices the defense.

LVI (Load Value Injection, CVE-2020-0551, March 2020), RIDL and ZombieLoad (May 2019, microarchitectural data sampling), and Inception (USENIX Security 2023, AMD-SB-7005 against Zen 3 and Zen 4 [@usenix-inception] [@amd-sb-7005]) each open a new variant. The structural answer the industry is moving toward is microarchitecturally-partitioned CPUs: Intel TDX [@intel-tdx] and AMD SEV-SNP [@amd-sev-snp] both ship hardware-isolated virtual machines with per-VM memory encryption that close the cross-VTL leakage class by construction. Both are datacenter-only at the 2019 cutline; neither lands on mainstream Windows endpoints until well after the article's window. The 2019 operational state is IBRS-plus-microcode mitigation, re-priced each time a new variant lands.

Big Game Hunting defense when backups stop being a deterrent. Maze's double-extortion playbook neutralized the backup-equipped defender's bargaining position [@krebs-maze]. Three research directions are open.

Cryptographic data-at-rest segmentation -- file-level encryption keyed to per-team hardware security modules, so a single compromised account cannot exfiltrate the full data corpus -- is the most direct technical answer. Segmented backup storage, in which the backup network is operationally isolated from the production network and authenticates only out-of-band, is the operational pattern that the segmented-tier-zero Active Directory work in this window points toward. Zero-knowledge backup storage, in which the storage provider holds only customer-encrypted blobs and cannot itself be compelled into the leak chain, is the architectural backstop.

Cyber-insurance market design is the fourth axis: after the Mondelez-versus-Zurich act-of-war dispute, the insurance industry restructured but did not solve the moral-hazard problem of ransom-coverage as a payment channel. Maze itself ceased operations in October 2020. The playbook persisted under Conti, LockBit, and successor groups through 2024.

Part 5 picks up at December 2020 with SolarWinds. Part 6 closes with the CrowdStrike Falcon outage and the post-Pluton trust topology. The next five years will not be quieter.

13. Frequently Asked Questions

Mimikatz still works, but the attack family Credential Guard was engineered against returns empty. The LSASS-scrape modules -- `sekurlsa::logonpasswords`, `sekurlsa::tickets`, `lsadump::secrets` -- read the bytes Credential Guard relocates into LSAISO in VTL1 [@ms-credential-guard], so the data is no longer where Mimikatz scans. What still works against a CG-enabled host is anything outside that threat model: pass-the-ticket replay of a TGT captured before CG was enabled, sign-in-time keylogging, stolen-DC krbtgt forgery, or BYOVD-grade kernel primitives that take advantage of secure-kernel bugs. Yes. Six classes, all enumerated in Section 8 -- BYOVD with a vulnerable signed driver, hypervisor or secure-kernel vulnerabilities such as the 2020 Amar-King work on `SkmmUnmapMdl` [@amar-king-bh2020], pre-IOMMU hardware DMA, microarchitectural side channels, trustlet-signing-root compromise, and bugs in the VTL0 agents that broker requests to VTL1. None of those undermines the architectural claim that classical kernel-mode code injection is closed by HVCI's enforcement of write-XOR-execute on VTL0 kernel pages [@ms-hvci]. The bypass classes shape deployment posture; they do not invalidate the model. Yes, in PowerShell user space. The Matt Graeber reflection trick that sets `AmsiUtils.amsiInitFailed` to true short-circuits AMSI within the running PowerShell process. MDSec's June 2018 write-up walks the family [@mdsec-amsi-bypass]. AMSI is a hook, not a sandbox; the bypass surface is part of the design tradeoff. The defender's response is the Defender behavioral pipeline and cloud telemetry, plus Constrained Language Mode and PowerShell logging that capture the bypass attempt itself as a high-confidence signal. Both are 2016+ Server features that build on the VBS substrate, but they were not the primary endpoint-security story in 2015-2019. The vTPM trustlet (Trustlet ID 2 in Ionescu's enumeration [@ionescu-bh2015]) supports Hyper-V Shielded VMs in the Server 2016 timeframe; that is a datacenter, not an endpoint, story. The Part 4 endpoint thesis is Credential Guard, HVCI, WDAC, AMSI, CFG, and Process Mitigation Policies. No. WannaCry used EternalBlue, an NSA-developed exploit that the Shadow Brokers leaked in their April 14, 2017 "Lost in Translation" dump [@wiki-eternalblue]. The operators of WannaCry were the Lazarus Group, attributed to North Korea by the United States, the United Kingdom, Australia, Canada, New Zealand, and Japan in a coordinated December 19, 2017 statement [@wh-wannacry]. The architectural lesson -- that a leaked nation-state SMB worm hit unpatched estates fifty-nine days after Microsoft shipped MS17-010 [@ms-ms17-010] -- is independent of who fired the weapon. No. Kaspersky and CrowdStrike independently confirmed that the Salsa20 key derivation in NotPetya made decryption impossible by design [@kaspersky-petya]. The ransom payment screen was a decoy; the malware was a wiper. US, UK, Canadian, and Australian governments attributed the operation to Russian military intelligence (GRU Sandworm / Unit 74455) on February 15, 2018 [@wh-notpetya] [@ncsc-russia-notpetya]. The October 19, 2020 US Department of Justice indictment named six GRU officers [@doj-gru-notpetya]. Control Flow Guard is forward-edge, software-only, compiler-instrumented Control-Flow Integrity per the Burow et al. ACM CSUR 2017 taxonomy [@burow-cfi-csur2017] [@ms-cfg]. It validates the targets of indirect calls and jumps against a compile-time-known bitmap. Intel Control-flow Enforcement Technology adds a hardware-enforced shadow stack -- a backward-edge defense that protects return addresses. CET on Windows is a Part 5 story; here it suffices to say that CFG and CET defend orthogonal edges of the control-flow graph.

14. Three Boxes, Three Outcomes

A 2017 red-team operator can dump LSASS on an unprotected Windows 7 box in less than a minute. The same operator, against a 1607 Enterprise laptop with Credential Guard enabled, sees an empty buffer where the NTLM hash should be. A 2017 NHS workstation, fifty-nine days behind on MS17-010, sees a ransom note. Three Windows boxes. Three outcomes. One five-year window.

The structural defense -- VBS, the Secure Kernel, LSAISO -- did exactly what its designers said it would do, in a way that was independently verifiable from the empty Mimikatz output buffer. The operational defense -- patch within a month, segment SMBv1, disable legacy protocols -- did exactly what its proponents said it would do, on the boxes where it was applied. The paradox of simultaneity is just the shape of the same picture seen from both sides.

Part 5 takes the story forward into supply-chain compromise, hardware-rooted attestation, and the Intel CET shadow stack. The next five years did not solve the six bypass classes named here. They named more of them.

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.

DPAPI and DPAPI-NG: The Credential Vault Under Everything

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

**Classic DPAPI (Windows 2000, February 17, 2000 [@wikipedia-windows2000]) wraps every per-user Windows secret -- browser cookies, WiFi keys, EFS file keys, Outlook passwords, Credential Manager entries -- in a four-stage chain rooted at the user's password.** DPAPI-NG (Windows 8 / Server 2012) [@wikipedia-winserver2012] replaces the (user, machine) decryption boundary with a protection descriptor [@ms-protection-descriptors] and rides the Microsoft Key Distribution Service [@ms-gmsa-overview] to give every domain controller in the forest the same per-(group, period) key without inter-DC sync. Group Managed Service Accounts, delegated Managed Service Accounts [@ms-dmsa-overview], Windows Hello for Business on TPM-less devices, and Credential Guard's isolated-secret persistence all sit on top. The 2022-2025 Golden gMSA [@semperis-golden-gmsa], Golden dMSA [@semperis-golden-dmsa], and Chromium app-bound encryption [@thn-app-bound] disclosures all admit the same thing: DPAPI's structural ceilings (user-context binding, single-password derivation, KDS-root-key irrotability, hibernation, domain-backup-key concentration) are the design, not bugs.

1. A Thumb Drive, a Profile Directory, and Three Mimikatz Commands

A DFIR analyst slides a stolen laptop's drive into a write-blocker. The volume mounts because BitLocker's recovery key was already in the corporate KMS. Six files in C:\Users\alice\AppData\Roaming\Microsoft\Protect\S-1-5-21-... -- five GUIDs and a Preferred pointer -- are the only thing standing between the analyst and a decade of Alice's saved Windows secrets.

Three Mimikatz [@mimikatz-dpapi-wiki] commands later (dpapi::masterkey /in:<GUID> /sid:S-1-5-21-... /password:<known>, then dpapi::cred /in:<credfile> /masterkey:<unwrapped>, then dpapi::chrome /in:"Login Data") the analyst has Alice's saved RDP password to the production jump host, her Microsoft 365 session cookie, the home WiFi PSK, the KeePass "Windows User Account" master password, and the EFS keys for her protected documents (each item is itemised with primary citations in §5's eleven-row credential-vault inventory). No kernel exploit. No live login. Just one (account-password, SID) pair recovered offline from last week's NTDS.dit backup.

The trick that makes that scene possible is older than most working engineers. It shipped in Windows 2000 GA on February 17, 2000 [@wikipedia-windows2000], it has been the same shape for 25 years, and its single-secret design assumption has been public and tractable since February 3, 2010 [@bursztein-talk-page]. The trick has a name: the Data Protection API, or DPAPI.

This article walks the API end-to-end at the level of detail an academic survey would, but with the working-engineer's framing the topic deserves. We open the four-stage classic-DPAPI chain at the SHA-1-of-NT-hash-into-PBKDF2-with-the-SID-as-UTF-16LE-salt level. We open the 2012 DPAPI-NG redesign [@ms-cng-dpapi] and the Microsoft Key Distribution Service's L0/L1/L2 derivation chain [@ms-gkdi-landing] at the same level of precision.

We name the four production consumers that ride the new chain in 2026: gMSAs, dMSAs, Windows Hello for Business [@ms-whfb-howitworks] software-KSP credentials, and Credential Guard [@paragmali-com-the-en]'s isolated-secret persistence. We name the five structural ceilings the 2022 Golden gMSA [@semperis-golden-gmsa], 2024 Chromium app-bound encryption [@google-security-blog-app-bound], and 2025 Golden dMSA [@semperis-golden-dmsa] disclosures all admit out loud. And we close with what a 2026 practitioner -- developer, defender, red-teamer, platform engineer -- actually does with all of it.

A note on adjacent topics: the companion Credential Guard article in this series covers the LSAISO trustlet's isolation boundary; the companion VBS Trustlets [@paragmali-com-secure-kernel] article covers the trustlet model itself; the TPM in Windows [@paragmali-com-the-c] article covers TPM-bound key storage providers; the BitLocker on Windows [@paragmali-com-limits-of] article covers full-volume encryption; the NTLMless [@paragmali-com-in-windows] article covers Kerberoasting and Golden Ticket disambiguation. Where we touch those topics, we touch them briefly and refer out -- the goal here is to make DPAPI's chain legible from CryptProtectData all the way to the four-phase GoldenDMSA pipeline.

If you can read those six files in Alice's Protect directory and you have her password's SHA-1 hash, you have everything Windows ever encrypted for her. The next eleven sections explain why -- and why the 2012 redesign that was supposed to fix it produced a new ceiling that, by 2022, turned out to be even harder to live with.

2. Why Windows 2000 Needed a Credential Vault: Generation 0 and Generation 1

Three years before DPAPI shipped, an attacker with a logged-in user's session could read every Internet Explorer auto-complete password, every Outlook Express account password, every saved-FTP credential, and every dial-up RAS phonebook entry on the machine -- without breaking any cryptography. The late-1990s reversing tradition (the original pwdump, L0phtCrack, Cain & Abel's "Protected Storage PassView," the ad-hoc Outlook Express and IE 4 form-fill stealers documented across Bugtraq and ntbugtraq mailing lists at the time) defeated all of it uniformly. The "encryption" applications used was honoured by the OS, faithfully, for the attacker's process as for the legitimate one -- because there was no system primitive that distinguished one from the other. Each application baked its own key into the binary; every reverser who pulled the binary apart pulled the key out with it.

The system-provided per-user and per-machine secret-storage primitive that ships in every Windows release from Windows 2000 onward [@wikipedia-dpapi]. The classic API surface is two flat-C functions -- `CryptProtectData` [@ms-cryptprotectdata] and `CryptUnprotectData` -- that take a plaintext, an optional caller entropy parameter, and return a self-contained opaque BLOB. The cryptographic chain inside those two functions is rooted at the user's login password and is what every "encrypted" Windows secret of the next 25 years sits on top of.

If the attacker is the user's session, what does "encrypt this for the user" even mean? That is the question every Generation 0 design dodged and every modern credential-vault design has to answer head-on. The 1990s answer (XOR-with-a-baked-in-key) and Microsoft's first attempt at a real system primitive (Protected Storage / PStore) both missed the same point in different ways.

Generation 1: Protected Storage

Protected Storage shipped with Internet Explorer 4 and stayed in the OS until Microsoft formally deprecated it. The pstore.dll [@ms-pstore] item taxonomy is a four-tuple (Key, Type, Subtype, Name) -- a folder hierarchy of named secret entries. The API was the first system-level secret store on Windows that any application could use without writing its own key derivation; the conceptual contribution survived even after the implementation was abandoned.

PStore had two ideas the post-Vista world kept and one it dropped. The two it kept: secrets live in a system primitive, not in each application; secrets are addressed by name, not by raw key handle. The one it dropped: an Authenticode access-rule clause that would have bound a stored item to the signing identity of the application that created it. No application ever used the access-rule clause in production. Microsoft's developer notes are blunt about how the story ended: "Pstore uses an older implementation of data protection. Developers are strongly encouraged to take advantage of the stronger data protection provided by the CryptProtectData [@ms-cryptprotectdata] and CryptUnprotectData functions"; PStore is "only available for read-only operations in Windows Server 2008 and Windows Vista, but may be unavailable in subsequent versions."

The PStore code-identity-pinning idea (Authenticode access rules) was abandoned in 2000 and re-invented twenty-six years later by Chromium 2024 app-bound encryption, which we will reach in §10.3.

What survived into DPAPI

The Generation 2 design that shipped with Windows 2000 in February 2000 made four moves at once. It kept the two PStore ideas worth keeping ("system-level, not per-application" and "secret addressed by structured name"). It dropped the unused Authenticode access-rule clause. It pushed the cryptographic chain down to a key derived directly from the user's login password. And it added a domain-recovery sidecar (the BackupKey Remote Protocol [@ms-bkrp-landing], which we open in §5) so managed enterprises would adopt it.

The canonical first public design document [@learn-microsoft-com-versions-ms995355vmsdn10]) -- NAI Labs / Network Associates' "Windows Data Protection" whitepaper, MSDN ms995355, October 2001 -- is unambiguous about the layering: "DPAPI initially generates a strong key called a MasterKey, which is protected by the user's password. DPAPI uses a standard cryptographic process called Password-Based Key Derivation, described in PKCS #5, to generate a key from the password." And: "DPAPI is a password-based data protection service. It requires a password to provide protection."Some secondary sources attribute a "Microsoft Windows Data Protection API" whitepaper to Niels Ferguson at niels.ferguson.com/research/dpapi.html. That URL has been TCP-unreachable for years, has zero Wayback captures across four candidate variants, and the Wikipedia Niels Ferguson article [@wikipedia-niels-ferguson] lists no DPAPI publication for him -- his named Microsoft paper is the 2006 BitLocker / Elephant-diffuser paper, not anything DPAPI-related. The verifiable Microsoft-blessed first design document is the NAI Labs ms995355 whitepaper [@learn-microsoft-com-versions-ms995355vmsdn10]).

The two-function flat-C API Microsoft shipped with Windows 2000 in February 2000 is what every Windows secret of the next 25 years has been encrypted with. The four-stage chain it hides behind those two function names is what we open up next.

3. The Four-Stage Chain: How `CryptProtectData` Actually Encrypts

A CryptProtectData [@ms-cryptprotectdata] call goes in with a plaintext buffer and an optional entropy parameter; out comes a self-contained opaque BLOB whose header adds roughly 100-150 bytes to the plaintext (the exact size depends on the algorithm choice and the master-key GUID encoding; the field-by-field BLOB layout is documented in the Bursztein-Picod 2010 paper [@bursztein-paper-pdf] and parsed by the Mimikatz dpapi::blob [@mimikatz-dpapi-wiki] module). There is no pszProvider argument, no hKey, no algorithm choice exposed to the caller. Behind those two parameters is a four-stage cryptographic chain that has been the same shape for a quarter-century. Each stage takes the previous stage's output and one new input; the only secret in the entire chain that an offline attacker has to guess is the user's password.

flowchart TD Password["User password"] --> NTHash["NT hash
(MD4 of UTF-16LE password)"] NTHash --> Sha1NT["SHA-1(NT hash)"] SID["User SID
(UTF-16LE)"] --> PBKDF2 Sha1NT --> PBKDF2["Stage 1: PBKDF2
(HMAC-SHA1 / HMAC-SHA512)"] PBKDF2 --> PreKey["Pre-key"] MK["Stage 2: Master key
(64 random bytes)"] -->|encrypted under| AESCBC["version-cipher wrap (AES-CBC on Win7+)"] PreKey --> AESCBC AESCBC --> MKFile["%APPDATA%/Microsoft/Protect/<SID>/<GUID>"] MK --> SessionKey["Stage 3: Session key
HMAC(MK, salt || entropy)"] SessionKey --> Wrap["Stage 4: BLOB wrap
(3DES or AES-256, salt, HMAC)"] Plaintext["Plaintext"] --> Wrap Wrap --> Blob["DPAPI BLOB"]

Stage 1: Pre-key derivation

The pre-key is a function of three values. The user-account password (or its NT-hash equivalent, supplied by LSASS to the local DPAPI provider) is hashed with SHA-1; the SHA-1 result is fed into PBKDF2 as the input keying material; the user's security identifier (SID) [@learn-microsoft-com-versions-ms995355vmsdn10]) UTF-16LE-encoded is the salt; and a Windows-version-dependent iteration count completes the call. The output is a fixed-width pre-key that Stage 2 will use to wrap the master key.

The chain has changed parameters across Windows versions but has kept the four-stage shape since 2000. The Passcape master-key analysis table [@passcape-master-key-analysis] records the migration verbatim:

Windows version	Symmetric cipher	HMAC	PBKDF2 iterations
Windows 2000	RC4	SHA-1	1
Windows XP	3DES	SHA-1	4 000
Windows Vista	3DES	SHA-1	24 000
Windows 7	AES-256	SHA-512	5 600
Windows 10 / 11	AES-256	SHA-512	8 000

The shift from PBKDF2-HMAC-SHA1 / 3DES (Windows 2000 -- Vista) to PBKDF2-HMAC-SHA512 / AES-256 (Windows 7 onward) happened at Windows 7, not Windows 10; Bursztein and Picod's 2010 USENIX WOOT paper [@usenix-woot10] documented the SHA-1/3DES era through Windows 7 (the Black Hat DC 2010 talk and WOOT paper covered XP's 4,000-iteration regime and Vista's 24,000-iteration regime; Windows 7's PBKDF2-SHA512/AES-256 shift had only recently shipped when the research was finalised).

Note: 8 000 iterations of HMAC-SHA-512 is not strong against a modern wordlist attack on a leaked NT hash. Cumulative updates can raise the iteration count further; the actual count is recorded in the master-key file's header and is not implicit. When you read someone's master key, read the iteration count from the file -- do not assume.

Stage 2: The master key

The master key is a 64-byte cryptographically random secret; one is generated per user, on first use of DPAPI, and a fresh one is generated every 90 days by default. Master keys live as files inside %APPDATA%\Microsoft\Protect\<SID>\<GUID>, where the GUID is the master-key identifier embedded in every BLOB that uses it. The file begins with a service header (containing the iteration count and algorithm IDs) followed by four distinct slots: (1) the user-master-key blob (encrypted under the Stage 1 pre-key with the version-dependent cipher -- RC4 on Windows 2000, 3DES on XP through Vista, AES-256-CBC on Windows 7 and later); (2) the local-encryption-key slot; (3) the local-backup-key (Windows 2000) or CREDHIST GUID (Windows XP and later); and (4) the domain-backup-key blob [@ms-bkrp-landing] (encrypted to the DC's backup public key, see §5).

A 64-byte random secret per user, persisted as a file under `%APPDATA%\Microsoft\Protect\<SID>\<GUID>`, encrypted under a pre-key derived from the user's password and SID. Every DPAPI BLOB the user ever creates is wrapped under a session key derived from one of these master keys. Master keys rotate every 90 days by default per the NAI Labs design document [@learn-microsoft-com-versions-ms995355vmsdn10]) and the Passcape master-key analysis [@passcape-master-key-analysis], but old master keys remain on disk so old BLOBs can still be decrypted.

Stage 3: The per-call session key

For every call to CryptProtectData, DPAPI generates a fresh per-blob salt, computes an HMAC of the master key with the salt and the optional caller entropy, and uses that HMAC as the session key for the actual symmetric encryption. The session key is never stored; it is derivable from (master key, salt, entropy) at unwrap time per the Bursztein-Picod 2010 paper [@bursztein-paper-pdf] §3.3 and the Mimikatz dpapi::blob parser [@mimikatz-dpapi-wiki]. The salt is in the BLOB header; the entropy, if any, must be supplied by the caller at unwrap time.

Stage 4: The BLOB wrap

The output BLOB is a self-describing structure with a fixed header. The provider GUID {df9d8cd0-1501-11d1-8c7a-00c04fc297eb} identifies it as a classic-DPAPI blob; the master-key GUID names the master key under which it was wrapped; an algCrypt algorithm identifier records which symmetric cipher was used (0x6603 for CALG_3DES on legacy builds, 0x6610 for CALG_AES_256 on later builds); the salt, ciphertext, and HMAC fill the rest. The Mimikatz dpapi module wiki [@mimikatz-dpapi-wiki] documents the verbatim field layout that every offline DPAPI tool parses to this day.

The `algCrypt` field in the DPAPI BLOB header is a CryptoAPI algorithm identifier from `wincrypt.h`: `0x6603` is `CALG_3DES` (the historical default, encoded as `ALG_CLASS_DATA_ENCRYPT | ALG_TYPE_BLOCK | ALG_SID_3DES`); `0x6610` is `CALG_AES_256` (used on Windows 7 and later, encoded as `ALG_CLASS_DATA_ENCRYPT | ALG_TYPE_BLOCK | ALG_SID_AES_256`). The provider GUID `{df9d8cd0-1501-11d1-8c7a-00c04fc297eb}` is the magic constant that marks every classic-DPAPI BLOB and is the same value the Mimikatz `dpapi::blob` module [@mimikatz-dpapi-wiki] and the Bursztein-Picod 2010 paper [@bursztein-paper-pdf] §3.3.1 print when they parse one.

Parse --> Cert&#123;"CERTIFICATE="&#125;
Parse --> Local&#123;"LOCAL="&#125;
Parse --> Web&#123;"WEBCREDENTIALS="&#125;
Sid --> KSP["Microsoft Key Protection Provider<br/>+ kdssvc.dll [MS-GKDI]"]
Cert --> CertKSP["Cert's KSP<br/>(TPM-backed possible)"]
Local --> LocalProv["Microsoft Key Protection Provider<br/>(LOCAL=user / LOCAL=machine)"]
Web --> Broker["Microsoft Client Key Protection Provider<br/>(credential broker)"]
KSP --> Wrap
CertKSP --> Wrap
LocalProv --> Wrap
Broker --> Wrap
Wrap["Derive wrapping key,<br/>encrypt content"] --> Blob["Self-describing blob<br/>(descriptor + provider info<br/>+ key id + ciphertext + HMAC)"]

The output blob is self-describing per the protected-data-format reference [@ms-protected-data-format]: descriptor, provider info, key identifier, ciphertext, HMAC. Any device with a CNG implementation that can satisfy the descriptor decrypts. There is no out-of-band key shipping. There is no "encrypt the blob and ship the key separately." The descriptor is the key-distribution policy.

Key idea: DPAPI-NG separates who can decrypt (the descriptor) from where the key material lives (the provider). The descriptor is the contract; the provider is the implementation. This is the structural innovation that lets a blob protected on one machine be decrypted on another without any application-layer key-management code.

The CNG DPAPI overview page lists only two principal classes -- AD group and web credentials -- whereas the protection-descriptors page enumerates three (adding the certificate-store class). Both are correct: the certificate descriptor maps to a different provider, hence the two-principal framing on the higher-level overview page and the three-keyword framing on the descriptors-grammar page.

The LOCAL=user and CERTIFICATE= cases are interesting but mostly variations on themes that classic DPAPI or the Windows certificate store could already do. The case that required Microsoft to ship a new DC-side daemon -- the case that turned DPAPI-NG into the substrate for gMSAs [@ms-gmsa-overview], dMSAs [@ms-dmsa-overview], Hello for Business, and Credential Guard's persistence layer -- is the SID= AD-group descriptor. The next section opens its substrate: the Microsoft Key Distribution Service and the [MS-GKDI] protocol.

7. The Microsoft Key Distribution Service: How `[MS-GKDI]` Computes the Same Group Key on Every DC Without Talking to Any of Them

Imagine a forest with seven writable domain controllers. A laptop in Singapore protects a DPAPI-NG blob with SID=S-1-5-21-...XYZ (some AD group). Three months later, a phone in Seoul -- a member of the same group, on a different DC -- needs to decrypt it. Neither DC has ever heard of the blob. Both DCs derive exactly the same group key and hand it to the requesting member. No inter-DC synchronisation. No key-distribution code in either application. The mechanism is one forest-wide root key plus a deterministic key-derivation function.

The DC-side daemon that ships in every writable domain controller from Windows Server 2012 onward [@wikipedia-winserver2012]. Implements the [`[MS-GKDI]` Group Key Distribution Protocol](https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-gkdi/943dd4f6-6b80-4a66-8594-80df6d2aad0a) (current revision class 10.0, April 2024) and is the substrate for every DPAPI-NG `SID=` blob, every gMSA password, every dMSA password, and the TPM-less software-KSP path of Windows Hello for Business. The service has one job: given a (group, time-period) request from a member computer, derive and return the per-(group, period) key from a single forest-wide root key.

Provisioning the root key

Every forest needs exactly one KDS root key before any DPAPI-NG SID= consumer can use it. The PowerShell cmdlet Add-KdsRootKey [@ms-add-kdsrootkey] is the provisioning entry point. The Microsoft Learn page is verbatim about the constraints: "The Add-KdsRootKey cmdlet generates a new root key for the Microsoft Group Key Distribution Service (KdsSvc) within Active Directory... It is required to run this only once per forest." The default EffectiveTime is "10 days after the current date" to allow Active Directory replication to converge across all writable DCs before any consumer tries to derive against the new key.The Add-KdsRootKey -EffectiveTime ((Get-Date).AddHours(-10)) override is for single-DC test forests only. Production forests should let the 10-day default replicate; using the back-dated override means the first consumer to call into the KDS may target a DC that has not yet received the new root key from replication.

The root key lives at CN=Master Root Keys,CN=Group Key Distribution Service,CN=Services,CN=Configuration,<forest-DN> and carries four attributes that downstream offensive-research tools enumerate: msKds-RootKeyData (the actual key bytes), msKds-KDFAlgorithmID (the KDF identifier, currently SP800-108 HMAC-SHA512), msKds-KDFParam (the KDF parameter block), and msKds-PrivateKeyLength. These four attributes, together, are everything a deterministic-KDF derivation needs to recompute every group key the forest will ever produce.

The single forest-wide secret that anchors every per-(group, period) key the Microsoft Key Distribution Service will ever derive, for every DPAPI-NG `SID=` blob, every gMSA, every dMSA, every Hello-for-Business software-KSP container, and every Credential-Guard isolated-secret persistence wrap. Provisioned with `Add-KdsRootKey` [@ms-add-kdsrootkey], exactly once per forest. Stored as four attributes (`msKds-RootKeyData`, `msKds-KDFAlgorithmID`, `msKds-KDFParam`, `msKds-PrivateKeyLength`) under `CN=Master Root Keys,CN=Group Key Distribution Service,CN=Services,CN=Configuration,`. Currently, Microsoft documents no rotation procedure [@ms-cng-dpapi-backup-keys]; see §9.3.

The L0 / L1 / L2 derivation chain

The [MS-GKDI] specification (current revision class 10.0, April 23 2024) describes the protocol. Internally, the KDS computes a three-level derivation:

L0 seed key: derived from the root key and a label that includes the period-in-hours-thousands tier and the group-related input, via a NIST SP 800-108 KDF in counter mode using HMAC-SHA-512 (see NIST SP 800-108r1 [@nist-sp-800-108r1], August 2022).
L1 seed key: derived from L0 with a second-tier label.
L2 seed key: derived from L1 with the third-tier label. This is the actual symmetric key the DPAPI-NG blob's content key wraps under (or the seed for a per-period group ECDH key pair, in the public-key DPAPI-NG mode).

The first level of the [`[MS-GKDI]`](https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-gkdi/943dd4f6-6b80-4a66-8594-80df6d2aad0a) three-tier derivation chain. Computed deterministically from the KDS root key and a label that combines the time-period tier (in units of `period-in-hours / 1000`) and a group-related input. The whole point of the chain is that any DC that holds the same root key, given the same label, derives the same L0 seed key without coordination with any other DC -- which is also the whole reason a single root-key compromise compromises every key the forest will ever derive. flowchart TD Root["KDS root key
(forest-wide secret)"] --> L0["L0 seed key
(period_hours / 1000 + group input)"] L0 --> L1["L1 seed key
(second-tier label)"] L1 --> L2["L2 seed key
(third-tier label)"] L2 --> Symmetric["Per-(group, period)
symmetric key OR
ECDH key-pair seed"] KDF["SP800-108 counter-mode
KDF, HMAC-SHA-512"] -.derives.-> L0 KDF -.derives.-> L1 KDF -.derives.-> L2

The `GetKey` round trip

A member computer's local KDS-NG provider calls the GetKey RPC (the primary opnum of [MS-GKDI]) against any reachable writable DC. The DC computes the L0/L1/L2 chain on demand and returns the per-(group, period) key material. No inter-DC synchronisation is needed because the KDF is deterministic.

sequenceDiagram participant Member as "Member computer (Microsoft Key Protection Provider)" participant DC as "Nearest writable DC (kdssvc.dll)" participant Root as Root key (AD-replicated) Member->>DC: GetKey(group_sid, period_id) DC->>Root: Read msKds-RootKeyData + KDF params Root-->>DC: Root-key material DC->>DC: Compute L0(period, group) -> L1 -> L2 DC-->>Member: Per-(group, period) key material Member->>Member: Wrap (or unwrap) DPAPI-NG blob Because the KDF is deterministic by design -- this is exactly the security property NIST SP 800-108r1 [@nist-sp-800-108r1] §5 establishes -- an attacker who reads the four root-key attributes once can derive every per-(group, period) key the KDS will ever produce, *for that root key*, without further DC interaction. The same property that lets a Singapore laptop and a Seoul phone derive the same key without talking to each other lets an attacker who reads the root key derive every gMSA password the forest will ever issue. This is the same property that makes Golden gMSA [@semperis-golden-gmsa] work in §10.

Every DC in the forest runs the same kdssvc.dll over the same root key with the same KDF; every authorised member of the named group can ask any DC for the per-(group, period) key and receive the same answer. The architecture is elegant. It is also, by structural necessity, the architecture that makes a one-shot read of the root key into a one-shot compromise of every key the forest will ever derive. Hold that thought; it is what §10 is built on. First we look at what actually rides on this substrate today.

8. The Four Things That Ride DPAPI-NG in 2026

One protocol, four production consumers. The same KDS root key that protects a SID= DPAPI-NG blob is also the root from which every gMSA password, every dMSA password, every TPM-less Windows Hello private key, and every Credential Guard isolated NT-hash is derived.

A Windows-Server-2012-introduced Active Directory account class whose password is computed automatically by the Microsoft Key Distribution Service [@ms-gmsa-overview] on the DC, rotated every 30 days, 256 bytes long, and shared across multiple service hosts via the `msDS-GroupMSAMembership` SDDL gate. From the Microsoft Learn overview verbatim: *"For a gMSA, the domain controller computes the password on the key that the Key Distribution Services provides, along with other attributes of the gMSA."* `Install-ADServiceAccount` on each member computer caches the derivation locally so the service can boot under the account. flowchart TD Root["KDS root key"] --> Chain["[MS-GKDI] L0/L1/L2 chain"] Chain --> GMSA["gMSA password
(30-day rotation,
256 bytes)"] Chain --> DMSA["dMSA password
(machine-bound,
Server 2025)"] Chain --> WHfB["WHfB software-KSP
(TPM-less devices,
SID + device descriptor)"] Chain --> CG["Credential Guard
LsaIso-isolated secret
(trustlet identity descriptor)"]

8.1 Group Managed Service Accounts

gMSAs shipped in Windows Server 2012 (GA September 2012). The model: one AD account, multiple service hosts, no admin-managed password rotation, no per-service password file. The Microsoft Learn overview [@ms-gmsa-overview] is verbatim about the chain: "The Microsoft Key Distribution Service (kdssvc.dll) lets you securely obtain the latest key or a specific key with a key identifier for an Active Directory account... For a gMSA, the domain controller computes the password on the key that the Key Distribution Services provides, along with other attributes of the gMSA."

The constructed attribute that surfaces the password to authorised member computers is msDS-ManagedPassword [@ms-ms-adts-managedpassword]; it is computed on demand by the DC from the KDS chain when an authorised member queries it. The authorisation gate is the msDS-GroupMSAMembership security descriptor on the gMSA object: only principals whose SIDs satisfy that SDDL get the password back. Rotation is every 30 days. The password length is 256 bytes -- "a randomly generated password of 256 bytes, making it infeasible to crack" per the Semperis Golden gMSA write-up [@semperis-golden-gmsa], which is true if and only if the KDS root key is intact. We come back to that if and only if in §10.

8.2 Delegated Managed Service Accounts

dMSAs shipped in Windows Server 2025 (GA November 1, 2024 [@wikipedia-winserver2025]). The same KDS chain; a different authorisation gate. Rather than binding to AD group membership, dMSA authentication binds to machine identity: the Microsoft Learn overview [@ms-dmsa-overview] describes dMSAs as "a machine account with managed and fully randomized keys, while disabling original service account passwords. Authentication for dMSA is linked to the device identity, which means that only specified machine identities mapped in Active Directory (AD) can access the account." The msDS-ManagedPasswordId attribute carries a machine-binding component. Microsoft's marketing framing positions dMSA as the "Kerberoast-immune" replacement for static service accounts.

The Server 2025 dMSA design has its own §10 footnote: the July 2025 Semperis Golden dMSA disclosure [@semperis-golden-dmsa] found that the msDS-ManagedPasswordId time-component has predictable structure with only ~1 024 plausible values, making offline brute-forcing tractable once the KDS root key is in hand.

8.3 Windows Hello for Business software-KSP credentials

The Hello for Business how it works page [@ms-whfb-howitworks] describes the credential as a per-user per-device asymmetric key pair. On TPM-equipped devices the private key lives in the TPM and DPAPI-NG is not in the wrap path. On TPM-less devices (the structural worst case) the WHfB private key sits in a CNG software Key Storage Provider container persisted as a DPAPI-NG-protected file [@ms-whfb-howitworks] whose protection descriptor binds it to the user SID + device. The TPM in Windows article in this series covers the TPM-bound case; here we record only that the software-KSP fallback rides on DPAPI-NG and inherits the KDS root-key dependency for the SID-bound branch.

A non-hardware-bound CNG key-storage provider that persists key material in DPAPI-NG-protected files in the user profile. Used by Windows Hello for Business on TPM-less devices [@ms-whfb-howitworks] and as the fallback when no hardware-bound KSP (TPM, smart card, Secure Enclave equivalent) is available. The structural worst case for the WHfB credential, because the private key lives in a file the OS can read in any user-context process, wrapped under a DPAPI-NG blob whose protection descriptor reduces back to the KDS root key for SID-anchored bindings.

8.4 Credential Guard isolated-secret persistence

The companion Credential Guard article in this series covers LsaIso.exe and the LSAISO trustlet's isolation boundary in depth; what matters here is that the trustlet's persistence layer is DPAPI-NG. LsaIso.exe, running in VTL1 IUM, stores the isolated NT one-way function outputs and Kerberos session keys in DPAPI-NG blobs whose protection descriptor binds them to the trustlet's own identity. The VSM master key (TPM-bound on TPM-2.0 systems per Microsoft Learn's Credential Guard [@ms-credential-guard] overview, which describes how Credential Guard "uses Virtualization-based security (VBS) [@ms-vbs] to isolate secrets") is what the trustlet seals its DPAPI-NG protection state under across reboots. The end result is that even though the Credential Guard model puts the credential outside lsass.exe, the persistence of that isolated secret rides on the same KDS-rooted DPAPI-NG chain every other consumer in this section uses.

Consumer	Rotation	Authorisation gate	On-disk artefact	Recovery story
gMSA	30 days	`msDS-GroupMSAMembership` SDDL	Cached on member via `Install-ADServiceAccount`	Recompute via KDS at any time
dMSA	Managed by KDS	Machine identity in AD	Cached on member; `msDS-ManagedPasswordId` carries machine binding	Recompute via KDS
WHfB software-KSP	Per-credential lifetime	User SID + device	DPAPI-NG-wrapped key container in user profile	New enrollment if lost
LsaIso DPAPI-NG persistence	Boot-cycle bound	Trustlet identity	Trustlet-managed VTL1 store, sealed under VSM master key	Re-derive on next logon

Every shipping Windows credential primitive that just works across multiple devices, multiple service hosts, or multiple cold-boot cycles -- without per-application key-management code -- is sitting on the same KDS root key. The architectural bet is that the root key never leaks. The next two sections are about what happens when it does.

9. The Five Structural Ceilings DPAPI Cannot Close

A reader who has followed the chain through §§3-8 has earned the right to a sharp question: where does this whole architecture fail? Not where does it have bugs (it has very few cryptographic ones); where does the design draw a line that no implementation patch can move? There are exactly five such lines.

9.1 The user-context ceiling

Any process running as the user can call CryptUnprotectData [@ms-cryptprotectdata] or NCryptUnprotectSecret [@ms-ncryptprotectsecret] against any blob the user could decrypt. The chain binds the secret to the user identity, not the consuming process identity. This is the structural reason every modern browser-cookie-stealer family (Lokibot, Vidar, RedLine, Lumma, StealC) works against DPAPI-protected Chrome state keys; it is also the reason Google introduced Chrome app-bound encryption [@thn-app-bound] in July 2024 outside DPAPI. Will Harris of the Chrome security team is verbatim about why the patch had to live outside DPAPI rather than inside it: "On Windows, Chrome uses the Data Protection API (...). However, the DPAPI does not protect against malicious applications able to execute code as the logged in user -- which info-stealers take advantage of."

On Windows, Chrome uses the Data Protection API (DPAPI). However, the DPAPI does not protect against malicious applications able to execute code as the logged in user -- which info-stealers take advantage of. -- Will Harris, Chrome security team, July 2024

9.2 The single-password-derivation ceiling

The classic-DPAPI master-key wrap is PBKDF2-HMAC-SHA512(SHA1(NT-hash), SID-as-UTF16LE, ~8000 iterations) in the modern (Windows 10/11) era per the Passcape table [@passcape-master-key-analysis]. 8 000 iterations of HMAC-SHA-512 is not strong against a modern wordlist attack on a leaked NT hash. The structural limit is the user's password, not the cryptographic primitive. The KDF parameter is tunable; the single secret in the chain is not -- a strong password makes the chain strong, a weak password makes the chain weak, and there is no architectural way to recover from a weak password short of re-deriving every user's master key under a stronger one.

9.3 The KDS-root-key irrotability ceiling

Once a KDS root key is in production use, rotating it would invalidate every gMSA msDS-ManagedPassword, every dMSA password, every SID= blob, every Hello-for-Business software-KSP container, and every Credential-Guard isolated-secret blob ever produced under it. Microsoft's documented mitigation is preventative (a system access control list on msKds-RootKeyData), not recoverable. This is the same structural ceiling that the Microsoft Learn DPAPI-backup-keys page [@ms-cng-dpapi-backup-keys] admits for the older [MS-BKRP] keys, in identical language: "There currently is no officially supported way of changing or rotating these DPAPI backup keys on the domain controllers." Burn-the-forest-and-rebuild for [MS-BKRP]; SACL-the-attribute-and-hope for KDS root keys.

9.4 The hibernation / S4 ceiling

CryptProtectMemory / CryptUnprotectMemory [@ms-cryptprotectmemory] provide an in-memory scrub primitive that scopes a secret across same-process / cross-process / cross-session lifetimes. They cannot scrub RAM written to hiberfil.sys on suspend-to-disk. On resume the master key is in plaintext in the page cache. The structural defence is BitLocker on the system volume (the BitLocker on Windows article in this series covers full-volume encryption end-to-end); within DPAPI itself the ceiling cannot move because the OS has to be able to resume.

9.5 The domain-backup-key concentration ceiling

The [MS-BKRP] backup key is the recoverability story for the password-reset case -- and it is also the structural reason any DA who can dump LSASS on a writable DC has every user's master key in the forest. mimikatz "lsadump::backupkeys /system:dc.contoso.local /export" is the canonical primitive, documented in the Mimikatz DPAPI wiki [@mimikatz-dpapi-wiki]. The architectural answer (HSM-backing the DC's RSA private key) is not in Microsoft's mainline guidance; the recommendation when these keys are compromised [@ms-cng-dpapi-backup-keys] is the burn-the-forest-and-rebuild line we just quoted.

Key idea: These five ceilings are not bugs. They are the design's price for the design's other guarantees. The user-context ceiling buys ubiquitous adoption. The single-password ceiling buys a usable recovery path. The KDS-root-key ceiling buys cross-DC determinism. The hibernation ceiling buys process performance and resumability. The domain-backup-key ceiling buys enterprise recovery. Every one of the next five years' DPAPI incidents will hit one of these five ceilings.

The 2022-2025 disclosures are not five surprises. They are five different attackers naming five different ceilings out loud. The next section walks the named incidents one ceiling at a time.

10. The 2022-2025 Residual Class: Golden gMSA, Golden dMSA, and Chromium App-Bound Encryption

In March 2022, Yuval Gordon (Microsoft Security Researcher, via Semperis blog) published Introducing the Golden GMSA Attack [@semperis-golden-gmsa] and the GoldenGMSA [@goldengmsa-repo] C# tool. In July 2024, Google announced Chrome's app-bound encryption [@google-security-blog-app-bound]. In July 2025, Adi Malyanker (also Semperis) published Golden dMSA: What Is dMSA Authentication Bypass? [@semperis-golden-dmsa] and the GoldenDMSA [@goldendmsa-repo] tool, mirrored on PR Newswire with a July 16, 2025 dateline [@prnewswire-semperis-dmsa]. Three disclosures in three years, three different ceilings -- but the same underlying pattern: each one is an admission that the structural ceiling cannot be patched inside DPAPI.

flowchart LR C1["§9.1 user-context"] --> Chromium["Chromium app-bound encryption
(July 2024, Will Harris)"] C2["§9.3 KDS-root-key irrotability"] --> GGMSA["Golden gMSA
(March 2022, Y. Gordon)"] C2 --> GDMSA["Golden dMSA
(July 2025, A. Malyanker)"] C3["§9.5 domain-backup-key"] --> MimikatzBKK["mimikatz lsadump::backupkeys"] C4["§9.4 hibernation / S4"] --> BL["BitLocker article cross-link"]

10.1 Golden gMSA (Yuval Gordon, Microsoft / Semperis blog, March 2022)

Targets the §9.3 KDS-root-key irrotability ceiling. Gordon is verbatim about the two-step nature of the attack: "An attacker with high privileges can obtain all the ingredients for generating the password of any gMSA in the domain at any time with two steps: Retrieve several attributes from the KDS root key in the domain... Use the GoldenGMSA tool to generate the password of any gMSA associated with the key, without a privileged account." Step 1 is a one-shot read of the KDS root key attributes. Step 2 is offline derivation. There is no further DC interaction, ever, because the [MS-GKDI] chain is deterministic by NIST SP 800-108r1 design.

The defensive answer is in the GoldenGMSA repository [@goldengmsa-repo]: "configure a SACL on the KDS root key objects for everyone reading the msKds-RootKeyData attribute. Once the system access control list (SACL) is configured, any attempt to dump the key data of a KDS root key will generate security event 4662 on the DC where the object type is msKds-ProvRootKey and the account name is not a DC." Plus the cross-trust SACL on msDS-ManagedPasswordId with property GUID {0e78295a-c6d3-0a40-b491-d62251ffa0a6}. This is a detective control, not a recovery control. Once the root key has been read, every gMSA password the forest has ever issued or will ever issue under that root key is offline-derivable.

An attacker with high privileges can obtain all the ingredients for generating the password of any gMSA in the domain at any time with two steps. -- Yuval Gordon, Microsoft / Semperis blog, March 2022

The Golden gMSA SACL detects same-trust reads only. Cross-trust reads of msDS-ManagedPasswordId from a forest the auditing forest does not control are the documented detection blind-spot. If your gMSA-using forest has a one-way trust from a forest you do not own, you cannot see its reads.

10.2 Golden dMSA (Adi Malyanker, Semperis, July 2025)

Targets the §9.3 ceiling, plus a fresh dMSA-specific surface. Malyanker is verbatim about the structural flaw: "a critical design flaw: a structure that's used for the password-generation computation contains predictable time-based components with only 1,024 possible combinations, making brute-force password generation computationally trivial." The four-phase pipeline is enumerated in the GoldenDMSA repository [@goldendmsa-repo]: "Phase 1: Key Material Extraction (pre requirement of the attack) -- Dump the KDS Root Key from the DC. Phase 2: Enumerate dMSA accounts ... Phase 3: ManagedPasswordID guessing ... Phase 4: Password Generation." The tool exposes commands wordlist, info, kds, bruteforce, compute, and convert -- the operational vocabulary the four-phase pipeline needs.

Semperis' own rating is MODERATE with the explicit caveat "to exploit it, attackers must possess a KDS root key available only to only the most privileged accounts: root Domain Admins, Enterprise Admins, and SYSTEM." That is exactly the §9.3 ceiling re-stated. The novelty in dMSA is the 1 024-combination time-component flaw -- a design weakness on top of the structural ceiling, not a substitute for it.

10.3 Chromium app-bound encryption (Will Harris, Google Chrome, July 30, 2024)

Targets the §9.1 user-context ceiling. The Google Security Blog announcement [@google-security-blog-app-bound] describes a COM-elevation service that wraps the Chrome state key with both DPAPI and a per-binary identity check the COM service enforces. The verbatim quote, mirrored via The Hacker News [@thn-app-bound]: "Because the app-bound service is running with system privileges, attackers need to do more than just coax a user into running a malicious app. Now, the malware has to gain system privileges, or inject code into Chrome, something that legitimate software shouldn't be doing."

The architecturally important word is "app-bound." Chromium's response to the user-context ceiling lives outside DPAPI. DPAPI itself is unchanged. The 2024 patch is application-layer code-identity pinning -- exactly what Generation-1 Protected Storage's abandoned Authenticode-access-rule clause was supposed to be in 2000, exactly what Apple Keychain [@apple-platform-security-keychain] has shipped on macOS for over two decades, exactly what the §11 wishlist asks for.

10.4 The recurring pattern

Each disclosure does not break a cryptographic primitive. Each is a re-statement of "the design's ceiling is the design's ceiling." The defensive answers are detection (SACL audit; cross-trust read alerting; binary-identity check) and workaround at a higher layer (the COM-elevation service Chrome wraps DPAPI in), never cryptographic strengthening of DPAPI itself. The 2026 reader's job is to recognise which ceiling each new incident hits.

Year	Disclosure	Ceiling hit	Tool reference	Defensive answer
2022	Golden gMSA (Y. Gordon, Microsoft / Semperis blog)	§9.3 KDS irrotability	`GoldenGMSA` [@goldengmsa-repo]	SACL on `msKds-RootKeyData`; Event 4662
2024	Chromium app-bound encryption (W. Harris, Google)	§9.1 user-context	Chrome 127 release notes [@chromereleases-127-stable]	COM-elevation per-binary identity check, outside DPAPI
2025	Golden dMSA (A. Malyanker, Semperis)	§9.3 + dMSA `msDS-ManagedPasswordId` predictability	`GoldenDMSA` [@goldendmsa-repo]	SACL plus monitoring `msDS-ManagedPasswordId` brute-force

By 2026 the pattern is clear: DPAPI's structural ceilings produce a steady drip of disclosures, each defensively answerable but none cryptographically fixable inside DPAPI itself. The open question is what the successor would even look like -- and that is the next section.

11. Open Problems

A few sharp open problems remain at the design layer -- problems that a future Generation 4 of the credential-vault tradition would have to solve. None of them is in Microsoft's published roadmap as of 2026.

KDS root-key rotation

A hybrid wrap-then-re-wrap-on-first-decrypt-under-new-root scheme could in principle restore rotation without invalidating existing blobs: every consumer would carry a tag indicating which root-key generation last unwrapped it; on first unwrap under a generation-N+1 root the system would re-wrap the consumer-side cache. No standard or product implements this today; no public proposal revises [MS-GKDI] to add it.

Code-identity pinning

Apple Keychain [@apple-platform-security-keychain] enforces "keychain items can be shared only between apps from the same developer ... enforced through code signing, provisioning profiles, and the Apple Developer Program." DPAPI / DPAPI-NG have no equivalent. A CALLER_ATTRIBUTION=Publisher:<wdac-rule-hash> descriptor would, in principle, give Windows the same property -- the SHA-256 hash of the WDAC rule [@paragmali-com-app-ide] that authorises the calling binary, baked into the descriptor, checked at unwrap time. No one is shipping it. The 2024 Chromium app-bound encryption response [@thn-app-bound] is the application-layer workaround that proves the design gap is real.

Post-quantum migration

DPAPI-NG today uses RSA or ECDH key transport via CMS enveloped-content format (CERTIFICATE= with RSA private keys, SID= for group descriptors) per the protected-data-format [@ms-protected-data-format] reference. Both wrap algorithms are vulnerable to Shor's algorithm on a sufficiently large quantum computer, and the persistent on-disk blob format is the harvest-now-decrypt-later target -- a framing surfaced across NIST's broader post-quantum migration corpus, including the NIST PQC project page [@nist-pqc-project] and the linked NIST IR 8547 migration-timeline document. The migration story for the symmetric chain is comparatively easy (the SP800-108 KDF is parameterised; HMAC-SHA-512 has no quantum-cliff weakness for the relevant key sizes). The migration story for the public-key wrap is the hard part. NIST published FIPS 203 (ML-KEM) [@nist-fips-203] and FIPS 204 (ML-DSA) [@nist-fips-204] in August 2024; OpenSSH 9.9 [@openssh-9-9-release] (September 2024) and TLS deployments shipped hybrid post-quantum key exchange. Windows added experimental post-quantum TLS support in 2024 but has not yet announced ML-KEM CNG-DPAPI providers; see the companion Post-Quantum Cryptography on Windows [@paragmali-com-year-migrati] article in this series for the broader Windows migration story. The shape that fits DPAPI's ceiling-laden design is hybrid wrap-then-re-wrap-on-first-decrypt: a hybrid wrap (RSA-OAEP || ML-KEM or ECDH || ML-KEM) -- protect under (RSA+ML-KEM) or (ECDH+ML-KEM) today; let consumers re-wrap to the new combiner on first unwrap; phase out the classical half on a long horizon -- is the only forward-compatible answer; Microsoft's published DPAPI-NG protection-providers [@ms-protection-providers] have not yet announced one.

Credential roaming for Entra-joined-only / unmanaged-device estates

Classic DPAPI's cross-device story has always been "use roaming profiles" (deprecated) or "use the [MS-BKRP] backup key" (admin-recovery, not user-driven). DPAPI-NG's SID= solves it cleanly for AD-joined estates but the modern Entra-only estate has no native equivalent -- the LOCAL=user descriptor is per-machine. An ENTRAGROUP=<object-id> descriptor that resolved through Entra ID Token Service the way SID= resolves through KDS would close the gap. No public roadmap announces this.

Hibernation / S4

BitLocker [@wikipedia-bitlocker] on the system volume defends the disk; suspending fully to ROM (or refusing S4 entirely) defends the in-RAM master key. Hardware-bound key derivation (TPM-released-only-while-PCRs-stable) would close more of the gap; the TPM in Windows article in this series covers TPM-bound primitives that approximate this property.

Every one of these is a design gap -- a property the architecture would need a new primitive to satisfy. None is on Microsoft's announced roadmap. The architecture we have is the architecture we will have for at least the next five years; the practitioner's job is to know which ceilings their estate is exposed to and how to detect each of them.

12. Practical Guide and Closing

The four-audience guide for the 2026 practitioner.

12.1 For a developer

Use CryptProtectData / CryptUnprotectData [@ms-cryptprotectdata] for per-user-on-this-device secrets. Pass pOptionalEntropy to bind the blob to a per-application secret -- but understand it is security-by-obscurity, not a code-identity check; any reader of the SharpDPAPI source [@sharpdpapi-readme] who knows your constant entropy can reproduce the unprotect call as the user.

Use NCryptProtectSecret [@ms-ncryptprotectsecret] with the appropriate descriptor for cross-device or multi-principal cases. LOCAL=user mirrors classic DPAPI on a single machine. SID=<group-sid> reaches AD groups via KDS. CERTIFICATE=HashID:<sha1> reaches a named certificate (TPM-backed for the high-security case). Use the WebAuthn / FIDO2 path for authentication secrets; do not store passwords in DPAPI when WHfB / passkey paths are available.

{` // Returns the appropriate DPAPI-NG protection-descriptor string for a use case. // Reference: learn.microsoft.com windows win32 seccng protection-descriptors function descriptorFor(useCase, ctx) { switch (useCase) { case "single-device-single-user": return "LOCAL=user";

case "ad-group":
  // Multiple machines, AD-authorized group members can decrypt.
  return "SID=" + ctx.groupSid;

case "tpm-backed-cert":
  // Decrypter must hold the named certificate's private key (TPM-bound KSP).
  return "CERTIFICATE=HashID:" + ctx.certThumbprintSha1;

case "web-credential":
  // Resolves through the Windows credential broker.
  return "WEBCREDENTIALS=" + ctx.credName;

default:
  throw new Error("Unknown use case: " + useCase);

} }

console.log(descriptorFor("single-device-single-user")); console.log(descriptorFor("ad-group", { groupSid: "S-1-5-21-...-5101" })); `}

Note: The pOptionalEntropy parameter to CryptProtectData lets you tag a blob with an extra secret the unwrap call must supply. It does not bind the blob to a process or a publisher. If your "entropy" is a constant compiled into your binary, every reverse-engineer who reads the binary can reproduce your unprotect call as the user. For real per-application separation today, use the Chromium 2024 pattern [@thn-app-bound]: wrap your DPAPI / DPAPI-NG blob in a SYSTEM-elevated COM service that enforces a per-binary identity check.

12.2 For a defender or DFIR analyst

Triage the credential-vault inventory in §5 first. The high-value paths are %APPDATA%\Microsoft\Protect\<SID>\, %APPDATA%\Microsoft\Protect\CREDHIST, %APPDATA%\Microsoft\Credentials\, %LOCALAPPDATA%\Microsoft\Vault\, the Chromium / Edge profile databases, and the AD CN=Master Root Keys,... container.

The SACL guidance from the GoldenGMSA repository [@goldengmsa-repo] is the only detective control today: "configure a SACL on the KDS root key objects for everyone reading the msKds-RootKeyData attribute. Once the system access control list (SACL) is configured, any attempt to dump the key data of a KDS root key will generate security event 4662 on the DC where the object type is msKds-ProvRootKey and the account name is not a DC." Plus the cross-trust SACL on msDS-ManagedPasswordId with property GUID {0e78295a-c6d3-0a40-b491-d62251ffa0a6}.

Tooling: Mimikatz [@mimikatz-dpapi-wiki] dpapi::* modules, SharpDPAPI [@sharpdpapi-readme], DPAPIck [@bursztein-talk-page] (Bursztein-Picod 2010), GoldenGMSA [@goldengmsa-repo], GoldenDMSA [@goldendmsa-repo], and the Volatility [@volatility3-repo] lsadump / cachedump / hashdump plugins for live-memory extraction of DPAPI_SYSTEM and the other LSA secrets that seed SYSTEM-context master-key derivation.

Walk a synthetic profile-directory layout and emit a DPAPI-relevant triage report.

import os from collections import defaultdict

Synthetic profile layout for demonstration only.

synthetic = { "Users/alice/AppData/Roaming/Microsoft/Protect/S-1-5-21-1234-1001/Preferred": "8KB", "Users/alice/AppData/Roaming/Microsoft/Protect/S-1-5-21-1234-1001/0d4a...": "740B", "Users/alice/AppData/Roaming/Microsoft/Protect/CREDHIST": "176B", "Users/alice/AppData/Roaming/Microsoft/Credentials/abcdef...": "300B", "Users/alice/AppData/Local/Microsoft/Vault/4BF4C442-9B8A-41A0-B380-DD4A704DDB28/Policy.vpol": "180B", "Users/alice/AppData/Local/Google/Chrome/User Data/Default/Cookies": "4MB", "Users/alice/AppData/Local/Google/Chrome/User Data/Local State": "12KB", }

categories = { "Master keys": "/Microsoft/Protect/S-1-", "CREDHIST chain": "/Protect/CREDHIST", "Credential Manager": "/Microsoft/Credentials/", "Windows Vault": "/Microsoft/Vault/", "Chrome state key": "/Google/Chrome/User Data/Local State", "Chrome cookies": "/Google/Chrome/User Data/Default/Cookies", }

report = defaultdict(list) for path, size in synthetic.items(): for label, marker in categories.items(): if marker in path: report[label].append((path, size))

for label, items in report.items(): print("==", label) for path, size in items: print(" ", path, "(" + size + ")") `}

12.3 For a red-team operator

The chain of primitives most-commonly used (verbatim from the harmj0y operational guide [@harmj0y-operational-guide] and the Mimikatz wiki [@mimikatz-dpapi-wiki]):

The operational vocabulary, in order of dependency:

mimikatz "sekurlsa::dpapi" -- enumerate cached master keys from a live lsass.exe.
mimikatz "dpapi::masterkey /in:<MK> /sid:<SID> /password:<known>" -- unwrap a master-key file.
mimikatz "dpapi::cred /in:<credfile>" -- decrypt a Credential Manager entry.
mimikatz "lsadump::backupkeys /system:dc.contoso.local /export" -- export the [MS-BKRP] RSA private key from a writable DC.
SharpDPAPI triage /pvk:key.pvk -- offline triage with the domain backup key.
SharpChrome cookies /pvk:key.pvk -- decrypt Chrome / Edge cookies offline.
GoldenGMSA gmsainfo then GoldenGMSA compute -k <root-key-guid> -s <gmsa-sid> -m <managed-password-id> -- offline gMSA password derivation per the March 2022 disclosure [@semperis-golden-gmsa].
GoldenDMSA wordlist / bruteforce / compute -- the four-phase Server 2025 dMSA pipeline per the July 2025 disclosure [@semperis-golden-dmsa].

The post-Credential-Guard scope reality: LSASS-isolated NT-hashes are gone (the Credential Guard article in this series covers what LsaIso.exe actually computes); on-disk DPAPI master keys, Chrome cookies, and Vault credentials are still there. The credential-vault inventory in §5 is the operator's map; the §10 disclosure list is the operator's playbook.

12.4 For a platform or identity engineer

Provision the KDS root key carefully. Use the Add-KdsRootKey [@ms-add-kdsrootkey] default 10-day EffectiveTime for production forests so AD replication converges before any consumer derives against the new key; the -EffectiveTime ((Get-Date).AddHours(-10)) override is for single-DC test forests only, never production.

Note: The Golden gMSA defensive answer is detective, not preventive. Configure the msKds-RootKeyData SACL before any production gMSA exists, so every read of the root-key attributes generates Security Event 4662 and you have a baseline of "DC accounts only, no humans, ever." Add the msDS-ManagedPasswordId cross-trust audit on day 1 too. After-the-fact SACL provisioning leaves a window during which the key may have been read silently.

For Server 2025 dMSA, monitor the msDS-ManagedPasswordId [@ms-ms-adts-managedpassword] brute-force surface until Microsoft addresses the time-component predictability the Golden dMSA disclosure [@semperis-golden-dmsa] named.

For Hello for Business, prefer the TPM-bound KSP (MS_PLATFORM_CRYPTO_PROVIDER); the software-KSP DPAPI-NG fallback [@ms-whfb-howitworks] is the structural worst case (per §8.3) and inherits the KDS root-key dependency on every TPM-less device.

Cross-platform context: Apple Keychain [@apple-platform-security-keychain] reaches a stronger upper bound (Secure-Enclave-bound + code-identity-pinned via the Apple Developer Program); GNOME libsecret [@libsecret-reference] covers the analogous Linux primitive over the Secret Service D-Bus interface. Neither is a drop-in replacement; both have shapes worth borrowing if Microsoft ever publishes the Generation-4 design.

12.5 The closing reflection

The credential vault under everything has a single-sentence summary in 2026: classic DPAPI is as strong as the user's password; DPAPI-NG is as strong as the KDS root key's life-cycle SOP is; both architectures admit ceilings the cryptography cannot move. The literacy a practitioner needs is the ability to recognise which ceiling any new incident hits. Twelve sections later, you have it.

Frequently Asked Questions

No. Credential Guard [@ms-credential-guard] protects LSA-isolated secrets only. Chrome cookies live in the user's profile under DPAPI / DPAPI-NG and are decryptable by any process running as the user, exactly as before. The Chromium 2024 app-bound encryption [@thn-app-bound] is a per-process workaround for the §9.1 user-context ceiling, not a fix inside DPAPI itself. A web reset of a *consumer* Microsoft Account password does not append to CREDHIST and does not benefit from [`[MS-BKRP]`](https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-bkrp/) backup -- there is no domain in the consumer scenario. Master keys encrypted under the previous password become irrecoverable for consumer Microsoft Accounts, full stop. Domain-joined enterprise users escape this because the domain backup key still works. True if the KDS root key [@ms-add-kdsrootkey] is intact -- the Semperis write-up [@semperis-golden-gmsa] records the *"randomly generated password of 256 bytes, making it infeasible to crack"* claim. False under the Golden gMSA / Golden dMSA [@semperis-golden-dmsa] assumption that any DA / SYSTEM on a DC can read `msKds-RootKeyData`. A 256-byte random password is irrelevant if the attacker can derive it offline. No. DPAPI-NG [@ms-cng-dpapi] is a redesign whose protection model is *descriptor-based* (multi-principal, multi-device) rather than *user-and-machine-bound*. The two APIs coexist; classic DPAPI is still the default for `CryptProtectData` [@ms-cryptprotectdata] callers, and DPAPI-NG is the path for `NCryptProtectSecret` [@ms-ncryptprotectsecret] callers. No. On TPM-less devices the WHfB private key sits in a CNG software-KSP container persisted as a DPAPI-NG blob whose protection descriptor binds it to user SID + device, per the Hello for Business architecture [@ms-whfb-howitworks]. The TPM-bound case is the preferred deployment; the software-KSP fallback is the structural worst case and inherits the §9.3 KDS root-key dependency. No. `CryptProtectMemory` [@ms-cryptprotectmemory] scrubs in-memory secrets between same-process / cross-process / cross-session lifetimes but cannot prevent the OS from writing the page-protected RAM into `hiberfil.sys` on suspend-to-disk. BitLocker on the system volume is the structural defence (the *BitLocker on Windows* article in this series covers full-volume encryption end-to-end). No. It broke the *secrecy of DPAPI's design*. The 2010 disclosure [@usenix-woot10] made the master-key chain public and tractable for offline forensics; it did not weaken the cryptography. The "break" was always structural -- DPAPI is as strong as the user's password is. The two-author byline is Bursztein and Picod (Black Hat DC 2010, USENIX WOOT 10), not "Bursztein, Picod and Aussel."

<StudyGuide slug="dpapi-and-dpapi-ng-the-credential-vault-under-everything" keyTerms={[ { term: "DPAPI", definition: "The Data Protection API; the per-user / per-machine secret-storage primitive in every Windows release from Windows 2000 onward." }, { term: "Master key", definition: "A 64-byte random secret per user, stored under %APPDATA%/Microsoft/Protect/<SID>/<GUID>, encrypted under a pre-key derived from the user's password and SID." }, { term: "[MS-BKRP] BackupKey Remote Protocol", definition: "The LSASS-hosted RPC interface that lets a member computer dual-wrap its master key under both the user password pre-key and a DC RSA backup public key; the canonical universal-decryption primitive available to Domain Admins." }, { term: "CREDHIST", definition: "The previous-password hash chain stored in %APPDATA%/Microsoft/Protect/CREDHIST; one entry per self-initiated password change; broken by administrative reset and consumer-Microsoft-Account web reset." }, { term: "Protection descriptor (DPAPI-NG)", definition: "The DPAPI-NG self-describing string (SID, SDDL, LOCAL, WEBCREDENTIALS, CERTIFICATE) that names the set of principals permitted to remove protection from a blob." }, { term: "Microsoft Key Distribution Service (kdssvc.dll)", definition: "The DC-side daemon that implements the [MS-GKDI] protocol and computes per-(group, period) keys deterministically from a single forest-wide root key." }, { term: "KDS root key", definition: "The single forest-wide secret that anchors every per-(group, period) key the KDS will ever derive; provisioned exactly once per forest with Add-KdsRootKey; documented as having no rotation procedure." }, { term: "Group Managed Service Account (gMSA)", definition: "A Server-2012-introduced AD account whose 256-byte password is derived from the KDS chain and rotated every 30 days, gated by the msDS-GroupMSAMembership SDDL." }, { term: "Software KSP", definition: "The non-hardware-bound CNG Key Storage Provider that persists key material as DPAPI-NG-protected files; used as the WHfB fallback on TPM-less devices." }, { term: "Golden gMSA / Golden dMSA", definition: "The 2022 / 2025 Semperis offline-derivation attacks that compute any gMSA / dMSA password the forest will ever issue, given a one-shot read of the four KDS root-key attributes." } ]} />

The Empty Hash: Credential Guard, the LsaIso Trustlet, and the Eleven-Year LSASS Extraction Tradition

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

**Credential Guard moves the long-lived NTLM hash and the Kerberos long-term key out of `lsass.exe` (in the VTL0 NT kernel) and into `LsaIso.exe` (in VTL1, behind the hypervisor).** The hash is no longer in the dump because the hash is no longer in the process. Default-on for domain-joined, non-domain-controller Windows 11 22H2+ and Windows Server 2025 systems that meet the hardware requirements [@ms-cg-overview]. The architecture closes the eleven-year LSASS-memory-dump class. It does not close credential **use** (Kerberoast [@attack-kerberoast]), token impersonation (the PrintSpoofer / Potato chain [@itm4n-printspoofer]), plaintext-secret protocols [@ms-cg-considerations] (NTLMv1, MS-CHAPv2, Digest, CredSSP), or the trustlet's own RPC output (Pass-the-Challenge, December 2022 [@lyak-passchallenge-wayback]). This is the deep look at the canonical VBS trustlet -- the encrypted-blob fields, the IUM API surface, the five residual attack classes, and Microsoft's own honest accounting of what Credential Guard was never going to protect.

1. The 3:14 a.m. Mimikatz that returned an empty hash

It is 3:14 a.m. on a 2026 Windows 11 24H2 box. The operator has SYSTEM. The operator has SeDebugPrivilege. The operator has bypassed Protected Process Light the way PPLdump [@github-ppldump] did in 2021, has dumped lsass.exe with sekurlsa::logonpasswords from Mimikatz [@github-mimikatz], and is staring at the screen.

For the nine years before mid-2015, the next line on that screen would have been the user's NTLM hash. Tonight, the next line is something else entirely.

Note: msv : [00000003] Primary * Username : alice * Domain : CONTOSO * NTLM : [LSA Isolated Data] Is NT Present: True Context Handle: 0x1b6d5216c60 Proxy Info: 0x7ffdd8bfd380 Encrypted blob: a000000000000000080000006400000001000000010100000100000036...4e746c6d48617368... DPAPI: c02c86e371103ad7d7d352b19af1a74a00000000 Structurally identical to the PassTheChallenge README [@github-passthechallenge] example, with username and domain renamed for narrative clarity. Hex prefix, field names, and embedded NtlmHash ASCII tag are verbatim. This is the artefact that tells the operator the architectural shift happened.

The literal string [LSA Isolated Data] sits where the NTLM hash used to sit. The hex prefix a000000000000000 is the same prefix on every Credential-Guard-protected box on the planet. The trailing ASCII tag 4e746c6d48617368 decodes to NtlmHash: the field name survives, the value does not.

This article is the deep look at the canonical VBS trustlet that is responsible for that empty hash. It is the companion piece to the broader VBS trustlets treatment in this series [@paragmali-com-secure-kernel], which uses LsaIso.exe as its running example without unfolding the four things that matter most about it: the eleven-year extraction history that motivated the design; what LsaIso.exe actually computes and what every field of the encrypted blob means; Pass-the-Challenge -- the residual class Credential Guard was never going to close; and the honest, Microsoft-documented limits [@ms-cg-howitworks], enumerated.

A note on intent and verification: this is defensive research. Every primary source was verified live on 2026-05-11, against the public web; every command and tool named is in the open-source security canon, used today by Microsoft's own product teams, by enterprise red teams, and by every blue team that takes the storage-versus-use distinction seriously.

The hash is not in the dump because the hash is no longer in the process. Where it went, and why Microsoft moved it, is twenty-two years of lsass.exe history.

2. Why LSASS became the single highest-value memory dump on Windows (1993--2014)

Twenty-two years before the empty hash, lsass.exe shipped in Windows NT 3.1. It was not, at first, the most-attacked process on Windows. It became that, slowly, over the course of eleven years and one tool. This is the tradition the trustlet was built to break.

The user-mode Windows service that handles interactive logon, NTLM challenge-response, Kerberos AS/TGS exchanges, security-policy enforcement, password changes, and the loading of every Security Support Provider DLL the system uses for authentication. Until Credential Guard, it also held every long-lived authentication secret for every signed-in user in its own process memory, because the protocols it implemented required the secret to be present when the network talked to it. See the canonical LSA Authentication [@ms-lsa-authentication] reference.

The architectural reason lsass.exe had to hold the secret is structural to the protocols it speaks. NTLM [@paragmali-com-in-windows] and Kerberos are challenge-response protocols. The server sends a challenge; the client encrypts the challenge with a key derived from the password; the server compares. The key the client uses is not the password itself but the NT one-way function output (NTOWF) [@wiki-pth] -- the MD4 of the UTF-16-LE password. For Kerberos the client uses a long-term key (DES, RC4, or AES) derived from the password under a protocol-defined string-to-key function [@en-wikipedia-org-wiki-kerberosprotocol]). In both cases the server expects the client to prove possession of a value that is functionally equivalent to the password, every time the client authenticates.

The MD4 hash of the UTF-16-LE encoded password. Despite the name, NTOWF is one-way only with respect to the original password. With respect to the network, the NTOWF *is* the credential: any process that holds it can compute the response to any NTLM challenge any server will ever issue, with no further information about the user.

For single-sign-on to work -- the user types the password once, the OS uses it transparently for every later authentication that day -- something has to remember that derived value, in clear, in a process that wakes up whenever a remote service asks the kernel to authenticate. That something is lsass.exe. Until 2015, "remembers" meant "holds the bytes in process memory."The phrase "the hash is the password" is not a metaphor. The NTLM challenge-response computation DESL(NTOWF, challenge) (three separate DES encryptions on 7-byte key segments per MS-NLMP section 3.3.1) accepts the NTOWF directly. An attacker who holds the NTOWF and can reach a server that speaks NTLM does not need to know the password at all. This is the structural reason Pass-the-Hash works on every NTLM-speaking service in the network.

The eight inflection points

In 1997, Paul Ashton published the original Pass-the-Hash technique on Bugtraq [@wiki-pth] -- a modified Samba SMB client that accepted user password hashes instead of cleartext passwords. The conceptual claim landed: if the client only proves possession of the hash, the hash is the credential. The implementation claim took another eleven years to land.

In 2001, Sir Dystic of Cult of the Dead Cow disclosed SMBRelay at lanta.con on March 31 [@cdc-smbrelay] (not March 21 as some Wikipedia revisions claim, per the project's own page). SMBRelay was the use-class breakthrough: rather than crack the hash, intercept the protocol exchange and let the victim's own client do the cryptography against the attacker's chosen target.

In 2008, Hernan Ochoa shipped the Pass-the-Hash Toolkit [@wiki-pth] -- the load-bearing 2008 contribution -- and introduced "dump the hash from lsass.exe memory" as a public, repeatable post-exploitation technique. The toolkit was later superseded by Windows Credential Editor [@wiki-pth]. For the first time, an attacker did not need to crack anything. The attacker needed OpenProcess(VM_READ) on lsass.exe and a parser.The Pass-the-Hash Toolkit and Windows Credential Editor [@wiki-pth] were the immediate ancestors of Mimikatz. They established the LSASS-process-memory dump as the canonical credential-extraction primitive on Windows; Mimikatz only had to follow the trail and add WDigest plaintext recovery on top.

In May 2011, Benjamin Delpy released Mimikatz, closed-source [@wired-mimikatz], and added one feature on top of WCE that turned the field upside down: sekurlsa::logonpasswords returned not just NTLM hashes but plaintext WDigest passwords. WDigest -- a digest-authentication SSP that Microsoft had shipped in Windows XP and Server 2003 to support HTTP digest -- stored the encrypted password blob and the encryption key in lsass.exe memory, simultaneously, so that the SSP could re-derive the digest response on demand. Delpy called the result, accurately, "like storing a password-protected secret in an email with the password in the same email" [@wired-mimikatz].

It's like storing a password-protected secret in an email with the password in the same email. -- Benjamin Delpy, on the WDigest plaintext-cache architecture

In September 2011, Mimikatz was used in the DigiNotar breach [@wiki-diginotar] -- the certificate-authority compromise that issued forged certificates for Google, Microsoft, and Twitter domains, used via MITM against roughly 300,000 Iranian Gmail users [@wiki-diginotar]. Mimikatz crossed from researcher curio to nation-state-grade tradecraft in a single news cycle.Wired's profile [@wired-mimikatz] recounts an early-2012 Positive Hack Days incident in Moscow in which, immediately after Delpy's Mimikatz talk, a man in a dark suit demanded that Delpy put his slides and a copy of Mimikatz on a USB drive. Delpy complied and then -- before leaving Russia -- published the code as open source on GitHub. It is the moment Delpy realised he had built something that nation-state services were now travelling to obtain in person.

On April 6, 2014, at 22:02:03, Delpy committed Mimikatz 2.0 to GitHub as open source [@github-mimikatz]. The compile timestamp is in the README banner, verbatim. Microsoft's lead time on every WDigest-class disclosure dropped from "months" to "the next minute any attacker reads the README."

On May 13, 2014, Microsoft shipped KB2871997 / MSA 2871997 [@ms-kb2871997]. On Windows 8.1 and Server 2012 R2 and later, the registry value WDigest\UseLogonCredential defaults to 0 and WDigest no longer caches plaintext credentials in lsass.exe memory. The plaintext leg closed. The hash leg could not, because the protocol required it.

timeline title LSASS as the highest-value Windows process, 1993-2014 1993 : NT 3.1 ships : lsass.exe holds NTOWF + Kerberos keys 1997 : Paul Ashton : Pass-the-Hash on Bugtraq 2001 : Sir Dystic : SMBRelay at lanta.con 2008 : Hernan Ochoa : Pass-the-Hash Toolkit (later WCE) 2011 : Benjamin Delpy : Mimikatz closed-source release (May) 2011 : DigiNotar breach : Mimikatz used in the wild (September) 2014 : Mimikatz 2.0 : GitHub open-source (April 6, 22:02:03) 2014 : KB2871997 : WDigest cache disabled by default (May 13) The class of attack in which an authenticated client proves possession of an NTOWF (the NT one-way function output, MD4 of the UTF-16-LE password) directly, without ever knowing the cleartext password. The technique was originally published by Paul Ashton in 1997 [@wiki-pth] and was made native to Windows by Hernan Ochoa's 2008 Pass-the-Hash Toolkit [@wiki-pth]. It is structural to the NTLM protocol; closing the class requires either eliminating the protocol or moving the hash out of any process the attacker can read.

By May 2014, Microsoft had patched what could be patched. Mimikatz 2.0 was on GitHub. The hash was still in the process, because it had to be. The next move had to be architectural. But before Microsoft made that move, they tried four other things.

3. What Microsoft tried before trustlets (2007--2014)

If you cannot move the secret, what can you do? Microsoft tried four answers between 2007 and 2014. Each is in production today. None of them moves the secret.

Generation 2: Vista's Protected Process (2007)

In Windows Vista, Microsoft introduced the Protected Process [@ionescu-bh2015-pdf] primitive: a binary signed under a designated Microsoft media-protection certificate could run in a process whose memory other Windows processes -- including processes running as administrator -- could not read or modify. The reason was DRM. Audio and video pipelines wanted a way to keep AACS and PlayReady decryption keys out of debuggers. The Protected Process primitive was not, in 2007, applied to lsass.exe. Six years passed before Microsoft generalised it.

Generation 3: LSA Protection / `RunAsPPL` (2013)

In Windows 8.1, Microsoft generalised Protected Process into Protected Process Light (PPL) [@itm4n-runasppl], a signer-level lattice that allowed multiple signer "kinds" to live alongside the original DRM kind, and the RunAsPPL registry value lit up lsass.exe as a PPL [@paragmali-com-app-ide].

A Windows process that runs at a signer-level higher than ordinary administrator processes, such that ordinary administrators cannot open it for memory read or for code injection. Created in Windows 8.1 as a generalisation of the Vista Protected Process primitive. Enforcement is done by the NT kernel: `OpenProcess` with `PROCESS_VM_READ` from a non-PPL caller returns `ERROR_ACCESS_DENIED` (0x5) [@itm4n-runasppl] regardless of the caller's token privileges.

itm4n's reference write-up of RunAsPPL [@itm4n-runasppl] reproduces what Mimikatz sees on a PPL-protected lsass.exe: the call to OpenProcess(PROCESS_VM_READ | PROCESS_QUERY_INFORMATION, FALSE, lsass_pid) -- the verbatim opener of kuhl_m_sekurlsa_acquireLSA() -- fails with 0x00000005, ERROR_ACCESS_DENIED. The hash extraction routine never runs, because the attacker cannot read the page.

itm4n's writeup is also the canonical source for what RunAsPPL is not. The same NT kernel that enforces PPL is the kernel the attacker is trying to subvert. Two bypass classes exist in the public record. The first is kernel-mode: an attacker who loads a signed driver -- including Delpy's own mimidrv.sys [@itm4n-runasppl] -- can suspend PPL enforcement from kernel-space because the kernel is the enforcement mechanism. This is the bring your own vulnerable driver bypass class.

A privilege-escalation pattern in which an attacker with administrator privilege loads a signed-but-vulnerable third-party driver, then exploits a known vulnerability in the driver to run arbitrary code at kernel mode. Because the driver is signed, the kernel loads it; because the kernel loaded the driver, the driver can disable any defence the kernel enforces, including PPL. Microsoft's recommended vulnerable-driver block-list shrinks the BYOVD inventory; it does not eliminate the class. Delpy's own `mimidrv.sys` is the canonical reference exploit driver [@itm4n-runasppl] for this class against `lsass.exe`.

The second is userland: itm4n's PPLdump (April 2021) [@github-ppldump] exploited a structural weakness in the PPL section-validation logic. A new Windows process loads NTDLL, then asks the image loader to load other DLLs. PPLs are allowed to load DLLs from the \KnownDlls directory, and -- crucially -- the digital signature of a \KnownDlls entry is checked when the section is created, not when it is mapped into the address space of a PPL process. PPLdump used DefineDosDevice to swap the symbolic link of a \KnownDlls entry, and the PPL lsass.exe mapped the swapped-in attacker DLL into its own address space, with PPL enforcement intact. The SCRT writeup [@blog-scrt-bypass-lsa] is the canonical 2021 reference. Microsoft closed the userland weakness in build 19044.1826, the July 2022 update [@itm4n-end-of-ppldump], with an LdrpInitializeProcess patch in NTDLL gated by a Feature_Servicing_2206c_38427506__private_IsEnabled feature flag. On Windows 8.1 and Server 2012 R2, PPLdump's behaviour is unstable per the project README [@github-ppldump]: itm4n notes the exploit fails on fully updated machines for an unidentified earlier patch. The userland weakness is therefore closed across the modern estate; legacy boxes that have lapsed on cumulative updates remain the practical exposure.itm4n is explicit about the architectural framing: LSA Protection is "a true quick win [@itm4n-runasppl]" because attackers "will have to use some relatively advanced tricks if they want to work around it, which ultimately increases their chance of being detected." But in the same post: "[LSA Protection] tends to be confused with [Credential Guard], which is completely different ... Credential Guard and LSA Protection are actually complementary." That confusion is the most common architectural error in defensive-security reviews of Windows endpoints.

Generation 4: KB2871997 + the compensating-control playbook (2014)

KB2871997 [@ms-kb2871997] shipped on May 13, 2014 and rolled up three behavioural changes: WDigest cache disabled by default in Windows 8.1 / Server 2012 R2 and later (UseLogonCredential = 0); the TokenLeakDetectDelaySecs registry default; and a follow-on October 14, 2014 update that added Restricted Admin mode for Remote Desktop Connection [@ms-kb2871997] on Windows 7 / Server 2008 R2. The same broader 2013--2014 credential-protection initiative also delivered the Protected Users group [@ms-protected-users] (an Active Directory feature shipped in Windows 8.1 [@wiki-win81] / Server 2012 R2 [@wiki-ws2012r2], October 2013). Protected Users is the device-side mitigation: members cannot use credential delegation (CredSSP), Windows Digest, NTLM cached credentials or NTOWFs, DES or RC4 in Kerberos preauthentication, or offline cached verifiers; their TGT lifetime is capped at four hours.

Protected Users membership requires AES-only Kerberos. Estates with legacy applications that rely on RC4 service tickets (a long tail in any healthcare or industrial deployment) cannot enable Protected Users without a forklift modernisation of their Kerberos client and server inventory. This is the practical reason the Protected Users adoption rate, ten years after the feature shipped, sits well below 100% on enterprise estates that have every other 2014-era mitigation enabled.

Generation 4.5: Tier 0 isolation, jump-server architecture, AdminSDHolder hygiene

The Mitigating Pass-the-Hash v1 (2012) and v2 (2014) playbooks [@ms-lsa-protection] layered organisational changes on top of the per-host technical changes: tier the administrative model so that Tier 0 credentials never log on to Tier 1 or Tier 2 hosts; require every Tier 0 administrative session to traverse a dedicated jump server; clean up AdminSDHolder so that orphaned high-privilege accounts cannot be re-used. The playbooks are still cited in 2026 deployment guides because the underlying recommendations remain correct.

flowchart TD G0["Gen 0: NT 3.1 lsass.exe (1993)
NTOWF + Kerberos keys in process memory"] G1["Gen 1: WDigest plaintext cache (XP/2003)
Plaintext + key both in lsass.exe"] G2["Gen 2: Vista Protected Process (2007)
For DRM; not applied to lsass.exe"] G3["Gen 3: LSA Protection / RunAsPPL (2013)
NT-kernel-enforced; mimidrv + PPLdump bypassable"] G4["Gen 4: KB2871997 + Protected Users (2014)
WDigest off; AES-only Kerberos; 4hr TGT"] G5["Gen 5: Credential Guard / LsaIso.exe (2015)
Hypervisor-enforced; NT kernel out of TCB"] G6["Gen 6: Default-on (Win 11 22H2 / Server 2025)
No-UEFI-lock"] G0 --> G1 --> G2 --> G3 --> G4 G4 -->|"NT kernel still in TCB"| G5 G5 --> G6

Key idea: As long as the secret lives in a process whose address space is governed by the same NT kernel that the attacker can compromise, the secret is extractable. Generations 0--4 add layers inside the NT-kernel TCB. The 2014 conclusion -- that you cannot patch your way out of the storage problem -- is structural to that TCB argument; the chain Gen 0 -> Gen 4 above traces it explicitly.

Each of these layers shrinks the attack surface. None of them changes where the hash physically lives. The 2014 conclusion was unavoidable: the only fix is to move the hash out of the kernel that the attacker can compromise. So Microsoft did.

4. Credential Guard lands, then hardens, then defaults on (May 2015 -- November 2024)

On May 4, 2015, Brad Anderson stood at Microsoft Ignite [@ms-brad-ignite-2015] and said "more than 75 percent of all these attacks come down to weak credentials or compromised identities." Eighty-six days later, Windows 10 Enterprise RTM shipped with LsaIso.exe running in VTL1.The 75-percent figure is the verbatim Anderson keynote quote and tracks Microsoft's own internal incident-response telemetry from the 2014--2015 period. The keynote explicitly demonstrates Device Guard at length; the Credential Guard announcement at the same event is corroborated by ITPro Today's same-day recap (Wayback snapshot) [@itprotoday-ignite] and Microsoft's own subsequent blog posts.

The eight-event chronology

On May 4, 2015, the Anderson Ignite keynote announced Virtualization-Based Security, Device Guard, and Credential Guard alongside the Hello and Microsoft Passport identity story. On July 29, 2015, Windows 10 RTM [@ms-cg-overview] shipped with LsaIso.exe as Trustlet ID 1 on Enterprise and Education SKUs. On August 5--6, 2015, Alex Ionescu reverse-engineered the trustlet model at Black Hat USA and published the slide deck [@ionescu-bh2015-pdf] that documents the dual-EKU + Signature Level 12 constraint and names LSAISO.EXE as Trustlet ID 1 verbatim.

Through 2016--2020, Server 2016 brought Credential Guard to server installs [@ms-ws2016-whatsnew], and the VSM master key + TPM 2.0 binding [@ms-cg-howitworks] hardened the persistent-state path.

On September 20, 2022, Windows 11 22H2 became generally available with Credential Guard default-on for domain-joined non-DC hardware-eligible boxes [@ms-cg-overview], shipped without UEFI Lock. On December 26, 2022, Oliver Lyak published Pass-the-Challenge [@lyak-passchallenge-wayback]: the trustlet itself was faithful, but its RPC output became the new attack surface. On November 1, 2024, Windows Server 2025 became generally available and extended the default-on stance to server with the same domain-controller carve-out: "Enabling Credential Guard on domain controllers isn't recommended. Credential Guard doesn't provide any added security to domain controllers, and can cause application compatibility issues on domain controllers." [@ms-cg-overview]

A binary signed at Signature Level 12 with both the Windows System Component Verification EKU (1.3.6.1.4.1.311.10.3.6) and the Isolated User Mode EKU (1.3.6.1.4.1.311.10.3.37), exporting an `s_IumPolicyMetadata` structure from a `.tpolicy` PE section, loaded by the Secure Kernel into VTL1 user mode at boot via `NtCreateUserProcess` with the `PsAttributeSecureProcess` attribute. Documented verbatim in Alex Ionescu's Black Hat USA 2015 deck [@ionescu-bh2015-pdf], which is still the load-bearing reverse-engineering primary on the trustlet model. Two privilege levels enforced by the Hyper-V hypervisor on top of the host CPU's existing ring 0 / ring 3 split. VTL0 is the Normal World: Ring 3 user mode and Ring 0 NT kernel mode. VTL1 is the Secure World: Ring 3 user mode runs trustlets like `LsaIso.exe`, Ring 0 runs the Secure Kernel (`securekernel.exe`). The hypervisor uses Second-Level Address Translation (SLAT) to ensure VTL0 page tables cannot map physical pages that VTL1 has marked private. The Hypervisor TLFS Virtual Secure Mode reference [@ms-tlfs-vsm] defines `#define HV_NUM_VTLS 2` and notes that "Architecturally, up to 16 levels of VTLs are supported; however a hypervisor may choose to implement fewer than 16 VTLs. Currently, only two VTLs are implemented." The Ring-3 user mode component of VTL1. IUM hosts trustlets (signed user-mode binaries) that the Secure Kernel loads at boot. IUM processes have no device drivers, no third-party modules, and no normal-world IPC except via the explicitly-marshalled secure-call interface that the Secure Kernel mediates. Quarkslab's IUM debugging walkthrough [@quarkslab-falcon-ium] names "the isolated version of LSASS (`LSAIso.exe`) when Credential Guard is enabled" as the canonical IUM example.

The four shipping trustlets per Ionescu's 2015 reverse-engineering [@ionescu-bh2015-pdf]: Trustlet ID 0 is the Secure Kernel Process (Device Guard); Trustlet ID 1 is LSAISO.EXE (Credential Guard); Trustlet ID 2 is vmsp.exe (the Hyper-V virtual TPM host side); Trustlet ID 3 is the vTPM provisioning trustlet. Eleven years later, that list is still exactly four, with ID 1 still the most-discussed.

Every domain-joined Windows 11 box ships with LsaIso.exe running today. What that small binary actually is, what it computes, and what an attacker who has SYSTEM on the box now sees is the load-bearing technical question of the next section.

5. What `LsaIso.exe` actually is

The trustlet is a small binary that sits inside a separate kernel from the one your shell is running under. Its identity is precise, its API is small, and its memory is unreadable from the side of the boundary you are on. Microsoft's documentation gives the one-sentence shape:

With Credential Guard enabled, the LSA process in the operating system talks to a component called the isolated LSA process that stores and protects those secrets, LSAIso.exe. Data stored by the isolated LSA process is protected using VBS and isn't accessible to the rest of the operating system. -- Microsoft Learn, *How Credential Guard works* [@ms-cg-howitworks]

That sentence hides everything interesting. The next six subsections unfold it.

5.1 Identity in the trustlet model

LsaIso.exe passes the five-gate trustlet definition [@ionescu-bh2015-pdf] by construction: Trustlet ID 1; signed at Signature Level 12; carries both the Windows System Component Verification EKU (1.3.6.1.4.1.311.10.3.6) and the Isolated User Mode EKU (1.3.6.1.4.1.311.10.3.37); exports the s_IumPolicyMetadata structure from a .tpolicy PE section; and is loaded by SMSS / wininit at boot through NtCreateUserProcess with the PsAttributeSecureProcess attribute, which routes through the Secure Kernel [@paragmali-com-the-en] rather than the NT kernel.

An Extended Key Usage object identifier embedded in an Authenticode signature that constrains what the signed binary is allowed to do. The Windows kernel and Secure Kernel inspect EKUs at load time. The dual-EKU requirement on trustlets means a signature legitimate for ordinary kernel-mode driver loading is *not* sufficient to load a binary as a trustlet; both the WSCV and the IUM EKU must be present, both signed by Microsoft.

The two EKUs together are the identity gate. A binary that has only the WSCV EKU is a normal Microsoft-signed component.The IUM EKU is not a publicly issuable Authenticode EKU; only Microsoft can mint it -- per the Trustlet identity model documented verbatim in Ionescu's Black Hat USA 2015 deck [@ionescu-bh2015-pdf]. A binary that has only the IUM EKU does not exist in the wild. A binary that has both, and is signed by Microsoft, is admissible as a trustlet. The IUM EKU is not issued by any commercial CA; it is a Microsoft-internal OID with a Microsoft-internal issuance policy.

5.2 The agent / trustlet split

Credential Guard splits lsass.exe (the historical agent) into two cooperating processes:

lsass.exe in VTL0 holds protocol state, network I/O, and every Security Support Provider DLL the system loads: msv1_0.dll (NTLM), kerberos.dll (Kerberos), negoexts.dll (SPNEGO extensions), cloudap.dll (the Microsoft Entra cloud authentication package), wdigest.dll (Digest, with caching disabled), tspkg.dll (Terminal Services / CredSSP), livessp.dll (Microsoft account / Live), pku2u.dll (peer-to-peer Kerberos), and schannel.dll (TLS). The core SSP/AP set (Negotiate, Kerberos, NTLM, Digest, CredSSP, Schannel) is enumerated in Microsoft's SSP Packages Provided by Microsoft [@ms-ssp-packages] reference; CloudAP, NegoExts, TSPkg, LiveSSP, and PKU2U are documented under the broader LSA Authentication [@ms-lsa-authentication] reference. lsass.exe does not hold the long-lived NTOWF or Kerberos long-term keys.
LsaIso.exe in VTL1 holds NTLM hashes and Kerberos TGTs, plus a small fixed RPC API that lets the agent compute responses against those secrets without ever exposing them.

flowchart LR subgraph VTL0NT["VTL0 -- NT kernel governs the entire user-mode process space"] L["lsass.exe
NTOWF, Kerberos keys,
SSP DLLs, network I/O"] M["mimikatz
SeDebugPrivilege"] end M -->|"OpenProcess(VM_READ) + memory dump"| L flowchart LR subgraph V0["VTL0 (Normal World)"] L["lsass.exe
SSP DLLs, network I/O,
protocol state
(NO long-term key)"] M["mimikatz
SeDebugPrivilege"] end subgraph V1["VTL1 (Secure World)"] I["LsaIso.exe
NTOWF + Kerberos keys"] SK["securekernel.exe
(secure kernel)"] end M -->|"OpenProcess(VM_READ)"| L L -->|"LSA_ISO_RPC_SERVER ALPC
NtlmIumCalculateNtResponse(...)"| SK SK -->|"validated secure call"| I I -->|"derived response"| SK SK -->|"return value"| L

The architectural pivot is that the mimikatz-style memory dump still reaches lsass.exe, but it no longer reaches the long-term key. The key has moved across a boundary the hypervisor [@paragmali-com-a-security] enforces with hardware page-table-permission bits, and no VTL0 process -- regardless of token, regardless of privilege -- can map the page.

5.3 The encrypted-blob format and the IUM API

The visible artefact of the move is the [LSA Isolated Data] block in the Pypykatz dump from §1. The structure of that block is documented byte-by-byte in the PassTheChallenge README [@github-passthechallenge]: an opaque encrypted payload, a Context Handle (an opaque RPC handle that identifies the per-logon session inside the trustlet), a Proxy Info field that points to the protocol-side session metadata in lsass.exe, and a DPAPI GUID that ties the encrypted blob to the per-user DPAPI master-key chain.

The Windows API for protecting per-user secrets at rest. The DPAPI master-key chain is keyed off the user's password (or NTOWF for Pass-the-Hash-resistant variants), and is the canonical persistence layer for credentials and certificates that need to survive process restarts. In the Credential Guard architecture, the per-user DPAPI keys are themselves derived from material the trustlet has access to; the GUID in the `[LSA Isolated Data]` block links the in-memory trustlet record to the on-disk DPAPI chain.

The four IUM-side methods that matter for NTLM authentication, as documented by Lyak's Pass-the-Challenge writeup [@lyak-passchallenge-wayback]:

EncryptData / DecryptData: the trustlet's general-purpose AES-GCM wrap and unwrap on opaque blobs, used by every other Credential Guard code path that needs to round-trip a secret through lsass.exe memory without lsass.exe ever seeing the cleartext.
NtlmIumProtectCredential: the trustlet entry point that converts an NTOWF supplied by lsass.exe immediately after a logon (when the user typed the password and msv1_0.dll derived the NTOWF in VTL0 memory) into the isolated form. After this call returns, the only copy of the NTOWF that survives is inside the trustlet.
NtlmIumCalculateNtResponse: the trustlet entry point that computes an NTLMv1 response from the protected NTOWF and a server-supplied challenge. This is the function that gets called every time the user authenticates to an SMB share, an MS-SQL server, an Exchange front-end, or any other NTLM endpoint.
NtlmIumLm20GetNtlm3ChallengeResponse: the equivalent for NTLMv2.

The Pypykatz fork output structure carries the exact byte layout for all of this: Is NT Present, Context Handle, Proxy Info, Encrypted blob, DPAPI. The verbatim hex prefix a000000000000000080000006400000001000000010100000100000036 is a length-prefixed serialisation header. The literal string 4e746c6d48617368 -- which decodes from hex to the ASCII string NtlmHash -- is the field-name tag inside the ciphertext. The ciphertext itself is the AES-GCM-wrapped NTOWF; the tag tells you what the cleartext used to be called.The fact that the field-name tag survives the wrap is not a bug. AES-GCM is an authenticated cipher; by construction, its tag is a MAC over the ciphertext, not an obfuscation primitive over the plaintext. The serialiser includes the field name in the structure so that the trustlet can correctly route the request when the agent calls back. The name tag is your verifiable "the encrypted blob really is the hash" artefact.

{` // The verbatim hex prefix from the PassTheChallenge README dump example. // (Full blob is longer; this prefix is the load-bearing identifying header.) const blobPrefix = 'a000000000000000080000006400000001000000010100000100000036';

// Inferred field decomposition from the byte pattern of the verbatim // PassTheChallenge README dump example. The README documents the hex-dump // shape and the embedded NtlmHash ASCII tag, but does not name the per-byte // fields; the decomposition below is illustrative. // [ProtectionLevel | StructLen | Version | Cipher | TagLen | EncryptedPayload] // The encrypted payload itself contains an embedded ASCII tag identifying // the field that was wrapped.

const fields = parseHeader(blobPrefix); console.log('ProtectionLevel:', '0x' + fields.protectionLevel.toString(16)); console.log('Version :', fields.version); console.log('Cipher :', fields.cipher === 1 ? 'AES-GCM (per spec)' : 'unknown'); console.log('TagLen :', fields.tagLen);

// The literal '4e746c6d48617368' (= ASCII 'NtlmHash') sits inside the ciphertext // further into the blob. Its presence is the verifiable 'this really is the hash' // signal in the PassTheChallenge dumps. const ntlmHashTag = Buffer.from('4e746c6d48617368', 'hex').toString('ascii'); console.log('Embedded tag :', ntlmHashTag); // -> 'NtlmHash' `}

5.4 The `LSA_ISO_RPC_SERVER` ALPC port

The agent reaches the trustlet through a single secure-call endpoint named LSA_ISO_RPC_SERVER (terminology per Lyak's writeup [@lyak-passchallenge-wayback]). The marshalling layer is the IUM Base API. The actual VTL boundary crossing is a hypercall: when a VTL0 thread invokes the secure call, the hypervisor switches the CPU to VTL1, the Secure Kernel inspects the call ordinal, copies the input buffer across the boundary into a VTL1-owned page, and dispatches to the trustlet's entry point. The reverse path mirrors that step for the return value.

The undocumented Windows IPC primitive that succeeds the older LPC. ALPC ports support multiple message-passing modes, fast handles, and direct shared-memory regions. In Credential Guard, the agent talks to the trustlet via an ALPC port whose server side is implemented inside the Secure Kernel, so that the IPC delivery path itself crosses the VTL boundary without exposing any VTL1 memory to VTL0. Lyak's Pass-the-Challenge writeup [@lyak-passchallenge-wayback] names the channel verbatim.

This single endpoint is the entire externally-reachable surface of the trustlet. There is no debugger interface, no driver-load path, no shared-memory region, and no second ALPC port. The trustlet's code runs only when the agent calls it, and the agent can only call it through one specific channel that the Secure Kernel mediates.

sequenceDiagram participant SRV as Remote SMB server participant LSASS as "lsass.exe (VTL0 -- msv1_0.dll)" participant SK as "securekernel.exe (VTL1 ring 0)" participant ISO as "LsaIso.exe (VTL1 trustlet)" SRV->>LSASS: NTLM challenge (8-byte server challenge) LSASS->>SK: Secure call: NtlmIumCalculateNtResponse(ctxHandle, challenge) SK->>SK: validate ordinal, copy input across VTL boundary SK->>ISO: dispatch (NTOWF retrieved from sealed in-process state) ISO->>ISO: Three-DES against the isolated NTOWF -- NTLMv1 DESL per MS-NLMP 3.3.1 ISO->>SK: derived 24-byte NTLMv1 response SK->>LSASS: response (no NTOWF returned) LSASS->>SRV: NTLMv1 response on the wire

5.5 The `MSV1_0\IsolatedCredentialsRootSecret` registry sentinel

Microsoft documents one verifiable artefact of default-on Credential Guard activation: the registry value Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\IsolatedCredentialsRootSecret [@ms-cg-overview]. Its presence on a Windows 11 22H2+ Pro / Pro Education box is the evidence that default-on activated the feature. A Pro Edu deployment that does not show this value either has Credential Guard explicitly disabled by policy, or sits on hardware that does not meet the requirements (no IOMMU, Secure Boot off, no virtualization extensions in firmware).

5.6 TPM binding and the VSM master key

Persistent state in Credential Guard is rare. The trustlet does not normally persist the NTOWF or TGT material across reboots; the next user logon re-derives both. When persistence is needed, the data is sealed under what Microsoft calls the VSM master key:

"On recent supported hardware with TPM 2.0, VSM data that is persisted will be protected by a key called the VSM master key, which is protected by device firmware protections. ... The VSM master key is protected by the TPM, ensuring that the key and secrets protected by Credential Guard can only be accessed in a trusted environment." [@ms-cg-howitworks]

A symmetric key, generated and stored only in VTL1, that wraps any persistent state the trustlets need to survive reboots. The VSM master key is itself sealed by the TPM under PCR-bound policy, so an attacker who pulls the disk and reboots into a different OS cannot unseal the VSM master key without also reproducing the platform's pristine measured boot state. See the companion TPM in Windows article [@paragmali-tpm] for the full seal / unseal primitive treatment.

Key idea: Credential Guard removes the NT kernel from the TCB for the long-lived NTOWF and the Kerberos long-term keys, by moving them into a process whose pages no other VTL can map. The trustlet still answers queries about the keys; what changed is who can touch the bytes.

Where the hash physically lives, in 2026, is in pages of LsaIso.exe that the VTL0 NT kernel cannot map. What an attacker on a default-on Credential Guard box actually sees, what the verification surface for defenders is, and what the operational reality looks like in production is the next question.

6. The operational reality of default-on Credential Guard

Default-on means specifics. Specifically: every domain-joined Windows 11 22H2+ Enterprise / Education box that meets the hardware requirements has Virtualization-Based Security up, has LsaIso.exe running, has the registry sentinel at HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\IsolatedCredentialsRootSecret written, and reports "Credential Guard" in the running-services bitmask of Win32_DeviceGuard. Pro and Pro Education boxes are not default-on targets; the special case where a Pro/Pro Edu device previously ran Credential Guard on Enterprise is the one path that lights it up there, and the registry sentinel from §5.5 is precisely how you detect that carry-over case.

Default-on scope and the no-UEFI-lock choice

Microsoft's Credential Guard overview page [@ms-cg-overview] is precise about scope: Windows 11 22H2 and later (Enterprise, Education), Windows Server 2025, domain-joined non-DC, hardware-eligible (Hyper-V Generation 2 VM with IOMMU on virtual hardware; UEFI Secure Boot, virtualization extensions, IOMMU, and TPM 2.0 on physical hardware). Pro and Pro Education hold the licence entitlement only via the Enterprise-to-Pro carry-over case. The default-on policy ships "without UEFI Lock" [@ms-cg-overview], which is a deliberate trade-off."Without UEFI Lock" means an administrator can disable Credential Guard remotely (via Group Policy, Intune, or a registry change) without first sending someone to the box's UEFI menu. The trade-off: an attacker who has already obtained the level of privilege required to write the registry can also undo the same setting. Microsoft chose remote-disable convenience over the in-principle attacker-disable hardening because compatibility incidents -- a rolled-out third-party SSP that breaks under CG -- are an operational reality, and not being able to disable the feature remotely turns an SSP regression into a desk-side support ticket. The overview page [@ms-cg-overview] documents the rationale verbatim.

The three supported verification surfaces

Microsoft's configuration guide [@ms-cg-configure] names three supported ways to verify Credential Guard is running, and explicitly disrecommends a fourth:

msinfo32: opens the System Information UI; the line "Virtualization-based Security Services Running" includes "Credential Guard" when the trustlet is up.
PowerShell Get-CimInstance Win32_DeviceGuard: returns a SecurityServicesRunning array whose values are a bitmask.
WinInit Event ID 13 in the System log: "Credential Guard (LsaIso.exe) was started and will protect LSA credentials." [@ms-cg-configure]

The disrecommended approach is "look for LsaIso.exe in Task Manager." Microsoft's words: "Checking Task Manager if LsaIso.exe is running isn't a recommended method for determining whether Credential Guard is running." [@ms-cg-configure] Task Manager runs in VTL0 and queries an enumeration that an attacker who controls VTL0 can hide; the three supported surfaces all consult the hypervisor or the boot-time event log, neither of which a VTL0 attacker can edit.

Note: Use the supported surfaces, not Task Manager. The PowerShell one-liner is (Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard).SecurityServicesRunning. The returned array contains 1 when Credential Guard is running; 2 denotes Hypervisor-Enforced Code Integrity (HVCI) per the broader Win32_DeviceGuard schema [@learn-microsoft-com-code-integrity]. The corresponding WinInit Event IDs are 13 (Credential Guard started), 14 (configuration loaded), 15 (warning -- secure kernel not running), 16 (failed to launch), and 17 (UEFI configuration error), per the configuration guide [@ms-cg-configure].

{` // Mirrors what (Get-CimInstance Win32_DeviceGuard).SecurityServicesRunning returns. // Microsoft's Win32_DeviceGuard documentation enumerates the values: // 1 = Credential Guard // 2 = Hypervisor-enforced Code Integrity (HVCI / Memory Integrity) // 3 = System Guard Secure Launch // 4 = SMM Firmware Measurement // 5 = Kernel-mode Hardware-enforced Stack Protection // 6 = Kernel-mode Hardware-enforced Stack Protection (Audit mode) // 7 = Hypervisor-Enforced Paging Translation // Note: MBEC (Mode-Based Execution Control) is a CPU capability advertised // in the SEPARATE AvailableSecurityProperties array, not here. const SECURITY_SERVICES = { 1: 'Credential Guard', 2: 'Hypervisor-enforced Code Integrity (HVCI)', 3: 'System Guard Secure Launch', 4: 'SMM Firmware Measurement', 5: 'Kernel-mode Hardware-enforced Stack Protection', 6: 'Kernel-mode Hardware-enforced Stack Protection (Audit mode)', 7: 'Hypervisor-Enforced Paging Translation' };

function describe(running) { if (!running.length) return 'No VBS services running'; return running.map(v => SECURITY_SERVICES[v] || ('Unknown service id ' + v)).join(', '); }

// On a default-on Windows 11 22H2+ domain-joined Pro/Enterprise box this returns: console.log(describe([1, 2])); // => "Credential Guard, Hypervisor-enforced Code Integrity (HVCI)"

// On a Windows 10 box without VBS enabled: console.log(describe([])); // => "No VBS services running" `}

What changes for the protocols

When Credential Guard is enabled, four SSPs lose the ability to use signed-in credentials: "NTLMv1, MS-CHAPv2, Digest, and CredSSP can't use the signed-in credentials" [@ms-cg-howitworks]. For NTLMv1 and Digest the practical effect is small (NTLMv1 is end-of-life [@paragmali-ntlmless]; Digest is essentially unused outside legacy HTTP digest authentication). For MS-CHAPv2 and CredSSP the effect is real: any single-sign-on path that depended on those protocols breaks with Credential Guard on. The considerations page [@ms-cg-considerations] calls out PEAP-MSCHAPv2 / EAP-MSCHAPv2 WiFi and VPN configurations explicitly: "If you're using WiFi and VPN endpoints that are based on MS-CHAPv2, they're subject to similar attacks as for NTLMv1." [@ms-cg-considerations] The recommended remediation is to migrate the endpoints to PEAP-TLS / EAP-TLS (certificate-based authentication).

For Kerberos, Credential Guard "doesn't allow unconstrained Kerberos delegation or DES encryption, not only for signed-in credentials, but also prompted or saved credentials" [@ms-cg-howitworks]. Constrained Delegation and Resource-Based Constrained Delegation continue to work. The remaining Kerberos etype choices on the wire on a Credential Guard box are AES-128 and AES-256.

What doesn't change

The agent surface still exposes every SSP that loads inside lsass.exe. The trustlet isolates the secret the SSP uses; it does not isolate the parser that the SSP runs against an attacker-controlled wire format. A bug in msv1_0.dll's NTLM parser is exactly as exploitable on a 2026 Credential-Guard-on box as it was on a 2015 Credential-Guard-off box. The trustlet does not guard the agent; the trustlet guards the key.

A VBS-based feature that uses the hypervisor's SLAT enforcement to ensure that any kernel-mode page that is executable is also signed and immutable, and any writable kernel-mode page is non-executable. HVCI closes the kernel-driver-loader leg of the BYOVD / PPL bypass class for *unsigned* drivers, but it does not close BYOVD against a signed-but-vulnerable driver. HVCI is orthogonal to Credential Guard; the overview page [@ms-cg-overview] recommends running both.

Credential Guard is on; the surface is documented; the verification is one PowerShell line. So what other things claim to "protect LSASS," and how do they fit together with Credential Guard?

7. The other things that "protect LSASS"

Six other things in the Microsoft security stack get called "LSASS protection" in someone's marketing. None of them is a substitute for Credential Guard. Most of them are complements. The difference matters because the choice between them is not a choice; the answer is all of them, layered.

Feature	Enforcement TCB	Attacker bar to defeat	Residual class it leaves open
LSA Protection (`RunAsPPL`)	NT kernel (signer-level lattice)	Signed kernel driver (BYOVD via `mimidrv.sys` [@itm4n-runasppl]); userland on legacy via PPLdump [@github-ppldump]	Trustlet RPC outputs; non-LSA process credentials
Credential Guard / `LsaIso.exe`	Hypervisor + Secure Kernel + VTL1 trustlet	Hypervisor escape; VTL1 code-execution bug	Pass-the-Challenge [@lyak-passchallenge-wayback]; credential use; tokens; supplied creds
HVCI / Memory Integrity	Hypervisor-enforced kernel page W^X	Signed-and-vulnerable driver that does not load arbitrary unsigned code	Kernel-mode logic bugs in signed drivers
Defender for Identity LSASS read-monitoring [@ms-defender-identity]	Behavioural detection (no TCB)	Stealth tradecraft that does not trip the canonical signatures	Anything not yet patterned
Hello for Business	Per-device TPM-bound asymmetric key (no shared secret on the wire)	TPM compromise; on-device keylogger before sign-in	Not a substitute -- it is what CG protects on cloud-joined boxes
Restricted Admin / Protected Users	Protocol-level credential-delegation suppression	Per-protocol; does not move where the secret lives	Everything Credential Guard already covers, plus the four-hour TGT cap

LSA Protection's kernel-driver-loader bypass class is closed by HVCI for unsigned drivers but not for signed-and-vulnerable ones. Defender for Identity is a detection layer, not a TCB boundary. Hello for Business [@paragmali-com-hellos-hardwar] replaces the password with a TPM-bound asymmetric key [@ms-hello-business]: the Hello for Business overview [@ms-hello-business] row in the Security comparison table reads "It uses key-based or certificate-based authentication. There's no symmetric secret (password) which can be stolen from a server or phished from a user and used remotely." The Microsoft Entra ID Primary Refresh Token (PRT) inside cloudap.dll is the cloud-joined analogue of the on-prem trustlet model: the PRT itself is protected by the trustlet on Credential-Guard-enabled boxes, with Hello as the per-device long-term key chain. Restricted Admin and Protected Users [@ms-protected-users] suppress credential delegation at the protocol layer; on a Credential-Guard-on box they are additionally effective because they remove the prompt path, but they are not a substitute for the storage-isolation primitive.

The structural model differs in interesting ways across general-purpose desktop operating systems. macOS uses the Apple Secure Enclave [@apple-secure-enclave]: a separate coprocessor "isolated from the main processor" running an Apple-customised L4 microkernel, with its own attestation chain and a constrained API surface that does not require a "secure call" from the application processor to be tunnelled through a trusted broker. Linux relies on the in-process Kerberos credential cache and per-user keyrings (KCM [@sssd-kcm], GNOME Keyring, KWallet); none of these provide kernel-bypass isolation by default, and the equivalent of "dump LSASS" is "dump the user's keyring file plus the per-user master key from `~/.local/share/`." ChromeOS uses cryptohome [@chromium-cryptohome] plus per-user U2F keys, structurally close to the Hello-for-Business model. Windows is the only general-purpose desktop OS that combines a TPM-bound long-term key (Hello), a hypervisor-isolated derived-secret store (Credential Guard / LsaIso), and a behavioural detection layer (Defender for Identity). It is also the only one that accumulated the largest deployed base of password-equivalent secrets in process memory before it found the architectural answer.

Credential Guard closes the storage class. Layering closes the adjacent classes. But there are five classes the layers cannot close -- five things Credential Guard was never going to close, by documented design. The next section enumerates each one.

8. The five things Credential Guard was never going to close

Microsoft's own How Credential Guard works [@ms-cg-howitworks] page lists what Credential Guard does not protect, in plain English. The list has five classes. Each class has a publicly disclosed worked example. Each worked example is in 2026 production attacker tradecraft. This is the honest accounting.

8.1 Pass-the-Challenge: the trustlet's RPC output as the new attack surface

On December 26, 2022, Oliver Lyak published Pass-the-Challenge [@lyak-passchallenge-wayback]. The technique is exactly the lesson of §5: the trustlet's pages are unreadable, but the trustlet's RPC output is exactly the response the attacker wants, and the attacker can ask for it.

The attack flow, end to end:

The attacker has SYSTEM and SeDebugPrivilege on a Credential-Guard-on box (any of the bypass paths from §3 still apply for getting to that point; Credential Guard does not change them).
The attacker injects a security-package DLL named SecurityPackage.dll (per the PassTheChallenge tool's source [@github-passthechallenge]) into lsass.exe. Inside lsass.exe, that DLL inherits the established ALPC channel to the trustlet, because it is now part of the agent.
The attacker uses the Pypykatz fork [@github-pypykatz-ly4k] to extract the per-logon Context Handle and Proxy Info from the [LSA Isolated Data] block of an existing user session.
The attacker calls the trustlet's NtlmIumCalculateNtResponse method through the established ALPC channel, supplying the Context Handle and "the static challenge 1122334455667788" [@github-passthechallenge], the value historically used in pre-computed NTLMv1 rainbow tables and accepted by the crack.sh [@lyak-passchallenge-wayback] cracking service.
The trustlet faithfully returns the NTLMv1 response. No memory of the trustlet is read. No bug in the trustlet is exploited. The trustlet does what it was built to do.
The attacker submits the response to crack.sh. "In less than a minute, I received an email from crack.sh stating that the NTLM hash was successfully recovered in 30 seconds: 65A13AB2FAEB5B700DE1A938AE5621CA." [@lyak-passchallenge-wayback]

There is also a v2 variant. Lyak: "Another interesting option is to compute an NTLMv2 response using the LSAIso method NtlmIumLm20GetNtlm3ChallengeResponse." [@lyak-passchallenge-wayback] The v2 variant uses an Impacket modification plus an AD CS [@lyak-passchallenge-wayback] Web Enrollment relay to obtain a certificate for the target user (Certipy's Administrator certificate-based authentication path) without needing the cleartext NT hash at all.

sequenceDiagram participant ATT as Attacker (SYSTEM) participant LSASS as "lsass.exe (VTL0) -- SecurityPackage.dll injected" participant SK as "securekernel.exe (VTL1 ring 0)" participant ISO as "LsaIso.exe (VTL1 trustlet)" participant CRACK as crack.sh ATT->>LSASS: Inject SecurityPackage.dll ATT->>LSASS: Extract Context Handle from Pypykatz dump LSASS->>SK: NtlmIumCalculateNtResponse(ctxHandle, 1122334455667788) SK->>ISO: dispatch (signed-and-attested call) ISO->>SK: 24-byte NTLMv1 response SK->>LSASS: response LSASS->>ATT: response (no NTOWF, just the ciphertext) ATT->>CRACK: submit NTLMv1 ciphertext for 1122334455667788 CRACK->>ATT: NT hash recovered in ~30 seconds

Microsoft's response landed in two phases. First, NTLMv1 was deprecated and disabled by default in Windows 11 24H2 / Server 2025 [@paragmali-ntlmless], which removes the crack.sh rainbow-table leg specifically. Second, the trustlet stopped accepting NTLMv1 calls on the same builds. The class -- "use the trustlet to mint derived material" -- remains structural to the agent / trustlet split, because closing it requires removing either the agent's ability to call the trustlet (which would defeat single-sign-on) or the attacker's ability to compromise the agent (which is the point of every other layer in the stack).

Pass-the-Challenge is not a Microsoft bug. It is a class property of any agent / trustlet split where the agent owns the protocol code. If `lsass.exe` could not call the trustlet, the trustlet would be useless: there would be no path from the wire challenge to a response. If `lsass.exe` *can* call the trustlet, then an attacker who compromises `lsass.exe` can call it too. Closing this gap structurally requires rewriting the SSP loading model so that protocol code, too, runs inside the trustlet -- which would put parsers for arbitrary attacker-controlled wire formats inside VTL1 and dramatically expand the trustlet TCB. Microsoft has not announced an intent to do that. The honest read of the architecture is that the storage surface is closed and the use surface is structurally open.

8.2 Credential use without theft

Three named techniques in 2026 production tradecraft do not require reading the memory of any Credential-Guard-protected machine. They request derived material from the network and do offline cryptography on the response.

Kerberoasting. Tim Medin disclosed Kerberoasting at DerbyCon 4 in September 2014 [@irongeek-derbycon-medin] under the talk title Attacking Microsoft Kerberos: Kicking the Guard Dog of Hades. The mechanism, per the MITRE ATT&CK technique page [@attack-kerberoast]: any authenticated domain user requests a TGS-REP ticket for any registered Service Principal Name. "Portions of these tickets may be encrypted with the RC4 algorithm, meaning the Kerberos 5 TGS-REP etype 23 hash of the service account associated with the SPN is used as the private key and is thus vulnerable to offline Brute Force attacks that may expose plaintext credentials." [@attack-kerberoast] The ticket arrives on the attacker's machine; the cracking happens on the attacker's GPUs; no memory of any Credential-Guard-protected box is ever read.

The class of attack in which any authenticated domain user requests a Kerberos TGS-REP ticket for any registered Service Principal Name and submits the encrypted portion of the response to offline cracking, recovering the service-account password if it is weak. Documented as MITRE ATT&CK T1558.003 [@attack-kerberoast]. Kerberoasting reads no memory of the targeted host; it consumes only network responses to entirely-legitimate Kerberos requests.

AS-REP Roasting. The same class for accounts with DONT_REQ_PREAUTH set [@attack-asreproast]: the attacker requests a Kerberos AS-REP without sending preauthentication, the KDC returns a ticket portion encrypted with the user's long-term key, and the attacker cracks offline.

Resource-Based Constrained Delegation (RBCD). Originally described by Elad Shamir in Wagging the Dog (January 2019) [@shenanigans-wagging-dog]; refined by James Forshaw's "Exploiting RBCD using a normal user" (May 2022) [@tiraniddo-rbcd]; turned into a turnkey LPE by Dec0ne's KrbRelayUp (2022) [@github-krbrelayup], which the README describes -- accurately -- as "essentially a universal no-fix local privilege escalation in windows domain environments where LDAP signing is not enforced (the default settings)." [@github-krbrelayup] The attack abuses the msDS-AllowedToActOnBehalfOfOtherIdentity LDAP attribute: if the attacker can write that attribute on a target computer object, they can mint a Kerberos service ticket as anyone against the target. Forshaw's 2022 contribution removed the precondition that the attacker must control a computer account (it used to require a MachineAccountQuota-bypass); after Forshaw, any authenticated domain user with write access to the attribute is enough.

A Kerberos delegation feature in which the resource (server) lists which principals are allowed to delegate to it via the `msDS-AllowedToActOnBehalfOfOtherIdentity` LDAP attribute on the resource's computer object. RBCD enables S4U2Self and S4U2Proxy chains where the configured principal can request a service ticket *as any user* against the resource, including Domain Administrators. Abuse documented in Wagging the Dog [@shenanigans-wagging-dog], refined in tiraniddo.dev [@tiraniddo-rbcd], and weaponised in KrbRelayUp [@github-krbrelayup].

8.3 The SeImpersonatePrivilege Potato chain

The Potato family [@paragmali-com-on-the] is a chain of escalations from a low-privilege service user (anyone with SeImpersonatePrivilege or SeAssignPrimaryTokenPrivilege) to NT AUTHORITY\SYSTEM. The chain starts with Hot Potato (Stephen Breen, January 16, 2016) [@foxglove-hot-potato]: NBNS spoofing plus WPAD plus HTTP-to-SMB NTLM relay. The breenmachine writeup [@foxglove-hot-potato] is verbatim: "Hot Potato (aka: Potato) takes advantage of known issues in Windows to gain local privilege escalation in default configurations, namely NTLM relay (specifically HTTP->SMB relay) and NBNS spoofing." [@foxglove-hot-potato]

Rotten Potato (Breen + Chris Mallz, September 26, 2016) [@foxglove-rotten-potato] replaced the NBNS / WPAD / WSUS triggering with a synthesised DCOM round-trip via CoGetInstanceFromIStorage against the BITS CLSID 4991d34b-80a1-4291-83b6-3328366b9097 over a local TCP port, achieving 100% reliability across Windows versions. Juicy Potato (Andrea Pierini @ohpe + Claudio Tenaglia @decoder_it, August 2018) [@github-juicy-potato] made the CLSID a parameter, dropping the BITS-on-port-6666 hardcoding. PrintSpoofer (itm4n, May 2, 2020) [@itm4n-printspoofer] replaced the DCOM coercion with a Print Spooler named-pipe coercion, surviving Microsoft's Server 2019 / Windows 10 19H1 mitigations against the DCOM-based predecessors.

The Windows token privilege that allows a process to call `ImpersonateLoggedOnUser` against a token obtained from another security context. Service accounts (`NT AUTHORITY\NETWORK SERVICE`, IIS app pool identities, MSSQL service accounts) hold this privilege by default. As `decoder_it` first observed [@itm4n-printspoofer], if you have `SeAssignPrimaryToken` or `SeImpersonate` privilege, you are SYSTEM: combine it with a coerced inbound NTLM authentication from `NT AUTHORITY\SYSTEM` to a local listener, and `CreateProcessWithToken` finishes the chain.

The Potato chain exploits tokens, not credentials. The chain of Hot / Rotten / Juicy / PrintSpoofer / RoguePotato / GodPotato has been continuous since January 2016 because every link in the chain abuses a Windows OS feature (DCOM marshalling, RPC, named-pipe impersonation, Print Spooler, COM activation through alternative interfaces) that has a legitimate use case Microsoft cannot remove. Credential Guard does not protect tokens; Credential Guard protects credentials.

8.4 Plaintext-secret protocols and supplied credentials

"When Credential Guard is enabled, NTLMv1, MS-CHAPv2, Digest, and CredSSP can't use the signed-in credentials" [@ms-cg-howitworks], but they can still be used with prompted or saved credentials. In every such case the cleartext password (or a symmetric secret derived from it) is supplied to lsass.exe from outside the trustlet, so the trustlet has nothing to protect at the moment of use.

The considerations page [@ms-cg-considerations] names PEAP-MSCHAPv2 / EAP-MSCHAPv2 WiFi and VPN configurations as the most consequential remaining surface in 2026: a corporate WiFi or VPN endpoint that authenticates users with MS-CHAPv2 still cracks under the same offline tradecraft as the original NTLMv1 attacks, because the protocol itself uses MD4 + DES against the user's NT hash. The recommendation: "organizations move away from passwords to other authentication methods, such as Windows Hello for Business, FIDO 2 security keys, or smart cards" [@ms-cg-considerations], or migrate the WiFi / VPN endpoint to certificate-based PEAP-TLS / EAP-TLS.

8.5 Out-of-LSA credential storage

Four storage locations are out of scope for Credential Guard by Microsoft's own design:

Generic Credential Manager entries -- web passwords, browser-stored credentials, the Windows Credential Manager's "Web Credentials" tab. "Generic credentials, such as user names and passwords that you use to sign in websites, aren't protected since the applications require your clear-text password." [@ms-cg-considerations]
Non-Microsoft Security Support Providers. "Some non-Microsoft Security Support Providers (SSPs and APs) might not be compatible with Credential Guard because it doesn't allow non-Microsoft SSPs to ask for password hashes from LSA. ... For example, using the KerbQuerySupplementalCredentialsMessage API isn't supported." [@ms-cg-considerations] Third-party SSPs that depend on hash retrieval through that API simply break under Credential Guard.
The Active Directory database on domain controllers. "Credential Guard doesn't protect the Active Directory database running on Windows Server domain controllers." [@ms-cg-howitworks] The most-attacked LSASS on the network -- lsass.exe on the domain controller, holding NTDS.dit and the krbtgt long-term key -- is explicitly out of Credential Guard's scope. Microsoft's stated rationale is that domain controllers do not benefit from the same isolation, because the entire AD database is, by design, available to the LSA process on a DC.
Credential-input pipelines such as Remote Desktop Gateway and Just-In-Time admin access tooling, where the typed cleartext is supplied to lsass.exe over an inbound network protocol and is in clear at the moment of arrival.

Doesn't prevent an attacker with malware on the PC from using the privileges associated with any credential. We recommend using dedicated PCs for high value accounts. -- Microsoft Learn, *How Credential Guard works* [@ms-cg-howitworks] flowchart LR CG["What CG closes:
Long-term key in lsass.exe memory"] R1["Pass-the-Challenge:
trustlet RPC output
(Lyak, Dec 2022)"] R2["Credential use without theft:
Kerberoast, AS-REP Roast,
RBCD / KrbRelayUp"] R3["Token impersonation:
Hot/Rotten/Juicy/PrintSpoofer
SeImpersonatePrivilege"] R4["Plaintext protocols:
NTLMv1, MS-CHAPv2, Digest,
CredSSP"] R5["Out-of-LSA storage:
Web creds, non-MS SSPs,
NTDS.dit on DCs"] CG -.does not close.-> R1 CG -.does not close.-> R2 CG -.does not close.-> R3 CG -.does not close.-> R4 CG -.does not close.-> R5

Key idea: The trustlet is the storage layer; the agent is the use layer; an attacker who controls the agent can request derived material the trustlet was never going to refuse. This is the structural reason Credential Guard was never going to close the use surface.

Five classes documented; five worked examples named. What is not yet documented -- the open problems where the research is still in progress -- is what the next section walks.

9. Open problems

Five things the Credential Guard architecture has not yet closed. One of them is structural; four are deployment frontiers.

9.1 Trustlet IUM API surface fuzzing. Pass-the-Challenge proved one corner of the agent-callable RPC surface is exploitable when fed inputs the developer did not anticipate (the static 1122334455667788 challenge whose responses are pre-computed in commercial cracking tables). The systematic audit of every IUM API entry point -- there are not many; the trustlet is small -- has not been published. A blue-team-friendly fuzzer that exercises the channel from a controlled VTL0 agent against a controlled VTL1 target is on the public to-do list of several research groups.

9.2 Domain-controller LSASS / NTDS.dit / krbtgt protection. Microsoft documents the DC carve-out as out of scope [@ms-cg-howitworks]. An architectural fix would require a DC-resident trustlet model that can answer Kerberos AS-REP and TGS-REP queries against the entire NTDS.dit without compromising AD replication semantics. That model is not on the public roadmap, and the practical recommendation -- the dedicated-Tier-0-PAW model from the Mitigating Pass-the-Hash v2 playbook [@ms-lsa-protection] -- still applies in 2026.

9.3 TGT and service-ticket lifetime in lsass.exe after the trustlet mints them. Pass-the-Ticket on the agent recovers the current TGT or service ticket from lsass.exe memory. Credential Guard isolates the long-term key; it does not isolate the per-session derived material that the agent has to hold to send on the wire. The trustlet's TGT protection [@ms-cg-howitworks] is verbatim: the long-term-key path is closed, the service-ticket path is not. A 2026 attacker with SeDebugPrivilege who dumps lsass.exe recovers the Kerberos service tickets even though they cannot recover the underlying NTOWF.

9.4 Pass-the-Cookie / token-lift class against derived material. Microsoft Entra Primary Refresh Token (PRT) [@ms-entra-prt] cookies issued by the trustlet to the agent become bearer tokens until the session ends. Per-token device binding raises the bar (the cookie is bound to a TPM-bound device key, so use of the cookie outside the device is detectable by the cloud), but it does not close the class for an attacker who has on-device persistence and can replay the cookie from the same device.

9.5 Compatibility and observability frontier. The third-party SSP / MS-CHAPv2 / CredSSP behaviour-change surface keeps showing up in real-estate compatibility reports. Microsoft's Considerations page [@ms-cg-considerations] is updated routinely; the practical operational pattern in 2026 is "enable Credential Guard via Intune in audit mode for 30 days, harvest the compatibility errors, fix or replace the affected SSPs, then promote to enforce." That pattern is now well-trodden but the per-estate inventory is real work.

Open problems are interesting; daily practice is more interesting. What does a 2026 administrator, researcher, red-team operator, and detection engineer actually do with Credential Guard?

10. Practical guide

Four audiences; four operational checklists. Each is short because each builds on a section we have already walked.

For an administrator or platform engineer

Verify Credential Guard is running using the three supported surfaces [@ms-cg-configure]: (Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard).SecurityServicesRunning should contain 1; msinfo32 should list "Credential Guard" under Virtualization-based Security Services Running; the System event log should show WinInit Event 13. Deploy via Intune Settings Catalog or GPO with "Enabled without lock" [@ms-cg-configure]. Inventory NTLMv1, MS-CHAPv2, Digest, CredSSP, and non-Microsoft SSP usage before enabling, because those are the protocols that will lose SSO under Credential Guard.

On a Credential-Guard-on box, the following one-liner returns `True`:

(Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard).SecurityServicesRunning -contains 1

The 1 corresponds to Credential Guard in the SecurityServicesRunning bitmask [@ms-cg-configure]. Pair with the System event log filter EventID=13, Source=Wininit to confirm the boot-time launch event. Use these to verify, not Task Manager: Microsoft explicitly disrecommends the Task Manager check.

Note: "Credential Guard should be enabled before a device is joined to a domain or before a domain user signs in for the first time. If Credential Guard is enabled after domain join, the user and device secrets may already be compromised." [@ms-cg-configure] On a default-on Windows 11 22H2+ deployment this is automatic; on legacy estates being migrated, it requires a re-image cycle.

For a security researcher

The verifiable trustlet artefacts are: the .tpolicy PE section in LsaIso.exe; the s_IumPolicyMetadata export; the dual-EKU signature with the IUM EKU 1.3.6.1.4.1.311.10.3.37 visible in the certificate chain. The IUM-side enumeration approach is NtQuerySystemInformation with the SystemIsolatedUserModeInformation class. Quarkslab's IUM-debugging walkthrough [@quarkslab-falcon-ium] documents the nested-virt setup (VMware L1 + Hyper-V L2), the GDB-stub attach on hvix64.exe, the patch on SecureKernel!SkpsIsProcessDebuggingEnabled to force-return 1, and the walk to SecureKernel.exe from HvCallVtlReturn at hypercall ID 0x12. Lyak's PassTheChallenge methodology [@github-passthechallenge] is the canonical worked example for the agent-side trustlet RPC interaction.

For a red-team operator

Assume the long-term hash and TGT are not in lsass.exe. Assume the trustlet's RPC output is. The 2026 LPE / credential playbook focuses on credential use (Kerberoast against weak service-account passwords; AS-REP Roast against accounts with DONT_REQ_PREAUTH; RBCD via KrbRelayUp [@github-krbrelayup]; AD CS misconfigurations -- the ESC1-ESC11 enumeration), token impersonation (the PrintSpoofer / Potato chain [@itm4n-printspoofer]), and supplied-credential capture (keylogger on the prompt path). The companion NTLMless article in this series [@paragmali-ntlmless] covers the protocol-removal frontier that closes the Pass-the-Challenge NTLMv1 leg specifically.

For a detection engineer

WinInit Events 15, 16, and 17 ("Credential Guard configured but did not run") are a high-fidelity "attacker disabled Credential Guard" detection -- if the box is supposed to be Credential-Guard-on and the boot-time event logs show one of those IDs, something blocked the trustlet from launching. ETW Microsoft-Antimalware-Engine plus AMSI [@ms-amsi] on lsass.exe security-package load is the high-fidelity detection surface for Pass-the-Challenge-style injection (the attacker has to load a security-package DLL into lsass.exe to get the established ALPC channel). On the network side, a crack.sh submission carrying the static 1122334455667788 challenge is an indicator of Pass-the-Challenge cracking activity by an internal user.

Three misconceptions about Credential Guard get asked in every defensive-architecture review. The FAQ that follows resolves them, with primary citations for each answer.

11. Frequently asked questions

These are the seven questions that come up in every Credential Guard architectural review. Each answer is grounded in a primary source.

No. The *long-lived* NTLM hash and the Kerberos *long-term key* are unstealable from VTL0 memory; the per-session Kerberos service tickets are not protected, though the TGT is [@ms-cg-howitworks]. Pass-the-Ticket on the agent recovers the current session's tickets even on a Credential-Guard-on box. The architectural pivot is "long-lived secret out of the agent's memory," not "no secret in the agent's memory." Yes. The dump succeeds; the contents are different. Where the NT hash field used to hold the bytes of the hash, [the field now holds the literal string `[LSA Isolated Data]` followed by an opaque ciphertext](https://github.com/ly4k/PassTheChallenge), with embedded `Context Handle`, `Proxy Info`, and `DPAPI` GUID fields. The encrypted blob is AES-GCM-wrapped by the trustlet under a key the agent does not hold. The dump is a statement of architecture, not a statement of failure. No. Kerberoasting [@attack-kerberoast] cracks the service account's NT hash from a TGS-REP delivered over the wire by the KDC. No memory of the Credential-Guard-protected box is ever read. The mitigation for Kerberoasting is strong service-account passwords (or moving to managed service accounts with auto-rotated 240-character passwords), not Credential Guard. No. The Potato chain [@itm4n-printspoofer] (Hot, Rotten, Juicy, PrintSpoofer, RoguePotato, GodPotato) escalates from a service user with `SeImpersonatePrivilege` to NT AUTHORITY\SYSTEM by impersonating a coerced inbound SYSTEM authentication. The chain operates on *tokens*, not *credentials*. Credential Guard protects credentials. No, by design. Microsoft documents the carve-out verbatim: "Enabling Credential Guard on domain controllers isn't recommended. Credential Guard doesn't provide any added security to domain controllers, and can cause application compatibility issues on domain controllers." [@ms-cg-overview] The most-attacked LSASS on the network -- on the domain controller, holding `NTDS.dit` and the `krbtgt` long-term key -- is explicitly out of scope. The mitigations for DC LSASS are physical and procedural: dedicated Tier-0 Privileged Access Workstations, no general-purpose interactive logon, and the *Mitigating Pass-the-Hash* v2 playbook [@ms-lsa-protection]. No. PPL is kernel-enforced inside the NT TCB; Credential Guard is a VTL1 trustlet outside it. itm4n's writeup is explicit: "LSA Protection tends to be confused with Credential Guard, which is completely different ... Credential Guard and LSA Protection are actually complementary." [@itm4n-runasppl] Both should be enabled. PPL raises the bar for opportunistic attackers; Credential Guard moves the secret across a TCB boundary that an NT-kernel-mode attacker cannot cross. Because the application chains through a protocol that cannot use Credential-Guard-protected credentials. "When Credential Guard is enabled, NTLMv1, MS-CHAPv2, Digest, and CredSSP can't use the signed-in credentials" [@ms-cg-howitworks]; third-party SSPs that depend on `KerbQuerySupplementalCredentialsMessage` simply break under Credential Guard [@ms-cg-considerations]. The remediation is to migrate the application to a supported protocol (Kerberos with AES, certificate-based EAP-TLS / PEAP-TLS, or Hello-for-Business per-application keys).

The empty hash from §1 is, in 2026, a property of every domain-joined Windows 11 22H2+ box on the planet. Eleven years of lsass.exe extraction history made the architectural pivot inevitable; eight years of trustlet maturation have made the pivot the default. What remains -- the use surface, the protocol surface, the token surface, the typed-credential surface, the third-party-SSP surface -- is the next eleven years of work.

VBS Trustlets: What Actually Runs in the Secure Kernel

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

**Trustlets are the user-mode processes Microsoft places in Virtual Trust Level 1** to hold the secrets a SYSTEM-privilege attacker on the Windows kernel must never reach: NTLM hashes, Kerberos tickets, biometric templates, virtual TPM keys, and (in 2025-2026) just-in-time admin tokens. A binary becomes a trustlet by passing five gates at load time: a process attribute, two specific signing EKUs at Signature Level 12, a `.tpolicy` PE section containing `s_IumPolicyMetadata`, a Trustlet Instance GUID, and a stripped-down loader path. Once loaded, the trustlet talks to the rest of Windows over ALPC, services an agent process in VTL0, and uses only 48 of NT's roughly 480 syscalls. The Hyper-V hypervisor refuses to map its pages into VTL0. That is what "isolated" means.

1. Four Locked Rooms

It is 3:14 a.m. and a red-team operator on a fully patched Windows 11 25H2 box has, after eight hours of careful work, achieved the prize: a SYSTEM-privilege write primitive in the NT kernel. For two decades that has been the moment when the engagement ends and the report writes itself. SYSTEM in the kernel meant every process, every page, every secret. Game over.

It is not game over.

The operator's target list has four items on it. The NTLM hashes and Kerberos Ticket-Granting Tickets sitting in lsass.exe. The user's fingerprint template, in whatever process the Windows Hello biometric pipeline puts it. The just-in-time admin token that Administrator Protection issued thirty seconds ago. The keys of the four Hyper-V virtual machines running on the box, including the one hosting the user's corporate VPN. Four secrets. Four user-mode processes. And on this 2026 machine, four locked rooms whose pages the operator's kernel write primitive cannot touch and whose contents the operator's kernel does not have permission to ask.

Those four processes are trustlets. They run in a different kernel from the one the operator just compromised, on a different virtual trust level enforced by a hypervisor running underneath both. The operator owns the NT kernel; the NT kernel does not own them. That sentence is what changed in 2015, and the rest of this piece is what it actually means.

This is not "Microsoft hid the memory better." It is not obfuscation, not a clever access-control rule, not a kernel mitigation that the next CVE will erase. It is an architectural relocation: the user-mode processes that hold the secrets no longer live in the operating system the attacker compromised. The hypervisor refuses to map their pages into Virtual Trust Level 0 ("VTL0"), and the operator's kernel is in VTL0.

Key idea: Four user-mode processes survive a SYSTEM kernel write primitive on a 2026 Windows 11 box. That is what changed in 2015, and trustlets are the reason.

The promise of this piece is to explain trustlets at the level of "what does LsaIso.exe actually do, how is it built, how does it talk to the rest of the system, and where does the model end." Not at the level of "VBS isolates them." By the end, four locked rooms will have become something you can name, list, audit, and reason about. Where the public record runs out (some trustlet binary names and IDs are not on Microsoft's published list as of mid-2026), the piece will say so, and it will tell you what the actual records look like instead of inventing replacements.

So how does a user-mode process become unreachable from SYSTEM-in-the-NT-kernel? The answer is not new. It begins, like much of operating-system security, at MIT in the early 1970s.

2. The User-Mode-In-A-Higher-Privilege Problem

In March 1972 Michael Schroeder and Jerome Saltzer published a paper in the Communications of the ACM describing an unusual machine. The Multics team at MIT had been wrestling with a question that does not, at first glance, sound like a security question. What should happen when a user program calls a password-checking routine that needs to read the system password file? The user program must not be allowed to read that file directly. The routine must be allowed to read it. The two pieces of code run in the same process. How does the machine know which one is asking?

Schroeder and Saltzer's answer was eight hardware-enforced rings of privilege, with each segment in memory carrying a ring bracket in its descriptor word, and with cross-ring calls validated automatically by the hardware [@multicians-protection] [@multicians-papers]. The hardware that shipped this design was the Honeywell 6180 in 1973 [@wiki-protection-ring]. The pattern matters more than the gear. Some user code needed to run with more privilege than its caller and less privilege than the kernel. Multics arranged eight such layers from user code at the outermost ring down to the supervisor at ring 0 [@wiki-multics].

The set of hardware, firmware, and software whose correct operation is necessary to enforce a security policy. If any component of the TCB can be subverted, the policy can be subverted. The smaller the TCB, the easier it is to audit; the larger it is, the more places an attacker can find a foothold.

A few years later at Carnegie Mellon, William Wulf, Roy Levin, and the Hydra team took a different swing at the same problem. Hydra was a capability-based, object-oriented microkernel that ran on the C.mmp multiprocessor between 1971 and 1975 [@wiki-hydra]. Where Multics multiplied rings, Hydra multiplied vocabulary: every protected resource was an object addressable only through capability tokens, and security-critical subsystems lived not inside the kernel but as user-mode capability-holders trusted by the kernel to enforce their own policy. Levin et al.'s 1975 SOSP paper "Policy/Mechanism Separation in HYDRA" gave the design its slogan, and that slogan has outlived the system that produced it [@levy-capabook].Hydra's "policy versus mechanism" phrasing still appears verbatim in modern object-capability literature, in the design discussion of WebAssembly's component model, and in seL4's published rationale.

For two decades the L4 family answered "but is this fast enough to be practical?" Jochen Liedtke's 1993 prototype, hand-coded in i386 assembly, ran inter-process communication twenty times faster than Carnegie's Mach microkernel [@wiki-l4]. His 1995 SOSP paper "On µ-Kernel Construction" was inducted into the ACM SIGOPS Hall of Fame in 2015 and is the foundational statement of the minimal-kernel, maximal-user-mode-trusted-services design. By 2010, OKL4, a commercial L4 derivative, had shipped in over one billion mobile devices [@wiki-l4].

A kernel design that pushes as much functionality as possible out of kernel mode and into user-mode "servers" that communicate via inter-process calls. Filesystem code, networking stacks, even device drivers can run as user-mode processes. The kernel itself shrinks to a few thousand lines of code that schedule processes, route messages, and enforce memory isolation, and nothing else.

In 2009 the lineage reached an end that nobody had reached before. Gerwin Klein, Kevin Elphinstone, Gernot Heiser and the NICTA team published seL4: Formal Verification of an OS Kernel at SOSP, reporting a machine-checked proof of functional correctness from a formal specification down to the C implementation [@sel4-sosp-paper]. seL4 was open-sourced in July 2014 [@wiki-sel4]; the seL4 Foundation's About page states plainly that seL4 stands out because of its thoroughgoing formal verification [@sel4-about]. A kernel of about 8,700 lines of C, formally verified from specification to C implementation, with sub-microsecond inter-process calls.

Schroeder and Saltzer asked it for hardware rings. Hydra asked it for capabilities. Liedtke asked it for inter-process speed. Klein and Heiser asked it of formal logic. The question stayed the same: how do you let some user-mode code hold a secret that some other code in the same machine is not allowed to read, when both pieces of code are scheduled by the same kernel? The Multics answer was rings. The Hydra answer was capabilities. The L4 answer was a tiny kernel plus IPC. The seL4 answer was a tiny kernel plus IPC, plus a proof.

The Microsoft answer, in July 2015, was a hypervisor.

timeline title User-mode-in-higher-privilege lineage 1972 : Multics 8-ring hardware : Honeywell 6180 ring brackets 1974 : Hydra capabilities 1975 : Policy vs mechanism 1993 : L4 microkernel : Fast user-mode IPC : Windows NT ships ring 0/3 2007 : Vista Protected Processes 2009 : seL4 verification 2013 : Windows 8.1 PPL 2015 : Windows 10 IUM ships : Trustlets 0-3 enumerated 2024 : VBS Enclaves go third-party 2026 : Administrator Protection

If the architectural answer was already in the 1970s academic literature, why did Microsoft wait until 2015 to ship it on Windows? Because three earlier attempts to ship user-mode isolation on Windows -- under three different names, in three different decades -- each failed in the same way.

3. Three Tries Before Trustlets

Before 2015 Microsoft tried three times to ship user-mode isolation on Windows. All three shipped in production. All three failed in the same way.

2007: Vista Protected Processes

Windows Vista introduced Protected Processes in January 2007. The motivation was not credential security; it was Digital Rights Management. The Protected Media Path required a set of binaries -- audiodg.exe, mfpmp.exe, and a handful of others involved in Blu-ray playback -- whose memory non-protected processes could not read, whose threads could not be debugged from outside, and whose DLL imports could not be hijacked at runtime [@wiki-pmp]. The kernel enforced these rules by refusing to grant the relevant access masks (PROCESS_VM_READ, PROCESS_VM_WRITE, THREAD_ALL_ACCESS) to handles requested from non-protected processes.

The mechanism was elegant. The threat model was not. Alex Ionescu announced in January 2007 -- within weeks of Vista's general availability -- that he had developed a bypass method for the Protected Media Path [@wiki-pmp]. The same NT kernel that enforced the protection was the kernel an attacker would compromise to bypass it. A signed kernel driver, or any of the long stream of subsequent kernel vulnerabilities, would walk straight through.

2012: AppContainer and the LowBox token

Windows 8 introduced AppContainer process isolation in October 2012, originally to support Windows Store apps (later unified as the Universal Windows Platform in Windows 10) [@wiki-uwp]. Each AppContainer process ran with a LowBox token: a low-integrity primary token plus a SID, plus a set of named capabilities (internetClient, picturesLibrary, and so on), plus a per-AppContainer named-object subtree under \Sessions\<N>\AppContainerNamedObjects\<SID>. The NT kernel checked the SID against object DACLs at every object access, denying access by default and granting it only where the AppContainer's declared capabilities matched the requested operation.

This is a Hydra-style capability lattice bolted onto NT's existing access-control system. It is a useful sandboxing primitive for untrusted code, and modern browsers (the Edge renderer, the Chromium sandbox) consume it for exactly that purpose. It is not a defence against an attacker who already has kernel code execution. In August 2018 James Forshaw at Google Project Zero published an exploit for Issue 1550 that turned the AppContainer named-object namespace itself into an arbitrary-directory-creation primitive [@forshaw-2018]:

The AppInfo service... calls the undocumented API CreateAppContainerToken... As the API is called without impersonating the user... the object directories are created with the identity of the service, which is SYSTEM.

A low-integrity caller could direct that SYSTEM-owned creation at any directory it pleased and use the result to elevate. The lattice held; the lattice's enforcer did not. AppContainers continue to ship, doing their actual job (sandboxing untrusted code) reasonably well. They were never going to answer the trustlet question (isolating trusted code from a compromised kernel) because they are NT-kernel-enforced.

2013: Protected Process Light (PPL) and `RunAsPPL`

Windows 8.1 generalised the Vista mechanism into a signer-level lattice. Each protected process now had a two-dimensional protection level: a signer (WinTcb, Windows, Antimalware, Authenticode, others) and a protection type (PsProtectedSignerTcb, PsProtectedSignerAuthenticode, others). Higher-signer processes could manipulate lower-signer ones; same-signer processes could not see across the line. The first canonical use case was anti-malware services that registered an Early Launch Anti-Malware (ELAM) driver and then ran their user-mode service as a Protected Process Light [@msdocs-protecting-am].

A Windows 8.1 process attribute that constrains which other processes can request high-privilege access to it. PPL extends the Vista Protected Process mechanism with a signer-level lattice (WinTcb > Windows > Antimalware > Authenticode > None) and a protection type. The NT kernel enforces the rules. LSASS running as a PPL is the canonical use case, exposed to administrators via the `RunAsPPL` registry value [@itm4n-runasppl].

Alex Ionescu's 2013 essay "The Evolution of Protected Processes Part 3" documented the resulting Signing Levels table -- Signature Level 12 named "Windows," Level 13 "Windows Protected Process Light," Level 14 "Windows TCB" [@ionescu-ppp3] [@ionescu-ppp1]. That table is the load-bearing reference for every later trustlet design: every IUM binary on a 2026 Windows machine must satisfy at least Signature Level 12. Microsoft shipped LSASS-as-PPL ("LSA Protection," exposed through the RunAsPPL registry value under HKLM\SYSTEM\CurrentControlSet\Control\Lsa) as the canonical example: a way to keep the lower-privileged half of an administrator's session from reading credential material out of LSASS memory.

It worked, for some values of "worked." It worked against pass-the-hash tools that ran as an ordinary administrator without a signed kernel driver. It did not work against an attacker willing to load any signed driver, and -- as became clear in 2021 -- it did not work even from userland once the bypass class was identified.

In August 2018 James Forshaw, in the same Project Zero post that exposed the AppContainer issue, also documented a DefineDosDevice plus Known-DLL hijack technique. By creating a symbolic link in the NT object manager namespace that aliased a Known DLL section, an administrative caller could induce a target PPL process to load arbitrary code at the next image load [@forshaw-2018]. In 2021 the researcher who blogs as itm4n weaponised the same primitive into PPLdump, a userland tool that dumped lsass.exe memory from an administrator command prompt with no kernel driver involved [@itm4n-runasppl]. itm4n's writeup is honest about what this means:

Like any other protection though, it is not bulletproof and it is not sufficient on its own, but it is still particularly efficient.

Microsoft closed the DefineDosDevice corner of this class in Windows 10 21H2 build 19044.1826, shipped in July 2022 [@itm4n-end-of-ppldump]. That is eight years of mainstream PPL deployment during which the LSASS-as-PPL credential boundary was bypassable without ring 0 access at all.

The pattern

Three primitives. Three different protection mechanisms. One common failure mode.

Mechanism	Year	Enforcer	Threat model	Defeated by	Status today
Vista Protected Process	2007	NT kernel	Untrusted user code reading DRM-protected media buffers	Signed kernel drivers; Ionescu Jan 2007 [@wiki-pmp]	Superseded by PPL for non-DRM use
AppContainer / LowBox	2012	NT kernel	Untrusted store-app code escaping its capability sandbox	SYSTEM-owned directory creation via service impersonation [@forshaw-2018]	Active for sandboxing untrusted code; not a trustlet substitute
Protected Process Light (`RunAsPPL`)	2013	NT kernel	Userland administrative attacker reading LSASS credential material	`DefineDosDevice` plus Known-DLL hijack; PPLdump 2021 [@itm4n-runasppl]	Active as defence-in-depth; closed in build 19044.1826, July 2022
Isolated User Mode / trustlets	2015	Hypervisor + Secure Kernel	VTL0 kernel attacker reading user-mode secrets	Secure-call interface bugs; agent-side RPC residual [@amar-bh2020]	Active; subject of this article

Three rows, one diagnosis. Every NT-kernel-enforced isolation primitive shares the attacker's TCB. Improving the lattice the NT kernel enforces does not move the security ceiling, because the NT kernel itself can be compromised; once it is, any policy decision the NT kernel makes is the attacker's policy decision. Microsoft's own VBS hardware-requirements page admits the diagnosis verbatim:

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. -- Microsoft, OEM VBS hardware requirements [@msdocs-oem-vbs]

Note: RunAsPPL is useful defence in depth. It is not, and has never been, a substitute for Credential Guard. itm4n's 2021 PPLdump release was the proof for the userland half of that statement; signed-driver loaders are the proof for the ring-zero half. If your threat model includes a determined attacker with administrative rights, Credential Guard is the boundary; PPL is the speed bump in front of it [@itm4n-runasppl].

If every primitive the NT kernel enforces shares the attacker's TCB, the kernel that enforces user-mode isolation has to be a different kernel. In July 2015 Microsoft shipped one.

4. July 2015: The Hypervisor Becomes the Arbiter

On 29 July 2015 Microsoft shipped Windows 10 build 10240 [@wiki-win10-history]. Two new ideas shipped with it. The first was Hyper-V's hypervisor running underneath the NT kernel even on a laptop, not just on a server hosting virtual machines [@wiki-hyperv]. The second was a separate kernel running alongside the NT kernel, at a different Virtual Trust Level. Together those two ideas produce a substrate where the long-time equation "SYSTEM kernel write primitive equals every secret in user-mode memory" is no longer true.

A hypervisor-managed privilege axis added on top of x86's existing ring 0 / ring 3 split. Each VTL has its own kernel mode and its own user mode. Higher VTLs can read and write lower-VTL memory; lower VTLs cannot read or write higher-VTL memory at all. The Hyper-V Top-Level Functional Specification reserves up to 16 VTLs; the current Hyper-V implementation defines `#define HV_NUM_VTLS 2` [@msdocs-vsm].

The Hyper-V Top-Level Functional Specification states the rule directly: "VSM achieves and maintains isolation through Virtual Trust Levels (VTLs)... Architecturally, up to 16 levels of VTLs are supported; however a hypervisor may choose to implement fewer than 16 VTL's. Currently, only two VTLs are implemented" [@msdocs-vsm]. The NT kernel runs in VTL0 ring 0; user-mode applications run in VTL0 ring 3. The Secure Kernel runs in VTL1 ring 0; trustlets run in VTL1 ring 3. Each VTL transition takes the CPU through a VMEXIT and back, with VMCS save and restore on each crossing [@quarkslab-virtual-journey].The architectural cap of sixteen VTLs is in the published specification but is not deployed. Stocking the unused slots would require both hypervisor changes and a new design for who manages the additional kernel images. The two-VTL design is the entire shipped product.

Quarkslab's reverse-engineering team put the practical consequence in one sentence in their IUM-debugging writeup: "VTL0 is the Normal World, where the traditional kernel-mode and user-mode code run in ring 0 and ring 3, respectively. On top of that, a new world appears: VTL1 is the privileged Secure World, where the Secure Kernel runs in ring 0, and a limited number of IUM processes run in ring 3. Code running in VTL0, even in ring 0, cannot access the higher-privileged VTL1" [@quarkslab-debug-ium].

That sentence is the architectural fact the whole article rests on. The hypervisor configures each guest physical page's permissions on a per-VTL basis using the CPU's Second Level Address Translation tables. A page can be readable from VTL0 and VTL1, readable from VTL1 only, or readable from neither.On Intel hardware, the per-VTL permissions are implemented with Extended Page Tables (EPT); on AMD they use Nested Page Tables (NPT). The hypervisor keeps the per-VTL EPT/NPT entries in its own memory, not in the guest's.

The hardware mechanism (Intel EPT, AMD NPT) that lets a hypervisor define page-level read, write, and execute permissions independent of the guest's own page tables. With VTLs, SLAT entries are per-VTL: a page's permissions when the CPU is executing VTL1 code can differ from the same page's permissions when the CPU is executing VTL0 code. A SYSTEM-privilege VTL0 attacker who edits the NT kernel's page tables cannot change the VTL1-side permissions, because those live in hypervisor-managed structures that VTL0 page-table writes do not touch. flowchart LR subgraph VTL0["VTL0 (Normal World)"] ring3_0["Ring 3: lsass.exe, vmwp.exe, user apps"] ring0_0["Ring 0: NT kernel + signed drivers"] ring3_0 --> ring0_0 end subgraph VTL1["VTL1 (Secure World)"] ring3_1["Ring 3: LsaIso.exe, vmsp.exe, trustlets"] ring0_1["Ring 0: Secure Kernel (securekernel.exe)"] ring3_1 --> ring0_1 end VTL0 -. ALPC over agent ALPC port .-> VTL1 VTL1 -. read VTL0 memory .-> VTL0 hv["Hyper-V hypervisor: per-VTL SLAT permissions"] VTL0 --> hv VTL1 --> hv

The VTL hierarchy is not symmetric. VTL1 code can read VTL0 memory; that is how a trustlet can dispatch the contents of an lsass.exe RPC request the moment after VTL0 wrote it. VTL0 code cannot read VTL1 memory under any condition the hypervisor permits. A kernel write primitive in VTL0 lets the attacker corrupt the NT kernel's data structures, modify drivers, and walk every VTL0 process's pages. The attacker can do every one of those things and not be one byte closer to the contents of LsaIso.exe.

Microsoft's IUM documentation at Windows 10 RTM named two trustlets explicitly: Trustlet ID 0 = the Secure Kernel Process (hosts Device Guard and Hypervisor-protected Code Integrity policy decisions), and Trustlet ID 1 = LSAISO.EXE (Credential Guard's isolated LSA, holding NTLM hashes and Kerberos Ticket-Granting Tickets out of VTL0 reach). Two more (IDs 2 and 3, covered in §6) also shipped on the RTM image and were enumerated a week later by Ionescu's Black Hat reverse-engineering [@msdocs-ium] [@ionescu-bh2015]. Microsoft Learn's IUM page introduces the vocabulary the rest of this piece will use:

Trustlets (also known as trusted processes, secure processes, or IUM processes) are programs running as IUM processes in VSM... With VSM enabled, the Local Security Authority (LSASS) environment runs as a trustlet.

A week after Windows 10 shipped, on 5 August 2015, Alex Ionescu walked into a Black Hat USA briefing room in Mandalay Bay and reverse-engineered the entire thing in front of an audience [@ionescu-bh2015-infocondb]. His talk, "Battle of the SKM and IUM: How Windows 10 Rewrites OS Architecture," is the canonical first public account of the trustlet model and the source from which Microsoft's own later documentation borrows terminology one for one [@ionescu-bh2015]. Almost every concrete fact in the next section -- the syscall allow-list, the EKUs, the .tpolicy section, the Trustlet Instance GUID -- traces back to that single deck.

Now we know what world a trustlet lives in. What architecturally is one?

5. The Five Gates

A trustlet is not a special process class the way a Protected Process is. It is an ordinary Portable Executable binary that has been loaded under five very specific conditions. Walk through them once and you will be able to recognise a trustlet in a dumpbin /headers listing. The status is mechanical, not categorical. Chapter 9 of Windows Internals, Seventh Edition, Part 2 (Allievi, Russinovich, Ionescu, Solomon) covers the same architecture from the kernel-team side as a reference complement to Ionescu's BH2015 reverse-engineering [@windows-internals-7e-pt2].

A Windows user-mode process that runs in Virtual Trust Level 1 user mode (ring 3 of the Secure World), scheduled by the Secure Kernel and isolated from VTL0 by Hyper-V's per-VTL SLAT enforcement. A binary becomes a trustlet only if it satisfies five load-time conditions: a process attribute, two signing EKUs at Signature Level 12, a `.tpolicy` PE section containing `s_IumPolicyMetadata`, a Trustlet Instance GUID, and a stripped-down loader path. Trustlets are sometimes also called "trusted processes," "secure processes," or "IUM processes" [@msdocs-ium]. The user-mode environment of Virtual Trust Level 1. IUM is, structurally, ring 3 of VTL1. Its inhabitants are trustlets; its kernel is the Secure Kernel; its system-call surface is approximately one-tenth of NT's. Quarkslab's IUM-debugging writeup describes IUM as the place where *"a limited number of IUM processes run in ring 3"* of VTL1; Microsoft's Win32 documentation describes the same architectural placement with different wording [@quarkslab-debug-ium] [@msdocs-ium].

Gate 1: the process attribute

VTL0 user-mode code cannot call CreateProcess and produce a trustlet. The Win32 API does not expose the necessary primitive. A trustlet is born via a direct NtCreateUserProcess syscall that carries a PsAttributeSecureProcess attribute with a 64-bit Trustlet ID. Only callers that already live in VTL1, or callers in VTL0 that hold a specific brokering capability, can request that attribute and have the Secure Kernel honour it [@ionescu-bh2015].

This is intentional. The Win32 layering is one of the surfaces an attacker can compromise, so the trustlet boot path bypasses it. There is no "trustlet via shell" -- not for an administrator, not for SYSTEM, not for the Secure Kernel itself other than through the documented internal path.

Gate 2: two EKUs at Signature Level 12

The binary must be signed with a certificate chain that contains two specific Enhanced Key Usage identifiers, and the resulting Signing Level must be 12 or higher. From Ionescu's BH2015 deck (correcting a typo in the slide): "They must have a Signature Level of 12... This means they must have the Windows System Component Verification EKU (1.3.6.1.4.1.311.10.3.6)... They must have the IUM EKU 1.3.6.1.4.1.311.10.3.37" [@ionescu-bh2015].

An X.509 certificate extension that restricts which purposes a certificate can be used for. An EKU is an object identifier (OID); a code-signing certificate that claims an OID of `1.3.6.1.4.1.311.10.3.6` is asserting it is valid for the "Windows System Component Verification" purpose. The Windows code-integrity subsystem (`ci.dll`) checks the requested EKU against the actual certificate at signature time and refuses to load the image if the EKU is missing or the certificate is not chained to a trusted root [@ionescu-ppp3].

Both EKUs are required. The Windows System Component Verification EKU establishes the binary as a Microsoft-signed Windows component. The IUM EKU asserts the binary's intent to load as a trustlet. A PPL EKU may sit on top, layering the PPL signer-level check on the trustlet check, but the two-EKU minimum is what Signing Level 12 enforces.The system-component EKU check is skipped when both Test Signing is enabled and the local machine trusts the Microsoft Test Root. That is the exact attack class Ionescu names verbatim in the BH2015 deck: "compromise the platform via Test Signing" disables the signing gate that defines trustlet identity.

Gate 3: the `.tpolicy` section and `s_IumPolicyMetadata`

Every trustlet image must contain a PE section named .tpolicy marked IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ. The section must export the symbol s_IumPolicyMetadata, a structure with three required components: a version byte set to 1, a 64-bit Trustlet ID that must match the one the process attribute requested, and a per-trustlet policy table containing entries for ETW (event tracing), debug permissions, crash-dump key release, and other trustlet-specific runtime knobs [@ionescu-bh2015].

The Secure Kernel parses this section at load time via an internal routine the deck names SkpspFindPolicy. A binary with no .tpolicy section, or with one whose Trustlet ID disagrees with the process-attribute Trustlet ID, or whose version byte is anything other than 1, fails the gate. The Secure Kernel does not "infer" a trustlet identity; it reads it out of the binary the attacker would have had to sign.

Gate 4: the Trustlet Instance GUID

Once gates 1-3 pass, the trustlet calls a secure-service routine the deck names IumSetTrustletInstance, identified by secure-call ordinal 0x80000001. That routine binds the running process to a Trustlet Instance GUID, the runtime identity by which the Secure Kernel discriminates one instance of a trustlet from another. Hyper-V partition GUIDs flow into this identifier for the vTPM trustlets, so that the secrets a partition's vTPM holds are scoped to that partition's Instance GUID.

The same Instance GUID can be shared across distinct Trustlet IDs. That is the architectural primitive Microsoft uses for trustlet-to-trustlet authentication: the host-side Hyper-V vTPM (vmsp.exe, Trustlet ID 2) and the vTPM provisioning trustlet (ID 3) cooperate on a single partition's secrets by sharing the partition's Instance GUID. The Secure Kernel's SkCapabilities table hardcodes which Trustlet IDs are permitted to invoke which secure-storage operations against an Instance GUID; for the 2015-era IUM surface, the only ID-discriminated rules are CheckByTrustletId 2 for SecureStorageGet and CheckByTrustletId 3 for SecureStorageSet [@ionescu-bh2015].

Gate 5: the stripped-down loader

A trustlet's image loader is not the standard NT loader. The Secure Kernel routes trustlet loads through a path the deck names LdrpIsSecureProcess, which skips an unusually long list of features. Application Verifier hooks: skipped. Image File Execution Options registry checks: skipped. SxS / Fusion DLL redirection: skipped. The CSRSS connection ordinary NT processes establish during startup: skipped (the BASE_STATIC_SERVER_DATA structure CSRSS would normally hand back is fabricated locally on the trustlet's heap so dependent calls do not crash). Safer, AuthZ, Software Restriction Policies: all skipped. Any DLL load triggered from VTL0: refused.

The result is a loader path with no attack surface against VTL0 environment variables, no susceptibility to NT's normal "load this DLL instead" knobs, and no opportunity for the user's CSRSS process to inject anything into the trustlet's address space. The system-call surface available inside the trustlet is restricted to roughly fifty allowed entries. Ionescu's deck states the count verbatim: "Only 48 system calls are currently allowed from IUM Trustlets" [@ionescu-bh2015].

sequenceDiagram participant Caller as Caller (VTL1 or brokered VTL0) participant NT as NtCreateUserProcess participant CI as ci.dll (CipMincryptToSigningLevel) participant SK as Secure Kernel (SkpspFindPolicy) participant Ldr as LdrpIsSecureProcess participant Iset as IumSetTrustletInstance Caller->>NT: Create with PsAttributeSecureProcess + Trustlet ID NT->>CI: Verify EKUs System Component plus IUM and Signing Level ge 12 CI-->>NT: Pass or fail NT->>SK: Parse .tpolicy, validate s_IumPolicyMetadata SK-->>NT: Pass or fail NT->>Ldr: Strip down loader and deny VTL0-triggered DLL loads Ldr-->>NT: Image mapped under IUM rules NT->>Iset: Bind Trustlet Instance GUID Iset-->>NT: Trustlet alive in VTL1

Gate	What it checks	Where it lives	Failure outcome
1. Process attribute	`PsAttributeSecureProcess` with 64-bit Trustlet ID, requested via `NtCreateUserProcess`	NT kernel boot path	Normal NT process; no IUM bit ever set [@ionescu-bh2015]
2. EKUs + Signing Level	Windows System Component EKU (`1.3.6.1.4.1.311.10.3.6`) AND IUM EKU (`1.3.6.1.4.1.311.10.3.37`); Signing Level >= 12	`ci.dll` integrity check, `CipMincryptToSigningLevel`	Load refused; no trustlet [@ionescu-ppp3] [@ionescu-bh2015]
3. `.tpolicy` + `s_IumPolicyMetadata`	PE section with version 1, matching Trustlet ID, and per-trustlet policy entries	Secure Kernel `SkpspFindPolicy`	Load refused; no trustlet [@ionescu-bh2015]
4. Trustlet Instance GUID	`IumSetTrustletInstance` secure-call ordinal `0x80000001`; per-partition scoping for vTPM	Secure Kernel runtime	Process exists but cannot bind to per-instance secret storage
5. Loader strip-down	Skip Application Verifier, IFEO, SxS, CSRSS, Safer, AuthZ, SRP; deny VTL0-triggered DLL loads	NT `LdrpIsSecureProcess`	Normal NT loader runs; image loads but is not isolated

The pseudocode below walks each gate in order against a fake binary descriptor. It is not a loader, it is not an exploit, and it is not a security tool. It is a teaching aid: if you can read it, you can read the trustlet load path.

{` // Trustlet load-time gate check (educational pseudocode). // Inspired by Ionescu BH2015 reverse-engineering of Win10 RTM (2015). // Not a real loader; not a security tool.

const WINDOWS_SYSTEM_COMPONENT_EKU = "1.3.6.1.4.1.311.10.3.6"; const IUM_EKU = "1.3.6.1.4.1.311.10.3.37"; const MIN_SIGNING_LEVEL = 12; // "Windows"

function loadTrustlet(bin) { // Gate 1: process attribute if (!bin.attr || !bin.attr.PsAttributeSecureProcess) { return "fail at gate 1: no PsAttributeSecureProcess attribute"; } const requestedId = bin.attr.PsAttributeSecureProcess.trustletId;

// Gate 2: two EKUs at Signing Level 12+ const ekus = (bin.cert && bin.cert.ekus) || []; if (!ekus.includes(WINDOWS_SYSTEM_COMPONENT_EKU)) { return "fail at gate 2: missing Windows System Component EKU"; } if (!ekus.includes(IUM_EKU)) { return "fail at gate 2: missing IUM EKU"; } if ((bin.cert.signingLevel || 0) < MIN_SIGNING_LEVEL) { return "fail at gate 2: signing level below 12"; }

// Gate 3: .tpolicy section with s_IumPolicyMetadata const tpol = bin.sections && bin.sections[".tpolicy"]; if (!tpol || !tpol.exports || !tpol.exports.s_IumPolicyMetadata) { return "fail at gate 3: no .tpolicy section with s_IumPolicyMetadata"; } const meta = tpol.exports.s_IumPolicyMetadata; if (meta.version !== 1 || meta.trustletId !== requestedId) { return "fail at gate 3: malformed or mismatched s_IumPolicyMetadata"; }

// Gate 4: Trustlet Instance GUID (bound at runtime via IumSetTrustletInstance) const instance = bin.runtime && bin.runtime.instanceGuid; if (!instance) { return "fail at gate 4: no Trustlet Instance GUID bound"; }

// Gate 5: stripped-down loader (skip Application Verifier, IFEO, SxS, CSRSS, // Safer, AuthZ, SRP; deny VTL0-triggered DLL loads). // We don't simulate the loader here; we just refuse VTL0-injected DLL loads. if (bin.loaderTriggers && bin.loaderTriggers.fromVtl0) { return "fail at gate 5: VTL0-triggered DLL load denied"; }

return "trustlet loaded: id=" + requestedId + " instance=" + instance; }

// Smoke test. const sample = { attr: { PsAttributeSecureProcess: { trustletId: 1 } }, cert: { ekus: [ "1.3.6.1.4.1.311.10.3.6", "1.3.6.1.4.1.311.10.3.37", ], signingLevel: 12 }, sections: { ".tpolicy": { exports: { s_IumPolicyMetadata: { version: 1, trustletId: 1 }, } } }, runtime: { instanceGuid: "" }, loaderTriggers: { fromVtl0: false }, }; console.log(loadTrustlet(sample)); `}

Key idea: A trustlet is what passes all five gates. There is no other definition. Status is mechanical, not categorical: it is what the Secure Kernel's load path produces when a properly signed binary with a properly formed .tpolicy section calls NtCreateUserProcess with a proper secure-process attribute.

All five gates pass. The binary is now a trustlet. It is running in VTL1 user mode. The hypervisor refuses to map its pages into VTL0. Now what does it do? Who does it talk to?

6. The Inbox Roster

Five gates. Pass them all and you become a trustlet. Microsoft passes them on behalf of -- as of mid-2026 -- this list.

The agent / trustlet pattern

Before the roster, the pattern. Almost every shipping trustlet has a partner: an agent process in VTL0 that does the high-volume work of integrating with the rest of the operating system, and the trustlet itself in VTL1 holding the secret material. The two talk over an Asynchronous Local Procedure Call port whose server end is hosted by the trustlet.

A Windows inter-process communication primitive optimised for fast, fixed-size message exchange between processes on the same machine. The NT kernel hosts ALPC ports as named kernel objects (e.g., `\RPC Control\LSA_ISO_RPC_SERVER`); clients open a port and exchange messages with the server. For trustlets, the ALPC server runs inside the trustlet in VTL1; clients in VTL0 send requests, the Secure Kernel marshals the request across the VTL boundary, and the trustlet returns a result back to VTL0. The hash never leaves VTL1; the request and response do. flowchart LR NetClient[Network or local client] Agent["lsass.exe (VTL0 agent)
protocol parsing
session state
network I/O"] SK["Secure Kernel
(VTL1 ring 0)
marshals secure calls"] Trustlet["LsaIso.exe (VTL1 trustlet)
NTLM hashes
Kerberos TGTs
EncryptData / DecryptData"] NetClient -->|"network protocol"| Agent Agent -->|"ALPC: LSA_ISO_RPC_SERVER"| SK SK -->|"IUM Base API"| Trustlet Trustlet -->|"opaque blob"| SK SK --> Agent

The roster below names the agent for each trustlet where Microsoft has published one. Where the agent is not publicly named, the row says so.

Trustlet ID 0 -- the Secure Kernel Process

The first inhabitant of VTL1 user mode. Hosts Device Guard and Hypervisor-protected Code Integrity policy decisions. Architecturally close to a daemon: it does not service external clients; it provides services the Secure Kernel itself relies on for policy decisions about whether a given image is permitted to load in VTL0 [@ionescu-bh2015].

Trustlet ID 1 -- `LsaIso.exe` (Credential Guard)

The canonical trustlet. Holds NTLM hashes and Kerberos Ticket-Granting Tickets. Its agent in VTL0 is lsass.exe, the Local Security Authority Subsystem Service that has held those secrets directly for every version of Windows NT until 2015. The ALPC port name is LSA_ISO_RPC_SERVER. The IUM-side API the trustlet exposes is narrow: EncryptData and DecryptData on opaque blobs, plus a handful of internal management operations [@msdocs-credential-guard].

The Microsoft Learn explanation is the verbatim public account:

With Credential Guard enabled, the LSA process in the operating system talks to a component called the isolated LSA process that stores and protects those secrets, LSAIso.exe. Data stored by the isolated LSA process is protected using VBS and isn't accessible to the rest of the operating system. LSA uses remote procedure calls to communicate with the isolated LSA process [@msdocs-credential-guard].

A VTL0 caller -- including SYSTEM-in-the-NT-kernel -- can ask the trustlet to encrypt a freshly supplied credential or to authenticate a freshly received challenge. It cannot ask the trustlet to expose the underlying NTLM hash. The hash never leaves VTL1. That is the entire point.

Trustlet ID 2 -- `vmsp.exe` (Hyper-V vTPM, host side)

The Hyper-V Virtual Trusted Platform Module on the host side. One vmsp.exe instance per guest partition; the agent is vmwp.exe, the Hyper-V Virtual Machine Worker Process for that partition. The Instance GUID is the partition's GUID, so that the keys a partition's vTPM holds are scoped to that partition and that partition only. Storage primitives include a Mailbox primitive (protected by a per-instance Security Cookie) and a Secure Storage primitive that produces Ingress and Egress blobs encrypted with per-Instance IDK material [@ionescu-bh2015] [@msdocs-guarded-fabric].

Shielded VMs on Windows Server 2016 and later consume vmsp.exe. A shielded VM, per Microsoft Learn, "has a virtual TPM, is encrypted using BitLocker, and can run only on healthy and approved hosts in the fabric" [@msdocs-guarded-fabric]. The vTPM keys live in the host's vmsp.exe trustlet; the BitLocker volume master key in the guest is sealed against that vTPM; and a SYSTEM-privilege NT-kernel write primitive on the host cannot read the partition's vTPM secrets even though the host can otherwise reach the partition's memory.

Trustlet ID 3 -- vTPM provisioning trustlet

Pushes initial secrets into a partition's Instance GUID at vTPM creation time. The Secure Kernel's SkCapabilities array hardcodes CheckByTrustletId 2 for SecureStorageGet and CheckByTrustletId 3 for SecureStorageSet; those are the only Trustlet-ID-checked secure-storage operations in the 2015-era IUM secure-call surface [@ionescu-bh2015]. The pair of trustlets cooperates on the same Instance GUID so the provisioning trustlet writes and vmsp.exe reads, with the Secure Kernel enforcing that no other trustlet can do either.

Enhanced Sign-in Security (ESS) biometric matching component (Windows 11+)

Microsoft Learn documents the architectural placement of Windows Hello's facial-recognition algorithm verbatim:

When ESS is enabled, the face algorithm is protected using VBS to isolate it from the rest of Windows. The hypervisor is used to specify and protect memory regions, so that they can only be accessed by processes running in VBS. The hypervisor allows the face camera to write to these memory regions providing an isolated pathway... Sensors that support ESS have a certificate embedded during manufacturing [@msdocs-ess].

The page also documents the certificate chain that authenticates the camera to the matcher and the match-on-sensor requirement for fingerprint readers under ESS. Microsoft does not publicly name the binary that hosts the face algorithm, and it does not publicly assign that binary a Trustlet ID. The architectural placement is a trustlet. The naming is not on the record.

Administrator Protection / Adminless issuer (Windows 11, rolling out 2025-26)

In October 2025 Microsoft shipped a preview of Administrator Protection in KB5067036 [@kb5067036] and reverted the rollout in the same update note [@msdocs-admin-protection]. The Microsoft Learn page describes the security model:

Once authorized, Windows uses a hidden, system-generated, profile-separated user account to create an isolated admin token. This token is issued to the requesting process and is destroyed once the process ends, ensuring that admin privileges don't persist. Administrator protection introduces a new security boundary with support to fix any reported security bugs [@msdocs-admin-protection].

The implementation surface that issues those tokens is not publicly named. The architectural family resemblance to a trustlet is strong, and the "new security boundary with support to fix any reported security bugs" line is the formal commitment Microsoft makes for VBS-isolated components. Whether the issuer is a trustlet, a VBS Enclave, or a separately isolated VTL0 process is, as of mid-2026, not on the public record.

Third-party VBS Enclaves (Windows 11 24H2 and later)

For the first time since 2015, the trustlet primitive is exposed to third-party developers. A VBS Enclave is a DLL signed with a Trusted Signing certificate and loaded into a VTL1 enclave region of a host process via CreateEnclave and CallEnclave. The OS support is narrow:

Windows 11 Build 26100.2314 or later... Windows Server 2025 or later... Visual Studio 2022 version 17.9 or later... The Windows Software Development Kit (SDK) version 10.0.22621.3233 or later, which provides veiid.exe (the VBS Enclave import ID binding utility) and signtool.exe... A Trusted Signing account [@msdocs-vbs-enclaves].

Azure SQL's "Always Encrypted with secure enclaves" is the public flagship consumer. The architectural difference from an inbox trustlet is the API surface and the enclave-versus-process model: a VBS Enclave is a region inside an existing process's address space, not a separately scheduled process. The threat model is identical: the host (the rest of the process, including its VTL0 code) is the attacker, the enclave is the defender [@pulapaka-vbs-enclaves].

Roster table

Trustlet ID	Binary	VTL0 agent	ALPC endpoint	Secret / operation	Source
0	Secure Kernel Process	(internal; no external agent)	(internal)	Device Guard / HVCI policy decisions	[@ionescu-bh2015]
1	`LsaIso.exe`	`lsass.exe`	`LSA_ISO_RPC_SERVER`	NTLM hashes, Kerberos TGTs; `EncryptData` / `DecryptData`	[@msdocs-credential-guard] [@ionescu-bh2015]
2	`vmsp.exe`	`vmwp.exe` (per partition)	per-instance, partition GUID scoped	Hyper-V vTPM, host side; secure storage `Get`	[@ionescu-bh2015] [@msdocs-guarded-fabric]
3	vTPM provisioning trustlet	(Hyper-V provisioning agent)	per-instance, partition GUID scoped	Initial secret provisioning; secure storage `Set`	[@ionescu-bh2015]
(unpublished)	ESS face-algorithm component	Hello biometric pipeline; sensor-issued cert auth	not publicly named	Face template matching (fingerprint matching under ESS is match-on-sensor)	[@msdocs-ess]
(unpublished)	Administrator Protection issuer	UAC / Authorization Manager broker	not publicly named	Just-in-time admin token issuance	[@msdocs-admin-protection]
(third-party)	VBS Enclave DLL	host process (`CreateEnclave` caller)	direct calls via `CallEnclave`	Application-defined; e.g., Azure SQL Always Encrypted	[@msdocs-vbs-enclaves] [@pulapaka-vbs-enclaves]

The published authoritative trustlet list still stops at Trustlet IDs 0-3 from August 2015. Every roster published after that point has been inferred from secondary evidence: kernel symbols, ALPC port enumeration via NtQuerySystemInformation, documented architectural placements. Microsoft has not republished an authoritative roster for any later Windows release.

Two trustlets in the list above are *architecturally* trustlets per Microsoft's published documentation but have not been publicly named or numbered. The ESS face-algorithm matcher is documented to live in VBS-isolated memory, with sensor-certificate authentication and template-encryption keys held in VBS, but the binary's name and Trustlet ID are not on the public record [@msdocs-ess]. The Administrator Protection token issuer's implementation surface is even less precisely specified -- "a hidden, system-generated, profile-separated user account" inside "a new security boundary," but no commitment to whether the issuer is a trustlet, a VBS Enclave, or a separate isolated process [@msdocs-admin-protection]. This article will not invent names or numbers for either. Empirical enumeration via `NtQuerySystemInformation(SystemIsolatedUserModeInformation)` on a current Windows 11 build is the only way to obtain a current roster, and that route is outside the scope of this piece.

Note: Credential Guard prevents the memory-resident NTLM hash or Kerberos TGT from being read out of VTL0. It does not protect typed-in credentials, the agent-side relay surface, plaintext-secret protocols (CredSSP / NTLMv1 / MS-CHAPv2 / Digest), or liveness; the full four-item enumeration with citations lives in Section 10. Microsoft documents one corner of the limit verbatim: Credential Guard "doesn't prevent an attacker with malware on the PC from using the privileges associated with any credential" [@msdocs-credential-guard].

The published roster stops at Trustlet IDs 0-3 from 2015. The actual roster on a 2026 box is bigger. How much bigger Microsoft hasn't said. That is one of the open problems Section 9 will pick up.

7. Competing Approaches

Microsoft is not alone. The same threat model -- "protect user-mode code from a compromised OS kernel" -- has been answered six other ways. None is strictly better than a trustlet. None is strictly worse. The right answer depends on what platform you are on, what threat model you have, and what workload you are trying to protect.

A hardware-enforced or hypervisor-enforced execution context whose memory and state are inaccessible to the surrounding host operating system, including its kernel. The Open Mobile Terminal Platform (OMTP) first defined the term, and GlobalPlatform now publishes the standard APIs (TEE Client API for the host, TEE Internal Core API for the trusted code). Windows trustlets, Intel SGX enclaves, ARM TrustZone Trusted Applications, AMD SEV-SNP confidential VMs, Apple's Secure Enclave, and seL4 user-mode security servers are all variants of TEE [@wiki-tee].

Intel SGX

Software Guard Extensions launched with the sixth-generation Intel Core processors (Skylake) in 2015 [@wiki-sgx]. SGX adds two CPU instructions with different privilege requirements: ENCLS (ring 0; the OS issues leaves like ECREATE on behalf of a user-mode application) and ENCLU (ring 3; the application issues leaves like EENTER and EEXIT to enter and leave its enclave) [@intel-sdm-sgx]. The result is a user-mode-controllable enclave whose memory is encrypted on the way out of the CPU's Enclave Page Cache to DRAM. The CPU microcode itself, plus the Quoting Enclave, is the TCB. Neither the OS kernel nor the hypervisor sits in the trust path.

That sounded ideal in 2015. It has not aged well. Foreshadow (USENIX Security 2018, Van Bulck et al.) demonstrated that transient-execution attacks could extract not only enclave memory but the platform's attestation key [@foreshadow-usenix]. The Foreshadow team's site states the consequence:

Foreshadow demonstrates how speculative execution can be exploited for reading the contents of SGX-protected memory as well as extracting the machine's private attestation key... due to SGX's privacy features, an attestation report cannot be linked to the identity of its signer. Thus, it only takes a single compromised SGX machine to erode trust in the entire SGX system. -- Foreshadow project site [@foreshadow-attack-eu]

SGAxe (attestation-key extraction) [@sgaxe], Plundervolt (software-controlled undervolting to fault SGX computations) [@plundervolt], SgxPectre (branch-target injection across the enclave boundary) [@sgxpectre], and others followed. Intel deprecated SGX on 11th-generation Core and later client CPUs, which incidentally removed Ultra HD Blu-ray playback on officially licensed software including PowerDVD [@wiki-sgx]. SGX continues on Xeon for confidential cloud workloads but is no longer a target architects pick on Windows clients.The Ultra HD Blu-ray collapse is the closest the SGX deprecation has come to mainstream visibility. PowerDVD's SGX dependency meant that a client SGX deprecation broke a consumer product line, and Cyberlink had to ship updates rerouting around the dropped CPU feature.

AMD SEV-SNP and Intel TDX

AMD's Secure Encrypted Virtualization with Secure Nested Paging (SEV-SNP), introduced on EPYC 7003 (Milan, launched 15 March 2021) [@wiki-amd-epyc], and Intel's Trust Domain Extensions (TDX), introduced on 4th-generation Xeon Scalable (Sapphire Rapids, launched 10 January 2023) [@wiki-sapphire-rapids], provide whole-VM confidential computing [@amd-sev-overview] [@intel-tdx-overview]. AMD's verbatim claim: "SEV-SNP adds strong memory integrity protection to help prevent malicious hypervisor-based attacks like data replay, memory re-mapping, and more to create an isolated execution environment" [@amd-sev-overview]. Intel's verbatim claim about TDX: "A CPU-measured Intel TDX module enables Intel TDX. This software module runs in a new CPU Secure Arbitration Mode (SEAM) as a peer virtual machine manager (VMM)" [@intel-tdx-overview]. The AMD SEV-SNP whitepaper "Strengthening VM Isolation with Integrity Protection and More" is the canonical technical reference [@amd-sev-snp-whitepaper].

The granularity is different from a trustlet. SEV-SNP and TDX isolate an entire virtual machine from its hypervisor and host. They do not isolate a process from its own VM's kernel. For "this user-mode process should be protected from a SYSTEM kernel write primitive on the same OS," a trustlet is the primitive; for "this entire VM should be protected from a compromised cloud provider," a CVM is the primitive. Use the right one.

ARM TrustZone and OP-TEE

The two-world hardware split that has shipped on every Cortex-A processor since the mid-2000s -- the Wikipedia ARM architecture article states verbatim that "the Security Extensions, marketed as TrustZone Technology, is in ARMv6KZ and later application profile architectures," the lineage every Cortex-A core inherits [@wiki-arm-architecture]. The CPU enforces a Non-Secure World and a Secure World; switching between the two is mediated by a Secure Monitor Call (SMC) instruction. OP-TEE is the canonical open-source secure-world OS for Cortex-A TrustZone, with Trusted Applications running as user-mode binaries in Secure World EL-0 and the OP-TEE OS itself running at EL-1 [@optee-about]. The OP-TEE about page describes the design: "OP-TEE is a Trusted Execution Environment (TEE) designed as companion to a non-secure Linux kernel running on Arm; Cortex-A cores using the TrustZone technology" [@optee-about].

TrustZone is the closest non-Windows analogue to a trustlet at the architectural level. The vocabulary maps one for one.

Concept	Windows VBS / IUM	ARM TrustZone / OP-TEE
Isolation primitive	Hyper-V hypervisor + SLAT	TrustZone Address Space Controller; CPU NS/S bit
Secure-side kernel	Secure Kernel (VTL1 ring 0)	OP-TEE OS (Secure World EL-1)
Secure-side user mode	IUM (VTL1 ring 3)	Trusted Applications (Secure World EL-0)
Agent / supplicant	The trustlet's VTL0 agent (e.g., `lsass.exe`)	`tee-supplicant` and TEE Client API on the Linux side
Trust gate	Microsoft EKUs + Signature Level 12	OP-TEE TA signing key configured at build time

Apple Secure Enclave Processor (SEP)

Apple's answer is a dedicated on-die security subsystem. SEP is a separate processor core, isolated from the Application Processor on the same SoC, with its own boot ROM, its own AES engine, and its own random number generator. It has been in every iPhone since iPhone 5s (2013), every Apple Silicon Mac, every Apple Watch from Series 1 [@apple-sep]. Apple's verbatim description:

The Secure Enclave Processor runs an Apple-customized version of the L4 microkernel. It's designed to operate efficiently at a lower clock speed that helps to protect it against clock and power attacks [@apple-sep].

SEP is the strongest counter to microarchitectural side channels among the production options, because the cores genuinely do not share microarchitectural state with the Application Processor. The price is that everything is firmware-class: patching a SEP bug means rolling SEP firmware on every Apple device, not pushing an OS update. The cycle is slower and more centralised.

seL4 plus user-mode security servers

The academic conscience of the lineage. About 8,700 lines of formally verified C, with machine-checked proofs of functional correctness, confidentiality, and integrity [@sel4-sosp-paper] [@sel4-about]. Sub-microsecond IPC. The price is that seL4 is a separation microkernel, not a desktop OS; building a Credential-Guard-equivalent on seL4 means designing the application architecture from the microkernel up, not retrofitting it onto a Windows-compatible stack. seL4 has shipping deployments in defence (the DARPA HACMS programme), automotive ECUs, and Qualcomm's Hexagon DSP secure OS.

When to pick which

A decision table of the kind a colleague would actually use.

You want	Pick
Protect a user-mode Windows process from a SYSTEM kernel write primitive	Trustlet (inbox) or VBS Enclave (third-party) [@msdocs-vbs-enclaves]
Protect an entire VM from your cloud provider's host	AMD SEV-SNP or Intel TDX [@amd-sev-overview] [@intel-tdx-overview]
Protect a user-mode Linux-on-ARM service from a compromised Linux kernel	TrustZone + OP-TEE Trusted Application [@optee-about]
Hold an iPhone owner's Touch ID / Face ID template safely from iOS	Apple SEP [@apple-sep]
Build a high-assurance system with a machine-checked proof of kernel correctness	seL4 [@sel4-sosp-paper]
Run Intel SGX enclaves on Xeon for confidential cloud	SGX (modulo Foreshadow-class side channels) [@foreshadow-attack-eu]

Trustlets are the right answer for Windows. They are not the right answer for every platform, every threat model, or every workload. They are also not without limits on Windows itself. What are those?

8. The Floor of the Threat Model

By 2020 the trustlet model had been shipping for five years. Two researchers at the Microsoft Security Response Center, Saar Amar and Daniel King, pointed a fuzzer at the secure-call interface for two weeks and reported back with five VTL0-to-VTL1 bugs [@amar-bh2020]. Their Black Hat USA 2020 talk, "Breaking VSM by Attacking Secure Kernel," is the most important public document on what the trustlet model actually guarantees and what it does not [@amar-publications].

The talk is honest in a way Microsoft is rarely honest about its own products. The slides enumerate the bugs by CVE number, name the specific Secure Kernel routines they exploited, and -- unusually -- list the hardening changes Microsoft shipped because of what was found. Reading the deck is the closest thing to a Q-and-A with the Secure Kernel team.

Bug class 1: the secure-call interface is the floor

The Secure Kernel exposes about three dozen "secure services" callable from VTL0 via the IumInvokeSecureService dispatcher. Each takes a parameter block from VTL0, parses it inside VTL1, and returns. That dispatcher is, by definition, the largest VTL0-controllable input surface in the model. Amar and King retargeted the Hyperseed hypercall fuzzer, originally written by Daniel King and Shawn Denbow for hypercall fuzzing, at securekernel!IumInvokeSecureService [@amar-bh2020]. Two weeks of fuzzing produced five bugs.

Two of them shipped with public CVE numbers in 2020. CVE-2020-0917 is an out-of-bounds read in the secure-call surface; CVE-2020-0918 is a design flaw in SkmmUnmapMdl where a VTL0 caller could pass a fully attacker-controlled Memory Descriptor List to SkmiReleaseUnknownPTEs [@nvd-cve-2020-0917] [@nvd-cve-2020-0918] [@amar-bh2020]. The NVD entries describe both with the same boilerplate ("Windows Hyper-V Elevation of Privilege Vulnerability") and classify the CWE as "Insufficient Information"; the technical detail lives in the Amar/King deck.

Microsoft hardened in response. The Amar/King deck enumerates what changed:

The Secure Kernel pool moved to segment heap in mid-2019, breaking the heap layout the public exploit depended on.
Four W+X regions in VTL1 were reduced to +X only, eliminating attacker-controlled code-injection targets.
SkpgContext, a HyperGuard-style control-flow integrity check for the Secure Kernel, was introduced [@amar-bh2020].

Alex Ionescu's term for an attacker-controlled trustlet, enabled by a substrate compromise rather than a trustlet bug. If Test Signing is on, or if a production Microsoft signing key leaks, or if Secure Boot can be bypassed, an attacker can sign and load their own "trustlet" that passes the five gates of Section 5 and operates with VTL1 privilege. The trustlet model itself remains intact; the trust roots underneath it are what fail [@ionescu-bh2015].

Bug class 2: denial of service is not a security boundary

Amar's deck states the rule that excludes liveness from the VBS threat model verbatim:

VTL0 can DOS VTL1 by design. -- Saar Amar and Daniel King, Black Hat USA 2020 [@amar-bh2020]

The hypervisor schedules VTL1; VTL0 is the agent for almost every communication channel into VTL1; VTL0 can stop talking to VTL1 at any time. None of this is, in Microsoft's stated model, a security violation. A VTL0 kernel attacker who can prevent Credential Guard from issuing tickets has not stolen any credential; they have, in the language of the threat model, achieved denial of service, which is out of scope. This matters in practice: a defender cannot reason about a trustlet "always being available." They can only reason about its memory not being readable from VTL0 when it is available.

Bug class 3: the agent RPC surface lives in VTL0

The trustlet's pages are safe even from VTL0 ring 0. The agent process that services the trustlet's ALPC port is not safe. The agent is lsass.exe for Credential Guard, vmwp.exe for the vTPM, presumably the Hello biometric pipeline for ESS. Every byte of every protocol whose state machine the agent implements is reachable from VTL0. The hash never leaves VTL1; the authentication outcomes the hash produces can be relayed.

In December 2022 Oliver Lyak published "Pass-the-Challenge: Defeating Windows Defender Credential Guard" [@lyak-pass-the-challenge]. The technique recovers usable NTLM challenge responses from encrypted credential blobs that LsaIso.exe returns to lsass.exe in VTL0:

In this blog post, we present new techniques for recovering the NTLM hash from an encrypted credential protected by Windows Defender Credential Guard. While previous techniques for bypassing Credential Guard focus on attackers targeting new victims who log into a compromised server, these new techniques can also be applied to victims logged on before the server was compromised [@lyak-pass-the-challenge].

A network authentication protocol that uses NTLM works in challenge-response form: the server sends a challenge, the client encrypts it with its NTLM hash, the server (or a domain controller) verifies the response. With Credential Guard, the client's NTLM hash lives in `LsaIso.exe`; only `LsaIso.exe` can perform the encryption. A VTL0 attacker who can talk to `lsass.exe` can ask `lsass.exe` to ask `LsaIso.exe` to compute an NTLM response for an attacker-supplied challenge. The attacker never sees the hash; they see an authentication response computed with it. Many real-world relay attacks need only the response, not the hash. Lyak's writeup is the worked example; the architectural fact is that the agent RPC channel is a VTL0 surface even though the hash itself is not.

Microsoft documents one corner of the limit verbatim: Credential Guard "doesn't prevent an attacker with malware on the PC from using the privileges associated with any credential" [@msdocs-credential-guard]. The "use" is the agent-side operation; the trustlet is doing the cryptography, and the cryptography is being used by the attacker.

Bug class 4: trustlet-to-trustlet via shared Instance GUIDs

Trustlets that share an Instance GUID can read and write storage blobs the Secure Kernel scopes per-Instance. The pair vmsp.exe and the vTPM provisioning trustlet uses exactly this primitive: provisioning writes, vmsp.exe reads, the Secure Kernel hard-codes which Trustlet IDs may invoke SecureStorageSet versus SecureStorageGet on each Instance GUID. The defence is in the SkCapabilities table; bugs in that table are exploit-class.

In Ionescu's vocabulary, a "malwarelet" is the worst case here: an attacker-controlled trustlet -- enabled by a Secure Boot or Test Signing compromise -- could request access to the Instance GUIDs of other trustlets, and any missing rule in SkCapabilities would let it read what those trustlets stored. There are no public exploits in this class as of mid-2026. There also is not a published audit of the table.

Bug class 5: substrate compromise (Secure Boot, firmware, signing keys)

If Test Signing is on; if a production signing key leaks; if Secure Boot can be bypassed to boot a kernel that accepts attacker-controlled trustlet roots; if the UEFI firmware itself permits a DMA attack against early-boot memory -- the entire trustlet model is moot. Ionescu's BH2015 deck states the diagnosis: "VBS' key weakness is its reliance on Secure Boot" [@ionescu-bh2015]. Rafal Wojtczuk's Black Hat USA 2016 attack-surface analysis empirically validated the warning, demonstrating one non-critical VBS-feature bypass and one critical firmware exploit [@wojtczuk-bh2016]. The firmware below VBS is the substrate trustlets sit on; the trustlet model is no stronger than that substrate.

flowchart TD Attacker["VTL0 kernel attacker"] SK["Secure Kernel"] Trustlet["Trustlet (VTL1 user)"] Agent["VTL0 agent process (lsass.exe, vmwp.exe...)"] Substrate["Substrate: UEFI firmware, Secure Boot, signing roots"] Attacker -->|"1. Secure-call interface bugs
CVE-2020-0917, CVE-2020-0918"| SK Attacker -->|"2. DoS by design (out of scope)"| SK Attacker -->|"3. Agent RPC surface
Pass-the-Challenge"| Agent Agent -->|"authentication outcome"| Trustlet Attacker -->|"4. Trustlet-to-trustlet
via shared Instance GUID"| Trustlet Substrate -->|"5. Substrate compromise
malwarelets, BootHole-class"| SK Substrate --> Trustlet

The Hyperseed fuzzer had a prior life. Daniel King and Shawn Denbow first presented it at OffensiveCon 2019 as a hypercall fuzzer [@amar-bh2020]. The retargeting at the secure-call interface is the same tool, pointed at a different parser. The two-weeks-five-bugs result is therefore not "Microsoft wrote bad code" but "a well-built fuzzer aimed at a complex parser will find bugs in ~2 weeks." That is the empirical bar for an unverified TCB.

Key idea: The trustlet model is hypervisor-strong against the VTL0 kernel; it is not stronger than the substrate it sits on. Five attack classes -- secure-call interface bugs, designed-out denial-of-service, the agent RPC residual, trustlet-to-trustlet via shared Instance GUIDs, and substrate compromise -- bound what the model can guarantee. None of them invalidates trustlets; all of them are reasons to deploy trustlets alongside other controls rather than as a sole defence.

The trustlet model has a finite, audited attack surface. The surface is not zero. Liveness is not promised. The firmware and Secure Boot underneath everything still matter. What is new on this surface in 2024 to 2026?

9. Open Problems

Three things you might expect Microsoft to have published by 2026 -- the current inbox trustlet roster, an architecture diagram of Administrator Protection on par with Credential Guard's, and a public CVE wave around VBS Enclaves -- are still partial or missing. Here is the frontier.

1. Trustlet enumeration drift. Ionescu's August 2015 enumeration of Trustlet IDs 0 through 3 remains the only authoritative published list. Eleven years later, the ESS biometric matcher has not been named with a Trustlet ID and the Administrator Protection issuer has not been committed to as a trustlet at all. A researcher with a debugger and the Quarkslab IUM-debugging recipe can recover the current roster empirically [@quarkslab-debug-ium]; Microsoft has not republished it.

2. VBS Enclave trust-boundary hardening. Microsoft's Security Response Center published a blog post in June 2025 -- "Everything Old Is New Again" -- explicitly committing to host-to-enclave pointer validation, copy-before-check discipline, and TOCTOU avoidance as the active hardening surface for VBS Enclaves [@ms-everything-old]. The post is unambiguous that a CVE wave is foreseeable as researchers turn their attention to the host-enclave seam. As of the publication of this article no public CVE has been issued against a VBS Enclave-using product, but Microsoft's narrowing of supported Windows builds in 2025 (from "Windows 11 24H2 or later" to "Windows 11 Build 26100.2314 or later") is the kind of build-floor adjustment that historically precedes a documented hardening change [@msdocs-vbs-enclaves].

3. Side channels against VTL1. Transient-execution attacks against VTL1 memory have not been publicly demonstrated end to end. The Foreshadow class of attacks against SGX is the existence proof that a co-resident TEE can leak through microarchitectural side channels, and the threat model explicitly includes them [@foreshadow-attack-eu]. There is no VBS-specific transient-execution mitigation; platform-wide mitigations (Kernel Virtual Address Shadow, Retpoline, Indirect Branch Restricted Speculation) are the only defence. A demonstration of "Foreshadow-against-LsaIso" would not be surprising; its absence to date is, given the research community's interest, mildly so.

4. Debugging asymmetry. Researchers have a working trustlet-debugging recipe; defenders have an explicit "no" from Microsoft. The Quarkslab writeup walks through nested virtualisation to attach to a trustlet under controlled conditions [@quarkslab-debug-ium]; Microsoft's product-facing page states verbatim that "it is not possible to attach to an IUM process" and that "other APIs, such as CreateRemoteThread, VirtualAllocEx, and Read/WriteProcessMemory will also not work as expected when used against Trustlets" [@msdocs-ium]. The asymmetry favours offence: an attacker with the time, hardware, and tooling Quarkslab demonstrates can study trustlet internals in ways a defender on a production box cannot. Live-system trustlet introspection for incident response is the missing capability.

5. Administrator Protection transparency. As of 10 May 2026, the Administrator Protection feature has been shipped in preview (KB5067036, 28 October 2025), then reverted in the same update note pending a future re-rollout [@kb5067036] [@msdocs-admin-protection]. There is no architecture diagram on the level of Credential Guard's "how it works" page. There is no published Trustlet ID. There is no public commitment to whether the token issuer is a trustlet, a VBS Enclave, or something else inside the new security boundary. For a feature that materially changes the local-elevation model of Windows, that is unusual reticence.

6. Cross-architecture portability. A workload that wants to run as a trustlet on Windows, a Confidential VM on Linux, a Trusted Application on ARM, and a Secure Enclave Application on Apple silicon must, today, be written four times. GlobalPlatform's TEE Client API standardises one side of TrustZone, the Open Enclave SDK abstracts a subset of SGX and TrustZone, and VBS Enclaves do their own thing. No universal portable TEE API exists. For workloads where portability matters more than peak isolation, this is the open problem with the most direct commercial pressure behind it.

Two answers, both incomplete. The defensive answer: an enumerated trustlet list is an attacker's targeting list, and Microsoft prefers not to publish targeting lists for components whose exact attack surface is still under active study. The historical answer: the 2015 list was a side-effect of Ionescu reverse-engineering Windows 10 RTM. There has been no comparable public reverse-engineering push for any post-2015 Windows release at the same level of completeness, and Microsoft has not chosen to fill the gap with first-party documentation. Empirical enumeration via `NtQuerySystemInformation(SystemIsolatedUserModeInformation)` works on a live system, but doing it on every Windows 11 servicing build is a research programme, not a citation.

These are questions a researcher with a year of grant time could move the field on. The next section is the question a practitioner has today.

10. Practitioner Guide

What changes in a real workflow once you know what a trustlet is? Four short answers.

Windows administrator

Verify Credential Guard is actually running before you assume it is. Two ways.

Note: GUI: Run msinfo32 and check Virtualization-based security Services Running. You should see at least "Credential Guard" and ideally "Hypervisor enforced Code Integrity." PowerShell: Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard. The properties SecurityServicesRunning and VirtualizationBasedSecurityStatus are the load-bearing ones; values of 1 and 2 respectively indicate Credential Guard is running with VBS in full enforcement [@msdocs-credential-guard].

Enumerating live trustlets on a 2026 box requires more care than enumerating ordinary processes. Process Explorer's Image tab carries an IUM marker for trustlet processes. SysInternals Sigcheck on a candidate binary surfaces the Signing Level. The Microsoft Learn IUM page is explicit that "other APIs, such as CreateRemoteThread, VirtualAllocEx, and Read/WriteProcessMemory will also not work as expected when used against Trustlets" [@msdocs-ium] -- the same APIs many EDR products rely on for behavioural monitoring will silently fail or report sentinel values when targeted at a trustlet. Plan detections accordingly.

Security researcher

The Quarkslab blog post "Debugging Windows Isolated User Mode (IUM) Processes" is the canonical recipe for attaching to a trustlet under nested virtualisation [@quarkslab-debug-ium]. The empirical enumeration path is NtQuerySystemInformation with class SystemIsolatedUserModeInformation; the structure returned includes a count of running trustlets and their identifying metadata.The driver-side pattern Microsoft documents for "is this process a trustlet?" is IsSecureProcess, an internal Win32K predicate the IUM page names as the canonical check. Tools that need to behave differently against trustlets (memory scanners, integrity checkers, EDR sensors) should call the supported equivalent rather than parsing process attributes by hand [@msdocs-ium].

Application developer (VBS Enclaves)

If you are writing third-party code that needs trustlet-class isolation, the primitive you target is a VBS Enclave, not a trustlet. The toolchain is specific:

Visual Studio 2022 version 17.9 or later.
Windows SDK version 10.0.22621.3233 or later (provides veiid.exe, the VBS Enclave import ID binding utility, and signtool.exe).
A Trusted Signing account for production signing [@msdocs-vbs-enclaves].

The architectural rule is never trust the host. The host process's address space is reachable by the enclave; the enclave's address space is not reachable by the host. Range-validate every pointer the host hands the enclave; copy before you check (so the host cannot mutate the data between your check and your use); avoid TOCTOU windows. Microsoft's "Everything Old Is New Again" post is explicit that this is the hardening surface researchers are looking at right now [@ms-everything-old].

The development guide includes a sample with a comment that captures the discipline:

Every DLL loaded in an enclave requires a configuration. This configuration is defined using a global const variable named __enclave_config of type IMAGE_ENCLAVE_CONFIG... // DO NOT SHIP DEBUGGABLE ENCLAVES TO PRODUCTION [@msdocs-vbs-enclaves-dev-guide].

The IMAGE_ENCLAVE_POLICY_DEBUGGABLE flag is for development only. The VbsEnclaveTooling repository on GitHub provides a NuGet package and a code generator that make the cross-VTL marshalling less error-prone, plus reference documentation including Edl.md, HelloWorldWalkthrough.md, and CodeGeneration.md [@vbs-enclave-tooling].

1. Confirm OS support: Windows 11 Build 26100.2314+ or Windows Server 2025+ [@msdocs-vbs-enclaves]. 2. Install Visual Studio 2022 17.9+ and Windows SDK 10.0.22621.3233+. 3. Acquire a Trusted Signing account; configure `signtool.exe` for it. 4. Define `__enclave_config` as `IMAGE_ENCLAVE_CONFIG`; set family/image/SVN fields. 5. Use `veiid.exe` to bind import IDs. 6. Sign the enclave DLL with `signtool.exe` and the Trusted Signing certificate. 7. Test with `IMAGE_ENCLAVE_POLICY_DEBUGGABLE` set; remove it before production. 8. Range-validate every host-supplied pointer; copy before check.

Defender

Know what Credential Guard does not protect, because that is where most exposure remains.

Note: The trustlet protects memory-resident NTLM hashes and Kerberos TGTs from a VTL0 kernel attacker. It does not protect: - Supplied credentials at the logon prompt (keyloggers, screen-scrapers, hardware shimming). - The agent RPC channel (Pass-the-Challenge-class relay against lsass.exe is reachable from VTL0) [@lyak-pass-the-challenge]. - Protocols that require a usable secret in plaintext: CredSSP, NTLMv1, MS-CHAPv2, Digest. These are unsupported with the trustlet-protected token by design [@msdocs-credential-guard]. - Liveness: a VTL0 kernel attacker can stop talking to VTL1 and prevent the trustlet from being available. Denial of service is out of the VBS threat model [@amar-bh2020]. The summary: trustlets shrink the credential-theft attack surface, they do not eliminate it.

The trustlet model is finite, audited, and useful. Use the lock; do not assume the lock is the only thing on the door.

11. Frequently asked questions

No. Protected Process Light (PPL) and trustlets sit in the same lineage but differ at the architectural level. A PPL is enforced by the NT kernel, which is also the attacker's likely foothold; itm4n's 2021 PPLdump showed the result over eight years of LSASS-as-PPL deployment [@itm4n-runasppl]. A trustlet is enforced by the Hyper-V hypervisor and the Secure Kernel, both running in a different Virtual Trust Level from the NT kernel; a VTL0 kernel write primitive does not touch the trustlet's pages [@quarkslab-debug-ium]. The signing-level lattice is similar (both rely on Signature Level 12); the enforcement architecture is not. Not directly. Inbox trustlets require the Microsoft IUM EKU (`1.3.6.1.4.1.311.10.3.37`), which Microsoft does not grant to third parties [@ionescu-bh2015]. Since Windows 11 24H2, the third-party-shippable equivalent is a VBS Enclave: a DLL signed with a Trusted Signing certificate, loaded into an enclave region of a host process via `CreateEnclave` and `CallEnclave`. The architectural threat model is identical (the host is the attacker, the enclave is the defender); the API surface and the enclave-versus-process model differ. VBS Enclaves require Windows 11 Build 26100.2314 or later, Windows SDK 10.0.22621.3233 or later, Visual Studio 2022 17.9 or later, and a Trusted Signing account [@msdocs-vbs-enclaves]. No. It means that the *memory-resident* NTLM hash or Kerberos TGT cannot be read out of `LsaIso.exe` by a VTL0 kernel attacker. It does not mean credentials are unstealable. Section 10 enumerates the four classes of residual exposure -- typed-in credentials, the agent-side RPC relay (Pass-the-Challenge) [@lyak-pass-the-challenge], plaintext-secret protocols (CredSSP / NTLMv1 / MS-CHAPv2 / Digest are unsupported with the trustlet-protected token), and liveness (denial of service against VTL1 is out of the VBS threat model) -- with citations [@msdocs-credential-guard] [@amar-bh2020]. For that trustlet, yes; for the model, by design. The Secure Kernel plus trustlets are the VBS TCB. Amar and King's 2020 work demonstrated practical VTL0-to-VTL1 vulnerabilities (CVE-2020-0917, CVE-2020-0918) [@amar-bh2020] [@nvd-cve-2020-0917] [@nvd-cve-2020-0918]; Microsoft hardened in response, moving the Secure Kernel pool to segment heap, reducing four W+X regions to +X only, and introducing `SkpgContext` HyperGuard for VTL1 [@amar-bh2020]. The surface remains finite and audited; the trustlet model is hypervisor-strong against the VTL0 kernel and not stronger than the substrate it sits on. Not on ESS-capable systems. The Microsoft Learn page is clear that *"when ESS is enabled, the face algorithm is protected using VBS to isolate it from the rest of Windows... The hypervisor is used to specify and protect memory regions, so that they can only be accessed by processes running in VBS"* [@msdocs-ess]. The biometric *template* is encrypted with VBS-only keys and lives in VBS-isolated memory. The TPM still has a role -- it holds the per-user Hello *private keys* that authenticate against the local credential provider -- but the biometric template itself does not live in the TPM [@msdocs-tpm]. No. The Microsoft Learn page describes the new model: an authorised user triggers a Windows Hello-backed prompt; Windows then *"uses a hidden, system-generated, profile-separated user account to create an isolated admin token. This token is issued to the requesting process and is destroyed once the process ends"* [@msdocs-admin-protection]. The in-session prompt is still there; the elevated token's *origin* is what changed (from a split-token impersonation of the same account to a transient system-generated admin account). The October 2025 preview shipped in KB5067036 and was then reverted in the same update note pending a future rollout [@kb5067036]. As of 10 May 2026 the feature is not generally available.

<StudyGuide slug="vbs-trustlets-what-actually-runs-in-the-secure-kernel" keyTerms={[ { term: "Trustlet", definition: "A user-mode process running in VTL1 user mode, scheduled by the Secure Kernel, isolated from VTL0 by per-VTL SLAT permissions. Defined by passing five load-time gates." }, { term: "Virtual Trust Level (VTL)", definition: "A hypervisor-managed privilege axis added on top of x86 rings. Currently two VTLs are implemented out of an architecturally supported sixteen." }, { term: "Isolated User Mode (IUM)", definition: "Ring 3 of VTL1. The user-mode environment trustlets run in. Restricted to about 48 of NT's ~480 syscalls." }, { term: "Secure Kernel", definition: "The kernel that runs in VTL1 ring 0. Schedules trustlets, parses .tpolicy sections, enforces SkCapabilities rules on secure-call invocations." }, { term: "IUM EKU", definition: "The Enhanced Key Usage OID 1.3.6.1.4.1.311.10.3.37. Required alongside the Windows System Component Verification EKU for a binary to be loaded as a trustlet at Signature Level 12." }, { term: "Trustlet Instance GUID", definition: "A runtime identifier the Secure Kernel uses to scope per-instance secrets. Set via IumSetTrustletInstance; shared between cooperating trustlets (e.g., vmsp.exe and the vTPM provisioning trustlet) so they can read each other's storage blobs under SkCapabilities control." }, { term: "Malwarelet", definition: "Ionescu's term for an attacker-controlled trustlet, enabled by a Test Signing or Secure Boot compromise rather than by a trustlet-internal bug." }, { term: "ALPC", definition: "Asynchronous Local Procedure Call: Windows IPC primitive used by VTL0 agent processes to communicate with their VTL1 trustlet counterparts." } ]} questions={[ { q: "Name the five gates a Windows binary must pass at load time to become a trustlet.", a: "(1) PsAttributeSecureProcess process attribute with a 64-bit Trustlet ID. (2) Two EKUs at Signature Level 12: Windows System Component Verification (1.3.6.1.4.1.311.10.3.6) and IUM (1.3.6.1.4.1.311.10.3.37). (3) A .tpolicy PE section exporting s_IumPolicyMetadata with matching Trustlet ID. (4) A Trustlet Instance GUID bound via IumSetTrustletInstance. (5) The stripped-down LdrpIsSecureProcess loader path." }, { q: "Why does a SYSTEM-privilege NT-kernel write primitive on Windows 11 25H2 fail to read LsaIso.exe memory?", a: "Because the NT kernel runs in VTL0, LsaIso.exe runs in VTL1, and the Hyper-V hypervisor configures per-VTL SLAT entries that refuse VTL0 read access to VTL1-only pages. The attacker's kernel write primitive can edit NT kernel structures but cannot change the hypervisor-managed SLAT entries." }, { q: "What does Pass-the-Challenge demonstrate about the limits of Credential Guard?", a: "That while the NTLM hash itself never leaves VTL1, the agent process (lsass.exe in VTL0) can be asked to ask the trustlet to compute an authentication response for an attacker-supplied challenge. The resulting response is reachable by the VTL0 attacker and is sufficient for many relay attacks. The hash is protected; the authentication outcomes it produces are not." }, { q: "What is the practical floor of the trustlet attack surface that Amar and King exposed at Black Hat USA 2020?", a: "The secure-call interface (IumInvokeSecureService) parses VTL0-controlled inputs in VTL1. Hyperseed retargeted at it found five VTL0->VTL1 bugs in two weeks, including CVE-2020-0917 (OOB read in the secure-call surface) and CVE-2020-0918 (SkmmUnmapMdl design flaw). Microsoft responded with segment-heap migration, W+X reduction, and SkpgContext (Secure Kernel HyperGuard)." }, { q: "What is the third-party equivalent of an inbox trustlet on Windows 11 24H2 and later?", a: "A VBS Enclave: a DLL signed with a Trusted Signing certificate and loaded into an enclave region of a host process via CreateEnclave / CallEnclave. Requires Windows 11 Build 26100.2314 or later, Windows SDK 10.0.22621.3233 or later, and Visual Studio 2022 17.9 or later." } ]} />

When SYSTEM Isn't Enough: The Windows Secure Kernel and the End of Total Kernel Trust

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

**The Windows Secure Kernel (securekernel.exe) is a minimal kernel running in a hardware-isolated environment (VTL1) above the main NT kernel, enforced by the Hyper-V hypervisor.** It protects credentials, code integrity, and application secrets even when an attacker has full control of the standard kernel. Born from the failure of software-only defenses like PatchGuard, it represents the biggest architectural shift in Windows security since the original NT reference monitor. It is not invulnerable -- rollback attacks and side-channel vulnerabilities remain open problems -- but it fundamentally changed what "kernel compromise" means on Windows.

When SYSTEM Isn't Enough

An attacker has achieved the holy grail: SYSTEM-level access on a domain-joined Windows machine. They load Mimikatz, point it at LSASS, and reach for the domain admin's Kerberos ticket. The command runs. The output comes back empty. The credentials are there -- the machine uses them every second -- but they're locked behind a wall that even full kernel access cannot breach.

Welcome to the world of the Windows Secure Kernel.

For decades, Windows security rested on a single hard boundary: user mode versus kernel mode. If you crossed that line -- if you achieved Ring 0 execution -- the system was yours. Every credential, every security policy, every secret was accessible. Tools like Benjamin Delpy's Mimikatz turned this architectural reality into a practical catastrophe, making Pass-the-Hash and Pass-the-Ticket attacks trivially easy across enterprise networks [@mimikatz-github].

But on a modern Windows 11 machine with Virtualization-Based Security (VBS) enabled, the rules have changed. A new trust boundary exists -- one enforced not by the kernel, but by the hypervisor running above the kernel. Even SYSTEM-level access in the traditional kernel cannot reach across this boundary [@ms-vbs].

If kernel mode gives you everything, what could possibly be above kernel mode? The answer requires a 30-year journey through Windows security.

The All-or-Nothing Kernel: How Windows NT Was Built

In 1988, Dave Cutler began designing Windows NT with a security model influenced by military security research -- especially the reference monitor concept, distinct from Bell-LaPadula's mandatory-access-control model. State-of-the-art for its era. It also contained a fatal assumption.

The core component of the Windows NT security architecture that mediates all access to securable objects (files, registry keys, processes) by checking Access Control Lists (ACLs) against the caller's security token. The SRM runs in kernel mode and enforces discretionary access control for every system operation.

The NT kernel drew a hard line between Ring 3 (user mode) and Ring 0 (kernel mode) [@custer-inside-nt]. User-mode processes could not directly access kernel memory. The Security Reference Monitor mediated all access to system objects. For the early 1990s, this was a significant advance over DOS and Windows 9x, where applications and the OS shared the same memory space with no isolation at all.Dave Cutler previously designed VMS at Digital Equipment Corporation (DEC). Many NT design principles -- including the SRM, the object manager, and the layered architecture -- trace directly back to VMS. The letters "WNT" are famously one character ahead of "VMS" in the alphabet.

But the NT model contained a fatal assumption: all kernel-mode code is equally trusted. Once a driver or exploit gained Ring 0 access, it shared the same address space and privilege level as the kernel itself. It could read and write any memory, modify the System Service Dispatch Table (SSDT), manipulate the Interrupt Descriptor Table (IDT), or unlink processes from the EPROCESS active process list.

This was the golden age of kernel-mode rootkits. Jamie Butler's FU rootkit (2004) used Direct Kernel Object Manipulation (DKOM) to unlink processes from the active process list, making malicious processes invisible to Task Manager, antivirus tools, and every other system utility [@hoglund-rootkits]. SSDT hooking allowed rootkits to intercept and redirect any system call, providing total control over OS behavior.

Mark Russinovich and Bryce Cogswell built the Sysinternals tools to make these kernel internals visible to defenders [@sysinternals-story]. Process Explorer, Filemon, and Regmon became essential diagnostic instruments. But visibility is not protection. Defenders could see the problem; they could not stop it.

Key idea: The NT kernel drew one hard line -- user mode versus kernel mode. When attackers crossed that line, there was nothing left to protect. Every security mechanism, every credential, every policy lived in the same flat address space. Microsoft needed to draw a new line.

Software Guards for a Hardware Problem: PatchGuard and Friends

What do you do when the prisoners are as powerful as the guards? You send in more guards at the same level. That was Microsoft's first strategy -- and its fundamental flaw.

A software-only kernel integrity monitor introduced in 2005 for 64-bit Windows. PatchGuard periodically checks critical kernel structures (SSDT, IDT, GDT, processor MSRs) for unauthorized modifications and forces a Blue Screen of Death (CRITICAL_STRUCTURE_CORRUPTION) if tampering is detected.

PatchGuard arrived in Windows XP x64 and Windows Server 2003 SP1 in 2005 [@wp-patchguard]. It used obfuscated, randomized integrity checks to detect unauthorized modifications to kernel structures. If it caught tampering, it triggered a BSOD. On the surface, this seemed like a strong defense.PatchGuard's internal implementation uses extensive obfuscation: randomized check intervals, encrypted context blocks, and self-protecting code that resists static analysis. Microsoft never published its internal design, treating security through obscurity as a deliberate delaying tactic against attackers.

Mandatory kernel-mode code signing followed with Windows Vista x64 in 2007, requiring all kernel drivers to carry a valid Authenticode signature [@ms-kmcs]. Data Execution Prevention (DEP) marked memory pages as non-executable [@ms-dep]. Address Space Layout Randomization (ASLR) randomized the memory layout of loaded modules [@ms-mitigations]. Supervisor Mode Execution Prevention (SMEP) blocked kernel code from executing user-mode memory pages [@ms-mitigations].

Each mitigation raised the cost of attack. Together, they made kernel exploitation significantly harder. But each one had a fatal weakness.

An attack technique where adversaries install a legitimately signed but vulnerable third-party driver, then exploit the driver's vulnerability to gain arbitrary kernel-mode code execution. Because the driver carries a valid signature, it bypasses kernel-mode code signing enforcement.

PatchGuard runs at Ring 0 -- the same privilege level as the attackers it monitors. In 2019, the InfinityHook project demonstrated how to hook kernel callbacks via the Event Tracing for Windows (ETW) subsystem without patching any kernel structures that PatchGuard checks [@infinityhook-github]. PatchGuard never noticed.

Kernel-mode code signing stops unsigned drivers but not signed-and-vulnerable ones. The BYOVD technique became a staple of advanced persistent threat (APT) groups: install a legitimately signed driver with a known vulnerability, exploit that vulnerability, and gain arbitrary kernel execution while all code signing checks pass [@ms-vuln-drivers].

DEP is bypassed by Return-Oriented Programming (ROP). Instead of injecting new code, attackers chain existing executable code snippets ("gadgets") to achieve arbitrary computation [@wp-rop]. ASLR has limited entropy on 32-bit systems and is defeated by information leaks that reveal randomized base addresses [@wp-aslr].

Benjamin Delpy released Mimikatz in 2011, and the security world was never the same. What began as a proof-of-concept for extracting plaintext passwords from LSASS memory became the single most-used credential theft tool in real-world attacks. Red teams used it. Nation-state actors used it. Ransomware gangs used it. The tool's existence -- more than any theoretical argument -- forced Microsoft to confront the fact that LSASS credentials in a flat kernel address space were indefensible. Credential Guard was Mimikatz's direct response [@mimikatz-github]. PatchGuard was a guard who could be knocked out by the very prisoners it watched. A defense sharing its privilege level with the attacker can always, given sufficient motivation, be subverted.

Key idea: No software-only defense can protect against an attacker at the same privilege level. This is not a fixable bug -- it is a structural limitation. PatchGuard delays attacks; it cannot prevent them. Microsoft needed something that kernel-mode code could not even reach.

Building the Foundation: Secure Boot and the Trust Chain

If you cannot trust the kernel at runtime, can you at least trust that it started clean? UEFI Secure Boot bet on that premise.

Windows 8 (October 2012) mandated Secure Boot for certified hardware, establishing a cryptographic chain of trust from firmware through bootloader to OS kernel [@ms-secure-boot]. Only components signed by trusted authorities could execute during the boot process. Measured Boot extended this by hashing each boot component into TPM Platform Configuration Registers (PCRs), creating a verifiable boot log that remote attestation services could check [@ms-trusted-boot].

This was a real advance. Bootkits like TDL4/Alureon, which operated below the OS and were invisible to all software-based defenses, were effectively blocked [@ms-alureon]. The boot chain was now cryptographically verified.

But Secure Boot had a critical gap: it protected the boot process, not runtime. Once Windows loaded and started executing, a kernel exploit could compromise the system just as before. PatchGuard was still the only runtime defense, and we have already seen its limitations.

Note: In 2023, ESET researchers confirmed BlackLotus -- the first publicly known UEFI bootkit that bypassed Secure Boot on fully updated Windows systems. It exploited CVE-2022-21894, using a legitimately signed but vulnerable Windows boot manager to load malicious code before the OS [@blacklotus-eset]. The attack demonstrated that even boot-time trust chains can be undermined via BYOVD-style techniques applied to the boot stack itself.

Secure Boot ensured the system started clean but could not keep it clean. Microsoft needed runtime isolation -- and the key technology was already sitting on millions of machines, unused for this purpose: the hypervisor.

The Breakthrough: Virtual Trust Levels and the Secure Kernel

The insight that changed everything was deceptively simple: if Ring 0 attackers can compromise anything at Ring 0, create a Ring -1. The hypervisor was already there.

Intel VT-x and AMD-V hardware virtualization extensions, shipping since 2005-2006, gave the hypervisor a privilege level above the OS kernel [@x86-virtualization]. Microsoft's Hyper-V already used this capability for virtual machines. The breakthrough was recognizing that the same hardware could create a security boundary within a single OS instance -- not a separate VM, but a hardware-isolated execution context that the kernel could not reach.

A hardware-enforced execution environment created by the Hyper-V hypervisor using Second Level Address Translation (SLAT). VTL0 is the Normal World where the standard NT kernel, drivers, and applications run. VTL1 is the Secure World where securekernel.exe and security-critical trustlets execute. VTL1 memory is physically inaccessible to all VTL0 code, including the NT kernel. A hardware feature (Intel Extended Page Tables / AMD Nested Page Tables) that provides a second layer of virtual-to-physical address translation managed by the hypervisor. SLAT enables the hypervisor to control which physical memory pages each VTL can access, making VTL1 memory invisible to VTL0 without any software-level enforcement that could be bypassed.

In May 2015, Brad Anderson announced Virtualization-Based Security, Device Guard, and Credential Guard at Microsoft Ignite [@anderson-ignite-2015]. The initial Windows 10 release, version 1507 (July 2015), shipped with VBS, creating two Virtual Trust Levels: VTL0 (Normal World) and VTL1 (Secure World) [@ms-vbs].

flowchart TB subgraph VTL1["VTL1 -- Secure World"] SK["securekernel.exe\n(Secure Kernel)"] IUM["Isolated User Mode"] LSAISO["lsaiso.exe\n(Credential Guard)"] ENCLAVE["VBS Enclaves"] IUM --- LSAISO IUM --- ENCLAVE end subgraph VTL0["VTL0 -- Normal World"] NT["ntoskrnl.exe\n(NT Kernel)"] DRIVERS["Kernel Drivers"] LSASS["lsass.exe\n(LSASS broker)"] APPS["User Applications"] end subgraph HV["Hyper-V Hypervisor"] SLAT["SLAT Enforcement\n(Intel EPT / AMD NPT)"] end HV -->|"enforces memory isolation"| VTL1 HV -->|"enforces memory isolation"| VTL0 VTL0 -.->|"Secure Service Calls\n(controlled boundary)"| VTL1

Here is how it works:

At boot, the Hyper-V hypervisor initializes and creates both VTLs.
The standard NT kernel (ntoskrnl.exe), all drivers, and user-mode applications run in VTL0.
securekernel.exe loads in VTL1 kernel mode. It is a minimal, purpose-built kernel that handles only security-critical functions [@ionescu-bh2015].
The hypervisor uses SLAT to make VTL1 memory physically inaccessible to VTL0. No amount of Ring 0 code in VTL0 can read or write VTL1 pages.
Communication between VTL0 and VTL1 occurs only via Secure Service Calls (SSCs) -- controlled hypercalls that cross the VTL boundary under strict validation [@ms-vbs].

A process running in VTL1 Isolated User Mode (IUM), protected from all VTL0 access by hypervisor-enforced memory isolation. The canonical example is lsaiso.exe, the Credential Guard trustlet that holds NTLM hashes and Kerberos tickets in VTL1 where even a fully compromised NT kernel cannot reach them.

securekernel.exe is deliberately minimal. While ntoskrnl.exe is a large general-purpose kernel, securekernel.exe is a much smaller, purpose-built VTL1 kernel whose exact size varies by Windows build. A smaller codebase means a smaller attack surface -- every line of code in VTL1 is a potential entry point for attackers, so Microsoft keeps it as small as possible.

Alex Ionescu's 2015 Black Hat presentation was the first major public technical teardown of the Secure Kernel Mode (SKM) and Isolated User Mode (IUM) architecture [@ionescu-bh2015]. Rafal Wojtczuk (Bromium) followed in 2016 with the first independent security audit of VBS, mapping the trust boundaries and identifying the secure call interface as the primary attack surface [@wojtczuk-bh2016].

What can an attacker with full SYSTEM access in VTL0 not do?

Read credentials protected by Credential Guard
Load unsigned kernel drivers when HVCI is enabled
Access VTL1 memory or modify Secure Kernel data structures
Disable VBS without rebooting (and with Secure Boot + UEFI lock, not easily even then)

For the first time, an attacker with full NT kernel compromise could not access secrets protected in VTL1. This fundamentally changed the Windows threat model.

For the first time, full NT kernel compromise was no longer game over. But what, exactly, does this new architecture protect?

The Pillars: What the Secure Kernel Protects

The Secure Kernel is not a product -- it is a platform. Five distinct security features stand on its shoulders, each protecting a different class of asset.

Credential Guard

When Credential Guard is enabled, NTLM password hashes and Kerberos Ticket-Granting Tickets (TGTs) are stored exclusively in lsaiso.exe -- a trustlet running in VTL1 [@ms-credential-guard]. The VTL0 lsass.exe process acts as a broker: authentication requests from VTL0 are forwarded to lsaiso.exe via secure RPC over the VTL boundary. lsaiso.exe performs cryptographic operations (challenge signing, ticket generation) within VTL1 and returns only the result -- never the raw secret.

sequenceDiagram participant App as Application (VTL0) participant LSASS as lsass.exe (VTL0) participant HV as Hypervisor participant LSAISO as lsaiso.exe (VTL1) App->>LSASS: Authentication request LSASS->>HV: Secure Service Call HV->>LSAISO: Forward to VTL1 LSAISO->>LSAISO: Sign challenge with stored credential LSAISO->>HV: Return signed response (NOT the raw secret) HV->>LSASS: Forward to VTL0 LSASS->>App: Authentication result Note over LSASS: Even SYSTEM access here cannot read VTL1 memory

Even a Mimikatz-wielding attacker with SYSTEM access in VTL0 gets nothing -- the raw credentials never exist in VTL0 memory. Credential Guard is enabled by default on domain-joined, non-DC Windows 11 22H2+ systems that meet VBS hardware requirements [@ms-credential-guard].

HVCI / Memory Integrity

A VBS feature (also called "Memory Integrity") that enforces kernel-mode code integrity from VTL1. HVCI ensures only signed code executes in the kernel and enforces W^X (Write XOR Execute) policy on all kernel memory pages via SLAT. No kernel memory page can be both writable and executable simultaneously. A memory protection policy enforcing that a page can be either writable or executable, but never both simultaneously. HVCI enforces W^X across all kernel memory via SLAT page permissions controlled from VTL1, preventing attackers from injecting and executing arbitrary code in the kernel.

HVCI moves code integrity enforcement from VTL0 into VTL1 [@ms-hvci]. Before any kernel-mode driver loads, its signature is verified by VTL1 code integrity services. HVCI enforces W^X on kernel memory pages using SLAT: page table modifications that would create a writable-and-executable page are trapped by the hypervisor and denied. Even if an attacker achieves kernel execution in VTL0, they cannot load unsigned drivers or make arbitrary kernel memory executable.On newer CPUs, Intel Mode-Based Execution Control (MBEC, Kaby Lake / 7th Gen+) and AMD Guest Mode Execute Trap (GMET, Zen 2+) provide hardware-accelerated W^X enforcement. Older CPUs rely on software emulation ("Restricted User Mode"), which increases overhead.

flowchart TD A["Driver load request\n(VTL0)"] --> B["Signature check\n(VTL1 code integrity)"] B -->|"Valid signature"| C["Set page permissions:\nExecutable + Read-Only"] B -->|"Invalid signature"| D["BLOCKED\nDriver cannot load"] E["Attacker tries to\nmake page W+X"] --> F{"SLAT check\n(Hypervisor)"} F -->|"Violation: W+X"| G["DENIED\nPage remains Read-Only"] F -->|"Valid: W XOR X"| H["Allowed"]

VBS Enclaves

An isolated memory region backed by VTL1 that allows third-party applications to protect secrets from even admin-level OS compromise. The host application in VTL0 communicates with the enclave via the CallEnclave API. Enclave memory is invisible to all VTL0 code, including the NT kernel. Available since Windows 11 24H2.

Starting with Windows 11 24H2, third-party developers can create their own VTL1-protected enclaves -- isolated memory regions for protecting application-level secrets like encryption keys and authentication tokens [@pulapaka-vbs-enclaves]. Unlike Intel SGX, VBS Enclaves require no specialized hardware beyond a VBS-capable CPU [@ms-vbs-enclaves]. Developers define enclave interfaces using EDL (Enclave Description Language) files and build with the VBS Enclave Tooling SDK [@vbs-enclave-tooling].

The development model works like this: you create an enclave DLL, sign it with a Trusted Signing certificate, and load it via the host application. The enclave runs in VTL1 user mode with access to a limited API surface -- no general Windows API access. All inputs from the VTL0 host must be validated and copied into VTL1 before use. Microsoft's developer guide covers the details [@ms-vbs-enclaves-dev], and the VBS Enclave Tooling package provides Rust crate support and Visual Studio 2022+ integration [@vbs-enclave-tooling].

System Guard Runtime Attestation

System Guard extends the trust chain from boot into runtime [@ms-system-guard]. A trustlet running in VTL1 periodically measures the integrity of critical system components -- boot state, kernel integrity, driver signatures -- and signs these measurements using a hardware-backed TPM key. Because the measurement code runs in VTL1, it is protected from tampering by compromised VTL0 code [@ms-system-guard-hw]. Remote attestation services (such as Microsoft Defender for Endpoint) can verify these signed reports to confirm device health -- enabling zero-trust conditional access decisions.

Secured-core PCs

Secured-core PCs integrate hardware, firmware, and VBS into a single security platform requirement [@ms-secured-core]. Certified hardware must include a 64-bit CPU with SLAT, IOMMU for DMA protection, TPM 2.0, UEFI with Secure Boot, SMM protection, DRTM support, and VBS/HVCI enabled and firmware-locked. Major OEMs -- Dell, HP, Lenovo, Microsoft Surface -- ship Secured-core PCs for enterprise and government customers.

VBS also enables additional isolation features beyond these core pillars. Windows Defender Application Guard (WDAG) uses Hyper-V containers to isolate untrusted browser sessions and Office documents, preventing web-based exploits from reaching the host OS. Hyper-V container isolation provides similar protection for containerized workloads.

Decision Guide

Scenario	Recommended Approach
Protect domain credentials from Pass-the-Hash/Ticket	Enable Credential Guard
Prevent unsigned kernel driver loading	Enable HVCI / Memory Integrity
Protect application-level secrets from admin attacks	Develop a VBS Enclave
Verify device integrity for zero-trust	Enable System Guard Runtime Attestation
Maximum baseline security for new hardware	Require Secured-core PC certification

The Secure Kernel now protects credentials, code integrity, application secrets, and device health. It is deployed across many millions of Windows 11 and Windows Server machines via VBS-by-default. But is it unbreakable?

How Others Solve This Problem: Competing Approaches

Windows is not alone in this challenge. Intel, AMD, and ARM each built their own answer to the same question: how do you protect secrets from a compromised OS? Each made different trade-offs.

Intel SGX

Intel Software Guard Extensions provided hardware enclaves at the CPU level without requiring a hypervisor [@wp-sgx]. Application code and data inside an SGX enclave were encrypted in memory and isolated from the OS, hypervisor, and other applications. The idea was compelling: trust nothing but the CPU itself.

Then side-channel attacks proved the CPU itself was not trustworthy. The Foreshadow attack (2018) exploited L1 Terminal Fault to extract data directly from SGX enclaves via CPU cache side channels [@foreshadow]. Intel deprecated SGX across 11th Gen client CPUs, including Tiger Lake mobile and Rocket Lake desktop, and continued that direction with 12th Gen Alder Lake [@wp-sgx].

AMD SEV-SNP

AMD Secure Encrypted Virtualization with Secure Nested Paging (SEV-SNP) encrypts VM memory with per-VM keys and enforces page ownership via a Reverse Map Table (RMP) -- a hardware table that records which VM owns each physical page [@amd-sev]. Even the hypervisor cannot read or remap guest memory without the guest's consent. This is a fundamentally different trust model from VBS: SEV-SNP distrusts the hypervisor, while VBS trusts it. SEV-SNP protects VMs in multi-tenant cloud environments (like Azure Confidential VMs) but does not provide intra-OS isolation within a single machine the way VBS does. The two are complementary, not competing.

Intel TDX

Intel Trust Domain Extensions create hardware-isolated Trust Domains for VMs, excluding the hypervisor from the trusted computing base [@intel-tdx]. The TDX Module runs in a special CPU mode called Secure Arbitration Mode (SEAM) and mediates all interactions between the hypervisor and Trust Domains -- the hypervisor can schedule TD VMs but cannot read their memory or registers. Like SEV-SNP, TDX targets cloud confidential computing rather than intra-OS protection. It complements VBS rather than replacing it.

ARM TrustZone

ARM TrustZone partitions the CPU into a Secure World and a Normal World using a hardware security state bit, predating VBS by a decade (2004 vs. 2015) [@arm-trustzone]. World transitions happen through a Secure Monitor Call (SMC) instruction, handled by firmware or a trusted OS like OP-TEE. The concept is similar to VBS -- two execution worlds with hardware isolation -- but the mechanism differs. TrustZone has a smaller attack surface (no hypervisor in the path) but is less flexible: it typically supports only two worlds with coarser granularity. TrustZone dominates mobile and embedded devices; Windows on ARM still uses the hypervisor-based VBS model for VTL0/VTL1 separation, the same architecture as VBS on x64.ARM TrustZone predates VBS by over a decade. The concept of hardware-enforced dual execution worlds was well established in the mobile/embedded world long before Microsoft applied the idea to desktop Windows. The insight was not the dual-world concept itself, but using the x86 hypervisor to implement it.

Linux

No production equivalent of VBS exists in mainline Linux. Linux relies on Mandatory Access Control (SELinux/AppArmor), container isolation (namespaces/cgroups), and VM-level isolation via SEV-SNP or TDX for cloud workloads. Google's pKVM (Protected KVM) in Android and ChromeOS is the closest parallel -- it uses the hypervisor to isolate a secure VM from the host kernel, similar in spirit to VTL1. Research projects have proposed similar intra-OS isolation for desktop Linux, but none has reached mainline. Linux's security philosophy favors defense-in-depth via many smaller mechanisms rather than a single architectural boundary.

Cross-Platform Comparison

Dimension	Windows VBS	Intel SGX	AMD SEV-SNP	Intel TDX	ARM TrustZone
Isolation granularity	OS-level (VTL split)	Process-level enclaves	VM-level	VM-level	2 worlds
Trusts the hypervisor?	Yes	N/A (no hypervisor)	No	No	N/A
Memory encryption	No (isolation only)	Yes	Yes (full VM)	Yes (full VM)	Varies
Primary use case	Desktop/server OS	Legacy high-assurance	Cloud confidential VMs	Cloud confidential VMs	Mobile/IoT
Status (2025)	Active, expanding	Deprecated on consumer	GA on major clouds	Rolling out	Widely deployed
Known weakness	Rollback, side-channels	Foreshadow, deprecated	Physical attacks	Early deployment	Firmware attacks

Every platform bets on a different trust anchor. VBS trusts the hypervisor. SEV-SNP trusts only the CPU and its encryption keys. SGX trusted the CPU itself -- until side-channel attacks proved that wrong. The uncomfortable question follows: what cannot VBS protect against?

The Limits: What VBS Cannot Protect Against

Every security boundary has an edge. VBS's edge is more nuanced than most defenders realize.

Attacking the Secure Kernel Directly

In August 2020, Saar Amar and Daniel King of Microsoft's own MSRC stood on the Black Hat stage and demonstrated something the community had feared: direct exploitation of securekernel.exe itself [@amar-bh2020]. Using a custom fuzzer called Hyperseed, they found the first five vulnerabilities in the secure call interface within two weeks; combined with continued manual auditing, they ultimately disclosed ten vulnerabilities [@amar-publications]. Memory corruption bugs in pool management and interface validation allowed VTL0 code to achieve code execution inside VTL1 -- breaking the isolation entirely.

All vulnerabilities were patched before disclosure. Microsoft has since added mitigations: improved KASLR, Control Flow Guard (CFG) in VTL1, and stricter input validation. But the attack proved that VTL1 is not invulnerable -- the secure call interface is a real attack surface, and any bug there defeats all VBS guarantees.

Pass-the-Challenge: The Protocol-Level Bypass

Oliver Lyak's "Pass-the-Challenge" research revealed a subtle limitation of Credential Guard [@lyak-pass-the-challenge]. Credential Guard prevents credential extraction -- but it cannot prevent credential use. An attacker with SYSTEM access can relay NTLM authentication challenges through lsaiso.exe, using the machine as an "NTLM oracle." The raw hash never leaves VTL1, but the attacker can still sign challenges on demand.

Note: Credential Guard perfectly isolates secrets in VTL1, but the VTL0 broker (lsass.exe) necessarily provides an interface for using those secrets. Pass-the-Challenge exploits that interface -- not to extract secrets, but to relay them. This is a fundamental design tension: the more useful the isolation boundary, the more attack surface the boundary's API exposes.

Side-Channel Attacks

Spectre and Meltdown demonstrated that speculative execution creates information leakage channels across any software-enforced boundary [@spectre-paper]. VTL0 and VTL1 share the same physical CPU, including caches, branch predictors, and TLBs. Microsoft has deployed microcode updates and software mitigations (IBRS, STIBP, retpolines) [@ms-spectre-advisory], but these reduce the risk rather than eliminating it. Complete elimination requires fundamentally different CPU designs that do not share microarchitectural state across trust boundaries.

The Formal Verification Gap

The seL4 microkernel is formally verified -- mathematically proven correct for approximately 8,700 lines of C code [@sel4-whitepaper]. This means its isolation guarantees are not empirical ("we tested it and found no bugs") but mathematical ("we proved it cannot have certain classes of bugs"). Hyper-V is orders of magnitude larger and more complex. Formally verifying it with current techniques is infeasible. The gap between "extensively tested" and "mathematically proven" is significant: Hyper-V's isolation is empirically strong, not provably correct. A single hypervisor bug could allow VTL escape.

Microsoft's Own Boundary

Microsoft explicitly states in its Security Servicing Criteria that an administrator with physical access is not a security boundary [@ms-servicing-criteria]. VBS defends against remote kernel exploitation and privilege escalation, but not against an administrator who can modify firmware, attach hardware debuggers, or perform DMA or evil-maid-style physical attacks; Microsoft's VBS guidance separately calls out IOMMU-backed DMA protection as a distinct hardware requirement [@ms-vbs].

This boundary declaration has practical consequences: it is why CVE-2024-21302 (Windows Downdate) required an opt-in fix rather than an automatic security update -- the attack requires admin privileges.

VBS is the strongest runtime isolation Windows has ever had. But it is empirically strong, not mathematically proven. And one attack discovered in 2024 threatened to undo it entirely.

The Arms Race: Rollback Attacks and the Ongoing Battle

In August 2024, Alon Leviev of SafeBreach Labs stood on the Black Hat stage and demonstrated something terrifying: he could silently roll back a "fully patched" Windows system to a state where all VBS protections were vulnerable -- using Windows Update itself.

I found several vulnerabilities that let me develop Windows Downdate -- a tool to take over the Windows Update process to craft fully undetectable downgrades. -- Alon Leviev, SafeBreach Labs

The Windows Downdate attack (CVE-2024-21302) works by hijacking the Windows Update mechanism to replace current versions of securekernel.exe, ci.dll, and other VBS components with older, vulnerable versions [@leviev-downdate]. The system continues to report itself as "fully patched" while running code with known, exploitable vulnerabilities [@cve-2024-21302]. The attack requires administrator privileges -- which, as we noted, Microsoft does not consider a security boundary.

sequenceDiagram participant Attacker as Attacker (Admin in VTL0) participant WU as Windows Update participant FS as File System participant Boot as Next Boot Attacker->>WU: Hijack update process WU->>FS: Replace securekernel.exe with old version WU->>FS: Replace ci.dll with old version Note over FS: System still reports "fully patched" FS->>Boot: Boot with vulnerable binaries Boot->>Boot: VBS runs with known vulnerabilities Note over Boot: All previously patched bugs are re-exposed

Microsoft does not consider admin-to-kernel a security boundary, which is why CVE-2024-21302 required an "opt-in" fix rather than an automatic security update. Organizations must explicitly deploy KB5042562 to enable rollback protection.

Microsoft responded with KB5042562, publishing a SkuSiPolicy.p7b revocation policy to block loading of outdated VBS-related binaries [@ms-rollback-guidance]. A UEFI variable lock reduces the risk of firmware-level rollback, though Leviev's research demonstrated it can be bypassed through Windows Update manipulation without physical access [@leviev-downdate-update]. But deployment is opt-in and complex -- applying it incorrectly can cause boot failures. And the underlying mechanism (admin-level control over the update process) remains exploitable [@leviev-downdate-update].

The weaponization of VBS itself followed shortly. At DEF CON 33 in August 2025, Akamai researchers demonstrated "BYOVE" (Bring Your Own Vulnerable Enclave) and "Mirage" -- techniques for running malware inside a VBS enclave, hidden from EDR and antimalware tools that cannot inspect VTL1 memory [@akamai-vbs-weaponization]. The very isolation that protects legitimate secrets can also protect malicious code.

Note: The same VTL1 isolation that makes VBS enclaves secure for legitimate applications makes them invisible to security tools. An attacker who can load a legitimately signed but vulnerable enclave DLL gains a hiding place that no VTL0 security product can inspect. Microsoft is actively hardening the enclave trust boundary [@ms-vbs-enclave-hardening], but the fundamental tension between isolation and visibility persists.

The pattern is clear: VBS raises the cost of attack, attackers find creative bypasses, Microsoft hardens further. The question is no longer "is VBS breakable?" but "where does the research go next?"

Open Questions: Where Research Is Heading

The Secure Kernel is mature but not finished. Five open problems define the next decade of research.

Complete rollback prevention. KB5042562 is a start, but complete protection may require hardware-enforced monotonic version counters -- similar to ARM's anti-rollback fuse bits -- integrated into platform firmware [@ms-rollback-guidance]. Without hardware support, the administrator-who-controls-updates problem remains fundamentally unsolved.

Secure Kernel vulnerability discovery. Jonathan Jagt's 2025 MSc thesis at Radboud University documented the process of setting up a Secure Kernel debugging environment and analyzed patched security bugs to identify vulnerability patterns [@jagt-thesis]. A key finding: the tooling for VTL1 research is scarce. Building a VTL1 debugging environment requires VMware-specific configurations and custom modifications that most researchers do not have access to. Better tooling would accelerate both offensive and defensive research.

VBS Enclave security model. The tension between protecting legitimate secrets and preventing malware evasion has no clean solution. Microsoft's hardening guidance addresses developer mistakes (TOCTOU races, pointer validation, reentrancy risks) [@ms-vbs-enclave-hardening], but the architectural problem -- that VTL1 isolation is equally useful to attackers and defenders -- requires a new approach to enclave attestation and monitoring.

Formal verification. Can we ever prove Hyper-V correct? The seL4 proof covers approximately 8,700 lines of C [@sel4-whitepaper]. Hyper-V is hundreds of thousands of lines. Current verification technology cannot scale to that size. Partial verification of critical subsystems (the SLAT enforcement logic, the secure call dispatcher) might be feasible and would meaningfully reduce the trusted computing base.

Side-channel elimination. Requires fundamentally different CPU designs. Current mitigations (microcode patches, partitioned caches, branch prediction barriers) reduce the leakage rate but cannot close the channel entirely while VTL0 and VTL1 share physical hardware [@spectre-paper]. Some academic designs propose physically separate execution units for different trust levels, but these are years from production.

Note: The theoretically perfect system would combine: a formally verified hypervisor, hardware with no shared microarchitectural state between trust levels, a complete binary revocation mechanism preventing all rollback attacks, and zero performance overhead. Each requirement is individually infeasible today. The Secure Kernel is the best available approximation.

The Windows Secure Kernel is the most significant architectural change to Windows security since the NT reference monitor. It does not make Windows invulnerable -- no technology does. But it changed what "kernel compromise" means.

gantt title Windows Kernel Security Evolution dateFormat YYYY axisFormat %Y section Gen 0 NT Kernel (flat trust) :1993, 2005 section Gen 1 PatchGuard (KPP) :2005, 2012 KMCS (driver signing) :2007, 2012 DEP :2004, 2012 ASLR :2007, 2012 SMEP :2011, 2015 section Gen 2 UEFI Secure Boot :2012, 2015 Measured Boot + TPM :2012, 2015 section Gen 3 VBS + Secure Kernel :2015, 2026 Credential Guard :2015, 2026 HVCI / Memory Integrity :2015, 2026 System Guard Attestation :2018, 2026 Secured-core PCs :2019, 2026 section Gen 3.5 VBS Enclaves :2024, 2026

Modern Windows runs all three generations simultaneously -- PatchGuard still watches for kernel tampering, Secure Boot still verifies the boot chain, and VBS adds hardware-enforced isolation on top. Newer defenses supplement rather than replace earlier ones.

Theory is valuable; practice pays the bills. Here is how to enable, verify, and troubleshoot VBS on your systems.

Hardware Requirements

VBS requires: a 64-bit CPU with hardware virtualization (Intel VT-x or AMD-V), Second Level Address Translation (Intel EPT or AMD NPT), TPM 2.0, and UEFI firmware with Secure Boot [@ms-vbs]. For optimal HVCI performance, Intel Kaby Lake (7th Gen) or newer (for MBEC) or AMD Zen 2 or newer (for GMET) is recommended [@ms-hvci].

Enabling VBS

VBS can be enabled through:

Group Policy: Computer Configuration > Administrative Templates > System > Device Guard > Turn On Virtualization Based Security
Intune/MDM: Use the DeviceGuard CSP or endpoint security policies
Registry: Set HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\EnableVirtualizationBasedSecurity to 1

HVCI/Memory Integrity can be enabled separately via Windows Security > Device Security > Core Isolation > Memory Integrity.

Verifying VBS Status

{` // Simulates Get-CimInstance -ClassName Win32_DeviceGuard // -Namespace root/Microsoft/Windows/DeviceGuard

const vbsStatus = { VirtualizationBasedSecurityStatus: 2, // 0=Not enabled, 1=Enabled but not running, 2=Running RequiredSecurityProperties: [1, 2], // 1=Hypervisor support, 2=Secure Boot AvailableSecurityProperties: [1, 2, 3, 5, 6], // What hardware supports SecurityServicesConfigured: [1, 2], // 1=CredentialGuard, 2=HVCI SecurityServicesRunning: [1, 2], // Which services are active };

const statusNames = { 0: "Not enabled", 1: "Enabled (not running)", 2: "Running" }; const serviceNames = { 1: "Credential Guard", 2: "HVCI / Memory Integrity", 3: "System Guard" };

console.log("VBS Status:", statusNames[vbsStatus.VirtualizationBasedSecurityStatus]); console.log("\nConfigured Security Services:"); vbsStatus.SecurityServicesConfigured.forEach(s => console.log(" -", serviceNames[s] || "Unknown (" + s + ")") ); console.log("\nRunning Security Services:"); vbsStatus.SecurityServicesRunning.forEach(s => console.log(" -", serviceNames[s] || "Unknown (" + s + ")") ); console.log("\nTo check on your system, run in PowerShell:"); console.log("Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root/Microsoft/Windows/DeviceGuard"); `}

You can also verify VBS status via:

msinfo32.exe: Look for "Virtualization-based security" in the System Summary
Windows Security app: Device Security > Core Isolation details

**Driver compatibility:** Some older drivers violate W^X policy and fail to load with HVCI enabled. Check the Windows Event Log (CodeIntegrity events) for blocked drivers. Microsoft's Hardware Lab Kit (HLK) provides HVCI compatibility testing.

Performance impact: VBS/HVCI adds roughly 5-10% overhead in CPU-bound workloads, especially gaming benchmarks [@vbs-perf]. On modern CPUs with MBEC/GMET, the overhead is lower. For gaming workloads, you may see reduced frame rates in CPU-bound scenarios.

Credential Guard and NLA: Network Level Authentication can fail if Credential Guard is enabled but the domain controller does not support the required Kerberos extensions. Ensure domain controllers are running Windows Server 2016 or later.

Cannot enable VBS: Verify that virtualization is enabled in BIOS/UEFI settings, Secure Boot is on, and TPM 2.0 is present and enabled. Some older systems lack SLAT support.

Note: 1. Open msinfo32.exe and confirm "Virtualization-based security: Running" 2. Check that "Credential Guard" and "Hypervisor enforced Code Integrity" appear under running services 3. Run Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root/Microsoft/Windows/DeviceGuard in PowerShell for detailed status 4. Verify Secure Boot is enabled and TPM 2.0 is present

The Windows Secure Kernel is the most important Windows security feature most people have never heard of. It does not make the headlines that zero-days do. But it quietly changed the fundamental question of Windows security -- from "can we keep attackers out of the kernel?" to "what can we protect even after they get in?" The secrets behind the VTL1 wall remain safe. At least until the next chapter of the arms race.

VBS and HVCI add roughly 5-10% overhead in CPU-bound workloads, with gaming seeing the most noticeable impact [@vbs-perf]. For typical business usage (email, documents, web browsing), the impact is negligible. Modern CPUs with Intel MBEC (Kaby Lake / 7th Gen+) or AMD GMET (Zen 2+) significantly reduce this overhead through hardware-accelerated W^X enforcement. No. securekernel.exe coexists with ntoskrnl.exe. The NT kernel handles all general OS operations -- process management, file systems, networking, device drivers. The Secure Kernel handles only security-critical functions: credential isolation, code integrity enforcement, enclave management. They run in parallel in separate VTLs. No. VBS protects specific assets (credentials, code integrity, application secrets) from a compromised kernel. The NT kernel itself can still be exploited -- an attacker can still gain SYSTEM access, install rootkits in VTL0, and control the standard OS environment. What they cannot do is access VTL1-protected secrets or load unsigned kernel drivers (with HVCI enabled). No. VBS uses the Hyper-V *hypervisor*, not traditional VMs. You can run VBS without creating any virtual machines. The hypervisor runs as a thin layer beneath both VTLs to enforce memory isolation. If you also use Hyper-V VMs, VBS coexists with them. No. Credential Guard protects stored credentials (NTLM hashes, Kerberos TGTs) from extraction, but it does not eliminate the need for strong authentication. It does not protect against phishing, password reuse, or credential relay attacks (as demonstrated by Pass-the-Challenge [@lyak-pass-the-challenge]). Credential Guard is one layer in a defense-in-depth strategy. Not without rebooting. And with Secure Boot and a UEFI lock, VBS cannot be easily disabled even across reboots. However, the Windows Downdate attack demonstrated that VBS *components* can be silently downgraded to vulnerable versions without disabling VBS itself [@leviev-downdate]. Deploying KB5042562 rollback protection mitigates this risk. No. VBS creates isolated execution environments within a single OS instance, not separate VMs. VTL0 and VTL1 share the same OS, the same desktop, the same processes (with the exception of trustlets in VTL1). The isolation is at the memory level via SLAT, not at the OS level. It is more like having a secure safe inside your house than having two separate houses.