Kerberos

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 applied every control from the Death of NTLM chapter (Chapter 16) 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 [691]. 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.

The chain has a name and a primary disclosure: Elad Shamir's "Wagging the Dog" post on shenaniganslabs.io, January 28, 2019 [691]. The weaponised tooling is GhostPack's Rubeus, the C# Kerberos toolset that ships ready-made commands for s4u, asktgt, kerberoast, and diamond [738]. 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) [693].

Walkthrough: post-NTLM RBCD chain. Read the exchange as a ticket-and-directory state machine, not as an exploit recipe. First, the low-privileged user creates CN=ATTACKER$,CN=Computers,DC=contoso,DC=com; the directory now stores a fresh machine password and SPNs for that computer because MachineAccountQuota permits the create. Second, the user writes the target server's msDS-AllowedToActOnBehalfOfOtherIdentity security descriptor so the target resource says, in directory policy, "ATTACKER$ may act for users to me." Third, ATTACKER$ performs a normal AS exchange and receives a TGT encrypted to krbtgt. Fourth, ATTACKER$ asks S4U2Self for a service ticket whose client name is Administrator; the output is a ticket to ATTACKER$, not to the file server. Fifth, ATTACKER$ sends that ticket as the additional ticket in S4U2Proxy and asks for cifs/fs01.contoso.com; because the target resource's RBCD descriptor authorizes ATTACKER$, the KDC issues a forwardable service ticket to the file server. Sixth, the AP-REQ goes to SMB. The file server decrypts the ticket with its own long-term key, reads a PAC naming Administrator, and has no NTLM decision to make. The trust boundary abused here is not "password fallback"; it is the directory object that defines who may delegate to the resource [691] [693].

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 catalog 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 [739].

This is the chapter's load-bearing thesis. Removing NTLM did not remove the attack surface; it shifted the attack surface onto a protocol with its own long retrofit history and an expanding share of the Windows authentication load. 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 [717]. The Death of NTLM chapter (Chapter 16) walked through the NTLM-side mechanics of that transition. This chapter 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 1988 designers intended?

Origins: Needham, Schroeder, Athena, and 1988

Kerberos is not new engineering. The story of Windows authentication in 2026 starts with a 1978 paper in Communications of the ACM by Roger Needham of the University of Cambridge and Michael Schroeder of Xerox PARC.

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 [740]. The paper is paywalled on the ACM Digital Library, but RFC 4120's own Background section names it as the parent protocol [741]. The symmetric-key version of that protocol is five messages long; summarized below, it is the structural blueprint of every "ticket from a trusted third party" design that followed.

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 ticket a decade 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. RFC 4120 names Denning and Sacco's modifications as the other parent of Kerberos v5 [741]: the Needham-Schroeder symmetric protocol [742] is vulnerable to replay if an attacker recovers an old session key, and timestamps are the fix. This is the structural reason every Kerberos ticket carries a timestamp and every Kerberos network requires a synchronised time service today.

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" [744], 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 artifacts. 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 [745]. 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 [746]. 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 remains recognizable thirty-eight years later.

On January 24, 1989, MIT shipped the first public release of Kerberos v4 [747]. Five years later, in September 1993, the IETF adopted Kerberos v5 as RFC 1510 [748]. 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 [741].

Walkthrough: the Kerberos triple. The first exchange is AS-REQ / AS-REP. The client names itself, the realm, requested options, requested enctypes, and pre-authentication data; the KDC returns two related objects: a TGT encrypted to the krbtgt long-term key, and client-visible key material encrypted to the user's long-term key. The client cannot open the TGT; it can only cache it and use the adjacent TGT session key. The second exchange is TGS-REQ / TGS-REP. The client proves possession of the TGT session key with an authenticator, names an SPN such as cifs/fs01.contoso.com, and receives a service ticket encrypted to the service account plus a new client/service session key. The third exchange is AP-REQ / AP-REP. The client sends the opaque service ticket and an authenticator to the service; the service decrypts the ticket with its own key, checks the authenticator freshness, and validates the PAC material it is equipped and required to validate under Windows PAC rules. It may verify the service-keyed PAC signature locally; validation of KDC-keyed PAC signatures is a different trust path. That six-message shape is why a stolen long-term key is so powerful: the service-side AP decision is deliberately local once the ticket arrives [741] [743].

Kerberos in 2026 still exposes the same AS / TGS / AP outline, with decades of extensions layered inside it. The skeleton you draw on a whiteboard for a graduate seminar is recognizably the skeleton a Windows 11 24H2 machine uses with a 2025 domain controller. The interesting question is what those extensions did to the inside of every message. (Note: 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 [739]. The five-minute window is the residue of Denning and Sacco's 1981 timestamp fix.)

The wire in 2026: Six messages and an encryption matrix

Every Kerberos textbook draws the same six-message diagram introduced above. 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 [741]. 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 [749]), PA-FX-FAST-REQUEST (FAST armoring [750]), PA-AS-FRESHNESS (PKINIT freshness [751]). The skeleton survives only because the joints are extensible.

The AS-REP returns the TGT. The TGT itself is encrypted under the TGS/krbtgt long-term key, so the client cannot inspect the TGT's EncTicketPart. What the client can inspect are the mirrored or adjacent fields in the encrypted AS-REP reply part that is encrypted to the client key, including ticket flags and session-key material. 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 [741]. (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 [752] [753].

Inside the ticket's AuthorizationData field is the Microsoft-specific construction that turns Kerberos into a Windows authorization system. The Privilege Attribute Certificate, defined in [MS-PAC] revision 26.0 [743] [754], carries the user's SID, their group SIDs, their logon name, timestamps, and, depending on patch level, up to four cryptographic signatures: a Server signature, a KDC signature, a Ticket Checksum (added for CVE-2020-17049, the Bronze Bit fix, binding the PAC to its ticket), 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 [755].

Then there is the encryption matrix. Kerberos abstracts ciphers behind the RFC 3961 framework [757], 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 23 is the row that built every Kerberoasting career. K. Jaganathan, Larry Zhu, and John Brezak of Microsoft published RFC 4757 in December 2006 [759]. 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" [763].

The cryptography in that definition is short enough to follow end-to-end.

That PBKDF2-HMAC-SHA1 result is only the intermediate; the AES256 long-term key used by Kerberos is the RFC 3962 DK(tkey, "kerberos") result, and Windows stores key material according to the account's available keys and msDS-SupportedEncryptionTypes state. 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 defense 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 [764] [765]. (Note: PBKDF2 at 4,096 iterations is well below modern PHC recommendations. The 2023 OWASP guideline for PBKDF2-HMAC-SHA1 is 1.3 million iterations [766], 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 [764].)

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.

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

Generation 1, 2014: Kerberoasting

Tim Medin's primitive [688]. Will Schroeder's PowerShell weaponisation as Invoke-Kerberoast (later rolled into the C# Rubeus) [738]. Sean Metcalf's operational walkthrough on adsecurity.org [767]. MITRE cataloged 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" [689].

The structural insight is the part that matters. The service ticket inside the TGS-REP is encrypted with the service account's long-term password-derived key, so any domain user who can obtain that ticket can mine the service-ticket 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". In the ordinary Kerberoasting case, possession of a TGT is enough to request the service ticket.

Microsoft's dispositive engineered response did not arrive until ten to twelve years later, even though a partial, not-purpose-built mitigation predated the disclosure. Server 2012 had 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 authorized in msDS-GroupMSAMembership [764]. 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" [765]. The October 2024 Microsoft Security Blog formalized the Kerberoasting guidance in a single page that names RC4 as the load-bearing weakness and announces the deprecation [763]. The December 2025 Beyond-RC4 announcement closed the cadence with a calendar date [760].

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) [261]. 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 [741]. 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 [738]: 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 organization 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 [726]. 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 [691]. 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" [691]. Every clause of that TL;DR points at a documented behavior. The chain in this chapter's opening gap analysis is built directly on top.

Bronze Bit. Jake Karnes at NetSPI; CVE-2020-17049; disclosed November 10, 2020 [753] [752]. 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" [752]. 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 [752]. 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 [752] tightened the KDC's S4U2Proxy ticket-validation step; KB5008380 (November 2021) [768] shipped alongside the canonical "set ms-DS-MachineAccountQuota = 0 for non-administrator users" hardening guidance; LDAP signing and channel binding work, ongoing since the NTLM-retirement effort began, 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 [769]. 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 matched the certificate's Subject Alternative Name (SAN) to an account: a User Principal Name for user certificates, or the DNS name (populated from dNSHostName) for machine certificates. 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 [770]: 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 [770].

KrbRelayUp. Mor Davidovich (Dec0ne), April 24, 2022 [693]. 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 Enrollment.

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 [693]

Generation 5, 2022: 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 [771] [772]. 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)" [771]. 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, no krbtgt-keyed signature covered the entire encoded PAC: the Server Signature spanned the whole PAC but used the service's own (recomputable) key, while the KDC Signature covered only the Server Signature's bytes. That left room for a key-holder to modify PAC fields and recompute the coverage they could reach.

Sapphire Ticket. Charlie Bromberg, also known online as "Shutdown", at Synacktiv [773] [774]. 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 [774]. 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" [773]. 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" [775]. (Note: 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 [776]. The verified Sapphire-Ticket originator is Charlie Bromberg (Shutdown, Synacktiv) per [773].) (Note: 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 [767].)

Microsoft's engineered response to both Diamond and Sapphire was CVE-2022-37967, the KrbtgtFullPacSignature [755] [756]. 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. This closes PAC tampering by parties that do not hold the krbtgt key, the modification-after-issuance class the sub-signatures left uncovered. It does not stop an attacker who already holds the krbtgt key: a Golden or Diamond forger computes a valid Full PAC Signature with that same key. KrbtgtFullPacSignature raises the bar against PAC modification by non-key-holders; it is not a defense against krbtgt compromise itself, for which the only remedy is securing and dual-rotating krbtgt (Chapter 18).

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 [763]

The spine table

Walkthrough timeline: attack cascade. The public sequence runs from Kerberoasting and Mimikatz Golden/Silver tickets in 2014, through AS-REP roasting, SpoolSample/PrinterBug, RBCD, and Bronze Bit, into the 2022 cluster of KrbRelayUp, Certifried, Diamond, Sapphire, and Microsoft's KrbtgtFullPacSignature response. The security lesson is chronological: each primitive exposed a different ticket, flag, PAC, or delegation seam.

Eight years. Eleven structural primitives. One protocol. By 2022 the public cascade slowed, not because the protocol had become simple, but because the known seams had acquired named mitigations, patches, or operational controls. 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.

The defensive cadence before 2023

Each of the eleven primitives in the attack-cascade section eventually met a patch, mitigation, or operational control. By 2022 every named primitive had a response. 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) [777]. A new security group that triggers five non-configurable client-side protections and four non-configurable domain-controller-side protections [672]. 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" [672]. 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" [672]. 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 group users, computers, and service accounts under authentication policies that restrict where high-value credentials can be used and tune Kerberos TGT lifetime and access conditions. The standard tier-zero / tier-one / tier-two split fits neatly under three silos [778] [779].

Restricted Admin (2014) and Remote Credential Guard (2016) [780]. 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 [780].

Credential Guard (Windows 10 RTM, 2015) [621]. 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. The Credential Guard chapter (Chapter 15) owns this mechanism in full; the load-bearing distinction for this chapter is that it isolates the long-term key, not the tickets minted from it: current-session TGTs and service tickets still sit in VTL0 lsass.exe, which is why ticket abuse remains a Kerberos problem after the long-term secret is off the box.

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 [750]. 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 defense for service accounts [764] [781]. The Microsoft Key Distribution Service (kdssvc.dll) computes and rotates the account password material, and member hosts authorized for the gMSA can retrieve current and previous password values 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 defense. 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 [693] 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; this closes PAC modification by parties that do not hold the krbtgt key. It does not stop a krbtgt-key holder (Golden or Diamond), nor Sapphire-class variants that obtain a legitimate KDC-issued PAC via S4U2Self [755] [756].

MachineAccountQuota = 0 guidance (KB5008380, November 2021) [768]. The dispositive RBCD defense 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 the opening gap analysis.

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 catalog. 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 known public engineering catalog had matured. The 2023 announcement was the first plan in this sequence 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.

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 post's raw HTML metadata records a modified time of 2023-11-11T01:30:49.108-08:00; its description reads "Discover how we're securing authentication and reducing NTLM usage in Windows" [717]. 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 [728]. 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" [728].