How to Detect and Mitigate Kerberoasting Attacks

What are Service Principal Names (SPNs) and Why They Matter in Kerberoasting?

Service Principal Names (SPNs) serve as unique identifiers in Active Directory that link specific logon accounts to service instances. Attackers target SPNs to obtain encrypted service tickets, which they can then crack offline to reveal service account passwords. To block this, audit SPNs regularly and flag anything unusual or unauthorized.

How to Detect SPNs in Active Directory?

To manage Kerberos authentication and provide safe service configurations, Administrators must be able to identify and manage Service Principal Names (SPNs) in Active Directory. The “ServicePrincipalName” element of AD objects contains the SPNs, therefore accuracy in configuration is crucial.

Windows comes with a built-in tool called the setspn utility for managing SPNs. The following are the main commands.

• To list every SPN for a specific user or computer, type:setspn -L
• To find out if a particular SPN already exists in the domain, use:setspn -Q
• To add an SPN, but only after making sure there are no duplicates:setspn -S
• To add an SPN without verifying (which may result in duplication), use:setspn -A

Identifying Duplicate SPNs: Kerberos authentication may fail collectively or revert to NTLM if any SPNs are absent or duplicated. Two accounts registering the same SPN will break Kerberos authentication. Using setspn -X helps identify collisions. Once located, you must determine which account is incorrect, and remove the SPN from that account using setspn -D SPN , then reassign properly.

Listing with PowerShell: Using the Active Directory module, PowerShell offers robust querying capabilities. To list every object in Active Directory with SPNs instead of retrieving only the Properties attribute for ServicePrincipalName run:

Get-ADUser -Filter * -Properties ServicePrincipalName | Select-Object SamAccountName, ServicePrincipalName

Exporting Data via PowerShell: You can export SPNs to a file for analysis:

Get-ADUser -Filter * -Properties ServicePrincipalName | Select-Object SamAccountName, ServicePrincipalName | Export-Csv SPN_List.txt -NoTypeInformation

This command exports the SPN list to the current directory’s “SPN_List.txt” file.

How to Spot Abnormal Kerberos Ticket Requests?

Below is a step-by-step guide for identifying abnormal Kerberos ticket requests:

1. Monitor Service Ticket Request: Enabling Kerberos service ticket request monitoring and looking for users with an excessive number of 4769 events will allow you to keep an eye out for a lot of Kerberos service ticket requests in Active Directory. After the initial login, users request Kerberos TGS service tickets to access the numerous services on the network, which means that Event ID 4769 will be logged in the domain numerous times. On most networks, normal activity may range from dozens to hundreds of tickets per user per day. The key is to baseline your environment and alert on unusual spikes.
2. Set Ticket Encryption Type: The ticket encryption type is set to 0x12 for Kerberos events that use AES encryption. The Ticket Encryption Type assigned to Kerberos RC4 encrypted tickets is 0x17. Decrease the 4769 events” is misleading the goal is not to reduce events but to detect anomalies. RC4 (0x17) encryption on tickets is frequently an indication of malicious behaviour, particularly when it comes to automated or scheduled requests.
3. Review High-Privilege Accounts: When ticket requests to increase access arise from unfamiliar hosts or IPs or diverge from a user’s typical behaviour, they are suspicious. This would raise an alarm that needs to be reviewed
4. Check Unexpected IP Address: Look closely at the IP Address field in Event 4769’s logs. Ticket requests from unknown or unrelated IP addresses may suggest lateral movement or the use of stolen credentials.
5. Examine Any Failed Requests: A single successful ticket after several unsuccessful requests, particularly for high-value or sensitive services, may indicate reconnaissance or brute-force activity. Examine patterns like repeated failures followed by success, especially if they originate from the same source or account.

Best Practices to Mitigate Kerberoasting Attacks

Protecting your Active Directory environment from Kerberoasting involves improving password hygiene, SPN configuration, and monitoring.

1. Apply Least Privilege & Just-In-Time Access: Use the least privilege principles for all the accounts and implement Just-In-Time Administration frameworks, assign just the essential privileges, and refrain from granting domain-admin-level access unless absolutely necessary. To lessen the likelihood of golden ticket production, restrict the number of accounts that can access directory synchronisation (DCSync). Disable NTLM and RC4 authentication where possible, keeping in mind potential compatibility issues with legacy systems.
2. Implement Multi-Factor Authentication (MFA): When it is possible, implement MFA on every account. Multi-Factor Authentication reduces the impact of stolen password hashes or forged tickets by adding an additional layer of protection by requiring a second authentication factor, even in the event that a ticket or credential is taken.
3. Use Strong, Complex Passwords: Use lengthy, random, and distinctive passwords for service accounts, particularly those with SPNs. Avoid using dictionary words or repeating passwords. The passwords for service accounts linked to SPNs should be lengthy and randomly generated, as this significantly raises the difficulty of offline cracking. Passwords that are weak or frequently used greatly reduce the obstacle for attackers attempting ticket forging or Kerberoasting assaults. To guarantee consistency and minimize human error, passwords should also be changed on a regular basis at least every 90 to 180 days and automated through Group Managed Service Accounts (gMSAs).
4. Reduction of SPN Exposure: An SPN increases your attack surface for each service account. Consolidate when feasible, eliminate unneeded or old accounts, and audit active SPNs on a regular basis. Attackers have fewer targets when there are fewer SPNs. SPN-based queries can lead to privilege escalation, so avoid assigning SPNs to high-privilege accounts such as Domain Admins.
5. Restrict Delegation Usage: Unless it is absolutely necessary, disable unrestrained Kerberos delegation. Select resource-based or constrained delegation if it is required, as this lowers the possibility of lateral ticket misuse and restricts the delegation’s reach.
6. Enabling Kerberos Armoring: Enabling Kerberos Armoring (Flexible Authentication Secure Tunneling) strengthens the integrity of the initial authentication exchange This strengthens the initial exchange’s integrity protection, preventing tools from taking advantage of pre-auth techniques that aren’t as strong.

How Lepide Helps

The Lepide Data Security Platform, provides behavior-based threat detection, automated response capabilities, and real-time auditing of Active Directory events (including Event IDs 4768 and 4769). Lepide Auditor records and notifies users of unexpected Kerberos service ticket requests, including monitoring Event ID 4769, which serves as a proactive measure, empowering organizations to stay ahead of emerging threats and safeguard their digital assets effectively. It also provides comprehensive logs with before/after context for forensic analysis.

The Lepide Data Security Platform includes an Active Directory auditing and security solution which assists in providing you with the visibility you need to identify and address these problems before they become more serious.

Set up a demo with one of our engineers or download a free trial right now to discover how Lepide can benefit your organization.