MITRE ATT&CK - Kerberos Vulnerabilities and Security

From the previous post, the summary of Kerberos authentication process is as below:

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.)

Vulnerabilities = The protocol is vulnerable to Kerberoasting, Golden Ticket and Silver ticket attacks, and pass-the-ticket attacks.

Kerberoasting

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. Tools like 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.

Golden Ticket and Silver Ticket Attacks

Kerberos authenticaiton 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:

FQDN of the domain

SID of the domain (Security Identifier)

Username of the account they want to impersonate

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.