How should teams recover after a golden ticket with SID history attack?

How a Golden Ticket With SID History Changes Recovery

A golden ticket with sid history is not just a single forged logon artifact, it is a forest-trust problem. Recovery has to assume the attacker may still be able to impersonate privileged access paths across domains until those trust anchors are reset and the effective privilege path is broken everywhere the ticket could be honored.

The practical difference is that SID history can preserve access even when one obvious account path looks closed. That means recovery is about removing acceptance conditions, not just expiring one session or resetting one administrator password.

What Teams Need to Contain Before They Rotate Anything

Containment should focus on the trust path first because the attacker’s value comes from continued ticket acceptance. Isolate forest-root administration from child-domain access, stop any cross-domain administration that could reintroduce forged privilege, and confirm which domains, trusts, and administrative hosts may still validate the forged authorization data.

The containment goal is to prevent the forged ticket from being useful while you rebuild confidence in the directory. If the ticket can still be used to reach a privileged system, recovery work is happening too late and too slowly.

In practice, this often means treating the directory itself as the incident boundary, not just the compromised endpoint or user account. Where the attacker used credential theft, pass-the-ticket style access, or DCSync-like capabilities to obtain persistence, the operational assumption should be that multiple identity paths may be contaminated until proven otherwise.

Why krbtgt Rotation Alone Is Necessary but Not Sufficient

Rotating krbtgt in every affected domain is the core cryptographic reset because it invalidates the ticket-signing material the attacker depended on. But recovery is only complete when you verify that the forged ticket is rejected in every relevant domain and that there is no remaining route through forest-root or cross-domain privilege inheritance.

That verification step matters because a partially rotated environment can leave a gap between “the obvious domain looks clean” and “the forest is actually clean.” Teams should expect to validate more than one domain controller path, more than one administrative tier, and more than one trust relationship before declaring the incident contained.

For deeper operational context on identity attack response, the Identity Threat Detection and Response (ITDR) Guide is useful because it frames golden ticket style compromise as an identity-response problem, not just a malware cleanup problem. If the attack path involved stolen credentials or privileged reuse, NHIMG’s The State of NHI & AI Agent Breach Report 2026 also reinforces how attackers turn durable secrets and privileged access into persistence.

Risk and Threat Considerations

The main risk is false confidence: teams may reset one account, rotate one key, or clean one domain and still leave a ticket-valid trust path alive elsewhere in the forest. Because SID history can preserve inherited privilege, an attacker may retain access even after the most visible indicators have been cleared.

Failure mechanism: The forged ticket remains accepted because the directory still trusts the signing material, the trust relationship, or the privilege path that the attacker used to project authority across domains.

Impact: Privileged access can persist across child and root domains, allowing continued lateral movement, administrative abuse, and incomplete eradication even after local remediation steps appear successful.

Practitioner Guidance

What to verify: Verify that every affected domain has had its ticket-signing material rotated, and test from the perspective of the attacker’s original path, not just from a newly created clean account. If a forged ticket is still accepted anywhere in the forest, recovery is not complete.

Decision rule: If forest-root administration can still reach child-domain privilege paths without a clearly isolated boundary, treat the environment as still exposed and continue containment before moving to cleanup or normal operations.

Practitioner takeaway: The right recovery test is not “did we reset the account,” but “can the forged ticket still buy access anywhere.” Until the answer is no across the forest, the incident remains active from a privilege standpoint.

Related resources from NHI Mgmt Group

• What should teams do after a Golden Ticket attack is discovered?
• How should teams respond when a secret is found in a support ticket?
• How should security teams protect F5 configuration so application delivery can recover quickly after a change error or attack?
• What breaks when teams do not have a trusted environment to recover identity infrastructure into after an attack?