Why Golden Ticket detection matters in Cybersecurity
Golden Ticket detection is a core Cybersecurity task for defenders maintaining Active Directory environments, because a forged Kerberos Ticket Granting Ticket can grant near permanent domain access. Attackers who obtain the krbtgt hash can mint TGTs that appear legitimate, bypassing standard authentication and lateral movement controls.
This guide focuses on practical detection and containment: Windows Event IDs and Sysmon indicators to hunt forged TGTs, SIEM queries for Splunk and Elastic, PowerShell checks to inspect ticket attributes, containment actions including krbtgt rotation and account isolation, and post-incident validation. The guidance is geared to sysadmins, incident responders, and Blue Team engineers who need reproducible steps.
How Golden Tickets work in Active Directory
A Golden Ticket is a forged Kerberos TGT signed with the krbtgt account key, allowing an adversary to impersonate any account for authentication. Because the ticket is cryptographically valid, many services and Domain Controllers will accept it unless additional checks are present.
Typical evidence of a Golden Ticket includes unexpected long-lived tickets, TGTs issued from unusual hosts, ticket encryption mismatches, or mass privileged logons that do not correlate with normal user behavior. Detection requires correlating Kerberos events with endpoint and memory indicators, and adjusting for legitimate administrative automation that may generate similar artifacts.
Windows Event IDs and Sysmon indicators
Start by collecting relevant Windows Security events and Sysmon logs centrally. Key Windows events to monitor include Event ID 4768, which logs TGT requests, Event ID 4769 for service ticket requests, Event ID 4624 for successful logons, and Event ID 4672 for privileged logons. Correlating these events highlights suspicious TGT issuance patterns.
- Event ID 4768: Kerberos authentication ticket requested, contains Ticket Encryption Type and Service Name data.
- Event ID 4769: Service ticket requested, useful to spot unusual SPNs and sname values.
- Event ID 4624 and 4672: Successful and privileged logons, used to map suspicious account use after ticket issuance.
Sysmon can provide supporting evidence, for example logs showing lsass memory dumps, suspicious process creation involving credential tools, or network connections to unusual management hosts. Watch for process creation events that indicate credential harvesting, such as rundll32 loading suspicious DLLs, or PowerShell invoking encoded commands against domain controllers.
SIEM queries for Splunk and Elastic
Use targeted SIEM queries to identify anomalies in Kerberos events. Below are template queries you can adapt to your field mappings and parsing rules. They prioritize extracting ticket encryption type, service name, account, source host, and ticket lifetimes.
Splunk example:
index=wineventlog EventCode=4768
| xmlkv
| stats count by Account_Name, Ticket_Encryption_Type, Workstation_Name
| where Ticket_Encryption_Type="rc4_hmac" OR Account_Name="krbtgt"
Elastic (KQL) example:
event.code: 4768 and (winlog.event_data.ServiceName: "krbtgt" or winlog.event_data.TicketEncryptionType: "rc4_hmac")
| summarize count() by winlog.event_data.TargetUserName, host.name
Adjust queries for your schema, and create alerting on patterns like krbtgt service tickets issued from non-DC hosts, unusually high counts of TGTs for a single account, or rare encryption types compared to baseline. Tune thresholds to reduce false positives from legitimate tools.
Sysmon rules and hunting queries
Create Sysmon rules to capture high-fidelity indicators that often accompany Golden Ticket activity. Important Sysmon detections include process creation events for credential dumping tools, suspicious LSASS access, and abnormal network sessions from admin workstations to domain controllers.
- Monitor ProcessCreate for known offensive tools and suspicious PowerShell commands, including encoded commands.
- Detect Event ID 10 or 11 variants where lsass is accessed or dumped, flagging potential credential theft prior to ticket forging.
Combine Sysmon alerts with Kerberos event anomalies to raise the confidence of an incident. For example, a spike in ProcessCreate entries for mimikatz followed by TGT issuance for many accounts is a high priority alert for investigation.
PowerShell tools to inspect Kerberos tickets
On endpoints, use built-in tools and defender-safe PowerShell scripts to inspect Kerberos tickets. The klist utility lists cached tickets, showing ticket lifetimes and service names. Run klist sessions and klist tgt to inspect locally cached tickets quickly.
klist
klist tgt
For centralized log inspection, use PowerShell to parse Security event logs for Event ID 4768 and extract winlog.event_data fields. Example template, adjust field names for your environment:
Get-WinEvent -FilterHashtable @{LogName='Security';Id=4768;StartTime=(Get-Date).AddDays(-7)}
| ForEach-Object { $xml=[xml]$_.ToXml(); $xml.Event.EventData.Data | Where-Object {$_.Name -eq 'TicketEncryptionType' -or $_.Name -eq 'TargetUserName'} }
These scripts let you bulk-export ticket attributes and look for anomalies such as unexpected encryption types or krbtgt usage from non-DC sources.
Immediate containment steps for suspected compromise
If you confirm or strongly suspect Golden Ticket activity, act quickly to contain the attacker. Priority actions include isolating affected accounts and hosts, blocking remote access for compromised admin accounts, and increasing logging on domain controllers to capture ongoing activity.
- Isolate compromised admin workstations from the network, preserve volatile memory for forensic analysis.
- Disable or lock accounts showing suspicious TGT issuance, including known attacker-controlled service accounts.
- Increase monitoring and collect Security and Sysmon logs from all Domain Controllers and suspected hosts.
Containment should be coordinated with IR and communications teams, since some actions like account disablement or krbtgt resets can impact services. Document each step and maintain chain of custody for any collected evidence.
Remediation: krbtgt rotation and account recovery
Rotating the krbtgt account credentials is the primary remediation step to invalidate forged Golden Tickets. Microsoft recommends performing two krbtgt password resets, separated by a replication interval, to ensure all DCs have the new key material and old keys expire from caches.
Follow documented procedures when rotating krbtgt, test in a lab first, and schedule during a maintenance window where possible. In addition to krbtgt rotation, perform a thorough password reset for all high-privilege accounts, rekey service principals if needed, and rebuild any known-compromised hosts.
Post-incident validation, hardening, and FAQs
After remediation, validate that forged tickets are no longer accepted by testing authentication flows, monitoring for new unusual Kerberos events, and verifying there are no lingering backdoors or scheduled tasks. Re-assess domain trust and service account permissions to reduce blast radius.
Hardening recommendations include enforcing strong Kerberos encryption policies, tightly controlling and auditing privileged accounts, restricting which hosts can request TGTs, enabling long term SIEM detections, and using managed service accounts where possible.
- Q: How long until a Golden Ticket becomes unusable after krbtgt rotation? A: After the first krbtgt reset, old tickets remain valid until the new key replicates and the old key expires, which is why two resets spaced by replication are required.
- Q: Can klist detect forged tickets across the domain? A: klist only shows local cached tickets. Use SIEM and central log analysis to detect forged ticket patterns across many hosts and controllers.
- Q: Should we rebuild domain controllers after a Golden Ticket compromise? A: Rebuilding DCs depends on the scope of compromise. If the krbtgt hash was extracted, krbtgt rotation is required, and rebuilding DCs may be considered for thoroughness.
- Q: Which encryption types are suspicious for detection? A: Look for encryption types that deviate from your domain baseline, for example unexpected RC4 usage in a domain that enforces AES. Use the encryption type as one signal, not the sole indicator.
Conclusion
Detecting and responding to Golden Ticket attacks is complex, requiring coordination between logging, endpoint monitoring, SIEM analysts, and Active Directory administrators. This guide provides practical hunting signals, SIEM query templates, Sysmon rule guidance, PowerShell inspection commands, containment steps, and remediation actions centered on krbtgt rotation and account isolation. The emphasis is on high-confidence detections obtained by correlating Kerberos event anomalies with process and memory indicators, rather than relying on a single log source.
For defenders, the most effective strategy combines prevention, detection, and rapid response: minimize privileged exposure, enable comprehensive logging, tune alerts for Kerberos anomalies, and rehearse krbtgt rotation procedures to reduce downtime during real incidents. Document playbooks, keep forensic evidence intact during containment, and validate remediation with post-incident checks and ongoing monitoring. Regular audits and hardening steps will reduce the likelihood of successful Golden Ticket attacks, and when incidents occur, an informed, methodical response will restore trust in your Active Directory environment more quickly.