How to Prevent Kerberoasting Attacks?

Kerberoasting attack targets the Active Directory environment to enable attackers to extract and crack service account credentials. Threat actors can gain elevated privileges by exploiting weak password policies and misconfiguration, which further results in lateral movement and deeper network compromise. In this article, we will learn about the harm that Kerberoasting causes, also its impact on Active Directory security and the best practices that organisations can follow to detect and prevent such attacks.

What is a Kerberoasting Attack?

Kerberoasting is an attack technique in which hashed passwords of service accounts are stolen in Active Directory (AD) environments. This attack targets the Kerberos, a network authentication protocol used to ensure the security of authentication requests. Kerberos is the default authentication protocol that enables secure communication between client and server applications. This secure communication is created by using secret-key cryptography.

In this, an authenticated user requests tickets for a service principal name and the ticket received is encrypted with the hashed password of the associated service account. Attacker further cracks the password’s hash using tools like hashcat.

A short tutorial on Ticket Granting service (TGS) before understanding Kerberoasting attacks

To understand attacks, we must first establish a solid understanding of the Kerberos authentication process.

A ticket granting service (TGS) is a service that issues service tickets and is a component of Kerkberos key distribution center (KDC). The TGS job is to use TGT to verify the clients identity and then issue a service ticket needed to access a particular resource.

A ticket granting service and service ticket are two different concepts. A TGS ticket is used to obtain the service tickets, whereas a service ticket is a ticket obtained from the ticket granting service using the Ticket Granting Ticket (TGT) issued by the Key Distribution Center (KDC). These tickets are the centerpiece of the Kerberos authentication process.

Now to Kerberoasting attack….

How does Kerberoasting attack work?

To identify service accounts operating on servers (like web services, SQL services, etc.), Kerberos uses Service Principal Names (SPNs). A specific service account is linked to each SPN and any user in the domain can request it. To identify service accounts, attackers can use tools like BloodHound. This tool maps the AD environment, highlighting the escalation paths to service accounts with domain admin or any other privileged user.

A Ticket Granting Service (TGS) ticket can be requested by attackers who have access to the domain (even with regular user privileges) for any service using its SPN. The password hash of the service account is used to encrypt this ticket.

Once the encrypted TGS ticket is received by the attacker, they can dump it from the Kerberos ticket cache or memory. Since the service account’s password hash is used to encrypt the ticket, the attacker does not have the password yet.

To recover the clear-text password of the service account, an offline brute force attack or dictionary attack is performed by the attacker against the encrypted ticket. This step depends on the encryption method and the strength of the service account’s password. Offline cracking enables attackers to minimise the noise of failed login attempts, which results in difficulties in attack detection and can be done with some tools like Hashcat, John-the-Ripper, etc.

After the password is cracked, the service account credentials can be used by the attacker to access the network with the same privileges as that account. This can enable lateral movement and even further compromise within the environment since service accounts often have elevated privileges.

What makes Kerberoasting Attack dangerous?

Since Kerberoasting attacks are difficult to detect and exploit common drawbacks in password management and authentication mechanisms, they pose a serious threat to organisations. Here are the following reasons why they are dangerous:

Silent and Difficult to Detect

Kerberoasting can initiate even without high privileges. For the Active Directory service accounts, any authenticated domain user can request service tickets (TGS). Since ticket hashes are extracted and cracked by attackers offline, after obtaining the encrypted service ticket, there is no direct interaction with the target system. This makes real-time detection more difficult.

Since Kerberoasting uses legitimate Kerberos requests that appear as normal network activity, standard security monitoring tools may not flag them as malicious. Attackers can decrypt the password hashes faster with GPU-based brute force attacks if service accounts use legacy or weak encryption such as RC4-HMAC.

Exploits Weak or Poorly Managed Passwords

Once the attacker gets the encrypted ticket, attacking service accounts with brute-force or dictionary attacks becomes easier because of the weak or non-expiring passwords. Service accounts typically run automated processes and applications, thus organisations often ignore them during password audits.

Attackers can use cracked service account credentials to perform lateral movement, escalate privileges or gain access to sensitive data or systems. Unless it has strong password policies such as complex, long and randomly generated passwords, it can still be cracked within a short period.

Why Kerberoasting is a Threat to Active Directory?

Kerberoasting exploits weaknesses in Kerberos authentication to gain access to critical systems, thus it poses a significant security threat to Active Directory (AD). Once a service account’s password is cracked by an attacker, they can move laterally across the network using the credentials. Often service accounts contain elevated privileges that enable attackers to access sensitive data, escalate privileges or even gain control of domain controllers. Compromised service accounts can disrupt functions and result in major security incidents since they are connected to business-critical applications.

Service accounts often have weak and non-expiring passwords, which makes them an even easier target for attackers to get encrypted service tickets. Services running under specific accounts are identified by SPNs in AD. They can uncover high-privilege accounts to Kerberoasting attacks if misconfigured. Attackers can perform Kerberoasting without raising alarms if organisations cannot monitor and audit Kerberos service ticket requests.

Advanced persistent threat (APT) groups and ransomware gangs widely use Kerberoasting to get an initial foothold in enterprise networks. Threat actors have leveraged Kerberoasting as part of their attack chain in multiple cybersecurity breach reports, often in combination with tools such as Rubeus or Mimikatz to crack or extract Kerberos ticket hashes.

How to Prevent Kerberoasting Attacks?

Kerberoasting focuses on cracking offline user passwords, in such cases, there is no use in decrypting the hash without it being decrypted. Therefore, the most effective step to prevent these attacks is implementing a strong corporate password policy. There are the following recommendations to stop and mitigate the effectiveness of kerberoasting:

It is recommended to reduce the privileges associated with service accounts. Only the permissions necessary to complete their tasks should be enabled in these accounts. Avoid giving them excessive privileges like high-level permissions or Domain Admin.

Passwords of service accounts should be long and complex (at least 25 characters). This makes it even more challenging to brute force the password hash from a Kerberoasting attack. To reduce exposure time, rotate service account passwords regularly, especially for sensitive accounts and where possible, consider the use of Group-managed service accounts.

For unnecessary or stale SPNs, review and audit service accounts. Only those accounts should have SPNs registered which require Kerberos authentication. It is recommended to have stronger encryption methods such as AES256 instead of weak encryption methods like RC4 because weaker encryption methods are more exposed to offline cracking. It is important to ensure that AES encryption is supported and used by service accounts and domain controllers for Kerberos tickets. One can use the Group Policy to configure this.

Accounts should be prevented from using weak encryption for Kerberos authentication by the Protected Users security group, as it disables NTLM authentication. It mitigates the risk of Kerberoasting and other credential-based attacks by adding high-value accounts to this group.

Often, privileges are escalated by using Kerberoasting attacks to compromise service accounts having delegation rights. It is recommended to restrict service account delegation unless necessary. Instead of using unconstrained delegation, which is more vulnerable to abuse, one can use “Resource-based Constrained Delegation” or “Constrained Delegation.”

Best Practices for Kerberoasting Attack Detection

Here is a combination of technical measures and best practices that can be followed to reduce the potential entry points for attackers:

Monitoring Kerberos Ticket Requests

Regular monitoring and auditing of Kerberos ticket requests is essential to detect unusual patterns of the initial phase of the attack. In ticket requests, unusual spikes or repeated attempts to request service tickets can be considered a red flag.

Check for Event IDs 4768 and 4769. Event 4679 generates when a TGS request is made. Look for the Event ID 4771 – Kerberos Pre-Authentication Failed, this is generated when an attacker tries to enumerate username or service account before requesting the ticket. The two event IDs should be monitored on priority. These security events are not enabled for auditing by default, therefore, it’s important to ensure your security auditors and internal team can pick up this during security setting reviews.

Remember to look for events with activity typically seen during attacks, such as monitoring for legitimate encryption types. For instance, encryption type 0x17 is associated with RC4 usage, typically used by AD attacking tools. Genuine requests use 0x11 and 0x12. An event detail should include a field such as:

<Data Name=”TicketEncryptionType”>0x12</Data>

For instance, enforcing an SIEM solution which helps to track ticket requests and trigger alerts whenever high-frequency activity appears, enables organisations to identify potential threats earlier. The detection capabilities can be improved by integrating automated threat intelligence by connecting known attack signatures with ticketing anomalies.

Implementing a strong password policy

To ensure strong password security in an organisation, protecting service accounts is amongst the top priorities for an identity security strategy. Service accounts must enforce strong password policies, including unique, long and complex passwords and regularly update them. Offline cracking of the passwords can be minimised by using lengthy, non-dictionary passwords with mixed characters.

Passwords can be made both memorable and secure by using passphrases which combine random phrases or words (such as “BlueSky!Lion$Tree”). Attackers can be prevented from exploiting credentials over an extended period by regularly implementing password expiration policies.

Restrict SPN Exposure

One should identify and audit SPNs to understand which service accounts are exposed. This can be done to minimise the accounts vulnerable to Kerberoasting. For example, PowerShell scripts it is a regular audit tool that help enumerate SPNs and assess their necessity to help limit exposure. This is useful to identify active directory account that has a SPN because it ties Kerberos service to a user account, likely at times the source to identify privileged accounts in use within AD environments. Additionally, deactivate unnecessary or outdated service accounts that ensure critical SPNs are safe with stronger controls and can significantly reduce the attack surface.

Limit Service Account Privileges

For service accounts to function, it is recommended to restrict the privileges to the minimum necessary. Always use the principle of least privileges to minimise the impact of a compromised service account. For example, prevent service accounts from being logged in interactively or used to run non-essential tasks by configuring them. Ensure that each service account has permissions aligned only with its specific purpose by applying role-based access control (RBAC), as it prevents excessive access, which can be leveraged in an attack.

Use Honeytokens (Deceptive SPNs/Accounts)

Honeytokens are basically decoy SPNs or service accounts created to lure attackers attempting to perform a kerberoasting attack. In case any interaction is made with the honeytokens, then it should immediately trigger an alarm, and then should be investigated to prevent the attack. It is useful to detect other credential thefts as well.

Use Managed Service Accounts (MSAs)

MSAs can be used to streamline the management of service account credentials and they also ensure automatic password updates. For example, you can configure group MSAs to support services running across multiple servers that automate password management when maintaining security.

This lowers the risk of human error connected to manual password updates and makes sure credentials remain updated without administrative overhead.

These best practices can help you minimise the attack surface and make it difficult for attackers to exploit Kerberos authentication mechanisms. For improved security posture, organisations can consider employing monitoring tools that alert security teams about the potential indicators of compromise (IOCs).

Use Privileged Access Workstations (PAWs)

Privileged Access Workstations (PAWs are the machines which are dedicated to do administrative tasks only. It is recommended to use PAW only for domain admin and sensitive account management work. To reduce the risk, isolate those machines from internet browsing or email access. This can stop the attacker from further escalating their privileges.

Challenges in Mitigating Kerberoasting Attacks

The difficulties in detection, resource constraints, and outdated infrastructure make preventing Kerberoasting attacks difficult.

Detection Complexity: Since attackers exploit legitimate Kerberos functionality, identifying Kerberoasting attempts is challenging. In normal network activity, the process of requesting service tickets is common, which makes it difficult to distinguish between malicious observation and routine requests. Often hidden techniques are used by attackers to remain undetected, like using a long time before cracking passwords offline, or requesting service tickets in small batches.

Resource Constraints: Many organisations lack a budget and staffing, which makes it challenging to provide sufficient resources for ongoing monitoring and threat hunting. Security measures like Managed Detection and Response (MDR) solutions can be expensive and need continuous maintenance and threat hunting. Security teams may not be capable of detecting Kerberos-based attacks, which result in gaps in defensive strategies.

Legacy Systems: Essential security features such as AES encryption for Kerberos tickets might not be available in older Active Directory environments, which makes them more vulnerable to Kerberoasting. Additional attack surfaces are created by legacy applications that depend on weaker encryption methods, such as RC4-HMAC, that are tough to patch without breaking compatibility. Often significant investment and planning are required to upgrade or replace legacy systems, which leads organisations to postpone security improvements.

Conclusion

Kerberoasting attacks when undetected could cause a big headache for your entire corporate environment or wider environments (where trusts or production environments are included). However, you can significantly reduce your exposure with proactive measures. Take action now to secure your Active Directory environment before it’s too late. Our thorough active directory security assessment covers an in-depth assessment of active directory security. Get in touch to discuss our methodology and share your concerns to see if we can work with each other.

Identify vulnerabilities before attackers can exploit them, get a comprehensive assessment of your AD security, and schedule a free security consultation now. Cyphere can help you implement best practices and technical measures to reduce Kerberoasting and other credential-related attacks.