Hey, guys! How y’all doing?
Today, we’re going to detour and venture a little on Kerberos protocol and the attacks that are happening against this protocol recently. Since there’s a lot to be covered on the basics of Keberos alone, I’ve decided to split up the write-up in 2 parts - Basics & Attacks.
This piece is all about Kerberos basics so, let’s go!
What is Kerberos?
Firstly, Kerberos is a network authentication protocol, not authorization. In other words, it allows for the identification of individual users, who provide a secret password. However, it does not validate which resources or services authenticated users can access. This protocol is designed to provide strong authentication for client/server applications by using secret-key cryptography.
Kerberos is used in Active Directory (AD). In AD, Kerberos provides information about the privileges of each user, but it is the responsibility of each service to determine if the user has access to its resources.
Before we go into the technicalities of how Kerberos functions, let’s understand all the components of the Kerberos environment first.
Kerberos Components
Transport layer
Kerberos uses either UDP or TCP as its transport protocol, which sends data in clear-text. Due to this, Kerberos is responsible for providing encryption.
Ports used by Kerberos are UDP/88 and TCP/88, which should be listened to in KDC (explained in the next section).
Agents
Several agents work together to provide authentication in Kerberos. They are as follows:
- Client or user who wants to access the service.
- AP (Application Server) which offers the service required by the user.
- KDC (Key Distribution Center), the main service of Kerberos, responsible for issuing the tickets, installed on the DC (Domain Controller). It is supported by the AS (Authentication Service), which issues the TGTs.
Encryption keys
There are several structures handled by Kerberos, such as tickets. Many of those structures are encrypted or signed in order to prevent being tampered by third parties. Those keys are as follows:
- KDC or krbtgt key which is derived from the krbtgt account NTLM hash.
- User key which is derived from user NTLM hash.
- Service key which is derived from the NTLM hash of the service owner, which can be a user or computer account.
- Session key which is negotiated between the user and KDC.
- Service session key to be used between user and service.
Tickets
The main structures handled by Kerberos are the tickets. These tickets are delivered to the users in order to be used by them to perform several actions in the Kerberos realm. There are 2 types of tickets:
- The TGS (Ticket Granting Service) is the ticket which a user can use to authenticate against a service. It is encrypted with the service key.
- The TGT (Ticket Granting Ticket) is the ticket presented to the KDC to request for TGSs. It is encrypted with the KDC key.
PAC
The PAC (Privilege Attribute Certificate) is a structure included in almost every ticket. This structure contains the privileges of the user and it is signed with the KDC key.
It is possible for services to verify the PAC by communicating with the KDC, although this does not happen often. Nevertheless, PAC verification consists of checking only its signature, without inspecting if privileges inside the PAC are correct.
Furthermore, a client can avoid the inclusion of the PAC inside the ticket by specifying it in the KERB-PA-PAC-REQUEST field of the ticket request.
Messages
Kerberos uses different kinds of messages. The most interesting are as follows:
- KRB_AS_REQ: Used to request the TGT to KDC
- KRB_AS_REP: Used to deliver the TGT by KDC
- KRB_TGS_REQ: Used to request the TGS to KDC, using the TGT
- KRB_TGS_REP: Used to deliver the TGS by KDC
- KRB_AP_REQ: Used to authenticate a user against a service, using the TGS
- KRB_AP_REP: (Optional) Used by service to identify itself against the user
- KRB_ERROR: Message to communicate error conditions
Additionally, even if it is not part of Kerberos, but NRPC, the AP optionally could use the KERB_VERIFY_PAC_REQUEST message to send to KDC the signature of the PAC, and verify if it is correct.
How does Kerberos work?
To understand the Kerberos attack, you must know the authentication flow with the domain controller (aka KDC) for better understanding and visibility for faster incident response.
Let’s have a look at the whole flow of Kerberos authentication messages first.
Now, let’s go step-by-step.
[1] KRB_AS_REQ
Firstly, a user must get a TGT from KDC. To achieve this, a KRB_AS_REQ is sent.
KRB_AS_REQ has, among others, the following fields:
- A encrypted timestamp with client key, to authenticate user and prevent replay attacks
- Username of authenticated user
- The service SPN associated with krbtgt account
- A Nonce generated by the user
Note: The encrypted timestamp is only necessary if the user requires preauthentication, which is common, except if DONT_REQ_PREAUTH flag is set in the user account.
[2] KRB_AS_REP
After receiving the request, the KDC verifies the user identity by decrypting the timestamp. If the message is correct, then it responds with a KRB_AS_REP.
KRB_AS_REP includes this information:
- Username
- TGT, which includes:
- Username
- Session key
- Expiration date of TGT
- PAC with user privileges, signed by KDC
- Some encrypted data with user key, which includes:
- Session key
- Expiration date of TGT
- User nonce, to prevent replay attacks
Once finished, the user will already have the TGT, which can be used to request TGSs, and access services.
[3] KRB_TGS_REQ
In order to request a TGS, a KRB_TGS_REQ message is sent to KDC.
KRB_TGS_REQ includes:
- Encrypted data with session key:
- TGT
[4] KRB_TGS_REP
After receiving the KRB_TGS_REQ message, the KDC returns a TGS inside of KRB_TGS_REP.
KRB_TGS_REP includes:
- Username
- TGS, which contains:
- Service session key
- Username
- Expiration date of TGS
- PAC with user privileges, signed by KDC
- Encrypted data with session key:
- Service session key
- Expiration date of TGS
- User nonce, to prevent replay attacks
[5] KRB_AP_REQ
At last, if everything went well, the user already has a valid TGS to interact with the service. In order to use it, the user has to send a KRB_AP_REQ message to the AP.
KRB_AP_REQ includes:
- TGS
- Encrypted data with service session key:
- Username
- Timestamp, to avoid replay attacks
After that, if user privileges are correct and valid, this user can access the service. If this is the case, which does not usually happen, the AP will verify the PAC against the KDC. Besides, if mutual authentication is needed, it will respond to the user with a KRB_AP_REP message.
And, that’s a wrap! That’s it for today, guys. We’ve covered the basics of Kerberos. I’ll meet you in the next write-up with Kerberos-related attacks.
Until next time, friends!
Credits: Tarlogic & SOCInvestigation