Kerberoastable Service Accounts
Any authenticated domain user can request a TGS for any account with a Service Principal Name set. The ticket is encrypted with the service account's password hash and returned without special rights. The finding is accounts where this combination exists: an SPN on a user object, RC4 encryption still accepted, and a password that has not rotated recently. Cracking is covered in Kerberoasting.
Identify roastable accounts
List all user objects with SPNs set. Computer accounts are excluded — machine account passwords rotate automatically and are effectively uncrackable.
This lists without requesting tickets. Output includes the account name, SPN, and whether the account is enabled.
With bloodyAD for additional attributes:
Pull memberOf, pwdLastSet, and userAccountControl alongside the SPN data. These determine severity.
With nxc:
This extracts hashes immediately — useful to confirm the accounts are roastable and to see which encryption type is returned (RC4 vs AES).
Assess severity per account
Roastable accounts are not equally dangerous. Three factors determine how much a given account matters.
Encryption type. RC4 (etype 23, $krb5tgs$23$) is fast to crack. AES-128 (etype 17) and AES-256 (etype 18) are orders of magnitude slower. An account that only issues AES tickets is much harder to crack in practice. Check what the DC returns:
Hash lines starting with $krb5tgs$23$ are RC4 — prioritize these. If only $krb5tgs$18$ or $krb5tgs$17$ are returned, the account has AES enforced via the This account supports Kerberos AES 256 bit encryption flag.
Group membership. A roastable account in Domain Admins or any tier-0 group is a critical finding. Check:
An SPN account in a privileged group means cracking the password produces immediate high-impact access.
Password age. Service accounts set up years ago and never rotated are far more likely to crack.
A pwdLastSet value of 0 means the password was set at account creation and never changed. Convert the Windows timestamp to confirm how old it is:
Service classes that indicate privileged access
The SPN prefix identifies the service. Some classes are consistently higher impact than others.
SPN prefix | Service | Why it matters |
|---|---|---|
| SQL Server | Often runs as domain user with local admin on DB host |
| IIS / web apps | May have local admin, access to app secrets |
| SMB file services | File server access, often on sensitive data hosts |
| Windows host general | Broad service association, often elevated |
| WinRM | Direct remote management path |
| RDP | Remote desktop access |
MSSQLSvc and HTTP accounts in environments with business-critical services are the highest-value targets.
Targeted Kerberoasting via GenericWrite
If no roastable accounts exist, check whether you have GenericWrite or GenericAll on any user account. These rights allow setting an SPN on an account that does not have one, making it temporarily roastable.
Then check ACLs for writable objects via BloodHound or ACL Enumeration. A writable account with no SPN can be made roastable. Remove the SPN after cracking.
For the full extraction and cracking workflow, see Kerberoasting and AD Kerberoasting.
References
-
GetUserSPNs for SPN listing and ticket extraction
-
NetExec Kerberoastingwww.netexec.wiki/ldap-protocol/kerberoasting (opens in new tab)
--kerberoasting module and hash output
-
LDAP search with attribute selection for SPN accounts
Was this helpful?
Your feedback helps improve this page.