Analyzing Kerberos Golden Ticket Persistence in Active Directory

In the hierarchy of Active Directory (AD) compromises, few scenarios are as devastating as the creation of a "Golden Ticket." While an initial breach might grant an attacker administrative access to a single server or a specific domain, a Golden Ticket represents a fundamental breakdown of the Kerberos trust model. It is not merely an escalation of privilege; it is a persistent, forged identity that allows an attacker to impersonate any user, with any group membership, for an indefinite period.

For security practitioners, understanding the mechanics of this attack is critical for developing robust detection and remediation strategies. This post dives into the technical architecture of the Kerberos protocol, the mechanics of the forgery, and the operational complexities of recovery.

The Mechanics of Kerberos Trust

To understand the Golden Ticket, one must first understand the role of the Key Distribution Center (KDC). In an Active Directory environment, the KDC (running on the Domain Controller) is the arbiter of identity. The KDC relies on a specific service account, the `krbtgt` account, to maintain the integrity of the Kerberos realm.

The Kerberos authentication flow typically follows this pattern:

1. AS-REQ/AS-REP: The user requests an Authentication Service (AS) reply. The KDC verifies the user's credentials and issues a Ticket Granting Ticket (TGT).
2. TGT Encryption: Crucially, the TGT is encrypted using the NTLM hash (or AES key) of the `krbtgt` account.
3. TGS-REQ/TGS-REP: When the user needs to access a specific service (e.g., SMB or LDAP), they present the TGT to the Ticket Granting Service (TGS). The KDC decrypts the TGT using its `krbtgt` key, validates the contents, and issues a Service Ticket (ST).

The security of the entire domain rests on the secrecy of the `krptgt` key. If an attacker possesses this key, they possess the ability to encrypt their own TGTs. Because the KDC trusts any TGT that can be successfully decrypted with the `krbtgt` key, the attacker can forge a TGT containing a manipulated Privilege Attribute Certificate (PAC).

The Anatomy of a Golden Ticket Attack

A Golden Ticket attack is rarely the first step in a breach. It is the culmination of a successful lateral movement and privilege escalation campaign, typically involving a DCSync attack.

Phase 1: Credential Extraction

The attacker must first gain high-level privileges (usually Domain Admin) to perform a DCSync. Using tools like Mimikatz, the attacker impersonates a Domain Controller and requests replication of the `krbtgt` hash from the actual DC. This does not require executing code on the DC itself, making it incredibly stealthy.

Phase *b*: Forgery

Once the `krbtgt` hash is obtained, the attacker can use a tool to craft a TGT offline. The forged TGT includes:

• User Identity: Can be any valid or even non-existent username.
• Group Memberships: The attacker manually inserts the SIDs (Security Identifiers) for highly privileged groups, such as `Domain Admins` (RID 512) or `Enterprise Admins` (RID 519).
• Lifetime: While standard TGTs have a set expiration (e.g., 10 hours), a forged TGT can be set to remain valid for years.

Phase 3: Injection and Persistence

The forged TGT is "passed-the-ticket" into the attacker's current session. To the KDC, this ticket is indistinguishable from a legitimate one because the cryptographic signature-created using the compromised `KRBTGT` key-is valid.

Detection Strategies: Finding the Invisible

Detecting a Golden Ticket is notoriously difficult because the authentication itself is cryptographically "correct." Detection must therefore focus on anomalies in the Kerberos protocol usage and the precursors to the attack.

1. Monitoring for DCSync Activity

Since the `krbtgt` hash must be stolen, monitoring for Directory Service Replication primitives is the most effective proactive measure.

• Event ID 4662: Look for operations involving the `DS-Replication-Get-Changes` and `DS-Replication-Get-Changes-All` extended rights, especially when the source is not a known, authorized Domain Controller.

2. TGT Lifetime Anomalies

Standard Kerberos configurations enforce strict expiration windows. A TGT with an unusually long lifetime (e.g., a 10-year expiration) is a massive red flag.

• Analysis: Inspect Kerberos TGS requests for discrepancies between the `starttime` and `endtime` fields in the Kerberos ticket structure.

3. PAC Validation Failures

While a Golden Ticket bypasses many checks, inconsistencies in the PAC (such as a mismatch between the user's actual group membership in AD and the membership claimed in the TGT) can occasionally trigger alerts in advanced security monitoring tools.

The Remediation Nightmare: The "Double Reset"

The only way to invalidate a Golden Ticket is to change the password of the `krbtgt` account. However, this is not a simple single-step operation.

The Complexity of the `krbtgt` Password History

Active Directory maintains a history of the previous `krbtgt` password. This is a feature designed to prevent authentication breakage during replication; it allows DCs that haven't yet received the new password to still decrypt tickets encrypted with the old one.

If you reset the `krbtgt` password only once:

1. The new password becomes the "current" key.
2. The previous (compromised) password remains in the history.
3. The Golden Ticket remains valid.

The Operational Implementation

Conclusion

As shown across "The Mechanics of Kerberos Trust", "The Anatomy of a Golden Ticket Attack", "Detection Strategies: Finding the Invisible", a secure implementation for analyzing kerberos golden ticket persistence in active directory depends on execution discipline as much as design.

The practical hardening path is to enforce strict token/claim validation and replay resistance, deterministic identity policy evaluation with deny-by-default semantics, and certificate lifecycle governance with strict chain/revocation checks. This combination reduces both exploitability and attacker dwell time by forcing failures across multiple independent control layers.

Operational confidence should be measured, not assumed: track false-allow rate and time-to-revoke privileged access and time from suspicious execution chain to host containment, then use those results to tune preventive policy, detection fidelity, and response runbooks on a fixed review cadence.