Kerberos is Active Directory’s authentication mechanism (Authentication! Not Authorization!).
What is Kerberos You Ask?
Kerberos is used in Active Directory. It is responsible for authentication (not authorization). Essentially, it is an authentication protocol (port 88) within the domain.
Agents:
A client or a user who wants to access the service.
AP (Application Server) which offers the service required by the user.
The KDC (Key Distribution Center), the main service of Kerberos, is responsible for issuing tickets. It is installed on the DC (Domain Controller) and is supported by the AS (Authentication Service), which issues the TGT/STs.
Encryption keys:
KDC or KRBTGT key that is derivative from KRBTGT account NT-Hash.
User key which is derivative from user NT-hash.
Service key which is derivative from the NT-hash of the service owner, which can be a user or computer account.
Session key which is negotiated between the user and the KDC. All encryption after obtaining the TGT will be done using the session key instead of the user’s password hash
Service session key which is used between the user and the service.
Tickets:
The TGT (Ticket Granting Ticket) is the ticket presented to the KDC to request for ST (Service Ticket) from the TGS (Ticket Granting Service). It is encrypted with the KDC key.
The ST (Service Ticket) is the service ticket that a user can use to authenticate against a service. It is encrypted with the service 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.
Services can 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 of the PAC are correct.
Furthermore, a client can avoid the inclusion of PAC inside the ticket by specifying it in the KERB-PA-PAC-REQUEST field of the ticket request. Essentially, the PAC includes all the groups and privileges the user has and is responsible for authorization after obtaining the TGT.
Messages:
KRB_AS_REQ: Used to request the TGT from the KDC.
KRB_AS_REP: Used by the KDC to deliver the TGT.
KRB_AP_REQ: Used to authenticate a user against a service, using the ST.
KRB_AP_REP: (Optional) Used by the service to identify itself to the user.
KRB_ERROR: Message to communicate error conditions.
How does it work? (On the “High Level”)
Kerberos authentication is divided into 3 parts:
Request TGT-> Get TGT with Session Key (KDC).
Request ST + Auth → Get Service Ticket + Session Key (KDC).
Request Server + Auth → Get Authentication (Resource Server — MSSQL, WS, CA, and so on).
Technical Overview:
Step 1 — KRB_AS_REQ:
For starters, the user sends a KRB_AS_REQ (Kerberos Authentication Service Request) to the KDC. The request includes the username, and the timestamp (current time). The timestamp is encrypted with the user’s password hash, the service SPN associated with the KRBTGT account, and a nonce generated by the user. That’s how the KDC verifies that the user is legitimate, and not just a replay attack.
Replay Attack (MITM) — A replay attack occurs when an unauthorized user captures network traffic and sends the communication to its original destination, acting as the original sender. To prevent replay attacks, timestamps can be implemented along with sequential numbers. This allows the authentication system to accept only network packets that contain the appropriate timestamp or sequential numbers. If the timestamp is beyond a certain time, the packet is then discarded.
If the KDC receives 2 packets from the same user with the same timestamp, the KDC will then classify this as a replay attack and drop the requests.
Step 2 — KRB_AS_REP:
The KDC takes the packet & the user’s password (from the ntds.dit file) and decrypts the cipher on the packet. If the decryption succeeds and the timestamp is correct (the packet needs to still be relevant — up to 5 minutes max beyond the timestamp’s creation), it will allow the user to continue and the KDC will respond with the TGT that the user has requested. (KRB_AS_REP)
A hacker cannot forge this request because the request is encrypted with the user’s password hash and the current timestamp. Essentially, the packet can only be viewed by the hacker and not modified.
The packet is encrypted with a genuine encryption that is reversed by the KDC.
There is an option in Active Directory to not require Kerberos Pre-Authentication.
User Properties -> Account -> Account Options -> Do Not Require Kerberos Pre-Authentication)
If “Do Not Require Kerberos Pre-Authentication” is enabled — an AS-REPROASTING attack can be performed.
In the KRB_AS_REP packet, we might find the username (to whom the KDC responded), a session key, and the TGT expiration time + user nonce. Of course, it will be encrypted with the password hash (just like before). In the same packet, we will also find the TGT.
The TGT includes the username (to whom the KDC responded), a session key, the TGT’s expiration time, and the PAC. All of this is encrypted with the KRBTGT password hash.
TGT Expiration Time — the timeframe that the TGT ticket is valid for. The default is 10 hours.
If you manage to acquire the KRBTGT hash, you can request tickets (since you are using the KRBTGT account). This is called a “Golden Ticket”.
Similar to cookies, TGTs provide a way to authenticate multiple users (hundreds) without the need to store that information in the server’s memory. It’s packaged on the server side and returned to the client. This mechanism allows users to re-authenticate without storing the information locally in memory. Therefore, a TGT functions similarly to an encrypted cookie.”
Step 3 — KRB_TGS_REQ:
In this step, the client is asking the KDC for a ticket to communicate with another service in the domain. The client is requesting a service ticket encrypted with the service’s password hash so the other service will verify that he is legitimate (by asking for a service ticket, the client provides the SPN of the chosen service).
Inside the Service Ticket request we can find:
The User’s username -> Encrypted with the session key
The Timestamp -> Encrypted with the session key
TGT -> Encrypted with the KRBTGT hash
SPN
User nonce
The KDC decrypts the packet using the session key from the TGT and then validates the timestamp. If everything passes validation — we continue to the next step which is the SPN.
The KDC will check the requested SPN and if this service exists, it will respond with a Service Ticket ticket that will be used later for accessing the service (check service types).
Ticket Service Types
WMI-> HOST, RPCSS
PowerShell Remoting -> HOST, HTTP, WSMAN, RPCSS
WinRM -> HOST, HTTP
Scheduled Tasks-> HOST
Windows File Share (CIFS) -> CIFS
LDAP Operation (Including mimikatz dcsync) -> LDAP
Windows Remote Server Administration Tools -> RPCSS, LDAP, CIFS
Step 4 — KRB_TGS_REP:
The ST is the ticket the client sends to the Application Server (Resource Server) he would like to access. The ST is returned by the KDC (TGS). The ST includes:
Service Session key
User’s Username
TGS Expiration Time
PAC
All that is encrypted by the service owner’s password hash. (Machine Account’s password for example)
If the service owner has a weak password, it is possible to perform a Kerberoasting attack to get the Service Ticket and try to crack it offline to get the user’s clear-text password.
Make sure to always use the FQDN. Otherwise, you will see a ‘1326 error’.
