BIPI
BIPI

Golden Tickets: Why a Single KRBTGT Rotation Is Not Enough

Cybersecurity

Golden Ticket attacks survive password resets, group membership changes, and account disablement. The only defense is the KRBTGT key itself, and rotating it once is not how the protocol works.

By Arjun Raghavan, Security & Systems Lead, BIPI · December 14, 2024 · 8 min read

#golden-ticket#kerberos#active-directory#ir

A Golden Ticket is a Kerberos TGT forged offline using the krbtgt account's NTLM or AES key. Once an attacker has the krbtgt hash (typically via DCSync), they can issue TGTs for any user, in any group, with any lifetime, that domain controllers will accept as valid. The TGT does not need to be tied to a real account. We have created Golden Tickets for users named SantaClaus that DCs happily honored.

How attackers create them

Mimikatz remains the canonical tool, but Rubeus and impacket's ticketer.py implement the same forgery.

  • Acquire the krbtgt hash via DCSync: lsadump::dcsync /user:krbtgt /domain:corp.local. This gives both the NTLM hash and the AES256 key.
  • Forge with Mimikatz: kerberos::golden /user:Administrator /domain:corp.local /sid:S-1-5-21-... /aes256:key /id:500 /groups:512,520,518,519 /endin:600 /renewmax:10080 /ptt. The /ptt injects the ticket into the current session.
  • ticketer.py -nthash krbtgthash -domain-sid S-1-5-21-... -domain corp.local Administrator produces a .ccache file usable from Linux.
  • Kerberos session: any tool that uses Kerberos (psexec.py -k, secretsdump.py -k, NetExec --use-kcache) authenticates as the forged user.

Forged tickets bypass account lockout, group membership changes, and password resets, because the DC trusts the krbtgt-signed PAC inside the ticket. If the ticket says the user is in Domain Admins, the DC issues service tickets accordingly. The only check that matters is whether the DC can verify the signature, which depends on the krbtgt key being the same as when the ticket was forged.

What defenders see

Golden Tickets are detectable because the forgery is rarely perfect. Defaults in Mimikatz produce specific anomalies.

  • 4769 events for a TGS request where the requesting user does not exist in AD. Forged tickets often use SantaClaus or Administrator-style names that no real account holds.
  • TGT lifetime anomalies: Mimikatz defaults to 10 years for a Golden Ticket. The domain policy maximum is usually 10 hours. A 4624 with a session whose TGT EndTime is 2034 is a screaming signal.
  • 4768 (TGT request) is absent before 4769 (TGS request) in a Golden Ticket session, because the TGT was forged offline and never went through the KDC. Correlation rules looking for TGS without preceding TGT catch this.
  • Ticket encryption type 0x17 (RC4) for accounts that should be AES-only. Older Mimikatz still defaults to RC4 if AES keys are not specified.
  • Microsoft Defender for Identity has Suspected Golden Ticket detections built in. Tune them, do not silence them.

Remediation

Golden Ticket defense is partly preventive (do not let krbtgt be stolen) and partly recovery (assume it has been, rotate correctly).

  1. Rotate krbtgt on a fixed cadence. Microsoft now recommends every 180 days as a baseline. Use the official New-KrbtgtKeys.ps1 script or the AD admin tier-0 toolkit.
  2. Rotate twice during incident response, with replication confirmation between. Set-ADAccountPassword on krbtgt, wait for replication, repeat. Confirm the previous-password slot also holds the new hash.
  3. Reduce the maximum TGT lifetime via GPO: Maximum lifetime for user ticket. The default 10 hours is reasonable; 7 hours is tighter.
  4. Block krbtgt from being used as a logon account by adding it to the Protected Users group is not possible (it is a built-in account). Instead, monitor that no 4624 events ever show krbtgt as the SubjectUserName.
  5. Enforce ticket encryption AES-only at the domain level: Network security: Configure encryption types allowed for Kerberos. This forces forged tickets to also use AES, which raises the bar slightly and produces a cleaner detection baseline.
  6. After confirmed Golden Ticket use, the IR procedure is: rotate krbtgt twice, identify all hosts authenticated by forged tickets via 4624 logs, treat them as compromised, and rebuild tier-0 if the krbtgt was extracted from a domain controller.

The blunt reality: if an attacker reaches krbtgt, the domain is compromised in a way that requires careful, sequenced recovery. The preventive controls are everything in the Pass-the-Hash article (tier model, Credential Guard, Protected Users) plus DCSync detection. The reactive control is correct krbtgt rotation. Both matter.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.