KRBTGT: The Account That Owns Active Directory

1. Ninety Seconds to Domain Admin#

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

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

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

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

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

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

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

2. The Account: RID 502, Disabled, Indelible#

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

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 as one of the three default local accounts in the Users container, with the verbatim note that "the KRBTGT account can't be enabled in Active Directory" ^[7]. 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 ^[8]. 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" ^[9]. ※ RIDs 500 through 1000 are reserved for built-in security principals; 500 is Administrator, 501 is Guest, 502 is krbtgt. Renaming the sAMAccountName cannot move the RID. The KDC service derives its key lookups from the principal name, which binds to the RID, not from the friendly name shown in ADUC. Renaming krbtgt as a defensive measure is a fallacy that the next section will sharpen further.

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" ^[7]. 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" ^[7]. ADUC will show a renamed display, but the underlying object identity (the RID, the principal name) is fixed by the directory schema and by LsaSrv enforcement on the writeable DCs.

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

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" ^[5]. This is the mechanical foundation for the two-reset procedure Section 7 will dissect. The KDC keeps both a current and a previous key in the krbtgt account; in-flight TGT validation tries both during the brief window after a rotation; one reset retires only the older of the two; a second reset, separated by at least the maximum ticket lifetime, evicts the key the attacker held.

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

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

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

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

The Microsoft specification puts it as plainly as is possible to put it. [MS-KILE] specifies that the KDC encrypts every ticket using the long-term cryptographic key of the krbtgt principal, citing RFC 4120 §5.2.2 ^[12]. 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 ^[11].

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 ^[13]. 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 ^[13], 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) ^[13].

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 §5 Generation 6 ^[14].

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 ^[14][15]. Computed by the KDC over the entire PAC -- including the older two signatures -- and stored alongside them. Also computed under the krbtgt long-term key.

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

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

The enctype matrix#

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

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 ^[12]. No Kerberos extension shipped through 2026 moves the TGT's trust anchor anywhere other than the krbtgt long-term key.

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

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

// Simplified model of the three PAC signatures on a TGT.
// Each signature is a keyed HMAC computed under the krbtgt long-term key.
const pacContents = "SIDs, groups, restrictions";
const krbtgtKey = "<32-byte AES-256 long-term key>";

function hmac(key, data) {
return key === krbtgtKey
  ? "SIG(" + data + ")"           // attacker-with-key computes valid sigs
  : "INVALID";                    // attacker-without-key cannot forge them
}

function buildPACBlock(attackerKey) {
const serverSig = hmac(attackerKey, pacContents);
const kdcSig    = hmac(attackerKey, serverSig);
const fullPAC   = hmac(attackerKey, pacContents + serverSig + kdcSig);
const validates = [serverSig, kdcSig, fullPAC].every(s => s !== "INVALID");
return { serverSig, kdcSig, fullPAC, validates };
}

console.log("with krbtgt key   :", buildPACBlock(krbtgtKey).validates);
console.log("without krbtgt key:", buildPACBlock("guess-key").validates);

4. Origins: 1988 Athena, RFC 4120, [MS-KILE]#

Open the bibliography of RFC 4120 and find an entry tagged [Ste88]: "Steiner, J., Neuman, C., and J. Schiller, 'Kerberos: An Authentication Service for Open Network Systems,' USENIX Conference Proceedings, February 1988" ^[11]. The principal name krbtgt is in that paper. It has been carried forward unchanged through RFC 1510 (1993) ^[16], through Active Directory's February 2000 release, through RFC 4120 (2005) ^[11], through the first [MS-KILE] revision (2007), and into the current [MS-KILE] revision 47.0 dated April 27, 2026 ^[12]. Thirty-eight years.

What did the 1988 design decision look like, and what has changed about its security properties since?

MIT Project Athena, 1983-1991#

Project Athena ran at MIT from 1983 to 1991 as a campus-scale distributed-computing experiment funded primarily by IBM and DEC ^[17]. 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 ^[18].

The design property that one key encrypts every TGT was not framed in 1988 as a security risk. It was framed as a simplification: by giving the TGS one stable identity that issues every TGT, the protocol does not need to negotiate per-session KDC identities or per-server validation paths. The protocol reduces, mathematically, to two questions: did the KDC issue this TGT, and did the TGT permit the subsequent TGS-REQ for this service? Both reduce to "does this signature validate under the krbtgt key?"

From RFC 1510 to [MS-KILE]#

John Kohl and Clifford Neuman published RFC 1510 in September 1993, standardising Kerberos version 5 ^[16]. The krbtgt/DOMAIN@DOMAIN principal-name convention carried forward unchanged from Athena. RFC 1510 is the document Microsoft engineers read when they chose Kerberos v5 as the Windows 2000 default authentication protocol; the krbtgt account became part of the AD schema at the Windows 2000 ship date (RTM December 15, 1999; general availability February 17, 2000) ^[19]. 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" ^[7].

RFC 4120, published in July 2005 by Neuman, Yu, Hartman, and Raeburn, obsoleted RFC 1510 ^[11]. The principal name carried forward unchanged again. Section 5.3 defines the wire format of a ticket; §6.2 defines the principal-name convention. Microsoft Open Specifications then published the first [MS-KILE] revision in March 2007, documenting the Windows wire profile on top of RFC 4120. The current revision -- 47.0, dated April 27, 2026 -- still says the same thing: the krbtgt long-term key encrypts every TGT ^[12]. 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 ^[7][5].

Every Kerberos domain on the public Internet today has a krbtgt principal in it. The name has not moved in thirty-eight years. Only the AD-specific overlay is what gives this article its Windows-specific subject; the protocol substrate is older than the attack surface by twenty-six years.

The principal name and the trust property are nearly forty years old. The exploit chain that targets them is twelve. The interesting question is what happened in the twelve years that turned an academic design decision into the most consequential single key in enterprise computing. That story has a beginning at Black Hat USA on August 7, 2014.

5. The Attack Cascade, 2014 to 2024#

Six generations of attack span ten years. None of them found a way to forge a TGT without the krbtgt key; the search space is mathematically closed in that direction. What they did instead is get progressively better at hiding the forgery inside genuine-looking wire traffic. By 2022, the forgery and the legitimate TGT are wire-indistinguishable. Here is how that arc unfolded.

gantt
title Attack and defence generations
dateFormat YYYY-MM-DD
axisFormat %Y
section Attack
Gen 0 Academic baseline       :done, g0, 2000-02-01, 2014-08-05
Gen 1 MS14-068 PAC forgery    :crit, g1, 2014-11-18, 90d
Gen 2 Golden Ticket           :crit, g2, 2014-08-07, 2920d
Gen 3 Silver Ticket           :       g3, 2015-01-01, 4000d
Gen 4 Diamond Ticket          :crit, g4, 2022-06-21, 1700d
Gen 5 Sapphire Ticket         :crit, g5, 2022-10-15, 1300d
section Defence
MS14-068 patch                :done, d1, 2014-11-18, 30d
MDI alert family              :done, d2, 2016-01-01, 800d
Full PAC Signature audit      :done, d3, 2022-12-13, 210d
Full PAC Signature enforce    :done, d4, 2023-07-11, 90d
Compatibility removed         :done, d5, 2023-10-10, 30d

Generation 0 (pre-November 2014): the academic baseline#

Two assumptions held for fourteen years between Windows 2000 RTM and Black Hat USA 2014. First, the PAC's two signatures -- the Server Signature and the KDC Signature -- were treated as adequate; the [MS-PAC] specification required the KDC Signature to be a keyed HMAC under the krbtgt key, but Windows KDCs in practice accepted weaker non-keyed checksums on it (CRC32, RSA-MD5) ^[13][20]. Second, the long-term krbtgt key was held only on writeable DCs and was considered unreachable to remote attackers because no remote primitive existed to extract it. Both assumptions failed within months of each other. The MS14-068 disclosure broke the first; the productionised DCSync primitive in Mimikatz broke the second.

Generation 1 (November 18, 2014): MS14-068 and CVE-2014-6324#

On November 18, 2014, Microsoft published security bulletin MS14-068, "Vulnerability in Kerberos Could Allow Elevation of Privilege (3011780)" ^[20]. The disclosure: the KDC validated PACs using a checksum algorithm that did not actually depend on the krbtgt key. Any authenticated domain user could forge a PAC asserting Domain Admin group membership, attach it to an otherwise-valid AS-REQ exchange, and the KDC would accept the forgery. The NVD entry for CVE-2014-6324 records that the bug "allows remote authenticated domain users to obtain domain administrator privileges via a forged signature in a ticket, as exploited in the wild in November 2014, aka 'Kerberos Checksum Vulnerability'" ^[21]. CVSS 9.0. Critical for every supported Windows Server SKU. Exploited in the wild within hours of the bulletin.

Microsoft's patch replaced the weak checksum with a real keyed HMAC under the krbtgt key, the same construction the [MS-PAC] document specifies today. The patch was correct: it restored PAC integrity to actual dependence on a real secret. It also, as a side-effect, elevated the krbtgt key from "an important secret in the directory" to "the load-bearing secret of every authentication decision in the domain." From November 18, 2014 onward, an attacker who held the krbtgt key did not just hold a useful credential; the attacker held the only credential the KDC could not check above.

The MS14-068 patch was correct -- it restored PAC integrity to dependence on the krbtgt key. Its side-effect was to elevate the krbtgt key from "important" to "load-bearing for every authentication decision in the domain." From November 18, 2014 onward, the krbtgt key was the single secret worth attacking directly.

Generation 2 (August 7, 2014): Golden Ticket#

Skip Duckwall and Benjamin Delpy presented "Abusing Microsoft Kerberos: Sorry you guys don't get it" at Black Hat USA on August 7, 2014 ^[22]. 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 ^[3]. 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 ^[1]; Benjamin Delpy's Mimikatz kerberos::golden command operationalises it ^[2].

sequenceDiagram
participant A as Attacker (holds krbtgt key)
participant L as Local Kerberos cache
participant K as KDC on a DC
participant S as Target service
A->>A: Choose target SID and groups
A->>A: Build EncTicketPart locally
A->>A: HMAC PAC signatures under krbtgt key
A->>A: AES-encrypt enc-part under krbtgt key
A->>L: kerberos::ptt -- inject ticket
L->>K: TGS-REQ presenting forged TGT
K->>K: Decrypt TGT with krbtgt key -- valid
K->>L: TGS-REP for target service
L->>S: Present service ticket -- access granted

The Golden Ticket works because of the single-key trust property the 1988 design chose. There is nothing in the protocol that asks "is this TGT in the KDC's issuance log?" The TGT is self-verifying. If it decrypts and its signatures validate under the key, it is, by definition, a TGT.

Why, then, does Golden Ticket sometimes get caught? Because the default Mimikatz invocation leaves four observable artefacts that Microsoft Defender for Identity ships dedicated alerts for, under the umbrella of the Suspected-Golden-Ticket alert family ^[23][24]. 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) ^[23].

The structural observation: every alert in this family detects symptoms of forging from scratch. None of them detects the primitive of holding the krbtgt key. That distinction is what makes Generation 4 (Diamond) and Generation 5 (Sapphire) interesting.

Generation 3 (parallel path): Silver Ticket#

Silver Tickets forge a service ticket (TGS) under a captured service-account key. They sidestep the krbtgt key entirely; the KDC is never involved in the forgery, and the forgery validates only against the one service whose key was captured. MITRE T1558.002 catalogues the technique ^[25]. Mentioned here so the question stops being asked. Silver Tickets are a sibling technique that targets a different trust root (per-service account keys), not the krbtgt key.

Generation 4 (June 2022): Diamond Ticket#

In June 2022, Andrew Schwartz at TrustedSec and Charlie Clark at Semperis co-published "A Diamond in the Ruff," documenting a refinement of Golden Ticket that defeats every PAC-content anomaly detection in one stroke ^[26][27]. The technique: instead of forging the TGT from scratch, the attacker requests a real TGT from the KDC, then decrypts its enc-part using the held krbtgt key, modifies the PAC contents, re-signs the PAC under the krbtgt key, re-encrypts the enc-part, and walks away with a ticket whose every wire property -- sname, cname, authtime skew matching the real KDC's clock, plausible endtime, AES-256 envelope -- looks like a legitimate KDC-issued artefact.

sequenceDiagram
participant A as Attacker (low-priv user, holds krbtgt key)
participant K as KDC on a DC
participant L as Local Kerberos cache
participant S as Target service
A->>K: AS-REQ for low-priv user
K->>A: Real TGT, encrypted under krbtgt key
A->>A: Decrypt enc-part with held krbtgt key
A->>A: Modify PAC SIDs to Domain Admins
A->>A: Recompute PAC signatures under krbtgt key
A->>A: Re-encrypt enc-part under krbtgt key
A->>L: ptt -- inject modified TGT
L->>K: TGS-REQ presenting Diamond TGT
K->>K: Decrypt -- valid, signatures match
K->>L: TGS-REP for target service
L->>S: Access granted as Domain Admin

Every MDI Suspected-Golden-Ticket detection disappears, by construction. The encryption type is AES-256 because the KDC issued it that way. The lifetime matches the AD policy because the KDC set it that way. The cname matches a real account because the attacker requested the TGT as a real low-privilege account they own. The only thing the attacker changed is the group SIDs inside the PAC, and the PAC signatures revalidate because the attacker recomputed them under the same krbtgt key the KDC would have used.

The Diamond Ticket disclosure pointed at an architectural problem: with the krbtgt key in hand, every PAC-content anomaly detection is defeated. Microsoft's structural answer was the Full PAC Signature in November 2022. We come to that in Generation 6.

Generation 5 (October 2022): Sapphire Ticket#

Charlie Bromberg, who publishes under the handle Shutdown (@_nwodtuhs) at Synacktiv and maintains The Hacker Recipes wiki, disclosed Sapphire Ticket in October 2022 ^[28][29]. Where Diamond modifies the PAC, Sapphire splices the PAC. The procedure abuses two Kerberos extensions in combination -- Service-for-User-to-Self (S4U2self) and User-to-User (U2U) -- to coerce the KDC into issuing a service ticket whose embedded PAC describes a target user the attacker wishes to impersonate. The attacker then extracts that genuine PAC from the service ticket and embeds it, unchanged, in a freshly constructed TGT signed under the held krbtgt key.

sequenceDiagram
participant A as Attacker (low-priv user, holds krbtgt key)
participant K as KDC on a DC
participant L as Local Kerberos cache
participant S as Target service
A->>K: AS-REQ for low-priv user
K->>A: Real attacker TGT
A->>K: S4U2self + U2U TGS-REQ for target user
K->>A: TGS containing target user's genuine PAC
A->>A: Extract genuine PAC from TGS
A->>A: Build new TGT, embed genuine PAC
A->>A: Sign three PAC signatures under krbtgt key
A->>A: Encrypt enc-part under krbtgt key
A->>L: ptt -- inject Sapphire TGT
L->>K: TGS-REQ presenting Sapphire TGT
K->>K: Decrypt -- valid, PAC is genuine
K->>L: TGS-REP for target service
L->>S: Access granted as target user

By construction, there is no PAC-content anomaly to detect: the PAC inside the resulting TGT is literally a PAC the KDC issued for the target user, because the KDC did issue it. The PAC's three signatures revalidate because the attacker held the krbtgt key to sign them; if Microsoft validates the Full PAC Signature on incoming tickets, that signature also validates because the attacker computed it under the same krbtgt key. Detection must move to traffic-flow analysis -- specifically, the anomalous S4U2self plus U2U TGS-REQ sequence on the wire -- and as of May 2026 no vendor has shipped a clean canonical default-enabled analytic for that signal ^[31].

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

Generation 6 (November 2022 to October 2023): KrbtgtFullPacSignature#

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

Here is the structural fact. The Full PAC Signature is also computed under the krbtgt key. So an attacker who holds the krbtgt key still mints fully-validating tickets, including:

• Sapphire Tickets, which never modify the PAC at all; the existing signatures the KDC issued are valid by construction, the Full PAC Signature included.
• Recomputed Diamond Tickets, in which the attacker simply computes the Full PAC Signature alongside the older KDC signature in the same step, because both depend on the same key the attacker holds.

KrbtgtFullPacSignature retired one specific class of attack (Diamond Tickets that did not recompute the Full PAC Signature). It did not retire the underlying primitive (TGT forgery from a known krbtgt key). The PAC signature surface in Section 3 -- all three signatures terminating at the same key -- is exactly why this is so.

The Full PAC Signature was Microsoft's structural response to Diamond Ticket. It is itself computed under the krbtgt key. So an attacker who holds the krbtgt key recomputes it in the same step as the KDC signature -- and Sapphire Tickets, which never modify the PAC at all, are unaffected by construction. CVE-2022-37967 retired one class of attack (PAC-modifying Diamond variants); it did not retire the primitive.

Comparing the three forgery variants#

Six generations from MS14-068 to KrbtgtFullPacSignature, and the residual primitive is exactly what the 1988 paper described: hold the key, mint the ticket. So what does the detection topology in 2026 actually catch?

6. The Detection Stack in 2026#

Detection of krbtgt-class attacks in 2026 is a four-layer stack. Each layer has a specific class of signal it reads, a specific class of attack it catches, and a specific gap that the next layer is supposed to close. Three of the four layers have a known gap above them. The fourth has nothing above it.

flowchart TD
L4["Layer 4 -- S4U2self plus U2U residual (no vendor analytic shipped)"]
L3["Layer 3 -- Network/SIEM (Sentinel, Splunk T1558.001)"]
L2["Layer 2 -- Behavioural (MDI Suspected-Golden-Ticket family)"]
L1["Layer 1 -- Posture (BloodHound DCSync edge)"]
KEY["krbtgt long-term key (the attacker's objective)"]
L1 --> L2
L2 --> L3
L3 --> L4
L4 --> KEY

Layer 1: posture (BloodHound DCSync edge)#

The posture layer asks a question with no per-event component: "Who has rights that could extract the krbtgt key, regardless of whether they have used those rights?" In Active Directory terms, the answer is "anyone holding DS-Replication-Get-Changes plus DS-Replication-Get-Changes-All rights against a writeable DC, plus anyone who holds privileges that allow them to grant those rights to themselves." BloodHound encodes the answer as a DCSync edge in its graph; the canonical community Cypher query is MATCH (u)-[:DCSync]->(d:Domain) RETURN u, d. The current shipping release of BloodHound Community Edition is v9.1.0, dated 2026-05-06 per the release notes ^[34].

What this layer detects: any principal whose existing AD permissions create a path to the krbtgt key. What this layer misses: any attacker who already has the key. Posture is preventive, not detective. By the time the attacker is invoking kerberos::golden, the posture layer has already missed its window.

Layer 2: behavioural (Microsoft Defender for Identity)#

Microsoft Defender for Identity ships an alert family covering classic Golden-Ticket-from-Mimikatz behaviour. The live MDI classic alerts page enumerates six Suspected-Golden-Ticket External IDs: 2009 (encryption downgrade), 2013 (forged authorization data), 2022 (time anomaly), 2027 (nonexistent account), 2032 (ticket anomaly), and 2040 (ticket anomaly using RBCD) ^[23]. The Credential access section adds External ID 2006 for "Suspected DCSync attack" on the extraction side ^[23].

What this layer detects: the Mimikatz Golden Ticket defaults plus the DCSync extraction primitive that produces the krbtgt key in the first place. What this layer misses: Diamond and Sapphire by construction. Diamond removes the PAC-content anomalies because every artefact except the modified group SIDs comes from the real KDC. Sapphire defeats PAC-content anomaly detection entirely by using a PAC the KDC genuinely issued via S4U2self plus U2U.

The MDI credential-access alerts page is the entry point to the family in the modern Microsoft Defender XDR console layout ^[24].

Layer 3: network and SIEM (Sentinel, Splunk)#

Multi-vendor SIEM content packs ship analytic rules covering Kerberos behaviours flagged under MITRE T1558.001. Splunk's research catalogue contains the canonical example: "Kerberos Service Ticket Request Using RC4 Encryption" detects TGS-REQ traffic with encryption-type 0x17 (RC4-HMAC), leveraging Windows Event 4769 from the DCs ^[36]. Microsoft Sentinel ships parallel rules under the Microsoft Defender XDR content connector. The pattern these analytics share is reliance on encryption-type anomalies, group-membership anomalies, or lifetime anomalies that appear in Windows event logs after the fact.

What this layer detects: signature-style indicators of Golden Ticket behaviour on the wire and in the DC event log. What this layer misses: the same encryption-downgrade dependency MDI's alert 2009 has. The Splunk analytic verbatim acknowledges its own limit: "This detection may be bypassed if attackers use the AES key instead of the NTLM hash" ^[36]. Diamond and Sapphire both use the AES-256 key. Both walk through this layer untouched.

Layer 4: the Sapphire residual#

What would catch a Sapphire Ticket? The only wire-observable residual of the technique is the conjunction of (a) a TGS-REQ specifying the S4U2self flag, and (b) the same TGT being used to address a User-to-User request to the KDC. No other layer of the stack reads this signal because no other attack has historically produced it as a precondition.

What ships: nothing canonical. SpecterOps and the BloodHound content team have signalled graph-query work on the U2U TGS issuance pattern in 2026 trend reports ^[34], but no shipped default-enabled analytic. Palo Alto Unit 42's "Precious Gemstones" survey describes Cortex XDR detection-attempt heuristics but does not publish the rule ^[31]. The gap is engineering, not theoretical: the signal exists, the analytic to read it has simply not been packaged.

Defensive method matrix#

Adjacent T1558 family techniques that are not krbtgt detections#

Detection in 2026 is a four-layer stack, and three of the layers leave gaps the next layer is supposed to close. The fourth gap -- the Sapphire residual -- has no layer above it. When the gaps close enough to confirm a krbtgt compromise, what does recovery actually look like?

7. Recovery: What the Two-Reset Procedure Actually Does#

The Microsoft AD Forest Recovery page states the procedure verbatim:

"You should perform this operation twice. You must wait 10 hours between password resets. 10 hours are the default Maximum lifetime for user ticket and Maximum lifetime for service ticket policy settings, hence in a case where the Maximum lifetime period changes, the minimum waiting period between resets should be greater than the configured value." -- and -- "The password history value for the krbtgt account is 2, meaning it includes the two most recent passwords. By resetting the password twice you effectively clear any old passwords from the history, so there's no way another DC replicates with this DC by using an old password." ^[5]

What exactly do those two resets buy, and what do they not buy?

The mechanics of two-slot eviction#

The krbtgt account, like every other AD account, stores both current and previous keys. A TGT issued at time $T = 0$ under key $K_0$ continues to validate after a rotation at $T = T_1$ (when $K_1$ becomes current and $K_0$ moves to the previous slot), because the KDC tries both keys during the in-flight validation window. One rotation fills the previous slot with the now-replaced $K_0$; the second rotation, separated by at least MaxTicketAge so that all $K_0$-signed TGTs have expired naturally, fills the previous slot with $K_1$ and evicts $K_0$ entirely. After the second rotation completes and replicates, no key in the krbtgt account matches the attacker's extracted $K_0$; forged TGTs from that key fail validation cleanly ^[5].

flowchart LR
A0["T=0: K_0 current, K_prior previous"] --> A1["T=T_1: reset 1 -- K_1 current, K_0 previous"]
A1 --> A2["T_1 + 10h: K_1 still current, K_0 still previous"]
A2 --> A3["T=T_2 (≥ T_1 + 10h): reset 2 -- K_2 current, K_1 previous"]
A3 --> A4["After replication: K_0 evicted from both slots"]

The 10-hour wait between resets is not a Microsoft convenience choice; it is a cryptographic requirement. If the second reset lands before all $K_0$-signed TGTs have expired naturally, some of those tickets will hit a DC whose previous slot now holds $K_1$ rather than $K_0$, and the KDC will reject them. This is what KB5020805's PAC-signature deployment phases also had to navigate during the November 2022 to October 2023 rollout: signature additions and validation transitions had to bracket the maximum in-flight ticket lifetime ^[14].

// Model the krbtgt account as a two-slot store; simulate the two-reset procedure.
function simulate(events) {
const slots = { current: "K_prior", previous: null };
let stolen = null;
for (const ev of events) {
  if (ev.kind === "compromise") {
    stolen = slots.current;
  } else if (ev.kind === "reset") {
    slots.previous = slots.current;
    slots.current  = ev.newKey;
  }
  const validates =
    stolen && (stolen === slots.current || stolen === slots.previous);
  console.log(
    "[t=" + ev.t.toString().padStart(3) + "h]",
    ev.kind.padEnd(11),
    "current=" + slots.current,
    "prev=" + (slots.previous ?? "-"),
    "attacker_validates=" + validates
  );
}
}

simulate([
{ t: 0,  kind: "issue"      },
{ t: 1,  kind: "compromise" },  // attacker stores K_prior as stolen
{ t: 3,  kind: "reset", newKey: "K_1" },
{ t: 13, kind: "reset", newKey: "K_2" },  // ≥ MaxTicketAge later
{ t: 14, kind: "issue"      },
]);

New-KrbtgtKeys.ps1#

Microsoft's reference automation for the procedure is New-KrbtgtKeys.ps1, originally distributed as an MSDN Gallery script and currently hosted in the microsoftarchive GitHub organisation. The repository banner reads, verbatim: "This repository was archived by the owner on Mar 8, 2024. It is now read-only" ^[37]. The script remains the canonical reference for the rotation procedure, including pre-reset and post-reset replication-health checks; it is simply no longer actively maintained. Operators in 2026 commonly fork it locally or wrap the same Set-ADAccountPassword plus replication-status pattern in their own runbooks.

What two-reset does#

Cryptographically invalidates previously-forged TGTs after the second reset replicates fully across all writeable DCs. This is unambiguous and well-documented; the Microsoft Learn page is the primary ^[5]. After step 3 (the second reset) has replicated, no TGT signed under the pre-compromise key validates anywhere in the domain.

What two-reset does not do#

Any attacker who held the krbtgt key has typically already installed parallel persistence. SpecterOps's "Domain of Thrones Part II" by Nico Shyne and Josh Prager, published November 6, 2023, names the rotation list verbatim: "Machine accounts ... User accounts ... Service accounts -- Per domain KRBTGT account ... Trust keys and objects related to trust of all other domains; Group-managed service accounts; Key distribution service root keys" ^[6]. The same playbook enumerates the persistence vectors an attacker with krbtgt access typically establishes: AdminSDHolder ACL edits, AD CS template alternates spanning the ESC1 through ESC8 abuse classes (canonically catalogued in Schroeder and Christensen's "Certified Pre-Owned," SpecterOps, June 2021) ^[38], SID History entries, machine-account secret retention, KDS root key exfiltration, trust-key compromise, and DSRM password exfiltration. Two-reset rotates the krbtgt key only; the rest of the trust-root set is untouched ^[39][6].

Two-reset rotation cryptographically invalidates previously-forged TGTs. It does NOT rotate any of the other secrets an attacker who held the krbtgt key has typically already installed: AdminSDHolder edits, ADCS templates, SID History, machine-account secrets, KDS root keys, trust keys, DSRM passwords. This is why confirmed krbtgt compromise is a forest-rebuild event, not a key-rotation event.

Two-reset rotation is the cryptographic finish; the operational finish spans the rest of the Domain-of-Thrones surface, and the rotation alone cannot reach it. The single-sentence punchline of the article lands at the end of §11.

Recovery has two pieces: a fast cryptographic part (two resets, well-documented) and a slow operational part (seven other secret classes, days to weeks). Both are necessary. Neither is sufficient. Even the combined procedure leaves three structural residuals, which the next section names.

8. Theoretical Limits and Open Problems#

Even with the full Domain-of-Thrones rotation surface executed correctly, three structural residuals remain. Each has a current best-partial-result; none has a closed solution.

(a) The pre-second-reset TGT-lifetime window#

Any TGT minted from the compromised krbtgt key between the moment of compromise and the moment the second reset replicates remains valid until naturally expired or until step 3 lands. Mimikatz's default 10-year lifetime makes this a years-long window if the attacker pre-minted tickets and a careless DC missed the time-anomaly signal. The MDI Suspected-Golden-Ticket family includes a time-anomaly alert (the External ID 2022 sibling) ^[23] that reads the difference between plausible and implausible ticket lifetimes. The window is bounded above by the AD MaxTicketAge floor: at minimum, the procedure must take 10 hours of wall-clock per Microsoft's own guidance ^[5]. Below that floor the cryptographic invalidation does not finish.

The mitigation is procedural: between detection and the start of the rotation, the IR team treats every TGT in the domain as suspect. In practice that means rejecting cached tickets at high-value services, forcing a TGT renewal cycle, and watching the time-anomaly alert closely. The mitigation is not perfect; an attacker who minted tickets with realistic 10-hour lifetimes inside the typical AD policy survives this residual entirely.

(b) AD CS alternate persistence (the ESC class)#

An attacker who held the krbtgt key long enough to also touch AD Certificate Services has often installed an ESC-class alternate-identity persistence: a backdoored certificate template allowing Domain Admin certificate issuance (ESC1), a misconfigured EnrolleeSuppliesSubject template (ESC4), an HTTP-bound CA endpoint vulnerable to NTLM relay (ESC8). The ESC class taxonomy is catalogued in Schroeder and Christensen's "Certified Pre-Owned" white paper (SpecterOps, June 2021) ^[38]. The compromised template or endpoint survives krbtgt rotation entirely. The CA private key is its own trust root, parallel to (not subordinate to) the krbtgt key. Domain-of-Thrones Part II names ADCS as a separate rotation workstream that must be addressed alongside the krbtgt reset ^[6].

The structural fact: a domain with AD CS deployed has at least two cryptographic trust roots (krbtgt long-term key + CA private key) whose compromises are both recoverable only through different mechanisms. PKINIT, the Kerberos pre-authentication extension that validates certificate-bearing AS-REQs, accepts identities the CA chain attests to. Compromise of the CA chain yields valid Kerberos authentication as any principal, by a different mechanism than holding the krbtgt key, with the same end result.

(c) Cross-domain trust-key compromise#

Within a multi-domain forest, the krbtgt of each domain is trusted by the others through inter-domain trust keys. A krbtgt compromise in a child domain can become a forest-level event if the trust topology is not hardened: SID Filtering misconfigurations, missing Selective Authentication on outbound trusts, or stale forest-trust artefacts from earlier domain migrations all extend the blast radius beyond the directly-compromised domain. Microsoft's "Recover from systemic identity compromise" guidance and the AD Forest Recovery procedure index together cover the cross-domain rotation requirements; Domain-of-Thrones Part II's "Trust keys and objects related to trust of all other domains" entry is the concise operational statement ^[6].

The mitigation is architectural: domain-isolation discipline at the design phase plus Selective Authentication on all inbound trusts. After the fact, every domain whose krbtgt the compromised domain trusted (directly or transitively) becomes part of the rotation surface.

(d) The HSM-bound krbtgt aspiration#

A theoretically clean solution exists in the literature: split the krbtgt key material such that no single party -- including the DC's own KDC service -- could read the full key in cleartext. The construction would be a hardware-security-module-bound krbtgt key (the HSM exposes only sign and verify operations on a key it never releases), or a threshold-cryptography scheme (the key is reconstructed across $n$ DCs, $t$ of which must cooperate per ticket-signing operation). Either construction would close the underlying primitive by making the krbtgt key unreadable in cleartext to anyone with code execution on a DC.

Neither construction is supported by any [MS-KILE] revision through 47.0 dated April 27, 2026 ^[12]. Neither is on any published Microsoft roadmap as of May 2026. The closest analogues that have shipped -- LSAISO/Credential Guard's VBS trustlet for LSASS secrets on workstations and member servers -- explicitly omit the writeable-DC case by design, because a writeable DC must read the krbtgt key to issue tickets.

Even after two-reset and Domain of Thrones, three residuals remain: a window of time, an alternate trust root, and a topology problem. None of them are theoretical -- all three are operational realities documented in 2024-2026 incident-response practice. But they raise a different question: how does the krbtgt key compare to the other secrets in an AD trust-root set?

9. Where KRBTGT Sits in the AD Trust-Root Set#

A correction to a framing that appears in many secondary write-ups: the krbtgt long-term key is one of a small set of "AD trust roots," not the only one. The framing matters because the rotation playbook in Section 7 lists seven secret classes for a reason: each is a candidate trust root that survives compromise of any other.

flowchart TD
K["krbtgt long-term key"] -->|"every TGT in the domain"| ENVA["Domain-wide Kerberos auth"]
C["AD CS root CA private key"] -->|"PKINIT certificates"| ENVA
G["KDS root key"] -->|"gMSA password derivation"| SVC["Service-account auth"]
T["Inter-domain trust keys"] -->|"cross-domain TGT minting"| FOR["Forest-wide auth"]
D["DSRM passwords on writeable DCs"] -->|"local-admin equivalent"| DC["DC-local auth"]
DC --> ENVA
DC --> C
DC --> G
DC --> T
DC --> K

KRBTGT long-term key. Issues TGTs for all principals in the domain. Unique property within the Kerberos trust root: holding it forges TGTs for arbitrary principals, including ones that do not exist in the directory. Rotation: the two-reset, ten-hour-interval procedure on the AD Forest Recovery page ^[5].

AD CS root CA private key. Issues certificates that PKINIT trusts for Kerberos pre-authentication. Compromise yields Kerberos auth as any principal via PKINIT -- a different mechanism with the same end result. Rotation: CA hierarchy rebuild, significantly more expensive than krbtgt rotation. SpecterOps "Certified Pre-Owned" (Schroeder + Christensen, June 2021) is the canonical primary on the ESC-class abuses of this trust root, cross-referenced in Domain of Thrones Part II ^[38][6].

KDS root key. Group Managed Service Account passwords are derived deterministically from a KDS root key plus a per-account msDS-ManagedPasswordId. Compromise of the KDS root key reads every gMSA password in the forest. Different blast radius (service accounts only). Rotation: KDS root key rotation followed by gMSA cycling ^[6].

Per-domain inter-domain trust keys. Bridge Kerberos trust between domains in a forest or across explicit external trusts. Compromise yields cross-domain TGT minting. Rotation: per-trust password rotation, with SID Filtering and Selective Authentication audits as the standard hardening procedure.

DSRM passwords on writeable DCs. Directory Services Restore Mode is a local-admin equivalent at the DC level; compromise yields a local logon to the DC, which then enables many other paths including direct read of the krbtgt key from ntds.dit. Rotation: per-DC DSRM password rotation ^[6].

The precise framing#

Within the Kerberos trust root of a single domain, the krbtgt key occupies a unique position: it is the issuer of every TGT, and forging a TGT requires exactly this key. At the forest-AD-trust-graph level, the krbtgt key is one of a handful of high-cost-to-rotate trust roots, not the only one. The framing matters because it explains why Domain of Thrones Part II lists seven rotation workstreams: each is a candidate path to the same end result (arbitrary identity in the forest) through a different cryptographic mechanism.

Five trust roots, one (krbtgt) with a unique forge-arbitrary-TGTs property, all five surfacing in the rotation list. With the trust-root topology mapped, the article's last technical job is the practical playbook: what does the reader actually do tomorrow morning?

10. Practical Guide: The Rotation and Detection Playbook#

Four lanes. Each lane is a concrete action a reader can execute starting tomorrow morning.

Lane 1: preventive hygiene#

Rotate the krbtgt password twice a year on a calendar schedule, regardless of any specific incident. Use New-KrbtgtKeys.ps1 (or a fork of it) with pre-reset and post-reset replication-health checks ^[37]. Verify Active Directory replication health between the two rotations; if replication is lagging on any DC, the second reset can outpace the first in some replicas and break in-flight tickets.

Move every Tier-0 account into the Protected Users group. Enable Credential Guard on every workstation and member server. Credential Guard does NOT protect the DC itself by design -- DCs must read the krbtgt key unencrypted -- but it kills the worker-station memory-scrape that initially gets an attacker into a position to pivot to the DC.

Audit who can invoke DCSync. The BloodHound query MATCH (u)-[:DCSync]->(d:Domain) returns every principal whose existing AD permissions can extract the krbtgt key without a DC compromise ^[34][4]. Every match should map to a justified administrative role; any unexpected match is a finding.

Lane 2: detection deployment#

Ship the MDI Suspected-Golden-Ticket alert family plus the DCSync alert (External ID 2006) ^[23][24]. Confirm the Suspected-Golden-Ticket alerts (2009, 2013, 2022, 2027, 2032, 2040) are active for every domain controller MDI is deployed against. Configure Microsoft Sentinel content-pack rules covering T1558.001 Golden Ticket and Kerberos-anomaly patterns (not the T1558.003 Kerberoasting rules, which target service-account SPNs and are not a krbtgt detection asset). Configure Splunk T1558.001 detection ^[36] and tune the encryption-type baseline against legacy systems that legitimately negotiate RC4 (or, better, retire those systems).

Ingest BloodHound for posture-graph visibility. Configure regular collections (the default is weekly) so the DCSync edge list stays current as ACLs change. Cross-reference the DCSync edge inventory against the actual administrative role assignments quarterly.

Lane 3: confirmed-compromise response#

When MDI or Sentinel surfaces a confirmed krbtgt compromise -- DCSync extraction observed against a writeable DC, or a Suspected-Golden-Ticket alert with concrete supporting evidence -- the response runs in two parallel tracks. The cryptographic track executes the two-reset rotation: reset the krbtgt password (replicate, verify), wait at least 10 hours, reset again (replicate, verify) ^[5]. The operational track executes the Domain-of-Thrones Part II rotation surface ^[6]:

• AD CS template review covering the ESC1 through ESC8 abuse classes ^[38]; replace or restrict templates with EnrolleeSuppliesSubject, broad Enroll permissions, or weak EKU restrictions.
• SID History audit (Get-ADUser -Filter * -Properties SIDHistory); investigate every account whose SID History contains a Domain Admins or Enterprise Admins SID.
• AdminSDHolder ACL audit; reset Protected Group inherited ACLs and verify the SDProp runs cleanly.
• Machine-account secret rotation, especially for Tier-0 servers.
• KDS root-key rotation followed by gMSA password cycling.
• Trust-key rotation for every inbound and outbound trust.
• DSRM password rotation on every writeable DC.

After both tracks complete, re-baseline detection: the post-incident DC event-log baseline will differ from the pre-incident baseline, and detection thresholds may need re-tuning to suppress the resulting alerts.

Lane 4: what does NOT work#

Preventive hygiene, detection deployment, confirmed-compromise response, and four traps to avoid. The FAQ that follows addresses what remains.

11. FAQ#

One sentence to take away#

Krbtgt rotation invalidates forged TGTs; it does not recover the systemic compromise that produced the forged TGTs in the first place.

That is the precise sentence to keep from ten thousand words. The cryptographic question -- "is the ticket valid?" -- terminates at one key. The operational question -- "is the domain still ours?" -- never does. The 1988 design chose to make ticket validation a property of a single shared secret because that choice made the protocol simple and provably correct. The choice remains correct in 2026. What changed is the meaning of the word compromise: in 1988 the threat model was a passive eavesdropper on a campus LAN; in 2026 the threat model is a remote API call that streams the secret across a DRSGetNCChanges exchange. The key did not move. The attacker's reach did.