AS-REP Roasting is an Active Directory attack technique that targets user accounts configured without Kerberos pre-authentication. When pre-authentication is disabled, an attacker may be able to request authentication response material for the account and attempt to crack the encrypted response offline.
The attack is dangerous because it does not require interactive login to the vulnerable account. If the account has a weak password, reused password, privileged access, service-account permissions, or access to sensitive systems, AS-REP Roasting can become the first step in a larger Active Directory compromise path.
AS-REP Roasting is especially relevant during internal penetration testing, red team operations, Active Directory reviews, and identity-security assessments because it exposes weaknesses in account hygiene, Kerberos configuration, password policy, service-account management, and detection coverage.
Redbot Security validates AS-REP Roasting exposure through internal and external penetration testing, red team operations, MITRE ATT&CK adversary simulation, manual penetration testing, attack-chain validation, and cloud security testing.
What Is AS-REP Roasting?
AS-REP Roasting is a Kerberos-based attack against Active Directory accounts that have the “Do not require Kerberos preauthentication” setting enabled.
In a normal Kerberos authentication flow, pre-authentication helps prove that the user knows the password before the domain controller returns encrypted authentication material. When pre-authentication is disabled, the domain controller may return an AS-REP response that is encrypted with material derived from the user’s password.
Attackers can capture that response and attempt to crack it offline. If the password is weak or reused, the attacker may recover the plaintext password and use it for domain access, lateral movement, privilege escalation, or further attack chaining.
The vulnerability exists when accounts are configured without Kerberos pre-authentication and have passwords that can be cracked offline.
Why Kerberos Pre-Authentication Matters
Kerberos pre-authentication is designed to prevent unauthenticated users from requesting password-derived authentication material for arbitrary accounts.
When pre-authentication is enabled, the user must prove knowledge of the password before the Key Distribution Center returns the authentication response. This reduces the ability for attackers to collect crackable material without first knowing the password.
| Kerberos Setting | Security Behavior | Risk |
|---|---|---|
| Pre-Authentication Enabled | User must prove knowledge of the password before receiving authentication material | Reduces AS-REP Roasting exposure |
| Pre-Authentication Disabled | Authentication response may be requested without first proving password knowledge | Enables offline password-cracking attempts |
| Weak Password | Password-derived encryption may be cracked offline | Can expose plaintext credentials |
| Privileged Account | Recovered password may provide elevated access | Can accelerate domain compromise |
| Service Account | Long-lived passwords and broad access increase impact | Can support persistence and lateral movement |
Disabling Kerberos pre-authentication should be rare, justified, documented, monitored, and reviewed regularly.
How AS-REP Roasting Works
AS-REP Roasting begins with identifying Active Directory accounts that do not require Kerberos pre-authentication. Depending on domain exposure and available access, this may be attempted from an unauthenticated or authenticated perspective.
Once vulnerable accounts are identified, authentication response material can be requested from the domain controller. That material can then be subjected to offline password-cracking attempts. If the password is recovered, the attacker may use it to authenticate normally.
| Attack Stage | What Happens | Defensive Concern |
|---|---|---|
| Account Discovery | Attacker identifies accounts without Kerberos pre-authentication | Weak account hygiene or unnecessary legacy settings |
| AS-REP Request | Authentication response material is requested from the domain controller | Suspicious Kerberos request behavior |
| Offline Cracking | Encrypted response material is tested against password guesses offline | Weak passwords or reused service-account passwords |
| Credential Use | Recovered password is used for authentication | Credential reuse, lateral movement, and privilege escalation |
| Attack Chaining | Access is combined with other weaknesses | Domain exposure, cloud access, SaaS access, or sensitive data compromise |
A concrete representation of this concept can be observed in Figure 1, where the developers of CrackMapExec provide an example of an AS-REP Roasting attack.
Conversely, an alternative approach to executing the attack involves authentication. If active credentials are accessible within a specific domain, this avenue enables the acquisition of hash values for susceptible accounts, thereby laying bare their vulnerabilities. This process is demonstrated in Figure 2, depicting the outcome of an authentication-based attack.
Unauthenticated vs Authenticated AS-REP Roasting
AS-REP Roasting can appear in two broad testing contexts: unauthenticated discovery and authenticated domain testing. The feasibility depends on domain configuration, network access, enumeration exposure, and whether valid domain credentials are already available.
| Testing Context | Description | Security Meaning |
|---|---|---|
| Unauthenticated | Attacker attempts to identify roastable accounts without valid domain credentials | May indicate excessive exposure or weak domain enumeration controls |
| Authenticated | Attacker uses valid domain access to enumerate and request material for vulnerable accounts | Shows what a low-privilege foothold can unlock |
| Internal Testing | Assessment validates exposure from inside the network or domain context | Helps measure post-compromise risk |
| Red Team Validation | Technique is tested as part of a larger attack objective | Shows whether identity controls detect and stop real attacker behavior |
The authenticated scenario is especially important because many breaches begin with one low-privilege credential. AS-REP Roasting may then help attackers find additional passwords and expand access.
Why AS-REP Roasting Is Dangerous
AS-REP Roasting is dangerous because it turns an account configuration issue into an offline password attack. Once response material is collected, attackers can attempt cracking without continuously interacting with the domain controller.
If the vulnerable account uses a weak password, a reused password, or a long-lived service-account password, the attacker may recover credentials that provide meaningful access.
| Risk Driver | Business Impact |
|---|---|
| Weak Passwords | Recovered credentials can allow unauthorized domain access |
| Service Accounts | Long-lived passwords may expose applications, servers, databases, or scheduled tasks |
| Privileged Users | Recovered passwords can enable rapid privilege escalation |
| Password Reuse | One cracked password may work across VPN, cloud, SaaS, endpoints, or admin tools |
| Poor Monitoring | Kerberos request activity and subsequent credential use may go unnoticed |
| Attack Chaining | Recovered credentials can be combined with internal weaknesses, cloud exposure, or lateral movement |
The finding should be evaluated based on password strength, account privileges, service dependencies, reuse risk, and what the account can access.
Service Accounts and AS-REP Roasting Risk
Service accounts are a frequent concern in Kerberos-related attacks because they often have long-lived passwords, broad permissions, limited monitoring, unclear ownership, and dependencies that make rotation difficult.
If a service account does not require Kerberos pre-authentication and uses a weak password, AS-REP Roasting can expose credentials that unlock applications, servers, databases, scheduled tasks, file shares, or cloud-connected workflows.
Managed service accounts, strong passwords, least privilege, ownership tracking, and rotation procedures help reduce this risk.
Detection Opportunities
Detecting AS-REP Roasting requires visibility into Kerberos activity, domain controller logs, account configuration, endpoint behavior, and subsequent credential use.
Defenders should monitor for unusual authentication service requests involving accounts that do not require pre-authentication, especially from unexpected systems, unusual users, or abnormal network locations.
| Detection Area | What to Monitor |
|---|---|
| Kerberos AS-REQ / AS-REP Activity | Requests for accounts without pre-authentication, unusual request volume, or unexpected source hosts |
| Account Configuration | Accounts with “Do not require Kerberos preauthentication” enabled |
| Domain Controller Events | Authentication patterns involving vulnerable accounts and suspicious Kerberos activity |
| Password Cracking Indicators | Follow-on successful logins after unusual Kerberos request behavior |
| Service Account Behavior | Interactive logins, unusual host access, unexpected process activity, or off-hours use |
| Attack Chaining | Credential use followed by lateral movement, privilege escalation, cloud access, or sensitive data access |
Detection should focus not only on the AS-REP request, but also on what happens after credentials are recovered or reused.
Mitigation and Hardening
Preventing AS-REP Roasting starts with eliminating unnecessary accounts that do not require Kerberos pre-authentication. Organizations should review the setting regularly, especially for privileged users, service accounts, and legacy accounts.
| Control | Security Objective |
|---|---|
| Require Kerberos Pre-Authentication | Disable unnecessary “Do not require Kerberos preauthentication” settings |
| Strong Password Policy | Reduce the likelihood of successful offline cracking |
| Service Account Governance | Track ownership, permissions, dependencies, and rotation procedures |
| Managed Service Accounts | Use managed identity options where appropriate to reduce static password exposure |
| Least Privilege | Limit what vulnerable or service accounts can access if compromised |
| Monitoring and Alerting | Detect unusual Kerberos requests and follow-on credential use |
| Retesting | Confirm that vulnerable accounts are remediated and detection works |
Strong passwords help, but the better control is to require Kerberos pre-authentication and reduce unnecessary exposure across all accounts.
AS-REP Roasting in Attack Chains
AS-REP Roasting is often one piece of a larger attack path. The recovered password may enable VPN access, internal application access, cloud access, lateral movement, privilege escalation, or further Active Directory attacks.
This is why the finding should not be evaluated only as a configuration issue. It should be evaluated based on the account’s access, where the password is reused, what systems trust the account, and whether monitoring detects suspicious use.
Related guidance includes Chaining Low-Risk Findings Into Breaches, Living off the Land Attacks Explained, and NTLM Relaying and AD CS Attack Paths.
How Redbot Validates AS-REP Roasting Risk
Redbot Security validates AS-REP Roasting exposure by identifying accounts without Kerberos pre-authentication, evaluating account privilege, reviewing service-account hygiene, testing detection visibility, and determining whether recovered credentials could support broader attack paths.
The objective is to understand whether vulnerable account configurations can become real business risk through password cracking, credential reuse, internal access, cloud access, lateral movement, or privilege escalation.
| Assessment Area | Redbot Validation Focus |
|---|---|
| Account Discovery | Identify users and service accounts that do not require Kerberos pre-authentication |
| Privilege Review | Determine whether vulnerable accounts have sensitive access, group membership, or service dependencies |
| Password Risk | Evaluate whether password policy and account hygiene reduce offline cracking risk |
| Attack-Path Analysis | Assess what the account could access if the password were recovered |
| Detection Testing | Validate whether Kerberos request behavior and follow-on credential use generate alerts |
| Remediation and Retesting | Confirm vulnerable configurations are corrected and controls are operating effectively |
Redbot delivers practical evidence, risk context, remediation guidance, and retesting support so organizations can reduce Active Directory credential exposure before attackers exploit it.
What is AS-REP Roasting?
AS-REP Roasting is an Active Directory attack technique that targets accounts configured without Kerberos pre-authentication, allowing attackers to request encrypted authentication material and attempt offline password cracking.
Why does disabling Kerberos pre-authentication create risk?
Disabling Kerberos pre-authentication may allow authentication response material to be requested without proving knowledge of the password first, creating an offline password-cracking opportunity.
Does AS-REP Roasting require valid domain credentials?
AS-REP Roasting may be attempted from unauthenticated or authenticated contexts depending on the environment. Authenticated testing is common during internal assessments because valid low-privilege access can reveal vulnerable accounts.
Why are service accounts risky in AS-REP Roasting?
Service accounts are risky because they often have long-lived passwords, broad permissions, unclear ownership, and dependencies that make password rotation difficult.
How can organizations prevent AS-REP Roasting?
Organizations can reduce AS-REP Roasting risk by requiring Kerberos pre-authentication, enforcing strong passwords, governing service accounts, using managed service accounts where appropriate, applying least privilege, and monitoring Kerberos activity.
What should be monitored for AS-REP Roasting?
Security teams should monitor accounts without Kerberos pre-authentication, unusual AS-REQ and AS-REP activity, unexpected source hosts, suspicious service-account behavior, and follow-on credential use.
How does Redbot Security test AS-REP Roasting risk?
Redbot Security tests AS-REP Roasting risk through internal penetration testing, Active Directory account review, service-account hygiene analysis, attack-path validation, detection testing, remediation guidance, and retesting.
References
Internal Penetration Testing
Active Directory, credential exposure, lateral movement, and privilege-path validation.
Red Team Operations
Objective-driven adversary simulation and control validation.
Cloud Testing
Cloud IAM, hybrid identity, service-account, and trust-path validation.
Application & API Testing
Web and API penetration testing for real attack paths.
AI / LLM Security
AI workflow, prompt injection, RAG, and agent testing.
Redbot Social