AS-REP Roasting Warning Signs: What to Watch for First
AS-REP roasting leaves subtle traces in authentication logs that reveal whether an account lacks pre-authentication requirements.
Look for Kerberos pre-authentication failures paired with offline hash cracking attempts. Monitor for accounts with the Do Not Require Kerberos Preauthentication flag enabled. Check for unusual TGT requests from non-domain controllers.
The First Glitch in Authentication Logs
The earliest sign of AS-REP roasting is a spike in specific authentication failures. You will see error codes related to Kerberos pre-authentication. These errors appear when a client requests a Ticket Granting Ticket but skips the initial proof of identity step.
Kerberos pre-authentication is a security check that proves the user knows their password before the server issues a ticket. When this step is skipped, the server returns an encrypted response. This response can be cracked offline. If you notice a cluster of these failures for a single account, an attacker is likely harvesting the hash.
Hidden Flags in Account Properties
Some accounts are configured to allow this behavior intentionally. The property is called Do Not Require Kerberos Preauthentication. Administrators sometimes enable this for legacy applications or service accounts that cannot handle modern authentication flows.
An attacker performing attacker reconnaissance will scan for these accounts. They do not need to guess a password to start the attack. They simply request a ticket and receive the encrypted data. The danger lies in the fact that these accounts often have high privileges or access to sensitive resources.
The Silence After the Request
A subtle sign is the lack of follow-up activity. After the initial request, the attacker leaves the network. They take the encrypted hash to their own machine to crack it. This means you will not see immediate login attempts from the compromised account.
This delay creates a blind spot. Traditional alerts look for failed logins followed by successful ones. AS-REP roasting breaks this pattern. The theft happens in the first request. The exploitation happens later, potentially on a different network segment.
Correlating Network Traffic Patterns
Network traffic analysis can reveal the source of these requests. The attacker sends a specific Kerberos message type to the domain controller. This message is larger than a standard login attempt because it contains the encrypted response.
You can filter logs for this message type. Look for requests originating from workstations that do not typically access domain controllers. Servers and admin stations are expected clients. A developer laptop or a compromised IoT device is not.
The volume of these requests is also telling. An attacker will often target multiple accounts in a short window. A burst of requests from a single IP address suggests automated scanning. This is a strong indicator of malicious intent rather than a misconfigured application.
The Impact on Credential Security
Once the hash is cracked, the attacker gains the plaintext password. This leads to direct credential theft. The attacker can then log in as that user. They may escalate privileges or move laterally.
This attack bypasses many standard defenses. Multi-factor authentication is often not triggered for the initial hash extraction. The attacker only needs the password for the final login. If the password is weak, the entire security posture of that account collapses.
See also: Incident Triage Meaning: How to Prioritize Alerts Fast
Responding to Detected Activity
When you identify these signs, immediate action is required. First, disable the affected accounts if they are not critical. This stops the attacker from using the cracked credentials. Second, reset the passwords for any accounts that had the pre-authentication flag enabled.
You should also review the audit logs for the past few days. Look for any successful logins from those accounts. This helps determine if the attacker already gained access. If you find successful logins, assume the environment is compromised.
| Sign | What it usually means | What to do |
|---|---|---|
| Pre-authentication failures | Attacker requesting AS-REP hashes | Audit account properties for pre-auth flags |
| Burst of requests from one IP | Automated scanning for vulnerable accounts | Block the source IP and investigate the host |
| No follow-up logins | Offline hash cracking in progress | Monitor for new login attempts from known IPs |
| Service account involvement | High-value target for privilege escalation | Reset credentials and review service permissions |
Preventing Future Exploitation
The most effective defense is to enforce Kerberos pre-authentication on all accounts. This setting should be the default. Only disable it if you have a technical requirement that cannot be met otherwise.
Regularly audit your domain for accounts with this flag enabled. Use scripts to scan the directory and report any violations. This reduces the attack surface significantly. It forces attackers to rely on brute-force attacks, which are easier to detect and block.
Integrate these checks into your security operations. You can use breach and attack simulation tools to test your defenses. These tools mimic the AS-REP roasting process without causing harm. They help you verify that your monitoring rules are working.
False positives in threat detection can clutter your alerts. Ensure your rules distinguish between legitimate pre-authentication errors and malicious bursts. Tune your thresholds to avoid alert fatigue. This allows your team to focus on real threats.
Understanding the Threat Model
AS-REP roasting is a form of credential theft. It exploits a weakness in the Kerberos protocol implementation. The weakness exists when accounts are configured to skip pre-authentication. This configuration is rare in modern environments but still present.
The attack is part of a broader campaign. It is often combined with pass-the-ticket attacks. Once the attacker has the ticket, they can impersonate the user. This makes detection difficult because the authentication appears valid.
Defending against this requires a deep understanding of Kerberos. You must monitor the authentication layer, not just the application layer. This approach aligns with the Pyramid of Pain concept. It forces attackers to change their tactics because simple hash extraction no longer works.
Key takeaways
- The primary indicator is a surge in Kerberos pre-authentication failures for specific user accounts.
- Attackers often target service accounts or disabled users that lack pre-authentication requirements.
- Defenders should audit account properties and monitor for offline hash extraction behaviors.
AS-REP roasting exploits accounts that skip Kerberos pre-authentication, allowing offline password cracking. Enforce pre-authentication on all accounts and monitor for bursts of authentication failures to detect early activity.
Frequently asked questions
How do I check if an account requires Kerberos pre-authentication?
You can use PowerShell commands to query the userAccountControl flag for the specific account and check for the pre-authentication bit.
Can multi-factor authentication stop AS-REP roasting?
MFA does not prevent the initial hash extraction, but it can block the subsequent login if the attacker does not have the second factor.
What is the difference between AS-REP roasting and Kerberoasting?
AS-REP roasting targets accounts without pre-authentication, while Kerberoasting targets service accounts with SPNs by requesting service tickets.
How long does it take to crack an AS-REP hash?
The time depends on the password complexity and the attacker's hardware, ranging from seconds to years for strong passwords.
How this guide was produced: written by the Sandbox Dispatch 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.
