Add support for LDAP and LDAPS protocols in ntlmrelayx SOCKS #1825
Conversation
|
hi @b1two . This looks like a relly interesting feature to integrate! thanks! this was trying pywerview: any idea what could be happening? |
|
Hello, thanks for testing this PR. I checked and pywerview actually performs an SMB bind to retrieve the FQDN of the domain prior to performing the action (see https://github.com/the-useless-one/pywerview/blob/973ed7933b5621d88960152bba422e6644327d34/pywerview/requester.py#L353). Since there was no relay available for SMB ( You can either use the For the second option, I did not manage to make it work without the following two patches to impacket.
The patches: diff --git a/impacket/examples/ntlmrelayx/utils/targetsutils.py b/impacket/examples/ntlmrelayx/utils/targetsutils.py
index 7e119d67..6f4fdaa8 100644
--- a/impacket/examples/ntlmrelayx/utils/targetsutils.py
+++ b/impacket/examples/ntlmrelayx/utils/targetsutils.py
@@ -157,7 +157,7 @@ class TargetsProcessor:
# Multirelay feature is disabled, general candidates are attacked just one time
elif multiRelay == False:
for target in self.generalCandidates:
- match = [x for x in self.finishedAttacks if x.hostname == target.netloc]
+ match = [x for x in self.finishedAttacks if x.hostname == target.netloc and x.scheme == target.scheme]
if len(match) == 0:
self.generalCandidates.remove(target)
return target
diff --git a/impacket/nmb.py b/impacket/nmb.py
index 7cf6412a..a7f451d6 100644
--- a/impacket/nmb.py
+++ b/impacket/nmb.py
@@ -686,10 +686,13 @@ class NetBIOSSessionPacket:
return self.type
def rawData(self):
+ trailer = self._trailer
+ if type(self._trailer) != bytes:
+ trailer = self._trailer.getData()
if self.type == NETBIOS_SESSION_MESSAGE:
- data = pack('!BBH', self.type, self.length >> 16, self.length & 0xFFFF) + self._trailer
+ data = pack('!BBH', self.type, self.length >> 16, self.length & 0xFFFF) + trailer
else:
- data = pack('!BBH', self.type, self.flags, self.length) + self._trailer
+ data = pack('!BBH', self.type, self.flags, self.length) + trailer
return data
def set_trailer(self, data):In the end, with the two relays in place, pywerview seems to work fine:
Let me know if that works on your side as well. |
|
This made me realize that I was building the NTLM challenge message for the client with dummy data, although it works, it may cause issues for tools that rely on the information in this message. I have a (tiny) working patch that, instead of building the whole message from scratch, uses the one that was received from the real server during the relay. I pushed the modifications in another branch: b1two@6c5f97d Do you want me to update this PR to reflect this change? |
|
@b1two yes please! thank you! |
|
Hi. I am trying to proxy Bloodhound.py using this PR but it does not fully work. Bloodhound.py requires both port 389 and port 3268 to work so I configure ntlmrelayx to setup SOCKS servers on both ports using your two patches above. However, once Bloodhound.py attempts to use port 3268, ntlmrelayx outputs "...(389) is being used at the moment!" and Bloodhound.py crashes. Any ideas? Thanks! ntlmlrelayx: bloodhound.py: |
|
@anadrianmanrique Done! No worries, I am quite busy myself these days. @dkjajhqu2h3j I will look into it, but I think that the issue is likely to come from Bloodhound.py trying to use multiple connections to the LDAP server in parallel ( |
Adds support for LDAP and LDAPS protocols in the SOCKS server of ntlmrelayx.
This allows the use of any tool that works with LDAP(s) through the relay obtained using ntlmrelayx. Specifically, this eliminates the need to reimplement every LDAP attack within the LDAP interactive shell, allowing to use of any available PoC directly through the SOCKS server provided by ntlmrelayx.
Some technical details about the implementation:
impacket/examples/ntlmrelayx/clients/ldaprelayclient.py) that was not required until now. It simply performs a basic LDAP query to keep the connection alive.It should fix #514.
Please let me know if any adjustments or improvements are needed.
Short usage example: