Prevent Golden Ticket Attacks: Practical Defence Measures
Golden ticket attacks bypass standard logins by forging authentication tokens, meaning your password policies are irrelevant once an attacker gains domain control.
Stop golden ticket attacks by restricting domain admin access, enforcing Kerberos encryption standards, and monitoring for unusual ticket lifetimes. Focus on limiting privileges rather than just changing passwords, as the threat relies on stolen keys, not credentials.
The Anatomy of a Forged Credential
A golden ticket attack exploits the Kerberos protocol, which handles authentication in many enterprise networks. In a standard setup, a client requests a ticket from the Key Distribution Centre to access a service. The golden ticket bypasses this centre entirely. An attacker creates their own ticket, signing it with the secret key of the domain controller. This key is called the krbtgt account.
Because the ticket is signed with the legitimate secret, the domain controller accepts it as valid. The attacker can create a ticket for any user, including administrators. They can set the ticket to last for days or weeks. This allows persistent access even if you reset passwords or disconnect the compromised machine. The attack does not require the attacker to be on the network at the time of creation. They can forge the ticket offline and use it later.
Removing the Source Material
The most effective defence is to ensure the krbtgt secret never leaves the domain controllers. This secret is used to sign all Kerberos tickets. If an attacker obtains it, they can forge any ticket they wish. You must treat domain controllers as high-value assets. They should not be used for daily tasks such as browsing the web or reading email. These activities increase the risk of malware infection, which can lead to the extraction of the secret key.
Limit the number of people who have domain administrator rights. Every additional account increases the attack surface. Use a separate, isolated network segment for domain controllers. This reduces the chance of lateral movement from compromised workstations. Regularly audit who has these privileges. Remove access for employees who no longer need it. This reduces the number of potential entry points for an attacker seeking the krbtgt key.
Enforcing Strong Encryption Standards
Older versions of Kerberos support weak encryption types, such as DES and RC4. These algorithms are vulnerable to brute-force attacks. An attacker can capture a ticket and decrypt it to reveal the password or key material. Modern systems support AES encryption, which is significantly stronger. Configure your domain to reject tickets that use weak encryption types.
This setting applies to both ticket requests and service tickets. It forces clients and servers to use AES. This adds a layer of difficulty for attackers who might have captured older ticket data. It does not stop an attacker who already has the krbtgt key, but it prevents them from using weaker methods to extract it. Ensure all clients and servers in your environment support AES. Older systems may fail to authenticate if they do not support these standards.
Monitoring for Anomalous Behaviour
Golden tickets often have unusual characteristics. They may have extremely long lifetimes, far exceeding the default policy. They might be created for accounts that do not log in regularly. They could originate from unexpected source addresses. Configure your security information and event management system to alert on these anomalies. Look for Kerberos event ID 4769, which indicates a service ticket request.
Filter for tickets with durations longer than your maximum allowed lifetime. Check for tickets issued to accounts that have not been active recently. Monitor for multiple service ticket requests from a single client in a short period. This pattern often indicates an attacker testing access to various services. Combine this with baseline data to reduce noise. Knowing what normal activity looks like helps you spot the outliers quickly.
What Does Not Work
Many organisations rely solely on password complexity rules to prevent golden ticket attacks. This is a fundamental misunderstanding of the threat. Passwords protect the initial login. They do not protect the Kerberos ticket itself. Once an attacker has the krbtgt key, they can create tickets for any account, regardless of password strength. Changing passwords after an incident is useless if the attacker already forged a ticket.
Another common misconception is that disabling old protocols stops the attack. While disabling weak encryption is helpful, it does not prevent ticket forgery if the attacker has the signing key. Firewalls and intrusion detection systems cannot see inside the encrypted Kerberos traffic easily. They may block external access, but golden tickets are often used internally. Relying on perimeter defences alone leaves the internal network exposed.
See also: YARA vs Sigma Rules: Which Detection Method Fits Your Environment · Network Traffic Analysis: Fixing 6 Common Misconceptions
The Cost of Mitigation
Implementing these controls requires careful planning. Enforcing AES encryption may break compatibility with legacy systems. You must identify and upgrade or isolate these systems before making changes. Monitoring for anomalies generates a high volume of alerts. You need to tune your detection rules to avoid alert fatigue. This takes time and expertise.
Restricting domain admin access can slow down IT operations. Administrators may find it difficult to perform routine tasks. You need to establish clear procedures for emergency access. This adds overhead but reduces risk. The trade-off is between convenience and security. In the case of golden ticket attacks, the risk of undetected persistence outweighs the inconvenience of stricter access controls.
| Measure | Effort | What it stops |
|---|---|---|
| Restrict Domain Admins | Medium | Prevents extraction of krbtgt key from compromised admin accounts |
| Enforce AES Encryption | Low | Stops brute-force decryption of captured tickets and weak key usage |
| Monitor Ticket Lifetimes | High | Detects forged tickets with abnormal durations or unusual usage patterns |
| Isolate Domain Controllers | High | Reduces risk of malware infection and lateral movement to critical servers |
Closing Checklist
Start with these three actions to reduce your exposure. They address the most common failure points in Kerberos security.
- Audit your domain administrator group and remove unnecessary members.
- Configure your domain to reject tickets using DES and RC4 encryption.
- Create an alert for Kerberos tickets with lifetimes exceeding your policy.
Key takeaways
- Restricting domain administrator accounts removes the primary material needed to forge tickets.
- Enforcing strong encryption prevents attackers from using weak keys to create valid authentication tokens.
- Monitoring for anomalous ticket durations helps detect forged credentials that outlast normal session limits.
Golden ticket attacks bypass password security by forging authentication tokens with stolen domain keys. Focus on restricting admin access and monitoring for anomalous ticket behaviour to detect and prevent these intrusions.
Frequently asked questions
How do I know if a golden ticket attack has occurred?
Look for Kerberos tickets with unusually long lifetimes or issued to inactive accounts. Monitor for service ticket requests from unexpected sources or at odd hours.
Can antivirus software detect a golden ticket?
Antivirus software typically cannot detect forged Kerberos tickets. The ticket is a valid data structure, not a malicious file. Detection requires behavioural analysis and log monitoring.
Does changing the krbtgt password stop an active attack?
Changing the krbtgt password invalidates all existing tickets. This forces all users to re-authenticate. It stops the attacker’s current access but causes widespread disruption.
Are cloud environments vulnerable to golden ticket attacks?
Cloud environments using Active Directory Domain Services are vulnerable. The underlying Kerberos protocol is the same. Ensure cloud-managed domains follow the same security principles.
How this guide was produced: written by the DarkWeb Dispatch 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.
