What is Kerberoasting?

TL;DR:
Kerberoasting is an attack technique used to steal and crack passwords for service accounts in Active Directory. It is quiet, fast, and often leads directly to Domain Admin access. All it takes is one compromised user account and a weak internal password. That is why ransomware groups frequently rely on it to move from initial access to full control of your network.

What is Kerberoasting?

If you have never heard of Kerberoasting, you are not alone. Most executives and business leaders are unfamiliar with it until it shows up in a post-incident report.

Kerberoasting targets a part of your internal infrastructure that is easy to overlook. It goes after service accounts, which are special user accounts created for systems and software, not people. These accounts often run your databases, backup tools, or internal apps. Since they operate in the background, service accounts are rarely reviewed and often use weak or outdated passwords.

Here is where the problem starts. Once an attacker has access to your internal network, even using a basic domain user account with no special privileges, they can request encrypted password data for those service accounts. The system gives it to them by design. The attacker saves this data, takes it offline, and begins cracking the passwords using freely available tools. If any of those passwords are weak, they can unlock access to critical systems or even gain Domain Admin control.

This process is called Kerberoasting, and it has become one of the most common ways attackers escalate privileges once they are inside. It does not require malware, exploit kits, or advanced tools. It takes advantage of how Active Directory works and how many organizations fail to enforce strong passwords and proper account hygiene.

This technique is used in both real ransomware attacks and in manual penetration tests, because it reflects what would happen in an actual breach.

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, they just need 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 is not new. It has been a known attack technique for years, and the tools used to carry it out are free, well-documented, and easy to operate. So why does it still succeed?

Because most companies have not addressed the underlying issues.

Weak passwords, outdated encryption settings, and unmonitored service accounts are still common across internal environments. Many organizations focus heavily on external threats but fail to test what an attacker could do once they are already inside. Kerberoasting takes advantage of that gap. It uses normal system behavior, relies on poor configuration, and usually goes unnoticed until it is too late.

The attack works not because of some advanced exploit, but because the basics are not locked down. That is why ransomware operators and red teams continue to use it. It is reliable, fast, and difficult to detect unless you are looking for it.

The good news is that this risk is preventable. With strong password policies, proper account management, encryption enforcement, and internal security testing, you can shut down this attack path. But to fix it, you need to know it exists in your environment.

That is where Artifice Security comes in. Our team runs manual penetration tests that simulate real-world attacks like Kerberoasting. We show you exactly how far someone could get, what accounts are vulnerable, and how to fix the problems before they are used against you.

If you want to stop attacks like Kerberoasting before they reach your critical systems, a proper internal pentest is the right place to start.

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.

FAQ

Want to go deeper? Check out our Ultimate Guide to Penetration Testing for a full breakdown of testing methodologies, tools, and real-world applications.