TL;DR: Kerberoasting was publicly documented in 2014. It is still one of the first techniques applied in assumed breach assessments in 2026 — because service account password hygiene has not improved. Any domain user can request a Kerberos service ticket for any service account with an SPN, and crack the ticket offline. If the password is weak, the attacker now has the service account's credentials. If that service account has Domain Admin, the engagement is over in an hour.
How Kerberos TGS Ticket Encryption Works
Kerberos is the authentication protocol underlying Active Directory in every Windows enterprise environment. When a user authenticates to a domain, they receive a Ticket Granting Ticket (TGT) from the Key Distribution Center (KDC). To access a specific service — a SQL server, a web application, a file share — the user presents their TGT and requests a service ticket (TGS) for that service.
The service ticket is encrypted with the NTLM hash of the service account's password — the account configured to run the target service and registered with a Service Principal Name (SPN). The KDC does this so that only the service itself (which knows its own password) can decrypt the ticket and verify the user's identity.
Here is the fundamental problem: any authenticated domain user can request a TGS ticket for any service with an SPN registered in the directory. The KDC does not check whether the requesting user is authorized to access that service before issuing the ticket. The ticket arrives, encrypted with the service account's password hash — and the requesting user can take it offline and crack it without ever touching the target service.
What Pentesters Actually Find
In a typical enterprise Active Directory environment, Lorikeet Security's assessments identify between 5 and 40 Kerberoastable service accounts during an assumed breach engagement. The distribution of findings is consistent across industries and organization sizes:
- Service accounts with dictionary-crackable passwords — "ServiceAccount1!", "SQL2019Prod!", or the application name followed by the year of deployment. These crack within minutes on a modern GPU cracking rig.
- Accounts unchanged for 3–10 years — service accounts set up during an initial deployment and never rotated, because the application team is afraid of breaking the service if the password changes.
- Service accounts with Domain Admin membership — granted during troubleshooting or initial deployment because it was easier than determining the minimum required permissions. Never scoped down afterward.
- Legacy RC4 encryption — service accounts that still negotiate RC4 encryption for Kerberos tickets rather than AES-256, because the account or domain is not configured to require stronger encryption types. RC4 tickets crack significantly faster.
AS-REP Roasting is Kerberoasting's close relative — and even more dangerous. Accounts with "Do not require Kerberos preauthentication" enabled can be attacked without any credentials at all. An unauthenticated attacker can request an AS-REP for these accounts and receive crackable encrypted material. Check for this flag as part of every AD security audit.
Attack Technique vs. Detection Method
| Technique | SIEM Detection | Detection Confidence | Notes |
|---|---|---|---|
| Kerberoasting (bulk TGS requests) | Event ID 4769 — high volume of TGS requests in short window, especially for RC4 encryption type | Medium — easy to baseline, but single targeted requests are harder to detect | Alert on RC4 TGS requests where AES is expected by policy |
| Kerberoasting (targeted, slow) | Event ID 4769 for unusual service accounts outside normal business hours | Low — single TGS request for a service account is normal behavior | Requires behavioral baselining per account to detect anomalous requestors |
| AS-REP Roasting | Event ID 4768 — Kerberos preauthentication failure followed by AS-REP with no prior TGT | Medium — the no-preauth flag is visible in AD attributes; accounts should be known and monitored | Prevent by auditing and removing the no-preauth flag from all non-legacy accounts |
| Password cracking (offline) | Not detectable — occurs off-network | None — no network activity generated | Only prevention works: strong passwords or gMSA accounts |
| Service account lateral movement post-crack | Event ID 4624/4648 — logon from unusual source for service account | High — service accounts should not be used interactively or from workstations | Alert on any interactive or network logon for designated service accounts outside expected hosts |
Defensive Mitigations That Actually Work
Group Managed Service Accounts (gMSA)
The most effective remediation for Kerberoasting is eliminating the attack surface entirely for services that support it. Group Managed Service Accounts (gMSA) are Active Directory account types where Windows automatically manages a 120-character random password that rotates on a configurable schedule — typically every 30 days. Because no human knows the password, there is no weak password to set, and the password length makes offline cracking computationally infeasible with any current or near-future hardware.
gMSA adoption requires that the service or application running under the account supports the Windows credential manager — which is the case for most Microsoft services (IIS, SQL Server, scheduled tasks) and many third-party applications. Applications that require hardcoded credentials in configuration files do not support gMSA, and are a separate remediation project.
AES-Only Encryption Enforcement
Configuring service accounts to require AES-256 encryption for Kerberos tickets — by clearing the "This account supports Kerberos AES 128/256 bit encryption" flag and removing RC4 support — significantly increases the computational cost of offline cracking. AES-256 tickets are roughly 7x harder to crack than RC4 tickets on equivalent hardware. This is defense in depth for accounts that cannot be migrated to gMSA.
Protected Users Security Group
The Protected Users security group in Active Directory applies a set of hardened Kerberos policies to member accounts: no NTLM authentication, no DES or RC4 encryption, no Kerberos delegation, and short TGT lifetimes. For privileged user accounts — Domain Admins, IT administrators, service accounts with elevated privileges — membership in Protected Users provides meaningful defense against credential theft techniques. Note that this group is not suitable for accounts that require NTLM fallback or legacy protocol support.
Service Account Privilege Review
The majority of over-privileged service accounts were not deliberately granted excessive permissions — they were set up with Domain Admin because it was convenient and never reviewed. A dedicated service account privilege audit, reviewing every account with an SPN against the actual permissions required by its service, typically reduces the blast radius of a successful Kerberoasting attack dramatically.
Our Active Directory penetration testing service includes a complete Kerberoasting assessment, AS-REP roasting enumeration, BloodHound attack path analysis, and remediation consultation. We identify exactly which service accounts represent your highest-priority remediation targets.
The Business Case for AD Security Investment
The argument against prioritizing AD security is usually that it is "internal" risk — it only matters if an attacker already has a foothold. But that reasoning ignores the dominant breach pattern: phishing campaigns succeed at significant rates in every organization, endpoint compromise is a matter of when not if, and the question is what happens next. A Kerberoastable Domain Admin service account transforms a phishing email into a full domain compromise in under two hours.
The remediation investment is modest. Migrating service accounts to gMSA, enforcing AES encryption, and adding critical service accounts to Protected Users is IT operations work — not a major security program. The gap between the remediation cost and the incident cost it prevents is among the most favorable in enterprise security investment.
Get Your Active Directory Assessed Before Attackers Do
Lorikeet Security's Active Directory penetration testing identifies Kerberoastable accounts, AS-REP roasting targets, privilege escalation paths, and detection gaps — with a prioritized remediation roadmap that your team can act on immediately.
