Kerberoasting: The Cyber Technique for Cracking Weak Active Directory Passwords

To comprehend how Kerberoasting works, we must first briefly understand the fundamentals of the Kerberos protocol and the role of Service Principal Names within Active Directory.

Kerberos is a ticket-based authentication protocol. When a user logs into a Windows domain, they don't send their password directly to the file server or SQL database they want to access. Instead, they authenticate to the Key Distribution Center (KDC), which resides on the Domain Controller.

The authentication flow works like this:

1. Authentication Service (AS) Request: The user authenticates to the KDC and receives a Ticket Granting Ticket (TGT). This TGT proves the user's identity.
2. Ticket Granting Service (TGS) Request: When the user wants to access a specific service (like an MS SQL database), they present their TGT to the KDC and request a Service Ticket (TGS) specifically for that service.
3. Application Access: The user presents this Service Ticket to the SQL database. The database verifies the ticket and grants access.

This is where Service Principal Names (SPNs) become critical. An SPN is a unique identifier for a specific service running on a server. It tells Active Directory which account is running the service. For example, if a SQL server is running under a specific domain user account called svc_sqladmin, an SPN is registered in AD linking the SQL service to that user account.

The fundamental vulnerability exploited by Kerberoasting lies in the creation of the Service Ticket (TGS) during step 2. When the Domain Controller creates the Service Ticket for the user, it encrypts a specific portion of that ticket using the NTLM password hash of the account associated with the SPN (in our example, the svc_sqladmin account).

The brilliance and danger of Kerberoasting lie in its simplicity and its stealth. The attack does not require exploiting a software zero-day vulnerability, nor does it require administrative privileges. Any valid domain user can execute a Kerberoasting attack.

The attack unfolds in the following distinct phases:

1. Reconnaissance (Finding the SPNs) The first step for the attacker is to identify targets. Once the attacker has gained initial access to a standard user workstation (perhaps via a phishing email), they query the Active Directory environment to find all user accounts that have an SPN associated with them.

Active Directory is inherently designed to be readable by any authenticated user. The attacker uses simple LDAP queries (often automated via tools like PowerShell's PowerView or the Impacket suite) to ask the Domain Controller: "Please give me a list of all user accounts that are running a service." The Domain Controller gladly provides this list. The attacker ignores computer accounts (which have complex, randomly generated 120-character passwords that are rotated every 30 days) and focuses exclusively on human-created Service Accounts, as these are far more likely to have weak, human-created passwords.

2. Requesting the Service Tickets (The "Roast") With a list of target service accounts in hand, the attacker proceeds to request Service Tickets (TGS) for each of those SPNs. Remember, the Kerberos protocol is designed to allow any user to request a ticket for any service. The attacker does not actually need to connect to the SQL database or the web server; they only need to request the ticket from the Domain Controller.

Using built-in Windows tools or specialized hacking scripts, the attacker sequentially requests a TGS for every interesting SPN they discovered. The Domain Controller obliges, generating the tickets and sending them back to the attacker's compromised workstation. Crucially, the sensitive portion of each ticket is encrypted with the password hash of the target service account.

3. Offline Password Cracking The attacker now possesses the encrypted service tickets in the memory of their compromised workstation. They extract these tickets (often using tools like Mimikatz or Rubeus) and export them to a file.

This is where the attack becomes an offline attack, which is the defining characteristic of Kerberoasting. The attacker transfers the file containing the encrypted tickets out of the corporate network and onto their own high-powered, GPU-equipped cracking rig. Using password cracking software like Hashcat or John the Ripper, along with massive dictionary wordlists, the attacker begins to brute-force the encryption.

The cracking tool works by hashing words from the dictionary and attempting to decrypt the ticket. Because the encryption algorithm (often RC4) is relatively fast to compute, a powerful GPU rig can attempt billions of password guesses per second. If the service account was configured with a weak password like CompanyName2023!, the attacker will crack the hash and recover the plaintext password in minutes.

4. Privilege Escalation and Lateral Movement Once the plaintext password is recovered, the attack is complete. The attacker now possesses the credentials for a service account. In many legacy Active Directory environments, service accounts are vastly over-privileged. An account meant to run a backup service might be a member of the "Domain Admins" group to avoid permission issues. If the attacker cracked a Domain Admin service account, they instantly possess total control over the entire network, allowing them to deploy ransomware, exfiltrate data, and create persistent backdoors.

Kerberoasting is a favored technique among Red Teams and ransomware operators for several critical reasons:

• No Admin Rights Required: It can be executed by the lowest-privileged user in the domain.
• Extremely Stealthy: Requesting service tickets is normal, expected behavior on a Windows network. A user requesting a ticket looks exactly like legitimate network traffic. It does not trigger traditional antivirus or Endpoint Detection and Response (EDR) alerts, and it does not generate "failed login" events that would alert the Security Operations Center (SOC).
• Exploits Human Weakness: The attack relies entirely on the fact that IT administrators often create service accounts with weak, human-readable passwords and set them to "Password never expires."

Defending against Kerberoasting requires a combination of strong password policies, proper account management, and utilizing modern Active Directory security features. Because the attack exploits the fundamental design of Kerberos, it cannot be completely "patched" away; the risk must be mitigated through configuration.

1. Enforce Massive Passwords for Service Accounts The most effective and immediate defense against Kerberoasting is rendering the offline cracking phase mathematically impossible. Service accounts are not humans; they do not need to remember their passwords. If an account requires an SPN, its password should be a randomly generated string of at least 30 to 40 alphanumeric characters. A password of this length and complexity cannot be cracked by any modern GPU rig before the universe ends.

2. Implement Group Managed Service Accounts (gMSA) For modern Windows environments, the ultimate solution is to eliminate traditional service accounts entirely and transition to Group Managed Service Accounts (gMSAs). A gMSA is a special type of Active Directory account designed specifically for running services. The critical advantage of a gMSA is that Active Directory automatically manages the password. AD generates a highly complex, 120-character password and automatically rotates it every 30 days without any administrator intervention. Because the password is long and constantly changing, a gMSA is fundamentally immune to Kerberoasting.

3. Upgrade Kerberos Encryption (Disable RC4) Historically, Kerberos utilized the RC4 encryption algorithm (specifically RC4-HMAC). RC4 is weak and computationally fast to crack, making it ideal for attackers. Organizations should ensure that their Active Directory environment is configured to use the much stronger AES-128 or AES-256 encryption algorithms for Kerberos ticket generation. While AES tickets can still be extracted, they require significantly more computational power to crack than RC4 tickets, raising the cost and time required for the attacker. To force AES, administrators must ensure that the "Network security: Configure encryption types allowed for Kerberos" Group Policy is updated to disable RC4.

4. Adopt the Principle of Least Privilege Even if an attacker successfully Kerberoasts a service account, the impact should be minimized. Service accounts must strictly adhere to the Principle of Least Privilege. A service account should never be a member of the Domain Admins group. It should only possess the exact permissions required to run its specific application and access its specific database. By heavily restricting the privileges of service accounts, you limit the lateral movement capabilities of an attacker who manages to compromise the credentials.

5. Implement Targeted Detection (Honey SPNs) While detecting the actual Kerberoasting attack is difficult because the traffic looks normal, organizations can create traps. Security teams can create fake "Honey" service accounts with SPNs that have no legitimate business purpose. Because no normal user or application will ever request a service ticket for a fake service, any TGS request directed at the Honey SPN is almost certainly an attacker running an automated Kerberoasting script. Monitoring event logs for TGS requests to these specific honey accounts provides a high-fidelity alert of malicious activity on the network.