AS-REP roasting is the sibling of Kerberoasting, and in one important way it is even better: it can require no credentials at all. It exploits accounts that have Kerberos pre-authentication disabled, turning the very first step of the Kerberos exchange into a source of crackable password material.
The pre-authentication mechanism
Normally, when a client sends an AS-REQ to request a TGT, it includes a timestamp encrypted with the user's own key (derived from their password). This is pre-authentication: it proves the requester knows the password before the KDC will issue anything. If the encrypted timestamp does not decrypt cleanly, the KDC refuses.
Pre-auth exists precisely to prevent what comes next. Without it, anyone can request an AS-REP for an account, and the KDC will happily return a response that contains material encrypted with that account's key — handing an attacker crackable ciphertext for an account whose password they do not know.
The vulnerable flag
An account is roastable when the DONT_REQ_PREAUTH flag is set in its
userAccountControl attribute (bit value 4194304). When set, the KDC
skips the pre-auth check for that account.
# LDAP filter for pre-auth-disabled accounts
(userAccountControl:1.2.840.113556.1.4.803:=4194304)Why would anyone disable pre-auth? Almost always for a legacy application or appliance that could not perform the pre-auth exchange, so an administrator turned it off "temporarily" and never turned it back on. Each such account is a standing invitation.
How the attack works
| Step | What happens |
|---|---|
| 1. Find the accounts | Query LDAP for the DONT_REQ_PREAUTH flag — or, with no creds, guess usernames |
| 2. Request an AS-REP | Send an AS-REQ for the account; because pre-auth is off, the KDC returns an AS-REP |
| 3. Extract the ciphertext | Part of the AS-REP is encrypted with the account's password-derived key |
| 4. Crack offline | Guess passwords, derive keys, test against the ciphertext — all offline |
The credential-less angle
With a valid domain credential you query LDAP directly for the roastable accounts. But the AS-REQ in step 2 does not itself require authentication — so if you have a list of usernames (from OSINT, document metadata, or a naming convention), you can attempt an AS-REP request for each one and roast any that happen to have pre-auth disabled, without ever authenticating to the domain.
The same tools that roast with a credential (Impacket's GetNPUsers, Rubeus) also run in a no-password mode that takes only a username list — which is what makes this a pre-authentication attack. The recovered AS-REP material is etype-23 (RC4) where possible and cracks fast, exactly as in Kerberoasting. The exploitation walkthrough with commands is in the Vulns & Misconfigs section under AS-REP Roasting.
This is why AS-REP roasting pairs so naturally with Kerbrute username enumeration: Kerbrute quietly confirms which usernames exist, and every confirmed name is a candidate for a no-password AS-REP attempt. The two together can produce a crackable hash from nothing but a domain name and a naming convention.
Targeted AS-REP roasting
As with Kerberoasting, write access changes the game. If you have
GenericWrite or GenericAll over an account (an
ACL finding), you can flip the
DONT_REQ_PREAUTH flag on yourself, roast the account, and flip it
back — manufacturing a roastable target on demand.
Detection and defence
| Control | Effect |
|---|---|
| Never disable pre-authentication | The root fix — audit for DONT_REQ_PREAUTH and clear it wherever it appears |
| Strong passwords on any exception | If an account genuinely must have pre-auth off, a long random password makes the AS-REP uncrackable |
| Monitor event 4768 with pre-auth type 0 | An AS-REQ without pre-auth data for such an account is the signal |
| Honeypot account | A decoy with pre-auth disabled and a strong password — any AS-REP request for it is malicious |
The takeaway
AS-REP roasting is a small, sharp technique: one legacy flag on one account, and the first step of Kerberos becomes an offline password-cracking oracle — sometimes without a single credential. It is quick to check for, quick to exploit, and its fix is a one-attribute cleanup. On an engagement it is worth running the moment you can query LDAP, and worth attempting against a username list even before you can. See Kerberoasting for the closely related SPN-based attack and the Kerberos page for the exchange it abuses.