Kerberoasting attack traits and prevention

A Kerberoasting attack is a post-exploitation technique used by attackers to exploit weaknesses in the Kerberos authentication protocol, specifically in Active Directory (AD) environments. The goal of a Kerberoasting attack is to obtain the hashed credentials of service accounts, which can then be cracked offline to reveal the plaintext password. These accounts often have elevated privileges, making them valuable targets.

Using this technique attackers with basic domain user privileges request encrypted Kerberos service tickets (TGS tickets) for services running under user accounts, then attempt to crack the ticket offline to obtain the plaintext password of the service account. Once the password is cracked, attackers can potentially escalate privileges or move laterally within the network. Defending against Kerberoasting involves using strong passwords, monitoring SPN requests, and employing password management strategies such as using Managed Service Accounts (MSAs).

?

What’s a Kerberoasting attack:

1. Service Principal Names (SPNs): In Active Directory, Kerberos is used to authenticate users and services. Every service running under a domain user account is associated with an SPN (Service Principal Name), which allows the Kerberos protocol to identify which service a user is trying to access. These services may include SQL servers, web servers, or other applications running in the domain that require authentication.
2. Requesting Service Tickets (TGS): When a user (or an attacker with access to the domain) wants to access a service, they request a service ticket (also called a Ticket Granting Service or TGS) for that service from the domain controller (DC). The TGS ticket is encrypted using the hash of the service account’s password.
3. Extracting the TGS Ticket: An attacker with basic user privileges can enumerate SPNs (services) and request TGS tickets for those services. This is a legitimate action within Kerberos and does not require elevated privileges. The attacker then extracts the encrypted TGS ticket.
4. Offline Cracking of the TGS Ticket: The attacker attempts to crack the TGS ticket offline by brute-forcing or using dictionary attacks to recover the service account’s password hash. Tools like Hashcat or John the Ripper are commonly used for this purpose. If the service account has a weak or poorly managed password, the attacker can successfully recover the plaintext password from the TGS ticket.
5. Privilege Escalation: If the cracked service account has elevated privileges (e.g., it is a domain admin, local admin on a sensitive computer, or has access to sensitive resources), the attacker can use the credentials to escalate privileges within the AD environment or use this account to infiltrate local SAM with other privileged accounts. Even if the service account has limited permissions, it can still be a foothold for lateral movement or further attacks within the network.

?

Traits of a Kerberoasting attack:

• Non-admin privilege required: The attacker needs only basic domain user access to request TGS tickets.
• Offline attack: The actual cracking of the password is done offline, so the attack is stealthier, and there are no immediate signs of compromise within the network.
• Weak password vulnerability: The success of the attack depends on the service account's password strength. Weak, short, or poorly managed passwords are highly vulnerable.
• Targeted accounts: Service accounts with SPNs are typically the target, especially those associated with high-privilege roles such as database services, web servers, or applications.

?

Kerberoasting attack defense

To effectively prevent and defend against Kerberoasting attacks in an Active Directory (AD) environment, organizations must implement a combination of password management, monitoring, and security best practices.

1. Enforce Strong, Complex Passwords for Service Accounts

• Use Long, Complex Passwords: Ensure that all service accounts have strong, complex passwords with at least 25 characters, combining letters, numbers, and special characters.
• Use AD managed service accounts: Encourage the use of Active Directory managed service accounts, where AD manages the password rotation and an encrypted string is used in place of a password in Service Account login configuration.

2. Implement Managed Service Accounts (MSAs) or Group Managed Service Accounts (gMSAs)

• Automated Password Management: Use Managed Service Accounts (MSAs) and Group Managed Service Accounts (gMSAs), which automatically manage and rotate passwords, ensuring that passwords are both complex and regularly updated without manual intervention.
• Eliminate Static Passwords: MSAs and gMSAs prevent Kerberoasting attacks by eliminating static passwords that remain unchanged for long periods.

3. Regularly Rotate Service Account Passwords

• Frequent Password Changes: Set up policies that ensure service account passwords are rotated regularly (e.g., every 30-90 days). This limits the window of opportunity for attackers to crack passwords.
• Automate Password Rotation: Use tools to automate the password rotation process, ensuring that it happens without delays or human errors, such as AD managed service accounts mentioned above.

4. Monitor and Detect Unusual Kerberos Ticket Requests

• Track SPN Requests: Monitor your environment for unusual volumes or patterns of Service Principal Name (SPN) requests, especially from user accounts that do not typically request service tickets. This can be done using Microsoft products such as Defender for Identity / Advance Threat Protection.
• SIEM Integration: Use a Security Information and Event Management (SIEM) tool like Microsoft Sentinel or other logging solutions to detect anomalies and trigger alerts for potential Kerberoasting activities.

5. Limit Privileges of Service Accounts (Least Privilege)

• Follow the Principle of Least Privilege: Ensure that service accounts only have the minimum permissions necessary to perform their functions. Avoid assigning high-privilege roles like Domain Admin to service accounts unless absolutely required.
• Separate Privileges: Ensure that highly privileged accounts are not used as service accounts. If a service account must have elevated privileges, consider additional monitoring and password policies.

6. Disable Unnecessary and Stale Service Accounts

• Remove or Disable Unused Accounts: Regularly audit service accounts to ensure they are still needed. Disable or remove any accounts that are no longer in use to reduce the attack surface.
• Monitor Account Usage: Set up policies to track and disable service accounts that have not been used for a certain period.
• Service Account Restrictions: restrict service accounts from interactive / local logos. This way if an account is compromised it cannot be used by a bad actor to process a logon on a sensitive system. This restriction policy can be implemented using AD Group Policy.

7. Enforce Multi-Factor Authentication (MFA) for Privileged Accounts

• MFA for Service Accounts (if applicable): Where feasible, enforce multi-factor authentication (MFA) for elevated accounts. Although MFA may not directly stop Kerberoasting, it helps secure elevated accounts against unauthorized access.
• MFA for Admins: Ensure that administrative accounts, especially those managing service accounts, are protected with MFA to prevent unauthorized access.

8. Implement Kerberos Armoring (FAST)

• Enable FAST (Flexible Authentication Secure Tunneling): Kerberos Armoring (also known as FAST) helps protect against ticket interception and replay attacks, adding an additional layer of security to Kerberos authentication.
• Configure Domain Controllers: Ensure your domain controllers support and enforce FAST, providing enhanced protection against credential-theft attacks.

9. Use Account Tiering for High-Privilege Roles

• Account Segmentation: Implement an account tiering model, where highly privileged accounts (Tier 0 accounts, such as Domain Admins) are used only for specific tasks and cannot access lower-tier resources. This limits the scope of potential compromise from a Kerberoasting attack.
• Use Separate Service Accounts: Do not use the same service accounts across different tiers. Ensure that each service account has the least privilege and is isolated from critical infrastructure.

10. Enable Auditing and Log Event Monitoring

• Enable Detailed Kerberos Auditing: Turn on Kerberos event logging on domain controllers to capture events like ticket requests, service ticket creation, and potential suspicious activity.
• Review Logs Regularly: Ensure your security team regularly reviews logs for indicators of a Kerberoasting attack, such as abnormal numbers of ticket-granting service (TGS) requests. Relevant events include Event ID 4769 (Kerberos Service Ticket Request) for abnormal activity.

If you need help with identifying, mitigating or preventing Kerberoasting attacks on your AD environment, please reach out and I will be happy to help!