ASREP Roasting

Published: 16 February 2020

AKA Kerberos Party Tricks


If an Active Directory user has pre-authentication disabled, a vulnerability is exposed which can allow an attacker to perform an offline bruteforce attack against that user’s password.

This attack is commonly known as “AS-REP Roasting” in reference to Authentication Service Requests, a part of the process of authentication with Kerberos. An attacker who is able to find a user with pre-authentication disabled can request an AS-REP ticket for that user and this will contain data encrypted with the user’s password.

The attack is also known as “Kerberos Party Tricks” in reference to a conference talk given by Geoffrey Janjua of Exumbra Operations Group back in 2016.

Pre-authentication prevents this by encrypting the AS-REP ticket with the service key (the hash associated with the KRBTGT account within active directory).

The attack has been well known for a while, with articles published back in early 2014 stating that it’s important not to disable it due to potential password-guessing attacks.

The Attack

The attack has two parts; the first is requesting an AS-REP ticket from the Domain Controller (or more specifically, the KDC). If pre-authentication is disabled for that, it will disclose if a user with the given username exists and supply a piece of data encrypted with the users password.

Many people will habitually correct this to say “Well actually, you mean hashed not encrypted!”, however in this instance encrypted is correct, as can be seen in RFC4120.

The encrypted part is signed with the client key, which allows us to perform a bruteforce attack to determine the user’s password. Performing the attack is possible either with Impacket or Rubeus.

ASREP Roasting with Impacket

The following command will ASREP Roast with Impacket, using a supplied list of potential users, returning with are valid with hashes. These can then be cracked with John or Hashcat.

python [domain]/ -usersfile [username file] -format [hashcat|john] -outputfile [output file] -no-pass
python Core/ -usersfile users.txt -format john -outputfile out.john -no-pass

If a user does not exist with preauthentication disabled, you will see a message like this:

If no tested users are found to have pre-authentication disabled, the output will be empty

However, if a valid user is discovered with preauthentication disabled, the hash is displayed:

John or Hashcat.

Rubeus.exe asreproast  /format:[hashcat|john] /outfile:[output file]
Rubeus.exe asreproast /format:john /outfile:out.john

Rubeus can be used to perform the same attack

Cracking the Hash

These hashes can be cracked with John the Ripper, with a command such as:

john out.john [--wordlist=wordlist.txt]

John the ripper can be used to attempt to crack these hashes

Here you can see the hash (in this case gathered through impacket’s GetNPUsers running on Kali) is detected as a krb5asrep and has been cracked to reveal the password as “Password123”

The Fix

Preventing AS-REP Roasting is fairly simple, ensure that no users within the Active Directory domain have Pre-authentication disabled (it is enabled by default).

You can check if any enabled users have pre-authentication disabled with the following PowerShell:

get-aduser -filter * -properties DoesNotRequirePreAuth | where {$._DoesNotRequirePreAuth -eq "True" -and $_.Enabled -eq "True"} | select Name

Alternatively you check check this within the Active Directory Users and Computers menu:

The user properties window showing where to fnd the pre-authentication option

This menu can be accessed from within Active Directory Users and Computers, by right-clicking user a selecting properties. The box should be unchecked to enable pre-authentication.

Additionally it should be pointed out that this weakness relies on the passwords being feasibly cracked with a tool like John or hashcat, so more secure password choices will additionally reduce the risk.