AS-REP Roasting: Hacking Techniques to Gain Access to Kerberos Accounts Without Passwords

To comprehend AS-REP Roasting, one must first understand the standard Kerberos authentication flow in a Windows domain. The process involves three main entities: the Client (user), the Service (resource being accessed), and the Key Distribution Center (KDC), which is a service running on the Domain Controller.

The Standard Authentication Flow

When a user attempts to log into the domain, the following sequence occurs:

1. AS-REQ (Authentication Service Request): The client sends a request to the KDC. Crucially, in a standard configuration, this request includes a timestamp encrypted with the user's password hash (specifically, their NTLM hash). This step is known as Kerberos Pre-Authentication. It proves to the KDC that the user actually knows their password before any further communication occurs.
2. AS-REP (Authentication Service Reply): The KDC receives the AS-REQ, looks up the user's hash in the Active Directory database, and attempts to decrypt the timestamp. If successful, the KDC knows the user is authentic. The KDC then replies with an AS-REP. This reply contains a Ticket-Granting Ticket (TGT) and a session key, part of which is encrypted with the user's password hash.
3. TGS-REQ & TGS-REP: The client uses the TGT to request access to a specific service (like a file share) and receives a Ticket-Granting Service (TGS) ticket in return.
4. AP-REQ: The client presents the TGS ticket to the target service to gain access.

The vulnerability that enables AS-REP Roasting hinges entirely on the first step: Kerberos Pre-Authentication.

By default, Active Directory requires pre-authentication for all user accounts. This prevents attackers from blindly requesting TGTs for users. Because the attacker doesn't know the user's password, they cannot encrypt the timestamp required in the AS-REQ, and the KDC will reject the request.

However, administrators sometimes disable this requirement for specific accounts. This is usually done to support legacy applications or systems (such as old UNIX machines or specific network appliances) that do not support the Kerberos Pre-Authentication standard. In Active Directory, this is controlled by a specific User Account Control (UAC) attribute: Do not require Kerberos preauthentication (DONT_REQ_PREAUTH).

When this setting is enabled for a user account, the security dynamic shifts drastically, opening the door for AS-REP Roasting.

If an attacker identifies an account with pre-authentication disabled, they can execute the AS-REP Roasting attack. The process is elegant in its simplicity and devastating in its effectiveness.

Step 1: Identifying Vulnerable Accounts

The attacker, having already gained some level of initial access to the network (even with a standard, unprivileged user account), will query the Active Directory database (often via LDAP) to find accounts with the DONT_REQ_PREAUTH flag set. Tools like PowerView or BloodHound are frequently used to map the domain and easily identify these misconfigured accounts.

Step 2: Requesting the AS-REP

Once a vulnerable account is identified (let's call it svc_legacyapp), the attacker sends an AS-REQ to the Domain Controller for that specific user.

Because pre-authentication is disabled for svc_legacyapp, the Domain Controller does not require the attacker to prove they know the password. It happily processes the request and responds with the AS-REP.

Step 3: Extracting the Encrypted Material

As established in the standard Kerberos flow, the AS-REP contains data that is encrypted using the target user's password hash. Specifically, it encrypts the session key using the RC4 or AES hash of the user's password. The attacker receives this AS-REP and extracts the encrypted portion.

Step 4: Offline Password Cracking

This is the "Roasting" phase. The attacker takes the extracted, encrypted material offline, to their own powerful cracking rig equipped with high-end GPUs.

Using tools like Hashcat or John the Ripper, the attacker attempts to brute-force or dictionary-attack the encryption. The cracking tool rapidly guesses passwords, converts them into hashes, and attempts to decrypt the AS-REP data. When the decryption is successful, the tool knows it has found the correct plaintext password for the svc_legacyapp account.

AS-REP Roasting is particularly dangerous for several reasons:

Stealth and Lack of Logs: Because the attacker is not actually attempting to log in with an incorrect password, no authentication failure events (Event ID 4625) are generated on the Domain Controller. The request looks like a standard Kerberos ticket request, blending in with normal network traffic.

No Account Lockouts: Standard brute-force attacks against AD will quickly trigger account lockout policies, locking the account and alerting administrators. Because the password cracking in AS-REP Roasting happens offline, on the attacker's own hardware, the AD account lockout policy is completely bypassed. The attacker can make millions of guesses per second without the Domain Controller ever knowing.

High-Value Targets: Often, the accounts that have pre-authentication disabled are service accounts used by applications. Service accounts frequently have elevated privileges, sometimes even Domain Admin rights, and their passwords are rarely changed. Compromising a highly privileged service account via AS-REP Roasting can lead to an immediate and total domain compromise.

Defending against AS-REP Roasting requires diligent Active Directory hygiene and proactive monitoring.

1. Audit and Enforce Pre-Authentication

The most effective mitigation is to simply ensure that Kerberos Pre-Authentication is enabled for every single account in the domain.

Administrators should regularly audit Active Directory to identify accounts with the Do not require Kerberos preauthentication flag set. This can be done using simple PowerShell scripts or tools like PingCastle. If an account is found with this setting enabled, investigate why it was disabled.

If it was disabled for a legacy application that is no longer in use, enable pre-authentication immediately. If the legacy application is still required, strongly consider upgrading or replacing the application with one that supports modern authentication standards. The risk posed by disabling pre-authentication usually outweighs the benefit of maintaining legacy software.

2. Implement Extremely Strong Passwords

If an account absolutely must have pre-authentication disabled due to an unavoidable business requirement, the password for that account must be exceptionally strong.

Because the attacker is cracking the hash offline, the only defense is mathematical complexity. The password should be a long, randomly generated passphrase (e.g., 30+ characters), utilizing a mix of uppercase, lowercase, numbers, and symbols. A sufficiently long and complex password will render offline cracking computationally infeasible, even with vast arrays of GPUs. Furthermore, utilize Managed Service Accounts (MSAs) or Group Managed Service Accounts (gMSAs) where possible, as AD automatically manages their incredibly complex passwords.

3. Monitor for Suspicious AS-REQ Traffic

While the attack is stealthy, it is not entirely invisible. Security Operations Centers (SOCs) can configure their SIEM (Security Information and Event Management) systems to monitor Windows Event Logs for indicators of roasting.

Specifically, monitor for Event ID 4768 (A Kerberos authentication ticket (TGT) was requested). While this event occurs constantly in a normal environment, defenders can filter for Event ID 4768 where the Ticket Options field contains 0x40810010 (which indicates pre-authentication was not required) and the Result Code is 0x0 (Success). A sudden spike in these specific events originating from a single IP address, especially targeting multiple different user accounts, is a strong indicator of an active AS-REP Roasting reconnaissance or exploitation phase.

4. Utilize Advanced Threat Protection

Deploy advanced identity security solutions, such as Microsoft Defender for Identity (MDI). These platforms use behavioral analytics to monitor traffic communicating with the Domain Controllers. They are specifically designed to detect the anomalies associated with attacks like AS-REP Roasting, Kerberoasting, and Pass-the-Ticket, often alerting defenders before the offline cracking phase is complete.