Detect Golden Ticket Attacks — Forged Kerberos TGT & krbtgt Hash Abuse

MITRE ATT&CK

Security Relevance

The krbtgt account is the cryptographic root of Kerberos authentication in Active Directory. Its hash is used to sign every TGT issued in the domain — possession of it means an attacker can forge credentials for any user indefinitely. Golden Tickets are the endgame of a domain compromise: they survive password resets of target accounts, Active Directory cleanups that miss the krbtgt reset, and even domain controller reboots. Detecting and responding to a Golden Ticket requires both invalidating the forged tickets (double krbtgt reset) and identifying how the krbtgt hash was obtained in the first place — typically via DCSync or NTDS.dit dumping.

Indicators of Malicious Use

• ⚑Event ID 4769 with Ticket Encryption Type 0x17 (RC4-HMAC) when your domain enforces AES256 — Mimikatz defaults to RC4 when forging Golden Tickets
• ⚑Event ID 4769 where Account Name does not match any existing AD account — Golden Tickets can specify arbitrary usernames
• ⚑Event ID 4769 with Ticket Options 0x40810000 or unusual flag combinations not seen in legitimate traffic
• ⚑Event ID 4624 Type 3 logon followed immediately by 4672 (special privileges) with no preceding 4768 (TGT request) on the DC
• ⚑Service ticket requests (4769) for high-value targets (cifs, host, ldap on DCs) from accounts with no prior authentication history
• ⚑Rubeus or Mimikatz kerberos::golden command signatures in Event ID 4104 (PowerShell script block) or 4688 (process creation)

Example Log Entry

Event ID: 4769 — Kerberos Service Ticket Request
Account Name:        DomainAdminFake          ← account does not exist in AD
Account Domain:      CORP.LOCAL
Service Name:        cifs/DC01.corp.local
Service ID:          S-1-5-21-...
Ticket Options:      0x40810000
Ticket Encryption:   0x17 (RC4-HMAC)         ← AES256 expected; RC4 = forged ticket
Client Address:      ::ffff:10.10.5.22
Failure Code:        0x0 (success)

Note: No Event ID 4768 (TGT request) preceded this on the DC —
the TGT was forged locally, not issued by the KDC.

Investigation Steps

1. 1.Identify the account name in Event ID 4769 — search Active Directory to confirm whether it exists. A non-existent account is definitive evidence of a forged ticket.
2. 2.Check the Ticket Encryption Type: 0x17 (RC4-HMAC) is suspicious if your domain has enforced AES256 via 'Network security: Configure encryption types allowed for Kerberos' Group Policy.
3. 3.Look for Event ID 4768 on the domain controller within the preceding minutes for the same account. A Golden Ticket bypasses TGT issuance — absence of 4768 is a strong signal.
4. 4.Examine Event ID 4624 and 4672 for the session — check Client Address. If it originates from a workstation, pivot to that host's security log and process creation events (4688) for credential dumping indicators.
5. 5.Search for the krbtgt compromise vector: check Event ID 4662 (DCSync replication) and Event ID 4663 (NTDS.dit or LSASS access) in the 48 hours before the ticket was observed.
6. 6.Determine ticket lifetime: Golden Tickets can be issued with arbitrarily long validity (check the ticket's EndTime if available in your SIEM). Legitimate tickets default to 10 hours.
7. 7.Scope the breach: identify all systems where the forged account authenticated (Event ID 4624/4634 with the same Account Name) — every system it touched may be laterally compromised.
8. 8.Initiate response: reset the krbtgt password TWICE with a minimum 10-hour gap between resets. The first reset invalidates new tickets; the second reset invalidates sessions using the previous key. All active Kerberos sessions will be disrupted.

Common False Positives

• ◎RC4 encryption (0x17) alone is not proof of a Golden Ticket — older systems, printers, and some services still negotiate RC4 for compatibility. The combination of RC4 + non-existent account + no preceding 4768 is the definitive pattern.
• ◎Some security testing tools (adversarial simulation, red team engagements) generate Golden Tickets during authorized assessments — coordinate with your security team before escalating.
• ◎Misconfigured service accounts with unusual names may trigger account-existence checks — cross-reference with HR/IT systems, not just AD, before concluding the account is fictitious.
• ◎Is a Golden Ticket the only way to get persistent domain access? No — Silver Tickets, DCSync with ongoing access, and skeleton key backdoors are alternatives. Golden Ticket is the most common endgame because it requires only the krbtgt hash.

Remediation

• ✓Reset the krbtgt password TWICE — use Microsoft's krbtgt Key Reset Script (ADFSHelp GitHub). First reset invalidates future tickets; second reset (10+ hours later) invalidates all tickets signed with the previous key.
• ✓Identify and remediate the krbtgt compromise vector before resetting — if DCSync or NTDS.dit access was used, the attacker retains the ability to re-forge tickets until AD access is fully removed.
• ✓Enable AES256 Kerberos encryption and disable RC4 in Group Policy ('Network security: Configure encryption types allowed for Kerberos') — Mimikatz defaults to RC4 for Golden Tickets, making RC4 detection a reliable signal.
• ✓Deploy Microsoft Defender for Identity — it detects Golden Ticket usage via behavioral analysis of replication traffic and ticket anomalies that event logs alone cannot catch.
• ✓Add privileged accounts (Domain Admins, krbtgt) to the Protected Users security group — members cannot use RC4 and have reduced Kerberos ticket lifetimes.
• ✓Audit and minimize who can perform DCSync (DS-Replication-Get-Changes-All) — only DCs and authorized sync accounts (Azure AD Connect) should have this right.

Related Event IDs

Related Detection Guides

Frequently Asked Questions

How do I know if a Golden Ticket is active in my environment?

Look for Event ID 4769 with RC4 encryption (0x17) where AES256 is expected, especially for privileged accounts. Check whether the Account Name exists in Active Directory — Golden Tickets can specify any name, including non-existent ones. Also look for privileged sessions (Event ID 4672) with no corresponding TGT request (4768) on the DC. Defender for Identity provides the most reliable detection via behavioral analysis of Kerberos traffic.

Why must the krbtgt password be reset twice?

Active Directory maintains two versions of the krbtgt password — the current and the previous. Kerberos accepts tickets signed with either key during the transition window. Resetting once invalidates tickets signed with the old key but leaves the previous-previous key in play. The second reset (after a 10-hour interval to allow legitimate ticket expiry) eliminates the second key, ensuring all Golden Tickets are invalidated. Resetting only once is insufficient.

Can a Golden Ticket survive a domain controller reboot?

Yes. Golden Tickets are stored in the attacker's memory (or a .kirbi file on disk), not in Active Directory. A DC reboot does not invalidate them. Only resetting the krbtgt password (twice) invalidates existing Golden Tickets, because the forgery relies on the krbtgt NTLM hash which is stored in AD — not in DC memory.

What is the difference between a Golden Ticket and a Pass-the-Ticket attack?

Pass-the-Ticket (PtT) reuses a legitimately-issued Kerberos ticket stolen from another user's session — typically via Mimikatz kerberos::list /export. It works only until the ticket expires (10 hours by default). A Golden Ticket is entirely forged using the krbtgt hash and can be created for any account with any lifetime. PtT requires stealing an existing ticket; Golden Ticket requires the krbtgt hash but then grants unlimited persistence.