If the KRBTGT account is the master key to your domain, a golden ticket is a forged copy of the key. Golden Ticket (T1558.001) is a Credential Access technique that applies to Windows. It is a subtechnique of Steal or Forge Kerberos Tickets.
How attackers use it
MITRE describes adversaries who have the KRBTGT account password hash forging Kerberos ticket-granting tickets, which are called golden tickets. A golden ticket lets an adversary generate authentication material for any account in Active Directory.
With the forged ticket-granting ticket, the adversary then requests service tickets that grant access to specific resources. Golden tickets require interaction with the Key Distribution Center to obtain those service tickets.
The KDC service runs on domain controllers. KRBTGT is the KDC service account, responsible for encrypting and signing all Kerberos tickets. MITRE says the hash may be obtained using OS Credential Dumping and privileged access to a domain controller. So the technique usually comes after an adversary already has deep access, which makes it a persistence and impact multiplier rather than a way in.
How to detect it
MITRE's analytic correlates several anomalies:
- Unusual ticket lifetimes.
- Unexpected encryption types, such as RC4 in a modern domain.
- Malformed fields in logon and logoff events.
- Service ticket requests that have no preceding ticket-granting ticket request.
- Abnormal access patterns associated with elevated privileges across multiple systems.
Because a golden ticket can name any account, detection leans on what is wrong with the ticket rather than who is using it. Build baselines for your domain's normal ticket lifetime and encryption types, and alert on departures.
How to reduce the risk
MITRE lists two mitigations.
- Privileged account management. Limit domain admin account permissions to domain controllers and a small set of servers. Delegate other administrative functions to separate accounts, so a stolen everyday admin credential cannot reach the domain controller.
- Active Directory configuration. To contain a golden ticket that already exists, reset the KRBTGT account password twice. Change it once per domain, force replication, and change it a second time. MITRE also suggests considering regular rotation.
Why the response is different for this technique
Most techniques can be fixed by removing a foothold. A golden ticket cannot, because the forged ticket does not depend on any account or machine still being compromised. It depends on the KRBTGT secret. Cleaning the domain controller does nothing if the adversary kept the hash. The cure is to change the secret, and that is why MITRE's guidance is so specific about the double reset.
It also means timing matters. If you suspect KRBTGT was exposed, the work is: contain the access that allowed the dump, then rotate the secret twice with replication in between, then watch for any ticket activity that predates the rotation.
Test the procedure in a lab or a maintenance window before you need it. The reset affects the whole domain, and a team that has done it once is calmer the second time.
Check your own environment
# Windows: when was the KRBTGT password last set? (needs the Active Directory module)
Get-ADUser krbtgt -Properties PasswordLastSet | Select-Object Name,PasswordLastSet
Then confirm:
- Who can log on interactively to a domain controller? The list should be short.
- Is the domain admin group small, and are those accounts separate from daily-use accounts?
- Do you have a written, rehearsed procedure for the double KRBTGT reset?
Quick check
What does an adversary need before they can forge a golden ticket?
The KRBTGT account password hash. MITRE notes it may be obtained with OS Credential Dumping and privileged access to a domain controller.
