MaLDAPtive: Diving Deep Into LDAP Obfuscation, Deobfuscation & Detection

MaLDAPtive: Diving Deep Into LDAP Obfuscation, Deobfuscation & Detection

Speakers: Daniel Bohen, Principal Threat Researcher at Permiso Security; Sabata, Senior Cyber Security Engineer at Solaris

Conference: Black Hat USA

YouTube: https://www.youtube.com/watch?v=3HrGoSPT8cU

Overview

This talk, "MaLDAPtive," delivered by Daniel Bohen (Divo) and Sabata (Sabi), delves into the often-overlooked realm of LDAP search request obfuscation, deobfuscation, and detection within Active Directory environments. Daniel Bohen, a Principal Threat Researcher at Permiso Security with a history of endpoint research at Microsoft and a self-professed "obsession" with obfuscation, teams up with Sabata, a Senior Cyber Security Engineer at Solaris specializing in cyber defense, detection engineering, and incident response. The presentation aims to shed light on how attackers can leverage LDAP's flexible nature to evade detection and, crucially, how defenders can counter these techniques.

The core problem addressed is the current asymmetry in visibility for defenders when it comes to LDAP queries, particularly in production environments. While offensive tools like PowerView and BloodHound extensively use LDAP for Active Directory reconnaissance, defensive capabilities often lag, making it challenging to identify malicious activity. The speakers emphasize the critical distinction between client-side and server-side LDAP logging, highlighting how obfuscation can appear differently in each, and introduce their open-source framework, MaLDAPtive, designed to empower defenders.

Background

▶ Watch: Introduction of speakers and talk agenda overview (0:00)

The journey into LDAP's intricacies begins with a historical overview, tracing its roots back to the 1980s with the Directory Access Protocol (DAP). LDAP emerged in the 1990s as a "lightweight" version of DAP, gaining significant traction with the release of OpenLDAP in 1998. A pivotal moment for enterprise security came in 2000 when Microsoft introduced Active Directory (AD), which rapidly became the world's largest directory service. Active Directory functions as the server-side component, housing crucial organizational information, while LDAP serves as the protocol through which client-side applications interact with and extract data from AD.

In the past decade, the cybersecurity landscape has seen a proliferation of open-source tools that leverage LDAP search requests to query Active Directory. Tools such as PowerView, BloodHound, and Pincast have become indispensable for both offensive operations (e.g., reconnaissance, privilege escalation path mapping) and, paradoxically, defensive purposes (e.g., understanding attack surfaces, validating detections). However, the widespread availability and utility of these tools pose a significant challenge for defenders: how to effectively detect their malicious use when attackers actively seek to obfuscate their activities.

The speakers highlight a frustrating reality for defenders: achieving comprehensive visibility into LDAP search requests in production environments remains difficult. While lab environments might offer more control (e.g., using tools like SilkyTW from Ruben), options for real-world detection are limited. Microsoft Defender is acknowledged as a prominent example offering both client-side and server-side visibility. This lack of robust, widespread visibility creates an "attacker's heaven" where malicious LDAP queries can often go unnoticed, underscoring the necessity for enhanced detection capabilities and a deeper understanding of LDAP's underlying mechanisms.

Key Findings

▶ Watch: Challenges for defenders: Client vs. server-side logging visibility (2:00)

The talk reveals several critical insights into LDAP search requests and their defensive implications, primarily stemming from the stark differences in how these requests are processed and logged on the client versus server side.

Firstly, a fundamental discovery emphasized by the speakers is the asymmetry between client-side and server-side logging of LDAP search requests. On the client side, particularly when applications utilize the wldap32.dll mechanism, the logging is largely WYSYWYG (What You See Is What You Get). This means any obfuscation applied to an LDAP filter will appear precisely as obfuscated in the client-side logs. This characteristic, while seemingly straightforward, creates an "attacker's heaven" where sophisticated obfuscation techniques can easily bypass client-side detection mechanisms that rely on signature matching against cleartext queries.

A significant implication of this client-side behavior was the discovery by Falcon Force, leading to the development of SoapHound. This tool demonstrates how attackers can bypass client-side logs altogether by issuing SOAP requests instead of relying on the wldap32.dll mechanism for LDAP interactions. This highlights a critical blind spot for defenders who solely focus on client-side telemetry.

In contrast, server-side logs present a different challenge and opportunity. The speakers note that Active Directory's server-side processing involves considerable normalization of LDAP search requests. This normalization can sometimes lead to "weird undocumented expansions" and, in certain cases, even produce "technically invalid search filters" in the logs. While normalization might simplify some queries, it also means that the original, potentially obfuscated, client-side query might look significantly different on the server. This distinction is crucial: defenders need to understand both perspectives to build resilient detection strategies. The talk stresses that both data sources – client-side and server-side logs – are "really important" for a comprehensive security posture.

The speakers also unveil their extensive research effort, having invested "over 2,000 hours of R&D" into understanding LDAP parsing, obfuscation, deobfuscation, and detection. This monumental effort culminates in the development and planned release of MaLDAPtive, an open-source framework designed to address these challenges. The name "MaLDAPtive" itself suggests a core finding: contrary to the common perception of LDAP as a rigid and inflexible protocol, the research demonstrates its inherent "adaptive" qualities, particularly in how queries can be manipulated and interpreted, which attackers can exploit.

Finally, the talk establishes the LDAP filter as the primary target for obfuscation, given its widespread use by defenders for detection purposes. However, it also identifies base object and attribute selection as secondary and tertiary focuses for obfuscation, indicating a holistic approach to understanding and countering evasion techniques across various components of an LDAP search request, as defined by RFC 4511.

Technical Deep Dive

▶ Watch: Bypassing client-side logs with SoapHound and server logs (2:40)

The technical deep dive into LDAP search requests centers around RFC 4511, the foundational standard governing the LDAP protocol. The speakers break down an LDAP search request into four fundamental components, emphasizing their relevance to both query functionality and potential for obfuscation:

1. Base Object: This specifies the starting point within the Active Directory hierarchy for the search. It defines the root of the subtree or the specific object from which the LDAP client wishes to retrieve information. Obfuscating the base object could involve using different naming conventions or relative paths to obscure the true target of a query.
2. Scope: The scope dictates how far the search should extend from the base object. Common scopes include:

• Base: Searches only the base object itself.
• One-level: Searches the base object and its immediate children.
• Subtree: Searches the base object and all objects within its subtree.

Manipulating the scope could allow an attacker to target specific, less-monitored areas of the directory or to perform broader reconnaissance while attempting to appear innocuous.

1. Filter: This is arguably the most critical component for both querying and obfuscation. The filter defines the criteria that objects must meet to be returned by the search. It acts as a logical expression, combining attributes, values, and operators to precisely select desired entries. Given its central role in defining what data is retrieved, the filter is the primary focus for obfuscation techniques, as it's also the most frequently used component by defenders for detection.
2. Attribute Selection: This specifies which properties or attributes of the matching objects should be returned in the search results. Instead of returning all attributes, clients can request specific ones (e.g., sAMAccountName, memberOf, adminCount). Obfuscating attribute selection might involve requesting common, benign attributes while implicitly targeting sensitive ones through other means, or using less common attribute names if the directory supports aliases.

The speakers elaborate on the structure of the LDAP filter itself, which is typically enclosed within parentheses and follows a specific syntax. It comprises five required tokens:

• Group Start ((): Marks the beginning of a filter group.
• Group End ()): Marks the end of a filter group.
• Attribute: The specific LDAP attribute being queried (e.g., objectClass, sAMAccountName, userAccountControl).
• Value: The value associated with the attribute that the search is looking for (e.g., user, admin, 512).
• Comparison Operator: Specifies the relationship between the attribute and its value (e.g., =, ~=, >=, <=, *). For instance, (objectClass=user) searches for objects whose objectClass attribute is "user".

Beyond these required tokens, filters can also incorporate two operational tokens that add significant flexibility and complexity, making them ripe for obfuscation:

• Boolean Operator: These operators combine multiple filter conditions. The primary Boolean operators are:
• & (AND): All conditions must be true. Example: (&(objectClass=user)(sAMAccountName=admin*))
• | (OR): At least one condition must be true. Example: (|(objectClass=group)(objectClass=user))
• ! (NOT): Negates a condition. Example: (!(objectClass=computer))

The nesting and combination of these operators allow for highly complex and potentially obfuscated queries.

• Extensible Match Filter: These filters provide advanced matching capabilities beyond simple equality or substring comparisons. They are characterized by bitwise values that have different meanings depending on the specific attribute being queried. Microsoft provides extensive documentation for these values. An example provided in the talk is userAccountControl:1.2.840.113556.1.4.803:=2, which effectively means "object is not disabled." The 1.2.840.113556.1.4.803 is an LDAP_MATCHING_RULE_BIT_AND OID, used to test if specific bits are set or unset in a bitmask attribute like userAccountControl. This level of detail and the use of OIDs and bitwise operations offer substantial opportunities for attackers to construct highly specific and less common queries that might evade simpler signature-based detections.

The detailed breakdown of these components underscores that LDAP's structure, while standardized, offers numerous avenues for manipulation. The speakers' emphasis on the filter as the primary obfuscation target, followed by the base object and attribute selection, indicates that a comprehensive detection strategy must account for potential evasion techniques across all parts of an LDAP search request.

Demo / Proof of Concept

▶ Watch: Anatomy of an LDAP search request and its components (3:48)

The speakers announced their intention to demo and release MaLDAPtive, an open-source framework developed over 2,000 hours of R&D. This framework is described as a comprehensive tool for "all things LDAP," encompassing parsing, obfuscation, deobfuscation, and detection. While the transcript clearly states the intent to demo and release MaLDAPtive at the end of the presentation, the provided unique transcript content concludes before any details of the demonstration or the framework's specific functionalities are described. Therefore, the specific workings of the demo and the capabilities of MaLDAPtive are not detailed within this segment of the talk.

Defensive Implications

▶ Watch: Deep dive into LDAP filter tokens and operators (4:20)

The insights shared in "MaLDAPtive" carry significant implications for cybersecurity defenders grappling with the challenge of detecting malicious activity within Active Directory environments. The core problem identified is the current asymmetry in visibility that favors attackers. While offensive tools like PowerView and BloodHound routinely leverage LDAP search requests for reconnaissance and privilege escalation, defenders often struggle with limited and inconsistent logging, especially in production environments.

A primary defensive implication stems from the crucial distinction between client-side and server-side LDAP logging:

1. Client-Side Log Blind Spots: Defenders relying solely on client-side logs (e.g., those generated via wldap32.dll) are vulnerable. The "WYSYWYG" nature of these logs means that sophisticated obfuscation techniques applied by attackers will appear obfuscated in the logs, making direct signature-based detection difficult. Furthermore, the discovery by Falcon Force regarding SoapHound highlights that attackers can completely bypass these client-side logs by using SOAP requests instead of standard LDAP calls. This necessitates that defenders broaden their telemetry collection beyond traditional client-side LDAP events. Endpoint detection and response (EDR) solutions must evolve to detect such bypasses or alternative communication methods.
2. Server-Side Log Complexities: While server-side logs offer a different perspective, they introduce their own set of challenges. The normalization, "undocumented expansions," and potential for "technically invalid search filters" on the server side mean that a direct correlation between a client-side obfuscated query and its server-side representation might not be straightforward. Defenders need to understand the Active Directory's LDAP server processing logic to accurately interpret these logs. This calls for advanced analytics that can deobfuscate client-side queries and correlate them with their server-side normalized counterparts, or at least identify suspicious patterns in the normalized output.
3. Need for Comprehensive Visibility: The talk strongly advocates for the importance of both client-side and server-side data sources. A holistic defense strategy requires collecting and analyzing telemetry from multiple points. This might involve enhancing Active Directory diagnostic logging, leveraging domain controller event logs, and integrating with network-level monitoring to capture LDAP traffic.
4. Targeting Obfuscation: By identifying the LDAP filter as the primary target for obfuscation, and the base object and attribute selection as secondary targets, the talk provides a roadmap for detection engineers. Defenders should focus on developing robust detection logic that can parse, normalize, and deobfuscate these components. This involves understanding the various tokens (group start/end, attribute, value, comparison operators) and operational tokens (Boolean operators, extensible match filters with bitwise values and OIDs) discussed in the technical deep dive. Generic regex patterns are unlikely to be sufficient; a more intelligent, parser-driven approach is required.
5. Leveraging Open-Source Tools: The planned release of MaLDAPtive as an open-source framework is a direct and impactful defensive implication. Defenders will gain a tool specifically designed to aid in parsing, deobfuscation, and detection of LDAP queries. This framework could serve as a vital resource for threat hunters, incident responders, and detection engineers to analyze suspicious LDAP traffic, build better detections, and understand attacker techniques. Its availability promises to reduce the "2,000 hours of R&D" burden on individual security teams.
6. Proactive Threat Hunting: Given the complexities of LDAP obfuscation, defenders should proactively hunt for anomalous LDAP search requests rather than relying solely on reactive alerts. This includes looking for unusual attribute combinations, rarely used extensible match filters, queries targeting sensitive objects with broad scopes, or sudden spikes in LDAP query volume from unusual sources.

In essence, the talk serves as a call to action for defenders to move beyond superficial logging and embrace a deeper, more analytical understanding of how LDAP queries are constructed, processed, and potentially manipulated. It highlights the necessity for advanced parsing, deobfuscation, and correlation capabilities to effectively counter sophisticated adversaries in Active Directory environments.

Key Takeaways

• LDAP Obfuscation is a Significant Threat: Attackers actively use LDAP obfuscation to evade detection, exploiting the protocol's flexibility and the inconsistencies in client-side versus server-side logging.
• Client-Side vs. Server-Side Logging Matters: Client-side logs are "WYSYWYG" but can be bypassed (e.g., via SOAP requests like SoapHound), while server-side logs involve normalization and undocumented expansions, making both critical but challenging to interpret.
• Comprehensive Visibility is Essential: Defenders need to collect and analyze LDAP search request data from both client and server perspectives to achieve a holistic understanding of activity.
• LDAP Filters are Key Obfuscation Targets: The structure of LDAP filters, including Boolean operators and extensible match filters with bitwise values, offers numerous avenues for attackers to hide their intent.
• MaLDAPtive Framework for Defenders: The upcoming open-source framework, MaLDAPtive, aims to provide tools for parsing, obfuscation, deobfuscation, and detection of LDAP search requests, empowering defenders.
• Proactive Detection Engineering is Required: Relying on simple signature-based detections for LDAP queries is insufficient. Defenders must adopt advanced parsing and deobfuscation techniques to build resilient detections and conduct effective threat hunting.

About the Speaker(s)

Daniel Bohen (Divo) is a Principal Threat Researcher at Permiso Security, a cloud and identity startup focused on detection and response. With approximately seven to eight years of experience in endpoint research at Microsoft, Daniel brings a deep understanding of system internals and security mechanisms. He describes himself as having an "obsession" with obfuscation, a passion evident in his past projects and the extensive research undertaken for MaLDAPtive. Beyond his professional pursuits, Daniel also enjoys coffee, books, and the conversations they inspire.

Sabata (Sabi) is a Senior Cyber Security Engineer at Solaris, based in Berlin, having recently moved from Albania. Her professional focus lies in cyber defense, encompassing detection engineering, incident response, and threat hunting. Sabata's background includes experience in consulting and governmental security roles, providing her with a broad perspective on cybersecurity challenges. In her free time, she appreciates a nice mountain view, good movies, and a good espresso.