Detect golden ticket attacks by monitoring for unusually long ticket lifetimes, service tickets issued by unexpected domain controllers, and users accessing resources without prior authentication events. Focus on Kerberos protocol anomalies and cross-reference ticket issuance with known service accounts.
The Nature of the Forgery
A golden ticket is a forged Kerberos Ticket Granting Ticket (TGT). Kerberos is the standard network authentication protocol used in Windows environments. Normally, a user presents credentials to a domain controller, which issues a TGT. This TGT allows the user to request service tickets for specific resources without re-entering passwords.
A golden ticket bypasses this initial step. An attacker with the KRBTGT account hash can create a TGT that the domain controller accepts as valid. Because the ticket is cryptographically valid, the domain controller does not log a failed login. It logs a successful authentication. This makes the attack invisible to tools that only look for brute-force patterns or locked accounts.
You must shift your detection strategy from looking for failed attempts to looking for impossible behaviors. The ticket works, but the context of its use is often wrong.
Anomalies in Ticket Duration
The most common indicator of a golden ticket is its lifetime. Default Kerberos policies set a maximum lifetime for TGTs, often twenty-four hours. Attackers frequently set this value to the maximum allowed, such as ten years, to ensure persistence.
Monitor your Kerberos logs for tickets with unusually long durations. A standard user ticket rarely lasts more than a day. If you see a ticket with a lifetime of months or years, it is likely forged. This anomaly is visible in the ticket’s start time and end time fields.
You can configure your detection rules to flag any TGT with a duration exceeding the organizational standard. This is a high-fidelity signal because legitimate systems rarely deviate from default maximums.
| Signal | Where to look | What it may mean |
|---|---|---|
| Unusually long TGT lifetime | Kerberos event logs (Event ID 4768) | Forged ticket with extended persistence |
| Ticket issued by non-PDC | Kerberos logs on all domain controllers | Attacker using a compromised DC or offline forgery |
| Access to sensitive resources | File server or AD audit logs | Lateral movement using stolen privileges |
| User login outside business hours | Authentication logs across the domain | Automated tooling or stealthy reconnaissance |
The Source of Issuance
In a healthy environment, the Primary Domain Controller (PDC) emulator usually issues TGTs. While other domain controllers can issue tickets, the PDC is the most common source for initial authentication.
A golden ticket can be issued by any domain controller that holds the KRBTGT hash, or it can be forged offline and presented to any controller. If you see a TGT issued by a domain controller that does not typically handle authentication for that user, it is suspicious.
Cross-reference the issuing domain controller with your infrastructure map. If a backup controller or a newly joined controller issues a TGT for a high-privilege account, investigate immediately. This discrepancy often reveals the location of the compromised credential store.
Behavioral Indicators in Access Logs
Even if the authentication looks valid, the behavior of the account may not. Golden tickets are often used by attackers who have recently gained access. They may not know the normal usage patterns of the compromised account.
Look for access to resources that the account has never touched before. A service account that usually only accesses a specific database server suddenly accessing file shares in a different department is a red flag. This lateral movement is a key stage in the cyber kill chain, where attackers expand their reach.
Also watch for access during unusual hours. If an account typically logs in between 9 AM and 5 PM, and suddenly authenticates at 3 AM, it warrants review. Combine this with the ticket duration and issuance source for a stronger signal.
Identifying Compromised Service Accounts
Attackers often target service accounts because they have high privileges and low visibility. These accounts may not log in frequently, making their baseline activity hard to define. A sudden login from a dormant service account is a strong indicator of compromise.
Review the password last change date for privileged accounts. If the KRBTGT password was changed recently, any golden tickets created before that change are now invalid. Attackers may reset the password to invalidate existing tickets, but this action itself is a forensic artifact.
Monitor for rapid password changes on the KRBTGT account. This is a defensive measure, but it can also indicate an attacker trying to cover their tracks. Ensure your incident triage process includes checking for these password resets.
See also: What Is Cyber Espionage: How State Actors Steal Data · Cyber Kill Chain vs MITRE ATT&CK: The Structural Difference
Blind Spots in Detection
Many organizations rely solely on antivirus and endpoint detection. These tools often miss golden tickets because the ticket is a network-level credential, not a file or process on the endpoint. The malicious activity happens in the authentication protocol, not on the hard drive.
Another blind spot is the assumption that all domain controllers are equally trusted. If an attacker compromises a single domain controller, they can issue valid tickets that other controllers will accept. You must treat all domain controllers as potential sources of compromise.
Finally, many teams ignore Kerberos logs because they are noisy. Filtering out the noise requires careful tuning. Without proper filtering, you will miss the subtle anomalies that indicate a forged ticket.
Integrating with Security Tools
Your SIEM (Security Information and Event Management) system is the central hub for correlating these signals. Configure it to ingest Kerberos logs from all domain controllers. Set up alerts for the specific anomalies described above.
Correlate Kerberos events with file access logs and DNS queries. A golden ticket allows access, but the attacker still needs to move data. Combining authentication data with data exfiltration indicators provides a complete picture.
Use threat intelligence sharing platforms to stay updated on new techniques. While golden tickets are an old attack, the methods of delivery and evasion evolve. Integrating external threat feeds can help you identify new indicators.
Responding to a Suspected Attack
If you detect a golden ticket, assume the KRBTGT hash is compromised. Reset the KRBTGT password twice. The first reset invalidates existing tickets. The second reset ensures that any tickets created during the first reset are also invalid.
During this process, legitimate users will be unable to authenticate. Plan this maintenance during a low-activity window. Communicate with your users to avoid unnecessary help desk tickets.
After resetting the password, investigate how the attacker obtained the hash. Look for memory dumps, compromised domain controllers, or exposed credential stores. This step is critical to prevent recurrence.
Key takeaways
- Standard authentication logs often miss golden tickets because they are valid Kerberos credentials, not brute-force attempts.
- Anomalous ticket duration and issuance source are the primary technical indicators of compromise.
- Blind spots include privileged service accounts that rarely log in, making their sudden activity easy to overlook.
Golden tickets hide in plain sight by mimicking valid authentication, so you must hunt for anomalies in ticket structure and usage rather than failed logins. Reset the KRBTGT password twice if you suspect compromise to invalidate all forged tickets.
Frequently asked questions
Can a golden ticket be used across different domains?
Yes, if the attacker has the KRBTGT hash for the target domain or if there is a trust relationship between domains.
Do golden tickets work on Linux systems?
They work on any system that uses Kerberos authentication, including Linux distributions integrated with Active Directory.
How long does it take to detect a golden ticket?
Detection time varies, but monitoring ticket duration and issuance source can identify them immediately upon creation or use.
Is resetting the KRBTGT password safe?
It is safe but disruptive. It invalidates all Kerberos tickets, forcing all users to re-authenticate. Plan for downtime.
How this guide was produced: written by the TechSec Headlines editorial team with AI assistance, checked against the public references listed below, and reviewed when the facts change. See our editorial policy or report an error.
