What is Kerberoasting?

TL;DR:
Kerberoasting is a technique attackers use to steal and crack passwords for service accounts in Active Directory. It is quiet, fast, and often leads to Domain Admin access. With just one low-level user account and a weak password, an attacker can escalate quickly. That is why this method is so common in ransomware attacks and internal compromise scenarios.

What is Kerberoasting?

If you have never heard of Kerberoasting, you are not alone. Most people don’t encounter the term until they’re reading about it in an incident report after it’s already caused real damage.

Kerberoasting is an attack technique that targets one of the most overlooked parts of your internal infrastructure: service accounts. These are the user accounts that keep your systems running in the background — databases, backup tools, internal apps. They’re rarely reviewed and often have weak or outdated passwords.

Once an attacker gains access to your internal network, even with just a basic domain user account, they can quietly request encrypted password data tied to those service accounts. The domain controller hands it over, just as it’s designed to. The attacker then cracks the passwords offline, looking for a weak one that opens the door to higher privileges.

This is the essence of Kerberoasting. It doesn’t rely on exploits or malware. It uses normal, expected behavior in Active Directory and it works because most environments aren’t hardened against it.

Whether you’re defending against ransomware or just trying to understand how attackers escalate inside a network, Kerberoasting is one of the first things you need to know.

How Does a Kerberoasting Attack Work?

Kerberoasting works because of how authentication is designed in Active Directory. The attacker does not need elevated access or special tools to start. They only need a valid domain user account, which can be obtained through phishing, a stolen VPN login, or other low-effort intrusion methods.

Once inside, the attacker moves through four simple steps:

1. Log in as a basic domain user.
They do not need admin access. Any regular account in the domain will work. These can often be found or guessed using public data, credential stuffing, or social engineering.

2. Identify service accounts and request tickets.
Using a tool like Rubeus or GetUserSPNs.py, the attacker queries Active Directory for service accounts tied to SPNs (Service Principal Names) and immediately requests their encrypted Kerberos service tickets, known as TGS tickets. These tickets are encrypted using the password hash of the service account.

3. Export those tickets and crack them offline.
Using tools like Hashcat or John the Ripper, the attacker attempts to brute force the password used to encrypt the ticket. If the password is weak or uses an outdated algorithm like RC4, this step can take only hours.

4. Use the cracked credentials to move deeper.
Once the attacker has a service account password, they check its permissions. If it has admin rights on any systems, which is often the case, they can log in, extract more credentials, or access sensitive data.

Imagine someone walks into your office building using a valid employee badge. They go to the front desk and request a copy of every service key used by internal departments. The receptionist hands them over without question, because the request follows normal protocol. Instead of trying the keys on doors right away, the person takes them to a private workshop, studies them, and makes duplicates. Once they figure out which key opens the most important doors, like the server room, they come back quietly and let themselves in.

That is how Kerberoasting works. The attacker uses a normal domain account to request encrypted service tickets. They take those tickets offline, crack the passwords, and use any successful result to access systems with elevated privileges — all without triggering alerts.

This entire process can be automated and done quietly. Most environments will not detect it unless specific logging and alerting are in place. That is what makes it so dangerous, especially in ransomware campaigns.

Why Is Kerberoasting Dangerous for Your Organization?

Kerberoasting is dangerous because it turns one small gap in your internal defenses into a direct path toward full domain compromise. It does not require malware. It does not rely on software vulnerabilities. And it often works even in environments that appear to follow standard security practices. This makes it a favored method for ransomware operators and other threat actors who want to quietly escalate their access without being detected.

Once an attacker cracks a service account password, they can begin moving laterally through the network. This means using that one account to access other systems, looking for more credentials, more access, and more control. Even if the cracked account is not a Domain Admin, it may still have local admin rights on key servers, access to backup data, or permissions that open new doors inside the network.

To put it in context, most ransomware incidents begin with something simple like a weak password or a stolen VPN login. But that initial access is just the beginning. What happens after the attacker gets in is what really causes damage. Kerberoasting is one of the fastest and quietest ways to turn that foothold into complete control of your domain.

This technique fits neatly into the second phase of an attack, where the goal is to escalate access and prepare for the final blow. Once the attacker gains Domain Admin, they can disable antivirus tools, access sensitive data, install persistence mechanisms, and launch a ransomware payload across hundreds of systems in minutes.

The risk is not just the loss of one account. The danger comes from what that account connects to and how quickly that access can grow. Kerberoasting gives attackers a way to chain together weak passwords, misconfigured permissions, and poor visibility into a full-blown breach.

For decision-makers, this is not just a technical flaw. It is a business risk that can lead to data loss, ransom payments, regulatory penalties, and long-term reputation damage. Ignoring it means giving attackers an easy and invisible path to your most sensitive systems.

💡 Real-World Threat. Real Fixes.
Most Kerberoasting attacks don’t need exploits — just a single weak service account. A proper internal pentest shows you exactly how far someone could get in your environment before a real attacker does.

What Tools Are Used in Kerberoasting Attacks?

Kerberoasting does not require advanced malware or custom code. In fact, attackers often use freely available tools to perform every step of the attack. If they gain access to a Windows system inside your network, they may run a tool called Rubeus, which allows them to interact with the Kerberos protocol and request service tickets. With just a few commands, Rubeus can list accounts tied to services, request the tickets, and export them for offline cracking.

Rubeus is popular with threat actors because it runs directly on a Windows host and blends in with normal system activity. It uses PowerShell or can be compiled as an executable. Either way, it is fast, quiet, and effective.

On the penetration testing side, we often use a tool called GetUserSPNs.py from the Impacket framework. This tool performs the same actions from a Linux system like Kali. It queries the domain controller for any account associated with a Service Principal Name, requests the encrypted ticket, and saves it to a file for analysis. The process reflects exactly what a real attacker would do, but in a controlled and safe environment.

There is also a module in Metasploit called auxiliary/gather/get_user_spns that can perform this step as well. While Metasploit is best known for exploitation, its modules are often used to demonstrate proof of concept during internal security assessments.

What these tools have in common is that they take advantage of normal, allowed behavior in a Windows domain. There is no exploit involved. The domain controller issues tickets because it is designed to. That is why tools like Rubeus and GetUserSPNs.py are so effective as they rely on built-in features and only need the kind of access most attackers can get early in an intrusion.

For security leaders, this means the tools themselves are not the real issue. The real issue is weak passwords, outdated encryption, and lack of visibility. The tools just reveal what is already possible in your environment.

How Can You Detect and Prevent Kerberoasting?

Kerberoasting is quiet by design. It uses legitimate features of Active Directory, so many environments do not detect it unless they are watching for very specific behaviors. That is part of what makes it so dangerous. It is not a virus, not a zero-day, and not something your firewall is going to block. It slips through unnoticed unless you know how to look for it.

Detection starts with logging. You need to collect and monitor Kerberos service ticket requests, especially when they involve accounts with Service Principal Names (SPNs). Windows Event ID 4769 can provide some visibility, but by default, most systems do not flag this as suspicious. What helps is correlating these requests with patterns, such as a low-privileged account making requests for multiple high-privilege service accounts in a short time span.

Security tools like Microsoft Defender for Identity or SIEM platforms like Splunk or Sentinel can help detect these anomalies, but only if the right logs are being ingested and alerts are properly configured. Without that, the entire attack can unfold with no one noticing.

Prevention focuses on reducing the attack surface. One of the most effective ways to block Kerberoasting is to use strong, complex passwords for all service accounts, especially those tied to SPNs. Passwords should be long (e.g. 24 characters), randomly generated, and changed regularly. If a password is too strong to crack in a reasonable amount of time, the attack becomes ineffective.

Another key step is using AES-only encryption for service accounts instead of older, weaker algorithms like RC4. Attackers often succeed because the tickets they capture are encrypted with outdated ciphers that can be cracked quickly. Enforcing AES means the encryption is much harder to break, even if an attacker manages to capture the ticket.

You can also reduce exposure by replacing traditional service accounts with Group Managed Service Accounts (gMSAs). These are managed by the domain controller and use complex passwords that rotate automatically. They cannot be used to log in interactively and are not vulnerable to Kerberoasting in the same way.

Finally, review and limit where your service accounts have admin rights. Many environments assign local admin access to service accounts on dozens of systems without realizing the risk. Just because a service needs to run on a server does not mean it needs elevated privileges everywhere.

To stop Kerberoasting, you need to harden accounts, enforce modern encryption, reduce privilege sprawl, and monitor for unusual Kerberos activity. It is not one fix. It is a combination of controls that work together to shut down this attack path.

How Penetration Testing Identifies Kerberoasting Risks

Kerberoasting is not something you can fully understand by looking at a checklist. It depends on real-world context, what accounts exist, how they are configured, where they have access, and how well they are protected. That is exactly why a manual penetration test is so valuable.

During an internal penetration test, we simulate the exact steps an attacker would take after gaining a foothold. If we are simulating a user-level compromise, one of the first things we do is look for service accounts tied to SPNs. Using tools like GetUserSPNs.py, we request service tickets from the domain controller and analyze the encryption type. If the tickets use weak ciphers or belong to accounts with short, guessable passwords, we attempt to crack them offline using tools like Hashcat.

The difference between this and a vulnerability scan is depth. A scanner might tell you that RC4 is still allowed or that a password policy is weak, but it will not tell you if a service account password can actually be cracked and used to access other systems. A manual pentest shows you what is possible right now, not what might be risky in theory.

We also test what happens next. If we successfully crack a service account password, we try to log in to systems where that account has access. If we can move laterally, escalate privileges, or reach sensitive data, we document every step. You see not just that a problem exists, but what someone could actually do with it.

In your case, we already covered this in our previous post, Can a Penetration Test Prevent Ransomware?, where a Kerberoasting attack led directly to Domain Admin access. That was not hypothetical, it reflected exactly what could happen in many real environments.

A proper penetration test does not stop at detection. It walks the same path an attacker would and gives you a clear report of what they would have found, how far they could have gone, and how to fix it.

Final Thoughts: Why This Attack Still Works in 2025

Kerberoasting isn’t new, but it still works. Not because attackers are using advanced exploits, but because the basics are often left wide open.

Weak service account passwords, outdated encryption, and a lack of internal visibility are still common in many environments. Most organizations focus on keeping attackers out but never test what happens if someone gets in. Kerberoasting takes advantage of that blind spot. It uses normal system behavior, slips past most detection tools, and rarely raises alarms.

The good news is that this risk is fixable. Stronger password hygiene, modern encryption settings, and internal testing can shut it down before it turns into something worse.

At Artifice Security, we perform manual penetration tests that simulate the exact steps real attackers use. We show you what could happen, how far someone could go, and how to fix it before it becomes a problem.

Want to know where your gaps are?

Let’s identify the risks now so you are not reacting to them later.

📧 contact@artificesecurity.com
📞 720–515–1337
🔗 artificesecurity.com

About the Author

Written by Jason Zaffuto, Founder of Artifice Security
Jason is a veteran penetration tester with over 25 years of experience in IT, electronics, and offensive security. He served in the U.S. Army as a Military Intelligence Systems Maintainer and later worked in red team operations for both the military and private sector. He holds several degrees in electronics and Cybersecurity and has led engagements for Fortune 500s, critical infrastructure, and government agencies. Today, he leads Artifice Security, helping clients identify and fix the exact weaknesses ransomware attackers exploit.

Originally published at https://artificesecurity.com on June 1, 2025.