A golden ticket is a forged Ticket Granting Ticket created using the domain controller’s KRBTGT password hash. It grants the attacker persistent, high-level access to any service in the Active Directory domain without triggering standard authentication failures, making it one of the most stealthy privilege escalation techniques available.
What is a golden ticket attack?
A golden ticket attack is a privilege escalation technique where an adversary forges a Ticket Granting Ticket (TGT) to impersonate any user within an Active Directory domain. The attacker does this by encrypting the ticket with the secret key of the KRBTGT account, which is the service account used by the Key Distribution Center to sign all TGTs. Because the ticket is signed with the correct key, the domain controller accepts it as legitimate without verifying the user’s actual credentials.
How does it differ from a silver ticket?
While a golden ticket grants access to any service in the domain, a silver ticket is a forged Ticket Granting Service (TGS) ticket that only grants access to a specific service. The key difference lies in the encryption key used: golden tickets use the KRBTGT hash, while silver tickets use the password hash of the specific target service account. This distinction matters because silver tickets are harder to detect via global TGT analysis but easier to isolate to a single compromised service.
Why does the KRBTGT account matter?
The KRBTGT account is the root of trust for the Kerberos authentication protocol within a Windows domain. Its password hash is used to encrypt and sign every TGT issued by the domain controllers. If an attacker obtains this hash, they can generate valid TGTs for any user, including administrators, without needing to know those users’ passwords. This makes the KRBTGT hash the single most sensitive piece of data in a Kerberos-based environment.
How do attackers obtain the KRBTGT hash?
Attackers typically acquire the KRBTGT hash by compromising a domain controller or by extracting credentials from memory on a machine with domain admin rights. They may use tools that read the Security Account Manager database or dump process memory from the lsass.exe process, which holds cached credentials. This initial compromise often involves other techniques, such as pass-the-hash attacks, where stolen credential hashes are reused to authenticate to other systems.
Can standard SIEM rules detect golden tickets?
Standard security information and event management systems often fail to detect golden tickets because the forged tickets are cryptographically valid. The domain controller logs a successful authentication event, not a failure, so rules based on failed login attempts or unusual login times are ineffective. The attack bypasses standard authentication checks because the system trusts the signature on the ticket, which matches the KRBTGT key it expects.
See also: Warning Signs of Cyber Range Training Platforms in Production · DFIR Training Myths That Weaken Incident Response Capabilities
What specific logs indicate a golden ticket?
You must look for specific anomalies in the Kerberos pre-authentication data within Event ID 4768 on domain controllers. A golden ticket often lacks certain standard attributes or contains a ticket lifetime that exceeds the maximum allowed by domain policy. For example, if a ticket has a lifetime of several days or years instead of the standard hours, it is likely forged. Analyzing these details is a core component of effective detection use cases for identity-based threats.
| Attribute | Normal TGT | Golden Ticket |
|---|---|---|
| Encryption Key | KRBTGT Hash | KRBTGT Hash (Stolen) |
| Ticket Lifetime | Standard Policy (e.g., 10h) | Arbitrary (often very long) |
| Pre-Auth Flag | Required | Often Bypassed or Missing |
| Service Target | Any Domain Service | Any Domain Service |
How do you respond to a suspected golden ticket?
If you suspect a golden ticket attack, you must reset the password for the KRBTGT account on all domain controllers. This invalidates all existing TGTs, forcing every user to re-authenticate. To make this change effective immediately, you must reset the password twice, as the first reset updates the domain controllers, but the second ensures the new hash is propagated and used for signing new tickets. This process is disruptive and should be part of your incident response plan for Active Directory attacks.
How can you prevent golden ticket attacks?
Prevention focuses on protecting the KRBTGT hash and limiting the blast radius of a compromise. You should enforce strict access controls on domain controllers and monitor for unauthorized access to the Security Account Manager database. Additionally, implementing tiered administration models ensures that even if a workstation is compromised, the attacker cannot easily reach the accounts needed to extract the KRBTGT hash. This approach reduces the likelihood of successful extraction during nation-state cyber attacks or insider threats.
What are the limitations of this attack?
Golden tickets do not grant access to resources outside the domain, such as cloud services or external networks, unless those services trust the domain. They also do not bypass local authentication on standalone machines. Furthermore, if the domain uses smart card authentication or strong pre-authentication requirements that cannot be forged, the effectiveness of a simple golden ticket may be reduced. Understanding these boundaries helps you prioritize defenses based on your specific infrastructure.
How does this relate to beaconing?
While golden tickets provide access, they do not inherently create network noise. However, an attacker using a golden ticket may establish persistent connections to command and control servers. This activity can manifest as beaconing, where the infected system sends regular, periodic signals to the attacker’s infrastructure. Detecting this network behavior is often more reliable than detecting the ticket itself, as the ticket remains silent at the application layer.
Key takeaways
- The attack relies on the static nature of the KRBTGT account hash, which rarely changes in most environments.
- Standard security information and event management systems often miss these attacks because the tickets appear cryptographically valid.
- Detection requires monitoring for anomalies in ticket lifetimes and specific attribute flags rather than just failed logins.
Golden tickets exploit the static trust in the KRBTGT account, making them nearly invisible to standard authentication logs. Monitor for anomalous ticket lifetimes and enforce strict isolation of domain controller access to mitigate this risk.
Frequently asked questions
Can a golden ticket be used on a server that does not trust the domain?
No, golden tickets are only valid within the domain that issued the KRBTGT hash. They cannot be used to authenticate to external domains or standalone servers unless a trust relationship exists and the attacker forges a ticket for that trust.
Does changing the KRBTGT password log out all users?
Yes, resetting the KRBTGT password invalidates all existing TGTs. Users will be forced to re-authenticate, which may cause temporary disruption to active sessions and services that rely on cached Kerberos tickets.
Can antivirus software detect a golden ticket?
Antivirus software generally cannot detect a golden ticket because it is a legitimate cryptographic structure. Detection requires behavioral analysis or specific identity protection tools that inspect Kerberos ticket attributes, not signature-based malware scanning.
Is a golden ticket the same as a pass-the-ticket attack?
No, pass-the-ticket involves stealing a legitimate, existing ticket from memory. A golden ticket is a completely forged ticket created by the attacker using the KRBTGT hash. Both grant access, but the golden ticket is more persistent and harder to trace to a specific source.
How this guide was produced: written by the Vuln Post 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.
