How to Detect Golden Ticket Attacks in Active Directory
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
The krbtgt account is the cryptographic root of Kerberos trust in Active Directory: every TGT in the domain is signed with its NTLM hash. An attacker who obtains the krbtgt hash (via DCSync, or LSASS dumping directly on a domain controller) can forge TGTs offline that are indistinguishable from legitimate ones to any domain controller.
Golden Tickets are often used for long-term persistence: the attacker uses them weeks or months after initial compromise, after the initial access vector has been closed. The krbtgt hash is also rarely rotated in most organizations, meaning a Golden Ticket signed a year ago may still be valid today.
What Golden Ticket Use Looks Like
Creating a Golden Ticket with Mimikatz:
# On any domain machine: does NOT require domain admin, just the krbtgt hash
mimikatz# kerberos::purge # Clear existing tickets
mimikatz# kerberos::golden \
/domain:corp.local \
/sid:S-1-5-21-1234567890-1234567890-1234567890 \
/krbtgt:9b3e7d8a5c2f4e1b6d0a8c3f7e2b4d9a \
/user:FakeAdminUser \
/groups:512,518,519,520 \
/ticket:golden.kirbi \
/endin:87600 \
/renewmax:87600
# /endin:87600 = 10 years in minutes
mimikatz# kerberos::ptt golden.kirbi # Pass the ticket into memory
# Now any Kerberos-authenticated resource is accessible as FakeAdminUser
dir \\dc01\c$ # Works: domain controller accepted the forged ticket
Key anomalies in a forged ticket:
- User may not exist in AD (or was deleted)
- Ticket lifetime: 87600 minutes (10 years) vs domain default of 10 hours
- Ticket is presented without a corresponding Event ID 4768 (TGT request) on any DC: the ticket was created offline, not issued by a DC
- The
Fromfield in Event 4769 shows the attacker's machine, but no 4768 with a matching logon ID exists on any DC - Domain SID in the ticket matches but the user RID may be unusual (non-existent, special values)
Detection: Event Log Anomalies
Anomaly 1: Service ticket (4769) without TGT request (4768)
Legitimate Kerberos flow: a client requests a TGT (Event 4768 on DC), then uses the TGT to request service tickets (Event 4769). With a Golden Ticket, the TGT exists only in memory: no 4768 was generated. When the attacker uses the Golden Ticket to request a service ticket, only 4769 appears with no corresponding 4768.
// Sentinel KQL: 4769 without preceding 4768 for same account and logon session
let serviceTickets = SecurityEvent
| where EventID == 4769
| where TicketEncryptionType != "0x17" // Filter out Kerberoasting
| project ST_Time = TimeGenerated, ST_Account = TargetUserName,
ST_IP = IpAddress, ST_LogonGuid = trim_end("}",trim_start("{",tostring(LogonGuid))),
ServiceName;
let tgtRequests = SecurityEvent
| where EventID == 4768
| project TGT_Time = TimeGenerated, TGT_Account = TargetUserName,
TGT_IP = IpAddress, TGT_LogonGuid = trim_end("}",trim_start("{",tostring(TicketOptions)));
serviceTickets
| join kind=leftanti tgtRequests on $left.ST_Account == $right.TGT_Account
| where ST_Time > ago(1h) // No TGT for this account in the last hour
| where ST_Account !endswith "$" // Exclude machine accounts
| sort by ST_Time desc
Anomaly 2: Ticket lifetime exceeding domain Kerberos policy
Domain Kerberos policy (Default Domain Policy) sets maximum ticket lifetimes: typically 10 hours for TGTs and 600 minutes for service tickets. Golden Tickets often exceed these:
# Check your domain's Kerberos policy
Get-ADDefaultDomainPasswordPolicy | Select-Object MaxTicketAge, MaxServiceAge, MaxRenewAge
# MaxTicketAge: 10 hours (default)
# MaxServiceAge: 600 minutes (default)
# MaxRenewAge: 7 days (default)
# Microsoft Defender for Identity raises an alert automatically for:
# - TGT lifetime > domain MaxTicketAge
# - TGT presented with account not in AD
# - Renewal requests for tickets older than MaxRenewAge
Anomaly 3: Access using accounts that do not exist
One evasion technique is using a real username but with modified group memberships in the ticket. Another is using a deleted account name. Both generate detectable patterns:
// Detect authentication from accounts not currently in AD
SecurityEvent
| where EventID == 4769
| where TimeGenerated > ago(24h)
| where TargetUserName !endswith "$"
// Cross-reference against HR/AD user list from UEBA or Azure AD export
// Any account in events but not in the current user list is suspicious
| join kind=leftanti (
IdentityInfo | where TimeGenerated > ago(1d)
| summarize by AccountUPN
) on $left.TargetUserName == $right.AccountUPN
| sort by TimeGenerated desc
Microsoft Defender for Identity (MDI): built-in Golden Ticket detection:
If you have MDI deployed, it automatically detects:
- Kerberos Golden Ticket activity
- Overpass-the-Hash
- Skeleton Key malware
- Abnormal resource access based on machine learning
MDI alert name: "Kerberos Golden Ticket activity": triggers when anomalous Kerberos ticket patterns match known attack signatures.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Mitigation: Double-Rotating the krbtgt Password
Any existing Golden Ticket becomes invalid after the krbtgt password is rotated: because the old hash can no longer sign new service ticket requests. However, existing TGTs in memory remain valid until they expire (up to 10 years for attacker-created ones), so the rotation must happen twice with a gap equal to the maximum ticket lifetime to invalidate everything.
Double-rotation procedure:
# Use Microsoft's New-KrbtgtKeys.ps1 script
# Download: https://github.com/microsoft/New-KrbtgtKeys.ps1
# Step 1: Mode 1: simulation (shows what would happen)
.\New-KrbtgtKeys.ps1 -Mode 1
# Step 2: Mode 2: reset on a single DC (for testing)
.\New-KrbtgtKeys.ps1 -Mode 2
# WAIT: the maximum ticket lifetime (default: 10 hours)
# This ensures all legitimate TGTs issued with the first hash expire
# During this window, users may be prompted to re-authenticate
# Step 3: Mode 2 again: second rotation
.\New-KrbtgtKeys.ps1 -Mode 2
# After the second rotation, all Golden Tickets signed with the original hash are invalid
Impact of krbtgt rotation:
- Users with cached Kerberos tickets will be prompted to re-authenticate
- Services using Kerberos authentication may briefly fail until their tickets renew
- Plan the rotation for low-activity windows and communicate to the helpdesk
- Some services (especially those with long ticket lifetimes configured) may need manual restart
Preventing krbtgt compromise:
# Limit who can access domain controllers (primary krbtgt compromise vector)
# Only Domain Admins should log into DCs: enforce via GPO
# Computer Configuration > Windows Settings > Security Settings >
# User Rights Assignment > Allow log on locally: Domain Admins only
# User Rights Assignment > Allow log on through Remote Desktop Services: Domain Admins only
# Monitor krbtgt password last-set date: should be rotated at least annually
(Get-ADUser krbtgt -Properties PasswordLastSet).PasswordLastSet
# If > 365 days: schedule a double-rotation during maintenance
The bottom line
Golden Ticket detection focuses on Kerberos ticket anomalies: Event 4769 service ticket requests without a corresponding 4768 TGT request, ticket lifetimes exceeding domain policy (Mimikatz defaults to 10 years), and authentication using accounts not present in AD. Microsoft Defender for Identity provides built-in Golden Ticket detection. Prevention requires protecting the krbtgt hash by restricting DC access to Domain Admins only; response requires double-rotating krbtgt with a 10-hour gap between rotations to invalidate all existing forged tickets.
Frequently asked questions
How do you detect a Golden Ticket attack?
Monitor for Kerberos anomalies: Event ID 4769 (service ticket request) without a preceding Event 4768 (TGT request) for the same account, Kerberos tickets with lifetimes exceeding your domain's MaxTicketAge policy (default 10 hours), and authentication attempts using accounts that do not exist in Active Directory. Microsoft Defender for Identity automatically detects Golden Ticket patterns using behavioral analysis.
How do you invalidate a Golden Ticket?
Rotate the krbtgt account password twice, with a gap between rotations equal to the maximum Kerberos ticket lifetime (default 10 hours). The first rotation makes the old hash invalid for signing new service tickets; the second rotation expires any TGTs issued with the first rotated hash. Use Microsoft's New-KrbtgtKeys.ps1 script for the procedure. Expect brief user re-authentication prompts and potential service disruptions during the window.
What is the difference between a Golden Ticket and a Silver Ticket attack?
A Golden Ticket forges a Kerberos TGT (Ticket-Granting Ticket) using the krbtgt account hash, granting the ability to request service tickets for any service in the domain. It requires the krbtgt hash (obtained via DCSync or NTDS.dit extraction) and provides domain-wide access. A Silver Ticket forges a service ticket (TGS) for a specific service using that service account's hash — bypassing the domain controller entirely. Silver Tickets are harder to detect because they never touch a domain controller (no TGT issuance logged at Event ID 4768), but they are limited to the specific service whose account hash was used.
How do you detect a Golden Ticket attack in event logs?
Golden Ticket detection is difficult because forged TGTs appear legitimate. Detection signals: Event ID 4769 (service ticket request) with no preceding Event ID 4768 (TGT request) for the same account from the same IP — a Golden Ticket uses a pre-forged TGT so no TGT request is needed; Event ID 4769 with ticket encryption type 0x17 (RC4-HMAC) where modern environments should use AES (0x12); mismatched domain names in Kerberos tickets; and ticket lifetimes exceeding the domain maximum (attackers often set 10-year ticket lifetimes). Microsoft Advanced Threat Analytics (ATA) and Microsoft Defender for Identity have specific detections for Golden Ticket usage patterns.
How do you prevent Golden Ticket attacks?
Golden Ticket prevention requires protecting the krbtgt hash. Measures: deploy Microsoft Defender for Identity (detects DCSync and NTDS.dit extraction attempts in real time); restrict domain controller access so only authorized administrators can reach DCs on the network (tier 0 isolation); audit all accounts with 'Replicating Directory Changes All' permission quarterly (DCSync-capable accounts); enable Defender for Identity protections on all domain controllers; and rotate the krbtgt password proactively once per year (not just after an incident). If DCSync activity is detected in your environment, assume the krbtgt hash is compromised and begin the two-rotation remediation immediately.
How do I verify that a krbtgt double-rotation actually invalidated existing Golden Tickets in my environment?
After completing both krbtgt password rotations separated by at least 10 hours, confirm invalidation by checking three things. First, verify the krbtgt PasswordLastSet attribute was updated twice: run 'Get-ADUser krbtgt -Properties PasswordLastSet, msDS-KeyVersionNumber' -- the msDS-KeyVersionNumber should have incremented twice from its pre-rotation value. Second, monitor for Kerberos errors 0x25 (KRB_AP_ERR_SKEW) and 0x18 (KDC_ERR_PREAUTH_FAILED) in the Security event log on domain controllers; these indicate that cached TGTs signed with the old key are being rejected. Third, if Defender for Identity is deployed, check the Golden Ticket alert status -- any previously active Golden Ticket sessions using the old krbtgt key will fail to renew after expiration and will generate authentication errors. After the second rotation, run 'klist purge' on administrative workstations and verify that re-authentication successfully issues new TGTs signed with the current krbtgt key version. A residual Golden Ticket from before the rotation will fail when it attempts to request a new service ticket because the KDC will not accept a TGT encrypted with a key that is now two versions old.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.