What should teams do after a Golden Ticket attack is discovered?

Why Golden Ticket Recovery Has to Start with Containment, Not Cleanup

A golden ticket means an attacker has forged Kerberos tickets with the trust anchored in the domain’s krbtgt secret, so the immediate problem is not just access loss but trust integrity. Teams need to assume the attacker may have used that trust to move laterally, collect additional credentials, or establish persistence before any reset begins. The critical question is how far the compromise reached, because hurried rebuilding can erase evidence and leave the attacker’s foothold intact.

That is why recovery starts with scoped containment and evidence preservation. The attacker’s path, affected systems, and any privileged activity in the ticket lifetime window matter more than cosmetic remediation. If you still have domain controllers, administrative shares, or high-value service accounts operating normally, they may already be part of the blast radius. In practice, many teams discover the full impact only after they have already begun resetting systems, which makes attribution and clean recovery harder.

For context on how compromised non-human identities amplify downstream damage, NHI Mgmt Group’s Ultimate Guide to NHIs — Why NHI Security Matters Now highlights that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.

How Teams Should Sequence Restoration After Detection

The recovery sequence should reflect the way Kerberos trust is actually renewed. First, preserve logs, ticket traces, and domain controller evidence long enough to reconstruct the attacker’s activity window. Then validate which systems, administrators, and authentication paths were touched before changing the krbtgt password. Because the krbtgt secret is replicated across domain controllers, the reset must be done twice, with replication completion verified between changes, so old ticket material cannot remain usable.

Operationally, that means the team should treat the first reset as invalidating one generation of forged tickets and the second reset as closing the remaining trust gap. The exact timing depends on replication health, controller consistency, and whether any disconnected sites could still hold stale state. During this period, privileged accounts, DC access, and other sensitive authentication paths need closer monitoring than normal, because attackers often try to keep using cached access while defenders are still rebuilding trust.

• Confirm the incident scope before restoring services that depend on Kerberos trust.
• Verify domain controller replication before scheduling the second krbtgt reset.
• Prioritise highly privileged and externally reachable systems for inspection.
• Use offline backups and an isolated forest only when the existing forest trust cannot be made reliable quickly.

Kerberos recovery guidance aligns with the broader identity-control discipline described in the NHI Lifecycle Management Guide, because the core issue is controlled revocation and re-issuance of trust. The MITRE ATT&CK Enterprise Matrix is also useful for mapping the likely post-compromise behaviours that should shape your hunt. These controls tend to break down when domain controllers are poorly replicated or when teams reset credentials before they have finished tracing persistence.

When Recovery Needs a Different Path

Stricter recovery often increases downtime and coordination overhead, so teams have to balance rapid restoration against the risk of reintroducing a forged trust chain. If the compromise is limited and the environment is well controlled, a staged krbtgt reset may be sufficient. If the attacker had broad privilege, unknown dwell time, or signs of controller-level tampering, the safer path is often a more disruptive rebuild strategy rather than trusting incremental cleanup.

Current guidance suggests that isolated forests and offline backups become especially important when there is doubt about the integrity of the existing authentication boundary. That is not because every Golden Ticket incident requires a full forest rebuild, but because some environments cannot prove that the attacker’s access has been fully uprooted. The tradeoff is straightforward: the stronger the assurance you need, the more recovery complexity you accept.

For teams that manage identities at scale, the broader lesson is that recovery is not finished when the ticket forgery stops. It is finished when the organisation can show that the trust anchor, replication state, privileged access paths, and backup integrity are all consistent again.

Risk and Threat Considerations

A golden ticket attack is especially dangerous because it turns domain trust into an attacker-controlled persistence mechanism. The main risk is not just unauthorized access, but prolonged impersonation of privileged identities across systems that continue to accept Kerberos tickets as valid.

Failure mechanism: The attacker forges tickets using the krbtgt trust secret, then uses those tickets to impersonate users or admins while defenders are still operating under the assumption that normal authentication controls are intact. If responders reset accounts or rebuild systems before preserving evidence and fully replacing the trust anchor, the attacker can retain access or force defenders to miss the original entry path.

Impact: Privileged movement, data exposure, and trust compromise can persist across the domain, and incomplete remediation can leave the environment vulnerable to repeated re-entry through the same authentication boundary.

Practitioner Guidance

What to prioritise: Establish how long the forged trust may have existed before touching broad remediation. The first decision is whether the incident is a contained credential abuse event or a domain trust compromise that requires preservation, hunt, and staged reset.

What to verify: Confirm domain controller replication health, krbtgt reset completion, and whether any offline or disconnected systems could still accept stale ticket material. If any of those cannot be verified, treat recovery as incomplete.

Decision rule: If you cannot confidently bound attacker dwell time or privileged reach, favour a conservative recovery posture with offline backup validation and isolated trust restoration rather than fast reattachment of business services.

Practitioner takeaway: Golden Ticket recovery is really about re-establishing proof of trust, not just removing access, and teams that rush past that distinction usually recover the environment before they have recovered control.

Related resources from NHI Mgmt Group

• How should teams respond when a secret is found in a support ticket?
• How should security teams detect identity attacks after login when MFA and phishing controls are already in place?
• How should security teams handle support cases and troubleshooting artifacts so session tokens and cookies are not exposed after an account compromise?
• What should organisations do after a suspicious identity provider account activity is discovered?