The Golden Ticket: Kerberos’ Forbidden Pass

A Golden Ticket attack is one of the most dangerous threats to any Active Directory environment. With a single stolen KRBTGT password hash, an attacker can forge Kerberos tickets, impersonate any user, and roam your domain with nearly unlimited access. Understanding how the attack works and how to defend against it is essential for any team responsible for identity security.

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 do not 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.

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 is 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 the 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 is 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 does not 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 is 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.

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 is 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

Do not give end users admin authority on their workstations, and do not let admins log on to end-user computers. That way, an attacker who manages to get a foothold on an endpoint will not 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.

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 is 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 truly suspicious activity in the ocean of events can be a real challenge. Consider investing in a third-party Active Directory monitoring solution that can provide 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 is 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 do not assume that will keep you safe. You also need to actively monitor what is 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.

References

• Golden Ticket Attacks: How They Work and How to Defend Against Them

• Security
• Technology

• Kerberos
• Active-Directory
• SysAdmin