krbtgt password not rotated
The krbtgt key that signs every Kerberos ticket hasn't changed in months, so a key stolen at any point since still forges tickets.
- Category
- Hygiene
- Severity
- Medium.
- Typical owner
- AD / identity team
- Data needed
- Any collection: the krbtgt account's password age, measured from the collection's time. Change the threshold with
krbtgt_age_days(180 by default).
On this page
In plain language
Every Kerberos ticket in the domain is signed with a key derived from the password of one account, krbtgt. Whoever steals that key can forge a ticket for anyone with any group memberships, a so-called golden ticket, without touching a domain controller again.
The only cure is changing the krbtgt password, twice, because domain controllers accept the current and the previous key. Rotating it regularly (Microsoft publishes a script that does it safely) limits how long a stolen key keeps working, and it is a standard step after any suspected compromise.
What Pathwarden flags
The krbtgt account's password has not been changed within the configured period (180 days by default). The key derived from this password signs and encrypts every Kerberos ticket-granting ticket (TGT) in the domain.
How attackers use it
Anyone who has ever obtained the krbtgt hash, for example through DCSync, a stolen DC backup or a past breach, can forge TGTs for any user with any group membership. These are "golden tickets" (Steal or Forge Kerberos Tickets: Golden Ticket, MITRE ATT&CK T1558.001). The forged tickets keep working until the krbtgt password has been changed twice, because domain controllers accept both the current and the previous key. Regular rotation limits how long a stolen key stays useful.
Find it with Pathwarden
Data needed: Any collection: the krbtgt account's password age, measured from the collection's time. Change the threshold with krbtgt_age_days (180 by default).
In the web UI or the HTML report, open the Findings tab and expand PW-014: each finding shows who can use it (its exposure), the attack path drawn out, the affected objects, and the fix. The remediation path tells you whether a single plan step closes it. On the command line:
# every finding of this rule, with its path and fix
pathwarden findings -i .\collect --rule PW-014
# the step-by-step guide on this page, offline
pathwarden guide PW-014
# after the fix: collect again, then check it is gone
pathwarden retest -i .\collect-after --rule PW-014Exit codes make retest easy to script: 0 Fixed, 1 Still open, 3 Can't tell. See findings lifecycle and retest.
Before you change anything
- Make sure Active Directory replication is healthy:
repadmin /replsummaryshould show no failures. A rotation that does not reach every DC causes Kerberos failures. - Read-only DCs have their own krbtgt_XXXXX accounts. Microsoft's script can handle those too.
- Rotate twice, with a wait between the rotations. The first change invalidates nothing on its own (the old key is still accepted as the previous key). The second change invalidates every ticket signed with the original key. Rotating twice in quick succession can break existing sessions and services before their tickets renew.
- Schedule the work in a change window and tell the service desk. Users may need to log off and on.
How to fix it
Option A: Microsoft's New-KrbtgtKeys.ps1 (recommended)
- Download
New-KrbtgtKeys.ps1from Microsoft's official GitHub repository (see References). - Run it on a domain-joined admin computer as a Domain Admin. Start with the simulation / read-only test modes it offers to check that all DCs are reachable and replicating.
- Run the reset mode for the domain's krbtgt account (first rotation).
- Wait at least the maximum user ticket lifetime (10 hours by default, see Default Domain Policy > Kerberos Policy) and until replication of the change to every DC is confirmed. Many organizations wait 24 hours.
- Run the reset mode a second time (second rotation).
- Repeat the double rotation at least every 180 days. After a suspected compromise, do it immediately.
Option B: Manual reset
In Active Directory Users and Computers, enable View > Advanced Features, right-click krbtgt in the Users container > Reset Password and enter any value. Windows replaces it with a random password. Repeat after the wait described above. The script is preferred because it verifies replication.
PowerShell
Import-Module ActiveDirectory
# Check the current password age
Get-ADUser -Identity krbtgt -Properties PasswordLastSet | Select-Object Name, PasswordLastSet
# Confirm replication health before and between rotations
repadmin /replsummary
# Run Microsoft's script and follow its menu: simulation first, then reset.
# Run it twice in total, waiting >= max ticket lifetime (default 10h) and for full
# replication between the two resets.
.\New-KrbtgtKeys.ps1Verify the fix
Get-ADUser krbtgt -Properties PasswordLastSet shows a recent date, and `repadmin /showobjmeta
<DC> "CN=krbtgt,CN=Users,DC=<domain>,DC=<tld>"` shows the same unicodePwd version on every DC.
Collect again (or use Retest on the finding) and confirm the finding ID is gone.
Roll back
A krbtgt rotation cannot be undone. If clients report Kerberos errors after the first rotation,
wait for replication to finish and have affected users log off and on (or run klist purge).
Do not perform the second rotation until the first has fully replicated.