Parag Mali - tag: mimikatz

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

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

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

1. Two Continents, Eleven Months Apart

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.1 Discovery timeline

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

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

3.2 The four zero-days

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

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

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

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

3.3 The stolen Authenticode certificates

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

3.4 Architectural lessons

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

3.5 Did Stuxnet defeat any defender primitive Windows 7 shipped?

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

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

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

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

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

4. Mimikatz: The Credential Layer Demolition

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

4.1 Delpy, LSASS, and the May 2011 release

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

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

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

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

4.2 Four primitives that broke the credential layer

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.3 The 2013 inflection: graph-walking offensive Active Directory

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

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

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

4.4 The 2014 inflection: the Golden Ticket

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

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

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

4.5 What this proved

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

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

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

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

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

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

5.1 The pivot up the trust stack

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

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

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

5.2 The Mimikatz codebase as a single causal node

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

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

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

5.3 The economic argument

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

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

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

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

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

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

6.1 Restricted Admin RDP

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

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

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

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

6.2 LSA Protected Process (RunAsPPL)

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

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

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

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

6.3 The Mitigating Pass-the-Hash whitepaper series

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

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

6.4 KB2871997 and the WDigest opt-out

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

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

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

6.5 The seeds of Credential Guard

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

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

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

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

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

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

7.1 The mechanism

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

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

7.2 The bundled extras

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

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

7.3 Strategic significance

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

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

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

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

8.1 The trusted-computing-base argument

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

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

8.2 The asymmetry

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

8.3 The VTL0-symmetry argument

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

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

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

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

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

8.4 The way out, foreshadowed

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

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

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

9. Open Problems at the End of 2014

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

10.2 Mimikatz tradecraft as the floor of red-team capability

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

10.3 Detection

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

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

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

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

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

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

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

11. Frequently asked questions

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

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

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.

"Can This Code Do This?" -- Twenty-Five Years of Attacks on the Windows Access-Control Model

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

Windows answers the question *can this code do this?* with one kernel function, `SeAccessCheck`, evaluated against five inputs: a security descriptor, an access token, a desired-access mask, a generic-mapping table, and any previously-granted access. The function and its inputs have not structurally changed since July 27, 1993. Every famous Windows local-privilege-escalation tool of the last twenty-five years -- Mimikatz, JuicyPotato and seven other Potatoes, the seventy AutoElevate-redirect methods catalogued in UACMe -- attacks one of those inputs. This article tells that story as one system, names the five structural limits Microsoft has publicly conceded, and explains why Adminless, NTLMless, VBS Trustlets, and Credential Guard are the four non-overlapping ways to close them.

1. One Question, Billions of Times a Second

Open a Windows PowerShell window and run whoami /priv. Read the column on the right. SeShutdownPrivilege. SeUndockPrivilege. SeIncreaseWorkingSetPrivilege. SeTimeZonePrivilege. About twenty rows of capabilities, almost all marked Disabled, on a token that lives inside explorer.exe's memory and that the kernel consults billions of times a second.

Now run icacls C:\Windows\System32\drivers\etc\hosts. The output reads BUILTIN\Administrators:(F), NT AUTHORITY\SYSTEM:(F), BUILTIN\Users:(R). Six characters per principal, decoded by something inside the kernel called SeAccessCheck, applied to a data structure called a security descriptor, against a credential called an access token, every time any process anywhere on the machine asks for read access to that single file [@ms-learn-access-control].

This article is about the model behind those two outputs. A model that has not structurally changed since July 27, 1993, when Windows NT 3.1 shipped from Redmond [@en-wiki-windows-nt-3-1]. A model that every famous Windows local-privilege-escalation tool of the last twenty-five years -- Mimikatz, JuicyPotato, fodhelper.exe, the seventy methods in the open-source UACMe catalogue -- exists to attack [@github-gentilkiwi-mimikatz, @github-ohpe-juicy-potato, @github-hfiref0x-uacme].

The thesis comes in three convictions:

SeAccessCheck is the answer. Every securable Windows operation that touches a securable object resolves through one decision function with one set of inputs [@ms-learn-how-dacls-control-access].
Every famous Windows escalation tool attacks one of those inputs. JuicyPotato attacks the token. Mimikatz attacks the privilege list. Fodhelper attacks the elevation flow that produces the token. HiveNightmare attacks the DACL on a single file [@nvd-cve-2021-36934]. The vocabulary scales.
The model has five structural limits its keepers have publicly conceded [@msrc-servicing-criteria], and Adminless, NTLMless, VBS Trustlets, and Credential Guard are the four non-overlapping ways to close them.

The forecast for the next 14,000 words: ten primitives (the Security Reference Monitor, security identifiers, tokens, security descriptors, DACLs, SACLs, ACEs, privileges, Mandatory Integrity Control, User Account Control), one canonical oracle (SeAccessCheck), two attack families (the Potato lineage and the UACMe bypass tradition), and four successor architectures (Adminless, NTLMless, VBS Trustlets, Credential Guard).

If the model has not structurally changed since 1993, why has it taken thirty-three years and seventy bypasses to map its failure modes -- and what does each generation tell us about the next?

2. Origins: From Lampson's Matrix to Cutler's Kernel (1971-1993)

The vocabulary starts in a paper Butler Lampson presented at Princeton in 1971 and the ACM republished in Operating Systems Review in January 1974. Lampson framed protection as a 2-D matrix: rows index the subjects (users, processes), columns index the objects (files, devices, memory pages), and the cell at the intersection holds the operations the subject is permitted on the object. The matrix is a sparse, mostly-empty table the size of every-process times every-file. No real system has ever stored it that way.

Two implementation strategies fall out of the formalism. Slice the matrix by row and you get capability lists: each subject carries a token that names the objects it can touch. Slice by column and you get access-control lists: each object carries a list of subjects allowed to touch it. Lampson worked through both in the paper. Operating systems built on the second slice came to dominate, partly because hardware in 1971 made unforgeable capabilities expensive, partly because file systems could carry an ACL at the inode without changing every program. Decades later, the gap between the two implementations would still matter; we will reach Norm Hardy's "Confused Deputy" in a moment.

The lever that turned theory into Windows came from procurement, not academia. On December 26, 1985, the U.S. Department of Defense published DoD 5200.28-STD, the Trusted Computer System Evaluation Criteria, known by the colour of its cover as the Orange Book [@nist-csrc-rainbow]. The Orange Book defined four divisions of trusted-system assurance, and its C2 class -- "Controlled Access Protection" -- made discretionary access control plus auditing a federal procurement floor. The September 30, 1987 Neon Orange Book (NCSC-TG-003) and the July 28, 1987 Tan Book (NCSC-TG-001) elaborated DAC and audit respectively [@nist-csrc-rainbow]. After 1985, no operating system that wanted U.S. federal customers could ship without per-user ACLs and an audit log.

A year before the Orange Book ossified DAC into procurement, Norm Hardy of the Tymshare / KeyKOS lineage published a three-page paper in Operating Systems Review that named the structural limit of the entire ACL-shaped class: "The Confused Deputy (or why capabilities might have been invented)" [@wayback-cap-lore-hardy]. Hardy described a privileged compiler that wrote billing records to a system file. A user could trick the compiler into writing the user's output file over the billing file, because the compiler used its own authority on every write and could not distinguish "authority I have" from "authority the caller asked me to use."

The Wikipedia summary of the field is exact: "Capability systems protect against the confused deputy problem, whereas access-control list-based systems do not" [@en-wiki-confused-deputy]. Hold this paper. It will come back in Section 10.

The team that built Windows NT was not assembled in Redmond. David Cutler arrived in October 1988 from Digital Equipment Corporation [@en-wiki-cutler], where he had led VMS and the cancelled Mica successor, and brought with him a fraction of his old DEC team.

The cultural import mattered: VAX/VMS, announced October 25, 1977 alongside the VAX-11/780 (V1.0 shipped August 1978) [@en-wiki-openvms], introduced UIC-based file protection and a kernel-mode security architecture, and by the mid-1980s the VAX/VMS line had been evaluated at TCSEC Class C2 [@en-wiki-openvms], by which time the system had been hardened with per-object ACLs, audit channels, and an explicit reference monitor. That C2-hardened VMS was the cultural reference Cutler brought with him to Microsoft. G. Pascal Zachary's Showstopper! tells the story of the four-year build of NT 3.1 from that team [@showstopper-zachary].

The point for this article is narrower. NT 3.1's nine access-control primitives -- Security Reference Monitor, security identifier, access token, security descriptor, DACL, SACL, ACE, privileges, audit channel -- did not arrive piecemeal. They were specified together, before the first line of SeAccessCheck was written, against a procurement standard the team intended to clear.

NT 3.1 released to manufacturing on July 27, 1993 [@en-wiki-windows-nt-3-1]. NT 3.5, released to manufacturing on September 21, 1994 [@en-wiki-nt-3-5], was hardened through Service Pack 3 (June 21, 1995) and was rated by the National Security Agency in July 1995 as complying with TCSEC C2 criteria against the standalone single-user configuration [@en-wiki-nt-3-5]; NT 4.0 Service Pack 6a was evaluated at TCSEC C2 in a standalone (non-networked) configuration, consistent with NT 3.5 SP3. The combination froze the model. Once C2 evaluation was on the books, structural changes to the access-control surface would have required re-evaluation. Federal procurement obligations have kept the structural shape intact for thirty-one years, even after the Department of Defense formally retired TCSEC in favour of the Common Criteria.

Cutler shipped a model that has answered "can this code do this?" the same way for thirty-three years. What is the actual function -- and what are its inputs?

3. The Kernel Oracle: `SeAccessCheck` and Its Inputs

The function has one signature, one return value, and one job. Microsoft's Win32 documentation exposes a user-mode mirror called AccessCheck that lets userland code ask the question without holding a handle, and a kernel routine called SeAccessCheck that the kernel invokes at every securable operation [@ms-learn-access-control, @ms-learn-access-tokens]. The shape is the same in both directions:

$$ \textsf{SeAccessCheck}(\textit{SD}, \textit{Token}, \textit{DesiredAccess}) \to (\textit{GrantedAccess}, \textit{Status}) $$

Three inputs in (a security descriptor, an access token, a requested-access mask), two outputs out (the access mask actually granted, and a STATUS_ACCESS_DENIED flavour if any). Two more hidden inputs make the kernel signature precise: a generic mapping table that translates the four generic rights (GENERIC_READ, GENERIC_WRITE, GENERIC_EXECUTE, GENERIC_ALL) into object-type-specific bits, and a previously-granted-access mask that the kernel carries forward when an access check happens in two phases. Together: five inputs, one decision, one log entry (the documented kernel routine carries a few additional parameters of kernel-internal bookkeeping -- a synchronization flag, an AccessMode discriminator that elides the check for kernel-mode callers, and a privileges out-parameter -- which the explanatory five-input model collapses; the user-mode AccessCheck mirror is closer to the model the article uses).

The kernel-mode component of the Windows NT executive that performs all access checks against securable objects. It owns `SeAccessCheck` and the audit log generation routines. The SRM is a *subsystem*, not a feature: every other kernel component that needs to grant or deny access calls into it. The Windows kernel routine that decides whether a thread may perform a requested set of operations on an object. It takes a security descriptor, an access token, a desired-access mask, a per-object-type generic-mapping table, and any previously-granted access. (The documented kernel signature also carries a synchronization flag, an `AccessMode` discriminator that elides the check for kernel-mode callers, and a privileges out-parameter; the five-input model used here is an explanatory simplification that the user-mode `AccessCheck` mirror tracks more closely.) It returns the subset of the desired-access mask that the kernel grants and a status code. Every call site that opens or modifies a securable object eventually reaches this function [@ms-learn-how-dacls-control-access].

The five inputs are not equally exotic. The desired-access mask and the generic-mapping table are bookkeeping that an object type defines once at registration time. The previously-granted-access input is the kernel handing itself a pencil for two-phase access checks, mostly invisible to userland. The two inputs the rest of the article will keep returning to are the security descriptor and the access token.

A security descriptor is the data structure attached to the object. It carries an owner SID, a primary-group SID, a discretionary access-control list (DACL) of allow / deny / audit entries, and a system access-control list (SACL) holding audit and integrity-label entries [@ms-learn-mic]. The DACL is what icacls prints. The SACL is what writes Event Log entries when something the descriptor's writer wanted to watch happens.

An access token is the data structure attached to the caller. It names the user (one SID), the user's groups (a list of SIDs), the privileges the user holds (a list of named superpowers), the integrity level the kernel will compare against the object's label, and a flag that says whether the token is a primary token (one per process) or an impersonation token (one per thread, used to act on a client's behalf) [@ms-learn-access-tokens].

Microsoft's documentation lists the token's contents almost as bullet points: "The security identifier (SID) for the user's account; SIDs for the groups of which the user is a member; A logon SID that identifies the current logon session; A list of the privileges held by either the user or the user's groups; An owner SID; The SID for the primary group; The default DACL; ... Whether the token is a primary or impersonation token; An optional list of restricting SIDs; Current impersonation levels..." [@ms-learn-access-tokens].

The flow inside SeAccessCheck is mechanical. The kernel maps DesiredAccess from generic to specific bits using the type's mapping table. It checks the integrity label of the object against the integrity level on the token (Mandatory Integrity Control runs before the DACL walk, a point Section 7 expands). It walks the DACL in order, deny-first, accumulating bits granted by allow ACEs whose SID is in the token's list. It applies a privilege bypass short-circuit if the caller holds SeBackupPrivilege, SeRestorePrivilege, SeDebugPrivilege, or one of the other privileges that grants access to whole classes of objects without consulting the DACL. It returns the accumulated GrantedAccess, or STATUS_ACCESS_DENIED if the requested bits were not all granted.

sequenceDiagram participant App as User-mode caller participant ObjMgr as Object Manager participant SRM as Security Reference Monitor participant Audit as Audit channel App->>ObjMgr: OpenObject(name, DesiredAccess, ImpersonationToken) ObjMgr->>ObjMgr: Resolve name (\BaseNamedObjects, \Device, \??) ObjMgr->>ObjMgr: Fetch security descriptor from object header ObjMgr->>SRM: SeAccessCheck(SD, Token, DesiredAccess) SRM->>SRM: Map generic rights via type mapping SRM->>SRM: Check mandatory integrity label SRM->>SRM: Privilege-bypass short-circuit (SeBackup, SeRestore, SeDebug) SRM->>SRM: Walk DACL in canonical order, deny-first SRM-->>ObjMgr: GrantedAccess + STATUS code ObjMgr->>Audit: Emit SACL audit ACE if matched ObjMgr-->>App: HANDLE or STATUS_ACCESS_DENIED

Five inputs. One function. One log entry on the way out. The thesis statement of this article is the consequence: every later section is an attack on one of those inputs. JuicyPotato attacks the token. Mimikatz attacks the privilege list. Fodhelper attacks the elevation flow that produces the token. HiveNightmare attacks the security descriptor on a single file. Conditional ACEs and Dynamic Access Control extend the matrix's subject dimension by adding claims to the token. UAC tries to keep the token small by default and only inflate it on demand. Every primitive in the article maps cleanly onto one of SeAccessCheck's five inputs, and every famous attack tool in the article maps cleanly onto one primitive.

The function is fixed. The inputs are five. So how does the kernel actually walk a DACL -- and where does the wrong answer come from?

4. The DACL Algorithm and the SID Namespace

"Walk the DACL in order." Six words that have generated hundreds of thousands of misconfigured ACLs since 1993. The Microsoft Learn page that ships the algorithm is short and exact. The system "examines each ACE in sequence until... an access-denied ACE explicitly denies any of the requested access rights to one of the trustees listed in the thread's access token... one or more access-allowed ACEs for trustees listed in the thread's access token explicitly grant all the requested access rights... All ACEs have been checked and there is still at least one requested access right that has not been explicitly allowed, in which case, access is implicitly denied" [@ms-learn-how-dacls-control-access].

Three terminations. Deny terminates with denial. Enough allows terminates with grant. End-of-list with anything left ungranted terminates with denial. Note the asymmetry the algorithm encodes: a single deny anywhere in the DACL kills the request, but an allow has to be paired with explicit coverage of every desired bit. The default is denial.

The ordered list of access-control entries (ACEs) attached to a securable object's security descriptor that specifies which trustees are granted or denied which access rights. *Discretionary* means the object's owner controls the list, in contrast to a mandatory list whose entries the system enforces independent of owner intent. A single grant, deny, audit, or mandatory-label record inside a DACL or SACL. Each ACE carries an SID identifying the trustee, a 32-bit access mask, a flags byte controlling inheritance, and a type discriminator. Windows defines four primary ACE types (`ACCESS_ALLOWED_ACE`, `ACCESS_DENIED_ACE`, `SYSTEM_AUDIT_ACE`, `SYSTEM_MANDATORY_LABEL_ACE`) plus callback variants for conditional ACEs [@ms-learn-ace-strings].

{` // Faithful implementation of the algorithm at // learn.microsoft.com/en-us/windows/win32/secauthz/how-dacls-control-access-to-an-object // Inputs: token (set of SIDs), DACL (ordered ACEs), desiredAccess mask. // Output: granted mask + a per-ACE trace of why.

function seAccessCheck(token, dacl, desiredAccess) { let remaining = desiredAccess; // bits still needed let granted = 0; // bits accumulated so far const trace = [];

// NULL DACL grants everything; empty DACL grants nothing. if (dacl === null) { return { status: 'GRANTED (NULL DACL)', granted: desiredAccess, trace: ['NULL DACL: full access'] }; } if (dacl.length === 0) { return { status: 'DENIED (empty DACL)', granted: 0, trace: ['Empty DACL: no access'] }; }

for (let i = 0; i < dacl.length; i++) { const ace = dacl[i]; const sidMatches = token.sids.includes(ace.sid); if (!sidMatches) { trace.push(`ACE ${i} (${ace.type} ${ace.sid}): SID not in token; skip`); continue; } if (ace.type === 'DENY') { const deniedBits = ace.mask & remaining; if (deniedBits !== 0) { trace.push(`ACE ${i}: DENY hits 0x${deniedBits.toString(16)} -> ACCESS_DENIED`); return { status: 'DENIED', granted: 0, trace }; } trace.push(`ACE ${i}: DENY ${ace.sid} 0x${ace.mask.toString(16)} -- no requested bit hit; skip`); } else if (ace.type === 'ALLOW') { const newBits = ace.mask & remaining; granted |= newBits; remaining &= ~newBits; trace.push(`ACE ${i}: ALLOW grants 0x${newBits.toString(16)}, remaining 0x${remaining.toString(16)}`); if (remaining === 0) { return { status: 'GRANTED', granted, trace }; } } } return { status: 'DENIED (end of DACL with bits unsatisfied)', granted: 0, trace }; }

// Demo: a token with the user's SID and BUILTIN\Users; DACL with explicit deny + Everyone allow. const token = { sids: ['S-1-5-21-A-B-C-1001', 'S-1-5-32-545', 'S-1-1-0'] }; const dacl = [ { type: 'DENY', sid: 'S-1-5-21-A-B-C-1001', mask: 0x00040000 }, // deny WRITE_DAC { type: 'ALLOW', sid: 'S-1-1-0', mask: 0x00120089 }, // FILE_GENERIC_READ { type: 'ALLOW', sid: 'S-1-5-32-545', mask: 0x001200A9 }, // GENERIC_READ + EXECUTE ]; console.log(seAccessCheck(token, dacl, 0x00040089)); `}

The runnable above implements three subtleties the prose can flatten. First: the NULL DACL versus empty DACL distinction. A descriptor with no DACL at all -- a literal NULL pointer where the list would be -- grants full access, on the theory that the writer expressed no policy and the kernel will not invent one. A descriptor with a DACL that exists but contains zero ACEs denies everything, because the writer expressed a policy and that policy has no allows. The single most common high-impact misconfiguration in the Windows codebase is code that meant to write the second and wrote the first, or vice versa.

Note: Newly-written code that "creates a file with no protection" almost always wants an empty DACL but ends up with a NULL DACL because of how the SECURITY_DESCRIPTOR initialisation defaults work. Verify with Get-Acl or icacls after creation; a NULL DACL surface in icacls looks like Everyone:(F) and is almost always a bug, not a feature [@ms-learn-how-dacls-control-access].

Second: ACE order is the caller's responsibility. The kernel walks the list in the order it finds it. The "canonical" order Windows expects is four-step, quoted verbatim from the Microsoft Learn reference [@ms-learn-order-of-aces]: "1. All explicit ACEs are placed in a group before any inherited ACEs. 2. Within the group of explicit ACEs, access-denied ACEs are placed before access-allowed ACEs. 3. Inherited ACEs are placed in the order in which they are inherited... 4. For each level of inherited ACEs, access-denied ACEs are placed before access-allowed ACEs."

The same page underlines who has to enforce the order: "Functions such as AddAccessAllowedAceEx and AddAccessAllowedObjectAce add an ACE to the end of an ACL. It is the caller's responsibility to ensure that the ACEs are added in the proper order." If the writer of the DACL hands the kernel an out-of-order list with a deny ACE buried after a wide allow ACE, the deny will be unreachable and the descriptor will silently grant more than the writer intended.

Third: there is no special case for "Everyone." The well-known SID S-1-1-0 exists in every token of every process on the machine; an ACE against it applies to every caller. There is no extra logic that says "if this is Everyone, treat it differently from any other group." James Forshaw made the point with characteristic bluntness in 2020: "don't forget S-1-1-0, this is NOT A SECURITY BOUNDARY. Lah lah, I can't hear you!" [@tiraniddo-sharing-logon-session]. The DACL evaluation algorithm does not know "Everyone" is special. It is a SID like any other.

That makes the SID namespace itself worth a tour. Microsoft documents the structure as a revision number, an identifier authority (a six-byte field that says which authority issued the SID), a list of sub-authorities, and a final relative identifier (RID) [@ms-learn-security-identifiers]. Microsoft's own page on SIDs is precise: "A security identifier (SID) is a unique value of variable length used to identify a trustee... When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group."

The well-known SIDs the kernel recognises by name include SYSTEM (S-1-5-18), LocalService (S-1-5-19), NetworkService (S-1-5-20), Everyone (S-1-1-0), Authenticated Users (S-1-5-11), and the four Mandatory Integrity Control levels (S-1-16-4096 / 8192 / 12288 / 16384) [@en-wiki-mic, @ms-learn-mic]. Machine-issued SIDs encode the machine's domain identity in the sub-authorities; domain-issued SIDs encode the domain identity. RID 500 is, by convention, the local Administrator account; RID 501 is the Guest account.

A variable-length, never-reused identifier for a trustee (user, group, machine, service, or capability) inside the Windows security model. SIDs are encoded in canonical form `S-R-I-S1-S2-...-RID`, where R is a revision number, I is the identifier authority, the Sn are sub-authorities issued by that authority, and RID is the relative identifier. Every ACE references an SID; every token contains a list of them [@ms-learn-security-identifiers].

James Forshaw documented in 2017 that Windows generates the per-service SID for NT SERVICE\<ServiceName> deterministically: it is the SHA-1 hash of the uppercased service name, formatted into the SID's sub-authority fields. This is why Windows can refer to running services as security principals without an explicit registration step -- the kernel derives the SID on demand [@tiraniddo-trustedinstaller-blog].

Two SID families this article will not derive: AppContainer Package SIDs (S-1-15-2-...) and capability SIDs (S-1-15-3-...). Both arrived with Windows 8 in 2012 and extend the matrix's subjects with code identity and capability tokens. The sibling App Identity article in this series carries the canonical derivation, including the Crockford-Base32 PublisherId derivation that produces a Package SID from an MSIX package signature [@app-identity-sibling]. Section 5 of this article will mention those SIDs in tokens; we will not redefine them here.

The DACL is half the story. What does the thread bring to the access check -- and why is the answer "whoever happens to hold the handle"?

5. Tokens as Bearer Credentials

A token is not a credential the way a password is. A token is a credential the way cash is: whoever holds it gets the rights. This is the single most important property in the article.

Microsoft splits tokens into two flavours by purpose [@ms-learn-access-tokens]. A primary token hangs off a process and represents the security identity that process runs as. Every process has exactly one. An impersonation token hangs off a thread and lets that thread temporarily act as someone else -- typically a network client whose request the thread is servicing. Tokens are kernel objects with handles, and like every other kernel object the kernel does not care how a process obtained the handle. If the handle resolves to a token in the kernel's table, the kernel grants the rights the token names.

A kernel object that names the security identity of a thread or process. It carries the user's SID, the SIDs of the user's groups, the privileges the user holds, an integrity level, an integrity-level mandatory policy, an optional list of *restricting* SIDs, a flag distinguishing primary from impersonation tokens, and the impersonation level (Anonymous / Identification / Impersonation / Delegation) [@ms-learn-access-tokens]. The kernel consults a token on every access check for the thread that holds it. A *primary token* is owned by a process and represents the identity the process runs as; every process has exactly one primary token. An *impersonation token* is owned by a thread and represents an identity the thread is temporarily acting on behalf of -- typically a network client. The primary / impersonation distinction is a discriminator inside the token itself, set when the token is created or duplicated [@ms-learn-access-tokens].

The impersonation flavour acquired its modern shape in Windows 2000. A token's impersonation level takes one of four values, ordered from least to most privileged for the impersonator. Anonymous lets the server know nothing about the client. Identification lets the server learn the client's SIDs but not act as the client. Impersonation lets the server perform local access checks as the client; this is the level a typical RPC server requests. Delegation lets the server forward the client's identity onto another machine, useful for multi-hop scenarios but a frequent source of relay-style bugs. Almost every Potato lineage attack consumes an Impersonation-level token; that is enough to call ImpersonateLoggedOnUser and run as the client [@itm4n-printspoofer-blog].

Microsoft documents a third token shape, the restricted token, that is rare in practice but worth understanding because it is the only place in the model where an explicit deny-list lives on the token itself rather than the descriptor. A restricted token combines three knobs: a list of SIDs converted to deny-only (their grants count for no allow ACE but their presence still triggers deny ACEs), a list of restricting SIDs that the access check must independently permit, and a list of privileges removed from the token's privilege set [@ms-learn-restricted-tokens].

The kernel runs SeAccessCheck twice and grants only the intersection: "When a restricted process or thread tries to access a securable object, the system performs two access checks: one using the token's enabled SIDs, and another using the list of restricting SIDs. Access is granted only if both access checks allow the requested access rights" [@ms-learn-restricted-tokens]. Restricted tokens are operationally niche because the same documentation requires applications using them to "run the restricted application on desktops other than the default desktop. This is necessary to prevent an attack by a restricted application, using SendMessage or PostMessage, to unrestricted applications on the default desktop" [@ms-learn-restricted-tokens]. Few applications can spare the desktop overhead.whoami /priv shows available privileges, not enabled privileges. The Enabled column is the load-bearing one: an available-but-disabled privilege does not affect any access check until the process explicitly enables it via AdjustTokenPrivileges. The discipline of leaving privileges disabled by default is a defence in depth that depends on the application not having an exploitable bug between disable and use.

A token also carries flags that drive specific runtime behaviours: a split-token indicator points at a linked full-administrator counterpart for the UAC scenario in Section 8; an AppContainer flag plus a Package SID and capability SIDs name an AppContainer-bound process. In every case, the kernel consults the token by handle and trusts the contents. The kernel does not ask how a process obtained the handle. It asks only what the token says.

This is the property that organises the rest of the article.

Key idea: The Windows access token is a bearer credential. Whichever process holds the handle gets the rights. The kernel does not ask how the handle was obtained; it asks only what the token says. This single property explains the entire Potato lineage, Mimikatz token::elevate, and most of the privilege-abuse canon. Once you see it, every later attack section in the article becomes the same bug repeated against a different token-acquisition primitive.

If the token is a bearer credential, anyone with a way to obtain a SYSTEM token's handle is SYSTEM. Every Potato in Section 10 will be a different way to provoke a SYSTEM-token handle into the attacker's process. But the access check has another input that bypasses the DACL entirely. What is it, and which attackers know about it?

6. Privileges as a Different Dimension

Privileges are not access rights. They are pre-checked superpowers. They live on the token, they bypass the DACL for specific operations, and they are baked into the kernel for those operations alone.

Microsoft's framing on Learn is exact: "Privileges differ from access rights in two ways: Privileges control access to system resources and system-related tasks, whereas access rights control access to securable objects" [@ms-learn-privileges]. The same page makes the operational consequence clear: "Most privileges are disabled by default" [@ms-learn-privileges]. A process that holds a privilege but has not enabled it (via AdjustTokenPrivileges) cannot use it. The discipline is "principle of least privilege at the millisecond level" -- the privilege is on the token, but it does nothing until the program explicitly turns it on for the next system call.

A named, kernel-recognised authority on the access token that lets the holder perform a specific class of operations the DACL evaluation alone would not permit. Privileges include `SeDebugPrivilege` (read/write any process), `SeImpersonatePrivilege` (act on a client's token), `SeAssignPrimaryTokenPrivilege` (start a process under a token), `SeBackupPrivilege` (read any file regardless of DACL), `SeRestorePrivilege` (write any file regardless of DACL), `SeTcbPrivilege` (act as the operating system), and `SeLoadDriverPrivilege` (load a kernel driver). Most are disabled by default and must be enabled via `AdjustTokenPrivileges` before use [@ms-learn-privileges].

The reason privileges deserve a section of their own is that five of them are equivalent to "I am SYSTEM" and the other dozen are housekeeping. The five-versus-housekeeping split is the load-bearing audit decision in any Windows hardening review. Step through them.

SeDebugPrivilege lets the holder open any process for full read and write, including processes running as SYSTEM. The privilege exists so that Visual Studio and WinDbg can debug code other users have started. The first move in almost every Mimikatz session is privilege::debug, which enables the privilege the local administrator already has on the token [@github-gentilkiwi-mimikatz, @en-wiki-mimikatz]. Once enabled, the next Mimikatz command opens lsass.exe and reads the credentials.

SeImpersonatePrivilege lets the holder accept any token offered by a client and act as that client. The privilege is held by every Windows service account by default -- IIS, SQL Server, the Print Spooler, scheduled tasks, Docker containers, Citrix, the entire population of background services that need to handle authenticated requests. This is the load-bearing privilege for the Potato lineage [@itm4n-printspoofer-blog]. Section 10 will spend twenty paragraphs on what a service account holding SeImpersonate can be tricked into doing; the privilege is the entry condition.

SeAssignPrimaryTokenPrivilege lets the holder launch a new process under any primary token. Combined with SeImpersonate, the pair gives an attacker the entire token-replay attack: get an impersonation handle to a SYSTEM token, then call CreateProcessAsUser to run a command as SYSTEM. itm4n quotes decoder_it on the operational consequence.

if you have SeAssignPrimaryToken or SeImpersonate privilege, you are SYSTEM. -- decoder_it, quoted by itm4n in the PrintSpoofer disclosure [@itm4n-printspoofer-blog]

SeBackupPrivilege lets the holder read any file regardless of DACL, on the theory that backup software has to. SeRestorePrivilege is the symmetric write privilege. The two together mean that a process holding both can rewrite any file on the machine, including service binaries.

The 2021 HiveNightmare / SeriousSAM vulnerability (CVE-2021-36934) is the worked example of what happens when the model assumes nobody but the backup process has read access to a sensitive file and the assumption breaks. The NVD description is exact: "An elevation of privilege vulnerability exists because of overly permissive Access Control Lists (ACLs) on multiple system files, including the Security Accounts Manager (SAM) database" [@nvd-cve-2021-36934]. The DACL on the live \Windows\System32\config\SAM was correct; the DACL on the Volume Shadow Copy mirror was overly permissive enough that any local user could read the SAM hashes through the shadow-copy device path.

Microsoft's fix required not just a patch but a manual operator step: "After installing this security update, you must manually delete all shadow copies of system files, including the SAM database, to fully mitigate this vulnerability" [@nvd-cve-2021-36934]. A patch alone could not erase the historical shadow copies that already had the wrong DACL.

SeTcbPrivilege lets the holder "act as the operating system" -- it is the privilege that grants identity to the kernel itself. Held only by LocalSystem services in well-administered environments. A non-system process that somehow acquired SeTcb is, in effect, indistinguishable from the kernel.

SeLoadDriverPrivilege lets the holder load a kernel driver. By itself the privilege is harmless, because the loaded driver still has to be properly signed for HVCI / Driver Signature Enforcement to accept it. Combined with a known-vulnerable signed driver, however, the privilege becomes the entry point for bring-your-own-vulnerable-driver (BYOVD) attacks: load a benign-looking but exploitable signed driver, then use its bug to execute arbitrary kernel code. Two worked examples bracket the class.

The kernel-read/write half of the class is best illustrated by Micro-Star's RTCore64.sys (CVE-2019-16098 [@nvd-cve-2019-16098]), the MSI Afterburner driver that "allows any authenticated user to read and write to arbitrary memory, I/O ports, and MSRs" [@nvd-cve-2019-16098]. In October 2022, the threat actors behind the BlackByte ransomware weaponised the primitive at scale [@sophos-blackbyte]: the dropper loaded RTCore64.sys, then walked the kernel's PspCreateProcessNotifyRoutine callback array and zeroed every entry, blinding every registered process-creation callback before the encryption stage ran.

Sophos's October 4, 2022 disclosure named the technique exactly: "We found a sophisticated technique to bypass security products by abusing a known vulnerability in the legitimate vulnerable driver RTCore64.sys. The evasion technique supports disabling a whopping list of over 1,000 drivers on which security products rely to provide protection" [@sophos-blackbyte].

The kernel-code-execution half of the class is GIGABYTE's gdrv.sys (CVE-2018-19320 [@nvd-cve-2018-19320]). The NVD description states the primitive directly: "The GDrv low-level driver in GIGABYTE APP Center v1.05.21 and earlier... exposes ring0 memcpy-like functionality that could allow a local attacker to take complete control of the affected system" [@nvd-cve-2018-19320]. A signed IOCTL accepts an attacker-supplied source pointer, destination pointer, and length, and copies kernel memory at ring 0 -- a write-what-where primitive that the attacker can compose with the read-anywhere primitive of RTCore64.sys to mint arbitrary kernel code execution.

CISA added GIGABYTE Multiple Products to the Known Exploited Vulnerabilities Catalog on October 24, 2022 with a remediation due date of November 14, 2022, citing in-the-wild exploitation [@nvd-cve-2018-19320]. The U.S. federal-civilian executive branch had two weeks to remediate; the rest of the install base did not.

Microsoft's structural answer is the Microsoft-recommended driver blocklist, enabled by default on every device since the Windows 11 2022 update [@ms-learn-driver-blocklist]. The Learn page is exact about coverage: the blocklist targets drivers with "known security vulnerabilities that an attacker could exploit to elevate privileges in the Windows kernel", and explicitly catches drivers whose behaviours "circumvent the Windows Security Model" [@ms-learn-driver-blocklist].

Both RTCore64.sys and gdrv.sys appear on the blocklist; the ride from disclosure to default-on enforcement was four years for RTCore64, four years for gdrv, and the same arc applies to every member of the class. Honourable mention: aswArPot.sys (CVE-2022-26522 / CVE-2022-26523 [@sentinelone-avast-avg]) shows the same pattern from a security-product driver, with SentinelLabs reporting "two high severity flaws in Avast and AVG... that went undiscovered for years affecting dozens of millions of users" before the silent fix [@sentinelone-avast-avg].

Note: On a Windows machine, holding any of SeDebugPrivilege, SeImpersonatePrivilege, SeAssignPrimaryTokenPrivilege, SeBackupPrivilege, or SeRestorePrivilege is operationally indistinguishable from being SYSTEM. The other privileges in the standard token (the long tail of SeShutdown, SeIncreaseWorkingSet, SeTimeZone, SeChangeNotify, SeUndock, SeIncreaseQuota...) are housekeeping. Audit the holders of the five accordingly: any non-LocalSystem-equivalent account that holds them is a target.

The DACL is the load-bearing thing for file access, but exactly one bad DACL on a sensitive file ends the model. HiveNightmare proved that the cost of getting a single security descriptor wrong on a single file is the entire credential database. The general rule the lesson encodes: every primitive in Section 3's input list has at least one production example where misuse of that primitive alone dropped the security model to zero.

Discretionary access control assumes the principal -- the user -- is the right unit of authorisation. By 2006, exploitable user-mode code had proven the principal was wrong. What did Microsoft do?

7. Mandatory Integrity Control: Stapling No-Write-Up onto DAC

November 2006. Vista releases to manufacturing, and for the first time in Windows history, the kernel's access check fires before the DACL walk -- on something other than the user's identity. The new layer is Mandatory Integrity Control (MIC), and it adds a four-level lattice to every securable object in the system.

Microsoft Learn frames MIC compactly. "MIC uses integrity levels and mandatory policy to evaluate access. Security principals and securable objects are assigned integrity levels that determine their levels of protection or access. For example, a principal with a low integrity level cannot write to an object with a medium integrity level, even if that object's DACL allows write access to the principal" [@ms-learn-mic]. The same page enumerates the levels: "Windows defines four integrity levels: low, medium, high, and system" [@ms-learn-mic]. The levels are encoded as four well-known SIDs: Low (S-1-16-4096), Medium (S-1-16-8192), High (S-1-16-12288), System (S-1-16-16384) [@en-wiki-mic].

A Windows kernel mechanism, introduced with Vista (released to manufacturing November 8, 2006; consumer general availability January 30, 2007 [@en-wiki-windows-vista]), that adds an integrity-level check to `SeAccessCheck`. Each securable object carries an integrity label inside its SACL; each access token carries an integrity level. An access whose direction violates the configured *mandatory policy* (typically *no-write-up*) is denied at the integrity check before the DACL walk runs. MIC is the mandatory layer the Windows DAC model historically lacked [@ms-learn-mic]. A linearly-ordered tag (Low / Medium / High / System) carried on every Windows process token and every securable object. The kernel uses the relative ordering to enforce mandatory policy independent of the object's DACL. The four well-known SIDs are S-1-16-4096 (Low), S-1-16-8192 (Medium), S-1-16-12288 (High), and S-1-16-16384 (System) [@en-wiki-mic].

The default policy is no-write-up. A process at integrity level $L$ cannot modify an object at integrity level greater than $L$, regardless of what the DACL says. Microsoft's example is the load-bearing one: a process running at Low IL cannot write to a Medium-IL object even if the DACL says Everyone has full control. The integrity check fires before the DACL walk; if the integrity check denies, the DACL is not consulted [@ms-learn-mic].

The integrity label is stored as a SYSTEM_MANDATORY_LABEL_ACE inside the SACL, not the DACL [@ms-learn-system-mandatory-label-ace]. The mask field on the label ACE encodes which directions of access the policy forbids: SYSTEM_MANDATORY_LABEL_NO_WRITE_UP (0x1), SYSTEM_MANDATORY_LABEL_NO_READ_UP (0x2), and SYSTEM_MANDATORY_LABEL_NO_EXECUTE_UP (0x4) [@ms-learn-system-mandatory-label-ace].

Storing the label in the SACL is a deliberate choice with one operational consequence: tools that copy the DACL but not the SACL silently drop the integrity label. The most common consequence is a Low-IL file getting copied to a new location and emerging with no integrity label, which defaults to Medium and unintentionally raises the object's protection. The opposite mistake -- a Medium-IL file losing its label and dropping to Low -- is the more dangerous one.

The no-write-up mask is the one to memorise, because it is the policy almost every label uses. When a Low-IL caller tries to act on a Medium-IL object, the kernel denies any access whose mapped result contains write-class bits, including the standard-rights WRITE_DAC (bit 18 of the 32-bit ACCESS_MASK [@ms-learn-access-mask]) and WRITE_OWNER (bit 19), the type-generic DELETE (bit 16), and the file-specific FILE_WRITE_DATA (0x2), FILE_APPEND_DATA (0x4), FILE_WRITE_EA (0x10), and FILE_WRITE_ATTRIBUTES (0x100) [@ms-learn-file-access-rights].

The presence of FILE_APPEND_DATA in that list matters operationally: a careless reader of the spec might assume that "append" semantics escape the no-write-up rule because they do not modify existing bytes. They do not. MIC denies both write modes, so log-only append handlers cannot be used as a write-up channel into a higher-IL object.

A second rule completes the model: process integrity inheritance. When a process is created, the kernel assigns it the minimum of the user's integrity level and the file's integrity level [@ms-learn-mic]. A medium-IL user running a low-IL executable gets a low-IL process. This is the rule that lets Internet Explorer 7 run at Low even when launched from a Medium user session.

The first MIC consumer was IE7 Protected Mode, which shipped with Windows Vista RTM (released to manufacturing November 8, 2006) [@wayback-skywing-uninformed-v8a6, @en-wiki-windows-vista]. (IE7 standalone for Windows XP, released October 18, 2006 [@en-wiki-ie7], runs without Protected Mode -- the feature depends on Vista's MIC kernel layer.) Skywing's Uninformed Volume 8 Article 6, "Getting Out of Jail: Escaping Internet Explorer Protected Mode," is the first public reverse-engineering of the implementation.

Skywing's framing remains the most-cited primer on the subject: "With the introduction of Windows Vista, Microsoft has added a new form of mandatory access control to the core operating system. Internally known as 'integrity levels', this new addition to the security manager allows security controls to be placed on a per-process basis. This is different from the traditional model of per-user security controls used in all prior versions of Windows NT" [@wayback-skywing-uninformed-v8a6]. IE7's Protected Mode pattern -- a Low-IL worker that does the dangerous parsing, paired with a Medium-IL broker that performs the system-changing operations on the worker's behalf -- became the template Windows would later generalise into AppContainer.User Interface Privilege Isolation (UIPI) is the window-message gate that uses MIC at the desktop. A Low-IL window cannot send SendMessage or PostMessage traffic to a Medium-IL or higher window. UIPI is the reason you cannot click-jack a UAC consent prompt from a normally-running browser process: the consent prompt runs at High IL, the browser runs at Medium [@en-wiki-mic].

Windows 8 generalised the MIC pattern into AppContainer. An AppContainer process gets a fresh Low-IL token plus an AppContainer flag, a Package SID that identifies the app, and a list of capability SIDs the app declared in its manifest. Microsoft Learn states the resulting isolation directly: "Windows ensures that processes running with a low integrity level cannot obtain access to a process which is associated with an app container" [@ms-learn-mic]. The Package SID and capability SID derivations are the subject of the App Identity sibling article in this series; we will not redefine them here [@app-identity-sibling].

MIC fixed the integrity boundary inside the kernel. But the same year shipped a separate retrofit for a different problem: why was the consumer admin running every clicked-on .exe with full administrative authority? And why did Microsoft refuse to call its answer a security boundary?

8. UAC, the Split-Token, and the Bypass Tradition

Vista's User Account Control is the most famous Windows security retrofit, and the only one whose own keepers explicitly published a document declaring it not a security boundary [@msrc-servicing-criteria]. The mechanism is precise. The bypass tradition is enormous. The classification is honest.

The mechanism first. Microsoft's documentation on how UAC works gives the verbatim recipe [@ms-learn-uac]: "When an administrator logs on, two separate access tokens are created for the user: a standard user access token and an administrator access token. The standard user access token... contains the same user-specific information as the administrator access token, but the administrative Windows privileges and SIDs are removed... is used to display the desktop by executing the process explorer.exe. Explorer.exe is the parent process from which all other user-initiated processes inherit their access token. As a result, all apps run as a standard user unless a user provides consent or credentials to approve an app to use a full administrative access token."

A Windows mechanism, introduced with Vista (released to manufacturing November 8, 2006 [@en-wiki-windows-vista]), in which an administrative user receives two linked tokens at logon: a *filtered* Medium-IL token without administrative privileges or SIDs, used by `explorer.exe` and every process descended from it, and a *full* High-IL administrative counterpart that the kernel hands out only after the user clicks through a consent prompt or supplies credentials. The two tokens reference each other through the `LinkedToken` field. UAC is a UX-and-default-behaviour mechanism, not an enforced security boundary [@ms-learn-uac, @msrc-servicing-criteria].

The split-token mechanism produces three elevation triggers. First, an executable can declare its required level in its manifest via the requestedExecutionLevel element (asInvoker, highestAvailable, or requireAdministrator). Second, certain Microsoft-signed binaries appear on an AutoElevate whitelist that the kernel consults; processes on the whitelist transparently get the full token without prompting. Third, COM components can be marked elevatable via the COM Elevation Moniker, which lets code instantiate Elevation:Administrator!new:{guid} (or Elevation:Highest!new:{guid}) to obtain a High-IL administrator COM caller -- not a SYSTEM caller; the moniker's supported run levels are Administrator and Highest [@ms-learn-com-elevation-moniker]. Method 41 (Oddvar Moe's ICMLuaUtil construction) is the canonical worked example.

The classification next. Microsoft's Security Servicing Criteria for Windows defines a security boundary as the logical separation between security domains with different trust levels, and gives the kernel-mode / user-mode separation as the canonical example [@msrc-servicing-criteria]. The criteria document then enumerates which boundaries Microsoft commits to servicing. UAC and admin-to-kernel are not on the enumerated list.

A security boundary provides a logical separation between the code and data of security domains with different levels of trust... the separation between kernel mode and user mode is a classic [...] security boundary. Microsoft software depends on multiple security boundaries to isolate devices on the network, virtual machines, and applications on a device. -- Microsoft Security Servicing Criteria for Windows [@msrc-servicing-criteria]

The "outside the enumerated list" classification has a concrete consequence: bypasses of UAC are not eligible for the same security-update treatment a kernel-mode-to-user-mode bypass would get. Mitigations are issued per-redirect, when an attacker's specific path becomes operationally noisy enough to warrant attention. The seventy-plus methods catalogued in UACMe are the empirical consequence.

Key idea: UAC was never a security boundary. The seventy-plus methods catalogued in UACMe are not bugs in UAC. They are the formal consequence of UAC's classification. Once you recognise that UAC is a UX-and-default-behaviour mechanism rather than an enforced boundary, the bypass tradition is legible as a feature being used as designed and the structural arc to Adminless makes sense.

The bypass canon. Walk it generation by generation.

Method 1 -- Leo Davidson, 2009. Davidson's Windows 7 UAC Whitelist writeup is the genealogical root of the UAC bypass tradition [@pretentiousname-davidson, @github-hfiref0x-uacme]. He noticed that sysprep.exe is on the AutoElevate whitelist and that, when launched from C:\Windows\System32\sysprep\, it loads several DLLs from the working directory. Use the IFileOperation COM interface (which the elevator treats as AutoApprove, enabling the file copy without prompting) to drop a malicious cryptbase.dll into %SystemRoot%\System32\sysprep\. Then trigger sysprep.exe -- which is on the AutoElevate whitelist -- and the auto-elevated process loads the attacker's DLL, and the attacker has a High-IL full administrative token.

Davidson's writeup quotes himself bluntly: "This works against the RTM (retail) and RC1 versions of Windows 7" [@pretentiousname-davidson]. UACMe Method 1 records the technique with structured metadata: "Author: Leo Davidson / Type: Dll Hijack / Method: IFileOperation / Target(s): \system32\sysprep\sysprep.exe / Component(s): cryptbase.dll / Implementation: ucmStandardAutoElevation / Works from: Windows 7 (7600) / Fixed in: Windows 8.1 (9600)" [@github-hfiref0x-uacme].

Method 25 -- Matt Nelson (enigma0x3), August 15, 2016. Seven years after Davidson, Nelson published "Fileless UAC Bypass Using eventvwr.exe and Registry Hijacking" [@enigma0x3-eventvwr-blog]. The bypass replaces the file-system DLL hijack with a registry redirect. Nelson noticed that eventvwr.exe, an AutoElevated binary, queries HKCU\Software\Classes\mscfile\shell\open\command before HKCR\mscfile\shell\open\command to find the command to run for the mscfile ProgID. His verbatim observation: "From the output, it appears that 'eventvwr.exe', as a high integrity process, queries both HKCU and HKCR registry hives to start mmc.exe" [@enigma0x3-eventvwr-blog]. HKCU is writable by the standard user; the user writes a malicious command line under that key, runs eventvwr.exe, and the auto-elevated process happily executes the user-supplied command line. The first fileless UAC bypass.

Method 33 -- winscripting.blog, 2017. Same primitive, different target. The fodhelper.exe binary is on the AutoElevate whitelist and queries HKCU\Software\Classes\ms-settings\shell\open\command to launch the Settings app. UACMe records the credit precisely: "Author: winscripting.blog / Type: Shell API / Method: Registry key manipulation / Target(s): \system32\fodhelper.exe / Component(s): Attacker defined / Implementation: ucmShellRegModMethod / Works from: Windows 10 TH1 (10240) / Fixed in: unfixed" [@github-hfiref0x-uacme]. Fixed in: unfixed. This is what "outside the enumerated list" looks like in practice: nine years after Method 1 and a year after Method 25 demonstrated the underlying class, the registry-redirect template was still being applied to fresh AutoElevate targets and shipping unmitigated.

Method 41 -- Oddvar Moe. The COM elevation moniker route. UACMe records: "Author: Oddvar Moe / Type: Elevated COM interface / Method: ICMLuaUtil" [@github-hfiref0x-uacme]. Instantiate the CMLuaUtil COM object via the elevation moniker from a Medium-IL process, get back a High-IL COM caller, and call its ShellExec method to run an attacker command line at High IL. The seam is the COM moniker registry's Elevation\Enabled key, which marks specific CLSIDs as elevation-capable.

Method 31 (sdclt), 29, 34, ... The pattern repeats. Matt Nelson's sdclt.exe variants exploit the backup-restore UI's registry lookups. Forshaw's schtasks variant exploits the scheduled-task COM interface. The UACMe README enumerates the lot with the laconic one-liner "Defeating Windows User Account Control by abusing built-in Windows AutoElevate backdoor" [@github-hfiref0x-uacme]. Most of the methods reduce to the same primitive: an AutoElevated Microsoft-signed binary performs a lookup that the standard user can redirect, the standard user supplies an attacker-controlled answer, and the auto-elevated binary executes attacker-controlled work.

flowchart TD A[User Medium-IL process] --> B[Write attacker command line into HKCU writable seam: registry key, file system path, scheduled-task XML] B --> C[Trigger AutoElevated Microsoft-signed binary: sysprep.exe / eventvwr.exe / fodhelper.exe / sdclt.exe / etc.] C --> D[AutoElevate flag honoured by kernel] D --> E[Binary launched at High IL with full administrative token] E --> F[Binary performs lookup: HKCU registry / DLL search path / scheduled-task definition] F --> G[Lookup returns attacker-supplied content] G --> H[High-IL process executes attacker work] Mark Russinovich's June 2007 *TechNet Magazine* cover story, "Inside Windows Vista User Account Control," is the canonical practitioner walkthrough of the split-token model and is preserved on the Wayback Machine [@wayback-russinovich-uac-technet]. Russinovich opens by naming the misunderstanding: "User Account Control (UAC) is an often misunderstood feature in Windows Vista... In this article I discuss the problems UAC solves and describe the architecture and implementation of its component technologies." The framing throughout the article is that UAC's purpose is to create the *expectation* that consumer software would run as a standard user, and to push the developer community to refactor away from gratuitous administrator requirements. That framing -- UAC as a UX and migration mechanism -- is consistent with the eventual MSRC servicing-criteria position: not a defended boundary, but a behaviour gate.

Note: Microsoft's servicing-criteria position means a UAC bypass that does not also cross a serviced security boundary is not, by policy, eligible for a security update. Mitigations land when the operational footprint of a particular bypass becomes large enough to justify one. Track UAC mitigations by KB number, not by feature description; consult the UACMe README's Fixed in: field as the institutional memory [@github-hfiref0x-uacme, @msrc-servicing-criteria].

UAC bypasses redirect the elevation flow that produces a token. A different attack family takes the result and steals tokens from already-elevated SYSTEM services. Where do those attacks come from, and why are they all the same bug?

9. The Object Manager and the Lookup Surface

SeAccessCheck evaluates a security descriptor it has been handed. Who hands it the descriptor?

The kernel's Object Manager does, after walking a name. Every named kernel object lives somewhere in a hierarchical namespace rooted at \. Devices live under \Device. Synchronisation primitives live under \BaseNamedObjects. Pre-resolved DLL names live under \KnownDlls. Per-session subtrees live under \Sessions. The DOS device prefix \GLOBAL?? (and its session-local sibling \??) holds drive-letter symbolic links into the device tree. When a process calls OpenObject, the Object Manager parses the name, walks the tree, and returns the object whose security descriptor SeAccessCheck will then evaluate.

The kernel performs the lookup before the access check. This sequencing creates a parallel attack surface that bypasses SeAccessCheck entirely. If the attacker can influence the name resolution -- redirect a \??\ symbolic link, plant a junction in NTFS that re-targets a directory traversal, hardlink a low-privilege file at a path the kernel will trust because of the parent directory's descriptor -- then by the time SeAccessCheck runs, it is being asked about a different object than the original code path intended to open.

The HiveNightmare lookup path is the canonical worked example. The exploit reads the SAM database not via \Windows\System32\config\SAM (which has a tight DACL) but via \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy*\Windows\System32\config\SAM. That path resolves through the Object Manager's \GLOBAL?? symbolic link, into the device tree, into a Volume Shadow Copy mirror of the original volume, into a copy of SAM whose DACL was, until the August 2021 patch, readable by any authenticated local user (BUILTIN\Users) [@nvd-cve-2021-36934].

The lookup-phase attack class is wider than file-system shadow copies. Object Manager symbolic links and NTFS hard links both produce the same primitive: the kernel resolves a name through an attacker-influenced redirect and ends up evaluating SeAccessCheck against a different security descriptor than the calling code intended.

CVE-2020-0668, the Service Tracing elevation-of-privilege bug Clément Labro disclosed in February 2020, is the textbook symbolic-link case [@itm4n-cve-2020-0668-blog]. The Service Tracing infrastructure under HKLM\SOFTWARE\Microsoft\Tracing is user-writable, and several SYSTEM services -- IKEEXT, RasMan, the Update Session Orchestrator service -- consult those keys to find a tracing log path. When the log file exceeds the configured MaxFileSize, the service renames it from MODULE.LOG to MODULE.OLD, deleting any existing MODULE.OLD first.

itm4n's exploit is exactly the one his blog post names: "All you need to do is set the target directory as a mountpoint to the \RPC Control object directory and then create two symbolic links: A symbolic link from MODULE.LOG to a file you own; A symbolic link from MODULE.OLD to any file on the file system" [@itm4n-cve-2020-0668-blog]. The mountpoint reroutes the kernel's name resolution into an Object Manager directory the attacker controls; the two symlinks reroute the rename operation; the SYSTEM service ends up performing an arbitrary file move with kernel authority. Forshaw's googleprojectzero/symboliclink-testing-tools repository [@github-projectzero-symlink-tools] provides the primitive library the exploit consumes -- CreateSymlink, CreateMountPoint, BaitAndSwitch -- and the repository is, in effect, the institutional library every Object Manager lookup-phase attack of the past decade has linked against.

The NTFS hard-link case predates the symbolic-link case by half a decade. James Forshaw's December 2015 Project Zero post, "Between a Rock and a Hard Link," is the canonical primary source [@projectzero-blog-rockandhardlink]. Forshaw observes that hard links have been a feature of NTFS "since it was originally designed", and that their relevance to local privilege escalation is exactly the lookup-vs-access-check sequencing this section describes: "Why are hard links useful for local privilege escalation? One type of vulnerability is exploited by a file planting attack, where a privilege service tries to write to a file in a known location" [@projectzero-blog-rockandhardlink].

The worked example Forshaw walks is CVE-2015-4481, a Mozilla Maintenance Service hard-link primitive: any user can write a status log to C:\ProgramData\Mozilla\logs\maintenanceservice.log, and during the service's pre-write BackupOldLogs rename a brief window opens in which the attacker can replace the about-to-be-written log path with a hard link to an arbitrary system file. The service's subsequent write -- which it performs with its own SYSTEM authority -- ends up overwriting the system file. The DACL on the source file (the Mozilla log directory) was correct; the DACL on the destination file (the system binary) was correct; the kernel arrived at the destination by resolving a hard-link name the attacker had planted, and SeAccessCheck saw only the destination DACL, not the planted-link DACL [@projectzero-blog-rockandhardlink]. Microsoft's MS15-115 mitigation tightened the kernel's hard-link semantics for sandboxed callers (the kernel's NtSetInformationFile now requires FILE_WRITE_ATTRIBUTES on the target handle when the caller's token has the sandboxed-token flag, matching what the user-mode CreateHardLink wrapper had always opened the target with). The fix closes the sandboxed-process branch of the bug class but, as Forshaw notes, does nothing for the Maintenance Service vulnerability itself, which is exploited by a non-sandboxed local user; the structural fix is to write the log to a directory the user cannot create files in, not to enforce a hard-link mask -- a structural fix to the lookup phase, not the access-check phase.

The two examples generalise the rule. The kernel resolves names before checking the requesting user's authority over the destination. The DACL at target.path and the DACL at attacker.planted.path after a junction or hard-link redirect can be different; SeAccessCheck evaluates the descriptor it arrives at, not the descriptor the original caller intended. Capability systems would resolve names through unforgeable handles instead of strings, and the redirect class would not exist by construction [@en-wiki-capability-based-security]. Windows checks the descriptor on every OpenObject because the name is a forgeable string. The Object Manager namespace is therefore an attack surface whose load-bearing fix is structural rather than per-bug.The Object Manager's namespace is not documented as policy in the same way SeAccessCheck's algorithm is. The de facto modern documentation is empirical: practitioners enumerate the namespace with tools that read kernel structures directly. James Forshaw's NtObjectManager PowerShell module, part of the Project Zero sandbox-attacksurface-analysis-tools repository, is the dominant such tool [@github-projectzero-sandbox-attacksurface]. The repository's banner is exact: "NtObjectManager: A powershell module which uses NtApiDotNet to expose the NT object manager."

The James Forshaw / Project Zero corpus is the systematic reference for the Object Manager attack surface. Forshaw's "Sharing a Logon Session a Little Too Much" (April 2020) names a primitive PrintSpoofer would later consume: when the LSA creates a token for a new logon session, it caches the token for later retrieval. Forshaw's verbatim explanation: "when LSASS creates a Token for a new Logon session it stores that Token for later retrieval. For the most part this isn't that useful, however there is one case where the session Token is repurposed, network authentication" [@tiraniddo-sharing-logon-session]. The cached token plus a named-pipe path-validation bug becomes a non-DCOM SYSTEM-token primitive that no DACL touches.

The lookup surface is half the attack story. The other half is the token surface, and the canonical example of the token surface is a six-year, eight-tool lineage.

10. The Potato Lineage: Eight Tools, One Bug (2016-2021)

January 16, 2016. Stephen Breen of Foxglove Security publishes "Hot Potato." The disclosure post opens with a sentence the article will earn the right to repeat: "Microsoft is aware of all of these issues and has been for some time (circa 2000). These are unfortunately hard to fix without breaking backward compatibility and have been [used] by attackers for over 15 years" [@foxglove-hot-potato-blog]. Six years and seven tools later, that admission still describes the situation.

The single underlying primitive. A low-privileged service account holding SeImpersonatePrivilege (which IIS, SQL Server, the Print Spooler, scheduled tasks, Docker, Citrix, and almost every managed-service account hold by default) tricks SYSTEM into authenticating to a TCP, RPC, or named-pipe endpoint the attacker controls. The attacker's endpoint accepts the authentication, ends up with an impersonation handle to a SYSTEM token, and calls ImpersonateLoggedOnUser followed by CreateProcessAsUser to run arbitrary code as SYSTEM. Same primitive, eight tools, six years.

sequenceDiagram participant Attacker as Attacker (service account, SeImpersonate) participant Coercer as Coercion primitive (NBNS / DCOM / EFSRPC / Spooler RPC) participant SYSTEM as SYSTEM service participant Endpoint as Attacker-controlled local endpoint Attacker->>Coercer: Trigger coercion (e.g. EfsRpcOpenFileRaw, BITS CoGetInstanceFromIStorage) Coercer->>SYSTEM: Tell SYSTEM to authenticate SYSTEM->>Endpoint: NTLM authentication to attacker endpoint Endpoint->>Endpoint: Accept NTLM, build impersonation token Attacker->>Attacker: ImpersonateLoggedOnUser(SYSTEM token) Attacker->>Attacker: CreateProcessAsUser(SYSTEM token, "cmd.exe") Note over Attacker: SYSTEM shell

Walk the lineage one paragraph at a time.

Hot Potato (Stephen Breen / Foxglove, January 2016) [@foxglove-hot-potato-blog]. The original. Hot Potato chains three Windows defaults: NBT-NS (NetBIOS name service) spoofing on the local network, the Web Proxy Auto-Discovery (WPAD) protocol's automatic proxy lookup, and Windows Update's HTTP-to-SMB NTLM relay. The exploit poisons NBT-NS so that the SYSTEM-running Windows Update service resolves WPAD to the attacker's local listener; the attacker's listener serves a proxy configuration that proxies SMB through localhost; the Windows Update service authenticates to the attacker's localhost SMB endpoint as SYSTEM. Foxglove's verbatim summary: "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-blog].

Rotten Potato (Stephen Breen and Chris Mallz / Foxglove, September 2016) [@foxglove-rotten-potato-blog]. The successor abandons the network-protocol fragility for a DCOM activation trick that James Forshaw had published as Project Zero issue 325. The attacker calls CoGetInstanceFromIStorage with the BITS CLSID {4991d34b-80a1-4291-83b6-3328366b9097} and a custom marshalled IStorage pointer; the COM activation runs on the local DCOM server (which runs as SYSTEM) and authenticates back to a TCP listener the attacker controls.

The Foxglove blog states the three steps verbatim: "1. Trick the 'NT AUTHORITY\SYSTEM' account into authenticating via NTLM to a TCP endpoint we control. 2. Man-in-the-middle this authentication attempt (NTLM relay) to locally negotiate a security token for the 'NT AUTHORITY\SYSTEM' account. 3. Impersonate the token... This can only be done if the attackers current account has the privilege to impersonate security tokens" [@foxglove-rotten-potato-blog]. The same post credits the Project Zero work directly: "this work is derived directly from James Forshaw's BlackHat talk and Google Project Zero research" [@foxglove-rotten-potato-blog].

Juicy Potato (decoder_it and ohpe, 2018) [@github-ohpe-juicy-potato]. A weaponised, configurable Rotten Potato. The repository README is exact about lineage and entry conditions: "RottenPotatoNG and its variants leverages the privilege escalation chain based on BITS service having the MiTM listener on 127.0.0.1:6666 and when you have SeImpersonate or SeAssignPrimaryToken privileges. ... We decided to weaponize RottenPotatoNG: Say hello to Juicy Potato" [@github-ohpe-juicy-potato].

Juicy Potato adds a CLSID brute-list (so the attacker can cycle through DCOM activations until one works on the target Windows version), a configurable listener port, and a configurable target binary. The repo's own framing of when it works is the article's PullQuote-worthy line: "If the user has SeImpersonate or SeAssignPrimaryToken privileges then you are SYSTEM" [@github-ohpe-juicy-potato]. Juicy Potato was killed by a Windows 10 1809 / Server 2019 mitigation that prevented the OXID resolver from being queried on a port other than 135. The mitigation was the first time Microsoft had touched the underlying primitive.

Rogue Potato (Antonio Cocomazzi and Andrea Pierini, May 2020) [@decoder-rogue-potato-blog]. The bypass for the loopback-OXID mitigation. Decoder's blog states the engineering problem and the fix in two sentences: "Starting from Windows 10 1809 & Windows Server 2019, its no more possible to query the OXID resolver on a port different than 135" [@decoder-rogue-potato-blog]. Rogue Potato works around the constraint by routing the OXID resolution through an attacker-controlled remote OXID resolver, typically reached via socat tcp-listen:135,fork TCP:attacker:9999. The remote resolver returns a string binding pointing back at the attacker's local listener; the constraint is satisfied (the OXID resolver is on port 135) but the listener it ultimately reaches is the attacker's. The lineage extends.

PrintSpoofer (Clément Labro / itm4n, May 2020) [@github-itm4n-printspoofer, @itm4n-printspoofer-blog]. The same week as Rogue Potato, a different no-DCOM, no-OXID variant lands. PrintSpoofer drops DCOM entirely. It uses the Print Spooler RPC method RpcRemoteFindFirstPrinterChangeNotificationEx to coerce the spooler (running as SYSTEM) to call back to a named pipe whose path the attacker controls. A path-validation bypass on the named-pipe name lets the attacker capture the SYSTEM credential the spooler offers.

itm4n's repository description summarises the entry condition: "From LOCAL/NETWORK SERVICE to SYSTEM by abusing SeImpersonatePrivilege on Windows 10 and Server 2016/2019" [@github-itm4n-printspoofer]. The blog post opens with credit and the canonical decoder_it quote: "I want to start things off with this quote from @decoder_it: 'if you have SeAssignPrimaryToken or SeImpersonate privilege, you are SYSTEM'" [@itm4n-printspoofer-blog].

RemotePotato0 (Cocomazzi and Pierini, 2021) [@github-antoniococo-remotepotato0]. The first Potato to escape the local machine. A cross-session DCOM activation lets the attacker reach a token from a different logged-on user; a cross-protocol RPC-to-LDAP relay then turns that user's authentication into a domain-administrator action against Active Directory.

The README is candid about the shape of the response: "UPDATE 21-10-2022: The main exploit scenario RPC->LDAP of RemotePotato0 has been fixed... Just another 'Won't Fix' Windows Privilege Escalation from User to Domain Admin. RemotePotato0 is an exploit that allows you to escalate your privileges from a generic User to Domain Admin... It abuses the DCOM activation service and trigger an NTLM authentication of any user currently logged on in the target machine" [@github-antoniococo-remotepotato0]. Just another "Won't Fix" Windows Privilege Escalation is the precise framing: the underlying primitive is structural, the 2022 fix addressed the specific RPC-to-LDAP path, and the construction continues to work for other relay targets.

PetitPotam (Lionel Gilles / topotam77, July 2021) [@github-topotam-petitpotam, @nvd-cve-2021-36942]. Not strictly a local-LPE Potato, but the source of the EFSRPC coercion primitive that local-LPE Potatoes consume. PetitPotam exploits the Encrypting File System remote-procedure-call protocol's EfsRpcOpenFileRaw (and several other functions) to coerce a Windows host to authenticate to an attacker-controlled endpoint.

The README is exact about the interface choices: "PoC tool to coerce Windows hosts to authenticate to other machines via MS-EFSRPC EfsRpcOpenFileRaw or other functions :) The tools use the LSARPC named pipe with inteface c681d488-d850-11d0-8c52-00c04fd90f7e because it's more prevalent. But it's possible to trigger with the EFSRPC named pipe and interface df1941c5-fe89-4e79-bf10-463657acf44d" [@github-topotam-petitpotam]. PetitPotam's most-cited use case is cross-machine relay against Active Directory Certificate Services, but the EFSRPC coercion is also locally consumable.

SharpEfsPotato (bugch3ck, 2021) [@github-bugch3ck-sharpefspotato]. The local-machine variant of the PetitPotam coercion. The README is precise about lineage: "Local privilege escalation from SeImpersonatePrivilege using EfsRpc. Built from SweetPotato by @_EthicalChaos_ and SharpSystemTriggers/SharpEfsTrigger by @cube0x0" [@github-bugch3ck-sharpefspotato]. SharpEfsPotato uses EfsRpcOpenFileRaw against the local LSARPC pipe to coerce SYSTEM to authenticate to a local endpoint, then performs the by-now-familiar token capture and CreateProcessAsUser.This article's stage-4 source verification corrected an attribution that had been carried forward from the original scope file: SharpEfsPotato's canonical repository is bugch3ck/SharpEfsPotato, not the often-cited ly4k/SharpEfsPotato. The latter URL returns HTTP 404. Cross-references that point at the ly4k URL should be updated to point at bugch3ck [@github-bugch3ck-sharpefspotato].

The pattern across the lineage is that the mitigation that did break a tool was always specific (the loopback-OXID restriction, the cross-session DCOM partial fix, the EFSRPC coercion partial mitigation in KB5005413), and the mitigation that would break the family is structural (remove SeImpersonatePrivilege from service accounts, end NTLM-to-self-as-machine relay, retire the bearer-credential property of tokens). Microsoft has shipped the first kind of fix seven times across the lineage and continues to ship them; the second kind requires architectural changes that arrive in successor articles in this series.

Tool	Year	Author(s)	Coercion vector	Mitigation that broke it	Mitigation that did not
Hot Potato	2016	Breen	NBT-NS + WPAD + HTTP-to-SMB relay	Disable WPAD; KB3146965	`SeImpersonate` on services
Rotten Potato	2016	Breen, Mallz	DCOM `CoGetInstanceFromIStorage` (BITS)	(none specific until Juicy fix)	`SeImpersonate` on services
Juicy Potato	2018	decoder_it, ohpe	DCOM CLSID brute-list, configurable port	Loopback-OXID restriction (1809 / 2019)	`SeImpersonate` on services
Rogue Potato	2020	Cocomazzi, Pierini	Remote OXID resolver via `socat`	Cross-session DCOM partial fix	`SeImpersonate` on services
PrintSpoofer	2020	Labro	Spooler RPC + named-pipe path bypass	KB5005010 (PrintNightmare-era spooler hardening) [@nvd-cve-2021-34527]	`SeImpersonate` on services
RemotePotato0	2021	Cocomazzi, Pierini	Cross-session DCOM + RPC-to-LDAP relay	RPC-to-LDAP relay fix (October 2022)	`SeImpersonate` on services; remaining relay targets
PetitPotam	2021	Gilles	EFSRPC coercion via LSARPC	KB5005413 partial; ADCS hardening [@nvd-cve-2021-36942]	`SeImpersonate` on services; other relay targets
SharpEfsPotato	2021	bugch3ck	Local EFSRPC coercion	(none specific to local variant)	`SeImpersonate` on services

Eight tools. One privilege. Every "mitigation that did not" cell points at the same thing: a bearer-token model plus SeImpersonatePrivilege on a service account.

Eight tools in six years against the same underlying primitive is not a tooling coincidence. It is the empirical signature of the bearer-credential property and the omnipresent service-account `SeImpersonate` privilege. The Hot Potato post's verbatim "hard to fix without breaking backward compatibility" admission [@foxglove-hot-potato-blog] is the same argument Microsoft eventually formalised in the security-servicing-criteria position: this surface is intentionally retained for compatibility, and structural changes belong in a different architecture. The article earns the bridge to the Adminless and NTLMless successors here, six years before the calendar gets there.

Note: A service account holding SeImpersonatePrivilege plus any RPC interface that authenticates to attacker-controllable endpoints equals SYSTEM. Eight Potatoes in six years prove this is structural, not a tooling fad. Audit every server: any non-LocalSystem-equivalent process holding SeImpersonate or SeAssignPrimaryToken should be treated as a Potato target until proven otherwise. Pre-deploy per-service SIDs and Group Managed Service Accounts where possible to constrain the blast radius [@github-itm4n-printspoofer].

Eight Potatoes prove the bearer-token property is unkillable by point fixes. But what does an attacker who is already admin do? The answer is the most-cited offensive Windows tool of the past fifteen years.

11. Mimikatz, Conditional ACEs, and the Edges of the Model

May 2011. Benjamin Delpy releases the first version of Mimikatz [@en-wiki-mimikatz]. Wikipedia's biographical summary is precise: "He released the first version of the software in May 2011 as closed source software" [@en-wiki-mimikatz]. Fifteen years later, every offensive Windows engagement on Earth still reaches for it.

Mimikatz contains many modules. Two of them sit directly on the access-control surface and are worth naming explicitly. The repository's own command surface lists them as privilege::debug and token::elevate [@github-gentilkiwi-mimikatz].

privilege::debug is one line of code: the command enables SeDebugPrivilege on the caller's token. Any local administrator on stock Windows holds the privilege on the token by default; the command flips it from Available to Enabled via AdjustTokenPrivileges. With SeDebugPrivilege enabled, the calling process can OpenProcess against any other process on the machine, including SYSTEM-level services such as lsass.exe. Every Mimikatz session that wants to read process memory begins with privilege::debug.

token::elevate is three lines of code in spirit. The command opens a SYSTEM-owned process (typically lsass.exe), calls OpenProcessToken to retrieve a handle to the SYSTEM token, calls DuplicateTokenEx to duplicate the handle for impersonation, and calls SetThreadToken to attach the duplicated SYSTEM token to the calling thread. The thread is now SYSTEM. The bearer-token property in three lines of code.

This article does not cover sekurlsa::logonpasswords. That command is the most-cited Mimikatz capability in journalism (it reads cached credentials from lsass.exe), but the credential-storage surface and the Credential Guard mitigation belong to the Secure Kernel sibling article in this series [@secure-kernel-sibling]. For the purposes of this article, the lesson stops at token::elevate.

The lesson is the structural concession. With administrator rights on the local machine and SeDebugPrivilege enabled, the access-control model has no defence for "I will pretend to be a different process," because admin equals kernel by Microsoft's own boundary definition [@msrc-servicing-criteria]. The DACL evaluation algorithm does not protect against a caller who can read and write arbitrary kernel memory. The privilege list does not protect against a caller who can rewrite the privilege check. The integrity check does not protect against a caller who can edit the integrity label. Every primitive in the model is, by construction, defenceless against an attacker who has crossed the boundary the model considers itself responsible for defending.

Note: With administrator rights and SeDebugPrivilege, the Windows access-control model has no defence for "I will pretend to be a different process," because admin equals kernel by Microsoft's own boundary definition. Mimikatz token::elevate is the canonical demonstration. The structural fix for selected secrets is Credential Guard, which moves the secret out of the NT kernel's address space entirely. See the Secure Kernel sibling article for the architecture [@secure-kernel-sibling, @msrc-servicing-criteria].

The model has been extended in only one structural direction since 1993, and that direction is the subject of the access matrix. Conditional ACEs and Dynamic Access Control (DAC) shipped together in Windows Server 2012 and Windows 8 [@ms-learn-dac]. They are the only extension of the access-matrix subject Microsoft has shipped in thirty-three years.

The mechanism is twofold. First, ACEs gain an expression syntax. The SDDL ACE strings page documents XA, XD, XU, and ZA as conditional callback variants of the basic allow / deny / audit / object-allow ACE types [@ms-learn-ace-strings]. A conditional ACE carries an expression in addition to a SID and an access mask, and the kernel evaluates the expression against the token's claims at access time. The canonical example is (XA;;FA;;;AU;(@User.Department=="Finance")) -- an allow-callback ACE that grants FILE_ALL_ACCESS to Authenticated Users if the token carries a Department claim equal to "Finance".

Second, the token gains claims. A claim is a typed key-value pair attached to the token by Active Directory at logon. Claims can be sourced from the user's AD attributes, the device's AD attributes, or resource properties on the object. Microsoft Learn states the role they play: "A central access rule is an expression of authorization rules that can include one or more conditions involving user groups, user claims, device claims, and resource properties. Multiple central access rules can be combined into a central access policy" [@ms-learn-dac].

A Central Access Policy (CAP) is a set of Central Access Rules (CARs), each of which is a conditional-ACE expression. The CAP is applied to file shares; the file-share metadata says "evaluate this CAP for every access," and the CAP's expressions reference token claims. The DAC scenario guidance enumerates the deployment-side primitives -- automatic and manual file classification, central access policies for safety-net authorisation, central audit policies for compliance reporting, and Rights Management Service encryption for data-in-use protection [@ms-learn-dac-scenario].

The reason DAC has not displaced classic DAC outside file-server scenarios is in the same Microsoft Learn page: "Dynamic Access Control is not supported in Windows operating systems prior to Windows Server 2012 and Windows 8. When Dynamic Access Control is configured in environments with supported and non-supported versions of Windows, only the supported versions will implement the changes" [@ms-learn-dac]. Heterogeneous environments fall back to classic DAC. Airgapped environments without a working AD plus AD FS plane have no claims to evaluate. Conditional ACEs are a real extension of the model's subject dimension; they are also a real bet that the AD-and-Kerberos plane is healthy enough to evaluate them on every access.AppContainer's Package SIDs (Windows 8) and conditional ACEs (Server 2012) shipped the same year. Both extend the subject dimension of the access matrix -- one with code identity, one with attribute claims. Neither closes the kernel-equals-admin gap. The two extensions are coordinate, not stacked: a conditional ACE can reference a Package SID; a Package SID can be the subject of a conditional ACE [@ms-learn-dac, @app-identity-sibling].

The model has been extended in two coordinate dimensions in thirty-three years. It has not been replaced. So what does the whole thing look like put together -- and what does it actually fail at?

12. The 2026 Plane: Ten Primitives, One Decision

Run a single OpenObject call on a Windows 11 machine and walk the kernel's path. Every primitive the article has introduced fires for that one call.

flowchart LR A[User-mode caller] -->|OpenObject name, DesiredAccess, Token| B[Object Manager] B -->|Resolve name in namespace| C[Namespace lookup] C -->|Fetch security descriptor| D[Object header SD] D --> E[SeAccessCheck] E --> F[Generic-to-specific mapping] F --> G[Mandatory Integrity Control check] G -->|Pass| H[AppContainer / capability check] H --> I[Privilege bypass: SeBackup / SeRestore / SeDebug] I --> J[DACL walk in canonical order] J --> K[Conditional ACE expression evaluation] K --> L[GrantedAccess accumulated] L --> M[SACL audit ACE emit if matched] M --> N[Return HANDLE or STATUS_ACCESS_DENIED]

The diagram is the article in one figure. Read it left to right. Every box is a primitive named in Sections 3 to 11. Every famous Windows escalation tool of the last twenty-five years targets one of those boxes:

#	Primitive	Section introduced	Year shipped	Canonical primary citation	Canonical attack
1	Security Reference Monitor	3	1993	[@ms-learn-access-control]	(Underlying surface; not directly attacked)
2	Security Identifier (SID)	4	1993	[@ms-learn-security-identifiers]	Misused well-known SIDs ("Everyone is just a SID")
3	Access Token	5	1993	[@ms-learn-access-tokens]	The Potato lineage; Mimikatz `token::elevate`
4	Security Descriptor	3	1993	[@ms-learn-how-dacls-control-access]	HiveNightmare (CVE-2021-36934)
5	DACL + ACE	4	1993	[@ms-learn-how-dacls-control-access, @ms-learn-order-of-aces]	NULL DACL misconfigurations; out-of-order ACEs
6	SACL + audit	3	1993	[@ms-learn-access-control]	Tools that copy DACL but not SACL silently drop integrity labels
7	Privilege	6	1993	[@ms-learn-privileges]	Mimikatz `privilege::debug`; `SeBackup` abuse
8	Mandatory Integrity Control	7	2007	[@ms-learn-mic]	IE7 Protected Mode broker bypasses
9	UAC split-token	8	2007	[@ms-learn-uac]	UACMe: 70+ AutoElevate-redirect methods [@github-hfiref0x-uacme]
10	Conditional ACE / DAC	11	2012	[@ms-learn-dac, @ms-learn-ace-strings]	Falls back to classic DAC in heterogeneous environments

Note: The Windows access-control model is one decision plane, not a feature catalogue. Every securable Windows operation resolves through SeAccessCheck against five fixed inputs. Every famous escalation tool of the last twenty-five years attacks one of those inputs. Recognising the model as a single plane is the key to using its vocabulary against any specific attack.

The plane is whole. It is also full of structural holes its own keepers have publicly admitted. What are they?

13. The Five Structural Limits

Microsoft's Security Servicing Criteria for Windows defines a security boundary as "a logical separation between the code and data of security domains with different levels of trust... the separation between kernel mode and user mode is a classic [...] security boundary" [@msrc-servicing-criteria]. The criteria document then enumerates which boundaries Microsoft commits to servicing. The kernel-mode / user-mode boundary qualifies. UAC and admin-to-kernel are not in the enumerated list. Once that admission is on the public record, the model's structural arc becomes legible. Five derived limits flow from the concession.

Limit 1: Admin equals kernel. Any compromise with administrator rights can rewrite the model's own enforcement code. Consequence: Mimikatz, every kernel-driver-loading attack, every signed-driver bring-your-own-vulnerable-driver path. Successor: VBS Trustlets, which host secrets and policy enforcement in the Virtual Trust Level 1 user-mode environment that the VTL0 NT kernel cannot read or modify. Detailed coverage belongs to the Secure Kernel sibling article in this series [@secure-kernel-sibling].

Limit 2: Tokens are bearer credentials. Whichever process holds the handle gets the rights. The kernel does not ask how the handle was obtained. Consequence: the entire Potato lineage (eight tools, six years), Mimikatz token::elevate, every cross-session token-theft attack. Successor: Adminless / Administrator Protection, which retires the long-lived filtered/full token pair in favour of a fresh, time-limited, just-in-time elevation flow gated by Windows Hello plus a hidden, system-generated, profile-separated user account that issues an isolated admin token [@ms-learn-administrator-protection, @techcommunity-admin-protection]. The forthcoming Adminless article in this series will cover the architecture in detail.

Limit 3: SeImpersonatePrivilege on every service account. IIS, SQL Server, the Print Spooler, scheduled tasks, Docker, Citrix, almost every managed-service account by default. Consequence: every Potato, by construction. Partial successor today: per-service SIDs and Group Managed Service Accounts let administrators constrain the blast radius of a compromised service. Structural successor: Adminless, which removes the privilege from the daily authentication path and demands a fresh elevation per privileged action [@ms-learn-administrator-protection, @techcommunity-admin-protection].

Limit 4: NTLM relay surface. As long as Windows services accept NTLM and the operating system signs NTLM challenges with the local-machine credential, the local-NTLM-to-self attack is structurally available. Consequence: PetitPotam, RemotePotato0, every cross-protocol relay. Successor: NTLMless, which formally retires NTLM as a default Windows authentication protocol [@techcommunity-windows-auth-evolution]. The on-ramp is the NTLM auditing channel introduced in Windows 11 24H2 and Windows Server 2025 (KB5064479, original publish date July 11, 2025), which records NTLMv1 usage in Microsoft\Windows\NTLM\Operational and gives administrators a per-workload deprecation telemetry [@ms-support-ntlm-auditing]. The forthcoming NTLMless article in this series will cover the architecture in detail.

Limit 5: The DACL is local. Conditional ACEs and Dynamic Access Control claims need a working AD-and-AD-FS plane to evaluate; airgapped or heterogeneous environments fall back to user / group SIDs as the only available subject. Consequence: the access-matrix subject is, in practice, still "user and group" for most non-file-server workloads. The 2012 extension to claims and code identity is real but operationally bounded.

The deepest of the five limits is the one Norm Hardy named in 1988. Hardy's framing returned in Section 2 [@en-wiki-confused-deputy] holds: capability systems close the gap structurally; ACL engineering does not.

seL4 closes it with machine-checked correctness proofs and a capability-based design that makes ambient authority a category error [@en-wiki-capability-based-security]. Windows closes it, when it closes it at all, with VBS Trustlets that move the right to perform the operation into a separate execution domain. The Potato lineage is the textbook confused-deputy instance: a service running with SeImpersonatePrivilege is the privileged compiler; the attacker is the user holding a billing-records-shaped pointer; the service uses its own authority on every authentication it accepts.

Note: Hardy's 1988 paper [@wayback-cap-lore-hardy] and the Wikipedia summary [@en-wiki-confused-deputy] both say the same thing: ACL systems are structurally vulnerable to confused-deputy attacks; capability systems are not. The gap is not asymptotic. ACL engineering does not close it. The Potato lineage is what the gap looks like in the field, repeated against eight different coercion primitives over six years.

Key idea: The next generation of Windows defences cannot live inside the kernel, because the kernel is on the wrong side of the boundary the model draws. Microsoft's own servicing criteria admit it. Adminless, NTLMless, VBS Trustlets, and Credential Guard are the four non-overlapping ways to fix it. Each successor was scoped to close a specific gap the access-control model could not.

The five limits are named. The successors are shipping. What replaces what?

14. The Successors: Adminless, NTLMless, VBS Trustlets, Credential Guard

One paragraph each. This section is a forward-reference index, not a detailed walk-through.

Adminless. Removes the local Administrators group from the daily authentication path. The long-lived filtered / full token pair the UAC model produces at logon is replaced with a fresh, time-limited, just-in-time elevation flow: when a user wants to perform a privileged action, the system gates the action behind Windows Hello plus a hidden, system-generated, profile-separated user account that issues an isolated admin token, and the resulting token is bounded in time and scope [@ms-learn-administrator-protection].

The Microsoft Tech Community announcement (modified November 19, 2024) summarises the security argument: "By requiring explicit authorization for every administrative task, Administrator protection protects Windows from accidental changes by users and changes by malware... Malicious software often relies on admin privileges to change device settings and execute harmful actions. Administrator protection breaks the attack kill chain" [@techcommunity-admin-protection]. Closes: limits #2 and #3 -- there is no long-lived bearer credential to steal, and SeImpersonatePrivilege does not need to live on every service account because services run as bounded principals issued capabilities at the moment of need. Forthcoming article in this series.

NTLMless. Formally retires NTLM as a default Windows authentication protocol [@techcommunity-windows-auth-evolution]. The Tech Community announcement is unambiguous about direction: "Reducing the use of NTLM will ultimately culminate in it being disabled in Windows 11. We are taking a data-driven approach and monitoring reductions in NTLM usage to determine when it will be safe to disable" [@techcommunity-windows-auth-evolution].

The transition rests on a local KDC (IAKerb) that lets Kerberos service both local and domain accounts, plus an audit channel introduced in Windows 11 24H2 and Windows Server 2025 (KB5064479, original publish date July 11, 2025) that records NTLMv1 usage in Microsoft\Windows\NTLM\Operational and gives administrators per-service telemetry on which workloads still require the protocol [@ms-support-ntlm-auditing]. The local-NTLM-to-self attack class -- coerce a SYSTEM service to authenticate with the local-machine credential, accept the challenge, relay it back to a local service that trusts the credential -- ends when the local-machine NTLM credential ends. Closes: limit #4. Forthcoming article in this series.

VBS Trustlets and Isolated User Mode. Shipped in Windows 10 1507 in 2015. Virtualization-Based Security (VBS) uses the Hyper-V hypervisor to host a second user-mode environment, Virtual Trust Level 1 (VTL1), whose memory the NT kernel running in VTL0 cannot read or write. A Trustlet is a process that runs in VTL1. Closes: limit #1, for selected secrets. The ordinary NT kernel still runs the show for ordinary processes; VTL1 is a side-channel for secrets and policy decisions that the model wants to protect even from a kernel-level attacker. Detailed coverage in the Secure Kernel sibling article [@secure-kernel-sibling].

Credential Guard. The canonical first Trustlet. lsass.exe continues to run in VTL0 and answer authentication requests; the credential blobs lsass.exe historically held are moved to a Trustlet called LsaIso in VTL1. The VTL0 lsass.exe retains handles to the blobs but cannot read their contents; authentication happens by calling into the Trustlet. Mimikatz sekurlsa::logonpasswords returns no plaintext credentials against a Credential-Guard-on system, because the plaintext does not live in VTL0 memory at all. The default-enablement timeline and the SKU-specific configuration matrix are covered in the Secure Kernel sibling article [@secure-kernel-sibling].

Pluton-rooted attestation and the hardware foundation. The successor architectures rest on a hardware identity chain that begins below the firmware, in Microsoft's Pluton in-die security processor. Pluton holds the keys that vouch for the boot measurements that the OS in turn uses to attest its own integrity to a remote relying party. The Pluton article in this series covers the architecture and the Caliptra root-of-trust direction it foreshadows [@pluton-sibling]. The TPM 2.0 architecture that the same chain extends and the Secure Boot chain that runs before the access-control model boots are covered in their own sibling articles in this series.

The five limits enumerated in Section 13 and the four successor articles in this section are in one-to-one correspondence: Adminless closes #2 and #3, NTLMless closes #4, VBS Trustlets close #1, and Credential Guard is the canonical first Trustlet that demonstrates #1 closing for a specific high-value secret. Limit #5 -- the DACL is local -- is operational rather than architectural and is closed by deployment investment in AD plus AD FS rather than by a new mechanism. The correspondence is not a coincidence. Each successor was scoped to close a specific gap the access-control model could not close from inside.

With the gaps named and the successors mapped, what does an administrator actually do today?

15. Practical Guide

Six concrete recommendations for 2026, each tied to a primary Microsoft Learn or named-expert source.

Note: whoami /all prints the SIDs in the calling thread's token, the integrity level, every privilege with its Enabled / Disabled / Default Enabled state, and -- on AD-joined machines with claims -- the user and device claim set. It is the single most useful diagnostic command for understanding what a session can do. Read the Enabled column carefully: an available-but-disabled privilege does not affect any access check until the process explicitly enables it [@ms-learn-access-tokens].

Note: icacls <path> prints the DACL on a file or directory; the mass-rights letters are (F) full, (M) modify, (RX) read and execute, (R) read, (W) write, (D) delete, (GA) generic all, (GR) generic read, (GW) generic write [@ms-learn-how-dacls-control-access]. PowerShell's Get-Acl returns the same descriptor as a structured object that can be filtered and audited at scale. Sysinternals accesschk.exe answers the inverted query (which paths grant a given SID a given right) and is the right tool for catching descriptor misconfigurations across a large file system. Treat NULL DACL and empty DACL surfaces as the most-likely misconfiguration vectors.

Note: On every Windows server, enumerate the principals whose tokens hold SeImpersonatePrivilege or SeAssignPrimaryTokenPrivilege in their Default or Available lists. Treat any non-LocalSystem-or-equivalent holder as a Potato target until proven otherwise. Where a service must hold the privilege (most managed-service workloads do), constrain the blast radius with per-service SIDs and Group Managed Service Accounts so that a compromise of one service does not extend to a compromise of every service that shares the host's identity [@github-itm4n-printspoofer].

Note: The UACMe README is the institutional memory for the seventy-method bypass canon. Every method's Fixed in: field cites a specific Windows version or unfixed. Before declaring a binary "patched," consult the README; a method with a Fixed in: unfixed annotation is structurally available on every supported Windows version. The institutional position is that UAC bypasses do not, by Microsoft's own servicing-criteria policy, earn CVEs of their own, so the mitigations are issued per-redirect rather than per-feature [@github-hfiref0x-uacme, @msrc-servicing-criteria].

Note: Windows Event ID 4688 ("A new process has been created") is the most-cited detection signal for the Potato lineage and the UAC bypass tradition, because almost every member of both families ends in a CreateProcessAsUser or a redirected AutoElevate launch with a command-line argument that does not match the legitimate use of the parent binary. Enable command-line auditing under Audit Process Creation and forward the log; Sysmon Event ID 1 is the equivalent and richer signal in environments that deploy Sysinternals' Sysmon.

Note: The access matrix is the part of the model with deliberately extensible subjects. New code that lives behind an AppContainer SID gets a Low-IL token, a Package SID, and a capability list that constrain what it can touch even when the user running it is an administrator. New file shares that need attribute-based authorization should use conditional ACEs and Dynamic Access Control rather than ad-hoc group membership. Cross-link to the App Identity sibling article for Package SID derivation [@app-identity-sibling] and to the Dynamic Access Control overview [@ms-learn-dac].

{` // Inputs: // token -- {sids:[...], integrity:'Low'|'Medium'|'High'|'System', // appContainer:bool, capabilities:[...], claims:{...}, // privileges:{enabled:[...]}} // descriptor -- {dacl:[...], integrityLabel:'Low'|...|'System', // policyNoWriteUp:bool} // desired -- access mask (number) // Output: {granted, status, fired:[...]}

function fullAccessCheck(token, descriptor, desired) { const fired = []; const ilOrder = {Low:1, Medium:2, High:3, System:4};

// 1. MIC check fires before DACL walk. if (descriptor.policyNoWriteUp) { const writeBits = 0x00040000 | 0x00000002 | 0x00000004; // WRITE_DAC|WRITE|APPEND if ((desired & writeBits) && ilOrder[token.integrity] < ilOrder[descriptor.integrityLabel]) { fired.push('MIC no-write-up: token IL ' + token.integrity + ' < object IL ' + descriptor.integrityLabel); return {granted:0, status:'DENIED at integrity check', fired}; } }

// 2. Privilege bypass short-circuit. if (token.privileges.enabled.includes('SeBackupPrivilege') && (desired & 0x80000000)) { fired.push('SeBackupPrivilege bypass: GENERIC_READ granted'); return {granted: desired, status:'GRANTED via SeBackupPrivilege', fired}; }

// 3. AppContainer capability check (simplified). if (token.appContainer && descriptor.requiresCapability) { if (!token.capabilities.includes(descriptor.requiresCapability)) { fired.push('AppContainer capability check: missing ' + descriptor.requiresCapability); return {granted:0, status:'DENIED at AppContainer check', fired}; } }

// 4. DACL walk, deny-first, in canonical order. let remaining = desired; let granted = 0; for (const ace of (descriptor.dacl || [])) { if (!token.sids.includes(ace.sid)) continue; if (ace.condition && !evalCondition(ace.condition, token.claims)) continue; if (ace.type === 'DENY' && (ace.mask & remaining) !== 0) { fired.push('Conditional/plain DENY: ' + ace.sid); return {granted:0, status:'DENIED at DACL', fired}; } if (ace.type === 'ALLOW') { const newBits = ace.mask & remaining; granted |= newBits; remaining &= ~newBits; fired.push('ALLOW ' + ace.sid + ': granted 0x' + newBits.toString(16)); } if (remaining === 0) { return {granted, status:'GRANTED', fired}; } } return {granted, status: remaining === 0 ? 'GRANTED' : 'DENIED end of DACL', fired}; }

function evalCondition(expr, claims) { // Toy evaluator for "(@User.Department == \"Finance\")"-style expressions. const m = expr.match(/@User\.(\w+)\s*==\s*"([^"]+)"/); if (!m) return true; return claims[m[1]] === m[2]; }

// Demo: a Medium-IL user trying to write to a System-IL object via an allow ACE. console.log(fullAccessCheck( {sids:['S-1-5-21-X-Y-Z-1001'], integrity:'Medium', appContainer:false, capabilities:[], claims:{Department:'Finance'}, privileges:{enabled:[]}}, {dacl:[{type:'ALLOW', sid:'S-1-5-21-X-Y-Z-1001', mask:0xFFFFFFFF}], integrityLabel:'System', policyNoWriteUp:true}, 0x00040000)); // WRITE_DAC `}

The simulator runs the full plane in order: MIC integrity check, privilege bypass short-circuit, AppContainer capability check, DACL walk with conditional-ACE evaluation. Reading the fired log in the output tells you which primitive made the decision and why. It is the mental model the rest of the article has been building toward.

The six tips and the simulator together close the practical loop. With them, the practitioner can reason about any specific access decision the way the kernel does -- not by remembering features, but by walking the same plane.

The Sysinternals accesschk and psgetsid utilities have long been first-line investigative tools for ACL audits. Both ship in the Sysinternals Suite today and continue to surface the same descriptors Get-Acl and icacls print, in the form most useful to an administrator working at scale.

16. Frequently Asked Questions

No. By Microsoft's own *Security Servicing Criteria for Windows*, UAC and admin-to-kernel are not on the enumerated security-boundary list [@msrc-servicing-criteria]; bypasses are not, by policy, eligible for security servicing as boundary violations. The seventy-plus methods catalogued in UACMe are the empirical consequence of the classification, not a long string of bugs in a feature that was meant to defend against the techniques [@github-hfiref0x-uacme]. No. `Everyone` (the well-known SID `S-1-1-0`) is just a SID. ACEs that reference it are subject to the same DACL walk as any other SID; if a deny ACE for `Everyone` precedes an allow ACE for `Authenticated Users`, access is denied. The DACL evaluation algorithm does not know `Everyone` is special. Forshaw made the point with a meme-able rant in 2020: "S-1-1-0 is NOT A SECURITY BOUNDARY" [@tiraniddo-sharing-logon-session]. No. *Empty* DACL denies all access. *No* DACL (a NULL DACL) grants full access. Newly-written code that "creates a file with no protection" almost always gets this distinction wrong [@ms-learn-how-dacls-control-access]. Verify with `Get-Acl` or `icacls` after creation; an `icacls` output of `Everyone:(F)` on an object you intended to lock down is almost always a NULL DACL, not the policy you meant to write. For DACL alone, yes. For MIC, no -- a System-IL administrator still cannot write to a process at higher integrity if MIC denies the request, because the integrity check fires before the DACL walk [@ms-learn-mic]. For AppContainer, no -- AppContainer-bound objects require the capability SID, not just an administrator SID. For VBS Trustlets, no -- secrets in VTL1 are unreachable from VTL0 even with administrator rights, which is the whole point of the architecture [@secure-kernel-sibling]. No. The list shows *available* privileges. The `Enabled` column is the one that matters for runtime decisions; available-but-disabled privileges must be enabled via `AdjustTokenPrivileges` before any privileged operation can use them. Most privileges are disabled by default precisely so that a process must explicitly opt in to using one, which lets a security-conscious application minimise the window in which a bug can abuse the privilege [@ms-learn-privileges]. No. The underlying NTLM-to-self surface is still open. SharpEfsPotato (2021) [@github-bugch3ck-sharpefspotato] is the most recent member of the lineage; new tools using fresh coercion primitives (EFSRPC, the spooler, the schedule-task COM interface, cross-session DCOM) appear every twelve to eighteen months. Microsoft's own Hot Potato post called the underlying issue "hard to fix without breaking backward compatibility" [@foxglove-hot-potato-blog]; the structural fix is the Adminless and NTLMless successor articles, not a point patch on any one primitive. Partially. AppContainer is a process-level isolation mechanism with a Low-IL token plus a capability-SID list. It is also a *named principal* in the Windows access-control model -- something Chrome's sandbox is not -- which means AppContainer-bound code can be referenced by SID in a DACL or conditional ACE, and Windows can refuse access to it as a principal in its own right. The sibling App Identity article in this series covers the Package SID derivation and the relationship to Authenticode and App Control for Business [@app-identity-sibling].

17. Closing: Return to the Hook

Open a Windows PowerShell window again. Run whoami /priv. Read the column on the right, this time with the article's vocabulary annotated above each line.

SeShutdownPrivilege -- a privilege, in the kernel sense of a pre-checked superpower; bookkeeping rather than power.

SeIncreaseWorkingSetPrivilege -- the same. Most of the twenty rows are housekeeping that the kernel checks at specific call sites to gate non-security-critical operations.

The five rows that matter are easy to spot once you know what to look for. SeDebugPrivilege -- Mimikatz starts here. SeImpersonatePrivilege -- the entire Potato lineage starts here. SeAssignPrimaryTokenPrivilege -- the second half of every token-replay attack. SeBackupPrivilege -- HiveNightmare's privilege class. SeRestorePrivilege -- service-binary replacement. The kernel reads the same column on every securable operation, billions of times a second, and the answer to "can this code do this?" is built out of this list every time.

Now run icacls C:\Windows\System32\drivers\etc\hosts again. BUILTIN\Administrators:(F) is an allow ACE granting full control to the well-known SID S-1-5-32-544. NT AUTHORITY\SYSTEM:(F) is an allow ACE granting full control to S-1-5-18. BUILTIN\Users:(R) is an allow ACE granting FILE_GENERIC_READ to S-1-5-32-545. The DACL is in canonical order: explicit entries before inherited entries, deny entries (none here) before allow entries within each group. SeAccessCheck will walk this DACL on every read of hosts from any process on the machine, and the output will be deterministic -- the same answer every time, for the same caller -- because the model that produces it is closed and finite.

The article's payoff. Every later post in this series starts where this one ends. The Adminless article retires the bearer-credential property of long-lived tokens. The NTLMless article retires the local-NTLM-to-self relay surface. The Secure Kernel article hosts secrets in VTL1 outside the NT kernel's address space and tells the Credential Guard story in detail [@secure-kernel-sibling]. The Pluton article roots the hardware identity chain that the successor architectures all eventually verify against [@pluton-sibling]. The TPM article and the Secure Boot article cover the static-time and boot-time chains that run before the access-control model even loads. Each successor was scoped to close a specific gap the access-control model could not close from inside.

NT 3.1 froze a model in July 1993 because federal procurement demanded it. That model has not structurally changed in thirty-three years. The accumulated attack surface against it -- twenty-five years, eight Potatoes, seventy UAC bypasses, one Mimikatz -- is the empirical proof that "frozen" was always going to mean "attackable from below." The next generation of defences takes that lesson and stops trying to fix the model from inside. The model is not a feature catalogue. It is a decision plane with five inputs, ten primitives, and five publicly conceded structural limits, and the four successor architectures of the next decade are the four non-overlapping ways to close those limits without re-evaluating against TCSEC C2 again.

SeAccessCheck decides every time. The next decade decides what it decides about.

Parag Mali - tag: mimikatz

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

1. Two Continents, Eleven Months Apart

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

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

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

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

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

3.1 Discovery timeline

3.2 The four zero-days

3.3 The stolen Authenticode certificates

3.4 Architectural lessons

3.5 Did Stuxnet defeat any defender primitive Windows 7 shipped?

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

4. Mimikatz: The Credential Layer Demolition

4.1 Delpy, LSASS, and the May 2011 release

4.2 Four primitives that broke the credential layer

4.3 The 2013 inflection: graph-walking offensive Active Directory

4.4 The 2014 inflection: the Golden Ticket

4.5 What this proved

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

5.1 The pivot up the trust stack

5.2 The Mimikatz codebase as a single causal node

5.3 The economic argument

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

6.1 Restricted Admin RDP

6.2 LSA Protected Process (RunAsPPL)

6.3 The Mitigating Pass-the-Hash whitepaper series

6.4 KB2871997 and the WDigest opt-out

6.5 The seeds of Credential Guard

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

7.1 The mechanism

7.2 The bundled extras

7.3 Strategic significance

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

8.1 The trusted-computing-base argument

8.2 The asymmetry

8.3 The VTL0-symmetry argument

8.4 The way out, foreshadowed

9. Open Problems at the End of 2014

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

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

10.2 Mimikatz tradecraft as the floor of red-team capability

10.3 Detection

11. Frequently asked questions

Protected Process Light: When the Administrator Isn't Enough

1. Mimikatz on a Protected Box

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

3. _PS_PROTECTION -- The Single-Byte Encoding

4. The Signer Lattice -- Who Can Open Whom

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

6. RunAsPPL -- Hardening LSASS

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

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

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

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

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

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

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

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

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

Deploy

Verify

Monitor

12. FAQ -- Common Misconceptions

DPAPI and DPAPI-NG: The Credential Vault Under Everything

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

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

Generation 1: Protected Storage

What survived into DPAPI

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

Stage 1: Pre-key derivation

Stage 2: The master key

Stage 3: The per-call session key

Stage 4: The BLOB wrap

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

Provisioning the root key

The L0 / L1 / L2 derivation chain

The GetKey round trip

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

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

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

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

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

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

The `GetKey` round trip

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

5. What `LsaIso.exe` actually is

5.4 The `LSA_ISO_RPC_SERVER` ALPC port

5.5 The `MSV1_0\IsolatedCredentialsRootSecret` registry sentinel

3. The Kernel Oracle: `SeAccessCheck` and Its Inputs