AS-REP Roasting Myths: What Attackers Actually Harvest
AS-REP roasting targets accounts with Kerberos pre-authentication disabled, not weak passwords, and yields offline hashes that never touch the domain controller.
AS-REP roasting exploits accounts where Kerberos pre-authentication is disabled. Attackers request an AS-REP, which returns an encrypted hash they can crack offline. It does not require network sniffing or valid credentials, and it only affects specific misconfigured accounts.
Myth: AS-REP roasting requires network traffic sniffing
Reality: You do not need to intercept packets on the wire to perform AS-REP roasting. The attack is active and direct. An attacker sends a specific request to the domain controller for a target user account. The domain controller responds with an encrypted ticket that includes the user's password hash. This exchange happens over standard Kerberos ports and looks like normal authentication traffic.
The misconception arises because many credential attacks rely on capturing NTLM hashes or session tickets in transit. AS-REP roasting bypasses the need for interception entirely. The attacker initiates the request and receives the data directly from the server. This means that even on a segmented network with strict egress filtering, the attack can succeed if the attacker has IP access to the domain controller.
Myth: Only users with weak passwords are vulnerable
Reality: Password strength is irrelevant to the feasibility of AS-REP roasting. The vulnerability exists solely because the account has the "Do not require Kerberos preauthentication" flag enabled. If this flag is set, the Kerberos Key Distribution Center (KDC) will return an AS-REP encrypted with a weak algorithm, regardless of whether the password is a simple word or a complex string of random characters.
The encryption used for the AS-REP when pre-authentication is disabled is often RC4-HMAC-NT or AES-128-CTS-HMAC-SHA1-96, depending on the domain functional level. These algorithms are computationally inexpensive to crack compared to modern password hashing standards. An attacker can brute-force this hash in minutes or hours, even against a strong password. The weakness lies in the protocol configuration, not the user's choice of characters.
Myth: The attack leaves obvious logs on the domain controller
Reality: AS-REP roasting is notoriously difficult to detect through standard Windows event log monitoring. The attack generates an AS-REQ for a user with pre-authentication disabled. The domain controller processes this request successfully and returns the AS-REP. From the perspective of the operating system, this is a valid authentication request.
Standard security logs record successful and failed logons. They do not typically distinguish between a legitimate user requesting a ticket and an attacker harvesting a hash for offline cracking. The event IDs generated are often the same as those for normal user activity. Without specialized parsing rules that look for the specific combination of a user with pre-auth disabled and a subsequent AS-REP request, the activity blends into background noise.
Myth: AS-REP roasting is the same as Kerberoasting
Reality: These are two distinct attacks that target different parts of the Kerberos protocol. AS-REP roasting targets user accounts that have pre-authentication disabled. Kerberoasting targets service accounts that have Service Principal Names (SPNs) registered.
In Kerberoasting, the attacker requests a Ticket Granting Service (TGS) ticket for a service account. The TGS ticket is encrypted with the service account's password hash. In AS-REP roasting, the attacker requests an initial Authentication Service (AS) request. The response is encrypted with the user's password hash. The mechanisms, the targets, and the resulting hash types are different. Confusing the two leads to ineffective defense strategies, as the remediation for one does not fix the other.
Myth: Disabling the affected account stops the attack
Reality: Disabling the account is a valid remediation, but it is not the only step. Simply disabling the account prevents further abuse but does not address the root cause: the existence of accounts with pre-authentication disabled. Attackers often scan for these accounts during initial attacker reconnaissance. If you disable one account, the attacker moves to the next.
The true fix is to identify all accounts in the directory that have the "Do not require Kerberos preauthentication" flag set. You must then enable pre-authentication for these accounts or remove them if they are unnecessary. This requires auditing the Active Directory database. Leaving even one account in this state leaves the door open for the same technique.
See also: How Phishing Simulations Work: Mechanics, Blindsides, and Limits · Open-Source Intelligence Benefits and Trade-Offs
Myth: This attack only affects legacy systems
Reality: AS-REP roasting works on modern Windows Server versions. The Kerberos protocol has remained largely consistent in this regard. While newer domain functional levels support stronger encryption types, the fundamental behavior of accounts with pre-authentication disabled remains exploitable.
Many organizations migrate to newer server versions without auditing legacy account configurations. Accounts created years ago may still have pre-authentication disabled due to compatibility requirements for older applications or services. These accounts persist in the directory and remain vulnerable. The age of the server operating system does not mitigate the risk if the account configuration is misaligned with modern security standards.
| Myth | Reality |
|---|---|
| Requires network sniffing | Direct request to domain controller |
| Targets weak passwords | Targets pre-authentication disabled flag |
| Leaves obvious logs | Blends into normal Kerberos traffic |
| Same as Kerberoasting | Different protocol stage and target |
| Fixed by disabling account | Requires enabling pre-authentication |
| Only affects legacy systems | Works on modern Windows Server versions |
How to verify your exposure
You can check for vulnerable accounts by querying the Active Directory for the specific user attribute. The attribute is userAccountControl. The bit value for "Do not require Kerberos preauthentication" is 4194304. If this bit is set, the account is vulnerable.
Use PowerShell or LDAP queries to find these accounts. Do not rely on visual inspection of the account properties in the GUI, as this is error-prone in large directories. Automate the search to ensure you catch all instances. Once identified, evaluate whether pre-authentication can be enabled. If an application requires it to be disabled, consider isolating that account or using a different authentication method.
This audit process is part of broader network enumeration. It helps you understand the attack surface before an adversary does. Regular audits are necessary because new accounts are created and configurations change over time.
Key takeaways
- The attack targets the Kerberos protocol configuration, not password complexity.
- Cracking happens offline, leaving no immediate trace on the domain controller.
- Disabling pre-authentication is the sole prerequisite for this specific vector.
AS-REP roasting exploits a specific Kerberos configuration, not password strength or network visibility. Audit your directory for accounts with pre-authentication disabled and enable it immediately.
Frequently asked questions
Does AS-REP roasting work on Windows 11 clients?
The attack targets the domain controller's response, not the client OS. Any client that can reach the domain controller can perform the request.
Can I use breach and attack simulation to test for this?
Yes, simulation platforms can execute AS-REP roasting techniques to verify if vulnerable accounts exist and if detection rules trigger.
Is AS-REP roasting related to golden ticket attacks?
No. Golden tickets involve forging a Ticket Granting Ticket using the KRBTGT hash. AS-REP roasting harvests user password hashes for offline cracking.
Do ISACs share data about AS-REP roasting?
Information Sharing and Analysis Centers focus on threat intelligence. They may share indicators of compromise, but AS-REP roasting is a technique, not a specific threat actor signature.
How this guide was produced: written by the Firewall Chronicle 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.
