What Is a Kerberoasting Attack?

A Kerberoasting attack targets Microsoft Active Directory service accounts. Any authenticated domain user can request a Kerberos service ticket for an account with a Service Principal Name, extract the encrypted ticket material, and attempt to recover the service account password offline.

Kerberoasting abuses normal Kerberos functionality rather than a software vulnerability. Its success usually depends on weak, static service-account passwords and excessive privileges. Because password cracking happens away from the network, defenders have to detect suspicious ticket requests and reduce the value of any recovered credential.

Key Takeaways

• Any authenticated domain account can request the service tickets used in Kerberoasting.
• Offline cracking creates no failed sign-ins or account lockouts in Active Directory.
• Weak service-account passwords, RC4 tickets, and excessive privileges increase impact.
• Managed service accounts, long random passwords, AES, and ticket-request monitoring reduce risk.

How a Kerberoasting Attack Works

An attacker first enumerates accounts that have Service Principal Names. The attacker requests Ticket Granting Service tickets, extracts the encrypted portions, and moves them to a cracking system.

If a password is recovered, the attacker signs in as the service account and uses its permissions for privilege escalation, lateral movement, or access to sensitive systems.

Common Types and Techniques

• SPN enumeration from a compromised account
• Bulk TGS ticket requests for service accounts
• Offline cracking of RC4 or AES ticket material
• Use of recovered service credentials

Security and Business Risks

• Privilege escalation from a low-level foothold
• Compromise of highly privileged service accounts
• Lateral movement and persistence
• Access to business applications and sensitive data

Warning Signs and Detection

Monitor Windows event 4769 for one identity requesting many service tickets, requests for unusual SPNs, RC4 use in an AES environment, and ticket activity from hosts that do not normally access the service. Baseline legitimate service behavior before alerting.

Prevention and Response

Use group Managed Service Accounts where possible, assign long random passwords to remaining service accounts, rotate them regularly, enforce AES, retire unnecessary SPNs, and apply least privilege. Investigate the initial credential compromise that gave the attacker domain access.

How SOCRadar Can Help

SOCRadar combines external asset visibility, threat intelligence, Dark Web monitoring, vulnerability context, and indicator enrichment to help teams identify exposure and investigate activity connected to Kerberoasting attack.

Explore SOCRadar Dark Web Monitoring or request a demo to strengthen threat-informed prevention and investigation.

Frequently Asked Questions

What Accounts Are Targeted in a Kerberoasting Attack?

Kerberoasting targets user accounts that have at least one Service Principal Name (SPN), most commonly service accounts running applications, databases, or scheduled tasks. Any account with an SPN receives Kerberos service tickets whose encrypted portion can be taken offline for password cracking.

Can a Standard Domain User Perform Kerberoasting?

Yes. Requesting a TGS ticket for any SPN is normal Kerberos behavior available to any authenticated domain account. The attack needs no exploit or elevated rights to begin, which is why restricting SPNs and auditing ticket requests matter even in well-managed environments.

Why Does Kerberoasting Avoid Account Lockouts and Failed Logins?

The password guessing happens offline against extracted ticket material, not against the domain controller. Active Directory never sees failed authentication attempts, so lockout policies and login-based alerts do not fire during the cracking phase.

Which Encryption Types Make Kerberoasting Easier?

RC4-encrypted tickets are the fastest to crack because they use the RC4-HMAC algorithm with weaker key derivation than AES. In environments where AES is available, tickets requested with RC4 can themselves be a detection signal, since modern domain functional levels should rarely fall back to legacy encryption.

How Do Attackers Find Service Accounts Worth Kerberoasting?

Attackers enumerate accounts with SPNs using tools or LDAP queries, then often filter results for high-value names such as accounts with domain admin rights or those running critical services. Bulk TGS requests for many SPNs from a single identity is a common follow-up pattern.

What Should I Look for in Windows Event 4769?

Baseline normal service ticket activity first, then alert on one identity requesting tickets for many distinct SPNs in a short window, requests for SPNs never accessed before, RC4 encryption where AES is expected, and ticket requests originating from hosts that do not normally use the service.

What Should I Do If a Service Account Password Was Cracked?

Immediately rotate the compromised password to a long random value, review the account’s group memberships and delegated permissions, and hunt for logons or lateral movement performed with the service identity. Also investigate how the attacker obtained initial domain credentials in the first place.

Do Group Managed Service Accounts Stop Kerberoasting?

gMSAs make Kerberoasting impractical for covered accounts because they use 240-plus character random passwords that rotate automatically, and their tickets cannot be meaningfully cracked. They do not protect legacy service accounts, so those still need long passwords, AES enforcement, and least privilege.

How Is Kerberoasting Different From AS-REP Roasting?

Kerberoasting requests service tickets for accounts with SPNs, while AS-REP roasting targets accounts where Kerberos pre-authentication is disabled and extracts the AS-REP encrypted part directly. Both involve offline cracking of account passwords from Kerberos material, but they require different account misconfigurations.

Why Is Least Privilege Important for Service Accounts?

The Kerberos protocol will still issue tickets regardless of password strength, so the real question is what a recovered password unlocks. A service account with domain admin rights turns a routine ticket request into full domain compromise, while a least-privileged account limits the blast radius.