How to Defend Against Golden Ticket Attacks on Active Directory

In the 1964 Roald Dahl novel Charlie & the Chocolate Factory, the enigmatic Willy Wonka hides five Golden Tickets among his factory’s chocolate candy bars. Those who find the tickets win the honor of behind-the-scenes access to his company’s facility. In the digital world, Golden Tickets also provide access, but to something far more valuable than a mysterious factory—your organization’s IT environment.

Related reading

• Active Directory Security: Top Risks & Best Practices

Your Ticket, Please

As a quick primer: when a PC client authenticates to a domain, the Kerberos Key Distribution Center (KDC) on the authenticating domain controller (DC) provides the client a Ticket Granting Ticket (TGT). This TGT gives the client the ability to request a service ticket from the KDC to access a service (for example, a file server). The KDC sends the service ticket to the client, encrypted with the hashed value of the service account’s password. The client passes the ticket to the service, which decrypts it and grants the client access to the service.

The krbtgt account functions as a service account for the KDC service. With control of the krbtgt account, attackers can create fraudulent TGTs to access any resources they want. This scenario is the essence of a Golden Ticket attack. If performed successfully, Golden Ticket attacks enable threat actors to impersonate any user. The attack is difficult to detect and can be used by threat actors to persist under the radar for long periods of time.

Launching the attack requires that the attacker has already compromised an account with elevated privileges that can access the domain controller. Every domain controller in the AD environment runs a KDC. Once they have access to the domain controller, the attacker can use a tool like Mimikatz to steal the NTLM hash of the krbtgt account.

With the krbtgt password hash in hand, the threat actor only needs the following to create a TGT:

• Fully Qualified Domain Name (FQDN) of the domain
• The domain’s Security Identifier (SID)
• The username of the account they are targeting.

While TGTs are usually valid for 10 hours by default, an attacker can make the TGT valid for any length of time up to 10 years. For this reason, having a strategy to detect, mitigate, and remediate these attacks is critical.

Use basic security hygiene to guard against Golden Ticket attacks

Preventing Golden Ticket attacks starts with basic security hygiene. Adversaries cannot launch the attack without first compromising the environment, so organizations can start by implementing a layered defense to reduce the attack surface and raise the barrier to entry.

1. Preventing credential theft: The first layer involves the prevention of credential theft. Blocking credential-stealing malware and phishing attacks is critical and should involve a mix of employee security awareness training as well as network and endpoint security. Eliminating common passwords from your directory by using a custom password filter such as Azure AD Password Protection will reduce the chance that a password spray attack will succeed. Any Mimikatz activity that is not being led by your organization’s Red team or an authorized pen tester is a clear sign that attackers have arrived.
2. Keeping AD secure: The next layer involves raising the castle wall around AD itself. Because a Golden Ticket attack requires privileged access to a domain controller, implementing the principle of least privilege is crucial to keeping AD secure. AD teams should keep the number of user and service accounts with access to DCs to a minimum. Accounts with domain administrator or “replicating directory changes” permissions can be used to launch DCSync attacks, which enable the krbtgt hash to be stolen.
3. Looking for forged tickets: Just like counterfeit dollar bills, forged tickets can be discovered by looking for unusual user behavior and then examining the ticket for telltale signs. For example, mistakes such as username and relative ID (RID) mismatches or alterations to the ticket’s lifespan might be indicators of malicious activity. Additionally, monitoring AD for unusual activity, such as changes to group membership, is also important.
4. Using caution when changing the krbtgt password: One of the most common pieces of advice for addressing Golden Ticket attacks is changing the krbtgt password every 180 days. This shouldn’t be done casually, as it will temporarily cause Privileged Attribute Certificate (PAC) validation failures. The best method of updating the password is studying and running the krbtgt account password reset script (provided by Microsoft MVP Jorge de Almeida Pinto, this is a continuously updated reset script), which also allows organizations to validate that all writable DCs in the domain have replicated the keys derived from the new password hash. Changing the krbtgt password every 180 days is a best practice. However, AD teams should also consider changing it every time an employee who could create a Golden Ticket leaves the organization. Taking this action reduces the risk of a disgruntled former staffer using a forged ticket for malicious purposes. It’s important to remember that if a Golden Ticket attack is detected, the password will have to be reset twice to mitigate the attack. Why? Because the krbtgt account remembers the previous two passwords, so resetting the password twice is necessary to prevent another DC from using an old password to replicate with the affected DC. As a warning, changing the password twice before the password can replicate throughout the environment can disrupt network access, so take your time and be sure the first update has propagated to every DC.

Building a solid defense against Golden Ticket attacks

Mitigating and responding to a Golden Ticket attack is difficult. However, because these attacks can pave the way to widescale data theft and ransomware, factoring Golden Ticket attacks into your AD recovery and incident response scenarios is vital.

Take care to ensure that the extent of the attackers’ activity has been determined before rebuilding affected systems and resetting accounts, thus letting the actor know that you’ve detected their activity. Ensure you have an offline backup and ideally a recovered, isolated forest so that if the actor detonates the ransomware payload, you still have a viable AD forest. Only by fully understanding the damage done can organizations be sure that they have completely closed the door on the attackers and prevented them from maintaining a foothold.