Skip to main content
Kerberoasting is a technique that obtains a crackable password hash for any AD account carrying a Service Principal Name (SPN), an attribute that ties a service (MSSQL, HTTP, a custom app) to the domain account it runs as. No elevated rights are needed to pull it off, any authenticated domain user, down to the lowest-privileged account, can request a ticket for any SPN in the domain.

​
A Quick Kerberos Refresher

Normal Kerberos authentication is a two-step exchange with the Domain Controller’s KDC (Key Distribution Center):
  1. AS-REQ / AS-REP - the user authenticates once (password/hash/ticket) and gets back a TGT (Ticket Granting Ticket), proof of identity for the rest of the session.
  2. TGS-REQ / TGS-REP - to actually reach a specific service, the user presents the TGT and asks the KDC for a TGS (service ticket) for that service’s SPN. The KDC hands back a TGS, encrypted with a key derived from the service account’s own password, not the requesting user’s.
That TGS is then handed to the service itself, which decrypts it with its own key to confirm the ticket is legitimate and extract the user’s identity/authorization data.

​
Why This Is Exploitable

The critical detail: the KDC issues a TGS to anyone who asks for one, regardless of whether that user actually has any business talking to the service. Authorization is the service’s job, checked when the ticket is presented, not the KDC’s job when the ticket is issued. The KDC’s only check is “does this SPN exist”, not “should this user have it”. That means any domain user can request a TGS for, say, an SQL service account’s SPN, and get back a validly encrypted ticket, with a key derived from that service account’s password, that they were never meant to be able to decrypt. The encrypted blob itself becomes the target to crack: taken offline, there’s no lockout policy, no rate limiting, no logging on every guess, just raw compute against the service account’s password.

​
Finding Vulnerable (Kerberoastable) Accounts

A Kerberoastable account is simply any user object with a non-empty servicePrincipalName attribute. Computer accounts also carry SPNs by default, but their machine account passwords are long, random, and auto-rotated, not practically crackable, so every method below filters specifically for user objects with an SPN, not computers.

​
The Underlying Mechanism: servicePrincipalName

Every tool below is querying for the same thing, a user object where servicePrincipalName is set, one way or another. The raw LDAP filter underneath needs nothing but ldapsearch:

​
PowerView

​
Native AD Module (No PowerView Needed)

​
Impacket (GetUserSPNs.py)

​
Requesting & Harvesting Tickets

Viewing cached tickets
Requesting & exporting tickets
Mimikatz
Rubeus

​
Cracking

How to crack Hashes is fully covered on the Password Cracking page. Use the correct modes while cracking.