Kerberoasting

Any domain user within Active Directory can request a service ticket (TGS) for any service that has an SPN (Service Principal Name). A part of the service ticket will be encrypted with the NTLM hash of the target user, allowing for an offline bruteforce attack.

This is true for user accounts and computer accounts, but computer account passwords are randomised by default and rotated frequently (every 30 days). However service user accounts may have weak passwords set which could be cracked. This attack is commonly called Kerberoasting. Although, don’t confuse this attack with the similarly named ASREP Roasting. A common setup where you might find this vulnerability is where a service account has been set up for Microsoft SQL Server.

The Attack

The attack can be performed with Rubeus or Impacket. With Rubeus use the “kerberoast” option, as below:

Rubeus.exe kerberoast /outfile:hashes.txt

Rubeus can be used to perform kerberoasting

Here you can see that a user “sqlservice” has been found with an SPN “MYSQLsvc/sqlserver.akimbo.core.labs:MSSQLServer”. At the bottom of the screenshot (clipped) you can see a hash has been written to out.john.

With Impacket you can use the “GetUserSPNs” example, as:

python3 examples/GetUserSPNs.py domain/username:password -outputfile filename
e.g.
python3 examples/GetUserSPNs.py akimbo.core.labs/gmorris:Winter2020 -outputfile out.john

Here the same attack is shown but this time using Impacket

The Fix

As with the previous post about ASREP Roasting, one key factor in this attack is a password weak enough to be cracked using a tool like Hashcat or John. Therefore this can be prevented by ensuring that service accounts have secure passwords configured.

That’s it!

Read More

• Bruteforcing Windows Accounts
• Preventing Windows Accounts Being Bruteforced
• Creating Strong Passwords
• Bruteforcing Kerberos
• ASREP Roasting