What Is a Kerberoasting Attack?

What Is a Kerberoasting Attack?

Kerberoasting is a post-exploitation technique that exploits inherent weaknesses in the Kerberos authentication protocol used in Active Directory environments. The attack leverages the fact that any authenticated domain user can request service tickets for accounts tied to a Service Principal Name (SPN). These service tickets are encrypted using the service account’s password hash. Once attackers extract these tickets, they can conduct offline brute-force attacks to crack the password hash and obtain the plaintext credentials for the service account. The effectiveness of this technique largely depends on the complexity of the password associated with the SPN.

Uncover the Attack Paths Targeted by Kerberoasting

Try the interactive experience and identify high-risk routes.

VIEW PATHS

SPN-related accounts can either be machine or user accounts, but attackers typically focus on user accounts. This is because machine account passwords are automatically managed by the domain—regularly changed, complex by default, and periodically updated.

However, when an SPN is associated with a regular user account, the security landscape changes. Domain-enforced password policies typically don’t apply to these user accounts, leaving the strength of the password solely up to the user. Once attackers successfully crack the password, they can escalate privileges, move laterally across the network, steal sensitive data, deploy malware, and potentially compromise the entire infrastructure.

How Does Kerberos Protocol Work?

To understand Kerberoasting, it’s essential to first grasp the flow of Kerberos authentication:

Figure 1. Overview of the Kerberos Authentication Protocol Workflow in Active Directory

• KDC Consists of Two Parts: Authentication Server (AS) & Ticket Granting Server (TGS)

To understand the Key Distribution Center (KDC), it's essential to recognize that it consists of two key components: the Authentication Server (AS) and the Ticket Granting Server (TGS). The AS is responsible for authenticating users and verifying their identities before issuing a Ticket Granting Ticket (TGT).

• User Authentication + TGT Issuance

The authentication process begins when the user logs into their system. The user’s device (client) requests a Ticket Granting Ticket (TGT) from the Key Distribution Center (KDC). To do this, the user encrypts the timestamp using the NTLM hash of their password and sends the request to the KDC.

On the KDC side, user NTLM hashes are stored. The KDC decrypts the timestamp and, if valid, confirms the user's authentication. Once authenticated, the KDC issues the TGT, which is encrypted with a secret key known only to the KDC. This TGT includes important information such as the user’s identity and the ticket’s expiration time.

• Service Ticket Request

When the user needs to access a specific service (like an application or file share), the client uses the TGT to ask the TGS for a service ticket. The request specifies the exact service the user wants to use by giving its Service Principal Name (SPN), which is the service’s unique identifier.

• Service Ticket Issuance 

The TGS checks the TGT to ensure it’s valid. If everything is correct, it creates and sends a service ticket back to the client.  This ticket is encrypted with a secret key that belongs to the service the user wants to access, ensuring that only that service can read it. Note that the ticket is encrypted with the NTLM hash of the service-related user.

• Service Access 

Once the client has the service ticket, it sends it to the specific service it wants to access. The service uses its secret key to decrypt the ticket. If the ticket is valid, the server verifies the identity of the requestor. This ensures that the user is indeed who they claim to be. For example, if UserA is requesting access, the server confirms that the request is genuinely from UserA. Only the verified user is granted access to the service within the domain.

Because services in Kerberos rely on this process, each service must be associated with a Service Principal Name (SPN). In the next section, we will explore the importance of SPNs in greater detail.

What Are Service Principal Names (SPNs)?

Service Principal Names (SPNs) are unique identifiers in Active Directory (AD) that link a specific service instance to a service logon account. They allow clients to request authenticated sessions with services; therefore, each SPN must be unique within the AD forest to ensure proper authentication.

SPNs consist of two main components:

• Service Class: Specifies the type of service, such as HTTP for web services, LDAP for directory services, or MSSQLSvc for Microsoft SQL Server.
• Host Name: Identifies the server where the service is hosted.

Here are some examples for SPNs:

Each Service Principal Name (SPN) is associated with an account in Active Directory, either a machine or user account. User accounts are particularly attractive targets in Kerberoasting attacks because any authenticated user can request service tickets for any SPN. These accounts are known as Kerberoastable accounts, a concept we will explore further.

However, user accounts are typically preferred for several reasons. 

• First, user account passwords are managed by the users themselves and are generally easier to crack due to their often weaker length and complexity.

• Additionally, the privileges associated with domain user accounts are more appealing to attackers compared to machine accounts.

• By default, machine account passwords are more secure, as they are longer than 25 characters and are automatically changed by the domain each month, making them much harder to brute-force. 

For this reason, adversaries focus on user accounts with SPNs, targeting them for Kerberoasting. It’s also common to see kerberoastable domain admin users, which further increases the risks. Once attackers compromise these accounts, they can impersonate the user, escalate privileges, and move laterally across the network, making SPNs a significant vulnerability in Kerberoasting attacks.

Now that we’ve covered the roles of user accounts and SPNs, let's explore how a real-life Kerberoasting attack is executed in practice.

How Do Kerberoasting Attacks Work?

There are mainly four steps to a successful Kerberoasting attack.

Step 1: Domain Authentication

As previously mentioned, for an attacker to carry out a Kerberoasting attack, they must first be authenticated within the domain. In other words, the attacker needs to have at least the privileges of a regular domain user. Kerberos domain authentication, as explained earlier, is a prerequisite for the attack.

Step 2: Finding a Kerberoastable Target

Once authenticated, the attacker begins by scanning for Service Principal Names (SPNs) to identify potential targets. The attack starts when the attacker, now an authenticated domain user, requests a Kerberos TGS ticket for a specific service. 

These SPNs are associated with service accounts used in Kerberos authentication, making them potential targets for the attacker.

SPN Scanning

Attackers commonly perform SPN scanning to discover service-related accounts associated with network services including but not limited to web servers or database servers (e.g., SQL). These accounts often have elevated privileges, making them prime targets for compromise. By scanning for SPNs, attackers can pinpoint accounts that could enable lateral movement or privilege escalation if compromised.

Adversaries are particularly interested in service-related accounts with high-level privileges, such as those tied to Domain Admins, as compromising these accounts would grant significant control over the network.

For instance, the following is a built-in binary, focusing on user accounts. With such a simple executable, it is possible to identify all kerberoastable accounts in the domain.

While commercial tools can be quite noisy, this built-in tool quickly retrieves kerberoastable user accounts without much noise.

The attacker selects a target user. How do they choose?

Attackers may look at the adminCount, review group memberships, examine several candidates, or even check last login times. Additionally, the attacker might configure a fake SPN for a non-existent or unused service. Even a single request to this invalid service is risky and can be detected through SPN scanning. If you request a TGS for that unused service tied to a specific user, alarms may go off. 

For instance, if an attacker targets a kerberoastable user named UserA, linked to an unused service, the attacker simply requests access to that service. If they request a TGS for it, the attack is complete, and the service would be compromised.

Step 3: TGS Requested

When the user requests a Ticket Granting Service ticket for target kerberoastable accounts (linked to an SPN), the Domain Controller generates and returns the TGS. This ticket is encrypted using the NTLM hash of the target service account (the service account associated with the SPN).

• Ticket Encryption: The TGS is encrypted with the service account’s NTLM password hash. The user requesting the TGS does not need elevated privileges to request the ticket, and the Domain Controller does not verify if the user has actual permissions to access the service—only that the user is authenticated. This is what makes the Kerberoasting attack possible, as any authenticated user can request service tickets for SPN accounts and attempt to crack them offline.

Step 4: Attacker Extracts the TGS Ticket 

Once the TGS ticket is issued, the attacker (or user) can extract the encrypted TGS ticket from memory. Tools like Mimikatz or Rubeus are commonly used for this purpose. These tools allow attackers to dump Kerberos tickets from memory, often without needing administrator privileges, depending on the system configuration. 

• Extract TGS ticket for a specific service (e.g., MSSQL service):

Once these tickets are dumped, attackers can use the exported TGS tickets for offline cracking, which we will discuss in the next step.

Step 5: Offline Cracking of Kerberos TGS Ticket 

In the final step of a Kerberoasting attack, an adversary can take the encrypted TGS tickets and crack them offline using tools like John the Ripper, Hashcat, or tgsrepcrack.py, with the command examples given below.

Since the TGS is encrypted with the NTLM hash of the service account, cracking it reveals the account’s password. 

The offline nature of the attack bypasses security measures like account lockouts and remains undetected.

Who Is Vulnerable to Kerberoasting?

For this question, the answer is simple.

A Kerberoastable account is any service account within an AD environment that has one or more Service Principal Names associated with it, making it a target for Kerberoasting attacks. These accounts are vulnerable because the presence of SPNs allows attackers to request a TGS ticket, which is encrypted with the service account’s password hash. Attackers can then extract and attempt to crack these tickets offline, revealing the plaintext credentials.

While any service account with an SPN can be vulnerable, accounts using weak passwords or not protected by stringent password policies are particularly at risk. Service accounts with high privileges, such as those tied to critical services or administrative roles, are especially attractive targets in Kerberoasting attacks.

The Complete Active Directory Security Handbook Exploitation , Detection, and Mitigation Strategies

How to Detect Kerberoasting Attack?

TL;DR

1. Create a Kerberoasting honeypot by associating an SPN with a user account for a known unused service, and monitor Event ID 4769 for any TGS requests related to that SPN.

2. Enable Logging of Event ID 4769 on DC for Kerberos TGS requests.

3. Look for Ticket Encryption Type 0x17 (RC4-HMAC).

4. Identify Excessive TGS requests from a single user for multiple SPNs.

5. PowerShell activity related to Kerberos requests.

6. Monitor and correlate unusual activity with high-privilege accounts.

Detecting Kerberoasting can be challenging since the attack leverages standard Kerberos operations, which occur frequently in an AD environment. However, there are certain indicators and configurations that can help identify potential Kerberoasting attempts. 

Below are methods and best practices to detect Kerberoasting activity.

Detecting Kerberoasting: Honeypot Kerberoasting 

In Kerberoasting detection, the concept of a honeypot can be highly effective. The idea is to set up an attractive, kerberoastable user tied to a non-existent service. This works by linking an SPN to a user account for a service that you know is not in use.

By closely monitoring Event ID 4769, which logs TGS requests, you can detect any suspicious activity. The moment you see a request for this specific user and service, you know something is off. Why would anyone be requesting access to an unused service? This could indicate someone is tampering with the system or, more likely, that an attacker has fallen for the trap, unaware the service isn’t real.

To make this approach effective, the honeypot service needs to be highly convincing. If attackers are using automated tools to scan for kerberoastable accounts, these tools will automatically request access to the fake service, revealing the attack attempt.

By using this strategy, you can lure attackers into exposing themselves while keeping your legitimate services secure.

Detecting Kerberoasting: Enabling Kerberos Logging (Event ID 4769) on Domain Controllers

A critical step in detecting Kerberoasting attacks is enabling proper logging on Domain Controllers. Specifically, you should enable “Audit Kerberos Service Ticket Operations” under Account Logon in Group Policy. This will allow you to monitor and capture Kerberos ticket requests.

• Event ID 4769: Logs when a Kerberos service ticket (TGS) is requested.

• Event ID 4770: Logs when a Kerberos service ticket is renewed.

Since TGS requests are central to Kerberoasting attacks, monitoring Event ID 4769 is essential. 

However, due to the large number of TGS requests in enterprise environments, careful filtering is necessary to identify potentially malicious activity. Filtering for high-value targets, such as service accounts or administrative accounts, can help reduce the noise and focus on potential threats.

Detecting Kerberoasting: Look for RC4-HMAC Encryption (Ticket Encryption Type 0x17)

Kerberoasting attacks commonly exploit RC4-HMAC encryption due to its weakness and ease of cracking using tools like Hashcat, compared to stronger encryption algorithms like AES-128 or AES-256. 

To detect potential Kerberoasting activity, monitor Event ID 4769 (Kerberos TGS ticket requests) and filter for Ticket Encryption Type 0x17 (RC4-HMAC). 

RC4-HMAC (0x17) should be rare in modern environments where AES (0x18) is the default encryption for Kerberos tickets [1]. The presence of RC4-HMAC often signals the use of older accounts or legacy systems, but it can also be a clear indicator of Kerberoasting attempts.

To detect such activity, you can plan for catching mistakes attackers might make. 

As a result, attackers using these tools should modify the defaults to avoid detection. Many deductions have been written about this, so attackers need to be aware that using default configurations makes them easier to spot.

By monitoring for RC4-HMAC and unusual access permissions, security teams can better detect Kerberoasting attempts and respond accordingly.

Detecting Kerberoasting: Identify Unusual Patterns of TGS Requests

Monitoring for unusual patterns in Ticket Granting Service requests can be an effective method to detect potential Kerberoasting activity. Attackers often request multiple service tickets over a short period to increase their chances of finding service accounts with weak passwords.

Key indicators of suspicious activity include:

• Excessive Event ID 4769 for a Single User:

If a single user requests multiple TGS tickets for different services or SPNs within a short timeframe, it may indicate malicious behavior. Typically, users request service tickets for a limited number of services they regularly interact with, not a wide variety of services in quick succession. It is unusual for a legitimate user to access numerous, unrelated services—such as SQL databases, file servers, and web servers—within a short period.

How to Prevent Kerberoasting?

Here are four simple steps you can take to help prevent a potential Kerberoasting attack.

Preventing Kerberoasting: Enforce Strong Passwords for User Accounts 

One of the most effective ways to mitigate Kerberoasting attacks is by enforcing strong, complex passwords for user accounts (service related accounts). Since Kerberoasting relies on offline password cracking, the strength of the password significantly impacts the attack's success.

• Password Complexity:

User account passwords should be long and complex, ideally more than 25 characters, incorporating a mix of letters, numbers, and special characters. 

• Password Retention

Passwords should be regularly, ideally every 30 days or less. Frequent rotation reduces the window of opportunity for attackers to successfully crack and exploit service account credentials.

Preventing Kerberoasting: Using Managed Service Accounts

Managed Service Accounts (MSAs) and Group Managed Service Accounts (gMSAs) provide an effective way to mitigate Kerberoasting by ensuring strong password hygiene and automated password management.

• Automatic Password Changes:

MSAs and gMSAs automatically rotate their passwords on a regular basis, often every 30 days or less, without manual intervention. This greatly reduces the likelihood of successful offline password cracking, as attackers would need to crack the password within a very short time window. 

In contrast, non-rotated service account passwords give attackers an indefinite amount of time to attempt offline cracking.

• Delegated SPN Management:

gMSAs simplify Service Principal Name (SPN) management by delegating control to specific accounts or services, ensuring that SPNs are correctly configured and reducing the risk of Kerberoasting attacks that exploit misconfigured SPNs.

Visualizing and Preventing Kerberoasting Attacks with Picus Attack Path Validation

At Picus, we developed Attack Path Validation (APV) to help organizations identify and map their most critical attack paths that adversaries might exploit to compromise their networks. Picus APV reveals how attackers can leverage misconfigurations and security weaknesses in Active Directory environments, including Kerberoastable accounts or service accounts with weak passwords, to obtain service account credentials, escalate privileges, and move laterally across the network—potentially compromising high-value organizational assets.

Figure 2. Picus Attack Path Validation

Using our Intelligent Adversary Decision Engine, Picus APV simulates real-world attacker techniques, showing how adversaries can move laterally and target your organization’s Crown Jewels, such as domain admin accounts.

To help you gain a clear understanding, we’ve created a video on Attack Path Validation that demonstrates how Decision Engine identifies the stealthiest attack paths in your AD environment. Watch the video to discover how attackers could exploit Kerberoasting in your environment. Identify critical attack paths and strengthen your defenses today!

The Complete Active Directory Security Handbook Exploitation , Detection, and Mitigation Strategies