Recently my team had a discussion about what the exact difference between AS_REP Roasting and Kerberoasting is.
As we were short of time, we did not come to a concrete answer and were also not able to find an article that explains it in short.

I am neither a professional with years of experience nor a Kerberos guru. So if you are looking for a complex deep-dive, feel free to move along.

Credits to: Allagar´s Art

Introduction

Kerberos is an authentication protocol for non-secure networks, which is build upon tickets.
It´s a really interesting topic and so I used our discussion as a starting point to dig a little deeper into both attacks and came up with this very high-level write-up comparing the two scenarios.
As a sideeffect, this is helping me to understand the processes inside Kerberos in more detail.
The protocol (at least to me) is very complex, and the write-ups I found were never 100% accurate in terms of terminology and clarification of things. You may read that messages are partly signed with a secret-key or with a users password hash or even just with the password. To make things worse this might happen in one single article. So I am quite sure that there will be some mistakes here and there in my write-up as well, but the basics should be correct.

Although Kerberos is not a native Microsoft protocol, one will most likely find it in Windows Active Directory environments, where it is the successor to NTLM and used since Windows Server 2000.
Over the years Kerberos was extended with additional features. One of these features is pre-authentication, which is enforced by default inside a Windows domain.

Terminology

The following abreviations will be used along this article. If you need more detail I recommend looking at the ldapwiki or this Microsoft article.

KDC: Key Distribution Center - The trusted 3rd party / the Domain Controller
TGS: Ticket Granting Server - A subset function of the KDC which issues service tickets
TGT: Ticket Granting Ticket - A userbased ticket used to authenticate to the KDC
ST: Service Ticket - Used to authenticate against services
SPN: Service Principal Name - The name of a service on the network

TL;DR

AS_REP Roasting is taking place during the initial authentication procedure within Kerberos. It´s abusing the fact, that for accounts with the option Do not require Kerberos preauthentication set, there is no need to send the (normally required) encrypted timestamp (with the users password hash) at the very beginning. Thus everyone on the network who knows the name of an affected account may ask the KDC to authenticate as that user and in return fetch a AS_REP response which partly is encrypted with the AS_REP roastable account´s password hash. Once obtained, an attacker can try to offline crack the hash and fetch the cleartext credentials.

Kerberoasting aims at asking for service tickets related to services on the network where the SPNs are tied to user accounts, rather than computer accounts. The background here is that if a person creates a user he will choose the password most likely according to human standards i.e. a phrase, a word mixed with numbers, etc. If that password is weakly chosen, then it is possible to crack the hash and get the cleartext credentials.
During the process of asking to access a service on the network, the TGS will send a data package that contains a service ticket which is encrypted with the service-account´s password hash, that again like in the AS_REP roasting attack can be cracked offline.

AS_REP roasting

The Kerberos authentication process looks like the following (high level - there is more going on in in detail and parts are missing):

1. Login to a system with username and password
2. AS_REQ request containing the username, desired service (in this case krbtgt) and a timestamp encrypted with the users password hash is sent to the KDC asking for a TGT
3. KDC checks if he can:
   a) decrypt the timestamp with the hash he has for that user in his database and
   b) if the timestamp is within a certain period of time compared to the servers current time (5 minutes default)
4. If valid and within the allowed time period the KDC returns a AS_REP response which, amongst others, contains the TGT and an encrypted session-key, which can be decrypted with the user´s password hash.
5. Client decrypts the session-key and saves the TGT for later usage

Now with the option Do not require Kerberos preauthentication set, the timestamp stuff is disabled for this account and only the default Kerberos cleartext message is needed to ask for a TGT.
This results in any user who has the correct name of that account to be able to request the TGT, which in return will be send as part of the AS_REP - again with parts encrypted with the users password hash we were asking for. This info can then be used to try to crack the hash to get the cleartext password offline.

Attack

We can use Rubeus on a domain joined machine (if we have valid credentials for a domain user we can also run all the stuff from a non domain joined machine with powershell´s /runas command or provide the missing parts directly to Rubeus) to find all accounts on that domain where Do not require Kerberos preauthentication is set and have it return the corresponding hashes. The /format option will directly give us output that is crackable with hashcat.

Rubeus.exe asreproast /format:hashcat

The AS-REP hash can then be fed into hashcat for offline attacks i.e. with brute-force or wordlist attacks.

hashcat64.exe -m 18200 '<AS_REP-hash>' -a 0 c:\wordlists\rockyou.txt

Mitigation

To check which accounts in you environment have pre-authentication disabled, you can use the following powershell cmdlet, which is available when having the RSAT tools installed. The following works from Windows 10 1809 onwards:

Add-WindowsCapability –online –Name “Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0”
Import-Module activedirectory
get-aduser -filter * -properties DoesNotRequirePreAuth | where {$._DoesNotRequirePreAuth -eq "True" -and $_.Enabled -eq "True"} | select Name

Or you can import PowerView into your powershell session and issue the Get-DomainUser cmdlet:

Get-DomainUser -PreauthNotRequired -Properties distinguishedname -Verbose

You should make sure that every account in your AD is using pre-authentication.
If for some reason an account needs to have it disabled, it all comes down to password complexity and length.

Kerberoasting

Kerberoasting aims at asking for a ST for a service that is tied to a user account and will most likely contain a human generated password. Normally SPNs are bound to computer accounts which have a random 128-character password that automatically gets changed every 30 days.

Every valid account inside your domain may ask the TGS to access a service and will be given a corresponding ST. The decision of whether and how this account can access the service is the responsibility of that service and not the TGS.

With valid credentials for an account and as such a valid TGT in hand, an attacker may request a ST for every SPN on the network.
The flow is as follows (involving the steps from the AS_REP roasting section):

1. With a valid TGT a TGS_REQ request is send to the TGS
2. The TGS checks if the SPN is valid, opens the TGT and does some additional tests to it
3. If everything is okay it generates a ST. Then it encrypts the ST with the service-account´s password hash and sends it back to the client as part of the TGS_REP response
4. The client receives the response, extracts the ST and can forward it to the desired service to access it

The problem here lies in the fact, that the ST is encrypted with the password hash of the SPNs account, and that by design everyone inside the domain may request a ticket for that service.
The attacker can intercept or extract the ticket from memory, and crack the hash offline.
According attacks can be performed even from non domain joined machines, as long as valid credentials for one user were obtained.

Attack

All described scenarios were performed from a domain joined machine. But there are ways and commandline-arguments for all the tools to be run from non domain joined systems.

Rubeus, mimikatz or PowerView can be used to fetch the tickets and extract the hashes for offline cracking.

Rubeus
The following attack will try to roast all users on the current domain leaving us with hashes in a crackable format for hashcat:

Rubeus.exe kerberoast /format:hashcat

PowerView
We can get a list of all user accounts that have a SPN set:

Get-DomainUser -SPN

Afterwards we can fetch the hashes like so:

Get-DomainSPNTicket -SPN <spn> -OutputFormat hashcat

mimikatz
mimikatz can be used to extract STs from memory. But beforehand you will have to identify SPNs and ask for tickets for them.
Having a look at the PowerView section above we are already able to query the desired SPNs.
Next step is to ask for the ST which can be done with two lines of powershell:

Add-Type –AssemblyName System.IdentityModel  
New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken –ArgumentList ‘<SPN-name>:<SPN-port>’

In order to extract the ticket from memory we use mimikatz:

kerberos::list /export

hash cracking
The output from Rubeus and PowerView can directly be fed into hashcat:

hashcat64.exe -m 18200 '<AS_REP-hash>' -a 0 c:\wordlists\rockyou.txt

For the mimikatz extracted hashes we need to issue tgsrepcrack.py

python tgsrepcrack.py c:\rockyou.txt c:\ticket.kirbi

Mitigation

Check which accounts in your environment are affected with PowerView´s Get-DomainUser cmdlet as explained above.
If the SPN needs to be tied to a user rather than a computer account, make sure to make the password long and complex.

In some circumstances, mainly when SPNs get registered manually with the help of the setspn tool, or when the machine is not able to unregister SPNs for several reasons, you might have dead SPNs in your environment. This means you can check the services.msc but wont find the suspected account under the logon settings. In these cases have a closer look at the user object in the AD under the Attribute Editor tab and then under servicePrincipalName. You can manually delete it here if needed or use the setspn tool like so:

#to list SPNs associated with an account (user or computer)  
setspn -l <accountname>    
setspn -l sqlservice  

#to remove an SPN from an account   
setspn -d <SPN> <accountname>  
setspn -d MSSQL/SQLSERVER1 sqlservice  

Conclusion

AS_REP roasting is taking place at the very beginning of the Kerberos authentication procedure. An attacker would only need physical access to the network, but would also have to know the principal name (user name) of the account he wants to ask a TGT for. The option Do not require Kerberos preauthentication for the object needs to be set and as such is less likely to be found during an assessment nowadays.

Kerberoasting is abusing a legit function inside an environment that makes use of Kerberos. The problem is that the service tickets are encrypted with the hash of the SPNs account and every account of the Active Directory can request such a ticket. If the password is weak an attacker will most likely be able to crack it. He therefore only needs to retrieve a valid user account and credentials.

So that´s it, a rather small blog-post about two Active Directory attack methods. I hope you liked it.
If you think that I made mistakes, that parts are still unclear or you are missing things, please feel free to hit me up on twitter.

Special thanks to my awesome colleagues S3cur3Th1sSh1t and 0x23353435 for their input and support.

I also want to thank the people who already did all the thinking and who wrote down and shared their knowledge:
Aidan Preston
Sean Metcalf
Will Schroeder

If you are interested in further info, here are the links that helped me write this blog-post:
https://m0chan.github.io/2019/07/31/How-To-Attack-Kerberos-101.html
https://adsecurity.org/
https://www.harmj0y.net/blog/redteaming/kerberoasting-revisited/
https://www.harmj0y.net/blog/activedirectory/roasting-as-reps/
https://zeroshell.org/kerberos/kerberos-operation/
https://www.qomplx.com/qomplx-knowledge-kerberoasting-attacks-explained/
https://iam.uconn.edu/the-kerberos-protocol-explained/
https://redmondmag.com/articles/2012/02/01/understanding-the-essentials-of-the-kerberos-protocol.aspx
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc772815(v=ws.10)
https://medium.com/@robert.broeckelmann/kerberos-and-windows-security-kerberos-v5-protocol-b9c804e06479
https://medium.com/@robert.broeckelmann/kerberos-and-windows-security-history-252ccb510137
https://stealthbits.com/blog/extracting-service-account-passwords-with-kerberoasting/
https://pentestlab.blog/2018/06/12/kerberoast/
https://www.secura.com/blog/kerberoasting-exploiting-kerberos-to-compromise-microsoft-active-directory
https://www.ired.team/offensive-security-experiments/active-directory-kerberos-abuse/t1208-kerberoasting
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc772815(v=ws.10)
https://swarm.ptsecurity.com/kerberoasting-without-spns/