AS-REP Roasting

Overview

AS-REP Roasting is an attack against Active Directory accounts that have Kerberos pre-authentication disabled.

Anyone can request an AS-REP for the account without knowing its password. The KDC will respond with data encrypted using the account’s password hash, which attackers can then take offline and try to crack.

What makes this attack so popular is that the cracking happens completely offline, making it very hard to detect in real time.

Kerberos Authentication

Before diving into the details of the attack, we first need to understand the fundamentals of how Active Directory handles authentication. Because hey, we need to understand what we’re attacking, right?

Active Directory relies on the Kerberos protocol for authentication. I won’t go too deep into Kerberos itself since there are already tons of solid resources out there, but let’s quickly review the parts that actually matter for us.

In a Kerberos authentication flow, there are three main actors:

• The client (the one who wants to access a resource, it can be a computer but it will most likely be a user)
• The service (the server hosting the resource the client wants to access)
• The Key Distribution Center (KDC), which lives on the Domain Controller. The KDC holds all the secrets from the client and the resource, and is trusted by the client and the resource

The KDC doesn’t decide whether you can actually access the service — that’s the job of the server hosting that service. The KDC’s role is just to vouch for your identity: it tells the service, “Yup, this user is who they claim to be.”

Think of it like a house party. You’re invited, but when you show up, there’s a guard at the door. That guard is the KDC. They check your ID to make sure you are who you say you are. Once that’s confirmed, the guard lets the host know: “Yep, this person is legit.” But it’s still the host — the server hosting the party — who decides whether you’re allowed inside or not.

Source: MS-KILE, Microsoft Open Specifications

From the diagram above, we can see that the first step in the Kerberos process is KRB_AS_REQ. This AS-REQ is the moment when the client authenticates to the Authentication Service (AS), which resides inside the KDC, and asks for a Ticket Granting Ticket (TGT) to access a service.

The idea behind the TGT is simple: instead of forcing the client to re-authenticate every single time, the client gets a reusable ticket. By default, a TGT has a lifetime of 10 hours and can be renewed for up to 7 days.

An AS-REQ typically includes:

• The User Principal Name (UPN)
• A timestamp (encrypted using the client secret key, derived from the client password)
• Supported encryption types

Next comes the AS-REP. The AS attempts to decrypt the timestamp using the client’s password hash stored in its database. If the decryption works, the AS sends back:

• A Ticket Granting Ticket (TGT), encrypted with the KDC’s secret key (so only the KDC can read it), and
• A session key, encrypted with the client’s key (derived from their password), so only the client can use it.

Alright, now we have an overview of how authentication works in Kerberos, we can now talk about AS-REP Roasting.

Attack Examples

By default, Kerberos pre-authentication is enabled. For it to be disabled, someone has to set the option “Do not require Kerberos preauthentication” on the account.

This attack can be performed from both Windows and Linux, and we’ll cover examples on each.

Attacking From Linux

I have a list of users that I found during enumeration, but I don’t know if any of them are vulnerable to AS-REP Roasting.

We can use a few different tools for this. I suggest practicing the attack with several tools (don’t get stuck on a single one). In this example I’ll use NetExec: it verifies which usernames are valid and checks whether any account is vulnerable to AS-REP Roasting. Note that I only have a list of usernames here, no credentials.

nxc ldap 10.0.2.10 -u users.txt -p '' -k

Looking at the screenshot, we can see that for most users the result is KDC_ERR_PREAUTH_FAILED. This means the user exists, but authentication failed (which is expected since we don’t have credentials).

For this example, I also added the user idontexist, so you can see what it looks like when the user doesn’t exist in the AD.

We’ve found a vulnerable user! odembele will be our target now, let’s use impacket-GetNPUsers for the AS-REQ.

impacket-GetNPUsers ankou.local/odembele -request -no-pass

We received the AS-REP! Now we can attempt to crack it offline using Hashcat or John (covered in the next section).

Attacking From Windows

On Windows, we will use the same methodology: we want to first find which accounts do not have “Do not require Kerberos preauthentication” set.

For this example, we will use Get-ADUser, a built-in Windows command. Here we filter on UserAccountControl set to 4194304, which stands for DONT_REQ_PREAUTH.

Get-ADUser -LDAPFilter "(&(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=4194304))" -Properties Name,UserPrincipalName | Select-Object Name, UserPrincipalName

Awesome! We got the same result as on Linux, and we’ll continue with our target odembele.

To make the AS-REQ, we will use a tool called Rubeus. Rubeus will likely be flagged by AV solutions, so you may need to address AV/EDR in a real assessment; for the sake of this example, Windows Defender has been disabled.

.\Rubeus.exe asreproast /user:odembele /nowrap

Again! We got the AS-REP containing the hash!

Cracking

Now that we have the hash, the next step is to attempt to crack it on our machine. This won’t interact with the target, so we don’t need to worry about generating noise on the target network.

We will crack the hash using both Hashcat and John; I saved the hash in a file named odembele_hash.

hashcat -m 18200 -a 0 odembele_hash /usr/share/wordlists/rockyou.txt

john --format=krb5asrep --wordlist=/usr/share/wordlists/rockyou.txt odembele_hash

Awesome! Using Hashcat and John we could crack odembele’s password.

Detection

Defenders will typically see Windows Security event ID 4768 (a Kerberos TGT request) when a user requests an AS-REP. The challenge is that TGT requests are completely normal. In a corporate environment there can be thousands of 4768 events every day. That makes AS-REP Roasting difficult to spot, since the cracking happens offline and the malicious request looks the same as legitimate ones.

By default, tools such as Rubeus and GetNPUsers will use RC4 encryption, as you can see from the screenshot. This is because it is easier to crack than AES256.

By monitoring event ID 4768, if you see the cryptographic algorithm set to 0x17 (RC4), it may be a good indicator of a potential AS-REP Roasting attack.

But to be specific about AS-REP Roasting, we also need to check the PreAuthType field in event 4768. If preauthentication is enabled, you’ll see the value set to 2, which corresponds to PA-ENC-TIMESTAMP.

On my target odembele, preauthentication is disabled: we see PreAuthType: 0, which indicates the client logged in without preauthentication. If you combine that with the ticket using RC4 (TicketEncryptionType: 0x17), I have a strong indicator that odembele was compromised.

The TGT request was made. What we don’t know, however, is whether the attacker was successful in cracking it offline.

My SIEM is Kibana, so I can filter for those events to reduce the noise and make it easier to detect AS-REP Roasting. The same type of filtering can be applied in other SIEMs as well.

Here, let’s see the difference with just the filter for the event code 4768.

Lot of traffic, right? Now let’s use this filter:

event.code: "4768" and winlog.event_data.PreAuthType: "0" and winlog.event_data.TicketEncryptionType: "0x17"

By using the filter, we can greatly reduce the results and focus on this specific request to confirm whether an AS-REP Roasting attack was made.

Remediation

To prevent AS-REP Roasting, you need to identify accounts that have “Do not require Kerberos preauthentication” enabled. Unless it is strictly necessary, this option should be disabled.

If you really need an account with this option enabled, make sure it follows a strong password policy so attackers can’t crack it offline. It’s also best practice to rotate the password regularly.