Know your enemy: How Kerberoasting cracks passwords without “hacking” anything

October is Cybersecurity Awareness Month, a good time to look at the attacks that are hardest to see. This is the third post in our three-part series on the most destructive identity attacks, and how identity and security teams can mitigate their impact. The first two parts of this series covered Golden Ticket and DCShadow attacks that rely on exploiting trust. In the final part of this series, we walk through Kerberoasting.

A Kerberoasting attack needs one login, and just one phone call can supply it. Crowdstrike’s 2026 Threat Hunting Report detected a 2x increase in vishing intrusions in the first half of 2026 compared with the second half of 2025. Attackers call your employees, pose as IT staff, and walk away with a working login. From there, Kerberoasting needs no elevated privileges and no exploit. FIN12, APT40, and Akira ransomware operations have all used it, for that same reason.

This post explores how attackers use Kerberoasting to get working passwords and how you can catch it.

An attack that doesn't need elevated permissions

Any account with a Service Principal Name (SPN) in Active Directory (almost always a service account) will hand a ticket to any logged-in domain user who asks for one. It's how your laptop talks to a file share or a SQL server without making you type a password repeatedly. An attacker doesn't need to “hack” anything because they ask for the ticket with a login they already have. 

The attacker takes the ticket, feeds it into a tool like Hashcat (a free password-cracking tool), and starts guessing the password hash by hash. Service account passwords tend to be old, reused, or short because they're set once and forgotten. Crack one, and the attacker can use the real password to gain access to everything the service account has access to. 

Here’s the sequence most Kerberoasting attacks follow:

1. Getting in the door: The attacker authenticates with any valid domain credential.
2. Casing the service accounts: Using access every domain user already has, the attacker queries AD for every account with a registered SPN.
3. Collecting tickets: The attacker requests TGS (ticket granting service) tickets for the accounts that look interesting. A TGS ticket proves a user's identity and grants authorized access to a particular network resource. AD issues TGS tickets to the attacker.
4. Cracking off-network: The attacker takes the tickets to their own hardware and brute-forces the password out of them.
5. Cashing in: Armed with a working password for an often over-permissioned service account, the attacker authenticates and moves toward whatever it has access to.

Why traditional detection methods fail to catch Kerberoasting

“Event ID 4769” (the log entry for a service ticket request) is one of the most common entries in any AD environment's logs, so a few additional requests are near invisible. What’s more, the part that breaks the password happens later, offline, on the attacker's hardware. 

Kerberoasting doesn't involve privilege escalation, so there's nothing to catch on that front. But the attacker still leaves clues early. For example, if one account asks for tickets to an unusually large number of services in a short window. Or it asks for weaker encryption than your domain normally uses. 

How Cohesity Identity Resilience gets ahead of it

Cohesity Identity Resilience continuously surfaces service accounts as Indicators of Exposure (IOEs) when they’re at risk for Kerberoasting. Some examples are when service accounts have excess privilege or weak passwords. This capability is one of several built-in features that protect dedicated service accounts. During an attack, Cohesity Identity Resilience watches ticket-request behavior and flags  abnormal volumes of requests.

Cohesity Identity Resilience automatically flags targeted service accounts for immediate credential rotation. That way you can secure your service accounts before an attacker cracks them. 

Here's an example of how Cohesity Identity Resilience detects and responds to a Kerberoasting attack*.

1. An attacker logs in with an ordinary domain account. No elevated privileges. They query Active Directory for every account with a registered SPN. Then they request Kerberos service tickets for the accounts that look valuable.
2. Cohesity Identity Resilience flags the anomalous ticket-request pattern in real time. If one user requests tickets across an unusual number of SPNs in a short window, that triggers an alert. No single request would look wrong in the Windows Event Log, but a pattern of behavior gives it away.
3. The alert reaches your security team with full context. You see which account requested the tickets and which services it targeted. You also see why the pattern is anomalous: that account has never talked to those services before.
4. Automated response flags the targeted service accounts for immediate credential rotation. This invalidates the password before the attacker's offline cracking attempt can produce anything usable.
5. Your team completes triage and confirms containment. Then you can harden the exposed accounts. Hardening looks like stronger passwords, AES instead of RC4 where supported, and no more privilege than each account needs.

*The walkthrough above is illustrative, a representative sequence. Not every Kerberoasting attack follows these exact steps.

Stop a Kerberoasting attack before the ticket ever gets cracked

Unlike DCShadow attacks, a Kerberoasting attack doesn't use legitimate AD mechanics. If you catch the request pattern—instead of waiting on a login failure—you can stop the attack before the attacker cracks the passcode.

This is final the part of a three-part series on the most destructive identity attacks, and how identity and security teams can mitigate their impact. Read the previous two parts here: 

• Part 1: Golden Ticket 
• Part 2: DCShadow

Watch the demo below to see how Cohesity Identity Resilience detects and stops attacks like Kerberoasting in your environment.

Learn more:

• Get a free identity security assessment 
• Solution Brief