Golden ticket detection: the forged TGT that never touches the krbtgt password

A golden ticket is a Kerberos ticket-granting ticket forged with the key of the krbtgt account. Because the ticket is signed with a key the domain considers authoritative, the domain controller accepts it and issues service tickets in response. The account is invented, the password never expires, and no authentication event against a real credential occurs.

Why the forgery is durable

The krbtgt account holds the key that signs ticket-granting tickets, and every domain controller uses the same key. An attacker who obtains the password hash can mint a ticket for any identity, any group membership and any lifetime, and the domain controller has no way to distinguish the forged ticket from a legitimate one.
Remediation is the hard part. Changing the krbtgt password once leaves the previous key valid for ticket validation, because tickets issued before the change must continue to work. Rotating twice, with an interval longer than the maximum ticket lifetime, is what removes the old key from service. That is a scheduled maintenance activity with a specific interval, not an incident action.

Signals that survive

Detection has to come from properties of the ticket rather than from a failed logon. Four are worth instrumenting.
The first is ticket lifetime. A forged ticket can name a lifetime of years, and the domain policy for normal users is measured in hours. A logon whose ticket validity exceeds the configured maximum is anomalous by definition.
The second is the encryption type of the ticket-granting ticket. Weak RC4 tickets where the domain has moved to AES describe a forgery that used an old key or failed to negotiate the current suite.
The third is the group list. A ticket for an ordinary account that carries domain administrator membership, or a group that the account does not hold in the directory, is not producible by legitimate issuance.
The fourth is the absence of a matching ticket request. A service ticket issued without a preceding ticket-granting request on the same domain controller is the observable gap between a forged ticket's presentation and its supposed origin.

Defensive implications

• Enable logging for Kerberos service ticket operations and for account logon events, and forward them to a collector the domain controller cannot modify.
• Alert on ticket lifetimes above policy, on ticket-granting tickets encrypted with weak ciphers, and on privilege group memberships that do not match the directory.
• Protect the krbtgt account as a tier-zero credential: restrict who can read its secrets, and treat any backup that contains the domain database as equivalent to the account.
• Schedule krbtgt rotation twice with an interval beyond the maximum ticket lifetime, and record the dates so that the rotation is auditable.
• Review domain replication rights, because access to the directory database yields the same key material without touching the account directly.
• Keep the tier model honest: a workstation administrator who can log on to a domain controller has an effective path to the key. The last item explains most incidents of this class. The forgery is the final step, and the earlier step is a privilege path that was never closed.

References

• Microsoft: Kerberos authentication overview, retrieved 2026-10-08
• Microsoft: Windows security auditing, retrieved 2026-10-08
• MITRE ATT&CK: Steal or Forge Kerberos Tickets, retrieved 2026-10-08
• CISA Known Exploited Vulnerabilities catalog, retrieved 2026-10-08