Kerberoasting dans Active Directory : fonctionnement et stratégies de défense

Kerberoasting is a post-compromise attack that leverages the design of Active Directory to extract passwords from service accounts. Attackers exploit the way Kerberos tickets are created and used to gain access to sensitive data and systems. The attack relies on a simple user account to enumerate service principal names (SPNs) and then request a service ticket, allowing them to crack the service account password. Effective defenses involve strengthening passwords, migrating away from RC4_HMAC encryption, implementing multi-factor authentication, and monitoring Kerberos ticket requests for anomalous activity. A key takeaway is that focusing solely on initial breaches misses the crucial phase of exploitation *after* access is gained, and neglecting Active Directory's internal vulnerabilities can lead to significant damage.

Kerberos becomes a point of entry for attackers due to the fundamental architecture of Active Directory. In the early days of local networks, ease of connectivity was the priority, and security was reduced to a perimeter guarded by identifiers. However, this naive model quickly became a vulnerability. The theft of credentials began almost immediately with the first versions of Active Directory. But the architectural weaknesses went far beyond simply underestimating passwords; Active Directory was, and remains, inherently open. Once an attacker breaches the perimeter by compromising a standard user account, the internal design of the directory facilitates deeper access.

The technique known as Kerberoasting, documented for the first time during a 2014 research presentation by Tim Medin, exploits this openness with devastating effectiveness. Its primary target is service accounts – machine identities used to run applications in the background within AD, such as SQL Server, Exchange, IIS, or backup solutions. These accounts often possess elevated privileges. Because they are machine identities rather than human ones, they frequently evade standard identity monitoring devices, making them a security blind spot.

Kerberoasting is a two-stage process. The first is reconnaissance. Using LDAP queries and common tools, the attacker enumerates accounts possessing a Service Principal Name (SPN) registered in Active Directory. SPNs are labels that allow the Kerberos authentication protocol to identify the services to which users want to access.

This enumeration phase reveals a structural weakness: any user account in Active Directory, even one with limited privileges, can execute LDAP requests to list SPNs within the directory. Attackers don’t need to be administrators to identify valuable service accounts. A compromised standard account is sufficient to map the terrain.

Once an interesting SPN is identified, the attacker requests a service ticket (ticket TGS) from the ticket-granting service. This is a legitimate mechanism within the Kerberos operation. A user authenticates, obtains a Ticket Granting Ticket (TGT) from the Key Distribution Center (KDC), and this TGT then allows access to services without needing to re-enter credentials each time.

Cracking service accounts offline. The ticket received by the attacker contains a partially encrypted piece of information using a key derived from the service account password. The attacker retrieves this ticket offline and attempts to crack it using tools like Hashcat.

The speed of the operation depends on two factors: the robustness of the password and the encryption algorithm used. If the ticket is encrypted with RC4_HMAC, a weak algorithm still present in many environments, cracking can be fast. AES-256 significantly increases the difficulty, but not necessarily prevents cracking when passwords are weak or reused.

In theory, this is where Kerberoasting should fail. Strong passwords and modern encryption should constitute barriers. In practice, however, this is often not the case. Service accounts are managed inconsistently. Password rotation is neglected. Legacy configurations persist. This combination explains why Kerberoasting has remained a cornerstone attack in ransomware campaigns for over a decade.

Once an attacker cracks the password of a single service account, the impact depends on the access it possesses. Taking control of a high-privilege service account can mean taking control of the applications and data associated with it.

Active Directory can be hardened against this attack, but it requires deliberate effort. The starting point is password rigor. Service accounts must have long and complex passwords, and should be converted to Group Managed Service Accounts (GMSA) wherever possible. GMSAs automate password generation and rotation, eliminating the human factor that makes manual management unreliable.

On a protocol level, organizations using RC4_HMAC should prioritize migration to AES-128 or AES-256. Microsoft has recommended this for years. The persistence of RC4 in many networks is less about a technical necessity and more about operational neglect.

Multi-factor authentication (MFA) should be applied to user accounts, accompanied by real-time monitoring of access activity to detect anomalous behavior. Kerberos ticket requests should also be monitored: unusual spikes in the number of TGS requests constitute a detectable signal of Kerberoasting activity, provided the logging infrastructure is in place to surface them.

The place of your security tools in Active Directory isn’t neutral, and for defense against Kerberoasting in particular, architectural positioning matters. Some tools deploy directly on domain controllers or integrate into the Kerberos authentication chain. The appeal is obvious: maximum visibility and control. The risk is equally high. A tool positioned within the authentication chain becomes a target in itself. If compromised, the attacker inherits its position, with potential access to the authentication infrastructure itself.

an alternative approach involves maintaining security controls outside the authentication chain. A tool can communicate with Active Directory via LDAP to read user attributes, group memberships, and access conditions, then apply policies at the session layer rather than intercepting ticket attribution. This approach contains the impact radius. Compromise of the security tool doesn’t propagate to the Kerberos infrastructure.

Solutions like UserLock rely on this principle, applying access controls at the session layer without inserting into the Kerberos ticket attribution flow. The authentication chain continues to function independently, even if the security tool is targeted.

The real lesson of Kerberoasting is that reporting on cybersecurity tends to focus on initial breaches: the phishing email, the exploited vulnerability, the stolen credentials. What happens *after* this initial access is given receives far less attention. In Active Directory environments, this is precisely the wrong priority. The techniques deployed by attackers after gaining a foothold – from Kerberoasting to credential harvesting to lateral movement – are often what determine whether an incident becomes a breach. The initial breach is the door. Kerberoasting is what happens *after* they’re inside.