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:

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

(&(ui