Bypassing LDAP Detection: How Obfuscation Breaks Your SIEM

TLDR: LDAP search filters are the backbone of Active Directory reconnaissance, yet most detection rules rely on fragile, string-based matching that is trivial to bypass. By leveraging undocumented behaviors in LDAP filter parsing—such as OID notation, bitwise flag manipulation, and logical inversion—attackers can hide malicious queries from standard EDR and SIEM alerts. The newly released MalDAPtive framework provides a robust parser and detection engine to help researchers and defenders identify these evasive techniques in real-time.

Active Directory remains the primary target for lateral movement and privilege escalation in almost every enterprise environment. When we run red team engagements, the first thing we do is query the domain for interesting objects: users with specific group memberships, machines with unconstrained delegation, or accounts that haven't changed their passwords in years. We do this via LDAP search filters. Defenders know this, so they write detection rules to flag common patterns like (samAccountName=*) or queries targeting the krbtgt account.

The problem is that these detection rules are almost universally built on simple string matching. If a rule looks for a specific string, it assumes the attacker is going to send that string exactly as written. But LDAP is a protocol with a surprisingly flexible and complex grammar. If you understand how the server parses that grammar, you can rewrite your queries to look like complete garbage while remaining perfectly functional to the domain controller.

The Mechanics of LDAP Evasion

LDAP search filters are defined by RFC 4511 and RFC 1558. At their core, they are just a series of tokens: group starts, attributes, comparison operators, values, and group ends. Most security tools treat these as static blobs of text. However, the protocol allows for multiple ways to represent the same data.

Take the attribute name. You can query it by name, but you can also query it using its OID (Object Identifier). If you want to find a user named "Sabi," you don't have to write (name=Sabi). You can use the OID for the name attribute, and because the parser is case-insensitive and ignores certain formatting, you can inject leading zeros or even use Ambiguous Name Resolution (ANR) to force the server to do the heavy lifting of matching your query against multiple attributes simultaneously.

The most effective evasion technique involves bitwise operations. Many security attributes, like userAccountControl, are bitmasks. If you want to find enabled accounts, you might look for a specific flag. Attackers can break these bitwise flags into smaller, logically equivalent chunks using AND and OR operators. By splitting a single query into a complex tree of nested filters, you render simple regex-based detection rules useless. The SIEM is looking for a specific pattern, but the attacker is sending a mathematically equivalent, structurally unique query that the SIEM doesn't recognize.

Why Your Current Detection Rules Fail

During our research, we found that even the most common tools used for AD enumeration—like PowerView or BloodHound—often generate queries that are easily flagged because they follow predictable patterns. However, once you move away from these standard tools and start crafting custom LDAP queries, you enter a space where most blue teams have zero visibility.

The MalDAPtive framework was built to address this gap. It includes a custom C# state machine parser that doesn't just look for strings; it tokenizes the entire LDAP query into a syntax tree. This allows it to understand the logical structure of the request regardless of how it is obfuscated. Whether an attacker uses hex encoding, prepended zeros, or complex double-negation via De Morgan’s laws, the parser reconstructs the intent of the query.

For example, consider the use of the NOT operator. In LDAP, NOT is a boolean operator that can be applied to a filter. If you apply it twice, you get the original filter back. If you apply it to a complex AND filter, you can use De Morgan’s laws to flip the logic entirely. A detection rule looking for (A & B) will miss (!(!A | !B)), even though they are functionally identical. Our parser handles these transformations, allowing us to write detection rules based on the behavior of the query rather than its syntax.

Practical Application for Pentesters

If you are performing a penetration test, you should be testing your client's detection capabilities against these techniques. Don't just run standard enumeration scripts. Use the MalDAPtive tool to take your standard queries and apply different layers of obfuscation. See if the client's SIEM alerts on the raw query but stays silent when you add a few layers of hex encoding or redundant boolean logic.

This isn't just about bypassing alerts; it's about understanding the limitations of the monitoring stack. If you can successfully enumerate the entire domain without triggering a single alert, you have identified a critical blind spot in the client's security operations. When you report this, don't just say "we bypassed detection." Show them the raw LDAP traffic, show them the obfuscated query, and explain that their detection rules are looking for the wrong thing.

Defenders need to move away from string-based matching and toward protocol-aware parsing. If your SIEM isn't parsing the LDAP traffic at the protocol level, you are essentially blind to any attacker who has read the RFCs. Start by auditing your current ruleset against the obfuscation techniques demonstrated in the MalDAPtive project. If your rules are just a list of strings, it is time to rewrite them. The goal is to detect the intent of the query, not the specific characters used to express it.