Fails to Forward Requests via SOCKS5 Proxy — “Can't contact LDAP server” Error

[camlischke1]

I'm running LDAPx locally attempting to forward LDAP queries to a domain controller via a SOCKS5 proxy. The SOCKS proxy is listening on 127.0.0.1:30006 and tunnels traffic through an SSH connection to a machine which can reach the target domain controller.

Here's how I run LDAPx:

> ldapx -t 172.31.79.105 -l :11389 -F 5 -R 5 -N --socks socks5://127.0.0.1:30006
2025/09/23 15:58:05 [+] LDAP Proxy listening on ':11389', forwarding to '172.31.79.105:389' (T) via 'socks5://127.0.0.1:30006'
2025/09/23 15:58:05 [+] BaseDNMiddlewares: []
2025/09/23 15:58:05 [+] FilterMiddlewares: []
2025/09/23 15:58:05 [+] AttrListMiddlewares: []
2025/09/23 15:58:05 [+] AttrEntriesMiddlewares: []

2025/09/23 15:58:12 Failed to connect to target LDAP server: server does not respond properly

And here's a sample search query routed through the LDAPx server running on port 11389

> ldapsearch -H ldap://127.0.0.1:11389 -x -D "CN=Administrator,CN=Users,DC=cam,DC=com" -W -b "CN=Users,DC=cam,DC=com" -d 5
ldap_url_parse_ext(ldap://127.0.0.1:11389)
ldap_create
ldap_url_parse_ext(ldap://127.0.0.1:11389/??base)
Enter LDAP Password: 
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP 127.0.0.1:11389
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying 127.0.0.1:11389
ldap_pvt_connect: fd: 3 tm: -1 async: 0
attempting to connect: 
connect success
ldap_open_defconn: successful
ldap_send_server_request
ber_scanf fmt ({it) ber:
ber_scanf fmt ({i) ber:
ber_flush2: 85 bytes to sd 3
ldap_result ld 0x5a84a12afb90 msgid 1
wait4msg ld 0x5a84a12afb90 msgid 1 (infinite timeout)
wait4msg continue ld 0x5a84a12afb90 msgid 1 all 1
** ld 0x5a84a12afb90 Connections:
* host: 127.0.0.1  port: 11389  (default)
* from: IP=127.0.0.1:49524
  refcnt: 2  status: Connected
  last used: Tue Sep 23 15:58:12 2025


** ld 0x5a84a12afb90 Outstanding Requests:
 * msgid 1,  origid 1, status InProgress
   outstanding referrals 0, parent count 0
  ld 0x5a84a12afb90 request count 1 (abandoned 0)
** ld 0x5a84a12afb90 Response Queue:
   Empty
  ld 0x5a84a12afb90 response count 0
ldap_chkResponseList ld 0x5a84a12afb90 msgid 1 all 1
ldap_chkResponseList returns ld 0x5a84a12afb90 NULL
ldap_int_select
read1msg: ld 0x5a84a12afb90 msgid 1 all 1
ber_get_next
ldap_err2string
ldap_result: Can't contact LDAP server (-1)
ldap_do_free_request: asked to free lr 0x5a84a12b0180 msgid 1 refcnt 0
ldap_free_connection 1 1
ldap_free_connection: actually freed

When I don't use LDAPx at all and instead configure proxychains paired with the above ldapsearch query, works fine.

When I try to use proxychains with ldapx instead of the native --socks option, the connection times out.

What I’ve Tried:

• Verified that the SOCKS proxy is reachable and working.
• Verified that bypassing ldapx completely and just using proxychains ldapsearch query works fine.
• Confirmed that the LDAP proxy is listening and accepting connections.
• Tried both "127.0.0.1:30006" and "socks5://127.0.0.1:30006" as the socksServer string.
• Ensured that the domain controller supports plain LDAP on port 389 (not LDAPS).

[camlischke1]

I've identified a likely issue with how the h12w/socks library handles SOCKS5 connections when the remote target resolves to an IPv6 address.

Observations
When using proxychains directly to issue the LDAP request through a SOCKS5 proxy (without ldapx), the packet flow includes:

• A pair of authentication packets
• A successful negotiation with an IPv4 remote host

When using ldapx, which relies on h12w/socks, the final negotiation packet attempts to use an IPv6 address. This results in an immediate connection reset.

Root Cause
The issue appears to stem from the SOCKS5 implementation in socks5.go, which does not appear to properly handle IPv6 addresses during the connection negotiation phase.

Here’s the relevant snippet:
https://github.com/h12w/socks/blob/dbaf06c866e76870148c86a518d3495b9c6b6afc/socks5.go#L60

func (cfg *config) dialSocks5(targetAddr string) (_ net.Conn, err error) {
    .
    .
   .
    .
        resp, err := cfg.sendReceive(conn, req.Bytes())
        if err != nil {
            return nil, err
        } else if len(resp) != 2 {
            return nil, errors.New("server does not respond properly")
        } else if resp[0] != version {
            return nil, errors.New("server does not support user/password version 1")
        } else if resp[1] != 0 {
            return nil, errors.New("user/password login failed")
        }
    }
}

Disabling IPv6 in the target environment is not an option, so SOCKS5 support for IPv6 is required.

Looks like the only way to go is to refactor this to use a different library to handle SOCKS that can use ipv6. Happy to help test or contribute a patch if needed.

[camlischke1]

Coded up a quick fix here https://github.com/camlischke1/ldapx

Known Issues with Forked Version

• The forked version only supports SOCKS5.
  • You must provide the SOCKS5 server address via the --socks argument (ie --socks 127.0.0.1:30006. NOTICE: there is no socks4a:// prepended as this tool only expects socks5 addresses.
  • If you need to use a different SOCKS protocol, use the original tool from GitHub.
• The original tool will fail if the target machine uses IPv6.
• The original tool also expects the SOCKS protocol to be provided via the --socks argument (ie --socks socks5://127.0.0.1:30006)

[Macmod]

Thanks @camlischke1!

It's a mystery to me why is it that the remote address got swapped by a link-local IPv6 address in the SOCKS packets you demonstrated - ldapx doesn't do that explicitly, and it would seem that the original socks library doesn't either, at least not explicitly... For now users with this issue should try your fork.

I set up a very similar environment as yours on AWS, with Mythic running on an Ubuntu Server and the DC being a Windows Server 2025. It worked normally too, so I haven't been able to reproduce the issue.

If others stumble upon this kind of issue please let me know a bit about your setup so we can analyze it better. For now I'll leave the issue open as I think some may appreciate backwards compatibility for SOCKS4. Regardless of that, it seems that the SOCKS library doesn't handle IPv6 well - which is another issue. I'll try to perform some additional testing to try to understand if we can fix it in a better way in the near future.

[camlischke1]

If it helps, the link-local IPv6 address that is getting resolved is attached to the same interface as the target IPv4 given in the ldapx command above.

[Macmod]

Closed due to inactivity.