AS-REP Roasting: Exploiting Kerberos Pre-Authentication

In Active Directory environments, Kerberos is the default authentication protocol. While generally secure, specific misconfigurations can leave user accounts highly vulnerable to offline password cracking. One such attack is AS-REP Roasting, a technique that specifically targets accounts configured to bypass a crucial security step: Kerberos Pre-Authentication.

In this tutorial, we'll dive into the mechanics of Kerberos authentication, explain how AS-REP Roasting exploits pre-authentication bypass, and walk through the attack using standard tools.

[!TIP]

Interactive Learning: Want to see this attack visualized in real-time? Try our interactive AS-REP Roasting Lab to experience the packet flow firsthand.

1. The Theory: Kerberos and Pre-Authentication

To understand AS-REP Roasting, we first need a basic understanding of how a standard Kerberos authentication flow works.

Standard Authentication Flow

• AS-REQ (Authentication Service Request): The user wants a Ticket Granting Ticket (TGT). To prove their identity, they encrypt a timestamp using their password hash and send this in the AS-REQ to the Key Distribution Center (KDC), which is usually the Domain Controller.
• KDC Validates: The KDC looks up the user's password hash in Active Directory, attempts to decrypt the timestamp, and verifies it. This is Pre-Authentication.
• AS-REP (Authentication Service Response): If successful, the KDC responds with the AS-REP, which contains the TGT (encrypted with the `krbtgt` account hash) and a session key (encrypted with the user's password hash).

The Misconfiguration

By default, Active Directory requires pre-authentication. However, administrators can disable it for specific accounts by checking the box: "Do not require Kerberos preauthentication" in the account's properties in Active Directory Users and Computers (ADUC).

Why would anyone do this? Usually, it's for legacy application support or service accounts that don't support modern Kerberos implementations.

The Vulnerability

When pre-authentication is disabled, an attacker can simply send a fake AS-REQ for that specific user. Because pre-authentication is off, the KDC skips the timestamp check and immediately responds with the AS-REP.

Crucially, a portion of the AS-REP is encrypted with the target user's password hash. The attacker can request this response for any vulnerable user without knowing their password, save the encrypted AS-REP, and attempt to crack it offline.

2. Executing the Attack (The Impacket Way)

The most common tool suite for this attack is Impacket, specifically the GetNPUsers.py script.

Step 1: Reconnaissance (Finding Vulnerable Users)

Before you can roast an AS-REP, you need to know which accounts have pre-authentication disabled. If you already have low-privileged access to the domain, you can query Active Directory via LDAP to find these accounts.

You can use PowerView from a compromised host:

Get-DomainUser -PreauthNotRequired

Or, if you are attacking from a Linux machine, you can use GetNPUsers.py to query the DC (assuming you have valid credentials or the domain allows anonymous LDAP binding):

impacket-GetNPUsers contoso.local/ -dc-ip 192.168.1.10 -request

Step 2: Requesting the AS-REP

If you already know the username (e.g., svc_backup), or if GetNPUsers.py finds vulnerable accounts, it will automatically request the AS-REP and format the output so it can be cracked.

impacket-GetNPUsers contoso.local/svc_backup -no-pass -dc-ip 192.168.1.10

The output will look something like this:

$krb5asrep$23$svc_backup@CONTOSO.LOCAL:6a2b3c4d5e6f7a...

3. Cracking the AS-REP Hash

Once you have the hash string from GetNPUsers.py, save it to a text file (e.g., asrep.txt).

You can use Hashcat to crack it. The mode for Kerberos 5 AS-REP etype 23 is 18200.

hashcat -m 18200 asrep.txt /usr/share/wordlists/rockyou.txt

If the account uses a weak password, Hashcat will quickly recover the plaintext password, giving you access to that account.

4. Defending Against AS-REP Roasting

Defending against AS-REP Roasting is straightforward: enforce pre-authentication.

Mitigation Steps

• Enable Pre-Authentication:
• Audit your Active Directory for accounts with the "Do not require Kerberos preauthentication" attribute set.
• Unless absolutely necessary for legacy application compatibility, uncheck this box for all users.
• Enforce Strong Passwords:
• If an account must have pre-authentication disabled, ensure it has a randomly generated, highly complex password (25+ characters). This makes offline cracking computationally infeasible.
• Implement Fine-Grained Password Policies (FGPP):
• Apply stricter password policies to service accounts that might require legacy configurations.
• Monitor Kerberos Traffic:
• While the attack is stealthy regarding failed logins, monitoring for an unusual volume of AS-REQ packets requesting `RC4-HMAC` (etype 23) without pre-authentication data can indicate an ongoing attack. Event ID `4768` (A Kerberos authentication ticket (TGT) was requested) is the primary log to monitor, paying attention to the `Pre-Authentication Type` field.

Conclusion

AS-REP Roasting is a targeted attack that preys on a specific, often unnecessary, Active Directory misconfiguration. By regularly auditing account properties and enforcing pre-authentication, organizations can easily eliminate this attack vector.

To practice executing and detecting this attack in a fully simulated, interactive environment, visit our AS-REP Roasting Lab.