Golden Ticket attacks show the limits of Active Directory trust

At a glance

What this is: This is an analysis of Golden Ticket attacks in Active Directory and how forged Kerberos tickets turn one account compromise into domain-wide impersonation.

Why it matters: It matters because IAM and NHI teams still depend on long-lived trust anchors, and KRBTGT compromise can bypass normal access controls across the domain.

By the numbers:

• 10 hours

👉 Read Semperis's analysis of Golden Ticket attacks and KRBTGT recovery

Context

A Golden Ticket attack is a Kerberos abuse pattern, not just a password problem. Once KRBTGT is compromised, the attacker can mint tickets that appear legitimate to Active Directory and then use them to reach resources across the domain. That is a direct identity and access management failure, because one trusted signing account becomes the root of broad authorization.

For IAM and NHI practitioners, the lesson is that authentication trust can become a persistence mechanism when ticket lifetimes, privileged roles, and recovery procedures are too permissive. The article's examples are typical of the attack class: compromise, ticket forgery, and long-lived access that survives ordinary account cleanup.

Key questions

Q: How should security teams reduce the risk of Golden Ticket attacks in Active Directory?

A: Security teams should reduce KRBTGT exposure, limit privileged account use, and maintain a tested recovery runbook. Tiered administration helps narrow who can reach the signing trust root, while monitoring Kerberos ticket behaviour helps spot forged tickets earlier. The key is to treat the attack as a domain trust compromise, not a single-account incident.

Q: Why are Golden Ticket attacks so difficult to contain once KRBTGT is compromised?

A: Golden Ticket attacks are difficult to contain because the attacker can forge a valid Kerberos ticket after stealing the KRBTGT signing secret. That lets them impersonate users and request downstream service tickets without repeated exploitation. The forged identity can remain useful until the KRBTGT secret is fully replaced and old tickets expire.

Q: What is the difference between a normal Kerberos ticket issue and a Golden Ticket attack?

A: A normal Kerberos ticket is issued by the domain’s Key Distribution Center after legitimate authentication. A Golden Ticket is forged by an attacker who has the KRBTGT hash, allowing the attacker to create tickets with arbitrary identity, group membership, and lifetime. The difference is not just validity, but who controlled the trust decision.

Q: When should organisations reset KRBTGT after suspected compromise?

A: Organisations should reset KRBTGT as soon as compromise is credibly suspected and after they have verified domain controller health and replication readiness. A second reset is needed after the ticket lifetime window so forged tickets expire. Waiting too long extends attacker persistence, while rushing without coordination can disrupt authentication.

Technical breakdown

How KRBTGT compromise enables forged Kerberos tickets

Kerberos relies on the Key Distribution Center to sign Ticket Granting Tickets, and KRBTGT is the account that backs that trust. If an attacker obtains the KRBTGT hash, they can forge a TGT with chosen group membership, ticket lifetime, and user identity. That forged ticket can then request service tickets from the domain as if it were issued legitimately. The security issue is not simple password theft. It is the ability to mint authority inside the directory itself, which makes this a persistence and authorization problem as much as an authentication problem.

Practical implication: Treat KRBTGT as a domain trust anchor and protect it with the same rigor as the most sensitive signing keys.

Why Golden Ticket detection depends on ticket semantics

Golden Ticket activity often shows up through anomalies in Kerberos metadata rather than obvious login failure. Unusually long ticket lifetimes, mismatched SIDs, and service ticket requests from accounts that do not fit their historical behavior are all clues. Event 4769 can also expose irregular service ticket use patterns, especially when high-privilege resources are being accessed by accounts that should not need them. In practice, defenders need to monitor the structure and lifetime of tickets, not just whether a user authenticated successfully.

Practical implication: Add Kerberos anomaly detection to identity monitoring instead of relying only on account-centric alerts.

Why double resetting KRBTGT is the recovery anchor

A single password reset is not enough if forged tickets already exist or if replication timing leaves the old secret usable in parts of the domain. The common recovery pattern is a second reset after the default ticket lifetime has elapsed so cached forged tickets expire and the new secret propagates. Microsoft-style operational guidance often pairs the reset with validation of replication and DC health before and after each change. The mechanism matters because the attacker is anchored to a signing secret, not an individual session.

Practical implication: Build and test a two-step KRBTGT reset runbook before an incident forces you to improvise.

Threat narrative

Attacker objective: The attacker wants durable, domain-wide impersonation that survives initial detection and allows unrestricted access to sensitive systems.

1. Entry begins when the attacker obtains privileged access in Active Directory and reaches the KRBTGT account or its hash.
2. Escalation occurs when the attacker forges a Kerberos TGT with chosen identity and lifetime, then injects it into the session cache.
3. Impact follows when the forged ticket is used to request service tickets and access domain resources as any user, including administrators.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Cisco Active Directory credentials breach — Kraken ransomware group leaked Cisco Active Directory credentials.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Golden Ticket attacks are an identity persistence problem, not a niche Active Directory trick. Once KRBTGT is compromised, the attacker is operating inside the trust fabric that authorises everything else. That means recovery has to be treated as a signing-key event, not a routine account remediation. Practitioners should manage KRBTGT as a domain-level trust root, not just another privileged credential.

Long-lived Kerberos trust creates a hidden identity blast radius. The attacker does not need to keep breaking in after the initial compromise if the forged ticket remains valid. This is the kind of standing trust that zero trust architecture is supposed to reduce, yet many AD environments still allow it to persist operationally. Security teams should assume that any domain-wide signing secret can become a persistence layer.

Golden Ticket detection should focus on ticket behavior, not only on user behaviour. Identity telemetry that watches only logons misses forged authority that appears valid at the protocol layer. Ticket lifetime, SID consistency, and privileged service request patterns are more useful than generic anomaly alerts. Teams that do not monitor Kerberos semantics will continue to detect the aftermath instead of the attack.

KRBTGT recovery requires pre-approved operational choreography. The two-reset pattern works only if replication, downtime tolerance, and validation steps are already mapped. That is a governance issue as much as a technical one, because incident response teams need authority to act fast without guessing at the process. Organisations should rehearse the reset before they need it.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
• From our research: Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• From our research: For the broader NHI lifecycle gap, see Ultimate Guide to NHIs | Key Challenges and Risks.

What this signals

Identity blast radius is the right lens for Golden Ticket defence. If one signing secret can impersonate any principal in the domain, then access reviews alone will not constrain the damage. The programme shift is toward minimising the number of trust anchors that can authorise the whole directory and validating those anchors continuously.

With 97% of NHIs carrying excessive privileges, the broader pattern is clear: over-entitled identities create persistence opportunities long before an attacker forges a ticket. Teams should map privileged directory controls to the same governance models used for other high-value NHI secrets.

Golden Ticket detection should be integrated into identity observability, not left as a domain specialist task. Aligning Kerberos monitoring with NIST Cybersecurity Framework 2.0 improves visibility, response, and recovery coordination when ticket abuse appears.

For practitioners

• Protect KRBTGT as a trust anchor Treat the KRBTGT account as a domain signing root and restrict access, monitoring, and administrative handling to the smallest possible group.
• Implement two-step KRBTGT reset runbooks Document a tested procedure for resetting the KRBTGT password twice, including replication checks, ticket lifetime timing, and rollback criteria.
• Detect Kerberos anomalies in real time Alert on ticket lifetimes beyond normal baselines, mismatched SIDs, unusual service ticket requests, and privileged resource access from unexpected accounts.
• Reduce privileged account concentration Use tiered administration, remove unnecessary Domain Admin exposure, and separate routine administration from high-risk directory control functions.

Key takeaways

• Golden Ticket attacks turn KRBTGT into a domain-wide persistence mechanism, which makes identity governance the primary defence.
• Kerberos ticket lifetime, SID consistency, and privileged service use provide better detection signals than simple login monitoring.
• A tested two-reset KRBTGT recovery process is essential because cleanup without trust-root replacement leaves forged tickets viable.

Key terms

• Golden Ticket Attack: A Golden Ticket attack is a Kerberos forgery technique in which an attacker uses the KRBTGT signing secret to create valid-looking Ticket Granting Tickets. The result is domain-level impersonation that can survive normal account cleanup and enable access to many resources at once.
• KRBTGT: KRBTGT is the Active Directory account that signs Kerberos Ticket Granting Tickets. Because it anchors trust for the domain, compromise of this account lets an attacker mint forged tickets and impersonate identities across the environment.
• Ticket Granting Ticket: A Ticket Granting Ticket is the Kerberos token used to request service tickets after the initial authentication step. In a Golden Ticket attack, the attacker forges this token so the directory accepts an identity and authorisation decision that was never legitimately issued.
• Ticket Lifetime: Ticket lifetime is the period during which a Kerberos ticket remains usable before renewal or expiry. Long or unusual lifetimes can indicate forged tickets, because attackers often extend validity to preserve access and reduce the chance of rapid detection.

Deepen your knowledge

Golden Ticket attack response, KRBTGT recovery, and privileged directory governance are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for Active Directory trust roots, the course gives a practical starting point.

This post draws on content published by Semperis: Active Directory security guidance on Golden Ticket attacks. Read the original.