Kerberoasting Attack Explained: What It Is and How to Stop It

Kerberoasting is one of the most consistent findings in Active Directory penetration tests. It exploits a feature that has been in Windows since Windows 2000 and that most environments have never fully addressed.

Microsoft's December 2025 Active Directory threat guidance explicitly lists Kerberoasting as a high-priority threat, noting that it targets service accounts by requesting Kerberos service tickets and performing offline brute-force attacks to recover passwords, and that because the attack uses legitimate Kerberos functionality, it often goes undetected. The MITRE ATT&CK framework tracks it as T1558.003.

If your environment has service accounts with weak passwords, and most do, Kerberoasting is a quiet, reliable path to privilege escalation.

How Kerberoasting Works

When a user or application needs to access a service in a Windows domain, it requests a service ticket from the domain controller using Kerberos. That ticket is encrypted with the service account's password hash.

Any authenticated domain user can request a service ticket for any service in the domain. No elevated privileges needed. No admin rights. A standard account and network access are enough.

Kerberoasting is the attack where an attacker:

  1. Enumerates all service accounts in the domain that have a Service Principal Name (SPN) registered. This takes seconds using tools like Rubeus or Impacket's GetUserSPNs.py.
  2. Requests service tickets for every one of them.
  3. Takes those encrypted tickets completely offline, with no further network communication required.
  4. Runs a password cracker like Hashcat against the ticket hashes.

If the service account has a weak password, anything based on a word, a pattern, a season, or under 20 characters, it cracks. Modern GPU cracking hardware tests billions of password candidates per second against RC4-encrypted Kerberos tickets. A password like Summer2024! falls in under a minute. A properly generated 25-character random password may never crack.

The attack generates minimal logs, triggers no account lockouts, and is invisible to most endpoint security tools.

Why Service Account Passwords Are Weak

Service accounts are created to run scheduled tasks, application services, and integrations. They're set up once, given a password that meets complexity requirements, and then forgotten. Several factors keep them weak.

Password rotation is painful. Changing a service account password requires updating every application, scheduled task, and service configuration that uses it. Incomplete documentation means a rotation can break production. So nobody does it.

Expiration policies are disabled. Standard user accounts have password expiration. Service accounts are routinely excluded because the disruption risk is too high. Passwords set years ago remain in place indefinitely.

Legacy accounts accumulate. Many environments have service accounts whose original purpose is unclear. They remain active, have SPNs registered, and are fully Kerberoastable, with no one monitoring them.

How to Find Kerberoastable Accounts Right Now

You don't need an attacker to assess this. Run this PowerShell query with any domain user account:

Get-ADUser -Filter {ServicePrincipalName -ne "$null"} `
  -Properties ServicePrincipalName, PasswordLastSet, PasswordNeverExpires `
  | Select-Object SamAccountName, ServicePrincipalName, PasswordLastSet, PasswordNeverExpires `
  | Sort-Object PasswordLastSet

Review the output for three things: PasswordNeverExpires = True (high risk), PasswordLastSet older than 12 months (elevated risk), and SPNs that don't match any active service (orphaned accounts).

In most credit union environments, this query returns 5 to 20 accounts. Several will have passwords set 3 to 5 years ago.

Prioritizing Remediation With BloodHound

Kerberoastable accounts carry different levels of risk depending on what they can reach if compromised. This is where BloodHound attack path analysis becomes essential.

BloodHound's Kerberoasting query shows which service accounts sit on a path to Domain Admins. A service account that leads to domain admin in two steps is an immediate critical finding. A service account with no useful permissions is low priority.

Fix the high-path accounts first, regardless of how many total accounts you have.

How to Fix It

Step 1: Rotate all service account passwords immediately

Every account returned by the query above needs a password rotation to a randomly generated string of at least 25 characters. Use a password manager to generate these. Do not choose them manually.

Before rotating, document every place the account's credentials are used: services, scheduled tasks, and application config files. Update those first, then rotate the password.

Step 2: Migrate to Group Managed Service Accounts (gMSAs)

gMSAs are the permanent solution. Active Directory manages their passwords automatically: 240-character randomly generated strings that rotate on a schedule. They cannot be Kerberoasted because cracking a 240-character random password is computationally infeasible.

Not every application supports gMSAs. Check vendor documentation before migrating. For those that do, this eliminates the exposure permanently. Microsoft's gMSA documentation walks through the setup process.

Step 3: Remove orphaned SPNs

# List all SPNs registered in the domain
setspn -Q */*

Remove SPNs for services that no longer exist. Fewer SPNs means fewer targets.

Step 4: Require AES encryption on service accounts

In Active Directory Users and Computers, on each service account: Account tab, check "This account supports Kerberos AES 128/256 bit encryption" and uncheck "Use Kerberos DES encryption."

This forces Kerberos to issue AES-encrypted tickets rather than RC4. AES tickets crack significantly slower offline. It works alongside strong passwords as a defense-in-depth measure.

Step 5: Monitor for Kerberoasting attempts

Windows Event ID 4769 (Kerberos Service Ticket Request) with encryption type 0x17 (RC4-HMAC) is the primary detection signal. In environments that have migrated to AES, an RC4 ticket request for a service account is immediately anomalous. Configure alerting on this pattern in your SIEM or Windows Event Forwarding setup.

How This Connects to the Broader Attack Chain

A cracked service account password rarely produces domain admin access on its own. More commonly, it enables lateral movement. The attacker reaches servers the account can access, finds additional credentials there, or arrives at a misconfigured ADCS template. Where your Kerberoastable accounts sit in the overall attack graph determines how urgently each one needs attention.

For the full picture of what attackers do with compromised service account credentials, see our guide on Active Directory penetration testing for credit unions.

Frequently Asked Questions

Can Kerberoasting be done without admin rights? Yes. Any authenticated domain user can request service tickets for every SPN-registered account in the domain. This is by design in the Kerberos protocol, not a misconfiguration.

How fast can modern hardware crack service ticket hashes? A GPU cracking rig running Hashcat can test billions of RC4 Kerberos ticket candidates per second. Dictionary words with common substitutions crack in seconds. Passwords under 12 characters with standard complexity crack within hours. Randomly generated 20+ character passwords are computationally infeasible.

Does patching Windows fix Kerberoasting? No. Kerberoasting exploits how Kerberos authentication is designed to work. The fix is operational: strong service account passwords or gMSAs. Patches do not address it.

Sources

Stay sharp. Stay prepared. — ThreatForged AI

Written by Ryan Kucher, founder of ThreatForged AI. Book a scoping call to find out which Kerberoastable accounts in your environment have crackable passwords.