Last week, I was solving the TryHackMe room on kerberos attacks and techniques. I was unable to understand the underlying concepts. I was not getting the actual technique and mechanism of how those tools like rubeus, impacket are working and how they are enumerating users, how mimikatz in performing golden ticket attacks. Then I understood, all this question has only one solution, that is, knowing the underlying ruling concept, i.e. Kerberos. So today, I will deep dive into the realm of windows active directory (AD) to demonstrate kerberos and share my knowledge upon it. So let’s jump right in.

Some brief background upon kerberos and other windows authentication protocols:

If you have done hash cracking of windows user’s passwords, a special type of hash always used to pop up, named NTLM hash (New technology LAN Manager). For older windows versions before Windows 2000, NTLM used to be the default authentication protocol. 

NTLM is actually a challenge-response authentication protocol which occurs in the form of handshake between Server and client to authenticate Users. NTLM mostly relies on password hashing and uses it in the authentication process. But soon, NTLM faced several questions regarding the integrity of user passwords. Many security vulnerability related password hashing and salting was discovered. All this happened  ‘cause NTLM user passwords that are stored on servers and DCs (Domain Controllers) are not salted. That means we can easily crack those password hashes, using Open source password brute forcing tools.

For that reason, Microsoft made Kerberos the default authentication protocol on Windows. Although, NTLM is still present to serve as a backup, if in some way kerberos authentication fails to authenticate the user.

So, Why was kerberos promoted to a default position as an authentication protocol ?

This is because its working principle is totally different from that of NTLM. Kerberos is also an authentication protocol just like NTLM. Kerberos is not only used in active directory but also in many other areas like in posix authentication, nfs and samba.

It can also be used as an alternative authentication mechanism to ssh, POP, SMTP, IMAP, etc. Although it is also vulnerable to certain attacks, like kerberoasting, AS-REP roasting, etc.

Kerberos Components and basics:

1. Architectures:

There are 3 security architectural components present in the Kerberos authentication process:

1. A Client who is seeking for connection
2. A Server that Client wants to connect
3. Kerberos Key Distribution Centre or KDC (Authentication Server (AS) and Ticket Granting Server (TS) ).

NOTE:

KDC is available in Active Directory domain environments in the form of a service account named krbtgt (Kerberos Key Distribution Centre Service Account). This is also sometimes called the trusted third party in the AD domain. This service account does have a password, which no one knows except the Domain Controller or KDC. This password has a lot to do in the process of kerberos.

2. Keys:

All these 3 architectures use / exchange a minimum of  5 keys in the process of authentication. And all of these 5 keys are symmetric in nature.

Among those 5 keys, there are 3 long Term or LT keys and remaining 2 session keys.

1. Long Term keys:

1. KDC Long Term secret key (KD LT key)

2. Client Long Term secret key (Client LT key)

3. Service Long Term Secret key (Service LT key)

NOTE:

Long Term key is actually the account password in kerberos hash format.

KDC LT key → krbtgt service account password hash

Client LT key → Client user account password hash

Service LT key → Service account password hash

2. Session Keys:

1. Session key between KDC’s TGS and Client

2. Session key between Client and Target Server/ Service

3. To be kept in mind, each and every symmetric key used here ( in this case, 5) must be present in two places minimum.

1. On KDC
2. With the other Kerberos Principals, i.e. either a User or Server.

4. All of these key sharing is done to accomplish only one thing, refraining the share of password in plain text over the network

We can see from the above image, DC has all the 3 Long Term keys already stored.

But session keys are not shown here as to show that you have to know the 6 steps of kerberos authentication process first. Session keys are created on the run, that is, during the running process. So when I deep dive into each step of kerberos, and explain about session keys, you will understand ok ??

Let’s go step by step:

Step1: AS-REQ 

We can see that Client C requests an authentication ticket or Ticket Granting Ticket (TGT)  along with it’s username and ip address and other important infos along with a Timestamp of that particular moment, which is encrypted by Client user account LT key as denoted by Kc. Well I will explain what TGT is, please be patient Kiddo!! 

After getting the request, the AS will see the 1st unencrypted request related to user infos. And check whether the username is present in the KDC database or not. If the result of validation is positive, then it will open the encrypted portion of the request with the user LT key (Kc), which KDC already has in their database.

NOTE:

If after opening the encrypted request portion, the Timestamp present within it doesn’t match with the present time or time difference becomes much larger as compared to present time (more or less than two minutes), then the AS will automatically abundan that request assuming it as a replay attack. 

Step2: AS-REP

So when, AS finds everything related to the AS-REQ is legit, it soon crafts two packets, both holding a session key between Client C and TGS ( SKC TGS) within them. 

1. One packet is encrypted with user LT key (Kc), so that client can decrypt it to get the session key ( SKC TGS) so that it can continue interacting with TGS without getting authenticated again and again by AS (ofc. it works only for the lifetime of the session key). It also contains the same Timestamp value as we sent it earlier in Step1, lifespan (same as TGT as TGT will be valid as long as SKC TGS, after that they again have to reauthenticate ) and the TGS Name/ID.

Normally the lifespan of both SKC TGS and TGT  is eight to ten hours depending on the AD configuration.

2. The other packet is actually the TGT, ticket for krbtgt service. Well it is pretty much self-explanatory, it is used to get more tickets in future from TGS in krbtgt service (or KDC). This ticket contains user necessary information like user Group membership, SID, so that this user does not get any extra privilege after getting connected to the target server. This important information is denoted by PAC (Privileged Attribute Certificate) in the above image. It also contains Lifespan, Timestamp, Username/ID and TGS name/ID within it.

TGT is actually encrypted by KDC LT key (K krb),  so that it can be opened by none other than TGS itself, as it only has the K krb key to decrypt it.

The first two steps in kerberos authentication acts as an authentication mechanism for the users that want to login to the AD environment and PAC performs authorization of the user in the AD. 

Step3: TGS-REQ

So now, User got 2 response packets. The 1st one which is encrypted by the User’s own password hash is decrypted by it, to get the TGS session key SKC TGS. The user keeps SKC TGS  and the other packet (as it does not have the krbtgt hash password to decrypt it) in the Kerberos Tray the user has.

As now users know the TGS server name/ID, it can send TGS-REQ messages to TGS within KDC.

In this step, User send 3 packages:

1. TGT, as it got in the AS-REP message encrypted by krbtgt account password

2. Sends the Service name, User wants to connect to, in an unencrypted format

3. Lastly, sends the User authenticator (which contains user’s name/ID) encrypted by session key SKC TGS.

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. 

(As KDC is present in the DC, it knows about everything  related to users and accounts in that domain.) 

If so, then TGS 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. 

For example: 

If service name is: MSSQL , the domain name is: reveng.local , name of domain controller: DC1 and port number on which domain controller is active: 60111

SPN:  DC1/SQLService.reveng.local:60111

NOTE: There are many ways of constructing SPN, I’m not gonna cover that here.

Then the TGS decrypts the TGT by using Kkrb(krbtgt password hashkey), to get the TGS session key (SKC TGS) within it. Now TGS can decrypt the 3rd encrypted packet using the TGS session key (SKC TGS). 

Now TGS starts to check what is present within those two packets which were previously encrypted.

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

• Then TGS stores the retrieved TGS session key (SKC TGS) and user attributes in its cache, for further use of it in the future. This also acts as a mitigation technique against replay attack. If in some way, TGS gets a user ticket with username same as the one present in the TGS cache, it will not provide further response to that user, assuming it as an illegitimate user causing replay attack. 

Step4: TGS-REP

Now when TGS finds everything as legit, it crafts two message packets, both of them containing a crafted Service Session key ( SKC S) :

1. One packet contains the Service name in the form of SPN , its lifetime and Timestamp (same as the one sent by User, back in AS-REQ step) along with the Service Session key ( SKC S) between User and Service, encrypted by TGS session key (SKC TGS), so that User can decrypt it to get the Service session key ( SKC S) to talk to its target Service.

2. Another packet is actually the Service Ticket containing PAC informations of User, essential for authorization of user , lifetime of Service Ticket along with Service Session key ( SKC S), encrypted by Service LT key (Ks), which only the Service knows. 

Step5: AP-REQ

In the Step4, the User got 2 packets: 

1. One contains Service Ticket encrypted by Service LT key (Ks)
2. Other contains Service Session key ( SKC S) encrypted by the User’s LT Key (Kc). User decrypts it to get the Service Session key ( SKC S).

So, now User crafts one and only packet to send to Target Server along with the Service Ticket.

1. User sends the same Service Ticket that it got in the previous step from TGS, to Target Server.
2. User then crafts another User authenticator packet which contains user’s name/ID and other infos (i.e. PAC) encrypted by Service Session key ( SKC S) and then sends it to the Target Server.

Step6: AP-REP

1. Target Server then gets the two encrypted packets. Decrypts the Service Ticket with it’s password LT key (Ks) to get the Service Session key ( SKC S).
2. Then with this Service Session key ( SKC S), it decrypts the 2nd User authenticator packet to get the User infos. 

Now the Server checks all the infos present within those packets. Checks the validity of the timestamp and also validates whether those timestamp values present in both the packets matches or not, etc.

If everything looks good, then Service checks it’s cache to see whether this User’s authenticator is already present in that cache or not, this again provides replay attack protection. 

As these tickets are everywhere in Kerberos authentication process, in each and every step, replay attack protection is maintained. 

Anyways, if Service cache doesn’t have the User’s info then the Service will add the User’s authenticator to log the incident.

Now the Server will create a Service authenticator packet containing it’s Service Name/ ID/ SPN and Timestamp encrypted by Service Session key ( SKC S) and sends it to User.

Then the User can decrypt the packet using Service Session key ( SKC S), it has in its kerberos tray. After decrypting, if the User found the server name to be the same as the name of the Server it wants to connect to, then this Kerberos mutual Authentication Process becomes successful !! 🎉

Now, Some important things to be noticed.

In the above image we can see the kerberos tray contains 5 Things:

1. User’s LT key
2. Service Ticket
3. TGT
4. Session key between User and Target Service 
5. Session key between User and TGS

Each and every thing will be reused in the near future.

1. User’s LT key

It is used everywhere in the kerberos authentication process.

2. Service Ticket and 4. Session key between User and Target Service

Service Session Key is kept so that User can interact to Server.

Service Ticket is kept ‘cause if for some reason, User needs to authenticate to Server, it can re-authenticate to Server using this Service Ticket (ofc. Within the lifespan of the Service Ticket as well as the Service Session key).

5. Session key between User and TGS and  3. TGT

When the Service Ticket expires, Users again have to make one Service Ticket. Then it will need a Session key between User and TGS, and TGT to get a new Service Ticket from TGS for the same server. 

Session Key between User and TGS, and  TGT will also be needed if User wants to connect to another Server(say server2), then User needs to talk to TGS to get another Service Ticket and Service Session Key, but for this case, the service Ticket is for the new Server the User wants to connect to.

Then the number of Keys will be increased from 5 to 7 (Service Session key and Service LT key of server2). For this reason earlier in this blog, under the Keys portion of the Kerberos Components and basics heading, I used the word minimum. The more number of server, User wants to connect to, the more will be the number of keys involved in this Kerberos authentication process.

Another thing to be kept in mind, that after every kerberos authentication process completion, whether it involved minimum of 5 symmetric key or any other massive number of keys, One thing is always CONSTANT, all the kerberos principal (i.e. Users, servers and KDC), have more than one symmetric key in their cache or kerberos tray. 

So that’s what kerberos is all about. Though, this is actually a high level overview of Kerberos authentication. If you are a deep packet analyst type nerd when it comes to networking, then I would recommend seeing this awesome blog by Robert Broeckelmann . In this blog, he has done wireshark packet capture of each and every step of kerberos authentication. 

If you have any queries, suggestions or any criticism about this blog, you can reach out to me on twitter, I would love to interact with you. 

Until then, Bye 👋.

Soumyanil Biswas

HackHouse.net author