kerberoasting, any domain user can crack a service account

the hook

here's a fun one for anyone running active directory. any regular domain user, no admin rights, no exploit, nothing fancy, can ask the domain controller for a ticket to any service account. part of that ticket is encrypted with the service account's password hash. take it offline, crack it, and if that account has a weak password you now own whatever that account has access to. if that account happens to be in domain admins, which happens way more than it should, you just handed over the keys.

what's actually happening

this is called kerberoasting and it's not a bug, it's just how kerberos works. any authenticated user can request a service ticket (a "TGS") for any service that has a registered service principal name (SPN) in ad. that's normal, that's how services authenticate to each other. the catch is part of that ticket is encrypted using the ntlm hash of the service account's password. an attacker doesn't need to touch the domain controller's memory or exploit anything, they just ask for a ticket like they're supposed to, then crack the encrypted piece offline at their own pace, no lockout policy involved because they're not guessing against ad.

impacket-GetUserSPNs corp.local/user:pass -request -dc-ip 10.0.0.10
hashcat -m 13100 krb.hash rockyou.txt

breaking down the command

the first line pulls every account in the domain that has an SPN attached to it, meaning it's registered as running some service, then requests a ticket for each one. corp.local/user:pass is just any valid domain credential, doesn't need to be privileged. -dc-ip points it at the domain controller. the tool dumps the crackable portion of each ticket into a hash file.

the second line feeds that hash file into hashcat with mode 13100, which is the mode for kerberos 5 TGS-REP etype 23 hashes, and points it at a wordlist. if any service account's password is in that wordlist or close to it, hashcat cracks it and now the attacker has that account's plaintext password.

the actual dangerous part isn't the tooling, it's what happens next: whoever cracked it logs in as that service account and inherits whatever permissions it has. service accounts are notorious for being set up once, given broad permissions "just in case," and then never touched again for years.

why this keeps working

three things line up to make kerberoasting a favorite for attackers and a nightmare for defenders who aren't watching for it. first, service accounts are frequently created years ago by someone who's long gone, with passwords that were never rotated. second, those passwords are often set manually by a human, which means they're shorter and weaker than the long random strings a computer would generate. third, nobody's watching for the ticket requests because they look like completely normal kerberos traffic, which is exactly what makes this technique so quiet.

how to check yourself

you don't need attacker tools to find this exposure, you can audit your own environment directly. pull every account with an SPN and check password age and length:

Get-ADUser -Filter {ServicePrincipalName -ne "$null"} -Properties ServicePrincipalName,PasswordLastSet | Select Name,PasswordLastSet

anything with a password older than a year, or shorter than 25 characters, is a candidate for cracking. cross-reference that list against domain admins and any other privileged groups. if a service account with a weak, stale password is sitting in a privileged group, you've found your own exposure before anyone else does.

how to fix it

the real fix is making the crackable ticket useless even if someone grabs it. use long, randomly generated passwords for service accounts, ideally 25+ characters, managed through group managed service accounts (gMSA) so windows rotates the password automatically and no human ever has to remember it. get service accounts out of domain admins entirely, they should have exactly the permissions they need and nothing more. enable AES encryption for kerberos instead of RC4, since RC4-based tickets crack dramatically faster. and turn on logging for event id 4769 so you can spot unusual spikes in ticket requests, especially against accounts nobody normally queries.

the takeaway

kerberoasting doesn't need a vulnerability, it needs a weak password sitting on an overprivileged account, which honestly describes a lot of environments that haven't done a service account audit in years. the fix isn't complicated, it's just unglamorous: rotate passwords, use gMSAs, trim permissions, watch your logs. do that and the ticket an attacker cracks becomes worthless, which is a much better place to be than finding out the hard way.