hunt-ldap – Other skill for AI agents

> ⚠️ AUTHORIZED USE ONLY

> This skill is for educational purposes or authorized security assessments only.

> You must have explicit, written permission from the system owner before using this tool.

> Misuse of this tool is illegal and strictly prohibited.

> Mandatory confirmation gate

> Before running any command that probes, exploits, changes, persists on, extracts data from, or attempts credential access against a target:

> 1. Ask the user to state the exact target URL, IP, account, or resource.

> 2. Ask the user to confirm written authorization and the permitted scope.

> 3. Show the exact command(s) and explain their expected effect.

> 4. Wait for explicit confirmation in the current conversation.

>

> Without that confirmation, remain read-only and provide defensive guidance only. Prefer a sandbox, disposable VM, or controlled lab.

HUNT-LDAP — LDAP Injection & XPath Injection

> Grounding note: LDAP injection is rarely disclosed with verbatim payloads on

> public platforms (most live on internal-pentest reports). This skill is

> grounded in the **OWASP LDAP Injection Prevention / Testing Guide

> (WSTG-INPV-06), PortSwigger Web Security Academy (LDAP injection)**, and

> the RFC 4515 filter grammar — all publicly verifiable references rather

> than invented HackerOne IDs. Do not cite a report you cannot link.

Crown Jewel Targets

LDAP injection that bypasses authentication = Critical. Blind attribute

exfiltration of credentials/secrets = High. AD enumeration alone = Medium-High.

Highest-value chains:

• LDAP auth bypass — close the uid filter and append an always-true OR so the

bind/search returns the admin entry without a valid password.

• Blind attribute exfil — char-by-char extraction of an attribute value via a

boolean oracle (login success/failure, result count, or response length).

• userPassword hash exfil (non-AD only) — on OpenLDAP/389-DS the

userPassword attribute can hold {SSHA}/{CRYPT} hashes that ARE readable

by query. See the AD-vs-generic warning below.

• XPath injection auth bypass — ' or '1'='1 against XML-backed auth.

---

CRITICAL — Active Directory vs generic LDAP

Do not conflate the two. They behave very differently:

| | Generic LDAP (OpenLDAP, 389-DS, ApacheDS) | Active Directory |

|---|---|---|

| Password attribute | userPassword — may hold {SSHA}/{MD5}/{CRYPT} and is readable if ACL allows | unicodePwd — write-only, never returned by any search |

| Hash exfil via injection | Possible where ACLs leak userPassword | Not possible — there is no readable hash attribute over LDAP |

| Useful enum attrs | uid, cn, mail, userPassword | sAMAccountName, userPrincipalName, mail, memberOf, description (often holds plaintext secrets!) |

**Do not tell a reader that blind LDAP injection yields AD password hashes — it

does not.** unicodePwd is write-only. Against AD, the win is enumeration

(sAMAccountName, memberOf, description/info fields that admins misuse to

store passwords) and auth bypass — not hash dumping. The hash-exfil technique

applies only to non-AD directories exposing userPassword.

---

Attack Surface Signals

Corporate SSO / intranet login pages (often legacy Java/Spring/PHP)
Windows + IIS + "integrated" directory auth
/api/ldap/*  /api/directory/*  /people  /address-book  /search?dir=
"Find a colleague" / org-chart / employee-search features
XML-backed config or auth → XPath injection candidate
Error strings that confirm an LDAP backend:
  javax.naming.NameNotFoundException
  javax.naming.directory.InvalidSearchFilterException
  LDAP: error code 49 - 80090308  (AD invalid creds / bind failure)
  com.sun.jndi.ldap.*  /  System.DirectoryServices  /  ldap_search():
  "Bad search filter"  /  net.ldap (Go)  /  python-ldap SERVER_DOWN

---

LDAP filter grammar (RFC 4515) — why injection works

A login filter is typically built by string-concat:

(&(uid=<USERNAME>)(userPassword=<PASSWORD>))

& = AND, | = OR, ! = NOT. Filters are prefix/Polish notation — the

operator comes first and every sub-filter is parenthesised. To inject you must

(a) escape the current (uid=...) group, (b) inject your own logic, and

(c) leave the overall parenthesis count balanced or the server throws a

filter-syntax error instead of executing.

The special-character set — TEST EACH ONE

These characters are syntactically meaningful and MUST be escaped by a safe app

(RFC 4515 §3). A different response can suggest parser involvement but does not prove unescaped input or exploitability:

| Char | Filter escape | Why it matters |

|------|---------------|----------------|

| * | \2a | wildcard — matches any value |

| ( | \28 | opens a filter group |

| ) | \29 | closes a filter group |

| \ | \5c | escape char itself |

| NUL | \00 | string terminator — truncates filter in C-backed servers |

| , | DN-context escaping | RDN separator; DN encoding differs from filter encoding |

Search-filter context vs DN injection are different bugs:

• Search-filter injection (most common): your input lands inside a

(attr=VALUE) filter. Payloads use * ( ) & | !.

• DN injection: your input is concatenated into a Distinguished Name

(uid=VALUE,ou=people,dc=corp). Here , = + " \ < > ; and leading/trailing spaces

matter, and a * is NOT a wildcard. Test both — the payloads do not transfer.

---

Step-by-Step Hunting Methodology

Phase 1 — Confirm an LDAP backend (baseline first)

# ALWAYS capture a control response first — you compare everything to this.
BASE=$(curl -s -o /dev/null -w "%{http_code}|%{size_download}|%{time_total}" \
  -X POST https://$TARGET/api/login \
  -H "Content-Type: application/json" \
  -d '{"username":"validlookinguser","password":"wrongpass"}')
echo "BASELINE (valid-format, wrong pw): $BASE"

# Send a single unbalanced paren. A SAFE (escaping) app → identical baseline.
# An INJECTABLE app → 500 / filter-syntax error / different size.
curl -s -X POST https://$TARGET/api/login \
  -H "Content-Type: application/json" \
  -d '{"username":"test)","password":"x"}' | grep -iE \
  "naming|InvalidSearchFilter|error code 49|Bad search filter|jndi|ldap_search"

A lone ) that produces a syntax error/500 while a balanced payload does not is

the cleanest LDAP-injection tell — note it, you will need it as proof.

Phase 2 — Derive a controlled test from the actual expression

Do not copy a universal login payload. Record the full resulting filter, its

parentheses and the actual bind/search flow; LDAP filters have no SQL-style

comment syntax. A filter selecting a user does not itself authenticate a password.

In a local fixture where the complete predicate is (uid=INPUT), * changes the

expression to (uid=*) and tests presence rather than a literal star. Compare

that with the correctly escaped literal (uid=\2a) and a nonexistent synthetic

UID. In a real nested AND filter, those results do not establish password bypass.

Use paired true/false controls on a public synthetic attribute and controlled

accounts, not a production credential value. Bound the requests, rate and runtime;

stop on lockout, elevated errors or unexpected personal data. Never expand to

password spraying, hash cracking or real attribute extraction without separately

scoped authorization and the exact command gate above.

Phase 3 — XPath and evidence

For a known XPath 1.0 expression using a quoted string, a quote may alter syntax;

construct the entire predicate and verify precedence, quoting and selected nodes

in a disposable local XML fixture. Prefer variable binding in the application's

XPath API to concatenation. Error messages or response length alone do not prove

successful authentication or data access. Use a controlled test session and a

post-login resource only within scope; do not print cookies or account records.

Phase 4 — Direct LDAP confirmation and remediation

If direct directory access is authorized, use certificate-verified LDAPS or

required StartTLS and prompt-based credentials (ldapsearch -W) rather than a

password in command arguments. Restrict requested attributes and search base.

Use the library's distinct filter-value and DN escaping APIs, least-privilege

bind accounts and proper bind authentication; reject empty passwords where the

application requires authentication. A referral-like filter attribute is not a

standard instruction to follow a URL. OOB callbacks require correlation and

controls and cannot automatically prove LDAP injection or exclude scanner noise.

Primary references: [RFC 4515](https://www.rfc-editor.org/rfc/rfc4515),

[OWASP prevention](https://cheatsheetseries.owasp.org/cheatsheets/LDAP_Injection_Prevention_Cheat_Sheet.html).

Chain Table

| LDAP finding | Chain to | Impact |

|--------------|----------|--------|

| Auth-bypass (always-true filter) | Admin/SSO pane

… (full content is in the download package)