AS-REP Roasting

ActiveDirectoryCredentialAccessintermediateT1558.00412 min

AS-REP Roasting targets Active Directory accounts that have Kerberos pre-authentication disabled, allowing an attacker to request encrypted credential material without knowing the account's password. This lesson explains the precondition that makes the attack possible, why the mechanism works, what the attacker gains, how it differs from Kerberoasting, and how to communicate the risk clearly in interviews, reports, and stakeholder conversations.

This lesson builds on

Kerberos Authentication

Theory

Why It Matters

AS-REP Roasting exploits a specific misconfiguration that appears in real environments more often than administrators expect.

Understanding this technique matters because it demonstrates how a single account setting — disabling pre-authentication — converts a design-safe protocol exchange into an offline credential attack. It is a common interview topic because it tests whether a candidate understands the Kerberos authentication flow at a level deeper than tool commands, specifically the role of pre-authentication and what happens when it is removed.

Preconditions

AS-REP Roasting requires that at least one domain account has the 'Do not require Kerberos preauthentication' flag set in Active Directory (the DONT_REQ_PREAUTH UserAccountControl flag). The attacker needs network access to a domain controller on port 88 (Kerberos).

Unlike Kerberoasting, the attacker does not necessarily need valid domain credentials — if they already know the username of an account with pre-authentication disabled, they can request the AS-REP directly from outside the domain. With domain credentials, the attacker can first enumerate which accounts have the flag set via LDAP, making the attack more targeted.

Key Concepts

Kerberos pre-authentication — the standard mechanism where the client proves knowledge of the password by encrypting a timestamp before the KDC issues any ticket material; this is the control that AS-REP Roasting bypasses
DONT_REQ_PREAUTH flag — the UserAccountControl flag that disables pre-authentication for an account; typically set for legacy application compatibility or misconfiguration, not by deliberate security design
AS-REP encrypted material — when pre-authentication is disabled, the KDC's AS-REP contains a portion encrypted with the account's password hash; this is the material the attacker captures and cracks offline
No credentials required for the request — unlike Kerberoasting, which requires any domain user account, AS-REP Roasting can be performed with only a username and network access to the KDC; domain credentials only help with enumerating which accounts are vulnerable
Difference from Kerberoasting — Kerberoasting targets TGS tickets encrypted with service account passwords; AS-REP Roasting targets AS-REP responses encrypted with the vulnerable account's own password; different protocol stage, different precondition, different target set
Lower prevalence but distinct risk — fewer accounts typically have pre-authentication disabled compared to the number of SPN-bearing service accounts, but the misconfiguration can affect any account type including privileged users

Why It Works

In standard Kerberos authentication, the AS-REQ (Authentication Service Request) includes an encrypted timestamp that proves the client knows the account's password before the KDC issues any ticket material. This is pre-authentication — it prevents an attacker from requesting ticket data for arbitrary accounts because they cannot produce the encrypted timestamp without the password.

When pre-authentication is disabled on an account, the KDC skips this verification and responds to any AS-REQ with encrypted material derived from the account's password hash. The attacker captures this AS-REP and takes it offline for cracking. The encrypted portion uses the account's password hash as the key, so a weak password can be recovered through dictionary or brute-force attacks against the captured material. The KDC issues the response without verifying the requester's identity because the pre-authentication check — the only step that would have prevented this — has been explicitly disabled.

What the Attacker Gains

A successful AS-REP Roast yields the plaintext password of one or more accounts with pre-authentication disabled. The impact depends on the privilege level of the affected accounts. If the account is a standard user, the attacker gains a foothold or an additional credential for lateral movement. If the account is a service account or a member of a privileged group, the impact can be significant — potentially leading to privilege escalation or domain compromise.

The technique is particularly valuable early in an engagement because it can work without domain credentials, and the cracking happens entirely offline with no further interaction with the target environment.

Where It Fits in the Attack Chain

AS-REP Roasting can occur at two points in an engagement. Without domain credentials, an attacker who has obtained a list of usernames (through OSINT, email harvesting, or username enumeration) can attempt AS-REP Roasting from the network without any authenticated access. With domain credentials, the attacker can enumerate accounts with pre-authentication disabled via LDAP and then request AS-REPs for those specific accounts.

In both cases, the technique sits in the credential access phase and often runs in parallel with or shortly after Kerberoasting. The results feed into lateral movement and privilege escalation decisions.

Tools & Examples

Impacket GetNPUsers.py — identifies accounts with pre-authentication disabled and requests AS-REPs; works with or without domain credentials
Rubeus asreproast — Windows-based AS-REP Roasting from a domain-joined host; enumerates vulnerable accounts and extracts crackable hashes
PowerView Get-DomainUser -PreauthNotRequired — enumerates accounts with the DONT_REQ_PREAUTH flag set via LDAP
hashcat -m 18200 — cracks AS-REP hashes (Kerberos 5 AS-REP etype 23) using dictionary or brute-force attacks
Kerbrute userenum — username enumeration tool that can identify valid accounts and check for AS-REP Roasting vulnerability in a single pass

Defender's Perspective

Audit all accounts for the DONT_REQ_PREAUTH flag. In most environments, no account should have pre-authentication disabled unless there is a documented legacy application requirement.
Re-enable pre-authentication on every account where it has been disabled without a current business justification. This is the single most effective remediation.
If pre-authentication must remain disabled for specific accounts, enforce strong passwords (25+ characters) on those accounts and rotate them regularly.
Monitor for AS-REQ traffic without pre-authentication data, particularly from sources outside normal authentication patterns. Event ID 4768 with pre-authentication type 0 indicates an AS-REP Roasting attempt.
Include pre-authentication status in regular privileged account audits to prevent configuration drift.

Communication

How to Explain It in an Interview

AS-REP Roasting targets accounts that have Kerberos pre-authentication disabled.

Pre-authentication is the step where the client proves it knows the password before the KDC issues any ticket material — when it is disabled, the KDC responds to any request for that account with encrypted data derived from the account's password hash. An attacker captures that response and cracks it offline. The key difference from Kerberoasting is the protocol stage and precondition: Kerberoasting targets TGS tickets for service accounts with SPNs, while AS-REP Roasting targets AS-REP responses for any account with pre-authentication disabled. AS-REP Roasting can also be performed without domain credentials if the attacker knows the username, which makes it valuable early in an engagement.

The practical risk depends on which accounts have the flag set and how strong their passwords are — a Domain Admin with pre-authentication disabled and a weak password is a critical finding.

How to Explain It to a Stakeholder

AS-REP Roasting exploits a specific account setting in Active Directory that removes a security check from the login process. When this setting is enabled on an account, anyone on the network can request encrypted password material without providing any credentials, and then attempt to crack the password offline. The setting exists for legacy compatibility reasons, but in most environments it is either a leftover from old configurations or an accidental misconfiguration.

The risk depends on which accounts are affected — if administrative accounts or service accounts have this setting, the attacker may gain privileged access. The fix is straightforward: re-enable the security check on every affected account and enforce strong passwords on any account where the setting must remain disabled.

How It Might Appear in a Report

Finding: Accounts Vulnerable to AS-REP Roasting. During the assessment, the operator identified four accounts with Kerberos pre-authentication disabled (DONT_REQ_PREAUTH). AS-REP requests were submitted for each account, and offline password cracking recovered the plaintext password for the svc_legacy account, which has local administrator access on three application servers. The remaining three accounts had sufficiently strong passwords to resist cracking within the assessment window.

Severity: Medium.

Recommendation: Re-enable Kerberos pre-authentication on all accounts where it is not required for documented legacy compatibility. For accounts where pre-authentication must remain disabled, enforce passwords of at least 25 characters and implement regular rotation. Audit UserAccountControl flags as part of routine privileged account reviews.

Common Weak Answers

Describing AS-REP Roasting as 'like Kerberoasting but different' without explaining what is actually different — the protocol stage (AS vs TGS), the precondition (disabled pre-auth vs SPN), and the target set (any account type vs service accounts).
Not explaining what pre-authentication is or why disabling it creates the vulnerability. The attack only makes sense if you understand that pre-authentication normally prevents the KDC from issuing encrypted material to unauthenticated requesters.
Claiming AS-REP Roasting always leads to high-impact compromise. The real impact depends on which accounts have pre-authentication disabled. In many environments, the affected accounts are low-privilege, which limits the immediate value.
Forgetting that AS-REP Roasting can work without domain credentials. This is a meaningful difference from Kerberoasting and is relevant for explaining where the technique fits in the attack chain.
Treating AS-REP Roasting and Kerberoasting as interchangeable. They target different protocol exchanges, have different preconditions, and yield different types of encrypted material.

Likely Follow-Up Questions

What is Kerberos pre-authentication, and what security purpose does it serve?
How does AS-REP Roasting differ from Kerberoasting in terms of preconditions, protocol stage, and target selection?
Can you perform AS-REP Roasting without any domain credentials? Under what conditions?
Why might an administrator disable pre-authentication on an account, and what would you recommend as an alternative?
If you found a Domain Admin account with pre-authentication disabled but a strong password, would you still report it? Why?

Study Kit