Kerberoasting is one of the highest-value techniques you can learn for internal Active Directory assessments. It turns any single authenticated domain account, even an unprivileged one, into a shot at cracking the passwords of service accounts, which are often the accounts with the most access. The attack is quiet, it runs entirely with normal domain traffic, and the cracking happens offline where no defender can see it.
This guide walks through the whole chain: how the Kerberos design makes the attack possible, how to find targets, how to request the tickets, and how to crack them. We will also cover what this looks like from the defender's side, because you should understand what you are triggering before you run it on a real engagement.
How Kerberos Hands You the Material
When a user logs into a domain, the Key Distribution Center (KDC, which runs on the domain controller) issues them a Ticket Granting Ticket (TGT). To access a network service later, the user presents that TGT and asks for a service ticket, formally a Ticket Granting Service (TGS) ticket, for the specific service they want to reach.
Here is the part that matters. That service ticket is encrypted with the password hash of the account that runs the service. The KDC does not check whether you are actually allowed to use the service before it hands over the ticket. It only checks that you have a valid TGT. So any authenticated user can request a service ticket for any service in the domain, and receive a blob encrypted with that service account's key.
If we can request the ticket, take the encrypted portion offline, and guess the password that decrypts it, we recover the service account's plaintext credentials. That is Kerberoasting in one sentence.
Why Service Accounts Are the Weak Link
A service is tied to an account through a Service Principal Name (SPN), an identifier like MSSQLSvc/db01.corp.local:1433. Only accounts that have an SPN registered can be Kerberoasted, and in practice those are the service accounts: SQL Server, IIS application pools, custom line-of-business services, and so on.
These accounts have three properties that make them worth attacking:
- Their passwords are frequently set by a human, once, years ago, and never rotated because rotating them means restarting production services.
- They are often members of privileged groups because whoever set them up wanted the service to "just work."
- Nobody is watching them the way they watch the domain admins.
A service account with a weak password and Domain Admin rights is not rare. That is the prize.
Step 1: Find the Kerberoastable Accounts
You need any valid domain account to start. From a Windows box that is domain-joined, the built-in tool works:
setspn -T corp.local -Q */*
That lists every SPN in the domain. For a cleaner view of which user accounts (not computer accounts) carry SPNs, PowerView is the standard choice:
Get-DomainUser -SPN | select samaccountname,serviceprincipalname
[Screenshot: PowerView output listing three service accounts with their registered SPNs, including a svc_sql account]
From Linux, Impacket's GetUserSPNs.py does the same enumeration with just domain credentials, no domain-joined machine required:
GetUserSPNs.py corp.local/lowpriv:'Password123' -dc-ip 10.10.10.5
Why this matters: you are building a target list. Computer accounts also have SPNs, but their passwords are 120-character machine-managed strings that you will never crack, so ignore them. Focus on user service accounts.
Step 2: Request the Service Tickets
Now request the tickets for those accounts and dump them in a crackable format. Impacket does both enumeration and extraction in one command with the -request flag:
GetUserSPNs.py corp.local/lowpriv:'Password123' -dc-ip 10.10.10.5 -request -outputfile hashes.txt
If you are on a Windows host inside the domain, Rubeus is the go-to tool:
Rubeus.exe kerberoast /outfile:hashes.txt
[Screenshot: Rubeus roasting output showing a hash beginning with $krb5tgs$23$ for the svc_sql account]
A note on encryption types. Tickets encrypted with RC4 (etype 23) crack far faster than AES tickets. The hash you want to see starts with $krb5tgs$23$. If you see $krb5tgs$18$ instead, that account only supports AES256, which is still crackable but much slower. Rubeus has a /tgtdeleg trick to nudge the KDC toward RC4 on some accounts, but do not count on it against a hardened domain.
Step 3: Crack It Offline
This is where the attack leaves the network entirely. Move hashes.txt to your cracking box and let hashcat work. RC4 Kerberoast hashes are mode 13100:
hashcat -m 13100 -a 0 hashes.txt rockyou.txt
For AES256 tickets use mode 19700, and for AES128 use 19600. Add a rules file such as best64.rule to stretch your wordlist:
hashcat -m 13100 -a 0 hashes.txt rockyou.txt -r rules/best64.rule
[Screenshot: hashcat status screen showing one recovered password, Summer2023!, next to the svc_sql hash]
When a hash cracks, you have the service account's real password. From there you authenticate as that account and see what it can reach.
Common Mistakes to Recognize
- No hashes returned at all. Your account is probably fine but no user accounts have SPNs, or you mistyped the domain. Re-run the enumeration step on its own first.
- Only computer-account hashes. You are roasting machine accounts, which will not crack. Filter to user accounts with the PowerView query above.
- A hash that never cracks. That is a win for the defender, not a bug in your setup. It means the account uses a long random password or a group Managed Service Account. Move on to the next target.
- The account only issues AES tickets. Switch hashcat to mode 19700 and be patient, or reprioritize toward RC4-capable accounts.
What This Looks Like From the Other Side
Since these tutorials are meant to make you a better tester, you should know what you are setting off. Every service ticket request generates Windows Event ID 4769 on the domain controller. A defender tuned for this attack watches for a single account requesting tickets for many SPNs in a short window, especially with RC4 (encryption type 0x17) when the rest of the domain has moved to AES.
Mature environments also plant a honeypot service account, an SPN that no legitimate process ever requests, wired to an alert. If you roast the whole domain blindly, you will hit it. On a real engagement, request tickets selectively for the accounts that actually look valuable rather than roasting everything at once.
The fixes defenders apply are worth knowing too: 25-plus character random passwords on service accounts, migration to group Managed Service Accounts (gMSA) with their auto-rotated 120-character passwords, and removing service accounts from privileged groups they never needed. If you find a service account sitting in Domain Admins, that is a finding to write up regardless of whether you crack it.
Where to Practice
Do not run this against anything you are not authorized to test. To build the muscle memory legally, the retired Active Directory boxes on HackTheBox and the Kerberos-focused rooms on TryHackMe are built exactly for this. The tooling is documented at the Impacket repository and the hashcat wiki, and Microsoft's own Kerberos authentication overview is the clearest reference for the ticket flow described above.
Once you have recovered a service account, the natural next steps are dumping more credentials with our Mimikatz walkthrough and understanding how those tokens get reused for lateral movement in our guide to privilege escalation through token manipulation.
Kerberoasting rewards patience over cleverness. Enumerate carefully, roast selectively, and let hashcat do the slow work while you document everything you touch.
HacknPentest