What Is a Kerberoasting Attack?

A Kerberoasting attack is a technique against Microsoft Active Directory in which an attacker requests service tickets for accounts running network services, then cracks those tickets offline to recover the service accounts’ plaintext passwords. It abuses a normal, by-design feature of the Kerberos authentication protocol rather than any software vulnerability.

Kerberoasting is one of the most reliable post-compromise techniques in the attacker playbook, and its defining characteristic is what makes it so dangerous: it requires no elevated privileges. Any authenticated domain user can perform it.

How Kerberoasting Works

The four attack steps: enumerate SPNs, request TGS, extract hash, crack offline.

Service Principal Names (SPNs) and Kerberos Tickets

Kerberos identifies network services through Service Principal Names (SPNs) registered against domain accounts. When an SPN is tied to a regular user account, that account is called a service account. To let a client use a service, the domain controller issues a Ticket Granting Service (TGS) ticket, and part of that ticket is encrypted with the service account’s password hash. That design choice, encrypting a ticket with the account’s own key, is the seam Kerberoasting pries open.

Requesting the TGS Ticket

An authenticated attacker enumerates accounts that have SPNs registered, then simply asks the domain controller for TGS tickets for those services, which is a routine request the protocol is built to fulfill. The attacker does not need to interact with the target service at all; obtaining the ticket is enough, because the ticket itself contains material encrypted with the service account’s key.

Offline Password Cracking

The attacker extracts the encrypted portion of each ticket and cracks it offline, away from the network, using tools like Hashcat or John the Ripper. Offline cracking generates no failed logons and triggers no lockouts, so it produces almost no noise on the domain. If a service account has a weak or short password, recovery can take minutes; strong, long passwords can make cracking computationally infeasible.

Why Kerberoasting Doesn’t Require Elevated Privileges

This is the single most-repeated point about Kerberoasting, and it drives its popularity. Requesting a TGS ticket is a standard Kerberos operation available to every authenticated account, so an attacker who has compromised even one low-privileged domain user can request tickets for high-value service accounts, then crack them offline. Because service accounts are frequently over-privileged, cracking one often hands the attacker administrative or even domain-admin access, turning a minor foothold into a full compromise without ever escalating privileges through an exploit.

Why Active Directory Environments Are Vulnerable

Several habits common in Active Directory environments make Kerberoasting effective. Service accounts often carry passwords that were set once years ago and never rotated. Many were configured by administrators using human-memorable, and therefore crackable, passwords. Service accounts also tend to accumulate excessive privileges over time, and organizations frequently lack visibility into how many SPN-bearing accounts they even have. The result is a target-rich environment where a single crackable service account can unlock disproportionate access.

Kerberoasting in the Wild

Kerberoasting is far from theoretical. IBM X-Force has reported a sharp rise in Kerberoasting activity, noting roughly a 100 percent increase in related incidents between 2022 and 2023. CISA and multiple incident responders have documented its use by Russian state-sponsored groups and by ransomware affiliates as a standard privilege-consolidation step after initial access. Its low noise, minimal prerequisites, and high payoff keep it a fixture in real intrusions.

Detecting Kerberoasting

Detection focuses on the ticket-request stage, since the cracking happens offline and out of view. Useful signals include a single account requesting an unusually high volume of TGS tickets, or requests for many distinct SPNs in a short window; TGS requests specifying weak, legacy encryption (RC4) when the environment otherwise uses AES; and requests for service tickets from accounts or hosts that have no business reason to use those services. Windows security event 4769 (Kerberos service ticket requested) is the primary source, and correlating spikes and RC4 usage against normal baselines is the most practical detection approach.

Preventing and Mitigating Kerberoasting

Strong Service Account Passwords

Since the attack ultimately depends on cracking a password offline, password strength is the decisive control. Service account passwords should be long (25+ characters) and random, which pushes offline cracking beyond practical feasibility.

Managed Service Accounts (gMSA)

Group Managed Service Accounts let Active Directory automatically generate and rotate very long, complex passwords with no human involvement. Migrating service accounts to gMSA (or delegated managed service accounts) largely neutralizes Kerberoasting by removing the weak, static, human-chosen passwords that make it work.

Additional mitigations include enforcing AES encryption and disabling RC4 for Kerberos, applying least privilege to service accounts so a cracked one yields little, auditing and removing unnecessary SPNs, and monitoring for the detection signals above.

How SOCRadar Helps Identify Exposed Credentials Used in Kerberoasting

Kerberoasting often follows an initial foothold obtained with stolen credentials, and the cracked service account passwords sometimes reappear for sale afterward. SOCRadar’s Dark Web Monitoring detects exposed corporate credentials in stealer logs and breach dumps, cutting off the initial access that precedes a Kerberoasting campaign. Cyber Threat Intelligence tracks the threat actors and ransomware affiliates known to rely on the technique, helping defenders prioritize Active Directory hardening against the groups most likely to target them.

FAQ

Does Kerberoasting require admin privileges?

No, and that is its defining trait. Any authenticated domain user can request the service tickets needed to attempt the attack.

Is Kerberoasting exploiting a vulnerability in Kerberos?

No. It abuses Kerberos working as designed. The weakness is operational: service accounts with weak, static passwords, not a flaw in the protocol.

What is the best defense against Kerberoasting?

Eliminate crackable service account passwords. Group Managed Service Accounts (gMSA) with automatic long-password rotation, combined with least privilege and AES-only Kerberos, is the strongest approach.

How do defenders detect Kerberoasting?

By monitoring Kerberos service ticket requests (event 4769) for abnormal volumes, requests for many SPNs, and weak RC4 encryption requests that deviate from the environment’s baseline.