Golden Ticket Attacks: Debunking 6 Common Myths About Kerberos Forgery
Golden ticket attacks do not require network traffic capture or password cracking, as they rely on forging authentication structures using a single static domain key that persists indefinitely.
Golden ticket attacks bypass Kerberos authentication by forging tickets signed with the KRBTGT key. They do not require capturing network traffic or cracking passwords. The attack persists because the forged ticket remains valid until the domain key is changed, making detection reliant on behavioural anomalies rather than credential analysis.
Myth: Golden tickets require capturing network traffic
Reality: Golden ticket attacks do not depend on intercepting Kerberos traffic. Attackers do not need to sit on the network wire or perform man-in-the-middle attacks to steal a ticket-granting ticket. The mechanism relies entirely on the cryptographic signing key of the domain controller, known as the KRBTGT account. This key is replicated across all domain controllers in the environment. An attacker only needs to extract this key from a single compromised controller.
Once the key is obtained, the attacker can generate valid authentication tickets locally on their own machine. No network sniffing or packet capture is required for the initial compromise phase. This distinction matters because network-based intrusion detection systems often miss the attack entirely. The traffic generated during exploitation looks identical to legitimate user activity. The threat originates from the possession of the key, not the interception of credentials in transit.
Myth: The attack involves cracking user passwords
Reality: Password cracking plays no part in a golden ticket attack. Attackers do not attempt to guess or brute-force the password of a specific user account. They do not target the password hash of the victim. Instead, the attacker targets the password hash of the KRBTGT service account. This service account is responsible for signing all ticket-granting tickets within the domain.
The KRBTGT password is complex and rarely changed, but it is identical across every domain controller. Extracting the hash from memory or the security account manager database is sufficient. The attacker then uses this hash to sign new tickets for any user they choose. This means the strength of individual user passwords is irrelevant to the success of the attack. Even if a user has an impossibly strong password, the attacker can create a ticket for that user without ever knowing the password.
Myth: Golden tickets expire after a short duration
Reality: Golden tickets persist until the underlying domain key is changed. Standard Kerberos tickets have a limited lifespan, typically eight hours, to limit the window of exposure. Attackers exploit this by setting the lifetime field of the forged ticket to a maximum value, often up to 10 years. This duration is hardcoded into the Kerberos protocol limits. The ticket does not degrade or invalidate over time.
It remains valid for every service request the attacker makes. This creates a persistent backdoor that survives reboots, account lockouts, and even password resets for the target user. The only way to invalidate a golden ticket is to change the KRBTGT password. This action requires a domain-wide update and temporary disruption to authentication services. Until that change propagates, the forged ticket remains fully functional.
Myth: Security teams can detect golden tickets via failed login attempts
Reality: Golden ticket attacks generate no failed login attempts. The authentication process succeeds because the ticket is cryptographically valid. The domain controller verifies the signature using the known KRBTGT key. If the signature matches, access is granted immediately. There are no brute-force patterns, no lockouts, and no suspicious login failures to analyse. This silence makes the attack difficult to detect through standard log monitoring.
Security analysts often look for spikes in failed attempts as a sign of credential abuse. Golden tickets bypass this heuristic entirely. The attack is invisible to systems that rely on failure-based detection. Detection requires looking for successful logins with unusual parameters. Analysts must identify tickets with excessive lifespans or access to services that do not match the user's historical behaviour.
Myth: The attack requires physical access to a server
Reality: Physical presence is not a prerequisite for golden ticket attacks. Attackers can extract the KRBTGT key remotely if they have administrative privileges on the domain. Remote code execution vulnerabilities or misconfigured permissions can provide the necessary access. The DCSync attack technique is commonly used for this purpose. DCSync allows an attacker with specific directory service privileges to request replication data from a domain controller.
This data includes the password hashes of critical accounts, including KRBTGT. This replication happens over the network using standard directory services protocols. No physical console access or out-of-band management channel is needed. The attacker operates from a compromised workstation anywhere in the network. This remote capability makes the threat accessible to threat actors who have achieved a foothold through phishing or software vulnerabilities.
See also: Island Hopping Attacks: Prevention Checklist for Network Defence · Threat Actors Definition: Who They Are and How They Operate
Myth: Changing a user password stops the attack
Reality: Changing the password of the targeted user account does not invalidate a golden ticket. The golden ticket is signed with the KRBTGT key, not the user's password hash. The ticket contains the user's security identifier and permissions, but not their credential. When the user changes their password, the system updates the password hash stored in the directory. The golden ticket remains valid because it is verified against the KRBTGT key, which has not changed.
The attacker continues to possess a valid authentication token for that user. This misconception leads to false confidence in incident response procedures. Resetting user passwords is a standard step in containing credential theft, but it fails against golden tickets. The only effective countermeasure is changing the KRBTGT password, which invalidates all existing tickets in the domain. This forces all users to re-authenticate, breaking the attacker's session.
| Myth | Reality |
|---|---|
| Requires network traffic capture | Requires only the KRBTGT key |
| Involves cracking user passwords | Uses the KRBTGT hash to sign tickets |
| Tickets expire quickly | Tickets persist for years until key change |
| Detected via failed logins | Leaves no failure logs; requires behavioural analysis |
| Needs physical server access | Can be executed remotely via DCSync |
| Stopped by user password reset | Requires KRBTGT password change to invalidate |
Detection relies on behavioural anomalies
Reality: Effective detection requires analysing user behaviour rather than credential validity. Since the ticket is valid, the system records a successful login. Analysts must look for patterns that deviate from the norm. A user who normally accesses only email and file shares suddenly requesting access to domain controllers or sensitive databases is suspicious. The ticket-granting service logs can reveal the source of the ticket.
If the ticket was issued by a controller that the user has never contacted before, this is an anomaly. Additionally, the ticket lifetime field is a strong indicator. Standard tickets have short lifespans. A ticket with a maximum duration suggests forgery. Combining these behavioural signals with the technical details of the ticket structure provides a reliable method for identifying the attack. This approach complements other indicators of compromise in a broader threat intelligence framework.
Key takeaways
- Forged tickets use the KRBTGT key, allowing access to any service without needing specific service passwords.
- The attack leaves no login logs for the initial ticket creation, creating a blind spot in standard auditing.
- Detection relies on identifying tickets with unusual durations or access to resources the user never touched.
Golden ticket attacks bypass standard authentication checks by forging valid tickets with a static domain key, rendering password resets ineffective for containment. Change the KRBTGT password immediately upon suspicion to invalidate all forged tickets and force a complete domain re-authentication.
Frequently asked questions
Can a golden ticket be used from any computer?
Yes, the forged ticket can be used from any machine on the network that has Kerberos configured to trust the domain, allowing the attacker to move laterally without restriction.
How does this differ from a silver ticket attack?
A silver ticket grants access to a specific service, while a golden ticket grants access to all services in the domain, making it significantly more powerful and harder to contain.
Do modern Windows versions prevent golden ticket attacks?
No, modern versions still rely on the Kerberos protocol and the KRBTGT key, so the underlying vulnerability remains unless strict least-privilege access is enforced to protect domain controllers.
Can endpoint detection and response tools stop this?
Endpoint detection may identify the tool used to generate the ticket, but it cannot stop the ticket's use once created, as the network traffic appears legitimate to the domain controller.
How this guide was produced: written by the Malware Brief 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.
