KRBTGT

Ninety seconds to domain admin

A classic Golden Ticket operation, with the krbtgt account's AES-256 long-term key in hand, can walk the attacker onto resources in the domain as Administrator without first tripping several controls defenders often expect to help. No Domain Admin password need be reset. No Domain Admin account need be created. No SACL need fire until the forged identity touches a monitored object. No LSASS on any host need be dumped for the ticket-minting step. No signature-based IDS rule is guaranteed to trigger. 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 [787]. 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.

In the gap-analysis scenario, earlier in the engagement, the attacker used a DCSync-style replication request against the krbtgt object from a member-server foothold and obtained the krbtgt long-term key material [261]. Then they used Golden-Ticket tooling to forge a ticket from scratch. The important point for this chapter is not the operator syntax; it is the trust-chain gap: the forged ticket validates because the attacker holds the same domain key the KDC uses. The extraction tooling itself (Mimikatz and its lsadump::dcsync module) is owned by the Mimikatz chapter (Chapter 14), whose Residual routed exactly this problem here: Golden Ticket and krbtgt forgery begin where credential theft ends.

Classic Golden-Ticket tooling performs three steps in one local process: it builds a TGT, computes the PAC signatures under the held krbtgt key, and places the resulting bearer ticket into the client Kerberos cache. Sean Metcalf documented that operator workflow in 2015 [650]. This chapter treats the workflow only as gap analysis: the network sees a later TGS request presenting a ticket that decrypts under the domain key, so the KDC accepts the ticket as if it had issued it.

Count the controls that may not fire while the forged ticket is being minted and first 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, until the forged identity touches a SACL-covered resource. No LSASS dump on a writeable DC, because DCSync is a replication API call, not a memory scrape [788]. No signature-based IDS hit on a known-malicious payload, if the malicious work stays in attacker process memory and the wire traffic is, structurally, a TGS-REQ. No MFA prompt or Conditional Access decision for the on-prem Kerberos leg itself, because Kerberos pre-authentication is satisfied by holding a valid TGT and the TGT was minted offline. Downstream resource logs can still record access; the gap is that they see an already-authorized identity, not the key disclosure that made it possible.

This chapter'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 [789] and does cryptographically invalidate forged tickets. But under a confirmed key-disclosure incident, the operational recovery posture often expands to forest recovery or rebuild 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 [789]; Mandiant- and SpecterOps-style incident-response playbooks often escalate confirmed krbtgt compromise to forest-recovery or rebuild planning under systemic-compromise assumptions [790]. Both postures can be 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.

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 [791].

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

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 among the default accounts in the domain's Users container, with the verbatim note that "the KRBTGT account can't be enabled in Active Directory" [791]. It is a built-in domain account, not a local SAM account in the ordinary workstation sense. 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 [792]. 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" [793]. (Note. RIDs below 1000 are reserved for built-in security principals: 500 is Administrator, 501 is Guest, 502 is krbtgt; the first RID assigned to a user-created principal is 1000.) 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.

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" [791]. 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" [791]. 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. Microsoft's forest-recovery guidance is precise: ADUC asks the operator to type a new password, but "the password that you specify isn't significant because the system generates a strong password automatically independent of the password that you specify" [789]. The reset is still a real password-write and key-derivation event: it advances the current/previous key slots, updates pwdLastSet, and replicates like any other domain secret. What operators do not control is the resulting secret value; rotation is the supported primitive they have over it.

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" [789]. This is the mechanical foundation for the two-reset procedure this chapter later dissects. 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 (the subject of the Credential Guard chapter, Chapter 15), does not isolate this read on writeable DCs by design: a DC must read the key to issue tickets [87] (see also the aside below 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 this chapter cares about the long-term cryptographic key it holds.

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 [741]. 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 each ticket with the long-term key of the ticket's server principal (RFC 4120 §5.3); for a TGT, that server principal is krbtgt/CONTOSO.LOCAL@CONTOSO.LOCAL, so every TGT is encrypted under the krbtgt long-term key [794]. 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.

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 [741].

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 [743]. 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 [743], a TGT-resident PAC carries three of them:

1. 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) [743].

2. 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 the KrbtgtFullPacSignature discussion [795].

3. 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 [795][755]. 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.

PAC-signature walkthrough. Read the TGT-resident PAC as a three-step integrity chain, not as three independent authorities:

1. The KDC builds the PAC contents: user SID, group SIDs, account restrictions, logon metadata, and policy fields.
2. Because the ticket being issued is a TGT, the "service" named in the ticket is krbtgt/DOMAIN. The server-signature key is therefore the krbtgt long-term key, not an application server key.
3. The KDC then computes the KDC signature under the same krbtgt long-term key, binding the server signature to the domain KDC authority.
4. On patched domains, the KDC also computes the Full PAC Signature over the whole PAC buffer, including the older signatures, again under the krbtgt long-term key.
5. The EncTicketPart containing that PAC is encrypted under the krbtgt key and sent as the TGT. Later, when any DC receives that TGT in a TGS-REQ, validation is a local cryptographic check: decrypt under krbtgt, verify the PAC signatures, and issue a service ticket if the checks pass.

The Full PAC Signature adds bytes to the signed surface and closes unsigned-PAC rewriting classes, but the arrows still converge on one secret. A defender who asks "which signature did the attacker fail to compute?" gets a useful question only when the attacker lacks the krbtgt key. Once the attacker has that key, all three checks become reproducible outputs of the same secret.

This is the architectural fact the rest of this chapter 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 attack cascade and the 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. The enctype numbers are assigned in RFC 3961/3962/4757 and the IANA Kerberos registry; common Windows values are AES-256-CTS-HMAC-SHA1-96 (enctype 18), AES-128 (enctype 17), and the legacy RC4-HMAC (enctype 23) [741]. 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 materialize the AES keys. The post-2016 AES-SHA2 family (enctypes 19 and 20, RFC 8009) is defined by IETF but not documented as deployed in mainline Windows production in the current [MS-KILE] public documentation cited here [794].

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 [794]. 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 this chapter rests on. The next section explains how a 1988 academic design decision became the cryptographic foundation of every Windows domain alive today.

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" [741]. The principal name krbtgt is in that paper. It has been carried forward unchanged through RFC 1510 (1993) [748], through Active Directory's February 2000 release, through RFC 4120 (2005) [741], through the first [MS-KILE] revision (2007), and into the current [MS-KILE] public documentation cited here [794]. 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 began at MIT in May 1983 and formally ended on June 30, 1991, after IBM and DEC helped fund and equip a campus-scale distributed-computing environment [796][797]. 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 [745].

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, standardizing Kerberos version 5 [748]. 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 in the Windows 2000 release wave (RTM December 15, 1999; worldwide availability February 17, 2000) [798][70]. 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" [791].

RFC 4120, published in July 2005 by Neuman, Yu, Hartman, and Raeburn, obsoleted RFC 1510 [741]. The principal name carried forward unchanged again. RFC 4120 section 5.3 defines the wire format of a ticket; section 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 [794]. 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 [791][789].

Every Active Directory domain has a krbtgt principal in it, and conventional Kerberos realms inherit the same Ticket-Granting Service naming pattern from the IETF design. The name has not moved in thirty-eight years. Only the AD-specific overlay is what gives this chapter 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.

The attack cascade, 2014 to 2024

Six generations of attack span ten years, but they do not all belong to the same class. MS14-068 was a historical KDC/PAC-validation bug: an authenticated user could obtain elevated Kerberos authorization without first stealing the krbtgt key. Golden, Diamond, and Sapphire are the post-fix forgery line: absent a KDC validation bug, they require the krbtgt key and get progressively better at hiding the forgery inside genuine-looking wire traffic. By 2022, the forged artifact and the legitimate TGT can be wire-indistinguishable. Here is how that arc unfolded.

Academic baseline before November 2014

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; [MS-PAC] specified keyed PAC signatures, while MS14-068 later showed that Windows KDC signature-verification behavior did not enforce the intended authority boundary [743][799][800]. 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.

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)" [799]. The disclosure: the KDC validated PACs using a checksum algorithm that did not actually depend on the krbtgt key. Any authenticated domain user could obtain a legitimate TGT, then submit a TGS-REQ carrying forged PAC authorization data that asserted Domain Admin group membership, and the vulnerable KDC would accept the forged checksum instead of enforcing the krbtgt-keyed PAC signature. 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'" [800]. CVSS 9.0. Critical for every supported Windows Server SKU. Exploited in the wild within hours of the bulletin.

Microsoft describes the patch as correcting Kerberos signature-verification behavior [799]. The practical result was to restore PAC integrity to dependence on the keyed construction [MS-PAC] specifies. It also made the defensive dependency explicit: after MS14-068, absent another validation bug, an attacker who wanted arbitrary TGT authority had to hold the krbtgt key itself. From November 18, 2014 onward, an attacker who held that key did not just hold a useful credential; the attacker held the credential the KDC could not check above.

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 [801]. 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 [650]. 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 [787]; Benjamin Delpy's Mimikatz tooling operationalised it [261].

Flow in prose. In a Golden Ticket gap analysis, the attacker who already holds the krbtgt key constructs the TGT locally, signs and encrypts it under that key, and inserts it into a Kerberos cache. The KDC is not asked to issue the TGT; it sees only a later TGS-REQ whose presented TGT decrypts and verifies under the domain key.

Golden Ticket sequence, rendered without offensive syntax:

1. Attacker already holds the domain krbtgt key material.
2. Local process chooses the claimed client SID, group SIDs, timestamps, and PAC contents.
3. Local process computes the PAC server, KDC, and Full PAC signatures under krbtgt.
4. Local process encrypts the TGT EncTicketPart under krbtgt and places the ticket in a cache.
5. Client presents that TGT in a later TGS-REQ.
6. DC decrypts and verifies the TGT with krbtgt, then issues a service ticket.
7. Target service sees a normal service ticket produced by the DC and makes its access decision.

The teaching point of the sequence is not how to operate a tool. It is where the trust check occurs: the first domain-controller contact may be the TGS-REQ, not TGT issuance. If the forged TGT is cryptographically consistent with the krbtgt key, the KDC has no issuance log above that key to consult.

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 artifacts that Microsoft Defender for Identity ships dedicated alerts for, under the umbrella of the Suspected-Golden-Ticket alert family [802][803]. 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) [802].

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 Diamond and Sapphire interesting.

Silver Ticket as the parallel path

Silver Tickets deserve more than a footnote because they define the boundary of the krbtgt problem. A Silver Ticket is a forged service ticket (TGS), not a forged TGT. The attacker does not need the krbtgt key and does not ask the KDC to issue anything. They need the long-term key of the target service account: a machine-account key for CIFS on a file server, an HTTP service-account key for a web application, an MSSQL service-account key for SQL Server, or any SPN-bearing principal whose key the service will use to decrypt incoming AP-REQs. MITRE catalogs that sibling technique as T1558.002 [804].

The trust root is therefore different. Golden, Diamond, and Sapphire abuse the domain's TGT issuer. Silver abuses one service's local verifier. When a file server accepts a Kerberos AP-REQ, it decrypts the service ticket with its own key. If the attacker forged a ticket that decrypts under that key and carries a PAC whose signatures the service path accepts, the service can grant access without the KDC ever seeing the forged artifact. That is why a Silver Ticket can be quiet on domain-controller telemetry: there may be no TGS-REQ corresponding to the service ticket that later appears at the server.

Silver Ticket sequence, at the verifier boundary:

1. Attacker already holds one SPN-bearing account key, not the krbtgt key.
2. Local process builds a service ticket whose sname targets that SPN.
3. The ticket is encrypted under the service account or machine account key.
4. The client presents the ticket directly to the target service in an AP-REQ.
5. The service decrypts with its own key and evaluates the PAC/access token path it normally uses.
6. The KDC may never see the forged ticket, because no TGS-REQ was needed for this artefact.

That last line is the detection constraint. A Golden-class forgery usually leaves at least a later DC-side TGS-REQ because the forged TGT must be exchanged for a service ticket. A Silver-class forgery can start at the service boundary. The most reliable analytic is therefore correlation, not a single event: a server accepted a Kerberos logon, but the DCs did not issue a matching service ticket for that client, SPN, time window, and encryption type. That correlation is operationally hard in large domains because DC logs are distributed, service clocks skew, ticket caches are reused, and legitimate constrained-delegation or S4U flows can also decouple the service-side event from a simple client-initiated TGS request.

The blast radius is also different. A stolen krbtgt key mints TGTs that can request service tickets anywhere in the domain. A stolen CIFS service key mints tickets only for that CIFS service identity. If the captured account is a broadly reused service account with SPNs on many hosts, the blast radius can still be large; if it is a single machine account, the blast radius is usually that machine's services. This is the practical reason Silver belongs in the chapter: it prevents a common category error. Rotating krbtgt twice invalidates forged TGTs. It does not rotate every service-account key in the domain, and therefore does not by itself evict Silver Ticket persistence.

The exact constraints are crisp. Silver does not let the holder of a random user password mint arbitrary domain TGTs. It does not cross to unrelated SPNs unless the same account key backs those SPNs. It does not survive reset of the affected service or machine account key. It does not prove krbtgt compromise when observed. Conversely, krbtgt double rotation does not evict it, because the verifying key is not krbtgt. The incident owner has to ask "which long-term key verified this ticket?" before choosing a rotation plan.

The detection model follows the same boundary. Golden-ticket detections look for impossible or suspicious TGT properties: wrong enctype, implausible lifetime, nonexistent account, group claims that do not match the directory, or later TGS use of a suspect TGT [802][803]. Silver-ticket detection often has to compare service-side logon events with KDC-side issuance events: did the server accept a Kerberos logon for which no matching TGS-REQ was observed? Did the ticket target an SPN whose account password age or delegation settings make key theft plausible? Did the PAC claim groups that the directory does not support for that principal? These are useful but service-local questions, not krbtgt questions.

Recovery is likewise separate. After confirmed krbtgt compromise, double-rotate krbtgt. After confirmed Silver Ticket abuse, reset the affected service account or machine account, purge existing tickets where possible, review SPN placement, and remove unnecessary shared service accounts. In a mature incident response, both workstreams may run at once because an operator with DCSync rights can usually extract both krbtgt and service-account secrets. But the cryptographic guarantees are not interchangeable: krbtgt rotation fixes the TGT issuer; service-key rotation fixes the service verifier. Confusing the two leads to false closure.

Diamond Ticket

In July 2022, Andrew Schwartz (TrustedSec) and Charlie Clark (Semperis) co-published "A Diamond (Ticket) in the Ruff," cross-posted on the TrustedSec and Semperis blogs, documenting a refinement of Golden Ticket that defeats every PAC-content anomaly detection in one stroke [772][771]. 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 artifact.

Flow in prose. In a Diamond Ticket gap analysis, the attacker first obtains a real KDC-issued TGT for a low-privilege account, decrypts the TGT with the held krbtgt key, edits the PAC, recomputes the PAC signatures, and re-encrypts the ticket. The resulting ticket keeps the KDC-issued envelope properties while changing the authorization claim inside.

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.

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. That response is the KrbtgtFullPacSignature rollout.

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 [805][806]. 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 uses that KDC-issued PAC as source authorization data for a freshly constructed TGT and, because they hold the krbtgt key, produces whatever TGT-resident PAC signatures the final artifact must validate with.

Flow in prose. In a Sapphire Ticket gap analysis, the attacker combines S4U2self and User-to-User to obtain a service ticket containing KDC-issued authorization data for the target user, then uses that PAC material while constructing a new TGT whose final signatures validate under the held krbtgt key. The detection problem changes because the authorization contents are not synthetic; they originate as real KDC output reused in a forged container.

By construction, there is no simple PAC-content anomaly to detect: the authorization claims began as KDC output for the target user. The important defensive statement is not that every PAC buffer can be transplanted blindly between ticket contexts; [MS-PAC] is precise about ticket, extended-KDC, server, and KDC signatures and about when the KDC recomputes them [743]. The safe claim is narrower: because the attacker holds the krbtgt key, they can produce a final TGT-resident PAC/signature set that validates. Detection must move to traffic-flow analysis (specifically, the anomalous S4U2self plus U2U TGS-REQ sequence on the wire) and in the vendor documents surveyed for this chapter I found no clean canonical default-enabled analytic for that signal as of May 2026 [775][808].

The empirical artifact is the Impacket pull request #1411, in which Bromberg added the -impersonate flag to ticketer.py to put the tool into "sapphire ticket mode" [809][806]. Palo Alto Unit 42's "Precious Gemstones" survey is the vendor-side state-of-the-art summary [775].

KrbtgtFullPacSignature

Microsoft's formal response to the post-2014 attack arc shipped as KB5020805 starting November 8, 2022, addressing CVE-2022-37967 [795][755]. 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:

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

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, where the authorization contents originate as KDC-issued PAC data; the attacker still relies on the held krbtgt key to make the final TGT-resident signature set validate in its new container.
• Recomputed Diamond Tickets, in which the attacker 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 (all three signatures terminating at the same key) is exactly why this is so.

Comparing the three forgery variants

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?

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.

Posture with the 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 on the domain naming context (exercised by replicating from a writable 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 [808].

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 presenting a forged TGT, the posture layer has already missed its window.