Golden Ticket Attack: The Keys to Your Kingdom

What Is a Golden Ticket?

A Golden Ticket is a forged Kerberos Ticket Granting Ticket (TGT) that gives an attacker unlimited, persistent access to every resource in an Active Directory domain — without needing any user's password.

The attack abuses the KRBTGT account, whose hash is used to sign every TGT issued in the domain. If an attacker obtains this hash, they can craft valid TGTs for any user, including Domain Admins, with any group memberships and any expiry date they choose.

This makes the Golden Ticket one of the most severe post-exploitation techniques in Active Directory: a single stolen hash translates into indefinite domain-wide control.

How It Works

Kerberos authentication relies on a trusted third party: the Key Distribution Center (KDC), which runs on every Domain Controller.

The normal flow:

1. A user authenticates to the KDC and receives a TGT, signed with the KRBTGT hash.
2. The user presents the TGT to request Service Tickets (TGS) for specific resources.
3. Services validate the TGS and grant access.

The KRBTGT account is the root of trust for every TGT in the domain. No service validates TGTs directly against the KDC at the time of use — they trust the signature. This means a forged TGT, signed with the real KRBTGT hash, is indistinguishable from a legitimate one.

⚠️ Key insight: The KDC is only consulted when issuing a TGT. Once issued, no further verification occurs. A forged ticket bypasses the KDC entirely.

The Attack Chain

Step 1 - Gain Domain Admin (or equivalent)

The attacker needs sufficient privileges to extract the KRBTGT hash. This typically means compromising a Domain Controller or any account with DS-Replication-Get-Changes-All rights (DCSync).

Common escalation paths that lead here: Kerberoasting a privileged service account, abusing ADCS ESC1/ESC8, or exploiting unconstrained delegation.

Step 2 - Extract the KRBTGT Hash via DCSync

The attacker runs a DCSync attack using Mimikatz or Impacket to pull the KRBTGT NTLM hash without touching the DC disk or triggering a logon event:

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

# Impacket (remote, from Linux)
impacket-secretsdump -just-dc-user krbtgt corp.local/admin:[email protected]

The output includes the NTLM hash and the domain SID — both needed to forge the ticket.

Step 3 - Forge the Golden Ticket

With the KRBTGT hash and domain SID, the attacker crafts a TGT for any user they choose:

# Mimikatz — forge and inject directly into the current session
kerberos::golden /user:Administrator /domain:corp.local /sid:S-1-5-21-XXXXXXXXXX /krbtgt:HASH /ptt

Key parameters:

Step 4 - Full Domain Access and Persistence

The forged TGT is accepted by every service in the domain. The attacker can now:

• Access any file share, RDP session, WMI endpoint, or DCOM service
• Create new backdoor accounts and add them to privileged groups
• Push malicious GPOs to all machines
• Persist indefinitely — password resets of any user account have zero effect

⚠️ Critical: A Golden Ticket remains valid until the KRBTGT password is rotated twice. Resetting every other account in the domain changes nothing.

Detection

Golden Tickets are difficult to detect because forged TGTs look like legitimate Kerberos traffic. The KDC is not consulted at ticket use time, so no authentication event fires on the DC when the ticket is presented to a service.

Detection relies on anomaly analysis rather than direct event correlation.

Windows Event IDs

Behavioral Anomalies

• Ticket lifetime over 10 hours - Microsoft's default maximum is 10 hours; forged tickets often have lifetimes of years
• Nonexistent usernames in Kerberos events - Golden Tickets can be forged for accounts that do not exist in AD
• RC4 encryption when your domain enforces AES-only - older tooling defaults to RC4 (0x17)
• TGS request with no prior AS-REQ - a service ticket request on a DC with no corresponding TGT request is a strong indicator
• SID mismatch - the SID embedded in the ticket does not match any real AD account

SIEM Detection Query (Elastic KQL)

event.code: "4769" AND
winlog.event_data.TicketEncryptionType: "0x17" AND
NOT winlog.event_data.ServiceName: ("krbtgt" OR "*$")

event.code: "4768" AND
winlog.event_data.TicketEncryptionType: "0x17" AND
winlog.event_data.PreAuthType: "0"

💡 Tip: Enforce AES-only encryption across your domain. Any RC4 Kerberos traffic then becomes an immediate high-confidence alert.

Remediation

⚠️ Prerequisite: Identify and contain the compromise path before rotating KRBTGT. If the attacker still has DCSync rights, rotating changes nothing.

Immediate Response

Rotate the KRBTGT password twice, with a delay between rotations equal to the maximum Kerberos ticket lifetime (default: 10 hours).

• First rotation invalidates all currently active forged tickets.
• Second rotation removes the previous hash from DC memory, preventing use of tickets forged with the old hash.

Use Microsoft's official script, which handles multi-DC replication checks automatically:

# Download and run New-KrbtgtKeys.ps1
# https://github.com/microsoft/New-KrbtgtKeys.ps1

.\New-KrbtgtKeys.ps1 -Mode ModeSingle
# Wait at least 10 hours (max ticket lifetime)
.\New-KrbtgtKeys.ps1 -Mode ModeSingle

ℹ️ Note: Manual rotation with Set-ADAccountPassword works but skips replication validation. In multi-DC environments, use Microsoft's script to avoid authentication failures during propagation.

Hardening to Prevent Initial Compromise

Verify DCSync Exposure

# Find accounts with DCSync rights (non-DC accounts with replication permissions)
Get-ADObject -Filter * -Properties nTSecurityDescriptor | Where-Object {
    $_.nTSecurityDescriptor.Access | Where-Object {
        $_.ObjectType -eq "1131f6ad-9c07-11d1-f79f-00c04fc2dcd2" -and
        $_.IdentityReference -notmatch "Domain Controllers"
    }
}

How EtcSec Detects This

EtcSec checks for the conditions that make Golden Ticket attacks possible and persistent in your environment.

The GOLDEN_TICKET_RISK detection flags environments where the KRBTGT account password has not been rotated recently — a direct indicator that any previously forged Golden Ticket may still be valid.

Additional related checks include:

• WEAK_KERBEROS_POLICY - Kerberos ticket lifetime and renewal settings that extend the window of exposure for forged tickets
• KERBEROS_RC4_FALLBACK - RC4 encryption still permitted on the domain, which is required to forge tickets with older tooling and makes detection harder
• UNCONSTRAINED_DELEGATION - Accounts with unconstrained delegation that can be used to capture TGTs, a common precursor to Golden Ticket attacks

ℹ️ Note: EtcSec automatically checks for these vulnerabilities during every AD audit. Run a free audit to verify whether your environment is exposed.