Kerberos authentication: How it works — and how to maximize its security

Kerberos authentication has been Microsoft’s default authentication method since Windows Server 2000. In my previous post, I explained the weaknesses in the older NTLM protocol and why organizations should make a concerted effort to stop using it, especially the weaker NTLMv1.

But how does Kerberos authentication work, and exactly why is it better than NTLM? Moreover, does Kerberos authentication have any vulnerabilities of its own (spoiler alert: It does!) and how can you mitigate your risk? Let’s dive in.

How Kerberos authentication works

Kerberos authentication takes its name from Cerberos, the three-headed dog that guards the entrance to Hades in Greek mythology to keep the living from entering the world of the dead.

The name was chosen because Kerberos authentication is a three-way trust that guards the gates to your network. The three “heads” of Kerberos are:

• The user’s client machine
• The server with the service the user needs to access
• The Key Distribution Center (KDC), a process that runs on every domain controller in the Active Directory domain and provides two key services: Ticket-Granting Service (TGS) and Authentication Service (AS)

How do those pieces fit together? Well, users need to access various IT resources, such as file servers, in order to do their jobs. But not just anyone should be able to access those resources, so there has to be an authentication process that verifies that the user requesting access actually is who they claim to be, followed by an authorization process, which checks that the authenticated user has been granted the access they seek.

But it would be unworkable to require users to authenticate each time they need to access a new application or document. Plus, it would be highly insecure for them to be sending their credentials all over the network, and for every network resource to have a copy of those credentials to check against.

With Kerberos, users don’t have to constantly provide their credentials, and they never directly authenticate themselves to the various IT services they need to use. Instead, the process proceeds as follows:

1. For the initial authentication, the user’s client machine sends a request to the KDC Authentication Service (AS). The request includes details like the user’s username, and the date and time. All information except the username is encrypted using the hash of the user’s password.
2. The KDC AS uses the username to look up its copy of the user’s password hash and uses it to decrypt the rest of the request. If the decryption is successful, that means the client used the correct password hash and the user has successfully authenticated.
3. Once the user is authenticated, the KDC AS sends the user’s client a ticket granting ticket (TGT). The TGT includes a unique session key and a timestamp that specifies how long that session is valid (normally 8 or 10 hours). Importantly, before sending the 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 IT resources.
4. Whenever the user needs access to an IT resource, their client machine sends the request to the KDC Ticket Granting Service (TGS), including the TGT to prove that the user has been recently authenticated.
5. The KDC TGS decrypts the TGT using the KRBTGT password If that process is successful and the timestamp indicates the TGT is still valid, the TGS creates a token and encrypts it using the service account’s NTLM password hash (which, ideally, is known only to the DC and the service itself). It sends the resulting TGS ticket to the user’s client machine.
6. The client machine sends the TGS ticket to the application server, which decrypts it using its own password hash. Upon verification, it grants access to its resources to the user for a specific period of time, known as the Time to Live (TTL) (by default, the TTL is 10 hours). (I’ve skipped over the details of authorization — determining exactly what access to which resources the user has been granted — since we’re focused on authentication here.)

Kerberos vs NTLM

Kerberos authentication offers a number of advantages over the older NTLM protocol. If you remember my previous blog post, one key weakness of NTLM is that it leaves artifacts all over the place for attackers to grab, and they can use them to discover user password hashes or even brute-force the plaintext passwords. In that way, NTLM is like old-style credit card imprinting machines, a methodology that left every merchant you visited with a copy of your credit card number.

Because Kerberos relies on TGT and TGS tickets for authentication, user passwords are far less exposed. In particular, the Kerberos authentication process never caches passwords on the local user’s hard disk. So, it’s more like PayPal, where you provide your credit card number to just one entity, and they handle the interactions with each merchant without ever giving them your sensitive data.

In addition, Kerberos authentication delivers the following advantages over NTLM when it comes to security:

• Kerberos authentication makes use of more advanced encryption methods than the outdated MD4 cryptographic function used in NTLM. In fact, using Security policy settings in Group Policy, you can configure which of the following encryption types are allowed in Kerberos authentication:
• DES_CBC_CRC
• DES_CBC_MD5
• RC4_HMAC_MD5
• AES128_HMAC_SHA1
• AES256_HMAC_SHA1
• Kerberos supports multifactor authentication (MFA).
• NTLM gives the user’s client no way to validate the identity of the server it’s authenticating to, but Kerberos provides mutual authentication.

Aside from better security, Kerberos authentication also offers faster performance.

Vulnerabilities in Kerberos authentication

Still, the Kerberos authentication process is not without potential issues. In particular, the protocol is vulnerable to Kerberoasting, Golden Ticket and Silver Ticket attacks, and pass-the-ticket attacks.

Kerberoasting

Kerberoasting was first described in 2014; today, it’s a common attack used by hackers who’ve compromised a user’s credentials and want to begin lateral movement. Since the attackers seem to be a valid domain user, they can complete steps 1–5 of the process above. Then, when their client receives the service ticket, the hackers extract it from memory and attempt to crack it offline.

For service accounts that have old or weak passwords, Kerberoasting is a powerful attack technique. In fact, there are readily available tools that streamline the entire process: Impacket, PowerSploit and Empire automate the process of requesting service tickets and extracting the ticket hashes, while password-cracking tools like John the Ripper and Hashcat can try over a million possible passwords per second, enabling them to brute-force plaintext passwords in fairly short order from vulnerable hashes.

Since in the Kerberos authentication process, DCs don’t track whether users actually connect to a service after requesting a ticket, hackers can request hundreds of tickets to try to crack — without generating any traffic to the target service that might trigger an alert. Plus, the attacker does not need to have administrator credentials to put the attack in motion; compromising a regular user’s credentials is sufficient.

Forged tickets: Golden Ticket and Silver Ticket attacks

Kerberos authentication is built upon the assumption that any TGT encrypted with the KRBTGT password hash is legitimate. Therefore, any attacker who can create forged tickets has virtually unlimited power in the domain — a so-called Golden Ticket.

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, which attackers do all the time using techniques like phishing, spyware, brute force and credential stuffing.

The fourth item is a bit harder to get, but still not all that difficult. I explain them in detail in my Golden Ticket blog post, but they include:

• Stealing the NTDS.DIT file, which stores the password hashes for all users in the domain
• Compromising a workstation and using administrative credential artifacts left there
• Using the open-source tool Mimikatz to gather credential data
• Pretending to be a DC and requesting password hashes from a legitimate DC (a DCSync attack)

With all four pieces of info in hand, a hacker can create a Kerberos ticket to impersonate any AD user they want, including a highly privileged Domain Admin. Moreover, they can make those tickets valid for as long as they want, even if that violates the organization’s time limit policy setting.

There are also Silver Ticket attacks, which are more limited but still can be quite devastating. Using a technique like Kerberoasting, an attacker steals a TGS for a service (such as SharePoint), extracts the hash of the service account and uses that hash to forge additional TGS tickets for that service.

Stolen tickets: Pass-the-ticket (PtT) attacks

In addition to forging tickets, hackers can also steal legitimate TGS or TGT tickets issued to a user by the KDS. With those tickets in hand, they access IT resources as if they were that user — without ever learning the user’s password. One technique is to use a tool like Mimikatz to extract Kerberos tickets from the memory of the LSASS.exe process.

If a hacker compromises a particular user’s account, they can obtain the TGT and all TGS tickets for that user. But an adversary who manages to steal administrative privileges can obtain all TGTs and TGS tickets cached on the system.

Best practices for mitigating your risk

Following IT security best practices can mitigate the risks inherent in Kerberos authentication. Here are the top ones I recommend.

Practice good password hygiene, especially for service accounts.

A great way to mitigate the risk of successful Kerberoasting attacks is to make sure service accounts have long passwords that are changed regularly. A common recommendation is to require passwords to be at least 25 characters long and rotate them every 30 days. Even with modern hardware and password cracking tools, hackers will be hard-pressed to brute-force the passwords before they are changed. To automate the process of establishing complex passwords for Microsoft service accounts and changing them on a regular basis, you can use group managed service accounts (gMSAs); there are also third-party solutions that deliver comprehensive management of all privileged accounts, including service accounts.

However, don’t limit your service account strategy to simply controlling passwords. Instead, institute proper governance: Carefully track what service accounts you have and how they are being used, rigorously enforce the principle of least privilege for all of them, and follow other core best practices for these powerful accounts.

More broadly, follow current NIST guidelines for all passwords in your environment. In particular, note that  password length is much more important for thwarting hackers than password complexity, and that requiring frequent password changes is no longer recommended.

Restrict access to the KRBTGT account password and change it regularly.

The primary defense strategy against Golden Ticket attacks is to enforce the cornerstone security principle: least privilege. By minimizing who and what has access to the KRBTGT password hash, you limit your vulnerability to Golden Ticket attacks. For starters, know exactly which accounts have the rights required to extract password hashes. By default, this includes the builtin\Administrators and builtin\domain controllers group. The account used for Azure AD Connect typically has this power 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 the KRBTGT password hash, investigate immediately and remove any permissions that are not strictly necessary.

Of course, you’ll still have (a limited number of) accounts with access to this critical piece of data, so be sure to change the KRBTGT password regularly. Changing the password won’t prevent hackers from creating Golden Tickets but it will invalidate any that are already in your systems. To avoid authentication errors caused by delayed replication of the new KRBTGT password hash across your environment, I recommend using Microsoft’s KRBTGT account password reset script every 180 days. In addition to these scheduled password rotations, I strongly advise changing the password every time a human who had the ability to create a Golden Ticket leaves the organization (ie. The ability to extract the KRBTGT hash), as well as any time you spot evidence of a Golden Ticket attack.

Warning: Proceed with caution! To avoid serious issues, it’s usually best to reset the KRBTGT password using the script from Microsoft. To force all users to get new TGTs encrypted with the new password hash, you might need to take additional steps. For more details on these issues, reference my Golden Ticket post.

Monitor, analyze and alert on activity across your IT ecosystem

It’s also essential to actively watch for suspicious activity in your environment. In particular, track the activity of all privileged users and service accounts that have Domain Administrative permissions or Replicating Directory Changes ALL permissions. Both of these permissions enable the account to discover objects in AD, which can be used in a DCSync attack to get the KRBTGT hash and create Golden Tickets.

Moreover, clearly record the purpose of each service account. That documentation not only helps you grant privileges in accordance with least privilege; it also helps you spot misuse of the account for other purposes. With a third-party solution, you can even configure alerts to proactively notify you about improper activity, such as a service account being used from a location other than its designated one.

In addition, audit your system for tickets whose TTL value is more than the Kerberos default of 10 hours. Golden Tickets are often set to 10 years.

Have a recovery plan

Even the best prevention and detection strategies can fail, so it’s imperative to create (and regularly test!) an Active Directory recovery plan. Remember, attackers might trash your DCs either as part of their primary objective or simply to obfuscate their tracks, and if your DCs are down, your business is dead in the water.

Having a solid Active Directory disaster recovery strategy isn’t just vital for attacks related to Kerberos. Because Active Directory plays such a critical role in the IT ecosystem, it is the target of many different attacks — including that modern scourge, ransomware, which can take down all of your DCs with blazing speed.

Conclusion

Discontinuing use of NTLM in favor of Kerberos authentication is a proven way to improve the security of your IT environment. Still, all organizations should understand the vulnerabilities in the Kerberos authentication process and take steps to block, detect and recover from attacks involving the protocol.