What is Kerberoasting? A Practitioner's Definition
TL;DR - Kerberoasting is an Active Directory attack that requests Kerberos service tickets for service accounts. - Attackers crack those tickets offline to recover weak service account passwords. - Reduce risk with strong managed service account credentials, least privilege, and monitoring for unusual ticket requests.
Definition
Kerberoasting is a post-compromise Active Directory attack where an authenticated user requests Kerberos service tickets tied to service accounts and then attempts to crack them offline to recover the accounts’ plaintext passwords. It is popular because it often requires only normal domain user access and targets service accounts that tend to have old, complex-looking but weak, or rarely rotated passwords.
How it works
Kerberoasting abuses normal Kerberos behavior, not a software bug. In a Windows domain, a user can request a Ticket Granting Service (TGS) ticket for a service identified by a Service Principal Name, or SPN. If that service runs under a domain account, the resulting ticket is encrypted in a way that can be tested offline against password guesses.
In practice, the attack usually follows this pattern:
-
Initial access or basic domain access
The attacker already has credentials for any standard domain user, often from phishing, password spraying, or another foothold. -
Enumerate service accounts and SPNs
They identify accounts associated with SPNs, because those are candidates for Kerberoasting. -
Request service tickets
The attacker asks the domain controller for TGS tickets for those services. This is often allowed as part of normal Kerberos operations. -
Export ticket material
The encrypted portion of the ticket is extracted from memory or tooling output. -
Offline password cracking
The attacker uses password cracking tools to test guesses against the ticket hash material without generating repeated login attempts or account lockouts. -
Privilege escalation or lateral movement
If the cracked service account is privileged, the attacker can use it to move deeper into the environment, access servers, or escalate toward domain admin.
Technical Notes
Common SPN enumeration from a Windows host:
setspn -Q */*
A more targeted PowerShell approach in a domain:
Get-ADUser -Filter {ServicePrincipalName -like "*"} -Properties ServicePrincipalName |
Select-Object SamAccountName, ServicePrincipalName
Security teams often monitor for Kerberos service ticket requests in Windows event logs, especially:
Event ID 4769 - A Kerberos service ticket was requested
Patterns worth reviewing include: - High volumes of TGS requests from a single user or host - Requests for many different SPNs in a short period - Requests involving older encryption types where applicable - Ticket requests for sensitive or high-privilege service accounts
Why it matters to defenders
Kerberoasting is effective because it blends legitimate protocol activity with offline cracking. The risky part is not just the ticket request. The bigger issue is poor service account hygiene.
Service accounts are often: - Overprivileged - Shared across systems - Exempt from interactive use controls - Set with passwords that rarely change - Managed manually instead of with modern account controls
That makes them ideal targets. A single cracked SQL Server, IIS app pool, backup, or automation account can provide broad access across production systems.
How to prevent it
There is no single switch to disable Kerberoasting, because requesting service tickets is part of how Kerberos works. Prevention is about reducing the value and crackability of service accounts.
Use managed service accounts where possible
Group Managed Service Accounts, or gMSAs, are one of the best defenses for Windows services in Active Directory environments. They provide long, automatically managed passwords and reduce the chance of human-created weak credentials.
If a service supports gMSA, prefer it over a traditional user-based service account.
Enforce strong, long service account passwords
For accounts that cannot yet use gMSA: - Use long, randomly generated passwords - Avoid human-memorable patterns - Rotate passwords regularly - Store them in a privileged access or secrets management system
Length matters more than complexity tricks. Random 25+ character passwords are much harder to crack offline.
Minimize service account privileges
Do not give a service account domain admin or local admin rights unless there is a documented, unavoidable requirement. Scope permissions to the exact systems and actions needed.
Review: - Group memberships - Local administrator assignments - Rights to log on interactively - Delegation settings - Access to file shares, databases, and backup systems
Audit and reduce SPN exposure
Find accounts with SPNs and review whether they are still needed.
Example review command:
Get-ADUser -Filter {ServicePrincipalName -like "*"} -Properties ServicePrincipalName, PasswordLastSet |
Select-Object SamAccountName, PasswordLastSet, ServicePrincipalName
Look for: - Legacy services no longer in use - Duplicate or stale SPNs - Accounts with very old passwords - Sensitive service accounts tied to broad infrastructure roles
Monitor Kerberos ticket request activity
Detection is not perfect, but it helps. Alert on: - Unusual spikes in Event ID 4769 - One account requesting tickets for many SPNs - Workstations requesting service tickets they do not normally request - Reconnaissance followed by lateral movement behavior
If you have SIEM coverage, correlate 4769 with: - Logon events - PowerShell execution - LSASS access attempts - New admin group membership - Remote service creation or scheduled task creation
Technical Notes
Basic Windows event review with PowerShell:
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4769} -MaxEvents 100 |
Select-Object TimeCreated, Id, Message
A simple hardening checklist: - Migrate eligible services to gMSA - Rotate old service account passwords - Remove unnecessary admin rights - Restrict where service accounts can log on - Review and prune SPNs quarterly
When you’ll encounter it
You will usually encounter Kerberoasting in one of four situations:
During Active Directory security assessments
Red teams and penetration testers commonly test for Kerberoastable accounts because the technique is low-noise and often successful in mature-looking but poorly maintained domains.
During incident response
If an attacker has obtained standard domain credentials, Kerberoasting is often one of the next steps. IR teams may see bursts of SPN enumeration, unusual 4769 activity, or compromised service accounts being used for lateral movement.
While reviewing service account hygiene
Blue teams and identity engineers encounter Kerberoasting when auditing old service accounts, legacy apps, and brittle operational dependencies that still rely on manually managed credentials.
In environments with legacy applications
Older enterprise applications, SQL services, middleware, and scheduled automation frequently depend on traditional domain service accounts. These are prime Kerberoasting targets, especially when passwords have not changed for years.
Related terms
Kerberos
The authentication protocol used in Active Directory environments.
SPN (Service Principal Name)
An identifier that maps a service instance to an account in Kerberos.
Service account
A domain or local account used by an application or service to run non-interactively.
TGS ticket
A Ticket Granting Service ticket issued so a client can authenticate to a service.
gMSA
A Group Managed Service Account with automatically managed credentials in Active Directory.
AS-REP Roasting
A related attack that targets accounts with Kerberos preauthentication disabled.
Password spraying
An attack that tries a small number of common passwords across many accounts.
The practitioner takeaway
Kerberoasting is not about breaking Kerberos. It is about abusing normal ticket requests to expose weak service account passwords to offline cracking. If your service accounts are long, random, rotated, minimally privileged, and managed with gMSA where possible, the attack becomes much less useful to an adversary.
For further reading on related topics, check out our articles on what is dynamic application security testing and the implications of cloud repatriation for security architecture.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.