Kerberoasting in 2026: Why It Still Works in 80% of Indian AD Environments

Last updated: April 26, 2026

Kerberoasting is a 2014 attack technique. Microsoft has issued advisories. Every blue-team training course covers it. And yet, on more than 80% of Indian enterprise pentests we run in 2026, we still walk away with at least one cracked service-account password from a single Kerberoasting pass. This article explains why the attack persists, how to execute it cleanly, how to detect it from the defender’s side, and how to actually fix it — not just patch the symptom.

The attack in 90 seconds

Active Directory uses Kerberos for service authentication. When a user requests a Kerberos ticket for a service (a Service Ticket, ST), the domain controller encrypts part of that ticket using a key derived from the service account’s password. If the service is registered with a Service Principal Name (SPN), any authenticated user in the domain can request that ticket — without needing to actually use the service.

An attacker:

1. Authenticates to AD as any domain user (no admin needed).
2. Asks the DC for a service ticket for every account with an SPN registered.
3. Takes the encrypted portion offline.
4. Cracks it. The cleartext is the service account’s password.

If the service account’s password is weak (a dictionary word, a rotated-yearly pattern, the name of the application + a number), the cracker wins. And service-account passwords are almost always weaker than user passwords because nobody types them, nobody rotates them, and they were set in 2017 by an admin who has since left.

Why this still works in 80% of Indian environments

We track this number across our last 50 BFSI / fintech / SaaS engagements:

• 40+ environments had at least one Kerberoastable account with a crackable password.
• ~25 had service accounts that were members of Domain Admins or Enterprise Admins. A single crack equals tier-zero compromise.
• ~15 had MSSQL service accounts with passwords like SqlServer@123, WelcomeMSSQL2023, or the company name plus the year.
• Only ~5 were running Group Managed Service Accounts (gMSA) — the actual fix. The rest still have human-set, human-memorable service-account passwords.

Why so persistent? Three structural reasons:

1. Legacy accounts. The Oracle service account was created in 2014. The current DBA inherited it. Nobody knows the password rotation cadence; in practice it has not been rotated.
2. SPN sprawl. Every line-of-business application registers an SPN. Vendors install applications with their own service accounts. Over a decade, the SPN-registered account count grows linearly with software inventory and never shrinks.
3. Privilege creep. Service accounts get added to Domain Admins because “the application needs it” — even when the application would work fine with delegated rights. The temporary fix becomes permanent.

How to perform Kerberoasting (red-team perspective)

From a Linux box with valid domain credentials:

impacket-GetUserSPNs -dc-ip 10.0.0.5 corp.local/alice:'Welcome123' -request -outputfile spns.txt

This pulls every SPN-registered account in the domain and requests a service ticket for each. The output is in hashcat-ready format (mode 13100). Then crack offline:

hashcat -m 13100 -a 0 spns.txt rockyou.txt --rules-file best64.rule

For more targeted attacks against specific high-value accounts, use impacket-GetUserSPNs with -target-user <account>. From a Windows compromised host, Rubeus kerberoast /outfile:spns.txt does the same job.

What the attack tree looks like in practice

The Bengaluru SaaS company we audited last quarter:

• 0 to 2 minutes. Authenticated as a kiosk-user account (low-privilege, but in the domain). Ran GetUserSPNs.
• 2 to 4 minutes. Got 14 service tickets. One was for an account named svc_jenkins_build in Domain Admins.
• 4 to 12 minutes. hashcat with rockyou + best64 rules cracked it: Jenkins2019!.
• 12 to 14 minutes. Used secretsdump.py with the cracked credentials. NTDS.dit dumped. Game over.

From valid domain creds to NTDS.dit dump in 14 minutes. The CISO’s first reaction: “But we have an EDR.” The EDR did not see it. It was not designed to. The attack uses legitimate Kerberos protocol traffic; nothing on the endpoint indicates anomalous activity.

Detection — what actually works

Kerberoasting leaves a specific event-log fingerprint that most SIEM use-case libraries miss:

• Event ID 4769 on domain controllers — “A Kerberos service ticket was requested.” Every TGS-REQ generates one.
• Encryption type field. Modern Kerberos uses AES-256 (encryption type 0x12). Kerberoasting tools downgrade to RC4 (0x17) because RC4 is faster to crack offline.
• Service Name field. Look at the SPN being requested.

The detection rule:

Alert when a single user account requests Kerberos service tickets (Event 4769) for many distinct service principal names within a short window, especially when the encryption type is RC4 (0x17). Tune for: account is not a known administrator, encryption type is RC4 or DES, > 5 distinct SPNs requested in 5 minutes.

In Splunk:

index=wineventlog EventCode=4769 Ticket_Encryption_Type=0x17
| stats dc(Service_Name) AS unique_spns by Account_Name, _time
| where unique_spns > 5

In Elastic / Sigma:

title: Potential Kerberoasting (RC4 service tickets to multiple SPNs)
detection:
  selection:
    EventID: 4769
    TicketEncryptionType: '0x17'
  condition: selection
  timeframe: 5m
  count by user: > 5

In SEBI CSCRF environments, this rule is part of the baseline use-case library. Tag it MITRE T1558.003 (Kerberoasting).

Why the standard fixes do not fix it

Common defender response: “We rotated all service-account passwords last year.” That helps for one cycle, not durably. Common other response: “We require complex passwords.” Complex by AD policy means ≥14 characters, mixed case, special character. Jenkins2019! meets that bar. So does Welcome@CompanyName2024. Cracking dictionaries are stuffed with these patterns; rules do the case mutations automatically.

Other partial measures:

• Forcing AES-only Kerberos on the account — set msDS-SupportedEncryptionTypes = 0x18. Slows the attacker (AES-256 is harder to crack), but does not prevent the attack. If the password is in rockyou, AES still loses.
• Long passwords (32+ characters, random) — actually works. But human admins do not generate or remember 32-character random strings. Some end up in a password manager that is itself accessible to the next compromised admin.

The actual fix: Group Managed Service Accounts (gMSA)

gMSAs solve Kerberoasting at the protocol level:

• The password is automatically generated by AD as a 240-byte random string. Uncrackable.
• The password rotates automatically every 30 days (configurable). No human ever sees or types it.
• Authorised hosts retrieve the password via the KDS Root Key infrastructure; the password never traverses the network in plaintext.
• The account can still register SPNs and operate as a service identity.

Migration from a regular service account to a gMSA is well-documented:

# Pre-req: Kerberos KDS root key (one-time per forest)
Add-KdsRootKey -EffectiveTime ((Get-Date).AddHours(-10))

# Create the gMSA
New-ADServiceAccount -Name gmsa_jenkins_build `
  -DNSHostName jenkins.corp.local `
  -PrincipalsAllowedToRetrieveManagedPassword 'jenkins-builders'

# Install on the host that will use the account
Install-ADServiceAccount -Identity gmsa_jenkins_build

# Configure the service to run as gmsa_jenkins_build$ (note the $)

The application — Jenkins, MSSQL, IIS app pool, scheduled task — runs as the gMSA. Kerberoasting that account is now mathematically impractical (240 bytes of entropy).

If the application is too old to support gMSA (some legacy vendor stacks), the fallback is a 32+ character random password stored in a privileged-access tool like CyberArk, Delinea, or HashiCorp Vault, with rotation automated. Never type this password; never store it in a runbook.

How to find your next Kerberoastable account

For attackers, the next attack is one tier deeper:

• AS-REP Roasting (T1558.004) — same idea but for accounts with DONT_REQUIRE_PREAUTH set. impacket-GetNPUsers targets these. Less common but devastating where present (especially in legacy migrated AD environments where pre-auth was disabled to support some old client).
• Targeted Kerberoasting — write SPN to a target account using WriteSPN permission. If you have ESC1 (write to servicePrincipalName attribute) on a higher-tier account, you can register an SPN on it, then Kerberoast it. BloodyAD and Targeted Kerberoasting tools automate this.
• Silver Tickets — once you crack a service-account password, you can forge service tickets directly without going back to the DC. This makes detection harder and persistence easier. T1558.002.

For defenders, the next hardening step is a comprehensive SPN audit:

• Run Get-ADUser -Filter {servicePrincipalName -ne "$null"} -Properties servicePrincipalName, MemberOf, PasswordLastSet against your domain.
• For each account: who created it, what is it used for, when was the password last set, what groups is it in?
• Move every supportable account to gMSA.
• For unsupportable accounts: rotate to 32-byte random password in a vault, restrict group membership to least privilege, monitor 4769 events tightly.
• For accounts whose owner you cannot identify: candidate for deletion. Run a 30-day deprecation period; if no application breaks, remove.

Compliance mapping

• RBI Cyber Security Framework — service accounts with weak passwords violate identity-management baseline expectations.
• SEBI CSCRF — Kerberoasting maps to MITRE T1558.003. The CSCRF detection-engineering requirement expects a SIEM rule for this technique.
• DPDP Act §8(5) — reasonable security obligation. A service account in Domain Admins with a guessable password processing personal data fails this test under any reasonable interpretation.
• ISO 27001:2022 — Annex A 5.16 (identity management), 8.5 (secure authentication), 8.6 (capacity management of accounts).

The takeaway

Kerberoasting is not new, not novel, and not hard to detect. It still works because service-account hygiene is genuinely hard at organisational scale, and because gMSA migration has been treated as optional. If you have not run GetUserSPNs against your own AD this quarter, do it tomorrow. If you have not migrated your top-five privileged service accounts to gMSA this year, that is your highest-leverage AD hardening work — measurably more valuable than another EDR rule.

The attacker’s path from low-privilege user to NTDS.dit through Kerberoasting can be 14 minutes. The defender’s path to closing it permanently is two engineering sprints. Pick your sprints.