Golden Ticket Attack Prevention Checklist for Identity Security

Why Golden Tickets Bypass Standard Defenses

Golden ticket attacks exploit the trust model inherent in Kerberos authentication. An attacker who obtains the hash of the krbtgt account can forge valid ticket-granting tickets for any user or service. These forged tickets appear legitimate to domain controllers because they are signed with the correct keys. The attack does not require live credentials or interaction with the target system during the initial phase.

It relies entirely on the cryptographic signature being valid. This makes detection difficult because the authentication flow looks normal to standard logging tools. The attacker can create tickets for users that do not exist, bypassing account lockout policies entirely. Understanding this mechanism is the first step in building effective defenses.

Securing the krbtgt Account

The krbtgt account is the root of trust in the Kerberos hierarchy. Protecting this account requires strict access controls and regular password rotation. Rotating the krbtgt password twice is necessary to invalidate both current and previous ticket-granting tickets. This process ensures that any golden tickets created with the old hash become invalid.

You must monitor access to this account closely. No regular user or service account should have permission to modify krbtgt attributes. Implementing privileged access management solutions helps restrict who can interact with this critical object. The cost of rotation is temporary authentication disruption, but the security benefit is immediate invalidation of stolen credentials.

• Rotate krbtgt password twice: invalidates existing forged tickets created with the old hash.
• Restrict krbtgt group membership: prevents unauthorized users from modifying the master key.
• Enable audit logging for krbtgt changes: provides forensic evidence if the account is tampered with.

Enforcing Ticket Lifetime Policies

Default Kerberos configurations often allow tickets to remain valid for extended periods. Long-lived tickets increase the window of opportunity for an attacker to use a stolen or forged credential. Setting maximum ticket lifetimes to short durations, such as 10 hours, limits the usefulness of any compromised ticket. You must also configure renewable lifetime limits to prevent tickets from being extended indefinitely. These settings apply to both user and service tickets. Strict lifetime policies force attackers to re-authenticate frequently, increasing their chance of detection. This approach balances security with usability, as most legitimate users do not need 24-hour continuous sessions.

• Set max ticket lifetime to 10 hours: reduces the window for using forged credentials.
• Set max renewable lifetime to 10 hours: prevents attackers from extending ticket validity indefinitely.
• Enforce these settings via Group Policy: ensures consistent application across all domain controllers.

Monitoring for Anomalous Authentication Patterns

Detection relies on identifying deviations from normal authentication behavior. Golden tickets often exhibit specific characteristics that differ from legitimate tickets. Look for tickets with unusually long lifetimes or those issued to users who do not typically log in at certain times. Monitor for the use of the krbtgt account in authentication requests, as this is rare in normal operations.

Analyzing ticket flags can reveal if a ticket was forged rather than issued by a ticket-granting server. You should correlate authentication logs with user activity patterns to spot anomalies. This method requires baseline knowledge of normal user behavior to distinguish between legitimate and malicious activity.

• Alert on tickets with infinite lifetimes: golden tickets often ignore standard lifetime restrictions.
• Monitor for krbtgt in authentication logs: indicates potential misuse of the master key.
• Check for unusual ticket flags: forged tickets may lack standard security extensions or flags.

Integrating with Broader Threat Intelligence

Golden ticket attacks are often part of larger campaigns that include other identity-based threats. Understanding the relationship between golden tickets and other attacks helps in building a holistic defense strategy. For example, an attacker might use NTLM relay attacks to gain initial access before attempting to extract the krbtgt hash. Similarly, DCSync attacks can be used to replicate the krbtgt account and obtain its hash directly. Knowledge of these related techniques allows you to anticipate attacker movements. Reviewing threat intelligence reports can provide insights into how attackers are evolving their methods. This context helps in prioritizing which defenses to implement first.

• Review NTLM relay attack defenses: prevents initial access that could lead to golden ticket creation.
• Monitor for DCSync activity: detects attempts to replicate the krbtgt account directly.
• Analyze Kerberoasting risks: ensures service accounts are not compromised to facilitate further attacks.

See also: Account Takeover vs Identity Theft: The Critical Difference · Remote Desktop Abuse: The Step-by-Step Attack Chain

Validating Incident Response Procedures

When a golden ticket attack is suspected, immediate action is required to contain the threat. Your incident response runbooks should include specific steps for handling Kerberos-related incidents. This includes isolating affected systems, rotating credentials, and analyzing logs for evidence. Testing these procedures regularly ensures that your team can respond effectively under pressure. Documentation of the incident helps in understanding the attack vector and improving future defenses. You should also consider the impact on blue team operations, as detecting these attacks requires specialized skills. Regular training and simulation exercises help maintain readiness.

• Update incident response runbooks: includes specific steps for Kerberos ticket forgery incidents.
• Conduct tabletop exercises: tests the team's ability to detect and respond to golden ticket attacks.
• Document attack vectors: helps in understanding how the attacker gained access to the krbtgt hash.

Limitations of Endpoint Protections

Endpoint detection and response tools are valuable but have limitations against golden ticket attacks. Since the attack happens at the identity layer, endpoint agents may not see the initial forgery. The attacker can create tickets from any machine with the krbtgt hash, making the source of the attack hard to pinpoint. Relying solely on endpoint security leaves a gap in your defense strategy. You must integrate identity monitoring with endpoint data to get a complete picture. This combined approach helps in correlating events and identifying the full scope of the compromise.

• Integrate identity logs with endpoint data: provides a broader view of potential attack activities.
• Monitor for lateral movement: golden tickets often enable attackers to move freely across the network.
• Validate OSINT investigations: ensures external indicators are not missed in the detection process.

Key takeaways

• The krbtgt account hash is the master key for all Kerberos ticket-granting tickets.
• Infinite lifetime tickets are a primary indicator of a successful golden ticket creation.
• Regular rotation of the krbtgt password invalidates existing forged tickets.

Frequently asked questions

Can antivirus software detect golden ticket attacks?

No, antivirus software typically cannot detect golden ticket attacks because they do not involve malware execution or file changes on the endpoint.

How often should I rotate the krbtgt password?

You should rotate the krbtgt password regularly, such as every 180 days, to limit the window of opportunity for attackers using stolen hashes.

What is the difference between a golden ticket and a silver ticket?

A golden ticket is a forged ticket-granting ticket that allows access to any service, while a silver ticket is a forged service ticket that grants access to a specific service only.

Do golden tickets work across different domains?

No, golden tickets are specific to a single domain because they are signed with the domain's krbtgt hash and do not automatically grant access to trusted domains.

How this guide was produced: written by the Sandbox Desk 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.