AS-REP roasting exploits accounts with pre-authentication disabled. An attacker requests a ticket, receives an encrypted response, and cracks the password offline. This bypasses server-side lockout policies and leaves minimal trace in standard audit logs until the password is actually used.
The Kerberos Pre-Authentication Gap
Kerberos is the default authentication protocol for Windows domains. It relies on a Key Distribution Center to issue tickets that prove identity. Normally, a user must prove they know their password before the server issues any useful data. This step is called pre-authentication. It ensures that the server only sends encrypted data to someone who can decrypt it. If an account has this requirement disabled, the server skips the proof step. This creates a vulnerability known as AS-REP roasting. The system assumes the user is valid and sends back a ticket encrypted with the user’s password hash. An attacker can capture this ticket and crack it later.
Stage 1: Target Identification
The attacker begins by finding accounts that allow pre-authentication bypass. This is a configuration choice, often made for legacy service accounts or automated systems that cannot handle the extra handshake. The attacker queries the domain controller for a list of users. They filter for the "Do not require Kerberos preauthentication" flag. This flag is a boolean setting in the user object attributes. Finding these accounts is passive and does not trigger security alerts. The attacker now has a list of potential targets. They prioritize accounts with high privileges, as cracking these yields greater access.
Stage 2: The AS-REQ Request
The attacker initiates a standard Kerberos request to the Key Distribution Center. They send an AS-REQ message for the target account. This message asks for a Ticket-Granting Ticket. Because pre-authentication is disabled for this user, the server does not demand proof of identity. The server processes the request as if it were legitimate. It generates a session key and encrypts it using the target user’s password hash. The server then sends this encrypted data back to the attacker in an AS-REP message. The attacker receives this response without needing to provide any credentials.
Stage 3: Offline Password Cracking
The attacker now possesses the encrypted ticket. This ticket contains the session key, encrypted with the user’s password. The attacker takes this data offline to their own machine. They use a cracking tool to perform a dictionary or brute-force attack against the hash. This process is entirely local. The domain controller is no longer involved. The attacker tries millions of password guesses per second. If the user’s password is weak, the hash will match a guess. The attacker then recovers the plaintext password. This step can take seconds or days, depending on password complexity. No server resources are consumed during this phase.
Stage 4: Credential Verification and Access
Once the password is recovered, the attacker has valid credentials for the domain. They can now log in to any system where that account has permissions. This is the point of compromise. The attacker may use the password to log in via RDP or SMB. They may also use it to request new Kerberos tickets for other services. The initial roasting attack is now complete. The value of the attack is realized through the subsequent access. The attacker can move laterally, escalate privileges, or exfiltrate data. The original AS-REP request remains hidden in the noise of normal traffic.
| Stage | What happens | Where it can be stopped |
|---|---|---|
| Target ID | Attacker queries for users with pre-auth disabled. | Enforce pre-auth on all accounts. |
| Request | Attacker sends AS-REQ to KDC. | Block AS-REQ from untrusted networks. |
| Response | Server sends encrypted AS-REP. | Detect AS-REP traffic volume spikes. |
| Cracking | Attacker cracks hash offline. | Enforce complex password policies. |
| Access | Attacker logs in with recovered password. | Monitor for impossible travel or anomalous logins. |
See also: Implement Deception Technology: A Step-by-Step Operational Guide · Diamond Model of Intrusion Analysis Explained Simply
Interrupting the Attack Chain
Defenders must address both the configuration flaw and the detection gap. The primary defense is configuration. Every account should require Kerberos pre-authentication. This forces the server to verify identity before sending any sensitive data. If an attacker tries to request a ticket for a protected account, the server will reject the request without sending the encrypted payload. This breaks the attack at Stage 2. You must audit your directory regularly to ensure no new accounts are created with this flag enabled. Automation helps maintain this baseline.
The Hidden Cost of Weak Policies
The real risk is not the request itself, but the offline nature of the cracking. Traditional defenses like account lockout policies are useless here. The server sees only one request. The millions of password guesses happen on the attacker’s machine. This means a weak password is as vulnerable as if the attacker were at the login prompt. The trade-off for convenience in legacy systems is severe. You cannot detect the cracking attempt. You can only detect the result. This shifts the burden to strong password complexity and length. Short passwords will always fail against this technique.
Detecting the Silent Request
Network monitoring can reveal the initial request. AS-REP roasting generates specific traffic patterns. A sudden spike in AS-REQ messages for accounts that rarely authenticate is a strong indicator. You can use packet capture analysis to inspect the raw packets. Look for requests to accounts that are not interactive users. Service accounts rarely request TGTs directly. If they do, it is often abnormal. Correlate this with log tampering attempts. Attackers may try to delete logs after gaining access. Early detection of the request allows you to reset the password before the crack succeeds.
Integrating with Broader Defense Strategies
This attack is a specific Tactic, Technique, and Procedure (TTP) used by many groups. Understanding it helps in adversary emulation exercises. You can simulate this attack to test your detection capabilities. It also fits into the Diamond Model of intrusion analysis. The capability is the roasting tool, the infrastructure is the attacker’s machine, the victim is the domain, and the act is the AS-REQ request. Incident triage becomes faster when you recognize the pattern. Deception technology can also help. You can create honey accounts with pre-auth disabled. When an attacker roasts these, you know they are present.
The Role of Password Complexity
Since the cracking happens offline, password strength is your last line of defense. Simple passwords are cracked instantly. Complex, long passwords make the cracking process computationally expensive. The attacker may give up if the hash does not yield a result quickly. This does not stop the attack, but it mitigates the impact. You must balance usability with security. Service accounts should use managed identities or certificates instead of passwords. This removes the password from the equation entirely. If the account has no password, it cannot be roasted.
Beyond the Initial Compromise
Once the password is known, the attacker acts like a legitimate user. Standard monitoring must catch this. Look for logins at unusual times or from unusual locations. Check for access to sensitive resources. The AS-REP roasting attack is just the entry point. The real damage comes from what the attacker does next. You must assume that any account with pre-auth disabled is already compromised. Reset the password immediately. Audit the account’s activity for the past 90 days. Check for any lateral movement or data exfiltration. This proactive approach limits the blast radius.
Summary of Defensive Actions
Stop AS-REP roasting by enforcing pre-authentication on all accounts. Monitor network traffic for abnormal AS-REQ patterns. Use strong, complex passwords to increase cracking time. Implement managed identities for service accounts. Detect the initial request before the password is cracked. Respond to any compromise by resetting passwords and auditing activity. This layered approach protects against the offline nature of the attack. You cannot prevent the request if the configuration is wrong, but you can make the result unusable.
Key takeaways
- The attack relies on the AS-REP protocol allowing requests without prior proof of identity for specific user accounts.
- Cracking happens offline, meaning brute-force attempts do not trigger account lockout mechanisms on the domain controller.
- Defenders can stop this by enforcing pre-authentication requirements or detecting the specific request pattern in network traffic.
Frequently asked questions
Does AS-REP roasting work on all Windows versions?
Yes, it works on any version that uses Kerberos for authentication, as long as the account has pre-authentication disabled.
Can I detect AS-REP roasting with SIEM alone?
Standard SIEM logs may not show enough detail. You often need network packet data or specific Kerberos audit logs enabled on the domain controller.
Is disabling pre-authentication ever safe?
It is rarely safe. Only do it if the application strictly requires it and you have compensating controls like network segmentation and strong monitoring.
How do I fix accounts that already have this flag enabled?
Enable the pre-authentication requirement in the user properties. Force the user to change their password immediately to invalidate any existing tickets.
How this guide was produced: written by the SecOps Monitor editorial team with AI assistance, checked against the public references listed below, and reviewed when the facts change. See our editorial policy or report an error.
