Kerberoasting - Part 1
Previous works: There has been a number of differnet blog posts, presentations and projects that have happened before this post and I will reference a number of them during the post and at the end have a link to all that I know about. If you know of any works on this subject that I am missing please submit a comment below and I’ll will be sure to reference it.
Attacker KB Link: (to be updated later)
Common Findings DB Link: (to be updated later)
What are SPNs
[Service Principal Names](https://msdn.microsoft.com/en-us/library/ms677949(v=vs.85).aspx) (SPNs) are:
a unique identifier of a service instance. SPNs are used by Kerberos authentication to associate a service instance with a service logon account." - MSDN
Basically mapping a service running on a server to an account it’s running as so that it can do / accept kerberos authentication. Normally, these services, like “CIFS” (Windows Shares) run under the context of the computer account.
Why would they be associated with users?
I won’t say that this is the reason for the change, but for a long time Information Security professionals (and bad guys) have exploited the idea that services run as the all powerful “NT AUTHORITY\SYSTEM” account. For those who don’t know, this means that if someone exploits one of those services, they are basically ROOT on that machine in the Windows world.
One of the ways that Microsoft has enabled system administrators and software developers to step away from this paradigm is to create the [NT AUTHORITY\NETWORK SERVICE](https://msdn.microsoft.com/en-us/library/windows/desktop/ms684272(v=vs.85).aspx) and [NT AUTHORITY\LOCAL SERVICE](https://msdn.microsoft.com/en-us/library/windows/desktop/ms684188(v=vs.85).aspx) accounts. This allowed basic permissions and are great alternatives. However, these accounts, while perfectly limited, did not have any authentication abilities on the network. So, system administrators started using domain accounts to run services. This is where things go wrong again.
Yes, I know there is such a thing as [Managed Service Accounts](https://technet.microsoft.com/en-us/library/dd560633(v=ws.10).aspx) now (introduced in 2011 with a Windows Server 2008 R2 update) and spoiler alert, that’s the fix to the issue we will be discussing below and in the next few parts, but even MSAs have an issue that I’ll discuss in the last section of this series.
Why should I care?
Any valid domain user can request a kerberos ticket for any domain service (or even services outside the domain as long as there is a trust there). Once the ticket is received, password cracking can be done offline on the ticket to attempt to break the password for whatever user the service is running as. The users running these services usually are at the very least administrators on the computers for which they are a service on, but more commonly they are some sort of administrative account (Domain Admins).
Listing SPNs
Ok, so, now you know the background and why you want to do this attack, but how do we go about listing what SPNs are out there for the domain you are on. There are a ton of ways to do this:
- Just use the built in
SetSPN.exebuilt into Windows - Use the Get-SPN.ps1 that @_nullbind (Scott Sutherland) posted about on the NetSPI blog in a post titled Faster Domain Escalation using LDAP
- Use the PowerShell Empire port of @_nullbind’s Get-SPN powershell script
- Use Tim Medin - @timmedin’s GetUserSPNs VB script
- Use Tim Medin - @timmedin’s GetUserSPNs PowerShell script
- Use Impacket’s GetUserSPN.py - unlike the other tools and techniques, this one executes without the advantage of the Windows tokes, so you are going to need credentials, but this is also the advantage as you are not loading anything on disk or executing anything through the use of cmd.exe or powershell.exe
1. SetSPN
SetSPN is a tool built into Windows and will do that job perfectly just as Tim Medin describes in his presentation and Kerberoast Github repo:
|
|
Each line that starts with “CN” is an account" and the SPNs under it are the ones associated with that account. Lots of great information can be determined just from the output of this command. Even though for cracking purposes we only want the SPNs associated with possibly weak password accounts (usually only User accounts), we should still pull this information down.
Get-SPN
This module gives you a lot more information than SetSPN did. Having the PasswordLastSet and LastLogon helps to figure out when and if an account has ever been used. In the example below the “sqladmin01” account has never logged on and was created recently. If this password cracks then there is a good chance that it is some common password set when setting up accounts
Disclaimer: As of this writing, this module only works with PowerShell 3.0+
|
|
PowerShell Empire
This module basically just incorporates the script from above.
Disclaimer: As of this writing, this module only works with PowerShell 3.0+
|
|
Listing User SPNs
GetUserSPNs.vbs
GetUserSPNs was the first script to focus only on accounts that were Users. When you are looking at a network that has 40,000+ Windows boxes and all of the has the “HOST” SPN, it’s a lot to trudge through. This script cuts the fat and just gives you the list of SPNs that have a much higher chance of having their accounts cracked.
|
|
GetUserSPNs.ps1
I really like this script because it tells you the time the password was last set. This allows for you to make educated selections on which accounts to attack with your password cracking. (More hashes needed to crack, the longer it takes)
Below I use the IEX (Invoke-Expression) command in PowerShell to download and run the PowerShell script directly from Tim’s repository, but you could just as easily upload it and run it.
|
|
Impacket
Impacket is a recent addition to the list of tools that perform SPN listing. Pull request #153 - TGS-Response code to work with windows AD was all it took to motivate @agsolino into making an example script and while PyKerberoast by @skelsec came first, it doesn’t have a plain “list” function so I wanted to save it for the extraction post.
|
|
And that is it for now. We have listed all of the SPNs or just the ones we needed. In Part 2 we will make requests for the SPN tickets we want.
References:
Tools
Presentations
- Tim Medin’s Slides - [Kicking the Guard Dog of Hades - slides](https://files.sans.org/summit/hackfest2014/PDFs/Kicking%20the%20Guard%20Dog%20of%20Hades%20-%20Attacking%20Microsoft%20Kerberos%20%20-%20Tim%20Medin(1).pdf)
- Tim Medin’s Video - Kicking the Guard Dog of Hades - video