AS-REP Roasting: Harvesting Hashes Without Credentials

What Is AS-REP Roasting?

AS-REP Roasting is an Active Directory attack that targets accounts with Kerberos pre-authentication disabled. Any unauthenticated attacker — or any domain user — can request an AS-REP response for these accounts and receive a blob encrypted with their password hash, ready to crack offline.

Unlike Kerberoasting, AS-REP Roasting requires zero credentials to enumerate and exploit targets if the attacker has network access to the domain. It is one of the lowest-friction attacks in Active Directory.

The vulnerability stems from a Kerberos option called DONT_REQUIRE_PREAUTH. When enabled on an account, the KDC skips the pre-authentication step and issues an AS-REP directly — containing data encrypted with the account's hash.

⚠️ Key difference from Kerberoasting: Kerberoasting requires a valid domain account. AS-REP Roasting can be performed with no credentials at all, from outside the domain.

How It Works

In standard Kerberos, before the KDC issues a TGT, the client must prove it knows the user's password by sending an encrypted timestamp (the AS-REQ pre-authentication data). This prevents offline hash collection because the KDC never sends encrypted material to unauthenticated requesters.

When DONT_REQUIRE_PREAUTH is set on an account, this step is skipped. The KDC responds to any AS-REQ for that account with an AS-REP containing a session key encrypted with the account's NTLM hash — no proof of identity required.

The attacker extracts this encrypted blob and cracks it offline to recover the plaintext password.

ℹ️ Note: The DONT_REQUIRE_PREAUTH flag is sometimes set intentionally for legacy application compatibility or by mistake during account provisioning. In either case, it represents a direct attack surface.

The Attack Chain

Step 1 - Enumerate Vulnerable Accounts

The attacker queries AD for accounts with the DONT_REQUIRE_PREAUTH flag set. This can be done with a standard domain user account or, if the DC allows anonymous LDAP, without any credentials:

# PowerShell — find accounts with pre-auth disabled
Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} -Properties DoesNotRequirePreAuth, PasswordLastSet |
    Select-Object SamAccountName, PasswordLastSet

# Impacket — no credentials required if LDAP allows it
impacket-GetNPUsers corp.local/ -usersfile users.txt -no-pass -dc-ip 10.10.0.1

# With a valid domain account — enumerate automatically
impacket-GetNPUsers corp.local/user:password -request -dc-ip 10.10.0.1

Step 2 - Collect AS-REP Hashes

For each vulnerable account, the tool sends a bare AS-REQ and receives an AS-REP with the encrypted session key:

# Rubeus — enumerate and collect all AS-REP hashes in one pass
.\Rubeus.exe asreproast /format:hashcat /outfile:asrep_hashes.txt

The output format is $krb5asrep$23$... — directly compatible with Hashcat.

Step 3 - Crack Offline

# Hashcat — mode 18200 for AS-REP hashes
hashcat -m 18200 asrep_hashes.txt /usr/share/wordlists/rockyou.txt --rules-file best64.rule

AS-REP hashes use RC4 by default, making them fast to crack — the same speed as Kerberoasting RC4 tickets: hundreds of millions of attempts per second on a modern GPU.

Step 4 - Account Takeover

A cracked AS-REP hash yields the account's plaintext password. The attacker can then authenticate as that user, access their resources, and use the account as a pivot for further attacks — privilege escalation, lateral movement, or persistence.

If the targeted account has elevated privileges (common when IT staff disable pre-auth for "convenience"), the compromise is immediate and severe.

Detection

AS-REP Roasting generates Kerberos AS-REQ and AS-REP events on the Domain Controller. Detection is more reliable than Kerberoasting because the absence of pre-authentication data in the AS-REQ is a direct indicator.

Windows Event IDs

Key Detection Signal

Event 4768 with Pre-Authentication Type = 0 is the clearest indicator. In a properly configured domain, this should never appear — all accounts should require pre-authentication.

💡 Tip: A single 4768 event with pre-auth type 0 for an account that normally requires it is a high-confidence alert. Tune your SIEM to fire on this immediately.

SIEM Detection Query (Elastic KQL)

event.code: "4768" AND
winlog.event_data.PreAuthType: "0" AND
winlog.event_data.Status: "0x0"

For bulk enumeration detection:

event.code: "4768" AND
winlog.event_data.PreAuthType: "0"
| stats count() by source.ip, winlog.event_data.TargetUserName
| where count > 3

Behavioral Anomalies

• AS-REQ with no pre-auth data from external or unexpected IPs
• Sequential requests for multiple accounts from a single source within seconds
• Requests for service accounts or admin accounts that should never authenticate interactively
• Off-hours authentication attempts for accounts with DONT_REQUIRE_PREAUTH

Remediation

💡 Quick Win: Run the audit query below and re-enable pre-authentication on every account that has it disabled. This is a one-line fix per account with zero user impact in most cases.

Re-enable Pre-Authentication

# Re-enable pre-auth on a single account
Set-ADAccountControl -Identity vulnerable_user -DoesNotRequirePreAuth $false

# Bulk fix — re-enable on all accounts with pre-auth disabled
Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} | ForEach-Object {
    Set-ADAccountControl -Identity $_ -DoesNotRequirePreAuth $false
    Write-Host "Fixed: $($_.SamAccountName)"
}

Audit and Harden

1. Identify all accounts with pre-auth disabled and verify whether the flag is legitimately required:

Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} -Properties DoesNotRequirePreAuth, PasswordLastSet, Description |
    Select-Object SamAccountName, PasswordLastSet, Description |
    Export-Csv asrep_vulnerable_accounts.csv -NoTypeInformation

2. Check for legacy application requirements — if a system genuinely needs pre-auth disabled, isolate it, monitor it, and ensure the account has minimal permissions.

3. Rotate passwords on affected accounts — even if you re-enable pre-auth, the hash was already exposed if any attacker collected it. Rotate immediately.

# Force password reset at next logon for all previously vulnerable accounts
Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} | Set-ADUser -ChangePasswordAtLogon $true

4. Apply fine-grained password policies to accounts that cannot have pre-auth re-enabled — at minimum enforce a 20+ character password to resist cracking.

5. Restrict LDAP anonymous access — prevent unauthenticated enumeration of the DONT_REQUIRE_PREAUTH flag by disabling anonymous LDAP binds on Domain Controllers.

# Verify anonymous LDAP is disabled
Get-ADObject -Identity "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=corp,DC=local" `
    -Properties dsHeuristics | Select-Object dsHeuristics
# dsHeuristics value position 7 should not be '2' (anonymous access)

How EtcSec Detects This

EtcSec flags accounts with Kerberos pre-authentication disabled as part of every AD audit.

The ASREP_ROASTING_RISK detection identifies all accounts in your domain with DONT_REQUIRE_PREAUTH set, regardless of whether they have been targeted yet. Every flagged account is a credential waiting to be harvested.

Related checks that increase the risk:

• PASSWORD_NEVER_EXPIRES - accounts with pre-auth disabled and non-expiring passwords represent a permanent attack surface; a cracked hash is valid indefinitely
• PASSWORD_POLICY_WEAK - a weak domain password policy makes offline cracking faster and more likely to succeed
• WEAK_KERBEROS_POLICY - permissive Kerberos settings extend the window of exploitation for harvested hashes

ℹ️ Note: EtcSec automatically checks for these vulnerabilities during every AD audit. Run a free audit to identify which accounts in your environment are exposed to AS-REP Roasting.