TTechniqueActiveDirectory
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.
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.
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.
MITRE · Official MITRE ATT&CK reference for AS-REP Roasting, including detection guidance and procedure examples
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.
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.
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.
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.
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.
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.