Kerberoasting in Active Directory: How it works and how to stop it

Kerberoasting is one of Active Directory's most dangerous and most exploited attack techniques. Starting with nothing more than a low-privilege user account, an attacker can extract a service account password hash and crack it offline. No elevated access required, and no domain controller touched after the initial ticket request. This article explains how the attack works, why Active Directory is structurally vulnerable to it, and what defenders can do to protect their environment.

The whole point of networking in the earlier LAN era was to make it easy to find and connect to network resources, a philosophy that prioritized ease and speed of connectivity. When it came to security, the LAN was viewed as a simple perimeter guarded by user credentials. If you had the right credential, you were assumed to be trustworthy.

By today's more pessimistic outlook, this is viewed as naively open to abuse. Of course credential theft started as soon as Active Directory first appeared.

Unfortunately, the flawed security assumptions went deeper than simply underestimating the weakness of passwords. Active Directory was, and is, very trusting in its internal design. Once an attacker has penetrated beyond the security perimeter by compromising an ordinary user account, the directory's open design makes it easier than it should be to move to deeper levels inside the system.

The key for attackers is to find a foothold for lateral movement from a low-privilege user account whose credentials they have compromised, to a higher-privilege account with greater powers. Kerberoasting, first documented in a 2014 research presentation by researcher Tim Medin, is one of the most widely exploited and best-known techniques for achieving this.

In theory, the target could be any high-privileged account, but the most sought after is usually service accounts.

Service accounts are non-human machine accounts used to run background Active Directory applications, for example, SQL Server, Exchange, IIS Web Server, or a backup application. This access makes them an obvious draw.

If an attacker can take over a service account, they can access and control applications directly. Better still, because service accounts are machine identities, they are often not subject to the same monitoring as human identities in ways that turn them into a security blind spot.

Targeting service accounts in Kerberoasting is a two-stage process, the first part of which is reconnaissance and discovery using hacking tools and LDAP queries to list service accounts which have a Service Principal Name (SPN) attribute registered. Stored in Active Directory, SPNs are labels that allow the Kerberos authentication protocol to identify and authenticate the network services users are trying to access.

This SPN enumeration is useful for several reasons. First, because in general service accounts have SPNs, it helps attackers identify these accounts from thousands of low-value user accounts. Second, it provides the precise string required to launch a full-scale Kerberoasting attack on any service accounts which have been granted Domain admin powers.

This underlines a larger Active Directory weakness: any user account, even a low-privileged one, can run these LDAP queries. No wonder attackers start with low-value accounts; no matter how limited in its privileges, in Active Directory any account can be exploited as a weak point.

Having identified a valuable SPN, the next stage of Kerberoasting is to request a service ticket (TGS ticket) from the Ticket Granting Service, using the TGT obtained during initial authentication. This aspect of Active Directory is a convenience, similar in principle to the way persistent tokens work; a user authenticates to Active Directory after which the encrypted TGT issued by the Key Distribution Center (KDC) allows them to keep accessing an application without the need to constantly re-authenticate.

Because the captured service ticket contains a portion encrypted using the service account's password-derived key, attackers still have work to do. Attackers must take the ticket offline and attempt to crack it with a password cracking tool such as Hashcat. How long this takes depends on a combination of the password length and complexity and the algorithm used to encrypt it: RC4_HMAC is weak and crackable in short order, while AES-256 makes offline cracking considerably harder.

In theory, this stage should be where Kerberoasting is stopped, with a strong password and encryption algorithm being the barriers. Unfortunately, under real-world conditions, this is often not the case, which is why the technique became so popular in the first place as part of ransomware attacks.

What happens next depends on which tickets the attackers have managed to crack. But they only need to crack the password for one important application, and they gain control over it and its data.

It's tempting to heap the blame for this technique solely on weaknesses in Active Directory and Kerberos. This is true up to a point. The security design puts too much emphasis on perimeter security implemented through password credentials, leaving itself vulnerable to attackers who get past this layer.

But Active Directory can be hardened if defenders take the time. Implementing this usually starts with ensuring that all accounts apply robust password policies. IT should also apply multi-factor authentication (MFA) to user accounts along with some form of live access activity monitoring to spot unusual access patterns.

For service accounts, human error can be removed from the equation by ensuring they are all Group Managed Service Accounts (GMSAs) rather than user managed. These automatically apply strong password policies and password rotation. Kerberos ticket requests should be monitored to spot unusual patterns such as spikes in the number of requests.

As recommended by Microsoft for some time, organizations that suspect they might still be using RC4_HMAC on their network should prioritize moving to AES-128 or AES-256 as soon as possible.

Not all third-party security solutions approach Active Directory the same way. For Kerberoasting defense specifically, the architectural relationship between a tool and the domain controller is worth understanding before making a selection.

Some tools deploy directly onto Domain Controllers or insert themselves into the Kerberos authentication chain. The appeal is visibility and coverage: sitting close to authentication means seeing and controlling everything that happens there. The downside is that it concentrates the blast radius. A tool positioned inside the authentication chain becomes a target. If compromised, the attacker inherits that position, which could mean inheriting access to the authentication infrastructure itself.

For some environments, a more defensible design is a solution that sits outside the authentication chain. It communicates with Active Directory, reading user attributes, group memberships, and access conditions via LDAP, and enforces policy at the session layer rather than intercepting ticket-granting. A compromise of the tool does not cascade into the Kerberos infrastructure. The authentication chain continues to function, and the blast radius is contained.

Solutions such as UserLock are built this way. UserLock communicates with domain controllers via LDAP to read policy-relevant data, while the Desktop Agent enforces access controls at the Windows logon layer. Neither component inserts itself into the Kerberos ticket-granting flow, which means UserLock is not a single point of failure for authentication.

This is a deliberate architectural choice, not a limitation. The security value of a third-party solution shouldn't come at the cost of creating a new attack path. For organizations evaluating options to harden their AD environment, that trade-off is worth weighing explicitly.