Kerberos is an authentication protocol based on tickets. It basically works like this (simplified process):
  1. 1.
    Client asks the KDC (Key Distribution Center, usually is a domain controller) for a TGT (Ticket Granting Ticket). One of the requesting user's keys is used for pre-authentication. The TGT is provided by the Authentication Service (AS). The client request is called AS-REQ, the answer is called AS-REP.
  2. 2.
    Client uses the TGT to ask the KDC for a ST (Service Ticket). That ticket is provided by the Ticket Granting Service (TGS). The client request is called TGS-REQ, the answer is called TGS-REP.
  3. 3.
    Client uses the ST (Service Ticket) to access a service. The client request to the service is called AP-REQ, the service answer is called AP-REP.
  4. 4.
    Both tickets (TGT and ST) usually contain an encrypted PAC (Privilege Authentication Certificate), a set of information that the target service will read to decide if the authentication user can access the service or not (user ID, group memberships and so on).
A Service Ticket (ST) allows access to a specific service. The TGT is used to ask for STs. TGTs can be obtained when supplying a valid secret key. That key can be one of the following (read more).
Key name (a.k.a. etype)
Details on key calculation
Key derivated from user's password
Key == NT hash
Key derivated from user's password (with salt)
Key derivated from user's password (with salt)
By default, the salt is always
  • For users: uppercase FQDN + case sensitive username = DOMAIN.LOCALuser
  • For computers: uppercase FQDN + host + lowercase FQDN hostname without the trailing $ = DOMAIN.LOCALhostcomputer.domain.local
Again, Microsoft has poorly implemented the zero-knowledge proof concept in Kerberos. An attacker knowing a user's NT hash could use it to ask the KDC for a TGT (if RC4 key is accepted). This is called Overpass-the-hash.
Users are not the only ones whose NT hashes can be used to abuse Kerberos.
  • A TGT is encrypted with the krbtgt's NT hash. An attacker knowing the krbtgt's NT hash can forge TGTs impersonating a domain admin. He can then request STs as a domain admin for any service. The attacker would have access to everything. This forged TGT is called a Golden ticket.
  • A ST is encrypted with the service account's NT hash. An attacker knowing a service account's NT hash can use it to forge a Service ticket and obtain access to that service. This forged Service ticket is called a Silver ticket.
​Overpass-the-hash, silver ticket and golden ticket attacks are used by attackers to obtain illegitimate tickets that can then be used to access services using Kerberos without knowing any password. This is called Pass-the-ticket.


If Kerberos preauthentication is disabled for a user, it is possible to request a TGT for that specific user without knowing any credentials. When the TGT is requested, the KDC sends it along with a session key in the KRB_AS_REP message to the requesting client. The session key being encrypted with the requested user's NT hash, it is possible to crack that session key offline in a an attempt to find the user's password. This is called ASREProasting.
If an attacker finds himself in a man-in-the-middle position, effectively capturing Kerberos messages, he could capture KRB_AS_REQ messages and operate a similar cracking attempt.
When attackers have a foothold in the domain (i.e. valid domain credentials), they have the (intended) ability to request a service ticket (ST) for any valid SPN (ServicePrincipalName). The ST being encrypted with the service account's NT hash, when that service account's password is weak, it is then possible to crack the ST offline in a an attempt to find the password. This is called Kerberoasting.
As it turns out, AS-REQ messages can not only be used to request TGTs but can be invoked to ask for Service Tickets as well. One of the consequences of this is that Kerberoast can be conducted without prior foothold to the domain if the attacker knows the service to target (its SPN or name) as well as an ASREProastable username: without-pre-authentication.


Kerberos delegations allow services to access other services on behalf of domain users. For instance, this allows services to require access to other services' data on the authenticated user's behalf in order to pull data that only the said user is supposed to have access to.
In some situations, Kerberos delegations can be abused by attackers to operate lateral movement or privilege escalation.
In some cases, the delegation will not work. Depending on the context, the bronze bit vulnerability (CVE-2020-17049) can be used to try to bypass restrictions.

Service-for-User extensions

Kerberos delegations can be abused by attackers to obtain access to valuable assets and sometimes even escalate to domain admin privileges. Regarding constrained delegations and rbcd, those types of delegation rely on Kerberos extensions called S4U2Self and S4U2Proxy.
  • Service for User to Self (S4U2self): allows a service to obtain a Service Ticket, on behalf of another user (called "principal"), to itself.
S4U2self requirements
  • Service for User to Proxy (S4U2proxy): allows a service to obtain a Service Ticket, on behalf of a user to a different service.
S4U2proxy requirements
More technical notes

User-to-User authentication

U2U has nothing to do with S4U mechanisms and plays no part in delegation internals.
[U2U] allows users to host secure application services on their desktop machines. [...] In the user-to-user protocol, one user acts as a server, and the other user acts as a client. (Frequently Asked Questions about Kerberos).
More technical notes
S4U2self + U2U
Copy link
On this page
Service-for-User extensions
User-to-User authentication