Identify service accounts and SPNs worth investigating
Needs: Directory visibility and correct service/account association; roasting requires the additional authentication and encryption conditions
Windows commands
REM Baseline
setspn -Q */*
setspn -L ACCOUNT
PowerShell commands
# Baseline
Get-DomainUser -SPN | Select-Object samaccountname,serviceprincipalname,memberof,useraccountcontrol,pwdlastset
Record
account → service class/host/port → groups → password age/encryption/delegation clues → reachable service. An SPN means the account represents a Kerberos service identity; it does not mean the password is weak, the service is reachable or the account is privileged. Ticket acquisition/cracking is Block 11.
Verify → Record SPN, account/object type and relevant privilege relationships before prioritizing recovery.
If it fails → An SPN alone proves neither weak password nor destination admin rights. Rank by evidence and potential benefit. More detail ↓
Explanation & examples
Identify service accounts and SPNs worth investigating
- USE WHEN
- User-owned SPNs or service-account clues
- STARTING ACCESS
- A known domain identity or a directory endpoint that permits the selected anonymous query
- RESULT
- A prioritized service-account and roast candidate list
Recognize the clue
Enumerate servicePrincipalName on user objects and associate each SPN with its owning account and memberships.
Get-DomainUser -SPN | Select-Object samaccountname,serviceprincipalname,memberof
samaccountname: SERVICE_USER
serviceprincipalname: HTTP/TARGET_HOST
memberof: GROUPMeans: A user-owned service name identifies a potential ticket/password-recovery target whose rights may be useful.
Confirm: Check actual account type, KDC authentication, encryption type and feasibility; SPN existence alone is not weakness.
- After validation
- The selected account is requestable and recovery is justified: choose the roast method.
- Ruled out in this context
- The candidate is a strong random machine-account key with no useful recovery rationale: reject the assumed easy-password path.
- Still inconclusive
- Unknown ownership or unreadable attributes require a narrower directory query.
Troubleshooting: An SPN alone proves neither weak password nor destination admin rights. Rank by evidence and potential benefit.
Additional prerequisite checks
setspn -Q */*
Record account → service class/host/port → groups → password age/encryption/delegation clues → reachable service. An SPN means the account represents a Kerberos service identity; it does not mean the password is weak, the service is reachable or the account is privileged. Ticket acquisition/cracking is Block 11.
Why it works
An SPN maps a service name to an account key. Computer-account SPNs and user-service-account SPNs have different password characteristics; SPN presence is not a cracked password.
Worked example · hypothetical
Observation: a named user owns an HTTP SPN. Test: inspect account context and request only the selected account's ticket when permitted. Illustrative output: a roastable ticket is obtained. Interpretation: choose the matching offline mode and evaluate feasibility.
New identity, privilege, host or route? Re-enumerate → All topic tasks →