Kerberoasting to a privileged service account
Any domain user can request service tickets for accounts that run under a Service Principal Name; those tickets are encrypted with the service account's password hash, so they can be cracked offline — and service accounts are too often over-privileged.
Scenario
An authorized internal engagement where you already hold one ordinary domain account (from a prior phase or a provided low-privilege user). The objective is to show whether weak service-account passwords and excessive service-account rights let a standard user escalate.
- 1
Discovery
Find accounts with an SPN
As an authenticated user, enumerate domain accounts that have a servicePrincipalName set — these are the roastable targets. Note which look privileged (admin-sounding names, membership in sensitive groups) so cracking effort is spent where it matters.
DetectionLDAP queries that filter specifically for servicePrincipalName from a workstation are an early, catchable signal.
MitigationMinimise the number of SPN accounts, review their group membership, and alert on broad SPN enumeration.
- 2
Credential Access
Request and extract service tickets
Request Kerberos service tickets (TGS-REP) for the chosen SPNs. The ticket is encrypted with the service account's password-derived key, so you receive crackable material without ever touching the service host — document which accounts yielded roastable tickets.
DetectionA burst of TGS requests (event 4769), especially for RC4 (0x17) encryption, from one account is a high-fidelity Kerberoasting signal.
MitigationUse group Managed Service Accounts (gMSA) with 120-character machine-managed passwords, and disable RC4 so tickets use AES.
- 3
Credential Access
Crack the ticket offline
Crack the extracted tickets offline against a wordlist and rules. A service account with a weak or never-rotated password falls quickly; a strong or gMSA-managed one does not — the finding is the weak password policy on service accounts, not the protocol.
DetectionOffline cracking is invisible to the domain; detection relies on the request-side signals above and on honeypot SPN accounts that should never be roasted.
MitigationEnforce long, rotated service-account passwords (or gMSA), and plant a honeypot SPN account that alerts the moment it is requested.
- 4
Privilege Escalation / Lateral Movement
Use the recovered account
Authenticate as the cracked service account and demonstrate the access its rights actually grant — often local admin on several hosts, or a path toward higher privilege. Report the specific over-permissioning, and stay within scope.
DetectionThe service account logging on interactively or from unusual hosts, and new admin sessions, are detectable with logon auditing and tiering.
MitigationApply least privilege to service accounts, keep them out of Domain Admins, and tier administration so one cracked account is contained.
Key takeaways
- Kerberoasting needs nothing more than one ordinary domain account — the crack happens entirely offline.
- gMSA or long, rotated passwords plus AES-only tickets make the recovered material uncrackable in practice.
- The real damage is over-privileged service accounts: least privilege and tiering turn a cracked account into a dead end.