How to Secure Kerberos Authentication Protocol – 1

In this blog series, we will talk about the details of Kerberos protocol, delegation methods, attack vectors that can be used to exploit these methods, mitigation plans and detection rules against these attacks. In the first post of the series, we will analyze the details of the Kerberos Protocol.

The Kerberos authentication protocol was first developed by MIT and supported by many organizations. It was developed to provide encrypted and secure authentication on an insecure network without sharing a clear-text password. While encrypting the data on the network, the protocol uses the Shared Secret Key method.

By making various customizations in the Kerberos protocol, Microsoft uses this customized protocol by default in Windows Server 2000 and later. Kerberos is used in the Microsoft Active Directory environment to provide authentication during the access of objects (User, Computer) to resources (File Sharing, Remote Desktop Access, etc.).

There are 3 basic elements in the Kerberos protocol.

1. Key Distribution Center: KDC is the main service responsible for the Kerberos protocol. This service runs on Domain Controller servers. It contains information and password hashes of all client and service accounts in the Active Directory environment. These password hashes are used as the Shared Secret Key during the Kerberos protocol.

• • Authentication Service (AS): It is the module in the Key Distribution Center that is responsible for the authentication step. This module authenticates clients by checking information such as whether the client is in the Active Directory domain (Domain), whether the password it provides is correct.
  • Ticket Granting Service (TGS): It is the module that provides the creation, validation, and management of necessary tickets for authenticated clients.
  • KRBTGT: It is the user account that provides the administration of the Key Distribution Center service. This user’s password hash is used to encrypt some tickets.

2. Client: It is the object that initiates the authentication process to access the service. It can be a user account or a machine account. Each user and computer in the Active Directory environment has an account. User accounts are created with the username, while computer accounts are indicated by the machine name and $ sign. Computer accounts have also passwords like user accounts. These passwords are complex passwords that are automatically generated and changed every 30 days. The NT hash of these passwords functions similarly to the user password hashes in the Kerberos protocol.

3. Server: It is the service that the client wants to access at the end of the process. User, computer, MSA (Managed Service Account), GMSA (Group Managed Service Account) objects that manage these services are also called service accounts. Password hashes of service accounts are used to create and authenticate some tickets in the Kerberos authentication protocol.

Whether an object in the Active Directory environment is a service account is determined by the Service Principal Name (SPN) values. These names are unique within the same domain. The SPN value of each service is associated with the account that manages that service and is used during the Kerberos protocol. These SPN values are kept in the ServicePrincipalName attribute of the accounts to which they are assigned. These values can be seen with tools like Active Directory Users and Computers, ADExplorer or Powershell. SPN values can be in different formats as follows.

The SPN values in the Active Directory environment and the accounts that manage these values can be determined with the commands below.

Kerberos AS-REQ Packet

The first step of Kerberos authentication is authenticating the user on the KDC and obtaining the Ticket Granting Ticket (TGT). For this purpose, the client first sends the domain name, username, SPN value of KRBTGT and authentication data (Pre-Authentication Data, PA-DATA) which encrypted with the account’s NT hash to the Authentication Service (AS) module. In other words, in this package, the user, domain name and SPN are transmitted as clear text, and the authentication data is transmitted as encrypted.

AS, firstly reads the domain name and username in this packet from the client and obtains the password hash of this user from the NTDS.dit database and tries to decrypt the Pre-Authentication data with this hash. If this step fails, the password is incorrect and the required error message is sent to the client. If the KDC successfully decrypts the Pre-Authentication data, it checks the timestamp in this data. Authentication is successful if the timestamp is in a specific range. An error message is sent to the client if the timestamp is older than the specified range. This timestamp control prevents attacks (Packet Replay) like reusing packets captured over the network. This time interval is 5 minutes by default and can be managed with Kerberos Policy in Group Policy.

Kerberos AS-REQ Packet

When a successful AS-REQ request is examined with network analysis programs, It is possible to see encrypted data and which algorithm is used while encrypting the Pre-Authentication Data in section 1. In section 2, there is the username and domain information that makes the request, and in section 3, there is krbtgt username and domain information.

With the Powershell script below, accounts that have pre-authentication disabled can be detected.

Option that disables User’s Pre-Authentication Phase

AS-REQ Packet Capture of the User with Pre-Authentication Phase Disabled

When the AS-REQ request for a user with the disabled pre-authentication is examined, it can be seen that there is no Pre-Authentication Data in section 1.

Supported Encryption Types for the Client

When the error message is examined, the encryption algorithms that the client can use during the Kerberos protocol and some data (salt) that can be used for these algorithms can be seen in section 1. Algorithms that can be used in the Kerberos protocol can also be managed with Group Policy and settings to be made on the user object.

1.The attacker, who successfully performs a Man in the Middle, can intercept the victim’s AS-REQ request and perform an offline brute-force attack on the part encrypted with the user password hash in this package. If users’ passwords are simple and the encryption algorithm is relatively weak, attackers can access plain-text passwords. Although this attack method is not very popular, it is called ASREQ-Roasting.

Kerberos AS-REP Packet

The AS module on the KDC sends the Ticket Granting Ticket (TGT) ticket and the Session Key to the client who authenticated with the AS-REQ request. The ticket and the key will be used as evidence in the later stages of the protocol. The AS encrypts a piece of TGT and Session Key data with krbtgt’s NT password hash. It encrypts another piece of Session Key data with the client’s password hash. In this way, the client will not be able to decrypt the part encrypted with the krbtgt password hash but will be able to decrypt the part encrypted with its password hash and use the Session Key value in the further stages.

As a result of this step, the user will have a valid TGT ticket for 10 hours by default. In the next 10 hours, the Kerberos protocol can be operated with the current TGT without the need for AS-REQ and AS-REP stages again. TGT expiration threshold can also be managed with the Group Policy.

Kerberos AS-REP Packet

When the AS-REP message is examined, the encrypted version of the TGT ticket and the algorithm used for encryption can be seen in part 1, and the encrypted part including the Session Key, which the user can decrypt, and the encryption algorithm can be seen in part 2.

1.Attackers can obtain the AS-REP packets of the accounts whose pre-authentication phase is disabled using only the name of the accounts and can perform an offline brute-force attack on the part encrypted with the NT password hash of the user in these packets. If users’ passwords are simple and the encryption algorithm is relatively weak, attackers can access plain-text passwords. This attack method is called ASREP-Roasting.

2.Similar to the ASREP-Roasting attack, a brute-force attack can also be performed offline on the part encrypted with the KRBTGT password hash in the AS-REP message. Although the krbtgt password is defined in a complex way by default and a simple password cannot be defined for this account, it can be cracked in rare scenarios.

3. Even if the attackers intercept the victim’s AS-REP message, they will not be able to obtain the Session Key value and use the TGT because they do not know the password hash of the user. However, if the attackers obtain the TGT ticket from the memory of a server that they compromised, they can still use the TGT ticket even if he does not know the password summary of the user since he can also obtain the Session Key over the memory. With this method, the attacker can access all services that the user can access with this ticket until the ticket expires. This attack method is also called Pass the Ticket.

4. If the attackers can obtain the NT password hash of the krbtgt user, they can create the TGT ticket transmitted in the AS-REP message with very long expiry times for any existing or non-existing user in the domain. In this way, they can create TGT for authorized users and access any service in the domain environment. This attack method is also called Golden Ticket.

Kerberos TGS-REQ Packet

After obtaining the TGT ticket, the client must use this ticket to obtain the required service ticket for the service they want to access. For this purpose, the client sends the TGT ticket obtained in the previous step and the timestamp information encrypted with the Session Key obtained in the previous step to the KDC. KDC decrypts the TGT in the TGS-REQ package using the NT password hash of the krbtgt account and obtains the Session Key value. Then it checks whether the TGT has expired. With the obtained Session Key, it decrypts the other part that was encrypted and verifies the timestamp.

Kerberos TGS-REQ Packet

When the TGS-REQ request created to access the file sharing (CIFS) service on the DC server is examined with Wireshark, it can be seen in section 1 that the TGT ticket obtained in the previous step is sent to the KDC. The cipher data in the enc-part of this ticket is exactly the same as the data in the previous ticket. The data in section 2 consists of the timestamp and some data encrypted with Session Key. This authenticator data also includes checksum information to verify the package. In section 3, there is information about the service to be accessed. The service name is CIFS and the server name is DC.

Kerberos TGS-REP Packet

When the TGS-REQ request sent from the client is confirmed by the KDC, KDC sends the required service ticket and the second Session Key to the client to access the related service. It encrypts the service ticket and Session Key with the NT password hash of the user who manages that service and also encrypts the same Session Key with the previously obtained Session Key. In this way, the client will not be able to decode and read the service ticket. However, he will be able to obtain the second Session Key value by decrypting it with the Session Key transmitted to him before.

As a result of this stage, the user obtains an ST (Service Ticket) ticket valid for 10 hours by default, similar to the AS-REP stage. To access the same service in the next 10 hours, the current ST is sufficient without the need to repeat AS-REQ, AS-REP, TGS-REQ and TGS-REP steps. The ST expiration threshold can also be managed with the help of Group Policy.

Kerberos TGS-REP Packet

When the TGS-REP message is examined with the Wireshark, the encrypted ST (Service Ticket) ticket and the algorithm used for encryption can be seen in section number 1. In section number 2, encrypted second Session Key that the user can decrypt and the encryption algorithm can be seen.

1. Since the Kerberos protocol does not perform the authorization check, all users in the environment can make TGS-REQ requests for all services and obtain the relevant ST ticket for the service. In this way, attackers can take the necessary ST tickets for the services in the environment and perform an offline brute-force attack on the part encrypted with the password hash of the service user in the tickets. If the passwords of the service accounts are simple and the encryption algorithm is relatively weak, attackers can obtain the plain-text password. This attack method is called Kerberoasting.

2. The attacker, who successfully performs a Man in the Middle attack, can capture the TGS-REP message of the victim and perform an offline brute-force attack on the part encrypted with the password hash of the service user in this package. If service users’ passwords are simple and the encryption algorithm is relatively weak, attackers can access plain-text passwords. Although this hacking method is different, the result is the same as a Kerberoasting attack.

3. Even if attackers intercept the victim’s TGS_REP message, they will not be able to obtain the second Session Key value and will not be able to use the ST because they do not know the Session Key value. However, if the attackers dump the TGS ticket from the memory of a compromised server, they can still use the ST ticket even if they do not know the password hash of the user, since they can also obtain the Session Key over the memory. The attackers can access the relevant service in the ticket until this ticket expires. They can also access other services on the target server by changing the service name in the ticket. This attack method is called Pass the Ticket.

4. If the attackers can obtain the NT password hash of the service account, they can create the ST ticket transmitted in the TGS-REP message for any existing or non-existing user in the domain. In this way, they can create ST for authorized users and access the services managed by this service account. This attack method is also called Silver Ticket.

Kerberos AP-REQ Packet

When the clients obtained the required ST for the relevant service, they can access the service with the help of this ticket. The client sends the ST encrypted with the password hash of the service account and the timestamp encrypted with the second Session key value to the server where the service is running. The service decrypts the first piece as it is encrypted with its password hash and checks the information in it. In addition, using the Session Key value in this part, the service decrypts the second part and makes the necessary verifications. After this stage, the service will check whether the user is authorized to access the service and return the relevant response to the client.

Kerberos AP-REQ Packet

When the AP-REQ request is examined with Wireshark, it is seen that there is the ST ticket obtained in the TGS-REP stage in the first part. All data in enc-part is the same as the data received in the previous packet. In the second part, there is the verification data containing the timestamp encrypted with the second Session Key.

1. The attacker, who successfully performs a Man in the Middle attack, can capture the AP-REQ message of the victim and perform an offline brute-force attack on the part encrypted with the password hash of the service user in this packet. If service users’ passwords are simple and the encryption algorithm is relatively weak, attackers can obtain plaintext passwords. This attack is also the same as the Kerberoasting attack, although the hijacking method is different.

At this stage, the server returns to the client about the authentication and authorization result. This response includes the encrypted timestamp with the second Session Key, sequence number and other relevant data. This step is not mandatory to complete the Kerberos authentication.

Kerberos AP-REP Packet

When the AP-REP package is examined, the encrypted part and used encryption algorithm can be seen.

In this blog post, we talked about the Kerberos protocol steps and the attack methods that can be performed at each phase. In our next article, we will examine the Kerberos Protocol in detail and go about ticket types, PAC verification and Kerberos steps between domains and forests. In further stages, we will analyze the delegation methods, Kerberos steps during the use of delegation, and all Kerberos-related attack methods from the perspective of exploitation, prevention and detection.

• https://web.mit.edu/kerberos/
• https://datatracker.ietf.org/doc/html/rfc4120
• https://www.secureauth.com/blog/kerberos-delegation-spns-and-more/
• https://www.tarlogic.com/en/blog/how-kerberos-works/
• https://improsec.com/tech-blog/asreqroast-from-mitm-to-hash