There are numerous techniques available for enumerating data via LDAP. In the context of a Red Team engagement – where operational security (OPSEC) is critical to avoid detection by the Blue Team – directly running LDAP queries from a PowerShell console has become increasingly impractical in recent years due to improved monitoring and detection capabilities.

That said, there are still viable methods to perform LDAP enumeration under these constraints. One such approach is outlined in the LDAP obfuscation research by Sabajete Elezaj and Daniel Bohannon, published in August 2024 [1]. Their work demonstrates how LDAP queries can be obfuscated using various techniques to evade detection. However, even with obfuscation, executing PowerShell commands from within a C2 beacon may still pose significant OPSEC risks.

Over the years, the community has published a wealth of content on this topic. One of the blogs I can recommend is “Active Directory Enumeration for Red Teams” by @domchell of MDSec, published in February 2024 [2]. It’s highly recommended for anyone looking to deepen their understanding of stealthy AD enumeration tactics.

In the spring of 2025, I conducted tests using several LDAP enumeration techniques to evaluate what actions would trigger alerts in Microsoft Defender for Identity (MDI) and Microsoft Defender for Endpoint (MDE). Some of these tests were run directly from a PowerShell console on a client machine, while others were executed through a Cobalt Strike beacon using the ldapsearch Beacon Object File (BOF) from TrustedSec’s Situational Awareness toolkit [3].

When leveraging the ldapsearch BOF, output can be retrieved from Cobalt Strike’s log files and parsed using BOFHound [4], a tool that converts results into JSON format suitable for ingestion into BloodHound for post-exploitation analysis. The BOFHound repository also links to blog posts with all the technical details needed to replicate this workflow.

As a third method, for added variety in this blog post, I also explored executing LDAP queries directly from Microsoft Excel using the OleDB provider – a less conventional, but interesting vector for stealthy enumeration.

The victim client used for these tests was a fully patched Windows 11 client with MDE P2 license enabled. The MDI threshold level configuration was set to the lowest for all settings:

MDI threshold settings

In the test results below, each entry includes the LDAP query command that was executed, followed by the corresponding detection outcome from Microsoft Defender for Identity (MDI). For each test, I evaluated two key aspects:

1. Did MDI trigger an alert as a result of the query?
2. Was the query logged in MDI’s IdentityQueryEvents table, accessible via the Advanced Hunting section in the Microsoft Defender portal [5]?

Most of the queries were executed using various LDAP obfuscation techniques, aiming to reduce the likelihood of detection or logging by MDI.

LDAP Enumeration using native PowerShell

The initial tests were conducted using native ADSI PowerShell queries, incorporating basic LDAP query obfuscation techniques. These queries were executed directly from a PowerShell console on a Windows client, without any connection to a command-and-control (C2) framework.

List Domain Admins Group

The following query lists the Domain Admins builtin group (without it’s members) by using ambiguous name resolution and hex encoding as well as ComparisonOperator obfuscation:

Note: The string \64\6F\6D\61\69\6E Admi*asdfasdfasdf translates to Domain Admi*, where the hexadecimal values represent ASCII characters. A random string was appended after the wildcard. As highlighted in the 2024 research by Daniel Bohannon and Sabajete Elezaj, when using Ambiguous Name Resolution (ANR) in LDAP queries, any characters following a wildcard (*) are ignored during query execution. This behavior can be leveraged to obfuscate search terms while still retrieving valid results.

MDI alert triggered: No
Data in IdentityQueryEvents: Yes

IdentityQueryEvents entry of Domain Admins group query

Listing of all Service Principal Names (SPN)

The following query lists all accounts with ServicePrincipalNames configured and uses the ComparisonOperator obfuscation:

MDI alert triggered: No
Data in IdentityQueryEvents: No

List users

The following query gets all User accounts which were created after a specific date and uses oid notation with prefixed zeroes:

MDI alert triggered: No
Data in IdentityQueryEvents: No

Enumeration using the ldapsearch BOF

Next, some LDAP enumeration was done via a C2 beacon on our Windows 11 machine. As mentioned earlier, MDE was enabled on this system with a P2 license.

Get information about specific user

The following query lists a user’s details by the given samaccountname:

MDI alert triggered: No
Data in IdentityQueryEvents: No

Listing of all enabled users

The following query lists all enabled users:

MDI alert triggered: No
Data in IdentityQueryEvents: Yes

IdentityQueryEvents entry of the query which lists all enabled users

Querying all enabled Users (with basic LDAP obfuscation)

The following query lists all enabled users and uses ComparisonOperator obfuscation:

MDI alert triggered: No
Data in IdentityQueryEvents: No

Querying the Domain

The following query lists the domain object:

MDI alert triggered: No
Data in IdentityQueryEvents: Yes

IdentityQueryEvents entry of the query which lists the domain object

Querying the Domain (with basic obfuscation)

The following query lists the domain object and uses logical AND and NOT operator:

MDI alert triggered: No
Data in IdentityQueryEvents: No

Listing all computers (using OID)

The following query lists all computers and uses the OID number instead of the object name:

MDI alert triggered: No
Data in IdentityQueryEvents: Yes

IdentityQueryEvents entry of the query which lists all computers

Listing all Computers (with basic obfuscation)

The following query lists all computers and uses HEX encoding and the OR operator for basic obfuscation:

MDI alert triggered: No
Data in IdentityQueryEvents: Yes

IdentityQueryEvents entry of the query which lists all computers

Listing all computers (with more obfuscation)

The following query lists all computers and combines HEX encoding, AND, OR and NOT operators, OID and ComparisonOperator for obfuscation:

MDI alert triggered: No
Data in IdentityQueryEvents: No

Enumerating LDAP via Excel OleDB

In Microsoft Excel, you can use the OleDB provider to connect to LDAP and query data directly from Active Directory. To set this up, open a new Excel workbook and navigate to the Data tab. From there, select:

Get Data → From Other Sources → Blank Query

This opens the Power Query editor, where you can define and run LDAP queries using OleDB connection strings.

Listing all users

The following query lists all users:

The resulting list in Excel:

Excel containing list of all AD users

MDI alert triggered: No
Data in IdentityQueryEvents: Yes

IdentityQueryEvents entry for the OleDB query listing users

List all groups with Basic Obfuscation

The following query lists all groups and uses HEX encoding for basic obfuscation:

MDI alert triggered: No
Data in IdentityQueryEvents: Yes

List Domain Admins with Basic Obfuscation

The following query lists the members of the Domain Admins group and uses HEX encoding for basic obfuscation:

MDI alert triggered: No
Data in IdentityQueryEvents: No

Limiting Results

In larger environments, it’s often advisable to limit the amount of data returned from LDAP queries to avoid generating excessive or suspicious telemetry that could trigger detection mechanisms.

This can be achieved in some tools through paging, if supported. Alternatively, you can control the query scope manually by crafting more specific LDAP filters. For instance, using the ComparisonOperator allows you to apply conditions that narrow down results – such as querying only for objects modified after a certain date, or filtering based on a specific attribute value.

Example 1

One way to achieve this is  to e.g. get all users with samAccountName starting with the letter A:

You can use the >= and <= operators to define a range in your LDAP filter. Since the letter “z” is at the end of the ASCII sort order, appending several “z” characters (e.g., zzzzzz) to the upper bound can help ensure that entries like “Azz…” are also included in the result set.

Example 2

Adding Custom Detection Rules (Defender for Identity)

When analyzing the MDI-related tables in the Advanced Hunting section of the Microsoft Defender portal, it’s possible to create custom detections that cover LDAP queries which do not trigger built-in MDI alerts.

To determine whether MDI has logged evidence of a specific LDAP query, I typically use the following Kusto Query Language (KQL) query:

The Advanced Hunting interface also includes a convenient “Create detection rule” button, which allows you to directly convert your KQL query into a custom detection rule.

Detecting LDAP Enumeration with Defender for Endpoint

Microsoft Defender for Endpoint (MDE) can also be leveraged to create custom detections based on LDAP activity. For example, the following KQL query retrieves all LDAP queries executed within the last 12 hours:

References: