Detecting LDAP enumeration and Bloodhound‘s Sharphound collector using AD Decoys

Introduction

In this blog post, we’ll discuss how to detect enumeration done by Bloodhound’s SharpHound collector and LDAP Reconnaissance activities in an Active Directory environment. We’ll be using deception to detect this by creating a few decoy accounts (or honey accounts) and mixing them with the real accounts. Decoy accounts are the ones that are created for deceptive purposes and are also used in defense to detect malicious actions. MITRE has covered Bloodhound and Domain enumeration in their tools and techniques.

Active Directory is a centralized database that describes a company’s structure and contains information about different objects like users, computers, groups and. and their relation to each other in the environment. In active directory, decoy accounts can be created in the form of user accounts, group accounts, service accounts, computer accounts, etc. Relevant details can be added to make a system, service, groups, etc. look more realistic. And when the Active Directory objects data is enumerated, it also enumerates the decoy accounts and can be used to raise an alert when the reconnaissance activity happens.

Bloodhound

Bloodhound is a tool that is generally used by adversaries to visually map an organization’s Active Directory structure and analyze it to find its weaknesses. Being able to analyze the Active Directory is very useful to attackers to identify which objects are worth targeting in an organization. Any user within an active directory domain can interrogate their organization’s Active Directory which runs on the domain controllers.

Bloodhound uses the collector which is called as SharpHound to collect various kinds of data by running a ton of LDAP queries to collect information within Active Directory.

Fig.1 Sharphound querying the Active Directory

In the above screenshot, we can see that the Sharphound has enumerated 222 objects in the Active Directory and saved the results in compressed files. Once the zipped files with the results of all the Active Directory objects, groups, sessions, trusts, etc. are collected and imported into Bloodhound, it uses graph theory for data visualization running the Neo4j graph database in the backend. The output after importing the collected data into Bloodhound looks similar to the data shown in the below screenshot.

Fig.2 Bloodhound showing the Attack path

Now the information gathered from Active Directory (using SharpHound) is used by attackers to make sense out of the AD data and analyze it to understand the target organization’s AD structure and find out various interesting facts and shortcut paths to get to a Domain Admin and the permissions of users on different hosts etc.

In the backend, Sharphound uses LDAP queries to collect data from Active Directory as you can see in the code:

https://github.com/BloodHoundAD/SharpHound/blob/41516e778ea186e144e4494f2e070cdb9aa878b9/Sharphound2/Enumeration/LdapFilter.cs#L58

Fig.3 Sharphound LDAP queries

Sharphound collector queries for the details like all the AD objects including all enabled accounts, disabled accounts, accounts with SPN, all the organisational units, group policy objects, all the security and non-security groups in AD, groups in the Builtin container, etc.

We’ll take a look at the LDAP queries that it runs in the backend and will try to detect both the Sharphound enumeration and if the LDAP queries are sent without sharphound.

LDAP Queries

Let’s see the kind of LDAP queries that Sharphound runs in the backend:

(|(|(samaccounttype=268435457)(samaccounttype=268435456)(samaccounttype=536870913)(samaccounttype=536870912)(primarygroupid=*))(&(sAMAccountType=805306369)(!(UserAccountControl:1.2.840.113556.1.4.803:=2)))(|(samAccountType=805306368)(samAccountType=805306369)(samAccountType=268435456)(samAccountType=268435457)(samAccountType=536870913)(samAccountType=536870912)(objectClass=domain)(&(objectcategory=groupPolicyContainer)(flags=*))(objectcategory=organizationalUnit))(objectclass=domain)(|(samaccounttype=268435456)(samaccounttype=268435457)(samaccounttype=536870913)(samaccounttype=536870912)(samaccounttype=805306368)(samaccounttype=805306369)(objectclass=domain)(objectclass=organizationalUnit)(&(objectcategory=groupPolicyContainer)(flags=*)))(|(&(&(objectcategory=groupPolicyContainer)(flags=*))(name=*)(gpcfilesyspath=*))(objectClass=domain)(objectcategory=organizationalUnit))(&(serviceprincipalname=*)(samaccounttype=805306368)))

If we run these LDAP queries without SharpHound and using tools like ADFind, it also returns the data that is requested:

Fig.4 Performing LDAP enumeration

In the result, we can see that 222 objects have been enumerated (same as Sharphound) and we have all the details in the output:

Fig.5 LDAP enumeration results

Configuring the AD Environment

Below are the tasks that we’ll perform:

1. Create a few Active Directory Decoy accounts
2. Enable auditing on those accounts
3. Run Bloodhound’s Sharphound tool
4. Perform LDAP Reconnaissance activities within the active directory environment
5. Detect the activities in Windows event logs.

The reason for creating decoys to detect this kind of activity is that when the domain enumeration is done and Active Directory objects data is enumerated, it also includes the decoy accounts. Decoys accounts are created to make sure that we enable audit logging only on a few decoy accounts and not for all the objects to minimize the noise.

First of all, let’s make sure that the AD environment is configured properly with the advanced logging policies enabled, that are required to accomplish this task. The only policy that is required to detect this enumeration process is the Directory service Access Audit policy. On the domain controllers, it is enabled by default. If it is disabled, we can enable it on the domain controller by using the auditpol command as shown below:

Below is the command to enable the advanced auditing required for this:

auditpol /set /subcategory:”Directory Service Access” /Success:Enable

Fig.6 Enable Advanced Audit Logging

We should see the Success once the policy is enabled:

Fig.7 Verify Advanced Audit Logging

Now that the required audit policy is enabled, we’ll create decoy objects now. Let’s start first with the decoy user object.

Create Decoy User Objects

We’ll create decoy user objects from the Active Directory Users and Computers MMC (Microsoft Management Console) and enable auditing for them. To do this, below are the steps:

• Right-click the user object- Properties — Go to Security>Advanced>Auditing and add a new audit entry
• Add a new Principal “Everyone”
• From “Applies to” dropdown, choose “This object only”
• Uncheck all main permissions.
• Select Read all properties, Read permissions.
• Click OK to save the changes.

Below is the graphical representation of how it can be done using the GUI:

Fig.8 Create Decoy User Account

This can also be done using PowerShell:

New-ADUser -Name “Josh Austin” -GivenName “Josh” -Surname “Austin” -SamAccountName “Josh.Austin” -UserPrincipalName “Josh.Austin@threatlab.corp” -Path “OU=Managers,DC=threatlab,DC=corp” -AccountPassword(Read-Host -AsSecureString “Please enter password”) -Enabled $true

Note: The Read-Host parameter will ask you to input a new password.

Fig.9 Create Decoy User Account using PowerShell

Creating Decoy Computer Object

We’ll create decoy computer objects from the AD Users and Computers MMC Snap-in. To do this, below are the steps from the AD Users and Computers MMC:

• Right-click the computer object — Properties — Go to Security>Advanced>Auditing and add a new audit entry
• Add a new Principal “Everyone”
• From “Applies to” dropdown, choose “This object only”
• Uncheck all main permissions. Select Read all properties, Read permissions.
• Click OK to save the changes.

Below is the graphical representation of how it can be done using the GUI:

Fig.10 Create Decoy Computer Account

This can also be done using PowerShell:

New-ADComputer -Name “THL-SRV2” -SamAccountName “THL-SRV2” -Path “OU=ApplicationServers,DC=THREATLAB,DC=CORP”

After the computer account is created, you can view its properties using Get-ADcomputer command as shown below:

Fig.11 Create Decoy Computer Account using PowerShell

Creating Decoy Group Object

We’ll also create decoy Group objects from the AD Users and Computers MMC and enable auditing for them:

• Right-Click IT Helpdesk — Properties — Go to Security>Advanced>Auditing and add a new audit entry
• Add a new Principal “Everyone”
• From “Applies to” dropdown, choose “This object only”
• Uncheck all main permissions.
• Select Read all properties, Read permissions.
• Click OK to save the changes.

Below is the graphical representation of how it can be done using the GUI:

Fig.12 Create Decoy Group Account

This can also be done using Powershell:

New-ADGroup -name “IT Helpdesk” -GroupScope Global

Fig.13 Create Decoy Group Account using PowerShell

Configuring Decoy User, Group, and computer Objects

It’s important to mimic the decoy accounts to look as realistic as the other Active Directory objects. The naming convention of decoy objects should match the normal Active Directory accounts. We’ll also add details in the common attributes of the objects as follows:

• Add details in the description, organisation attributes of the decoy user objects
• Add details in the operating system name, version, and DNS name attributes for computer accounts
• In the case of groups, make sure to add the group information, add members and make it look legitimate.

Fig.14 Add details to make decoys accounts look more real

Run Bloodhound’s Sharphound Collector

After configuring the environment and creating decoy accounts, we’ll run SharpHound now:

Fig.15 Running Blodhound’s Sharphound collector

Performing the LDAP Enumeration

We’ll also perform the normal LDAP enumeration using the ADFind tool. AdFind is a free command-line query tool that can be used for performing LDAP enumeration to gather information from Active Directory.

Fig.16 Performing LDAP enumeration using ADFind

Detections (Event 4662)

Any activities related to enumeration of the Active Directory environment by using Bloodhound’s SharpHound and also the LDAP enumeration performed by tools like ADFind for the Decoy accounts will be logged under event ID 4662 in Windows Security events.

Enumeration attempt on the Decoy Group Account:

Fig.17 Detecting LDAP enumeration on the decoy group account

Enumeration attempt on the Decoy Computer Account:

Fig.18 Detecting LDAP enumeration on the decoy computer account

Enumeration attempt on the Decoy User Account:

Fig.19 Detecting LDAP enumeration on a decoy user account

Note: As you can see in the above screenshot, Event Viewer shows the values of Object Name and Object type, but while forwarding the events, windows doesn’t forward the Object Name value in the logs. Instead, it forwards the object GUID value for the Object Name and object Type which looks like below.

Fig.20 Object GUID in Windows Event log forwarding

So while creating detection rules, it’s important to include the object GUID value of the decoy objects in the use cases to alert only for the events and not for other 4662 events in the environment.

Example Spotter Query:

resourcegroupname = “ms_windows-security” and baseeventid = 4662 and devicecustomstring1 = “Read Property” and filename = “%{afd7a537–221e-42bd-8063–29c751a32734}”

This kind of rule will result in the events when there is a “Read Property” type access attempt on the AD object with GUID “%{afd7a537–221e-42bd-8063–29c751a32734}” which means the decoy account only.

Conclusion

Our goal as a defender is to disrupt the adversary activity in the network. And using deception, it is possible to detect the presence of adversaries. More deception content can be added to strengthen the defense strategy like decoy network shares etc.

Some of the best practices while designing the deception are :

• Add Decoy Groups with *Admin* in the group name. Because adversaries usually search for *Admin* in LDAP queries to enumerate the high privilege accounts
• Create Decoys in important protected as well like Domain Admins
• Create decoy network shares and enable auditing
• Place users and computers in different OUs
• Create Computer objects as Decoys and assign unconstrained delegation as adversaries would like those accounts as interesting
• Always create long and difficult passwords for Decoy accounts
• And if more decoy accounts are sitting in different places, we have more information when reconnaissance activities are going on

Securonix Threats Labs researches cutting-edge security topics to drive our industry-leading security analytics and operations platform. Check out the Securonix blog for up to date advisories and alerts for emerging threats