I’ve never fully appreciated Kerberos before, so this is my attempt to explain it. To set up the explanation, it’s worth knowing about the players and the keys.
The players
The client
The Key Distribution Centre (KDC), which runs on the Domain Controller. It fulfils two roles:
The Authentication Service (AS)
The Ticket Granting Service (TGS)
The service the client ultimately wants to reach
The keys
Three long-term keys, each derived from an account’s password hash:
#1 the client’s key
#2 the krbtgt account’s key
#3 the service’s key
Two session keys, ephemeral and minted by the KDC for each exchange:
#4 the TGT session key
#5 the TGS session key
Read along and refer back to this diagram:
1. Authentication Service Request (AS-REQ)
Client → Domain Controller
To begin, the client sends its username to the Domain Controller (DC), along with a timestamp encrypted with the hash of the user’s password. The DC retrieves that same hash from the ntds.dit database and uses it to decrypt the timestamp. Successful decryption proves to the DC that the client genuinely holds the user’s password hash, and checking the timestamp against an acceptable window confirms the request is fresh rather than a potentially replayed capture.
2. Authentication Service Response (AS-REP)
Domain Controller → Client
The DC then returns two things to the client:
A session key, encrypted with the user’s password hash.
A Ticket Granting Ticket (TGT) encrypted with the krbtgt account’s NTLM hash, so the client cannot read it. The TGT contains:
the username
the domain
the timestamp
a copy of the session key.
At this point, the KDC considers client authentication complete.
Importantly, note that the session key arrives twice. Once in a form the client can open (sealed with its own hash), and again in a form it cannot open: locked inside the TGT (sealed with the krbtgt hash). The client decrypts the first copy and retains it for the third step. The copy inside the TGT remains sealed and will be forwarded by the client to the DC for later reopening.
3. Ticket Granting Service Request (TGS-REQ)
Client → Domain Controller
This is where the client requests access to a specific resource, such as a share or a mailbox. The TGS-REQ contains:
the username and timestamp, encrypted with the session key obtained in the previous step,
the SPN of the target resource,
the TGT it received from the DC in the previous step, still encrypted with the krbtgt’s key.
The KDC, which holds the krbtgt key, decrypts the TGT, extracts the session key, and uses it to decrypt the username and timestamp from the client. In doing so, it validates that:
the TGT has not expired,
the username in the TGS-REQ matches the username sealed inside the TGT.
4. Ticket Granting Service Response (TGS-REP)
Domain Controller → Client
The DC responds with a new session key for use between the client and the target service, along with a service ticket. As in AS-REP, the key comes in two wrappers:
Bundled with the service name and sealed with the TGT session key (readable only by the client).
Inside the service ticket, sealed with the service account's hash (readable only by the service).
This last detail is the entire basis of Kerberoasting. Because the ticket is sealed with the service account’s hash, anyone able to request a ticket for that SPN can carry it away and attempt to crack it offline.
5. Application Request (AP-REQ)
Client → Application Server
The client uses the TGT session key it received in the AS-REP to decrypt the service name and pull out the new service session key. It then uses that service session key to encrypt its username and timestamp again and sends the result to the target server along with the service ticket (sealed with the service’s hash) that it received in the previous step.
In effect, the client presents two things:
The service ticket containing the TGS session key, encrypted with the service’s key.
A fresh username and timestamp, encrypted with the TGS session key, which the service can obtain by decrypting the service ticket with its own key.
6. Service Authentication
Application Server → Client
The server decrypts the service ticket using its own service account password hash, revealing the username, group memberships, and session key sealed inside. It uses that session key to decrypt the username sent by the client in the AP-REQ, and if the two usernames match, the request is accepted.
Notably, the application server never contacts the DC during this exchange. It trusts the ticket purely because it can decrypt it with its own hash. This is exactly what a Silver Ticket exploits. In a Silver Ticket attack, a service ticket is forged with a stolen service account hash and presented to the application server.
A Golden Ticket works on the same principle but at the next layer up. It is a forged TGT, built with the krbtgt hash. It exploits the fact that the DC will trust any TGT it can decrypt with the krbtgt key.