Kerberos: From 0 to hero

KERBEROS: From 0 to Hero

Kerberos is not only the three headed dog that protect the hell entrance, but also an authentication protocol that uses secret-key cryptography to allow time-limited tickets for accessing network resources and services. This protocol avoids sending passwords across the network. In this post we will explain how the protocol works and some of the most common attacks against it.

Kerberos Components

Kerberos consist of the following necessary components:

Key Distribution Center (KDC):

This logical component resides in the Domain Controllers when referring to a AD environment. It is the responsible to authenticate the users and services within a network and issue the tickets. To do this it has two main components:

• Authentication Server (AS): This service verify the identity of a user or another service when they log in by checking their credentials. If valid, a Ticket-Granting Ticket (TGT) is issued.
• Ticket Granting Server (TGS): This service issues other service tickets using the TGT.

All this is done in the Domain Controller under the service account named krbrtgt. This service account has a password only known by the Domain Controller/KDC.

Client

The Client is the user that request access to a service.

Service Server (SS)

These are the Servers that host a service that require authentication in order to provide access.

Keys

Kerberos uses keys to encrypt tickets that are needed for the protocol. A minimum of 5 keys are used through out the service request.

3 of these keys are Long Term keys that already exist and are stored, in fact, they are the account passwords stored in kerberos hash format. The 2 other keys are Session Keys that are created on the run.

• KDC key (Long Term key): krbtgt service account password NTLM hash
• Client key (Long Term key): Client user account password NTLM hash
• Service key (Long Term key): Service account password NTLM hash.

This Long Term keys must be stored in the KDC (Domain Controller) an in the Kerberos Principals (a principal is a unique identity to which Kerberos can assign tickets) of the corresponding User or Server. This is important because if it exist in both endpoints, it is not needed to send the key across the network.

• Session Key between Client and KDC
• Session Key between Client and the SS

Kerberos workflow

Now that we know the required and necessary components needed for Kerberos authentication, lets dive into the key steps.

1: AS-REQ

This is the first step and is where the client asks to de KDC for the Ticket Granting Ticket. To do this, the client sends the KRB_AS_REQ message to the KDC. This message has (among others):

• A timestamp encrypted with the Client Long Term key (we already mentioned that it is the password hash of the user password). This is only necessary if the user requires preauthentication. If the attribute DONT_REQ_PREAUTH is set, it won’t be necessary.
• The username of the authenticated user
• A nonce

Once the KDC (AS) receives this message, using the un-encrypted part of the requests, it search for the username in its database and retrieves the Client Long Term key corresponding to that user. Since it should be the same and it is a symmetric key, the AS will be able to decrypt the encrypted part of the message. If the timestamp does not match the current time (plus a margin time), the message is ignored since it asumes a replay attack.

2: AS-REP

Now, KDC will build a new message to give a response. This message is the KRB_AS_REP. This message has several contents:

• The Username
• Encrypted data (encrypted with the Client Long Term key) which contains:
  • Session key (this key is a temporal key created with the KDC after the first step).
  • Expiration date of the TGT
  • The user nonce (to prevent reply attacks).
• The Ticket Granting Ticket (TGT). This ticket is encrypted with a key shared between the AS and the TGS (The KDC Long Term Key), so the user can’t see the contents of this ticket:
  • Username
  • Service Session key
  • Expiration date of the TGT
  • PAC (contains the user privileges and other info (SID, groups, etc.))

Once the user receives this message, is able to decrypt the encrypted data and obtain the Session key and the nonce. This will also authenticate the KDC so the user can trust that ticket.

3: TGS-REQ

This message( KRB_TGS_REQ) is sent by the client to the KDC and it contains:

• The TGT that was sent before by the KDC
• Service name
• User authentication encrypted with the Session key. It contains the user ID/user name

The TGS at first checks the service name\ID in the unencrypted message. And then checks whether this service name\ID is present in the current domain or not. 

If so, then TGS (KDC) sends the User the unique service account name related to that service in this domain (also known as SPN or Service Principal Name) so that User can connect to the target server in that specific domain. 

In addition to this, the TGS can can decrypt the TGT because it has the private key.
It then notices Username/ID , User ip address and timestamp present in both of the decrypted packets, and then checks whether they match each other or not. If it matches, then it assumes the User to be legit. This is actually PAC as I mentioned earlier, which is essential for authorization.

4: TGS-REP

When the TGS has done all the checks and validated the KRB_TGS_REQ, it sends the KRB_TGS_REP message that contains:

• Username
• TGS (Encrypted with a key that only the Ticket Granting Server and the service share (The Service Longterm key)):
  • Service session key (A key that will be used between the client and the service)
  • Username
  • Expiration date of TGS
  • PAC
  • Timestamp
• Encrypted data (with the session key)
  • SPN (the service name)
  • Service session key
  • Expiration date of the TGS
  • The user nonce or timestamp.

Like the second step, the user will be able to decrypt de data and retrieve the service session key and the nonce, that will validate the message.

5: AP-REQ

Now that the user has decrypted the encrypted data using the session key, the Service session key can be used to craft the new message, the KRB_AP_REQ, to the service. This message contains:

• The TGS (that the user is not able to decrypt)
• Encrypted data (using the service session key):
  • Username
  • Timestamp
  • PAC

6: AP-REP

Since the service server knows the long-term service key, it can decrypt the TGS and retrieve the service session key. Then, it uses this session key to decrypt the other message that the user sent.

Now the server checks all the info present within those packets. It checks the validity of the timestamp and also validates whether the timestamp values present in both packets match, etc.

If everything looks good, then the service checks its cache to see whether this user’s authenticator is already present in that cache or not; this provides replay attack protection.

Now the server will create a service authenticator packet containing its service name/ID/SPN and timestamp encrypted by the service session key (SKC_S) and sends it to the user.

Kerberos Attacks

Kerberoasting

A Kerberoasting attack occurs when an attacker tries to obtain a password hash related to an account that holds a service (and has an SPN). This type of attack doesn’t rely on any malware, so it is easy for many traditional tools and solutions to detect it.

The attack works like this:

1. The attacker needs an authenticated domain account.
2. Using that account, the attacker requests a Kerberos service ticket.
3. The TGS ticket (given to the user at step 4) is encrypted with the Service Long-Term Key, which is the Service password hash.
4. Now that the attacker has this ticket, they take it offline and attempt to find the password using tools like Hashcat or JohnTheRipper.

Detect kerberoasting

Since this attack doesn’t execute any malware nor exploit a vulnerability and can be executed offline, it is not easy to detect. However, the tools that most attackers use, like Impacket, can be noisy and detected using SIEM tools such as Splunk.

If Audit Kerberos Service Ticket Operations is active in the Domain Controller, event “4769: A Kerberos service ticket (TGS) was requested” will appear each time someone requests a TGS.

It is normal for users to trigger these events since it is expected behavior, but if a single user requests many different TGS in a short period of time, it may imply the use of an automated tool to request TGS and then try to crack them. This situation should raise an alert.

Another way to detect possible Kerberoasting activity relies on the encryption used. Windows’ default encryption algorithm is AES, but some legacy systems only work with RC4, an older and less secure encryption algorithm. Attackers usually specifically request RC4 tickets because they are easier and faster to crack. The best way to avoid this is by disabling RC4 encryption, but if it is needed for compatibility with some services, then you should track if a user is requesting a lot of RC4 encrypted tickets.

How can we detect this? Well, as mentioned before, if we have Audit enabled, every time someone requests a TGS, a Windows event log 4769 gets created:

There is a field named “Ticket Encryption Type” with a Hex value. If this Hex value is 0x17 it implies that the encryption used is RC4.

Silver ticket attack

For a silver ticket attack, the attacker needs to have the NTLM hash of a service account, so we could say that it can be done after performing a successful Kerberoasting attack or obtaining the hashes through other methods.

Once you have the hash of that service account, you can decrypt the ticket and modify the PAC to give you access to that service. The crafted ticket is known as the silver ticket.

However, this will only work for the service associated with the account whose hash has been compromised.

Golden ticket attack

A golden ticket attack works the same as the silver ticket attack; however, the goal here is to craft the TGT instead of the TGS ticket. This means that the hash that has to be cracked is the one from the krbtgt account since it is always that account which encrypts the TGT.

If the attacker is able to get the hash of that account, they can craft any TGT and could, for example, use the Administrator username in the PAC and obtain access to all services.

AS-REP Roasting

This attack focuses on obtaining the passwords from users whose accounts have Kerberos Preauth disabled (DONT_REQUIRE_PREAUTH set). Accounts that have this option enabled don’t need to send the first encrypted message (AS-REQ) to the KDC. This message is encrypted with the user’s password and the KDC, since it also knows the password, checks they are the same and if so, it sends the AS-REP answer, that contains a message also encrypted with the user’s password.

Since this step won’t happen, an attacker could ask for TGTs using different users that have the DONT_REQUIRE_PREAUTH set because the KDC won’t do the check. The attacker will get the TGTs along with the other encrypted data with the user’s password hash and he can crack these password hashes offline.

It is different from Kerberoasting because Kerberoasting focuses on cracking the service account of a TGS while AS-REP Roasting focuses on user accounts.