Kerberoasting turns a normal Active Directory feature against itself: any authenticated user can request a service ticket for any account with a Service Principal Name, and that ticket is encrypted with the service account's own password hash. Crack the hash offline, and the attacker has a working credential with no alerts, no lockouts, and often domain admin rights attached.
- Kerberoasting exploits SPN-registered service accounts to steal password hashes via normal TGS requests.
- Migrating to gMSAs and enforcing AES256 removes the crackable password most Kerberoast attacks rely on in 2026.
- Standing admin rights on service accounts turn a cracked hash into full domain compromise — strip them.
- Monitoring alone won’t stop it; identity microsegmentation contains what gets through after a hash is cracked.
Why this matters
Kerberoasting doesn't require malware, phishing, or an exploit. Any domain user can run a setspn query, pull every account with a registered SPN, and request a ticket for each one — activity that looks identical to normal Kerberos traffic in most logs.
The accounts most likely to have an SPN are service accounts, and service accounts are disproportionately likely to have weak, old, or never-rotated passwords because someone set them up once and moved on. Combine a crackable password with the standing privileges service accounts often carry, and one Kerberoasting run becomes a path to domain admin.
That's why Kerberoasting shows up so often as the pivot point in credential theft investigations, not just as a standalone finding. If you're already working through how to stop credential theft in Active Directory environments, Kerberoasting is one of the specific techniques that guide needs to account for, because it targets accounts your identity team may not be watching closely in 2026.
What you'll need
- Domain admin or delegated rights to query and modify SPN-registered accounts
- A current inventory of all accounts with Service Principal Names (
setspn -Q */*or an AD reporting tool) - Access to Security Event Logs on domain controllers, specifically Event ID 4769 (TGS request)
- A test environment or maintenance window to convert legacy service accounts to Group Managed Service Accounts (gMSA)
- Group Policy access to enforce AES256 Kerberos encryption
- 2-4 weeks of lead time if you're migrating a large number of legacy service accounts, since app owners need to validate compatibility
The steps
1. Find every Kerberoastable account before an attacker does
Run an SPN audit across the domain and flag every account with a registered Service Principal Name, then cross-reference against group membership. Accounts with an SPN AND membership in Domain Admins or another privileged group are your highest-risk targets — rank remediation by that overlap, not by account count.
Expect to find more SPN-registered accounts than IT remembers configuring. Legacy application installs, old SQL Server instances, and abandoned pilot projects routinely leave service accounts behind with an SPN still active and a password that hasn't changed since 2019 or earlier.
Common mistake: treating this as a one-time cleanup instead of a recurring query. New SPNs get registered every time an app is installed with a service account, so the audit needs a monthly or quarterly cadence, not a single sweep.
2. Migrate service accounts to gMSA or dMSA
Group Managed Service Accounts generate a 120-character random password, rotate it automatically on a 30-day default interval, and never expose the plaintext to a human. That removes the exact weakness Kerberoasting depends on: a password an attacker can feasibly crack offline.
Standalone Managed Service Accounts (sMSA) work for single-server scenarios; gMSA supports accounts shared across multiple servers, which covers most enterprise service account use cases. Delegated Managed Service Accounts (dMSA), introduced for Windows Server 2025 environments, extend this further for migrating legacy accounts without app rewrites.
Migrate your highest-privilege, highest-visibility service accounts first — the ones tied to domain controllers, backup systems, and monitoring tools. Expected outcome: those accounts stop showing up as crackable in Kerberoasting simulations because there's no feasible password to crack.
Common mistake: migrating accounts in one large batch. A phased rollout, account by account, isolates which application breaks if compatibility issues surface.
3. Enforce AES256 and disable RC4 for Kerberos tickets
RC4-encrypted service tickets are dramatically faster to crack offline than AES256-encrypted ones, and many domains still default to RC4 because a legacy app or OS requested it years ago. Set the msDS-SupportedEncryptionTypes attribute to AES256 for every service account and confirm through Group Policy that RC4 is not the fallback.
This single change doesn't stop Kerberoasting requests from happening, but it makes the resulting ticket computationally impractical to crack for accounts with reasonably strong passwords — which is why it pairs directly with the gMSA migration in step 2, not as a substitute for it.
Common mistake: assuming AES256 alone solves the problem. It reduces crackability; it doesn't touch the standing privileges those accounts might still carry.
4. Strip standing privileged access from service accounts
A cracked service account password is only as dangerous as the privileges attached to it. Audit every SPN-registered account for group memberships and delegated rights, then remove anything not required for the account's actual function — no service account needs Domain Admins to run a backup job or a monitoring agent.
This is the step most organizations skip because it requires touching production dependencies, but it's the one that determines whether a Kerberoasting hit turns into a contained incident or a full domain compromise. Secfolio's guide on eliminating standing privileged access in Active Directory walks through the account-by-account privilege review in more depth.
Expected outcome: even if an attacker cracks a service account password, the blast radius is limited to whatever that account can actually touch — not the domain.
5. Watch for abnormal TGS request patterns
Event ID 4769 on domain controllers logs every service ticket request. A single request for a given SPN is normal; a burst of requests across dozens of SPNs from a single user account in a short window is not — that pattern is the signature of an automated Kerberoasting tool.
Alert on ticket requests using RC4 encryption specifically (encryption type 0x17), since a legitimate, updated environment should rarely request RC4 tickets in 2026 once AES256 is enforced. That single filter cuts a large amount of the noise SOC teams otherwise wade through.
Common mistake: building the alert rule around volume alone. Attackers running low-and-slow Kerberoasting queries stay under naive volume thresholds; pattern and encryption-type detection catches what volume-based rules miss.
6. Contain what gets through with identity microsegmentation
Even with gMSA migration, AES256 enforcement, and privilege reduction, assume some Kerberoastable account will slip through a merger, an unmanaged app, or a rushed deployment. Identity microsegmentation limits what any single compromised identity — human or service account — can reach, so a cracked credential doesn't become a path across the domain.
Secfolio's approach to identity microsegmentation for Active Directory environments segments identities the same way network microsegmentation segments hosts: by enforcing what an identity can authenticate to, not just what network it sits on. That's the difference between a Kerberoasting hit staying isolated and it becoming a lateral movement incident.
Contain Kerberoasting fallout by design
See how identity microsegmentation limits what a cracked service account can reach.
7. Plant decoy accounts to catch reconnaissance early
Create a small number of honeypot accounts with SPNs and no real privileges, then alert on any ticket request against them. No legitimate process ever requests a service ticket for a decoy account, so any hit is a near-certain indicator of active Kerberoasting reconnaissance.
This costs almost nothing to set up and gives you an early warning signal that fires before an attacker finds a real crackable account, which buys the security team response time measured in hours instead of days.
Troubleshooting
Legacy application breaks after gMSA migration. Some older applications hardcode a service account's password rather than using the Windows credential provider. Roll back that specific account to a standard managed account temporarily and flag the application for an upgrade path — don't disable AES256 domain-wide to accommodate one app.
AES256 enforcement locks out an old server. Windows Server 2008 and earlier, along with some embedded systems, don't support AES256 Kerberos encryption. Isolate those systems on a segmented network path rather than reverting encryption settings for the whole domain.
Alert volume on Event 4769 is unmanageable. Filter first on encryption type (RC4 requests specifically) and second on request velocity per account. That two-stage filter typically drops false positives by a wide margin without missing genuine Kerberoasting bursts.
Kerberoasting stops, but AS-REProasting attempts increase. Attackers who find Kerberoasting closed off often pivot to targeting accounts with Kerberos pre-authentication disabled. Audit for DONT_REQ_PREAUTH flags on accounts and remove that setting unless there's a documented reason it's required.
Service account owners resist privilege reduction. Framing the change as "removing unused rights" rather than "restricting access" reduces pushback; pair the change with a rollback plan for the first 48 hours so app owners have a fast path if something breaks.
Tools and resources
- Native AD tooling:
setspn, PowerShell'sGet-ADServiceAccount, and Group Policy for encryption type enforcement - BloodHound or a similar attack-path mapping tool to visualize which SPN-registered accounts sit on privileged paths
- Domain controller Security Event Logs, filtered for Event ID 4769 and 4768
- A change management process for the gMSA migration, since app compatibility testing is the long pole, not the AD configuration itself
- Secfolio's guidance on monitoring privileged access continuously for building the detection layer around steps 5 and 7
What to do next
Closing Kerberoasting removes one credential-theft path, but it doesn't address what happens if a different path succeeds — phishing, a leaked credential, an insider. If a credential does get compromised despite these controls, the next question is how far it can travel before it's stopped. Secfolio's guide on reducing blast radius after credential compromise covers that containment layer directly, and it connects to the microsegmentation work in step 6 above.
It's also worth noting where this fits if ransomware or exfiltration follows a credential compromise. Traditional backups store complete, recoverable copies of data — exactly what a ransomware operator wants to find and encrypt or steal. Secfolio's Cyber Storage architecture encrypts, shards, and distributes data across independent locations before that data ever leaves the environment, so no single system holds a reconstructable file. A cracked service account might grant an attacker a path in, but it doesn't hand them usable data if the underlying storage architecture never stores a complete, exploitable file in one place.
FAQ
What is Kerberoasting and how does it work?
Kerberoasting is an attack where any authenticated domain user requests a Kerberos service ticket for an account with a registered Service Principal Name, then attempts to crack that ticket offline to recover the account’s password. It requires no exploit, malware, or elevated access to start — only a valid domain login.
How do attackers find kerberoastable accounts?
Attackers run a simple SPN query, such as PowerShell’s Get-ADUser filtered on ServicePrincipalName, to list every account registered with an SPN. Tools like Rubeus and Impacket automate requesting tickets for all of them in seconds.
What is the best defense against Kerberoasting?
Migrating service accounts to Group Managed Service Accounts (gMSA) is the strongest single control, since gMSA passwords are 120 characters, randomly generated, and rotate automatically. Pair that with AES256 enforcement and privilege reduction on remaining legacy accounts for full coverage.
Do gMSAs eliminate Kerberoasting risk entirely?
No. gMSA removes the crackable password, but any account that still can’t be migrated remains a target, and attackers who find one weak account can still cause damage if it carries standing privileges. Privilege reduction and monitoring remain necessary alongside the migration.
How long should service account passwords be if gMSA isn’t an option?
For accounts that can’t migrate to gMSA, use randomly generated passwords of at least 25 characters with no dictionary words, since shorter or human-created passwords are the ones offline cracking tools break fastest. This is a stopgap, not a permanent substitute for managed accounts.
Can Kerberoasting be detected in real time?
Yes, by monitoring Event ID 4769 for abnormal ticket request volume against multiple SPNs from a single account, and by flagging any RC4-encrypted ticket requests once AES256 is enforced domain-wide. Decoy honeypot accounts add an early, high-confidence detection signal.
Is Kerberoasting still effective against organizations in 2026?
Yes, because many domains still run legacy service accounts with static passwords and RC4 encryption enabled by default. It remains one of the most common credential-theft techniques observed in Active Directory environments precisely because the underlying feature can’t be disabled, only mitigated.
Does disabling RC4 encryption stop Kerberoasting on its own?
It significantly raises the cracking difficulty but doesn’t stop the ticket request itself from succeeding. An account with a weak password can still be cracked even under AES256 if the password is short or predictable, which is why password strength and gMSA migration matter independently.
One last thing
Most Kerberoasting write-ups stop at "use strong passwords for service accounts." The detail that actually changes outcomes is the encryption type filter on Event 4769: once AES256 is enforced domain-wide, any RC4-encrypted ticket request is close to a guaranteed signal of either a misconfigured legacy system or an active Kerberoasting attempt — there's very little legitimate traffic left in that category by 2026 in a properly configured domain.
Related guides
