Kerberoasting allows attackers to determine sensitive passwords and the most common place for detecting this attack is on the domain controller. In this post, we will look into the details of Kerberoasting from a DFIR perspective.

Domain Controllers can contain a wealth of information, especially when it comes to tracking user authentication activity across a domain. They should be examined in any intrusion investigation to look for account compromise and lateral movement. We recently added analytics into Cyber Triage to detect domain controller attacks, including Kerberoasting, and wanted to share more about it.

In this post, we will cover:

Kerberoasting Key Concepts
Kerberoasting Details
Attack Goal
Attack Requirements
Artifacts for Detection
How Cyber Triage can help

Kerberoasting Key Concepts

Kerberoasting (T1558.003) is a tactic used by threat actors to get credentials to a domain account by exploiting normal Kerberos behavior in a Windows Active Directory (AD) environment.

The basic concept is that an attacker interacts with the domain controller to get a “ticket” that has data encrypted using a user’s password hash. The attacker then brute forces the data offline and learns the password. They can then use that password to log into other systems.

From a DFIR perspective:

The domain controller has events that show when the attacker requested the ticket, but it could blend in with normal activity
The computer used to request the ticket may have artifacts from Kerberoasting tools that were run
The computers that were accessed using the password will have no evidence that Kerberoasting occurred.

Kerberoasting Details

To understand how Kerberoasting works and how to detect its activity you must first understand the basics of Kerberos authentication in Windows. There are a few main components:

Security Principals: Represents user, service, and computer accounts in AD. Security Principles can act as both clients (end users and computers) and services hosting various resources (file shares, databases, etc…) within the domain.
Key Distribution Center (KDC): A service on a Domain Controller (DC). It is responsible for providing a secure mechanism to prove an entity’s identity through the use of session based tickets.
Ticket-Granting-Ticket (TGT): A ticket that provides the ability for a security principal to prove its identity to the KDC and request Service Tickets.
Service Ticket (ST): A ticket that provides the ability for a security principal to prove its identity to a service. The service determines if the identity is authorized to access its resources. Part of the ticket is encrypted with the service accounts password hash. This is the key component that Kerberoasting takes advantage of.

The below diagram helps to illustrate the Kerberoasting attack flow, which is identical to a Kerberos authentication diagram except for step 5 where the attacker offloads a ticket for offline cracking.

A standard Kerberoasting attack goes as follows:

The threat actor uses a compromised domain account and requests a Ticket Granting Ticket (TGT) from the domain controller via an Authentication Service Request (AS Req).
The domain controller verifies the user’s (compromised) identity and sends back a TGT via Authentication Service response (AS Rep).
Next, the threat actor requests a Service Ticket (ST) by sending the TGT in a Ticket-Granting Service Request (TGS Req).
If successful, the domain controller sends back the ST in a TGS response (TGS Rep). The ST contains the encrypted password.
With a ST in hand the attacker can transfer the ticket to a machine dedicated to brute forcing the password offline using John the Ripper, HashCat, or other password guessing tools.

For a more detailed look at the Kerberos authentication process in full check out Tim Medins, who first discovered Kerberoasting, blog here and Sean Metcalfs blog here.

Attack Goal

The goal of Kerberoasting is to obtain the password for service accounts. The password for the compromised account can then be used for:

Persistence: There are no indicators that an attacker has successfully Kerberoasted an account since the brute force is done offline. As a result, threat actors can hold on to the credentials and use them as a persistence mechanism if they lose access to a target.
Lateral Movement: Newly obtained credentials can be used to move to new systems previously inaccessible depending on permissions of the compromised account.
Privilege Escalation: Newly obtained credentials may have higher privileges than the account performing the attack. This is often the case since no special privileges are needed to perform Kerberoasting.

Attack Requirements

For a successful Kerberoasting attack to take place two criteria must be met:

Obtain a Service Ticket
Brute force the password from a Service Ticket

Details For Getting a Service Ticket

The threat actor ultimately wants a service ticket to decrypt the password from.

Under normal Kerberos operation a user (security principle) must hold a valid Ticket Granting Ticket (TGT) to obtain a Service Ticket (ST) from the domain controller (Key Distribution Center). This requires an adversary to have access to a domain account prior to performing any Kerberoasting activity. There are no special privileges required so any account within the domain will work.

If access to an account is not possible another non-standard approach to getting a Service Ticket can be attempted. The alternate approach requires an attacker to find an account that has Kerberos pre-authentication disabled. When an account has pre-authentication disabled a TGT can be requested without having to provide credentials. This allows an attacker to craft a special AS REQ that will return a Service Ticket instead of the normal TGT as discussed here.

Once an adversary is capable of requesting ST it’s time to find the Service Principal Names (SPNs) or account names to request STs for. This is key to understanding the scope of a Kerberoasting attack. A Service Ticket will only ever be encrypted with an account that has a SPN associated with it. As a result, only accounts with a SPN are susceptible to Kerberoasting. These are often computer accounts and service accounts that are associated with a service like MS SQL. However, normal user accounts can have a SPN as well. These are the core targets of a Kerberoasting attack as we will discuss shortly.

Obtaining a list of Kerberoastable accounts is trivial when the threat already has access to an account. Active Directory (AD) can be queried to get a list of all accounts with an SPN. Further refinement can be done to only get admin accounts with SPN or other filtering criteria to find interesting Kerberoastable accounts.

Ex. Powershell command to retrieve all admin accounts with a SPN:

get-aduser -filter {AdminCount -eq 1 -and ServicePrincipalName -like '*'} -prop * |

 select name,created,passwordlastset,lastlogondate,ServicePrincipalName

This capability is already baked into many of the Kerberoasting tools out there like Rubeus, Invoke-Kerberoast, and Impackets GetUsersSPNs.py. For a detailed look at how to perform Kerberoasting using some of previously mentioned tools check out the great red team write ups from HackTricks and Ired.Team.

Brute Force The Password From A Service Ticket

Getting a ST for an account with an associated SPN is only half the battle. The Service Ticket provides the data necessary to perform an offline brute force attack. For the attack to be successful a threat actor must guess the password, usually with a tool like John the Ripper, HashCat or tgsrepcrack.py. Kerberoasting relies on poor password management and weak passwords, which is not hard to come by. However, there are a few tricks to increase the chances of a successful attack:

Target user accounts
Request older encryption on Service Tickets

Kerberoasting is generally useless when it comes to targeting computer accounts and other managed service accounts. Not because these accounts cannot be Kerberoasted but they are impractical to attack due to the strong password management on such accounts. Computer account passwords are updated every 30 days, by default, and contain a 120 unicode character password. Similarly, managed service accounts have passwords that are managed by AD and have similar password age and length requirements that computer accounts have. As a result, Kerberoasting attacks tend to focus on standard user accounts that administrators create and manage. Again relying on the hope that administrators are not setting strong passwords or updating the password as frequently as one should.

Attackers can additionally leverage weak encryption on Service Tickets to increase the likelihood of cracking a password. Adversaries and many tools will often request ST with RC4 as the encryption. This was replaced by AES starting with Windows 2008 Server and Windows Vista. Again this does not mean AES ST are not susceptible to Kerberoasting it just means it is more work and time to try and brute force those tickets. ST with RC4 should generally not exist in your environment unless you have applications or older systems that require it.

DFIR Artifacts for Kerberoasting Detection

Kerberoasting is difficult to detect as it takes advantage of standard Kerberos behavior. Having said that, there are still a few artifacts to focus on during a DFIR investigation. We will be grouping the artifacts under the following two categories as the artifacts available are dependent on the system being analyzed:

Artifacts found on Domain Controllers
Artifacts found on Kerberoasting System

Artifacts found on Domain Controllers

Domain controllers are key to hunting down Kerberoasting activity due to the fact that they contain the KDC and can log all requests for TGT and ST within the domain.

Service Ticket Events

Event 4769 (A Kerberos service ticket was requested) is generated in the security event log whenever a Service Ticket has been requested. However, auditing for this event does not appear to be enabled by default based on Microsoft’s baseline auditing documentation. As a result it is critical that this setting is enabled for success and failure auditing on all domain controllers in case the data is needed for an investigation.

The key pieces of information we are looking for Kerberoasting activity are:

Encryption type: This field represents the encryption used. It can be leveraged as a way to filter out noise so STs that are more likely a result of Kerberoasting activity can be bubbled up. Focus on values of 0x1 or 0x3 for DES encryption and 0x17 and 0x18 for RC4 encryption.
Service Name: The service name that was requested in the Service Ticket. This represents a potentially compromised account if Kerberoasting was successful. This event cannot indicate the successful brute force guessing of an account’s password, just that its information was obtained for potential malicious use. This field can also be used to filter out noise like computer accounts (ends with a $).
Client Address: The IP of the machine that requested the Service Ticket. This will indicate a machine that has been compromised and should be further investigated if the ticket is found to be related to Kerberoasting.
Account Name: User that requested the Service Ticket. This will indicate a compromised account and warrants further investigation if the ticket is found to be related to Kerberoasting.

It’s important to note that if analyzing an older environment that has a Windows 2003 DC or a member workstation before vista then RC4 encryption will be present as AES was not introduced until vista/2008 server as documented here. There are other scenarios where you may run into older encryption due to applications that only support RC4 as well.

TGT Events

Event 4768 (A Kerberos authentication ticket was requested) is generated in the security event log whenever a TGT ticket has been requested. However, auditing for this event does not appear to be enabled by default based on Microsoft’s baseline auditing documentation. As a result it is critical that this setting is enabled for success and failure auditing on all domain controllers in case the data is needed for an investigation.

The key pieces of information we are looking for Kerberoasting activity are:

Service Name: The service name for a TGT ticket should always be krbtgt. However, when performing the Kerberos trick we previously mentioned where a ST is received via a AS REQ it will generate a TGT event with the name of the service requested. This is an easy indicator that a threat actor requested the ticket.
Client Address: Same information from 4769 event
Account Name: Same information from 4769 event

Artifacts Found on Kerberoasting System

While most Kerberoasting activity will only be visible from a Domain Controller, there is potential to find evidence on workstations that initiated the Kerberoasting activity. These systems can be identified by the source IP field in both TGT and ST that are suspected to be related to Kerberoasting. The key is to focus on process history that shows any evidence of known Kerberoasting related tools. For example, if you discover rubeus.exe has been executed via 4688 process creation events or find evidence that Invoke-Kerberoast.ps1 was ran via powershell logs then there is a good chance some Kerberos related activity was attempted on that machine and further investigation should occur. Here is a brief list of some common tools used during Kerberoasting:

Rubeus.exe (executable)
GetUserSPN.py (python)
Invoke-Kerberoast (powershell)
Kerberoast Attack Toolkit (python)
Kerberoasting scripts from Tim Medin (python/PS1/VBS)
setspn.exe (builtin windows binary)
- Arguments to get ST for all roastable accounts
- -T DOMAIN_NAME.LOCAL -Q */* | Select-String ‘^CN’ -Context 0,1 | % { New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList $_.Context.PostContext[0].Trim() }

How Cyber Triage Can Help

This is a lot of information to absorb and remember for a single attack, especially when things get heated during the middle of an investigation. It can be difficult to remember all of the locations where evidence can be found or the various heuristics that can be applied. That is why Cyber Triage is here to help! Our tool aims to assist in the following areas:

Automatic artifact collection
Automatic artifact scoring

As part of an investigation, you should collect data from the domain controller and analyze the authentication logs. This can show you Kerberos attacks and where users logged into.

Automatic Artifact Collection

Our adaptive collector collects source files (event logs, registry hives, etc..), parses out artifacts, and collects other interesting files based on references from artifacts. In the case of a Kerberoasting attack our collector will collect the security event log and parse out 4768 and 4769 events as artifacts.

Cyber Triage has a dedicated UI to displaying domain controller authentications so that you can see logon activity even if the specific destinations have not been collected and analyzed. Below is an example of a Service Ticket request (4769). The Sources tab shows you why Cyber Triage knows about the authentication attempt. From here, you can see:

The request came in from 10.0.0.2.
The authenticated user account was acme/rosemarie
The service that is being accessed is computer2$

Similarly, here is an example of a Ticket Granting Ticket request (4768). The main difference in the top table is the service name, which is because the TGT request goes to the krbtgt service.

If you are not seeing authentication types that you had hoped to see, you can go to the “OS Config Settings” to see what the audit settings were:

All of this is done without any user configuration, running of multiple tools, or manual parsing of tool output. The collector is run, DFIR related artifacts are collected, and data is displayed to a user for review.

Automatic Artifact Scoring

Cyber Triage automatically scores the collected data to show you what is suspicious in the case. In the case of Kerberoasting there are two main heuristics. The first is to detect potential Kerberoasting activity via Service Ticket requests with weak encryption.

The second is to detect non-standard services in TGT tickets, which as we discussed is a method an attacker can use to request a ST via AS REQ when an account has pre-authentication disabled.

Conclusion

In summary, Kerberoasting is essentially an offline brute force attack that relies on exploiting the Kerberos Authentication protocol to get a piece of information (ST) to guess an account’s password. Detection is difficult due to the nature of the attack exploiting normal Kerberos behavior and the offline brute force component.

It can be hard to detect the Kerberoasting events amongst all your event logs. If you are looking for a faster and more comprehensive way to analyze your domain controllers, then try Cyber Triage. You can download a free one week trial version here: https://www.cybertriage.com/download-eval/

Key Features

Recent Updates

Resources

Connectors

Training

DFIR Breakdown: Kerberoasting