Pass-the-Hash to Pass-the-PRT

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 authentication artifact that the latest boundary does not fully cover, then commoditises replay 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) shows the modern storage-versus-use gap. On Credential-Guard-on Entra-joined devices, the long-lived PRT/session-key state should be read as part of the protected storage model rather than as a directly documented per-field layout; CloudAP in VTL0 still performs the in-use SSO-cookie derivation. That derivation or brokered signing path, not flat theft of the isolated root, is the replay surface. The next decade of Windows credential theft turns on whether every in-use cloud-token derivation receives a boundary as strong as the storage boundary.

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. (Side note: 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 [818]. 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." [818]

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 24H2 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 CloudAP can be driven through the Mollema/Delpy path to produce PRT-derived proof material usable for SSO-cookie replay [819]. 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 [820] [821] when the target client/resource path accepts that unbound proof. Every Microsoft defense shipped in 2015, 2022, and 2024 may be running; the attack still wins against unsupported browser paths, third-party SaaS, legacy integrations, or controls outside the verifier path.

You will meet the eight researchers at the center of this lineage. 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, whose adsecurity.org reference became the canonical practitioner explainer of Overpass-the-Hash and 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 chapter 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.

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 this chapter's load-bearing claim, and the rest of the lineage is its consequence. The mechanics behind it. How NTOWF = MD4(UNICODE(password)) is computed, how NTLMv1's informal DESL shorthand (three DES encryptions over the challenge) and NTLMv2's HMAC_MD5 turn that key into a challenge response, and why the verifier recomputes the same value from the stored hash in the SAM or NTDS.dit: belong to Foundations and the The Death of NTLM chapter (Chapter 16), which own the NTLM challenge-response primitive in full [716] [646]. The one fact this chapter inherits and builds on is the consequence: the cleartext password appears in exactly one place in the entire protocol, the input to the hash on the client, so a stolen hash skips only the typing step and produces an NTLM_AUTHENTICATE message the verifier cannot distinguish from a genuine logon. 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. (Margin note: 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. Supply the victim user's hash instead of the victim user's password, and the protocol still produces a valid response, signed by the substituted key. The bug is not a bug; it is a documented property.

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 [818]. 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 among others, because they asked the attacker or user to enter the cleartext password to authenticate, and not the corresponding password hash value." [822]

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.

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 artifact 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 [824]. It contained two principal executables. whosthere.exe read the NTLM credentials cached in LSASS for the active logon sessions, and iam.exe opened the LSASS process with PROCESS_VM_WRITE, located the cached credential block for the current interactive logon session, and overwrote the username, domain, and NT hash fields with attacker-supplied values in place (a companion genhash.exe computed hashes).

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 summarizes 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." [822] 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 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." [823] 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.

(Side note: Hernan Ochoa's Windows Credentials Editor (WCE), released about two years 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.

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." [617] Wikipedia corroborates: "He released the first version of the software in May 2011 as closed source software." [461] The program was called Mimikatz.

What made Mimikatz architecturally different from Ochoa's toolkit was that it was modular: named command groups each retargeted the same LSASS reachability at a different artifact: sekurlsa::logonpasswords for NT hashes, sekurlsa::tickets for Kerberos tickets, kerberos::ptt to inject a stolen ticket through the documented LsaCallAuthenticationPackage API [825], and lsadump::dcsync to impersonate a domain controller and pull the krbtgt hash by directory replication [653]. The module-by-module mechanics (and the DCSync replication-RPC abuse in particular) are owned by the Mimikatz and the Credential-Theft Decade chapter (Chapter 14); what matters to the lineage here is that one tool made retargeting routine.

Same LSASS, different artifact, different protocol surface. The architectural property named earlier had two artifacts 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 re-injects a chosen ticket on any machine where the user has a Kerberos credentials cache.

The third generation followed shortly. Overpass-the-Hash observes that for the RC4-HMAC Kerberos encryption type (long accepted for Windows Kerberos compatibility and often selected in estates that had not forced AES-only policy before the 2022 hardening work), 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 [759]. 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 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 [827] and the Duckwall + Delpy Black Hat USA 2014 talk and whitepaper [801] [826]. 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 [828].

(Side note: 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 chapter uses Metcalf's reference as the canonical practitioner explainer rather than as a single inventor citation.)

The DigiNotar incident in September 2011 is the earliest public criminal-use attribution this chapter can source for Mimikatz, but the attribution is single-source and should be read with that caveat. The Dutch certificate authority DigiNotar (founded 1998, acquired by VASCO in January 2011, hacked in June 2011, declared bankrupt in September 2011 [829]) was used to issue hundreds of fraudulent certificates that were then used in man-in-the-middle attacks on Iranian Gmail users [829] [830].

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

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.

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" [823]. 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 [619]. 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 [672]. 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 in the May 13, 2014 KB2871997 credential-protection wave and completed for older RDP client/server combinations through the October 2014 follow-on servicing path [831]). 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 [832].

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" [328]) is also the prediction: PPL is part of the answer, but only when paired with the architectural pivot still to come.

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.

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.

Credential Guard and the architectural pivot

On July 29, 2015, Microsoft shipped Windows 10 Enterprise [833]. 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 is the first defense in this lineage that isn't documentation, and its architecture is owned in full by the Credential Guard chapter (Chapter 15). In one paragraph: it runs on Virtualization-Based Security, which the Secure Kernel chapter (Chapter 6) splits into a normal VTL0 and an isolated VTL1; it moves the covered secrets into the LSAISO trustlet, one of the signed VTL1 processes the VBS Trustlets chapter (Chapter 7) describes, where no VTL0 process or driver can read them; and HVCI from the Code Integrity chapter (Chapter 8) closes the kernel-mode bypass that would otherwise map VTL1 memory directly. The one fact this chapter needs from that architecture: NT hashes, Kerberos TGT session keys, and "credentials stored by applications as domain credentials" leave VTL0 LSASS for the VTL1 LSAISO trustlet, default-enabled on hardware-eligible domain-joined non-DC systems since Windows 11 22H2 [87].

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." [87] 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?" [301] 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)."

What does Credential Guard not isolate? This is the load-bearing question for the rest of this chapter. 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)." [87] 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, authorized 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." [87] 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 chapter 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 chapter spends its time documenting being fulfilled:

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 artifact Credential Guard's verbatim scope does not cover. The rest of this chapter reads as the unfolding of that prediction.

PPL and Credential Guard are complementary, not alternatives. itm4n's analysis [328] 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 [87]. Seven years of uneven deployment.

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.

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: many mature Active-Directory-integrated enterprises had been running Microsoft's PKI for years, and Schroeder and Christensen found template-level catastrophes in nearly every AD CS environment they examined.

On June 17, 2021, Will Schroeder and Lee Christensen posted "Certified Pre-Owned" on Medium, with the accompanying 143-page whitepaper [709] [834]. 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:

The ESC catalog organizes 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.

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 that maps to a computer account, including a domain controller.

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 [769] [838].

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." [770]

(Side note: The KB5014754 change-log preserves a forensic artifact 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." [770] 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) [770]. 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 [709]. 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 [835] [836]. Méheut's write-up documents the KDC_ERR_PADATA_TYPE_NOSUPP error path that diverts the PKINIT-blocked attacker into Schannel.

(Side note: 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." [836] The technique name is socially attributed; the catalog framing is editorial.)

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) [770]. 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 [839] [837].

The current state of the catalog: as of the 2025 Certipy 5.x documentation, ESC1 through ESC16 is the practitioner enumeration, with each technique characterized by a template-level, ACL-level, CA-administrator-level, NTLM-relay-level, SID-extension-level, or mapping-level abuse primitive [837]. 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) [840]. 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.

Table 1. A representative slice of the ESC1-ESC16 catalog showing what KB5014754 closes and what remains administrative hardening [841] [837] [839].