Securing Active Directory Against Kerberoasting Attacks

In enterprise networks, Active Directory (AD) manages identity and access control. However, legacy configurations and the Kerberos authentication protocol’s design introduce vectors that attackers exploit. One such lateral movement and privilege escalation technique is Kerberoasting.

In this article, we explain the mechanics of a Kerberoasting attack and how security administrators can harden Active Directory environments to prevent it.

Understanding Kerberos and SPNs

Active Directory uses the Kerberos protocol to authenticate users. When a user requests access to a service (like an SQL database or a shared file system), their system requests a service ticket from the Domain Controller.

Kerberos identifies services using a Service Principal Name (SPN). Every SPN is bound to an Active Directory account under whose credentials the service runs. This is often a standard user account configured as a Service Account.

The Kerberoasting Exploit Path

To secure communication, the Domain Controller encrypts the ticket containing the user’s authorization details using the NLM/Kerberos hash of the service account’s password.

Here is why this protocol design is vulnerable:

1. No Admin Privileges Needed: Any domain-joined user (even a standard employee account) can request a Ticket Granting Service (TGS) ticket for any service account with an SPN registered in the domain.
2. Offline Cracking: The Domain Controller hands the encrypted ticket to the client. The client can extract this ticket from their memory, save it to a file, and transfer it to an offline machine.
3. Password recovery: The attacker attempts to crack the password hash offline using dictionary tools like Hashcat or John the Ripper. Since this cracking happens on the attacker’s own hardware, it generates zero logs on the Active Directory network, avoiding detection.

If the service account has a weak or common password, the attacker will recover the plain-text password within seconds, compromising a high-privilege account.

How to Harden Active Directory

Defending against Kerberoasting requires a multi-layered approach:

1. Implement Group Managed Service Accounts (gMSAs)

Traditional user accounts are susceptible because their passwords are created by humans. By transitioning to gMSAs, Active Directory automatically manages the service account password. It generates a 240-character random password and rotates it every 30 days. These passwords are cryptographically impossible to crack offline.

2. Enforce Strong Passwords

If gMSAs cannot be used due to legacy application constraints, enforce a password policy of at least 25 characters for all service accounts. An attacker will not be able to crack a high-entropy 25-character password, rendering the harvested ticket useless.

3. Transition to AES Encryption

Older configurations might still support legacy RC4 encryption for Kerberos tickets. RC4 hashes are significantly faster to crack offline compared to modern AES-256 hashes. Disable RC4 support and enforce AES encryption for Kerberos communication.

4. Setup HoneyToken Accounts

Create an attractive dummy service account with an SPN, but configure it to not run any actual service. Since no legitimate system should ever request a ticket for this account, any TGS request targeting it is highly likely to be malicious. Monitor domain controllers and trigger alerts on requests for this honeytoken account’s SPN.