Golden Ticket attacks show the limits of Active Directory trust

At a glance

What this is: This is an explanation of Golden Ticket attacks and how compromise of KRBTGT lets an attacker forge Kerberos tickets for broad Active Directory access.

Why it matters: It matters because Active Directory remains a central identity control plane, and a compromised ticket-signing account can turn one credential abuse into domain-wide impersonation and persistence.

Context

A Golden Ticket attack is a Kerberos abuse pattern, not a general password problem. Once an attacker obtains the KRBTGT account hash, they can forge ticket-granting tickets and present themselves as another identity inside the domain.

For identity teams, the governance issue is trust concentration. Active Directory security models assume the ticket-signing path remains intact and that privileged accounts can be bounded, monitored, and reset in a predictable lifecycle. When KRBTGT is compromised, that assumption breaks and normal review cycles are too slow to matter.

The article is therefore less about a single exploit and more about what happens when a directory-level trust anchor is treated as ordinary access. That is a classic identity governance failure mode with direct implications for PAM, AD hardening, and incident response.

Key questions

Q: What breaks when a KRBTGT account is compromised?

A: Kerberos trust breaks at the domain level because the attacker can forge ticket-granting tickets that downstream services accept as legitimate. That turns one account compromise into impersonation of any user, broad service access, and persistence that can survive ordinary password changes. The key failure is not login theft alone, but the collapse of the directory’s trust anchor.

Q: Why do Golden Ticket attacks create such broad identity risk in Active Directory environments?

A: Golden Ticket attacks are dangerous because they let an attacker forge Kerberos tickets after obtaining the KRBTGT hash. That breaks the trust model of Active Directory and can unlock access to domain resources, devices, and controllers. Once the ticket is injected into a session, the attacker can operate with extended authority until the compromised trust chain is reset and contained.

Q: What are the signs that a Golden Ticket attack is underway?

A: Common warning signs include Kerberos tickets with unusually long lifetimes, unexpected privileges on service tickets, suspicious token manipulation, and evidence of LSASS memory reads. Teams should also watch for sudden privilege escalation, credential dumping behaviour, and unusual access patterns in Active Directory and system logs. These indicators often appear before the attacker fully entrenchs.

Q: What should Active Directory teams do after suspected Golden Ticket activity?

A: They should validate domain controller replication, execute the KRBTGT reset process correctly, and confirm that forged-ticket acceptance has ended before resuming normal operations. Recovery also needs review of privileged access paths and tiering, because the attack exposes trust concentration as well as possible account compromise.

Technical breakdown

How Golden Ticket forging works in Kerberos

A Golden Ticket attack abuses the Kerberos trust model. The KRBTGT account signs ticket-granting tickets in Active Directory, so anyone with its hash can create a forged TGT that Kerberos accepts as valid. The attacker can choose the impersonated username, domain SID, and group membership, then present the ticket to obtain service tickets across the domain. The problem is not just authentication bypass, but the fact that authorization is inherited from a forged identity token that looks legitimate to downstream services.

Practical implication: treat KRBTGT as a domain trust anchor and protect it with the same rigor used for the highest-privilege credentials.

Why KRBTGT compromise creates persistent access

KRBTGT compromise creates persistence because forged tickets remain useful until the signing secret changes. If the attacker caches a TGT before password resets, they can continue requesting service tickets until the old ticket expires or the key material is invalidated. That is why the article emphasizes a double reset and waiting for ticket lifetime to pass. This is a lifecycle problem as much as an authentication problem, because the security outcome depends on when the secret is rotated and whether replication has completed.

Practical implication: verify KRBTGT reset sequencing, replication health, and ticket lifetime assumptions before declaring the environment clean.

What to watch for in forged ticket detection

Detection relies on anomalies that expose the mismatch between a forged ticket and normal directory behaviour. Indicators include unusually long ticket lifetimes, SIDs that do not map to active domain identities, repeated use of tickets issued before a KRBTGT password change, and abnormal access by accounts that should not reach high-privilege resources. Windows Event ID 4769 can help surface suspicious service ticket requests, but the signal is strongest when correlated with account behaviour and directory changes. This is why directory telemetry and privileged account baselines matter together.

Practical implication: correlate Kerberos events with privileged account baselines so forged-ticket activity stands out as an identity anomaly, not just a log event.

Threat narrative

Attacker objective: The attacker aims to impersonate privileged users at will and maintain durable control over the Active Directory domain.

1. Entry begins when an attacker gains access to the KRBTGT account or its hash within Active Directory.
2. Credential abuse follows when the attacker extracts the NTLM hash and forges a Kerberos ticket-granting ticket with chosen identity attributes.
3. Escalation occurs when the forged ticket is injected into a session and used to request service tickets for high-value resources across the domain.
4. Impact is full domain impersonation and persistent access to sensitive systems until the KRBTGT trust anchor is reset.

Breaches seen in the wild

• Cisco Active Directory credentials leak 2025: Kraken leaked Cisco Active Directory hashes, including service and krbtgt accounts; Cisco says they came from its 2022 breach, not a new one.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Golden Ticket attacks are a trust-anchor failure, not just a credential-theft event. The KRBTGT account is the cryptographic root that makes Kerberos tickets trustworthy. Once that root is compromised, the directory can no longer distinguish a legitimate ticket from a forged one, and the usual “authenticate, authorize, log” sequence loses integrity. The practitioner implication is that domain trust anchors need dedicated lifecycle governance, not ordinary privileged account handling.

Privilege concentration in Active Directory creates an identity blast radius that defenders often underestimate. The article shows how one compromised signing account can expand into impersonation of any user and access to any resource. That is a structural governance problem because the blast radius is determined by the directory’s trust model, not by the number of endpoints affected at entry. The implication is that tiering, delegation, and recovery planning must be designed around directory-wide failure modes.

KRBTGT reset is an incident-control mechanism, not a routine hygiene task. The article’s double-reset guidance exists because forged tickets survive ordinary credential-change assumptions until the signing state is fully invalidated. That means recovery is tied to ticket lifetime, replication state, and the ability to prove the old trust anchor is gone. The practitioner implication is that identity incident response must include domain trust-anchor recovery playbooks, not just account lockout procedures.

Active Directory monitoring must look for authorization impossibility, not just authentication success. A forged ticket can authenticate cleanly while still representing a security compromise. That makes anomalous ticket lifetime, SID mismatch, and privileged resource access by unexpected identities the higher-value signals. The implication is that identity threat detection has to move from login events to ticket semantics and access-path validation.

Kerberos trust abuse is a directory governance issue, so it belongs in identity programme design, not only in IR. The article connects Golden Ticket attacks with tiered administration, fewer privileged accounts, and regular auditing. Those are governance controls over who can shape directory trust, not merely technical responses to an alert. The implication is that Active Directory hardening, PAM, and recovery governance need to be treated as one programme.

What this signals

Identity trust anchors need incident-grade governance: Golden Ticket attacks show that directory signing secrets are not ordinary credentials. When KRBTGT is compromised, the security boundary moves from user authentication to domain trust integrity, which means recovery planning has to start before an incident, not after one.

Active Directory programmes that still treat privileged account count as the main risk metric miss the larger issue. The real exposure is the ability to forge identity proof inside the domain, so controls around tiering, reset sequencing, and detection of anomalous ticket behaviour deserve more attention than generic login monitoring.

For practitioners

• Reset KRBTGT with a controlled two-step process Use a validated double-reset procedure for the KRBTGT account, confirm replication across domain controllers, and respect the ticket lifetime window before declaring the environment clean.
• Reduce domain-wide privilege concentration Rework Active Directory administration so the smallest possible set of accounts can influence ticket-signing trust, and separate high-risk administration into distinct tiers.
• Baseline Kerberos ticket behaviour Alert on ticket lifetimes that exceed normal Kerberos expectations, SIDs that do not match active domain identities, and service-ticket requests from accounts that should not reach those resources.
• Audit privileged access paths continuously Review which accounts can access domain controllers, which identities can request service tickets, and whether those pathways still make sense after role or personnel changes.

Key takeaways

• Golden Ticket attacks work because a compromised KRBTGT account lets an attacker forge Kerberos tickets that the domain accepts as valid.
• The article shows persistent access, impersonation of any user, and access to sensitive systems after initial compromise, which is why the attack remains dangerous.
• Defence depends on tight privilege tiering, correct KRBTGT reset handling, and detection of ticket anomalies such as long lifetimes and SID mismatches.

Key terms

• Golden Ticket Attack: A Golden Ticket attack forges a Kerberos ticket after an attacker obtains the KRBTGT hash in Active Directory. It can grant broad, durable access because the forged ticket is treated as trustworthy by the domain, making it a classic high-impact identity compromise.
• 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.
• Kerberos Ticket-Granting Ticket: A Kerberos credential that proves the user has already authenticated and can request service tickets without re-entering credentials. In delegation scenarios, it becomes valuable because a service may store it in memory, making it a target for attackers who compromise the host.
• Privilege tiering: Privilege tiering is an administrative model that separates high-risk identity administration from lower-risk operating duties. In this context, it reduces the number of accounts that can influence domain trust and limits the blast radius if a privileged identity or signing secret is compromised.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.