When should organisations reset KRBTGT after suspected compromise?

Why KRBTGT resets are a timing decision, not just a cleanup task

KRBTGT is the Kerberos account that signs ticket-granting tickets in Active Directory, so resetting it is the control that invalidates forged Kerberos tickets after a suspected domain compromise. The right timing balances two risks: leaving the key in place gives an attacker a longer window to persist, but resetting before replication is healthy can break authentication across the domain.

In practice, the reset is triggered by credible suspicion of compromise, not by absolute proof that every attacker path is known. That is because the objective is to remove trust in tickets that may already be forged or replayable, while keeping domain services stable enough to absorb the change.

For a deeper walkthrough of the reset sequence, replication checks and edge cases such as recovery of a domain controller or RODC, see krbtgt account.

How to time the first reset and the follow-up reset

The first reset should happen as soon as compromise is credibly suspected and the domain controller estate has been checked for health and replication readiness. That is the point at which you want to stop trusting any ticket material that may have been exposed, while still avoiding a reset into a broken replication topology.

The second reset matters because one change does not fully clear out every forged ticket already in circulation. You need to wait for the ticket lifetime window to pass so old tickets age out, then perform the follow-up reset to invalidate any remaining forged material that was minted before the first change.

If your incident involves a broader Active Directory compromise, the right sequencing is often easier to execute from a full recovery playbook that includes trust resets, rebuild decisions and clean-up of related persistence paths. A practical reference point is the Active Directory Domain Compromise Response Playbook.

What can go wrong if you reset too early or wait too long?

The main failure mode is choosing between attacker dwell time and service disruption. If you delay too long, forged tickets can keep working and the attacker may continue moving laterally or maintaining privileged access. If you reset before domain controllers are healthy and replication is aligned, you can create inconsistent authentication behaviour, including logon failures and hard-to-diagnose ticket issues.

That is why KRBTGT reset is best treated as a coordinated domain recovery action rather than a simple password change. The decision should be tied to replication status, domain controller stability, and whether any dependent systems still need a controlled remediation window before trust is revoked.

For incident scoping and coordinated eviction logic that helps decide when to contain, when to observe and when to move to eviction, the Incident Scoping and Containment Strategy Guide is useful.

Risk and Threat Considerations

The security risk is not limited to password exposure. A compromised KRBTGT key can enable long-lived forged tickets, which means the attacker may retain access even after obvious account resets or password changes elsewhere in the environment. The reset window is therefore a containment decision as much as a remediation step.

Failure mechanism: Old or forged Kerberos tickets remain valid until the relevant lifetime window expires, and a rushed or uncoordinated reset can destabilise authentication if replication is incomplete.

Impact: Delayed reset extends persistence and lateral movement opportunity, while an unsafe reset can interrupt legitimate logons, service access and recovery operations across the domain.

Practitioner Guidance

What to verify: Confirm domain controller health, replication convergence, and whether the environment can tolerate a coordinated first reset before you touch KRBTGT. If replication is already inconsistent, stabilise that first, because a failed reset sequence can create a wider recovery problem than the original compromise.

Decision rule: If compromise is credible, prioritise the first reset quickly, then plan the second reset only after the forged-ticket lifetime window has elapsed and the environment has remained stable. Do not let uncertainty about every attacker action become a reason to defer the control.

Practitioner takeaway: The right KRBTGT reset is a timed containment step, not a reactive password change, and the quality of your replication readiness check determines whether it removes attacker persistence or creates avoidable outage.

Related resources from NHI Mgmt Group

• What should teams do in the first 24 to 72 hours after suspected package compromise?
• How do identity logs help after a suspected compromise?
• What breaks when mass password reset is handled manually during a suspected compromise?
• Should organisations prioritise token revocation or password resets after suspected compromise?