Kerberoasting in a Nutshell
Post-exploitation tools are the bread-and-butter for any successful cyber-attacker. Once the initial foothold is made into a network and breach is assumed, the attacker must go to work to gain situational awareness, escalate privileges, and move laterally through the network undetected. Commonly misconceived, the exploitation phase of the cyber kill chain takes place in mere moments, primarily consisting of getting a piece of malware on one system in the victim network. The heavy lifting in a cyber-attack then takes place after the first asset is compromised.
If you observe trends in post-exploitation tools over the years, you will notice that they change rapidly. Most of the time, change is instigated by the evolution of best practices. Some years ago, exploiting Group Policy Preferences was a go-to for attackers to gain escalated privileges on a network. Later, exploiting LLMNR, NetBIOS over TCP, and WPAD protocols became an offensive trend, as relying on broadcast-based protocol’s design weaknesses yielded quick results. Now, a more refined technique called “kerberoasting” has dominated the scene. In grabbing ticket hashes by using the Kerberos protocol design flaws, in conjunction with an understanding of human nature on passwords, attackers can own networks relatively quickly and reliably.
How Kerberos Works
In order to understand why kerberoasting is significant, you must first understand what Kerberos is, how it functions, and why it is important. In short, the protocol itself serves an essential purpose — providing secure authentication to services on an open network. Starting with Windows 2000, Kerberos is the go-to method of brokering authentication to services on Windows-based networks, so its use is almost guaranteed in many organizations. You see this in use when you access file shares, applications, web portals, or even your email.
To quickly understand how the Kerberos protocol works, think about going to see an ‘R’ rated horror movie at the local theater. First, you must go to the ticket booth at the theater (the Key Distribution Center, “KDC” — in Windows networks. This is likely the Domain Controller) and purchase a ticket. In order to prove you are who you say you are and that you are old enough to be there, your ID will be requested (your password in the form of an NTLM hash). This movie is rated ‘R’ after all!
After the whole process of identifying and purchasing, you have a movie ticket (a Ticket-Granting Ticket, or “TGT”), usually perforated down the middle. This ticket is then brought to the ticket-taker (in the form of a Ticket-Granting Service request, or “TGS-Request”), who validates it and rips it down the middle (the “TGS-Response”). One half stays with the ticket-taker, while the other is given back to you as proof that you went through the whole process. The stub allows for re-entry within a reasonable time frame (the TGS ticket). Enjoy your movie!
Now, what protection does this provide? For one, the ticket-taking booth as well as the moviegoer have proof that the purchase happened, and that you are permitted to be there. This is commonly referred to as ‘mutual authentication’. For another, it generates a timestamped stub to indicate what you are there to see, and when. Imagine coming in the next day and presenting yesterday’s stub to the ticket-taker? They would turn you back around and request you purchase another ticket! Ideally, the same thing happens with Kerberos. After a set number of hours, you will need to re-authenticate to access the resource.
Where’s The Issue?
Here is where the kerberoasting technique will burn you. Services on Windows networks which are capable of Kerberos authentication maintain Service Principal Name attributes (SPNs), which essentially is an alias for use with the protocol that is registered with the KDC. Think of it as a neon sign, displaying the name “Web Server”, or “CMS Application”, making it easier for workstations to identify the service being offered.
In Windows networks, Kerberos requires that each SPN be associated with a service account on the domain. A user with a valid TGT ticket can request a TGS ticket for any of the services with SPNs via the domain controller by using legitimate LDAP queries. These tickets are encrypted with an NTLM hash of the service account’s password, which lend themselves well to being taken offline for cracking.
To put it bluntly, if you are successfully authenticated on the domain using Kerberos, and you have an active session, you can request tickets from the domain controller for any service account with a registered SPN. Depending on how you set up permissions for your service accounts, this could include accounts in the Domain Admins group, Remote Desktop groups, or local administrators. What’s worse, there is a wide variety of freely available tools which automate all aspects of this technique.
What It Means For You
Here’s where I break the bad news to you — there is no direct fix or patch for this vulnerability. It exists firmly in the design of Windows’ implementation Kerberos for functionality with Active Directory. The old adage “It’s not a bug, it’s a feature!” is very much applicable here. Instead, set your sights on your organization’s configuration practices to harden yourself from kerberoasting.
Focus your efforts on mitigating the brute-forcing aspect of the attack. Ask yourself, what are the password complexity requirements in use for you service accounts? Do you have a requirement for how long and difficult they should be? If you follow a secure baseline such as DISA STIG, it is very possible you are exempting service accounts. The recommendation from MITRE is 25+ characters, alphanumeric, with capital/lowercase letters and symbols. This should provide significant strength to prevent most brute-forcing attacks.
Next, think about what your service accounts have access to. If you have not tailored the permissions for your service accounts, you will want to consider it. When you create one, think about the risk you would face if the account were to be compromised. Would an attacker have free reign over your network? Or would they be confined to only one or two servers?
Beyond the password length recommendation, you may want to ask when the last time many of these service accounts were changed, and if any service accounts are still floating around from applications long gone. More often than not, environments are afraid to touch service accounts out of fear that a server somewhere out there is still using it to run a critical application. Avoid this urge!
If you need some guidance to identify where these accounts are being used, and you have a log aggregator like Splunk at your disposal, you may be able to run queries for where the accounts are logging into and when. PowerShell also has strengths here, and you may be able to check in with your DC on when these accounts last logged in. If they haven’t been seen in a while, get rid of them! Finally, make sure Kerberos is using strong encryption on your network. Algorithms like RC4 and DES are weak, and have long-standing issues. Configure AES Kerberos encryption via Group Policy, and you are taking a strong step towards resilience against this attack.
Post-exploitation techniques are indeed getting trickier to mitigate, but if you take the right precautionary steps you can avoid getting severely burnt!
Thanks for reading! I am a Sr. Security Engineer with InquisIT, offering premier cybersecurity services to the federal government. Our goal is to help agencies tackle complex cybersecurity challenges, and bridge policy into operations. Comments or critiques? Reach me on LinkedIn , email — jtrinka[at]inquisitllc[dot]com, or reply below.
