AS-REP Roasting is one of the few Active Directory attacks that requires zero credentials to execute. If any account in the domain has Kerberos pre-authentication disabled, you can extract an encrypted hash from the domain controller without ever authenticating. Take the hash offline, crack it, and you have credentials — often for an account that has never had its password rotated.

The attack is quiet, unauthenticated, and scales across any domain. Any domain user — or nobody at all — can find these accounts. Here is how it works and how to automate it.

MITRE ATT&CK: T1558.004 — Steal or Forge Kerberos Tickets: AS-REP Roasting

How AS-REP Roasting Works

Kerberos pre-authentication is a security feature that requires a client to prove it knows the user's password before the KDC will issue a Ticket Granting Ticket (TGT). The proof is a timestamp encrypted with the user's key. The KDC verifies the timestamp, confirms the client has the correct credentials, and only then responds with a TGT.

When pre-authentication is disabled on an account, that verification step is skipped. An attacker can send an Authentication Service Request (AS-REQ) for the target account without providing any timestamp or credential proof. The KDC responds with an AS-REP containing a TGT, and that TGT is partially encrypted with the user's password hash.

The attacker extracts the encrypted blob from the AS-REP and takes it offline for cracking. No authentication, no account lockout, no interaction with the target account.

RC4 vs AES: By default, the KDC responds using RC4-HMAC encryption (etype 0x17) unless the account enforces AES. RC4 hashes crack significantly faster because hashcat mode 18200 handles etype 23 at high throughput. Accounts configured for AES-only (etype 18) are still crackable but require substantially more time. When you enumerate AS-REP roastable accounts, note which encryption types are supported — RC4-capable accounts are your priority targets.

Detection signal: The KDC logs Event ID 4768 (Kerberos Authentication Service) for every AS-REQ. When pre-authentication is disabled, the event shows Pre-Authentication-Type 0 and the target username. This is the primary detection signal. In environments running Microsoft Defender for Identity, this triggers a built-in alert. In most environments without MDI, it goes unnoticed.

Finding Vulnerable Accounts

An account is AS-REP roastable if the flag DONT_REQUIRE_PREAUTH is set in its userAccountControl attribute. The decimal value of this flag is 4194304.

The LDAP filter to enumerate all AS-REP roastable user accounts:

(&(userAccountControl:1.2.840.113556.1.4.803:=4194304)(objectCategory=user))

Run it directly with ldapsearch:

ldapsearch -H ldap://dc.domain.local -x -b "DC=domain,DC=local" \
  "(&(userAccountControl:1.2.840.113556.1.4.803:=4194304)(objectCategory=user))" \
  sAMAccountName userAccountControl memberOf

Why accounts get this flag: Pre-authentication is disabled for several reasons, most of them operational shortcuts that were never remediated. Common causes include legacy Kerberos clients (RFC 1510-era systems that do not support pre-auth), misconfigured service accounts where an admin toggled the flag during troubleshooting and left it, and Oracle database accounts that historically required this flag. In large domains, it is common to find accounts with this flag set from integrations that were decommissioned years ago but whose AD objects were never cleaned up.

Manual approach with impacket: GetNPUsers.py from the impacket suite handles AS-REP Roasting without authentication. Provide a username list and it will query the KDC for each:

GetNPUsers.py domain.local/ -usersfile users.txt -no-pass -dc-ip 192.168.1.1

Without a username list, it requires at least read access to LDAP to enumerate accounts. ADscan sidesteps this requirement entirely.

Extracting and Cracking

The AS-REP hash output looks like this:

[email protected]:a1b2c3d4e5f6...

The 23 identifies RC4-HMAC encryption (etype 23). Save the hash to a file and run hashcat with mode 18200:

hashcat -m 18200 hash.txt rockyou.txt

For AES-encrypted hashes (etype 18), the hash header will show a different format, and you use hashcat mode 18200 with the appropriate AES hash format. AES hashes crack at a fraction of the speed of RC4. On a modern GPU, RC4 hashes run at hundreds of millions of guesses per second; AES hashes may run at single-digit millions. Prioritize RC4 targets when time is limited.

Wordlist strategy for domain accounts: rockyou.txt is a baseline, but AS-REP roastable accounts tend to be service accounts or legacy user accounts. These often have passwords that follow internal conventions rather than appearing in common password lists. Build a targeted wordlist from:

Corporate naming patterns: Companyname2024!, Domain2023@
Season and year combinations: Spring2025!, Winter2024, Autumn2023@
Application or service names visible in the environment
The company name, domain name, or city combined with common suffixes and years
Default passwords for the specific system or application that originally used the account

In real engagements, AS-REP roastable accounts are frequently set-and-forgotten. The password was defined when the system was deployed and has not changed since. Targeted wordlists built from environment context outperform generic lists for these accounts.

ADscan Workflow

ADscan runs AS-REP Roasting in unauthenticated mode — before you have any credentials at all.

When you start an engagement with start_unauth, ADscan performs unauthenticated enumeration of the domain. This includes querying the KDC for AS-REP roastable accounts without needing a username list, using Kerberos protocol directly against the DC. Any account with pre-authentication disabled is identified and the AS-REP hash is extracted automatically.

# Inside ADscan shell
start_unauth --target dc.domain.local --domain domain.local

AS-REP roastable accounts appear in the vulnerability list immediately. ADscan maps each account against the attack path graph — you see not just the hash, but which accounts have paths to Domain Admin through group membership, ACL edges, delegation, or other relationships computed from the full domain enumeration.

This matters for prioritization. If you have five AS-REP roastable accounts, ADscan tells you which one to crack first based on its position in the attack graph. An account with GenericAll over a Tier 0 object is more important than an orphaned service account with no outbound edges.

Evidence is saved to the workspace automatically: hashes, the affected account list, and the enumeration timestamp are all retained in the audit trail.

With ADscan PRO, adscan deliver generates a client-ready PDF that documents the AS-REP Roasting finding with CVSS scoring, affected account evidence, and remediation guidance formatted for the client report — no manual editing required.

Running 2+ AD engagements per year? Request PRO beta — 90 days free.

Detection and Prevention

Detection:

Monitor for Event ID 4768 (Kerberos Authentication Service) with Pre-Authentication-Type 0. This field is only present when an AS-REQ is processed without pre-authentication. Correlate it against the source IP and target account. A non-domain-joined host requesting AS-REPs for multiple accounts in a short window is a reliable signal.

Microsoft Defender for Identity includes a built-in detection rule for AS-REP Roasting that correlates request patterns across time. Environments without MDI should configure SIEM rules against 4768 with the Pre-Auth-Type 0 field.

Prevention:

Enable Kerberos pre-authentication on all accounts. In Active Directory Users and Computers, open the account properties, go to the Account tab, and ensure "Do not require Kerberos preauthentication" is unchecked. Enforce this via Group Policy and audit quarterly.
Audit userAccountControl for the DONT_REQUIRE_PREAUTH flag. Run the LDAP filter above against your domain monthly. Any account with this flag that is not documented and justified should have it removed immediately.
Migrate legacy systems. If a system requires pre-auth to be disabled, it is using an obsolete Kerberos implementation. Plan the migration or decommission.
Use gMSA for service accounts. Group Managed Service Accounts use 240-character randomly generated passwords that rotate automatically. If a service supports gMSA, the password is uncrackable and pre-auth remains enabled.

For a related technique that targets authenticated sessions, see the Kerberoasting guide.

Conclusion

AS-REP Roasting is unusual among AD attacks because it works before you have a foothold. No credentials, no domain user account, no prior enumeration — if any account in the domain has pre-authentication disabled, you can extract a crackable hash directly from the KDC.

These accounts exist in almost every large domain. They are created during integrations, left behind after migrations, and forgotten. The attack generates minimal noise and targets accounts that are rarely audited.

ADscan LITE finds AS-REP roastable accounts automatically during unauthenticated enumeration — free and open source:

Download ADscan LITE: https://github.com/ADScanPro/adscan
Request PRO beta: https://adscanpro.com/pro