Service Accounts Never Change Their Passwords
Kerberoasting: how an ordinary domain user walks out with crackable credentials for the accounts that actually matter.
Most network attacks you imagine as a break-in. Kerberoasting isn’t that. It’s closer to walking up to the front desk, politely asking for a sealed envelope you’re allowed to have, and then taking it home to open at your leisure, where nobody is watching, and you have all the time in the world.
The envelope is encrypted with a password. The password belongs to a service account. And service accounts, famously, never change their passwords.
A two-minute model of Kerberos
In an Active Directory domain, you don’t send your password to every service you use. You authenticate once to a central authority (the KDC) and get a ticket-granting ticket (TGT). When you want to reach a specific service, you present the TGT and ask for a service ticket (a TGS) for that service.
Services are identified by a Service Principal Name (SPN), something like MSSQLSvc/db01.corp.local:1433. Here’s the load-bearing detail: the service ticket the KDC hands back is encrypted with the service account’s password-derived key. That’s how the service later proves the ticket is genuine: only it (and the KDC) knows that key.
The flaw is a feature
Any authenticated user can request a service ticket for any SPN. You don’t need permission to use the service. You don’t even need to talk to it. You just ask the KDC, and it hands you a ticket encrypted with the service account’s key.
So you ask for tickets for every juicy SPN you can enumerate, and now you’re holding a pile of ciphertext, each piece encrypted with a service account’s password. Take it offline and crack it. Historically these tickets use RC4 (NTLM-hash-derived), which cracks fast.
# enumerate SPNs and request the tickets (Impacket)
GetUserSPNs.py corp.local/cade:'<password>' -dc-ip 10.0.0.10 -request
# crack offline — hashcat mode 13100 is Kerberoastable TGS-REP (RC4)
hashcat -m 13100 tickets.txt rockyou.txt
Nothing about the cracking touches the network. The KDC saw a normal user request normal tickets (which happens thousands of times a day) and then nothing. The compromise happens on your laptop, in silence.
Why it works in the real world
Service accounts are the soft underbelly of a domain because of how they’re created and forgotten:
- A human picked the password, years ago, and it was
Summer2019!or the vendor default. - It’s set to never expire, because rotating it might break the service at 3 a.m.
- It’s been granted far more privilege than it needs, because that was faster than scoping it.
Weak password plus high privilege plus offline, undetectable cracking is the whole game. One cracked service account is often the pivot from “some user” to “the part of the network that matters.”
The fix
- Group Managed Service Accounts (gMSA). Let the domain generate and rotate a long, random password automatically. You can’t crack
Summer2019!if the password is 120 random characters that change on a schedule. - Kill RC4. Enforce AES encryption types for tickets; AES dramatically raises cracking cost.
- Least privilege. A service account should hold exactly the rights its service needs and nothing more, so a crack is a smaller win.
- Watch the requests. Abnormal volumes of TGS requests, or requests specifically for RC4 tickets, are a detectable signature of someone roasting your domain.
The point
In the book, the door that matters is held shut by a service account whose password hadn’t been touched in months. Cade doesn’t pick the lock. He asks the domain for a ticket he’s allowed to have, walks off with it, and opens it somewhere no one is looking. The break-in already happened by the time anyone could have seen it, which is exactly why it’s the technique that keeps showing up.