Kerberoasting Attacks: How They Work and How to Stop Them in 2026

In 23% of all Active Directory intrusions tracked by CrowdStrike in their 2024 Global Threat Report, attackers used Kerberoasting to extract service account credentials without deploying a single piece of malware. The attack requires only a standard domain user account and leaves log entries that most SIEM configurations ignore entirely.

Kerberoasting is an Active Directory credential attack (MITRE ATT&CK T1558.003) in which a domain user requests Kerberos service tickets for accounts registered with Service Principal Names (SPNs), exports those tickets offline, and cracks the underlying service account password using GPU-accelerated tools. Because every step uses legitimate Windows authentication mechanisms, endpoint detection tools produce no alert. The entire attack chain is invisible without specific Event ID monitoring.

How the Attack Chain Works

The Kerberos authentication protocol, by design, allows any authenticated domain user to request a service ticket for any account registered with a Service Principal Name. That ticket is encrypted with the service account's password hash. The attacker never needs to contact the service itself. They just need the ticket.

The attack proceeds in four steps:

1. Enumerate SPNs. The attacker queries Active Directory's LDAP interface for all user accounts with servicePrincipalName attributes set. A standard user account has read access. This query produces a target list in seconds.
2. Request TGS tickets. For each SPN target, the attacker's Kerberos client sends a TGS request to the domain controller. The DC returns a ticket encrypted with the target account's NT hash. No password required on the attacker's side.
3. Export tickets. Tools like Rubeus or Impacket's GetUserSPNs.py extract the raw ticket data in formats directly compatible with Hashcat or John the Ripper.
4. Crack offline. A modern GPU cracking rig processes 8-character passwords protected with RC4-HMAC in under 10 minutes. Longer passwords with dictionary words fall to rule-based attacks within hours.

The recovered plaintext password then gives the attacker access to every system the service account can reach. SQL service accounts and backup agents often have broad network access by necessity. That access becomes the attacker's lateral movement path.

Why Kerberoasting Remains a Top Threat in 2026

The attack technique was published in 2014. It is still in the top five Active Directory attack methods a decade later. Three structural reasons explain that persistence.

First, service account sprawl. Most enterprises have accumulated dozens or hundreds of accounts with SPNs over years of application deployments. Many of those accounts have passwords set by administrators years ago, before password length requirements increased. A 12-character password from 2018 is crackable in hours on current hardware.

Second, detection gaps. According to a 2024 analysis by Mandiant, fewer than 30% of organisations had Kerberos TGS monitoring rules active in their SIEM when a Kerberoasting-related breach was investigated. The Event IDs exist. The data is collected. The rules are not written.

Third, the attack requires no malware and no command-and-control infrastructure. It generates no network anomalies. Standard endpoint detection and response tools have no behavioral signature to trigger on. As CISA notes in its advisory on Active Directory attacks, "Kerberoasting may be difficult to detect because the requests blend with normal Kerberos traffic."

Detection: The Three Signals That Matter

Detection requires Windows Security auditing to be enabled on domain controllers. Specifically, audit policy for "Kerberos Service Ticket Operations" must be set to log Success events.

The reliable detection query: alert when a single account generates more than five Event ID 4769 entries with Encryption Type 0x17 within a 30-second window. Legitimate applications request service tickets one at a time, on-demand. Mass enumeration is the Kerberoasting signature.

A Splunk search that implements this:

index=wineventlog EventCode=4769
  Ticket_Encryption_Type=0x17
| stats count by Account_Name, dest, _time span=30s
| where count > 5

Equivalent logic applies in Microsoft Sentinel, Elastic SIEM, and Chronicle. The query parameters vary; the logic is identical.

Behavioral Indicators Beyond Event IDs

Two additional signals supplement event log analysis. Unusual LDAP query volume from a workstation account is the reconnaissance phase: attackers enumerating SPNs generate a large servicePrincipalName=* LDAP query that baseline tooling rarely sees outside of IT management systems. Second, off-hours Kerberos TGS spikes. Legitimate applications access services during working hours. Bulk TGS requests at 2am from a standard user account warrant investigation regardless of encryption type.

Prevention: The Four Controls That Actually Work

1. Migrate Service Accounts to Group Managed Service Accounts (gMSA)

Group Managed Service Accounts are the most complete mitigation available. The Key Distribution Service on the domain controller generates the gMSA password automatically, rotates it every 30 days, and uses a 256-bit key. No human ever knows the password. It cannot be set to a weak value. Even if an attacker successfully exports a TGS ticket for a gMSA, the underlying password is computationally infeasible to crack on any current or near-future hardware.

Microsoft's recommendation, stated in its Kerberoasting mitigation guidance, is to migrate all eligible service accounts to gMSA. The migration requires Windows Server 2012 domain functional level or higher. For applications that cannot use gMSA directly, use Virtual Accounts or Standalone Managed Service Accounts (sMSA) as alternatives.

For service accounts that cannot be migrated (legacy applications with hardcoded credential calls), set the password to a randomly generated string of at least 100 characters. A Kerberoasting attack against a 100-character random password is technically feasible but practically useless given current GPU capabilities.

2. Enforce AES Encryption for Kerberos

Configure Group Policy to require AES 128 or AES 256 for Kerberos ticket encryption. The setting is under Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options: "Network security: Configure encryption types allowed for Kerberos."

Disable RC4-HMAC (0x17) and DES (0x01, 0x03). This forces the domain controller to issue AES tickets only. Attackers can still request and export those tickets, but the cracking timeline shifts from minutes to months or years.

Warning: disabling RC4 can break older applications that only support RC4 Kerberos. Test in a lab environment first and audit SPN-registered accounts for RC4-only dependencies before enforcing domain-wide.

3. Minimise SPN Exposure

Run a quarterly audit of all SPN registrations using the built-in query:

Get-ADUser -Filter {ServicePrincipalName -ne "$null"} `
  -Properties ServicePrincipalName | Select Name, ServicePrincipalName

Remove SPNs from accounts that no longer require them. Decommissioned services often leave SPN registrations behind for years. Each orphaned SPN is an attack surface.

Assign the least privilege required to each service account. SQL service accounts with Domain Admin membership (a configuration seen in the wild far more often than it should be) turn a successful Kerberoast into a full domain compromise within minutes.

4. Store and Manage Service Account Credentials in a Password Vault

For accounts that cannot use gMSA, a centralised password vault enforces the 100-character random password policy and provides audit trails for every credential access. NordPass for Business supports organisational-level credential storage with role-based access controls, making it practical to manage dozens of service account passwords without any human memorising them or storing them in spreadsheets.

If You Detect Kerberoasting: A Response Playbook

Detection does not mean the attack succeeded. An attacker who requested tickets but has not yet cracked them gives you a window to act.

1. Identify the source account. The 4769 event includes the requesting account name and source IP. Isolate that workstation immediately.
2. Identify the targeted SPNs. The 4769 event also logs which service account ticket was requested. Those accounts now have potentially compromised passwords even if cracking has not completed.
3. Rotate passwords on all targeted service accounts. Do this before the attacker cracks them. For gMSA accounts, no action is needed. For manual accounts, generate a new 100-character random password via your vault and update the dependent services.
4. Review targeted account permissions. Check whether any of the targeted service accounts have excessive domain privileges. This is the moment to trim them.
5. Investigate the requesting account. Determine whether that domain user account was the attacker's initial access point or was itself a compromised account. Treat it as compromised until proven otherwise.

Summary: The Kerberoasting Defense Stack

Kerberoasting persists in attacker playbooks because the defensive gap is simple to describe but takes real organisational effort to close. Migrating 50 legacy service accounts to gMSA is not a one-afternoon task. But the alternative is leaving service account passwords accessible to anyone with a domain login and a copy of Rubeus.

The controls above, applied in priority order, close that gap.

Frequently Asked Questions

What is a Kerberoasting attack?

Kerberoasting (MITRE ATT&CK T1558.003) is an Active Directory credential attack where a standard domain user requests Kerberos service tickets for accounts with Service Principal Names (SPNs), then extracts those tickets for offline brute-force cracking. Because the attack uses legitimate Windows Kerberos functionality, it generates no malware alerts and leaves only log entries that most SIEM rules miss.

What Windows Event ID detects Kerberoasting?

Windows Security Event ID 4769 (Kerberos Service Ticket Was Requested) with Ticket Encryption Type 0x17 (RC4-HMAC) is the primary detection signal. A single account requesting multiple 4769 events with RC4 encryption within a 30-second window is the Kerberoasting signature. Enabling AES enforcement removes the RC4 ticket type, which eliminates the crackable output attackers need.

Do Group Managed Service Accounts (gMSA) prevent Kerberoasting?

Yes, effectively. gMSAs auto-rotate their passwords every 30 days using 256-bit keys generated by the domain controller's Key Distribution Service. No human knows the password and it cannot be set to a weak value. Even if an attacker extracts the Kerberos ticket, the underlying password is computationally infeasible to crack. Microsoft recommends gMSA as the primary mitigation for Kerberoasting.

What tools do attackers use to Kerberoast?

The most common tools are Rubeus (a .NET command-line tool for Kerberos attacks), Impacket's GetUserSPNs.py (Python, often used from Linux attack platforms), and PowerView's Invoke-Kerberoast function. All three query Active Directory for accounts with SPNs, request TGS tickets via standard Kerberos, and export them in Hashcat-compatible format for offline cracking.