Kerberoasting: A Blue Team Perspective
I’ve gotten into kerberoasting lately and thought this would be a good opportunity to talk about auditing your SPN’s and encryption types in your environment. There are some pitfalls that I thought I should explain first so that you can adequately plan and eventually remediate RC4 based Kerberos encryption types in your environment.
First lets start with a typical network hardening scenario of Kerberos in a Server 2016 Domain Controller Environment. Its a safe bet you may see a domain controller configured with these default encryption types kerberos…. you also might not see these at all if you applied the default Microsoft Security baseline.
The issue is around weak ciphers. Particularly RC4. Depending on your service account password strength. Having a default Kerberos encryption type of RC4 combined with a weak password you can run the risk of the service account password compromise. Running these types of tools require no special rights to use and cracking the passwords can be done entirely offline.
So lets start with setting a SPN on a service account in our environment. This is a good resource for syntax related items with setspn.exe
In the script below I do a check to make sure my service account for this user ID does not exist. Next I’ll attach an spn name of http/project1.local to the SPN.
At the end of this setup the domain administrator is done. I think what goes on from here happens a lot without any checking on the security of the SPN that was put in place.
A few things about setting SPN’s. Setting SPN’s require domain administrator rights. One problem with this is some orgs may have allowed other accounts such as SQL Service accounts to automatically register SPN’s. Doing custom modifications inside of ADSI can be extremely difficult to detect.
Microsoft has a good article that has since been removed to automatically register SPN’s as outlined in Step 3 of this article:
Every administrator should make a print out of the above reference link and start taking inventory of SQL service accounts. You will have to get into ADSI edit and look at the properties of the account with the “Self Permission”. Usually the properties granted will be blank. So when you dig into the permission you will probably fine both read and write service principal names.
The problem with service accounts having SPN write ability is because of compromise. You can set an SPN to any account in the Active Directory domain. So attackers can leverage setting SPN’s to domain admins and use RC4 downgrade attacks to crack their passwords in a offline manner.
Next I will take a look at the encryption type of the SPN I just set up in the above screenshot by using the following powershell code:
Add-Type -AssemblyName System.IdentityModel
New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList “SPN NAME”
Next I will open a command prompt and type klist:
As we can see in the about screenshot the Kerberos ticket is using a RSADSI RC4-HMAC(NT) encryption type. This is not good especially if the password is weak.
So before we start further I’m going to show how to compile and use Rubeus as a blue team tool to audit all your SPN’s that are using RC4. Rubeus is used by Red Teams to dump hashes that support RC4 encryption types. I like it because you can inventory all SPNs that support RC4 very quickly so that you can ultimately plan for remediation.
(Warning: Obtain approval from your information security or risk department prior to running these types of tools. Especially on a production network)
All GhostPack files will need to be compiled using an IDE editor. Visual Studio Community edition will work for our needs. You can download it here:
Rubeus can be found at the following github repository:
When you install Visual Studio Community I did the following options. If you choose UWPD along with .net desktop development this should give you the necessary components to compile Rubeus yourself with different .net library options.
I also choose multiple .net framework targeting packs so I could compile Rubeus using different .net frameworks. This gives you alot of flexibility to drop Rubeus on machine without having to upgrade the .net framework version that is on the machine.
Next you will right click on the Rubeus.sln file and load it with Microsoft Visual Studio 2019.
You will probably get a warning that the targeted .net framework 3.5 does not exist and will ask to change the target .net framework to 4.6.1. This is fine to do. Below I will show you how to change the targeted .net frameworks to lower or higher versions. The purpose of compiling Rubeus with multiple .net framework versions is so you don’t have to upgrade the .net framework on the target machine. Especially for stealth.
You can always click on the properties of Rubeus in visual studio and change your target framework to different editions as shown below.
Once you selected your .net framework targeted framework you can click on Build > Build Solution to compile Rubeus into a .exe.
Here is a handy chart especially for a red team on .Net Framework versions and dependencies.
Rubeus has a fantastic help file when you run Rubeus.exe. I am not going to dive into great detail but will give a list of a couple of commands that will be most useful for Blue Teams.
Rubeus.exe kerberoast /stats
This gives you high level summary of kerberoastable users on your target domain network that support default RC4 encryption types.
Rubeus.exe kerberoast
This will kerberoast all accounts both AES and RC4. This is the list you will want to target on remediation starting with the RC4 accounts first.
If you want to specifically just target RC4 you can do so by do the following command:
Rubeus.exe kerberoast /rc4opsec /nowrap
Next lets remediate service account 1028892723SA. We are going to do a couple of things to it.
- Set service account password to a random 25 character password.
- Set account to support AES256 by doing the following.
As you can see below this service account now has a supported encryption type of AES256_CTS_HMAC_SHA1_96
So you may be asking yourself. Why is this account Kerberoastable its now using a AES256 encryption type with a strong 25 character password. The krb5tgs$18$ hash indicates this is running default AES256 encryption
See Reference:
Lets run the following command:
Rubeus.exe kerberoast /usetgtdeleg /nowrap
As you can see from the above output we are back at a krb5tgs$23$ encryption type hash which is RC4 even though the supported encryption type is AES256. If you haven’t changed your password to the service account or if it has a weak password RC4 can easily be reversed.
This is why its absolutely imperative that you set service accounts to a minimum of 25 characters. It will make cracking this password more difficult to crack. This is your first line of defense against kerberoasting attacks.
Some Weirdness to know about.
Lets say you do have a strong password account and you decide not to change the password but you do set the encryption type supported to AES256 but after running Rubeus.exe kerberoast you find yourself staring at a krb5tgs$23$ hash without performing an RC4 downgrade.
First rest easy. This is due to TTL’s on user tickets set to 10 hours in the default domain policy for Kerberos:
Doing a password reset immediately fixes the issue. Otherwise you just need to wait and this issue will resolve itself out.
So what happens after you A) Set all encryption types to AES and B) Set the domain controller policy for Kerberos to not allow RC4 encryption below: (hint these settings are not configured if you download the server 2016 baseline from the Microsoft Security Compliance Toolkit: https://www.microsoft.com/en-us/download/details.aspx?id=55319
This is the spot you want to be in on your network. RC4 downgrade attacks no longer work:
So just to re-iterate to protect yourself on kerberoasting attacks.
- Set service account passwords to a minimum of 25 characters. Higher password entropy is your best defense. Audit your passwords if possible. I highly recommend this tool to use to audit your network’s passwords. You can take inventory of accounts with weak passwords.
(Hint: If you run the weak password tool and the account is flagged as missing AES keys. You have to reset the password first before you can use an AES encryption type for kerberos with the account)
2. Mark your service accounts with AES128 or 256 encryption
3. Remove RC4 encryption via group policy. Apply this to both Domain Controllers, member servers, and Windows 10 Clients.
