Parag Mali - tag: kerberos

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

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

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

1. Two Afternoons, Twenty-Nine Years Apart

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

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

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

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

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

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

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

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

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

2. The Architectural Property the Family Shares

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

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

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

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

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

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

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

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

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

And then nothing happened for eleven years.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4. Mimikatz and the Kerberos Turn

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5. Documentation Is Not Defense

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

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

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

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

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

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

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

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

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

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

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

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

6. Credential Guard and the Architectural Pivot

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7. Pass-the-Certificate: The Predictable Response

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

8. Pass-the-PRT: The CloudAP Frontier

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

9. The 5x5 Matrix and the Irregular Cadence

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

10. Open Problems and the 2026-2030 Forecast

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

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

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

The five concrete open problems flow from the lower bound.

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

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

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

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

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

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

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

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

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

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

11. The 2026 Defender Playbook

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

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

Open PowerShell as administrator and run:

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

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

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

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

12. Frequently Asked Questions

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

13. The Pattern That Outlived Six Defenses

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

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

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

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

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

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

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

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

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

Microsoft Defender for Identity: The Defensive AD Stack That Sees What BloodHound Maps

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

**Microsoft Defender for Identity (MDI) is the cloud-backed, on-DC defensive sensor that watches for almost every offensive Active Directory primitive in the SpecterOps / Mimikatz / Certipy corpus** -- DCSync, DCShadow, Golden / Silver / Diamond ticket forgery, Kerberoasting, AS-REP roasting, NTLM relay, and AD CS abuse -- by parsing Kerberos, NTLM, LDAP, and DRSUAPI on the wire and running per-principal behavioural baselines in a multi-tenant cloud backend. The product began as the Israeli startup Aorato (acquired by Microsoft in November 2014), shipped on-prem as Microsoft ATA in 2015, moved to the cloud as Azure ATP in 2018, was renamed to MDI in 2020, folded into Microsoft Defender XDR at Ignite 2023, and reached its current MDE-integrated v3.x sensor in October 2025. The alert catalogue maps cleanly onto MITRE ATT&CK, and the residual blind spots are knowable: the Credential Guard wall, the Sapphire Ticket's cryptographic indistinguishability, the encrypted-channel DCSync class, the cross-forest under-instrumentation tail, and legitimate-principal compromise. The operator question in 2026 is not whether MDI detects the attack, but whether the sensor is deployed, the alert was triaged inside the batched-emission window, and the residuals are covered by KQL, Sigma rules, or out-of-band controls.

1. A Friday Afternoon at the Domain Controller

Friday, 14:33. A red-team contractor in conference room C runs Rubeus.exe asreproast on a corporate laptop she was issued an hour ago. A junior auditor on the fourth floor, working from a desk with read-only Active Directory access, runs bloodhound-python -c All for a routine quarterly review. A quiet service account on the SQL host in rack 14 runs mimikatz "lsadump::dcsync /domain:contoso.com /user:Administrator". The operator at the other end of that session is not on the payroll. Three different workstations. Three different intents. One domain controller on the receiving end of all three.

The Security Operations Center has not noticed any of them yet. The watcher on the domain controller, however, has. By 14:35 three named alerts are sitting in the Defender XDR queue, each tagged with a MITRE ATT&CK technique ID, each waiting for someone to triage. Suspected AS-REP Roasting attack (T1558.004) for the Rubeus invocation [@mslearn-mdi-alerts-xdr]. Security principal reconnaissance (LDAP) for the BloodHound enumeration [@mslearn-mdi-alerts-mdi-classic]. Suspected DCSync attack -- replication of directory services, External ID 2006, T1003.006, for the Mimikatz call [@mslearn-mdi-alerts-mdi-classic][@mitre-t1003-006]. The watcher is Microsoft Defender for Identity.SOC operators inside Microsoft customers describe this with a stock phrase: "the watcher was already on the DC." The phrase shows up in incident-response runbooks, vendor training decks, and the Microsoft Defender for Identity Tech Community archive. It captures what is, architecturally, a strange thing -- the defender's sensor is co-located with the attacker's target, not perched outside it.

A Windows Server hosting the Active Directory Domain Services role, responsible for processing Kerberos authentication, NTLM challenges, LDAP queries, and inter-DC directory replication (DRSUAPI) for a domain. Every named MDI runtime alert in this article fires on signal that originates on or transits a domain controller; the deployment model assumes one MDI sensor per DC, plus optional sensors on AD FS, AD CS, and Microsoft Entra Connect servers when those identity roles run on dedicated hosts.

Almost every offensive AD primitive a reader of the SpecterOps, Mimikatz, and Certipy corpus already knows has a runtime alert or a posture assessment shipped by Microsoft on that same DC. Almost is the load-bearing word. The alert fires only if three things are true: the sensor is deployed on the surface the attack touches, the audit subcategory the alert depends on is enabled, and the SOC opens the Defender XDR incident inside the batched-emission window the cloud backend uses to aggregate signal. This article is about all three conditions, the twelve-year arc that built the watcher, and the structural blind spots no future MDI release will close.

The watcher was not always on the domain controller. For the first decade of Active Directory, nothing on the DC saw what BloodHound today maps. To understand where the watcher came from -- and why its blind spots look the way they do -- we have to start with three founders in Herzliya and a Kerberos forgery presentation in Las Vegas.

2. Origins -- Aorato, the Israeli Startup That Became the Watcher

August 2014, Black Hat USA. Tal Be'ery and Michael Cherny take the stage with Alva Duckwall and Benjamin Delpy to present "Abusing Microsoft Kerberos: Sorry You Guys Don't Get It," a demonstration that a stolen krbtgt key lets an attacker mint Kerberos ticket-granting tickets that survive every password rotation in the standard remediation playbook [@blackhat-us14-briefings]. The audience is Active Directory operators who thought their password-reset runbook covered them. By the end of the talk it does not. The startup behind the research is Aorato, three years old, headquartered in Herzliya, Israel. Three months later, Microsoft buys it.

The credential a Kerberos client receives from the Key Distribution Center (the KDC, which on a Windows network runs on every DC) after successful pre-authentication. The TGT is encrypted with the KDC's own long-term key -- on Active Directory, the password hash of the `krbtgt` account. Possession of the `krbtgt` hash therefore lets an attacker forge a valid TGT for any principal in the domain, since the KDC has no other way to distinguish a forged ticket from a real one. This forged-ticket class is what MITRE catalogues as T1558.001 Golden Ticket [@mitre-t1558-001].

The Aorato deal closed on November 13, 2014, announced on the Microsoft Official Blog by Takeshi Numoto, then Corporate Vice President of Cloud and Enterprise Marketing [@msblog-aorato]. The post named the central technology Microsoft was acquiring: Aorato's Organizational Security Graph, described as "a living, continuously-updated view of all of the people and machines accessing an organization's Windows Server Active Directory." Pre-acquisition Microsoft had Azure AD on the cloud side and per-DC event log auditing on the on-prem side, but no first-party behavioural-analytics product over Active Directory. Aorato's pre-acquisition product, the Directory Services Application Firewall, did exactly that -- it parsed Kerberos, NTLM, LDAP, and DRSUAPI on the wire and ran per-principal behavioural baselines against the parsed protocol stream. Microsoft wanted that capability inside Windows Server, and inside Office 365.Aorato's three founders, per the Globes coverage of the acquisition in November 2014, were Idan Plotnik (CEO), Michael Dolinsky (VP R&D), and Ohad Plotnik (VP professional services). Tal Be'ery was VP of Research. A popular reading of the deal names "the Plotnik brothers and Tal Be'ery" as the co-founder trio, which compresses out Dolinsky's role -- the contemporaneous record names four people, not three [@globes-aorato-2014].

The product lineage that follows is twelve years long and runs through five names. Microsoft Advanced Threat Analytics (ATA) was announced as generally available on August 27, 2015 (build 1.4.2457, dated August 31, 2015) -- the on-prem productisation of Aorato's wire-side parser, packaged as a SPAN-mirror appliance ("ATA Gateway") plus an on-prem analytics server ("ATA Center") with its own MongoDB-style document store [@mstc-ata-ga][@atadocs-versions]. Azure ATP went GA on March 1, 2018 -- the cloud-side rewrite that kept the on-DC sensor but moved the analytics engine to a multi-tenant cloud backend [@mstc-azureatp-ga][@mstc-azureatp-intro]. Microsoft Defender for Identity was the September 22, 2020 rename announced at Ignite 2020, part of Microsoft's broader brand consolidation that also rebranded Office 365 ATP to Microsoft Defender for Office 365 and Microsoft Defender ATP to Microsoft Defender for Endpoint [@mssecblog-unified-xdr][@itpro-defender-rebrand][@infusedinnov-names]. The November 2023 Ignite keynote consolidated Microsoft 365 Defender into Microsoft Defender XDR [@virtreview-ignite2023][@handsontek-defender-rebrand]. In October 2025 the v3.x sensor GA folded MDI's on-DC sensor into the Microsoft Defender for Endpoint agent that organisations were already running on every server [@mslearn-mdi-whats-new][@modernsec-v3x][@jeffreyappel-v2v3]. The May 2026 release notes extended the v3.x sensor to cover AD FS, AD CS, and Microsoft Entra Connect identity roles directly when those roles run on a domain controller, and raised the per-workspace sensor cap from 350 to 1,000 [@mslearn-mdi-whats-new].

gantt title Microsoft Defender for Identity lineage, 2012-2026 dateFormat YYYY-MM-DD axisFormat %Y section Aorato Aorato startup (DSAF product) :a1, 2012-01-01, 2014-11-13 section Microsoft ATA ATA initial release SPAN-mirror Gateway :a2, 2015-08-27, 2016-05-01 ATA 1.6-1.9 Lightweight Gateway :a3, 2016-05-01, 2018-03-01 ATA Extended Support window :a4, 2018-03-01, 2026-01-31 section Cloud rewrite Azure ATP GA :a5, 2018-03-01, 2020-09-22 Microsoft Defender for Identity name :a6, 2020-09-22, 2023-11-15 section Defender XDR era MDI inside Defender XDR (v2.x) :a7, 2023-11-15, 2025-10-01 MDI v3.x MDE-integrated sensor :a8, 2025-10-01, 2026-05-27

Aorato's pitch in 2014 was that the Windows Security event log -- the thing every SIEM in the world was ingesting -- could not see the attacks an Active Directory operator most needed to catch. To believe that pitch you have to know exactly what the event log misses.

3. Why the Event Log Could Not See Golden Tickets

Present a Golden Ticket to a domain controller, and the LSA writes a successful event 4769 -- a Kerberos service ticket request. Present a legitimate ticket from the same principal, and the LSA writes a successful event 4769. Nothing in the event log's schema, anywhere in any field, distinguishes the two. The ticket is forged with the real krbtgt key, so the KDC's signature checks pass. The event log records that an authentication happened, not whether the ticket presented was genuine. This is the structural ceiling the SIEM industry could not work around for the first decade of its existence, and it is the gap Aorato was built to close [@mitre-t1558-001][@semperis-golden-ticket].

The bare-event-log model has three structural failure modes, each of which drove a generation of detection engineering. Forged-ticket invisibility is the first: the LSA logs that an auth happened, but every byte in the 4769 event matches the legitimate case. Per-DC silo is the second: a Kerberos auth against one DC and a follow-up auth against another DC five seconds later sit in two different Security.evtx files, on two different machines, with no aggregation layer to ask "did the same principal hit ten DCs in five minutes?" Manual-review throughput collapse is the third: a medium-sized forest emits thousands of 4624, 4768, 4769 events per minute per DC, and the human analyst hand-walking them never catches up.

DCSync makes the first two failure modes vivid. Sean Metcalf's September 2015 ADSecurity writeup walks through running lsadump::dcsync /domain:contoso.com /user:Administrator from a workstation: the DC handles the DRSUAPI replication request, the LSA emits a 4662 event for the directory-service-object access, and the attacker walks away with the password hash [@adsec-dcsync].Metcalf's companion DerbyCon V talk, Red vs. Blue: Modern Active Directory Attacks & Defense (September 2015), is the canonical operator-grade introduction to the same material [@adsec-dump-ad]. The 4662 event is structurally indistinguishable from a legitimate replication request between two DCs. A SIEM rule that flagged 4662 events whose source IP was not a DC could catch it -- but only if the analyst maintained the IP allowlist (a single Microsoft Entra Connect server in the wrong subnet broke the rule), and only if 4662 was enabled at all (it was high-volume, and many SOCs disabled it to stay under the SIEM's GB/day licence).

Key idea: The SIEM was not failing at Active Directory detection because the rules were wrong. It was failing because the event log -- the data source every SIEM relied on -- could not see what the SIEM needed it to see. Better rules over the same event log would not have closed the gap. Aorato's contribution was to find a different data source: the wire itself.

Aorato's three primitives, none of which the SIEM-plus-event-log model had, were: per-principal behavioural baselines so that a long-tail anomaly stood out without anybody writing a rule for it; on-DC network capture so that the ticket structure, the DRSUAPI opnum, and the LDAP search filter were available to detection logic; and a graph over the directory so that the path from compromised workstation to crown-jewel asset could be computed rather than inferred. ATA shipped the first two in 2015. The graph took longer.

4. Early Approaches -- ATA 1.x and the Generations That Tried Before

By the time Aorato shipped its first product, four prior generations of Active Directory detection had already tried and stalled. Each one could see something the previous generation could not. Each one had a structural ceiling an attacker primitive eventually pushed through. The seven generations that follow are the real spine of the article.

flowchart LR G1["Gen 1: bare per-DC
event log audit"] --> G2["Gen 2: SIEM-centralised
events with static rules"] G2 --> G3["Gen 3: first-generation UEBA
over SIEM events"] G3 --> G4["Gen 4: Aorato DSAF and
ATA 1.4-1.5 (SPAN mirror)"] G4 --> G5["Gen 5: ATA 1.6-1.9
(Lightweight Gateway + LMP)"] G5 --> G6["Gen 6: Azure ATP, MDI v1.x-v2.x
(cloud analytics)"] G6 --> G7["Gen 7: MDI v3.x
(MDE-integrated + Identity Explorer)"]

Generation 1 -- bare per-DC event log auditing (1999-2008) was already covered above. It was the only model that existed for the first decade of Active Directory, and its structural ceilings became Aorato's pitch deck.

Generation 2 -- SIEM-centralised event log ingestion with static correlation rules (2005-2014) is the era of ArcSight, Splunk, QRadar, and LogRhythm. Windows Event Forwarder agents on every DC streamed Security event log entries into a central index, and SOC operators wrote rule-based correlation searches in the vendor's query language. The model gave the SOC cross-DC correlation, a query language, and an audit trail that satisfied PCI-DSS Requirement 10. It did not give the SOC anything new about the data the LSA emitted. Mimikatz's lsadump::dcsync was committed to the public Mimikatz repository in March 2015 [@mimikatz-github][@adsec-dcsync]. Sean Metcalf's longer ADSecurity writeup of the technique followed in September 2015. At commit time, every SIEM in production was correlating DC event logs and not one was emitting a DCSync alert, because the 4662 event was structurally identical to a legitimate DC-to-DC replication.

Generation 3 -- first-generation UEBA on SIEM event data (2013-2017) was Securonix, Exabeam, and Splunk UBA. Per-principal behavioural baselines layered on top of the SIEM event index could catch novel TTPs without prior signatures -- a Kerberoasting variant whose SPN list had never been seen before could still trip "this account is requesting an unusual number of service tickets compared to its baseline." UEBA also closed Generation 2's per-principal context gap. It did not, however, see ticket structure: a Golden Ticket replayed against ten DCs produces ten successful auths that are behaviourally indistinguishable from the legitimate Domain Admin's pattern unless the attacker's source IP or geographic distribution breaks the baseline. This is the legitimate-principal-compromise non-detection class that survives every defensive generation into 2026.

Generation 4 -- on-wire protocol analytics via off-DC SPAN-mirror Gateway is where Aorato's product, and then Microsoft ATA 1.4 and 1.5, lived. A switch SPAN port mirrored DC traffic to a dedicated ATA Gateway appliance, which ran libpcap-equivalent capture and parsed Kerberos AS-REQ / TGS-REQ / AP-REQ, NTLM challenges, LDAP searches, and DRSUAPI replication calls. Parsed events streamed to the on-prem ATA Center, which ran detection logic and surfaced alerts in a web console [@mstc-ata-ga]. The wire-side parse closed Generation 1-3's biggest blind spot: ticket structure was finally visible. The SPAN-port operational tax killed the architecture in nine months. Many enterprises could not provision a SPAN mirror. Virtualised DCs on shared hypervisors had no equivalent of a physical SPAN. And the security review of "all DC traffic now mirrors to this appliance" was non-trivial.

Generation 5 -- ATA 1.6 Lightweight Gateway through ATA 1.9 (May 2016 to March 2020) moved the Gateway in-process onto the DC itself. ATA 1.6 (May 2016) introduced the Lightweight Gateway with dynamic resource management that capped the sensor's CPU and memory footprint and let the sensor consume events locally rather than via mirrored network traffic [@mslearn-ata-1-6]. ATA 1.7 (August 31, 2016) added Role-Based Access Control for the ATA Console, Windows Server Core support, and detection of reconnaissance through directory-services enumeration [@mssupport-ata-1-7][@atadocs-versions]. ATA 1.8 (June 30, 2017; announced July 26, 2017) shipped behavioural-brute-force detection, a Golden Ticket lifetime detector, and the abnormal-modification-of-sensitive-groups alert [@mslearn-ata-1-8][@mstc-ata-1-8][@ataversions-1-8-availability]. ATA 1.9 (March 21, 2018) shipped both the entity-profile lateral-movement-aware view and the Lateral movement paths to sensitive accounts report [@mslearn-ata-1-9][@atadocs-versions][@atadocs-lmp-usecase].A widespread reading of the ATA timeline anchors LMP to ATA 1.7 in late 2017. The primary record contradicts this on both date and feature: ATA 1.7 shipped on August 31, 2016 per the Microsoft Support KB and the ATA-versions table, and the 1.7 release notes do not mention Lateral Movement Paths. Neither do the 1.8 release notes -- LMP first appears in ATA 1.9 (March 21, 2018), which introduced both the entity-profile lateral-movement view and the full Lateral movement paths to sensitive accounts report in the same release [@mssupport-ata-1-7][@atadocs-versions][@mslearn-ata-1-8][@mslearn-ata-1-9].

Note: A popular framing of the LMP timeline says "Microsoft adopted BloodHound-style graph attack paths in 2022." The primary sources contradict this. Graph-anchored attack-path evaluation in Microsoft's defensive stack originates in ATA 1.9 (March 2018), not in any 2022 adoption event. What did happen in 2022 was the start of the deprecation arc for the SAM-R-based discovery the LMP graph depended on, which culminated in Message Center notice MC1073068 in May 2025 when Microsoft disabled SAM-R-based local-administrators collection across MDI tenants [@handsontek-mc1073068]. The 2022 date that lingers in operator memory is the deprecation anchor, not the adoption anchor.

An attack chain through Active Directory in which a non-sensitive account whose credentials are exposed on one workstation can be used to authenticate to a second workstation where a sensitive account's credentials are cached, which in turn can be used to reach a third workstation, and so on until a Domain Admin or comparable target is reached. ATA 1.9's Lateral Movement Paths report was the first graph-anchored defensive surface that computed the chain in advance; the report was populated by SAM-R queries that enumerated each host's local-administrators group. Microsoft disabled the SAM-R-based collection in May 2025 (MC1073068), and the post-LMP graph layer migrated to the Defender XDR hunting graph plus the April 2026 Identity Explorer preview.

The limitation that drove Generation 5 into Generation 6 was the on-prem ATA Center's release cadence. Benjamin Delpy and Vincent Le Toux disclosed DCShadow at BlueHat IL 2018 in January 2018 -- the technique of registering a rogue domain controller via nTDSDSA object creation plus SPN registration, then pushing arbitrary updates into AD via legitimate DRSUAPI replication that the event log records as ordinary inter-DC traffic [@dcshadow-com][@mitre-t1207]. ATA 1.9 shipped two months later, in March 2018, with no DCShadow detection. Azure ATP -- the cloud-side rewrite, also GA in March 2018 -- shipped paired alerts External ID 2028 (Suspected DCShadow attack -- domain controller promotion) and External ID 2029 (Suspected DCShadow attack -- domain controller replication request) five months later, in July 2018 [@mslearn-mdi-alerts-mdi-classic][@mslearn-mdi-whats-new-archive]. The on-prem release cadence could not have closed that five-month gap. The cloud rewrite was the structural answer.

5. The Breakthrough -- Azure ATP and the Inverted Data Path

If the wire was the right data layer, the cloud was the right place to run the analytics. That is the architectural decision Azure ATP committed to in March 2018, and it is what distinguishes the Microsoft defensive product from every prior generation. The on-DC sensor stayed on the DC. The analytics engine moved.

Four architectural shifts followed. First, the on-DC sensor became a thin parser. Sensors no longer hosted detection logic; they captured the Kerberos / NTLM / LDAP / DRSUAPI traffic, parsed it into a stream of structured events, and shipped the stream upstream. Second, the data path inverted. Generation 4 sent unparsed packets from the wire to the off-DC Gateway, which parsed them and stored them on-prem; Azure ATP sent parsed events from the on-DC sensor upstream to a multi-tenant cloud backend that ran detection logic and wrote alerts back into a tenant-specific workspace. Third, per-principal behavioural baselines accumulated centrally rather than per-DC, so a baseline survived DC reboots, sensor restarts, and migrations across data centres. Fourth, identity signal joined endpoint and email signal in the same incident queue once Azure ATP folded into Microsoft 365 Defender -- the cross-product correlation that no on-prem product had ever offered [@mstc-azureatp-ga][@mstc-azureatp-intro][@mslearn-xdr-overview].

Then came the brand-and-architecture history every operator has to know to read a 2026 runbook. The September 22, 2020 rename from Azure Advanced Threat Protection to Microsoft Defender for Identity was a brand consolidation, not an architecture change -- the same sensor, the same alerts, the same workspace [@mssecblog-unified-xdr]. The legacy portal.atp.azure.com standalone portal was retired on June 30, 2023 via Message Center notice MC567494, with all requests automatically redirected to security.microsoft.com [@handsontek-mc567494][@mslearn-mdi-portal]. The November 15, 2023 Ignite keynote renamed Microsoft 365 Defender to Microsoft Defender XDR (Message Center MC696570) [@handsontek-defender-rebrand][@virtreview-ignite2023]. Again a brand change, again not an architecture change: the sensors stayed on the DC, the analytics stayed in the cloud, and the KQL schema -- IdentityLogonEvents, IdentityQueryEvents, IdentityDirectoryEvents -- stayed the same [@mslearn-xdr-identitylogon][@mslearn-xdr-identityquery][@mslearn-xdr-identitydirectory].The legacy portal.atp.azure.com URL is worth remembering because runbooks and SOAR rules from 2018 to 2023 frequently hard-coded it. Any rule that referenced the old portal needs an update; the redirect handles browser traffic but not API calls.

What the sensor actually feeds into the cloud backend, in 2026, is four data-input layers, ordered roughly by evidence strength. First, the Windows Security event log -- the audit subcategories that the MDI event-collection page lists as required, including Audit Credential Validation, Audit Kerberos Authentication Service, Audit Kerberos Service Ticket Operations, Audit Directory Service Access, and Audit Computer Account Management among others [@mslearn-mdi-event-collection]. These are public, documented, and easy to verify with auditpol /get /category:*. Second, on-DC network capture of Kerberos, NTLM, LDAP, and DRSUAPI -- well-documented because the sensor's network requirements are part of the public deployment guide. Third, Event Tracing for Windows providers that the sensor subscribes to in order to get signal the event log does not surface. Fourth, AD CS audit-log subscriptions added with the AD CS sensor release in August 2023 [@mstc-adcs-sensor][@dirteam-sander-aug2023].

Microsoft has never published the canonical list of Event Tracing for Windows providers that the MDI sensor subscribes to. Any specific list of providers a reader encounters traces back to community reverse-engineering: Synacktiv's *A primer on Microsoft Defender for Identity* by Guillaume Andre and Mickael Benassouli (November 2022) is the canonical operator-research primary [@synacktiv-primer-mdi][@synacktiv-primer-mdi-archive]. The methodological precedent is Olaf Hartong's *Microsoft Defender for Endpoint Internals* series, specifically the 0x02 entry on audit settings and telemetry, which documents the binary-side enumeration approach: run Matt Graeber's Get-TraceLoggingMetadata script against the sensor executable to enumerate the providers it registers, then use Sealighter to trace those providers to a file for further analysis [@falconforce-mde-0x02][@gist-tracelogging-metadata][@github-sealighter]. Hartong's 0x02 article reports "roughly 111 public and MDE-exclusive providers used" by MsSense.exe -- the MDI sensor binary is amenable to the same technique, and the provider mix differs (MDI subscribes heavily to LDAP, Kerberos, DRSUAPI, and SAM-R-class providers; MDE subscribes heavily to process, file, network, and image-load providers) but the methodology is shared [@falconforce-mde-0x03][@github-olafhartong]. Read any community-published MDI provider list as a snapshot of what the community has reverse-engineered, not as Microsoft-published ground truth. The breakthrough was not better detection algorithms. The breakthrough was moving the analytics off the DC entirely, so the per-principal baselines could accumulate centrally and the detection set could ship on a cloud cadence instead of an on-prem one. That decision is why MDI shipped DCShadow detection within five months of disclosure -- a cadence the on-prem product could not have matched.

That is the move that turned a wire-side parse into a sustained detection program. The proof is the DCShadow timeline: five months from disclosure to detection, on a cadence the on-prem product could not have matched. Now we can ask the question every reader of the offensive-AD corpus actually wants answered. What does the watcher catch in 2026?

6. MDI in 2026 -- Sensors, Alerts, KQL, and the Graph in Transition

This is the article's bookmarking section. Four parts: what is on the DC, what alerts fire, what KQL the operator writes when the alerts miss, and where the graph layer that began as ATA 1.9's Lateral Movement Paths report actually lives in 2026.

6.1 Sensor topology in 2026

What is on a Windows Server 2022 (or 2025) domain controller running MDI in May 2026? Two sensor families, two target-server matrices, and a workspace cap.

The v2.x sensor is the legacy standalone agent: supported on Windows Server 2016 and earlier domain controllers, and on AD FS, AD CS issuing certificate authorities, and Microsoft Entra Connect servers that are not themselves domain controllers, per the v2.x prerequisites page [@mslearn-mdi-prereq-sensor-v2]. v2.x carries its own installer, its own update cadence, and its own packet capture stack (NPCap). It also requires a Directory Service Account (DSA) -- a gMSA configured during install whose forest-wide read rights let the sensor enumerate AD objects.

A group Managed Service Account configured during MDI v2.x sensor installation, granted forest-wide read permissions on Active Directory objects so the sensor can resolve principal identities, enumerate group memberships, and read schema attributes that the wire-side parse refers to by SID. The v3.x sensor replaces the DSA pattern with LocalSystem impersonation -- the sensor impersonates the local-system account of the domain controller it runs on, which has equivalent on-DC read rights without needing a separate gMSA per tenant [@mslearn-mdi-deploy-sensor-v3][@mslearn-mdi-action-accounts].

The v3.x sensor is the current path. It requires Windows Server 2019 or later with the March 2026 (or later) cumulative update installed, the Defender for Endpoint agent already deployed and onboarded, and -- critically -- there is no separate MDI installer at all. The MDI sensor capability ships as an extension of the MDE SENSE service. Self-imposed resource caps: CPU at most 30% of the host DC's CPU, memory at most 1.5 GB, with explicit Hyper-V Dynamic Memory and VMware reservation guidance that ensures the cap is honoured under contention [@mslearn-mdi-deploy-sensor-v3]. v3.x uses LocalSystem impersonation for AD reads rather than a gMSA-based DSA. The May 2026 release notes added direct v3.x support for AD FS, AD CS, and Microsoft Entra Connect identity roles when those roles run on a domain controller (which is the recommended deployment pattern for most mid-sized tenants) [@mslearn-mdi-whats-new].The 30% CPU cap is honoured by the MDE SENSE service's scheduling, but Hyper-V Dynamic Memory and VMware ballooning can break the assumption -- if the hypervisor reclaims memory under contention the sensor cannot get its 1.5 GB and the local capture buffer drops events. Microsoft's deployment guide recommends a static memory reservation on virtualised DCs for that reason.

The four target server roles are domain controllers (every DC, including RODCs), AD FS federation servers (not Web Application Proxies), AD CS online issuing certificate authorities (not offline root CAs), and Microsoft Entra Connect servers (both active and staging). The May 2026 release notes also raised the per-workspace capacity ceiling from 350 sensors to 1,000 sensors per workspace [@mslearn-mdi-whats-new].

flowchart TD DC1["Domain Controller
(WS2019+, v3.x sensor
inside MDE SENSE)"] DC2["Domain Controller
(WS2016, v2.x sensor)"] ADFS["AD FS server
(v2.x sensor, non-DC)"] ADCS["AD CS issuing CA
(v2.x or v3.x sensor)"] EC["Entra Connect server
(v2.x sensor)"] CLOUD["MDI cloud backend
(multi-tenant analytics,
per-principal baselines)"] XDR["Microsoft Defender XDR
(security.microsoft.com)
Identity tables + alerts"] DC1 --> CLOUD DC2 --> CLOUD ADFS --> CLOUD ADCS --> CLOUD EC --> CLOUD CLOUD --> XDR

The deployment matrix below is the operator-grade reference -- which role gets which sensor, which audit subcategories the sensor depends on, and what posture data the role unlocks.

Server role	Sensor version	Required audit subcategories	Posture coverage unlocked
Domain controller (WS 2019+)	v3.x (preferred)	Credential Validation; Kerberos AS; Kerberos TGS; Logon; DS Access; Computer Account Mgmt	Full Identity Security Posture (entity hygiene, dormant accounts, weak crypto)
Domain controller (WS 2016)	v2.x	Same as above	Same as above, minus v3.x-only enhancements
AD FS federation server	v2.x (or v3.x if also a DC)	AD FS audit logs (Application + Security)	Hybrid auth signal (Entra ID + on-prem)
AD CS issuing CA	v2.x (or v3.x if also a DC)	AD CS audit logs (certificate request and template events)	Nine ESC posture assessments (ESC1-Preview, ESC2, ESC3, ESC4, ESC6-Preview, ESC7, ESC8, ESC11, ESC15) [@mslearn-mdi-certificates-posture]
Entra Connect server	v2.x (or v3.x if also a DC)	Sync engine event log	Sync-engine attribute-flow signal

Note: For new DC deployments on Windows Server 2019 or later, use v3.x: no separate installer, no gMSA, no NPCap, and the sensor ships its updates with the MDE agent. For AD FS, AD CS, or Entra Connect roles that run on dedicated Windows Server 2016 hosts, v2.x is the supported path until those hosts are upgraded. Mixed environments are normal during the migration window; the cloud backend handles both versions without operator intervention [@modernsec-v3x][@jeffreyappel-v2v3]. One known limitation as of May 2026: Windows Server 2025 domain controllers that currently run a v2.x sensor cannot be migrated to v3.x; Microsoft's What's New page is explicit that "migration of domain controllers with Windows Server 2025 from sensor v2.x to sensor v3.x is not supported" and the operator should continue on v2.x on those hosts until migration support ships [@mslearn-mdi-whats-new].

Sensor topology determines coverage. Coverage determines which alerts can fire.

6.2 The alert taxonomy mapped to MITRE ATT&CK

Every offensive Active Directory primitive a reader of the SpecterOps, Mimikatz, and Certipy corpus knows has a row in MDI's alert catalogue. The catalogue is the article's bookmarkable artifact, and the table below is the load-bearing data-density object. Four MITRE-aligned categories, the named alert for each primitive, and the ATT&CK technique ID the alert maps to.

Category	MDI alert (External ID / detector)	MITRE ATT&CK technique
Reconnaissance	Account enumeration reconnaissance (LDAP) -- External ID 2437	T1087 Account Discovery
Reconnaissance	Network-mapping reconnaissance (DNS)	T1018 Remote System Discovery
Reconnaissance	Security principal reconnaissance (LDAP)	T1069 Permission Groups Discovery
Reconnaissance	User and IP address reconnaissance (SMB)	T1018
Persistence and privilege escalation	Honeytoken activity (authentication / attribute / group)	T1098 Account Manipulation
Persistence and privilege escalation	Suspected Skeleton Key attack	T1556 (Modify Authentication Process)
Persistence and privilege escalation	Suspected Golden Ticket usage (encryption downgrade)	T1558.001 Golden Ticket [@mitre-t1558-001]
Persistence and privilege escalation	Suspected Golden Ticket usage (forged authorization data)	T1558.001
Persistence and privilege escalation	Suspected DCShadow attack (DC promotion) -- External ID 2028	T1207 Rogue Domain Controller [@mitre-t1207]
Persistence and privilege escalation	Suspected DCShadow attack (DC replication request) -- External ID 2029	T1207
Persistence and privilege escalation	Suspicious additions to sensitive groups	T1098 Account Manipulation
Credential access	Suspected DCSync attack (replication of directory services) -- External ID 2006	T1003.006 DCSync [@mitre-t1003-006]
Credential access	Suspected Brute Force attack (Kerberos, NTLM)	T1110 Brute Force
Credential access	Suspected AS-REP Roasting attack	T1558.004 AS-REP Roasting [@mitre-t1558-004]
Credential access	Suspected Kerberos SPN exposure / Kerberoasting	T1558.003 Kerberoasting [@mitre-t1558-003]
Credential access	Suspected over-pass-the-hash attack	T1550.002 Pass the Hash
Lateral movement	Suspected identity theft (pass-the-hash)	T1550.002
Lateral movement	Suspected identity theft (pass-the-ticket)	T1550.003 Pass the Ticket
Lateral movement	Remote code execution attempt	T1021 Remote Services
Lateral movement	Suspected NTLM relay attack (the ESC8 class)	T1187 Forced Authentication
Lateral movement	Suspected NTLM authentication tampering	T1557.001 LLMNR / NBT-NS / Man-in-the-Middle

Both alert documentation surfaces -- the classic-format alert reference and the XDR-format alert reference -- are the canonical primaries for this catalogue [@mslearn-mdi-alerts-mdi-classic][@mslearn-mdi-alerts-xdr]. Reading either page in sequence is the single most useful afternoon a SOC operator new to MDI can spend.The numeric External IDs (2006 for DCSync, 2028 and 2029 for DCShadow, 2437 for LDAP account enumeration, and so on) are a Microsoft-internal stability anchor that survives alert-name renames over time. Microsoft has renamed alerts -- "Suspected DCSync attack" was named differently in early Azure ATP -- but the External IDs do not change. Production SOAR rules should match on the External ID, not the alert name string.

An offensive primitive in which a principal that has been granted the *Replicating Directory Changes* and *Replicating Directory Changes All* extended rights uses the DRSUAPI replication interface (specifically `IDL_DRSGetNCChanges`) to request a full or partial replication of directory contents from a domain controller -- typically targeting the `unicodePwd` attribute on sensitive accounts like `krbtgt` and `Administrator`. The technique requires no code execution on the DC, no `Ntds.dit` copy, and no presence on a domain-joined machine other than network connectivity to a DC. Mimikatz's `lsadump::dcsync` command, written by Benjamin Delpy and Vincent Le Toux, is the canonical implementation; MITRE catalogues the technique as T1003.006 [@mitre-t1003-006][@adsec-dcsync]. A specific adversary behaviour catalogued in the MITRE ATT&CK framework, identified by a stable ID (for example T1003.006 for DCSync, T1558.001 for Golden Ticket, T1207 for Rogue Domain Controller). MITRE updates the framework periodically; the IDs themselves do not change, which is why detection-engineering tooling -- including MDI's per-alert MITRE mapping -- anchors to the IDs rather than the human-readable names.

Concrete mechanism, for one named alert. Suspected DCSync attack -- replication of directory services, External ID 2006, fires on the structural pattern that an IDL_DRSGetNCChanges request reached a domain controller from a source that is not itself a domain controller. The mechanism is the one place where MDI's wire-side capture pays for itself most visibly -- the 4662 event the LSA emits records the directory-service-object access but does not identify the source as not-a-DC; only the wire view sees the calling host's IP and resolves it against the directory's serverReference set.

sequenceDiagram autonumber participant Attacker as Attacker workstation (Mimikatz) participant DC as Domain Controller participant MDI as MDI v3.x sensor (on DC) participant Cloud as MDI cloud backend participant XDR as Defender XDR portal Attacker->>DC: IDL_DRSGetNCChanges (DRSUAPI replication request) DC->>DC: LSA writes event 4662 (DS object access) DC-->>Attacker: Replication response (unicodePwd, supplementalCredentials) MDI->>MDI: Wire parse: caller IP not in serverReference set MDI->>Cloud: Stream parsed event (caller, target object, attributes) Cloud->>Cloud: Correlate against known-DC IPs, fire detector Cloud->>XDR: Write alert External ID 2006 (T1003.006) XDR->>XDR: Surface in unified incident queue

The alert taxonomy makes the bookmarkable promise the rest of the article rests on. The trigger logic that fires each row, however, depends on signal the sensor can only acquire on the wire or in the event log -- and when the trigger logic misses, the operator's last-mile coverage is KQL.

6.3 The advanced-hunting schema and a worked KQL example

When the alert template misses, the hunter writes Kusto Query Language. Defender XDR exposes three identity-specific tables that the MDI sensor populates -- IdentityLogonEvents for authentication activity captured against on-prem AD, IdentityQueryEvents for queries performed against AD objects, and IdentityDirectoryEvents for events involving an on-prem domain controller including password changes, expirations, UPN changes, scheduled tasks, and PowerShell activity [@mslearn-xdr-identitylogon][@mslearn-xdr-identityquery][@mslearn-xdr-identitydirectory]. Cross-product context is available from the unified AlertInfo, AlertEvidence, and DeviceLogonEvents tables.

The worked example below is the structural DCSync detector that catches the encrypted-channel case the alert can miss. The runner in this environment cannot execute KQL directly, so the block is annotated rather than runnable -- a non-runnable KQL detector is stronger pedagogy here than a hand-rolled Python simulation, because the query as written is exactly what an operator would paste into the Defender XDR advanced-hunting console against the actual IdentityDirectoryEvents table.

// Structural DCSync detector -- DRSUAPI from non-DC IPs
// Run against the Defender XDR advanced-hunting IdentityDirectoryEvents table.
IdentityDirectoryEvents
| where Timestamp > ago(24h)                                  // tune window per triage cadence
| where ActionType == "DRSReplicate"                          // the DRSUAPI replication call
| extend SourceIP = tostring(parse_json(AdditionalFields).SourceIPAddress)
| where SourceIP !in ("10.0.1.10", "10.0.1.11", "10.0.1.12")  // tenant DC IPs go here
| where AccountName !startswith "MSOL_"                       // Entra Connect Cloud Sync FP class
| where AccountName !in ("ADConnectSync")                     // Entra Connect on-prem FP class
| project Timestamp, AccountName, SourceIP, TargetDeviceName, AdditionalFields
| order by Timestamp desc

The output rows that survive the filters are the operator's investigation queue: DRSUAPI replication requests against a DC from a source that is not itself a DC, and not a recognised hybrid-identity sync principal. The two cleanup principals -- MSOL_* (the Microsoft Entra Connect Cloud Sync service account, with a stable MSOL_ prefix and an 8-character random suffix) and ADConnectSync (the on-prem Entra Connect service account) -- are the two most common false positives every MDI tenant sees. Adding them to the !startswith and !in clauses cuts the FP rate by an order of magnitude in most environments. The third FP class that operators tune for is legitimate vulnerability scanners triggering the LDAP / SMB reconnaissance alerts -- the scanner's authenticated enumeration looks behaviourally identical to a SharpHound collector unless the scanner's source IP is in an allowlist.

flowchart LR A["IdentityDirectoryEvents
(DRSReplicate)"] --> B["Filter: source IP
not in known_dc_ips"] B --> C["Filter: account
not in sync allowlist"] C --> D["Suspect rows
(operator triage)"]

Beyond the three identity tables there is one more surface worth naming. The April 2026 Identity Explorer Preview in the Defender XDR Identity page builds on the Microsoft Sentinel data lake -- Microsoft's 2026 cross-product cold-storage and analytics layer with up to 12 years of retention in Parquet format [@mslearn-sentinel-datalake][@mslearn-mdi-whats-new]. Identity Explorer uses the Defender XDR hunting graph to visualise identity attack paths as interactive graphs with predefined scenarios for lateral movement, privilege escalation, and credential-access risk [@mslearn-xdr-hunting-graph][@mslearn-xdr-investigate-users].

The query language is the operator's last-mile coverage layer. Everything in section 6 so far is what MDI gives you. KQL is what you do when MDI does not.

6.4 The graph layer in transition

The graph that began as ATA 1.9's Lateral Movement Paths report no longer exists in the form most operators remember. The history is a clean three-step arc and a transition still in progress.

ATA 1.9 (March 2018) shipped the Lateral movement paths to sensitive accounts report, built on SAM-R-based local-administrator discovery: the sensor remotely enumerated each member host's local-administrators group and computed the chain of "who can become whom" through cached credentials [@mslearn-ata-1-9][@atadocs-lmp-usecase]. That report carried through Azure ATP, through the Microsoft Defender for Identity rename, and through the Microsoft Defender XDR rebrand essentially unchanged for seven years.

In May 2025, Microsoft disabled the SAM-R-based discovery via Message Center notice MC1073068, citing alignment with the broader Windows NTLM-deprecation roadmap [@handsontek-mc1073068]. The message body is explicit: "Disabling this feature will impact the ability to map potential lateral movement paths (using SAM-R queries) because the data used to calculate potential lateral movement paths will no longer be collected by the Defender for Identity sensor." SAM-R as a remote-discovery primitive had become a security debt as much as a feature; the deprecation brought MDI's collection behaviour into line with Restricted SAM and Microsoft's NTLM-deprecation posture, but it left the LMP surface without its primary data source.

The replacement is in two pieces. The first is the unified attack-path exploration surface in Microsoft Defender XDR, driven primarily by Microsoft Defender for Cloud's Cloud Security Posture Management (CSPM) attack-path engine [@mslearn-defenderforcloud-attack-path], with MDI feeding identity signal into the same correlation. The second is the Identity Explorer Preview that launched in April 2026 on the Microsoft Sentinel data lake, specifically for identity attack paths -- visible from the Identity page in Defender XDR for tenants with a Sentinel data lake licence [@mslearn-mdi-whats-new][@mslearn-xdr-hunting-graph][@mslearn-xdr-investigate-users]. The honest framing in 2026 is that the post-SAM-R LMP coverage is not yet fully closed by either replacement -- the Defender XDR hunting graph is rich, the Identity Explorer is improving, but the seven-year-old SAM-R-derived LMP report had operator workflows around it that the new surfaces have not all reproduced.

MDI's graph layer is in transition. The cloud rewrite handed Microsoft the platform to ship a better graph than ATA ever could; in 2026 the build-out is still in progress. Section 9 will name this as one of the article's open problems. First, though, we have to look at the competitive market the watcher sits inside.

7. Competing Approaches -- the 2026 Identity-Detection Market

If MDI is the watcher on the DC, what is everybody else? Five named methods share the 2026 identity-threat detection market with MDI, each optimising for a different trade-off. The table below is the six-column shorthand; the prose that follows is the per-method analysis.

Vendor / project	On-DC sensor model	Data-input mix	Alert taxonomy	Graph model	Pricing model
MDI	On-DC sensor (v2.x standalone or v3.x MDE-integrated)	Wire + event log + ETW + AD CS audit	MITRE-aligned alert catalogue + nine ESC posture	Hunting graph + Identity Explorer Preview	Bundled with M365 E5 / E5 Security / F5 Security
CrowdStrike Falcon Identity Protection	Connector on/near DC + endpoint agent	Wire (via connector) + endpoint telemetry	ITDR-style alerts, less granular ATT&CK mapping	Identity attack-path view (inline enforcement)	Falcon ITDR module add-on
Semperis DSP + ADFR	Off-DC change-tracking agent	AD object-change events (LDAP / replication)	IoC and IoE runtime alerts plus drift / tamper alerts	Tier 0 exposure graph + rollback graph	Standalone licence per AD object
SpecterOps BloodHound Enterprise	Off-DC collector (SharpHound CE)	AD permissions graph + Azure / Okta / Mac extensions	Attack-path exposure findings	Pure graph (Cypher over Postgres / Neo4j)	Standalone SaaS licence
Microsoft Sentinel native UEBA	None on DC (consumes MDI + other sources)	Sentinel data lake (cross-product)	UEBA risk scores, anomaly events	None on identity graph directly	Sentinel ingestion + UEBA add-on
Sigma + SIEM (open source)	None on DC (event forwarder agents)	Windows event logs, ETW via OSQuery / Velociraptor	Custom rule library	None	Free (rule library); SIEM cost separate

CrowdStrike Falcon Identity Protection is the post-acquisition rename of Preempt Platform, the product line CrowdStrike bought when it completed the Preempt Security acquisition on September 30, 2020 [@businesswire-cs-preempt]. Architecturally distinct from MDI: rather than relying on an on-DC sensor that parses wire traffic and event logs, Falcon Identity Protection inspects authentication traffic via a connector deployed on or near each DC and correlates it with Falcon-agent telemetry already collected from every protected endpoint. Identity-policy enforcement is inline -- the product can require an MFA challenge or block an authentication at the point of decision rather than emit a post-hoc alert [@crowdstrike-falcon-id]. This is the only commercial product in the survey that does inline enforcement on AD Kerberos and NTLM authentications; it is also the only one that is not bundled with a Microsoft 365 licence.

The product category that combines runtime detection of identity-targeted attacks (Kerberos forgery, credential theft, lateral movement) with response capabilities (force MFA, disable user, revoke session). Gartner formalised the term in 2022. CrowdStrike Falcon Identity Protection and SentinelOne Singularity Identity are the largest ITDR-positioned products outside the Microsoft stack; MDI plus the Defender XDR remediation actions surface effectively functions as Microsoft's ITDR offering for tenants already inside the Microsoft 365 estate [@mslearn-mdi-remediation-actions].

Semperis Directory Services Protector (DSP) and the companion Active Directory Forest Recovery (ADFR) product are best known for change-tracking and recovery, layered over a runtime Indicators-of-Compromise and Indicators-of-Exposure detection set that overlaps with MDI's alert taxonomy on classes like DCSync, DCShadow, and Golden Ticket replay [@semperis-dsp][@semperis-adfr]. DSP tracks AD object changes in near-real-time, fires IoC and IoE alerts on the same primitives MDI watches, and offers post-attack rollback as its primary differentiator; ADFR handles malware-free forest recovery in minutes-to-hours rather than days-to-weeks. The pair is partly complementary, partly overlapping with MDI: DSP catches the post-attack drift (the unauthorised group membership change, the rogue ACL) and offers a rollback path MDI does not have; MDI's per-principal behavioural baselines and unified Defender XDR incident queue are the differentiator on the in-flight detection axis; ADFR handles "the worst day of your career" forest-recovery scenarios where rebuilding the directory is the only remediation. Many tenants run all three.

SpecterOps BloodHound Enterprise (BHE) is the commercial form of the BloodHound 2016 graph model that Andy Robbins, Rohan Vazarkar, and Will Schroeder published at DEF CON 24 [@defcon-six-degrees][@bloodhound-github-specterops][@neo4j-bh]. Pure graph attack-path exposure model: BHE maps the paths that exist (Tier Zero hygiene, principal-to-principal cross-domain trust paths, Entra to on-prem pivots) rather than alerts on attacks in flight [@specterops-bhe]. Complementary to MDI: BHE tells you the attack path exists in the directory, MDI tells you someone is walking it right now. The SpecterOps team's Certified Pre-Owned whitepaper (June 2021) by Will Schroeder and Lee Christensen is the source of the ESC1-ESC8 vocabulary that downstream MDI ADCS posture assessments map to [@specterops-cpo-pdf][@specterops-cpo-blog].

Microsoft Sentinel native UEBA is the SIEM-side behavioural-baselines product over the broader event corpus that Sentinel ingests. Sentinel UEBA uses machine learning to build dynamic behavioural profiles for users, hosts, IP addresses, applications, and other entities, with named data-source connectors including Defender for Identity [@mslearn-sentinel-ueba]. Sentinel UEBA is the "outside the identity tables" layer -- detection that needs to correlate identity signal with email, endpoint, network, and SaaS signal lives there rather than in the identity tables themselves. The Defender XDR-to-Sentinel connector unifies the surfaces [@mslearn-sentinel-defender-connector].

Open-source detection stacks -- Sigma rules deployed against Sentinel, Splunk, or Elastic, plus Velociraptor and Wazuh -- can match many of MDI's pattern-based alerts but cannot match MDI's per-principal behavioural baselines without significant in-house investment [@sigmahq-github]. The SigmaHQ rule corpus contains over 3,000 detection rules in a vendor-neutral SIEM format. Olaf Hartong's FalconForce team publishes the FalconFriday hunting-query repository (MDE-schema KQL queries for DLL injection, COM hijacking, LOLBins, LDAP anomalies, and SMB NULL sessions) -- the operator-side companion to community-built detection libraries [@github-falconfriday][@falconforce-blog].

MDI is the high-coverage, low-effort identity-threat detection product if you already have Microsoft 365 E5 or E5 Security. The third-party products in this market win on differentiation -- inline enforcement, change-tracking, exposure-graph mastery -- rather than baseline coverage. The interesting question for an architect in 2026 is not which to buy. The interesting question is what MDI, by design, cannot see at all.

8. Theoretical Limits -- the Five Structural Ceilings

There are attacks no version of MDI will ever detect. Not because Microsoft has not shipped the alert yet, and not because the engineering team has not gotten around to it. Because the alert is structurally impossible.

Five named ceilings, each anchored to a primary source. Together they are the residual blind-spot inventory every operator should be able to name from memory.

flowchart TD subgraph causes ["Attacker-side cause"] C1["OS does not expose
the credential operation"] C2["Forged ticket is
cryptographically identical"] C3["Wire traffic is wrapped
in an encrypted channel"] C4["Attack pivots through
a forest without a sensor"] C5["Attacker uses real DA
real credentials"] end subgraph gaps ["Defender-side gap"] G1["Credential Guard wall"] G2["Sapphire Ticket class"] G3["Encrypted-channel DCSync"] G4["Cross-forest tail"] G5["Legitimate principal
non-detection"] end C1 --> G1 C2 --> G2 C3 --> G3 C4 --> G4 C5 --> G5

Ceiling 1 -- the Credential Guard wall. Anything the operating system itself cannot see is invisible to MDI. The DCSync class is the canonical example with a twist: Credential Guard isolates the LSASS process so that credentials in memory cannot be scraped from a compromised endpoint, but it does not prevent DRSUAPI-level secret extraction against the DC because the DRSUAPI replication interface is supposed to return password hashes to legitimate replication partners. MDI catches DCSync by detecting the wire-side pattern (DRSUAPI from a non-DC source), not by Credential Guard's protection. Anything the OS does not expose in event log, wire traffic, or instrumented API -- a custom kernel driver that reads secrets through a side channel, a hypervisor-level credential extraction on a non-Secured-core host -- is, by construction, outside MDI's data layer.

Ceiling 2 -- forged-ticket cryptographic indistinguishability, the Sapphire Ticket. This is the most important ceiling, and the one whose permanence the rest of this section orbits.

A forged Kerberos Ticket Granting Ticket whose Privileged Attribute Certificate (PAC) is a verbatim copy of a legitimate principal's PAC, obtained via the S4U2self plus User-to-User PAC-copy flow against the target principal and then encrypted with the stolen `krbtgt` key. The technique was disclosed by Charlie Bromberg (Synacktiv / Shutdown) in October 2022 and documented on The Hacker Recipes wiki [@hackerrecipes-sapphire]. The defining property: every byte of the forged ticket's PAC matches the byte pattern of a ticket the genuine KDC would have issued for the legitimate principal, including the group SID set, the user ID, the logon time, and the authorisation-data fields. The classic Golden Ticket leaves PAC anomalies that MDI's *Suspected Golden Ticket usage (forged authorization data)* alert fires on; the Sapphire Ticket leaves no PAC anomaly because there is no anomaly to leave. The Sapphire Ticket attack obtains a target principal's PAC via the S4U2self plus User-to-User PAC-copy technique -- a Kerberos protocol flow Microsoft published as part of MS-SFU and MS-KILE -- which extracts a genuine PAC into a usable form without ever needing to authenticate as the target. The attacker then forges a new ticket whose PAC is the captured PAC, encrypted with the stolen `krbtgt` key. The mechanical sequence is: S4U2self against the target produces a ticket containing the target's PAC; the U2U flow lets the attacker decrypt the embedded PAC blob; the attacker then mints a fresh TGT around that PAC with the genuine signing key. The KDC's signature checks pass because the signing key is real, and the PAC's structural fields pass because they were lifted from a ticket the genuine KDC just issued. Only the original credential compromise that produced the `krbtgt` hash leaves a trail.

Key idea: Cryptographic indistinguishability is a permanent class. No future MDI release fixes the Sapphire Ticket without breaking Kerberos itself.

Rotate `krbtgt` twice on a defined cadence -- 90 days is common; some Tier Zero playbooks rotate every 30 days. The "twice" is non-optional: a single rotation leaves the prior `krbtgt` key valid for the duration of any tickets the KDC has previously issued, so the stolen key is still usable for up to 10 hours (or longer, on `MaxRenewAge` extensions). Combine with Authentication Policy Silos for Tier Zero service accounts, Tier Zero access reviews, and Privileged Access Workstations for any administrator who can read `krbtgt`. None of these closes the Sapphire Ticket; together they shrink the window in which a stolen key remains weaponisable. Sample PowerShell for the double rotation is in the Microsoft-published `Reset-KrbTgt` script in the GitHub samples repository [@msdefender-id-github].

Ceiling 3 -- the encrypted-channel DCSync class. When DRSUAPI is wrapped in a transport the on-DC capture cannot decode -- DCSync over LDAPS via a SPN-bound impersonation chain, for instance -- the wire-side pattern recognition that powers the External ID 2006 alert degrades. The structural detector in Section 6.3 catches the unencrypted case; the encrypted case requires either a different observation surface (the DRSUAPI handler's own instrumentation) or behavioural baselining on the post-fact replication-log signal. MDI's coverage in this case is partial, not complete.

Ceiling 4 -- the cross-forest under-instrumentation tail. MDI sees the forests its sensors are deployed in. Pivot through an external trust to a forest without MDI coverage and the signal is incomplete -- the attacker's pre-pivot reconnaissance, the actual trust traversal, and any post-pivot actions on the trusting side that do not also touch an MDI-monitored forest will be invisible. This is a deployment property, not a product property: a tenant with MDI on every forest in its environment does not have this ceiling. A tenant whose acquisition portfolio includes three forests it does not yet monitor does.

Ceiling 5 -- legitimate-principal compromise non-detection. When the attacker uses a real Domain Admin's real credentials, every action is behaviourally indistinguishable from the legitimate principal unless timing, geolocation, or device fingerprint breaks the baseline. The 2025 and 2026 Suspected session cookie theft and related XDR-format alerts close part of this gap by adding behavioural side channels that the older Azure ATP alert catalogue did not cover [@mslearn-mdi-alerts-xdr]. The residual is permanent: a sufficiently disciplined attacker operating from the legitimate principal's normal workstation, during the legitimate principal's normal hours, doing things the legitimate principal might plausibly do, is, by construction, indistinguishable from the legitimate principal.

A sixth honourable mention sits adjacent to these five: out-of-band physical access -- a stolen Ntds.dit backup, an attacker-controlled DC's offline export, supply-chain firmware compromise on the DC hardware -- is outside the data layer MDI operates over. The hardware-trust-root community owns this class of mitigation, not the identity-threat detection community.

Note: The five structural ceilings are knowable, not surprises. A SOC that names them ahead of time has a better incident-response runbook than one that does not -- specifically, the runbook for "we just realised the attacker used a Sapphire Ticket" is fundamentally different from the runbook for "MDI fired and we ignored it." The first runbook starts with krbtgt rotation and Tier Zero hygiene review; the second starts with disciplinary review and SOAR-rule tuning. Knowing which runbook to pick depends on naming the ceiling correctly.

These five named residuals are why the rest of the article exists. If MDI caught everything, the operator playbook in Section 10 would be unnecessary. Because MDI does not, and because the gaps are knowable, the playbook in Section 10 is the difference between MDI as a licence line item and MDI as a working part of the SOC's day. But before the playbook, one last open-problem inventory: where is the research roadmap actually working?

9. Open Problems -- What the Research Roadmap Is Working On

Five open problems sit between the 2026 floor and a hypothetically perfect identity-threat detector. Each one has a current best partial result and a citation. None of them is closed.

Open Problem 1 -- the post-PKINIT NTLM-relay class beyond ESC8. Synacktiv's Understanding and evading Microsoft Defender for Identity PKINIT detection paper (Guillaume Andre, 2024) reverse-engineered MDI's PKINIT-class detection: MDI fingerprints offensive-tool-generated AS-REQ messages by the encryption types they advertise, which differ from the encryption-type list a legitimate Windows API PKINIT request generates [@synacktiv-pkinit-evasion][@synacktiv-pkinit-evasion-archive]. The companion Invoke-RunAsWithCert PowerShell tool generates AS-REQ messages via the Windows API itself, producing requests structurally identical to legitimate enterprise PKINIT authentication and bypassing the fingerprint-based detection [@synacktiv-runascert-gh][@deepwiki-runascert]. Aura Security's follow-on writeup confirms the technique against the current MDI version and walks through modifying Certipy to produce matching AS-REQ shapes [@aurainfosec-mdi-pkinit]. The partial mitigation in 2026 is the additional posture-side coverage in the nine MDI Certificates assessments, which closes some of the configurations the offensive tools target [@mslearn-mdi-certificates-posture]. The runtime detection arms race continues.

Open Problem 2 -- the graph-layer transition from SAM-R LMP to Identity Explorer. Section 6.4 covered the deprecation of SAM-R-based LMP discovery in May 2025 (MC1073068) and the two replacement surfaces: the Defender XDR attack-path exploration driven by Defender for Cloud's CSPM engine, and the April 2026 Identity Explorer Preview on the Sentinel data lake [@handsontek-mc1073068][@mslearn-defenderforcloud-attack-path][@mslearn-mdi-whats-new][@mslearn-xdr-hunting-graph]. The honest open question is whether either surface reproduces, in 2026, the operator workflows the seven-year-old SAM-R-derived LMP report had built up around itself. The Defender XDR hunting graph is richer than the LMP report ever was, but its data model is different; the Identity Explorer is closer in spirit but in Preview rather than GA.

Open Problem 3 -- the Sentinel data lake correlation and the Identity Explorer GA path. Microsoft Sentinel data lake, the cross-product cold-storage and analytics layer, went public preview in 2025 and ships with up to 12 years of retention in Parquet format, a clean separation of storage and compute, and KQL plus Jupyter notebook query surfaces [@mslearn-sentinel-datalake][@mstc-sentinel-datalake-preview]. Identity Explorer is the first identity-specific surface built on top of the data lake; it is in Preview as of April 2026 with no GA date published. The open problem is whether the data-lake-tier correlation can match the alert-tier MDI quality for long-running attacker dwell -- the months between Sapphire Ticket use and discovery class -- without producing more noise than signal.

Open Problem 4 -- the MDI evasion research arms race. Synacktiv's two papers (the sensor primer by Andre and Benassouli in 2022; the PKINIT evasion paper by Andre in 2024) plus the operator notes on alert-timing exploitation that show up in adsecurity.org and SpecterOps content are the public record of the offensive-research community's targeting of MDI specifically [@synacktiv-primer-mdi][@synacktiv-primer-mdi-archive][@synacktiv-pkinit-evasion][@synacktiv-pkinit-evasion-archive]. FalconForce's reverse-engineering of the MDE sensor (via Olaf Hartong's MDE Internals series) is the methodological precedent for the same approach against MDI; the FalconForce blog and the FalconFriday hunting-query repository are the operator-facing primaries [@falconforce-mde-0x02][@falconforce-mde-0x03][@falconforce-blog][@github-falconfriday][@github-olafhartong]. The Charlie Bromberg Sapphire Ticket disclosure (October 2022) is the cryptographic-attack-class research that Section 8's third ceiling rests on [@hackerrecipes-sapphire]. The arms-race property is permanent; the defensive product team's job is to keep the detection-shipping cadence faster than the evasion-shipping cadence, which the cloud rewrite (see Section 5) made structurally possible.

Open Problem 5 -- the non-Windows directory coverage tail. MDI covers Active Directory and (via the Microsoft Entra Connect sensor) the on-prem-to-Entra-ID sync surface. Native Entra ID attacks (token theft against Entra ID itself, OAuth consent phishing, Conditional Access bypass) are covered by Defender for Cloud Apps and Entra ID Protection, not by MDI. The boundary between MDI's scope and the adjacent products is operationally meaningful: a SOC operator reading "MDI did not fire" on an Entra-ID-only attack should not conclude the attack went undetected -- another product likely did fire, in another part of the same Defender XDR portal. The unified incident queue stitches the alerts together; the operator's mental model has to know which sensor surface to look at when triaging.

The article does not claim "BloodHound CE forced MDI to add ADCS detections in 2024." The framing is parallel evolution: as BloodHound CE expanded ADCS attack-path coverage in 2024-2025, MDI extended its ADCS posture assessments and PKINIT-class runtime detections during the same window. The two product communities watch each other; neither one "forces" the other.

The roadmap is real, the build-out is in progress, and the operator decision in 2026 is not "wait for the perfect product." It is "deploy what works now, and cover the residuals with KQL."

10. The MDI Deployment and Triage Playbook

Four lanes, mapped to four operator personas: the architect who designs the sensor footprint, the SOC analyst who triages the alerts, the threat hunter who writes the KQL that fills the gaps, and everyone who needs to know what does not work.

Lane 1 -- sensor placement and prerequisite hygiene

Deploy the v3.x sensor on every domain controller running Windows Server 2019 or later, paired with the MDE agent. The deployment path is the Microsoft Defender portal's migration wizard or the standalone install via the MDE agent's onboarding flow [@mslearn-mdi-deploy-sensor-v3][@modernsec-v3x][@jeffreyappel-v2v3].

Deploy the v2.x sensor on every AD FS federation server, every AD CS online issuing certificate authority, and every Microsoft Entra Connect server (both active and staging), unless those roles already run on a domain controller covered by a v3.x sensor with the May 2026 identity-role extension enabled [@mslearn-mdi-prereq-sensor-v2][@mslearn-mdi-whats-new].

Configure the required Windows audit subcategories via the Group Policy Subcategory Settings path that the MDI event-collection page enumerates -- Audit Credential Validation, Audit Kerberos Authentication Service, Audit Kerberos Service Ticket Operations, Audit Logon, Audit Directory Service Access, Audit Computer Account Management, plus the additional subcategories for AD CS and AD FS roles. The v3.x sensor includes an Automatic Windows auditing configuration toggle that uses the Windows LSA audit-policy APIs to set the subcategories directly, eliminating the GPO step [@mslearn-mdi-event-collection].

Set the MDI Action Account in the Defender portal. The default is LocalSystem impersonation on the sensor host, which works for response actions targeting AD objects (force password reset, disable user). A gMSA-based Action Account is the alternative for tenants that want least-privilege response identities scoped per workspace [@mslearn-mdi-action-accounts][@mslearn-mdi-remediation-actions]. Avoid configuring the same gMSA across multiple sensor hosts -- the documented anti-pattern is to use one Action Account for DC-side actions only.

Verify the Microsoft Defender portal role assignments so that SOC analysts have the correct read-and-respond permissions on identity alerts. The Microsoft Defender for Identity enterprise application (ID 60ca1954-583c-4d1f-86de-39d835f3e452) is the consent surface for the response actions; tenants that have not granted consent will see "remediation action unavailable" on identity-targeted incidents [@mslearn-mdi-remediation-actions].

Lane 2 -- alert triage SLAs

The triage matrix maps alert category to response-time target and the named SOC role that owns triage. Numbers below are typical Tier 1 / Tier 2 SOC targets; tune to your environment's incident-response policy.

Alert category	Response-time target	Owning SOC role	Notes
DCSync, DCShadow, Golden Ticket	1 hour	Tier 2 (privileged-account-compromise specialist)	Treat as confirmed compromise pending evidence to the contrary
AS-REP Roasting, Kerberoasting	4 hours	Tier 2	Higher-FP class; verify offending principal pattern before escalation
NTLM relay (ESC8 class)	4 hours	Tier 2	ADCS-aware; coordinates with CA team
Reconnaissance (LDAP / SMB / DNS)	24 hours	Tier 1	Highest-FP class; allowlist legitimate scanners
Honeytoken activity	1 hour	Tier 1 plus Tier 2 escalation	Near-zero FP; any hit is investigation-worthy

Two false-positive cleanup patterns appear in nearly every tenant. The Azure AD Connect Cloud Sync service principal -- MSOL_ plus an 8-character random suffix -- legitimately performs DRSUAPI-like operations as part of the hybrid identity sync flow, and will fire DCSync-class alerts unless allowlisted. Legitimate vulnerability scanners (Tenable, Rapid7, Qualys) perform authenticated enumeration that triggers the LDAP and SMB reconnaissance alerts; scanner IPs go in an exclusion list per the Defender XDR portal's identity-alert tuning surface.

The MDI Action Accounts and Remediation Actions surface lets the responder disable a user, force a password reset, revoke an Entra ID session, or mark an account as compromised -- triggered manually from the alert flow or automatically via the Defender XDR automatic attack disruption engine, which requires 99 percent or higher detector precision before taking containment action [@mslearn-xdr-attack-disruption][@mslearn-mdi-remediation-actions][@mslearn-xdr-investigate-users]. Automatic attack disruption is opt-in per containment action; the conservative default leaves analyst confirmation in the loop for password-reset-class actions and automates disable-user only on the highest-precision detector classes.

Note: The cloud-side analytics pipeline aggregates signal across the per-principal baseline window before deciding to emit. Empirically the alert latency is minutes-cadence, not seconds-cadence. Incident response runbooks that assume sub-second alert arrival will be wrong; the operator clock starts when the alert hits the Defender XDR queue, which is itself minutes after the wire-side event. Plan for this in the SLA matrix above -- the "1 hour" target for DCSync starts from the alert timestamp, not the attack timestamp, and the attack itself may have happened five or ten minutes earlier. The Microsoft alerts-overview page is explicit that MDI is "not designed to serve as an auditing or logging solution that captures every single operation or activity on the servers where the sensor is installed; it only captures the data required for its detection and recommendation mechanisms" [@mslearn-mdi-alerts-overview].

Lane 3 -- advanced-hunting queries that fill the gaps

Three structural detectors in KQL form, each one targeting a class the named alerts can miss. Each query names the table, the columns, and the threshold tuning the operator will need.

The structural DCSync detector runs against IdentityDirectoryEvents and catches the encrypted-channel case the External ID 2006 alert may miss:

IdentityDirectoryEvents
| where Timestamp > ago(24h)
| where ActionType == "DRSReplicate"
| extend SourceIP = tostring(parse_json(AdditionalFields).SourceIPAddress)
| where SourceIP !in ("10.0.1.10", "10.0.1.11", "10.0.1.12")   // tenant DC IPs
| where AccountName !startswith "MSOL_" and AccountName !in ("ADConnectSync")
| project Timestamp, AccountName, SourceIP, TargetDeviceName, AdditionalFields
| order by Timestamp desc

Threshold tuning: keep the time window short (24 hours) for daily triage. Cleanup principals (MSOL_*, ADConnectSync, plus any per-tenant sync identities) go in the !startswith and !in clauses. The query produces a clean queue of "DRSUAPI replication from a host that should not be doing DRSUAPI." False-positive class: legitimate Azure AD Connect Cloud Sync service principals; resolve by adding the principal to the allowlist.

The slow-burn Kerberoasting detector runs against IdentityLogonEvents and catches the rate-limited Kerberoast pattern that modern attackers use to stay below the MDI behavioural-baseline threshold:

IdentityLogonEvents
| where Timestamp > ago(7d)
| where Protocol == "Kerberos"
| where ActionType == "ServiceTicketRequest"
| extend EncType = tostring(parse_json(AdditionalFields).EncryptionType)
| where EncType in ("RC4-HMAC", "DES-CBC-MD5")
| summarize SpnCount = dcount(TargetSpn), SpnList = make_set(TargetSpn) by AccountName, bin(Timestamp, 1d)
| where SpnCount > 5     // tune per tenant baseline
| order by Timestamp desc, SpnCount desc

Threshold tuning: the SpnCount > 5 threshold is the load-bearing knob. Tenants with legitimate operational accounts that request many SPNs per day (privileged service accounts running scheduled tasks across many target hosts) will need a higher threshold and an allowlist. The seven-day window catches the slow-burn pattern that a one-hour window misses.

The PKINIT-relay structural detector runs against IdentityLogonEvents and watches for AS-REQ with PA-PK-AS-REQ pre-auth coming from unexpected client subnets:

IdentityLogonEvents
| where Timestamp > ago(24h)
| where Protocol == "Kerberos"
| where ActionType == "InitialAuthentication"
| extend PreAuth = tostring(parse_json(AdditionalFields).PreAuthType)
| where PreAuth == "PA-PK-AS-REQ"
| extend ClientSubnet = strcat(split(IPAddress, ".")[0], ".", split(IPAddress, ".")[1])
| where ClientSubnet !in ("10.0.5", "10.0.6")    // legitimate smartcard subnets
| project Timestamp, AccountName, IPAddress, DeviceName, AdditionalFields
| order by Timestamp desc

Threshold tuning: PKINIT is legitimate when smartcard logon is in use. Identify the legitimate smartcard-issuing subnets and add them to the !in clause. The residual queue is PKINIT from unexpected sources -- the structural pattern behind both the post-ESC8 NTLM-relay class and the Synacktiv Invoke-RunAsWithCert evasion class.

Tenants that want the alert and event corpus in their SIEM as well as in Defender XDR should configure the MDI to Microsoft Sentinel connector through the Defender XDR-to-Sentinel integration; the connector is auto-enabled when Sentinel is onboarded to the Defender portal [@mslearn-sentinel-defender-connector].

Lane 4 -- what does NOT work

Five named operator myths, each refuted with a one-paragraph structural reason.

Myth 1: "MDI without the DC sensor still catches Kerberos attacks via the Entra ID side." Wrong. The Kerberos protocol layer is on-prem; the analytics require on-DC capture of the AS-REQ / TGS-REQ / AP-REQ exchange. Entra ID's side of the hybrid auth flow does not carry the same protocol detail. A tenant with MDI licensed but the sensor not deployed on the DCs has no Kerberos detection at all -- the licensed state is necessary but not sufficient.

Myth 2: "Disabling the v2.x sensor on AD FS is fine since it is covered by the DC sensor." Wrong. The AD FS authentication flow generates federation-side events (SAML assertions, OAuth tokens, the Application and Security event logs that AD FS itself writes) that the DC sensor does not see. AD FS deserves its own sensor unless the AD FS role is collapsed onto a domain controller, in which case the May 2026 v3.x identity-role extension covers it.

Myth 3: "Defender for Endpoint covers what MDI covers." Wrong. MDE catches endpoint behaviour -- process creation, file access, network connections, registry writes. MDI catches protocol-level Kerberos, NTLM, LDAP, and DRSUAPI patterns. The two products share an agent surface in the v3.x architecture, but the signal classes are different. An MDE-only deployment will not catch a DCSync from a workstation if MDI is not licensed and the sensor is not deployed; the MDE agent on the DC sees the local process activity but not the wire-side replication call's source.

Myth 4: "MDI alerts are real-time." Wrong. As Callout in Lane 2 above. The cloud-side batched-emission cadence is minutes-not-seconds, and incident response runbooks need to account for it.

Myth 5: "MDI requires no tuning." Wrong. Every environment has unique false-positive patterns from internal tooling that need exclusions. Microsoft ships the default detector thresholds; tenants tune them through the Defender XDR portal's identity-alert configuration surface. A tenant that has not tuned the recon-alert allowlist for its vulnerability scanners will receive far more noise than signal.

Coverage, triage, KQL, and humility about what does not work. The four lanes are the difference between MDI as a licence item on a renewal sheet and MDI as a working part of the SOC's day.

11. Frequently Asked Questions and Closing

Six questions that come up every time MDI is on a whiteboard, each in the misconception-removal pattern: wrong answer named first, then refuted.

No. See the *common misreading worth fixing* Callout in Section 4: graph-anchored attack-path evaluation in Microsoft's defensive stack originates in ATA 1.9 (March 2018), and the 2022 anchor in operator memory is the start of the SAM-R-discovery deprecation arc that culminated in MC1073068 in May 2025 [@mslearn-ata-1-9][@handsontek-mc1073068]. Not as one alert per ESC class. The MDI Certificates posture page documents **nine ADCS posture assessments** -- ESC1 (Preview), ESC2, ESC3, ESC4 (template-owner and template-ACL variants), ESC6 (Preview), ESC7, ESC8, ESC11, and ESC15 [@mslearn-mdi-certificates-posture]. The runtime detection surface for the ESC8 NTLM-relay class is the *Suspected NTLM relay attack* alert in the XDR catalogue [@mslearn-mdi-alerts-xdr]. PKINIT-class runtime detection (the post-ESC8 chain) is the AS-REQ encryption-type fingerprint that Synacktiv documented and partially evaded; the August 2023 AD CS sensor release is the prerequisite for posture coverage [@mstc-adcs-sensor][@synacktiv-pkinit-evasion][@synacktiv-pkinit-evasion-archive]. Coverage is "nine posture assessments plus one runtime alert," not "one alert per ESC1 through ESC15." Microsoft has never published the canonical list; community reverse-engineering is the only source. See the *honest provenance of the ETW provider list* Aside in Section 5 for the full provenance (Synacktiv's November 2022 primer; Olaf Hartong's FalconForce MDE Internals 0x02 methodology; the Get-TraceLoggingMetadata + Sealighter toolchain) and the snapshot-not-ground-truth framing [@synacktiv-primer-mdi][@falconforce-mde-0x02]. In the cloud since Azure ATP went GA in March 2018 [@mstc-azureatp-ga][@mstc-azureatp-intro]. The on-DC sensor is a thin parser that captures Kerberos / NTLM / LDAP / DRSUAPI on the wire, parses the protocols into structured events, and streams the parsed signal to the multi-tenant cloud backend over HTTPS. The detection logic, the per-principal behavioural baselines, and the alert-emission pipeline all run in the cloud. The legacy on-prem ATA Center model ended with Azure ATP; ATA itself shipped its last release (1.9.3) in September 2020 and Extended Support ends January 2026 [@mstc-ata-eol][@atadocs-versions]. No. The framing is parallel evolution, not a "forcing" relationship. BloodHound CE expanded ADCS attack-path coverage substantially in 2024 and 2025; during the same window MDI extended its ADCS posture assessment surface and added the AD CS sensor release in August 2023 [@mstc-adcs-sensor][@dirteam-sander-aug2023]. Both product communities watch each other -- the Defender team uses BloodHound to red-team its own environments, the SpecterOps team uses MDI when consulting in enterprise Microsoft shops -- but the causal claim "BloodHound forced MDI" is not supported by the public release record. The two communities' work has been concurrent and mutually informing. Almost. The MITRE-aligned alert catalogue in Section 6.2 covers the most-prevalent offensive primitives. Section 8 names the five structural ceilings that remain by-construction unclosable; *almost* is the load-bearing word.

Friday, 14:35. The watcher on the domain controller has written three named alerts into the Defender XDR queue. The red-team contractor's Rubeus.exe asreproast fired Suspected AS-REP Roasting attack (T1558.004). The junior auditor's bloodhound-python -c All fired Security principal reconnaissance (LDAP). The Mimikatz DCSync against the SQL host's service account fired Suspected DCSync attack -- replication of directory services, External ID 2006, T1003.006. Three alerts. Three MITRE technique IDs. Three rows in a Tier 1 analyst's queue.

The watcher's job is done. Whether the analyst opens the right one first, whether the Tier 2 escalation happens inside the one-hour SLA, whether the response action gets approved before the attacker has moved on -- none of that is MDI's problem to solve. It is yours.

The Card That Wasn't a Card: How Windows Authentication Outgrew the Smart Card Metaphor

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

**The Windows smart card story is the story of a metaphor.** Roland Moreno's 1974 "card with a secret" became Windows 2000's `SCardSvr.exe`, then Windows 8's TPM Virtual Smart Card (a software card with the same PC/SC interface), then Windows Hello for Business (which threw the card edge away and talks to the TPM directly), then FIDO2 (which added the origin binding the card was never designed for). The cryptographic primitive -- a non-exportable asymmetric key under a local gesture -- survives every transition. The 2014 disclosure that smart-card-required accounts still mint a harvestable NTLM hash is closed not by any change to the card but by Microsoft's 2024-2026 NTLM removal plan. The card was always cryptographically sound; the protection terminated at the act of signing.

1. A Smart Card Login That Mints an NTLM Hash

Picture May 2014. A Department of Defense contractor pushes her Common Access Card into a Windows 7 workstation, types a six-digit PIN, and watches the lock screen melt into her desktop. The RSA-2048 private key that just signed her Kerberos pre-authentication blob lives inside a tamper-resistant secure element she cannot extract from the card. The cryptography is excellent. Three hours later, an attacker on the same network owns her domain account without ever touching the card [@dirteam-aorato] [@kb-2871997].

How is that even possible? Hold that question. The answer is the spine of this article.

The contractor here is a composite figure, not a documented incident. The mechanism (CAC + Windows 7, RSA-2048 signing inside the card, an NT hash recoverable from LSASS three hours later) is the one Aorato disclosed in 2014 [@dirteam-aorato] and Microsoft documented in KB 2871997 [@kb-2871997]. The scenario is faithful to the published attack chain; the person and the office park are illustrative.

The protocol that ran when she logged in is PKINIT, defined by RFC 4556 [@rfc-4556] and profiled for Windows in [MS-PKCA] [@ms-pkca]. PKINIT lets a Kerberos client present an X.509 certificate as pre-authentication for the Authentication Service Request (AS-REQ), with a digital signature proving possession of the matching private key. In a Windows smart card logon the signing happens inside the card. The Microsoft Smart Card Key Storage Provider hands the card a hash; the card returns a signed AuthPack containing a PKAuthenticator (timestamp, nonce, paChecksum) and Diffie-Hellman parameters; that signed AuthPack rides in the PA-PK-AS-REQ pre-authentication data of the AS-REQ [@rfc-4556] [@ms-pkca].

So far, so good. The Key Distribution Center (KDC) verifies the signature, validates the certificate chain, mints a Ticket-Granting Ticket (TGT), and returns it. Our contractor sees her desktop.

But the KDC has a second job she does not know about. Her account is flagged "smart card required for interactive logon," so she has no password. Windows must still authenticate her to a legacy SMB1 server or any network application that speaks only NTLM. The clean answer would be "it cannot." The answer Microsoft shipped in Windows 2000 is: the KDC silently maintains an NTLM-equivalent secondary credential for every smart-card-only user, rotating it at logon, so legacy services keep working [@kb-2871997] [@msrc-kb-2871997].

That secondary credential is an NT hash. Once her session is live, an NT hash sits in the Local Security Authority Subsystem (LSASS) memory of every machine she touches. The smart card never sees it. The card cannot police it. It is sixteen bytes of MD4 output that the OS minted around the cryptographic operation the card refused to delegate.

A non-NTLM-derived NT hash that Windows maintains for accounts configured to log on with a smart card or other non-password credential, so that legacy NTLM-accepting services (SMB1, pre-Windows-2000 applications, some printers) continue to authenticate the user. The hash is computed from a random secret, not the card key, and is rotated by the KDC. From a pass-the-hash attacker's perspective, it is indistinguishable from a password-derived hash and equally replayable.

Three hours later, an attacker who has phished a privileged helpdesk account runs sekurlsa::logonpasswords from a copy of mimikatz [@mimikatz-gh] against the LSASS process on a server the contractor logged into earlier that day. The output looks like NTLM : a1b2c3.... The attacker pipes that NT hash into a pass-the-hash against any NTLM-accepting service in the forest. Because RFC 4757 [@rfc-4757] makes the RC4-HMAC Kerberos long-term key identical to the NT hash, the attacker can also forge Kerberos pre-authentication for the smart-card-required account and request its TGT. The card sat in a reader the attacker never touched. None of that mattered.

This is the inversion the article exists to explain. The card protected the key. The card did not, and could not, protect the identity. Microsoft documented the gap on May 13, 2014 as KB 2871997, "Update to improve credentials protection and management" [@kb-2871997]; the Microsoft Security Response Center followed with a blog overview of the threat model and the defence-in-depth response [@msrc-kb-2871997]. The disclosure came from Tal Be'ery and his team at Aorato, a Tel Aviv security startup Microsoft would acquire six months later. The period-accurate operator analysis lives in Sander Berkouwer's July 15, 2014 writeup, cited here because the original Aorato post is offline [@dirteam-aorato].

How did Windows arrive at an architecture where a tamper-resistant cryptographic token could leave the user's identity wide open? To answer that we go back to a 1974 patent in Paris.

2. How Cards Got a Chip

Roland Moreno was twenty-nine when he filed his first smart-card patent family in 1974. A self-taught Parisian, a former pinball-machine fixer and humorist who had washed out of the Sorbonne, he wired an off-the-shelf microchip to a ring of contacts on a small plastic substrate and walked the result over to INPI, the French patent office. The patent family -- known in the secondary literature as carte a memoire -- did not invent the integrated circuit, the credit-card form factor, or even the idea of embedding silicon in plastic. What Moreno added was a property: the card holds a secret the cardholder cannot extract [@wp-moreno] [@wp-smart-card].

That property is the entire story.

Helmut Groettrup, a West German engineer, got there first. He filed German patents DE1574074 and DE1574075 in February 1967 for a tamper-proof identification switch based on a semiconductor device, and added a joint Austrian filing with Juergen Dethloff in September 1968 [@bmpos-history] [@wp-smart-card]. The standard French historiography credits Moreno with the secured-memory refinement rather than the form factor. The inventor question depends on which property you treat as load-bearing.

Three other people belong in this section. In 1977 Michel Ugon, an engineer at Honeywell Bull's CP8 division in France, built the first microprocessor smart card -- a card with a CPU on it, not just memory. In 1978 Bull filed the SPOM patent that collapsed CPU and EEPROM onto one chip, the architectural change that made mass production tractable [@bmpos-history] [@cnam-pdf]. And from 1987 to 1995 the International Organization for Standardization froze the card edge into a vendor-neutral wire format with the four parts of ISO/IEC 7816 [@wp-smart-card]: physical characteristics, electrical and transmission protocols, and -- the part that would matter most for Windows -- the command set.

The international standard for contact smart cards, in four parts that interest software architects: Part 1 covers physical characteristics, Part 3 covers electrical interface and the T=0 and T=1 transmission protocols, and Part 4 covers the organisation, security, and command set for interchange. ISO/IEC 7816-4:2020 is the current edition of Part 4. Application Protocol Data Unit. The request/response unit a host application exchanges with a smart card. The command APDU starts with a four-byte header `CLA INS P1 P2` (class, instruction, two parameter bytes), followed by an optional length byte `Lc` and `Lc` bytes of data, and an optional expected-response-length byte `Le`. The response APDU is `[data] SW1 SW2`, where the two status word bytes encode success or a card-side error.

A worked APDU example makes this concrete. To select the PIV application on a smart card, a host sends 00 A4 04 00 0B A0 00 00 03 08 00 00 10 00 01 00. The first byte is CLA = 00 (interindustry class). The second is INS = A4 (SELECT). P1 = 04 indicates that the parameter is an application identifier. P2 = 00 selects the first occurrence. Lc = 0B says eleven data bytes follow, and those eleven bytes are the full PIV AID per NIST SP 800-73-4 [@sp-800-73-4-upd1]: nine bytes for the registered application identifier (A0 00 00 03 08 00 00 10 00) followed by the two-byte PIV application version identifier (the PIX, 01 00, per SP 800-73-4 Part 1 §2.2). The card replies with optional file control information and the status word 90 00, which means success. Every operation the Windows smart card stack performs decomposes, eventually, into a sequence of these short frames.

timeline title Card-as-authenticator timeline 1967-1968 : Groettrup and Dethloff file IC-on-card patent 1974 : Moreno files carte a memoire family 1977-1978 : Ugon and Bull build CPU smart card and SPOM 1987-1995 : ISO/IEC 7816 parts 1, 3, 4 published 1996 : PC/SC Workgroup founded 2000 : Windows 2000 ships SCardSvr.exe 2007 : Microsoft Base Smart Card CSP and minidriver model 2011 : Windows 7 SP1 inbox PIV/GIDS minidriver 2012 : Windows 8 ships Virtual Smart Card 2015 : Windows Hello announced 2024 : NTLMv1 removed in Windows 11 24H2

By 1996 the card edge was settled. Three thousand-odd APDU specifications and proprietary applets later, the only remaining question was: how does a personal computer talk to a card reader? Smart card readers lived in two operationally incompatible worlds, the bank-teller world and the workstation world, and the workstation world was held back by a vendor-driver swamp. So in 1996 a consortium called the PC/SC Workgroup formed. The contemporary record names Microsoft, IBM, Hewlett-Packard, Sun Microsystems, Siemens Nixdorf, and Bull as founders, with Schlumberger and other card vendors joining shortly after [@wp-pcsc] [@sc-architecture].

The PC/SC specification series ("Interoperability Specification for ICCs and Personal Computer Systems") names exactly the right abstractions: a Smart Card Resource Manager that brokers access to attached readers, an Interface Device Handler that abstracts reader hardware, and a Service Provider that exposes a uniform programming surface to applications [@sc-architecture]. A personal computer talks to a smart card by speaking PC/SC, in user-mode, through whatever service the OS provides.

Personal Computer/Smart Card. The 1996 industry consortium and its specification series that define how a smart card reader is exposed to a desktop operating system. PC/SC factors the stack into reader hardware (Interface Device), an Interface Device Handler driver, a Smart Card Resource Manager (a system service brokering access), and a Service Provider exposing a uniform API to applications.

Microsoft answered the implementation question in February 2000 with SCardSvr.exe, the Smart Cards for Windows service that shipped in Windows 2000 [@sc-architecture]. And immediately created a new problem: every card vendor still wanted to own the cryptographic provider.

3. From SCardSvr to Base CSP: Eleven Years to a Vendor-Neutral Stack

Windows 2000 shipped smart card logon as a vendor-neutral primitive. Within months, the operational reality bit. Every card vendor shipped a different CryptoAPI plug-in, every plug-in needed installing per machine, per card, sometimes per user.

Walk down the stack. At the bottom is the reader, attached over USB or, in early-2000s deployments, an internal serial port. Above the reader is the Interface Device Handler driver supplied by the reader vendor. Above the driver is SCardSvr, Microsoft's Smart Card Resource Manager service. SCardSvr exposes a user-mode API called WinSCard: SCardEstablishContext, SCardConnect, SCardTransmit, SCardDisconnect [@winscard-api]. WinSCard is the C-level entry into PC/SC; an application that wants to send raw APDUs to a card uses WinSCard directly [@sc-architecture].

The Windows user-mode API surface for PC/SC. Canonical entry points include `SCardEstablishContext`, `SCardListReaders`, `SCardConnect`, `SCardTransmit`, and `SCardDisconnect`. An application sending raw APDUs to a smart card uses WinSCard; higher-level Windows components (Kerberos client, certificate enrolment, the lock-screen credential provider) reach the card indirectly through the Cryptographic Service Provider or Key Storage Provider layers.

Cryptographic clients do not want to write APDU sequences. They want to call CryptSignHash or NCryptSignHash and have a signature appear. Translating those API calls into the card's APDU command set is the job of a Cryptographic Service Provider in the CryptoAPI 1.0 world and a Key Storage Provider in the CNG (Cryptography Next Generation) world. From 1996 to 2007, almost every card vendor wrote its own CSP. The Schlumberger CSP. The Gemalto CSP. The Axalto CSP. The ActivIdentity CSP. Each was an in-process DLL that talked to the card through WinSCard, applied vendor-specific quirks, and exposed a CSP interface to Windows.

A plug-in for CryptoAPI 1.0 that provides cryptographic services (key generation, signing, hashing, key storage) to applications. CryptoAPI loads a CSP in-process. For smart cards, the CSP translates CryptoAPI calls into card-specific APDUs through WinSCard. Microsoft Base Smart Card CSP, shipped in 2007, replaced the per-vendor CSP with a single CSP that delegated card-specific behaviour to a much smaller minidriver. The CNG-era plug-in that provides key storage and asymmetric cryptographic operations. CNG separates algorithm providers (BCrypt: hashing, symmetric, signature primitives) from key storage providers (NCrypt: key lifecycle, key-protected operations). The Microsoft Smart Card Key Storage Provider is the CNG-side path for smart card and Virtual Smart Card keys; the Microsoft Platform Crypto Provider is its sibling that talks to the TPM directly.

The architecture had two problems by 2003. First, an N x M combinatorial. Every new card vendor multiplied integration cost for every cryptographic application, and vice versa. Large enterprises ran two or three CSPs per workstation; subtle bugs in signature padding or PIN caching only surfaced when an application built for vendor A's CSP met a card configured for vendor B's. Second, a security problem: each CSP ran in-process with every CryptoAPI client, so a buggy or compromised third-party CSP could reach critical OS components.

Microsoft's answer was the Smart Card Minidriver Specification, finalised around the Vista launch in 2006-2007. Microsoft would ship one CSP -- the Microsoft Base Smart Card CSP -- containing the cryptographic state machine common to all PIV-style cards. Per-card behaviour would live in a much smaller DLL called a minidriver, loaded by the Base CSP when it recognised the card. The specification, dn631754, currently maintained at v7.07, says exactly this: "The Microsoft Smart Card Base CSP and KSP is a refinement of the architecture that separates commonly needed CAPI-based CSP and CNG-based KSP functionality, respectively, from the implementation details that must change for every card vendor" [@sc-minidrivers] [@sc-minidriver-spec].

The CNG-side sibling, the Microsoft Smart Card Key Storage Provider, plugs into the same minidriver layer. CNG is the post-Vista cryptographic platform: BCrypt for algorithm primitives, NCrypt for key lifecycle and storage [@cng-storage]. The Smart Card KSP supports DH 512-4096, ECDH P256/P384/P521, ECDSA P256/P384/P521, and RSA 512-16384 [@cng-ksp-list]. Both the legacy Base CSP and the modern KSP route through the same minidriver, so a card vendor writes one DLL and gets compatibility with both CryptoAPI 1.0 and CNG applications.

flowchart TD A[Reader hardware] --> B[IFD driver] B --> C[SCardSvr Smart Card Resource Manager] C --> D[WinSCard user-mode API] D --> E[Microsoft Base Smart Card CSP and Smart Card KSP] E --> F[Card minidriver DLL] F --> G[ISO 7816-4 APDU on the card] H[CryptoAPI 1.0 client] --> E I[CNG NCrypt client] --> E

CryptoAPI's CryptSignHash walks the Base CSP; CNG's NCryptSignHash walks the Smart Card KSP; both end up issuing the same APDU sequence through the same minidriver to the same card.

Property	CryptoAPI Base CSP	CNG Smart Card KSP
Era	CryptoAPI 1.0, pre-Vista to present (legacy support)	CNG, Vista onward
Entry point	`CryptAcquireContext`, `CryptSignHash`	`NCryptOpenStorageProvider`, `NCryptSignHash`
Implementation DLL	`basecsp.dll`	`microsoft smart card key storage provider` registered through `ncrypt.dll`
Per-card extension	Smart card minidriver	Same smart card minidriver
Algorithm range	RSA, basic ECC	RSA, full Suite B ECC, large key ranges

By 2008 the architecture was elegant. But every PIV card still needed a minidriver acquired from somewhere -- a CD, a vendor ftp site, an enterprise distribution share. And in 2004 the US federal government was about to make the smart card mandatory for several million people who could not wait for a vendor disk.

4. PIV, GIDS, CAC, and the Inbox Driver That Removed the Last Install Step

On August 27, 2004, President George W. Bush signed Homeland Security Presidential Directive 12, a one-page policy with one operational sentence: there shall be "a mandatory, government-wide standard for secure and reliable forms of identification issued by the federal government to its employees and contractors" [@hspd-12]. HSPD-12 did not specify how. It pointed at the National Institute of Standards and Technology and said "make it so."

NIST's response was FIPS 201, the Personal Identity Verification standard, first published in February 2005. The current revision, FIPS 201-3, was published in January 2022, superseding FIPS 201-2 from 2013 [@fips-201-3] [@fips-201-3-pdf]. Where FIPS 201 specifies the credential -- what a PIV card is, biometrically, biographically, visually -- the companion NIST SP 800-73 specifies the card-edge interface: file system, data objects, APDU command set [@sp-800-73-4-upd1].

The US federal smart card identity credential defined by FIPS 201 and its companion NIST Special Publications. FIPS 201 defines what a PIV credential is; NIST SP 800-73 defines the card-edge interface (file structure, data objects, APDU command set) so any host can talk to any PIV-compliant card; SP 800-78 covers cryptographic algorithms; SP 800-76 covers biometrics; SP 800-79 covers card issuer accreditation.

The numbers are striking. NIST reports "close to five million PIV Cards today provide multifactor authentication to federal IT resources and facilities" [@nist-piv-home]. The largest single cohort is the DoD Common Access Card (CAC), which by 2002 numbers had reached more than one million card readers across more than 1,000 issuance sites in more than 25 countries [@wp-cac].

Microsoft, watching from Redmond, faced two choices: negotiate a separate minidriver for the GSC-IS card-edge applet some federal agencies were using, or ship an inbox class minidriver that auto-discovered PIV-compliant cards out of the box -- and for completeness, supported a Microsoft-defined alternative called the Generic Identity Device Specification.

GIDS, Microsoft's complementary card-edge profile, shipped v1.0 in April 2010 and v2.0 in October 2012 [@gids-spec]. It was a profile for card vendors and TPM integrators who wanted a Microsoft-blessed alternative to PIV, and it would become important to Windows 8's Virtual Smart Card design.

The Generic Identity Device Specification, a Microsoft-published smart card profile for identity credentials. GIDS v1.0 published April 2010; v2.0 published October 2012. GIDS coexists with PIV at the inbox minidriver layer: Windows' inbox `msclmd.dll` recognises both, allowing zero-install integration for any card that implements either applet.

The inbox driver shipped in Windows 7 SP1 in February 2011. Microsoft Learn is direct: "Windows provides an inbox generic class minidriver that supports Personal Identity Verification (PIV)-compliant smart cards and cards that implement the Generic Identity Device Specification (GIDS) card edge" [@inbox-minidriver]. The auto-discovery sequence is sequential: msclmd.dll issues a SELECT for the PIV AID; if the card returns 90 00, Windows treats it as PIV. If the PIV select fails, the driver tries the GIDS AID; if that succeeds, Windows treats the card as GIDS. If both selects return a "neither-AID-exists" status, Windows still proceeds as if the card were GIDS, and the inbox driver continues to handle it. Only an unknown SELECT error makes the inbox driver decline and Windows fall back to a vendor minidriver [@inbox-minidriver]. The effect: any PIV-compliant card (CAC, Yubico YubiKey 5 [@yubico-piv], any FIPS 201-compliant federal credential) worked on a stock Windows 7 SP1 install with zero additional software.

Before Windows 7 SP1, deploying a CAC to a workstation required an out-of-band CSP install: a vendor disk, an enterprise distribution share, or a manual download. Some classified networks could not reach the vendor distribution channels at all. The inbox `msclmd.dll` removed that friction. A workstation that had never been online could authenticate a CAC user on first boot, provided it was joined to a domain whose KDC chain it could reach for PKINIT validation. Many DoD operational deployments lived inside the airgap, and many of them only became deployable at scale once the inbox minidriver had landed.

With the card-edge problem solved and the install problem closed, what remained was the protocol Windows logon would use. That protocol is PKINIT.

Public Key Cryptography for Initial Authentication in Kerberos. Specified by [RFC 4556](#) [@rfc-4556] and profiled for Windows by `[MS-PKCA]` [@ms-pkca]. PKINIT lets a Kerberos client present an X.509 certificate, and prove possession of the private key, as pre-authentication for the Authentication Service Request (AS-REQ), instead of a password-derived shared secret. The Windows AS Exchange remains otherwise unchanged: the client receives a TGT encrypted with a session key established under the public-key exchange. The PKINIT structure that carries the client's proof of possession. It contains a `PKAuthenticator` (cusec, ctime, nonce, paChecksum) and Diffie-Hellman parameters. The client signs the `AuthPack` with the private key corresponding to its certificate, then embeds the signed structure in the `PA-PK-AS-REQ` pre-authentication data of the Kerberos AS-REQ. The granularity matters: the signature covers the `AuthPack`, not the AS-REQ as a whole.

In a Windows smart card logon the path from PIN to TGT runs through eight named components. Walk it once and the rest of the article becomes legible.

sequenceDiagram participant U as User at lock screen participant CP as Credential Provider participant LSA as LSASS Kerberos client participant KSP as Microsoft Smart Card KSP participant MD as Minidriver participant CARD as Smart card participant KDC as Domain Controller KDC

U->>CP: Insert card, type PIN
CP->>LSA: Logon attempt with PIV credential
LSA->>KSP: NCryptSignHash on AuthPack hash
KSP->>MD: Card-specific sign request
MD->>CARD: VERIFY PIN, then SIGN APDU
CARD-->>MD: Signed AuthPack bytes, SW=9000
MD-->>KSP: Signed AuthPack
KSP-->>LSA: Signed AuthPack
LSA->>KDC: AS-REQ with PA-PK-AS-REQ pre-auth
KDC->>KDC: Verify signature, cert chain, freshness
KDC-->>LSA: AS-REP with TGT
LSA-->>CP: Logon success, session keys cached
CP-->>U: Desktop

Notice what the card sees and what it does not. It sees a hash to sign and a PIN to verify. It does not see "I am authenticating to KDC DC01.contoso.local for user jdoe." A PIV card is a signing oracle. The relying party identity, the freshness, the replay window, the binding of signature to context: all of that lives in the protocol above the card, not in the card itself. We come back to this in section 8.

Key idea: The cryptographic primitive at the centre of the smart card metaphor -- a non-exportable asymmetric key, bound to a tamper-resistant element, gated by a local gesture -- is the longest-lived object in this lineage. The interface around the primitive (PC/SC, CryptoAPI, CNG, NCrypt-direct, WebAuthn) is what changes every generation.

By 2013 the cryptographic story was excellent. PKINIT was a clean Kerberos AS exchange. The card protected the key. The KDC issued a TGT. Then, in a few months in 2014, one researcher in Tel Aviv showed that the protection ended at the very moment of signing.

5. KB2871997 and the NTLM Secondary Credential

Tal Be'ery, then Vice President of Research at Aorato, sat down in early 2014 with a question that should have had a boring answer. If an Active Directory account is flagged "smart card required for interactive logon," and the user has no password, is the account immune to pass-the-hash?

The answer is no. Aorato's original disclosure post is offline; Microsoft acquired Aorato in November 2014 and the research became the foundation of what is now Microsoft Defender for Identity. The period-accurate operator analysis that survives in public is Sander Berkouwer's July 15, 2014 dirteam.com writeup, cited here in lieu of the dead original [@dirteam-aorato].

The attack is built from three off-the-shelf parts. The first is the NTLM secondary credential we met in section 1: every smart-card-only account in Active Directory has a usable NT hash on the KDC, maintained for legacy compatibility. The second is the harvesting tool. Benjamin Delpy's mimikatz had reached its 2.0-alpha milestone in April 2014; the README documents sekurlsa::logonpasswords extracting NT hashes from LSASS, plus sekurlsa::pth and golden-ticket forgery for replay [@mimikatz-gh]. The third is the cryptographic identity that makes hashes Kerberos-relevant. RFC 4757 section 2 establishes that the RC4-HMAC long-term key in Kerberos is the NT hash itself, "for compatibility reasons" [@rfc-4757] [@dirteam-aorato].

Compose those three parts. An attacker with administrative footing on any machine the user has touched runs sekurlsa::logonpasswords against LSASS and gets the NT hash. By RFC 4757 the hash is a usable Kerberos RC4-HMAC pre-authentication key for the user; pre-auth is a function of the long-term key, so the attacker can request a TGT. Or they replay the hash directly via SMB. The card sits, intact, in the user's reader. Nothing about it has changed.

The smart card's tamper-resistance was real. But the cryptographic guarantee terminated at the act of signing -- not at the authentication outcome.

This is the article's central inversion. The card was right. The system was wrong. The card protected the key; the OS minted credentials around that key the card could not police; the protection terminated at the signing operation; the identity did not.

Given an interactive shell as Local System or a debug-privileged user, the harvest is two commands:

privilege::debug
sekurlsa::logonpasswords

sekurlsa::logonpasswords walks LSASS sessions and prints any cached NT hashes, including the rotated secondary credential for smart-card-required users. The pass-the-hash replay is one more:

sekurlsa::pth /user:JaneDoe /domain:CONTOSO /ntlm:a1b2c3...

This launches a process whose Kerberos ticket cache accepts the supplied NT hash as the RC4-HMAC pre-auth key for the named principal. Any tool spawned from that process can request service tickets for the user. The smart card need not be in any reader on any machine on the network. KB 2871997 and the Pass-the-Hash mitigations (KB 2984972, 2984976, 2984981) addressed this defence-in-depth; NTLM removal addresses it structurally.

Microsoft's response shipped on May 13, 2014 as Security Advisory KB 2871997, "Update to improve credentials protection and management." It is mostly a registry change and a recommended Group Policy: set HKLM\SYSTEM\CurrentControlSet\Control\Lsa\TokenLeakDetectDelaySecs to 30 seconds [@kb-2871997]. The June 2014 MSRC blog added more context, especially around a new security group called Protected Users [@msrc-kb-2871997].

Protected Users, added to Windows Server 2012 R2 domains and Windows 8.1 clients, blocks NTLM, blocks DES and RC4 in Kerberos pre-authentication, blocks both forms of delegation, and prevents offline sign-in caching [@protected-users]. Add a privileged account to Protected Users and you force it off the RC4-HMAC code path. An attacker who steals the NT hash no longer has a usable Kerberos pre-auth key, even though the hash itself is still recoverable.

Microsoft's later response was Credential Guard, which isolates credential material in a Virtualization-Based Security (VBS) container called LSAISO, separated from LSASS by a Hyper-V trust boundary. On Windows 11 22H2 and Server 2025, Credential Guard is enabled by default on domain-joined, non-DC systems that meet hardware requirements, protecting NTLM hashes, Kerberos TGTs, and stored domain credentials [@credential-guard].

Note: The KB 2871997 family (TokenLeakDetectDelaySecs, Protected Users, LSA Protection / RunAsPPL, Credential Guard later) is defence-in-depth. It makes hash theft harder, the harvested hash less universally useful, and lateral movement more visible. None of those measures removes the secondary NT hash itself. The structural fix is to remove NTLM. That work began in earnest with the 2023 "evolution of Windows authentication" announcement and reached its first hard milestone with the NTLMv1 removal in Windows 11 24H2 and Windows Server 2025 [@evolution-windows-auth] [@ntlmv1-removal].

Two sentences look identical but mean very different things: "the card protected the key" and "the system protected the user." The first is a statement about a piece of hardware and the cryptographic discipline of its operation; it was true in 1996, true in 2014, true today. The second is a statement about the authentication subsystem that uses the card. In 2014 it was false, and the falsehood had been present for fourteen years, hidden under the assumption that strong cryptography at the card edge guaranteed a corresponding strength of identity assertion. The 2014 disclosure was a forcing function for distinguishing the two. Every subsequent design (VSC, WHfB, FIDO2) can be evaluated by where it draws that line.

If the card alone could not deliver the protection, perhaps the right move was to throw away the physical card entirely. Microsoft had shipped exactly that experiment eighteen months earlier.

6. Virtual Smart Cards in Windows 8

On October 26, 2012, Microsoft shipped Windows 8. Buried in the new features, alongside the Start screen redesign and the Hyper-V client, was a command-line tool named tpmvscmgr.exe that created a smart card without any plastic. The tool is still there. Open an elevated prompt on a current Windows installation and type tpmvscmgr create /name vsc1 /AdminKey DEFAULT /PIN PROMPT, and the system manufactures a new entry under ROOT\SMARTCARDREADER\ that any PC/SC client sees as a freshly inserted card [@tpmvscmgr].

The pitch is mechanical. Every Windows 8+ device with a Trusted Platform Module already has the cryptographic substrate of a smart card on the motherboard: a tamper-resistant chip, a non-exportable key store, dictionary-attack resistance, an isolated execution environment for crypto. Why not implement the smart card abstraction in software, with the TPM as the backing chip [@vsc-overview] [@vsc-understanding]?

The Microsoft Learn "Virtual Smart Card Overview" makes the framing crisp. The three core properties of a smart card -- non-exportability, isolated cryptography, anti-hammering -- map directly onto TPM capabilities. Non-exportability becomes TPM key wrapping. Isolated cryptography becomes signing inside the TPM. Anti-hammering becomes the TPM's dictionary-attack counter [@vsc-overview] [@vsc-understanding].

A TPM-backed software smart card introduced in Windows 8 (October 2012). A VSC exposes the same PC/SC card edge as a physical card -- the same WinSCard API, the same Base CSP, the same Microsoft Smart Card KSP, the same minidriver model. The chip backing the card is the TPM, soldered to the motherboard, rather than a removable IC on a plastic substrate. From the perspective of any application using the WinSCard API, a VSC is indistinguishable from a permanently-inserted physical smart card.

Note: Windows 8 shipped Virtual Smart Cards in October 2012. The Trusted Computing Group did not ratify TPM 2.0 until 2014. VSCs are therefore a TPM-binding policy technology, not a TPM-2.0-bound technology; Microsoft Learn lists TPM 1.2 as the documented minimum. TPM 2.0 works and is the practical choice on modern Windows 11 installations, but the architecture predates it [@vsc-overview] [@vsc-understanding].

The beauty of the design is that nothing above the chip changed. Applications still call CryptSignHash or NCryptSignHash. The Base CSP and Smart Card KSP still route through a minidriver. The minidriver still sends APDUs through WinSCard to a reader. The only differences: the reader is a software pseudo-device named Microsoft Virtual Smart Card, and the card behind it is the TPM dressed up as an ISO 7816-4 applet.

flowchart LR subgraph Physical [Physical smart card] A1[Application] --> B1[CSP/KSP] B1 --> C1[Minidriver] C1 --> D1[WinSCard] D1 --> E1[USB reader] E1 --> F1[Plastic card IC] end subgraph Virtual [Virtual smart card] A2[Application] --> B2[CSP/KSP] B2 --> C2[Minidriver] C2 --> D2[WinSCard] D2 --> E2[Virtual reader] E2 --> F2[TPM on motherboard] end

The cryptographic substrate underneath the abstraction is the TPM, and the binding policy is per-device. The Microsoft Learn "Understanding and Evaluating Virtual Smart Cards" article is precise: "Non-exportability: Because all private information on the virtual smart card is encrypted by using the TPM on the host computer, it can't be used on a different computer with a different TPM" [@vsc-understanding]. The property that makes a VSC tamper-resistant also makes it un-migratable. A TPM clear destroys the keys irrecoverably. We return to that in section 8.

The canonical primary source for the architecture is the "Understanding and Evaluating Virtual Smart Cards" whitepaper on the Microsoft Download Center. The download page reports Version: July 2014, Date Published: 7/15/2024 [@vsc-whitepaper]. The 2014 revision is canonical.

The card was a metaphor. Microsoft kept the byte-for-byte PC/SC interface and put the TPM behind it.

A worked provisioning example brings the design to ground. The tpmvscmgr create command takes four arguments that matter for security policy: the administrative key (/AdminKey {DEFAULT | PROMPT | RANDOM}), the PIN policy (/PIN PROMPT or /PIN DEFAULT), the attestation mode (/attestation {AIK_AND_CERT | AIK_ONLY}), and the card's reader instance, surfaced under ROOT\SMARTCARDREADER\000n in Device Manager [@tpmvscmgr].

{` function provisionVSC(opts) { const adminKeyMap = { DEFAULT: '0102030405060708' + '0102030405060708' + '0102030405060708', PROMPT: '[user-supplied 48 hex chars]', RANDOM: '[random 24-byte key the admin must record]', }; const attestationNote = { AIK_ONLY: 'Identity-binding only; no platform certificate chain stored on the card.', AIK_AND_CERT: 'Full AIK-and-EK-cert chain stored; supports federated re-enrolment.', NONE: 'No attestation; the card is identity-only.', }; return { cardName: opts.name, adminKey: adminKeyMap[opts.adminKey] || 'invalid', pin: opts.pin === 'PROMPT' ? '[user-typed PIN, min 8 chars, alphanumeric+special allowed]' : '12345678', attestation: attestationNote[opts.attestation || 'NONE'], advice: opts.adminKey === 'DEFAULT' ? 'WARN: default admin key is documented; treat as factory-default.' : 'OK: admin key not factory-default.', }; }

console.log(provisionVSC({ name: 'vsc-jdoe', adminKey: 'RANDOM', pin: 'PROMPT', attestation: 'AIK_AND_CERT', })); `}

The default administrative key 010203040506070801020304050607080102030405060708 is documented in the public tpmvscmgr page [@tpmvscmgr]. Any VSC provisioned with /AdminKey DEFAULT should be treated as factory-default; in production, supply (PROMPT) or randomise (RANDOM) the admin key and store it separately.

The provisioning chain has four hard-to-script steps: run tpmvscmgr create as administrator; request and install an authentication certificate from a PKI the domain trusts (typically Microsoft Certificate Services with an enterprise CA and a smart card auto-enrolment template); set the user PIN; log the user out and back in. Each step is a place an enterprise rollout can stall.

Key idea: Microsoft kept the PC/SC card edge byte-for-byte and put the TPM behind it. The Virtual Smart Card was, technically, exactly that: a software smart card whose chip happened to be soldered to the board. The cryptographic primitive at the centre did not change; only the form factor of the chip carrying it did.

VSCs solved the physical-distribution problem. They did not solve the user-experience problem -- and they introduced a new one no Windows feature had ever produced quite this way: a credential a hardware reset could permanently destroy.

7. WHfB, FIDO2, and the Card Edge That Got Discarded

On March 17, 2015, Joe Belfiore announced Windows Hello on the Windows Experience Blog: "I'd like to introduce you to Windows Hello -- biometric authentication which can provide instant access to your Windows 10 devices" [@windows-hello-blog]. The consumer pitch was face and fingerprint. The mechanism underneath, in the enterprise variant called Windows Hello for Business (WHfB), was the same TPM-bound asymmetric key the Virtual Smart Card had used -- except there was no virtual reader, no virtual minidriver, and no virtual APDU.

WHfB talks to the TPM directly through the Microsoft Platform Crypto Provider, a CNG Key Storage Provider that calls into the TPM rather than into a smart card minidriver [@whfb-overview] [@whfb-how-it-works]. The PC/SC card edge had been removed from the path entirely. The cryptographic primitive (non-exportable TPM-bound asymmetric key, gated by a local gesture, used to sign an authentication request) survived; the interface around the primitive simplified.

Microsoft Learn describes WHfB in five phases: device registration, provisioning, key synchronisation, certificate enrolment (cert-trust only), authentication. The public key is registered with the identity provider and mapped to the user account; the private key never leaves the device [@whfb-how-it-works]. WHfB ships in three deployment models -- cloud-only, hybrid, on-premises -- and two trust types: key-trust and cert-trust [@whfb-deploy].

Key-trust is cloud-first. The TPM-bound public key is registered with Microsoft Entra ID; authentication is a public-key proof of possession to Entra, which mints whatever downstream artifacts a federated service needs (PRT, refresh token, optional Kerberos TGT via the cloud Kerberos service). No X.509 certificate sits in the user's path. Cert-trust adds an X.509 wrapper for downstream services that require one: an enterprise PKI issues a smart-card-logon-style certificate bound to the TPM key, and the WHfB authentication produces a Kerberos PKINIT exchange against an on-premises DC, just as a physical smart card would. The certificate is the adapter to brownfield infrastructure that still expects a smart-card-shaped credential [@whfb-deploy].

So far the lineage has been Windows-specific. FIDO2 is not. WebAuthn 2 is a W3C Recommendation; CTAP 2.1 is a FIDO Alliance specification [@webauthn-2] [@ctap-2-1]. Together they specify a cross-vendor protocol for public-key authentication to web relying parties, with one load-bearing property the smart card lineage never had: origin binding.

The property that a WebAuthn credential is scoped to a specific relying party identifier (the RP ID, typically a domain name) and the authenticator will refuse to sign an assertion for any other RP ID. The W3C WebAuthn 2 specification states: "the public key credential can only be accessed by origins belonging to that Relying Party. This scoping is enforced jointly by conforming User Agents and authenticators" [@webauthn-2]. A PIV smart card has no equivalent property; it will sign whatever the host hands it.

Origin binding is the structural fix to a class of relay attacks. A PIV smart card cannot tell whether it is signing a Kerberos AuthPack for the legitimate KDC or a maliciously crafted blob for an attacker-controlled relay; the card has no notion of "what is this signature for." A WebAuthn authenticator does. It hashes the RP ID into the signed assertion, the relying party verifies the RP ID matches its own origin, and a phishing site cannot trick the authenticator into producing a signature it will accept.

Microsoft Entra ID supports FIDO2 in two flavours. Device-bound passkeys live on a FIDO2 security key (a YubiKey 5 [@yubico-piv]) or in Microsoft Authenticator and cannot be extracted. Synced passkeys are credentials a platform synchronises across the user's devices through a cloud passkey provider [@entra-passkeys-howto] [@entra-passwordless]. The trade-off is sharp: device-bound passkeys support attestation (the relying party can verify authenticator hardware at registration); synced passkeys do not.

For workforce identity, Microsoft's passwordless strategy describes a four-step journey: deploy a password-replacement option, reduce user-visible password surface, transition to passwordless, eliminate passwords [@passwordless-strategy]. WHfB and FIDO2 are the two recommended replacements.

What about smart cards? The Microsoft Learn Virtual Smart Card Overview now opens with a Warning box that reads, in full: "Windows Hello for Business and FIDO2 security keys are modern, two-factor authentication methods for Windows. Customers using virtual smart cards are encouraged to move to Windows Hello for Business or FIDO2. For new Windows installations, we recommend Windows Hello for Business or FIDO2 security keys" [@vsc-overview]. The deprecation signal could not be more explicit. Physical PIV and CAC cards are not deprecated -- the federal government is not switching off PIV -- but the structural recommendation for greenfield is now WHfB or FIDO2.

Why did Virtual Smart Cards not survive into the WHfB era? Three reasons.

The first is provisioning UX. A VSC requires four steps (tpmvscmgr create, certificate enrolment, PIN set, logon round-trip) where WHfB requires one (a setup wizard the user runs at first sign-in). Each VSC step can fail in idiosyncratic ways: the enterprise CA template not configured for VSCs, the user's certificate request rejected, the PIN policy mismatched between the GPO and the card. Even when every step succeeds, the user sees a "smart card" UI -- card reader prompts, PIN entries -- that does not match the device they are holding.

The second is recovery. A TPM clear destroys VSC keys irrecoverably. Microsoft Learn states the constraint plainly [@vsc-understanding]: "all private information on the virtual smart card is encrypted by using the TPM on the host computer." Recovery would have to be re-enrolment under a federated attestation chain. The AIK-and-EK-cert attestation mode in tpmvscmgr exists [@tpmvscmgr], but it never grew into a productised re-enrolment story; the practical answer was always "issue a new card."

The third is the multi-device world. VSCs bind one credential to one device. By 2017 most enterprise users had at least two devices: a laptop and a phone. By 2022 most had three. A credential metaphor borrowed from the era of one workstation per user could not stretch.

Where do physical smart cards still belong in 2026? Three places. First, federal PIV / DoD CAC: the badge IS the credential, the issuance lifecycle is owned by an external organisation, and the cards have to work cross-platform and cross-application in a way a Windows-only credential cannot. Second, high-assurance regulated industries (banking, healthcare imaging, court systems) where existing PKI investment and signed-document workflows make the card the institutional artifact, not just an authentication factor. Third, "smart card removal locks workstation" cases (operating-room PCs, trading-floor terminals) where the physical act of pulling the card out of the reader is the security control.

Where does Entra Certificate-Based Authentication fit? Entra CBA is the cloud-native PIV/CAC path. A federal user logs into Entra ID directly with their PIV/CAC card, bypassing the on-premises ADFS infrastructure that was the traditional cloud-bridge for federal organisations. Entra CBA preserves the PIV credential while replacing the on-premises STS, and is the practical answer to "we have to keep PIV, but also we are migrating to cloud."

The table below condenses the comparison.

Method	Where the key lives	Origin binding	NTLM secondary	Provisioning steps	Multi-device	Phishing resistance	Recovery	Suitable for new deployments
Physical PIV / CAC	Removable IC	No (relay possible)	Yes (until NTLM removed)	High (PKI + issuance)	Yes (cross-device by physical movement)	Conditional	Re-issue card	Federal/DoD only
TPM Virtual Smart Card	On-device TPM	No	Yes (until NTLM removed)	High (4-step)	No (bound to one TPM)	Conditional	Re-enrol	Not recommended (deprecation Warning)
WHfB key-trust	On-device TPM	Limited (RP=Entra)	Reduced (cloud Kerberos)	Low (in-OS wizard)	Per-device enrolment	Yes (relative)	Re-enrol via device registration	Yes (cloud/hybrid)
WHfB cert-trust	On-device TPM	Limited (RP=AD)	Yes (until NTLM removed)	Medium (PKI required)	Per-device enrolment	Conditional	Re-enrol; CA-issued cert	Yes (brownfield PKI)
FIDO2 security key	External authenticator (e.g., YubiKey)	Yes (WebAuthn RP ID)	Not applicable (no Kerberos)	Low	Yes (key is portable)	Yes (origin-bound)	Spare key or backup credential	Yes (high-assurance)
Entra device-bound passkey	TPM or external authenticator	Yes (WebAuthn RP ID)	Not applicable	Low	Per-device	Yes	Re-enrol	Yes
Entra synced passkey	Cloud-synced (no attestation)	Yes (WebAuthn RP ID)	Not applicable	Low	Yes (cloud-synced)	Yes (origin-bound)	Cloud provider recovery	Yes (consumer, low-friction)

The architecture is now mature. But the lineage has a hard ceiling no architecture can cross: a signing oracle cannot tell you what it signed for.

8. What a Card Edge Can and Cannot Mediate

Set aside provisioning UX. Set aside NTLM legacy. Set aside everything Windows-specific. What are the structural limits any card-edge-or-equivalent design must accept? Six, by my count, and each one is anchored to a primary source.

The card edge is a signing oracle, not a transcript witness. A PIV card receives a hash and returns a signature. It does not know what protocol the signature is for, what relying party requested it, or whether the same hash has been requested two minutes ago by an attacker on a wireless network. PKINIT's vulnerability to relay was open from 2006 (RFC 4556) until 2017 (RFC 8070, which added a freshness token to the AS exchange) [@rfc-4556] [@rfc-8070]. The fix had to live in the protocol, not in the card. The card cannot prove what it signed for.

The card has no notion of relying-party identity. This is the structural defect WebAuthn fixes. A WebAuthn authenticator includes the RP ID in the signed assertion and refuses to release a signature for the wrong RP. The W3C specification states this property explicitly [@webauthn-2]. A PIV card does not. To add an equivalent property to the smart card lineage would have meant changing the SP 800-73 command set; it was easier to throw the PC/SC card edge away and start over with FIDO2.

Cryptographic protection at the card edge cannot reach downstream OS-minted credentials. This is the 2014 NTLM-secondary lesson at its most general. The card protects a key; the OS may mint credentials around that key the card cannot police. Microsoft KB 2871997 closed the leak with defence-in-depth retrofits (TokenLeakDetectDelaySecs, Protected Users, RunAsPPL, eventually Credential Guard) [@kb-2871997] [@msrc-kb-2871997] [@protected-users] [@credential-guard]; the structural close had to wait for the 2024-2026 NTLM removal programme [@ntlmv1-removal]. Any future credential the OS mints around the card's key is, by construction, outside the card's authority.

Revocation must be reachable, and the card cannot tell you when it is not. A PIV card's certificate is a relying-party-side concept; revocation status is a property of the issuing PKI, not the card. CRL distribution points and OCSP responders are the relying party's problem to reach. When a domain controller cannot reach the CRL, the policy choice is to fail open or fail closed; either policy carries risk. The [MS-PKCA] Windows profile specifies server-side certificate-validation processing -- including revocation checking -- as a property of the KDC, not the credential the card presented [@ms-pkca]. The card signed correctly either way.

Certificate-to-user mapping must be strongly bound, and again the card cannot help. When a domain controller receives a PKINIT request, it must map the presented certificate to an Active Directory account. The Certifried CVE class disclosed in May 2022 (CVE-2022-26923, CVE-2022-26931, CVE-2022-34691) showed that weak mapping -- by Subject Alternative Name UPN without a strong identifier bound into the certificate -- lets an attacker who can enrol against an over-permissive template impersonate any account [@kb-5014754]. The card signed exactly what it was asked to sign; the structural defect was at the KDC's mapping step. Microsoft KB 5014754 closed the mapping defect by requiring strong certificate-to-account binding; we return to its multi-year deployment timeline in §9 [@kb-5014754].

Hardware-bound keys cannot be teleported -- and this is both feature and limit. Non-exportability is the central promise of the entire lineage. It is also the bound. A TPM clear or a hardware replacement destroys the key. The recovery story has to be re-enrolment, not restore. Microsoft Learn states the constraint for VSCs and the same constraint applies, structurally, to every TPM-bound or external-authenticator credential -- including FIDO2 device-bound passkeys [@vsc-understanding]. Synced passkeys recover this property by giving up attestation; you cannot have both.

Non-exportability is the property. It is also the bound.

Key idea: An ideal card-lineage authenticator refuses to sign without RP-issued freshness, refuses to release a signature outside its RP scope, leaves no downstream-cacheable credential material, attests to its hardware at registration, and supports identity portability via re-enrolment-under-attestation rather than key portability. No shipping authenticator delivers all five of these authenticator-side properties in a workforce-grade product today; the two RP-side limits (revocation reachability, certificate-to-user mapping) are necessarily closed at the relying party, not the authenticator. The combination is the work of the next decade.

Limit	What it forbids	Primary source
Signing oracle, not transcript witness	Card cannot prove signature was for the intended protocol context	RFC 4556 / RFC 8070 [@rfc-4556] [@rfc-8070]
No RP identity	Card cannot refuse a relay; relay window must close in protocol	WebAuthn 2 [@webauthn-2]
No reach to downstream OS credentials	Card protects key, not identity around the key	KB 2871997, MSRC [@kb-2871997] [@msrc-kb-2871997]
Revocation is not self-asserting	Card cannot vouch for its own validity; KDC must reach the PKI	[MS-PKCA] [@ms-pkca]
Strong cert-to-user mapping is not card-asserted	Relying party must bind certificate to AD account; card has no view of the mapping	KB 5014754 [@kb-5014754]
Non-exportability bounds portability	Key dies with the chip; recovery must be re-enrolment	VSC Understanding [@vsc-understanding]

Some limits are being closed. The signing-oracle limit is mitigated by RFC 8070 freshness tokens; the RP-identity limit is closed for new credentials by WebAuthn; the downstream-credential limit is being closed by NTLM removal; the strong-mapping limit was closed by KB 5014754 on shipping AD infrastructure between February and September 2025. Others are inherent: a non-exportable key is, by definition, not portable. The next decade of smart-card-lineage work is being shaped by which is which.

9. Open Problems for the Next Decade

Five problems are still open in 2026. Each has a candidate fix in flight; none has shipped to general availability for the workforce case.

PIV / CAC in a post-NTLM Windows estate. NTLMv1 was removed from Windows 11 24H2 and Windows Server 2025 [@ntlmv1-removal]; NTLMv2 is on the deprecation track [@deprecated-features]. What does "smart card required for interactive logon" mean in a forest with no NTLMv1 secondary credential? The historical answer was "the KDC mints an NT hash so legacy services keep working." The new answer must be either "no NT hash; legacy services break" or "an NT hash for NTLMv2 only, restricted by SCRIL rotation and Protected Users membership." Microsoft has not yet published a complete blueprint for what federal PIV deployments look like after NTLMv2 also retires. Credential Guard's role in the transition is to make any residual secondary credential harder to harvest [@credential-guard] [@protected-users].

Three concrete questions a federal IT shop should be asking. First: does our forest have any domain controllers still serving NTLMv1 to legacy clients? After 24H2 / Server 2025, the answer should be no [@ntlmv1-removal]. Second: are our privileged accounts in Protected Users? The group blocks NTLM, DES, RC4 pre-auth, and constrained or unconstrained delegation [@protected-users]; for a smart-card-required account, membership effectively removes the RC4-HMAC-via-NTLM-hash attack surface even before NTLMv2 retirement. Third: is Credential Guard enabled on every member system? On Windows 11 22H2 and Server 2025, it is on by default for hardware-eligible domain-joined non-DC systems [@credential-guard]. These three measures are the practical answer to "what does smart-card-required mean today." The full structural answer waits on NTLMv2 retirement.

The recovery primitive that never shipped. TPM-clear or device replacement destroys TPM-bound keys; this is the cost of non-exportability. AIK-and-EK-cert attestation in tpmvscmgr could in principle support federated re-enrolment with strong proof of platform identity [@tpmvscmgr], and the Entra passkey enrolment flow supports attestation-required policies [@entra-passkeys-howto], but neither path matured into a "your VSC died; here is how the help desk restores you in fifteen seconds" story. Synced passkeys recover this property by giving up attestation. Workforce-grade attestation and easy recovery, together, is still not shipping.

The certificate-based-authentication hardening lag. Microsoft's KB 5014754 hardens certificate-based authentication on Windows domain controllers against the Certifried CVE class (CVE-2022-26923, CVE-2022-26931, CVE-2022-34691) by requiring strong certificate-to-user mapping at the KDC. The CVE class was disclosed on May 10, 2022. The mitigation moved DCs to Enforcement mode by default on February 11, 2025, with a fallback to Compatibility mode still available; the override was finally retired on September 9, 2025 [@kb-5014754]. The KB's own change log records several intermediate slips of the Full-Enforcement target (the original commitment was a 2023 milestone, slipping to February 2025 and then to September 2025) [@kb-5014754]. That is roughly three years from CVE disclosure to default Enforcement and a further seven months to end-of-override on shipping infrastructure -- and the gap from the first published Full-Enforcement target to the actual end-of-override stretches the slip to a multi-year story in its own right. The lesson is sobering: in a brownfield estate, the time from "CVE disclosed" to "hardening fully enforced on every domain controller" is measured in years, not weeks. Separately, RFC 8070 PKINIT freshness tokens (February 2017) are a different hardening programme [@rfc-8070]; Windows has not deployed RFC 8070 freshness as the default in the broad estate, and the article's RunnableCode in §10 illustrates the freshness exchange rather than documenting deployed Windows behaviour. Any protocol-level fix to the smart-card lineage in 2026 will, on the KB 5014754 evidence, take three to four years to land -- and longer if the standards process itself slips, as RFC 8070's still-undeployed status (over nine years since publication) suggests.

Cross-platform card-edge longevity. OpenSC and pcsc-lite still implement NIST SP 800-73 on macOS and Linux; the cross-platform PIV story works for basic logon. But the modern features Windows keeps adding -- attestation chains, device-bound credential extensions, integration with the Entra passkey APIs -- lag on the open-source side. Whether PC/SC outlives the platforms that built it is genuinely uncertain. Some federal organisations will keep PIV alive cross-platform as policy; many private-sector deployments will quietly move off.

Post-quantum signature algorithms on smart cards. PIV's current baseline is RSA-2048 and ECDSA P-256 -- not post-quantum resistant. NIST's post-quantum standardisation selected ML-DSA (Module Lattice DSA, formerly Dilithium) and SLH-DSA (Stateless Hash-Based DSA, formerly SPHINCS+); both have key and signature sizes substantially larger than RSA-2048 or ECDSA P-256, and both will stress the storage and bandwidth budgets of a typical PIV card. SP 800-73-4 has no slots for post-quantum keys today [@sp-800-73-4-upd1] [@fips-201-3]. A future revision will have to accommodate them, and the existing population of $\approx$ five million PIV cards [@nist-piv-home] will not all be PQ-capable at once. The transition runs on a card-issuance cycle: roughly $T_{\text{transition}} \approx T_{\text{issuance}} + T_{\text{rollout}}$, each term in the multi-year range.

Architecture is a question about which problems your design cannot solve. The next section is for the architect who has to choose right now, with all five problems still open.

10. Choosing Between PIV, VSC, WHfB, and FIDO2 in 2026

Four operator-grade callouts. Pick the one that matches your context.

Note: Stay on PIV / CAC for the foreseeable future. FIPS 201-3 is the current standard and SP 800-73 the current card-edge interface; policy mandates are not changing on a tactical timeline [@fips-201-3] [@nist-piv-home]. Add Entra Certificate-Based Authentication for cloud workloads so the same PIV card authenticates to Microsoft 365 and Azure resources without going through on-premises ADFS. For the three operational controls -- Credential Guard, Protected Users membership for privileged accounts, and NTLMv1-removal status -- see the federal-IT checklist in the §9 Aside. Do not rely on the smart card alone to defeat NTLM-secondary-credential abuse until NTLM removal has reached your environment.

Note: Pick WHfB key-trust if you are cloud-first or hybrid, cert-trust if you have an existing on-premises PKI you need to honour [@whfb-deploy] [@whfb-how-it-works]. Add FIDO2 security keys for the populations that need cross-device portability or strict phishing resistance: contractors, executives, IT administrators, anyone whose credential theft would be catastrophic [@webauthn-2] [@passwordless-strategy]. Do not pick Virtual Smart Cards for new deployments; the Microsoft Learn VSC Overview deprecation Warning quoted verbatim in §7 applies [@vsc-overview].

Note: Continue to operate it but plan migration to WHfB. Audit your recovery and re-enrolment process: a TPM clear destroys VSC keys irrecoverably, so any disaster-recovery plan that assumes you can move a credential between devices is wrong [@vsc-understanding]. Do not assume your VSC deployment is "supported" the way it was in 2014; the deprecation Warning quoted in §7 applies here [@vsc-overview]. The cleanest exit path is to enrol the same users into WHfB cert-trust against your existing PKI, then retire the VSC layer once the WHfB credential is operational.

Note: FIDO2 security keys with attested device-bound credentials [@webauthn-2] [@ctap-2-1], paired with Microsoft Entra ID passkeys. Use attestation-required profiles for high-assurance populations (so the relying party can verify the authenticator hardware) and attestation-optional profiles for less sensitive populations who benefit from synced-passkey recovery [@entra-passkeys-howto] [@entra-passwordless]. The trade-off remains: device-bound passkeys are attestable but not portable; synced passkeys are portable but not attestable. Match the profile to the population, not the population to the profile.

For the architect who wants to see how PKINIT freshness enforcement would work if the RFC 8070 extension were enforced, the JavaScript below simulates the nonce check. The KDC issues a freshness token; the client includes it in the signed PKAuthenticator; the KDC verifies that the token in the signed structure matches the one it issued. This is illustrative protocol behaviour, not the Windows default today.

{` function kdcIssueFreshness() { const token = Math.random().toString(16).slice(2, 18); return { token, issuedAt: Date.now() }; }

const issued = kdcIssueFreshness(); const cardSign = (msg) => 'sig(' + msg.length + ')'; const signed = clientSignAuthPack({ freshness: issued, cardSign });

console.log('Honest client:', kdcVerify(signed, issued));

const replayed = { ...signed, pkAuthenticator: { ...signed.pkAuthenticator, freshness: 'stale-token-1234' } }; console.log('Replayed with stale token:', kdcVerify(replayed, issued)); `}

Whichever method you choose, no method alone defeats the legacy compatibility surfaces the card was never designed to police. The structural fix lives in the protocol-removal programme finishing through 2026 and beyond.

11. Frequently Asked Questions

Yes functionally and cryptographically; no physically. A VSC exposes the same PC/SC card edge, Microsoft Smart Card KSP, and minidriver model as a physical card. Above the minidriver layer, every Windows component sees it as a smart card. Tamper-resistance comes from the host TPM rather than a removable IC; Microsoft Learn lists TPM 1.2 as the documented minimum -- VSCs predate TPM 2.0 [@vsc-overview] [@vsc-understanding]. No, by construction. The card signs internally and returns the signature. The only material that leaves during normal operation is the signed output (or, for key exchange, an unwrapped symmetric session key the card has decrypted with the wrapping key). The private key is generated on-card during enrolment and cannot be extracted; that property is the load-bearing security claim of the entire lineage. Legacy NTLM compatibility. Many pre-Windows-2000 services speak only NTLM, and accounts flagged "smart card required for interactive logon" must still authenticate to them. KB 2871997 (May 13, 2014) added auto-rotation of the secondary credential at logon, reducing but not eliminating the attack surface [@kb-2871997]. The structural fix is NTLM removal: NTLMv1 has now been removed in Windows 11 24H2 and Windows Server 2025 [@ntlmv1-removal]. Yes. The YubiKey 5 series exposes a PIV applet that the inbox `msclmd.dll` minidriver recognises out of the box [@yubico-piv] [@inbox-minidriver]. Insert the YubiKey and Windows treats it as a PIV-compliant smart card; the same enrolment, PKINIT, and lock-screen workflows apply. The YubiKey 5 can act as a FIDO2 authenticator concurrently, which is the practical way to bridge smart-card and origin-bound passkey workflows on the same device. Conditionally. PKINIT signs an `AuthPack` containing a nonce and a paChecksum; with the RFC 8070 freshness extension and a correctly validated KDC certificate, an attacker cannot trivially replay or relay an `AuthPack` signed by the client's smart card [@rfc-4556] [@rfc-8070]. But PKINIT is not origin-bound in the WebAuthn sense -- the card has no notion of which KDC the signature is for. If a trust assumption fails (an attacker plants a certificate in the client's NTAuth store, for example), the card will happily sign for the wrong KDC. WebAuthn's RP-ID-bound assertion is a stronger guarantee [@webauthn-2]. See the §6 Callout "VSCs predate TPM 2.0" for the full timeline. TPM 1.2 is the documented minimum; TPM 2.0 is the practical choice on Windows 11, which itself requires TPM 2.0 for the OS [@vsc-overview]. Three reasons, all expanded in §7: provisioning UX, TPM-clear recovery, and the multi-device world. Windows Hello for Business delivered the same TPM-bound-key benefits without the PC/SC abstraction cost (no virtual reader, no virtual minidriver, no APDU layer); FIDO2 then added cross-device portability and origin binding, neither of which the VSC architecture could deliver. The Microsoft Learn VSC Overview deprecation Warning quoted verbatim in §7 makes the recommendation explicit [@vsc-overview] [@passwordless-strategy]. Both are CNG Key Storage Providers. The Smart Card KSP routes calls through the minidriver to either a physical card or a TPM VSC; the cryptographic operation is APDU-encoded and sent to the card. The Platform Crypto Provider routes calls directly to the TPM via TPM Base Services; there is no card abstraction in the path. Windows Hello for Business uses the Platform Crypto Provider for TPM-bound key operations [@cng-ksp-list] [@whfb-how-it-works].

The card was always a metaphor. The cryptographic primitive at its centre -- a non-exportable asymmetric key, bound to a tamper-resistant element, gated by a local gesture -- is the longest-lived object in this lineage. Every generation transition (PC/SC -> CryptoAPI/CNG -> inbox PIV/GIDS -> Virtual Smart Card -> WHfB -> FIDO2) was a transition of the interface around that primitive, not of the primitive itself. The May 2014 contractor whose CAC signed the right blob and lost her account anyway was the canary; the fix she needed was not on her card but in a decade-long programme to remove the OS-minted secondary credentials that lived outside the card's authority. Windows is most of the way through that programme now. The card that wasn't a card outgrew its metaphor -- and the protection it always promised is, finally, arriving at the authentication outcome.

Agentic Identity on Windows: When the Process Acting on Your Behalf Isn't You

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

Every locally-installed AI agent on Windows in May 2026 -- Claude Desktop, ChatGPT Desktop, Cursor, GitHub Copilot CLI, the MSIX-packaged Microsoft Copilot for Windows -- runs in a process whose primary token traces to the logged-on user. `SeAccessCheck`, ETW, RPC ACLs, Defender, and on-device Conditional Access all collapse "the user asked" and "the agent decided" into one principal. The cloud-identity layer has crossed this gap: Microsoft's Entra Agent ID has been in public preview since May 19, 2025 [@ms-security-blog-agentid], and the FIDO Alliance's Agentic Authentication Technical Working Group launched its three-pillar effort on April 28, 2026 with Google's AP2 and Mastercard's Verifiable Intent as foundational donations [@fido-aatwg-pr]. The Windows OS-level analog -- a kernel-recognised `AgentPrincipal` distinct from the user SID and the package SID -- does not exist, even though the substrate primitives (AppContainer package SIDs, Kerberos S4U2Proxy, WebAuthn and Windows Hello, the TPM's Direct Anonymous Attestation, the Administrator-Protection separate-session pattern, WAM, ETW) already ship. This article maps each AATWG pillar onto the Windows primitive that already exists and the glue that does not, and argues that agent identity belongs at both layers, with the OS layer being the missing piece.

1. Two principals walk into a syscall

A Tuesday in May 2026. Windows 11 24H2. Claude Desktop is open. In one terminal, the user types Remove-Item -Recurse -Force .\old-builds. In another, the agent decides to run the same command against the same path. SeAccessCheck returns the same answer for both. The Security event log records the same SubjectUserSid. ETW emits the same SubjectUserName. Microsoft Defender attributes both deletions to the same person -- the human at the keyboard.

As far as the Windows kernel is concerned, there is exactly one principal in this story, and his name is the user [@ms-learn-sids].

Nothing is broken. No malware. No zero-day. The kernel is doing exactly what NT 3.1 shipped to do on July 27, 1993 [@wiki-nt31]: read the primary token, hand the access-check engine the user SID, the group SIDs, and the integrity-level overlay [@ms-learn-mic], and decide. The decision is correct. It is also, in 2026, an attribution failure -- because the two actors who issued those two commands are different actors, and the kernel cannot tell.

The attribution-collapse claim holds for every deployment pattern of every shipping agent today, but the privilege-blast-radius framing is the strong claim for Electron-wrapped agents (full DPAPI user scope, full Kerberos ticket-granting ticket, full network egress) and a more qualified claim for MSIX-packaged agents like Microsoft Copilot for Windows, which inherit a LowBox token and a per-package DPAPI scope under AppContainer [@ms-learn-appcontainer].

The kernel-resident access token attached to every Windows process at creation. It contains a user SID, a list of group SIDs, an integrity-level SID carried in a `SYSTEM_MANDATORY_LABEL_ACE` inside the token's SACL [@ms-learn-mic], and a privilege set; every `SeAccessCheck` call reads it as the authoritative statement of "who is running this process" [@ms-learn-sids].

The collapse is structural. Three observations make the shape visible.

First, the kernel's access-check pipeline reads the user. SeAccessCheck walks the DACL on the target object and matches each ACE against the SIDs in the primary token. The integrity-level overlay, added in Windows Vista, gates writes against the integrity label [@ms-learn-mic]; AppContainer, added in Windows 8, adds a second-principal-shaped SID to the same token group list [@ms-learn-appcontainer]; but the primary SID -- the answer the kernel returns when a downstream consumer asks "whose authority is being exercised here?" -- is the user.

Second, the cloud-identity layer has just put the dual-principal answer on the wire. On April 28, 2026, the FIDO Alliance announced the Agentic Authentication Technical Working Group [@fido-aatwg-pr]. The three pillars: Verifiable User Instructions, Agent Authentication, and Trusted Delegation for Commerce. Chairs are CVS Health, Google, and OpenAI; vice-chairs are Amazon, Google, and Okta; the parallel Payments Technical Working Group is chaired by Mastercard and Visa. Google's Agent Payments Protocol (AP2) and Mastercard's Verifiable Intent framework are the foundational donations [@ap2-blog-google; @mastercard-vi]. Independent coverage from HelpNetSecurity dated April 29, 2026 carries the same governance roster [@helpnetsecurity-aatwg]. The cloud side now has a named, governed wire-format design space for the agent-as-distinct-principal story.

Third, the OS-side gap is structural. Every layer of Windows from SeAccessCheck through ETW [@ms-learn-mic] through on-device Conditional Access still answers "the user" because the primary token still has only the user SID. The package SID under AppContainer is the closest signal Windows has to a second principal; the access-check rule is intersection, not addition -- "the permitted access is the intersection of that granted by the user/group SIDs and AppContainer SIDs" [@ms-learn-appcontainer]. That intersection rule is the closest thing the kernel has to a sibling-principal model, and it identifies a package, not an agent.

Note: No engineering effort is required to produce this attribution failure. The kernel is functioning as designed. The design is from 1993. The user is the principal. The agent is the user. The audit log is what the audit log has always been.

What would it take, mechanically, for the kernel to know which principal was which -- and why has the answer been "the user" for the thirty-three years since NT 3.1? Both halves of that question have load-bearing histories, and those histories are older than NT itself.

2. From Multics to NT 3.1: the user-as-principal genealogy

MIT, Bell Labs, and General Electric. Fernando Corbato of MIT and Victor Vyssotsky of Bell Telephone Laboratories present Introduction and Overview of the Multics System at the AFIPS Fall Joint Computer Conference. Their opening describes a general-purpose programming system intended to scale to thousands of users at a single installation [@multics-fjcc]. Multics, jointly led by MIT's Project MAC, General Electric, and Bell Laboratories [@multics-wiki], is the first operating system designed from the start around the idea that the kernel must know whose work each running process is doing.

The Multics inheritance is not stylistic. It is the source of the abstraction Windows NT 3.1 picks up twenty-eight years later: a principal is a named entity (a user, or in some systems a service account); every process belongs to exactly one principal at creation; the kernel mediates access using that principal. TENEX, BBN's PDP-10 time-sharing system from 1969 [@tenex-bitsavers], inherits the same model and ports it into the DEC product line; the Multics-to-TENEX-to-Unix lineage [@multics-hist] is the route the article reads as carrying the user-as-principal assumption forward into the design ground from which DEC VMS and later Windows NT 3.1 emerged.

A variable-length data structure that uniquely identifies a security principal in a Windows access decision. The canonical user-SID form is `S-1-5-21--`; every access token carries a user SID plus a list of group SIDs, and every `SeAccessCheck` call reads them as the authoritative answer to "who is running this thread?" [@ms-learn-sids].

The formal model came in 1971. Butler Lampson, then at Xerox Palo Alto, published Protection at the 5th Princeton Conference on Information Sciences and Systems, later reprinted in ACM Operating Systems Review 8(1) in January 1974 [@lampson-catalog]. Lampson's access-matrix model -- subject by object by right -- is the operational mathematics behind every modern access-control system. Read the matrix row by row and you get a capability list ("what each subject can do"); read it column by column and you get an access control list ("who can do what to this object"). Windows picks column-major: every securable object on Windows is described by a DACL, and SeAccessCheck is the operational realisation of Lampson's matrix on NT. The DACL is the column; the primary token is the row index; the access-check answer is the cell.

The bwlampson.site author catalog is the canonical fetchable anchor for the 1971 paper [@lampson-catalog]. The Microsoft Research-hosted PDF that this corpus previously linked is dead (HTTP 404); the catalog page itself names the ACM OSR 8(1) January 1974 reprint as the journal of record.

timeline title Genealogy of the user-as-principal model 1965 : Multics : Corbato and Vyssotsky present at AFIPS FJCC : Per-user authentication as a kernel primitive 1969 : TENEX : BBN ports the user-as-principal model to PDP-10 1971 : Lampson's access-matrix model : Subject x object x right : Foundation for SeAccessCheck and the DACL 1988 : Hardy's Confused Deputy : Authority from two sources, no way to name which 1993 : NT 3.1 ships : One primary token per process, user SID as principal

Seventeen years later, in 1988, Norm Hardy writes The Confused Deputy at Key Logic (the company formed from the wreckage of Tymshare, where the events Hardy describes had occurred years earlier). Hardy's compiler is a FORTRAN compiler with a home-files licence; it legitimately holds authority to write into one path (the billing file (SYSX)BILL) so it can record per-user compilation charges, and it legitimately accepts user-supplied output paths so it can write generated .obj files where the user requests. A clever user supplies (SYSX)BILL as the output path. The compiler obediently writes the user's output over the billing record, because the compiler "had no way of expressing these intents" [@hardy-caplore].

Hardy's punchline is structural, and the article will return to it once more. "The fundamental problem is that the compiler runs with authority stemming from two sources. (That's why the compiler is a confused deputy.) ... The compiler had no way of expressing these intents!" [@hardy-caplore]. The deputy holds authority from two principals (itself, the licensed compiler; and the user it is serving), and the system the deputy talks to has no protocol for the deputy to say which authority it is exercising for this action. Any system that grants a deputy ambient authority from multiple sources without giving the deputy a way to name those sources at the syscall is a confused-deputy system by construction. The ACM Digital Library carries the canonical reprint at 10.1145/54289.871709 [@hardy-acm], with the cap-lore.com mirror as the fetchable secondary.

Hardy 1988: a process holding authority delegated from one principal can be tricked into using that authority on behalf of another principal because the process has no way to attribute its actions to the right authorising principal at the syscall [@hardy-caplore]. The structural lower bound on agent attribution.

July 27, 1993 [@wiki-nt31]. Dave Cutler ships NT 3.1. Every process on NT carries exactly one primary token; the token's user SID is the principal; impersonation is the only way a thread can temporarily speak as a different identity, and impersonation is bounded to the thread, not the process. Microsoft Learn states the consequence verbatim: "Each time a user signs in, the system creates an access token for that user. The access token contains the user's SID, user rights, and the SIDs for any groups the user belongs to" [@ms-learn-sids]. That description is the Multics inheritance with thirty years of refinement: one principal per process, the principal is a user, the access-check is the operational form of Lampson's matrix.

This is the user-identity milestone, not the code-identity milestone. NT 3.1 made user identity precise. The process that ran an attached binary still had no answer to "who is this code?" -- and as the late-1990s ActiveX download experience would prove, that gap could not stay open.

3. Layering code identity on user identity: 1996 to 2017

August 7, 1996. A joint Microsoft and VeriSign press release crosses the wire: Microsoft and VeriSign Provide First Technology For Secure Downloading of Software Over the Internet [@ms-news-authenticode-1996]. Internet Explorer 3.0 will ship with the new model the same year. The model has a name: Authenticode. The question this section asks: did Authenticode and its successors solve the principal question, or did they only decorate it?

The pattern that emerges across five generations of code-identity layering deserves a name. Every generation answers a real failure of the one before it. Every generation adds an attribute to the access decision -- a publisher signature on the binary, a policy gate at load time, a second SID in the token, a kernel-mode code-integrity policy. And every generation leaves the runtime principal unchanged. The user is still the user. The token's primary SID is still the user SID. The downstream consumer (Defender, an ETW provider, a remote RPC server, a file-system DACL) still sees one principal.

3.1 Authenticode (1996, NT 4.0 with IE 3.0)

Authenticode is a load-time attribute. The publisher signs the PE on disk; the signature is a PKCS #7 blob embedded in a dedicated PE attribute certificate slot [@ms-learn-cryptography]. When the loader maps the binary, Windows can verify the signature, walk the certificate chain to a trusted root, and present the publisher name to the user (in IE 3.0's case, in the famous ActiveX install dialog). Cross-vendor code-signing history places Authenticode among the earliest widely-deployed commercial schemes to bind a publisher identity to a downloaded executable [@wikipedia-codesign; @ms-news-authenticode-1996].

Authenticode is a load-time attribute -- the publisher signs the file on disk, not the running process. After the loader has validated the signature and mapped the image, the running process's primary token has nothing in it that records "this binary was signed by Microsoft Corporation." The runtime principal is unchanged from what the user's logon session created.

The failure mode that forces the next generation is structural. A signature is descriptive ("this file is from Microsoft"), not authoritative ("this process is acting with Microsoft's authority"). A binary's publisher is attached to the file on disk; nothing about it propagates into the access decision the kernel makes when the process opens a network socket, decrypts a DPAPI blob, or impersonates over RPC.

3.2 SRP and AppLocker (2001, 2009)

Software Restriction Policies arrived first with Windows XP (October 2001) [@wiki-winxp] and shipped again with Windows Server 2003 (April 2003) [@wiki-srv2003]; AppLocker arrived on Windows 7 (October 22, 2009) [@wiki-win7] and Server 2008 R2 as the formal successor. Microsoft Learn says it directly: "AppLocker policies in the GPO are applied and supersede the SRP policies in the GPO and any local AppLocker policies or SRP policies" [@ms-learn-srp-applocker]. Both layers are policy gates: an administrator authors rules naming publishers, hashes, or paths, and the OS enforces the rules at process creation. The runtime token is, again, unchanged.

The failure mode is one Microsoft itself documents in unusually plain language. The AppLocker overview reads, verbatim: "AppLocker is a defense-in-depth security feature and not considered a defensible Windows security feature" [@ms-learn-applocker]. The same page directs administrators to App Control for Business when the goal is defensible threat protection. Defense-in-depth means the feature raises attacker cost; it does not promise an attacker cannot bypass it. That promise is reserved for documented security boundaries.

3.3 AppContainer and the package SID (Windows 8, October 26, 2012 general availability)

AppContainer is the first time the kernel carries a second principal-shaped SID in the token's group list. Windows 8 ships with the new sandbox; every UWP app process runs with an S-1-15-2-... package SID attached to its primary token, alongside the user SID and the user's group SIDs. The dual-principal model has a verbatim Microsoft Learn definition: "This dual-principal model ensures that access to sensitive resources is tightly controlled and can be managed independently for different applications ... the permitted access is the intersection of that granted by the user/group SIDs and AppContainer SIDs" [@ms-learn-appcontainer].

The kernel sandboxing primitive shipped in Windows 8 (October 26, 2012 general availability) [@ms-learn-appcontainer; @wiki-win8]. It attaches a second SID (`S-1-15-2-...`) to a process's access token; access decisions become the intersection of user/group SIDs and the package SID, gated further by capability SIDs (`S-1-15-3-...`) the app declares in its manifest [@ms-learn-appcontainer]. The kernel-internal name for the structure is the LowBox token, which is why the relevant API is `NtCreateLowBoxToken` [@ms-learn-appcontainer-legacy].

The dual-principal language is real and load-bearing. It is also not what the article needs. The package SID identifies a package (the UWP manifest, the MSIX bundle), not an agent role. Nothing upstream tells Defender, ETW, or Conditional Access whether the package SID it sees represents an AI agent, a UWP calculator, or a games launcher. AppContainer also originally targeted UWP only; the legacy-applications variant arrived later as a way to retrofit unpackaged Win32 apps into the same kernel substrate [@ms-learn-appcontainer-legacy], which is the path Win32 App Isolation (June 14, 2023) extends [@ms-blogs-win32appiso].

3.4 App Control for Business (2017 onwards)

App Control for Business -- the policy formerly known as Windows Defender Application Control (WDAC), which arrived as a named feature in Windows 10 1709 (Fall Creators Update, released October 17, 2017) [@wiki-win10vh] -- is the kernel-mode code-integrity policy enforced by the loader itself [@ms-learn-appcontrol]. Unlike AppLocker, App Control for Business is on the documented security-boundary list when configured per the supported guidance; it can cover DLL loads, driver loads, and script-host loads with a single policy. The runtime principal is, predictably, still the user.

flowchart TD subgraph TokenAtRuntime["What is in the primary token"] US["User SID (1993)"] PSID["Package SID (2012)"] IL["Integrity level overlay (2006)"] end subgraph GateBeforeRuntime["What gates execution before the token exists"] AC["Authenticode signature (1996)"] SRP["SRP and AppLocker (2001 and 2009)"] WDAC["App Control for Business (2017)"] end AC --> SRP --> WDAC US --> PSID --> IL GateBeforeRuntime -.-> TokenAtRuntime classDef def fill:transparent

Note: Each generation of Windows code identity pushed the publisher, package, or integrity attribute into the token or into a load-time gate, but the runtime principal stayed the user. The agent-attribution problem is the third instance of this pattern -- the question shifts from "who wrote this code?" to "who instructed this code right now?" but the architectural answer Windows has shipped is the same answer it shipped in 1993.

So a reader who arrived at this article believing Windows must have some way of attributing what an AI agent does, given how much identity machinery has accumulated since 1993, can now see why the belief is wrong. Authenticode signs the file on disk. AppLocker is defense-in-depth. The AppContainer package SID is per-package, not per-role. App Control for Business controls what code runs, not which principal carries the authority once code is loaded. Five generations of layering identity attributes; one user SID at the centre.

If we take the genealogy seriously and ask what a sixth generation -- a second principal attached to the process at the kernel layer -- would have to look like, the answer is sitting in an Insider build.

4. Six generations, plus the one that hasn't shipped

Read the genealogy as a forcing function and the shape becomes clear. Every generation of Windows app identity was forced by a specific failure of the one before it, and the forced response was never "replace the existing identity model" -- it was always "add an attribute or a sibling principal alongside it." That conservation rule is what makes Windows identity legible across thirty-three years. It is also what makes the seventh generation visible by its absence.

The six shipped generations are easy to enumerate.

Generation 1: NT 3.1 primary token (July 27, 1993). One primary token per process. The token carries a user SID and a group SID list [@ms-learn-sids; @wiki-nt31]. The runtime principal is the user.
Generation 2: Authenticode (August 7, 1996). Publisher signature attached to the binary on disk [@ms-news-authenticode-1996]. Runtime token unchanged.
Generation 3: SRP, then AppLocker (2001, October 22, 2009). Group-Policy execution gates; runtime token unchanged; AppLocker explicitly defense-in-depth, not a defensible boundary [@ms-learn-applocker; @ms-learn-srp-applocker; @wiki-winxp; @wiki-win7].
Generation 4: AppContainer and the package SID (October 26, 2012). Second principal-shaped SID in the token group list. Access check is the intersection of user and package authority [@ms-learn-appcontainer; @wiki-win8]. Runtime principal is still the user.
Generation 5: App Control for Business (2017 onwards). Kernel-mode code-integrity policy; defensible boundary; controls what code can run, not which principal carries authority [@ms-learn-appcontrol; @wiki-win10vh].
Generation 6: Administrator Protection (late 2025 Insider, iterating through 2026). The first shipping Windows feature that mints a true second logon-session principal for a bounded action, gated by a Windows Hello user-verification gesture [@ms-techcomm-adminprot].

Administrator Protection is the interesting one. The feature surfaced on Windows 11 Insider builds in late 2025; subsequent Insider build iterations have continued through 2026, with a temporary disablement and re-enablement during that window [@ms-techcomm-adminprot]. As of May 2026 it is not yet generally available; the Tech Community announcement page is the canonical reference for the design [@ms-techcomm-adminprot].

The structural innovation is worth describing precisely. Pre-Administrator-Protection elevation on Windows used split tokens: an administrator user signs in, and the Local Security Authority creates two logon sessions for the same user, one filtered and one full. When the user clicks through the User Account Control prompt, the elevating process swaps its primary token from the filtered to the full session. Both sessions belong to the same user SID; the policy boundary is integrity-level and group-driven, not principal-driven.

Administrator Protection breaks that. The feature introduces a System-Managed Administrator Account shadow profile.The internal acronym is SMAA. It does not yet appear in whoami /all output on shipping builds. When the user authorises an elevation through Windows Hello, the elevated process runs under the separate SMAA logon session, scoped to that elevation [@ms-techcomm-adminprot]. The Hello gesture is the verification step; the separate session is the new principal; the bound is the single elevated action.

Key idea: Every generation of Windows app identity has been forced by a specific failure of the previous generation, and every forced response added an attribute or a sibling principal alongside the existing one -- but until Administrator Protection (Generation 6, Insider in 2026, not yet generally available), no shipping Windows feature minted a true second principal for a bounded action.

Administrator Protection is the existence proof. Windows can mint a second logon-session principal for a bounded action under a user-verification gesture. The architectural question this article asks: can the same pattern generalise from elevation to delegation?

flowchart TD G1["Gen 1: NT 3.1 primary token (1993). User SID only."] G2["Gen 2: Authenticode (1996). Publisher attached to binary."] G3["Gen 3: SRP and AppLocker (2001, 2009). Execution gates."] G4["Gen 4: AppContainer and package SID (2012). Second SID in token."] G5["Gen 5: App Control for Business (2017+). Kernel-mode CI."] G6["Gen 6: Administrator Protection (late 2025 Insider). Second logon session for elevation."] G7["Gen 7 (missing): AgentPrincipal. Second logon session for delegation."] G1 --> G2 --> G3 --> G4 --> G5 --> G6 -.-> G7

The missing seventh generation is what this article is about. It exists at the cloud layer. Microsoft's Entra Agent ID has been in public preview since May 19, 2025 [@ms-security-blog-agentid] and was the centrepiece of the Ignite 2025 expansion that Microsoft itself called "the largest expansion of Microsoft Entra capabilities to date, extending Zero Trust principles to AI workloads" [@ms-learn-ignite25]. The FIDO Alliance has named the wire-format design space [@fido-aatwg-pr]. The IETF has an individual draft for the OAuth wire format [@ietf-draft-agentoauth]. The OS layer does not have an analog.

If Generation 6 is the existence proof at the OS layer, what just happened at the cloud layer that finally makes the delegation case unavoidable?

5. April 28, 2026: the wire format goes public

April 28, 2026. The FIDO Alliance press release crosses the wire. FIDO Alliance to Develop Standards for Trusted AI Agent Interactions [@fido-aatwg-pr]. The opening sentence is the inflection point: "The FIDO Alliance today announced initiatives to develop interoperable standards for agentic interactions and commerce." Andrew Shikiar, FIDO Alliance CEO, is the launch spokesperson. The BusinessWire mirror under wire ID 20260427506015 carries the same text [@fido-aatwg-bw], and independent press coverage from HelpNetSecurity (April 29, 2026) [@helpnetsecurity-aatwg] and PPC Land [@ppcland-aatwg] corroborate the launch.

Four interlocking pieces of news land in the same press release.

5.1 The three AATWG pillars

The Agentic Authentication Technical Working Group is chartered around three pillars [@fido-aatwg-pr]. The press release wording is verbatim because the wording is what every downstream protocol will quote.

Verifiable User Instructions. "Enabling users to authorise AI agents through clear, phishing-resistant mechanisms so agents only perform approved actions, including transactions, without exposing credentials" [@fido-aatwg-pr]. The wire-format primitive: a passkey-signed delegation token bound to a specific intent ("approve $50 to vendor X"), with replay protection and a short TTL.
Agent Authentication. "Allowing services to verify that an AI agent is acting on behalf of an authenticated user and within defined parameters, distinguishing legitimate agents from unauthorised actors" [@fido-aatwg-pr]. The wire-format primitive: an attestation binding an agent class (optionally a specific instance) to a verifiable identity assertion.
Trusted Delegation for Commerce. "Defining how agent-initiated transactions can be executed within user-controlled boundaries, with verifiable authorisation" [@fido-aatwg-pr]. The wire-format primitive: the AP2 mandate or Verifiable Intent SD-JWT chain binding an agent action to a user-approved scope and constraint set.

The FIDO Alliance today announced initiatives to develop interoperable standards for agentic interactions and commerce ... Verifiable User Instructions ... Agent Authentication ... Trusted Delegation for Commerce. -- FIDO Alliance press release, April 28, 2026 [@fido-aatwg-pr]

5.2 The governance

The taxonomy matters because over-attribution is one of the easier mistakes to make in this story. AATWG chairs are CVS Health, Google, and OpenAI; vice-chairs are Amazon, Google, and Okta; the parallel Payments Technical Working Group is chaired by Mastercard and Visa [@fido-aatwg-pr]. Co-sponsors include OpenAI, Amazon, Okta, CVS Health, Visa, and Proof, plus the donating partners (Google, Mastercard). Proof Inc.'s Know Your Agent framework is a separate Sponsor-tier contribution to FIDO; it is not an AATWG chair or vice-chair role.

5.3 The foundational donations

Google's Agent Payments Protocol (AP2) and Mastercard's Verifiable Intent framework are the foundational donations [@ap2-blog-google; @mastercard-vi]. AP2 was open-sourced on September 16, 2025 [@ap2-cloud-blog] at github.com/google-agentic-commerce/AP2 under Apache 2.0 [@ap2-github]; v0.2 shipped alongside the FIDO donation, with the v0.2 release notes calling out "Human Not Present" payments [@ap2-blog-google]. Mastercard's Verifiable Intent specification is hosted at verifiableintent.dev as Draft v0.1, describing a three-layer SD-JWT delegation chain (Identity, Intent, Action) with eight constraint types -- amount bounds, merchant allow-lists, budget caps, recurrence terms -- "cryptographically bound and machine-verifiable" [@vi-dev]. The underlying credential model is the W3C Verifiable Credentials Data Model v2.0 W3C Recommendation [@w3c-vc-2].

The mandate vocabulary drifted between the September 2025 AP2 launch and the v0.2 release. The launch announcement at cloud.google.com described "Intent / Cart / Payment" mandates [@ap2-cloud-blog]; the current ap2-protocol.org spec describes "Checkout (Open / Closed) + Payment (Open / Closed)" [@ap2-protocol]. Readers diffing the September 2025 blog against the April 2026 spec should expect the vocabulary, not the underlying primitives, to have changed.

5.4 The Microsoft parallel

Microsoft has been on the same arc for nearly a year. The Build 2025 security blog, dated May 19, 2025, introduced Microsoft Entra Agent ID in public preview: "We are excited to introduce Microsoft Entra Agent ID, which extends identity management and access capabilities to AI agents" [@ms-security-blog-agentid]. The Workday Agent System of Record and ServiceNow AI Platform integrations announced on September 16, 2025 made Entra Agent ID a directory service for agents across two of the largest enterprise SaaS platforms [@prnewswire-workday]. The Ignite 2025 expansion (November 2025) was, in Microsoft's own framing, "the largest expansion of Microsoft Entra capabilities to date, extending Zero Trust principles to AI workloads" [@ms-learn-ignite25]; the agent OAuth protocol trio shipped at the same time [@ms-learn-agentoauth], and Conditional Access for agent identities followed into preview in early 2026 [@ms-learn-caagent]. WinBuzzer (May 20, 2025) corroborates the public-preview launch [@winbuzzer-agentid].

flowchart LR P1["Pillar 1: Verifiable User Instructions"] P2["Pillar 2: Agent Authentication"] P3["Pillar 3: Trusted Delegation for Commerce"] W1["Wire: passkey-signed delegation token, intent-bound, short TTL"] W2["Wire: attestation + identity assertion, agent class or instance"] W3["Wire: AP2 mandate or Verifiable Intent SD-JWT chain"] P1 --> W1 P2 --> W2 P3 --> W3

So the reader's understanding shifts. Before April 28, 2026 the easy mental model was that AI agents were a product feature, not an identity question. After the FIDO press release the design space is named, governed, and partially specified on the wire. The further shift drives the rest of the article: the cloud layer is no longer the gap. Entra Agent ID has shipped a directory; OAuth Token Exchange has had the act and may_act claims standardised since January 2020 [@ietf-rfc-8693]; the MCP authorisation profile has its 2025-11-25 revision live [@anthropic-mcp-2025-11-25]; AP2 and Verifiable Intent are now under FIDO governance.

The gap is on the desktop. So if we take the three pillars seriously, which Windows primitive does each pillar already have a substrate for, and which Windows primitive is missing?

6. Mapping the three pillars onto Windows primitives

One section. Three sub-sections, one per pillar. For each: the existing Windows primitive, the API surface that exposes it, and the missing glue that turns it into a pillar-compatible building block.

6.1 Pillar 1: Verifiable User Instructions on Windows

The substrate exists in user mode and lives in webauthn.dll, the Win32 platform-authenticator entry point. Microsoft Learn describes it verbatim: "Provides Win32 apps with APIs for communicating to Windows Hello and external security keys as part of WebAuthN and CTAP specifications" [@ms-learn-webauthn-api]. Windows Hello provides the TPM-rooted user-verification gesture: "credentials are asymmetric and generated within isolated environments of TPMs" [@ms-learn-hello]. The credential provider model in Winlogon, the passkey provider plug-in model in Windows 11 24H2, and per-relying-party passkey isolation in Windows Hello for Business round out the platform-authenticator surface.

What is missing is a Windows-native agent action approval UI surface. Today's pieces let a relying party in the browser ask the user to authenticate to that relying party; they do not let a locally-installed agent ask the user to authorise a specific action ("approve $50 to vendor X"; "approve rm -rf .\old-builds") by minting a per-action, intent-bound delegation token signed by the user's passkey with replay protection and a TTL measured in seconds. The Pillar 1 wire format AATWG is developing is exactly this kind of token; the Windows-side glue would land it as a system UI surface (analogous to UAC, but minting a passkey assertion rather than escalating an integrity level), wired into the WebAuthn platform authenticator and audited via ETW.

The Windows-resident OAuth token broker that ships with the operating system. WAM acts as an authentication broker on Windows 10 1703 and later; "WAM ensures that the refresh tokens are device bound and enables apps to acquire device bound access tokens" [@ms-learn-wam]. WAM is the on-device credential broker for Microsoft Entra ID; it does not work with third-party identity providers as of May 2026.

6.2 Pillar 2: Agent Authentication on Windows

The kernel substrate is AppContainer plus the package SID. The verbatim Microsoft Learn dual-principal model is the load-bearing citation: "the permitted access is the intersection of that granted by the user/group SIDs and AppContainer SIDs" [@ms-learn-appcontainer]. The cryptographic binding from binary to package is Authenticode signing the file [@ms-news-authenticode-1996; @wikipedia-codesign] and App Control for Business as the policy gating the loader [@ms-learn-appcontrol]. The privacy-preserving agent-class attestation primitive is Direct Anonymous Attestation, defined in the TPM 2.0 Library Specification by the Trusted Computing Group; the corpus's sibling DAA article describes the protocol in detail, and the verbatim TCG specification language is sourced there.

A TPM 2.0 protocol that lets a device prove membership in a privacy-preserving group without revealing the specific device identity. In the agent setting, DAA would let an agent vendor prove "this binary is a member of the *signed Claude Desktop* class" without revealing which specific desktop installation is making the call. The protocol's group-signature mathematics is the load-bearing primitive.

What is missing on Windows is a kernel-recognised AgentPrincipal that downstream consumers treat as first-class. Today the package SID is the closest signal; it is also category-incorrect, because the package SID represents a package, not an agent role. An AgentPrincipal would be a third token-resident SID alongside the user SID and the package SID, with its own ACL slot in opt-in DACLs, its own SubjectAgentSid field in SeAccessCheck audit events, its own ETW header alongside SubjectUserSid, its own RPC binding-handle metadata, and its own claim in the access tokens WAM mints. Defender, EDR, on-device Conditional Access -- every consumer that today reads the user SID would gain a sibling field.

The dominant deployment pattern for AI agents on Windows desktops in May 2026 is Electron plus an NSIS or MSI per-user installer, not MSIX plus the AppContainer kernel substrate. Claude Desktop, ChatGPT Desktop, and Cursor all ship through this Electron path; GitHub Copilot CLI ships as a Node.js CLI via npm (`@github/copilot`), WinGet (`GitHub.Copilot`), or an MSI installer from the github/copilot-cli GitHub Releases page, which is a different non-MSIX-packaged path but is structurally equivalent for the purposes of this article -- no package SID, no AppContainer kernel substrate, primary token traces to the user. Each of them runs under the user's primary token without a package SID; the WebAuthn platform authenticator is available to them via `webauthn.dll`, but the kernel-substrate dual-principal model under AppContainer is not.

Win32 App Isolation, announced in public preview on June 14, 2023, is the in-flight retrofit. The launch blog describes it directly: "We are thrilled to announce the public preview launch of Win32 app isolation ... Win32 app isolation is built on the foundation of AppContainers ... AppContainer, which is recognized as a security boundary by Microsoft" [@ms-blogs-win32appiso]. Adoption among agent vendors three years later is minimal; the Pillar 2 substrate exists, but the deployment substrate that would carry it does not.

6.3 Pillar 3: Trusted Delegation for Commerce on Windows

The act-on-behalf-of primitive on Windows is Kerberos S4U2Self and S4U2Proxy, formally specified in Microsoft's MS-SFU Kerberos Protocol Extensions [@ms-learn-mssfu]. S4U2Self lets a service obtain a service ticket for a user without that user's password (the "for" half); S4U2Proxy lets the service then present that ticket to a back-end service on the user's behalf (the "proxy" half). Resource-Based Constrained Delegation is the modern policy form: the back-end service authors which front-end services may delegate to it. Protected Users, Authentication Policies, and Authentication Silos are the policy plumbing. WAM is the on-device token broker for Entra-side delegation [@ms-learn-wam]; Microsoft's OAuth 2.0 On-Behalf-Of flow [@ms-learn-obo-flow] is the cloud analog.

Microsoft's Kerberos Protocol Extensions, formalised in MS-SFU, that let a server obtain a service ticket on behalf of a user without that user's password (S4U2Self) and then present that ticket to a back-end service (S4U2Proxy). They are the act-on-behalf-of primitive on Windows [@ms-learn-mssfu]. Resource-Based Constrained Delegation refines the policy: the back-end resource names the front-end services it accepts delegation from.

What is missing is a Macaroons-style mintable, attenuable, revocable capability-token format scoped to a per-tool allow-list. Macaroons were introduced by Birgisson, Politz, Erlingsson, Taly, Vrable, and Lentczner at NDSS 2014 (February 22, 2014) [@macaroons-ndss; @macaroons-gr]. The verbatim positioning from the Google Research abstract is the load-bearing description: "macaroons are bearer credentials, like Web cookies, macaroons embed caveats that attenuate and contextually confine when, where, by who, and for what purpose a target service should authorize requests" [@macaroons-gr]. The construction is a chained HMAC: a fresh HMAC of the previous HMAC plus a caveat. Any holder can append a caveat, derive a strictly weaker macaroon, and present it to a verifier; the verifier walks the chain, checks each caveat against its policy, and verifies the final HMAC against the issuer's secret.

Birgisson, Politz, Erlingsson, Taly, Vrable, and Lentczner at NDSS 2014 [@macaroons-ndss]. A bearer credential constructed as a chained HMAC over caveats; any holder can derive a strictly weaker credential by appending a caveat without round-tripping the issuer, but cannot derive a stronger one. The attenuation property is what makes macaroons the natural format for per-tool agent capabilities [@macaroons-gr].

In a Windows-shipping Pillar 3 implementation, the agent would not present the user's TGT to a downstream tool. The agent would present a macaroon issued at agent-install time -- attenuated to the specific tools the user authorised through a Pillar 1 Verifiable User Instructions flow -- and the tool would verify the macaroon plus an ETW emission carrying both SubjectUserSid and SubjectAgentSid. Revocation would land at the issuer (the WAM-resident macaroon authority), with a Continuous Access Evaluation analog fanning out to local token caches without logging the user out.

flowchart LR subgraph P1G["Pillar 1: Verifiable User Instructions"] P1S["Substrate: webauthn.dll, Windows Hello, passkey provider"] P1M["Missing: agent-action approval UI minting intent-bound delegation tokens"] P1S --> P1M end subgraph P2G["Pillar 2: Agent Authentication"] P2S["Substrate: AppContainer package SID, Authenticode, App Control, TPM 2.0 DAA, Pluton"] P2M["Missing: kernel-recognised AgentPrincipal across SeAccessCheck, ETW, RPC, Defender, CA"] P2S --> P2M end subgraph P3G["Pillar 3: Trusted Delegation for Commerce"] P3S["Substrate: Kerberos S4U2Proxy, RBCD, WAM, OBO flow, ETW"] P3M["Missing: Macaroons-style attenuable capability tokens plus AgentPrincipalSid in ETW"] P3S --> P3M end

The proposed access-check sequence is the second load-bearing diagram. Picture an agent in its own AppContainer, with its own package SID, holding a macaroon scoped to one tool. The agent calls the tool; WAM intercepts; if the action requires fresh user verification, Hello mints a passkey assertion; SeAccessCheck evaluates user SID, package SID, and the proposed agent SID; ETW emits the dual-principal record.

sequenceDiagram participant Agent as Agent process participant WAM as WAM broker participant Hello as Windows Hello participant Kernel as SeAccessCheck participant ETW as ETW provider Agent->>WAM: request tool access with macaroon WAM->>WAM: verify macaroon chain WAM->>Hello: if intent required, mint fresh assertion Hello-->>WAM: passkey assertion WAM->>Kernel: assemble token (user SID, package SID, agent SID) Kernel->>Kernel: access check with three principals Kernel-->>Agent: granted or denied Kernel->>ETW: emit dual-principal record

Pillar	Windows substrate that already ships	API surface	Missing glue
1: Verifiable User Instructions	`webauthn.dll`, Windows Hello, passkey provider	Win32 WebAuthn API; Hello credential provider	Agent-action approval UI; intent-bound passkey delegation tokens with short TTL
2: Agent Authentication	AppContainer + package SID, Authenticode + App Control, TPM 2.0 DAA, Pluton attestation	NtCreateLowBoxToken; LSASS package-SID assignment; TPM attestation	Kernel-recognised `AgentPrincipal` across `SeAccessCheck`, ETW, RPC, Defender, on-device CA
3: Trusted Delegation for Commerce	Kerberos S4U2Self/S4U2Proxy, RBCD, WAM, OBO flow, ETW	MS-SFU; MSAL WAM broker; Entra OBO token endpoint	Macaroons-style per-tool capability tokens; `AgentPrincipalSid` ETW field; CAE-style fan-out for revocation

Deployment pattern	Token at runtime	Where DPAPI lives	Network privilege
Non-MSIX user-mode (Claude Desktop / Cursor / ChatGPT Desktop: Electron + NSIS; Copilot CLI: Node.js + npm / WinGet / MSI)	User primary token; no package SID	User DPAPI scope (decryptable by any process under the same user)	Full user network privilege; user TGT available
MSIX-packaged AppContainer (Microsoft Copilot for Windows)	LowBox token with package SID; integrity level usually Low	Per-package DPAPI scope (isolated from other packages)	Capability-gated network egress per app manifest

So the substrate is largely on the box. The glue is not. What competing approaches already ship -- and which one wins?

7. Where the principal lives: three positions

Three architectural positions are already shipping enough code that "which one wins" is a real question. Each picks a different layer to host the agent principal: the cloud, the operating system, or the on-device token broker.

7.1 Cloud-only

Agent identity lives in the identity provider. Microsoft's Entra Agent ID is the reference design: agents are first-class directory objects, with their own client credentials, sign-in logs, Conditional Access policies, and audit trail in Purview [@ms-learn-agentid]. When an agent needs to call a back-end API on a user's behalf, it uses RFC 8693 Token Exchange [@ietf-rfc-8693] or Microsoft's OAuth 2.0 On-Behalf-Of flow [@ms-learn-obo-flow] to exchange the user's token for an actor-claim-carrying access token; the back-end API consumes the act and may_act claims to attribute the call.

Pros: works today, no kernel change, no Windows update required. The plumbing is fully specified at IETF [@ietf-rfc-8693; @ietf-rfc-9728; @ietf-oauth-v2-1], the Microsoft documentation is live [@ms-learn-agentoauth; @ms-learn-agentobo], and the directory exists [@ms-learn-agentid]. Cons: the OS never sees an agent principal. Every local file action, every DPAPI decrypt, every Kerberos ticket use, every RPC call inside the device collapses to the user identity. On-device endpoint detection cannot attribute. Continuous Access Evaluation knows the agent has been revoked in the cloud but cannot purge the user's local Kerberos cache or local DPAPI-protected secrets without logging the user out.

Microsoft Learn makes the cloud-only constraint explicit: "Agents aren't supported for OBO (/authorize) flows. Supported grant types are client_credential, jwt-bearer, and refresh_token" [@ms-learn-agentobo]. Agent identities are confidential clients only [@ms-learn-agentoauth]; the interactive-flow path used by browser-based delegation is not available to agent entities. Cloud-only works precisely because the agent never tries to participate in a desktop user-verification gesture. AzureFeeds (January 28, 2026) records the practical consequences for Conditional Access: agent authentication is "purely machine-driven" with no MFA prompt, no device check, and no authentication-strength evaluation [@azurefeeds-caagent].

7.2 OS-only

Hypothetical, not shipping. The kernel access-check, ETW, and RPC ACLs all carry an agent SID distinct from the user SID. Every event the kernel emits gets a SubjectAgentSid field next to the existing SubjectUserSid. The access check is a three-way intersection: user SID, package SID, agent SID. Capability SIDs gate per-resource consent the way they do today for UWP apps.

Pros: native attribution at every layer. EDR products read the agent SID directly from the kernel-supplied event header. File-system DACLs gain an explicit "deny the agent, allow the user" expression. On-device Conditional Access can refuse to release a DPAPI-protected secret if the requesting process carries an agent SID that has been revoked in Entra. Cons: requires a kernel-level change and a packaging story for non-MSIX agents (Electron in particular, the dominant deployment pattern). Without the packaging story, the kernel substrate exists but the deployment substrate does not.

7.3 Token broker

WAM extended with an agent-scoped token cache. The OS holds agent-scoped, attenuable tokens that any local agent process must mint from before calling a downstream API. The principal in the OS is still the user, but the token the agent presents to each downstream consumer is scoped to the agent.

Pros: reuses existing WAM plumbing [@ms-learn-wam]. WAM already binds refresh tokens to the device's TPM. Adding an agent-scope cache is plumbing, not architecture. Cons: cooperative. A malicious or buggy agent can bypass the broker and fall back to the user's TGT in the local Kerberos cache, the user's DPAPI master keys, or the user's network privileges. The broker can only attribute the agents that choose to be attributed.

A bearer OAuth access token, in OAuth 2.0 and OAuth 2.1, is a credential the bearer presents to a resource server; the server consults the issuer (via introspection or JWT signature verification) and accepts or rejects. Adding a new constraint means going back to the authorisation server and asking for a new token with the new constraint applied. Round-trip required.

A macaroon attenuates without a round-trip. The holder appends a caveat ("only for tool X", "only until 2026-05-25T15:00:00Z", "only with body hash matching sha256:...") and a fresh HMAC of the previous HMAC plus the caveat text. The verifier walks the chain, checks each caveat against its policy, and verifies the final HMAC against the issuer's secret. The holder cannot un-attenuate; the issuer does not have to be online. That property -- attenuation without a round-trip, by any party in the chain -- is what makes macaroons the natural format for per-tool agent capabilities [@macaroons-ndss; @macaroons-gr].

7.4 Three live spec families that complicate the picture

Three protocol families are racing in parallel and the article will not pretend any one is the obvious winner.

Anthropic's Model Context Protocol authorisation profile. Revision 2025-11-25 is the current authoritative profile [@anthropic-mcp-2025-11-25], and the MCP specification index confirms 2025-11-25 as the latest pointer [@anthropic-mcp-index]. The opening sentence makes the design choice explicit: "Authorization is OPTIONAL for MCP implementations. When supported: Implementations using an HTTP-based transport SHOULD conform to this specification. Implementations using an STDIO transport SHOULD NOT follow this specification, and instead retrieve credentials from the environment" [@anthropic-mcp-2025-11-25]. The HTTP profile is OAuth 2.1 [@ietf-oauth-v2-1] plus RFC 9728 [@ietf-rfc-9728] for resource metadata, with PKCE mandatory and dynamic client registration optional.
Google AP2 plus Mastercard Verifiable Intent. The W3C Verifiable Credential-shaped mandate ladder for agent-initiated commerce [@ap2-protocol; @ap2-github; @ap2-cloud-blog; @vi-dev; @w3c-vc-2]. The September 2025 launch vocabulary used Intent / Cart / Payment mandates [@ap2-cloud-blog]; the current v0.2 spec uses Checkout (Open / Closed) and Payment (Open / Closed) [@ap2-protocol]. The April 28, 2026 FIDO donation moves the spec to multi-vendor governance [@ap2-blog-google].
The IETF individual draft for agents on behalf of users. draft-oauth-ai-agents-on-behalf-of-user by Thilina Senarath and Ayesha Dissanayaka [@ietf-draft-agentoauth]. The current revision introduces the requested_actor parameter in authorisation requests and the actor_token parameter in token requests to authenticate the agent during code-to-token exchange [@ietf-draft-agentoauth]. The original -00 revision used requested_agent and defined an explicit grant type urn:ietf:params:oauth:grant-type:agent-authorization_code [@ietf-draft-agentoauth-00]; the parameter rename is documented and recent. The draft is an individual submission, not yet a working-group document.

Position	Principal lives in	Token format	Revocation surface
Cloud-only (Entra Agent ID + RFC 8693)	Entra directory	JWT with `act` claim	Sign-in policy + CAE
OS-only (hypothetical AgentPrincipal)	Kernel access token	Token-resident SID	Local SID purge + Defender
Token broker (WAM extended)	WAM cache (TPM-bound)	Macaroon or signed capability	WAM eviction + macaroon allow-list
MCP authorisation profile	MCP server's IdP	OAuth 2.1 bearer	OAuth introspection
AP2 plus Verifiable Intent	Mandate issuer	SD-JWT VC chain	Mandate revocation registry
IETF agent-OBO draft	Authorisation server	JWT with `actor_token`	OAuth introspection

Key idea: Most of the primitives exist on Windows today: AppContainer package SIDs, Kerberos S4U2Proxy, WebAuthn and Windows Hello, TPM 2.0 Direct Anonymous Attestation, the Administrator-Protection separate-session pattern, WAM, ETW. What does not exist is the coherent glue -- a kernel-recognised AgentPrincipal that downstream consumers treat as first-class. The article's position is that agent identity belongs at both the cloud layer and the OS layer, with the OS layer being the missing piece in May 2026. The cloud layer makes Conditional Access work; the OS layer makes endpoint detection work; both are necessary; neither is sufficient.

Even the union of all three positions has structural ceilings. What are the limits no engineering can buy?

8. Three ceilings no engineering can buy

Three structural ceilings constrain every agent-attribution architecture, regardless of which of the three positions wins.

8.1 The semantic-intent ceiling

No cryptographic primitive can distinguish "the user wanted the agent to delete this file" from "the user wanted to delete this file" once both calls go through the same syscall. The OS sees bytes, not intent. The strongest architecture binds each intent to a fresh user-verification gesture (passkey plus Hello); at the limit, this requires one gesture per syscall, which is operationally unusable. The practical optimum is batched intent traded off against granularity of audit: the user authorises a session-scoped delegation ("for the next 20 minutes, this agent may modify files under .\old-builds"), the system mints a macaroon attenuated to that scope, and the audit log records the macaroon issuance plus every syscall it gates. The intent is bounded by the scope of the gesture; the audit reconstructs intent after the fact from scope plus action.

8.2 The Confused-Deputy ceiling

Hardy 1988, in the verbatim formulation that began the genealogy. "The fundamental problem is that the compiler runs with authority stemming from two sources. (That's why the compiler is a confused deputy.) ... The compiler had no way of expressing these intents!" [@hardy-caplore]. Any system that grants a deputy ambient authority -- authority derived from multiple sources without the deputy being able to name which authority it intends to exercise for a given action -- is structurally susceptible to confused-deputy attacks. Capability-style attenuation (macaroons, capability SIDs in AppContainer) mitigates by forcing the deputy to name the authority on every call; it does not eliminate, because a deputy that holds two authorities can be tricked into presenting the wrong one if the protocol does not require the relying party to verify the intent.

8.3 The "running as the user" ceiling and the MSRC servicing-criteria rule

As long as the agent process runs under the user's primary token, the agent inherits the user's TGT, the user's DPAPI master keys, and the user's network privileges by construction. That inheritance is what makes attribution collapse. The proposed remedy in Section 6 is an AgentPrincipal that lives next to the user SID in the same token. The remedy depends on whether the Windows Security Response Center treats user-versus-agent as a defended security boundary.

The MSRC servicing criteria document defines the boundary taxonomy. The verbatim opening: "Does the vulnerability violate the goal or intent of a security boundary or a security feature? ... A security boundary provides a logical separation between the code and data of security domains with different levels of trust" [@ms-msrc-servicing]. The same document gives the kernel-mode-versus-user-mode separation as the canonical example of a security boundary, and that example is the article's anchor for what counts as a security boundary under current MSRC policy. By inference from the boundary taxonomy table, within the same logon session and the same primary token, a defect that requires the attacker to already be running as the user does not, by default, constitute a violation of a security boundary -- it is, under the criteria, a defense-in-depth concern rather than a CVE-eligible servicing event.

The MSRC document is the governance object that fixes the rule. For an OS-level `AgentPrincipal` to be a defensible boundary -- and therefore for an agent-bypass to qualify as a CVE-eligible servicing event -- the document itself would have to be amended to add the user-versus-agent split to the boundary taxonomy.

That is not an engineering ask. It is a governance ask. Microsoft has amended the document before (AppContainer was added to the security-boundary list during the Windows 10 era; Win32 App Isolation is built on the foundation of AppContainers, "which is recognized as a security boundary by Microsoft" [@ms-blogs-win32appiso]). The amendment is possible. It is not obviously imminent. As of May 2026 the MSRC document does not contain agent-related boundary language.

That third ceiling lands the shift. The deepest part of the gap is not engineering -- it is policy. The engineering substrate is more or less in place; the governance posture is not. An OS-level AgentPrincipal either becomes a new defended boundary (a major policy shift) or ships as a feature without boundary semantics (no CVE eligibility for agent-bypass). The Confused-Deputy ceiling is the structural mirror of the same observation: the only mitigation a deputy can perform is to name the two authorities at the access-check, which is what AgentPrincipal would do.

Given the structural ceilings, what specifically is still open in May 2026?

9. Seven open problems

Seven numbered, unsolved problems as of May 2026. None of them are blocked by physics; all of them are blocked by some combination of plumbing, packaging convention, and policy.

Note: The state-of-the-art inventory this article rests on names seven open problems; an earlier pass listed six and missed the methodological one (no shared cross-method benchmark). The seventh is restored at the end of this section, and three of the existing problems (cross-process delegation, signed-binary harvesting, and the DAA deployment chain) are walked through in worked-example form using kernel and TPM primitives the prior sections have named.

9.1 The Electron and Win32 packaging gap

Claude Desktop, ChatGPT Desktop, and Cursor are Electron and NSIS-installed apps; GitHub Copilot CLI is a Node.js CLI distributed via npm, WinGet, or MSI. None of them ships as MSIX. The package SID surface from AppContainer does not reach them; nothing in their primary token marks them as an agent class. Win32 App Isolation [@ms-blogs-win32appiso] is the in-flight retrofit -- adoption among agent vendors three years after the public preview is minimal. Until the dominant agent vendors ship under MSIX or Win32 App Isolation, the only kernel-level identifier the Pillar 2 substrate can grab onto does not exist for the agents readers actually have installed.

9.2 Cross-process delegation: a worked example

The failure mode lives at the kernel layer and is invisible from the source code of the agent. Claude Desktop on Windows 11 24H2 is a non-MSIX, NSIS-installed Electron binary whose primary process runs under the user's primary token. When that process calls CreateProcessW(L"powershell.exe", L"-NoProfile -Command \"Remove-Item ...\"", ...) to shell out, the kernel side of NtCreateUserProcess calls PspAllocateProcess, which calls into the security reference monitor to assign a primary token to the child. By default -- when the caller passes neither a replacement token through CreateProcessAsUserW nor a PROC_THREAD_ATTRIBUTE_SECURITY_CAPABILITIES entry in STARTUPINFOEX::lpAttributeList -- the kernel duplicates the parent's primary token verbatim. Microsoft Learn is explicit: "The new process runs in the security context of the calling process" [@ms-learn-createproc]. The child inherits the user's SID, the user's group SID list, the user's privileges, the medium integrity level, and the per-session logon SID. No TokenAppContainerSid is present (GetTokenInformation(..., TokenIsAppContainer, ...) returns zero); no TokenPackageClaims field is present. There is no field anywhere in the child's primary token that distinguishes "this PowerShell child was launched by Claude Desktop" from "this PowerShell child was launched by Notepad."

The rule that does work for packaged parents -- and the cliff at the unpackaged boundary -- are both in Microsoft Learn for legacy-application AppContainer behaviour: "When an unpackaged process running in an app container calls CreateProcess, the child process typically inherits the parent's token. That token includes the integrity level (IL) and app container info" [@ms-learn-appcontainer-legacy]. For an MSIX-packaged parent like Microsoft Copilot for Windows, the kernel propagates the TokenAppContainerSid and capability list to the child [@ms-learn-msix-container]. For an unpackaged Electron parent, the rule does not fire because there is nothing to propagate; even for the packaged parent, the package SID identifies the package, not an agent role. The semantics the article calls for -- "this child is acting on behalf of the user, and the agent making that decision is X" -- has no kernel-layer encoding today.

A hypothetical AgentPrincipal-preserving inheritance rule would extend the existing AppContainer rule. The pseudocode below is illustrative of an unshipped kernel routine; it cannot be executed.

// PspAssignPrimaryTokenWithAgentInheritance (kernel-mode, called by
// NtCreateUserProcess via PspAllocateProcess for the SRM token path).

NTSTATUS PspAssignPrimaryTokenWithAgentInheritance(
    PEPROCESS  ChildProcess,
    PEPROCESS  ParentProcess,
    PTOKEN     ParentToken,
    PSECURITY_CAPABILITIES Caps,
    PIMAGE_SECTION_OBJECT  ChildImage)
{
    PTOKEN ChildToken;
    NTSTATUS s = SeSubProcessToken(ParentToken, &ChildToken);
    if (!NT_SUCCESS(s)) return s;

    // Existing rule (today's kernel): propagate AppContainer SID + caps
    // when the parent token is in an AppContainer.
    if (SeTokenIsAppContainer(ParentToken)) {
        SePropagateAppContainerSids(ParentToken, ChildToken);
    }

    // New rule: AgentPrincipal inheritance with refusal path.
    PTOKEN_AGENT_PRINCIPAL_INFORMATION AgentInfo =
        SeQueryAgentPrincipalInformation(ParentToken);
    if (AgentInfo != NULL) {
        // Child image must be Authenticode-signed and on the
        // AgentSID's per-tool allowlist authored at agent-install
        // time via the FIDO AATWG Pillar 1 ceremony.
        if (!SeImageIsAuthenticodeSigned(ChildImage) ||
            !SeAgentAllowlistContains(AgentInfo->AgentSid,
                                      ChildImage->SignerCertHash)) {
            ObDereferenceObject(ChildToken);
            return STATUS_AGENT_TOOL_NOT_ALLOWED;
        }
        SePropagateAgentPrincipal(AgentInfo, ChildToken);
        EtwWriteAgentChildProcessCreated(
            ParentProcess, ChildProcess, AgentInfo->AgentSid);
    }
    return PsAssignPrimaryToken(ChildProcess, ChildToken);
}

The refusal path is the load-bearing part. Today, CreateProcess from an agent process to any binary the user can execute succeeds. Under the proposed rule, the agent's per-tool allowlist is the access-check boundary: a child image not on the allowlist -- for example, an attacker-dropped payload.exe masquerading as PowerShell -- is refused at the syscall layer, with the refusal landing in ETW as an AgentToolDenied event correlated to the agent SID. Win32 App Isolation already ships an analogous inheritance-with-refusal shape for unpackaged Win32 binaries: the Application Capability Profiler produces a developer-supplied capability profile that the kernel enforces at child-process creation, with unprofiled syscalls failing the same way AppContainer fails capability-bounded calls today [@ms-learn-win32appiso-overview]. The missing piece for the agent case is the agent dimension on the token, not the mechanism.

Note: Even if Windows ships an AgentPrincipal, every agent that shells out to PowerShell, Node, or Python today loses agent-attribution at the child-process boundary, because non-packaged children inherit the user's primary token unmodified. Agent vendors should assume that "shell out to a language runtime" is the default attack path; readers writing agent tools should keep operations inside the agent process where possible.

9.3 Revocation latency

Revoking an agent's Entra Agent ID in the cloud should fan out to a Kerberos TGT purge plus local token-cache invalidation plus a WAM cache flush, without logging the user out. The plumbing does not exist on Windows. Continuous Access Evaluation is the closest cloud-side analog -- it can short-circuit access-token reuse against a remote API on the cloud side, but it cannot reach the user's local Kerberos cache or the user's local DPAPI scope.

9.4 MCP authorisation alignment

Every MCP server today runs its own OAuth 2.1 plus RFC 9728 PRM dance [@anthropic-mcp-2025-11-25]. The OS-side agent principal has no role; per-tool authorisation lives above the OS and is invisible to ETW and Defender. An MCP-aware AgentPrincipal would let the OS surface the per-tool grant chain as part of the access-check audit record, so EDR can correlate an MCP grant to a downstream syscall.

9.5 DAA-for-agent-class deployment: end-to-end

TPM 2.0 Direct Anonymous Attestation can, in principle, prove "this binary is some Claude Desktop" without identifying the specific instance. As of May 2026 no agent vendor uses DAA as an attestation issuer for itself; the deployment glue between Pluton, Azure Attestation Service, and an AATWG Pillar 2 verifier does not exist. The cryptographic substrate is in the TPM; the deployment pipeline that would carry it is not. Working the chain end-to-end clarifies what would have to ship.

Leg 1: the agent vendor as DAA issuer. Anthropic, Microsoft, or Cursor plays the role of DAA Issuer in the canonical three-entity formulation: "The entities are the DAA Member (TPM platform or EPID-enabled microprocessor), the DAA Issuer and the DAA Verifier. The issuer is charged to verify the TPM platform during the Join step and to issue DAA credential to the platform" [@wiki-daa]. The vendor maintains a long-term issuer key pair; the public half is the basename a verifier consults. Discovery is conventionally JSON Web Key Set under OpenID Connect Discovery 1.0, the same mechanism Azure Attestation Service itself exposes for relying parties [@ms-learn-aas-concepts]. No agent vendor publishes such an endpoint today.

Leg 2: the Join step at first run. On first agent launch, a Windows-side broker (a proposed extension to WAM) mediates the Join with the vendor's issuer endpoint. Conceptually, the local Pluton or TPM runs TPM2_CreatePrimary(hierarchy = TPM_RH_ENDORSEMENT, inPublic.type = TPM_ALG_ECDAA, ...) to mint the member key, then TPM2_Commit to produce the ECDAA ephemeral commitments. The vendor issues an ECDAA membership credential -- not a per-device cert; the credential is unlinkable across signatures by construction -- and Pluton stores it in non-volatile memory [@ms-learn-pluton-tpm]. The user's WebAuthn-bound consent (the Pillar 1 evidence) is recorded in the vendor's audit log. The WAM broker has no agent-scoped DAA Join extension as of May 2026.

Leg 3: the Sign step on each agent action. Per-action, Pluton runs TPM2_Commit with the verifier's nonce, then TPM2_Sign(daaMemberKey, message_digest, scheme = TPM_ALG_ECDAA). The WAM broker bundles the ECDAA signature into an Azure-Attestation-Service-style JWT envelope and submits it to the AATWG Pillar 2 verifier endpoint [@ms-learn-aas-overview; @ms-learn-aas-concepts]. The verifier de-serialises the JWT, runs the four-step check from Problem 6 (Authenticode chain plus Pluton EK chain plus measured-boot PCRs plus application-load PCR) plus the ECDAA verification. The verifier learns "some Anthropic Claude Desktop is making this request" but not which device; two consecutive actions from the same agent on the same device are cryptographically indistinguishable from two actions on different devices. The Azure Attestation Service policy engine does not carry an "agent-class membership" claim type that downstream Conditional Access can consume as a signal today.

The deployment gap, taken together, is integration rather than algorithm. Every primitive exists in the TCG TPM 2.0 specification, in the Azure Attestation Service engine, and in the WAM broker. Nobody has glued vendor-issuer plus Pluton-member plus WAM-broker plus AAS-verifier into a shipping pipeline. The corpus's sibling DAA article carries the verbatim TCG protocol detail; this section anchors the deployment chain to the Windows-side primitives Microsoft documents.

9.6 Signed-binary harvesting: a worked example

An attacker who steals a legitimately signed agent binary inherits any AgentPrincipal that would otherwise be granted to that binary -- unless attestation is bound to runtime state, which DAA alone cannot provide. The attack is the Stuxnet-class supply-chain pattern, generalised to the agent case.

The attacker compromises Anthropic's signing infrastructure -- the private-key custodian for the EV code-signing certificate, or the build pipeline that calls the custodian. The historical precedent for this exact attack shape is the 2010 Stuxnet incident, in which two distinct Authenticode driver-signing certificates were exfiltrated from JMicron Technology Corp and Realtek Semiconductor Corp (both VeriSign-issued) and used to produce kernel drivers Windows accepted as legitimate [@wiki-stuxnet]. The attacker now produces claude-desktop-evil.exe with the Anthropic Subject Name signed by the legitimate private key; wintrust.dll!WinVerifyTrust returns S_OK. To every existing Authenticode consumer -- App Control for Business publisher rules, AppLocker publisher conditions, Defender signer-based exclusions -- the malicious binary is indistinguishable from the legitimate Claude Desktop. If a hypothetical AgentPrincipal is bound to the install-time Authenticode signature alone, Windows mints the same AgentSid for the malicious binary; the audit trail still reads "Claude Desktop did X" because the binary cryptographically is Claude Desktop as far as the load-time check can tell.

The remediation runs through Pluton's measured-boot chain plus Azure Attestation Service. Microsoft Pluton "provides hardware-based root of trust, secure identity, secure attestation, and cryptographic services" [@ms-learn-pluton]; secure attestation is exactly the role this attack requires. Pluton-rooted attestation is a TPM 2.0 TPM2_Quote over a selected set of Platform Configuration Registers signed by an Attestation Identity Key whose endorsement chain terminates at Pluton's manufacturer-burned Endorsement Key [@ms-learn-pluton-tpm]. The PCRs that matter for distinguishing the legitimate Claude Desktop from claude-desktop-evil.exe are PCRs 0 through 7 (UEFI firmware, Option ROMs, boot manager, Secure Boot policy -- the pre-OS measured-boot range per the TCG PC Client Platform Firmware Profile), PCR 11 (BitLocker and the OS loader application code path, into which ELAM and kernel-mode driver measurements extend on Windows), and an application-extend PCR (PCR 12 in many shipping configurations, sometimes a virtual PCR via the TPM Base Services or VBS) carrying the SHA-256 of the on-disk agent image plus the cumulative hash of in-process module loads. The wire format the verifier evaluates is the Azure-Attestation-Service JWT envelope [@ms-learn-aas-overview; @ms-learn-aas-concepts].

The AATWG Pillar 2 verifier performs four cascaded checks in order. (1) Authenticode chain valid -- the agent binary's image hash is covered by an Authenticode signature whose chain terminates in a trusted root; this is the only check today. (2) Pluton EK chain valid -- the AAS-issued JWT was signed by an AIK whose endorsement chain terminates at a Microsoft-issued Pluton EK certificate, proving the quote came from real hardware. (3) Measured-boot PCRs in known-good set -- PCRs 0 through 11 match a reference value for the user's claimed device class and OS build (Windows 11 24H2, Secure Boot on, VBS on). (4) Application-load PCR matches the published-by-vendor measurement -- PCR 12 matches the hash the agent vendor published in a verifier-discoverable channel for the legitimate release. Step (4) is the runtime-state binding. The attacker now needs either to compromise the vendor's published-hashes channel in addition to the signing key, or to compromise the user's Pluton-rooted measured-boot chain in addition to the signing key. Both are strictly stronger compromises; both raise the attacker's cost by a hardware-vs-software factor. No agent vendor publishes the application-load-PCR reference channel today; the AATWG Pillar 2 verifier reference implementation does not exist.

9.7 Agent-identity benchmark gap

No published peer-reviewed benchmark suite compares the cloud, OS, and broker positions on a common agent-attribution workload as of May 2026. The closest available empirical results are vendor-internal: AP2 v0.2 demo measurements published with the September 2025 cloud.google.com launch and the subsequent ap2-protocol.org release notes [@ap2-cloud-blog; @ap2-protocol]; Microsoft Build 2025 session telemetry for WAM Token Protection latency [@ms-learn-wam]; RFC 8693 OAuth Token Exchange implementations measured in IEEE / ACM / USENIX venues since 2019 [@ietf-rfc-8693] but in non-agent configurations. None of these is a comparison; all are baselines.

The absence matters at two levels. Practitioners deploying an agent stack in 2026 cannot make principled latency, scale, or audit-completeness tradeoffs across the seven methods catalogued in Section 7 without a shared harness; a cloud-managed enterprise running Entra Agent ID plus RFC 8693 plus MCP cannot compare its per-action token-mint latency against a competing WAM-extended deployment without rerunning both stacks under the same workload. At the literature level, the field has named its primitives, sketched its composition rules, and assembled its wire formats but has not yet produced shared evaluation workloads.

A public AATWG-blessed benchmark would have to measure four axes matching the four distinct architectural moves the article catalogues: per-action token-mint latency from agent decision to capability-token presentation; ETW event volume per agent action and per agent session; attestation chain length (Pluton AIK to AAS JWT to vendor ECDAA to relying-party verify) in the Pillar 2 path; and cross-process-delegation propagation success rate (the §9.2 property -- the fraction of agent-spawned child processes that retain agent attribution end-to-end). The four axes are necessary because the seven methods make incomparable tradeoffs across them, and the only honest cross-method statement today is the negative one: no shared benchmark exists.

10. What to ship today

Six things a Windows engineer or agent vendor can do in May 2026 using only primitives that already ship.

Ship the agent as an MSIX-packaged app to get a stable package SID. The package SID is not an agent principal, but it is the only kernel-level identifier you can rely on today [@ms-learn-appcontainer; @ms-learn-appcontainer-legacy]. Packaging is the precondition for per-package DPAPI scope, capability-gated network egress under Windows Filtering Platform, and any future AgentPrincipal retrofit -- a non-packaged Electron app gets none of these.
Mint agent-scoped tokens from Entra Agent ID rather than letting the agent act under the user's delegated token [@ms-learn-agentid; @ms-learn-agentoauth]. You get Conditional Access on the agent identity, Purview agent-interaction audit fields, and a sign-in log entry distinct from the user's. Available grant types are client_credentials, jwt-bearer, and refresh_token; interactive flows are not supported for agent entities [@ms-learn-agentobo].
Use Kerberos Resource-Based Constrained Delegation rather than unconstrained delegation. Scope the allowed-to-delegate-to list to the specific back-end services the agent legitimately calls [@ms-learn-mssfu]. RBCD inverts the authoring point: the back-end resource names the front-end services it accepts delegation from, which is the right authoring point when the agent population changes faster than the back-end population.
Route agent tool invocations through an MCP server with the 2025-11-25 OAuth 2.1 plus RFC 9728 PRM authorisation profile enabled [@anthropic-mcp-2025-11-25; @ietf-rfc-9728; @ietf-oauth-v2-1]. Do not rely on the user's logon credentials at the tool layer. Each tool grant is then explicit, scoped, and revocable independently of the user's session.

Note: The cost of MSIX packaging is paid once, at install-time, and the cost of leaving the Electron user-DPAPI scope alone is paid forever. Every future agent-attribution retrofit -- per-package DPAPI scope, capability-gated network egress, an AgentPrincipal token field -- depends on the package SID being there to attach to. Pay the install-time cost.

Treat every locally stored agent secret as a user-DPAPI-scope liability for Electron-wrapped agents. Any other process under the same user can decrypt it. If isolation matters, store the secret in a Virtualisation-Based Security trustlet behind Credential Guard, in an AppContainer per-package DPAPI scope, or in a Pluton-backed key. The substrate exists; the decision is whether to use it.
Subscribe to the FIDO Alliance AATWG and Payments TWG mailing lists [@fido-aatwg-pr; @fido-aatwg-landing]. Wire formats are in flight; deployment characteristics will not be settled until at least H2 2026. The mailing-list traffic is the cheapest signal you can get on what the agent-protocol wire format will look like in 2027.

Open an elevated PowerShell prompt and run `whoami /all`. You will see the primary user SID, the group SIDs, the integrity-level overlay, and the enabled privileges that your shell process is currently running with -- the exact data structure the kernel reads on every `SeAccessCheck` call.

If you have an MSIX-packaged AppContainer process available (the Microsoft Store apps are the easiest source), run Get-AppxPackage | Select Name, PackageFamilyName, SignatureKind and then Get-AppxPackage <Name> | Get-AppxPackageManifest to see the capability list. The capability SIDs that show up in the manifest are the per-resource gates that AppContainer adds on top of the package SID. There is, today, no analogous whoami /agent command. That absence is the gap.

The first RunnableCode block gives a hands-on feel for the shape of a primary token's principal set and what the proposed AgentPrincipal would add. The second demonstrates macaroon attenuation so the chained-HMAC construction stops being abstract.

{` // Conceptual model of a Windows access token, as whoami /all would print it. // On a non-AppContainer process today there are user/group SIDs but no // package SID and no proposed AgentPrincipalSid. const tokenToday = { primaryUserSid: 'S-1-5-21-3623811015-3361044348-30300820-1013', groupSids: [ 'S-1-5-21-3623811015-3361044348-30300820-513', // Domain Users 'S-1-5-32-545', // BUILTIN\\Users 'S-1-5-11', // Authenticated Users ], packageSid: null, // not in an AppContainer agentPrincipalSid: null, // proposed in this article; not in any shipping build integrityLevel: 'Medium', };

// Same agent process under the proposed seventh-generation token shape. const tokenWithAgentPrincipal = Object.assign({}, tokenToday, { packageSid: 'S-1-15-2-2756086904-3023256918-1882200006-3954548928-2786400166-3567463568-3801030027', agentPrincipalSid: 'S-1-15-7-1001-AGENT-CLAUDE-DESKTOP', integrityLevel: 'Low', });

function summarise(label, t) { console.log('--- ' + label + ' ---'); console.log('Primary user SID: ' + t.primaryUserSid); console.log('Package SID: ' + (t.packageSid || '(none)')); console.log('Agent SID: ' + (t.agentPrincipalSid || '(none)')); console.log('Integrity: ' + t.integrityLevel); }

summarise('Token today (Electron Claude Desktop under user logon)', tokenToday); summarise('Token after the seventh generation', tokenWithAgentPrincipal); `}

{` // Conceptual macaroon: each caveat is bound by a fresh HMAC over the prior // HMAC plus the caveat text. The holder can only attenuate; never expand. const crypto = { hmac(key, msg) { // Toy mixing function, not cryptographic. Real macaroons use HMAC-SHA256. let h = 2166136261; const data = String(key) + '|' + String(msg); for (let i = 0; i < data.length; i++) { h = Math.imul(h ^ data.charCodeAt(i), 16777619); } return ('00000000' + (h >>> 0).toString(16)).slice(-8); }, };

function mint(rootKey, identifier) { const sig = crypto.hmac(rootKey, identifier); return { id: identifier, caveats: [], sig }; }

function attenuate(macaroon, caveat) { const nextSig = crypto.hmac(macaroon.sig, caveat); return { id: macaroon.id, caveats: macaroon.caveats.concat([caveat]), sig: nextSig, }; }

function verify(rootKey, macaroon) { let sig = crypto.hmac(rootKey, macaroon.id); for (const c of macaroon.caveats) { sig = crypto.hmac(sig, c); } return sig === macaroon.sig; }

const ROOT = 'agent-issuer-root-secret-123'; const m0 = mint(ROOT, 'agent-claude-desktop-session-42'); const m1 = attenuate(m0, 'tool = filesystem.read'); const m2 = attenuate(m1, 'path-prefix = C:\\Users\\parag\\projects'); const m3 = attenuate(m2, 'expires-at = 2026-05-25T15:00:00Z');

console.log('Base verified: ' + verify(ROOT, m0)); console.log('Three-caveat chain: ' + verify(ROOT, m3));

// Holder cannot un-attenuate. A holder who tries to drop a caveat would // have to compute the prior signature, which requires the issuer's secret. const tampered = { id: m3.id, caveats: m3.caveats.slice(0, 2), sig: m3.sig }; console.log('Tampered (verify): ' + verify(ROOT, tampered)); `}

Six things you can do today; eight misconceptions you can stop carrying.

11. Misconceptions and practical concerns

Entra Agent ID solves the cloud-side half. It gives an agent a directory entry, a sign-in log, a Conditional Access surface, and a token-exchange path under `client_credentials`, `jwt-bearer`, and `refresh_token` grants [@ms-learn-agentid; @ms-learn-agentoauth]. What it does not do is reach inside the operating system. A locally-installed agent with an Entra Agent ID still calls the Windows file-system API under the user's primary token, decrypts user-DPAPI blobs as the user, and impersonates over RPC as the user. The OS-side attribution stays collapsed even when the cloud-side attribution is clean. Both layers are necessary; neither is sufficient. The Microsoft On-Behalf-Of flow [@ms-learn-obo-flow] and RFC 8693 Token Exchange [@ietf-rfc-8693] solve the *back-end-to-back-end* delegation problem: a web API can call another web API as the user. They do not address desktop attribution. When the user's Microsoft 365 Copilot client (running on the user's desktop as the user) calls a downstream API, the cloud-side token carries the actor claims; the desktop-side process still runs under the user's primary token, and the OS-side audit trail still records the user as the syscall principal. OBO is the cloud answer to a different question. The package SID is part of the agent attribution story, but it does not by itself constitute agent attribution. The verbatim Microsoft Learn rule is that "the permitted access is the intersection of that granted by the user/group SIDs and AppContainer SIDs" [@ms-learn-appcontainer]. That gives the access-check a way to restrict the package's authority below the user's; it does not give downstream consumers a way to distinguish "this package is an AI agent acting on a separable principal" from "this package is a UWP weather app." Treating the package SID as the agent principal also fails at the boundary every Electron-wrapped agent crosses today: those agents are not packaged, so they do not get a package SID at all. NT 3.1 solved *user* attribution. The primary token model, the user SID structure, impersonation, `SeAccessCheck` -- all of these are about distinguishing one user from another and about a thread temporarily speaking as a different identity [@ms-learn-sids]. None of them solved *code* identity (which took until 1996 with Authenticode and was still being refined in 2017 with App Control for Business) and none of them solved *agent* identity (the open problem this article is about). The article must not conflate the three. The 1993 milestone is the foundation; it is also incomplete by design for the question that arrived in 2025. Putting the agent in AppContainer gets you a package SID, a per-package DPAPI scope, capability-gated network egress, and a LowBox token; do this regardless of whether you call it an agent. What AppContainer does not give you is a kernel-level signal that distinguishes agent semantics from app semantics. Defender, ETW, and Conditional Access read package SIDs as package identifiers, not as agent role markers. A full agent-principal answer needs both the AppContainer-style sandbox and a sibling-principal SID that downstream consumers explicitly understand to be an agent identity, separately governed and separately revocable. Administrator Protection is the existence proof that Windows can mint a second logon-session principal for a bounded action under a Hello user-verification gesture. As of May 2026 it is in Insider preview, not generally available; the feature surfaced on Insider builds in late 2025 and subsequent Insider build iterations have continued through 2026 [@ms-techcomm-adminprot]. The architectural pattern -- separate logon session, Hello gesture, scoped to one action -- is exactly the shape the seventh-generation agent principal would take. What it does not do today is generalise to delegation. The System-Managed Administrator Account is scoped to elevation. The agent-principal version would be scoped to "this agent for the duration of this delegated session"; the policy machinery does not yet exist. No. Macaroons attenuate offline: the holder appends a caveat and a fresh HMAC, derives a strictly weaker macaroon, and presents it; the verifier walks the chain. OAuth bearer tokens cannot attenuate without round-tripping the authorisation server, which makes them structurally unfit for an agent that talks to many tools with many different scope shapes [@macaroons-ndss; @macaroons-gr]. See §7.3 for the worked construction. The Windows framing is specific because the article is specifically about Windows. The underlying problem is platform-general. iOS App Attest (`DCAppAttestService`) and the Android per-app UID model are the cross-platform analogs of an OS-level application principal; neither has a published agent-identity story as of May 2026. macOS has its own per-app code-signing and entitlement substrate; it also has no shipping agent-principal model. Linux distributions vary. The fact that Windows ships the AppContainer dual-principal substrate already, plus the Administrator Protection bounded-second-principal existence proof, plus the Pluton-rooted attestation chain, makes Windows the operating system where the seventh-generation answer is most legibly close. It is not a Windows-only problem; it is a problem where Windows is unusually well-equipped to solve it next.

The position the article ends on is the one each prior section pushed toward. As of May 2026 the cloud-identity layer has crossed the agentic-identity gap. The OS layer has not. The substrate primitives are largely in place: AppContainer package SIDs and the LowBox token, Kerberos S4U2Self and S4U2Proxy, WAM with TPM-bound refresh tokens, WebAuthn and Windows Hello with TPM-rooted user verification, TPM 2.0 Direct Anonymous Attestation, the Administrator-Protection separate-logon-session pattern, ETW as an audit channel. The missing piece is a kernel-recognised AgentPrincipal extended from the package-SID substrate, gated by Hello-mediated Verifiable User Instructions, scoped via a macaroon-style per-tool capability layer, audited via an ETW SubjectAgentSid field, and revocable via a CAE-style fan-out that does not require logging the user out. The MSRC servicing criteria document is the governance object that determines whether the seventh generation is a defensible security boundary or a defense-in-depth feature; that document has not been amended.

The question is when, not whether, Windows ships the seventh generation.

Certified Pre-Owned: AD CS and Active Directory's Second Trust Root

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

**Microsoft Certificate Services shipped in Windows 2000 Server on February 17, 2000 and was renamed Active Directory Certificate Services in Windows Server 2008.** Its misconfigurations remained admin-tunable knobs without numbered names for twenty-one years. In June 2021, Will Schroeder and Lee Christensen at SpecterOps published *Certified Pre-Owned* and named eight of them ESC1 through ESC8. Through 2025 the community extended the catalog to ESC16 across IFCR, Compass Security, SpecterOps, TrustedSec, and independent researchers, each one abusing one of six primitives: the template, the issuing authority, the transport, the mapping, the authentication step, or the persistence substrate. Two ESCs have cleanly received CVE-class Microsoft patches (EKUwu / ESC15 -> CVE-2024-49019; ESC8 received KB5005413 *hardening guidance* rather than a CVE, and the adjacent Certifried CVE-2022-26923 patches the dNSHostName impersonation chain on the Machine template rather than a numbered ESC); the rest are administrative hardening matters per Microsoft's Windows Security Servicing Criteria. The KB5014754 strong-mapping rollout closed ESC9 and ESC10 but is bypassed by ESC16. The architectural property -- that every CA in NTAuth is a key parallel to krbtgt that can mint a Domain Admin authenticator -- is not closable by any patch. The operational playbook is to run Locksmith, BloodHound CE, MDI, PSPKIAudit, and Certipy in parallel, ingest CA logs, and prepare a Lane-3 CA rebuild before you need it.

1. Two Hours, No KRBTGT, No Touch on Tier Zero

The operator's stopwatch reads two hours and seven minutes when the SOCKS proxy lights up with a Ticket-Granting Ticket for the Domain Administrator account. No service was crashed. No LSASS process was touched. No Tier-Zero principal had its password reset. The krbtgt account hash from last quarter's rotation is still good. The certificate that minted the ticket was issued, signed, and logged by the enterprise's own Certificate Authority -- the one the IT director's slide deck calls "internal PKI" -- against a template the help desk uses to enroll Wi-Fi clients.

Walk the chain backwards. The operator joined Domain Users four hours ago via a phishing payload that never escalated past medium integrity. They ran one tool. Certipy find enumerated every certificate template the foothold account was permitted to enroll in [@certipy-gh]. One of those templates -- call it WiFi-Auth -- had three properties: low-privilege enrollment open to Authenticated Users, the Client Authentication Extended Key Usage attached, and the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT bit flipped on. Certipy req produced a Certificate Signing Request that supplied DOMAIN\Administrator as the Subject Alternative Name. The Enterprise CA, doing exactly what its template configured it to do, issued the certificate. Certipy auth -pfx exchanged the certificate for a TGT via the Public Key Cryptography for Initial Authentication extension to Kerberos. Mimikatz ptt loaded the TGT into the operator's session. Domain Admin.

What did not fire is the part that frustrates the incident response team. There was no Windows Event 4624 for the Administrator account anywhere on the domain. Microsoft Defender for Identity raised no lateral-movement alert. No Pass-the-Ticket detection triggered, because the ticket was minted as fresh PKINIT authentication, not replayed. The only artifact in the entire chain was a single Event ID 4886 in the CA's issuance log -- the event the SOC's SIEM does not ingest, because the SOC's SIEM was built to follow krbtgt and not to follow PKI.

RFC 4556's Public Key Cryptography for Initial Authentication in Kerberos. The protocol extension that lets a Kerberos client present a certificate to a Key Distribution Center and receive a Ticket-Granting Ticket in return. Authored by L. Zhu (Microsoft) and B. Tung (Aerospace), published in June 2006 [@rfc4556]. PKINIT is the authentication step that converts an issued certificate into a TGT, and therefore the step every ESC must cross to convert a misconfigured template into Domain Admin.

The TGT in this scenario is produced by Active Directory's Key Distribution Center after it validates the certificate against its trusted certificate stores. The KDC does not call back to the CA -- it trusts any certificate signed by a CA published into the forest's NTAuthCertificates container. That trust relationship is the load-bearing detail; we will return to it in section eight.

So how is any of this possible? The operator's organization rotated krbtgt twice last quarter, runs a top-quartile EDR product, and bought Microsoft Defender for Identity with the AD CS sensor add-on. The simple answer is: rotating krbtgt closes one of the keys that can mint a Domain Admin authenticator in this forest. It does not close the others. The forest has more than one such key, and nobody told the IR plan.

Key idea: Every domain whose CA can issue authentication certificates has two trust roots that can mint a Domain Admin authenticator, not one. The first is the krbtgt account hash. The second is the private key of any Certificate Authority published into the forest's NTAuthCertificates container. Rotating one does not touch the other. The catalog this article walks through is the community's attempt to enumerate the misconfigurations that turn the second trust root into a path low-privilege users can walk.

The vocabulary for this surface -- the named techniques, the numbered identifiers, the tool that enumerates them in eleven seconds -- did not exist until June 2021. The misconfigurations did. They had been shipping as customer-tunable knobs in Microsoft's identity stack since Windows Server 2003. If this surface has been available for twenty-one years, why did it take twenty-one years for someone to give the misconfigurations names?

2. Twenty-One Years of Unnamed Knobs

February 17, 2000. Windows 2000 Server reaches general availability. Microsoft Certificate Services -- the AD-integrated CA role -- ships as an optional server component on day one [@wikipedia-w2k]. The role is not yet called Active Directory Certificate Services; that rename arrives with Windows Server 2008. The shipping defaults that the operator in section one just exploited were already buildable on the 2000 release.

You will see both anchor dates in the literature. Semperis's CVE-2022-26923 retrospective writes that "In Windows Server 2008, Microsoft introduced AD CS" [@semperis-cve]. The Microsoft Learn current overview describes AD CS as a "Windows Server role for issuing and managing public key infrastructure (PKI) certificates" [@msl-adcs-current] without distinguishing the ship date from the rename date. This article uses the dual anchor: the role *shipped* in 2000 as Microsoft Certificate Services, and was *renamed* Active Directory Certificate Services in 2008. The misconfigurations the ESC catalog enumerates were enabled by Windows Server 2003's V2 templates and have not been default-off since.

The misconfigurations the catalog later attacks did not all arrive at once. Three Microsoft releases between 2000 and 2008 built the surface piece by piece.

Windows Server 2003 (general availability April 24, 2003 [@wikipedia-ws2003]) shipped Version 2 (V2) certificate templates, user and computer autoenrollment over the V2 schema, and the AD-stored template store [@msl-ws2003-ca]. Most of the surface ESC1 and ESC4 later attack first appears in this release: msPKI-Certificate-Name-Flag, the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT bit, per-template DACLs editable in Active Directory Sites and Services, and the modifiable Extended Key Usage list. The Enrollee-Supplies-Subject flag, in particular, is a customer-tunable bit; it ships off by default on the stock templates but is a one-click enable in certtmpl.msc [@msl-adcs-2012r2]. Microsoft's documentation warned against it on sensitive templates. It did not warn against it as a numbered identifier.

Certificate templates have version numbers tied to the Active Directory schema. V1 templates ship with Windows 2000 and are non-modifiable from the GUI. V2 templates ship with Windows Server 2003 and are fully modifiable; they introduce the per-template DACL and the editable msPKI-Certificate-Name-Flag properties the catalog attacks. V3 templates ship with Windows Server 2008 and add Suite B cryptography support. The catalog mostly attacks V2 templates; ESC15 specifically attacks the residual V1 templates that ship pre-installed and cannot be removed.

Windows Server 2008 (general availability February 27, 2008 [@wikipedia-ws2008]) renamed the role to Active Directory Certificate Services and added new role services: Online Certificate Status Protocol Responder, Network Device Enrollment Service, Certificate Enrollment Web Service, and Certificate Enrollment Policy Web Service. These role services expanded the transport surface that ESC8 and ESC11 later attack. The Windows Server 2012 R2 documentation page hh831740 became the canonical reference SpecterOps later linked from the 2021 paper [@msl-adcs-2012r2].

Between 2008 and 2021 Microsoft published hardening guidance for AD CS in several places -- Test Lab Guides, PKI design pages, role-service deployment docs [@msl-pki-design]. The guidance covered template ACLs, manager approval, least-privilege enrollment, and the Enrollee-Supplies-Subject bit. It did not assign numbered identifiers to specific dangerous combinations. It did not appear in MSRC's vulnerability pipeline. It did not get a Common Vulnerabilities and Exposures registration. The configurations were documented but unnamed.

In 2019, two seeds for the named class appeared. Géraud de Drouas at the French ANSSI published a brief GitHub note that the Active Directory Public-Information property set includes altSecurityIdentities, which lets an attacker with that permission map their own certificate onto a privileged user [@dedrouas-altsec]. The note ends with a striking line: "This issue has been responsibly disclosed to MSRC and received a 'won't fix' response." The same year Microsoft began documenting the szOID_NTDS_CA_SECURITY_EXT extension in certificate-related KBs, though without making it default-on. The substrate for what would become ESC9, ESC10, and ESC14 was already in place; nobody had named it yet.

Twenty-one years from the role's ship date, then. Twenty-one years of admin-tunable knobs. No numbered identifiers, no patch cadence, no scanner enumeration, no MSRC pipeline. Microsoft documented every one of these settings individually, often well; what was missing was the catalog. Hardening guidance without numbered identifiers produces no defensive prioritization in real enterprises, because enterprise security programs prioritize against catalogs, not against documentation pages [@bollinger-ekuwu]. So what happened in June 2021 that turned a documentation pattern into a catalog?

flowchart LR A[2000
Microsoft Certificate Services
ships in Windows 2000 Server] --> B[2003
V2 templates
and autoenrollment] B --> C[2008
Role renamed
Active Directory
Certificate Services] C --> D[2019
de Drouas notes
altSecurityIdentities abuse] D --> E[June 2021
SpecterOps catalog
ESC1 through ESC8] E --> F[2021 to 2022
KB5005413
CVE-2022-26923
KB5014754] F --> G[2022 to 2023
ESC9 to ESC12
from Lyak Heiniger Knobloch] G --> H[2024
ESC13 to ESC15
Knudsen and Bollinger
CVE-2024-49019] H --> I[2025
ESC16
strong-mapping full enforcement]

3. Six Primitives Every ESC Abuses

Before opening the catalog, install the vocabulary. Every ESC -- without exception -- abuses one of six primitives: the template, the issuing authority, the enrollment transport, the certificate mapping, the authentication bridge, and the persistence substrate. Once you have these six names in your head, the sixteen ESCs compose into a small grid.

The Template

A certificate template is an Active Directory object stored in the CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration partition that tells an Enterprise CA what kind of certificate to issue and to whom. Templates carry their own DACL controlling who can enroll, who can write, and who can autoenroll. They carry a msPKI-Certificate-Name-Flag attribute whose bits control how the Subject and Subject Alternative Name fields are populated. They carry an Extended Key Usage list that names what the certificate is permitted to do. And they carry a Manager Approval bit that gates whether issuance is automatic or whether a CA officer must approve each request [@msl-adcs-2012r2].

The Active Directory-stored object specifying who can request what kind of certificate from an Enterprise CA. Templates carry per-object DACLs (enrollment, autoenrollment, write), a `msPKI-Certificate-Name-Flag` controlling Subject and SAN behavior, an Extended Key Usage list, and a Manager Approval bit. V1 templates (Windows 2000) are non-modifiable; V2 templates (Windows Server 2003) are fully modifiable; V3 templates (Windows Server 2008) add Suite B cryptography.

ESC1, ESC2, ESC3, ESC4, and ESC15 all attack the template. They differ only in which template property is misconfigured. (ESC9 also begins on a template flag, CT_FLAG_NO_SECURITY_EXTENSION, but its effect lives in the mapping layer; we file it under mapping below, matching SpecterOps's own Certify taxonomy [@specterops-certify-docs-index].)

The Issuing Authority

An Enterprise CA is a Windows Server role service that signs certificate requests against published templates. To be trusted for authentication, the CA must be published into the forest's NTAuthCertificates container. That container is the single list of CA certificates the Key Distribution Center trusts for PKINIT. The CA carries its own security descriptor controlling who can enroll, who can manage certificates, and who can manage the CA itself. It carries two registry flags that change its issuance behavior: EDITF_ATTRIBUTESUBJECTALTNAME2, which permits requesters to specify arbitrary Subject Alternative Names, and IF_ENFORCEENCRYPTICERTREQUEST, which controls whether RPC enrollment requires packet privacy [@compass-esc11]. The 2022 KB5014754 patch introduced szOID_NTDS_CA_SECURITY_EXT, a Microsoft-specific extension carrying the requester's Security Identifier; that extension is the load-bearing artifact of the strong-mapping enforcement track [@kb5014754].

The AD-integrated certificate authority role in AD CS. Publishes certificate templates into Active Directory, processes certificate requests against those templates, and signs issued certificates with its private key. To be trusted for Windows authentication, the CA's certificate must be present in the forest-wide `NTAuthCertificates` container. The AD-published container `CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration` listing CA certificates trusted by the Key Distribution Center for client authentication. Any certificate signed by a CA in this container can, given a valid mapping, mint a Kerberos Ticket-Granting Ticket. Publishing a CA into NTAuth is the moment that CA's private key becomes a trust root parallel to krbtgt.

ESC5, ESC6, ESC7, and ESC16 attack the issuing authority itself -- its DACL, its registry flags, its extension policy. (ESC11's RPC packet-privacy gap is a CA-side configuration, but its abuse is an NTLM relay; we group it with ESC8 under transport, matching the §5 diagram.)

The Enrollment Transport

A certificate is requested over a network protocol. The default transport is DCOM/MS-WCCE -- the Windows Client Certificate Enrollment protocol, an RPC-based interface that ships enabled on every Enterprise CA [@ms-icpr-spec]. Additional transports ship as separate role services: HTTP Web Enrollment (IIS-based, with NTLM auth by default), the Certificate Enrollment Web Service (web service, supports basic and Kerberos), the Network Device Enrollment Service (the SCEP gateway), and the Certificate Enrollment Policy Web Service. Each transport is a network attack surface for relay primitives that route a coerced NTLM authentication into a certificate request.

ESC8 attacks the HTTP Web Enrollment transport. ESC11 attacks the RPC transport. Both are NTLM-relay attacks; they differ only in which transport the relayed authentication targets.

The CA's security model distinguishes two rights that look similar but differ in scope. Issue and Manage Certificates permits the holder to approve pending requests, revoke issued certificates, and read the request store. Manage CA permits the holder to edit the CA's own configuration -- including its registry-controlled extension policy and its DACL. ESC7 attacks the latter. The escalation chain that follows ESC7 typically pivots to ESC4 (edit a template) or to issuing a certificate directly via a CA officer's request-approval right.

The Certificate Mapping

When a CA issues an authentication certificate, the certificate identifies a principal -- a user or a computer. The Key Distribution Center has to decide which Active Directory principal that certificate represents. Two mappings exist. Implicit mapping reads the Subject Alternative Name (or the Subject, on older templates) and looks up the principal by User Principal Name. Explicit mapping reads the AD principal's own altSecurityIdentities attribute, which holds one or more X.509 issuer/serial expressions [@dedrouas-altsec]. The May 2022 KB5014754 patch redefined which mappings the KDC accepts: explicit mappings using X509IssuerSerialNumber, X509SKI, or X509SHA1PublicKey are strong; everything else is weak and will be rejected once Full Enforcement is active [@kb5014754].

OID 1.3.6.1.4.1.311.25.2. The Microsoft certificate extension introduced by KB5014754 that embeds the SID of the requesting Active Directory principal directly into the issued certificate. When present, the KDC matches the certificate against the principal whose SID is embedded, defeating SAN-supply attacks like ESC1. The extension is the load-bearing mechanism of strong mapping enforcement. Per KB5014754, explicit `altSecurityIdentities` entries using the `X509IssuerSerialNumber`, `X509SKI`, or `X509SHA1PublicKey` formats are *strong*. All other formats -- including implicit UPN and SAN matching -- are *weak* and rejected once Full Enforcement mode is active (February 11, 2025 default; legacy-mapping registry override removed September 9, 2025) [@kb5014754]. The strong-mapping track was the single largest Microsoft mitigation of the ESC era.

ESC9, ESC10, ESC13, and ESC14 all attack the mapping. They abuse the gap between what a certificate asserts and which AD principal the KDC binds it to.

The Authentication Step

This component is the part of Windows that turns a certificate into an authenticator. For Kerberos, the protocol is PKINIT (RFC 4556 [@rfc4556]): client presents a cert, KDC validates the cert and the mapping, KDC issues a TGT. For TLS-based services -- LDAPS, RDP with smart card, IIS with client cert -- the protocol is Schannel. For the legacy smart-card pipeline, the path is the combination of the Smart Card Resource Manager and PKINIT.

No ESC attacks this step directly. Every ESC must cross it to convert a misconfigured template, ACL, or mapping into a usable authenticator. The authentication step is the choke point; it is also the point Microsoft has reshaped most heavily with KB5014754.

The Persistence Substrate

An issued certificate is not a transient credential. It is a signed authenticator with a configurable validity period (one year is common, ten years is permitted). The certificate authenticates the embedded principal as long as the certificate is valid and not revoked. That property is what the SpecterOps paper's DPERSIST and THEFT classes attack [@cpo-blog]. UnPAC-the-Hash recovers the NTLM hash from a PKINIT-issued TGT, giving the attacker a password-equivalent credential they did not previously have. The Golden Certificate attack steals the CA's own private key, granting forever-issuance against the entire forest.

This article scopes those attacks to a sidebar; the body walks the ESC1 to ESC16 escalation catalog. But every ESC ends in the persistence substrate: the certificate the attacker walks out with is the receipt that survives password rotation.

Note: A primitive is a Microsoft-shipped knob, flag, ACL, or protocol that, when misconfigured, becomes part of an escalation. An exploitation chain is the specific sequence of operator actions that turns one or more misconfigured primitives into a Domain Admin authenticator. ESCs are exploitation chains, not primitives. ESC1, for example, abuses the template primitive's CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT bit, combined with the bridge primitive (PKINIT), to produce the authenticator. The catalog enumerates chains; the six categories above enumerate the substrate.

Now that the vocabulary is in place, sixteen named attacks compose neatly onto a 6 by 16 grid. Here is the moment they did.

flowchart TD T[Template
per-template DACL
Name-Flag bits
EKU list
Manager Approval] A[Issuing Authority
NTAuth membership
CA security descriptor
EDITF flags
extension policy] X[Enrollment Transport
RPC/MS-WCCE
HTTP Web Enrollment
CES/CEP
NDES/SCEP] M[Certificate Mapping
implicit UPN/SAN
explicit altSecurityIdentities
strong vs weak
SID extension] B[Authentication Bridge
PKINIT for Kerberos
Schannel for TLS
smart-card pipeline] P[Persistence Substrate
validity period
UnPAC-the-Hash
Golden Certificate
CRL bypass] T --> A A --> X X --> B A --> M M --> B B --> P

4. Certified Pre-Owned

Will Schroeder pushes the SpecterOps Medium post live on June 17, 2021. (A revision tagged [EDIT 06/22/21] follows the next week; the literature settles on "June 2021" as the canonical date [@cpo-blog].) The whitepaper PDF drops in the same window and is rehosted on the SpecterOps domain the following year [@cpo-whitepaper]. Seven weeks later, on August 5, Schroeder and Christensen present Certified Pre-Owned: Abusing Active Directory Certificate Services at Black Hat USA 2021. Three GhostPack tools ship to GitHub on schedule: PSPKIAudit for defense [@pspkiaudit-gh], Certify for offense [@certify-gh], and ForgeCert for Golden Certificate work.

The paper names eight escalation paths and three persistence and theft prefixes:

ESC1 through ESC8 -- escalation paths from a low-privilege foothold to Domain Admin
DPERSIST -- domain persistence via forged certificates after CA private-key compromise
THEFT -- certificate and credential theft primitives, including the UnPAC-the-Hash technique
DETECT -- defensive detection primitives the team mapped to each abuse

The contribution was not the discovery of new individual primitives. Most of the individual misconfigurations had appeared in Microsoft's hardening guidance or in scattered community posts well before the paper. ENROLLEE_SUPPLIES_SUBJECT had been a documented warning for a decade. NTLM relay to IIS had been a known attack class since at least 2008. The EDITF_ATTRIBUTESUBJECTALTNAME2 flag was a documented option in certutil since Windows Server 2008 R2. What the paper contributed was the unified catalog -- numbered identifiers, reproducible exploitation, a tool that enumerated each path, and a single document tying every abuse to its primitive and its mitigation.

While AD CS is not installed by default for Active Directory environments, from our experience in enterprise environments it is widely deployed, and the security ramifications of misconfigured certificate service instances are enormous. -- Will Schroeder and Lee Christensen, *Certified Pre-Owned* (June 2021) [@cpo-blog]

Microsoft's response was uncharacteristically fast. KB5005413 published in late July 2021 -- roughly six weeks after the blog -- recommending Extended Protection for Authentication and "Require SSL" on the AD CS Web Enrollment and Certificate Enrollment Web Service role services [@kb5005413]. The KB closes ESC8 over HTTPS when EPA is enabled. It does not close ESC1 through ESC7, and it does not close ESC11 (which had not yet been named).

The "ESC" prefix is an acronym for escalation. The catalog uses three sibling prefixes from the same paper: DPERSIST for domain persistence, THEFT for credential and certificate theft, and DETECT for defensive detection identifiers. ESC numbering is consecutive but not contiguous in time -- ESC12 (a hardware substrate attack) was disclosed by Knobloch in October 2023 [@knobloch-esc12] [@knobloch-esc12-archive], four months before Knudsen disclosed ESC13 and ESC14 from SpecterOps. The numbering tracks the order of community disclosure, not a planned roadmap.

Here is the observation that this article will load-bear: the breakthrough was naming, not discovery. Until SpecterOps named the eight configurations, every one of them had been documented somewhere in Microsoft Learn or in a community blog. The hardening documentation had existed for years and had produced essentially no defensive prioritization in real enterprises. Microsoft Defender for Identity did not flag ESC1 templates. BloodHound did not graph ESC4-shaped DACLs. SIEMs did not ingest CA Event ID 4886. No commercial scanner shipped a rule for the Enrollee-Supplies-Subject bit. The reason was not that the information was inaccessible. The reason was that the configurations had no names -- and an enterprise security program cannot prioritize against an unnamed configuration.

Key idea: Naming is itself a defensive primitive. The 2021 SpecterOps catalog converted twenty-one years of unnamed admin-tunable knobs into a numbered backlog that scanners could enumerate, BloodHound could path-find, MSRC could patch, and operators could prioritize. Every subsequent mitigation generation -- KB5005413, CVE-2022-26923, KB5014754, CVE-2024-49019, BloodHound CE ADCS edges, Locksmith, Microsoft Defender for Identity's posture assessments -- builds on the catalog rather than on the underlying hardening documentation. The catalog is the security primitive; the patches are downstream of the catalog.

Eight ESCs in 2021. Within fifteen months, two researchers extended the catalog past the original boundary: Oliver Lyak at the Institute For Cyber Risk added ESC9 and ESC10 in August 2022 [@lyak-certipy-4-archive]; Sylvain Heiniger at Compass Security added ESC11 in November 2022 [@compass-esc11]. Hans-Joachim Knobloch added ESC12 in October 2023 [@knobloch-esc12]. SpecterOps's Jonas Bülow Knudsen added ESC13 in February 2024 [@knudsen-esc13] and ESC14 two weeks later [@knudsen-esc14]. Justin Bollinger at TrustedSec added ESC15 in October 2024 [@bollinger-ekuwu]. Lyak named ESC16 in 2025 against a workaround Schroeder himself had documented in 2022 [@specterops-esc16-docs]. Sixteen ESCs by the time you read this. Here is what each one does.

5. The Catalog: ESC-1 through ESC-16

Of the sixteen named ESCs, the original eight name the surface; ESC9 through ESC16 name the residual after every Microsoft mitigation shipped to date. We walk them in primitive-grouped order, following the same taxonomy the SpecterOps Certify documentation uses: template misconfigurations, access-control vulnerabilities, CA configuration issues, certificate mapping issues, and one hardware-substrate sidebar [@specterops-certify-docs-index].

Template misconfigurations: ESC1, ESC2, ESC3

ESC1 -- Misconfigured Certificate Template. A V2 template that lets a low-privilege principal enroll, has Client Authentication in its Extended Key Usage list, has CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT set, and does not require Manager Approval. The attacker requests a certificate naming the target principal in the Subject Alternative Name; the CA issues; the certificate maps via UPN to the target; PKINIT produces a TGT as the target. One operator chain: certipy req -u user -p pass -ca CA -template VulnTemplate -upn administrator@domain.local. First disclosed by SpecterOps in June 2021 [@cpo-blog]. BloodHound CE edge: ADCSESC1 [@bh-esc1-edge].

The `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT` bit in `msPKI-Certificate-Name-Flag`. When set, the requester is allowed to supply the Subject or Subject Alternative Name in the CSR rather than having the CA build the Subject from the requester's own AD attributes. This is the load-bearing primitive of ESC1. ```powershell Get-ADObject -SearchBase "CN=Certificate Templates,CN=Public Key Services,CN=Services,$((Get-ADRootDSE).configurationNamingContext)" -Filter * -Properties msPKI-Certificate-Name-Flag, pKIExtendedKeyUsage, msPKI-Enrollment-Flag | Where-Object { ($_.'msPKI-Certificate-Name-Flag' -band 0x1) -ne 0 -and ($_.'msPKI-Enrollment-Flag' -band 0x2) -eq 0 -and ($_.pKIExtendedKeyUsage -contains '1.3.6.1.5.5.7.3.2') } | Select-Object Name ``` The query lists templates with ESS set, no manager approval, and Client Authentication EKU. Locksmith, PSPKIAudit, and Certipy all run a logically equivalent check; this is the smallest reproducible form for an audit script that does not depend on a vendor tool.

ESC2 -- Any-Purpose or Subordinate CA EKU. A template that grants the Any-Purpose EKU (2.5.29.37.0) or the Subordinate CA EKU permits the certificate to be used for arbitrary purposes, including subordinate CA work. The attacker enrolls and then forges new certificates against the issued certificate's keypair. First disclosed by SpecterOps, June 2021 [@cpo-blog]. No BloodHound CE edge; the abuse pattern lives in Certify and Certipy [@certipy-wiki-priv].

ESC3 -- Enrollment Agent Template. A template with the Certificate Request Agent EKU lets the holder enroll certificates on behalf of other users. Combined with a second template flagged "Enrollment Agent" the attacker can request a certificate naming any principal. The chain is two requests rather than one. SpecterOps, June 2021 [@cpo-blog]. BloodHound CE edge: ADCSESC3.

Access-control vulnerabilities: ESC4, ESC5, ESC7

ESC4 -- Vulnerable Certificate Template ACL. Any principal with GenericAll, GenericWrite, WriteOwner, or WriteDacl on a template can modify the template into an ESC1-shaped configuration and then enroll. This converts a write right on a template object into Domain Admin. SpecterOps, June 2021 [@cpo-blog]. BloodHound CE edge: ADCSESC4.The ADCSESC4 edge composes with BloodHound's general DACL graph, so a Domain Users principal that holds WriteDacl on a sensitive template inherits the path automatically without a hand-written query. The edge composes naturally with the rest of BloodHound's principal-DACL graph -- a Domain Users principal with WriteDacl on the template inherits the path.

ESC5 -- Vulnerable PKI Object ACL. The same class of write rights on the CA computer object, the NTAuthCertificates container, or the AIA container. Compromising any of these gates the entire AD CS substrate. SpecterOps, June 2021 [@cpo-blog]. No BloodHound CE edge today; the surface is wide and the operator chain depends on the specific object compromised.

ESC7 -- Vulnerable CA ACL. A principal with the Manage CA right on the Enterprise CA can edit its registry-controlled configuration (including the EDITF_ATTRIBUTESUBJECTALTNAME2 flag, which converts the CA into a global ESC6 condition). A principal with Issue and Manage Certificates can approve their own otherwise-blocked certificate requests. SpecterOps, June 2021 [@cpo-blog]. No BloodHound CE edge; the abuse is a CA-side write rather than an AD principal-graph relationship.

CA configuration issues: ESC6, ESC8, ESC11

ESC6 -- EDITF_ATTRIBUTESUBJECTALTNAME2 on the CA. When this CA-wide flag is set, every certificate request can specify an arbitrary Subject Alternative Name regardless of the template's Name-Flag bits. The CA becomes globally ESC1-shaped against any template the attacker can enroll into. SpecterOps, June 2021 [@cpo-blog]. BloodHound CE edges: ADCSESC6a and ADCSESC6b (the latter for cases where the CA also disables the SID extension).

ESC8 -- NTLM Relay to AD CS HTTP Web Enrollment. The AD CS Web Enrollment role service ships with NTLM authentication enabled and, by default, no Extended Protection for Authentication. An attacker who can coerce a target computer to authenticate (PetitPotam, PrinterBug, DFSCoerce) can relay that authentication to the CA's /certsrv/ endpoint, request a certificate naming the relayed principal, and walk away with a certificate impersonating the coerced computer -- including Domain Controllers. SpecterOps, June 2021 [@cpo-blog]. BloodHound CE graphs this as the CoerceAndRelayNTLMToADCS edge [@bh-coerce-adcs-edge]: a Group-to-Computer edge whose source is Authenticated Users and whose destination is the coerced target computer, with the edge's evaluation conditioned on at least one ESC8-vulnerable Web Enrollment endpoint being reachable on the network.

Note: ESC8 needs no template misconfiguration. It needs a CA with HTTP Web Enrollment role service installed -- common in environments that ever provisioned smart cards or did web-based renewal -- and at least one computer account the attacker can coerce. Microsoft mitigated it with KB5005413 in July 2021 [@kb5005413], but the mitigation is configuration guidance (EPA on, "Require SSL" on, Web Enrollment disabled if unused), not a binary patch. Environments that never enabled EPA on /certsrv/ remain exploitable today. The "Domain Users to Domain Admin in eight minutes" demos that pepper conference talks are usually ESC8 demos.

ESC11 -- NTLM Relay to ICPR/RPC. The ICertPassage RPC interface (the default enrollment transport on every Enterprise CA) enforces packet privacy when the IF_ENFORCEENCRYPTICERTREQUEST flag is set; that flag has been on by default since Windows Server 2012. However, because the flag breaks certificate enrollment for legacy Windows XP clients, Compass Security observed real-world environments where administrators had explicitly removed the flag for compatibility, leaving the RPC enrollment surface unencrypted. When packet privacy is not enforced, an attacker can relay a coerced NTLM authentication into the CA's RPC interface and obtain a certificate impersonating the coerced principal. Disclosed by Sylvain Heiniger at Compass Security, November 2022 [@compass-esc11]. The SpecterOps Certify documentation describes the misconfiguration as "an insufficiently protected certificate authority RPC interface" [@specterops-esc11-docs]. No BloodHound CE edge; the RPC transport is below the principal-graph model.

Certificate mapping issues: ESC9, ESC10, ESC13, ESC14, ESC15, ESC16

ESC9 -- No Security Extension. A template flagged CT_FLAG_NO_SECURITY_EXTENSION instructs the CA to issue certificates without the szOID_NTDS_CA_SECURITY_EXT SID embedding. KB5014754's strong-mapping enforcement then falls back to weak UPN mapping, and the attacker can rename a controlled user account to match a privileged user's UPN, enroll, and authenticate as that privileged user. Disclosed by Oliver Lyak at IFCR on August 4, 2022, twelve weeks after KB5014754 [@lyak-certipy-4-archive]. BloodHound CE edges: ADCSESC9a and ADCSESC9b.

ESC10 -- Weak Certificate Mapping. The registry values StrongCertificateBindingEnforcement (on KDCs) and CertificateMappingMethods (on Schannel servers) control whether weak mappings are accepted. In Compatibility mode (the KB5014754 staged-rollout default through February 11, 2025), weak mappings still pass. An attacker who can write altSecurityIdentities on a target, or who can engineer a weak UPN match, authenticates as the target. Same disclosure: Lyak, August 4, 2022 [@lyak-certipy-4-archive]. BloodHound CE edges: ADCSESC10a and ADCSESC10b.

ESC13 -- Issuance Policy linked to AD Group via msDS-OIDToGroupLink. Active Directory issuance-policy OIDs can be linked to a security group via the msDS-OIDToGroupLink attribute. When a certificate carries that issuance-policy OID, the issued PAC includes the linked group. A template configured with such an issuance policy effectively grants its enrollees membership in the linked group at authentication time. Disclosed by Jonas Bülow Knudsen at SpecterOps on February 14, 2024; discovery credit goes to Adam Burford, who brought the technique to Knudsen and Stephen Hinck [@knudsen-esc13]. BloodHound CE edge: ADCSESC13.

ESC14 -- Explicit altSecurityIdentities Write. A principal with write access to a privileged user's altSecurityIdentities attribute can add their own certificate's X.509 expression to that attribute, then authenticate as the privileged user. The prior art goes back to Géraud de Drouas in 2019 [@dedrouas-altsec] and Jean Marsault at Wavestone in June 2021 [@marsault-wavestone]; Knudsen catalogued it as ESC14 in February 2024 [@knudsen-esc14]. No BloodHound CE edge today; the abuse traces through a write right on a single AD attribute and is in scope for future BloodHound coverage.

ESC15 -- V1 Template Application Policies Override (EKUwu). The pre-installed V1 WebServer template -- which ships on every CA, cannot be deleted, and is enrollable by Authenticated Users by default -- accepts Application Policies extensions in the request. Application Policies, a Microsoft extension parallel to standard EKU, are honored by the KDC. An attacker submits a CSR adding the Client Authentication Application Policy to a WebServer certificate, gets it signed, and authenticates as the requester. Disclosed by Justin Bollinger at TrustedSec on October 8, 2024 [@bollinger-ekuwu]. Microsoft assigned CVE-2024-49019 and patched it on November 12, 2024 [@cve-2024-49019-msrc]. No BloodHound CE edge.

ESC16 -- CA-wide SID Extension Disabled. The CA's DisableExtensionList registry value can list OIDs the CA will omit from issued certificates. If szOID_NTDS_CA_SECURITY_EXT (1.3.6.1.4.1.311.25.2) is on that list, the CA stops embedding the SID extension globally, and the strong-mapping enforcement of KB5014754 collapses into weak mapping for every certificate the CA issues. The SpecterOps Certify documentation records the punchline: "The configuration was first described in 2022 by Will Schroeder in this blogpost as a temporary workaround for the interaction between ESC7 and ESC6, but was later tagged ESC16 by Oliver Lyak" [@specterops-esc16-docs]. No BloodHound CE edge.

ESC12 lives in a different primitive category from every other ESC: it attacks the CA's HSM, not its software configuration. Hans-Joachim Knobloch's October 2023 disclosure (earliest Wayback snapshot dated October 24, 2023) observes that the YubiHSM2 Key Storage Provider on AD CS stores the HSM authentication key in cleartext under `HKEY_LOCAL_MACHINE\SOFTWARE\Yubico\YubiHSM\AuthKeysetPassword` [@knobloch-esc12] [@knobloch-esc12-archive]. A non-administrative user with shell access to the CA and read on that registry key can recover the HSM password and forge certificates against the HSM-backed CA key. Out of body scope for this article; readers running YubiHSM-backed CAs should read Knobloch's primary source.

By the time you reach ESC10 here, a pattern is visible without anyone naming it: every Microsoft mitigation in this class is followed by a new ESC that side-steps it. KB5005413 closes ESC8 over HTTPS; ESC11 routes around it via RPC. KB5014754 closes ESC9 and ESC10 under Full Enforcement; ESC16 disables the underlying SID extension. CVE-2024-49019 closes ESC15 on V1 templates; the V1 templates themselves remain on every CA. The catalog grows faster than the patches.

Of the sixteen entries above, BloodHound CE ships eleven principal-graph edges covering eight distinct ESCs: ADCSESC1, ADCSESC3, ADCSESC4, ADCSESC6a/b, ADCSESC9a/b, ADCSESC10a/b, ADCSESC13, plus the CoerceAndRelayNTLMToADCS edge that graphs ESC8 [@bh-llms]. The remaining eight ESCs (ESC2, ESC5, ESC7, ESC11, ESC12, ESC14, ESC15, ESC16) are out of edge coverage today -- some because their primitive lives below the principal graph (ESC11's RPC transport), some because their abuse is a CA-side write rather than a domain principal relationship (ESC7, ESC5), and some because they are too new to have been edge-modeled (ESC14, ESC15, ESC16). The gap is structural and operationally significant; section eight explores why.

flowchart TD subgraph TEMPLATE[Template] E1[ESC1 ESS+ClientAuth+LowPriv
SpecterOps 2021] E2[ESC2 AnyPurpose/SubCA
SpecterOps 2021] E3[ESC3 Enrollment Agent
SpecterOps 2021] E15[ESC15 V1 AppPolicy
TrustedSec 2024] end subgraph ACL[Access Control] E4[ESC4 Template DACL
SpecterOps 2021] E5[ESC5 PKI Object DACL
SpecterOps 2021] E7[ESC7 CA DACL
SpecterOps 2021] end subgraph CA[CA Configuration] E6[ESC6 EDITF SAN2
SpecterOps 2021] E16[ESC16 Disable SID Ext
tagged Lyak 2025] end subgraph TRANSPORT[Transport] E8[ESC8 Relay to HTTP
SpecterOps 2021] E11[ESC11 Relay to RPC
Compass 2022] end subgraph MAP[Mapping] E9[ESC9 No SID Ext
IFCR 2022] E10[ESC10 Weak Mapping
IFCR 2022] E13[ESC13 OIDToGroupLink
SpecterOps 2024] E14[ESC14 altSecurityIdentities
SpecterOps 2024] end subgraph HW[Hardware] E12[ESC12 YubiHSM Substrate
Knobloch 2023] end

The static rules that Certipy, Certify, Locksmith, and PSPKIAudit all run to decide whether a template is ESC1-shaped are simpler than the catalog above might suggest. Three boolean inputs, three conjunctive conditions, one output label.

{` function classifyTemplate(t) { const ess = t.flags.includes('CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT'); const clientAuth = t.eku.includes('1.3.6.1.5.5.7.3.2'); const lowPriv = t.enroll.some(p => ['Authenticated Users', 'Domain Users'].includes(p)); const noApproval = !t.flags.includes('CT_FLAG_PEND_ALL_REQUESTS'); if (ess && clientAuth && lowPriv && noApproval) return 'ESC1'; return 'safe-for-now'; }

const wifi = { flags: ['CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT'], eku: ['1.3.6.1.5.5.7.3.2'], enroll:['Authenticated Users'] }; console.log(classifyTemplate(wifi)); `}

6. The 2026 Toolchain

Sixteen ESCs is too many for one tool. The 2026 state of the art is a stack: defenders run Locksmith, PSPKIAudit, BloodHound CE, and Microsoft Defender for Identity in parallel; offense runs Certipy and Certify. No single tool covers every ESC, prioritizes its findings, and produces forensic primitives for response. Coverage gaps are structural, not accidental.

Certify is the original offense-side tool from the SpecterOps team that wrote Certified Pre-Owned. A C# Windows binary that enumerates and abuses AD CS misconfigurations using the operator's in-process credentials [@certify-gh]. Released at Black Hat 2021, built against .NET 4.7.2. Certify covers the ESC1 through ESC16 enumeration surface via its documentation pages [@specterops-certify-docs-index]; abuse implementations exist for the catalog's most operator-friendly entries, with ESC11 documented as enumeration-only at the most recent docs revision [@specterops-esc11-docs].

Certipy is the Linux-side sibling, written in Python by Oliver Lyak at IFCR (now an independent project) [@certipy-gh]. The README carries the strongest coverage claim in the tool community: "full support for identifying and exploiting all known ESC1-ESC16 attack paths." Certipy ships its own NTLM relay (certipy relay), embedded BloodHound output, certificate forging, and PKINIT-to-TGT exchange. The Certipy wiki's privilege-escalation page is the best walking reference for the entire catalog [@certipy-wiki-priv].

BloodHound Community Edition is the only tool in the stack that integrates AD CS findings into the broader Active Directory attack graph. SharpHound CE collects AD CS objects -- CAs, templates, NTAuth membership, per-template DACLs -- and the BloodHound server computes ten ADCSESC*N* edges (ESC1, ESC3, ESC4, ESC6a/b, ESC9a/b, ESC10a/b, ESC13) plus the CoerceAndRelayNTLMToADCS edge that graphs ESC8 via coercion [@bh-llms]. BloodHound CE 7.x added Privilege Zones, which let defenders tag NTAuth CAs and their templates as Tier-Zero objects and surface paths to them in the analysis UI.

The principal-graph model treats each AD object as a node and each access right or trust as an edge. The graph then path-finds from a starting principal to a Tier-Zero target. This model works elegantly for template DACLs (ESC4) and CA DACLs (ESC7) and for issuance-policy group linkage (ESC13). It struggles with attacks where the abuse is a transport-level interaction rather than a principal-to-principal relationship.

ESC8 used to be considered uncatchable in this model. The CoerceAndRelayNTLMToADCS edge solved that: BloodHound CE now models the SMB-coercion-plus-NTLM-relay-to-ESC8 chain as a Group-to-Computer edge whose source is Authenticated Users and whose destination is the coerced target computer; the relay target CA and the template are encoded in the edge's metadata, not as graph nodes [@bh-coerce-adcs-edge]. The edge exists because coercion has a stable shape -- an unauthenticated principal class, a target computer, and an ESC8-vulnerable CA endpoint reachable on the network -- that the graph can express.

ESC11 remains harder. The RPC enrollment transport does not have a stable coercion model (the trigger is ICertPassage packet privacy not being enforced, not a coercion gadget like MS-EFSR), and the BloodHound graph today does not ship an ADCSESC11 edge. The model limit is partial, not total. The conventional "BloodHound cannot graph transport attacks" framing -- which was the prevailing folklore through 2024 -- is wrong; ESC8 is in the graph. ESC11 is the open structural case.

Locksmith is a PowerShell defender tool by Jake Hildreth (with Spencer Alessi) [@locksmith-gh]. It runs locally on a domain-joined host and reports template, CA, and NTAuth-container findings against the catalog. Modes 0 through 4: identify-and-report, auto-remediate where safe, produce a CSV, and so on. The lowest-friction defender tool in the stack -- a single Invoke-Locksmith cmdlet returns a triage list against the published ESC range.

PSPKIAudit is the SpecterOps team's own defender baseline, built on top of PKI Solutions' PSPKI module [@pspkiaudit-gh]. Its Invoke-PKIAudit and Get-CertRequest cmdlets cover ESC1 through ESC8 plus the "Explicit Mappings" surface for ESC14. The README is marked beta; PSPKIAudit predates Locksmith and ships fewer remediation primitives, but it is the canonical reference for what the original SpecterOps team thinks the defensive audit should do.

Microsoft Defender for Identity ships the ADCS posture assessment suite when the MDI sensor is installed on the CA itself [@mdi-certs]. The current product surface assesses nine ESCs by name: ESC1 (Preview), ESC2, ESC3, ESC4 (split across two separate assessments -- template owner and template ACL), ESC6 (Preview), ESC7, ESC8, ESC11, and ESC15. The product page is explicit: "This assessment is available only to customers who have installed a sensor on an AD CS server." MDI's coverage is broad and operationally integrated -- the same SOC console that surfaces Pass-the-Hash detections now surfaces the largest named-ESC posture-assessment suite of any non-Certipy tool in the stack, with the ESC1 and ESC6 assessments shipped in Preview state.

The KB5014754 strong-mapping track is Microsoft's runtime mitigation rather than a tool, but operationally it belongs in the stack discussion because it is the largest single thing Microsoft has shipped for this class [@kb5014754]. Strong mapping closes ESC9 and ESC10 (plus Certifried CVE-2022-26923) under Full Enforcement, defaults to Compatibility through February 11, 2025, and removes the legacy-mapping registry override on September 9, 2025. Operationally this is a deployment decision more than a "tool to run", but every defender stack has to plan for it; the Microsoft Tech Community Intune blog is the cross-reference for environments using SCEP or PKCS [@ms-tc-intune].

The Hacker Recipes AD CS chapter is a community reference catalog rather than a runnable tool; it serves as the canonical operator-facing summary of every ESC and is worth bookmarking. (Network reachability of the canonical URL has been inconsistent in late 2025 / 2026.)

Here is a single-table comparison of the practical stack. The right answer for a real enterprise is roughly "all of them in parallel"; the table makes the coverage gaps explicit.

Tool / track	Language	ESC enumeration coverage	Abuse capable	Graph capable	Best deployed for	Source
Certify	C# (Windows)	ESC1 to ESC16 (per docs)	Yes (most)	No	Operator chains, Windows offense	[@certify-gh]
Certipy	Python (Linux)	ESC1 to ESC16 (README claim)	Yes	Embedded	Operator chains, Linux offense	[@certipy-gh]
BloodHound CE ADCS edges	Cypher	8 of 16 ESCs (11 edges: ten ADCSESCN + CoerceAndRelayNTLMToADCS)	No	Yes	Prioritization, attack-path analysis	[@bh-llms]
Locksmith	PowerShell	Published ESC catalog	Identify and fix	No	Operational scans on each CA	[@locksmith-gh]
PSPKIAudit	PowerShell	ESC1 to ESC8 plus Explicit Mappings	No (read-only)	No	Defender baseline, audit	[@pspkiaudit-gh]
MDI ADCS posture	SaaS	ESC1 (Preview), ESC2, ESC3, ESC4, ESC6 (Preview), ESC7, ESC8, ESC11, ESC15	No	Inside MDI console	SOC integration, posture scoring	[@mdi-certs]
KB5014754 strong mapping	Windows runtime	ESC9, ESC10, Certifried (mitigation)	n/a	n/a	Domain Controllers (deploy)	[@kb5014754]

Note: For most enterprises the realistic configuration is: Locksmith scheduled monthly on every CA; BloodHound CE with the ADCS collector enabled in SharpHound CE; Microsoft Defender for Identity sensor on every AD CS server (for the nine-ESC SOC visibility surface that now includes ESC1 and ESC6 in Preview); PSPKIAudit run once a quarter as the SpecterOps-blessed baseline; Certipy in the red-team or purple-team kit; and the KB5014754 rollout staged to land at Full Enforcement before February 11, 2025 (legacy-mapping removal September 9, 2025). The remaining gap items -- ESC5, ESC12, ESC14, and ESC16 (neither in BloodHound's principal graph nor in MDI's posture-assessment surface) -- are caught by Locksmith plus PSPKIAudit plus Certipy plus careful template review.

If no single tool covers everything, what is Microsoft actually doing about it?

7. What Microsoft Has Actually Shipped

Of sixteen named ESCs, Microsoft has shipped three CVE-class patches. The rest are hardening guidance. The asymmetry is not accidental; it tracks the boundary Microsoft draws in its Windows Security Servicing Criteria between default-state vulnerabilities (which receive CVEs and binary patches) and admin-configurable misconfigurations (which receive documentation). Most ESCs sit on the configurable side of that boundary.

Four Microsoft mitigation tracks define the response, in order of when they shipped.

KB5005413 (late July 2021) -- NTLM Web Enrollment hardening. Published roughly six weeks after Certified Pre-Owned in response to PetitPotam plus the SpecterOps ESC8 disclosure [@kb5005413]. Recommends enabling Extended Protection for Authentication, requiring SSL on the /certsrv/ virtual directories of AD CS Web Enrollment and the Certificate Enrollment Web Service, and disabling NTLM where Kerberos is available. Crucially: KB5005413 is guidance, not a binary patch. Environments that never enabled EPA on /certsrv/ remain exploitable today. The KB closes ESC8 over HTTPS when fully applied; it does not affect ESC11 (RPC), ESC1 through ESC7, or anything in the ESC9-plus range.

CVE-2022-26923 (May 10, 2022) -- Certifried. The single MSRC-acknowledged CVE in the original ESC1 through ESC8 design space [@cve-2022-26923-nvd] [@cve-2022-26923-msrc]. Disclosed by Oliver Lyak at IFCR [@lyak-certifried], the vulnerability lets any Authenticated User (because the default ms-DS-MachineAccountQuota is 10 [@semperis-cve]) create a computer account, write its dNSHostName to match a Domain Controller, request a certificate from the default Machine template, and PKINIT as the DC. Microsoft patched it on the May 10, 2022 Patch Tuesday. Semperis's retrospective documents the chain in detail [@semperis-cve]. The patch closes that specific path -- the dNSHostName impersonation race -- and is part of the same Patch Tuesday that shipped KB5014754. It does not close any other ESC.

KB5014754 (May 10, 2022 -- present) -- the strong-mapping rollout. The largest single Microsoft mitigation in the entire class [@kb5014754]. SpecterOps's own analysis -- "Certificates and Pwnage and Patches, Oh My!" -- remains the canonical walkthrough of how the new behavior interacts with the existing catalog [@specterops-pwnage].

The mechanics: KB5014754 introduces the szOID_NTDS_CA_SECURITY_EXT extension (OID 1.3.6.1.4.1.311.25.2), embeds the requester's SID into every issued certificate by default, and redefines which altSecurityIdentities mappings the KDC will accept. Deployment is staged across three modes -- Disabled, Compatibility, and Full Enforcement -- with the Full Enforcement transition originally planned for November 2023, then repeatedly delayed in response to customer compatibility issues with SCEP, Intune PKCS, and non-Microsoft PKIs. The KB's current text states that Full Enforcement becomes the default on February 11, 2025, and the legacy compatibility-mode registry override is removed by the September 9, 2025 Windows security update [@kb5014754].

What it closes: ESC9 (because Full Enforcement rejects certificates lacking the SID extension), ESC10 (because weak mappings are rejected), and Certifried even on unpatched templates. It is bypassed by ESC16, which disables the SID extension at the CA level.

CVE-2024-49019 (EKUwu / ESC15) -- November 12, 2024. Patched thirty-five days after Bollinger's October 8, 2024 disclosure [@bollinger-ekuwu]. The November 12, 2024 Patch Tuesday addressed the V1 WebServer template Application-Policies override [@cve-2024-49019-nvd] [@cve-2024-49019-msrc]. The patch hardens the KDC's interpretation of Application Policies in V1 certificates; it does not close ESC16, ESC11, or anything in the template DACL space.

Note: Microsoft's Windows Security Servicing Criteria reserves CVEs for vulnerabilities in default product state [@msrc-servicing-criteria]. Misconfigurations that require administrator action to introduce are treated as hardening matters and receive documentation rather than CVEs. The 2019 ANSSI altSecurityIdentities report received a "won't fix" response on exactly these grounds [@dedrouas-altsec]. The boundary explains the catalog's CVE asymmetry: ESC1 (template flag) is configuration; Certifried (a default-template behavior on an account-creation-default-permission interaction) is a CVE. ESC15 sat on the boundary -- the affected template is shipped pre-installed and cannot be uninstalled, so its default-state could be argued either way -- and Microsoft chose to issue a CVE. The boundary is operational policy, not technical bound; it can move.

The single most useful table in this article is the cross-reference of which Microsoft mitigation closes which ESC. Read row by row to understand which ESCs are runtime-closed in a hardened environment and which remain dependent on the customer's administrative hardening discipline.

ESC	KB5005413 (2021)	CVE-2022-26923 (2022)	KB5014754 (2022-2025)	CVE-2024-49019 (2024)	Hardening only
ESC1	--	--	Partial (SID ext defeats SAN supply for cert-authn)	--	Primary mitigation
ESC2	--	--	--	--	Yes
ESC3	--	--	Partial (SID ext binds the cert to the agent)	--	Yes
ESC4	--	--	--	--	Yes
ESC5	--	--	--	--	Yes
ESC6	--	--	Partial (SID ext defeats requested SAN)	--	Primary
ESC7	--	--	--	--	Yes
ESC8 (HTTP)	Closed when EPA + SSL deployed	--	--	--	Continues if EPA off
ESC9	--	--	Closed at Full Enforcement	--	Until Feb 2025
ESC10	--	--	Closed at Full Enforcement	--	Until Feb 2025
ESC11 (RPC)	--	--	--	--	Primary (`IF_ENFORCEENCRYPTICERTREQUEST` flag)
ESC12	--	--	--	--	Primary (HSM hardening)
ESC13	--	--	--	--	Yes
ESC14	--	--	--	--	Yes
ESC15	--	--	--	Closed (Nov 12, 2024)	--
ESC16	--	--	Bypassed (this attack disables the extension)	--	Primary

Of sixteen ESCs, three have CVE-class binary patches (Certifried, EKUwu, and -- if you count it -- the KB5005413 NTLM-relay hardening track), two are runtime-closed under KB5014754 Full Enforcement, and the remaining eleven are administrative hardening matters. If only three of sixteen have CVEs, what stops the catalog from growing forever?

8. The Two-Trust-Roots Problem

What stops the catalog from growing forever is the architectural property the catalog enumerates around but cannot eliminate. The catalog grows because the property is structural, not because the engineering is sloppy. Four pieces of theory anchor the limit.

Two trust roots. Active Directory's Kerberos KDC will mint a Domain Admin Ticket-Granting Ticket on presentation of any valid certificate signed by a CA in the forest's NTAuthCertificates container, provided the certificate maps to the Administrator principal. The krbtgt key is the symmetric root of trust for password and TGS authentication; an NTAuth CA's private key is an asymmetric root of trust for PKINIT. There is no architectural relationship between the two. Rotating the krbtgt key does not invalidate any certificate. Revoking a CA does not invalidate krbtgt-issued tickets. They are independent authenticator-minting keys. For a forest with $n$ NTAuth-published CAs, the count of independent keys that can mint a Domain Admin authenticator is $n + 1$.

Key idea: For an Active Directory forest with $n$ Certificate Authorities published into NTAuthCertificates, there are exactly $n + 1$ independent keys that can mint a Domain Admin authenticator: the krbtgt account hash, and the private key of every published CA. Rotating krbtgt closes one root. Revoking one CA closes another. The other $n - 1$ remain. The ESC catalog enumerates how an attacker can make those keys issue a Domain Admin authenticator with low-privilege materials; the architectural property -- that there are $n + 1$ such keys at all -- is a design property of PKINIT and is not closable by any patch [@rfc4556] [@cpo-whitepaper].

PKINIT's binding gap. RFC 4556 specifies how a Kerberos client presents a certificate and receives a TGT [@rfc4556]. The RFC does not bind the certificate to a Microsoft SID; the mapping from certificate to AD principal is a Microsoft extension. The KB5014754 strong-mapping track closes the mapping ambiguity by embedding the requester's SID into the certificate and matching the SID on the KDC side [@kb5014754]. It does not close the underlying primitive: a certificate is an alternate identity assertion that the KDC honors as long as the signing CA is trusted. Different ESCs find different ways to get a useful certificate; the authentication step is identical across the catalog.

The transport-versus-principal split. The §6 BloodHound Aside develops this in full: BloodHound's principal-graph model now expresses ESC8 as the CoerceAndRelayNTLMToADCS edge, but ESC11 remains the open structural case because the RPC transport has no equivalent coercion gadget [@bh-coerce-adcs-edge]. The model limit is partial, not total -- it applies to RPC, not to all transport attacks.

The configuration-versus-CVE boundary. The §7 Callout develops this in full. The catalog has accumulated CVEs only when Microsoft judged the configuration was default-state -- Certifried's machine-account-quota path and ESC15's pre-installed V1 templates. The architectural property is policy-driven and movable.

Active Directory has two trust roots that can mint a Domain Admin authenticator: the krbtgt key, and any CA published into NTAuth. Rotating one does not touch the other.

The architectural property reshapes how operators should think about the catalog. The catalog is not an arms race that ends; the catalog is the community mapping the surface of a design property of PKINIT. Each new ESC narrows the description of what surface remains exposed; no plausible patch removes the underlying $n + 1$ key count. Until PKINIT itself is replaced -- until PKINIT is deprecated, until the KDC stops accepting certificate-based authentication, until NTAuth-published CAs lose their KDC trust -- every NTAuth-published CA in the forest is a key parallel to krbtgt.

If the architectural limit cannot be closed, what are the open questions in 2026?

flowchart LR K[krbtgt account hash
symmetric KDC key] CA1[CA #1 private key
published in NTAuth] CA2[CA #2 private key
published in NTAuth] CAN[CA #n private key
published in NTAuth] KDC[Kerberos KDC
and PKINIT] AUTH[Domain Admin
authenticator TGT] K --> KDC CA1 --> KDC CA2 --> KDC CAN --> KDC KDC --> AUTH

9. Open Problems and the Catalog's Closure

The catalog has no published closure principle. Here are the five open frontiers in 2026.

No closure principle. The catalog has grown every year since 2021: ESC1 through ESC8 in June 2021; ESC9 and ESC10 in August 2022; ESC11 in November 2022; ESC12 in October 2023 [@knobloch-esc12] [@knobloch-esc12-archive]; ESC13 and ESC14 in February 2024; ESC15 in October 2024; ESC16 named in 2025 against a workaround from 2022 [@specterops-esc16-docs]. ESC15 revealed a twenty-four-year-old default behavior on V1 templates -- behavior that had been quietly present since the role's 2000 shipping date [@bollinger-ekuwu]. The Certify documentation conjectures an upper bound (the six primitive categories times the misconfigurable bits per primitive) but no formal upper bound is published. ESC15 is itself an existence proof that new categories still emerge: Application Policies as a parallel to standard EKU was not in the original 2021 catalog at all.

Detection asymmetry. Most ESCs leave artifacts on the CA -- specifically Event ID 4886 (certificate request submitted) and Event ID 4887 (certificate issued) -- and no artifact in the standard Active Directory event stream. Most SIEMs do not ingest CA logs, because CA logs were never on the standard Tier-Zero ingest checklist. The result is that the CA's own audit log carries the only reliable forensic primitive for the entire catalog, and that log is in a place the SOC does not look. Locksmith and PSPKIAudit can identify the misconfigurations but cannot tell you whether they have been exploited; that signal lives in the CA's audit log alone.

Strong-mapping migration risk. The KB5014754 staged rollout enters Full Enforcement on February 11, 2025 and removes the legacy compatibility-mode registry override on September 9, 2025 [@kb5014754]. Environments with legacy SCEP gateways, third-party PKI vendors, Intune PKCS profiles without strong mapping, or smart cards issued by non-Microsoft CAs face a real risk that legitimate authentication breaks at Full Enforcement. The Microsoft Tech Community Intune guidance is the operational reference for the SCEP/PKCS path [@ms-tc-intune]. The migration is a security upgrade and a deployment minefield in the same package; environments that defer the rollout past September 9, 2025 lose the legacy override and are forced into Full Enforcement by an OS update they did not opt into.

Note: Per the live KB5014754 text on Microsoft Support: "By February 2025, if the StrongCertificateBindingEnforcement registry key is not configured, domain controllers will move to Full Enforcement mode" and "the option to move back to Compatibility mode will remain until the September 9, 2025, Windows security update is installed" [@kb5014754]. Environments that have not finished the strong-mapping rollout by those dates -- particularly those with non-Microsoft PKI in the chain, including legacy SCEP / Intune PKCS / smart-card vendors -- should plan for breakage and have a rollback plan ready.

Cloud PKI. Entra-managed Cloud PKI changes the substrate: the issuing CA is Microsoft-operated, the template surface is partially exposed to administrators, and the trust relationship between Cloud PKI and on-premises Active Directory is itself a configurable bridge. The community has not yet published an ESC catalog for Cloud PKI; the on-premises catalog is on-prem-specific and does not transfer directly. The open question is whether the Cloud PKI substrate has its own equivalent primitives (a CA-side "this template is configured with ESS-equivalent behavior") that just have not yet been named.

The NTLM dependency in ESC8 and ESC11. Both ESC8 and ESC11 depend on NTLM authentication being available between the coerced computer and the CA host. Microsoft's stated direction is to disable NTLM by default in future Windows releases (the "NTLM disablement" track) [@ms-ntlm-evolution]. If that direction completes, ESC8 and ESC11's relay primitives lose their substrate -- not because the AD CS transport hardens, but because there is no NTLM authentication to relay. The rest of the catalog -- the template, ACL, mapping, and CA-configuration ESCs -- does not depend on NTLM and is unaffected by NTLM disablement.

Taken together, these results suggest the catalog's growth trajectory is structural. The reason ESC15 surfaced a twenty-four-year-old default is not that the SpecterOps team was lazy in 2021; it is that the surface is so large that systematic enumeration of every cross-product (six primitives multiplied by the configurable bits per primitive) is itself a research program. Knowing the architectural limits and the open problems, here is the operational playbook.

10. The Four-Lane Playbook

Here is what an enterprise security program actually does, in four lanes. Lane discipline matters because the catalog rewards parallel work: a single quarter spent only on Lane 1 leaves you detection-blind, and a single quarter spent only on Lane 2 leaves you remediation-paralyzed.

Lane 1: Preventive hygiene

Run Locksmith and PSPKIAudit on every Enterprise CA at least monthly [@locksmith-gh] [@pspkiaudit-gh]. Both tools enumerate the published catalog and produce a triage list. The defender baseline these tools encode is roughly:

Template ACL audit. Confirm that no non-Tier-Zero principal holds WriteDacl, WriteOwner, WriteProperty, or GenericAll on any V2 template.
CA security descriptor audit. Confirm that Manage CA and Issue and Manage Certificates are held only by Tier-Zero principals.
ESS audit. Confirm that no template enrollable by Authenticated Users or Domain Users has CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT set with Client Authentication EKU and no Manager Approval.
CA registry audit. Confirm that EDITF_ATTRIBUTESUBJECTALTNAME2 is not set, and IF_ENFORCEENCRYPTICERTREQUEST is set.
SID extension audit. Confirm that szOID_NTDS_CA_SECURITY_EXT (OID 1.3.6.1.4.1.311.25.2) is not present in any CA's DisableExtensionList registry value -- closing the ESC16 path.
Manager Approval on sensitive templates. Confirm that any template with privileged EKU sets has Manager Approval.
Least-privilege Enroll. Confirm that Domain Users-equivalent groups do not hold Enroll or Autoenroll on sensitive templates.

Lane 2: Detection deployment

Ingest the CA's own Security event log into the SIEM. The two load-bearing events are 4886 ("Certificate Services received a certificate request") and 4887 ("Certificate Services approved a certificate request and issued a certificate"). These events are what fire when an operator chain like the cold-open in section one executes. They are the only AD CS event stream the SOC needs to detect the entire issuance side of the catalog.

Enable Microsoft Defender for Identity sensors on every AD CS server. MDI now ships nine named ESC posture assessments -- ESC1 (Preview), ESC2, ESC3, ESC4 (template owner and template ACL as two separate assessments), ESC6 (Preview), ESC7, ESC8, ESC11, and ESC15 -- and surfaces them in the same console the SOC uses for the rest of Active Directory [@mdi-certs]. The ADCS-resident sensor is the only MDI sensor that produces these particular assessments; environments running MDI on Domain Controllers only do not get the AD CS surface.

Run SharpHound CE with the AD CS collection options enabled and ingest the resulting graph into BloodHound CE. Tag NTAuth-published CAs and their pre-installed sensitive templates as Tier Zero in BloodHound's Privilege Zones. Run the analysis layer's Shortest Paths to Tier Zero query weekly; ESC1, ESC3, ESC4, ESC6a/b, ESC9a/b, ESC10a/b, and ESC13 will surface as edges, along with CoerceAndRelayNTLMToADCS paths for any ESC8-vulnerable HTTP enrollment endpoint [@bh-llms] [@bh-coerce-adcs-edge].

Schedule Locksmith on a recurring cadence with output to a triage queue. Locksmith is the lowest-friction defender tool; it identifies and (with mode 1) optionally fixes published-catalog findings with a single cmdlet.

Lane 3: Confirmed-compromise response

This lane carries the article's load-bearing operational claim. If a CA's private key is suspected compromised -- whether through ESC12 hardware-substrate compromise, through ntdsutil-equivalent CA export, or through a vendor compromise of the HSM -- the recovery path is not "rotate krbtgt" and not "revoke the affected certificates". The recovery path is multi-week:

Revoke the CA's published certificate chain.
Decommission the CA (remove the role service, delete the CA private key store, retire the host).
Build a replacement CA on new hardware with a new key.
Publish the new CA into NTAuthCertificates.
Distrust the old CA's certificates throughout the forest (CRL update, certificate revocation lists pushed via Group Policy, decommissioning all certificates issued by the compromised CA).
Re-issue every credential that depended on the compromised CA.

This operation is analogous in scale and duration to a forest rebuild for krbtgt compromise -- a multi-week IR project, not a one-day patch. The reason is the two-trust-roots property: revoking the CA closes only one of the $n + 1$ keys; if the operator already minted Golden Certificates against the CA's private key, those certificates outlive the revocation unless every issued serial is on the CRL and every relying party has a fresh CRL fetch policy.

Note: The Lane-3 CA rebuild operation is the single most important preparatory deliverable in this entire playbook. Run a tabletop exercise: "the CA private key is compromised; what are the steps to a clean state?" If the answer is unclear in the absence of an incident, the answer will be improvised during one -- typically poorly. Build the runbook, identify the operational owners, pre-stage the replacement CA's hardware, and document the certificate inventory you will need to re-issue. The two-week recovery becomes a one-week recovery if the prep is done; the two-week recovery becomes a four-week recovery if it is not.

Lane 4: What does not work

Five operator myths that the catalog refutes by construction:

"Rotating krbtgt closes AD CS." Wrong. Rotating krbtgt closes the symmetric KDC key; it does not touch the asymmetric CA private keys in NTAuthCertificates. An ESC1 certificate issued against the new krbtgt mints a Domain Admin TGT the same way it would have against the old one.
"Credential Guard protects against ESC." Wrong. Credential Guard's LSAISO isolates LSASS-resident credentials from the rest of the OS. AD CS abuse does not touch LSAISO; the certificate is issued by the CA against a request submitted over a network protocol. The credential never leaves the attacker's machine in a form Credential Guard could isolate.
"Disabling Web Enrollment closes AD CS." Partial. Disabling the AD CS Web Enrollment role service closes ESC8 (the HTTP relay primitive). It does not affect ESC1 through ESC7 (template, ACL, and CA-config attacks), ESC11 (RPC relay), or any of the mapping ESCs. The default RPC enrollment transport on every Enterprise CA is unaffected.
"If we patch CVE-2022-26923 we're done." Wrong. CVE-2022-26923 closes the specific dNSHostName machine-account-impersonation chain. It does not close ESC1, ESC4, or any of the configuration ESCs that the same operator chain could have taken.
"Reset krbtgt twice and we have evicted the attacker." Wrong. The double-krbtgt-reset playbook is well-suited for Golden Ticket eviction. It is not effective against an attacker who has issued a long-validity authentication certificate from a CA the attacker controls or has compromised. The issued certificate authenticates against the new krbtgt the same way it did against the old one, because PKINIT does not bind the certificate's authority to the symmetric krbtgt key.

Run Locksmith this week. Tag NTAuth CAs as Tier Zero in BloodHound. Schedule the Lane 3 rebuild playbook before you need it. The catalog grew faster than the patches; the defender's only working strategy is parallel work in all four lanes.

11. Frequently Asked Questions

The SID extension is on by default for any CA running an OS that has installed KB5014754 or later. The catch is what the *KDC* does with that extension. Switching the KDC to Full Enforcement breaks every certificate that lacks the SID extension, which is why Microsoft built the three-mode staged rollout: the §7 timeline anchors the compatibility window (mechanics and the Feb 11, 2025 / Sep 9, 2025 milestones), and the §9 Callout carries the verbatim KB5014754 dates and the customer compatibility-friction set (legacy SCEP, Intune PKCS, non-Microsoft PKI, third-party smart cards). ESC16 closes the loop in the other direction: an admin (or a compromised admin) can re-disable the extension at the CA level, recreating the weak-mapping condition KB5014754 was designed to close. Partially. The on-premises ESC catalog enumerates misconfigurations of the on-premises AD CS role. Entra Cloud PKI is a Microsoft-operated SaaS CA whose substrate is not the on-premises AD CS Windows role at all -- so ESCs that abuse on-premises CA registry flags (ESC6, ESC16), on-premises CA DACLs (ESC5, ESC7), or the on-premises transport (ESC8, ESC11) do not transfer directly. But Cloud PKI still issues authentication certificates, still has a template-equivalent administrative surface, and still maps certificates onto AD or Entra principals. The community has not yet published a Cloud PKI ESC catalog; the open question is whether the cross-product of Cloud PKI's primitive surface and its mapping behavior has its own equivalent class of named misconfigurations. No. A two-tier hierarchy improves protection of the *root* CA's private key (the root signs only the subordinate's certificate and stays offline) but does nothing for the subordinate. The ESC catalog attacks the issuing subordinate, not the root. The misconfigured Enrollee-Supplies-Subject template, the editable `EDITF_ATTRIBUTESUBJECTALTNAME2` registry flag, the per-template DACL, the NTLM-relayable Web Enrollment endpoint -- all live on the subordinate CA. A two-tier hierarchy is the right architecture and is essentially orthogonal to the ESC discussion. No. Smart cards are *consumers* of certificates issued by AD CS; the smart-card pipeline reads a certificate off the card, presents it to PKINIT, and receives a TGT. AD CS is the *issuing* substrate. Every ESC attacks the issuance side. A smart-card deployment depends on AD CS being correctly configured; it adds no defense against ESC1 through ESC16 and may add complexity in the strong-mapping migration (smart-card-issued certificates may use legacy mappings that break under Full Enforcement). No. BloodHound CE does not ship a numbered `ADCSESC8` edge. It ships `CoerceAndRelayNTLMToADCS`, an edge representing "a computer can be SMB-coerced to authenticate to an attacker host, and the attacker host can relay that authentication to an ESC8-vulnerable Web Enrollment endpoint on a CA" [@bh-coerce-adcs-edge]. Look for that edge, not for a numbered ESC8 edge. If `CoerceAndRelayNTLMToADCS` paths exist anywhere in the graph, your Web Enrollment endpoint is ESC8-exposed and the operator chain from any coercible computer to a Domain Admin authenticator runs in eight minutes. ESC12 is treated in the §5 Aside: Knobloch's October 2023 YubiHSM hardware-substrate disclosure (earliest Wayback snapshot dated October 24, 2023), scoped out of the body because the abuse depends on the specific HSM vendor and on shell access to the CA host [@knobloch-esc12] [@knobloch-esc12-archive]. ESC0 does not exist in the SpecterOps catalog; some operator blogs use "ESC0" informally to describe naive enumeration (no abuse, just "the CA is reachable and the template store is readable") but it is not a community-named technique.

KRBTGT: The Account That Owns Active Directory

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

Active Directory's `krbtgt` account is the one secret in any Windows domain whose disclosure forges valid Ticket-Granting Tickets for every principal -- including ones that do not exist. Twelve years of attacks (Golden, Diamond, Sapphire) and Microsoft's responses (the MS14-068 patch, KrbtgtFullPacSignature, the two-reset rotation procedure) converge on one fact: krbtgt rotation invalidates forged TGTs but does not recover the systemic compromise that produced them. That distinction is why confirmed krbtgt compromise is a forest-rebuild event in modern incident-response playbooks, not a key-rotation event.

1. Ninety Seconds to Domain Admin

A single mimikatz kerberos::golden command, with the krbtgt account's AES-256 long-term key in hand, walks the attacker onto any resource in the domain as Administrator. No Domain Admin password was reset. No Domain Admin account was created. No SACL on a sensitive object fired. No LSASS on any host was dumped. No signature-based IDS rule triggered. The attacker holds exactly one cryptographic key -- the long-term key of the RID-502 service account named krbtgt -- and the entire Kerberos trust hierarchy of the domain now accepts whatever they sign [@mitre-t1558001]. The section title's "ninety seconds" is an illustration of how fast the attack is on the wall clock, not a measured demonstration from a published primary.

The operator sequence is short enough to quote. Earlier in the engagement, the attacker ran lsadump::dcsync /user:contoso\krbtgt from a member-server foothold and walked off with the krbtgt long-term key material [@mimikatz]. Then they switched tools to forge a ticket from scratch:

mimikatz # kerberos::golden /domain:contoso.local
                            /sid:S-1-5-21-1004336348-1177238915-682003330
                            /aes256:<key>
                            /user:Administrator /id:500
                            /groups:512,513,518,519,520 /ptt

That single command, documented by Sean Metcalf for operators in 2015 [@adsec-1640], does the forgery in process memory, injects the ticket into the local Kerberos cache (/ptt = pass-the-ticket), and lets the next dir \\dc01\admin succeed.

Count the controls that did not fire while the forged ticket was being minted and presented. No Domain Admin password reset, because the attacker never used a Domain Admin password. No new privileged account, because the attacker impersonated an existing one (RID 500). No SACL on a sensitive object, because the ticket was already approved by the Kerberos trust root before any object was touched. No LSASS dump on a writeable DC, because DCSync is a replication API call, not a memory scrape [@mitre-t1003006]. No IDS hit on a known-malicious payload, because Mimikatz lives in attacker process memory and the wire traffic is, structurally, a TGS-REQ. No anomalous logon time, MFA prompt, or Conditional Access decision, because Kerberos pre-authentication is satisfied by holding a valid TGT and the TGT was minted offline.

The article's load-bearing thesis: within the Kerberos trust root of a single domain, the krbtgt key is the unique secret whose disclosure yields valid TGTs for every principal -- including ones that do not exist. The technical recovery (two-reset rotation) is well-documented [@ms-forest-recovery] and does cryptographically invalidate forged tickets. But the operational recovery from a confirmed krbtgt compromise is a forest-rebuild event for reasons that have nothing to do with the krbtgt key itself.

This produces an apparent contradiction. Microsoft documents a clean two-reset rotation procedure with a ten-hour interval [@ms-forest-recovery]; Mandiant- and SpecterOps-style incident-response playbooks treat confirmed krbtgt compromise as a forest-rebuild event [@specterops-dot2]. Both statements are simultaneously true. The job of the next ten thousand words is to explain why -- starting with what krbtgt actually is. Not the key. Not the protocol. The account itself: RID 502, disabled, indelible.

2. The Account: RID 502, Disabled, Indelible

Open Active Directory Users and Computers on a fresh Windows Server 2022 domain promoted ten seconds ago. In the Users container there is an account called krbtgt. It has no password visible to the admin. It is disabled. Try to enable it -- the checkbox accepts the click, but the next replication cycle puts the account right back into the disabled state. Try to rename it -- the operation appears to succeed, but the objectSID does not change. Try to delete it -- the operation fails outright. You cannot log in as it; the disabled-for-interactive-logon property is enforced inside the Security Accounts Manager. The account exists exactly because the domain exists; the lifetime of the account and the lifetime of the domain are the same lifetime [@ms-default-accounts].

Why does Active Directory ship with an account that no admin can use, no attacker can authenticate as interactively, and no operator can remove?

The Kerberos Ticket-Granting Ticket service account that exists, exactly once per Active Directory domain, to hold the long-term cryptographic key the domain controllers use to encrypt and sign every TGT issued in the domain. The account name itself is the Kerberos principal name (`krbtgt/DOMAIN@DOMAIN`) inherited from MIT's 1988 Kerberos v4 design.

Creation. The account is created automatically when the first writeable domain controller is promoted in a new domain. The Microsoft Learn default-accounts page lists it alongside Administrator and Guest as one of the three default local accounts in the Users container, with the verbatim note that "the KRBTGT account can't be enabled in Active Directory" [@ms-default-accounts]. The account's lifecycle is bound to the domain's lifecycle; there is no operator-controllable provisioning of a krbtgt account, and no de-provisioning short of demoting the domain.

RID 502. The relative identifier at the tail of the account's SID (S-1-5-21-<domain>-502) is fixed by the well-known SID specification [@ms-sids]. Sean Metcalf's operator primer confirms the RID-502 binding directly: "Each Active Directory domain has an associated KRBTGT account ... The SID for the KRBTGT account is S-1-5-<domain>-502" [@adsec-483].RIDs 500 through 1000 are reserved for built-in security principals; 500 is Administrator, 501 is Guest, 502 is krbtgt. Renaming the sAMAccountName cannot move the RID. The KDC service derives its key lookups from the principal name, which binds to the RID, not from the friendly name shown in ADUC. Renaming krbtgt as a defensive measure is a fallacy that the next section will sharpen further.

Each Read-Only Domain Controller has its own krbtgt_<rid> account whose key signs only that RODC's tickets. The full-domain krbtgt account is read-only from the RODC's perspective -- the design property that lets RODCs participate in Kerberos without holding the full-domain trust root [@adsec-483].

Container. CN=Users,DC=<domain>. The standard Users container, not a Tier-0 OU or a Protected Users group. The account is privileged by virtue of its RID, not by virtue of its containership. Moving it into a different container does not change its semantic role to the KDC.

Disabled for interactive logon. Documented verbatim on the Microsoft Learn default-accounts page: "The KRBTGT account can't be enabled in Active Directory" [@ms-default-accounts]. The account is reserved for the KDC service. There is no interactive logon surface attached, no LSA logon-rights grant, no Kerberos pre-authentication path that produces a TGT for the krbtgt account itself. The account exists to provide a key, not to authenticate.

Indelible and unrenamable. Also from the same Microsoft Learn page: "This account can't be deleted, and the account name can't be changed" [@ms-default-accounts]. ADUC will show a renamed display, but the underlying object identity (the RID, the principal name) is fixed by the directory schema and by LsaSrv enforcement on the writeable DCs.

Password. System-generated, unknown to operators by design. Resetting it via ADUC produces a value Active Directory immediately replaces with a fresh system-generated value. The mechanism that produces the current key is therefore not operator-controllable; rotation is the only primitive operators have over the key value [@ms-forest-recovery].

Password history equals 2. Documented verbatim on the AD Forest Recovery page: "The password history value for the krbtgt account is 2, meaning it includes the two most recent passwords" [@ms-forest-recovery]. This is the mechanical foundation for the two-reset procedure Section 7 will dissect. The KDC keeps both a current and a previous key in the krbtgt account; in-flight TGT validation tries both during the brief window after a rotation; one reset retires only the older of the two; a second reset, separated by at least the maximum ticket lifetime, evicts the key the attacker held.

Where the key lives. The KDC service (kdcsvc.dll) on every writeable DC reads the krbtgt long-term key from ntds.dit at startup and holds it in process memory for ticket signing and validation. Credential Guard's VBS trustlet -- LSAISO -- does not isolate this read on writeable DCs by design: a DC must read the key to issue tickets [@ms-credential-guard] (see also §10 Aside on why Credential Guard skips the DC). This is the structural asymmetry that makes the krbtgt key reachable to any attacker who can compromise a writeable DC (or invoke its replication API remotely), even on a system where Credential Guard is otherwise enforced everywhere else.

We know what the account is now: a non-interactive, indelible, RID-502 service principal with a system-generated, two-slot password history. But the account is just the container. The rest of the article cares about the long-term cryptographic key it holds.

3. The Key: What RFC 4120 and [MS-KILE] Specify

Hand a network capture of a Kerberos AS-REP to a Wireshark dissector. The dissector shows the TGT as a sequence of ASN.1 fields. One field is named enc-part and its content is opaque. The dissector knows the format of what is inside that opaque blob -- an EncTicketPart -- but it cannot show the field values because the blob is encrypted [@rfc4120]. Encrypted under what? Under one key: the long-term key of the principal named krbtgt/CONTOSO.LOCAL@CONTOSO.LOCAL.

The Microsoft specification puts it as plainly as is possible to put it. [MS-KILE] specifies that the KDC encrypts every ticket using the long-term cryptographic key of the krbtgt principal, citing RFC 4120 §5.2.2 [@mskile]. That sentence, more than any other in the Microsoft Open Specifications corpus, is the cryptographic foundation of Active Directory authentication. Every TGT issued by every writeable DC in the domain is encrypted under one key. There is no per-account key, no per-DC key, no rolling subkey. One key, one trust scope.

The credential the Kerberos Key Distribution Center issues at logon, encrypted under the KDC's own service key (in Windows, the krbtgt account's long-term key), that the client subsequently presents to request service tickets without re-authenticating with a password. RFC 4120 §5.3 defines its fields; [MS-KILE] specifies the Windows wire profile [@rfc4120][@mskile]. The Kerberos service that issues TGTs (the Authentication Service) and exchanges TGTs for service tickets (the Ticket-Granting Service). In Active Directory the KDC runs as `kdcsvc.dll` on every writeable domain controller; it holds the krbtgt long-term key in process memory for the lifetime of the service [@rfc4120].

Inside the encrypted blob

RFC 4120 §5.3 specifies the fields of the EncTicketPart: a session key the KDC generates for this TGT, the client's name, the cross-domain transit path, the timestamps (authtime, starttime, endtime, renew-till), the optional client-address list, and a final field of authorization-data that Windows uses to carry the Privilege Attribute Certificate [@rfc4120].

The Windows-specific data structure embedded inside the `authorization-data` field of every Kerberos ticket. The PAC carries the user's SID, the SIDs of every group the user belongs to, account restrictions, profile path, logon server, and a small set of cryptographic signatures the KDC computes to bind the structure to the ticket. Defined in [MS-PAC] [@mspac].

The PAC is where the load-bearing security claim of Windows Kerberos lives. RFC 4120 itself does not care about groups; it cares about whether the client can prove identity to a server. The PAC carries the authorization layer Windows needs on top of authentication: which security principal the ticket represents, which groups confer which permissions, which restrictions apply [@mspac]. The first thing a Windows file server does when it receives a service ticket is decode the PAC, read the SIDs, and run the access-check algorithm.

The three signatures inside every PAC

The PAC is integrity-protected by a small set of signatures the KDC computes when it issues the ticket. As of the [MS-PAC] revision 26.0 dated June 10, 2024 [@mspac], a TGT-resident PAC carries three of them:

The PAC server signature. A keyed HMAC computed under the service key. For a TGT the service is krbtgt/DOMAIN, so the server signature is computed under the krbtgt long-term key. For a service ticket the server signature is computed under the service account's long-term key (the file server's machine-account key, for example) [@mspac].
The PAC KDC signature. A keyed HMAC computed under the krbtgt long-term key, signing the bytes of the server signature. This is the pre-2022 anchor of PAC integrity: even if a service holding only its own key could verify the server signature, only the KDC (or anyone holding the krbtgt key) could compute the matching KDC signature. The "pre-2022" framing tracks the deployment of KB5020805's Full PAC Signature, documented in §5 Generation 6 [@kb5020805].
The Full PAC Signature. Added by Microsoft's response to CVE-2022-37967, deployed via KB5020805 starting November 8, 2022 and enforced by default since July 11, 2023 [@kb5020805][@cve-2022-37967]. Computed by the KDC over the entire PAC -- including the older two signatures -- and stored alongside them. Also computed under the krbtgt long-term key.

flowchart TD PAC[PAC contents: SIDs, groups, restrictions] --> SSig[Server Signature] PAC --> KSig[KDC Signature] PAC --> FSig[Full PAC Signature] SSig --> KEY["krbtgt long-term key (TGT)"] KSig --> KEY FSig --> KEY KEY --> TGT[EncTicketPart for TGT] TGT --> WIRE[AS-REP / TGS-REP on the wire]

This is the architectural fact the rest of the article will refer back to. The addition of the Full PAC Signature did not relocate the trust to a different key. All three PAC signatures on a TGT terminate at the krbtgt long-term key. An attacker who holds the krbtgt key computes all three correctly in the same step. This is the precise technical observation that motivates the Section 5 attack cascade and the Section 7 rotation analysis.

The enctype matrix

The krbtgt account does not hold a single key; it holds a set of keys, one per Kerberos encryption type advertised in msDS-SupportedEncryptionTypes on the account object. RFC 4120 §5.2.9 defines the enctype numbers; common Windows values are AES-256-CTS-HMAC-SHA1-96 (enctype 18), AES-128 (enctype 17), and the legacy RC4-HMAC (enctype 23) [@rfc4120]. AES-256 has been the recommended default for newly-provisioned krbtgt accounts since the Windows Server 2008 R2 / Windows Server 2012 functional levels, though early Windows Server 2008 deployments often required a krbtgt password reset to materialise the AES keys. The post-2017 AES-SHA2 family (enctypes 19 and 20) is defined by IETF but not deployed in mainline Windows production as of [MS-KILE] revision 47.0 dated April 27, 2026 [@mskile].

A numeric identifier for the cryptographic algorithm and key length used to encrypt a Kerberos message. RFC 4120 §5.2.9 enumerates them; common Windows values are 17 (AES-128), 18 (AES-256), and 23 (the legacy RC4-HMAC). Each principal's long-term key is derived per enctype, so the krbtgt account stores multiple key derivations side by side [@rfc4120].

Each derivation is stored in both current and previous slots; rotating the krbtgt password rederives the entire set for the new password and shifts the previous derivations into the previous slot.

FAST armoring sits next to, not above, the krbtgt key

RFC 6113 / [MS-KILE] Flexible Authentication Secure Tunneling adds a second key layer for the client-facing pre-authentication exchange, armoring the AS-REQ under a separate channel key derived from a TGT the client already holds. FAST hardens pre-authentication against offline brute-force. It does not change the fact that the TGT's enc-part is encrypted under the krbtgt key on its way back to the client [@mskile]. No Kerberos extension shipped through 2026 moves the TGT's trust anchor anywhere other than the krbtgt long-term key.

Within a Kerberos domain, every TGT reduces to the same key, and that key has a name: krbtgt.

That sentence is the load-bearing claim the rest of the article rests on. The next section explains how a 1988 academic design decision became the cryptographic foundation of every Windows domain alive today.

{` // Simplified model of the three PAC signatures on a TGT. // Each signature is a keyed HMAC computed under the krbtgt long-term key. const pacContents = "SIDs, groups, restrictions"; const krbtgtKey = "<32-byte AES-256 long-term key>";

function hmac(key, data) { return key === krbtgtKey ? "SIG(" + data + ")" // attacker-with-key computes valid sigs : "INVALID"; // attacker-without-key cannot forge them }

function buildPACBlock(attackerKey) { const serverSig = hmac(attackerKey, pacContents); const kdcSig = hmac(attackerKey, serverSig); const fullPAC = hmac(attackerKey, pacContents + serverSig + kdcSig); const validates = [serverSig, kdcSig, fullPAC].every(s => s !== "INVALID"); return { serverSig, kdcSig, fullPAC, validates }; }

console.log("with krbtgt key :", buildPACBlock(krbtgtKey).validates); console.log("without krbtgt key:", buildPACBlock("guess-key").validates); `}

4. Origins: 1988 Athena, RFC 4120, [MS-KILE]

Open the bibliography of RFC 4120 and find an entry tagged [Ste88]: "Steiner, J., Neuman, C., and J. Schiller, 'Kerberos: An Authentication Service for Open Network Systems,' USENIX Conference Proceedings, February 1988" [@rfc4120]. The principal name krbtgt is in that paper. It has been carried forward unchanged through RFC 1510 (1993) [@rfc1510], through Active Directory's February 2000 release, through RFC 4120 (2005) [@rfc4120], through the first [MS-KILE] revision (2007), and into the current [MS-KILE] revision 47.0 dated April 27, 2026 [@mskile]. Thirty-eight years.

What did the 1988 design decision look like, and what has changed about its security properties since?

MIT Project Athena, 1983-1991

Project Athena ran at MIT from 1983 to 1991 as a campus-scale distributed-computing experiment funded primarily by IBM and DEC [@project-athena]. The authentication problem Athena needed to solve was the one every multi-user network has needed to solve since: how do you let thousands of workstations talk to thousands of services without broadcasting cleartext passwords on every connection? Steiner, Neuman, and Schiller presented their answer at the Winter USENIX conference in Dallas in February 1988. Their design introduced the krbtgt principal name and the trust property that one key encrypts every TGT in the Kerberos domain [@athena1988].

The principal name krbtgt predates Active Directory by twelve years. MIT's 1988 USENIX paper used the name, RFC 1510 standardised it in 1993 [@rfc1510], and Windows 2000 inherited it unchanged. There is no Microsoft-specific Kerberos principal naming convention; the convention is IETF.

The design property that one key encrypts every TGT was not framed in 1988 as a security risk. It was framed as a simplification: by giving the TGS one stable identity that issues every TGT, the protocol does not need to negotiate per-session KDC identities or per-server validation paths. The protocol reduces, mathematically, to two questions: did the KDC issue this TGT, and did the TGT permit the subsequent TGS-REQ for this service? Both reduce to "does this signature validate under the krbtgt key?"

From RFC 1510 to [MS-KILE]

John Kohl and Clifford Neuman published RFC 1510 in September 1993, standardising Kerberos version 5 [@rfc1510]. The krbtgt/DOMAIN@DOMAIN principal-name convention carried forward unchanged from Athena. RFC 1510 is the document Microsoft engineers read when they chose Kerberos v5 as the Windows 2000 default authentication protocol; the krbtgt account became part of the AD schema at the Windows 2000 ship date (RTM December 15, 1999; general availability February 17, 2000) [@windows-2000]. The Microsoft Learn default-accounts page binds the two specifications to the same account: "KRBTGT is also the security principal name used by the KDC for a Windows Server domain, as specified by RFC 4120" [@ms-default-accounts].

RFC 4120, published in July 2005 by Neuman, Yu, Hartman, and Raeburn, obsoleted RFC 1510 [@rfc4120]. The principal name carried forward unchanged again. Section 5.3 defines the wire format of a ticket; §6.2 defines the principal-name convention. Microsoft Open Specifications then published the first [MS-KILE] revision in March 2007, documenting the Windows wire profile on top of RFC 4120. The current revision -- 47.0, dated April 27, 2026 -- still says the same thing: the krbtgt long-term key encrypts every TGT [@mskile]. The Microsoft overlay on top of the IETF specification is the AD-account-management surface: RID 502 fixed, password system-generated, password-history-of-2, disabled-for-interactive-logon, automatic provisioning at first-DC promotion [@ms-default-accounts][@ms-forest-recovery].

Every Kerberos domain on the public Internet today has a krbtgt principal in it. The name has not moved in thirty-eight years. Only the AD-specific overlay is what gives this article its Windows-specific subject; the protocol substrate is older than the attack surface by twenty-six years.

The principal name and the trust property are nearly forty years old. The exploit chain that targets them is twelve. The interesting question is what happened in the twelve years that turned an academic design decision into the most consequential single key in enterprise computing. That story has a beginning at Black Hat USA on August 7, 2014.

5. The Attack Cascade, 2014 to 2024

Six generations of attack span ten years. None of them found a way to forge a TGT without the krbtgt key; the search space is mathematically closed in that direction. What they did instead is get progressively better at hiding the forgery inside genuine-looking wire traffic. By 2022, the forgery and the legitimate TGT are wire-indistinguishable. Here is how that arc unfolded.

gantt title Attack and defence generations dateFormat YYYY-MM-DD axisFormat %Y section Attack Gen 0 Academic baseline :done, g0, 2000-02-01, 2014-08-05 Gen 1 MS14-068 PAC forgery :crit, g1, 2014-11-18, 90d Gen 2 Golden Ticket :crit, g2, 2014-08-07, 2920d Gen 3 Silver Ticket : g3, 2015-01-01, 4000d Gen 4 Diamond Ticket :crit, g4, 2022-06-21, 1700d Gen 5 Sapphire Ticket :crit, g5, 2022-10-15, 1300d section Defence MS14-068 patch :done, d1, 2014-11-18, 30d MDI alert family :done, d2, 2016-01-01, 800d Full PAC Signature audit :done, d3, 2022-12-13, 210d Full PAC Signature enforce :done, d4, 2023-07-11, 90d Compatibility removed :done, d5, 2023-10-10, 30d

Generation 0 (pre-November 2014): the academic baseline

Two assumptions held for fourteen years between Windows 2000 RTM and Black Hat USA 2014. First, the PAC's two signatures -- the Server Signature and the KDC Signature -- were treated as adequate; the [MS-PAC] specification required the KDC Signature to be a keyed HMAC under the krbtgt key, but Windows KDCs in practice accepted weaker non-keyed checksums on it (CRC32, RSA-MD5) [@mspac][@ms14068]. Second, the long-term krbtgt key was held only on writeable DCs and was considered unreachable to remote attackers because no remote primitive existed to extract it. Both assumptions failed within months of each other. The MS14-068 disclosure broke the first; the productionised DCSync primitive in Mimikatz broke the second.

Generation 1 (November 18, 2014): MS14-068 and CVE-2014-6324

On November 18, 2014, Microsoft published security bulletin MS14-068, "Vulnerability in Kerberos Could Allow Elevation of Privilege (3011780)" [@ms14068]. The disclosure: the KDC validated PACs using a checksum algorithm that did not actually depend on the krbtgt key. Any authenticated domain user could forge a PAC asserting Domain Admin group membership, attach it to an otherwise-valid AS-REQ exchange, and the KDC would accept the forgery. The NVD entry for CVE-2014-6324 records that the bug "allows remote authenticated domain users to obtain domain administrator privileges via a forged signature in a ticket, as exploited in the wild in November 2014, aka 'Kerberos Checksum Vulnerability'" [@cve-2014-6324]. CVSS 9.0. Critical for every supported Windows Server SKU. Exploited in the wild within hours of the bulletin.

Discovery credit for MS14-068 appears across Metasploit module authorship, AttackerKB, and several practitioner write-ups as Tom Maddock. The MSRC bulletin verbatim says only "privately reported" and does not name the reporter publicly [@ms14068]. The Maddock attribution is folk knowledge; the MSRC primary does not confirm it.

Microsoft's patch replaced the weak checksum with a real keyed HMAC under the krbtgt key, the same construction the [MS-PAC] document specifies today. The patch was correct: it restored PAC integrity to actual dependence on a real secret. It also, as a side-effect, elevated the krbtgt key from "an important secret in the directory" to "the load-bearing secret of every authentication decision in the domain." From November 18, 2014 onward, an attacker who held the krbtgt key did not just hold a useful credential; the attacker held the only credential the KDC could not check above.

Key idea: The MS14-068 patch was correct -- it restored PAC integrity to dependence on the krbtgt key. Its side-effect was to elevate the krbtgt key from "important" to "load-bearing for every authentication decision in the domain." From November 18, 2014 onward, the krbtgt key was the single secret worth attacking directly.

Generation 2 (August 7, 2014): Golden Ticket

Skip Duckwall and Benjamin Delpy presented "Abusing Microsoft Kerberos: Sorry you guys don't get it" at Black Hat USA on August 7, 2014 [@infocondb-bh2014]. The technique they demonstrated is what Sean Metcalf later popularised as the Golden Ticket: with the krbtgt key in hand, an attacker forges a TGT from scratch for any principal SID with any group memberships [@adsec-1640]. The KDC validates the TGT by decrypting enc-part with the krbtgt key. There is no upstream authority to check, because krbtgt is the authority. MITRE T1558.001 codifies the technique [@mitre-t1558001]; Benjamin Delpy's Mimikatz kerberos::golden command operationalises it [@mimikatz].

sequenceDiagram participant A as Attacker (holds krbtgt key) participant L as Local Kerberos cache participant K as KDC on a DC participant S as Target service A->>A: Choose target SID and groups A->>A: Build EncTicketPart locally A->>A: HMAC PAC signatures under krbtgt key A->>A: AES-encrypt enc-part under krbtgt key A->>L: kerberos::ptt -- inject ticket L->>K: TGS-REQ presenting forged TGT K->>K: Decrypt TGT with krbtgt key -- valid K->>L: TGS-REP for target service L->>S: Present service ticket -- access granted

The Golden Ticket works because of the single-key trust property the 1988 design chose. There is nothing in the protocol that asks "is this TGT in the KDC's issuance log?" The TGT is self-verifying. If it decrypts and its signatures validate under the key, it is, by definition, a TGT.

Why, then, does Golden Ticket sometimes get caught? Because the default Mimikatz invocation leaves four observable artefacts that Microsoft Defender for Identity ships dedicated alerts for, under the umbrella of the Suspected-Golden-Ticket alert family [@mdi-classic][@mdi-credential]. Mimikatz historically defaulted to RC4-HMAC encryption (enctype 23), which is anomalous on a modern AD where AES is standard. Mimikatz historically defaulted to a ten-year ticket lifetime, against the AD MaxTicketAge default of ten hours. The attacker frequently asserts groups the user does not actually hold, which produces a "forged authorization data" anomaly. And the attacker sometimes forges a ticket for an account that does not exist in the directory at all, which produces a "nonexistent account" anomaly. Microsoft's live MDI alerts page enumerates six External IDs in the family: 2009 (encryption downgrade), 2013 (forged authorization data), 2022 (time anomaly), 2027 (nonexistent account), 2032 (ticket anomaly), and 2040 (ticket anomaly using RBCD) [@mdi-classic].

The structural observation: every alert in this family detects symptoms of forging from scratch. None of them detects the primitive of holding the krbtgt key. That distinction is what makes Generation 4 (Diamond) and Generation 5 (Sapphire) interesting.

Generation 3 (parallel path): Silver Ticket

Silver Tickets forge a service ticket (TGS) under a captured service-account key. They sidestep the krbtgt key entirely; the KDC is never involved in the forgery, and the forgery validates only against the one service whose key was captured. MITRE T1558.002 catalogues the technique [@mitre-t1558002]. Mentioned here so the question stops being asked. Silver Tickets are a sibling technique that targets a different trust root (per-service account keys), not the krbtgt key.

Generation 4 (June 2022): Diamond Ticket

In June 2022, Andrew Schwartz at TrustedSec and Charlie Clark at Semperis co-published "A Diamond in the Ruff," documenting a refinement of Golden Ticket that defeats every PAC-content anomaly detection in one stroke [@trustedsec-diamond][@semperis-diamond]. The technique: instead of forging the TGT from scratch, the attacker requests a real TGT from the KDC, then decrypts its enc-part using the held krbtgt key, modifies the PAC contents, re-signs the PAC under the krbtgt key, re-encrypts the enc-part, and walks away with a ticket whose every wire property -- sname, cname, authtime skew matching the real KDC's clock, plausible endtime, AES-256 envelope -- looks like a legitimate KDC-issued artefact.

sequenceDiagram participant A as Attacker (low-priv user, holds krbtgt key) participant K as KDC on a DC participant L as Local Kerberos cache participant S as Target service A->>K: AS-REQ for low-priv user K->>A: Real TGT, encrypted under krbtgt key A->>A: Decrypt enc-part with held krbtgt key A->>A: Modify PAC SIDs to Domain Admins A->>A: Recompute PAC signatures under krbtgt key A->>A: Re-encrypt enc-part under krbtgt key A->>L: ptt -- inject modified TGT L->>K: TGS-REQ presenting Diamond TGT K->>K: Decrypt -- valid, signatures match K->>L: TGS-REP for target service L->>S: Access granted as Domain Admin

Every MDI Suspected-Golden-Ticket detection disappears, by construction. The encryption type is AES-256 because the KDC issued it that way. The lifetime matches the AD policy because the KDC set it that way. The cname matches a real account because the attacker requested the TGT as a real low-privilege account they own. The only thing the attacker changed is the group SIDs inside the PAC, and the PAC signatures revalidate because the attacker recomputed them under the same krbtgt key the KDC would have used.

TrustedSec verbatim: Diamond "would almost certainly require access to the AES256 key" [@trustedsec-diamond]. The KDC issued the real TGT in AES-256, so the attacker needs the AES-256 key to decrypt and re-encrypt -- not just the RC4 NTLM hash that the classic Golden Ticket can use.

The Diamond Ticket disclosure pointed at an architectural problem: with the krbtgt key in hand, every PAC-content anomaly detection is defeated. Microsoft's structural answer was the Full PAC Signature in November 2022. We come to that in Generation 6.

Generation 5 (October 2022): Sapphire Ticket

Charlie Bromberg, who publishes under the handle Shutdown (@_nwodtuhs) at Synacktiv and maintains The Hacker Recipes wiki, disclosed Sapphire Ticket in October 2022 [@hackrecipes-sapphire][@shutdownrepo-sapphire]. Where Diamond modifies the PAC, Sapphire splices the PAC. The procedure abuses two Kerberos extensions in combination -- Service-for-User-to-Self (S4U2self) and User-to-User (U2U) -- to coerce the KDC into issuing a service ticket whose embedded PAC describes a target user the attacker wishes to impersonate. The attacker then extracts that genuine PAC from the service ticket and embeds it, unchanged, in a freshly constructed TGT signed under the held krbtgt key.

A Kerberos extension that lets a service request a ticket *to itself*, on behalf of another user, without that user presenting credentials. Originally designed for protocol-transition scenarios (a web service accepting forms-based auth and translating it to Kerberos for downstream calls). Defined in [MS-SFU] (Kerberos Protocol Extensions: Service for User and Constrained Delegation Protocol); referenced from [MS-KILE] [@mssfu]. A Kerberos extension defined in RFC 4120 §3.7 that allows a ticket to be encrypted under the recipient's session key rather than its long-term key, enabling two clients to authenticate to each other without either being a KDC-registered service [@rfc4120]. sequenceDiagram participant A as Attacker (low-priv user, holds krbtgt key) participant K as KDC on a DC participant L as Local Kerberos cache participant S as Target service A->>K: AS-REQ for low-priv user K->>A: Real attacker TGT A->>K: S4U2self + U2U TGS-REQ for target user K->>A: TGS containing target user's genuine PAC A->>A: Extract genuine PAC from TGS A->>A: Build new TGT, embed genuine PAC A->>A: Sign three PAC signatures under krbtgt key A->>A: Encrypt enc-part under krbtgt key A->>L: ptt -- inject Sapphire TGT L->>K: TGS-REQ presenting Sapphire TGT K->>K: Decrypt -- valid, PAC is genuine K->>L: TGS-REP for target service L->>S: Access granted as target user

By construction, there is no PAC-content anomaly to detect: the PAC inside the resulting TGT is literally a PAC the KDC issued for the target user, because the KDC did issue it. The PAC's three signatures revalidate because the attacker held the krbtgt key to sign them; if Microsoft validates the Full PAC Signature on incoming tickets, that signature also validates because the attacker computed it under the same krbtgt key. Detection must move to traffic-flow analysis -- specifically, the anomalous S4U2self plus U2U TGS-REQ sequence on the wire -- and as of May 2026 no vendor has shipped a clean canonical default-enabled analytic for that signal [@unit42-gemstones].

The Sapphire Ticket disclosure is widely misattributed to Charlie Clark (Semperis). The primary tooling artefact -- the Impacket PR #1411 conversation thread -- addresses the author as @ShutdownRepo, who is Charlie Bromberg of Synacktiv [@impacket-1411]. The Hacker Recipes wiki and pgj11.com both confirm Bromberg as the author of record [@hackrecipes-sapphire][@pgj11]. The misattribution conflates Sapphire with Clark's separate "AS Requested Service Tickets" technique.

The empirical artefact is the Impacket pull request #1411, in which Bromberg added the -impersonate flag to ticketer.py to put the tool into "sapphire ticket mode" [@impacket-1411][@shutdownrepo-sapphire]. Palo Alto Unit 42's "Precious Gemstones" survey is the vendor-side state-of-the-art summary [@unit42-gemstones].

Generation 6 (November 2022 to October 2023): KrbtgtFullPacSignature

Microsoft's formal response to the post-2014 attack arc shipped as KB5020805 starting November 8, 2022, addressing CVE-2022-37967 [@kb5020805][@cve-2022-37967]. The fix adds a new PAC signature -- the Full PAC Signature -- computed by the KDC over the entire PAC including the older two signatures, validated on incoming tickets, and rolled out across five deployment phases:

Phase	Date	Mode	`KrbtgtFullPacSignature` value
Initial Deployment	November 8, 2022	Signatures added, validation disabled	1 (Compatibility)
Second Deployment	December 13, 2022	Audit mode default	2 (Audit)
Third Deployment	June 13, 2023	Cannot disable signature addition	(value 0 removed)
Default Enforcement	July 11, 2023	Enforcement default	3 (Enforcement)
Removal of Compatibility	October 10, 2023	Audit removed, Enforcement permanent	(registry key removed)

KB5020805 documents the final state verbatim: "Windows updates released on or after October 10, 2023 will do the following: Removes support for the registry subkey KrbtgtFullPacSignature. Removes support for Audit mode. All service tickets without the new PAC signatures will be denied authentication" [@kb5020805].

Note: The KB number for KrbtgtFullPacSignature is KB5020805, not KB5021131. KB5021131 is the paired but distinct KB for CVE-2022-37966 (encryption-type enforcement). The PAC-signature-specific KB is KB5020805. Secondary sources routinely confuse the two.

Here is the structural fact. The Full PAC Signature is also computed under the krbtgt key. So an attacker who holds the krbtgt key still mints fully-validating tickets, including:

Sapphire Tickets, which never modify the PAC at all; the existing signatures the KDC issued are valid by construction, the Full PAC Signature included.
Recomputed Diamond Tickets, in which the attacker simply computes the Full PAC Signature alongside the older KDC signature in the same step, because both depend on the same key the attacker holds.

KrbtgtFullPacSignature retired one specific class of attack (Diamond Tickets that did not recompute the Full PAC Signature). It did not retire the underlying primitive (TGT forgery from a known krbtgt key). The PAC signature surface in Section 3 -- all three signatures terminating at the same key -- is exactly why this is so.

Key idea: The Full PAC Signature was Microsoft's structural response to Diamond Ticket. It is itself computed under the krbtgt key. So an attacker who holds the krbtgt key recomputes it in the same step as the KDC signature -- and Sapphire Tickets, which never modify the PAC at all, are unaffected by construction. CVE-2022-37967 retired one class of attack (PAC-modifying Diamond variants); it did not retire the primitive.

Comparing the three forgery variants

Dimension	Golden	Diamond	Sapphire
Requires krbtgt key?	Yes	Yes (AES-256)	Yes (AES-256)
Calls the KDC?	No (forges from scratch)	Yes (real AS-REQ)	Yes (AS-REQ + S4U2self+U2U)
Modifies the PAC?	Builds it from scratch	Yes (group SIDs)	No (genuine PAC)
Defeats MDI encryption downgrade alert?	No (defaults RC4)	Yes (real AES)	Yes (real AES)
Defeats MDI time-anomaly alert?	No (defaults 10y)	Yes (KDC lifetime)	Yes (KDC lifetime)
Defeats MDI forged-auth-data alert?	No	Yes (still triggers if group mismatch detected via other means)	Yes (PAC is genuine)
Defeats Full PAC Signature (post-July 2023)?	Yes (recomputed under held key)	Yes (recomputed)	Yes (genuine PAC)
Known wire-residual?	Encryption type, lifetime, groups	Re-encryption-under-held-key timing	S4U2self+U2U conjunction

Six generations from MS14-068 to KrbtgtFullPacSignature, and the residual primitive is exactly what the 1988 paper described: hold the key, mint the ticket. So what does the detection topology in 2026 actually catch?

6. The Detection Stack in 2026

Detection of krbtgt-class attacks in 2026 is a four-layer stack. Each layer has a specific class of signal it reads, a specific class of attack it catches, and a specific gap that the next layer is supposed to close. Three of the four layers have a known gap above them. The fourth has nothing above it.

flowchart TD L4["Layer 4 -- S4U2self plus U2U residual (no vendor analytic shipped)"] L3["Layer 3 -- Network/SIEM (Sentinel, Splunk T1558.001)"] L2["Layer 2 -- Behavioural (MDI Suspected-Golden-Ticket family)"] L1["Layer 1 -- Posture (BloodHound DCSync edge)"] KEY["krbtgt long-term key (the attacker's objective)"] L1 --> L2 L2 --> L3 L3 --> L4 L4 --> KEY

Layer 1: posture (BloodHound DCSync edge)

The posture layer asks a question with no per-event component: "Who has rights that could extract the krbtgt key, regardless of whether they have used those rights?" In Active Directory terms, the answer is "anyone holding DS-Replication-Get-Changes plus DS-Replication-Get-Changes-All rights against a writeable DC, plus anyone who holds privileges that allow them to grant those rights to themselves." BloodHound encodes the answer as a DCSync edge in its graph; the canonical community Cypher query is MATCH (u)-[:DCSync]->(d:Domain) RETURN u, d. The current shipping release of BloodHound Community Edition is v9.1.0, dated 2026-05-06 per the release notes [@bloodhound-notes].

A replication primitive Mimikatz first productionised in August 2015. The attacker invokes the `DRSGetNCChanges` API call against a writeable domain controller, masquerading as a peer DC, and the target DC obligingly streams back the requested account secrets including the krbtgt long-term key. MITRE T1003.006 catalogues the technique [@mitre-t1003006]. Sean Metcalf's adsecurity.org write-up notes "DCSync was written by Benjamin Delpy and Vincent Le Toux" [@adsec-1729].

What this layer detects: any principal whose existing AD permissions create a path to the krbtgt key. What this layer misses: any attacker who already has the key. Posture is preventive, not detective. By the time the attacker is invoking kerberos::golden, the posture layer has already missed its window.

Layer 2: behavioural (Microsoft Defender for Identity)

Microsoft Defender for Identity ships an alert family covering classic Golden-Ticket-from-Mimikatz behaviour. The live MDI classic alerts page enumerates six Suspected-Golden-Ticket External IDs: 2009 (encryption downgrade), 2013 (forged authorization data), 2022 (time anomaly), 2027 (nonexistent account), 2032 (ticket anomaly), and 2040 (ticket anomaly using RBCD) [@mdi-classic]. The Credential access section adds External ID 2006 for "Suspected DCSync attack" on the extraction side [@mdi-classic].

What this layer detects: the Mimikatz Golden Ticket defaults plus the DCSync extraction primitive that produces the krbtgt key in the first place. What this layer misses: Diamond and Sapphire by construction. Diamond removes the PAC-content anomalies because every artefact except the modified group SIDs comes from the real KDC. Sapphire defeats PAC-content anomaly detection entirely by using a PAC the KDC genuinely issued via S4U2self plus U2U.

The MDI credential-access alerts page is the entry point to the family in the modern Microsoft Defender XDR console layout [@mdi-credential].

Layer 3: network and SIEM (Sentinel, Splunk)

Multi-vendor SIEM content packs ship analytic rules covering Kerberos behaviours flagged under MITRE T1558.001. Splunk's research catalogue contains the canonical example: "Kerberos Service Ticket Request Using RC4 Encryption" detects TGS-REQ traffic with encryption-type 0x17 (RC4-HMAC), leveraging Windows Event 4769 from the DCs [@splunk-7d9]. Microsoft Sentinel ships parallel rules under the Microsoft Defender XDR content connector. The pattern these analytics share is reliance on encryption-type anomalies, group-membership anomalies, or lifetime anomalies that appear in Windows event logs after the fact.

What this layer detects: signature-style indicators of Golden Ticket behaviour on the wire and in the DC event log. What this layer misses: the same encryption-downgrade dependency MDI's alert 2009 has. The Splunk analytic verbatim acknowledges its own limit: "This detection may be bypassed if attackers use the AES key instead of the NTLM hash" [@splunk-7d9]. Diamond and Sapphire both use the AES-256 key. Both walk through this layer untouched.

Note: Microsoft Sentinel ships rules called "Kerberoasting" that target MITRE T1558.003 (extracting service-account secrets by requesting SPN-bearing service tickets and brute-forcing the resulting RC4-encrypted blobs offline). Those rules target service accounts with SPNs registered against them. They are not a krbtgt detection asset. The krbtgt account does not have an SPN that any client can request a TGS for; the relevant Sentinel content for krbtgt-class attacks is the T1558.001 Golden-Ticket and Kerberos-anomaly analytic family.

Layer 4: the Sapphire residual

What would catch a Sapphire Ticket? The only wire-observable residual of the technique is the conjunction of (a) a TGS-REQ specifying the S4U2self flag, and (b) the same TGT being used to address a User-to-User request to the KDC. No other layer of the stack reads this signal because no other attack has historically produced it as a precondition.

What ships: nothing canonical. SpecterOps and the BloodHound content team have signalled graph-query work on the U2U TGS issuance pattern in 2026 trend reports [@bloodhound-notes], but no shipped default-enabled analytic. Palo Alto Unit 42's "Precious Gemstones" survey describes Cortex XDR detection-attempt heuristics but does not publish the rule [@unit42-gemstones]. The gap is engineering, not theoretical: the signal exists, the analytic to read it has simply not been packaged.

Note: No vendor analytic shipped for the S4U2self plus U2U conjunction as of May 2026. Sapphire is the current frontier and the article's "what 2026 still cannot do" gap. An attacker who holds the krbtgt key and uses the Sapphire technique walks past every shipping detection layer.

SpecterOps and the BloodHound content team have signalled graph-query work on the U2U TGS issuance pattern; Palo Alto Unit 42's "Precious Gemstones" survey describes Cortex XDR detection-attempt heuristics [@unit42-gemstones]. Neither has shipped a clean canonical default-enabled analytic. The gap is engineering, not theoretical, and it is the active research front for the 2026 to 2028 cycle.

Defensive method matrix

Method	Catches Golden?	Catches Diamond?	Catches Sapphire?	Layer
BloodHound DCSync edge	preventive only	preventive only	preventive only	1
MDI Suspected-Golden-Ticket (4 alerts)	yes	no	no	2
MDI Suspected DCSync (ID 2006)	extraction step only	extraction step only	extraction step only	2
Sentinel / Splunk T1558.001 RC4 rule	yes (if RC4)	no	no	3
Sentinel Kerberos-anomaly content pack	partial (lifetime/groups)	no	no	3
Full PAC Signature (post-July 2023)	n/a (already signed correctly)	retires non-recomputing variants	no	n/a (cryptographic enforcement, not detection)
S4U2self+U2U conjunction analytic	n/a	n/a	would catch	4 (not shipped)

Adjacent T1558 family techniques that are not krbtgt detections

Technique	What it targets	krbtgt detection?
T1558.002 Silver Ticket	service-account long-term keys	no
T1558.003 Kerberoasting	SPN-bearing service accounts via offline RC4 crack	no
T1558.004 AS-REP Roasting	accounts with pre-auth disabled	no
OverPass-the-Hash	user NTLM hashes via Kerberos PA-DATA	no

Detection in 2026 is a four-layer stack, and three of the layers leave gaps the next layer is supposed to close. The fourth gap -- the Sapphire residual -- has no layer above it. When the gaps close enough to confirm a krbtgt compromise, what does recovery actually look like?

7. Recovery: What the Two-Reset Procedure Actually Does

The Microsoft AD Forest Recovery page states the procedure verbatim:

"You should perform this operation twice. You must wait 10 hours between password resets. 10 hours are the default Maximum lifetime for user ticket and Maximum lifetime for service ticket policy settings, hence in a case where the Maximum lifetime period changes, the minimum waiting period between resets should be greater than the configured value." -- and -- "The password history value for the krbtgt account is 2, meaning it includes the two most recent passwords. By resetting the password twice you effectively clear any old passwords from the history, so there's no way another DC replicates with this DC by using an old password." [@ms-forest-recovery]

What exactly do those two resets buy, and what do they not buy?

The mechanics of two-slot eviction

The krbtgt account, like every other AD account, stores both current and previous keys. A TGT issued at time $T = 0$ under key $K_0$ continues to validate after a rotation at $T = T_1$ (when $K_1$ becomes current and $K_0$ moves to the previous slot), because the KDC tries both keys during the in-flight validation window. One rotation fills the previous slot with the now-replaced $K_0$; the second rotation, separated by at least MaxTicketAge so that all $K_0$-signed TGTs have expired naturally, fills the previous slot with $K_1$ and evicts $K_0$ entirely. After the second rotation completes and replicates, no key in the krbtgt account matches the attacker's extracted $K_0$; forged TGTs from that key fail validation cleanly [@ms-forest-recovery].

The Kerberos policy value that bounds the lifetime of a Ticket-Granting Ticket from the moment of issuance. The Active Directory default is 10 hours, configured via the Default Domain Policy. The AD Forest Recovery procedure waits at least `MaxTicketAge` between krbtgt resets to ensure no in-flight TGT outlives the period between the two rotations [@ms-forest-recovery]. flowchart LR A0["T=0: K_0 current, K_prior previous"] --> A1["T=T_1: reset 1 -- K_1 current, K_0 previous"] A1 --> A2["T_1 + 10h: K_1 still current, K_0 still previous"] A2 --> A3["T=T_2 (≥ T_1 + 10h): reset 2 -- K_2 current, K_1 previous"] A3 --> A4["After replication: K_0 evicted from both slots"]

The 10-hour wait between resets is not a Microsoft convenience choice; it is a cryptographic requirement. If the second reset lands before all $K_0$-signed TGTs have expired naturally, some of those tickets will hit a DC whose previous slot now holds $K_1$ rather than $K_0$, and the KDC will reject them. This is what KB5020805's PAC-signature deployment phases also had to navigate during the November 2022 to October 2023 rollout: signature additions and validation transitions had to bracket the maximum in-flight ticket lifetime [@kb5020805].

{` // Model the krbtgt account as a two-slot store; simulate the two-reset procedure. function simulate(events) { const slots = { current: "K_prior", previous: null }; let stolen = null; for (const ev of events) { if (ev.kind === "compromise") { stolen = slots.current; } else if (ev.kind === "reset") { slots.previous = slots.current; slots.current = ev.newKey; } const validates = stolen && (stolen === slots.current || stolen === slots.previous); console.log( "[t=" + ev.t.toString().padStart(3) + "h]", ev.kind.padEnd(11), "current=" + slots.current, "prev=" + (slots.previous ?? "-"), "attacker_validates=" + validates ); } }

simulate([ { t: 0, kind: "issue" }, { t: 1, kind: "compromise" }, // attacker stores K_prior as stolen { t: 3, kind: "reset", newKey: "K_1" }, { t: 13, kind: "reset", newKey: "K_2" }, // ≥ MaxTicketAge later { t: 14, kind: "issue" }, ]); `}

`New-KrbtgtKeys.ps1`

Microsoft's reference automation for the procedure is New-KrbtgtKeys.ps1, originally distributed as an MSDN Gallery script and currently hosted in the microsoftarchive GitHub organisation. The repository banner reads, verbatim: "This repository was archived by the owner on Mar 8, 2024. It is now read-only" [@new-krbtgt-keys]. The script remains the canonical reference for the rotation procedure, including pre-reset and post-reset replication-health checks; it is simply no longer actively maintained. Operators in 2026 commonly fork it locally or wrap the same Set-ADAccountPassword plus replication-status pattern in their own runbooks.

What two-reset does

Cryptographically invalidates previously-forged TGTs after the second reset replicates fully across all writeable DCs. This is unambiguous and well-documented; the Microsoft Learn page is the primary [@ms-forest-recovery]. After step 3 (the second reset) has replicated, no TGT signed under the pre-compromise key validates anywhere in the domain.

What two-reset does not do

Any attacker who held the krbtgt key has typically already installed parallel persistence. SpecterOps's "Domain of Thrones Part II" by Nico Shyne and Josh Prager, published November 6, 2023, names the rotation list verbatim: "Machine accounts ... User accounts ... Service accounts -- Per domain KRBTGT account ... Trust keys and objects related to trust of all other domains; Group-managed service accounts; Key distribution service root keys" [@specterops-dot2]. The same playbook enumerates the persistence vectors an attacker with krbtgt access typically establishes: AdminSDHolder ACL edits, AD CS template alternates spanning the ESC1 through ESC8 abuse classes (canonically catalogued in Schroeder and Christensen's "Certified Pre-Owned," SpecterOps, June 2021) [@certified-pre-owned], SID History entries, machine-account secret retention, KDS root key exfiltration, trust-key compromise, and DSRM password exfiltration. Two-reset rotates the krbtgt key only; the rest of the trust-root set is untouched [@specterops-dot1][@specterops-dot2].

Key idea: Two-reset rotation cryptographically invalidates previously-forged TGTs. It does NOT rotate any of the other secrets an attacker who held the krbtgt key has typically already installed: AdminSDHolder edits, ADCS templates, SID History, machine-account secrets, KDS root keys, trust keys, DSRM passwords. This is why confirmed krbtgt compromise is a forest-rebuild event, not a key-rotation event.

Two-reset rotation is the cryptographic finish; the operational finish spans the rest of the Domain-of-Thrones surface, and the rotation alone cannot reach it. The single-sentence punchline of the article lands at the end of §11.

Why does Microsoft's AD Forest Recovery page treat krbtgt rotation as a recoverable rotation event while Mandiant-style and SpecterOps-style playbooks treat confirmed krbtgt compromise as a forest-rebuild event? Both statements are true at once. Microsoft documents the *cryptographic* recovery, which terminates at the krbtgt key. The IR playbooks document the *operational* recovery, which spans seven additional secret classes whose compromise the krbtgt holder typically also achieved. The cryptographic recovery is necessary and well-bounded; the operational recovery is necessary and not bounded by the same key.

Recovery has two pieces: a fast cryptographic part (two resets, well-documented) and a slow operational part (seven other secret classes, days to weeks). Both are necessary. Neither is sufficient. Even the combined procedure leaves three structural residuals, which the next section names.

8. Theoretical Limits and Open Problems

Even with the full Domain-of-Thrones rotation surface executed correctly, three structural residuals remain. Each has a current best-partial-result; none has a closed solution.

(a) The pre-second-reset TGT-lifetime window

Any TGT minted from the compromised krbtgt key between the moment of compromise and the moment the second reset replicates remains valid until naturally expired or until step 3 lands. Mimikatz's default 10-year lifetime makes this a years-long window if the attacker pre-minted tickets and a careless DC missed the time-anomaly signal. The MDI Suspected-Golden-Ticket family includes a time-anomaly alert (the External ID 2022 sibling) [@mdi-classic] that reads the difference between plausible and implausible ticket lifetimes. The window is bounded above by the AD MaxTicketAge floor: at minimum, the procedure must take 10 hours of wall-clock per Microsoft's own guidance [@ms-forest-recovery]. Below that floor the cryptographic invalidation does not finish.

The mitigation is procedural: between detection and the start of the rotation, the IR team treats every TGT in the domain as suspect. In practice that means rejecting cached tickets at high-value services, forcing a TGT renewal cycle, and watching the time-anomaly alert closely. The mitigation is not perfect; an attacker who minted tickets with realistic 10-hour lifetimes inside the typical AD policy survives this residual entirely.

(b) AD CS alternate persistence (the ESC class)

An attacker who held the krbtgt key long enough to also touch AD Certificate Services has often installed an ESC-class alternate-identity persistence: a backdoored certificate template allowing Domain Admin certificate issuance (ESC1), a misconfigured EnrolleeSuppliesSubject template (ESC4), an HTTP-bound CA endpoint vulnerable to NTLM relay (ESC8). The ESC class taxonomy is catalogued in Schroeder and Christensen's "Certified Pre-Owned" white paper (SpecterOps, June 2021) [@certified-pre-owned]. The compromised template or endpoint survives krbtgt rotation entirely. The CA private key is its own trust root, parallel to (not subordinate to) the krbtgt key. Domain-of-Thrones Part II names ADCS as a separate rotation workstream that must be addressed alongside the krbtgt reset [@specterops-dot2].

The structural fact: a domain with AD CS deployed has at least two cryptographic trust roots (krbtgt long-term key + CA private key) whose compromises are both recoverable only through different mechanisms. PKINIT, the Kerberos pre-authentication extension that validates certificate-bearing AS-REQs, accepts identities the CA chain attests to. Compromise of the CA chain yields valid Kerberos authentication as any principal, by a different mechanism than holding the krbtgt key, with the same end result.

(c) Cross-domain trust-key compromise

Within a multi-domain forest, the krbtgt of each domain is trusted by the others through inter-domain trust keys. A krbtgt compromise in a child domain can become a forest-level event if the trust topology is not hardened: SID Filtering misconfigurations, missing Selective Authentication on outbound trusts, or stale forest-trust artefacts from earlier domain migrations all extend the blast radius beyond the directly-compromised domain. Microsoft's "Recover from systemic identity compromise" guidance and the AD Forest Recovery procedure index together cover the cross-domain rotation requirements; Domain-of-Thrones Part II's "Trust keys and objects related to trust of all other domains" entry is the concise operational statement [@specterops-dot2].

The mitigation is architectural: domain-isolation discipline at the design phase plus Selective Authentication on all inbound trusts. After the fact, every domain whose krbtgt the compromised domain trusted (directly or transitively) becomes part of the rotation surface.

(d) The HSM-bound krbtgt aspiration

A theoretically clean solution exists in the literature: split the krbtgt key material such that no single party -- including the DC's own KDC service -- could read the full key in cleartext. The construction would be a hardware-security-module-bound krbtgt key (the HSM exposes only sign and verify operations on a key it never releases), or a threshold-cryptography scheme (the key is reconstructed across $n$ DCs, $t$ of which must cooperate per ticket-signing operation). Either construction would close the underlying primitive by making the krbtgt key unreadable in cleartext to anyone with code execution on a DC.

Neither construction is supported by any [MS-KILE] revision through 47.0 dated April 27, 2026 [@mskile]. Neither is on any published Microsoft roadmap as of May 2026. The closest analogues that have shipped -- LSAISO/Credential Guard's VBS trustlet for LSASS secrets on workstations and member servers -- explicitly omit the writeable-DC case by design, because a writeable DC must read the krbtgt key to issue tickets.

Even after two-reset and Domain of Thrones, three residuals remain: a window of time, an alternate trust root, and a topology problem. None of them are theoretical -- all three are operational realities documented in 2024-2026 incident-response practice. But they raise a different question: how does the krbtgt key compare to the other secrets in an AD trust-root set?

9. Where KRBTGT Sits in the AD Trust-Root Set

A correction to a framing that appears in many secondary write-ups: the krbtgt long-term key is one of a small set of "AD trust roots," not the only one. The framing matters because the rotation playbook in Section 7 lists seven secret classes for a reason: each is a candidate trust root that survives compromise of any other.

KRBTGT long-term key. Issues TGTs for all principals in the domain. Unique property within the Kerberos trust root: holding it forges TGTs for arbitrary principals, including ones that do not exist in the directory. Rotation: the two-reset, ten-hour-interval procedure on the AD Forest Recovery page [@ms-forest-recovery].

AD CS root CA private key. Issues certificates that PKINIT trusts for Kerberos pre-authentication. Compromise yields Kerberos auth as any principal via PKINIT -- a different mechanism with the same end result. Rotation: CA hierarchy rebuild, significantly more expensive than krbtgt rotation. SpecterOps "Certified Pre-Owned" (Schroeder + Christensen, June 2021) is the canonical primary on the ESC-class abuses of this trust root, cross-referenced in Domain of Thrones Part II [@certified-pre-owned][@specterops-dot2].

KDS root key. Group Managed Service Account passwords are derived deterministically from a KDS root key plus a per-account msDS-ManagedPasswordId. Compromise of the KDS root key reads every gMSA password in the forest. Different blast radius (service accounts only). Rotation: KDS root key rotation followed by gMSA cycling [@specterops-dot2].

Per-domain inter-domain trust keys. Bridge Kerberos trust between domains in a forest or across explicit external trusts. Compromise yields cross-domain TGT minting. Rotation: per-trust password rotation, with SID Filtering and Selective Authentication audits as the standard hardening procedure.

DSRM passwords on writeable DCs. Directory Services Restore Mode is a local-admin equivalent at the DC level; compromise yields a local logon to the DC, which then enables many other paths including direct read of the krbtgt key from ntds.dit. Rotation: per-DC DSRM password rotation [@specterops-dot2].

The precise framing

Within the Kerberos trust root of a single domain, the krbtgt key occupies a unique position: it is the issuer of every TGT, and forging a TGT requires exactly this key. At the forest-AD-trust-graph level, the krbtgt key is one of a handful of high-cost-to-rotate trust roots, not the only one. The framing matters because it explains why Domain of Thrones Part II lists seven rotation workstreams: each is a candidate path to the same end result (arbitrary identity in the forest) through a different cryptographic mechanism.

Five trust roots, one (krbtgt) with a unique forge-arbitrary-TGTs property, all five surfacing in the rotation list. With the trust-root topology mapped, the article's last technical job is the practical playbook: what does the reader actually do tomorrow morning?

10. Practical Guide: The Rotation and Detection Playbook

Four lanes. Each lane is a concrete action a reader can execute starting tomorrow morning.

Note: Lane 1: Preventive hygiene -- rotate krbtgt twice a year on a calendar schedule and audit who can DCSync. Lane 2: Detection deployment -- ship MDI Suspected-Golden-Ticket alerts plus SIEM T1558.001 content. Lane 3: Confirmed-compromise response -- two-reset rotation followed by the Domain-of-Thrones surface. Lane 4: What does NOT work -- four traps to avoid.

Lane 1: preventive hygiene

Rotate the krbtgt password twice a year on a calendar schedule, regardless of any specific incident. Use New-KrbtgtKeys.ps1 (or a fork of it) with pre-reset and post-reset replication-health checks [@new-krbtgt-keys]. Verify Active Directory replication health between the two rotations; if replication is lagging on any DC, the second reset can outpace the first in some replicas and break in-flight tickets.

Move every Tier-0 account into the Protected Users group. Enable Credential Guard on every workstation and member server. Credential Guard does NOT protect the DC itself by design -- DCs must read the krbtgt key unencrypted -- but it kills the worker-station memory-scrape that initially gets an attacker into a position to pivot to the DC.

Audit who can invoke DCSync. The BloodHound query MATCH (u)-[:DCSync]->(d:Domain) returns every principal whose existing AD permissions can extract the krbtgt key without a DC compromise [@bloodhound-notes][@mitre-t1003006]. Every match should map to a justified administrative role; any unexpected match is a finding.

LSAISO is a Virtualisation-Based Security trustlet that isolates long-term secrets from a SYSTEM-privileged kernel on workstations and member servers. On writeable DCs the design omits LSAISO because the KDC service must read the krbtgt key unencrypted to issue tickets. This is precisely the design property a DCSync-capable attacker exploits.

Note: Two krbtgt rotations per year as preventive hygiene -- not a response to a specific incident. Use New-KrbtgtKeys.ps1 with replication-health checks before, between, and after. The 10-hour wait between rotations is mandatory; do not shorten it [@ms-forest-recovery].

Lane 2: detection deployment

Ship the MDI Suspected-Golden-Ticket alert family plus the DCSync alert (External ID 2006) [@mdi-classic][@mdi-credential]. Confirm the Suspected-Golden-Ticket alerts (2009, 2013, 2022, 2027, 2032, 2040) are active for every domain controller MDI is deployed against. Configure Microsoft Sentinel content-pack rules covering T1558.001 Golden Ticket and Kerberos-anomaly patterns (not the T1558.003 Kerberoasting rules, which target service-account SPNs and are not a krbtgt detection asset). Configure Splunk T1558.001 detection [@splunk-7d9] and tune the encryption-type baseline against legacy systems that legitimately negotiate RC4 (or, better, retire those systems).

Ingest BloodHound for posture-graph visibility. Configure regular collections (the default is weekly) so the DCSync edge list stays current as ACLs change. Cross-reference the DCSync edge inventory against the actual administrative role assignments quarterly.

Lane 3: confirmed-compromise response

When MDI or Sentinel surfaces a confirmed krbtgt compromise -- DCSync extraction observed against a writeable DC, or a Suspected-Golden-Ticket alert with concrete supporting evidence -- the response runs in two parallel tracks. The cryptographic track executes the two-reset rotation: reset the krbtgt password (replicate, verify), wait at least 10 hours, reset again (replicate, verify) [@ms-forest-recovery]. The operational track executes the Domain-of-Thrones Part II rotation surface [@specterops-dot2]:

AD CS template review covering the ESC1 through ESC8 abuse classes [@certified-pre-owned]; replace or restrict templates with EnrolleeSuppliesSubject, broad Enroll permissions, or weak EKU restrictions.
SID History audit (Get-ADUser -Filter * -Properties SIDHistory); investigate every account whose SID History contains a Domain Admins or Enterprise Admins SID.
AdminSDHolder ACL audit; reset Protected Group inherited ACLs and verify the SDProp runs cleanly.
Machine-account secret rotation, especially for Tier-0 servers.
KDS root-key rotation followed by gMSA password cycling.
Trust-key rotation for every inbound and outbound trust.
DSRM password rotation on every writeable DC.

After both tracks complete, re-baseline detection: the post-incident DC event-log baseline will differ from the pre-incident baseline, and detection thresholds may need re-tuning to suppress the resulting alerts.

The reference automation runs against the krbtgt SID specifically, not the friendly name, to avoid any ambiguity with a renamed object. Conceptually: `Set-ADAccountPassword -Identity (Get-ADUser -Filter "objectSID -like '*-502'") -Reset -NewPassword (Convert-To-SecureString (New-RandomPassword) -AsPlainText -Force)`. The Microsoft Learn PowerShell reference for the `Set-ADAccountPassword` cmdlet documents the `-Reset` plus `-NewPassword` parameters used here [@ms-set-adaccountpassword]. The `New-KrbtgtKeys.ps1` script wraps this with replication checks and a confirmation prompt [@new-krbtgt-keys]. Production runbooks always include a pre-check that `Get-ADReplicationFailure` returns no failures before any reset is issued.

Lane 4: what does NOT work

Note: Renaming krbtgt. The RID 502 binding is what the KDC derives from, not the sAMAccountName. The KDC service does not care about the friendly name. Disabling krbtgt. The account is already disabled for interactive logon by design [@ms-default-accounts]. Toggling the field is semantically meaningless to the KDC service, which reads the long-term key directly from the directory. Single rotation. Password-history-of-2 means a single rotation only retires the older of the two keys, leaving the attacker-extracted key (which was current at compromise) still in the previous slot [@ms-forest-recovery]. The procedure must run twice. Treating MDI Suspected-Golden-Ticket alerts as sufficient. Those alerts do not cover Diamond and Sapphire by construction. Sapphire defeats every PAC-content anomaly detection because the PAC is genuine. Confirmed-compromise response must assume the worst even when MDI is silent.

Preventive hygiene, detection deployment, confirmed-compromise response, and four traps to avoid. The FAQ that follows addresses what remains.

11. FAQ

No. It retires Diamond Tickets that do not recompute the Full PAC Signature. It does nothing against tickets minted from a known krbtgt key, including Sapphire Tickets (no PAC modification) and recomputed Diamond Tickets (the attacker holds the key and can compute the new signature in the same step as the older KDC signature) [@kb5020805][@mspac]. No. See §10 Lane 4 trap #1: the RID 502 binding is what the KDC derives from, not the `sAMAccountName` [@ms-default-accounts][@ms-sids]. No. See §10 Lane 4 trap #3: password-history-of-2 keeps the previous key valid after a single rotation, so the procedure must run twice with at least `MaxTicketAge` between resets [@ms-forest-recovery][@new-krbtgt-keys]. No. See §10 Aside on why Credential Guard skips the DC: the KDC service on a writeable DC must read the krbtgt key unencrypted to issue tickets, and DCSync is a remote replication API call (DRSGetNCChanges), not a local LSASS memory scrape [@mitre-t1003006][@ms-credential-guard]. Mechanically, in-flight TGT validation requires the previous-key slot to retain validity for at least `MaxTicketAge` after each rotation. Operationally, the recommended cadence is calendar-driven preventive rotation twice a year, with incident-driven rotation as a separate workstream when confirmed compromise is detected [@ms-forest-recovery]. Indirectly. It forces all krbtgt-encrypted tickets to AES, raising the offline-crack bar against a captured ticket and reducing the surface for the Splunk RC4-Kerberos-anomaly detection family [@splunk-7d9]. It does not affect attacks against a captured krbtgt key; both AES-128 and AES-256 derivations are held in the same account and both validate forged TGTs cleanly. Yes. Each Read-Only Domain Controller has its own `krbtgt_` account whose key signs TGTs only for principals that the RODC can authenticate [@adsec-483]. The full-domain krbtgt is the only account whose key signs TGTs accepted by every DC in the domain; compromise of an RODC-specific `krbtgt_` is a contained event whose blast radius is bounded by the RODC's allowed-list policy. No. The IAKerb and Local KDC features shipping in recent Windows builds affect *where* KDCs run (allowing client-to-client Kerberos without a domain-joined intermediary), not the krbtgt-key trust root inside a domain. The post-RC4 enctype work affects *which* enctypes the krbtgt key derives, not the role of the key. As of [MS-KILE] revision 47.0 dated April 27, 2026, the krbtgt long-term key is still the sole trust anchor for every TGT in the domain [@mskile].

One sentence to take away

Krbtgt rotation invalidates forged TGTs; it does not recover the systemic compromise that produced the forged TGTs in the first place.

That is the precise sentence to keep from ten thousand words. The cryptographic question -- "is the ticket valid?" -- terminates at one key. The operational question -- "is the domain still ours?" -- never does. The 1988 design chose to make ticket validation a property of a single shared secret because that choice made the protocol simple and provably correct. The choice remains correct in 2026. What changed is the meaning of the word compromise: in 1988 the threat model was a passive eavesdropper on a campus LAN; in 2026 the threat model is a remote API call that streams the secret across a DRSGetNCChanges exchange. The key did not move. The attacker's reach did.

Who is allowed to log in where? The KDC-side answer to credential theft in Active Directory

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

Every NTLM and Kerberos credential-theft chain reduces to one operational question: which accounts will the directory authenticate, from which machines, with what credential materials? Active Directory's KDC-side answer arrived in a single October 2013 release -- the tier model (policy intent), the Protected Users security group (a non-configurable credential-restriction switch), and Authentication Policy Silos (KDC-enforced TGT-acceptance rules). It has since acquired residual closures (the November 2021 PAC hardening, the May 2022 PKINIT strong-mapping) and a cloud counterpart (Entra Conditional Access, a second independent enforcement plane). This article traces the 28-year arc from Paul Ashton's April 1997 pass-the-hash post to the 2026 reference deployment, names the four residuals the KDC cannot close by construction, and gives a six-phase playbook for putting the three controls into production this quarter.

1. Two accounts, one TGT, every domain controller

On a Tuesday morning in April 1997, an independent researcher named Paul Ashton posted to the NTBugtraq mailing list. His patched Samba smbclient did not accept a password. It accepted the hash, and the file server gave it everything [@exploit-db-19197]. The directory had no answer for the next sixteen years.

Skip forward to today. A domain admin's laptop is compromised by a phishing payload. The attacker runs Mimikatz against lsass.exe, recovers a Kerberos ticket-granting ticket for the admin account, and from that TGT every domain controller in the forest is reachable. The detection engineer who pulls the incident report knows exactly what happened. The architect on the other side of the table knows the answer was never going to come from the workstation, from the smartcard, or from the RDP client. It had to come from the directory.

This is what every credential-theft chain reduces to: a question about which accounts the directory will authenticate, from which machines, with which credential materials, for how long, and to whom they may delegate. Until October 2013, Active Directory had no place to answer that question. It had access-control lists, group memberships, and an AdminSDHolder template that re-stamped privileges every hour [@metcalf-p1906]. None of those mechanisms could refuse to issue a stolen credential, because on the wire a stolen credential is identical to a legitimate one.

Windows Server 2012 R2 changed that on October 18, 2013 [@save-date-blog]. In a single release, the directory acquired three controls that compose into one operational answer. The tier model names which accounts and machines belong to which control plane: T0 holds the domain controllers and the systems that manage them, T1 holds servers and business data, T2 holds workstations [@ms-eam]. The Protected Users security group (well-known RID 525) imposes a non-configurable credential-restriction set: no NTLM, no DES or RC4 in Kerberos, no delegation, no cached offline-sign-in verifier, and a four-hour non-renewable TGT cap [@ms-pu-current]. Authentication Policies and Authentication Policy Silos are directory objects that tell the Key Distribution Center (KDC) which source machines may authenticate which accounts, at AS-REQ time, before any TGT exists to be stolen [@ms-aps].

If you arrived here from the earlier posts in this series: this is the operational counterpart to the NTLM relay story, to the Kerberoasting story, and to the Credential Guard story. Silos are how the KDC says no; Credential Guard is how the host says no; Conditional Access is how the cloud says no. The three planes are independent and they compose.

Key idea: The on-prem AD KDC, keyed on directory state read at issuance time, is the operational answer to credential-theft attack chains. The directory decides which accounts may authenticate, from which machines, with which credential materials, for how long, and to whom they may delegate. The three controls -- tier model, Protected Users, Authentication Policy Silos -- compose into that decision.

The rest of this article pays off the question Ashton's 1997 post raises. Why did the directory have no answer for sixteen years? What changed in October 2013 that the pre-2013 controls could not deliver? What does a working 2026 deployment look like, and what does it still leave open?

2. Why the directory had no answer for a decade

Ashton's 1997 demonstration was not subtle. The NT hash is, on the wire, the credential. Windows NT 4's challenge-response authentication used the LanMan or NT one-way function output as the long-term key; anyone who could read that value from the SAM, from a network capture, or from lsadump could authenticate as the principal without ever knowing the password [@exploit-db-19197]. Wikipedia's secondary anchor attributes the first public demonstration to Ashton and dates it to 1997 [@wiki-pth]; the Exploit-DB mirror of the original patch preserves file modification timestamps that narrow the day to Tuesday, April 8, 1997 [@exploit-db-19197].

A credential-theft technique that uses an account's NT one-way function output (the NT hash) to authenticate, instead of the plaintext password. Because the Windows NTLM protocol uses the hash itself as the long-term key, an attacker who reads the hash from memory or from disk can authenticate as the account without ever cracking the password.

For more than a decade after Ashton's post, Microsoft's institutional position was that this was a protocol legacy, not a vulnerability. The reasoning was internally consistent: the hash IS the long-term key in the protocol's design; refusing to honour it would break every existing Windows client. The 2008 Pass-the-Hash Toolkit, written by Hernan Ochoa [@wiki-pth], turned the academic demonstration into a single-binary Windows-native tool that read NT hashes from lsass.exe and injected them into a running logon session [@wiki-pth]. Microsoft's Privileged access strategy page now records the 2008 release of the Pass-the-Hash Toolkit as the proximate cause of the escalation in attacker tooling [@ms-paw-strategy].

Pre-2012, Microsoft's public posture toward credential-extraction tooling was, in Benjamin Delpy's own retelling, "this is not a vulnerability." The Wired profile records the response he received when he disclosed Mimikatz to Microsoft in 2011 [@wired-mimikatz]. That posture is what made the 2012 white paper a turning point: Microsoft committed to treating the attack class as a vulnerability that had to be mitigated by a Microsoft control, not merely contained by operator discipline.

The escalation that finally broke the institutional posture was Benjamin Delpy's Mimikatz, released publicly in May 2011 (closed source) on his personal blog [@mimikatz-blog]. Wired's biographical piece records the date verbatim: "He released it publicly in May 2011, but as a closed source program" [@wired-mimikatz]. The GitHub repository at github.com/gentilkiwi/mimikatz opened in April 2014; the sekurlsa::logonpasswords command on a SYSTEM-level shell printed plaintext passwords, NT hashes, and Kerberos session keys directly from lsass.exe [@mimikatz-repo]. Within twenty-four months it was the default post-exploitation credential dumper in every public AD attack-and-defence talk [@metcalf-p1738][@wired-mimikatz].

Microsoft's first institutional acknowledgement arrived in December 2012 as Mitigating Pass-the-Hash, Version 1. The canonical Microsoft Download Center URL for that version has not survived the company's reorganisations and now returns HTTP 404; the document is preserved through references inside its successor, the 2014 Version 2 paper, which is still hosted [@pth-v2-pdf]. Version 2 introduces tiered administrative segmentation as a deployment shape and is unambiguous about why the previous decade of mitigations had not worked.

Pass-the-Hash and similar credential theft attacks are 100% successful when an attacker gains administrative privileges on a computer, because once a computer is compromised, the attacker can read any credential stored on that computer. -- Microsoft, *Mitigating Pass-the-Hash, Version 2* (2014) [@pth-v2-pdf]

That sentence is the institutional pivot. It moves the framing from "protocol feature, defend the host" to "credentials, once stolen, win." The defence cannot live in the host, because the host is where the attacker has already won. It also cannot live in the ACL, because the ACL evaluates the principal that is authenticating, and the stolen credential authenticates as the legitimate principal. If access-control lists cannot stop a stolen credential, what can?

3. Five generations of pre-2013 controls and why each one failed

Between 1997 and 2013, operators tried five distinct families of controls. Each targeted a different part of the stack. Each failed in the same structural way.

The first family was operational discipline: give every administrator two accounts, alice for daily work and alice.da for domain-administrative work, and trust her not to use the privileged identity from her daily workstation. NT 4 (RTM July 31, 1996) shipped with this as the operating model [@wiki-nt4]. As a control it is a procedure, not an enforcement: there is no directory mechanism that prevents alice.da from interactively logging on to a tier-2 workstation. The Microsoft 2014 paper named the failure mode plainly: once alice.da runs anywhere an attacker also runs, the credential material sits in that machine's LSASS and is replayable forest-wide [@pth-v2-pdf].

The second family was directory-ACL hardening. AdminSDHolder is an object under CN=System in the directory that stores a template security descriptor. A background task called SDProp runs every 60 minutes on the PDC emulator and re-stamps that ACL onto every account with adminCount=1 -- Domain Admins, Enterprise Admins, Schema Admins, and the rest of the protected groups [@metcalf-p1906]. The intent is to prevent ACL drift: a helpdesk operator's misconfigured permission cannot weaken Domain Admin protections for more than an hour. The mechanism survives in modern AD, but its original threat-model framing as a pass-the-hash mitigation is dead. ACLs evaluate the principal; a stolen credential authenticates as the legitimate principal. Worse, Sean Metcalf's Sneaky Active Directory Persistence #15 documents the inverse abuse: AdminSDHolder is not protected by AdminSDHolder, so an attacker who writes a Full-Control ACE into it once gets that ACE propagated across every protected member within sixty minutes [@metcalf-p1906].

`CN=AdminSDHolder,CN=System,DC=...` stores a template security descriptor. The SDProp (Security Descriptor propagator) task runs every 60 minutes on the PDC emulator and copies that ACL onto every member of the protected groups -- objects with `adminCount=1`. The mechanism prevents ACL drift on privileged accounts but does not stop credential theft.

The third family was smartcard-required admin accounts. Setting the SMARTCARD_REQUIRED flag (UAC bit 0x40000) on a privileged account causes the KDC to refuse any AS-REQ that is not a PKINIT request -- the user must present a certificate chain rooted in the domain, with the matching private key on a smartcard [@rfc-4556]. The phishing-credential-into-fake-portal vector is closed: the operator does not know a password to type. But the PKINIT exchange produces a derived long-term key that lives on the workstation as a normal NT hash. The 2014 Mitigating Pass-the-Hash paper is unambiguous in §6: "Smart cards do not protect against the Pass-the-Hash credential theft attack vector. When a smart card is used to log in to a system, the system computes a derived NT hash of the password and stores it on the system" [@pth-v2-pdf]. Mimikatz extracts the derived hash like any other.

The Public Key Cryptography for Initial Authentication in Kerberos extension, specified in RFC 4556. PKINIT lets a client present a certificate (typically held on a smartcard or a TPM) in its AS-REQ instead of a password-derived pre-authentication blob. The KDC validates the certificate against an account binding and issues a TGT. The resulting long-term key still lives in the host's LSASS process.

The fourth family was host-side credential protection: LSA Protection (RunAsPPL), WDigest plaintext disablement, and the TokenLeakDetectDelaySecs registry setting. LSA Protection runs lsass.exe as a Protected Process Light, refusing handles with PROCESS_VM_READ to anything not signed at PPL level [@ms-lsa-prot]. WDigest plaintext disablement (via UseLogonCredential=0, shipped in KB 2871997 in May 2014) stops the WDigest SSP from caching the user's plaintext password [@kb-2871997]. Both moved the bar; neither closed the attack. PPL is enforced by the kernel; on pre-VBS Windows an attacker with a signed kernel driver clears the protection bit, and Mimikatz ships mimidrv.sys for exactly this purpose [@mimikatz-repo] (on modern hardware-rooted HVCI/VBS, the VTL1 secure kernel closes the signed-driver bypass, but the discussion then moves to where the §6 Credential Guard primitive lives [@ms-cred-guard]). WDigest disablement removes plaintext from memory but does nothing to the NT hash or to Kerberos session keys, which are the actually-replayable material.

The fifth family was Restricted Admin Mode for RDP, shipped via the October 14, 2014 revision of KB 2871997 [@kb-2871997]. The intent was to interrupt lateral movement: mstsc /restrictedadmin causes the RDP client to send a CredSSP-wrapped network logon to the target. The target creates a network-logon token instead of an interactive one, and the user's NT hash or Kerberos session keys never land on the target [@ms-rcg][@kfalde-restricted-admin]. Within months, Benjamin Delpy demonstrated the inverse: because the RDP client authenticates with the user's existing credential material, an attacker on the client can pass a stolen NT hash directly into the RDP session with sekurlsa::pth /user:alice.da /domain:CORP /ntlm:<hash> /run:"mstsc /restrictedadmin" [@mimikatz-repo]. The defence became the lateral move. Microsoft updated KB 2871997 to acknowledge this, and Restricted Admin is off by default client-side on modern Windows [@kb-2871997].

Restricted Admin Mode for RDP is the cleanest case in the 28-year arc of a control whose deployment created the inverse of its intent. The mode that protects credentials on the RDP target also enables pass-the-hash into the RDP target from a compromised client. Microsoft's response -- disable it on the client side -- is the practical confirmation. This is the strongest argument in the historical record for moving the credential-restriction decision out of the host, the protocol, and the channel, and into the KDC.

flowchart TD Op["Operator discipline (two-account pattern, 1990s)"] --> Op_x["Procedure, not enforcement: one mistake compromises the forest"] ACL["AdminSDHolder + SDProp (NT 4 / 2000)"] --> ACL_x["ACLs evaluate the principal, and a stolen credential authenticates as the legitimate principal"] SC["Smartcard-required (Server 2003+)"] --> SC_x["PKINIT changes only the AS-REQ method, and the derived NT hash still lives in LSASS"] HS["LSA Protection / WDigest off (2013-14)"] --> HS_x["PPL bypassable by a signed kernel driver, with NT hash and Kerberos keys still in memory"] RA["Restricted Admin Mode for RDP (Oct 2014)"] --> RA_x["Inverse-of-intent: enables pass-the-hash via RDP from the compromised client"] Op_x --> Sink["All five enforce in a layer that does not see the directory's authoritative view of who-may-issue-credentials-from-where"] ACL_x --> Sink SC_x --> Sink HS_x --> Sink RA_x --> Sink

Note: A credential, once usable, is on the wire identical to the legitimate one. Every Generation 1-5 control fails because it enforces in a layer that cannot tell the two apart at the point where it tries to decide. The fix is to refuse to issue or to delegate the credential in the first place -- a decision that has to move one layer up, to the KDC, keyed on directory state.

If the operator cannot be trusted, the ACL cannot enforce, the smartcard-derived hash still lives in LSASS, the host-side protections can be bypassed by anyone with privilege to deploy them, and the RDP mode meant to interrupt lateral movement enables it -- where does the decision have to move?

4. October 18, 2013: the directory acquires a vocabulary

The Microsoft Server team's August 14, 2013 save-the-date blog post fixed the General Availability of Windows Server 2012 R2 for October 18, 2013 [@save-date-blog]. In that single release, three new directory-side primitives appeared: the Protected Users built-in security group with well-known RID 525, the msDS-AuthNPolicy AD object class for Authentication Policies, and the msDS-AuthNPolicySilo AD object class for Authentication Policy Silos [@ms-pu-legacy]. The legacy Windows Server 2012 R2 TechNet documentation, preserved on Microsoft Learn, states the introduction verbatim: "This group was introduced in Windows Server 2012 R2" [@ms-pu-legacy]. The architectural decision visible in the wire format: the KDC, not the application, now decides whether a TGT may be issued, what its lifetime will be, and what delegation operations on it will succeed.

The Kerberos authentication service, specified in RFC 4120. The KDC handles AS-REQ (issuing a Ticket-Granting Ticket from a long-term key) and TGS-REQ (issuing a service ticket from a TGT). On Windows domains, every domain controller runs a KDC; the KDC reads its policy state from the directory at request time, which is the property the Server 2012 R2 controls exploit [@rfc-4120]. A Microsoft authorisation-data overlay carried inside Kerberos TGTs and service tickets, specified in [MS-PAC]. The PAC's `PAC_LOGON_INFO` buffer contains the user's SID, primary-group SID, and a `GroupIds` array of well-known group memberships. Protected Users membership is encoded as RID 525 inside that array. There is no separate Protected Users flag bit [@ms-pac].

The detail that matters: there is no dedicated "Protected Users bit" in the PAC. The encoding is the well-known group SID S-1-5-21-<domain>-525 carried in PAC_LOGON_INFO.GroupIds ([MS-PAC] §2.5) [@ms-pac][@ms-pu-legacy]. The KDC reads that array at AS-REQ and TGS-REQ time the same way it reads it for every other group; what changes is the behaviour the KDC takes when it sees RID 525.

The down-level half of the shipment arrived seven months later. On May 13, 2014, Microsoft Security Advisory KB 2871997 backported the client-side honoring of Protected Users and Authentication Policies to Windows 7, Windows 8, Server 2008 R2, and Server 2012 [@kb-2871997]. KB 2871997 is not the introduction of Protected Users. It is the down-level backport that closed the long-tail Silo-bypass class an enterprise would hit if its 2014-era fleet could not honour the new restriction list. Five months later, the October 14, 2014 revision of the same KB shipped Restricted Admin Mode for RDP -- the mode §3 already taught the reader to treat as a cautionary tale.

The version-mismatch story matters for the operator who finds a 2014 KB cited as the "introduction" of Protected Users in older blog posts. It is not. The introduction is Server 2012 R2 GA on October 18, 2013; the backport is KB 2871997 on May 13, 2014. The legacy Microsoft Learn page records the introduction date plainly [@ms-pu-legacy].

Microsoft followed the primitive with a deployment shape. The Securing Privileged Access reference material, originally published on TechNet circa 2014-2015 and preserved on Microsoft Learn at the privileged-access-workstations root [@ms-paw-root], codified the clean-source principle: a higher-tier secret must never be exposed to a lower-tier host. T0 holds domain controllers, the PKI root, the identity-sync infrastructure, and the DC backup system. T1 holds servers and business data. T2 holds workstations [@ms-eam]. T0 credentials never authenticate to T1 or T2; T1 credentials never authenticate to T2. The Privileged Access Workstation (PAW) is the dedicated source machine for T0 administration. Server 2012 R2 gave operators the primitives; SPA gave them the shape.

flowchart LR A["Apr 8, 1997: Paul Ashton, NTBugtraq -- hash IS the credential"] --> B["2008: Hernan Ochoa, Pass-the-Hash Toolkit"] B --> C["May 2011: Benjamin Delpy, Mimikatz public release"] C --> D["Dec 2012: Microsoft, Mitigating Pass-the-Hash v1"] D --> E["Oct 18, 2013: Windows Server 2012 R2 GA -- Protected Users, Authentication Policies, Silos"] E --> F["May 13, 2014: KB 2871997 down-level backport"] F --> G["Oct 14, 2014: KB 2871997 adds Restricted Admin RDP"] G --> H["2014-2015: Securing Privileged Access reference material"] H --> I["Dec 15, 2020: ESAE retired, Enterprise Access Model begins"] I --> J["Nov 9, 2021: KB 5008380 PAC hardening"] J --> K["May 10, 2022: KB 5014754 PKINIT strong mapping"] K --> L["Feb 11, 2025: KB 5014754 Full Enforcement default"] L --> M["Sep 9, 2025: KB 5014754 Compatibility-mode revert removed"]

Key idea: The KDC, not the application, decides whether a TGT may be issued, what its lifetime is, and what delegation operations on it will succeed. The decision is made by reading directory state -- group SID 525 in PAC_LOGON_INFO.GroupIds for Protected Users, msDS-AssignedAuthNPolicySilo and msDS-AssignedAuthNPolicy for Silo and Policy bindings -- at request time. This is the architectural pivot. The credential-on-the-wire identity property no longer matters, because the credential never gets issued in the first place to be stolen.

Three controls, one ship. But how do they compose, exactly -- which decision does the KDC actually make at AS-REQ time, what does it read from the directory, and what does it refuse?

5. How the three controls compose: a mechanism walkthrough

If you have time to read only one section of this article, read this one. The Server 2012 R2 controls compose into a precise decision the KDC makes at AS-REQ and TGS-REQ time. The mechanism has four moving parts.

5.1 The tier model as policy intent

The tier model is policy intent, not enforcement. Tier 0 is the control plane: every domain controller, every certificate authority that issues domain-trust certificates, the Microsoft Entra Connect server that synchronises identity to the cloud, and the backup systems that can restore any of those. Tier 1 is the management and data plane: servers, business applications, and the database engines that hold the data the organisation actually cares about. Tier 2 is the user plane: workstations and the devices users carry [@ms-eam]. The rule that defines the model is the clean-source principle: a higher-tier credential must never authenticate to a lower-tier host, because once it lands in the lower-tier host's memory it is exfiltrable by anyone with privilege on that host [@ms-paw-strategy]. The tier model says nothing about how the rule is enforced. Protected Users and Authentication Policy Silos are how.

5.2 Protected Users: the credential-restriction switch

Protected Users is a global security group with well-known RID 525, present in every domain at Domain Functional Level 2012 R2 or later. Membership is encoded as the well-known SID S-1-5-21-<domain>-525 carried in the GroupIds array of the user's PAC_LOGON_INFO ([MS-PAC] §2.5) [@ms-pac][@ms-pu-current]. When the KDC reads RID 525 in that array, it applies a non-configurable restriction set documented on Microsoft Learn [@ms-pu-current]:

No NTLM authentication. The DC refuses any NTLM authentication attempt for a Protected Users member -- the NTLM SSP and NetLogon path on the DC enforce the rejection, and the Kerberos KDC enforces the corresponding refusal for AS-REQ flows that fall back to NTLM-style pre-authentication. NTLM relay against the account is structurally impossible because there is no NTLM session to relay.
No NTLM hash caching on the host. Even if the user has logged on interactively, the LSA never holds the account's NT one-way function output. Mimikatz sekurlsa::logonpasswords prints (null) for the NTLM tab.
No DES or RC4 in Kerberos pre-authentication. AES-128 or AES-256 only. Kerberoasting against the account becomes inapplicable, because the public roasting tooling requires RC4-HMAC ticket material that the KDC refuses to issue.
No constrained or unconstrained delegation, in either direction. The account cannot be the source of a constrained-delegation chain, and S4U2Self / S4U2Proxy against the account as a target is refused at TGS-REQ time.
No cached offline-sign-in verifier. The Windows Hello for Business PIN-based offline-logon path is unavailable for Protected Users members; this is the operational price of removing the cached verifier from disk.
TGT lifetime capped at 240 minutes, non-renewable. Microsoft Learn states the figure verbatim: "For Protected Users members, the group automatically sets these lifetime limits to 240 minutes" [@ms-pu-current]. The cap overrides the domain's "Maximum lifetime for user ticket" and "Maximum lifetime for user ticket renewal" policies.

The built-in domain Administrator (RID 500) is always exempt from Authentication Policy enforcement even when assigned to a Silo, which makes it a candidate break-glass identity [@ms-pu-current]. That exemption does not extend to the Protected Users restriction set itself: adding RID 500 to Protected Users on a domain whose Administrator account lacks AES keys will lock the account out. Service accounts cannot be enrolled in Protected Users without breaking workflows -- see §6's canonical Microsoft Learn PullQuote on this point.

5.3 Authentication Policies and Silos: the KDC-side policy objects

Two AD object classes, layered. The containment direction is the most common practitioner confusion, so be precise about it: the Silo references the Policy, not the other way.

The container object. A Silo enumerates the user, computer, and service accounts that share a set of restrictions and references one or more `msDS-AuthNPolicy` objects whose rules apply to its members. The Silo carries an `msDS-AuthNPolicySiloEnforced` Boolean that switches between audit-only and enforced modes. Accounts bind to it via `msDS-AssignedAuthNPolicySilo`, with `msDS-AuthNPolicySiloMembers` as the back-link [@ms-aps]. The rules object. A Policy carries the non-renewable TGT lifetime cap, the allowed-from SDDLs on source-machine identity (`UserAllowedToAuthenticateFrom`, `ServiceAllowedToAuthenticateFrom` -- computer accounts have no `-From` variant, only `-To`), the corresponding allowed-to SDDLs for delegation targets (`UserAllowedToAuthenticateTo`, `ServiceAllowedToAuthenticateTo`, `ComputerAllowedToAuthenticateTo`), claim-based authentication access-control conditions, and the option to require Kerberos armoring per RFC 6113 [@ms-aps][@rfc-6113].

The same Policy can be referenced by multiple Silos. Accounts can be bound to a Policy directly via msDS-AssignedAuthNPolicy without being placed in a Silo at all, though the more common pattern is Silo membership for the broader containment and Policy reuse for the rule definitions.

The containment direction is the single most-common practitioner confusion. The Silo names the Policy that applies to its members. The same Policy can apply to several Silos. The directory links are role-specific: the Silo carries msDS-UserAuthNPolicy, msDS-ComputerAuthNPolicy, and msDS-ServiceAuthNPolicy, each pointing outward to a Policy object [@ms-aps]. Older blog posts that describe "the Policy attached to the Silo" are using imprecise prose; the link in the schema is Silo to Policy, not the other way.

Note: Policy and Silo objects replicate via standard AD multi-master directory replication -- the DRS Remote Protocol, MS-DRSR / drsuapi [@ms-drsr]. They do NOT replicate via FRS or DFSR. FRS and DFSR replicate SYSVOL files (Group Policy content, scripts), not directory objects. Practitioners who chase "my Policy assignment is not replicating" through DFSR diagnostics are looking in the wrong primitive; the right one is repadmin /showrepl against the DRS partition.

5.4 The KDC's decision points

The KDC consults the directory at three precise moments, documented in [MS-KILE] §3.3.5 [@ms-kile]:

AS-REQ. The KDC reads the requester's msDS-AssignedAuthNPolicySilo and any msDS-AssignedAuthNPolicy. If the Policy specifies a UserAllowedToAuthenticateFrom SDDL, the KDC evaluates the source-machine identity (as presented in the pre-authentication exchange) against the SDDL. On denial, the KDC returns KDC_ERR_POLICY and no TGT is issued. The KDC also checks PAC_LOGON_INFO.GroupIds for RID 525; if present, it applies the Protected Users restriction set to the TGT it is about to issue (AES-only, 240-minute cap, delegation forbidden).
TGS-REQ for S4U2Self. The KDC reads the target account's group memberships and Silo bindings. If the target is a Protected Users member, S4U2Self is refused. If the target's Silo Policy specifies an allowed-to SDDL, the requesting service identity is evaluated against it [@ms-sfu].
TGS-REQ for S4U2Proxy. The KDC evaluates the requesting service's msDS-AllowedToDelegateTo and the target's msDS-AllowedToActOnBehalfOfOtherIdentity, then layers the Silo Policy's claim requirements on top. Protected Users membership on either side terminates the request [@ms-sfu].

sequenceDiagram participant PAW as PAW (source machine) participant KDC as KDC on DC participant DS as Directory (LDAP DSA) PAW->>KDC: AS-REQ for alice.da, pre-auth signed KDC->>DS: Read alice.da object (PAC_LOGON_INFO, msDS-AssignedAuthNPolicySilo) DS-->>KDC: GroupIds includes RID 525, Silo = "T0 Admins" KDC->>DS: Read referenced Policy (msDS-AuthNPolicy) DS-->>KDC: UserAllowedToAuthenticateFrom SDDL pinned to T0 PAWs KDC->>KDC: Evaluate source machine identity against SDDL alt Source is in the allowed-from set KDC->>KDC: Apply Protected Users restriction set (AES-only, no NTLM, no delegation) KDC->>KDC: Cap TGT lifetime at 240 minutes non-renewable KDC-->>PAW: TGT issued with restriction PAC else Source not in the allowed-from set KDC-->>PAW: KDC_ERR_POLICY, no TGT issued end flowchart LR A["User account alice.da (msDS-AssignedAuthNPolicySilo)"] --> S["Silo: T0 Admins (msDS-AuthNPolicySilo)"] C["Computer account paw01 (msDS-AssignedAuthNPolicySilo)"] --> S SV["Service account svc-bkp (msDS-AssignedAuthNPolicySilo)"] --> S S -- "references" --> P["Policy: T0 Source Restriction (msDS-AuthNPolicy)"] P --> Rule1["UserAllowedToAuthenticateFrom SDDL"] P --> Rule2["TGT lifetime cap"] P --> Rule3["Claim transformations"] P --> Rule4["FAST armoring requirement"] S -. "alt direct binding" .-> A2["Account can also bind via msDS-AssignedAuthNPolicy"]

The RunnableCode block below simulates the decision tree as a small JS function. It is pedagogical, not a real KDC, but the logic mirrors what [MS-KILE] specifies. Change the inputs -- move the source machine outside the allowed-from set, flip the Protected Users flag -- and the decision changes.

{` function kdcDecideAsReq(account, sourceMachine) { // account: { name, inProtectedUsers, siloPolicy: { allowedFrom: [], tgtMinutes, requireFast } } // sourceMachine: { name }

if (account.siloPolicy && account.siloPolicy.allowedFrom && !account.siloPolicy.allowedFrom.includes(sourceMachine.name)) { return { issued: false, error: "KDC_ERR_POLICY", reason: "source not in allowed-from set" }; }

const restrictions = []; let tgtMinutes = account.siloPolicy ? account.siloPolicy.tgtMinutes : 600; let renewable = true;

if (account.inProtectedUsers) { restrictions.push("no-NTLM", "AES-only", "no-delegation", "no-cached-verifier"); tgtMinutes = Math.min(tgtMinutes, 240); renewable = false; }

return { issued: true, tgtMinutes, renewable, restrictions, sourceMachine: sourceMachine.name }; }

const alice = { name: "alice.da", inProtectedUsers: true, siloPolicy: { allowedFrom: ["paw-t0-01", "paw-t0-02"], tgtMinutes: 480, requireFast: true } };

console.log("From PAW:", kdcDecideAsReq(alice, { name: "paw-t0-01" })); console.log("From workstation:", kdcDecideAsReq(alice, { name: "wks-finance-77" })); `}

The KDC now has a vocabulary it did not have in 1997. Well-known group SID 525 as a credential-restriction switch. msDS-AuthNPolicySilo and msDS-AuthNPolicy as policy objects. drsuapi as the replication primitive that carries policy changes to every DC. The decision is keyed on directory state, made at request time, before any TGT exists to be stolen. With the mechanism in hand, what does a current 2026 reference deployment look like?

6. The 2026 reference deployment

Microsoft has had thirteen years to settle the deployment shape. As of May 2026, a well-built environment looks like the layered stack below, in which Silos and Protected Users carry the on-prem enforcement and several complementary primitives close residuals the KDC plane cannot address by construction.

The control plane of an Active Directory environment. T0 contains the domain controllers and every system whose compromise grants forest-wide control: the AD CS certificate authorities, the Microsoft Entra Connect server, the privileged-access workstations used to manage them, and the backup systems that can restore any of those. The SpecterOps Tier Zero Table is the community-maintained canonical asset list and is the practical starting point for any T0 inventory [@tzt-pages][@tzt-github].

The reference deployment composes:

Tier model present as policy intent, with Authentication Policy Silos as the enforcement primitive that makes the tier boundary KDC-visible.
All human T0 administrators in Protected Users, in a "T0 Admins" Silo whose Policy's UserAllowedToAuthenticateFrom SDDL pins authentication to a defined set of T0 PAWs. The KDC will return KDC_ERR_POLICY for any AS-REQ from outside that set [@ms-aps][@ms-kile].
T0 service accounts in a "T0 Services" Silo with a more permissive Policy that still pins source machines. Service accounts cannot be in Protected Users; the Silo plane is the only KDC-side enforcement available to them [@ms-pu-current].
Domain-wide migration off RC4-HMAC for AS-REP, with msDS-SupportedEncryptionTypes audited per account. Protected Users enforces AES-only for free for human members; service accounts need explicit per-account configuration [@ms-config-pa].
Credential Guard default-on for non-DC Windows 11 22H2+ and Windows Server 2025+ devices that meet the hardware requirements [@ms-cred-guard]. Windows LAPS managing local-administrator password uniqueness on every workstation [@ms-laps].
Entra PIM for Entra ID privileged roles [@ms-pim], with Conditional Access keyed on the synced T0 Admins group requiring phishing-resistant MFA and a compliant device. The CA does not see the Silo; it sees the synced group. The two planes are independent (see §8).
Microsoft Defender for Identity assessments running, including "Identify privileged accounts that are not protected by Protected Users group" and adjacent recommendations [@ms-mdi]. This is the detection plane that tells the operator the reference deployment is the deployed posture.

For the service accounts that cannot be enrolled in Protected Users, the explicit AES enforcement story is direct: set msDS-SupportedEncryptionTypes to 0x18 (AES128 0x08 + AES256 0x10). To additionally signal Compound-Identity-Supported, use 0x20018 (0x18 | 0x20000) -- Compound-Identity-Supported is the G bit at position 17 of the [MS-KILE] §2.2.7 Supported Encryption Types Bit Flags diagram, value 0x20000, not 0x40. The full bit layout per [MS-KILE] §2.2.7 is: DES-CBC-CRC 0x01, DES-CBC-MD5 0x02, RC4-HMAC 0x04, AES128-CTS-HMAC-SHA1-96 0x08, AES256-CTS-HMAC-SHA1-96 0x10, FAST-Supported 0x10000, Compound-Identity-Supported 0x20000, Claims-Supported 0x40000, Resource-SID-Compression-Disabled 0x80000; 0x40 is bit 6 (AES128-CTS-HMAC-SHA256-128, an RFC 8009 enctype [@rfc-8009] older KDCs do not fully support and which is not Compound-Identity-Supported). The value 0x18 explicitly excludes RC4 (0x04) and the two DES flavours (0x01, 0x02). Note that 0x1C is not AES-only -- it is 0x10 | 0x08 | 0x04, which re-introduces RC4 on the very account you are trying to harden. Group Managed Service Accounts (gMSA) are the preferred new-service-account primitive: the Microsoft Key Distribution Service computes a long, automatically-rotated password keyed on a domain-wide root key, and the Microsoft Learn gMSA overview describes the mechanism in detail -- the resulting AES pre-auth tickets are not roastable in practical timeframes [@ms-gmsa-overview]. Microsoft's How to Configure Protected Accounts page lays out the per-account migration steps for non-gMSA legacy services [@ms-config-pa].

Never add accounts for services and computers to the Protected Users group. For those accounts, membership doesn't provide local protections because the password and certificate is always available on the host. -- Microsoft Learn, *Protected Users Security Group* [@ms-pu-current]

That quote is the operational reason the RBCD residual remains the punchline of §8. Before then, two further pieces of the reference deployment need to be named, because both have been mis-described in widely shared blog posts.

The first is the November 2021 PAC hardening in KB 5008380, which addressed CVE-2021-42287 and CVE-2021-42278 ("noPAC"). The fix added two new PAC buffer types to the Kerberos TGT: PAC_REQUESTOR (buffer type 18), which encodes the SID of the principal that requested the ticket, and PAC_ATTRIBUTES_INFO (buffer type 17), which carries PAC-generation attributes [@kb-5008380][@ms-pac]. The KDC at TGS-REQ time now verifies that the requestor SID in the PAC matches the principal currently presenting the TGT. Initial deployment was November 9, 2021; the Enforcement phase landed October 11, 2022 [@kb-5008380].

The second is the May 2022 PKINIT certificate-to-account strong-mapping fix in KB 5014754 [@kb-5014754]. Pre-fix, the KDC mapped a PKINIT certificate to an account by sAMAccountName or UPN -- the same comparison that Schroeder and Christensen's Certified Pre-Owned whitepaper showed could be spoofed via UPN conflicts or via the trailing dollar-sign convention on machine accounts [@cert-preowned-blog][@cert-preowned-pdf]. The fix added the SecurityIdentifier X.509 extension OID 1.3.6.1.4.1.311.25.2 to certificates issued by AD CS and requires the KDC to match the SID in the certificate against the SID of the account being authenticated. The Full Enforcement default landed February 11, 2025; the Compatibility-mode revert option was removed on September 9, 2025 [@kb-5014754].

The November 2021 PAC hardening is not the encoding of Protected Users membership. The Protected Users marker is RID 525 in `PAC_LOGON_INFO.GroupIds`, present in the PAC since Windows Server 2012 R2 GA in October 2013. The November 2021 buffers (`PAC_REQUESTOR`, `PAC_ATTRIBUTES_INFO`) are a separate, later KDC anti-spoofing primitive that closes the sAMAccountName-spoofing chain in CVE-2021-42278 plus CVE-2021-42287 [@kb-5008380][@ms-pac]. Conflating them produces wrong threat-model claims: it treats a 2021 anti-spoofing fix as if it were the 2013 credential-restriction marker, and leaves the operator unable to reason about either correctly.

Reference 2026 deployment: what runs where.

Account class	Protected Users?	Silo membership	Allowed-from SDDL anchor	TGT cap	Host-side	Cloud-side
Human T0 admin	Yes	T0 Admins	T0 PAWs only	240 min, non-renewable	Credential Guard on the PAW; LAPS irrelevant (PAW is unique)	Entra PIM + CA on synced group, phishing-resistant MFA, compliant device
T0 service account (gMSA)	No (breaks workflow)	T0 Services	T0 server set	Default; per-Policy cap	Credential Guard on every host the account runs on	n/a (on-prem only)
T1 admin	Optional	T1 Admins	T1 jump servers	Default; per-Policy cap	Credential Guard everywhere	CA on synced T1 group
T2 user	No	None	n/a	Default	Credential Guard default-on, LAPS for local admin	CA general policy

If this is the reference deployment, what about the alternative architectures customers actually have in production -- ESAE forests, MIM PAM bastion forests, the Enterprise Access Model?

7. Tiered Administration vs. bastion forest vs. Enterprise Access Model

Three operational doctrines coexist in 2026 production environments, with a fourth meta-architecture sitting above them. None are interchangeable; choosing the wrong one means over-building, under-building, or building the right thing in the wrong place.

Method A: Tier model + Authentication Policy Silos + Protected Users. The current Microsoft recommendation for the on-prem enforcement layer in connected and hybrid environments. The whole of §5 and §6 is the description. Cited references: [@ms-pu-current][@ms-aps][@ms-eam].

Method B: MIM Privileged Access Management with a bastion forest. Microsoft Identity Manager PAM with the Server 2016 bastion-forest functional level gives just-in-time activation of privileged group membership in a separate, hardened "bastion" forest with a one-way trust from production to bastion. Microsoft Learn's Raise the bastion forest functional level page is explicit on the feature pivot: "With Windows Server 2016, PAM features of time-limited group memberships and shadow principal groups are built into Windows Server Active Directory" [@ms-pam-bastion-ffl]. A user requests time-bound activation, MIM validates it, the user is briefly added to a bastion-forest privileged group (a shadow principal at WS 2016 FFL), and the resulting TGT carries the production SIDs via PAC SID History. When the activation expires, the SID History entry disappears from newly issued tickets. The Microsoft Learn page is explicit about scope:

The PAM approach provided by MIM PAM is not recommended for new deployments in Internet-connected environments. MIM PAM is intended to be used in a custom architecture for isolated AD environments where Internet access is not available, where this configuration is required by regulation, or in high impact isolated environments like offline research laboratories and disconnected operational technology or supervisory control and data acquisition environments. -- Microsoft Learn, *MIM PAM* [@ms-mim-pam]

Method C: Enhanced Security Admin Environment (ESAE) / Red Forest. A separate hardened forest used exclusively for administrative identities, with a one-way trust from production to the admin forest. Production-forest administration is performed by accounts that live exclusively in the admin forest. Microsoft retired ESAE as a mainstream recommendation on December 15, 2020 [@ms-esae-retire].

A dedicated Active Directory forest containing all administrative identities, with a one-way trust from the production forest to the admin forest. Retired as a mainstream Microsoft recommendation on December 15, 2020 [@ms-esae-retire]; preserved for air-gapped, OT, ICS, and SCADA scenarios where cloud-side privileged-access controls are unavailable. Microsoft's explicit guidance for existing ESAE deployments is "no urgency to retire" if the deployment is operating as designed.

Method D: Enterprise Access Model (EAM) / Rapid Modernization Plan (RaMP). Microsoft's current meta-architecture, announced concurrently with the ESAE retirement on December 15, 2020 [@ms-esae-retire][@ms-eam][@ms-ramp]. EAM widens the segmentation from forest boundaries to access levels: a privileged-access plane (the equivalent of T0, now explicitly including Entra ID admin roles), a management plane (formerly T1), a data/workload plane (where applications run), and a user/app plane (T2). EAM does not deprecate the directory-level controls -- it encloses them inside a larger model that adds the cloud control plane as a first-class object.

Microsoft's December 15, 2020 meta-architecture for privileged-access. Replaces forest-level isolation with access-level segmentation across four planes: privileged-access, management, data/workload, and user/app. EAM is the framework; Method A (Tier model + Silos + Protected Users) is the on-prem enforcement layer inside the privileged-access plane; Entra PIM and Conditional Access are the cloud-side enforcement [@ms-eam][@ms-ramp].

Four operational doctrines, side by side.

Dimension	A: Tier + Silos + Protected Users	B: MIM PAM bastion	C: ESAE / Red Forest	D: EAM + RaMP
Enforcement plane	KDC (AS-REQ, TGS-REQ, S4U)	Bastion KDC + MIM workflow	Admin-forest KDC + one-way trust	Meta: composes A + cloud + host
Primary restriction	Where a TGT may be issued and to whom delegated	Whether and for how long a privileged group is populated	Which forest privileged identities live in	Which planes are enforced and by what
AD schema footprint	4 attributes / 2 classes + RID 525	Server 2016 PAM FFL + Shadow Principal extensions	None new; uses standard trust + SID filtering	n/a (model)
Cloud / hybrid coverage	On-prem only	On-prem only (explicitly NOT for connected)	On-prem only	First-class hybrid by design
Deployment complexity	Moderate	High (forest pair + SQL + MIM)	Highest (forest pair + full DR)	Variable (sum of constituents)
Microsoft current status (May 2026)	Recommended for on-prem enforcement	OT / ICS / regulated air-gapped only	Legacy; supported for existing + OT only	Recommended as top-level architecture

Method D is the framework; Method A is the on-prem enforcement layer inside it; Methods B and C are the niche answers for environments Method A cannot reach. The four are not in competition for the same job. A connected hybrid enterprise in 2026 runs Method D + Method A on-prem, with B and C reserved for the air-gapped exception cases.

EAM is the framework. Method A is its on-prem enforcement layer. What does Method A's enforcement layer NOT close, by construction?

8. What the KDC cannot enforce

A well-deployed Method A architecture eliminates the credential-theft attack chain at the KDC. It does not close every gap. The remaining gaps are not implementation bugs; they are structural properties of where the KDC sits in the stack. Naming them is not optional.

The RBCD residual. Resource-based constrained delegation is configured by writing the msDS-AllowedToActOnBehalfOfOtherIdentity attribute on the target object [@ms-sfu]. The write is governed by the target object's DACL, not by the Silo plane. The KDC never sees the write; it only sees the resulting TGS-REQ. If the target is a service account that is Silo'd but not in Protected Users -- which, per Microsoft Learn's explicit guidance, is the case for most service accounts -- the RBCD chain remains exploitable. The defence is layered: pin the source machine via the Silo Policy, deny WriteProperty on msDS-AllowedToActOnBehalfOfOtherIdentity for everyone but directory administrators, prefer Group Managed Service Accounts for new services, and put Defender for Identity detection on the attribute-write event [@ms-mdi].

A constrained-delegation primitive introduced in Windows Server 2012. Unlike classic constrained delegation (configured by the privileged administrator on the *delegating* service via `msDS-AllowedToDelegateTo`), RBCD is configured on the *target* by writing `msDS-AllowedToActOnBehalfOfOtherIdentity`. The target object's owner controls which services may impersonate users to it. Governance is at the ACL plane, not the KDC plane, which is why RBCD writes are invisible to Authentication Policy Silo enforcement [@ms-sfu].

Note: Even after every tier-model, Silo, and Protected Users control is correctly deployed, RBCD remains exploitable against any tier-protected service account that is not also in Protected Users -- which, in practice, is most service accounts. Protected Users would close the gap but breaks delegation workflows. The KDC cannot prevent writes to msDS-AllowedToActOnBehalfOfOtherIdentity because the write is an ACL operation on a directory attribute, not a Kerberos operation. The defence is necessarily layered: ACL the attribute, Silo the target, gMSA the credential material, detect the write at the SIEM.

Physical extraction from a logged-on T0 host. The KDC cannot prevent the extraction of credential material from the memory of a machine on which the user is logged on. The credential has to exist somewhere in memory for the user to use it. Credential Guard raises the bar dramatically by placing the credential material in a VBS-protected VTL1 enclave that the VTL0 kernel cannot read, even with a signed driver [@ms-cred-guard]. Remote Credential Guard adds a parallel host-side control for RDP-initiated authentications that redirects Kerberos requests back to the originating client [@ms-rcg]. None of these is a KDC control. The KDC and the host are two layers; both are required.

The on-prem-to-cloud bridge. On-prem AD KDC enforcement (Silo membership) and Entra ID Conditional Access enforcement are two independent policy planes by construction. The Primary Refresh Token does not carry msDS-AssignedAuthNPolicySilo. Conditional Access does not consume the Silo binding. Operational alignment is achieved by synchronising the Silo'd group through Microsoft Entra Connect and writing a Conditional Access policy keyed on the synced group. The CA sees the synchronised group; it does not see the Silo. Two planes, both must hold.

The host-side limit ("Credential Guard moves the bar but cannot eliminate physical extraction") is the topic of the earlier Credential Guard post in this series; the on-prem-to-cloud limit is the topic of the Conditional Access post. The four-residual recognition in this section is the joint that connects all three.

Key idea: Closing the on-prem-to-cloud gap requires either a Microsoft product change that projects Silo membership into the Primary Refresh Token, or a third-party policy synthesiser. Neither exists as a product surface in May 2026 -- which is why the §10 Phase 4 workaround (sync the Silo'd group through Microsoft Entra Connect, key the Conditional Access policy on the synced group) is the current production answer. The workaround keeps both planes independent by construction; it does not close the gap, it routes around it.

Supply-chain compromise of T0 software. The KDC cannot enforce policy against an agent running as SYSTEM on every domain controller. By construction, the agent is outside the KDC's authorisation scope; it can rewrite the directory the KDC reads its policy from. The canonical instance is the SolarWinds Orion compromise disclosed in December 2020 (CISA Alert AA20-352A): the attackers used a backdoored Orion update to obtain SYSTEM-level access on management hosts and, per the CISA advisory's User Impersonation section, in several documented cases used that access to compromise "the SAML signing certificate using their escalated Active Directory privileges" -- the AD FS / Entra Connect token-signing certificate -- and then "create unauthorized but valid tokens" presented to services that trust SAML tokens from the environment, on T0 systems where the secret material has to exist in memory for the system to do its job [@cisa-aa20-352a]. The KDC saw legitimately-signed tickets and made legitimate policy decisions; the enforcement gap is one layer below, where the software running as the KDC's neighbour ships compromised code. The closure for this residual is not at the KDC; it is at the software-supply-chain layer (code signing, reproducible builds, attested deployment, and strict T0-software inventory).

Every Method A deployment requires two emergency-access break-glass accounts that are outside every Silo and outside Protected Users -- see §10 Phase 5 for the operational pattern (offline-stored passwords, monthly use-and-rotate, high-fidelity SIEM detection, RID 500 as the canonical first identity). Microsoft's RaMP guidance treats this as the *first* step of the privileged-access rollout, before any of the controls in §5 and §6 are deployed [@ms-ramp].

A maximally-correct Method A deployment closes the KDC-plane gaps it was designed to close. Four explicit residuals remain by construction. Three need additional controls (target-ACL hardening, Credential Guard, Conditional Access keyed on the synced group); the fourth is closed at the software-supply-chain layer. The architecture is correct. The world is bigger than the architecture.

What is the active research, and what does a practitioner do on Monday morning to deploy what is settled?

9. Active research lines as of mid-2026

The community is not standing still. Five lines of work are visible on the public radar.

Projecting Authentication Policy Silo membership into Entra Conditional Access as a first-class signal. The most-named open problem in both SpecterOps research and Microsoft's own post-NTLM roadmap discussion. Matthew Palko's October 2023 post Evolution of Windows Authentication is Microsoft's institutional acknowledgement that the post-NTLM future is Kerberos plus IAKerb plus Local KDC; the post does not commit to projecting Silo membership into the Primary Refresh Token, but it is the closest reading the community has of a hybrid identity direction [@palko-evol]. IAKerb plus Local KDC is plausibly the substrate that could eventually carry Silo state across the on-prem-to-cloud boundary, but no public Microsoft roadmap entry as of May 2026 announces that projection.

A community-maintained checklist of Active Directory and Microsoft Entra ID assets, annotated with whether each asset is "Tier Zero" (its compromise grants forest-wide or tenant-wide control), what platform it sits on, how to identify it (typically by SID or by role assignment), and what attack techniques apply by default versus by misconfiguration. The repository is `github.com/SpecterOps/TierZeroTable` with a rendered live view at `specterops.github.io/TierZeroTable` [@tzt-github][@tzt-pages].

Tier Zero scoping at hybrid-cloud scale. Defining the boundary of T0 in a hybrid environment is increasingly difficult. The on-prem T0 set (DCs, AD CS, Entra Connect, DC backup) is enumerable. The cloud-side T0 set (Entra ID Application Administrators with Graph permissions over AD-synced objects, Hybrid Identity Administrators, Global Administrators, Privileged Authentication Administrators) is large, dynamic, and contains roles whose tier-0 status is contested. The SpecterOps Tier Zero Table is the community's canonical operational answer; its GitHub README is explicit that "the table does not include all Tier Zero assets yet" [@tzt-github]. BloodHound Community Edition is the companion discovery primitive: feed it a directory snapshot, ask it for attack paths to T0, fix the paths [@bloodhound]. The introductory blog series at SpecterOps explains the "Defining the Undefined" definitional work behind the table [@tier-zero-part1].

If you have never used BloodHound against your own forest, that is the most leveraged single action you can take this month. The tool exposes the attack paths your tier model is supposed to be closing -- and the gaps are almost always somewhere you did not look. The Tier Zero Table is the human-readable companion; BloodHound is the machine-readable one [@bloodhound][@tzt-github].

Continued discovery of ADCS misconfiguration classes (ESC1-ESC8+). Schroeder and Christensen's June 17, 2021 Certified Pre-Owned whitepaper was the inflection [@cert-preowned-blog][@cert-preowned-pdf]. The original taxonomy catalogued ESC1 through ESC8; ESC9 and several subsequently-disclosed classes have been added since by the SpecterOps team and the wider AD CS research community, with the GhostPack Certify tool tracking the enumerable classes in its active branch [@ghostpack-certify], and adjacent variants continuing to land in the SpecterOps blog stream. Each class is a tier-bypass primitive that survives Method A's deployment if the AD CS configuration is itself misconfigured: the KDC sees a legitimately-signed certificate and a legitimate AS-REQ. KB 5014754's strong-mapping closes the specific CVE-2022-26923 ("Certifried") class; template hardening (manager-approval, no-CT, no-enrollee-supplies-subject) addresses several other classes [@kb-5014754].

Kerberos relay primitives. The KrbRelay family of attacks, anchored to James Forshaw's October 2021 Project Zero research on cross-protocol Kerberos relaying [@krb-relay-pz] and operationalised in the cube0x0/KrbRelay tool released shortly thereafter [@cube0x0-krbrelay], exploits the absence of channel binding in some pre-authentication flows. Silos enforce on the source-machine identity as presented in the AS-REQ; an attacker who can cause a different machine to issue an AS-REQ on the attacker's behalf and relay it can satisfy the Silo Policy. FAST (RFC 6113) provides the cryptographic primitive for channel binding [@rfc-6113]; Microsoft's Kerberos armoring uses FAST, and a Silo Policy can be configured to require FAST armoring. The open deployment question is whether FAST armoring becomes the universal default in legacy environments. The Palko post on the post-NTLM Windows authentication roadmap is the closest Microsoft has come to addressing the deployment direction publicly [@palko-evol].

Service-account placement: Protected Users vs. Silo-only. The unsolved sub-problem inside the RBCD residual. Service accounts have two failure modes: they cannot be placed in Protected Users without breaking their delegation workflows, and they cannot be left out without leaving an RBCD-attack primitive against tier-protected service accounts that have writable msDS-AllowedToActOnBehalfOfOtherIdentity. The current best partial result is composite: Group Managed Service Accounts plus a tight Silo Policy plus an ACL on the delegation attribute plus a SIEM rule on attribute writes. The architectural answer would be an extension to Protected Users that retains delegation-as-source but refuses NTLM, RC4, and DES. No such extension appears on Microsoft's public roadmap as of May 2026 [@ms-pu-current][@ms-mdi].

The settled controls are deployable. The open research is real and has not been closed. Five years from now, the Silo plane will likely still be the operational answer, with the residuals closed by different parts of the stack. What does that look like to a practitioner reading this on a Monday morning?

10. A six-phase playbook for deploying Method A this quarter

A staged playbook. The phases are ordered for safety: each phase reduces the blast radius of the next, and the first phase is the most important and the most often skipped.

Phase 0: Inventory Tier 0

Use the SpecterOps Tier Zero Table as the starting checklist [@tzt-github][@tzt-pages]. Pair it with BloodHound Community Edition to discover the attack paths your environment actually has into the T0 set [@bloodhound]. The Tier Zero Table is intentionally incomplete -- treat it as the floor, not the ceiling -- and add the assets specific to your environment: any service account whose compromise grants write access to a DC, any backup system that can restore a DC's NTDS.dit, any monitoring system that can run code on a DC. Sean Metcalf's body of work on secure workstation baselines is the canonical operator-grade reading for this phase [@metcalf-p3299][@metcalf-p1738].

Note: Do not start with Silo creation. Start with the T0 inventory. Every subsequent phase depends on a defensible list of what T0 contains. A T0 asset missed by the inventory is a T0 asset that is not Silo'd, not in Protected Users, and not behind a Conditional Access policy on the cloud side. Phase 0 is the single most-skipped step in failed Method A deployments and the single highest-value step in successful ones.

Phase 1: Create the T0 Admins Silo and Policy in audit mode

Create the msDS-AuthNPolicySilo named "T0 Admins" and its referenced msDS-AuthNPolicy named "T0 Source Restriction." Set msDS-AuthNPolicySiloEnforced=FALSE to start in audit mode [@ms-aps]. Place a single test admin account in Protected Users and assign it to the Silo. Set the Policy's UserAllowedToAuthenticateFrom SDDL to a SID set containing exactly one PAW. Confirm that authentication from the PAW succeeds, that authentication from a tier-2 workstation generates the expected audit event (Authentication Policy Silo audit failure in the Security log), and that nothing else in the environment breaks. Once the audit window is clean, flip the Silo to enforced mode. The KDC now returns KDC_ERR_POLICY for any AS-REQ from outside the allowed-from set [@ms-kile].

Phase 2: Catalogue every delegation relationship in the directory

Enumerate every account with msDS-AllowedToDelegateTo set, every object with msDS-AllowedToActOnBehalfOfOtherIdentity set, and every account with the legacy TrustedForDelegation UAC bit. For each T0-adjacent service account, decide whether the workflow can survive Protected Users membership. If yes, enrol the account and move on. If no -- which will be the common answer -- create a "T0 Services" Silo with a tight UserAllowedToAuthenticateFrom Policy, bind the account to the Silo, deny WriteProperty on msDS-AllowedToActOnBehalfOfOtherIdentity for everyone but directory administrators, and audit Defender for Identity for the corresponding alerts [@ms-mdi]. The composite defence is the current best partial answer to the RBCD residual.

Group Managed Service Accounts (gMSA) are the preferred new-service-account primitive for the §6 reference deployment. The Microsoft Key Distribution Service (kdssvc.dll) on the domain controller derives the account's password from a domain-wide root key plus a per-account key identifier and rotates it on a configurable schedule; service hosts retrieve the current password through an ACL-controlled flow [@ms-gmsa-overview]. The cryptographic-rotation property -- not Silo membership -- is what closes the AS-REP roasting primitive in practical timeframes for a service-account workflow that the §6 PullQuote forbids from enrolling in Protected Users. Microsoft's How to Configure Protected Accounts page covers the wider per-account migration shape for legacy non-gMSA services [@ms-config-pa].

Phase 3: Roll the human T0 administrators into Protected Users in batches

Audit the longest-running tier-0 administrative task in your environment before you enrol anyone. Forest backups, replication health checks, schema upgrade dry-runs, DC promotions, and emergency operational procedures sometimes exceed four hours; the Protected Users 240-minute non-renewable TGT cap will silently re-authenticate or fail outright when they do [@ms-config-pa]. Enrol in batches of two or three administrators at a time; keep the previous batch in for at least two weeks before adding the next. Microsoft's How to Configure Protected Accounts page lays out the staged enrolment shape [@ms-config-pa].

Note: The 240-minute non-renewable TGT cap on Protected Users members is the single most common cause of failed pilot deployments. Tasks that ran fine for years quietly fail at the 4-hour mark, or worse, re-authenticate against a different identity that has lower privilege. Audit your longest-running T0 operations against the cap before enrolling humans; document workarounds (runas for long tasks; batch jobs running under gMSAs with a per-Policy lifetime configured deliberately) before the enrolment, not after.

Phase 4: Project the T0 group into Entra Conditional Access

Sync the T0 Admins group through Microsoft Entra Connect. Write a Conditional Access policy that requires phishing-resistant MFA (FIDO2, Windows Hello for Business, or certificate-based authentication) for that group, plus a compliant device, plus a known-good location if the threat model justifies it [@ms-pim]. Document explicitly that the CA is keyed on the synchronised group, not on the Silo binding; the two enforcement planes are independent by construction. The Entra side is the topic of the Conditional Access post in this series for the deeper treatment.

For the cloud-side treatment of Conditional Access policy shapes -- compliant device, phishing-resistant MFA grant control, location and risk conditions -- see the Conditional Access post in this series. The CA policy keyed on the synced T0 group is what holds the two-plane workaround together.

Phase 5: Break-glass

Two emergency-access accounts that are outside every Silo, outside Protected Users, with passwords stored offline in a tamper-evident envelope held by two separate people, with a documented monthly use-and-rotate procedure, and with high-fidelity SIEM detection on every authentication attempt. The cost of the break-glass pair is the deliberate, audited counter-balance to the rest of the architecture. Microsoft's RaMP guidance treats this as the first step of the privileged-access rollout [@ms-ramp]. The built-in domain Administrator (RID 500) is the natural canonical first break-glass identity because it is exempt from Authentication Policy enforcement even when assigned to a Silo [@ms-pu-current].

Microsoft's RaMP page lists "Emergency access accounts" as the first initiative of the entire Rapid Modernization Plan, ahead of Entra PIM and the on-prem controls [@ms-ramp]. The ordering is deliberate: a privileged-access deployment that locks itself out before it has secured the recovery path is worse than no deployment at all.

The Active Directory PowerShell module exposes the cmdlets directly. The skeleton below creates a Policy and a Silo in audit mode, then assigns one user. Adapt the SDDL to your PAW computer SIDs before running.

New-ADAuthenticationPolicy -Name "T0 Source Restriction" -UserTGTLifetimeMins 240 -UserAllowedToAuthenticateFrom 'O:SYG:SYD:(XA;OICI;CR;;;WD;(@USER.ad://ext/AuthenticationSilo == "T0 Admins"))'

The @USER.ad://ext/AuthenticationSilo token in that SDDL is evaluated at AS-REQ time against the source machine's user-token claims, not against the requesting user's own Silo binding -- the Policy admits the requesting user only from devices whose computer accounts are themselves Silo members of "T0 Admins" (typically the T0 PAW set). The token's evaluation context is the source-device side of the request, which is the practical encoding of the source-machine pinning Method A relies on [@ms-aps].

New-ADAuthenticationPolicySilo -Name "T0 Admins" -Enforce:$false -UserAuthenticationPolicy "T0 Source Restriction"

Set-ADAccountAuthenticationPolicySilo -Identity alice.da -AuthenticationPolicySilo "T0 Admins"

Add-ADGroupMember -Identity "Protected Users" -Members alice.da

Run in audit mode (Enforce:false) for a full audit cycle, validate the Security log for Authentication Policy Silo events, then flip to enforced mode. The official PowerShell-cmdlet documentation is on the Microsoft Learn AD-cmdlet pages; the relevant deployment shape is described in How to Configure Protected Accounts [@ms-config-pa].

You have a playbook. You also have a set of questions readers are now going to ask. Here they are.

11. Frequently asked questions

No -- service accounts must not be (see §6's canonical Microsoft Learn PullQuote), and workstation users do not need to be (the Silo plane and Credential Guard handle their threat model). For human administrators, the answer is "yes, in batches, after testing" -- see §10 Phase 3's Callout on the 4-hour TGT cap, which is the single most common pilot break. Indirectly. Kerberoasting per se is defeated by AES-only enforcement and high-entropy passwords. Protected Users forbids RC4 and DES for its members, so a Silo'd and Protected human administrator cannot be roasted with the public RC4-dependent tooling. For service accounts that cannot be Protected, the defence is explicit AES enforcement via `msDS-SupportedEncryptionTypes` plus gMSA-managed high-entropy passwords [@ms-config-pa]. Defender for Identity surfaces accounts that still use RC4 [@ms-mdi]. No. Two independent planes. The PRT does not carry `msDS-AssignedAuthNPolicySilo`, and Conditional Access does not consume it. The standard alignment is to synchronise the Silo'd group through Microsoft Entra Connect and write a CA policy keyed on the synced group. The CA sees the synchronised group, not the Silo. Both planes must hold for a hybrid privileged identity to be safe [@ms-eam][@palko-evol]. Closing the gap requires either a Microsoft product change or a third-party policy synthesiser; neither exists as a product surface in May 2026. Subtly. ESAE -- the Red Forest pattern -- was retired as a mainstream recommendation on December 15, 2020 [@ms-esae-retire]. The tier model as an *idea* was folded into the Enterprise Access Model [@ms-eam]; the directory-level controls (Authentication Policy Silos, Protected Users) remain Microsoft's recommended on-prem enforcement layer. New ESAE deployments are not recommended outside air-gapped OT, ICS, and SCADA scenarios; existing ESAE deployments operating as designed have no urgency to retire. KB 2871997 is the May 13, 2014 down-level backport of Protected Users client-side honoring and Authentication Policy / Silo client-side support to Windows 7, Windows 8, Server 2008 R2, and Server 2012 [@kb-2871997]. It is NOT the introduction of those features -- the introduction is Windows Server 2012 R2 GA on October 18, 2013 [@save-date-blog][@ms-pu-legacy]. The October 14, 2014 revision additionally shipped Restricted Admin Mode for RDP, which has its own cautionary history as the canonical example of a defence that became its own inverse [@kfalde-restricted-admin][@ms-rcg]. The schema supports it -- a Silo's `msDS-ComputerAuthNPolicy` link carries a Computer Policy with its own Computer TGT Lifetime, and DCs are valid Silo members in principle [@ms-aps]. The operational pattern doesn't do that, for two reasons. First, DCs are themselves the authentication authority, and Microsoft Learn's Authentication Policies and Silos page explicitly warns against changing Computer TGT Lifetime on DC class accounts because shortened TGT lifetimes disrupt replication and other DC-to-DC operations ("It is not recommended to change this setting" [@ms-aps]). Second, the Silo plane is built for the accounts that authenticate *to* DCs -- T0 admins, the AD CS computer account, the Entra Connect server -- where source-machine pinning is the high-impact control. Silo the accounts that authenticate to your DCs; protect the DCs themselves with the orthogonal directory primitives (KDC service-account configuration, Defender for Identity sensor deployment, code-signing and update management, physical isolation). The Tier Zero Table and BloodHound surface the DC-adjacent accounts that need Silo membership [@tzt-github][@bloodhound].

The directory now has the answer it lacked for sixteen years. Three controls, one ship, plus thirteen years of operational discipline to compose them, plus an explicit acknowledgement of the four residuals the KDC cannot close by construction. On the Tuesday morning in April 1997 when Paul Ashton posted his patched smbclient to NTBugtraq, no one in the AD product group could have written this article. They can now -- and the KDC, keyed on directory state, is the layer they would write it from.

Two Checkmarks and the Keys to the Kingdom: How Active Directory's Replication Protocol Became the Longest-Lived Credential Attack on Windows

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

Active Directory's replication protocol (MS-DRSR) lets any domain controller pull every secret in the directory from any other domain controller, and the access check gates on an ACL, not on whether the caller is actually a DC. Mimikatz's `lsadump::dcsync` (August 11, 2015) and `lsadump::dcshadow` (January 2018) are the read and write sides of this loophole; both remain in active operational use eleven years later because the protocol cannot be amended without breaking AD replication. Credential Guard cannot help -- the secret moves from a remote DC's NTDS.dit over the network, never touching the attacker's LSASS. The 2026 defender response is four parallel detection layers (posture, behavioral, network, graph) because no single layer catches every case, and the architectural fifth layer that would close the class is not coming.

1. Two Checkmarks and the Keys to the Kingdom

A non-admin service account, created during a 2017 file-server migration and never cleaned up, holds exactly two access-control entries on the contoso.local domain object: Replicating Directory Changes and Replicating Directory Changes All. From a Windows 11 workstation -- not a domain controller, not a tier-zero admin host, just a desk -- the attacker opens a Mimikatz prompt and types:

lsadump::dcsync /domain:contoso.local /user:krbtgt

Sixty seconds later they have the krbtgt NT hash and Kerberos AES keys, and they own the domain. Credential Guard, enabled on every workstation in the building, never saw the credential transit anywhere in its scope.

That last sentence is the punchline of the entire field. The secret never touches the attacker's LSASS, so Credential Guard's design has nothing to say. The keys move from a remote domain controller's on-disk database, over an RPC channel, into the attacker's process memory. Credential Guard isolates LSASS on the local machine. It has no jurisdiction over what a remote DC chooses to send when asked nicely.

Note: Credential Guard isolates LSASS-resident secrets in a separate virtual trust level. DCSync reads secrets from a remote DC's NTDS.dit over MS-DRSR -- a network protocol attack, not a local-memory attack. Microsoft's Credential Guard documentation does not claim protection against MS-DRSR-based credential extraction [@credential-guard-considerations].

The 60-second timeline is not a marketing number. One RPC round trip per principal is the protocol's per-principal cost, fixed by specification. For a single high-value target -- and krbtgt is the highest-value target in any Active Directory forest, because its long-term key signs every Kerberos ticket -- the attack is over before a typical SOC operator has finished pouring coffee.

The four people whose names recur in this story are worth meeting now. Benjamin Delpy (gentilkiwi) wrote Mimikatz and authored both the DCSync read primitive (2015) and, with Vincent Le Toux, the DCShadow write primitive (2018). Vincent Le Toux built the original DCShadow implementation and the PingCastle posture-assessment tool. Sean Metcalf (Trimarc / ADSecurity) translated DCSync into operator vocabulary in the weeks after its release. Microsoft's Defender for Identity team ships the canonical first-party detections that fire on this attack class today.

This story is what happens when a 23-year-old domain-controller-to-domain-controller protocol's access check turns out to gate on an ACL, not on whether the caller is a domain controller. Two ACEs on one object should not give an attacker the entire credential trove. The fact that they do is not a bug in the implementation. It is a 1999 design assumption -- that nobody who is not a DC would ever speak this protocol -- that survived twenty-five years as a social convention and was nowhere written down in the access-check code.

The next section explains why Microsoft built this protocol in the first place, and why its access check forgot to ask the one question that would have closed the loophole.

2. Why the Protocol Exists at All

Rewind to February 17, 2000. Microsoft ships Windows 2000 Server, and Active Directory replaces the old NT 4.0 PDC/BDC model [@microsoft-windows-2000-launch]. NT 4.0 was single-master: one Primary Domain Controller held the authoritative account database, every Backup Domain Controller held a read-only copy, and a password change on the PDC propagated to BDCs through a hub-and-spoke replication channel. AD inverts the model. Every domain controller in an AD domain holds a writable copy of the directory; a password change on any DC must propagate to every other DC within minutes; the replication topology is a mesh, not a star.

Multi-master replication is the design constraint that forces MS-DRSR's existence. If any DC can accept a write, then every DC must be able to pull every change -- including secret attributes like unicodePwd, dBCSPwd, ntPwdHistory, lmPwdHistory, and supplementalCredentials -- from every other DC. There is no second protocol. Replication of secrets is replication, and replication is MS-DRSR [@ms-drsr-spec].

The RPC protocol by which any Active Directory domain controller can replicate any object, including secret attributes, from any other DC in the same forest. Layered over DCE/RPC; the current public specification is revision 46.0 dated March 9, 2026 [@ms-drsr-spec]. MS-DRSR is the mechanism that makes AD's multi-master replication invariant work. The MS-DRSR method (opnum 3) that returns changed objects within a naming context. A calling DC supplies a target DN and a set of replication flags; the called DC returns the object's attribute values, with secret attributes encrypted under a session-derived key. This is the protocol method that DCSync invokes. flowchart LR subgraph Domain["contoso.local domain"] DCA[DC-A
NTDS.dit] DCB[DC-B
NTDS.dit] DCC[DC-C
NTDS.dit] end DCA -- IDL_DRSGetNCChanges
unicodePwd, ntPwdHistory --> DCB DCB -- IDL_DRSGetNCChanges
supplementalCredentials --> DCA DCB -- IDL_DRSGetNCChanges
dBCSPwd --> DCC DCC -- IDL_DRSGetNCChanges
unicodePwd --> DCB DCA -- IDL_DRSGetNCChanges
ntPwdHistory --> DCC DCC -- IDL_DRSGetNCChanges
krbtgt keys --> DCA

The access check that gates IDL_DRSGetNCChanges is defined in [MS-DRSR] §4.1.10. It asks one question: does the calling principal hold the appropriate extended rights on the naming-context root being replicated? Extended rights are AD's mechanism for control-access permissions that do not fit into the standard ACL bit set [@ms-drsr-spec].

A schema-defined access-control right identified by a GUID rather than by a standard ACL bit. Extended rights are granted via an access-control entry on a target object and checked at runtime by the operation that requires them. The three replication extended rights are the canonical example: each is identified only by GUID, and each is checked by `IDL_DRSGetNCChanges` against the caller's effective rights on the naming-context root. A top-level replication partition of the Active Directory database. Every AD forest has at least three NCs: the Schema NC, the Configuration NC, and one Domain NC per domain (plus optional Application NCs). DCSync operates against the Domain NC root.

Three extended rights together form what practitioners call the rights triad. The two-checkmark version from §1 is the most-common configuration; the third right unlocks a smaller set of attributes flagged confidential. Microsoft's own AD schema documentation enumerates each one [@ad-schema-get-changes][@ad-schema-get-changes-all][@ad-schema-get-changes-filtered-set]:

The combination of three replication extended rights on a naming-context root: `DS-Replication-Get-Changes` (the baseline read), `DS-Replication-Get-Changes-All` (unlocks secret attributes), and `DS-Replication-Get-Changes-In-Filtered-Set` (unlocks attributes with the confidential flag). The first two are what most operators mean when they say "DCSync rights"; the third is sometimes required for completeness.

Right	Display name	Rights-GUID	What it unlocks	Introduced
`DS-Replication-Get-Changes`	Replicating Directory Changes	`1131f6aa-9c07-11d1-f79f-00c04fc2dcd2`	Baseline replication read	Windows 2000 Server [@ad-schema-get-changes]
`DS-Replication-Get-Changes-All`	Replicating Directory Changes All	`1131f6ad-9c07-11d1-f79f-00c04fc2dcd2`	Secret attribute replication (`unicodePwd`, `ntPwdHistory`, etc.) [@ad-schema-get-changes-all]	Windows Server 2003
`DS-Replication-Get-Changes-In-Filtered-Set`	Replicating Directory Changes In Filtered Set	`89e95b76-444d-4c62-991a-0facbeda640c`	Confidential-flag attributes [@ad-schema-get-changes-filtered-set]	Windows Server 2008

In a freshly-installed AD domain, four principal sets hold the rights triad by default on the Domain NC root: the Domain Controllers group, the Domain Admins group, the Enterprise Admins group, and the built-in Administrators group [@sean-metcalf-dcsync-2015]. Every other ACE on that object is a deliberate delegation choice made by some operator at some point in the domain's history.

Now read the access check carefully. It asks whether the caller holds the rights. It does not ask anything about who the caller is. The protocol does not check whether the caller's Service Principal Name is GC/... or ldap/... or anything else. It does not check whether the caller's machine account is in the Domain Controllers group. It does not check whether the caller's Kerberos service ticket was issued for a DC service. The whole gate is the ACL on one object.

This is the most consequential design omission in any Microsoft network protocol. Every other replication-style protocol in Windows ships some form of caller-machine-identity assertion. MS-DRSR shipped without one because, in 1999, nobody on the design team imagined an unprivileged workstation would speak the DC-to-DC protocol.

The 1999 closed-population design assumption is the load-bearing fiction underneath this whole story. The protocol's designers assumed -- entirely reasonably for the deployment universe of that decade -- that the only software that would ever implement an MS-DRSR client was the DC role itself, which Microsoft shipped, signed, and audited. No defender in 1999 was thinking about a Python script speaking DRSUAPI from a desk. The assumption was a social convention dressed as a security model, and it survived for fifteen years.

If the protocol exists to replicate every secret in the directory, and the access check is the ACL on one object, what stopped anyone from abusing it for the protocol's first fifteen years? That accidental safety period is the subject of the next section.

3. The Fifteen-Year Accidental Safety Period

Between 2000 and 2015, attackers who wanted the entire credential trove of an Active Directory domain had exactly one road open to them: reach a domain controller and steal its database. The reasons are not subtle. The credentials lived in one file -- C:\Windows\NTDS\NTDS.dit, an Extensible Storage Engine database protected by a Password Encryption Key wrapped under the BootKey scattered across four registry values in the SYSTEM hive [@ntdsxtract-repo]. Without code execution on a DC, there was no obvious way to ask the directory for its secrets in bulk.

The on-disk Extensible Storage Engine ("Jet Blue") database that holds every Active Directory object, including secret attributes. Located at `C:\Windows\NTDS\NTDS.dit` on every domain controller. The file is locked while AD DS is running; offline copying requires either Volume Shadow Copy snapshots, `ntdsutil ifm` bundling, or DC downtime [@mitre-t1003-003].

Three sub-techniques bloomed inside this constraint, and MITRE catalogs them collectively as T1003.003 OS Credential Dumping: NTDS [@mitre-t1003-003]. Each is operationally distinct, and each requires the same precondition.

G1a -- Volume Shadow Copy plus offline parse. The attacker runs vssadmin create shadow /for=C: on a domain controller, creating an instant point-in-time snapshot. They copy NTDS.dit and SYSTEM out of the shadow path, exfiltrate both files, and parse them offline with Csaba Barta's ntdsxtract toolkit [@ntdsxtract-repo] or Impacket's secretsdump.py running in offline mode. The parse walks the datatable ESE table row by row, decrypts the PEK with the BootKey, and decrypts each principal's secret attributes with the PEK.

G1b -- ntdsutil Install From Media. The built-in command ntdsutil "activate instance ntds" "ifm" "create full C:\Temp\IFM" packages NTDS.dit and the SYSTEM hive into a clean bundle, intended for legitimate seeding of a new replica DC. With local admin on any DC, an attacker invokes it without involving VSS.

G1c -- LSASS injection of the long-term DC secrets. Mimikatz's pre-DCSync technique reads cached long-term secret material (including the krbtgt key) directly out of lsass.exe memory on a domain controller via lsadump::lsa /inject /name:krbtgt. The variant that turned this surface into a persistence implant was Skeleton Key, disclosed by the Dell SecureWorks Counter Threat Unit on January 12, 2015 [@skeleton-key-wayback]. Skeleton Key patches the NTLM and Kerberos validation routines in LSASS on a DC so that a single master password works for any account.

Skeleton Key sits at the boundary between credential dumping and persistence. It does not produce usable NT hashes or Kerberos keys for offline forging; it gives the attacker a backdoor at the authentication step. The 2015 community debate over Skeleton Key versus the (then-imminent) DCSync technique was settled decisively by DCSync's August release: dumping the hashes is more useful than backdooring the auth path, because dumped hashes survive a DC reboot and are forge-ready material [@skeleton-key-wayback].

Sub-technique	Mechanism	Canonical tool	Emitted artifact	Host artifact on DC
G1a VSS + offline parse	Point-in-time snapshot, file copy, offline ESE parse	`vssadmin` + `secretsdump.py` / `ntdsxtract`	NT hashes, Kerberos keys, password history	VSS event in system log
G1b `ntdsutil` IFM	Built-in admin command produces clean bundle	`ntdsutil "ac i ntds" "ifm"`	Identical to G1a	IFM staging directory
G1c LSASS inject	Read long-term secrets from `lsass.exe` memory	`mimikatz lsadump::lsa /inject`	`krbtgt` key and other LSA-cached secrets	Process access of `lsass.exe`

The structural cost across all three is the same: code execution as SYSTEM on a domain controller. Read that requirement slowly. In a mature enterprise with even a basic tiered-administration model -- no interactive logon to DCs from workstations, restricted-admin RDP, Privileged Access Workstations for Domain Admin sessions, Protected Users group membership for Tier Zero principals -- DCs are the most defended boundary in the network. An attacker who has crossed that boundary has, in operational terms, already won. The credential dump is the trophy lap.

flowchart TD Start[Attacker foothold
on workstation] Start --> VSS[G1a: VSS snapshot
+ offline parse] Start --> IFM[G1b: ntdsutil IFM
create full] Start --> Inject[G1c: LSASS inject
on DC] VSS --> Gate[SYSTEM on DC] IFM --> Gate Inject --> Gate Gate --> Creds[All domain credentials
NT hashes, Kerberos keys, krbtgt]

This is what made the closed-population design assumption survive its first fifteen years. The protocol's design was open to abuse from any joined workstation that held the rights triad, but nobody noticed because the cheaper attack road -- compromise a DC, parse the database offline -- still passed through a defended chokepoint. The ACL on the Domain NC was nowhere on a defender's risk register, because no offensive tooling existed that treated the ACL as the gate.

There was a question waiting to be asked, though. What if you could ask the DC to send you the credentials, using a protocol the DC already speaks fluently with its peers? The protocol's wire format is published. Microsoft Learn hosts the IDL. The DCs trust each other's calls by ACL. The only missing piece was a client implementation that any attacker could run from any joined machine.

In August 2015 the missing piece arrived.

4. Generation by Generation

August 11, 2015, 01:27 Central European Time. Benjamin Delpy commits 47,132 insertions to the Mimikatz repository in a single push titled "DCSync in mimikatz & for XP/2003." The diff introduces four new modules -- kull_m_rpc_drsr.c/.h and kull_m_rpc_ms-drsr.h/_c.c -- generated from the [MS-DRSR] IDL. They are an MS-DRSR client surface, slotted into kuhl_m_lsadump.c as the new lsadump::dcsync command [@mimikatz-dcsync-commit][@mimikatz-repo]. Vincent Le Toux is credited as co-author.

Six weeks later Sean Metcalf writes the canonical operator post and presents the technique at DerbyCon V on Friday, September 25, 2015, in the Track 1 (Break Me) slot from 3:00 to 3:50 pm [@sean-metcalf-dcsync-2015][@sean-metcalf-derbycon-2015]. The closed-population assumption shatters in a weekend.

A commit hash widely cited in operator forums for the DCSync introduction -- `79b3577aed999baac0352cb1ba3a5f86b6d29f34`, dated 2015-07-20 -- does not exist in the Mimikatz repository. A `git --no-pager log --all` against a fresh clone returns `fatal: bad object` for that hash; the GitHub commit URL returns 404; the GitHub API returns 422. The actual introducing commit is `7717b7a7173fa6a6b6566bbbc3e7372b464d988f`, authored by Benjamin DELPY at 2015-08-11 01:27:13 +0200, with the subject line *"DCSync in mimikatz & for XP/2003"* [@mimikatz-dcsync-commit]. Sean Metcalf's contemporary writeup at ADSecurity confirms August 2015 as the release month [@sean-metcalf-dcsync-2015]. The lesson for verifying any third-party claim about a Mimikatz commit is the same lesson Stage 1 of this article's research pipeline applied: clone the repo, run `git show`.

What follows is the story of four generations of attacker approaches against this protocol, each motivated by the operational limit of the previous one.

Generation 2: DCSync (2015-08-11 onward)

Mimikatz becomes a DRSUAPI client. Operator invocation is one line:

lsadump::dcsync /domain:contoso.local /user:krbtgt

Behind that line, six wire steps fire:

sequenceDiagram participant A as Attacker workstation participant DC as Target DC (DRSUAPI) A->>DC: 1. resolve target DC by domain A->>DC: 2. IDL_DRSBind (interface UUID DRSUAPI) DC-->>A: 3. bind reply (handle, session key) A->>DC: 4. IDL_DRSGetNCChanges (opnum 3, MTX_ADDR DN, EXOP_REPL_OBJ) DC-->>A: 5. DRS_MSG_GETCHGREPLY (encrypted secret attributes) A->>A: 6. decrypt with session key, emit NT hash and Kerberos keys

The wire format is one round trip per principal. To dump every account in the domain, Mimikatz's /all /csv mode iterates the request server-side via the same opnum with paginating up-to-date vectors. Per-call wire size is a few kilobytes for a single user; full-domain bulk dumps run to tens of megabytes. Wall-clock time is dominated by network latency to the target DC [@sean-metcalf-dcsync-2015][@trellix-silent-domain-hijack].

The Generation-1 precondition is gone. The attack runs from any joined workstation. The Generation-1 host artifacts -- VSS events, IFM staging directories, multi-megabyte file copies -- all disappear. The only on-the-wire signature is "an IDL_DRSGetNCChanges call from an IP that is not a domain controller" -- which has to be detected at the protocol layer, not the host layer.

Sean Metcalf's 2015 post named the detection recipe in the same breath as the attack: "Configure IDS to trigger if DsGetNCChange request originates an IP not on the 'Replication Allow List' ..." [@sean-metcalf-dcsync-2015]. Every network detection rule in this space, including Microsoft's own ATA "Unusual Protocol Implementation" category two years later, descends from that one sentence [@ata-v17-release-notes].

DCSync is read-only. The ACL pair the attack exploits does not include directory-write rights. An attacker who wants to plant SID-history backdoors, modify userAccountControl flags, or write to AdminSDHolder needs a different primitive. The same trust loophole that gave them read access turns out to support a symmetric write side.

Generation 3: DCShadow (2018-01-24)

January 23-24, 2018. Benjamin Delpy and Vincent Le Toux present at BlueHat IL in Tel Aviv. The talk is titled "Active Directory: What can make your million dollar SIEM go blind?" [@youtube-bluehat-2018-dcshadow]. Four days later, on January 27, 2018, Delpy pushes the mainline merge to Mimikatz with commit ab18bd1, subject "Pushing @vletoux DCShadow in current branch with some adaptations" [@mimikatz-dcshadow-commit].

Vincent Le Toux contributed the original implementation; the BlueHat IL talk shared joint Delpy/Le Toux billing; the Mimikatz mainline merge commit ab18bd103a5cd7e26fb8d475c5ea0157d6633ca9 is dated 2018-01-27 01:37:55 +0100, four days after the conference disclosure. Le Toux is the same author behind PingCastle's posture-assessment tooling and the canonical dcshadow.com reference site [@mimikatz-dcshadow-commit][@dcshadow-com].

DCShadow inverts DCSync. Where DCSync makes the attacker a DRSUAPI client, DCShadow makes the attacker a DRSUAPI server. The mechanism: temporarily register an nTDSDSA object plus the associated SPNs in the Configuration NC; signal to a legitimate DC that the new "DC" wants to push changes via IDL_DRSReplicaAdd followed by IDL_DRSReplicaSync; the legitimate DC pulls the attacker's pre-staged writes through the replication channel as if they were legitimate peer replication; deregister to clean up [@mitre-t1207][@dcshadow-com].

sequenceDiagram participant A as Attacker (rogue DC) participant Cfg as Configuration NC participant T as Target DC A->>Cfg: 1. create nTDSDSA + server object A->>Cfg: 2. add SPNs (GC, DRS UUID) to machine account A->>T: 3. IDL_DRSReplicaAdd (dsaSrc = attacker) T->>A: 4. IDL_DRSGetNCChanges callback (target pulls) A-->>T: 5. staged writes returned as replication payload A->>T: 6. IDL_DRSReplicaDel A->>Cfg: 7. delete nTDSDSA, remove SPNs A directory operation that does not generate the standard Event ID 4662 / 4738 / 5136 object-modification events that the Domain Services Auditing subsystem emits for normal writes. Legitimate DC-to-DC replication is SACL-silent by design -- the audit subsystem intentionally suppresses change events on the replication channel to avoid drowning every DC in audit traffic on every directory change. DCShadow writes are SACL-silent because they ride the same channel.

That last design fact is the entire point of the talk title. A SIEM watching object-modification events sees nothing when a DCShadow write lands, because the modifications arrive on the replication channel that the SIEM intentionally ignores as routine DC chatter. The original 2018 framing -- "your million-dollar SIEM goes blind" -- was correct for SIEMs that monitored only object-modification events. We will see in §6 how that framing has aged.

DCShadow is write capability. An attacker who reaches it can plant SID-history backdoors (write S-1-5-21-...-519 for Enterprise Admins into a low-privileged account's sIDHistory), modify userAccountControl to clear ACCOUNTDISABLE on dormant high-privilege accounts, add ACEs to AdminSDHolder (which then propagate via the SDProp process to every protected admin account every 60 minutes), or set msDS-AllowedToActOnBehalfOfOtherIdentity on a target computer to enable resource-based constrained delegation chains.

Generation 4: Permission-graph attacks (2018-present)

By 2018 the attack-side question had shifted. Holding the rights triad directly was no longer the interesting precondition; the interesting question was how to reach it transitively, through whatever chain of ACL delegations a real-world domain happened to contain. The umbrella term that emerged is permission-graph attack. Its terminal edge is still DCSync; its novelty is the path that gets you to the terminal.

Three primitives anchor this generation. Elad Shamir's Wagging the Dog (January 28, 2019) showed how writing msDS-AllowedToActOnBehalfOfOtherIdentity on a target computer object enables S4U2Self plus S4U2Proxy impersonation of any user to that computer [@shenaniganslabs-wagging-the-dog]. Shamir's Shadow Credentials (June 21, 2021) demonstrated that writing msDS-KeyCredentialLink on a target account adds an attacker-controlled certificate trust, enabling Kerberos PKINIT authentication as that account without resetting its password [@eladshamir-shadow-credentials]. And Sean Metcalf's earlier work on AdminSDHolder template abuse showed that writing the AdminSDHolder ACL causes SDProp to propagate the new ACL onto every protected admin account every 60 minutes -- self-healing persistence that survives defender cleanup [@sean-metcalf-adminsdholder].

The unifying observation: DCSync is a terminal in a permission graph. The graph's nodes are AD principals; its edges are individual access-control entries (WriteDACL, WriteOwner, GenericAll, WriteProperty, AddMember, ForceChangePassword). Whoever can traverse the graph to the rights triad on the domain root has DCSync transitively. The attacker's job is no longer to invoke IDL_DRSGetNCChanges; it is to find the shortest path through the graph from a foothold to the rights triad. The defender's mirror job is to enumerate all paths into the rights triad and either prune them or monitor them.

gantt title Domain replication attack class evolution dateFormat YYYY-MM-DD axisFormat %Y section Attack Gen 1 NTDS.dit theft :a1, 2000-02-17, 2015-08-11 Gen 2 DCSync :active, a2, 2015-08-11, 2026-12-31 Gen 3 DCShadow :active, a3, 2018-01-24, 2026-12-31 Gen 4 Permission-graph chains :active, a4, 2018-06-01, 2026-12-31 section Defense BloodHound 1.0 DEF CON 24 :d1, 2016-08-06, 30d ATA 1.7 release :d2, 2017-04-01, 30d Azure ATP DCShadow alerts :d3, 2018-07-24, 30d Azure ATP rebrand to MDI :d4, 2020-09-22, 30d BloodHound v6.0 :d5, 2024-09-30, 30d BloodHound v6.3 Butterfly :d6, 2024-12-09, 30d BloodHound v8.0 OpenGraph :d7, 2025-07-29, 30d Trellix NDR Silent Hijack :d8, 2025-12-08, 30d

To make the read-side access check decision concrete -- and to expose how thin it actually is -- here is the logic of the gate written as a runnable function. This is pseudocode for the decision, not the protocol bytes:

{` // Illustrative model of the MS-DRSR access check on IDL_DRSGetNCChanges. // Returns "secrets returned" or "ACCESS_DENIED" given a caller's effective // rights on the naming-context root. function dcsyncAccessCheck(callerRights, ncRootDn, requestedAttrs) { const GET_CHANGES = '1131f6aa-9c07-11d1-f79f-00c04fc2dcd2'; const GET_CHANGES_ALL = '1131f6ad-9c07-11d1-f79f-00c04fc2dcd2'; const GET_CHANGES_FILTERED = '89e95b76-444d-4c62-991a-0facbeda640c';

const SECRET_ATTRS = new Set(['unicodePwd', 'dBCSPwd', 'ntPwdHistory', 'lmPwdHistory', 'supplementalCredentials']); const wantsSecrets = requestedAttrs.some(a => SECRET_ATTRS.has(a));

// Baseline read requires GetChanges. if (!callerRights.has(GET_CHANGES)) return 'ACCESS_DENIED'; // Secret attributes require GetChangesAll. if (wantsSecrets && !callerRights.has(GET_CHANGES_ALL)) return 'ACCESS_DENIED';

// Notice what is NOT checked: caller's SPN, machine-group membership, // ticket service, source IP. The access gate is the ACL, full stop. return 'secrets returned'; }

const attacker = new Set([ '1131f6aa-9c07-11d1-f79f-00c04fc2dcd2', '1131f6ad-9c07-11d1-f79f-00c04fc2dcd2', ]); console.log(dcsyncAccessCheck(attacker, 'DC=contoso,DC=local', ['unicodePwd', 'ntPwdHistory'])); `}

Four generations, eleven years, no Generation 5 in sight. What is the single insight that lets all of this exist, and why has nobody patched it?

5. There Is No DC Check

The whole structural error of this protocol is one missing question. Specification [MS-DRSR] §4.1.10 defines the access check on IDL_DRSGetNCChanges as: does the calling principal hold the rights triad on the naming context being replicated? [@ms-drsr-spec] That is the whole gate. There is no second check that asks "is the caller's service principal name a domain-controller SPN?" or "is the caller's machine account in the Domain Controllers group?" or "was the caller's Kerberos service ticket issued for a DC service?" The spec is empirically and literally just an ACL check on the NC root.

The empirical proof that a non-DC client succeeds lives in Mimikatz's kuhl_m_lsadump.c and its DRSUAPI client surface in kull_m_rpc_drsr* [@mimikatz-repo]. Mimikatz is software running on a workstation. It binds to the DRSUAPI interface UUID, calls IDL_DRSGetNCChanges, and the call returns. The protocol's behavior is correct by specification. The security model is the bug.

A major feature added to Mimkatz in August 2015 is 'DCSync' which effectively 'impersonates' a Domain Controller and requests account password data from the targeted Domain Controller. DCSync was written by Benjamin Delpy and Vincent Le Toux. -- Sean Metcalf, ADSecurity, September 2015 [@sean-metcalf-dcsync-2015]

Read Metcalf's verb carefully: impersonates. The scare quotes are doing work. The Mimikatz client is not pretending to be a DC in any cryptographic sense. It is not forging a machine-account ticket. It is not spoofing an SPN. It is not bypassing any signature check.

It is honestly making an authenticated call as the principal it actually is -- some user or service account that happens to hold the rights triad -- and the protocol honestly responds because its gate is satisfied. The "impersonation" framing is operator vocabulary borrowed from the social model the protocol was written under.

The 1999 designers assumed only DCs would speak. By that social contract, anyone who speaks must be a DC. The spec encoded the social contract by way of not encoding it at all. The ACL was the whole gate because, in 1999, the ACL was always satisfied by something that was always a DC.

flowchart TD Start[IDL_DRSGetNCChanges request arrives] Start --> Q1{"Caller holds rights triad
on the NC root?"} Q1 -- yes --> Return[Return encrypted
secret attributes] Q1 -- no --> Deny[ERROR_DS_DRA_ACCESS_DENIED] Start -.-> Absent["What the check does NOT ask:
Is the caller a domain controller?
Is the SPN a DC SPN?
Is the machine in Domain Controllers?"] Absent -.-> Nothing[no second gate exists]

This is the article's intellectual fulcrum. The 1999 closed-population assumption -- only DCs speak this protocol -- survives in 2026 as an open-population reality (anyone with the rights speaks it), and the closed-population assumption is nowhere written down in the access-check code. The fix that would close the model would require a second gate. The spec did not write one. The implementation cannot synthesize one without breaking every legitimate consumer that already operates without one (more on this in §8).

Key idea: The protocol's design is correct. The security model is the bug. No patch can fix this without breaking Active Directory replication itself.

There is a temptation, on first encountering this, to assume the missing gate is an oversight that Microsoft will eventually fix. That intuition is wrong, and it is wrong for a deeper reason than "Microsoft has not gotten around to it." If the protocol is the bug and the protocol cannot be amended, what defenses can possibly work in 2026? That question carries us into the next section.

6. What 2026 Actually Ships Against This

If the protocol cannot be fixed, the defender's question is no longer "how do I prevent DCSync?" but "which layer catches which class of attempt?" Four production detection layers ship against this attack class in 2026. None of them is individually sufficient. A fifth layer -- the architectural one that would close the structural error -- does not exist and is not coming.

Posture: enumerate who holds the rights

The posture layer reads the static ACL on the Domain NC root and surfaces every principal that holds any of the three rights. Microsoft Defender for Identity ships this as an Accounts security posture assessment family, computed continuously from MDI's per-DC sensors [@mdi-security-posture-accounts]. Vincent Le Toux's PingCastle exposes it as the C-DCSync finding in its critical-risks section. Tenable Identity Exposure exposes it as an indicator of exposure. Christopher Keim's 2025 practitioner guide documents the PowerShell pattern that AD administrators without a posture-tool license can run on demand [@keim-dcsync-rights]:

Illustrative model of the posture-layer check. In production, replace SAMPLE_ACL with output from Get-Acl in PowerShell or python-ldap against the live Domain NC root.

GET_CHANGES = '1131f6aa-9c07-11d1-f79f-00c04fc2dcd2' GET_CHANGES_ALL = '1131f6ad-9c07-11d1-f79f-00c04fc2dcd2' GET_CHANGES_FILTERED = '89e95b76-444d-4c62-991a-0facbeda640c' TRIAD = {GET_CHANGES, GET_CHANGES_ALL, GET_CHANGES_FILTERED}

DEFAULTS = { 'BUILTIN\\Administrators', 'CONTOSO\\Domain Controllers', 'CONTOSO\\Domain Admins', 'CONTOSO\\Enterprise Admins', 'NT AUTHORITY\\ENTERPRISE DOMAIN CONTROLLERS', }

SAMPLE_ACL = [ {'principal': 'CONTOSO\\Domain Admins', 'right': GET_CHANGES}, {'principal': 'CONTOSO\\Domain Admins', 'right': GET_CHANGES_ALL}, {'principal': 'CONTOSO\\Enterprise Admins', 'right': GET_CHANGES}, {'principal': 'CONTOSO\\Enterprise Admins', 'right': GET_CHANGES_ALL}, {'principal': 'CONTOSO\\backup_svc_2017', 'right': GET_CHANGES}, {'principal': 'CONTOSO\\backup_svc_2017', 'right': GET_CHANGES_ALL}, {'principal': 'CONTOSO\\MSOL_a1b2c3', 'right': GET_CHANGES}, {'principal': 'CONTOSO\\MSOL_a1b2c3', 'right': GET_CHANGES_ALL}, ]

residual = {} for ace in SAMPLE_ACL: if ace['right'] in TRIAD and ace['principal'] not in DEFAULTS: residual.setdefault(ace['principal'], set()).add(ace['right'])

for principal, rights in residual.items(): print(f"{principal}: {len(rights)} of 3 replication rights") `}

The residual set is the operational unit of work. In a freshly-installed domain it is empty. In a ten-year-old forest with a history of mergers and migrations it typically contains five to twenty entries -- a mix of legitimately delegated identity-sync products and forgotten service accounts from projects nobody on the current operations team remembers.

In Microsoft's Enhanced Security Administrative Environment and the BloodHound conventions, the set of principals and assets whose compromise yields domain-wide control. The `krbtgt` account, members of `Domain Admins` and `Enterprise Admins`, the Entra ID Connect MSOL_ sync account, and any non-default principal holding the rights triad on the domain root are all Tier Zero by construction. The Microsoft Entra ID (formerly Azure AD) Connect synchronization service account, created on-premises during Entra Connect installation. The account name uses an `MSOL_` prefix followed by a hex suffix. It legitimately holds the rights triad on the Domain NC root because it must replicate password hashes to the cloud directory; treating it as Tier Zero is the standard hardening recommendation. Microsoft Defender for Identity's (and ATA's earlier) internal baseline of which computers in the domain legitimately speak DRSUAPI to which DCs. Incoming `IDL_DRSGetNCChanges` requests are matched against this baseline; a request from a source outside the list fires the External ID 2006 alert.

An earlier scope document for this article quoted an MDI assessment titled verbatim "Remove non-admin accounts with DCSync permissions." That exact title does not appear on the live MDI Accounts security-posture-assessment page in 2026 [@mdi-security-posture-accounts][@mdi-security-posture-hybrid]. The surface exists -- MDI's Accounts and Hybrid security posture-assessment families together cover non-default principals with replication rights -- but the verbatim title was not reproducible.

Behavioral: catch the act after it fires

The behavioral layer watches network traffic and event logs for the act of DCSync or DCShadow as it happens. Microsoft's first-party stack lives in Defender for Identity and ships three canonical alerts [@mdi-alerts-classic]:

External ID 2006 -- "Suspected DCSync attack (replication of directory services)." Credential Access (TA0006), Persistence (TA0003). Technique T1003.006. Severity High. Trigger: a replication request is initiated from a computer that is not a domain controller.
External ID 2028 -- "Suspected DCShadow attack (domain controller promotion)." Defense Evasion (TA0005). Technique T1207. Trigger: a machine in the network tries to register as a rogue domain controller.
External ID 2029 -- "Suspected DCShadow attack (domain controller replication request)." Defense Evasion (TA0005). Technique T1207. Trigger: a suspicious replication request is generated against a genuine domain controller, indicative of DCShadow.

The product lineage is Microsoft Advanced Threat Analytics 1.7 (April 2017, where DCSync was covered under the umbrella "Unusual Protocol Implementation enhancements" detection category [@ata-v17-release-notes]); Azure Advanced Threat Protection (2018, where Tali Ash's July 24, 2018 Microsoft Tech Community post announced the two named DCShadow detections that became 2028 and 2029 [@tali-ash-azure-atp-dcshadow]); and Defender for Identity (the Microsoft Ignite 2020 rebrand, week of September 22-24, 2020 [@rcpmag-defender-rebrand]). The detection content carries forward unchanged across product renamings; what changes is the portal it surfaces in [@mdi-whats-new].

Open-source SIEM equivalents implement the same detection via Event ID 4662 on the domain object. The Sigma rule Mimikatz DC Sync (id 611eab06-a145-4dfa-a295-3ccc5c20f59a) fires on Event ID 4662 where Properties contains any of the three rights GUIDs or the literal string Replicating Directory Changes All, with AccessMask=0x100 [@sigma-rule-dcsync]. Splunk's parallel detection Windows AD Replication Request Initiated by User Account (rule 51307514-1236-49f6-8686-d46d93cc2821) implements the equivalent SPL search with the same MITRE T1003.006 annotation and the same known-false-positive list (Azure AD Connect, dcdiag.exe /Test:Replications) [@splunk-research-dcsync].

The SACL-event detection layer (Sigma + Splunk + every other SIEM-side implementation) requires that the operator first enable Advanced Security Audit policy Audit Directory Services Access under DS Access, with SACLs on the domain root auditing the three rights against Everyone, Domain Computers, and Domain Controllers. A fresh-install AD does not have these SACLs by default [@splunk-research-dcsync]. The detection rule's documentation calls out the prerequisite explicitly; many operators discover it only after wondering why their Splunk dashboard is silent.

Network: NDR on the DRSUAPI interface

The network layer parses DCE/RPC traffic on the wire, identifies the DRSUAPI interface by its UUID, and fires when an IDL_DRSGetNCChanges call originates from a source outside the legitimate-DC baseline. The canonical 2025 reference is Trellix Advanced Research Center's "Silent Domain Hijack: Uncovering the DCSync Attack and Detecting with Trellix NDR", published in week 50 of 2025 [@trellix-silent-domain-hijack]. Equivalent capability ships in Microsoft Defender for Identity's network analytics layer (the same sensor that powers External ID 2006) [@mdi-alerts-classic].

The Trellix writeup is explicit about the architecture: "Trellix NDR detects replication protocol abuse by analyzing abnormal DCE/RPC and MS-DRSR traffic. It detects DCSync-like behavior when replication requests are sent from non-DC hosts or unusual users" [@trellix-silent-domain-hijack]. The detection is independent of host-side telemetry, so it survives EDR tampering and works in environments where a DC is un-sensored from MDI's perspective.

Graph: BloodHound traverses the permission graph

The graph layer was built specifically for Generation 4. BloodHound, originally released by Andy Robbins, Rohan Vazarkar, and Will Schroeder at DEF CON 24 on August 6, 2016, models "you have DCSync rights to the domain" as a directed edge from a principal to the domain node, computed by combining the separately-collected GetChanges and GetChangesAll ACEs through nested-group membership [@wald0-bloodhound-intro][@defcon24-bloodhound-pdf][@bloodhound-edge-dcsync]. An operator queries "shortest path from any compromised principal to the DCSync edge into a Domain node" and gets back every transitive route into the rights triad.

The 2024-2026 release cadence is dense and matters:

BloodHound v6.0 (September 30, 2024) improved logic for identifying and creating complex edges requiring multiple permissions, including DCSync, when Authenticated Users or Everyone groups are involved [@bloodhound-v6-0-release-notes]. This closed a long-standing blind spot in which rights granted to a wildcard principal (the worst kind of delegation drift, often dating from compatibility settings in pre-2003 forests) were not surfaced as DCSync edges.
BloodHound v6.3 (December 9, 2024) introduced the Butterfly algorithm -- bi-directional risk analysis. Where the historical query was "which principals can attack this target?", Butterfly adds "which targets can be attacked from this compromised principal?" SpecterOps describes the algorithm in their blog post Unwrapping BloodHound v6.3 with Impact Analysis: "This is a massive upgrade to BloodHound Enterprise's risk analysis capability with a new algorithm we call 'Butterfly'" [@specterops-butterfly-blog][@bloodhound-v6-3-release-notes].
BloodHound v8.0 (July 29, 2025) introduced OpenGraph, generalizing the graph engine to model attack paths across non-AD systems (GitHub, 1Password, NPM, Snowflake) using the same Cypher front-end. The DCSync edge remains AD-specific; OpenGraph's relevance is that hybrid-cloud principals can now be modeled end-to-end [@bloodhound-v8-0-release-notes].

The graph layer is the only one that catches multi-hop chains to the rights triad. A principal A with GenericAll on group B, where B has the DCSync triad, is invisible to MDI's posture assessment but stands out as a one-hop path in BloodHound.

flowchart TD subgraph Posture[Posture layer] P1[MDI Accounts assessments] P2[PingCastle C-DCSync] P3[Keim PowerShell pattern] end subgraph Behavioral[Behavioral layer] B1[MDI 2006 / 2028 / 2029] B2[Sigma 611eab06] B3[Splunk 51307514] end subgraph Network[Network layer NDR] N1[Trellix NDR] N2[MDI per-DC sensor] N3[CrowdStrike DCE/RPC IoA] end subgraph Graph[Graph layer] G1[BloodHound DCSync edge] G2[v6.3 Butterfly Impact] G3[v8.0 OpenGraph] end P1 --> SOC[SOC alert queue] P2 --> SOC P3 --> SOC B1 --> SOC B2 --> SOC B3 --> SOC N1 --> SOC N2 --> SOC N3 --> SOC G1 --> SOC G2 --> SOC G3 --> SOC

The full layer-by-layer comparison is the load-bearing matrix of the entire 2026 SOTA:

Layer	What it inputs	What it detects	What it misses	False-positive class	Detection latency	Cost
Posture	NC-root ACL	Direct grant of the rights triad to a non-default principal	Multi-hop transitive paths; legitimate-principal abuse	Identity-sync products (Entra Connect MSOL_, third-party HR-IDM); legitimately delegated backup agents	24h score recomputation; ACE changes near real time	Built in to MDI; PowerShell variant free
Behavioral	Event ID 4662 or sensor-captured DRSUAPI traffic	The act of DCSync, or the DCShadow registration / replication, after it happens	Pre-attack staging; compromised-DC speaker; un-sensored DC blind spot	Azure AD Connect syncs; `dcdiag.exe /Test:Replications`	Minutes (alert "after the fact")	MDI license; Sigma / Splunk free with SACL config
Network	DCE/RPC packet capture	Wire signature of `IDL_DRSGetNCChanges` from non-DC source	Encrypted RPC payloads (per-principal granularity); sub-DC replicas misclassified	Same as behavioral plus Samba-DC peers	Seconds (passive inspection)	Commercial NDR appliance
Graph	LDAP-collected ACEs and group nesting	Multi-hop graph paths that could reach the rights triad	Net-new ACEs created after the last collection	Stale data showing principals that no longer hold the right	Hours to weeks (collection cadence)	BloodHound CE free; BHE commercial
Architectural (un-shipped)	TPM-attested DC machine identity	Pre-empts non-DC speaker entirely	Compromised DC speaker; rogue `nTDSDSA` registration	N/A	N/A (preventive)	Requires Microsoft protocol amendment

Four layers, dozens of products, no shortage of detections. Why isn't the problem solved?

7. Which Gap Does Each Defense Close?

The matrix in §6 has one structural observation that earns its keep. Read down the What it misses column. Each detection layer has a class of cases it cannot see. The posture layer cannot see transitive paths. The behavioral layer cannot see pre-attack staging or compromised-DC speakers. The network layer cannot see encrypted RPC payloads. The graph layer cannot see net-new ACEs created after the last collection. That is the load-bearing reason a mature defender runs all four in parallel instead of picking one.

Run a thought experiment. Suppose you ship only the posture layer. Your MDI assessment is green: no non-default principals hold the rights triad. An attacker compromises a workstation belonging to an unrelated business unit, finds that the BU has GenericAll on a group LegacyApp_Operators that itself has WriteDACL on the BackupOperators group, and adds themselves to BackupOperators. BackupOperators inherits a forgotten 2014 delegation of the rights triad through three levels of nesting. Then DCSync runs.

The posture layer never saw this because the residual list at the NC root is the four defaults. The graph layer would have surfaced the path. The behavioral or network layer would have fired the moment the DCSync call hit the wire. Without those layers, your green dashboard is a single-layer fantasy.

Now consider the inverse. You ship only the behavioral layer. MDI fires External ID 2006 -- but only after the request hits the DC. Your SOC's mean response time is twelve minutes. The attacker's mean complete-the-extraction time is sixty seconds. The detection is real; the response window is not.

The same structural observation applies on the attack side. The four attack primitives have very different precondition costs:

Attack primitive	Pre-condition	Output	Default detection layer	Tier of damage
DCSync via Mimikatz	Rights triad on NC root	Every secret-attribute value for one or all principals	MDI 2006; Sigma 611eab06; Splunk 51307514; NDR	Domain takeover (via Golden Ticket from `krbtgt`)
DCSync via Impacket	Same as Mimikatz; no on-target binary footprint	Same as Mimikatz, plus PtH / PtT auth modes	Same as Mimikatz (wire signature is identical)	Domain takeover
DCShadow	Domain Admin, local administrator on a DC, or `KRBTGT` hash (for rogue-DC registration) [@mitre-t1207][@dcshadow-com]	Arbitrary directory write, SACL-silent	MDI 2028 + 2029	Domain persistence (SID-history, AdminSDHolder ACE re-grant)
Gen-4 chains	Any ACE that transitively leads to the triad	Reach DCSync, then DCSync's output	BloodHound DCSync edge inbound paths	Domain takeover (composite)

DCSync via Mimikatz and via Impacket [@impacket-secretsdump] share the output (domain takeover via credential theft) and the default detection (the wire signature is the same). Their pre-conditions are identical. The Hacker Recipes documents Impacket's invocation surface for both pass-the-hash and pass-the-ticket modes [@hacker-recipes-dcsync]. This is why Impacket's secretsdump.py -just-dc has become the universal red-team and IR tool, while Mimikatz remains the reference implementation that every blue-team detection still names.

The Generation-4 row is the interesting one. Its pre-condition is dramatically cheaper than the other three (any ACE that leads to the triad, rather than the triad in hand). Its detection is by graph traversal, not by wire signature. This is why the 2024-2026 frontier in this space has been the graph layer: the attack-side cost asymmetry favors the chain-finding problem, so the defense-side investment has landed there.

A reader who has internalized the "no DC check" observation will naturally ask: surely the obvious architectural fix is to add a caller-machine-identity check? CVE-2020-1472, popularly known as Zerologon, is the counterexample. Secura's September 2020 whitepaper, published approximately one month after Microsoft's August 11, 2020 patch, documented that the Netlogon protocol's `ComputeNetlogonCredential` AES-CFB8 implementation used an all-zero initialization vector. An attacker who sends an all-zero `ClientChallenge` exploits the IV bug to authenticate with roughly 1-in-256 probability per attempt, then calls `NetrServerPasswordSet2` to reset the DC's machine account password (commonly to all zeros) and becomes that DC for protocol purposes [@secura-zerologon-whitepaper]. After Zerologon-class compromise, the attacker *is* a DC. Any architectural caller-machine-identity check on `IDL_DRSGetNCChanges` would have been satisfied. Zerologon is the canonical worked proof that promoting the access-check from "rights" to "rights and DC identity" raises the bar but does not change the class.

Note: Every detection layer in this space has a class of cases it cannot see. Mature defenders run all four (posture, behavioral, network, graph) because each layer is the only answer for a specific class of inputs, and accept that the un-shipped fifth layer (architectural) would only narrow the gap, not close it. Single-layer deployments produce confident but incomplete coverage.

If even the hypothetical perfect architectural fix would not close the class, what are the actual theoretical limits of any possible defense?

8. Why the Protocol Cannot Be Fixed

Two structural ceilings bound any conceivable MS-DRSR amendment. Both are provable from the specification's own definition of what it must do; both have been corroborated by the post-2018 industry consensus that detection (not prevention) is the only viable defender posture.

Ceiling 1: replicated secret material is the data the protocol exists to carry. MS-DRSR is the mechanism by which Active Directory's multi-master replication invariant holds. If IDL_DRSGetNCChanges did not return secret attributes -- unicodePwd, dBCSPwd, ntPwdHistory, lmPwdHistory, supplementalCredentials -- then a password change on DC-A would not converge to DC-B within the replication interval. AD's "any DC accepts any write and the others catch up within minutes" property would collapse [@ms-drsr-spec]. The protocol cannot stop returning secrets without ceasing to be the protocol. This is why "disable MS-DRSR" appears on every list of options that look attractive in a slide deck and break replication in production within minutes of being applied.

Ceiling 2: a machine-identity check on the caller would shift the attack class, not close it. Suppose Microsoft amended the access check on IDL_DRSGetNCChanges to require, in addition to the rights triad, a cryptographic proof that the caller's machine account is in the Domain Controllers group -- for example, that the call was made under a Kerberos service ticket issued for a DC SPN. This would defeat the Mimikatz-from-workstation case. It would also defeat every legitimate integration that today holds the rights triad on a non-DC service account: the Entra ID Connect MSOL_ account, third-party HR identity-management connectors, every backup and disaster-recovery tool that integrates at the AD level.

Worse, the new check would shift the attack class to compromising a DC's machine account -- CVE-2020-1472 Zerologon being the canonical worked example (see the §7 Aside for the mechanism). After a Zerologon-class compromise the attacker is a DC, so promoting the speaker check from (rights) to (rights and DC-identity) raises the bar but does not change the class [@secura-zerologon-whitepaper].

flowchart TD Fix[Proposed MS-DRSR fix] Fix --> A[Stop returning secrets
in IDL_DRSGetNCChanges] Fix --> B[Add machine-identity check
on the caller] A --> A1[AD multi-master replication breaks
password changes do not propagate] B --> B1[Legitimate integrations break
MSOL_ account, HR IDM, backup tools] B --> B2[Attack shifts to compromised DC
machine accounts e.g. Zerologon
CVE-2020-1472]

The honest structural fix would require a different replication architecture: a TPM- or HSM-attested DC machine identity, bound to a sealed replication key, with secret attributes encrypted under that key on the wire. No caller without the sealed key (or its hardware-bound equivalent on a different DC) could ever decrypt the response.

Microsoft has not announced any such architecture. Its closest published precedent in the Windows security stack is the LSAIso trustlet that Credential Guard uses for LSASS isolation -- a per-host isolation primitive applied to a per-host secret store. Applying the same idea to a multi-party wire protocol that must interoperate with twenty-five years of installed identity-sync tooling is a different engineering problem at a different scale. Microsoft has not committed to it.

Key idea: The replication attack class is structurally permanent. The honest defender response is detection-and-response, not prevention.

This is the article's humility moment. The reader who arrived at §5 thinking "this is fixable" should now understand why eleven years of attack/defense iteration have produced detection layers, not protocol revisions. The four-layer detection architecture is not a placeholder while we wait for Microsoft to ship the real fix. It is the real fix, conditional on the constraint that the protocol's job description does not change.

If the protocol is structurally unfixable, what exactly does 2026 still not solve operationally?

9. What 2026 Still Cannot Do

Five problems sit on the open-questions register in 2026. Each is documented in the literature. None has a satisfying answer.

The DCShadow gap window. MDI's External ID 2029 alert fires on the rogue DC's replication request, which is structurally after the rogue nTDSDSA registration has been committed. The alert documentation describes the detection as firing after the fact [@mdi-alerts-classic]. An attacker who completes the register-replicate-deregister cycle inside the alert's batch interval commits the persistence write before any SOC responder sees the alert. External ID 2028 (rogue promotion) fires earlier in the kill chain and partially closes the gap, but the gap is structural to the alert-batch model. The directory write that DCShadow lands -- a SID-history injection, an AdminSDHolder ACE re-grant -- survives the alert.

Encrypted-channel DCSync. DRSUAPI clients that negotiate AUTH_LEVEL_PKT_PRIVACY on the RPC binding (the modern hardened-DC default) encrypt the request and response bodies on the wire. Passive NDR sensors that depend on parsing the IDL_DRSGetNCChanges request to determine which principal is being targeted lose per-principal granularity.

The interface-bind packet is still in clear, so the existence of a DRSUAPI call is still visible, but the payload is not. The Microsoft channel-binding rollout that began in late 2023 (targeting LDAP rather than DRSUAPI, but cementing the broader trend toward encrypted directory traffic) makes this gap permanent on the wire side [@microsoft-ldap-channel-binding-kb4520412]. Detection moves into the DC itself via the MDI sensor model.

The legitimate-principal-compromise non-detection. A hijacked Domain Admin session that uses its rightful DCSync ability triggers no layer. The posture layer sees a default principal. The behavioral layer sees a request from a DC or admin workstation that the Replication Allow List baseline accepts. The network layer sees the same. The graph layer sees the principal as a default Tier Zero member. The MDI alert is explicit: the trigger is "a computer that isn't a domain controller" -- a compromised legitimate principal acting from a legitimately-baselined workstation does not fire it [@mdi-alerts-classic].

This is the failure mode that catches mature SOCs. The attacker who already has Domain Admin does not need to attack DCSync detection because DCSync detection is not designed for legitimate principal abuse. UEBA-style per-principal anomaly detection ("this DA has not run DCSync in 90 days; this DA running DCSync at 03:00 from a workstation it has not used before is anomalous") is the partial answer. No production product currently delivers it with low enough false-positive rates to be operationally useful for already-Tier-Zero principals.

Cross-forest replication abuse is under-instrumented. The interaction of DS-Replication-Get-Changes-In-Filtered-Set with the SPN-suffix routing matrix in multi-forest environments is poorly covered in public detection guidance. Large enterprises with M&A history hold dozens of trusts; the cross-trust edges are the least-audited surface in their identity architecture. BloodHound's SharpHound collector can enumerate cross-trust data, and v6.0's wildcard-principal fix improves the picture, but no fully automated detection pattern exists [@bloodhound-v6-0-release-notes].

Delegation-drift residual long tail. Even with the MDI Accounts security posture assessment perfectly tuned, the long tail of forgotten ACE delegations across a twenty-five-year-old forest with mergers, acquisitions, decommissioned products, and migrations remains the canonical entry point. Christopher Keim frames it unambiguously [@keim-dcsync-rights]:

"The defaults aren't the problem. The problem is delegation drift, backup agents, identity sync products, and application service accounts accumulate these rights over time, often with no documentation and no review." -- Christopher Keim, *"DCSync Attack: Finding and Fixing Replication Rights in Active Directory"* (2025) [@keim-dcsync-rights]

The posture-layer detection is necessary but not sufficient; the human-process loop -- documented ownership, periodic review, removal of unjustified ACEs -- is what closes the residual. Most enterprise SOCs are not staffed to run this loop at the cadence the residual requires.

Open problem	Why it matters	Current best partial result
DCShadow gap window	Persistence write commits before SOC sees the alert	Configure MDI to surface External ID 2028 (rogue promotion) with automated investigation and response to block RPC traffic from the suspected source [@mdi-credential-access-alerts]
Encrypted-channel DCSync	Passive NDR loses per-principal granularity	Hybrid deployment: NDR for cross-DC visibility, MDI on-DC sensor for per-principal granularity [@trellix-silent-domain-hijack]
Legitimate-principal compromise non-detection	The Tier Zero principal who already has DCSync rights triggers nothing	Reduce the count of DCSync-capable principals to a number a human can monitor; surface their DCSync activity to a high-severity review queue
Cross-forest replication abuse	Cross-trust DCSync paths are not enumerated by default	SharpHound trust-collection methods; manual BloodHound inspection of foreign-domain principals
Delegation-drift residual long tail	Posture surfaces the principals; humans still have to decide which are legitimate	Quarterly posture review with documented justification per non-default principal

What can a defender actually do on Monday morning, given all of the above?

10. What a Defender Does on Monday Morning

Three action lanes, in priority order.

Lane 1: inventory the rights triad

Read the Domain NC root's ACL. Filter on the three rights GUIDs. Subtract the four default principal sets plus any legitimately delegated identity-sync product (Entra ID Connect's MSOL_ account is the canonical exclusion). Every entry that remains gets a documented owner and a documented justification, or the ACE gets removed.

Operator-facing inventory script. The browser-runnable demo uses a hardcoded SAMPLE_ACL; in production, replace the SAMPLE_ACL with output from one of: PowerShell: Get-Acl "AD:$( (Get-ADDomain).DistinguishedName )" python-ldap: ldap_search(ncroot_dn, attr='nTSecurityDescriptor')

DEFAULT_OK = { 'BUILTIN\\Administrators', 'CONTOSO\\Domain Controllers', 'CONTOSO\\Domain Admins', 'CONTOSO\\Enterprise Admins', 'NT AUTHORITY\\ENTERPRISE DOMAIN CONTROLLERS', }

MSOL_ accounts: legitimate Entra ID Connect sync principals. Exclude by prefix, never by exact name (the suffix is random).

def is_known_legitimate(principal): return principal in DEFAULT_OK or '\\MSOL_' in principal

SAMPLE_ACL = [ {'principal': 'CONTOSO\\Domain Admins', 'right': GET_CHANGES_ALL}, {'principal': 'CONTOSO\\MSOL_a1b2c3d4', 'right': GET_CHANGES_ALL}, {'principal': 'CONTOSO\\backup_svc_2017', 'right': GET_CHANGES_ALL}, {'principal': 'CONTOSO\\hr_idm_connector', 'right': GET_CHANGES}, {'principal': 'CONTOSO\\fileserver_old$', 'right': GET_CHANGES_ALL}, ]

findings = [] for ace in SAMPLE_ACL: if ace['right'] not in TRIAD: continue if is_known_legitimate(ace['principal']): continue findings.append(ace['principal'])

print("Principals to investigate:") for p in sorted(set(findings)): print(f" - {p} -> document owner or remove ACE") `}

Anything in the Principals to investigate output is either a legitimately delegated service (document the owner and add to your exclusions; treat as Tier Zero) or a forgotten ACE from a project nobody remembers (remove it). Christopher Keim's framing is the operationally useful one: every common culprit is a backup tool, an identity-governance tool, or a service account from a long-dead migration [@keim-dcsync-rights].

The Microsoft Entra ID Connect synchronization service account, created on-premises during Entra Connect installation with an `MSOL_` prefix and a random hex suffix, legitimately holds the rights triad on the Domain NC root. It must -- it has to replicate password hashes to the cloud directory so that Entra ID can validate cloud logons against on-premises credentials. Removing its ACE breaks Entra ID password hash sync within a single replication interval, and your help desk will know about it.

The right answer is not to remove the ACE. It is to treat the MSOL_ account as Tier Zero. Dedicated host (the Entra Connect server itself, hardened as a DC-tier asset). No interactive logon. Multi-factor authentication on any privileged use. Conditional access policies that block sign-in from anything other than the Entra Connect service identity. The MDI Hybrid security posture-assessment family documents the surrounding controls [@mdi-security-posture-hybrid].

Lane 2: enable the canonical alerts and audit

Three configuration items.

First, ensure Microsoft Defender for Identity (or an equivalent identity-threat-detection product) is deployed with a sensor on every DC. The un-sensored-DC gap that the MDI alert documentation explicitly warns about creates a structural blind spot that an attacker will preferentially target [@mdi-alerts-classic].

Second, enable Advanced Security Audit policy Audit Directory Services Access under DS Access and apply SACLs on the Domain NC root that audit the three replication rights against Everyone, Domain Computers, and Domain Controllers. This is what makes Event ID 4662 fire on the request, which is what the Sigma 611eab06 and Splunk 51307514 rules consume [@sigma-rule-dcsync][@splunk-research-dcsync]. A fresh-install AD does not have these SACLs by default; the most common reason a SIEM dashboard for DCSync is silent is that the SACL never got applied.

Third, deploy or configure NDR coverage on the inter-DC subnet, with a rule that fires on DRSUAPI bind requests originating from source IPs outside the legitimate-DC baseline. Trellix NDR, Microsoft's MDI sensor, CrowdStrike Falcon, and community Zeek/Suricata rulesets all implement this [@trellix-silent-domain-hijack]. Where commercial NDR is out of budget, Sysmon with the SwiftOnSecurity or Olaf Hartong modular configuration surfaces Event ID 3 (NetworkConnect) and Event ID 22 (DnsQuery) outbound from non-DC hosts to DC RPC endpoints; a SIEM correlation rule can combine this endpoint-side signal with Event ID 4662 on the DC to approximate the network-plus-host signature without an appliance budget.

Lane 3: run BloodHound on the domain quarterly

Collect with SharpHound at minimum quarterly. Continuous collection if BloodHound Enterprise is available. Run the canonical query for the DCSync edge into the domain node. Trace inbound paths. Close the longest path first -- the longest paths are the ones a human operator is least likely to have noticed and most likely to have been delegated decades ago for a reason nobody remembers.

The v6.0 wildcard-principal fix is particularly worth a re-run on any forest that has been operated since before 2003: legacy Authenticated Users or Everyone ACEs on the domain root are exactly the kind of thing that survived a Server 2003 upgrade silently and never showed up in any subsequent audit [@bloodhound-v6-0-release-notes]. The v6.3 Butterfly algorithm lets you query the inverse view -- which targets fall if this principal is compromised? -- which is the right question to ask about any newly-discovered non-default DCSync holder [@specterops-butterfly-blog][@bloodhound-v6-3-release-notes].

What does not work

Four common misbeliefs are worth naming.

Note: See §1 -- Credential Guard does not stop DCSync. The secret transits remote-to-remote (a DC's NTDS.dit to the attacker's process), never local-to-LSASS, so the trustlet's isolation boundary has no jurisdiction over the call [@credential-guard-considerations]. Credential Guard is the right control for the local-memory attack surface and the wrong control for the network-protocol attack surface.

Note: After a confirmed DCSync of krbtgt, rotate the krbtgt account password twice, with at least ten hours between rotations. The first rotation invalidates the old key after the current Kerberos ticket lifetime expires. The second rotation invalidates the previous old key, which the directory stores alongside the current key for compatibility during replication convergence. Rotating only once leaves Golden Tickets forged from the dumped key valid for the duration of the second key. Rotating twice ten hours apart is what closes the window [@microsoft-new-krbtgtkeys]. (And neither rotation removes the ACE that allowed the dump in the first place: come back to Lane 1.)

Renaming krbtgt does nothing. The account's Relative Identifier (RID 502) is fixed by AD's design and is what the TGT signing key derives against, not the sAMAccountName [@microsoft-well-known-sids]. Renaming it to krbtgt-old-do-not-use confuses operators, not attackers.

Disabling MS-DRSR is not an option. The protocol is what makes AD replication work. Blocking opnum 3 at the RPC layer or refusing the DRSUAPI bind stops DCSync and stops every DC in the forest from talking to every other DC. Replication grinds. Password changes do not propagate. Domain joins fail. Within hours, the directory is split-brain across DCs, and within days, it is unrecoverable without DR-grade restore from backup: Microsoft's own AD-replication troubleshooting documentation walks the lingering-object pathology that produces exactly this split-brain when DCs stop replicating for longer than the tombstone lifetime [@microsoft-ad-lingering-objects].

On any DC, run `auditpol /get /subcategory:"Directory Service Access"` from an elevated prompt. If the output reads `No Auditing`, your Sigma / Splunk SACL-event detection will not fire because Event ID 4662 is not being generated. Enable with `auditpol /set /subcategory:"Directory Service Access" /success:enable /failure:enable`, then apply the SACL on the domain root as described in the Splunk rule's implementation notes [@splunk-research-dcsync].

The six FAQ items in the next section cover the misconceptions that did not fit into any single lane.

11. Frequently Asked Questions

No. The access check on `IDL_DRSGetNCChanges` requires both the baseline `DS-Replication-Get-Changes` right *and* `DS-Replication-Get-Changes-All` to read secret attributes [@ad-schema-get-changes][@ad-schema-get-changes-all]. The *All* suffix unlocks the secret attribute set given the baseline right; it is not a self-sufficient gate. Christopher Keim's PowerShell pattern filters on both GUIDs together [@keim-dcsync-rights]. Confidential-flag attributes additionally require `DS-Replication-Get-Changes-In-Filtered-Set`. Some detection rules (Sigma 611eab06 included) accept either GUID in the SACL event because the operational cost of a false positive on the broader filter is lower than the risk of missing one of the two required ACEs being present without the other [@sigma-rule-dcsync]. No. Credential Guard isolates LSASS-resident secrets in a separate virtual trust level so that local-memory attacks (Mimikatz `sekurlsa::logonpasswords`, comsvcs.dll mini-dumps of `lsass.exe`, and similar) cannot read cached credentials. DCSync does not touch the attacker's LSASS at all. The secret transits from a remote DC's NTDS.dit, over an encrypted MS-DRSR session, into the attacker's process memory. Microsoft's Credential Guard documentation lists the scenarios Credential Guard does and does not cover; MS-DRSR-based network credential extraction is not in scope [@credential-guard-considerations]. This is one of the clearest examples in the Windows security model of a control that is right for one attack surface and orthogonal to another. Not anymore. The BlueHat IL 2018 "your million-dollar SIEM goes blind" framing was correct in 2018 against SIEMs that monitored only object-modification events: the replication writes are SACL-silent. By July 24, 2018, Tali Ash announced Azure ATP's two new preview detections, which fired on the rogue-DC promotion fingerprint (creating an `nTDSDSA` object in the Configuration NC) and the replication request from the rogue, respectively [@tali-ash-azure-atp-dcshadow]. Those detections carried forward as Microsoft Defender for Identity External IDs 2028 and 2029 [@mdi-alerts-classic]. The writes themselves remain SACL-silent; the *registration* fingerprint that has to precede them is not. The honest contemporary statement is "DCShadow's writes are silent, but the rogue-DC scaffolding is not, and a sensored DC catches the scaffolding." A skilled attacker who completes the register-replicate-deregister cycle inside the alert batch interval may still commit the persistence write before SOC response. No. The protocol's design is the issue. Microsoft has not announced any MS-DRSR amendment that would change the `IDL_DRSGetNCChanges` access check, because amending the access check breaks legitimate non-DC consumers (the Entra ID Connect MSOL_ account is the most prominent) and shifts the attack class to compromised DC machine accounts (Zerologon is the worked example [@secura-zerologon-whitepaper]). The "fixes" that have shipped since 2015 are all detection: ATA 1.7 (April 2017) [@ata-v17-release-notes], Azure ATP (2018) [@tali-ash-azure-atp-dcshadow], Microsoft Defender for Identity (post-Ignite 2020 rebrand) [@rcpmag-defender-rebrand][@mdi-whats-new], and the posture-assessment families that surface non-default rights triad holders [@mdi-security-posture-accounts]. The protocol itself is the same protocol it was in Windows 2000 Server. The MSOL_ sync account legitimately holds the rights triad on the Domain NC root because it must replicate password hashes to Entra ID. Treat it as Tier Zero with the hardening profile listed in §10's MSOL_ Aside (dedicated hardened host, no interactive logon, MFA on privileged use, conditional access restricted to the Entra Connect service identity) [@mdi-security-posture-hybrid]. Critically, do *not* remove the ACE from the Domain NC root: doing so breaks Entra ID password hash sync within one replication interval, and your help desk will know about it within hours. No. DCSync is over DRSUAPI/MS-DRSR, not over LDAP. The directory's LDAP service refuses to return `unicodePwd` and related secret-attribute values regardless of caller privilege, because the attribute is marked confidential and the LDAP read path does not honor the replication extended rights. There is no "DCSync over LDAP" technique because LDAP simply does not return the data; MITRE T1003.006 names DRSUAPI explicitly as the protocol vector [@mitre-t1003-006]. Operators occasionally confuse this with LDAPS (LDAP over TLS) or with the November 2023 LDAP signing and channel-binding rollout, both of which are channel-protection concerns rather than credential-read concerns.

A final observation, since the closing should add something new. The protocol that this article calls structurally unfixable is not unusual. Most Microsoft security primitives that survive long enough enter the same regime -- the LSASS surface, the Kerberos delegation surface, the SMB authentication surface -- where the only honest answer is detection in depth because the protocol's job description and its abuse surface are the same surface viewed from different chairs.

The thing that makes MS-DRSR notable is the clarity with which the structural error is visible. Read §4.1.10 once and you are done. Everything from §6 onward is the industry's slow accumulation of detection layers around a gate that cannot be moved. Twenty-five years in, the gate is still where it was on February 17, 2000, and the four layers around it are still under active engineering.

Kerberos in Windows: The Other Half of NTLMless

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

**Kerberos was a 1988 protocol that solved one problem: mutual authentication on an untrusted network using a trusted third party.** Then it got piled on for thirty-three years. In 2026 NTLM is being switched off, the AS-REQ / AS-REP / TGS-REQ / TGS-REP skeleton is finally the single load-bearing authentication path for Windows, and the eleven attack primitives that exposed every joint of that skeleton between 2014 and 2022 are still mostly fixable by configuration, not by protocol. This is the companion to [NTLMless](/blog/ntlmless-the-death-of-ntlm-in-windows/): what happens to the protocol that takes over.

1. A Chain Without NTLM

Imagine a defender who has done every NTLM retrofit Microsoft has shipped. NTLM is disabled by default on the workstations. RestrictNTLMInDomain is on at the domain controller. SMB signing is enforced. Extended Protection for Authentication is set on every IIS endpoint. ESC8 has been patched. The defender has read the NTLMless post and ticked every box.

A low-privileged user on that network opens a PowerShell prompt. They run Powermad to create a fresh computer account. The default MachineAccountQuota is still 10, which means any authenticated domain user can create up to ten computer objects in Active Directory by design [@shenanigans-rbcd]. They then write a single LDAP attribute, msDS-AllowedToActOnBehalfOfOtherIdentity, on a target file server they have any write permission against. They ask the Key Distribution Center for a service ticket via Rubeus s4u, present that ticket to the target file server, and walk in as Administrator. Total elapsed time: less than this paragraph. Total NTLM in the chain: zero.

Note: The post-NTLM Resource-Based Constrained Delegation chain depends on three properties of Kerberos that are features, not bugs: (a) the default MachineAccountQuota = 10 setting on every fresh Active Directory forest, (b) the S4U2Proxy guarantee that always produces a forwardable TGS even when the input ticket was not forwardable, and (c) the absence of any KDC-side check on whether the requesting principal is a "trusted delegator". All three are documented behaviours of the protocol. None of them is a CVE [@shenanigans-rbcd].

The chain has a name and a primary disclosure: Elad Shamir's "Wagging the Dog" post on shenaniganslabs.io, January 28, 2019 [@shenanigans-rbcd]. The weaponised tooling is GhostPack's Rubeus, the C# Kerberos toolset that ships ready-made commands for s4u, asktgt, kerberoast, and diamond [@ghostpack-rubeus]. The single-line elevation wrapper that splices together Powermad, KrbRelay, Rubeus, and an SCM bypass is KrbRelayUp, published by Mor Davidovich ("Dec0ne") on April 24, 2022; its README scopes itself as a universal no-fix local privilege escalation in Windows domain environments where LDAP signing is not enforced (and that is the default) [@krbrelayup].

sequenceDiagram participant U as Low-priv user participant DC as Domain Controller / KDC participant T as Target file server U->>DC: Powermad: create machine account FAKE (machine account) U->>DC: LDAP write set RBCD attribute on T to allow FAKE U->>DC: AS-REQ for FAKE -> TGT U->>DC: S4U2Self as Administrator (non-forwardable TGS returned) U->>DC: S4U2Proxy with TGS returns forwardable TGS for cifs on T U->>T: AP-REQ presenting Administrator TGS T->>U: SYSTEM access on T

Read the chain twice. The first read shows that every step is a documented Kerberos exchange. The second read shows that removing NTLM did nothing to it. Restrict-NTLM, EPA, SMB signing, ESC8 -- the entire NTLM-retrofit catalogue has no edge against a Kerberos-only attack path that uses S4U2Self, S4U2Proxy, and the Resource-Based Constrained Delegation attribute exactly as Microsoft documented them in [@ms-kerberos-overview].

This is the article's load-bearing thesis. Removing NTLM did not remove the attack surface; it shifted the attack surface onto a protocol that is also thirty-three years old, also retrofitted, and now also the only load-bearing one. In October 2023, Matthew Palko, Microsoft's Principal Group Product Manager for Windows authentication, wrote the post that committed Microsoft publicly to deprecating NTLM and named the Kerberos features that would replace it [@ms-palko-evolution]. The NTLMless companion article walked through the NTLM-side mechanics of that transition. This one walks through the Kerberos side.

The question that drives everything that follows is the question the chain above forces: how did Windows arrive at a state where the most catastrophic post-NTLM Active Directory attack chain depends on Kerberos working exactly as the 1989 designers intended?

2. Origins: Needham, Schroeder, Athena, and 1988

Kerberos is not new engineering. The story of Windows authentication in 2026 starts with two Xerox PARC researchers and a 1978 paper in Communications of the ACM.

In December 1978, Roger M. Needham and Michael D. Schroeder published "Using Encryption for Authentication in Large Networks of Computers" in CACM 21(12), pages 993 to 999 [@needham-schroeder]. The paper is paywalled on the ACM Digital Library, but RFC 4120's own Background section names it as the parent protocol [@rfc4120] and the Wikipedia article on the Needham-Schroeder protocol preserves the message structure verbatim [@wiki-needham-schroeder]. The symmetric-key version of that protocol is five messages long, and it is the structural blueprint of every "ticket from a trusted third party" design that followed.

$$A \to S:\ A, B, N_A$$ $$S \to A:\ {N_A, K_{AB}, B, {K_{AB}, A}{K{BS}}}{K{AS}}$$ $$A \to B:\ {K_{AB}, A}{K{BS}}$$ $$B \to A:\ {N_B}{K{AB}}$$ $$A \to B:\ {N_B - 1}{K{AB}}$$

A and B are the principals; S is the trusted third party; K_AS and K_BS are pre-shared long-term keys; K_AB is the session key that S mints for the conversation; N_A and N_B are nonces. The "ticket" is the part of the third message that A cannot decrypt and just forwards to B. That structure -- a server-issued cryptographic envelope intended for somebody else and opaque to the carrier -- is what becomes the Kerberos TGS thirty-eight years later.

Three years later, in August 1981, Dorothy Denning and Giovanni Maria Sacco published "Timestamps in Key Distribution Protocols" in CACM 24(8), 533-536. The paper is also paywalled on dl.acm.org, but the Wikipedia secondary preserves the finding: the Needham-Schroeder symmetric protocol is vulnerable to a replay attack if an attacker recovers an old session key [@wiki-needham-schroeder]. Denning and Sacco proposed timestamps as the fix. This is the structural reason every Kerberos ticket carries a timestamp and every Kerberos network requires a synchronised time service today.

A Kerberos administrative boundary, written in uppercase like `CONTOSO.COM`, that scopes a set of principals (users, services, computers) sharing a single Key Distribution Center. Every Kerberos ticket names the issuing domain in its `EncTicketPart.crealm` and `EncTicketPart.cname` fields. Active Directory binds one Kerberos domain to one AD forest root by default [@ms-kerberos-overview].

Between 1983 and 1991, MIT Project Athena -- the joint MIT, DEC, and IBM campus computing effort led by Jerome Saltzer -- needed a working authentication service for a distributed workstation network running over a hostile campus LAN. The Athena Technical Plan Section E.2.1, "Kerberos Authentication and Authorization System" [@mit-athena-plan], is the canonical internal design document. Steve Miller and Clifford Neuman did the protocol work; Jeffrey Schiller ran the network operations.

In February 1988, MIT published two complementary artefacts. Bill Bryant wrote "Designing an Authentication System: a Dialogue in Four Scenes" -- a pedagogical script in which an engineer named Athena designs her way step by step from "users type their password to every server" to "users obtain time-limited tickets from a trusted third party". Bryant's dialogue is the most cited pre-protocol document about why Kerberos exists in the shape it does [@mit-dialogue]. The same month, Jennifer Steiner, Clifford Neuman, and Jeffrey Schiller presented "Kerberos: An Authentication Service for Open Network Systems" at the USENIX Winter Conference in Dallas [@cerias-steiner1988]. The protocol that paper described -- later called Kerberos version 4 -- carried forward to v5 with ASN.1 encoding, extensibility hooks, and pre-authentication, but the AS / TGS / AP message-triple skeleton it specified is unchanged thirty-eight years later.

On January 24, 1989, MIT shipped the first public release of Kerberos v4 [@wiki-kerberos]. Five years later, in September 1993, the IETF adopted Kerberos v5 as RFC 1510 [@rfc1510]. RFC 1510 added ASN.1 encoding, cross-domain trust, and an extensibility hook called PA-DATA that every Kerberos extension since has used. In July 2005, RFC 4120 replaced RFC 1510 as the Kerberos v5 standard [@rfc4120].

sequenceDiagram participant C as Client participant AS as Authentication Service participant TGS as Ticket-Granting Service participant S as Application Server C->>AS: AS-REQ: identify yourself AS->>C: AS-REP TGT encrypted to TGS, session key wrapped under client long-term key C->>TGS: TGS-REQ: present TGT, ask for service ticket TGS->>C: TGS-REP service ticket encrypted to S, session key wrapped under TGT session key C->>S: AP-REQ: present service ticket S->>C: AP-REP: mutual auth confirmation

Kerberos in 2026 is the same protocol as Kerberos in 1988, with thirty-three years of extensions piled on top. The skeleton you draw on a whiteboard for a graduate seminar is exactly the skeleton a Windows 11 24H2 machine throws at a 2025 domain controller. The interesting question is what those thirty-three years of extensions did to the inside of every message.The default maximum clock skew between client and KDC in Windows Kerberos is five minutes (300 seconds), set by Group Policy "Maximum tolerance for computer clock synchronization" and documented in [@ms-kerberos-overview]. The five-minute window is the residue of Denning and Sacco's 1981 timestamp fix.

3. The Wire in 2026: Six Messages and an Encryption Matrix

Every Kerberos textbook draws the same six-message diagram you saw in Section 2. The diagram has been unchanged since 1988. What is different in 2026 is everything inside the messages.

Look first at the AS-REQ. In raw RFC 4120 the AS-REQ carries a req-body (client name, target name, requested lifetime, requested enctypes) and an optional padata field [@rfc4120]. That padata slot is the load-bearing extensibility hook of the entire protocol. Every Kerberos enhancement since 1993 has been a new PA-DATA type: PA-ENC-TIMESTAMP (the encrypted-timestamp pre-auth blob), PA-PK-AS-REQ (PKINIT [@rfc4556]), PA-FX-FAST-REQUEST (FAST armoring [@rfc6113]), PA-AS-FRESHNESS (PKINIT freshness [@rfc8070]). The skeleton survives only because the joints are extensible.

A `SEQUENCE OF { padata-type, padata-value }` field in the Kerberos AS-REQ and AS-REP messages, introduced in RFC 1510 (1993) and carried forward unchanged into RFC 4120 §5.2.7 (2005). PA-DATA is the only protocol-level hook by which a Kerberos client can prove possession of a credential before the KDC issues a Ticket-Granting Ticket, and the only hook by which an enhancement like FAST or PKINIT can attach new behaviour to the AS exchange without breaking compatibility with older clients [@rfc4120].

The AS-REP returns the TGT. The TGT itself is encrypted under the TGS's long-term key, so the client cannot inspect it. What the client can inspect is the EncTicketPart flag bitfield wrapped in the TGT envelope. RFC 4120 §2 enumerates the ticket-flag positions, including forwardable, proxiable, postdated, renewable, initial, pre-authent, hw-authent, transited-policy-checked, and ok-as-delegate [@rfc4120]. (may-postdate looks like a sibling but is a KDCOptions request bit per RFC 4120 §5.4.1, not a TicketFlags bit.) Pay attention to forwardable. In 2020, Jake Karnes of NetSPI demonstrated that an attacker who knew a service account's long-term key could decrypt the S4U2Self output ticket, set forwardable = 1, re-encrypt, and feed the ticket back to the KDC's S4U2Proxy step. The KDC accepted it. The bypass is CVE-2020-17049 and the attack is called Bronze Bit [@cve-2020-17049] [@netspi-bronze-bit].

Inside the ticket's AuthorizationData field is the Microsoft-specific construction that turns Kerberos into a Windows authorisation system. The Privilege Attribute Certificate, defined in [MS-PAC] revision 26.0 [@ms-pac-overview] [@ms-pac-deeplink], carries the user's SID, their group SIDs, their logon name, timestamps, and three cryptographic signatures: a Server signature, a KDC signature, and -- since CVE-2022-37967 in November 2022 -- a Full PAC Signature that covers the entire encoded PAC structure instead of just the existing signatures [@cve-2022-37967].

A Microsoft-specific authorization data element that the Kerberos KDC attaches to every ticket it issues for a Windows principal. The PAC carries the user's SID, group SIDs, logon name, and timestamps, and is signed by the KDC's `krbtgt` key and by the target service's key. The PAC, not the Kerberos ticket itself, is what gives a Windows file server the access-control information it needs to make a permission decision. Defined in [MS-PAC] [@ms-pac-overview]. The KB article URL ends in `cve-2022-37967` and the body text begins by referring to "CVE-2022-37966". This is not a typo in the citation -- it is a Microsoft filing artefact. November 2022 Patch Tuesday paired two Kerberos CVEs: CVE-2022-37967 (Full PAC Signature, KrbtgtFullPacSignature) and CVE-2022-37966 (default session-key encryption type). KB5021131 covers the deployment of the encryption-type bypass side. A sibling article, KB5020805, covers the Full PAC Signature side. When citing KB5021131 alongside the Full PAC Signature, both CVE numbers are relevant [@ms-kb-5021131] [@cve-2022-37967].

Then there is the encryption matrix. Kerberos abstracts ciphers behind the RFC 3961 framework [@rfc3961], which defines an enctype as a tuple of (encrypt, decrypt, checksum, string-to-key, key-derivation) functions. The history of Windows Kerberos is the history of which enctypes were the default at any given time.

Enctype	Number	Spec	Status in 2026
DES-CBC-CRC	1	RFC 3961 [@rfc3961]	Disabled by default since Server 2008 R2 [@ms-kile-227]
DES-CBC-MD5	3	RFC 3961 [@rfc3961]	Disabled by default since Server 2008 R2 [@ms-kile-227]
RC4-HMAC	23	RFC 4757 [@rfc4757]	Informational, not Standards Track; default-removed in mid-2026 per [@ms-beyond-rc4]
AES-128-CTS-HMAC-SHA1-96	17	RFC 3962 [@rfc3962]	Default since Server 2008; cross-version compatible
AES-256-CTS-HMAC-SHA1-96	18	RFC 3962 [@rfc3962]	Default since Server 2008; the mid-2026 destination
AES-128-CTS-HMAC-SHA256-128	19	RFC 8009 [@rfc8009]	Specified in [MS-KILE] bit K [@ms-kile-227]; no default-enable timeline
AES-256-CTS-HMAC-SHA384-192	20	RFC 8009 [@rfc8009]	Specified in [MS-KILE] bit L [@ms-kile-227]; no default-enable timeline

Enctype 23 is the row that built every Kerberoasting career. Kannan Jaganathan, Larry Zhu, and John Brezak of Microsoft published RFC 4757 in December 2006 [@rfc4757]. The IESG note on the RFC is unusually candid: the document is Informational, not Standards Track, because RC4-HMAC "do[es] not provide all the required operations in the Kerberos cryptography framework [RFC 3961]" and because of "security concerns with the use of RC4 and MD4". The choice that made enctype 23 dangerous, however, was upstream of the RFC. To make Windows 2000's Kerberos rollout backward-compatible with the existing SAM password database, Microsoft set the RC4-HMAC long-term Kerberos key equal to the NT hash of the user's password -- the same hash NTLM was already storing. As Microsoft's own October 2024 Kerberoasting guidance puts it verbatim: "RC4 is more susceptible to the cyberattack because it uses no salt or iterated hash when converting a password to an encryption key" [@ms-kerberoasting-guidance].

The function that converts a typed password into a Kerberos long-term symmetric key. For RC4-HMAC (enctype 23), `s2k(password) = MD4(UTF-16-LE(password))` -- the NT hash, no salt, no iteration. For AES-CTS-HMAC-SHA1-96 (enctypes 17 and 18), `s2k(password, salt) = PBKDF2-HMAC-SHA1(password, salt, 4096, dklen)` followed by RFC 3962 post-processing into a 128- or 256-bit AES key. The salt is the concatenation of the Kerberos domain name and the user principal name [@rfc3962].

The cryptography in that definition is short enough to read end-to-end. Here it is in JavaScript using the Web Crypto API:

{` async function kerberosStringToKey256(password, salt) { const enc = new TextEncoder(); const passKey = await crypto.subtle.importKey( "raw", enc.encode(password), { name: "PBKDF2" }, false, ["deriveBits"] ); const rawBits = await crypto.subtle.deriveBits( { name: "PBKDF2", salt: enc.encode(salt), iterations: 4096, hash: "SHA-1", }, passKey, 256 ); const hex = [...new Uint8Array(rawBits)] .map((b) => b.toString(16).padStart(2, "0")) .join(""); return hex; }

const password = "Summer2026!"; const salt = "CONTOSO.COMalice"; const keyHex = await kerberosStringToKey256(password, salt); console.log("PBKDF2-HMAC-SHA1 output (truncated AES-256 key):", keyHex); `}

That 32-byte output is the value LSA stores when an account is configured with msDS-SupportedEncryptionTypes bit E set. When a Kerberoasting attacker steals the TGS-REP, what they crack offline is which password produces that key. The RFC 3962 post-processing -- a single round of DK(key, "kerberos") -- shapes the output to AES key length but does not slow the dictionary attack down. The dispositive defence is not in the cryptography; it is in the password (or, more precisely, in not having one at all -- the move to gMSA and dMSA replaces typed passwords with KDC-generated random secrets [@ms-gmsa] [@ms-dmsa]). PBKDF2 at 4,096 iterations is well below modern PHC recommendations -- the 2023 OWASP guideline for PBKDF2-HMAC-SHA1 is 1.3 million iterations [@owasp-password-storage] -- but the 4,096 figure is wired into RFC 3962 and is the same on every supported Windows version. Service accounts using gMSA bypass this entirely: the gMSA's "password" is a 240-character random secret rotated every 30 days, derived by the Microsoft Key Distribution Service rather than entered by a human [@ms-gmsa].

The wire in 2026 is therefore six messages and a matrix of seven enctypes. The protocol skeleton is forty years old. In 2014 a SANS instructor named Tim Medin gave a forty-five-minute talk that turned every one of those enctypes into a problem.

4. The Attack Cascade: 2014 to 2022

September 26-28, 2014. Louisville, Kentucky. DerbyCon 4. Talk slot T120. Tim Medin -- then at Counter Hack Challenges, also a SANS instructor -- walks on stage with a forty-five-minute talk titled "Attacking Microsoft Kerberos: Kicking the Guard Dog of Hades" [@irongeek-derbycon4]. The talk demonstrates that any authenticated domain user can request a TGS for any Service Principal Name in the directory, and that the service-portion of the returned ticket is encrypted under the SPN account's long-term key -- which, under RC4-HMAC enctype 23, is the NT hash of the password. Cracking the ciphertext is reduced to a dictionary attack against whatever password an admin set on the service account.

That talk is the moment Kerberos becomes interesting to attackers. The next eight years play out as a cascade. Five generations, each one named after the canonical primitive that defined it, each one exposing a different structural property of the protocol, each one earning its own engineered Microsoft response years later.

A unique identifier for a service instance in Active Directory, written in the form `service-class/host:port/service-name` (for example `HTTP/web01.contoso.com`). Kerberos uses the SPN to look up which account holds the long-term key that decrypts the service ticket. Any account that has an SPN -- a user account that has had `setspn -A` run against it, every machine account in the directory, every gMSA -- is a candidate for Kerberoasting [@adsecurity-kerberoast].

Generation 1, 2014: Kerberoasting

Tim Medin's primitive [@irongeek-derbycon4]. Will Schroeder's PowerShell weaponisation as Invoke-Kerberoast (later rolled into the C# Rubeus) [@ghostpack-rubeus]. Sean Metcalf's operational walkthrough on adsecurity.org [@adsecurity-kerberoast]. MITRE catalogued the technique in 2020 as ATT&CK T1558.003, which preserves the structural definition verbatim: "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" [@mitre-t1558-003].

The structural insight is the part that matters. The TGS-REP is encrypted with the service account's long-term password-derived key, so any domain user who can issue a TGS-REQ can mine ciphertext offline against any dictionary they care to assemble. The Kerberos protocol has no mechanism by which the KDC could tell whether the requesting user has any business asking for that SPN, because RFC 4120 has no concept of "this service is for these users". Anyone with a TGT gets the service ticket.

Microsoft's engineered response did not arrive until ten to twelve years later. Server 2012 introduced Group Managed Service Accounts: passwords randomised to 240 characters, derived by the Microsoft Key Distribution Service via kdssvc.dll, rotated every 30 days, retrievable from a domain controller by member hosts that are explicitly authorised in msDS-GroupMSAMembership [@ms-gmsa]. Server 2025 then introduced Delegated Managed Service Accounts (dMSA), which take the next structural step: the dMSA's secret is "derived from the machine account credential" held by the domain controller, and "the secret can't be retrieved or found anywhere other than on the DC" [@ms-dmsa]. The October 2024 Microsoft Security Blog formalised the Kerberoasting guidance in a single page that names RC4 as the load-bearing weakness and announces the deprecation [@ms-kerberoasting-guidance]. The December 2025 Beyond-RC4 announcement closed the cadence with a calendar date [@ms-beyond-rc4].

Generation 2, 2014-2017: Mimikatz Kerberos and AS-REP Roasting

Benjamin Delpy publishes mimikatz 2.0 on April 6, 2014; the v2 banner inside the repository README reads verbatim mimikatz 2.0 alpha (x86) release "Kiwi en C" (Apr 6 2014 22:02:03) [@mimikatz]. The Kerberos module contains two commands that define the era: kerberos::golden (forge a TGT from the KRBTGT account's long-term key, granting Domain Admin equivalence indefinitely) and kerberos::silver (forge a TGS from any service account's long-term key, granting impersonation of any user against that service).

The structural insight: RFC 4120 has no online ticket validation [@rfc4120]. Once a ticket carries the right signatures, the service trusts it. Whoever holds a long-term key forges any ticket that key signs. Possession of a key collapses to ticket forgeability.

Around 2017, the same team behind Rubeus publicises AS-REP Roasting [@ghostpack-rubeus]: the same offline-cracking primitive as Kerberoasting, but against any account whose userAccountControl has UF_DONT_REQUIRE_PREAUTH (the DONT_REQ_PREAUTH flag) set. With pre-authentication disabled, the KDC will return an AS-REP encrypted under the user's password-derived key to anyone who asks for it, no proof of password possession required. The dispositive Microsoft response was already in place: pre-authentication has been required by default for all new Active Directory accounts since Windows 2000, and the flag has to be deliberately cleared by an administrator. The remaining vulnerability is operational hygiene -- finding the handful of legacy accounts an organisation has left with pre-auth disabled.

Generation 3, 2018-2020: Delegation Abuse

Three primitives in three years.

SpoolSample / PrinterBug. Lee Christensen (tifkin_, SpecterOps) published the PoC on GitHub on October 5, 2018 [@spoolsample]. The MS-RPRN remote-procedure-call interface includes a method, RpcRemoteFindFirstPrinterChangeNotificationEx, that any authenticated user can invoke against any host's spooler service to ask the spooler to please call back to an attacker-controlled address. The spooler obediently authenticates outbound using the machine account's credentials. Combined with unconstrained Kerberos delegation on the attacker-controlled host, the inbound authentication captures the target machine's TGT.

Wagging the Dog (RBCD). Elad Shamir's January 28, 2019 post on shenaniganslabs.io [@shenanigans-rbcd]. The TL;DR of the post is the load-bearing structural disclosure: "Resource-based constrained delegation does not require a forwardable TGS when invoking S4U2Proxy. S4U2Self works on any account that has an SPN, regardless of the state of the TrustedToAuthForDelegation attribute. S4U2Proxy always produces a forwardable TGS, even if the provided additional TGS in the request was not forwardable. By default, any domain user can abuse the MachineAccountQuota to create a computer account and set an SPN for it, which makes it even more trivial to abuse resource-based constrained delegation to mimic protocol transition" [@shenanigans-rbcd]. Every clause of that TL;DR points at a documented behaviour. The chain in this article's Hook is built directly on top.

Bronze Bit. Jake Karnes at NetSPI; CVE-2020-17049; disclosed November 10, 2020 [@netspi-bronze-bit] [@cve-2020-17049]. The NVD entry preserves Microsoft's verbatim description: "A security feature bypass vulnerability exists in the way Key Distribution Center (KDC) determines if a service ticket can be used for delegation via Kerberos Constrained Delegation (KCD). To exploit the vulnerability, a compromised service that is configured to use KCD could tamper with a service ticket that is not valid for delegation to force the KDC to accept it" [@cve-2020-17049]. The bypass: any service in possession of its own long-term key can decrypt the S4U2Self output ticket, flip the forwardable bit in EncTicketPart, and re-encrypt with the same key. Pre-2020 the KDC's S4U2Proxy validation accepted the resulting ticket because nothing on the ticket independently attested whether the forwardable flag had been set by the KDC or by the service itself. Microsoft's November 10, 2020 fix, per the NVD entry verbatim, "addresses this vulnerability by changing how the KDC validates service tickets used with KCD" so that the tampered flag is rejected [@cve-2020-17049]. The PAC signatures, contra a common framing, were never meant to cover the EncTicketPart flag bits in the first place.

Microsoft's engineered responses: the November 2020 Bronze Bit patch [@cve-2020-17049] tightened the KDC's S4U2Proxy ticket-validation step; KB5008383 (November 2021) [@ms-kb-5008383] issued the canonical "set ms-DS-MachineAccountQuota = 0 for non-administrator users" guidance; LDAP signing and channel binding work, ongoing since the NTLMless era, became the dispositive control against the relay variant of the chain.

Generation 4, 2021-2022: Certificate-Based Ticket Forgery and Kerberos Relay

Certifried. Oliver Lyak (ly4k) at IFCR disclosed CVE-2022-26923 to Microsoft, who patched on May 10, 2022 [@cve-2022-26923]. The attack exploited a quirk of how Active Directory Certificate Services (ADCS) bound a certificate's identity to an AD account when the certificate was used for PKINIT. Before the strong-mapping fix, AD's account-lookup at PKINIT time used the certificate's Subject Alternative Name (SAN) and matched the User Principal Name. If an attacker controlled a machine account, they could change the machine's dNSHostName to match a domain controller's, request a certificate via the (overly-permissive) default Machine template, and use the resulting certificate to PKINIT-authenticate to the KDC as that domain controller. Microsoft's response is documented end-to-end in KB5014754 [@ms-kb-5014754]: a new "strong certificate mapping" requirement that pins each issued certificate to a specific account SID via an X.509 extension (OID 1.3.6.1.4.1.311.25.2). The original release moved to Compatibility mode on May 10, 2022; full Enforcement mode took effect on February 11, 2025; Disabled-mode rollback was removed on April 11, 2023; the remaining Compatibility-mode fallback was removed on September 9, 2025 [@ms-kb-5014754].

KrbRelayUp. Mor Davidovich (Dec0ne), April 24, 2022 [@krbrelayup]. The README's universal-no-fix-LPE framing is preserved in the PullQuote below. The chain wraps Powermad (machine account creation), KrbRelay (Kerberos relay to LDAP), Rubeus (S4U2Self bypass of Protected Users, RBCD privilege addition), and SCMUACBypass (a wrapper that uses the resulting ticket to open the local Service Control Manager and create a service running as NT AUTHORITY\SYSTEM). The class of attack is "Kerberos relay" -- the post-NTLM cousin of NTLM-relay. The dispositive control is not a Kerberos patch; it is domain-wide LDAP signing plus channel binding plus Extended Protection for Authentication on ADCS Web Enrolment.

A universal no-fix local privilege escalation in windows domain environments where LDAP signing is not enforced (the default settings). -- Mor Davidovich, KrbRelayUp README, April 2022 [@krbrelayup]

Generation 5, 2022-2023: Forged-Ticket Sophistication

Diamond Ticket. Charlie Clark at Semperis co-authored a blog post in 2022 with Andrew Schwartz at TrustedSec disclosing the modern Diamond Ticket technique [@semperis-diamond] [@trustedsec-diamond]. The Semperis byline names the antecedent: a 2015 Black Hat EU presentation by Tal Be'ery and Michael Cherny ("Watching the Watchdog") that introduced the "Diamond PAC" idea. Verbatim from the Semperis post: "Golden Ticket attacks take advantage of the ability to forge a ticket granting ticket (TGT) from scratch, Diamond Ticket attacks take advantage of the ability to decrypt and re-encrypt genuine TGTs requested from a domain controller (DC)" [@semperis-diamond]. The structural insight is that a Diamond Ticket has a legitimately issued, KDC-signed PAC at its base; only the privilege-claim fields inside the PAC are tampered. Before the November 2022 Full PAC Signature fix, the existing Server and KDC signatures only covered specific sub-structures, leaving room to modify the parts they did not sign.

Sapphire Ticket. Charlie Bromberg, also known online as "Shutdown", at Synacktiv [@pgj11-diamond-sapphire] [@thehacker-recipes-sapphire]. The community wiki The Hacker Recipes, which Bromberg maintains, documents the Sapphire Ticket technique end-to-end at thehacker.recipes/a-d/movement/kerberos/forged-tickets/sapphire [@thehacker-recipes-sapphire]. The verifiable third-party attribution lives at pgj11.com, which records verbatim: "One brand new technique is Sapphire Ticket. Created by Charlie Shutdown (twitter.com/_nwodtuhs) this approach is more stealthy. You can create a TGT impersonating any user assembling real TGT and real PAC combining S4U2Self + U2U ... He extended Ticketer from Impacket to add this attack" [@pgj11-diamond-sapphire]. The Sapphire Ticket bolts a legitimately KDC-issued PAC (obtained by chaining the S4U2Self and User-to-User Kerberos extensions to request a service ticket to oneself with the PAC of an arbitrary target user) onto a Diamond-style ticket. The result presents PAC signatures that the KDC itself produced. Unit 42's December 2022 "Next-Gen Kerberos Attacks" writeup is the secondary that joined Diamond and Sapphire into the same article and named them collectively the "Precious Gemstones" [@unit42-precious-gemstones]. Some secondary sources attribute Sapphire Ticket to Charlie Clark of Semperis. The misattribution probably stems from Clark's separate "AS Requested STs" post on the Semperis blog, which discusses a different technique exploiting unarmored machine-account AS-REQs and is not the Sapphire Ticket primary [@semperis-as-sts]. The verified Sapphire-Ticket originator is Charlie Bromberg (Shutdown, Synacktiv) per [@pgj11-diamond-sapphire]. The adsecurity.org URL ?p=2293 is Sean Metcalf's "Cracking Kerberos TGS Tickets Using Kerberoast -- Exploiting Kerberos to Compromise the Active Directory Domain" (not Metcalf's separate KRBTGT-account post, which lives at a different URL). The page is the operational walkthrough that pairs with Tim Medin's 2014 DerbyCon disclosure [@adsecurity-kerberoast].

Microsoft's engineered response to both Diamond and Sapphire was CVE-2022-37967, the KrbtgtFullPacSignature [@cve-2022-37967] [@ms-kb-5021131]. It is the first PAC-handling protocol change since Windows 2000's introduction of the PAC. After full enforcement, the KDC adds a Full PAC Signature that covers the entire encoded PAC, not just the existing sub-signatures. Diamond and Sapphire variants that modify any PAC field beyond what the Server and KDC sub-signatures already covered will fail validation.

The accounts most vulnerable to Kerberoasting are those with weak passwords and those that use weaker encryption algorithms, especially RC4. RC4 is more susceptible to the cyberattack because it uses no salt or iterated hash when converting a password to an encryption key, allowing the cyberthreat actor to guess more passwords quickly. -- Microsoft Security Blog, October 11, 2024 [@ms-kerberoasting-guidance]

The Spine Table

Generation	Year	Primitive	Structural Insight	Microsoft Response
1	2014	Kerberoasting [@irongeek-derbycon4]	TGS-REP is encrypted with the SPN account's long-term key; offline-crackable	gMSA (2012) [@ms-gmsa]; dMSA (2025) [@ms-dmsa]; Beyond-RC4 (2025-2026) [@ms-beyond-rc4]
2	2014-2017	Golden / Silver Ticket [@mimikatz]; AS-REP Roasting [@ghostpack-rubeus]	RFC 4120 has no online ticket validation [@rfc4120]; long-term key = forge equivalence	KrbtgtFullPacSignature (2022) [@cve-2022-37967]; preauth-required default since Windows 2000
3	2018-2020	SpoolSample [@spoolsample]; RBCD [@shenanigans-rbcd]; Bronze Bit [@cve-2020-17049]	MS-RPRN coercion; S4U2Proxy always returns forwardable; pre-2020 KDC did not independently validate the EncTicketPart flags	Bronze Bit patch (Nov 2020); KB5008383 MachineAccountQuota=0 (Nov 2021); LDAP signing
4	2022	Certifried [@cve-2022-26923]; KrbRelayUp [@krbrelayup]	ADCS template SAN-binding ambiguity; LDAP defaults unsigned	KB5014754 strong-mapping [@ms-kb-5014754]; LDAP signing + EPA on /certsrv/
5	2022	Diamond [@semperis-diamond]; Sapphire [@pgj11-diamond-sapphire] [@unit42-precious-gemstones]	PAC sub-signatures did not cover the encoded PAC structure	KrbtgtFullPacSignature (CVE-2022-37967, Nov 2022) [@cve-2022-37967]

timeline title Kerberos attack cascade section 2014 Sep 2014 : Kerberoasting (Tim Medin, DerbyCon 4) Apr 2014 : Mimikatz 2.0 (Golden / Silver Tickets) section 2017 2017 : AS-REP Roasting (Rubeus weaponisation) section 2018-2020 Oct 2018 : SpoolSample (PrinterBug, Lee Christensen) Jan 2019 : Wagging the Dog / RBCD (Elad Shamir) Nov 2020 : Bronze Bit (Jake Karnes, NetSPI) section 2022 Apr 2022 : KrbRelayUp (Mor Davidovich) May 2022 : Certifried (Oliver Lyak / ly4k) 2022 : Diamond Ticket (Clark / Schwartz) 2022 : Sapphire Ticket (Charlie Bromberg) Nov 2022 : KrbtgtFullPacSignature (Microsoft fix)

Eight years. Eleven structural primitives. One protocol. By 2022 the cascade slowed, not because the protocol got better, but because every primitive a thirty-three-year-old design could expose had been exposed. The 2022 Microsoft response, KrbtgtFullPacSignature, was the first one that targeted the structural properties (PAC coverage of its own structure) rather than the per-primitive patches that defined the 2014-2020 era. To see why that was a turning point, it helps to see exactly what the defensive cadence looked like before then.

5. The Defensive Cadence Before 2023

Each of the eleven primitives in Section 4 shipped with a fix. By 2022 every named primitive had a fix. And yet the cascade kept producing new primitives. Why?

The answer is in the shape of the defensive controls. Walk them in chronological order.

Protected Users (Server 2012 R2, October 2013) [@ms-server-2012-r2]. A new security group that triggers five non-configurable client-side protections and four non-configurable domain-controller-side protections [@ms-protected-users]. The client side: CredSSP "doesn't cache the user's plain text credentials"; Windows Digest "doesn't cache the user's plaintext credentials"; "NTLM stops caching the user's plaintext credentials or NT one-way function (NTOWF)"; "Kerberos stops creating Data Encryption Standard (DES) or RC4 keys ... or long-term keys after acquiring the initial Ticket Granting Ticket (TGT)"; "The system doesn't create a cached verifier at user sign-in or unlock" [@ms-protected-users]. The domain-controller side, also verbatim: members "cannot authenticate with NTLM authentication ... use DES or RC4 encryption types in Kerberos preauthentication ... delegate with unconstrained or constrained delegation ... renew Kerberos TGTs beyond their initial four-hour lifetime" [@ms-protected-users]. The limit is the obvious one: Protected Users breaks every workflow that relied on delegation, RC4, or NTLM, and there are many such workflows still in production.

Authentication Policy Silos (Server 2012 R2). A scope construct that lets administrators apply Protected-Users-equivalent constraints (no RC4, no unconstrained delegation, mandatory FAST) to tiered subsets of an organisation rather than per-account. The standard tier-zero / tier-one / tier-two split fits neatly under three silos [@ms-privileged-access].

A container of users, computers, and managed service accounts in Active Directory that scopes a single authentication policy. Members can be required to authenticate only from designated hosts, must use AES enctypes, may be excluded from delegation, and (when paired with FAST armoring) sign their AS-REQ inside a machine-account or anonymous-PKINIT armor. Available since Server 2012 R2; the operational granularity that Protected Users does not provide on its own [@ms-protected-users].

Restricted Admin (2014) and Remote Credential Guard (2016) [@ms-remote-credential-guard]. The RDP-side companions that block credential exposure on the target host. Both work by changing what gets sent on the wire during a remote sign-in: Restricted Admin (Windows 8.1 / Server 2012 R2 era) uses the user's TGT to authenticate via Kerberos network logon, so no credentials reach the target; Remote Credential Guard (Windows 10 1607, August 2016) performs the same trick but for interactive sessions, redirecting CredSSP back to the originating workstation [@ms-remote-credential-guard].

Credential Guard (Windows 10 RTM, 2015) [@ms-credential-guard]. Virtualization-Based-Security-isolated LSASS: secrets that LSASS would otherwise hold in user-mode memory are moved into the LSAISO trustlet running in Virtual Trust Level 1. SYSTEM on the box cannot read VTL1 memory. Credential Guard is the ceiling against memory-side ticket and key theft, and is one of the cross-link points to the NTLMless companion article.

FAST armoring (RFC 6113, April 2011). Sam Hartman and Larry Zhu's "A Generalized Framework for Kerberos Pre-Authentication" defines the FAST (Flexible Authentication Secure Tunneling) channel [@rfc6113]. The AS-REQ is wrapped in an outer armor envelope, keyed under the machine account's TGT (for a domain-joined client), an anonymous PKINIT TGT (for a non-domain-joined client), or a compound identity. The armor envelope encrypts the PA-ENC-TIMESTAMP blob and authenticates the entire request, closing the offline-cracking path that targets the encrypted-timestamp pre-auth. The limit: FAST is client opt-in, not on by default, and Server 2012 R2 domain functional level is the floor for compound identity. Many production environments still do not require FAST on their tier-zero accounts.

gMSA (Server 2012). The dispositive Kerberoasting defence for service accounts [@ms-gmsa]. The Microsoft Key Distribution Service (kdssvc.dll) computes a 240-character random password, rotated every 30 days, and member hosts authorised in msDS-GroupMSAMembership can retrieve it from a domain controller. The decisive property that gMSA closes is the human-typed-password assumption: there is no password to remember, write down, or share.

LDAP signing and channel binding. The dispositive KrbRelayUp defence. Set LDAPServerIntegrity = 2 to require signing on every LDAP bind, and LdapEnforceChannelBinding = 2 to require channel binding on TLS-bound LDAP connections. Both are off by default in older domain functional levels, which is exactly the default the [@krbrelayup] README is targeting when it calls itself "no-fix".

KrbtgtFullPacSignature (November 2022). The first PAC-handling protocol change since Windows 2000's introduction of the PAC. After full enforcement, every PAC carries an additional Full PAC Signature covering the entire encoded structure, not just sub-pieces; Diamond and Sapphire variants that previously evaded validation by tampering with un-covered fields now fail [@cve-2022-37967] [@ms-kb-5021131].

MachineAccountQuota = 0 guidance (KB5008383, November 2021) [@ms-kb-5008383]. The dispositive RBCD defence as a configuration: setting the directory-wide ms-DS-MachineAccountQuota attribute on the domain root to zero prevents non-administrative users from creating computer accounts at all, which kills the first step of the chain in Section 1's Hook.

Key idea: Each defensive control patches a primitive. No control patches the structural property of the protocol -- that any long-term symmetric key is forge-equivalent for every ticket type that key signs, and that the protocol's offline-validation guarantee makes online ticket revocation incompatible with the design.

Defence	Target Primitive	Structural Limit
Protected Users [@ms-protected-users]	Pass-the-Hash, Pass-the-Ticket, RC4 pre-auth	Breaks delegation, RC4, and NTLM; four-hour TGT cap may break legacy apps
Authentication Policy Silo [@ms-protected-users]	Per-tier scope of Protected-Users behaviour	Requires Server 2012 R2 DFL; FAST armoring requires Server 2012 R2 too
Credential Guard	LSASS memory theft (Mimikatz `sekurlsa::`)	Does not prevent ticket theft via legitimate Kerberos APIs
FAST (RFC 6113) [@rfc6113]	PA-ENC-TIMESTAMP offline cracking	Client opt-in; not on by default
gMSA [@ms-gmsa]	Kerberoasting on service accounts	Human-managed service accounts unaffected
LDAP signing + channel binding	KrbRelayUp [@krbrelayup]	Off by default in older domains
KrbtgtFullPacSignature [@cve-2022-37967]	Diamond and most Sapphire variants	Does not stop Sapphire variants whose tampered PAC was issued legitimately
MachineAccountQuota = 0	RBCD chain [@shenanigans-rbcd]	Default value is `10`; setting requires admin action

Read the table the way an attacker reads it. Each row is necessary; no row is sufficient. The "structural limit" column is the next-attack catalogue. Protected Users does not stop a Diamond Ticket forged from a stolen KRBTGT key. Credential Guard does not stop the operator who has SYSTEM on a domain controller. FAST does not stop AS-REP Roasting (because AS-REP Roasting only happens on accounts with pre-auth disabled, where FAST is moot). gMSA does not protect a service account someone still manages manually with a Notes-saved password.

The pattern is the answer to the section's opening question. Every control attacks one primitive -- a key, a flag, a coercion path, a ticket lifetime -- and none of them closes the protocol-level structural property that any long-term symmetric key in the domain is forge-equivalent for any ticket type that key signs. By 2022 the engineering catalogue was complete. The 2023 announcement was the first plan that targeted the structure.

What would a structural fix even look like, given that any "online revocation" change would also give up Kerberos's O(1) service-side validation, and given that any "deprecate the long-term key" change has to back-compat to clients that have not been touched since Server 2008? The October 2023 Palko post had answers.

6. The Breakthrough: Closing the Domainless Gap

October 11, 2023. Matthew Palko, Microsoft's Principal Group Product Manager for Windows authentication, publishes "The evolution of Windows authentication" on the Windows IT Pro Blog. The article's <meta property="article:modified_time"> reads 2023-11-11T01:30:49.108-08:00 in the raw HTML; the description metadata reads "Discover how we're securing authentication and reducing NTLM usage in Windows" [@ms-palko-evolution]. It is the first time Microsoft commits publicly to deprecating NTLM, and the first time Microsoft names the three load-bearing engineering features that move Kerberos from "domain-only" to "load-bearing-for-everything".

The plan has four moving parts. Each one closes a specific reason that NTLM survived for thirty years.

IAKerb: Kerberos without KDC line-of-sight

The structural reason NTLM lived through Server 2003, Server 2008, Server 2012, and Server 2019 is that Windows had no Kerberos-equivalent path for the case where a client cannot reach a KDC. A laptop on a hotel network, a hybrid Azure-joined workstation that can reach the application server but not the AD DC, a workgroup machine attempting to access a domain file share -- all of those flowed back to NTLM by default, because Kerberos required a working AS-REQ to the domain controller before it could mint a TGT.

IAKerb (Initial and Pass Through Authentication Using Kerberos V5 and the GSS-API) closes that gap. The draft IETF specification, draft-ietf-kitten-iakerb, is by Benjamin Kaduk, Jim Schaad, Larry Zhu, and Jeffrey E. Altman [@iakerb-draft]. The mechanism is GSS-API encapsulation: the client wraps each AS-REQ, AS-REP, TGS-REQ, and TGS-REP message inside a GSS-API token addressed to the application server, and the application server proxies the token to the KDC the server can reach. From the client's perspective, it is talking to the application server; from the KDC's perspective, the AS exchange came from the application server. The protocol's verbatim problem statement reads: "encapsulating the Kerberos messages inside GSS-API tokens. With these extensions a client can obtain Kerberos tickets for services where the KDC is not accessible to the client, but is accessible to the application server" [@iakerb-draft].

Initial and Pass Through Authentication Using Kerberos V5 and the GSS-API. An extension to GSS-API Kerberos (RFC 4121) that encapsulates Kerberos AS / TGS exchanges inside GSS-API tokens between client and application server, so the application server can proxy them to a KDC the server can reach but the client cannot. Documented in the IETF draft `draft-ietf-kitten-iakerb` by Kaduk, Schaad, Zhu, and Altman [@iakerb-draft]. A Kerberos Key Distribution Center implemented as an in-process service inside the local Windows Security Authority (LSASS) on a workgroup or Azure-joined machine. The Local KDC issues tickets backed by the local SAM password database, exposing no Kerberos port to the network; clients reach it only through IAKerb encapsulation tunnelled through the application protocol. Closes the "local account auth has no KDC" gap that has kept NTLM alive for workgroups since Windows NT 3.1 [@ms-palko-evolution] [@fosdem-localkdc].

MIT krb5 added IAKERB support fifteen years ago. The README for krb5-1.9, released December 22, 2010, says verbatim: "Add support for IAKERB -- a mechanism for tunneling Kerberos KDC transactions over GSS-API, enabling clients to authenticate to services even when the clients cannot directly reach the KDC that serves the services" [@mit-krb5-19-readme] [@mit-krb5-19-page]. The capability sat in MIT's mainline Kerberos for over a decade. Windows did not ship the equivalent because, until NTLM was on a deprecation path, Windows did not need it -- NTLM filled the line-of-sight gap. Once NTLM was on the road to removal, IAKerb stopped being optional. The sixteen-year gap between MIT krb5-1.9 IAKERB (December 22, 2010) and Microsoft's planned H2 2026 broad enable is the cleanest evidence that Microsoft's NTLM deprecation is the forcing function for the Kerberos refit, not a side effect. The specification was waiting for the customer demand to catch up.

Local KDC: Kerberos for the workgroup

The second structural reason NTLM survived was that Windows local accounts had no concept of "domain". Without an AD domain, there was no KDC. Without a KDC, there were no Kerberos tickets. Local-account authentication therefore flowed through NT challenge-response (NTLMv2) by default.

Local KDC closes this. The Local KDC, shipping in Windows 11 24H2 and Server 2025 with broad enablement targeted for H2 2026 [@ms-palko-evolution], is a Kerberos KDC built directly on top of the local SAM database. LSA derives an AES-256 long-term key from the local account's password rather than persisting the legacy RC4 NT hash. The Local KDC exposes no listening Kerberos port; clients reach it only through IAKerb encapsulation inside the application protocol (SMB, RDP, HTTP).

The parallel open-source path was demonstrated by Alexander Bokovoy and Andreas Schneider at FOSDEM 2025, where they presented "localkdc: A General Local Authentication Hub" [@fosdem-localkdc]. The abstract reads verbatim: "A local Kerberos Key Distribution Center (KDC) is not a new invention. It is a useful tool in combination with the Kerberos IAKerb extension but also allows to map SSO from a web authentication to local authentication or in a network environment isolated from the rest of the enterprise environment ... how use of NTLM in SMB protocol will be replaced by a localkdc in combination with IAKerb" [@fosdem-localkdc]. Samba 4.21 carries the prototype implementation.

The Bokovoy / Schneider talk is the cleanest external evidence that Local KDC is a *protocol-level* architecture, not a Microsoft-proprietary one. Samba, Heimdal, MIT krb5, and Microsoft are converging on the same design: an in-process KDC, GSS-API-tunnelled Kerberos exchanges, AES-keyed local accounts. The IETF draft-ietf-kitten-iakerb specification [@iakerb-draft] is the shared standardisation layer. Add support for IAKERB -- a mechanism for tunneling Kerberos KDC transactions over GSS-API, enabling clients to authenticate to services even when the clients cannot directly reach the KDC that serves the services. -- MIT krb5-1.9 release notes, December 22, 2010 [@mit-krb5-19-readme]

PKINIT and the freshness extension

The third gap NTLM filled was non-password credentials. Windows Hello for Business, smart cards, and Federal Information Processing Standard token logon all need to translate "I hold this private key" into "I hold this Kerberos TGT". PKINIT (Public Key Cryptography for Initial Authentication in Kerberos), RFC 4556, by Larry Zhu (Microsoft) and Brian Tung (Aerospace Corporation), is the protocol for that [@rfc4556]. The AS-REQ carries a PA-PK-AS-REQ PA-DATA element wrapping an AuthPack CMS structure signed by the client's private key; the AS-REP carries the TGT keyed for the client to decrypt with either RSA key transport or Diffie-Hellman key exchange.

The 2006 RFC 4556 PKINIT had a replay window: an attacker who recorded a signedAuthPack could replay it indefinitely until the client's certificate expired. RFC 8070, "PKINIT Freshness Extension," by Michiko Short, Seth Moore, and Peter Miller of Microsoft (February 2017) closed it [@rfc8070]. The AS-REP issues an opaque PA-AS-FRESHNESS blob in a preliminary KDC-error round-trip; the client must echo the blob in its next signed AS-REQ; replays after the freshness window fail. Verbatim from RFC 8070 abstract: "exchange an opaque data blob that a Key Distribution Center (KDC) can validate to ensure that the client is currently in possession of the private key during a PKINIT Authentication Service (AS) exchange" [@rfc8070].

Together, RFC 4556 plus RFC 8070 anchor every modern non-password Windows credential: Windows Hello for Business, smart-card logon, FIDO2 keys mediated by Windows Hello, and the upcoming Entra-issued cloud TGTs. The 2022 Certifried CVE [@cve-2022-26923] forced the strong-mapping layer on top of all of this: every certificate used for PKINIT must carry an X.509 extension binding it to a specific AD account SID. KB5014754 [@ms-kb-5014754] tracks the rollout; see §4 for the full Compatibility / Enforcement / rollback-removal date sequence.

FAST armoring as default

The fourth gap was the trust assumption at the start of an AS-REQ: the encrypted-timestamp pre-auth blob, PA-ENC-TIMESTAMP, is keyed under the client's password-derived key, which is offline-crackable on observation. FAST (RFC 6113) wraps the AS-REQ inside an armor envelope keyed under a separate key the attacker does not see [@rfc6113]. In a domain-joined client the armor key is derived from the machine account's TGT; in a non-domain-joined client it is derived from an anonymous PKINIT TGT; in a compound-identity scenario it is the combination of both.

What changes in the 2023 plan is the default-on posture: Authentication Policy Silos can now require FAST for every AS-REQ from a silo member, and Local KDC clients use anonymous PKINIT armoring out of the box because the SAM-derived long-term key is the only credential available and offline-crackability would be catastrophic.

sequenceDiagram participant C as Client (no KDC reach) participant S as Application Server participant KDC as KDC (reachable from S) C->>S: GSS-API token: IAKerb (AS-REQ wrapper) S->>KDC: AS-REQ (forwarded) KDC->>S: AS-REP (forwarded) S->>C: GSS-API token: IAKerb (AS-REP wrapper) C->>S: GSS-API token: IAKerb (TGS-REQ wrapper) S->>KDC: TGS-REQ (forwarded) KDC->>S: TGS-REP (forwarded) S->>C: GSS-API token: IAKerb (TGS-REP wrapper) C->>S: AP-REQ presenting service ticket S->>C: AP-REP -- session established

The Gap-to-Closure Mapping

NTLM-fallback gap	Engineered closure	Primary source	Ship target
Client has no KDC line-of-sight	IAKerb GSS-API encapsulation	[@iakerb-draft]	Windows 11 24H2 / Server 2025; broad enable H2 2026 [@ms-palko-evolution]
Local accounts have no domain KDC	Local KDC on SAM + AES-256 derivation	[@ms-palko-evolution] [@fosdem-localkdc]	Windows 11 24H2 / Server 2025
Non-password credentials need an AS path	PKINIT (RFC 4556) + Freshness (RFC 8070) + strong mapping (KB5014754)	[@rfc4556] [@rfc8070] [@ms-kb-5014754]	Enforcement February 11, 2025; Disabled mode removed April 2023; Compatibility mode removed Sept 9, 2025
AS-REQ pre-auth is offline-crackable	FAST armoring (RFC 6113) default-on in silos	[@rfc6113]	Available since Server 2012 R2; default-on with new silos

After thirty-three years of layered extensions, Kerberos in 2026 is finally a single-protocol authentication path for every Windows scenario. Domain-joined, workgroup, Azure-joined without AD line-of-sight, local-account to local-account. The mechanism that closes the last gap -- IAKerb -- is a sixteen-year-old MIT protocol coming to Windows for the first time. What's left for Kerberos to fix is encryption-type hygiene, and a December 2025 Microsoft post named the calendar dates for that too.

7. The Beyond-RC4 Cadence

December 3, 2025. The Microsoft Windows Server Blog publishes "Beyond RC4 for Windows authentication" [@ms-beyond-rc4]. The post is short and specific. Verbatim: "By mid-2026, we will be updating the domain controller default assumed supported encryption types. The assumed supported encryption types is applied to service accounts that do not have an explicit configuration defined. Secure Windows authentication does not require RC4; AES-SHA1 can be used across all supported Windows versions since it was introduced in Windows Server 2008" [@ms-beyond-rc4]. For the first time in twenty years, RC4-HMAC is on a removal cadence with a calendar date and an enforcement CVE.

The rollout has three phases.

Phase 1, January 2026, audit only. Domain controllers gain new fields in Event ID 4768 (TGT issued) and Event ID 4769 (TGS issued): msDS-SupportedEncryptionTypes, Available Keys, and Session Encryption Type. The fields tell an administrator, for each ticket issued, which enctypes the requesting account had configured and which one the KDC actually chose. Two new PowerShell auditing scripts ship in the microsoft/Kerberos-Crypto GitHub repository: List-AccountKeys.ps1 enumerates every account and the enctype configuration on each; Get-KerbEncryptionUsage.ps1 parses the 4768 / 4769 log stream and prints accounts still requesting or being issued RC4 tickets [@ms-beyond-rc4]. Verbatim from the post: "we have enhanced existing information within the Security Event Log and developed new PowerShell auditing scripts. These enhancements are available in Windows Server versions 2019, 2022, and 2025" [@ms-beyond-rc4].

Phase 2, April 2026, default flip. The "assumed" msDS-SupportedEncryptionTypes on accounts that have no explicit setting changes from "anything the client asks for, including RC4" to "AES-SHA1 only". AES-SHA1 (RFC 3962 enctypes 17 and 18) has shipped on every supported Windows version since Server 2008 [@rfc3962], so the flip is theoretically backward-compatible with every domain-joined client; in practice the casualties are third-party Kerberos clients (legacy Linux MIT krb5 with RC4-only keytabs, network-attached-storage appliances stuck on older krb5 libraries, SQL Server linked servers with manually-configured service-principal RC4 entries).

Phase 3, mid-2026, enforcement. RC4 tickets require explicit per-account opt-in. The enforcement boundary is CVE-2026-20833, called out by name in the Microsoft post [@ms-beyond-rc4]. After that date, an account that has not had msDS-SupportedEncryptionTypes explicitly written to include 0x4 (RC4) will not be issued RC4 tickets, and DCs will reject any TGS-REQ that asks for one against an account configured AES-only.

Note: The mid-2026 RC4-default removal is gated on CVE-2026-20833, named in the December 2025 "Beyond RC4" post as the enforcement boundary [@ms-beyond-rc4]. The audit window closes when this date lands. Production environments that have not migrated their service accounts to gMSA or explicitly set msDS-SupportedEncryptionTypes will find Kerberos authentication failing for those accounts the day Phase 3 ships.

The interesting question is why the migration destination is AES-SHA1 (enctypes 17 and 18) and not AES-SHA2 (enctypes 19 and 20). RFC 8009 specifies AES-SHA2 [@rfc8009]; Microsoft's [MS-KILE] §2.2.7 supported-encryption-types bit table includes bits K (AES128-CTS-HMAC-SHA256-128) and L (AES256-CTS-HMAC-SHA384-192) [@ms-kile-227]. Linux MIT krb5 has shipped RFC 8009 since version 1.15 (December 2016) [@mit-krb5-115]. Cross-domain interoperability between AES-SHA2 Windows and AES-SHA2 MIT works. The remaining work is purely Microsoft-side default enablement and the auditing infrastructure analogous to the RC4 cadence.

The Beyond-RC4 post does not name an AES-SHA1 -> AES-SHA2 timeline at all. The audit-default-enforce cadence Microsoft has now demonstrated for RC4 -- audit instrumentation in event logs, default flip with backward-compatible enctypes, enforcement gated by a named CVE -- has no announced analogue for AES-SHA1 yet.

Key idea: The cadence Microsoft has is audit, default, enforce. The RC4 to AES-SHA1 transition has all three: audit instrumentation in Phase 1, the default flip in Phase 2, and named enforcement via CVE-2026-20833 in Phase 3. The AES-SHA1 to AES-SHA2 transition has none. The [MS-KILE] bits exist; the cross-domain interoperability works; the Microsoft-side rollout is the missing piece. The microsoft/Kerberos-Crypto GitHub repository ships the two PowerShell auditing scripts (List-AccountKeys.ps1, Get-KerbEncryptionUsage.ps1) that the December 2025 post names as the Phase 1 instrumentation. They are the right tools for an administrator who wants to find their RC4-dependent service accounts before the audit window closes mid-2026 [@ms-beyond-rc4].

Mid-2026 is the audit-window-closes date. The question for every AD operator is which of their service accounts will still be requesting RC4 tickets when the default flips, and whether their detection tooling sees them in the window. Two quarters from now, the answer "we'll just turn RC4 off and see what breaks" stops being a defensible operating posture.

timeline title Beyond-RC4 rollout section Phase 1 -- Audit Jan 2026 : Event 4768 / 4769 fields msDS-SupportedEncryptionTypes Available Keys Session Encryption Type Jan 2026 : Kerberos-Crypto GitHub repo with List-AccountKeys.ps1 and Get-KerbEncryptionUsage.ps1 section Phase 2 -- Default flip Apr 2026 : Assumed msDS-SupportedEncryptionTypes flips to AES-SHA1-only for accounts without explicit configuration section Phase 3 -- Enforcement Mid 2026 : CVE-2026-20833 enforcement boundary -- RC4 tickets require explicit per-account opt-in

8. What Removing NTLM Cannot Buy You

After everything in Section 6 and Section 7 ships, Kerberos in 2026 is still vulnerable to four classes of attack. None of them are protocol bugs; all of them are protocol structure.

Kerberos has its own relay class. The KrbRelayUp README explicitly scopes itself to Windows domain environments where LDAP signing is not enforced -- the post-NTLM cousin of NTLM-relay [@krbrelayup]. The relay primitive survives the move from NTLM to Kerberos because the attack does not target the authentication protocol -- it targets the LDAP protocol's lack of mandatory integrity, and any authenticated bind (Kerberos or NTLM) is fair game once the channel is unsigned. The dispositive control is LDAP signing plus channel binding domain-wide, plus Extended Protection for Authentication on every AD CS Web Enrolment endpoint. It is a configuration, not a protocol fix. The NTLMless companion article walks through the LDAP-side work in detail.

The long-term-key problem is intrinsic to symmetric Kerberos. Whoever holds the krbtgt account's long-term key forges any TGT (the Golden Ticket primitive). Whoever holds an SPN account's long-term key forges any TGS for that service (the Silver Ticket primitive). RFC 4120's offline-validation property [@rfc4120] requires that the service trust the key alone -- the AP-REQ contains no callback to the KDC; the service decrypts the ticket, validates the signatures, and decides. Any change that adds an online "is this ticket still valid?" check also gives up Kerberos's O(1) service-side scaling and the offline-validation guarantee that makes the protocol cheap. Authentication Policy Silos, Protected Users, TPM-backed credentials, and Credential Guard all raise the cost of obtaining the key; they do not close the forge-equivalence property. Mathematically, if you have the key, you are the principal.

The PAC is a signed vouching token, not a verified live query. KrbtgtFullPacSignature [@cve-2022-37967] closes the modification side of Diamond and Sapphire. It does not close the staleness side. A user removed from Domain Admins at 09:00 still presents service tickets attesting Domain Admin membership until the ticket expires (default 10 hours user TGT, 7 days renewable; Protected Users members are capped at 4 hours [@ms-protected-users]). The PAC vouching window is the residual stale-authorization gap. The defender's option is shorter ticket lifetimes or out-of-band ACL flips at the service tier; the protocol itself has no callback by which a service learns about a group-membership change before the ticket expires.

Domainless does not mean keyless. Local KDC binds the SAM password to an AES-256 long-term key. The wire form of pass-the-hash is gone: there is no NT hash on the line, no LMv2 challenge response, no DES-CBC-MD5 keytab. But a NT AUTHORITY\SYSTEM-level attacker on the box still recovers the AES key, because LSA must materialise that key in user-mode memory to hand it to Kerberos. The chip- and VBS-based countermeasures (TPM-backed credentials, Microsoft Pluton, Credential Guard) remain orthogonal and necessary; none of them is replaced by Local KDC.

Key idea: H2 2026 ships Kerberos as the load-bearing single authentication protocol; it does not ship a Kerberos in which (1) the Kerberos-relay class is closed, (2) long-term-key forge-equivalence is closed, (3) PAC staleness is closed, or (4) local-key recovery from a SYSTEM-level attacker on the box is closed. The arc is a transition between tradeoffs, not out of them.

The Phase-3-as-transition-between-tradeoffs framing is mirrored in the [NTLMless](/blog/ntlmless-the-death-of-ntlm-in-windows/) companion article's Section 8 -- the symmetric framing is deliberate. Read the two articles together as a paired diagnosis: NTLMless is the eulogy and the migration story; this article is the inheritance and the to-do list.

9. Open Problems and the 2026-2027 Edge

Five problems sit on the May-2026 research agenda. None has a shipping Microsoft answer.

The AES-SHA1 to AES-SHA2 Windows-default timeline. RFC 8009 [@rfc8009] is nine years old. The [MS-KILE] §2.2.7 supported-encryption-types bit table already includes the AES-SHA2 bits K and L [@ms-kile-227]. Linux MIT krb5 shipped RFC 8009 in version 1.15 (December 2016) [@mit-krb5-115]. Cross-domain Kerberos interop between MIT clients and Windows DCs over AES-SHA2 works in the laboratory. What is missing is a Microsoft-side equivalent of the audit / default / enforce cadence already in place for the RC4 transition, especially because the hard part is not the cryptography but the long tail of third-party Kerberos clients and pre-2017 keytabs that an AES-SHA2 audit would have to enumerate before the default can flip. The 8009 cadence is the largest Windows-side cryptographic gap that has no announcement.

Quantum risk. Kerberos symmetric primitives (AES-128 and AES-256) retain a Grover-bound effective security margin of 64 and 128 bits respectively, which is durable against the near-term cryptographically-relevant quantum computer. PKINIT is the exposed half: the CMS signature chains in AuthPack are RSA or ECDSA per RFC 4556 §3.2 [@rfc4556], and both are broken by Shor's algorithm. Anonymous PKINIT, used for FAST armoring on non-domain-joined clients, has the same exposure. Microsoft has not announced a PKINIT-specific post-quantum cryptography plan; the Kerberos team's standardisation tracking sits on the IETF kitten working group's queue rather than on a shipping Windows roadmap. Cross-link to the post-quantum cryptography sibling article in this series.

dMSA field-deployment maturity. Server 2025 introduced Delegated Managed Service Accounts as the successor to gMSA [@ms-dmsa]. The protocol-level differences -- "Authentication for dMSA is linked to the device identity ... dMSA uses a randomized secret (derived from the machine account credential) that is held by the Domain Controller (DC) to encrypt tickets" -- close several gMSA gaps, including the multi-tenant-key problem. But the 14-day account-migration window, the four-ticket-lifetime startup state during which both the legacy account and the dMSA can authenticate, and the cross-domain plus cross-forest behaviours are still being shaken out in field deployments. As of the May 2026 reading, dMSA is shipping but not yet the default for new service accounts.

Cross-cloud Kerberos. Kerberos Cloud Trust for Windows Hello for Business is the architectural piece that lets an Azure-joined laptop obtain TGTs from Entra ID rather than from an on-premises DC, with the on-premises DC trusting Entra's signatures via federation. Per [@ms-palko-evolution] the architecture is planned but unproven in the field at scale. The role of Local KDC in pure-Entra (no AD on-prem) deployments is still being defined. The trust graph for "Local KDC + Entra ID + on-premises AD" is one of the open architectural problems the Palko post mentions but does not yet detail.

Open-source IAKerb and Local KDC. Samba's localkdc work, demonstrated by Alexander Bokovoy and Andreas Schneider at FOSDEM 2025 [@fosdem-localkdc], is the most public open-source mirror of Microsoft's Local KDC plan. Heimdal has a partial implementation. MIT krb5 IAKERB has been shipping since krb5-1.9 on December 22, 2010 [@mit-krb5-19-readme] and is mature. The Local-KDC-on-the-SAM pattern is new to the Windows world specifically; in the open-source world the equivalent (a Kerberos KDC fed from a local user database) has existed in textbooks since Kerberos v4.

Each of the five problems is a residual. Each is the next decade's research. None of them invalidates the Phase 3 shipping commitment. The article's load-bearing closing claim is honest about that: H2 2026 is a transition, and what comes next will be its own multi-year cadence.

10. What an AD Engineer Should Do This Quarter

If you read nothing else from this article, read this. Seven controls; each one is tied to one primary Microsoft Learn or MSRC URL; each one closes one of the attack primitives in Section 4. Cross-link to the parallel practical-guide section in the NTLMless companion article.

Note: Run the two PowerShell scripts in microsoft/Kerberos-Crypto: List-AccountKeys.ps1 enumerates every account's configured enctypes; Get-KerbEncryptionUsage.ps1 parses your Event 4768 / 4769 stream and lists accounts still requesting or being issued RC4 tickets. The audit window closes mid-2026 when Phase 2 flips the default [@ms-beyond-rc4]. Every account on the list above is a Phase-3 production incident if you do nothing.

Note: Do not rely on the mid-2026 default flip. Explicitly write msDS-SupportedEncryptionTypes with the value 0x18 (AES-128 + AES-256, no RC4) on every service account that does not have a documented RC4 dependency. For service accounts that do, write 0x1C (AES-128 + AES-256 + RC4) and put a calendar reminder against the RC4 dependency so it gets remediated before Phase 3 [@ms-beyond-rc4].

Note: Manually-managed service-account passwords are the Kerberoasting attack surface per [@ms-kerberoasting-guidance]. gMSA gives you 240-character KDS-derived passwords rotated every 30 days [@ms-gmsa]. dMSA on Server 2025 binds the account secret to the device identity and stores it only on the domain controller, where it can be further protected by Credential Guard [@ms-dmsa]. There is no service-account workflow gMSA or dMSA does not cover; the migration is operational, not architectural.

Note: Setting ms-DS-MachineAccountQuota on the domain root to zero kills the first step of the RBCD chain in Section 1 [@shenanigans-rbcd] and the KrbRelayUp chain [@krbrelayup]. The default value of 10 has been the de facto attack-surface enabler since Windows 2000. The control is one PowerShell line: Set-ADDomain -Identity (Get-ADDomain) -Replace @{'ms-DS-MachineAccountQuota'=0}. The breakage surface is small: only legitimate computer-account bootstrap workflows that today rely on user-driven djoin.exe.

Note: Protected Users gives every member the five non-configurable client protections plus the 4-hour TGT cap [@ms-protected-users]. Wrap an Authentication Policy Silo around the same population to add mandatory FAST armoring [@rfc6113] and per-silo logon-from constraints. Both controls have been available since Server 2012 R2; the operational reason most environments still have not adopted them is the breakage in legacy delegation workflows. Audit and remediate those workflows; do not skip Protected Users.

Note: Set LDAPServerIntegrity = 2 (require signing) and LdapEnforceChannelBinding = 2 (require channel binding on TLS-bound connections) via Group Policy. This is the dispositive KrbRelayUp defence [@krbrelayup] and the dispositive defence against any Kerberos-relay-class attack that targets the LDAP control plane. Pair with Extended Protection for Authentication on every AD CS Web Enrolment endpoint to close the Certifried-style certificate-issuance variant [@ms-kb-5014754].

Note: Flight the RC4DefaultDisablementPhase Group Policy setting in your Insider channel; pilot non-production AES-only configurations on a representative subset of service accounts; identify legacy NAS appliances, Linux MIT krb5 clients with keytabs older than 2017, and SQL Server linked-server SPNs before Phase 2 closes the audit window [@ms-beyond-rc4]. Phase 3 ships with CVE-2026-20833; production environments that have not run the audit will discover the dependency list the day enforcement lands.

Three quarters from now (mid-2026), every default in this list will have changed. Do the work in the audit window or do it in the post-flip ticket queue. The cost of an audit-window migration is a quarter of engineering time; the cost of a post-flip remediation is a sixty-minute outage on every undocumented RC4 dependency the directory holds. Cross-link to the Pluton, TPM, and Credential Guard sibling articles for the hardware-backing layer that protects the long-term keys these controls assume.

11. Frequently Asked Questions

AES-SHA1 (RFC 3962 enctypes 17 and 18) is enough against the 2026 attack picture: there is no known cryptographic attack against AES-256-CTS-HMAC-SHA1-96 within Kerberos's threat model, and AES eliminates the salt-less / iteration-less Kerberoasting weakness of RC4-HMAC [@rfc3962] [@ms-kerberoasting-guidance]. AES-SHA2 (RFC 8009 enctypes 19 and 20) is the obvious next step and is supported by [MS-KILE] bits K and L [@ms-kile-227]. Quantum threats are not the immediate worry for symmetric Kerberos; the exposed surface is PKINIT, not the ticket cipher.The Grover speedup applied to AES-256 leaves an effective 128-bit security margin, which is durable for the lifetime of any current cryptographic system [@nist-pqc]. Yes, for delegation, and that is the point. Per [@ms-protected-users], members cannot use unconstrained or constrained delegation, cannot use DES or RC4 in Kerberos pre-auth, and have their TGT capped at four hours. Workflows that today rely on a domain admin's TGT being forwardable to a downstream service must be reworked. Use Authentication Policy Silos for the per-account scope where some delegation must remain. Yes, with risk. The mid-2026 enforcement boundary CVE-2026-20833 [@ms-beyond-rc4] is the formal cutover. Disabling RC4 today by setting `msDS-SupportedEncryptionTypes` to `0x18` (AES-only) on accounts will work, but expect breakage from Linux clients with MIT krb5 keytabs older than 2017, network-attached-storage appliances with hard-coded RC4 entries, and SQL Server linked-server SPNs that have not been updated. The audit-then-migrate cadence in Section 10 is the operationally honest path. No. It kills *unsigned-PAC* Golden Tickets and most Diamond and Sapphire variants that tampered with PAC fields outside the original sub-signatures [@cve-2022-37967]. If an attacker has the actual `krbtgt` long-term key, they still mint correctly-signed tickets -- the Full PAC Signature is computed with that same key. The defence is rapid `krbtgt` rotation (the dual-password scheme means you must rotate twice with an interval) plus Credential Guard to keep the key out of LSASS user-mode memory. PKINIT [@rfc4556] exists, Active Directory Certificate Services exists, Windows Hello for Business is built on top of PKINIT. The reason "everywhere" was hard is Certifried (CVE-2022-26923) [@cve-2022-26923] and the strong-mapping retrofit [@ms-kb-5014754]: the original ADCS templates allowed a certificate's Subject Alternative Name to be set independently of the AD account that requested the certificate, which let an attacker mint a certificate claiming to be a domain controller. Strong mapping (the SID-binding X.509 extension) closed that, but the rollout took years to land in Enforcement mode (see §4 for the full date sequence). It eliminates the *wire* form. There is no NT hash on the LSA-to-Local-KDC path; the long-term key is an AES-256 derivation. A SYSTEM-level attacker on the box still recovers that AES key, because LSA must hold it in user-mode memory to hand to the Kerberos SSP. The chip-side defences (TPM, Microsoft Pluton, Credential Guard) remain orthogonal and necessary per [@fosdem-localkdc]. Local KDC closes the relay-from-the-wire class, not the SYSTEM-on-the-box class. Kerberos Cloud Trust for Windows Hello for Business issues TGTs from Entra ID and federates trust back to on-premises AD, so an Entra-joined laptop can present a domain-trusted Kerberos ticket to a file server it has never directly authenticated to. The on-premises KDC role is partially federated; the on-prem AD signs nothing for the Entra-issued TGT but trusts Entra's signature via Cloud Trust. Per [@ms-palko-evolution] the architecture is shipping in stages. The full story is its own article in this series. Not in this decade. The architectural trajectory is "Kerberos + PKINIT + FAST + Local KDC + IAKerb + Authentication Policy Silos + TPM-backed long-term keys" -- not a replacement protocol. The closest thing to a replacement on the horizon is post-quantum PKINIT, which is more of a re-cipher than a re-protocol. The Kerberos message triple (AS-REQ, TGS-REQ, AP-REQ) is genuinely durable.Compared with the 28-year deprecation cycle NTLM took, replacing Kerberos would be a thirty-year project on the same precedent. Microsoft's stated direction is to harden the joints, not to throw out the skeleton. The commands below assume Server 2019 or later with the `microsoft/Kerberos-Crypto` repo cloned locally. Run on a domain controller; output names every account whose configured `msDS-SupportedEncryptionTypes` allows RC4 or has no explicit setting (in which case it inherits the pre-Phase-2 default of "anything goes"). Cross-reference with the 4768 / 4769 audit stream from `Get-KerbEncryptionUsage.ps1` to identify which of those accounts is actually being issued RC4 tickets in practice.

# Enumerate accounts and configured enctypes
Import-Module ActiveDirectory
.\List-AccountKeys.ps1 -OutputCsv accounts.csv

# Parse 4768 / 4769 events for issued ticket enctypes
.\Get-KerbEncryptionUsage.ps1 -LookbackDays 30 -OutputCsv tickets.csv

# Join the two on account name -- the accounts that
# both have RC4-allowed AND were issued RC4 tickets
# are your Phase 3 incident list.

NTLMless: The Death of NTLM in Windows

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

**NTLM is the 30-year-old fallback authentication protocol that Active Directory still rests on whenever Kerberos cannot do the job -- and every consequential modern AD attack (pass-the-hash, NTLM relay, PetitPotam, ESC8) lives in that fallback path.** Microsoft's exit plan (IAKerb, Local KDC, NEGOEX, the Negotiate-everywhere refactor) closes the four reasons NTLM survived, and the January 2026 roadmap names "disabled by default in the next major Windows release" as Phase 3. This article tells the whole arc as one story: how NTLM works on the wire, every attack class against it, exactly what is being removed -- and what is not.

1. Eight Minutes

A defender has done every retrofit Microsoft has shipped over twenty years. SMB signing enforced on every member server. EPA enabled on every IIS endpoint. Credential Guard on. Restrict NTLM in audit mode. KB 5005413 applied to AD CS. An attacker with no credentials joins their network, runs Coercer against a domain controller, and a handful of seconds later holds a Kerberos ticket-granting ticket for the Domain Admin account [@gh-coercer, @specterops-cert-preowned-blog]. Total elapsed time: less than the time it took you to read this paragraph. Total prerequisites for the chain: that NTLM still exists as a fallback path on Windows.

The chain has a name. ESC8, from Will Schroeder and Lee Christensen's "Certified Pre-Owned" whitepaper, published June 17, 2021 [@specterops-cert-preowned-blog, @specterops-cert-preowned-pdf]. Its coercion primitive has another name. PetitPotam, from Lionel Gilles, published the next month. Together they take a fully retrofitted Active Directory environment to Domain Admin in four steps.

Note: 1. Coerce. Call EfsRpcOpenFileRaw against any Windows server -- including a DC -- over LSARPC. The service, running as SYSTEM, NTLM-authenticates back to an attacker-controlled UNC path. No credentials required. 2. Relay. ntlmrelayx.py from Impacket sits on the listening side and forwards the live NTLM exchange to the AD CS Web Enrollment endpoint at /certsrv/certfnsh.asp [@gh-impacket]. 3. Enroll. The relayed authentication enrolls the DC's machine account for a client certificate against the Machine template (or any default-enabled template that allows enrollment) [@specterops-cert-preowned-pdf]. 4. Forge. The attacker uses the certificate to perform PKINIT against the KDC, obtains a TGT for the DC's machine account, and uses the DC machine account's TGT to DCSync the domain's hashes -- including the krbtgt hash -- achieving full domain compromise. Domain Admin in under ten minutes [@specterops-cert-preowned-blog].

Pause on what is and is not true here. SMB signing did not fail; SMB signing was not in the chain. EPA failed because it was deployed on IIS authentication endpoints generally but the /certsrv/ deployment lagged [@ms-kb5005413]. Credential Guard did not fail; Credential Guard protects the NT-hash, and the attacker never touched a hash. Restrict NTLM in audit mode worked exactly as labelled: it audited.

The retrofits are not wrong. They patch the named primitives. The chain exploits the existence of the fallback path, not a primitive. Every protective control is honest about what it does and silent about what it does not.

sequenceDiagram autonumber actor A as Attacker (no creds) participant DC as Domain Controller participant R as ntlmrelayx listener participant CA as AD CS /certsrv/ participant KDC as KDC (PKINIT) A->>DC: EfsRpcOpenFileRaw -- UNC to attacker share DC->>R: NTLM AUTHENTICATE (SYSTEM (DC machine account)) R->>CA: Relay NTLM, enroll Machine cert as DC CA-->>R: Client certificate for DC R->>KDC: PKINIT AS-REQ with DC cert KDC-->>A: TGT for DC, request service tickets at will

This is the question that drives the rest of the article: how did Windows arrive at a state where the most catastrophic modern Active Directory attack chain depends on a thirty-year-old fallback nobody wants?

2. Origins: Why NTLM Existed at All

Rewind to 1987. IBM and Microsoft ship LAN Manager 1.0 for OS/2. PCs are still mostly file-and-print islands on Token Ring or 10BASE-2 coax; networking exists, but "domain" is a word for what a single server controls. LAN Manager needs an authentication scheme that can run on hardware with 640 KB of RAM, no DES export licence, and roughly zero institutional knowledge about cryptography. What it produces, the LM hash, is a near-perfect snapshot of every constraint and assumption of its moment [@wp-lan-manager].

The construction is short enough to write out. Take the password. Uppercase it. Pad or truncate to exactly fourteen ASCII characters. Split into two seven-byte halves. Convert each half into a 56-bit DES key (the eighth bit of each byte is a parity bit). Use each key to DES-encrypt the eight-byte constant KGS!@#$%. Concatenate the two eight-byte ciphertexts. That is the LM hash [@wp-lan-manager, @wp-nt-lan-manager].

The LAN Manager password hash from 1987. Constructed by uppercasing the password, truncating or padding to 14 characters, splitting into two 7-byte halves, and DES-encrypting the constant `KGS!@#$%` with each half as a key. The two halves are independent, the password is case-insensitive, and there is no salt. Every property of this construction enables an attack class that survives into NTLMv2 [@wp-lan-manager].

The eight-byte constant KGS!@#$% is what you get when somebody types "KGS" and then mashes shift-1, shift-2, shift-3, shift-4, shift-5 on a 1980s American IBM keyboard. The constant is in the protocol because the protocol predates the cryptographic-engineering norm that constants should look random. It would not survive a 2026 design review; in 1987 nobody asked.

Every choice tells a story about 1987. Uppercase, because some clients normalised case anyway and the developers wanted authentication to "just work" across mixed locale settings. Fourteen characters, because that was the field width DOS dictated. Two halves, because a 56-bit DES key already maxed out the practical computation; nobody was going to chain two DES operations through a feedback function with that much per-keystroke latency. No salt, because the deployment model was one server, one user database, and identical-password collisions were a feature for the help desk, not a leak.

The result is password-equivalent: anyone who possesses the LM hash is the user, forever, regardless of how the wire protocol presents the credential.

Six years later, July 27, 1993, Windows NT 3.1 ships. NTLM(v1) arrives with it [@wp-nt-lan-manager]. The NT-hash is what you would design if you started over with mid-1990s assumptions but were not yet willing to abandon DES at the response layer. It is simpler than the LM hash and stronger in exactly one place: NT-hash = MD4(UTF-16LE(password)) [@wp-nt-lan-manager]. No truncation. No case folding. Sixteen bytes of output. The hash is still password-equivalent; what changes is that the input to the hash is now whatever Unicode string the user typed, in full.

The wire protocol around the NT-hash is the famous three-message handshake. NEGOTIATE from the client. CHALLENGE from the server (an eight-byte random nonce). AUTHENTICATE from the client, carrying a DES-based response computed from the NT-hash and the server challenge. The whole exchange is self-contained: nothing in the three messages binds the authentication to a particular transport, a particular client, a particular server, or a particular service [@ms-nlmp]. That property -- the absence of binding -- is the property NTLM relay will eat for the next twenty-five years.

`MD4(UTF-16LE(password))`. Sixteen bytes. The single long-term secret that every NTLM authentication ever performed for a given user derives from. Possession of the NT-hash is mathematically equivalent to possession of the password for every authentication purpose. NTLMv2 changes the response computation but not the hash [@wp-nt-lan-manager]. timeline title NTLM and Windows authentication, 1987-2027 1987 : LAN Manager 1.0 ships : LM hash construction 1993 : Windows NT 3.1 : NTLMv1 + NT-hash MD4(UTF-16LE(pwd)) 1998 : NT 4.0 SP4 : NTLMv2 with HMAC-MD5 and AV_PAIRS 2000 : Windows 2000 : Kerberos is the default; NTLM demoted to fallback 2008 : MS08-068 patches SMB self-relay (CVE-2008-4037) 2015 : Windows 10 RTM ships Credential Guard 2019 : CVE-2019-1040 Drop the MIC (Simakov/Zinar) 2021 : PetitPotam (Gilles) + ESC8 (Schroeder/Christensen) 2023 : Palko commits to removing NTLM (October 11) 2024 : NTLM marked deprecated (June); NTLMv1 removed in 24H2/Server 2025 2025 : KB 5064479 enhanced NTLM auditing 2026 : Phase 1 (audit) + IAKerb/Local KDC pre-release (Phase 2) 2027 : Phase 3 -- NTLM disabled by default (next major Windows release)

The third revision arrives with NT 4.0 Service Pack 4, October 1998. NTLMv2 throws away DES at the response layer and replaces it with HMAC-MD5. It introduces a client challenge (so the response is no longer purely a function of the server's choice). It introduces AV_PAIRS, a small TLV structure carrying the target name, a timestamp, and -- in much later retrofits -- the channel binding hash and message integrity field [@ms-nlmp, @wp-nt-lan-manager]. NTLMv2 defeats pre-computation attacks against the response. It does not change the long-term secret. The NT-hash is still the NT-hash; possession is still authority.An intermediate variant, NTLM2 Session Security, shipped in NT 4.0 SP4 alongside NTLMv2 and is the dead end most often confused for v2. It added an 8-byte client challenge to the NTLMv1 DES envelope without touching the long-term hash, hoping to defeat pre-computation while preserving wire compatibility. It survived only as a transitional LMCompatibilityLevel setting; nothing in the modern attack catalogue treats NTLM2 SS as a distinct target [@ms-nlmp].

Property	LM hash (1987)	NTLMv1 (1993)	NTLMv2 (1998)
Hash function for the long-term secret	DES of constant with password halves	MD4(UTF-16LE(password))	MD4(UTF-16LE(password))
Case-sensitive	No (uppercase only)	Yes	Yes
Max input length	14 characters (truncated)	Unlimited Unicode	Unlimited Unicode
Salted	No	No	Per-exchange client challenge + timestamp
Response keyed MAC	DES (3 keys, 56-bit each)	DES (3 keys, 56-bit each)	HMAC-MD5
Binds to target server name	No	No	AV_PAIR `MsvAvTargetName` (retrofit)
Binds to TLS endpoint	No	No	AV_PAIR `MsvAvChannelBindings` (retrofit)
Possession of hash = authority	Yes	Yes	Yes

The two production response constructions on top of the same NT-hash. NTLMv1 chains three 56-bit DES operations across `K1 = NT-hash[0:7]`, `K2 = NT-hash[7:14]`, `K3 = NT-hash[14:16] || \x00\x00\x00\x00\x00`, encrypting the eight-byte server challenge under each. The third sub-key has only 16 bits of real entropy. NTLMv2 replaces all three DES operations with one HMAC-MD5 over `server_challenge || client_challenge || timestamp || av_pairs`, keyed by `NTOWFv2 = HMAC_MD5(NT-hash, UNICODE(Upper(user) || domain))` [@ms-nlmp, @wp-nt-lan-manager].

Then comes Windows 2000, and Kerberos. Microsoft's plan was simple: in a domain, Kerberos handles everything; NTLM stays around as a compatibility blanket for the cases Kerberos cannot cover yet [@microsoft-ntlm-overview]. The trouble was that "the cases Kerberos cannot cover yet" turned out to be a permanent set, not a transitional one. Twenty-three years later, the same four cases would be the table-of-contents of Microsoft's NTLM-removal plan [@palko-2023-evolution]:

No domain-controller line-of-sight. A laptop on a hotel Wi-Fi authenticating to a corporate file share through a VPN tunnel terminator has no Kerberos KDC to talk to. NTLM does not need one.
Local accounts. A user signing into a workgroup machine or a domain-joined machine's local SAM has no domain at all; Kerberos has nothing to authenticate against.
No service principal name. Kerberos requires a known SPN for the target service. Connect to a server by raw IP, by an alias DNS name not yet in the SPN database, or by a CNAME the operator forgot to register -- there is no SPN, so Kerberos cannot run.
Hard-coded NTLM. Application code that calls AcquireCredentialsHandleW(..., "Ntlm", ...) or RPC code that asks for RPC_C_AUTHN_WINNT directly bypasses the negotiator and forces NTLM regardless of what is available.

The Simple and Protected GSS-API Negotiation Mechanism. When two parties want to authenticate but do not know which security mechanism they share, SPNEGO offers a list and picks the best one both support. On Windows the SSPI provider is called `Negotiate`, and it has historically chosen Kerberos when possible and NTLM otherwise [@microsoft-ntlm-overview]. The "otherwise" path is where every modern NTLM attack lives.

Each fallback case is one shutter through which NTLM continues to leak into a Kerberos-by-default world. The demotion was supposed to be terminal. Why did the four fallback cases turn out to cover most of the real-world authentication surface, and what does that look like on the wire?

3. The Wire: Three Messages and One Hash

Most defenders have never read an NTLM authentication off the wire. The cryptography is short enough to fit on one screen, and the structural property that drives the next 28 years of attacks is visible inside those three messages. The point of this section is to make that property impossible to miss.

NEGOTIATE, CHALLENGE, AUTHENTICATE

The client opens with NEGOTIATE, advertising its capability flags: which signing modes it supports, whether it is willing to do session security, whether it is asking for extended session keys, and so on. The server replies with CHALLENGE. The body of CHALLENGE contains a single 64-bit nonce (the server challenge) and a TLV blob called TargetInfo: a list of attribute-value pairs the server wants to bind into the authentication [@ms-nlmp].

The client computes its response and sends AUTHENTICATE. That message contains the user name, the workstation name, the response itself, the AV_PAIRS the client wants to echo back, a Message Integrity Code field (HMAC-MD5 of the concatenation of all three NTLM messages), and -- in EPA-enforced deployments -- a hash of the TLS endpoint certificate placed in the MsvAvChannelBindings AV_PAIR [@ms-nlmp, @ms-epa-wcf].

sequenceDiagram autonumber participant C as Client participant S as Server C->>S: NEGOTIATE (capability flags) S->>C: CHALLENGE (server nonce 8B, TargetInfo AV_PAIRS) Note over C: NTOWFv2 = HMAC_MD5(NT-hash, UNICODE(Upper(user) plus domain)) Note over C: NTProofStr = HMAC_MD5(NTOWFv2, ServerChallenge plus temp) where temp = version plus Z(6) plus Time plus ClientChallenge plus Z(4) plus ServerName plus Z(4) C->>S: AUTHENTICATE (user, NTProofStr, temp, MIC, CBT) Note over S: Server replays the same HMAC_MD5 with its copy of the NT-hash to verify

The NTLMv2 response, verbatim

[MS-NLMP] §3.3.2 gives the response algorithm in three lines of pseudocode [@ms-nlmp]:

$$\text{NTOWFv2} = \text{HMAC-MD5}\big(\text{NT-hash},\ \text{UNICODE}(\text{Upper(user)} \mathbin{|} \text{domain})\big)$$

$$\text{temp} = \text{Responserversion} \mathbin{|} \text{HiResponserversion} \mathbin{|} Z(6) \mathbin{|} \text{Time} \mathbin{|} \text{ClientChallenge} \mathbin{|} Z(4) \mathbin{|} \text{ServerName} \mathbin{|} Z(4)$$

$$\text{NTProofStr} = \text{HMAC-MD5}\big(\text{NTOWFv2},\ \text{ServerChallenge} \mathbin{|} \text{temp}\big)$$

The temp byte string carries two version bytes, six zero bytes, the 8-byte FILETIME, the 8-byte client challenge, four zero bytes, the AV_PAIR list the spec calls ServerName, and a final four zero bytes. The client sends NTProofStr || temp as the response. The server, which holds its own copy of NT-hash for the user (cached or fetched from the domain controller), recomputes the same three lines and checks equality. That is the entire response protocol.

Notice what NTOWFv2 is. It is a function of two inputs: the NT-hash, and a normalised user/domain string. Both inputs are static once the user logs in. Knowing the NT-hash is sufficient to compute every NTLMv2 response forever, against every server, for every challenge, until the password changes [@wp-pass-the-hash].Why is HMAC-MD5 considered fine for the response side but considered weak for the key side? The response side is being asked: given a known key, can a verifier check a freshly computed tag? HMAC-MD5 still answers that without a known break. The key side is being asked: given a stolen 16-byte value, how hard is it to mount a precomputation attack on candidate passwords? MD4 of UTF-16LE is so cheap on modern GPUs that an 8-character password is in the minutes-to-hours range. Hashcat lists NetNTLMv2 (mode 5600) as the practical attack format and benchmarks NTLM cracking accordingly.

AV_PAIRS, MIC, and channel binding -- retrofits all the way down

AV_PAIRS is a TLV structure. The server places target NetBIOS, target DNS, a timestamp, and various flags into the TargetInfo of CHALLENGE. The client echoes the structure into AUTHENTICATE and adds two retrofit fields when both ends agree to use them [@ms-nlmp]:

MsvAvFlags is a bit field signalling that the client has computed a MIC and is therefore willing to bind all three NTLM messages together.
MsvAvChannelBindings holds a hash of the server's TLS endpoint certificate when the authentication is happening over an HTTPS-style transport that the client can see. This is the Extended Protection for Authentication (EPA) channel-binding-token mechanism [@ms-epa-wcf].

The MIC field itself is added to AUTHENTICATE. It is HMAC_MD5(ExportedSessionKey, NEGOTIATE || CHALLENGE || AUTHENTICATE). ExportedSessionKey coincides with SessionBaseKey in the common case; when NTLMSSP_NEGOTIATE_KEY_EXCH is set, the client generates a random session key, encrypts it under KeyExchangeKey, and ExportedSessionKey is the random key. The MIC always uses ExportedSessionKey, and it is intended to make tampering with any of the three messages detectable [@ms-nlmp].

A length-prefixed TLV list carried inside the `TargetInfo` byte string of NTLM `CHALLENGE` and the AV-list byte string of `AUTHENTICATE`. AV_PAIRS hold the target server names, a timestamp, the `MsvAvFlags`, the `MsvAvChannelBindings` (EPA), and the optional `MsvAvTargetName` (SPN). NTLMv2 reserved AV_PAIRS in 1998 but most of the fields are 2009-2019-era retrofits onto the original wire format [@ms-nlmp]. A 16-byte HMAC-MD5, keyed by `ExportedSessionKey`, computed over the concatenation of the NTLM `NEGOTIATE`, `CHALLENGE`, and `AUTHENTICATE` messages and embedded in `AUTHENTICATE`. (`ExportedSessionKey` equals `SessionBaseKey` unless `NTLMSSP_NEGOTIATE_KEY_EXCH` is negotiated; the MIC always uses the exported key.) Introduced as a retrofit so that a man-in-the-middle relay could not silently strip the signing-required flags from the negotiate phase. Drop-the-MIC (CVE-2019-1040) demonstrated that the *presence* of the MIC was itself a negotiated property and could be stripped [@ms-nlmp, @nvd-cve-2019-1040]. A hash of the server's TLS endpoint certificate placed in `MsvAvChannelBindings` so the authentication is bound to the specific TLS channel the client believed it was talking over. When both ends enforce CBT, an attacker who terminates one TLS channel and opens a different TLS channel to the real server cannot reuse the captured NTLM response. Microsoft documents three enforcement modes: None, Partial, and Full [@ms-epa-wcf].

Run it

The whole thing fits in a few dozen lines of JavaScript. The point of the runnable demo is not to teach you to crack hashes; it is to make the password-equivalence claim land as code rather than as an assertion.

{` // Demonstrates the [MS-NLMP] NTLMv2 response algorithm. // // The point: NTProofStr is a deterministic function of the NT-hash plus // values that travel in the clear or that the attacker controls. If you // possess the NT-hash, you can compute NTProofStr for any (challenge, // client_challenge, timestamp, av_pairs). That is the protocol-level // proof of password-equivalence. // // In a real client, NT-hash = MD4(UTF-16LE(password)). MD4 is removed from // most modern browser/Node crypto providers, so we use a precomputed // NT-hash for password "Summer2026!" and focus on the structural property // that matters: knowledge of those 16 bytes is sufficient forever.

const crypto = require("crypto");

// Precomputed NT-hash for password "Summer2026!" (16 bytes, hex): // reference value verified against impacket's NTOWFv1() helper offline. const ntHash = Buffer.from("41aed72cec76816423703d8e545eea31", "hex");

const user = "alice", domain = "CONTOSO";

// NTOWFv2 = HMAC-MD5(NT-hash, UNICODE(Upper(user) || domain)) const userDomain = Buffer.from((user.toUpperCase() + domain), "utf16le"); const ntowfv2 = crypto.createHmac("md5", ntHash).update(userDomain).digest();

// NTProofStr = HMAC-MD5(NTOWFv2, ServerChallenge || temp) // where temp = ResponserVersion(0x01) || HiResponserVersion(0x01) || Z(6) || // Time(8) || ClientChallenge(8) || Z(4) || ServerName || Z(4) const serverChal = Buffer.from("0123456789abcdef", "hex"); const clientChal = Buffer.from("fedcba9876543210", "hex"); const ts = Buffer.alloc(8); // any 8-byte FILETIME const serverName = Buffer.from("00000000", "hex"); // empty AV_PAIR list const tempBuf = Buffer.concat([ Buffer.from("0101000000000000", "hex"), // version 1.1 || Z(6) ts, clientChal, Buffer.from("00000000", "hex"), // Z(4) serverName, Buffer.from("00000000", "hex"), // Z(4) ]); const ntProofStr = crypto.createHmac("md5", ntowfv2) .update(Buffer.concat([serverChal, tempBuf])).digest();

console.log("NT-hash :", ntHash.toString("hex")); console.log("NTOWFv2 :", ntowfv2.toString("hex")); console.log("NTProofStr :", ntProofStr.toString("hex")); console.log(""); console.log("Now change serverChal/clientChal/ts and rerun: NTProofStr changes,"); console.log("but only the first line of input (the NT-hash) is a secret. The"); console.log("rest travels in the clear inside the three NTLM messages. Possessing"); console.log("ntHash IS possessing the credential -- forever, on every server."); `}

The demo prints three lines, then a punchline. The lines are not impressive; the punchline is.

Key idea: The NT-hash is not a credential; it is the credential. Knowing the hash IS authentication. Every pass-the-hash tool ever written, from Paul Ashton's modified Samba in 1997 to the present, is a different packaging of the same realisation: an authentication that is a deterministic function of a static secret turns possession of that secret into permanent authority [@wp-pass-the-hash].

If possession of the hash is the protocol, the last 28 years of attacks are not surprises -- they are obvious next steps. What are those steps?

4. The Three-Decade Attack Cascade

Five generations of attacks. Each one is named, each one is dated, each one took Microsoft years to respond to, and each Microsoft response always closed the primitive and left the class alive. They are not five surprises; they are five logical consequences of the wire protocol you just read.

Generation 1 -- 1997: Pass-the-Hash (Paul Ashton)

The first published exploit of password-equivalence comes from Paul Ashton, posted to the Bugtraq mailing list in 1997. Ashton ships a patch against the Samba SMB client that takes a 16-byte NT-hash directly on the command line, instead of asking for a cleartext password [@wp-pass-the-hash]. The patch is a one-paragraph change against an open-source codebase, and that fact -- the brevity of the change -- is the lesson.

The NTLM response function has no input that depends on knowing the plaintext password. Replacing the plaintext-password input with a literal NT-hash input does not change the bytes that go on the wire. The server cannot tell the difference.

Microsoft's response, for more than a decade, is do not lose your hashes. There is no protocol fix because there is no protocol bug to fix; the design is doing exactly what it was designed to do. The response is operational guidance: tier your admins, scrub LSASS, do not run privileged sessions on workstations.

Generation 2 -- 2001: NTLM Relay (Sir Dystic / SMBRelay)

If you do not have to steal the hash to use the credential, you also do not have to steal the live exchange. You can simply relay it. On March 31, 2001, at the @lanta.con conference, Sir Dystic of the Cult of the Dead Cow (Josh Buchbinder) releases SMBRelay: a small program that accepts an SMB connection on port 139, opens a second SMB connection back to another server, and shuttles the NEGOTIATE / CHALLENGE / AUTHENTICATE messages between the two sides [@cdc-smbrelay].

The attack works because the three NTLM messages are not bound to a particular client, server, or service. Whoever sits between them can replay the credential against whatever destination the attacker chooses, as that user, for the duration of the exchange.The colourful provenance matters. The Cult of the Dead Cow released SMBRelay alongside Back Orifice 2000; "Sir Dystic" is the same Josh Buchbinder who later wrote the SMBProxy authentication-relay framework. The point is not the chrome -- it is that the relay class was disclosed publicly at a conference in 2001, with working code on the cDc website, and Microsoft did not ship a fix for the trivial case (self-relay) until November 2008 [@cdc-smbrelay].

Microsoft's response is incomplete and slow. SMB signing exists from Windows 2000 onward, but it is off by default on member servers for more than a decade [@ms-smb-signing]. MS08-068, in November 2008, finally patches the self-relay case (CVE-2008-4037): the SMB server now refuses to accept an authentication that the client itself just generated against the same server [@nvd-cve-2008-4037]. NVD notes that reliable sources report the original fix as insufficient for CVE-2000-0834 -- meaning the patch closed exactly the self-relay case and nothing else [@nvd-cve-2008-4037]. Seven years to fix the simplest variant; the cross-server relay class is still wide open.

Generation 3 -- 2008-2014: Credential Theft as a Service

By 2008, the operational guidance "do not lose your hashes" stops being defensible. On February 29, 2008, Hernan Ochoa releases the Pass-the-Hash Toolkit v1.3, two native Windows binaries called iam.exe and whosthere.exe that read the NT-hash out of LSASS memory and inject it into a new logon session. PtH stops being a Linux-and-Samba trick and becomes a Windows-everywhere reality.

Three years later, Benjamin Delpy publishes Mimikatz. The first version is closed-source, released in May 2011 [@wired-greenberg-mimikatz]. By April 6, 2014, the GitHub repository goes public with the version string "mimikatz 2.0 alpha (x86) release 'Kiwi en C' (Apr 6 2014 22:02:03)" [@gh-mimikatz]. The repo description is a near-perfect summary of what LSASS is to an attacker: "extract plaintexts passwords, hash, PIN code and kerberos tickets from memory. mimikatz can also perform pass-the-hash, pass-the-ticket or build Golden tickets" [@gh-mimikatz]. LSASS becomes the universal credential oracle.Delpy did not intend Mimikatz to be a weapon. Wired's Andy Greenberg documents the trajectory in detail: Delpy "released it publicly in May 2011, but as a closed source program." In mid-2011, Delpy learned for the first time that Mimikatz had been used in an intrusion of an unnamed foreign government network. That September, it appeared again in the landmark DigiNotar hack. An unidentified man was found at his laptop in his Moscow conference hotel room -- the stranger apologised and quickly left, claiming a wrong room. A second man in a dark suit later demanded a copy of Mimikatz on a USB drive. He went open-source partly fearing for his own safety after the hotel confrontations, and partly to make the security industry confront what lived in LSASS [@wired-greenberg-mimikatz].

Microsoft's response is structural and specific. Credential Guard ships in Windows 10 RTM (Enterprise and Education editions), July 29, 2015 [@ms-credential-guard]. It uses Virtualization-Based Security to isolate lsaiso.exe in VTL1 within the same root partition; the kernel can no longer read NTLM hashes or Kerberos TGTs even at SYSTEM-level privilege. Protected Users and Restricted Admin in Server 2012 R2 / Windows 8.1 narrow the surface further. LSASS-as-PPL adds a process-protection layer between user-mode debuggers and the LSASS address space [@ms-credential-guard].

Credential Guard works -- against the credential-theft class. It does nothing against credential-use. An attacker who never extracts a hash, because they never need to, sails right past it. Relay does not need the hash. Coercion does not need the hash. ESC8 does not need the hash. That is the next generation.

Generation 4 -- 2018-2021: Forced-Authentication Coercion

In 2018 at DerbyCon 8, Lee Christensen releases SpoolSample, known publicly as "PrinterBug." The GitHub description is exact: "PoC tool to coerce Windows hosts authenticate to other machines via the MS-RPRN RPC interface" [@gh-spoolsample]. The trick is that the Print Spooler service runs as SYSTEM, accepts a remote RPC call (RpcRemoteFindFirstPrinterChangeNotificationEx) that takes a UNC path, and dutifully NTLM-authenticates back to whatever path the caller named -- on behalf of the machine account. Any Windows service running as SYSTEM that accepts a UNC path is a confused deputy that will authenticate on demand.

Microsoft's initial classification of SpoolSample was *authenticated-only / by design*: a caller needed valid domain credentials to reach the spooler endpoint, and authenticated callers triggering machine-account authentications was deemed within spec. The classification held through 2018, 2019, and most of 2020. PetitPotam broke it, because PetitPotam used MS-EFSRPC over LSARPC, which accepts *unauthenticated* binds on a domain controller's named-pipe interface. With the authentication requirement gone, "by design" stopped being a coherent defence. Microsoft started shipping fixes.

Marina Simakov and Yaron Zinar of Preempt (now CrowdStrike) publish "Drop the MIC" on June 11, 2019. The vulnerability is CVE-2019-1040: a tampering bug where "a man-in-the-middle attacker is able to successfully bypass the NTLM MIC (Message Integrity Check) protection" [@crowdstrike-drop-the-mic, @nvd-cve-2019-1040]. The bypass works by stripping the NTLMSSP_NEGOTIATE_SIGN and NTLMSSP_NEGOTIATE_ALWAYS_SIGN flags from the initial NEGOTIATE, removing the MIC field from AUTHENTICATE, and removing the Version field that drives MIC detection.

Servers that should have required a MIC silently accept the modified message. The MIC -- the retrofit integrity layer that was supposed to make tampering detectable -- turns out to be itself untethered to the negotiation [@crowdstrike-drop-the-mic].

Lionel Gilles (topotam77) publishes PetitPotam in July 2021, CVE-2021-36942. The GitHub repository description reads: "PoC tool to coerce Windows hosts to authenticate to other machines via MS-EFSRPC EfsRpcOpenFileRaw or other functions". The decisive new property compared to SpoolSample is that PetitPotam needs no credentials against a domain controller: LSARPC accepts unauthenticated binds, so the coercion can be triggered by an attacker who has merely joined the network.

In 2022, Remi Gascou (p0dalirius) publishes Coercer, a Python script that consolidates the coercion class across MS-RPRN, MS-EFSR, MS-DFSNM, MS-FSRVP, and many more RPC interfaces. The README describes it succinctly: "A python script to automatically coerce a Windows server to authenticate on an arbitrary machine through many methods" [@gh-coercer].

Generation 5 -- 2021: ADCS Web-Enrollment Relay (ESC8)

On June 17, 2021, Will Schroeder and Lee Christensen of SpecterOps publish "Certified Pre-Owned," a whitepaper and matching blog post that maps eight new attack classes against Active Directory Certificate Services [@specterops-cert-preowned-blog, @specterops-cert-preowned-pdf]. ESC1 through ESC7 are template and configuration weaknesses. ESC8 is the keystone of this article.

ESC8 says: AD CS Web Enrollment endpoints (/certsrv/) accept NTLM authentication. Coerce a server's machine account to authenticate to your relay listener; relay the authentication to /certsrv/; enroll the relayed identity for a machine-template certificate; use that certificate to perform PKINIT against the KDC and request a TGT [@specterops-cert-preowned-blog]. The NTLM-vs-Kerberos boundary stops being a meaningful one. NTLM is the protocol on the front side of the attack; Kerberos is the trust token on the back side; the certificate is the conduit between them.

The point of ESC8 is not just that it works. The point is that it works against a perfectly retrofitted environment. SMB signing did not enter the chain. LDAP signing did not enter the chain. EPA was supposed to enter the chain on the /certsrv/ side but was unevenly deployed. Credential Guard never had a hash to protect.

flowchart TD A[Gen 1 -- 1997 Pass-the-Hash
Paul Ashton, modified Samba] A --> A1[Response: operational guidance
Do not lose your hashes] A1 --> B[Gen 2 -- 2001 SMBRelay
Sir Dystic, atlanta.con] B --> B1[Response: MS08-068 2008
Patches self-relay only] B1 --> C[Gen 3 -- 2008-2014 LSASS extraction
Ochoa PtH Toolkit, Delpy Mimikatz] C --> C1[Response: Credential Guard 2015
Closes theft; not use] C1 --> D[Gen 4 -- 2018-2021 Coercion
SpoolSample, Drop-the-MIC, PetitPotam, Coercer] D --> D1[Response: KB 5005413, EPA
Closes primitive; not class] D1 --> E[Gen 5 -- 2021 ESC8
Schroeder/Christensen Certified Pre-Owned] E --> E1[Response: remove NTLM] sequenceDiagram autonumber actor A as Attacker participant V as "Victim SYSTEM service (Spooler, EFSR, DFSNM)" participant R as Attacker NTLM relay participant T as "Target service (LDAP, SMB, certsrv)" A->>V: RPC call with UNC path \\attacker\share V->>R: NTLM NEGOTIATE (as machine account) R->>T: Open new authenticated session T->>R: NTLM CHALLENGE R->>V: Forward CHALLENGE V->>R: NTLM AUTHENTICATE (signed by machine account) R->>T: Forward AUTHENTICATE -- T treats attacker session as the victim

Generation	Primitive	Public date	Microsoft response	What survived
1. Pass-the-Hash	Use the hash directly	1997, Paul Ashton, Bugtraq [@wp-pass-the-hash]	Operational guidance	Hash is still password-equivalent on the wire
2. NTLM relay (SMB)	Forward live exchange	March 31, 2001, Sir Dystic, @lanta.con [@cdc-smbrelay]	MS08-068 (Nov 2008) -- self-relay only [@nvd-cve-2008-4037]	Cross-server, cross-protocol relay
3. LSASS extraction	Steal hashes from memory	Feb 2008 (Ochoa); May 2011 closed / Apr 2014 open (Delpy) [@gh-mimikatz, @wired-greenberg-mimikatz]	Credential Guard (Jul 29, 2015) [@ms-credential-guard]	Hash use outside LSASS path; SYSTEM-level Mimikatz on the SAM
4. Coercion	Make SYSTEM authenticate on demand	2018 SpoolSample [@gh-spoolsample]; 2019 Drop-the-MIC [@crowdstrike-drop-the-mic, @nvd-cve-2019-1040]; 2021 PetitPotam; 2022 Coercer [@gh-coercer]	Per-interface patches; KB 5005413 EPA recipe [@ms-kb5005413]	The pattern of "SYSTEM holds an unanchored credential"
5. ESC8 ADCS Web Enrollment relay	NTLM coerce -> /certsrv/ -> TGT via PKINIT	June 17, 2021, Schroeder/Christensen, "Certified Pre-Owned" [@specterops-cert-preowned-blog, @specterops-cert-preowned-pdf]	KB 5005413; AD CS hardening; eventually Phase 3 of NTLM removal	Kerberos relay class on the other side (KrbRelay/KrbRelayUp) [@gh-krbrelayup]

KrbRelayUp -- a universal no-fix local privilege escalation in windows domain environments where LDAP signing is not enforced (the default settings). -- Dec0ne, KrbRelayUp README [@gh-krbrelayup]

The reader who started Section 4 believing "if I patch each named NTLM attack, the protocol is safe" finishes Section 4 believing something else. Every retrofit patches a primitive; none addresses the existence of the fallback path. The next attack is always one cross-protocol step away. The retrofit strategy is structurally incapable of closing the class.

By the end of 2021, NTLM-the-protocol cannot be removed because four use cases require it, and NTLM-the-fallback cannot be kept because ESC8 turned it into a domain-takeover oracle. Something has to change. What?

5. The Retrofit Strategy and Its Funeral

Before naming the answer, name the strategy that failed. Microsoft's defensive cadence between 2001 and 2021 splits into three families, each effective against a named primitive, each defeated by an unanchored cousin of that primitive.

Family A -- Per-protocol message authentication

SMB signing. LDAP signing and sealing. The idea is to anchor the content of each authenticated request inside a per-session signature derived from the authentication. SMB signing introduces an HMAC over every SMB message keyed by a per-session SigningKey; LDAP signing and sealing do the equivalent for LDAP operations [@ms-smb-signing].

Family A works when the target protocol enforces it. SMB-to-SMB relay against an SMB server with required signing fails; LDAP-to-LDAP relay against an LDAP server with required signing fails. The strategy assumes the attacker stays in the same protocol family. Cross-protocol relay -- SMB authentication relayed to LDAP, or SMB authentication relayed to /certsrv/ -- defeats it. The MS-EFSR coercion can produce an authentication that originates "as if from SMB" and gets accepted by an unrelated HTTPS service that ignores the SMB signing flag entirely [@nvd-cve-2019-1040, @specterops-cert-preowned-blog].

Family B -- Per-channel binding tokens and the MIC

EPA (channel binding) and the NTLMv2 MIC are the response to cross-protocol relay. Both try to tie the authentication to the specific channel the client believes it is using. EPA places a hash of the TLS endpoint certificate into the MsvAvChannelBindings AV_PAIR; an HTTPS server with EPA required compares it to its own certificate's hash and rejects the authentication if they do not match [@ms-epa-wcf]. The MIC binds all three NTLM messages together so a relay cannot strip the signing-required flags from NEGOTIATE after the client sets them [@ms-nlmp].

Family B works when both ends agree to enforce. Drop-the-MIC (CVE-2019-1040) demonstrated that the presence of the MIC was negotiated and could be stripped, so a server that supported MIC-less clients silently accepted MIC-less messages from a relay [@crowdstrike-drop-the-mic, @nvd-cve-2019-1040]. EPA suffers from the same enforcement-asymmetry: when an IIS endpoint runs with policyEnforcement="None" or "Partial", the binding is not checked. KB 5005413 published the explicit <extendedProtectionPolicy policyEnforcement="Always" /> recipe for /certsrv/ because field deployments had been running with weaker settings [@ms-kb5005413].

Family C -- Credential isolation

Credential Guard. LSASS-as-PPL. Protected Users. Restricted Admin. These attack the theft surface. Credential Guard moves the NT-hash into lsaiso.exe inside VTL1; the kernel can no longer read it. Microsoft now ships it enabled by default on domain-joined, non-DC systems running Windows 11 22H2 and Server 2025 on hardware that meets the requirements [@ms-credential-guard].

Family C is honest about what it covers. It does nothing about coercion flows that never touch the NT-hash. PetitPotam and ESC8 do not need a hash; the relay session uses the live NTLM exchange and is never persisted. Credential Guard cannot help.

Family	What it closes	What it does not close	Defeating attack
A. Per-protocol message auth (SMB/LDAP signing)	Same-protocol relay against the target	Cross-protocol relay; targets that do not enforce	LDAP relay from SMB coercion [@nvd-cve-2019-1040]; ESC8 relay to /certsrv/
B. Channel binding (EPA) + MIC	Same-channel relay through TLS termination	MIC stripping in negotiation; EPA at None/Partial; non-TLS targets	Drop-the-MIC [@nvd-cve-2019-1040]; under-enforced EPA [@ms-kb5005413]
C. Credential isolation (Credential Guard, LSASS-PPL)	Hash theft from running LSASS	Hash use in live relay; SAM extraction from disk; coercion	ESC8 + PetitPotam [@specterops-cert-preowned-blog]; SAM hive offline [@ms-credential-guard]

Key idea: Every retrofit Microsoft has shipped against NTLM attacks one primitive of NTLM. None address the existence of NTLM as a fallback path. ESC8 was the funeral of the retrofit strategy because ESC8 turned a fully retrofitted environment into a domain takeover without defeating any retrofit.

Note: "Certified Pre-Owned" did not break a Microsoft fix; it composed the existing infrastructure. The chain assumes SMB signing is on, EPA is on (somewhere), and Credential Guard is on. It still works, because none of those controls cover the path that goes Coercer -> NTLM relay -> AD CS Web Enrollment -> PKINIT. After 2021, the question stopped being "what's the next retrofit?" and became "what does it take to remove the fallback?" [@specterops-cert-preowned-blog, @ms-kb5005413].

To remove ESC8 without rebuilding AD CS, Microsoft has to remove NTLM. To remove NTLM, Microsoft has to remove the four reasons NTLM existed as a fallback in the first place. What does that look like in shippable form?

6. The Breakthrough: Closing the Fallback

October 11, 2023. Matthew Palko, Windows IT Pro Blog. "The evolution of Windows authentication." For the first time in twenty-three years, Microsoft publicly commits to removing NTLM, not restricting it, and names the three load-bearing features that make removal possible [@palko-2023-evolution].

The plan starts where every honest plan starts -- by stating the problem in its own words. There are four fallback reasons NTLM persisted: no DC line-of-sight, no domain at all (local accounts), no SPN for the target, and hard-coded NTLM in application code [@palko-2023-evolution]. Each gets an engineered answer. The four-to-three correspondence (three protocols plus one refactor) is the new architecture.

Our end goal is eliminating the need to use NTLM at all to help improve the security bar of authentication for all Windows users. -- Matthew Palko, Microsoft Windows IT Pro Blog, October 11, 2023 [@palko-2023-evolution]

IAKerb -- closing "no DC line-of-sight"

IAKerb stands for Initial and Pass Through Authentication Using Kerberos V5 and the GSS-API. The IETF draft has a four-author list -- Benjamin Kaduk, Jim Schaad, Larry Zhu, and Jeffrey E. Altman -- and a quiet history [@draft-ietf-kitten-iakerb].

The premise is simple. A client wants to authenticate to an application server with Kerberos but cannot reach a KDC -- maybe the client is behind a firewall, maybe the KDC is only reachable from the server's side of a VPN. IAKerb wraps the Kerberos AS-REQ and TGS-REQ messages inside GSS-API tokens and asks the application server to proxy them to a KDC that the server can reach. The client never opens a direct TCP/UDP connection to a KDC; the application server acts as the carrier.

The honesty duty: IAKerb's IETF draft (`draft-ietf-kitten-iakerb`) was marked "Dead WG Document" on August 29, 2019, by Robbie Harwood [@draft-ietf-kitten-iakerb]. Harwood's note read, roughly, that IAKerb was historical at that point and the working group had no interest left. The last revision (`-03`) is from March 30, 2017, by Benjamin Kaduk. Microsoft is now reviving the protocol in 2023-2026 for Windows 11 and Windows Server 2025 -- without acknowledging the dead-WG status in its own blog posts. This is the gap between an IETF standards-track document and what a vendor ships; the article reports both [@draft-ietf-kitten-iakerb, @palko-2023-evolution]. Initial and Pass Through Authentication Using Kerberos V5 and the GSS-API. A GSS-API-wrapped Kerberos exchange in which the client cannot reach a KDC directly and the application server proxies `AS-REQ` / `TGS-REQ` on the client's behalf. Defined by `draft-ietf-kitten-iakerb` (IETF kitten WG, currently a Dead WG Document). MIT Kerberos has shipped IAKerb since 1.9 (released February 2011); Apple ships `GSS_IAKERB_MECHANISM` since macOS 10.14. Microsoft is implementing IAKerb in Windows 11 / Server 2025 [@draft-ietf-kitten-iakerb, @palko-2023-evolution, @ms-cuomo-ad2025].

Local KDC -- closing "no domain at all"

Local accounts in the machine SAM have never had a KDC. Workgroup machines have no domain at all. Both cases force NTLM today. The fix is conceptually trivial: run a tiny Kerberos KDC against the local SAM, exposed only through IAKerb-wrapped exchanges so the wire protocol is the same as the trust-traversing case [@palko-2023-evolution, @ms-cuomo-ad2025].

This is the late-adopter move that surprises Linux-side practitioners. MIT Kerberos has had IAKerb since 1.9 (released February 2011). Samba has been working on a localkdc for years. At FOSDEM 2025 (February 2, 2025), Alexander Bokovoy and Andreas Schneider gave a talk explicitly framed as "localkdc -- a general local authentication hub" [@cryptomilk-localkdc]. Schneider's companion blog post the next week summarised the work: a parallel local-authentication hub for Linux that interoperates with the IAKerb wire format Windows is now adopting [@cryptomilk-localkdc].

A small Kerberos Key Distribution Center process that runs against a machine's local user database (the SAM on Windows; a file or sssd on Linux) and is exposed only through IAKerb. It lets local-account authentications use Kerberos under the same Negotiate / NEGOEX wire envelope used by domain authentications -- removing one of the four reasons NTLM persisted. Shipping in Windows 11 / Server 2025 [@palko-2023-evolution, @ms-cuomo-ad2025]; parallel Linux/Samba work coordinated under the FOSDEM 2025 `localkdc` umbrella [@cryptomilk-localkdc].

NEGOEX -- carrying IAKerb under the existing `Negotiate` API

You do not want to teach every application a new SSPI provider. Existing code calls AcquireCredentialsHandle("Negotiate", ...); that should keep working, and IAKerb should be one of the mechanisms Negotiate is willing to pick. The piece of plumbing that makes this possible is NEGOEX: SPNEGO Extended Negotiation [@ms-negoex, @draft-zhu-negoex].

NEGOEX adds a pair of meta-data messages on top of the standard SPNEGO NegTokenInit / NegTokenResp exchange, so that mechanisms (like IAKerb) that need a richer negotiation can ride inside the Negotiate envelope. The Microsoft Open Specification [MS-NEGOEX] is currently at revision 4.0 (April 23, 2024), with the original revision dated July 9, 2020 [@ms-negoex]. The expired Microsoft IETF draft draft-zhu-negoex from January 2011 is the historical anchor; four Microsoft authors -- Michiko Short, Larry Zhu, Kevin Damour, and Dave McPherson -- are listed verbatim in the draft metadata [@draft-zhu-negoex].

A correction is owed here. Scope notes inherited from earlier in this project cited "RFC 8143" as the NEGOEX standard. RFC 8143 is actually titled "Using Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP)" and updates RFC 4642; it has nothing to do with NEGOEX [@rfc-8143]. The correct primary references for NEGOEX are [MS-NEGOEX] and draft-zhu-negoex, both used consistently throughout this article [@ms-negoex, @draft-zhu-negoex].

The SPNEGO Extended Negotiation security mechanism. Adds a meta-data exchange inside the SPNEGO envelope so that richer mechanisms (like IAKerb) can be negotiated without changing the SSPI surface. Primary sources: Microsoft Open Specification `[MS-NEGOEX]` revision 4.0 (April 2024); expired IETF draft `draft-zhu-negoex` (January 2011). Despite a common scope-doc error, RFC 8143 is *not* NEGOEX; RFC 8143 is "Using TLS with NNTP" [@ms-negoex, @draft-zhu-negoex, @rfc-8143].

Negotiate-everywhere refactor -- closing "hard-coded NTLM"

The last fallback case is the most prosaic: application code that calls AcquireCredentialsHandleW(..., "Ntlm", ...) or RPC code that asks for RPC_C_AUTHN_WINNT. Both bypass Negotiate and force NTLM no matter what is on the wire. The fix is editorial -- audit Windows internals, replace each hard-coded Ntlm call with Negotiate -- and very large in surface area. Dan Cuomo's "Active Directory improvements in Windows Server 2025" post summarises the Windows Server Summit 2024 session in one sentence: "we have created completely new Kerberos features to minimize use of NTLM in your environments. This session explains and demonstrates IAKerb, Local KDC, IP SPN, and the roadmap to the end of NTLM" [@ms-cuomo-ad2025].

Fallback reason	Closure mechanism	Primary source	Ship target
No DC line-of-sight	IAKerb (GSS-wrapped Kerberos through the app server)	`draft-ietf-kitten-iakerb` (Dead WG, revived by Microsoft) [@draft-ietf-kitten-iakerb]	Windows 11 / Server 2025 [@palko-2023-evolution, @ms-cuomo-ad2025]
No domain at all (local accounts)	Local KDC over IAKerb	Palko 2023; Samba `localkdc` parallel [@palko-2023-evolution]	Windows 11 / Server 2025
No SPN	IP-SPN policy under Negotiate	`[MS-NEGOEX]`; Cuomo 2024 session [@ms-negoex, @ms-cuomo-ad2025]	Windows Server 2025
Hard-coded NTLM	Audit + replace `AcquireCredentialsHandle("Ntlm")` with `Negotiate`	Palko 2023 [@palko-2023-evolution]	Editorial, ongoing through Phase 2

flowchart LR R1[No DC line-of-sight] --> M1[IAKerb
draft-ietf-kitten-iakerb] R2[No domain at all
local accounts] --> M2[Local KDC
over IAKerb] R3[No SPN for target] --> M3[IP-SPN policy
under Negotiate] R4[Hard-coded NTLM
in app code] --> M4[Negotiate-everywhere
refactor] M1 --> N[NEGOEX
SPNEGO extension] M2 --> N M3 --> N N --> P[Negotiate SSPI
same call sites] sequenceDiagram autonumber participant C as Client (no KDC reach) participant S as Application server (KDC reach) participant K as KDC C->>S: SPNEGO NegTokenInit with NEGOEX MetaData, mechs=[Kerberos, IAKerb] S-->>C: NegTokenResp, server picks IAKerb C->>S: IAKerb token wrapping AS-REQ S->>K: AS-REQ K-->>S: AS-REP S-->>C: IAKerb token wrapping AS-REP -> client now has TGT C->>S: IAKerb token wrapping TGS-REQ for service ticket S->>K: TGS-REQ K-->>S: TGS-REP (service ticket) S-->>C: IAKerb token wrapping TGS-REP Note over C,S: From now on, ordinary AP-REQ / AP-REP over Kerberos -- no NTLM needed

What does this mean for Linux and macOS clients in a Windows domain? IAKerb is a GSS-API mechanism, and MIT's krb5 library shipped IAKerb in 1.9 (released February 2011) -- well before Microsoft. Apple's Heimdal-derived GSS framework has shipped GSS_IAKERB_MECHANISM since macOS 10.14 (Mojave, 2018). The cross-platform interoperability story is therefore better in 2026 than it has been in years: a Linux client using MIT 1.9+ or an Apple client using macOS 10.14+ can already speak IAKerb to a Windows Server 2025 Local KDC. The parallel Samba localkdc effort closes the symmetric case: a Linux machine acting as the IAKerb server [@cryptomilk-localkdc].

The reader who started Section 6 believing "NTLM is too entrenched to remove" finishes Section 6 believing something else. The entrenchment is exactly four named cases, and each one has been given an engineered answer. Removal is now a sequencing problem, not an architecture problem.

The engineering existed by October 2023. The shipping commitment came in January 2026. What is Microsoft actually shipping, and on what schedule?

7. The Three-Phase Roadmap

January 29, 2026. The Windows IT Pro Blog publishes "Advancing Windows security: Disabling NTLM by default" under the byline mariam_gewida [@gewida-2026-disabling]. The post documents Microsoft's published roadmap and opens with a caveat that the rest of this article works hard not to forget.

Note: "Disabling NTLM by default does not mean completely removing NTLM from Windows yet... during phase 3, NTLM will remain present in the OS and can be explicitly re-enabled via policy if you still need it." -- mariam_gewida, "Advancing Windows security: Disabling NTLM by default," Microsoft Windows IT Pro Blog, January 29, 2026 [@gewida-2026-disabling]

The plan has three phases. They are sequenced; each phase produces the inputs the next phase needs.

Phase 1 (now) -- Audit

Phase 1 is auditing. The deliverable is enhanced NTLM logging in Windows 11 24H2 and Windows Server 2025, documented in KB 5064479 (published July 11, 2025) [@ms-kb5064479]. The new logging surface is Applications and Services Logs > Microsoft > Windows > NTLM > Operational, gated by two GPOs called "NTLM Enhanced Logging" and "Log Enhanced Domain-wide NTLM Logs." For each NTLM authentication, the event tells the administrator three things: who called (the process), why (the negotiated SSPI provider chose NTLM), and where (the target service). The KB also names per-event warning classes for NTLMv1, MIC-less, and EPA-not-supported authentications [@ms-kb5064479].

Phase 1 also closes the oldest residual: NTLMv1. Microsoft's deprecation page added an NTLM entry in June 2024 with verbatim language: "All versions of NTLM, including LANMAN, NTLMv1, and NTLMv2, are no longer under active feature development and are deprecated. Use of NTLM will continue to work in the next release of Windows Server and the next annual release of Windows. Calls to NTLM should be replaced by calls to Negotiate" [@ms-deprecated-features].

The same row adds: "NTLMv1 is removed starting in Windows 11, version 24H2 and Windows Server 2025" -- the November 2024 update note [@ms-deprecated-features]. The KB 4090105 pre-24H2 NTLMv1 auditing surface (Event ID 4624 with Package Name (NTLM only): NTLM V1) remains valid for legacy environments [@ms-ntlmv1-dc-audit].

Phase 2 (H2 2026) -- IAKerb + Local KDC + Negotiate-first refactor in pre-release

Phase 2 puts the engineered closures from Section 6 into pre-release. IAKerb and Local KDC ship for Windows Insiders and Server preview channels. The Negotiate-first refactor lands -- Microsoft's own subsystems audit their AcquireCredentialsHandleW("Ntlm", ...) and RPC_C_AUTHN_WINNT call sites and replace them with Negotiate calls. Per-machine policy controls for NTLM scope make finer-grained restriction possible. IP-SPN policy lands so the "no SPN" case can be closed without naming every server by FQDN [@gewida-2026-disabling, @ms-cuomo-ad2025].

The Microsoft outreach mechanism for Phase 2 is the ntlm@microsoft.com mailbox; the January 2026 post names it explicitly as the channel for surfacing cross-forest, federated, and ISV-edge cases that need engineering help before Phase 3 [@gewida-2026-disabling].

Phase 3 (next major Windows / Windows Server release) -- Disabled by default

Phase 3 is the default-off flip. Network NTLM authentication is disabled by default in the next major Windows and Windows Server release. The disablement is a configuration, not a binary removal: NTLM remains in the OS, callable through Negotiate only when a policy explicitly re-enables it for a named scope [@gewida-2026-disabling]. The Hacker News' summary of the roadmap published February 2026 documents the same three-phase structure for industry-press consumption [@thn-2026-ntlm-phaseout].

flowchart LR P1[Phase 1 -- NOW
KB 5064479 enhanced auditing
NTLMv1 removed in 24H2 / WS2025] --> P2 P2[Phase 2 -- H2 2026
IAKerb + Local KDC pre-release
Negotiate-first refactor
Per-machine NTLM scope policy] --> P3 P3[Phase 3 -- next major Windows
Network NTLM disabled by default
Re-enablement requires explicit policy]

Phase	Deliverable	Date / target	Prerequisite	Primary
Phase 1	Enhanced NTLM auditing	KB 5064479, July 11, 2025	Windows 11 24H2 / Server 2025	[@ms-kb5064479]
Phase 1	NTLMv1 removal	Windows 11 24H2 / Server 2025, November 2024	NTLM family deprecation (June 2024)	[@ms-deprecated-features]
Phase 2	IAKerb + Local KDC pre-release	H2 2026, Windows Insider channel	Phase 1 audit data identifies callers	[@gewida-2026-disabling, @ms-cuomo-ad2025]
Phase 2	Negotiate-first refactor of Windows subsystems	H2 2026	Phase 1 audit data	[@palko-2023-evolution, @gewida-2026-disabling]
Phase 2	IP-SPN policy for "no SPN" case	Windows Server 2025 + flighting	NEGOEX in Negotiate	[@ms-cuomo-ad2025]
Phase 3	Network NTLM disabled by default	Next major Windows / Server release	All Phase 2 features GA	[@gewida-2026-disabling]

Phase 3 is the first default configuration in 30 years that does not include NTLM. It is not the first configuration in 30 years without authentication-relay attacks. Why not?

8. What Disabling NTLM Cannot Buy You

A blunt section. Phase 3 is real progress. It is not the end of authentication attacks on Windows. Three structural ceilings survive the transition; the article will not pretend otherwise.

Disabled is not removed

Phase 3 still ships NTLM in the OS. The default is off; the policy lockout is exactly as strong as the domain's tier-0 administrative segregation, not stronger. An attacker who reaches a domain controller with Group Policy edit rights can flip the policy and re-enable NTLM for the scope they want. The wording in the January 2026 post is precise: "during phase 3, NTLM will remain present in the OS and can be explicitly re-enabled via policy if you still need it" [@gewida-2026-disabling].

This is the design choice Microsoft has to make, because removing NTLM binaries entirely would brick every third-party application that hard-codes Ntlm and every legacy device that has not been firmware-updated since 2018. "Disabled by default with policy override" is the only configuration that has any chance of getting deployed.

Kerberos has its own relay class

The relay class does not depend on NTLM. KrbRelay, KrbRelayUp, RBCD abuse, unconstrained-delegation abuse, S4U2Self / S4U2Proxy chains -- the entire taxonomy survives the move to Kerberos with different named primitives. Dec0ne's KrbRelayUp README, quoted at the end of Section 4, calls the class a universal no-fix local privilege escalation; the rest of the README enumerates the LDAP-signing default and the RBCD primitive that drive the post-NTLM relay surface [@gh-krbrelayup].

What changes is the protocol. What does not change is that an application server that receives an authenticated message without enforcing message integrity or channel binding can be coerced into accepting an attacker-relayed authentication. The named primitives change. The class survives.

Local SAM hashes remain password-equivalent

The Local KDC reads the SAM. An attacker with SYSTEM-level access to the same machine reads the SAM too. Once they have the hash in hand, they can either feed it to a Local KDC running on a machine they control, or they can attempt offline cracking. IAKerb does not change either of those facts; what it changes is whether the wire exposes the password-equivalent secret. Defence in depth -- TPM-backed key wrapping, Credential Guard for VBS isolation of process credentials, BitLocker for the cold-boot scenario -- remains necessary [@ms-credential-guard].

Key idea: Phase 3 is a transition between tradeoffs, not a transition out of them. The exit from NTLM-the-protocol is not the exit from the authentication-relay class, or from the chip-layer credential class. The arc closes one specific 30-year-old attack surface and opens different conversations about the next.

If the structural classes survive, what practical problems remain that an administrator should worry about between today and Phase 3?

9. Open Problems and the 2026-2027 Edge

Five named problems sit between Phase 1 (now) and Phase 3 GA. Each one has a primary source and a "best partial result" available today.

ESC8 field deployment of EPA on /certsrv/ is uneven. Microsoft published KB 5005413 on July 23, 2021 with the dispositive recipe: <extendedProtectionPolicy policyEnforcement="Always" /> on every /certsrv/ virtual directory, plus disabling plain HTTP. Server 2025 hardening pushes EPA to required-by-default in many AD CS templates. Many environments are not on Server 2025 yet, and CISA's Known Exploited Vulnerabilities catalog still lists CVE-2021-36942 as actively exploited. CVE-2022-26925 ("Windows LSA Spoofing Vulnerability") is the LSARPC NTLM-relay variant that emerged after the initial PetitPotam patches; it is on the same KEV list [@ms-kb5005413].
Third-party and legacy-app hard-coded NTLM. Microsoft's Negotiate-everywhere refactor covers Microsoft's own code. Independent software vendors must do the same audit for theirs. Phase 1's enhanced auditing surface (KB 5064479) is the practical instrument for identifying the callers: every NTLM authentication carries the calling process name and a reason code [@ms-kb5064479]. The post-Phase-3 default-off configuration will surface these as outages on any environment that has not run the audit first.
Cross-forest and federated IAKerb edges. Single-forest IAKerb is well-defined. Multi-forest, federated, and partner-trust scenarios get implementation-defined quickly: NEGOEX has to carry IAKerb tokens through Negotiate across trust boundaries where the proxying server may not be in the same forest as the KDC. Microsoft's ntlm@microsoft.com outreach mailbox exists precisely to surface these edge cases before Phase 3 [@draft-ietf-kitten-iakerb, @gewida-2026-disabling].
Linux and macOS parallel. MIT Kerberos has had IAKerb since 1.9 (released February 2011). Apple ships GSS_IAKERB_MECHANISM since macOS 10.14. The Samba and localkdc effort from Bokovoy and Schneider (FOSDEM 2025) is the parallel open-source path: a Linux machine that can act as the IAKerb application server for a Windows client, or vice versa, under the same Negotiate envelope [@cryptomilk-localkdc]. The interoperability story should be better in 2026-2027 than it has been in twenty years.
Policy pressure. EU NIS2 mandates cybersecurity risk-management measures for entities in critical sectors; the Cyber Resilience Act adds mandatory security requirements for products with digital elements. Both frameworks make legacy authentication a documented compliance concern. Deprecation of NTLM under Microsoft's own deprecation page (ms-deprecated-features) gives a clean audit surface that did not exist before; an organisation can point to KB 5064479 audit data showing NTLM call sites with named callers and target services, and demonstrate progress on retirement [@ms-deprecated-features].The EU regulatory framing here is touched lightly because the primary texts (NIS2 Directive, Cyber Resilience Act) are extensive regulatory documents this article does not quote verbatim beyond the European Commission's official summaries. The relevant connection is operational: deprecation pages and audit logs give compliance teams an artifact for "we are retiring this class of credential under a published deprecation," which is the kind of evidence regulators ask for.

All five problems converge to one question for the AD engineer reading this article: what should I do this quarter?

10. What an AD Engineer Should Do This Quarter

Six numbered actions, ordered by impact. No filler, no compliance boilerplate.

Note: This is the prerequisite. Without Who/Why/Where data, Phase 3 surfaces breakage as outage. Enable the "NTLM Enhanced Logging" and "Log Enhanced Domain-wide NTLM Logs" GPOs on every domain controller and member server you operate. Subscribe to the Applications and Services Logs > Microsoft > Windows > NTLM > Operational channel. Identify every process that initiates NTLM, the reason Negotiate declined Kerberos, and the target service. Triage by call volume and criticality [@ms-kb5064479].

Note: Set LDAPClientIntegrity = 2 and LdapEnforceChannelBinding = 2 on every domain controller. This closes SMB-to-LDAP relay regardless of whether the originating authentication was NTLM or Kerberos. KrbRelayUp's existence makes this more urgent post-NTLM, not less: the relay class on Kerberos uses the same un-anchored LDAP target [@gh-krbrelayup].

Note: The KB 5005413 recipe is verbatim: add <extendedProtectionPolicy policyEnforcement="Always" /> to the authentication element of the IIS virtual directory and disable plain HTTP. /certsrv/ is the dispositive ESC8 target. Web Enrollment proxy endpoints (/certenroll/, /adpolicyprovider_cep_kerberos/ and similar) are the second tier. Audit every IIS authentication endpoint in the estate and confirm policyEnforcement="Always" is the value, not "None" or "Partial" [@ms-kb5005413].

Note: The Print Spooler service is the single highest-impact MS-RPRN coercion surface. Disabling Spooler on every server that does not actually print closes the entire RpcRemoteFindFirstPrinterChangeNotificationEx coercion class on those hosts. Microsoft's hardening guidance and the PrintNightmare disclosures (2021) made this an explicit recommendation [@gh-spoolsample].

Note: Coercer's scan mode is the canonical defensive auditing tool: it inventories which RPC coercion methods a given server still answers. Run it against every server you operate, in scan mode. The output is a list of unauthenticated and authenticated coercion endpoints to either patch, disable, or compensate around. Treat unauthenticated endpoints (LSARPC, \PIPE\lsarpc) as P0 [@gh-coercer].

Note: Microsoft's preferred sequence: Windows Insider flighting -> pilot non-production NTLM-off configurations -> identify hard-coded Ntlm SSPI calls in your in-house code -> stage Phase-3 rollout against your audit data. If you wait, the cut-over surfaces breakage as outage. If you audit, the cut-over is uneventful [@gewida-2026-disabling].

The Phase 1 audit is the load-bearing piece. Action 1 produces the data that makes Actions 2-6 prioritise correctly. The following snippet sketches the audit-event query logic an administrator would express in PowerShell -- the JavaScript runs the same logic so you can think through edge cases interactively.

{` // Sketch of the triage logic an administrator would run against // "Applications and Services Logs > Microsoft > Windows > NTLM > Operational" // after enabling the KB 5064479 enhanced auditing GPOs. The point of running // this in JavaScript is to make the rules explicit so you can think through // edge cases without standing up a Windows event channel.

const sampleEvents = [ { process: "C:\\app\\legacy.exe", reason: "NoSPN", target: "ldap/dc01.example.local", count: 142 }, { process: "C:\\Program Files\\Backup\\agent.exe", reason: "ExplicitNtlm", target: "cifs/backup02.example.local", count: 9 }, { process: "C:\\Windows\\System32\\spoolsv.exe", reason: "NoDcReach", target: "cifs/attacker.example.local", count: 1 }, { process: "C:\\Windows\\System32\\lsass.exe", reason: "LocalAccount", target: "host\\WORKGROUP-PC01", count: 38 }, { process: "C:\\Windows\\System32\\svchost.exe", reason: "NoSPN", target: "host/aliased.example.local", count: 7 }, ];

for (const row of triage(sampleEvents)) { console.log(`[${row.severity.toUpperCase()}] ${row.process}`); for (const a of row.actions) console.log(" -> " + a); } `}

Note: - LMCompatibilityLevel = 5 without audit. Forcing NTLMv2-only on every DC is correct as an endpoint, but flipping it without first running KB 5064479 audit will outage legacy applications that still attempt NTLMv1 [@ms-kb5064479]. - RestrictNTLM:Deny without exceptions. The Restrict NTLM family of GPOs supports per-server exemptions. Going straight to Deny without an exemption list is the classic outage path. - EPA on HTTPS-only while leaving plain HTTP enabled. KB 5005413 explicitly requires both policyEnforcement="Always" and disabling plain HTTP on /certsrv/. Leaving HTTP up makes the EPA enforcement moot [@ms-kb5005413]. - Trusting Credential Guard against coercion. Credential Guard protects against credential theft. It does not protect against ESC8, PetitPotam, or any other relay-of-live-authentication chain [@ms-credential-guard].

On a non-production Windows 11 Insider machine, the per-machine NTLM scope policy lives under `HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0`. Microsoft's pre-release documentation will name the value used to gate the Phase 2 IAKerb / Local KDC behaviours; consult the Windows Insider release notes that ship with the Phase 2 flight rather than hard-coding a value here -- the keys are subject to change up to GA. Use the `ntlm@microsoft.com` outreach channel for any environment-specific question [@gewida-2026-disabling].

This is the work. The Phase 3 deadline is the next major Windows release; the Phase 1 audit window is right now. If you wait, the cut-over surfaces breakage as outage. If you audit, the cut-over is uneventful.

11. Frequently Asked Questions

No. NTLMv2 is the version Drop-the-MIC, PetitPotam, and ESC8 all attack [@nvd-cve-2019-1040, @specterops-cert-preowned-blog]. The HMAC-MD5 response is strong against the response side, but the password-equivalence of the NT-hash and the lack of binding to the underlying transport are the structural properties every modern attack exploits. NTLMv2 is the *least bad* NTLM, not a safe NTLM. Phase 1 controls let you *audit*. Phase 2 features (IAKerb, Local KDC, IP-SPN, the Negotiate refactor) are what make disabling *survivable* for most organisations. If you go straight to `RestrictNTLM:Deny` without running the KB 5064479 audit first, you will outage legacy applications and possibly your help-desk laptops. The honest answer is: audit now, pilot Phase 2 in H2 2026, default-off at Phase 3 [@gewida-2026-disabling, @ms-kb5064479]. No. Credential Guard fixes credential *theft* from LSASS. It does nothing about credential *use* (relay), coercion (PetitPotam), or cross-protocol chains (ESC8). It is necessary -- ESC8 + Mimikatz is worse than ESC8 alone -- but it is not sufficient against the relay class [@ms-credential-guard]. No. KrbRelay and KrbRelayUp demonstrate the relay *class* survives on Kerberos. What changes is the named primitives, not the existence of relay. Defence is the same shape after Phase 3 as before: LDAP signing and channel binding everywhere, EPA enforced on every authentication endpoint, message integrity required at every level [@gh-krbrelayup]. Because the four fallback reasons (no DC, local accounts, no SPN, hard-coded NTLM) had no engineered answer until IAKerb, Local KDC, NEGOEX, and the Negotiate refactor existed in shippable form. The standards work, the IETF drafts (one of which was marked Dead WG Document in 2019 and is being revived), the MIT 1.9 parity, and the Apple precedent all had to exist before Microsoft had a credible removal path that did not break enterprise deployments [@palko-2023-evolution, @draft-ietf-kitten-iakerb]. Yes. MIT Kerberos has had IAKerb since 1.9 (released February 2011). Apple ships `GSS_IAKERB_MECHANISM` since macOS 10.14 (Mojave, 2018). The Samba `localkdc` effort from Bokovoy and Schneider (FOSDEM 2025) is the parallel open-source path for a Linux local KDC. Heterogeneous Windows-domain estates with Linux file servers and macOS clients are positioned to interoperate with Phase 3 *better* than they did with NTLMv2 [@cryptomilk-localkdc].

NTLM was the answer to a 1987 problem and a 1993 problem. It survived because removing it required engineering four orthogonal capabilities that did not exist. They exist now. The next major Windows release ships without it on by default. The attacks that follow it -- KrbRelayUp, RBCD chains, S4U2Self abuse, certificate-template misconfiguration -- target a different protocol with a different vocabulary. The relay class persists. The protocol it targets is no longer NTLM.

If you read this article as part of a sequence, the prior pieces cover the access-control model (SeAccessCheck and its inputs), the chip-layer credential story (TPM, Pluton, Credential Guard, BitLocker), and the application-identity layer (Authenticode, signed binaries, AppLocker, smart application control). NTLM removal is one strand of the broader move from "trust the perimeter" to "tie every credential to a token, a chip, or a Kerberos ticket whose lifetime you can name." Each strand by itself is incomplete; together they are how the next decade of Windows authentication looks.