RelayLDAP

Read the companion write-up, When SOCKS Is Not Enough: Reusing Retained LDAPS Relay Sessions, for the protocol details and compatibility testing behind RelayLDAP.

What it does

RelayLDAP reuses LDAP and LDAPS sessions held by Impacket’s ntlmrelayx SOCKS server. It can discover compatible relays from the local relay API, select the retained identity, complete the expected NTLM Sicily bind through proxychains4, and expose a guided operations menu. It also supports direct NTLM authentication when a normal LDAP client is more useful.

Why it exists

Keeping a relay alive is only useful if I can work with it reliably. RelayLDAP puts discovery, bind setup, common directory reads, deliberate writes, and evidence capture into one client instead of leaving the workflow spread across one-off commands.

Operations

Read operations cover identities, groups, computers, delegation, SPN and AS-REP candidates, LAPS, gMSA, policy, and targeted LDAP searches. Write operations include account, password, group-membership, computer, and attribute changes.

Every write displays the intended change and requires a typed confirmation. Broad and credential-sensitive reads are labeled before they run.

Evidence handling

Activity and result logs are written as permission-restricted JSONL. Passwords used for binds or account changes are redacted from those logs, but directory results may still contain passwords, managed-password blobs, paths, membership, or other sensitive data.

Limitations

• Relay mode requires a matching active LDAP or LDAPS session in ntlmrelayx.
• The broader operation set has not been validated across every directory and Impacket version.
• Direct LDAPS mode does not yet validate server certificates for IP-addressed targets.
• Read-only activity can still be logged, detected, or expensive on a large directory.
• Confirmations reduce accidental writes but do not make a change safe or reversible.