EtcSecBeta
🏢Active DirectoryKerberosAttack PathsAccountsConfig

AS-REP Roasting: Harvesting Hashes Without Credentials

AS-REP Roasting targets accounts with Kerberos pre-authentication disabled, allowing attackers to collect crackable hashes with zero credentials. Learn how to detect and fix it.

Younes AZABARBy Younes AZABAR8 min read
Available inEnglishFrançaisEspañolDeutschPortuguêsItaliano
AS-REP Roasting: Harvesting Hashes Without Credentials

What Is AS-REP Roasting?

AS-REP Roasting is an Active Directory attack against accounts that have Kerberos pre-authentication disabled.

When the DONT_REQ_PREAUTH flag is set on a user or service account, the Key Distribution Center (KDC) can return an AS-REP without first requiring the client to prove knowledge of the password. An attacker who knows or guesses a valid username can request that response, extract the encrypted material, and crack it offline.

This is why defenders treat the setting as high risk: it turns a domain account into an offline password-cracking target before authentication has succeeded.

The important distinction from Kerberoasting is operational:

  • Kerberoasting requires a valid domain identity to request service tickets.
  • AS-REP Roasting does not require valid credentials to request an AS-REP for a known account name.

What it does not mean is that anonymous LDAP enumeration is guaranteed. Microsoft disabled anonymous LDAP operations to Active Directory on domain controllers by default starting with Windows Server 2003, except limited operations such as rootDSE queries and binds. Username discovery is a separate problem from AS-REP collection.

How the Kerberos Exchange Changes

In a normal Kerberos AS exchange, the client sends an AS-REQ and includes pre-authentication data, most commonly an encrypted timestamp. That is the proof that the requester knows the account password.

If DONT_REQ_PREAUTH is set, the KDC skips that check and returns an AS-REP immediately. The encrypted part of that response is protected with the account's long-term Kerberos key derived from the password.

For defenders, two technical points matter here:

  • the attack works because the encrypted response can be requested before authentication succeeds
  • the returned material is suitable for offline cracking, so password length and password policy directly affect impact

Do not assume every AS-REP roastable account will yield the same encryption type. Modern Windows environments are expected to use AES-family types in many cases; older environments may still expose RC4. The right mental model is not "RC4 by default," but "the returned material depends on the account and Kerberos encryption configuration in that environment."

What an Attacker Actually Needs

A successful AS-REP Roasting attempt needs only three things:

  1. Network reachability to a domain controller that can answer Kerberos AS requests.
  2. Candidate usernames to test.
  3. At least one account with DONT_REQ_PREAUTH enabled.

That is what makes the technique attractive. The attacker does not need to steal a workstation session or phish a first account before starting the collection step.

In practice, username discovery usually comes from one of these sources:

  • a previous foothold in the domain
  • email naming conventions and public directories
  • legacy scripts or exports containing account names
  • authenticated LDAP or PowerShell enumeration by any low-privilege domain user

Anonymous LDAP should be treated as an additional mistake, not as a prerequisite for the attack.

The Attack Chain

Step 1 - Identify Roastable Accounts

With authenticated access, defenders and attackers can find accounts that do not require pre-authentication directly in AD:

Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} -Properties DoesNotRequirePreAuth, PasswordLastSet |
    Select-Object SamAccountName, PasswordLastSet

Without credentials, the attacker can still test known usernames by sending AS requests and seeing which accounts return roastable material.

Step 2 - Request AS-REP Responses

# Request AS-REP data for known usernames
impacket-GetNPUsers corp.local/ -usersfile users.txt -no-pass -dc-ip 10.10.0.1

With a valid domain account, the same tool can enumerate and request more directly:

impacket-GetNPUsers corp.local/user:password -request -dc-ip 10.10.0.1

Rubeus can do the same from a Windows host:

.\Rubeus.exe asreproast /format:hashcat /outfile:asrep_hashes.txt

Step 3 - Crack Offline

At this point the attacker has removed the domain controller from the problem. Password guessing happens offline, at the attacker's speed, against the returned Kerberos material.

That is why old service-account passwords, weak human-generated passwords, and non-expiring passwords matter so much in this scenario.

Step 4 - Use the Recovered Credential

If the password is recovered, the account can be used like any other compromised identity:

  • interactive access where allowed
  • LDAP and PowerShell enumeration
  • lateral movement to systems where the account is local admin or has delegated access
  • escalation when the account is tied to privileged groups, scheduled tasks, services, or high-value applications

A single exception created for a legacy application can therefore become the first step in a much larger identity path.

Detection

The most useful detection point is still the domain controller.

Event 4768 Matters

Microsoft's documentation for Event ID 4768 makes two fields especially valuable here:

  • Pre-Authentication Type = 0 means the TGT request happened without Kerberos pre-authentication.
  • Ticket Encryption Type shows which Kerberos encryption type was actually used for the issued TGT.

For AS-REP Roasting, Event 4768 with Pre-Authentication Type 0 is the signal to prioritize.

Practical Hunting Patterns

Hunt for these patterns first:

  • repeated 4768 events with Pre-Authentication Type = 0
  • bursts of requests from a single source against multiple usernames
  • requests involving service accounts or privileged users that should never authenticate interactively
  • 4768 Result Code 0x6 spikes, which can indicate username guessing before successful requests
  • account changes that enable DONT_REQ_PREAUTH, especially for service or admin-linked identities

Example SIEM Query

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

If directory-change auditing is enabled, also review account changes that toggle the relevant userAccountControl bit. That is often the cleaner place to catch a dangerous exception before it is exploited.

Remediation

1. Remove Unnecessary Pre-Auth Exceptions

Set-ADAccountControl -Identity vulnerable_user -DoesNotRequirePreAuth $false

Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} | ForEach-Object {
    Set-ADAccountControl -Identity $_ -DoesNotRequirePreAuth $false
}

This is the primary fix. If an account does not explicitly need the exception, it should not have it.

2. Rotate Passwords After the Setting Is Fixed

Do not stop after re-enabling pre-authentication. If the account was already roastable, assume the material may have been collected before you found it.

Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} |
    Set-ADUser -ChangePasswordAtLogon $true

For service accounts, plan an actual secret rotation, not just a flag change.

3. Re-evaluate Legacy Dependencies

If a team claims pre-authentication must remain disabled, force a technical review of that dependency:

  • what system still needs it
  • whether that system can be modernized or isolated
  • whether the account can be downgraded to minimum rights
  • whether interactive logon, delegation, or broad group membership can be removed

A pre-auth exception on a privileged or reusable service account is not a small compatibility tradeoff. It is an offline password exposure.

4. Harden the Accounts That Cannot Yet Be Changed

If an exception must survive temporarily:

  • use a long random password
  • remove privileged group membership wherever possible
  • restrict logon rights
  • monitor Event 4768 for that account specifically
  • set a named owner and review date

5. Do Not Rely on Username Secrecy

Even if anonymous LDAP is disabled, assume attackers can still build username lists. The durable control is to remove roastable accounts and reduce the value of any account that must remain exceptional.

Validate the Fix

A professional closure check for AS-REP Roasting is straightforward:

  1. Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} returns only documented exceptions.
  2. The passwords for previously exposed accounts have been rotated.
  3. Event 4768 with Pre-Authentication Type = 0 no longer appears for ordinary user and service accounts.
  4. Any remaining exception has an owner, business justification, compensating controls, and a review date.

If you cannot answer those four points with evidence, the issue is not actually closed.

One extra validation that is worth keeping

For every remaining exception, review the associated service inventory as well: linked SPNs, password age, group memberships, and the application owner who still claims the dependency. That small step prevents an abandoned service account from staying roastable simply because nobody wanted to decide whether the legacy application still mattered.

One more control worth documenting

It also helps to record which domain controllers or segments could actually serve AS traffic to the exposed account population. That simple note keeps teams from treating the issue as purely theoretical when, in practice, the account is still reachable from workstation networks, jump hosts, or externally exposed footholds.

Common Defender Mistakes

The recurring mistakes are usually the same:

  • assuming anonymous LDAP is required for AS-REP Roasting
  • re-enabling pre-authentication but not rotating the password
  • leaving the exception on old service accounts with broad access
  • treating the setting as harmless because the account is "non-interactive"
  • fixing the one visible account without fixing the provisioning process that created the exception

Technical readers will recognize the pattern: the exploit is simple, but the real risk depends on how much authority the exposed account accumulated over time.

Primary References

How EtcSec Detects This

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

The primary finding is ASREP_ROASTING_RISK: any account with DONT_REQ_PREAUTH set is a password exposure candidate.

Related findings often change the severity of the situation:

  • PASSWORD_NEVER_EXPIRES
  • PASSWORD_POLICY_WEAK
  • WEAK_KERBEROS_POLICY

That combination matters more than the flag alone. A roastable account with a weak, old, or non-expiring password is materially more dangerous than a tightly controlled temporary exception.

Related Reading

🏢 Active DirectoryKerberosAttack PathsAccountsConfig