Basic introduction

Kerberos is a computer network security protocol that authenticates service requests between two or more trusted hosts across an untrusted network, like the internet. It uses secret-key cryptography and a trusted third party for authenticating client-server applications and verifying users’ identities.

How it works

Let’s take a more detailed look at what Kerberos authentication is and how it works by breaking it down into its core components.

Here are the principal entities involved in the typical Kerberos workflow:

• Client. The client acts on behalf of the user and initiates communication for a service request
• Server. The server hosts the service the user wants to access
• Authentication Server (AS). The AS performs the desired client authentication. If the authentication happens successfully, the AS issues the client a ticket called TGT (Ticket Granting Ticket). This ticket assures the other servers that the client is authenticated
• Key Distribution Center (KDC). In a Kerberos environment, the authentication server logically separated into three parts: A database (db), the Authentication Server (AS), and the Ticket Granting Server (TGS). These three parts, in turn, exist in a single server called the Key Distribution Center
• Ticket Granting Server (TGS). The TGS is an application server that issues service tickets as a service

Now let’s break down the protocol flow.

First, there are three crucial secret keys involved in the Kerberos flow. There are unique secret keys for the client/user, the TGS, and the server shared with the AS.

• Client/user. Hash derived from the user’s password
• TGS secret key. Hash of the password employed in determining the TGS
• Server secret key. Hash of the password used to determine the server providing the service.

The protocol flow consists of the following steps:

Step 1: Initial client authentication request. The user asks for a Ticket Granting Ticket (TGT) from the authentication server (AS). This request includes the client ID.

Step 2: KDC verifies the client’s credentials. The AS checks the database for the client and TGS’s availability. If the AS finds both values, it generates a client/user secret key, employing the user’s password hash.

The AS then computes the TGS secret key and creates a session key (SK1) encrypted by the client/user secret key. The AS then generates a TGT containing the client ID, client network address, timestamp, lifetime, and SK1. The TGS secret key then encrypts the ticket.

Step 3: The client decrypts the message. The client uses the client/user secret key to decrypt the message and extract the SK1 and TGT, generating the authenticator that validates the client’s TGS.

Step 4: The client uses TGT to request access. The client requests a ticket from the server offering the service by sending the extracted TGT and the created authenticator to TGS.

Step 5: The KDC creates a ticket for the file server. The TGS then uses the TGS secret key to decrypt the TGT received from the client and extracts the SK1. The TGS decrypts the authenticator and checks to see if it matches the client ID and client network address. The TGS also uses the extracted timestamp to make sure the TGT hasn’t expired.

If the process conducts all the checks successfully, then the KDC generates a service session key (SK2) that is shared between the client and the target server.

Finally, the KDC creates a service ticket that includes the client id, client network address, timestamp, and SK2. This ticket is then encrypted with the server’s secret key obtained from the db. The client receives a message containing the service ticket and the SK2, all encrypted with SK1.

Step 6: The client uses the file ticket to authenticate. The client decrypts the message using SK1 and extracts SK2. This process generates a new authenticator containing the client network address, client ID, and timestamp, encrypted with SK2, and sends it and the service ticket to the target server.

Step 7: The target server receives decryption and authentication.  The target server uses the server’s secret key to decrypt the service ticket and extract the SK2. The server uses SK2 to decrypt the authenticator, performing checks to make sure the client ID and client network address from the authenticator and the service ticket match. The server also checks the service ticket to see if it’s expired.

Once the checks are met, the target server sends the client a message verifying that the client and the server have authenticated each other. The user can now engage in a secure session.

 

Exploitation

So what is wrong with the Kerberos authentication problem

In a lay man terms, we can use multiple exploits against the Kerberos system by affecting either exploiting TGS tickets, pre-authentication system or some other factors too.

Let’s see one method

Kerberoast

The goal of Kerberoasting is to harvest TGS tickets for services that run on behalf of user accounts in the AD, not computer accounts.

Thus, part of these TGS tickets are encrypted with keys derived from user passwords. As a consequence, their credentials could be cracked offline.
You can know that a user account is being used as a service because the property “ServicePrincipalName” is not null.
Therefore, to perform Kerberoasting, only a domain account that can request for TGSs is necessary, which is anyone since no special privileges are required.
You need valid credentials inside the domain.

Let’s see some ways to get the hashes and how to crack them

Enumeration and getting hashes

msf> use auxiliary/gather/get_user_spns
GetUserSPNs.py -request -dc-ip 192.168.2.160 <DOMAIN.FULL>/<USERNAME> -outputfile hashes.kerberoast # Password will be prompted
GetUserSPNs.py -request -dc-ip 192.168.2.160 -hashes <LMHASH>:<NTHASH> <DOMAIN>/<USERNAME> -outputfile hashes.kerberoast

Cracking the hashes

john –format=krb5tgs –wordlist=passwords_kerb.txt hashes.kerberoast
hashcat -m 13100 –force -a 0 hashes.kerberoast passwords_kerb.txt

 

Mitigation process

• Service Account Passwords should be hard to guess (greater than 25 characters)
• Use Managed Service Accounts (Automatic change of password periodically and delegated SPN Management)