“Golden Ticket attack” is a particularly colorful (if you’ll pardon the pun) name for a particularly dangerous attack. The moniker comes from Roald Dahl’s book Charlie and the Chocolate Factory, where a golden ticket is the highly coveted pass that gets its owner into Willy Wonka’s tightly guarded candy factory. Similarly, a successful Golden Ticket attack gives the hacker access to an organization’s entire Active Directory domain.
However, the analogy breaks down in one important way: While Charlie and the other children with golden tickets were (mostly) escorted around the candy factory under close supervision, a successful Golden Ticket attack gives the hacker nearly unfettered access to everything in your domain, including all computers, files, folders and domain controllers (DCs). They can impersonate anyone and do just about anything.
Let’s see how this powerful attack unfolds — and what you can do to defend your organization.
How a Golden Ticket attack works
Golden Ticket attacks take advantage of a vulnerability in the Kerberos authentication protocol, which Microsoft has been using as its default authentication protocol ever since Windows 2000.
How Kerberos authentication normally works
With Kerberos, users never directly authenticate themselves to the various services they need to use, such as file servers. Instead, the Kerberos Key Distribution Center (KDC) functions as a trusted third-party authentication service. Every domain controller in an Active Directory domain runs a KDC service.
Specifically, when a user authenticates, the KDC issues a ticket granting ticket (TGT), which includes a unique session key and a timestamp that specifies how long that session is valid (normally 8 or 10 hours). When the user needs access to resources, they don’t have to re-authenticate; their client machine simply sends the TGT along to prove that the user has already been recently authenticated.
Importantly, before sending a TGT, the KDC encrypts it using the password hash for a special account, the KRBTGT account. That password hash is shared among all the DCs in the Active Directory domain so that they can read the TGTs they receive as users request access to various resources.
(Hashing is a one-way algorithm that mathematically transforms a given password into a different string. It’s always the same string, so two computers can each hash a password and compare the results; if they match, they agree they both started from the same password without ever having to directly share that password in plain text. It is virtually impossible to turn a hashed password back into the original password directly; however, hackers can use a brute-force method — generating the hashes of millions of possible passwords in the hope of finding one that matches.)
In short, Kerberos authentication — the default authentication protocol in Active Directory — is built upon the assumption that any TGT encrypted with the KRBTGT password hash is legitimate.
How hackers can subvert the process
In a Golden Ticket attack, hackers bypass the KDC and create TGTs themselves to get access to various resources. To forge a TGT, hackers need four key pieces of information:
- The FQDN (Fully Qualified Domain Name) of the domain
- The SID (Security Identifier) of the domain
- The username of the account they want to impersonate
- The KRBTGT password hash
The first three are relatively easy to obtain simply by compromising any user account in the domain. To do that, hackers have a wide variety of tactics at their disposal; popular ones include phishing, spyware, brute force and credential stuffing.
The fourth item is also critical: To make a ticket appear legitimate to the domain controllers, the attacker must encrypt it using the KRBTGT password hash. That’s harder for a hacker to get, so the techniques are more sophisticated — but still not all that difficult. They include:
- Stealing the NTDS.DIT file — The NTDS.DIT file is a database that stores Active Directory data, including the password hashes for all users in the domain. A copy of the file is stored on every domain controller, in C:\Windows\NTDS\ by default. Someone who obtains this file can take all the time they need to crack those passwords offline, where they cannot be detected, and then use the credentials to act as any user on the domain, including a Domain Administrator.
- Compromising a workstation — Many attacks begin with attackers gaining a foothold on a user workstation or other endpoint. If the user has admin rights on the machine, or an admin logged on there at some point in the past, there can be credential artifacts in memory or on disk drive from the admin’s password.
- Using Mimikatz — Mimikatz makes it simple to gather credential data from Windows systems. A favorite tool of penetration testers as well as hackers, it is easy to get; official builds are maintained and hosted right on GitHub.
- Running a DCSync attack — Active Directory environments typically include multiple domain controllers, which have to remain in sync by updating each other about changes, such as updates to user credentials. In addition, some applications, including Azure Active Directory Connect, need replication permissions. In a DCSync attack, a hacker who has gained access to a privileged account with domain replication rights subverts this AD functionality by pretending to be a DC and requesting password hashes from a legitimate DC. DCSync is a capability of the Mimikatz tool.
However it’s obtained, the KRBTGT password hash is like Willy Wonka’s golden ticket. With it in hand, a hacker can create a Kerberos ticket to impersonate any AD user they want, including privileged administrators. Moreover, they can make those tickets valid for as long as they want, even if that violates the organization’s time limit policy setting. That gives them nearly unlimited power in the domain.
Defending against Golden Ticket attacks
There is no way to completely prevent Golden Ticket attacks, but there are multiple best practices that can dramatically reduce your risk. Here are the top ones I recommend.
Change the KRBTGT password regularly — and in special circumstances as well.
The first essential defense strategy against Golden Ticket attacks is to change the KRBTGT password regularly. That doesn’t prevent hackers from creating Golden Tickets, but it invalidates any that are already in your systems. Microsoft recommends “regular” password updates to the KRBTGT account, while STIG specifically recommends changing it every 180 days.
In addition to those scheduled updates, I strongly advise changing the password every time a human who had the ability to create a Golden Ticket leaves the organization. Even if you promptly delete their privileged account, they might have left behind TGTs that they could still use to cause havoc in your environment; resetting the KRBTGT password will render all such tickets invalid. Finally, it probably goes without saying that you need to immediately change the KRBTGT password if you spot any evidence of a Golden Ticket attack in your IT environment.
Note that the password history value for the KRBTGT account is 2, which means it includes the two most recent passwords. Therefore, to invalidate all TGTs currently in the system, you need to reset the password twice. Microsoft details the steps for manually changing the KRBTGT password, but it’s usually better to use the KRBTGT password reset script from Microsoft — it will change the password once, wait to make sure replication has gone all the way through to all your domain controllers, and then change the password again.
Important: Be aware that changing the KRBTGT password will affect almost all subsequent Kerberos operations. In particular, all the TGTs that have been issued will be invalid since they were encrypted with the old password. However, all authenticated sessions that have been established to a resource (such as a file share, SharePoint site or Exchange server) are good until the service ticket is required to re-authenticate. Microsoft advises that rebooting a computer is the only reliable way to recover functionality, since this will force both the computer account and the user account to log back in again, which in turn ensures that they get new TGTs encrypted with the new KRBTGT password hash.
To reset the password, you must be a member of both the Domain Admins group and the local Administrators group, or have been delegated the appropriate authority.
Minimize the number of accounts that can access the KRBTGT password hash.
Least privilege is a cornerstone of security, especially when it comes to your most valuable IT assets — and the KRBTGT password hash definitely qualifies, since it’s the key to a successful Golden Ticket attack. Be sure you know exactly which accounts could execute the DCSync command. By default, this includes the builtin\Administrators group and builtin\domain controllers; in addition, the account used for Azure AD Connect typically has the power to execute the DCSync command as well. Make sure you have only the absolute minimum number of Domain Admins, as well as members of other groups that provide logon rights to DCs, such as Print and Server Operators. If you find any other accounts with access to this critical data, investigate immediately and remove any unnecessary permissions.
Minimize opportunities for hackers to steal privileged credentials.
Don’t give end users admin authority on their workstations, and don’t let admins log on to end-user computers. That way, an attacker who manages to get a foothold on an endpoint won’t find any privileged credentials there to harvest and use in a Golden Ticket attack.
In addition, regularly change your service account passwords, and be sure to pick relatively long passwords to thwart password-guessing and other brute-force attacks. Another tip is to set up an alert that will notify the security team whenever a service principal name (SPN) is created or modified, so they can check that all relevant policies were followed. Of course, whenever possible, replace regular service accounts with group managed service accounts, which provide automatic password management.
Reduce your AD attack surface.
Monitor your IT environment for suspicious activity.
While strengthening your security posture is always a wise strategy, you need to assume that your environment will be breached. Therefore, it’s essential to be on the lookout for unusual activity that could be the sign of a Golden Ticket attack in progress. Items to monitor — or get alerted on — include the following:
- TGTs with long lifetimes — Any Kerberos ticket that exceeds your domain policy for maximum ticket lifetime is a clear sign that an attacker has exploited the Golden Ticket vulnerability. If you find one, investigate it immediately and if necessary, reset the KRBTGT password and get to the bottom of how the attack succeeded.
- Aberrant domain replication activity — Unusual domain replication activity can be a sign that someone is using DCSync or other techniques to steal password hashes. If you can quickly spot, investigate and respond to this activity, you can prevent hackers from successfully completing a Golden Ticket attack.
- Domain controller activity — Pay close attention to what executables and what scripts (especially PowerShell scripts) are running on your domain controllers.
- Changes to privileges — In particular, if the debug privilege is suddenly enabled, investigate immediately.
Unfortunately, the native Windows event logs do not include the TGT timestamps and ferreting out suspicious truly activity in the ocean of events can be a real challenge. Consider investing in a third-party Active Directory monitoring solution that can provides the clear, detailed reporting you need to spot activity indicative of Golden Ticket attacks.
Set bait.
Finally, another strategy for flushing out Golden Ticket attacks is to create honeypot objects in Active Directory, such as a honeypot user account. Make sure it’s prominent, give it a tempting username and give it membership in some interesting groups. Be sure to assign it the longest password in the world and throw that password away. Then watch for attempts to log on using that account — you may be surprised how many you get.
Conclusion
Golden Ticket attacks have a playful name but they are a serious threat to every Active Directory environment. Be sure to bolster your security posture by rigorously following proven best practices like least privilege, but don’t assume that will keep you safe. You also need to actively monitor what’s happening across your IT ecosystem, especially any activity that indicates an attempt to steal the critical piece to a successful Golden Ticket attack: the KRBTGT password hash.
