Kerberoasting & AS-REP Roasting: Request, Crack, Detect, Mitigate

Kerberoasting and AS-REP Roasting are two of the highest-yield offline credential attacks in any Active Directory engagement. Both abuse a deliberate feature of the Kerberos protocol: certain messages are encrypted with a key derived from an account's password, and any domain principal — or in the AS-REP case, sometimes an unauthenticated attacker — can request those messages and crack them at their leisure. There is no failed-logon noise on the target account, no lockout, and no traffic to the service itself. You request a blob, walk away, and feed it to a GPU.

This guide is written for authorized testing only. It covers what each attack actually requests on the wire, how to harvest the hashes with impacket and Rubeus, how to crack them with hashcat, and — critically — how a blue team detects and shuts both techniques down. Understanding the protocol mechanics is what separates running a tool from knowing why it works and how to evade or defend against it.

How Kerberos Pre-Authentication and Service Tickets Work

When a user authenticates, the client sends an AS-REQ to the Key Distribution Center (KDC). With pre-authentication enabled (the default), the client must prove it knows the password by encrypting a timestamp with its NTLM-derived key inside the PA-ENC-TIMESTAMP field. The KDC decrypts it, confirms the timestamp is fresh, and only then returns an AS-REP containing a Ticket Granting Ticket (TGT).

To reach a service, the client then sends a TGS-REQ naming a servicePrincipalName (SPN). The KDC returns a TGS-REP holding a service ticket whose encrypted portion is sealed with the service account's key. The service never has to be online — the KDC issues the ticket purely from directory data. Those two facts (timestamp sealed with the user key, service ticket sealed with the service-account key) are the entire basis for both attacks.

Kerberoasting: Cracking Service Account Passwords

Any authenticated domain user can request a TGS-REP for any SPN. Because the encrypted part is derived from the service account's password, you get an offline-crackable hash for every service account in the domain — without ever touching the service. Modern KDCs prefer AES, but if RC4 (etype 23) is permitted, the resulting hash (hashcat mode 13100) cracks dramatically faster than the AES variants (modes 19600/19700).

# impacket — request every SPN ticket from a low-priv account
GetUserSPNs.py corp.local/lowpriv:'Password123' -dc-ip 10.10.10.10 \
  -request -outputfile kerberoast.hashes

# Target a single high-value account
GetUserSPNs.py corp.local/lowpriv:'Password123' -dc-ip 10.10.10.10 \
  -request-user svc_sql -outputfile svc_sql.hash

# Rubeus on a domain-joined host (downgrade to RC4 where allowed)
Rubeus.exe kerberoast /rc4opsec /outfile:kerberoast.hashes

Prioritise accounts with adminCount=1, membership in privileged groups, or stale pwdLastSet values — these are where weak, never-rotated service passwords live. The /rc4opsec flag in Rubeus only roasts accounts that still support RC4 and skips AES-only ones, which avoids requesting tickets you cannot crack quickly and reduces noise.

AS-REP Roasting: When Pre-Authentication Is Disabled

If an account has DONT_REQ_PREAUTH set (the userAccountControl bit 0x400000), the KDC will return an AS-REP without first verifying a password. Part of that AS-REP is encrypted with the account's key, so you can request it and crack it offline. The killer detail: you do not need any valid domain credentials to ask for it — you only need a list of candidate usernames.

# Unauthenticated — spray a username list, no password required
GetNPUsers.py corp.local/ -dc-ip 10.10.10.10 -usersfile users.txt \
  -no-pass -format hashcat -outputfile asrep.hashes

# Authenticated — let the KDC enumerate vulnerable accounts for you
GetNPUsers.py corp.local/lowpriv:'Password123' -dc-ip 10.10.10.10 \
  -request -format hashcat

# Rubeus equivalent on Windows
Rubeus.exe asreproast /format:hashcat /outfile:asrep.hashes

The unauthenticated path is why a clean username list is so valuable — you can build one from OSINT, prior LLMNR captures, or RID cycling over null/guest sessions. Set DONT_REQ_PREAUTH is rarer than a kerberoastable SPN, but when it lands on a service or admin account the payoff is large because the attack needs no foothold at all.

Cracking the Hashes

Both attacks produce hashcat-formatted strings. The mode you choose must match the encryption type embedded in the hash header ($krb5tgs$23$ = RC4 TGS-REP, $krb5asrep$23$ = RC4 AS-REP, $krb5tgs$18$ = AES256 TGS-REP).

# Kerberoast — RC4 TGS-REP
hashcat -m 13100 kerberoast.hashes rockyou.txt -r best64.rule

# Kerberoast — AES256 TGS-REP (much slower)
hashcat -m 19700 kerberoast.hashes rockyou.txt

# AS-REP — RC4
hashcat -m 18200 asrep.hashes rockyou.txt -r best64.rule

Service accounts frequently carry long-but-guessable passwords (company name + year, app name + special char), so a curated wordlist plus rule mutations usually outperforms a raw brute force. If you are unsure which mode a captured hash needs, paste it into our Hash Identifier & Cracker to confirm the type and generate the matching hashcat and John commands, and keep the hashcat cheat sheet handy for mode numbers and rule syntax. To assemble the request-and-crack one-liners for a specific domain, the Active Directory payload generator templates GetUserSPNs, GetNPUsers, and the corresponding hashcat commands.

Detection: What the Blue Team Sees

Neither attack is silent at the KDC even though it is silent at the target service. Both leave distinctive Windows Security log artifacts on domain controllers:

• Event 4769 (Kerberos service ticket requested) is the Kerberoasting signal. Hunt for Ticket Encryption Type 0x17 (RC4) requests, an account requesting an unusually high volume of distinct SPNs in a short window, or tickets for SPNs that the requesting host has no business using.
• Event 4768 (Kerberos TGT requested) with Pre-Authentication Type 0 is the AS-REP Roasting tell — a TGT issued with no pre-auth means an account with DONT_REQ_PREAUTH was queried.
• Honey accounts are the highest-fidelity control: create a fake service account with a fabricated SPN and a strong random password, then alert on any 4769 for that SPN. Legitimate clients never request it, so a single hit is a near-certain intrusion.

# PowerShell — find every account with pre-auth disabled
Get-ADUser -Filter 'useraccountcontrol -band 4194304' -Properties useraccountcontrol

# List every user account carrying an SPN (kerberoastable surface)
Get-ADUser -Filter {ServicePrincipalName -like '*'} -Properties ServicePrincipalName

RC4 downgrade is the strongest behavioural indicator. In an AES-capable domain, a TGS request that explicitly asks for etype 23 is anomalous and worth alerting on by itself.

Mitigation and Defenses

The fixes are well understood; the hard part is operational discipline across hundreds of legacy service accounts. In priority order:

• Use Group Managed Service Accounts (gMSAs). gMSAs use 120-character, automatically-rotated passwords that are effectively uncrackable. Migrating service accounts to gMSAs removes Kerberoasting as a practical threat — this is the single highest-impact change.
• Enforce long, random passwords (25+ characters) on any remaining classic service account. Length, not complexity, is what defeats offline cracking. Rotate them and audit for stale pwdLastSet.
• Disable RC4 in the domain via Network security: Configure encryption types allowed for Kerberos, leaving only AES. This forces the slow-to-crack etypes and makes downgrade requests stand out. Test thoroughly — some legacy appliances still depend on RC4.
• Never set DONT_REQ_PREAUTH. Audit for it regularly with the PowerShell filter above and remediate any account that has it, especially privileged ones. There is almost never a legitimate modern reason to disable pre-auth.
• Apply least privilege to service accounts. A cracked service password only matters because of what the account can reach. Remove unnecessary group memberships and adminCount=1 flags so a compromised SPN does not equal Domain Admin.

For the broader attack chain these techniques feed into — BloodHound enumeration, Pass-the-Hash, DCSync, and Golden/Silver Tickets — see our companion Active Directory penetration testing guide, which puts roasting in the context of full domain compromise.

Key Takeaways

Kerberoasting and AS-REP Roasting persist because they exploit how Kerberos is designed to work, not a patchable bug. As an attacker you should map both surfaces early in every internal test — they are low-effort, low-noise, and frequently decisive. As a defender, the playbook is concrete: migrate to gMSAs, kill RC4, eliminate disabled pre-auth, lengthen and rotate remaining secrets, and plant honey SPNs so the requests light up your SIEM. Master the protocol mechanics on both sides of the engagement and these attacks become a routine finding rather than a domain-ending surprise.