AS-REP Roasting Response: Containment, Recovery and Prevention Steps
Forcing password resets does not stop an attacker who already holds the offline hash, requiring a specific protocol change to invalidate the stolen data.
Detect the Kerberos pre-authentication bypass. Isolate affected accounts immediately. Do not reset passwords yet. Disable Kerberos pre-authentication for the account to invalidate the stolen hash. Monitor for decryption attempts. Enable pre-authentication after investigation.
Identifying the Attack Vector
AS-REP roasting exploits a configuration weakness in Microsoft Active Directory. When an account has "Do not require Kerberos preauthentication" enabled, the Key Distribution Center returns an encrypted Authentication Service Reply without verifying the user’s identity. This reply is encrypted with the user’s password hash. An attacker captures this reply and cracks the hash offline. You cannot stop the cracking process once the data leaves the network. The attack leaves no immediate sign of compromise on the client machine. The evidence exists only in the directory service logs and network traffic.
First Hour
The first hour determines whether the attacker gains persistent access. You must act quickly but precisely. Rushing leads to unnecessary disruption and missed evidence.
- Identify all accounts with Kerberos pre-authentication disabled.
- Check directory logs for AS-REP requests from unusual workstations.
- Isolate the source workstation that sent the requests.
- Disable the compromised account temporarily to stop further requests.
- Preserve memory dumps from the source machine for forensic analysis.
First Day
Containment requires shifting from network isolation to credential invalidation. The stolen hash remains useful until the underlying authentication mechanism changes. You must alter the account properties in Active Directory.
- Disable the "Do not require Kerberos preauthentication" setting for the affected account.
- Force a password change for the user.
- Clear cached credentials on all devices where the user has logged in.
- Review group memberships to assess privilege escalation potential.
Changing the pre-authentication setting forces the Key Distribution Center to require proof of identity before issuing the encrypted reply. This makes the previously captured reply useless. The attacker can no longer use the static hash to request tickets. This step renders the offline cracking effort futile.
First Week
Recovery involves verifying that no lateral movement occurred. The attacker may have used the cracked password before you disabled the account. You must audit the user’s activity during the window between the request and the containment.
- Review login events for the account across all servers.
- Check for new service principal names added by the user.
- Inspect scheduled tasks for persistence mechanisms.
- Analyze network flows for command and control traffic originating from the user’s context.
Imagine the attacker cracked the hash within minutes. They could have authenticated to file servers or domain controllers. You need to look for actions that exceed normal user behavior. Focus on administrative tasks, data exports, and configuration changes. Use tools like Sysmon to correlate process creation with logon events. This depth of analysis reveals hidden persistence.
Who to Tell
Notification depends on the scope of the breach. If the account belongs to a service, the impact is higher. Service accounts often have broader permissions. You must inform the system owners of the affected services.
- Notify the identity management team to review similar accounts.
- Alert the network operations center to monitor for replay attacks.
- Inform legal and compliance if sensitive data was accessible.
- Engage incident response vendors if internal resources are stretched.
Clear communication prevents duplicate efforts. Each team needs specific information. The identity team needs account details. The network team needs IP addresses. Legal needs timelines. Do not share raw forensic data with non-technical stakeholders. Provide summaries of impact and remediation status.
See also: AI Hallucination Incident Response and Recovery Steps · Incident Communication Plans: How to Stop Chaos When Systems Fail
Stopping a Repeat
Prevention requires changing how you manage account security. The default setting in modern Windows versions requires pre-authentication. Legacy systems or misconfigurations often leave this disabled. You must audit your entire directory.
| Configuration | Risk Level | Action |
|---|---|---|
| Pre-auth required | Low | Maintain default settings |
| Pre-auth disabled | High | Enable pre-authentication |
| Empty password | Critical | Remove or secure account |
Regular audits catch drift. Scripts can check for misconfigured accounts. Integrate these checks into your continuous monitoring. Use Snort and Suricata rules to detect AS-REP requests in real time. This provides early warning before cracking occurs. Reference the MITRE ATT&CK Navigator to map these controls to defensive techniques. This ensures your strategy aligns with industry standards.
Analyzing the Impact
Not all AS-REP roasting leads to compromise. Some accounts have weak passwords that crack instantly. Others take years. You must assess the likelihood of compromise based on password complexity.
- Check password age and complexity policies.
- Review the time between the request and detection.
- Analyze the attacker’s infrastructure for decryption tools.
- Determine if the account had access to sensitive data.
If the password was complex, the attacker may not have cracked it yet. However, you must assume compromise until proven otherwise. This conservative approach protects your organization. It also provides a clear audit trail for future reviews. Document every step. This documentation helps in post-incident reviews and improves future responses.
Long-Term Hygiene
Security is a continuous process. AS-REP roasting is just one vector. You must strengthen your overall identity posture. Implement multi-factor authentication for all administrative accounts. This adds a layer of security that password hashing cannot bypass.
Monitor for scheduled task abuse as a secondary persistence method. Attackers often use these tasks to maintain access after initial compromise. Regularly review service accounts for unnecessary privileges. Remove any that are no longer needed. This reduces the attack surface. Refer to ISACs for shared threat intelligence on emerging tactics. This keeps your defenses updated.
Key takeaways
- Password resets fail to revoke offline hashes obtained via AS-REP roasting.
- Disabling Kerberos pre-authentication is the only way to invalidate the stolen ticket request.
- Monitoring for decryption attempts reveals if the attacker has moved laterally or exfiltrated data.
Disabling Kerberos pre-authentication invalidates stolen hashes faster than password resets. Audit all directory accounts to ensure pre-authentication is required by default.
Frequently asked questions
Does AS-REP roasting work on Windows 10 or 11?
Yes, if the user account is configured to not require pre-authentication. The operating system version does not prevent this protocol behavior.
Can I detect AS-REP roasting with standard firewalls?
Standard firewalls may not inspect internal Kerberos traffic. You need endpoint detection or network monitoring tools that understand protocol specifics.
How long does it take to crack an AS-REP hash?
It depends on password complexity and attacker resources. Simple passwords crack in seconds. Complex ones may take years or remain uncracked.
Should I disable all accounts with pre-auth disabled?
No. Some legacy applications require this setting. Instead, enable pre-authentication, reset the password, and update the application configuration.
How this guide was produced: written by the TechSec Feed 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.
