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 — 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

From the diagram above, we can see that the first step in the Kerberos process is KRB_AS_REQ. This AS-REQis 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-REQtypically 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 on 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 Keberos preauthenticationon 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 find first which accounts do not have Do not require Kerberos preauthentication

For this example, we will use Get-ADUser which is a Windows pre-built command, here we use the 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

e 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 odembelepassword

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 4768events 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 RC4encryption, 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 an odembelewas 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.PreAuthType: "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