AS-REP Roasting: cracking accounts that skipped Kerberos preauth

Most Kerberos attacks assume you already have a foothold. AS-REP roasting does not, and that is what makes it the first thing worth checking on an internal engagement.

The whole attack rides on one account flag: DONT_REQ_PREAUTH. When an account has "Do not require Kerberos preauthentication" set, the domain controller will hand out an AS-REP to anyone who asks for one in that account's name. Part of that response is encrypted with a key derived from the account's password. No password verification happens first. You ask, the DC answers, and now you have an offline cracking target for an account you never authenticated as.

Why the flag exists at all

Preauthentication is the thing that normally stops this. With preauth on, the client has to prove it knows the password (by encrypting a timestamp) before the DC sends anything sensitive back. Turn it off and that proof step disappears.

People disable it for legacy reasons. Old Unix Kerberos clients, certain appliances, a Java integration somebody set up in 2014 that broke with preauth on. So they flipped the flag to make the ticket flow work, the integration got decommissioned three years later, and the flag stayed. Now it is just a roastable account sitting in the directory.

Pulling the AS-REP

On a Linux attack box, Impacket's GetNPUsers.py is the standard tool. If you have a valid domain account, let it enumerate the vulnerable accounts for you:

GetNPUsers.py -dc-ip 10.0.0.10 contoso.local/lowprivuser:Password1 -request -format hashcat -outputfile asrep.txt

That queries LDAP for accounts with the preauth-not-required flag and requests an AS-REP for each one, writing them in hashcat format.

If you have no credentials at all but you do have a list of usernames (from OSINT, a breached dump, or earlier enumeration), you can run it unauthenticated:

GetNPUsers.py contoso.local/ -no-pass -usersfile users.txt -format hashcat -outputfile asrep.txt

Every name in that file that has preauth disabled comes back with a hash. The rest fail cleanly. This is the version that surprises people, because it needs nothing but network reach to the DC and a username guess.

From Windows, Rubeus does the same thing with Rubeus.exe asreproast, and it can scope to a single user or pull everything it can see.

The format and how to crack it

What lands in your file is a krb5asrep hash. For RC4 it looks like this:

$krb5asrep$23$user@CONTOSO.LOCAL:f4c8...

The 23 is the encryption type, RC4, and it decides whether this is worth your time. RC4 AS-REP hashes go to hashcat mode 18200:

hashcat -m 18200 -a 0 asrep.txt rockyou.txt -r /usr/share/hashcat/rules/best64.rule

These crack fast. RC4 throughput on a single GPU is billions of guesses per second, so any account with a dictionary-plus-rules password falls quickly. John the Ripper handles the same hashes with the krb5asrep format if you would rather autodetect. The usual hashcat versus John tradeoffs apply, and if the format is throwing you, the hashcat mode lookup covers AS-REP and the rest of the Kerberos family.

Sometimes you pull etype 17 or 18 instead. That is AES, and the cracking economics change completely: the slow string-to-key derivation drops your throughput by orders of magnitude. A weak password still falls, but a decent one is effectively out of reach. Most preauth-disabled accounts you find in the wild are still RC4, though, because the kind of legacy setup that needed preauth off usually predates AES enforcement too.

Where this sits next to Kerberoasting

The two attacks are cousins and people confuse them. The clean distinction is the entry requirement. Kerberoasting needs a valid domain account because you have to request service tickets for accounts with an SPN. AS-REP roasting can run with zero credentials against accounts that disabled preauth, and the crackable blob comes from the AS-REP, not a TGS.

In practice you run both. AS-REP roast first because it might work before you have any creds. Kerberoast once you do. The cracked passwords often overlap anyway, because the same admin who disabled preauth on a service account probably gave it a memorable password and registered an SPN on it too.

The defender's side

You cannot detect the AS-REP request the way you would catch a failed login, because to the DC it looks like a normal Kerberos exchange. But there are two real levers.

First, kill the flag. Pull every account with DONT_REQ_PREAUTH set and justify each one. The PowerShell is a one-liner against userAccountControl, and on most domains the honest answer is that none of them still need it. Re-enable preauth and the account stops being roastable entirely.

Second, watch event ID 4768, the Kerberos authentication ticket request. A 4768 with pre-authentication type 0 means an AS-REP was issued without preauth. A burst of those, especially across many accounts from one source, is the roast happening. Alert on it. Most environments never legitimately produce preauth-type-0 events, so the false-positive rate is low.

And the same thing that saves you everywhere else: password length. A preauth-disabled service account with a 20-character random password survives an RC4 roast fine. Summer2024! does not, and it never will.