Kerberoasting Attack Explained: Example And Prevention Guide

In May 2024 the Ascension Health system was hit by ransomware after attackers cracked a protected database by abusing RC4 support in Microsoft’s Kerberos. A year later, U.S. Senator Ron Wyden pressed the FTC to investigate Microsoft’s security defaults, citing Ascension as proof that Kerberoasting lets attackers steal domain administrator credentials by cracking service account passwords.

IBM’s 2025 X-Force Threat Intelligence Index found that 30% of all intrusions in 2024 involved stolen or abused credentials, making identity attacks the leading entry point.

Kerberoasting is a post exploitation technique where a domain user requests a service ticket for a Service Principal Name (SPN), receives one encrypted with the service account’s password hash, and attackers crack it offline to impersonate the account. This guide explains why Kerberoasting is resurging, how it works, what to monitor, and how to defend Active Directory.

Kerberoasting remains popular in 2024–2025 for a range of different reasons:

• Legacy encryption and weak passwords

Many Active Directory environments still allow RC4 encryption. When a service ticket uses RC4, the password hash is derived from the NetNTLM hash of the account, which is easier to brute force than newer AES hashes. In the Ascension breach, attackers exploited RC4 tickets to crack privileged service accounts. Microsoft’s plan to phase out RC4 by 2026 means many networks remain exposed today.

• Overlooked service accounts

Service accounts often belong to core applications and are rarely rotated. These accounts often have elevated permissions and hardly ever expire; cracking one can compromise the entire AD domain. Attackers enumerate SPNs tied to such accounts because administrators may forget about them, leaving them open to password cracking.

• Offline cracking and low privileges

Any authenticated domain user can request service tickets and export them without elevated rights. The cracking occurs offline, so network monitoring tools cannot see the brute force attack. This makes Kerberoasting attractive because it evades detection and can be executed after an initial compromise using minimal privileges.

• Credential theft and lateral movement

Once a service account is cracked, adversaries can impersonate it, traverse the domain, and eventually become Domain Admin. Attackers also chain Kerberoasting with other post exploitation techniques such as Pass-the-Hash and Golden Ticket attacks to maintain persistence. As adversaries target identities rather than machines, Kerberoasting fits neatly into broader credential theft campaigns.

• Incidents increase awareness

Public disclosures like the Ascension attack and Senator Wyden’s letter have drawn attention to Kerberoasting. Threat researchers and law enforcement now report increases in abuse of Ticket-Granting Service (TGS) tickets. The combination of widespread vulnerability and growing attacker interest means organizations need to start thinking about treating Kerberoasting as a serious threat.

Understanding Kerberoasting requires a quick recap of the Kerberos authentication protocol. Kerberos uses tickets to prove a user’s identity without sending plaintext passwords over the network. When a user logs in, they request a Ticket-Granting Ticket (TGT). The Authentication Server then verifies the credentials and issues the TGT.

Later, when the user wants access to a service, they use the TGT to request a TGS ticket for a specific SPN. The TGS ticket is encrypted using the service account’s password hash and is recorded as Windows Event 4769. The client presents this ticket to the application server to authenticate and gain access.  A Kerberoasting attack manipulates this process in five stages:

1. Domain user compromise

Attackers first compromise a domain user account via phishing, malware or purchased credentials. Kerberoasting does not require a Domain Admin account and can be launched with any valid domain user credentials. This makes it an accessible post exploitation technique.

2. SPN discovery and enumeration

The attacker queries Active Directory via LDAP to discover service accounts that have SPNs associated with them. Tools like Rubeus or GetUserSPNs.py automate this enumeration. Attackers prefer SPNs linked to user accounts because their passwords are chosen by humans and may be weak. Host based SPNs, on the other hand, use long random keys refreshed every 30 days, making them resistant to Kerberoasting.

3. Requesting service tickets

With a list of target SPNs, the attacker uses the compromised user account to request TGS tickets for those services. Because the domain controller does not check whether the user is authorized to access a particular service, it issues tickets on demand. Attackers can force the domain controller to use RC4 encryption, making subsequent cracking easier.

4. Exporting and cracking tickets

After receiving the TGS tickets, attackers extract them from memory and take them offline. They then use password cracking tools such as Hashcat or JohnTheRipper to brute force the service account password. Because the cracking occurs offline, it does not generate network traffic or logs, allowing the attacker to try an unlimited number of guesses without alerting defenders. When RC4 encryption is used, the hash is derived from the NTLM password hash, which is easier to crack than AES.

5. Lateral movement

Once the attacker recovers the plaintext password, they can authenticate as the service account and access any systems or data associated with that account. Service accounts often have elevated privileges, so a successful Kerberoasting attack can quickly lead to domain-wide compromise. Adversaries may then pivot laterally, perform further credential theft and maintain persistence across the network.

Unfortunately, detecting Kerberoasting is challenging because most of the attack occurs off the domain controller. Existing tools struggle to distinguish between normal ticket requests and malicious activity. Kerberoasting uses legitimate Kerberos traffic, and the password cracking phase takes place offline, leaving few traces. Nevertheless, a few strategies can help cybersecurity experts identify suspicious patterns: 

• Monitor unusual TGS requests

Track spikes in the number of service tickets requested by a single account or from a specific host. Watch for an excessive number of TGS requests in a short timeframe and requests targeting high privilege accounts. Unexpected requests for rarely used services can also signal enumeration or credential theft.

• Track SPN enumeration

A sudden surge in LDAP queries for SPNs may indicate an attacker using tools like PowerView or Rubeus. Hunting teams should baseline normal LDAP activity and investigate deviations.

• Analyze encryption downgrades

Attackers may request RC4-encrypted tickets to simplify cracking. An abrupt shift from AES to RC4 in ticket requests should raise an alert. Windows Event 4769 logs the encryption type used, enabling detection of unusual downgrades.

• Use identity detection tools

Traditional antivirus products focus on malware and often miss credential-based attacks. Use identity security monitoring and endpoint detection and response (EDR) tools that can identify abnormal authentication behaviors and ticket request patterns in real time. Microsoft Defender for Identity, CrowdStrike Falcon, and other identity analytics platforms can help detect Kerberoasting attempts. 

• Correlate with other indicators

Because Kerberoasting requires prior access, watch for signs of domain user compromise, like unusual login locations, abnormal volumes of failed logins, or endpoints infected with malware. Combining these signals with Kerberos monitoring generally improves detection.

Preventing Kerberoasting involves reducing the attack surface, hardening Kerberos settings, and improving identity and access management (IAM).

1. Harden service account passwords

Service accounts should use long, complex and random passwords of at least 14 characters and include upper and lowercase letters, numbers and special characters. Rotate these passwords regularly to limit the time available to attackers. Avoid reusing passwords across service accounts and ensure that password changes automatically update associated applications.

2. Disable RC4; enforce AES

Administrators should think about disabling RC4 encryption wherever possible and ensure that all service accounts support AES 128/256-bit encryption. Using AES produces stronger password hashes, making brute force attacks more time consuming. If RC4 cannot be removed immediately, restrict its use to trusted hosts and monitor for requests using it.

3. Remove SPN from human accounts

During software installation, developers sometimes assign SPNs to user accounts. Remove SPNs from human accounts and use dedicated service accounts or Group Managed Service Accounts (gMSAs). Doing so prevents attackers from cracking passwords that were never meant to be used as service credentials.

4. Principle of least privilege

Reduce the privileges associated with service accounts so that a compromise has limited impact. Avoid making service accounts members of Domain Admins or other high privilege groups unless absolutely necessary. Where possible, restrict service accounts to specific hosts or functions.

5. Shorter ticket lifetimes

Lowering the lifetime of tickets shortens the window in which a captured ticket remains valid. Enabling Kerberos pre-authentication forces clients to prove their identity before receiving a ticket, hindering offline password guessing.

6. Audit and rotate service accounts

Regularly audit Active Directory for unused or unnecessary SPNs. Remove or disable old service accounts, review privileges monthly and maintain a rotation schedule for service account passwords.

Another useful idea is for security teams to familiarize themselves with both offensive and defensive tooling related to Kerberoasting:

• Offensive tools

ADRecon, PowerView and BloodHound help enumerate Active Directory objects and visualize privilege relationships, giving cybersecurity experts insight into how attackers might move through the environment. Kerberoast modules in PowerSploit, GetUserSPNs.py and Rubeus automate SPN enumeration and ticket extraction, demonstrating how easy it is to launch a Kerberoasting attack.

• Defensive tools

EventSentry and the ELK Stack can collect and correlate Windows Event 4769 logs to detect unusual ticket requests. Microsoft Defender for Identity, CrowdStrike Falcon, BeyondTrust’s statistical detection tool and other identity analytics platforms monitor authentication behaviors and flag anomalies. SIEM systems should aggregate Kerberos ticketing logs, domain controller audits and endpoint telemetry to enable cross-correlation.

• Configuration best practices

Remove unnecessary SPNs from the domain, review service accounts monthly and disable unused accounts immediately. Create playbooks that define how often to audit TGS tickets and rotate passwords. Use gMSAs and limit the scope of service accounts to the minimum set of hosts and privileges. Where possible, restrict service accounts to support AES encryption only.

• Threat hunting

Use proactive threat hunting to look for low-and-slow Kerberoasting attempts. During an incident response situation, isolate compromised hosts, reset service account passwords and rotate Kerberos keys. After the event, review logging, tighten password policies and update detection rules.

Here are some common questions about Kerberoasting, how it works, and how you can protect against it.

1. Can multi-factor authentication (MFA) stop Kerberoasting?

MFA alone does not prevent the attack because Kerberos ticket requests use existing valid credentials. However, MFA limits the value of cracked passwords. Requiring MFA for privileged operations and remote access reduces the impact if a service account is compromised and complicates lateral movement.

2. What is the cost of a successful Kerberoasting attack?

The financial impact generally varies. In healthcare, the Ascension breach exposed 5.6 million patient records and disrupted clinical operations across multiple hospitals. Recovering from an incident like this includes ransom payments, remediation costs, regulatory fines and reputational damage. Because Kerberoasting grants domain wide access, an attacker can steal intellectual property, install ransomware or manipulate data, leading to costly downtime.

3. How does Kerberoasting differ from Pass-the-Hash?

Pass-the-Hash attacks reuse NTLM or Kerberos ticket hashes directly to authenticate without cracking them. Kerberoasting involves obtaining TGS tickets for service accounts and cracking the password hash offline. Both techniques rely on credential theft and offline use of password hashes but target different authentication elements. Defenses like disabling NTLM, enforcing AES and rotating service account passwords can mitigate both attacks.

4. Which encryption types influence Kerberoasting difficulty?

RC4 encryption uses the NTLM password hash as the key for service tickets, making it relatively easy to crack with GPU-based brute force tools. AES 128/256 uses a stronger key derivation process that dramatically increases cracking time. Organizations should disable RC4 and DES and configure all service accounts to support AES only. If older applications require RC4, restrict its use and monitor for RC4 ticket requests.

5. How can organizations test whether they are vulnerable?

Administrators can use PowerView or Rubeus in a lab environment to enumerate SPNs and request service tickets. Attempt to crack these tickets using Hashcat with dictionaries or brute force techniques. If passwords are cracked quickly, implement stronger password policies and rotate the accounts. Tools like BloodHound also help identify which service accounts have high privileges.

Kerberoasting is not a novel attack; it’s a vulnerability in Kerberos that has recently re-emerged in high-profile breaches. Attackers abuse legitimate Kerberos functionality to obtain encrypted service tickets, crack them offline and impersonate service accounts. 

Legacy encryption and weak password hygiene continue to make this attack feasible. Detection is challenging because the activity looks like normal Kerberos traffic and the cracking occurs outside the network.

Organizations should begin by reviewing their Active Directory. This means identifying service accounts, using strong passwords, removing RC4 encryption, and deleting any unnecessary SPNs. They should also use identity security and security monitoring tools to track ticket requests and spot unusual activity.

Kerberoasting is not just a service account compromise; it’s a gateway to data exfiltration. By securing endpoints with BlackFog, organizations can prevent attackers from stealing sensitive data and moving laterally across networks. Click here to your infrastructure before data leaks occur.