Kerberoast
Last updated
Was this helpful?
Last updated
Was this helpful?
When asking the KDC (Key Distribution Center) for a Service Ticket (ST), the requesting user needs to send a valid TGT (Ticket Granting Ticket) and the service name (sname) of the service wanted. If the TGT is valid, and if the service exists, the KDC sends the ST to the requesting user.
Multiple formats are accepted for the sname field: servicePrincipalName (SPN), sAMAccountName (SAN), userPrincipalName (UPN), etc. (see ).
The ST is encrypted with the requested service account's NT hash. If an attacker has a valid TGT and knows a service (by its SAN or SPN), he can request a ST for this service and crack it offline later in an attempt to retrieve that service account's password.
In most situations, services accounts are machine accounts, which have very complex, long, and random passwords. But if a service account, with a human-defined password, has a SPN set, attackers can request a ST for this service and attempt to crack it offline. This is Kerberoasting.
For all users
For specific user
The script (Python) can perform all the necessary steps to request a ST for a service given its SPN (or name) and valid domain credentials.
The Kerberoasting attack can be conducted without knowing any SPN of the target account, since a service ticket can be request for as long as the service's SAN (sAMAccountName) is known. ()
Nota bene, Kerberos can deliver service tickets even if the service has no SPN at all, but then the service's SAN must end with $, and in this case it's hard to know for sure if the service's password is defined by a human. Kerberoast attacks usually target user accounts with at least one SPN (servicePrincipalName) since they probably have human-defined passwords (sources: and ).