Kerberoasting in Active Directory – Secure Active Directory

Kerberoasting is an Active Directory attack technique where an authenticated domain user requests Kerberos service tickets for accounts that have Service Principal Names, then attempts to crack those tickets offline to recover the service account passwords.

Kerberoasting is dangerous because it does not require administrative privileges. In many environments, any valid domain user can request service tickets for service accounts. If those service accounts use weak, reused, or rarely rotated passwords, an attacker may be able to recover the plaintext password and use it to move laterally or escalate privileges.

What is Kerberos?

Kerberos is the primary authentication protocol used in modern Active Directory environments. It allows users and systems to authenticate to services without repeatedly sending passwords across the network.

At a high level, Kerberos uses tickets:

Ticket	Purpose
Ticket Granting Ticket (TGT)	Proves the user authenticated to the domain
Ticket Granting Service ticket (TGS)	Allows access to a specific service
Service Principal Name (SPN)	Identifies the service being requested

When a user wants to access a service, such as SQL Server, IIS, or a file service, the user requests a service ticket for the SPN associated with that service.

What is Kerberoasting?

Kerberoasting abuses the way Kerberos service tickets work.

When a domain user requests a service ticket for an SPN, the domain controller returns a ticket encrypted with key material derived from the service account’s password. The attacker can extract that ticket and attempt to crack it offline.

The basic attack flow looks like this:

The attacker obtains access to any valid domain account.
The attacker queries Active Directory for accounts with SPNs.
The attacker requests Kerberos service tickets for those accounts.
The attacker extracts the ticket data.
The attacker attempts to crack the ticket offline.
If successful, the attacker recovers the service account password.

MITRE ATT&CK tracks Kerberoasting as T1558.003, under Steal or Forge Kerberos Tickets. MITRE describes the technique as abusing Kerberos service tickets that may be vulnerable to offline brute force.

Why Kerberoasting matters

Kerberoasting matters because service accounts are often high-value targets.

In many environments, service accounts may have:

Passwords that rarely change
Passwords known by multiple administrators
Excessive privileges
Membership in privileged groups
Delegated access to servers, databases, or applications
SPNs that make them discoverable
Older encryption types enabled

If an attacker cracks a service account password, the impact depends on that account’s privileges. In a low-impact case, the account may only have access to a single application. In a high-impact case, the account may have local administrator rights on servers, database administrator access, or even domain-level privileges.

Why service accounts are commonly vulnerable

Kerberoasting is effective because service accounts are often treated differently from normal user accounts.

Common issues include:

Passwords are set manually and rarely rotated
Passwords are long-lived because outages are feared
Ownership of the account is unclear
The account is used by multiple systems
The account has more privileges than required
The account is excluded from normal password policies
RC4 encryption is still allowed
No one regularly reviews SPNs or service account permissions

Microsoft specifically recommends using stronger encryption, reviewing accounts configured with SPNs, and improving service account password practices to reduce Kerberoasting risk.

Kerberoasting vs AS-REP Roasting

Kerberoasting and AS-REP Roasting are related, but they are not the same attack.

Attack	Target	Main requirement	Offline cracking?
Kerberoasting	Accounts with SPNs	Valid domain account	Yes
AS-REP Roasting	Accounts without Kerberos preauthentication	Preauthentication disabled	Yes

Kerberoasting targets service accounts with SPNs. AS-REP Roasting targets accounts that do not require Kerberos preauthentication.

Both attacks can lead to offline password cracking, but they abuse different parts of the Kerberos authentication process.

How attackers identify Kerberoastable accounts

Attackers often search Active Directory for user accounts with SPNs. These accounts are commonly associated with services such as:

SQL Server
IIS application pools
Backup software
Monitoring platforms
Middleware
Legacy applications
Custom internal services

An SPN might look like:

MSSQLSvc/sql01.example.com:1433
HTTP/app01.example.com
HOST/server01.example.com

SPNs are not inherently bad. They are required for many Kerberos-enabled services. The risk comes from SPNs assigned to user accounts with weak passwords, excessive privileges, or outdated encryption settings.

PowerShell: Find accounts with SPNs

You can use PowerShell to identify user accounts that have SPNs.

Get-ADUser -Filter { ServicePrincipalName -like "*" } -Properties ServicePrincipalName |
    Select-Object SamAccountName, Enabled, ServicePrincipalName

To include additional fields that are useful during review:

Get-ADUser -Filter { ServicePrincipalName -like "*" } `
    -Properties ServicePrincipalName, PasswordLastSet, LastLogonDate, Enabled, MemberOf |
    Select-Object SamAccountName, Enabled, PasswordLastSet, LastLogonDate, ServicePrincipalName

This does not mean every account returned is compromised or misconfigured. It means the account should be reviewed.

PowerShell: Find SPN accounts with old passwords

Service accounts with old passwords are often higher priority.

$Cutoff = (Get-Date).AddDays(-365)

Get-ADUser -Filter { ServicePrincipalName -like "*" } `
    -Properties ServicePrincipalName, PasswordLastSet, Enabled |
    Where-Object { $_.Enabled -eq $true -and $_.PasswordLastSet -lt $Cutoff } |
    Select-Object SamAccountName, PasswordLastSet, ServicePrincipalName

This helps identify enabled SPN-bearing accounts with passwords older than one year.

PowerShell: Find SPN accounts using RC4

One of the most important Kerberoasting risk factors is weak encryption support. RC4 is especially important because tickets encrypted with RC4 are generally more attractive for offline cracking than tickets using stronger AES encryption.

You can review the msDS-SupportedEncryptionTypes attribute:

Get-ADUser -Filter { ServicePrincipalName -like "*" } `
    -Properties ServicePrincipalName, msDS-SupportedEncryptionTypes |
    Select-Object SamAccountName, msDS-SupportedEncryptionTypes, ServicePrincipalName

Interpreting this value can require care because missing or legacy values may behave differently depending on domain, account, and policy configuration. Treat this as a review point, not a complete conclusion by itself.

Detection opportunities

Kerberoasting can be difficult to distinguish from normal Kerberos activity because requesting service tickets is expected behavior in Active Directory.

However, defenders can look for suspicious patterns such as:

A single user requesting many service tickets in a short period
Service ticket requests for many unrelated services
Requests involving RC4 encryption
Requests for unusual or rarely used SPNs
Service ticket activity from unexpected workstations
Ticket requests followed by lateral movement
Ticket requests from accounts that do not normally access those services

MITRE’s detection strategy for Kerberoasting highlights monitoring Kerberos TGS requests, especially Event ID 4769, RC4 encryption type 0x17, unusual request volume, and service accounts targeted outside normal usage patterns.

Windows event logs to review

The primary Windows event to review is:

Event ID	Log	Purpose
4769	Security	A Kerberos service ticket was requested

Useful fields include:

Field	Why it matters
Account Name	The user requesting the service ticket
Service Name	The service account or SPN being requested
Client Address	Where the request came from
Ticket Encryption Type	Helps identify RC4 or stronger encryption
Failure Code	May help identify failed Kerberos behavior

A single 4769 event is not automatically suspicious. The value comes from baselining normal behavior and identifying unusual ticket request patterns.

Microsoft Defender for Identity detection

Microsoft Defender for Identity includes detections related to suspected Kerberoasting activity. Microsoft’s documentation describes suspicious Kerberos TGS requests where an attacker may request service tickets for SPN accounts, extract the tickets, and attempt to crack them offline.

Defender alerts can be useful, but they should not be the only control. Kerberoasting risk should also be reduced through service account hygiene, strong passwords, least privilege, and encryption hardening.

How to reduce Kerberoasting risk

The best defense is to reduce the value and crackability of service account tickets.

Use group managed service accounts when possible

Group Managed Service Accounts, or gMSAs, are often a better option than manually managed domain user service accounts. They provide automatic password management and reduce the operational burden of rotating service account passwords.

Microsoft recommends managed service account approaches as part of securing service accounts in Active Directory.

Use long, unique service account passwords

For service accounts that cannot be moved to gMSAs, use long, unique, randomly generated passwords. The longer and more random the password, the less practical offline cracking becomes.

Remove unnecessary SPNs

SPNs should exist only where they are required. Review SPNs periodically and remove stale or unnecessary entries.

Reduce service account privileges

Service accounts should not be Domain Admins or broad local administrators unless there is a truly exceptional reason. Apply least privilege and limit access to only what the service needs.

Prefer AES over RC4

Where possible, configure accounts and domain settings to use stronger Kerberos encryption types such as AES. Review legacy systems before disabling RC4 broadly, because older applications may depend on it.

Rotate service account passwords

Long-lived service account passwords increase risk. Build a controlled rotation process, especially for high-value service accounts.

Monitor service ticket requests

Collect and review Kerberos Event ID 4769. Look for unusual request patterns, RC4 usage, and unexpected clients requesting service tickets for sensitive accounts.

Common mistakes

You can use this section as regular text or convert it into accordions like you did with the LDAP signing article.

Assuming all SPNs are bad

SPNs are normal and required for Kerberos authentication to many services. The issue is not the existence of an SPN. The issue is an SPN on an account with weak password practices, excessive privileges, or risky encryption settings.

Treating Kerberoasting as only a detection problem

Detection is important, but prevention matters more. If the service account password is strong, unique, and managed properly, offline cracking becomes much less practical.

Leaving service accounts highly privileged

A cracked low-privilege service account is a problem. A cracked Domain Admin service account is a crisis. Privilege reduction is one of the most important Kerberoasting mitigations.

Ignoring stale service accounts

Old service accounts often have unclear ownership, unknown dependencies, and passwords that have not changed in years. These should be reviewed regularly.

Disabling RC4 without testing

Reducing RC4 usage is a strong goal, but disabling it without understanding legacy dependencies can break applications. Review and test before broad enforcement.

Practical recommendation

A practical Kerberoasting reduction plan should include:

Inventory all user accounts with SPNs.
Identify accounts with old passwords.
Identify accounts with privileged group membership.
Review accounts that support RC4.
Move eligible services to gMSAs.
Rotate passwords for high-risk service accounts.
Remove stale SPNs and unused service accounts.
Monitor Event ID 4769 for unusual TGS request patterns.
Review service account ownership and business purpose.
Apply least privilege to every service account.

The goal is not to eliminate every SPN. The goal is to make service accounts harder to crack, less privileged if cracked, and easier to monitor.

Summary

Kerberoasting is a common Active Directory attack technique that targets service accounts with SPNs. An attacker with any valid domain account may be able to request service tickets, extract them, and attempt to crack them offline.

The risk is highest when service accounts have weak passwords, old passwords, excessive privileges, or weaker encryption settings. Strong service account management, gMSAs, AES encryption, least privilege, password rotation, SPN hygiene, and Kerberos monitoring all help reduce exposure.

Kerberoasting is ultimately a reminder that service accounts are security-sensitive identities. They should be managed, monitored, and reviewed with the same care as privileged user accounts.