Detecting LDAP based Kerberoasting with Azure ATP

This post has been republished via RSS; it originally appeared at: Enterprise Mobility + Security articles.

In a typical Kerberoasting attack, attackers exploit LDAP vulnerabilities to generate a list of all user accounts with a Kerberos Service Principal Name (SPN) available. Once successful at listing these accounts, attackers grant Kerberos Service Tickets for each user account with an SPN and later perform offline Brute Force on the encrypted part of the Kerberos tickets. This action helps attackers locate a password that belongs to a domain account. Domain account passwords enable attackers to freely move laterally in your domain.

 

Environments where the Kerberos Ticket Granting Service (TGS) is encrypted with a weak cipher, and the cipher is generated from a well-known password (not randomly generated) are prime targets for successful brute force attacks of this type.  

 

The following attack logic is often used to find an organization's weakest link and perform LDAP based Kerberoast attacks.

 

Picture1.pngFigure 1-Typical Kerberoasting attack flow

 

Typical LDAP based Kerberoasting attack flow and result: 

 

Step 1: Identify

 

In this attack phase, attackers are using LDAP to query and locate all user accounts with a Service Principal Name (SPN). Running this LDAP query is possible for all user accounts in a domain.

 

Picture2.pngFigure 2- LDAP query that looks for all user accounts with a SPN set

Step 2: Enumerate

In this phase of the attack, a request is made for Kerberos TGS to the SPN using a valid TGT.

 

Fig3.pngFigure 3- TGS request to ExampleService of user1 by user2

Fig4.pngFigure 4 - TGS response with ticket to ExampleService of user1

 

Step 3: Brute force

 

In the brute force phase of the attack, by using commonly available password cracking tools on accounts with commonly used passwords, attackers easily succeed at obtaining the password.

 

In the following example, a commonly used password cracking tool, JohnTheRipper, performs a successful brute force using a rainbow table.  

 

images.pngFigure 5 - Cracked password using a rainbow table

Step 4: Attack  

 

In cases where the attempted brute force attack (shown previously) is successful, attackers use the newly obtained clear-text password to login to remote machines or access cloud resources and files.

 

images2.jpgFigure 6 - Interactive clear-text logon

How can you detect and prevent Kerberoast attacks from succeeding? 

Azure Advanced Threat Protection (Azure ATP) has risen to the Kerberoasting challenge and developed new methods to detect when malicious actors are attempting to perform LDAP based reconnaissance on your domain. While this type of attack is difficult to detect, and LDAP’s extensive query language presented additional challenges, our security research work involved differentiating legitimate workflows from malicious behavior and surfacing all related activities and entities.

Our newest security alert involves smart behavioral detection backed by extensive machine learning, designed to raise an alert when any type of abnormal enumeration (including SPN enumeration), or queries on sensitive security groups are detected.  

 

Starting from v2.72, Azure ATP issues a Security principal reconnaissance (LDAP) alert when the first stage of a Kerberoasting attack attempt is detected on the domains we monitor.  

 

Each alert includes vital information for use in your investigation and remediation:

 

1. Identification of malicious activity

2. Attempted enumeration details and specifics

3. Historical comparisons and activity correlation

4. Suggestion remediation steps 

 

images3.png

The following workflow explains how to use Azure ATP alerts to detect and remediate Kerberoasting attempts on your domain.

 

Step 1: Review the alert to identify the actors and entities involved.

 

images4.pngFigure 7 - Azure ATP alert on suspicious enumerations 

 

Step 2: Filter activities to review resource access on the entity involved

 

images5.pngFigure 8 - Filter for resource access activities on Client1's profile

 

Step 3: Use the filter results to investigate the resource access activities

 

images6.pngFigure 9 - Investigate the resource access activity (generated by Kerberos Ticket Granting Service) for ExampleService/User1

Step 4: Filter Interactive logon and Credential validation for the accessed entity

 

images7.pngFigure 10 - Filter Interactive logon and Credential validation on User1’s profile

Step 5: Review logon and access attempts

 

images8.pngFigure 11 - User1's clear text password was used to logon on interactively on Client2

Step 6: Remediate possible risks

  1. Force a password reset on the compromised account
  2. Require use of long and complex passwords for users with service principal accounts https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/minimum-password-length
  3. Replace the user account by Group Managed Service Account (gMSA) https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview

 

Kerberoasting remains a popular attack method and heavily discussed security issue, but the effects of a successful Kerberoasting attack are real. Make sure your security team is aware of common Kerberoasting risks and strategies, along with the tools and alerts Azure ATP offers to help protect your domain.

 

As always, we welcome your feedback about our work, and are interested in learning more about the security threats and risks you encounter. For more information about features and threat protection, or to learn how we can help, contact us

 

Get Started Today

 

If you are just starting your journey, begin trials of the Microsoft Threat Protection services today to experience the benefits of the most comprehensive, integrated, and secure threat protection solution for the modern workplace:

 

 

 

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.