1. The Vulnerability: A Protocol Feature Turned Weapon
Kerberos is the authentication backbone of every Active Directory environment. When a user or application needs to access a service, the Key Distribution Center (KDC) issues a Ticket Granting Service (TGS) ticket — encrypted with the service account's password hash. This is entirely by design.
The problem: any authenticated domain user can request a TGS for any registered service principal name (SPN). No elevated privileges required. The ticket lands in the attacker's memory, and from that point on, cracking happens entirely offline — no network traffic, no failed logins, no lockout.
When the TGS is encrypted with RC4 — which older environments still negotiate by default — the resulting hash has no salt and no key-stretching. A modern GPU can test hundreds of millions of password candidates per second. A weak password falls in seconds.
Tactic: Credential Access. Threat actors including APT29, FIN7 and Wizard Spider actively use Kerberoasting for lateral movement and privilege escalation. IBM X-Force 2025 attributes 30 % of all breaches in 2024 to credential abuse (secondary citation via Microsoft Security Blog).
Why RC4 Is the Critical Lever
RC4 (encryption type 0x17) uses the raw password hash as the encryption key — no salt, no iteration, no key derivation. AES-256 (0x12) applies salting and PBKDF2-style key derivation, making offline cracking impractical even against significant compute power — provided the password is strong.
Windows Server 2025 and Windows 11 24H2 disable RC4 by default. Earlier versions negotiate it unless explicitly restricted.
2. The Attack Path (Detection Perspective)
Understanding how the attack flows is the foundation for detection. No step in this chain requires administrative rights on the target — only a valid domain account.
[Attacker with valid domain account]
│
▼
[1] SPN Enumeration — LDAP query for user accounts with servicePrincipalName attribute
→ Detectable: abnormal LDAP query volume, BloodHound-style AD enumeration
│
▼
[2] TGS Requests for all discovered SPNs
→ KDC issues tickets (Event ID 4769, etype 0x17 if RC4 is not disabled)
→ Anomaly signal: one account requests many TGS for different service accounts in rapid succession
│
▼
[3] Offline hash cracking (GPU-accelerated)
→ No further network traffic; fully passive from this point
→ Weak passwords cracked in seconds to minutes
│
▼
[4] Authentication with the cracked password
→ Lateral movement, privilege escalation if SPN account is privilegedBefore Hardening: Attack Succeeds
In our isolated lab environment (lab.local), the service account svc-sql was registered with an SPN and protected by a human-chosen password. A standard domain user requested the TGS and extracted the RC4-encrypted hash.
# TGS requested for svc-sql (RC4 / etype 0x17) # Event ID 4769 logged on domain controller — Status 0x0 (success) # Offline cracking attempt: Hashcat status: Cracked Password found: Summer2026 Time elapsed: 4 seconds → Service account fully compromised.
Once an attacker has the plaintext password of a privileged service account, they can authenticate as that account across the environment — no exploit, no CVE, no detection event beyond the initial TGS request. Depending on the account's permissions, this can mean direct domain privilege escalation.
3. Closing the Attack Surface — and the Cost of Each Measure
gMSA / dMSA: Structural Elimination
Group Managed Service Accounts (gMSA) replace human-chosen passwords with 120-character cryptographically random secrets, auto-rotated every 30 days by the domain. No human ever knows the password — there is nothing to phish, guess, or crack. Delegated Managed Service Accounts (dMSA), introduced with Windows Server 2025, extend this model further.
Trade-off: gMSA migration requires each dependent service to be reconfigured and tested. Applications that cannot retrieve gMSA credentials programmatically (legacy software, certain scheduled tasks) may need workarounds or vendor support. Plan migration per service, not as a bulk rollout.
AES-Only Enforcement
Setting the msDS-SupportedEncryptionTypes attribute on SPN accounts to AES-only (values 24 or 28) prevents the KDC from issuing RC4-encrypted tickets for those accounts. Even if a TGS is captured, offline cracking becomes computationally infeasible for strong passwords.
Trade-off: Older clients or services that do not support AES Kerberos may fail to authenticate after this change. Audit your environment for RC4 dependencies before enforcing.
Password Length for Remaining SPN Accounts
Where gMSA migration is not immediately feasible, a password of at least 25 random characters raises the cracking effort beyond practical limits even with RC4, given today's GPU capabilities. This is a transitional measure — not a permanent substitute for gMSA.
SPN Hygiene
Every SPN registered on a user account is a potential cracking target. Remove SPNs from decommissioned service accounts, consolidate SPN registrations, and prefer computer accounts (which use machine passwords, not human-chosen ones) where possible.
Detection: Event ID 4769
Kerberoasting is invisible in standard monitoring — it generates only successful, legitimate-looking TGS events. Dedicated SIEM logic is required. The primary signal is Event ID 4769 with encryption type 0x17, filtered to exclude machine accounts and the krbtgt service.
| Signal | Source | Filter |
|---|---|---|
| RC4 TGS request | Windows Event 4769 | EncType=0x17 AND Svc≠krbtgt AND Svc≠*$ AND Status=0x0 |
| TGS burst from one account | 4769 burst / LDAP audit | ≥ 5 TGS from same account within 60 s |
| PowerShell-based Kerberoast | Event 4104 (ScriptBlock) | String: KerberosRequestorSecurityToken |
| Defender XDR built-in | Defender Identity | Alert: External ID 2410 — Suspected Kerberos SPN Exposure |
4. Lab Proof: Attack Before and After Hardening
The following result was reproduced in an isolated lab environment using only synthetic data. The same attacker account, the same tool, the same SPN — the only variable was the service account configuration.
# svc-sql migrated to gMSA: 120-character random password, auto-rotated # AES-only enforcement applied (msDS-SupportedEncryptionTypes = 24) # TGS request still succeeds (protocol-legitimate) — etype now 0x12 # Offline cracking attempt: Hashcat status: Exhausted Candidates tested: 14,344,391,570 Time elapsed: 8 hours Password: [not found] → Attack neutralised. Service continues to operate normally.
The SPN remains registered. The service continues to work. The only change is that the password behind the hash is now 120 random characters, rotated automatically. There is nothing left to crack.
Video Walkthrough
Hardening Checklist
| Measure | Effect | Effort |
|---|---|---|
| Migrate to gMSA / dMSA | Eliminates crackable password entirely | Medium — per-service migration & testing |
| Enforce AES-only (etype 0x12) | RC4 tickets can no longer be issued | Low — after RC4 dependency audit |
| Password ≥ 25 characters (interim) | Cracking infeasible in practice | Low — policy change + reset cycle |
| SPN hygiene audit | Reduces attack surface | Low — PowerShell / AD module |
| Protected Users group | Prevents RC4 TGT for sensitive accounts | Low — group membership, test first |
| SIEM rule: Event 4769 + etype 0x17 | Detects ongoing Kerberoasting attempts | Medium — log forwarding + tuning |
Conclusion
Kerberoasting requires no vulnerability, no patch, and no zero-day. It exploits the gap between how Kerberos was designed to work and how service accounts are typically managed. The fix is not a software update — it is a configuration discipline: replace human-chosen passwords with machine-managed ones, stop negotiating RC4, and watch the right events.
Every service account with an SPN and a weak, human-chosen password is a potential domain-compromise path. The question is not whether someone will try — it is whether they will succeed.
Blackfort assesses and hardens Active Directory configurations — including service account password policies, SPN hygiene, Managed Service Account migration and tiering models — and implements detection rules (Wazuh/SIEM) against Kerberoasting. This directly supports DORA IAM resilience and NIS2 identity security requirements. Contact us for an assessment →
Legal Notice & Disclaimer
This article is for informational purposes and the improvement of IT security (detection and hardening) only. It does not constitute legal advice and contains no ready-to-use attack instructions. All tests were conducted in an isolated laboratory environment using exclusively synthetic data. No liability is accepted for damages arising from the application of the described content.
The underlying proof-of-concept is publicly available. Attribution and licensing are respected; no weaponisation beyond what is already in the public domain has been performed.
Sources
- MITRE ATT&CK — T1558.003 Steal or Forge Kerberos Tickets: Kerberoasting
- Microsoft Security Blog — Kerberoasting Mitigation Guidance (October 2024)
- ADSecurity.org (Sean Metcalf) — Detecting Kerberoasting Activity
- TrustedSec — The Art of Detecting Kerberoast Attacks
- IBM X-Force Threat Intelligence Index 2025 (via Microsoft Security Blog)
Kontakt aufnehmen
Bereit für den nächsten Schritt?
Sprechen Sie mit uns über Ihre Sicherheitsanforderungen – konkret, ohne Verpflichtung und auf Augenhöhe.