TL;DR

AS-REP roasting abuses disabled Kerberos pre-auth to harvest encrypted TGTs for offline cracking; this report details the protocol flaw, tooling, forensic artifacts, and layered defenses needed to stop it.

AS-REP Roasting: A Technical and Forensic Analysis from a Malware Analyst’s Perspective

Abstract

The AS-REP roasting attack represents a sophisticated and stealthy credential-dumping technique that leverages a common misconfiguration in the Kerberos authentication protocol. By targeting user accounts with Kerberos pre-authentication disabled, an adversary can request an encrypted authentication response (AS-REP) without providing any credentials. This response, which contains a Ticket Granting Ticket (TGT) encrypted with the user’s password hash, can then be extracted and cracked offline. This report provides an exhaustive, low-level analysis of the attack from the perspective of a malicious binary. It deconstructs the underlying Kerberos protocol vulnerabilities, examines the programmatic implementation using Windows API calls and popular tooling like Impacket, and meticulously details the host- and network-based forensic artifacts left behind. The analysis concludes with a synthesis of critical findings and actionable recommendations for building a robust, multi-layered defense posture.

1. Introduction to the AS-REP Roasting Attack

1.1 Executive Summary and Attack Overview

AS-REP roasting is a credential-dumping technique that has gained significant prominence as a method for compromising Active Directory (AD) authentication systems. The attack hinges on a specific misconfiguration: the UF_DONT_REQUIRE_PREAUTH flag being enabled on a user account. This flag, which disables Kerberos pre-authentication, allows a low-privileged attacker with network access to a domain controller (DC) to request and receive a Kerberos Authentication Service Response (AS-REP) without providing any valid credentials. The AS-REP message contains a Ticket Granting Ticket (TGT) that is encrypted using a key derived from the user’s password hash. This encrypted data is the primary objective of the attack, as it can be extracted and then subjected to offline brute-force or dictionary attacks to recover the plaintext password.

The attack proceeds through a clear three-step lifecycle. First, an adversary performs reconnaissance to identify accounts with the vulnerable setting enabled. Second, a crafted authentication request (AS-REQ) is sent for one or more of these target users, and the password hash is extracted from the DC’s reply (AS-REP). Finally, the adversary uses powerful offline cracking tools like Hashcat or John the Ripper to obtain the plaintext password. This method is particularly effective due to its minimal privilege requirements and its ability to bypass standard security controls such as account lockout policies and rate-limiting systems.

1.2 Differentiating AS-REP Roasting from Kerberoasting

A common point of confusion in threat analysis is the distinction between AS-REP roasting and Kerberoasting. While both techniques are classified under the MITRE ATT&CK tactic T1558.004 (Steal or Forge Kerberos Tickets), they target different stages of the Kerberos protocol and different account types. Kerberoasting targets service accounts that have a Service Principal Name (SPN) registered in Active Directory. An attacker requests a Service Ticket (ST) from the Ticket Granting Service (TGS), and this ticket is encrypted with the service account’s password hash, which can then be cracked offline.

In contrast, AS-REP roasting targets standard user accounts that are configured to not require Kerberos pre-authentication. This attack exploits the initial Authentication Service (AS) exchange to obtain a Ticket Granting Ticket (TGT), which is encrypted with the user’s password hash. This fundamental difference in the targeted Kerberos sub-protocol and account type has profound implications for a defender’s ability to detect and respond to the attack. Kerberoasting generates a specific Event ID 4769 (A Kerberos service ticket was requested), which is tied to the TGS exchange. AS-REP roasting, however, triggers Event ID 4768 (A Kerberos authentication ticket (TGT) was requested). A defender cannot use a single detection rule for both techniques; a true AS-REP roast detection requires a rule that specifically looks for a Pre-Authentication Type 0 value within the Event ID 4768 log. This is a critical forensic distinction that dictates the architecture of effective threat hunting and incident response strategies.

1.3 The Attack Lifecycle: A High-Level Model

The AS-REP roasting attack follows a predictable and repeatable sequence:

• Reconnaissance: An adversary must first identify which user accounts within the target domain have Kerberos pre-authentication disabled. This is typically done with low-privileged access, using tools or scripts to query Active Directory.
• Request and Hash Extraction: Once vulnerable accounts are identified, the attacker crafts and sends an AS-REQ message for each account to the DC. The DC, due to the misconfiguration, responds with an AS-REP containing the password-encrypted hash, which the attacker captures.
• Offline Cracking: The captured hash is then transferred to a machine controlled by the attacker. Using powerful hardware and specialized cracking software, the hash is subjected to brute-force or dictionary attacks until the plaintext password is recovered.

2. Kerberos Protocol Mechanics and the Underlying Vulnerability

2.1 The Standard Kerberos Authentication Flow (AS-REQ and AS-REP)

To understand AS-REP roasting, it is necessary to first understand the standard Kerberos authentication process. The initial authentication exchange, known as the AS exchange, begins when a client sends a KRB_AS_REQ message to the Key Distribution Center (KDC), which is typically a domain controller. This message requests a Ticket Granting Ticket (TGT) for the user. As part of this request, and assuming pre-authentication is enabled, the client includes pre-authentication data (padata). This data is a timestamp that is encrypted using a key derived from the user’s password hash. The KDC receives the request, attempts to decrypt the timestamp using its stored copy of the user’s password hash, and verifies that the decrypted timestamp is current and valid. Only after this validation is successful does the KDC issue a KRB_AS_REP message, which contains the TGT and a session key. The TGT is encrypted with the KDC’s master key (krbtgt), while the session key is encrypted with the user’s password-derived key.

2.2 The Critical Role of Kerberos Pre-Authentication

Kerberos pre-authentication is a fundamental cryptographic control designed to prevent password guessing and dictionary attacks. By requiring the client to cryptographically prove knowledge of the password-derived key before the KDC issues any sensitive material, it serves as a robust defense. Without this check, an attacker could send a flood of AS-REQ messages with guessed usernames. If the KDC returned an encrypted response for each, the attacker would know which usernames were valid, enabling a large-scale password-guessing operation. Pre-authentication forces the attacker to possess the correct password-derived key upfront to receive any encrypted data, making it an essential component of a secure Kerberos deployment.

2.3 The Misconfiguration: Exploiting UF_DONT_REQUIRE_PREAUTH

The AS-REP roasting attack directly exploits a misconfiguration where the Kerberos pre-authentication check is bypassed. This occurs when the UF_DONT_REQUIRE_PREAUTH flag is enabled for an account in Active Directory. This flag corresponds to the bitwise value 4194304 or 0x400000 within the UserAccountControl attribute of a user object. When this flag is set, the KDC completely ignores the padata field of an incoming AS-REQ message and immediately proceeds to issue a TGT in the AS-REP response.

The core of the attack lies in this behavior: the AS-REP message, which contains the TGT and the session key, is still encrypted with a key derived from the user’s password. Because the attacker receives this encrypted AS-REP without having to perform any pre-authentication, the malicious actor effectively gets a copy of the password hash without ever knowing the password. This is not a traditional software vulnerability that can be patched with an update. Instead, it is a persistent administrative failure that provides a reliable attack vector for as long as the misconfigured flag remains enabled.

Table: Comparison of AS-REQ/AS-REP Messages (Pre-Auth Enabled vs. Disabled)

Feature	Pre-Authentication Enabled	Pre-Authentication Disabled
AS-REQ	Includes encrypted timestamp (padata).	padata field is absent.
KDC Validation	Validates padata by decrypting the timestamp with the user’s password hash.	Bypasses validation entirely.
KDC Response	Issues AS-REP only after successful validation.	Issues AS-REP immediately upon receipt of AS-REQ.
AS-REP	Contains TGT and session key, both encrypted with the user’s key.	Contains TGT and session key, both encrypted with the user’s key.
Result	Secure exchange; TGT is only issued to the legitimate user.	TGT and password-derived hash are exposed to any attacker.

3. Programmatic AS-REP Roasting: A Malware Implementation Deep Dive

3.1 Reconnaissance and Enumeration of Vulnerable Accounts

Before a malicious binary can perform the attack, it must first identify which accounts are vulnerable. The most common method involves programmatic enumeration of the Active Directory domain. This can be accomplished by querying for user objects with the specific UserAccountControl value. A standard PowerShell command leveraged by attackers is:

Get-AdUser -Filter { UserAccountControl -band 4194304 }

This query returns all users where the UF_DONT_REQUIRE_PREAUTH bit is set. A malicious binary could perform a similar Lightweight Directory Access Protocol (LDAP) query directly to the domain controller to achieve the same result. The relative simplicity of this reconnaissance step, combined with the low privileges required to execute it, makes it a highly attractive initial tactic for adversaries.

3.2 Crafting the Malicious AS-REQ Packet

A key advantage for a malware author is the programmatic simplicity of the attack. Since pre-authentication is disabled for the target account, the malicious binary does not need to handle any cryptographic operations or credential handling on the client side. The AS-REQ message sent by the attacker is a basic, unauthenticated request for a TGT, requiring only the target user’s sAMAccountName and domain name.

A custom C++ or C# implant could interact directly with the Windows Kerberos Security Support Provider (SSP) through the Security Support Provider Interface (SSPI) to craft and send these requests. The LsaCallAuthenticationPackage function is the primary Windows API for such low-level communication with authentication packages. A sophisticated binary could construct a KERB_ADD_CREDENTIALS_REQUEST structure to communicate the necessary parameters to the Kerberos SSP, thereby initiating the AS exchange and receiving the encrypted AS-REP directly. This method bypasses the need for external network libraries or executables, allowing the malware to operate as a stealthy, self-contained binary.

3.3 Analysis of Malicious Tooling: Impacket and Rubeus

Malicious actors and red team operators often rely on sophisticated toolsets that automate the complexities of the attack.

3.3.1 Impacket’s GetNPUsers.py: A Functional and Protocol-Level Breakdown

Impacket is a well-known, open-source collection of Python classes that provides low-level, programmatic access to network protocols, including Kerberos. The GetNPUsers.py script, a component of this library, is specifically designed to perform AS-REP roasting. The script first enumerates users with the disabled pre-authentication flag and then systematically sends AS-REQ messages for each. It then parses the returning AS-REP packets, extracts the password hash, and formats it for offline cracking tools like Hashcat or John the Ripper.

A crucial design choice of Impacket is its ability to craft and send network packets from scratch, operating at the protocol level rather than relying on native Windows SSPI APIs. This approach offers a significant stealth advantage. Endpoint security solutions and EDRs that monitor for suspicious API call chains (for example, LsaCallAuthenticationPackage) might be bypassed. Impacket’s traffic appears as standard Kerberos communication over the wire, making its detection reliant on network-level analysis or advanced behavioral monitoring on the host.

3.3.2 Rubeus: The .NET Equivalent for AS-REP Roasting

Rubeus is a powerful post-exploitation tool written in C# that is widely used for interacting with Kerberos tickets. It provides an easy-to-use command-line interface to perform an AS-REP roast with a simple command like:

Rubeus.exe asreproast /user:ESMERALDA_MIRANDA /format:hashcat

While Rubeus offers a streamlined user experience, its underlying functionality mirrors the Windows API interaction described earlier. It encapsulates the complex calls to the Kerberos SSP, making it a highly effective tool for operators to leverage on a compromised Windows host.

4. Hash Extraction and Offline Cracking Techniques

4.1 The AS-REP Hash Format: Dissecting the $krb5asrep$ String

After successfully capturing the AS-REP, the encrypted portion of the message is extracted and formatted into a string suitable for password cracking tools. The hash format for AS-REP roasting is standardized and universally recognized by modern crackers. A typical example looks like this:

$krb5asrep$23$ESMERALDA_MIRANDA@domain.local:b4d9969983602fa94d7fe07f55a2a0a2$

Each section provides critical information:

• $krb5asrep$: Identifier for the hash type, indicating a Kerberos 5 AS-REP hash.
• 23: The Kerberos encryption type, or etype. In this case, etype 23 corresponds to the RC4-HMAC-MD5 encryption algorithm, which is known to be weak and is a common target for cracking.
• ESMERALDA_MIRANDA@domain.local: The user principal name (UPN) of the targeted account.
• b4d9969983602fa94d7fe07f55a2a0a2$: The hexadecimal representation of the encrypted hash data.

4.2 Hashcat Mode 18200: A Technical Analysis

Hashcat, a highly performant and GPU-accelerated password cracking utility, is the tool of choice for adversaries performing the offline phase of the attack. The tool supports a multitude of hash formats, and the specific mode for AS-REP hashes is 18200. This mode is explicitly designated for “Kerberos 5, etype 23, AS-REP”. The attacker can then use this mode with various attack types (-a) to recover the plaintext password.

Since AS-REP roasting often targets legacy applications or service accounts with weak password policies, an attacker’s strategy is often to start with low-cost, high-yield attacks. A dictionary attack (-a 0) using a large wordlist like rockyou.txt is typically the first step, as it can quickly crack common passwords. If this fails, the attacker can move to more computationally intensive techniques, such as hybrid attacks (-a 6, -a 7) that combine a wordlist with a character mask, or pure brute-force attacks (-a 3). This tailored approach reflects an understanding of the common password hygiene weaknesses in targeted environments.

Table: Hashcat AS-REP Cracking Command Examples

Attack Type	Hashcat Command	Purpose
Dictionary Attack	hashcat.exe -m 18200 -a 0 hashes.txt rockyou.txt	Cracks the hashes using a pre-compiled wordlist.
Hybrid Attack (Wordlist + Mask)	hashcat.exe -m 18200 -a 6 hashes.txt wordlist.txt?d?d	Appends two numbers to each word in the wordlist.
Pure Brute-Force	hashcat.exe -m 18200 -a 3 hashes.txt ?l?d?s?u?a?d	Attempts password combinations based on a character set mask.

4.3 The Stealth Advantage: Why Offline Cracking Is a Threat

The offline nature of the password cracking phase is a significant advantage for attackers. Once the encrypted hashes are captured, no further communication with the victim’s network is required to recover the plaintext passwords. This completely bypasses traditional security mechanisms such as account lockout policies, rate-limiting, and real-time monitoring systems that are designed to detect repeated failed login attempts. An adversary can use powerful, GPU-accelerated hardware and take as long as necessary to crack the hashes without generating any additional network traffic or authentication logs that would alert the victim organization.

5. Forensic Artifacts: Traces of a Malicious Binary

5.1 Host-Based Artifacts

5.1.1 Windows Event Log (WEL) Analysis

The most critical and reliable host-based artifact for AS-REP roasting is Windows Security Event ID 4768. This event is generated on domain controllers every time a TGT is requested. A successful AS-REP roast will result in a specific set of field values within this event log entry. The primary indicator is that the Pre-Authentication Type field will be 0, signifying that no pre-authentication data was provided in the request. Security teams should actively monitor for any Event ID 4768 entries with a Pre-Authentication Type of 0, especially when combined with a Service Name of krbtgt.

In addition to this primary signature, Event ID 4738, which indicates a change to a user account object, could be relevant if an attacker modifies the UF_DONT_REQUIRE_PREAUTH flag to facilitate a subsequent attack.

5.1.2 PowerShell Script Block Logging (Event ID 4104)

If the attacker uses PowerShell for the initial reconnaissance phase, a powerful detection opportunity exists. With PowerShell Script Block Logging enabled on an endpoint, the specific command Get-AdUser -Filter { UserAccountControl -band 4194304 } will be recorded as EventCode=4104. This provides a critical forensic artifact of the attacker’s initial enumeration of the domain before the AS-REP roasting is even attempted.

5.1.3 File System and Registry Artifacts

Depending on the tools used, the attack can also leave traces on the file system. Tools like Rubeus or Impacket often write the captured hashes to temporary files (for example, hashes.txt or cracked.txt) before or after cracking. The presence of these files or their creation in unusual directories can be a key indicator of compromise.

5.2 Network-Based Artifacts

Packet analysis is another effective method for detecting AS-REP roasting. The Kerberos authentication protocol communicates over TCP and UDP port 88. A captured AS-REQ message that lacks the padata (Pre-Authentication Data) field is a clear indicator of a non-standard request. Furthermore, a network trace will show an immediate AS-REP message being returned from the domain controller without a preceding KRB_ERROR with KDC_ERR_PREAUTH_REQUIRED, which would normally be sent to a client that does not provide pre-authentication. The combination of a missing padata field in the request and an immediate encrypted response without an error is a definitive network signature of the attack.

Table: AS-REP Roasting Attack Phases and Associated Forensic Artifacts

Attack Phase	Host-Based Artifacts	Network-Based Artifacts
Reconnaissance	PowerShell Script Block Logging (Event ID 4104) containing Get-AdUser queries for UserAccountControl -band 4194304.	LDAP queries on port 389/636 targeting user attributes.
Request/Hash Extraction	Windows Event Log (Event ID 4768) on the DC with Pre-Authentication Type = 0 and Service Name = krbtgt.	Kerberos traffic on TCP/UDP port 88 with an AS-REQ that lacks a padata field, followed by an immediate encrypted AS-REP.
Offline Cracking	File artifacts such as hashes.txt or cracked.txt in unusual locations, indicating storage of captured hash data and cracked passwords.	None; this phase is conducted entirely offline with no interaction with the victim’s network.

6. Mitigation and Proactive Defense Strategies

6.1 Remediation: Enabling Kerberos Pre-Authentication

The most effective and direct mitigation against AS-REP roasting is to correct the underlying misconfiguration. This requires enabling Kerberos pre-authentication for all user accounts in Active Directory. This action completely blocks the attack by forcing any authentication request to provide a valid, encrypted timestamp before the DC will issue a TGT. The Set-ADAccountControl PowerShell cmdlet can be used to programmatically remediate these accounts on a large scale.

6.2 Proactive Hunting: Monitoring for Vulnerable Accounts

A reactive detection posture is insufficient to defend against this attack. A proactive approach involves regularly auditing the Active Directory environment to identify and remediate accounts that remain vulnerable. Tools like Purple Knight can automate this process by providing a security indicator that identifies all users with disabled pre-authentication. By continuously monitoring for unexpected accounts with this misconfiguration, defenders can prevent potential AS-REP roasting attempts before they occur.

6.3 Incident Response: Containment and Eradication

If an AS-REP roasting attack is detected, immediate and decisive incident response is required. This involves quarantining the compromised host from which the reconnaissance and requests originated and resetting the password of the targeted account. The broader response must include a comprehensive audit to ensure the misconfiguration has not been enabled for other accounts and that a similar attack cannot be launched in the future.

7. Conclusion and Final Recommendations

AS-REP roasting is a potent and enduring threat because it exploits a common administrative misconfiguration rather than a fleeting software vulnerability. The attack is low-effort for the adversary, requires minimal privileges, and its most critical phase—the password cracking—is performed offline, making it impervious to many traditional security controls. The analysis demonstrates that a successful defense requires a multi-layered approach that blends proactive remediation with robust, real-time monitoring.

For a robust defense posture against AS-REP roasting, the following recommendations are critical:

1. Enforce Kerberos Pre-Authentication: Ensure that the UF_DONT_REQUIRE_PREAUTH flag is enabled for all user accounts, especially privileged or service accounts.
2. Strengthen Password Policies: Implement strong password policies that mandate the use of lengthy and complex passphrases. This significantly increases the time and computational resources required for an adversary to crack a captured hash, even if they successfully perform an AS-REP roast.
3. Enhance Log Monitoring: Enable and actively monitor Windows Event ID 4768 on all domain controllers. Create specific detection rules to alert on any instance where the Pre-Authentication Type is 0.
4. Deploy Advanced Endpoint and Network Monitoring: Implement EDR solutions that can detect the execution of post-exploitation frameworks like Impacket or Rubeus and can log the specific PowerShell commands used for reconnaissance. In parallel, monitor network traffic for AS-REQ messages on port 88 that lack pre-authentication data.
5. Conduct Proactive Assessments: Regularly perform red team or penetration testing exercises to identify and remediate vulnerable accounts before they can be exploited by malicious actors.

By adopting this integrated defense strategy, organizations can proactively address the root cause of this attack and build a more resilient authentication infrastructure.

---

Share

• X (Twitter)
• LinkedIn
• Mastodon
• Email

Copy Link