ASD ISM 1847 Double KRBTGT password reset after compromise or six months
What it says
Credentials for the Kerberos Key Distribution Center's service account (KRBTGT) are changed twice, allowing for replication to all Microsoft AD DS domain controllers in-between each change, if the domain has been directly compromised, the domain is suspected of being compromised or they have not been changed in the past six months.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishReset the Active Directory KRBTGT account password twice, waiting for full domain controller replication between resets, after any known or suspected domain compromise and at least every six months.
Every Microsoft Active Directory domain has a hidden service account called KRBTGT. Its password is the master key the Kerberos Key Distribution Centre uses to sign and encrypt the tickets that prove who a user or computer is. If an attacker steals the KRBTGT password hash, they can forge their own tickets (often called "golden tickets") for any account, including domain administrators, and those forged tickets keep working for as long as the KRBTGT password stays the same. This control requires the KRBTGT password to be changed in three situations: when the domain has been directly compromised, when compromise is suspected, and routinely whenever it has not been changed in the past six months. It also requires the change to be done twice, not once. Active Directory keeps the current and previous KRBTGT password, so a single reset still leaves the old key valid for forged tickets. Only a second reset pushes the stolen key out of history. Between the two resets, the new password must replicate to every domain controller in the domain, otherwise domain controllers holding different keys will reject valid tickets and break authentication across the domain. The real-world risk this addresses is persistence. Attackers who reach domain administrator level typically extract the KRBTGT hash so they can return quietly after being "evicted". Without the double reset, an incident response can look complete while the attacker retains a working master key.
Free. Save your status, tasks and notes.
Why it matters
If the KRBTGT password is left unchanged, or is only reset once, an attacker who has taken the KRBTGT hash can keep forging Kerberos tickets for any user, including domain administrators, and regain full control of the domain indefinitely, even after other compromised accounts and hosts have been cleaned up. If the second reset is done before replication completes, domain controllers will disagree on the key and legitimate users and services can lose the ability to authenticate across the domain.
How to implement
Domain administrators run the first KRBTGT password reset in each Active Directory domain using the standard Active Directory tools or Microsoft's KRBTGT reset script, then record the date and time of the reset against that domain.
Before the second reset, the directory services team verifies replication of the new KRBTGT password to every domain controller in the domain (for example by checking replication status and the KRBTGT password-last-set attribute on each domain controller), and does not proceed until all domain controllers report the new value.
Once replication is confirmed, domain administrators run the second KRBTGT password reset for the same domain, verify replication again, and record the completion date as the new baseline for the six-month interval.
The security team writes the double KRBTGT reset into the incident response playbook as a required containment step for any directly compromised domain and for any domain where compromise is suspected, with the second reset only after replication is confirmed.
The directory services team schedules a recurring maintenance window at an interval shorter than six months for every domain, notifies service owners and the service desk beforehand, and confirms user and service authentication works normally after each reset.
Keep it running
Treat the double KRBTGT reset as a standing, scheduled activity with a six-month maximum interval, and as a mandatory step in the incident response playbook for any confirmed or suspected domain compromise. Record the date of the last reset for every domain and set a reminder well before the six-month deadline.
Between the two resets, confirm that the new password has replicated to every writable domain controller in the domain (including those in remote sites and any that are offline or lagging) before running the second reset. Because a reset can invalidate tickets already issued, schedule routine resets in a maintenance window and tell service owners and the service desk in advance. Confirm normal authentication after each reset. Each domain in the forest has its own KRBTGT account, so the process must be repeated per domain.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the record of KRBTGT password resets for each Active Directory domain over the past year.
Look at
Check that each reset event consists of two resets, and that the gap between the most recent completed reset and today does not exceed six months for any domain.
Good evidence
Every domain shows paired resets, with dates, the person who performed them, and no domain going more than six months without a change.
- Check 2 of 5What an auditor asks for
Ask for
Ask to see the KRBTGT account's password-last-set attribute on a sample of domain controllers in each domain.
Look at
Compare the value with the reset records and check it is consistent across domain controllers and within the last six months.
Good evidence
The attribute matches the recorded reset date on every sampled domain controller, showing the change replicated and the six-month limit is being met.
- Check 3 of 5What an auditor asks for
Ask for
Ask for the documented procedure or runbook used for KRBTGT password resets.
Look at
Look for an explicit step requiring the password to be reset twice and a check that replication to all domain controllers has completed before the second reset.
Good evidence
The procedure clearly mandates two resets, describes how replication is verified between them, and names who is responsible.
- Check 4 of 5What an auditor asks for
Ask for
Ask for the incident response playbook for Active Directory or domain compromise.
Look at
Look for the double KRBTGT reset as a required action when the domain is directly compromised or compromise is suspected.
Good evidence
The playbook requires the double reset in both confirmed and suspected compromise cases, and past incident records show it was carried out.
- Check 5 of 5What an auditor asks for
Ask for
Ask for evidence from the most recent reset showing replication was verified before the second change.
Look at
Check replication status output or screenshots taken between the first and second reset, covering every writable domain controller including those in remote sites.
Good evidence
Evidence shows all domain controllers held the new password before the second reset was run, with timestamps that fit the recorded sequence.
Mappings
Closest match in ASD Essential Eight: E8-RA-ML2.5, Long, unique, and managed credentials for admin accounts, which partially overlaps with this control.
ASD Essential Eight: 1 mapping
This control partially overlaps E8-RA-ML2.5.
ISM-1847 requires organisations to change the KRBTGT service account credentials twice (with replication between changes) when compromise is suspected/confirmed or if not changed in the last 12 months. E8-RA-ML2.5 relates by requiring long, unique, unpredictable and managed credentials for service accounts (which includes KRBTGT as a type of service account), improving the strength and management of those credentials. However, E8-RA-ML2.5 does not mandate KRBTGT-specific rotation timing/sequence, while ISM-1847 does not fully cover the broader Essential Eight requirement across all break glass, local admin and service accounts.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.