-
Notifications
You must be signed in to change notification settings - Fork 3.8k
Add LDAP relay server to ntlmrelayx #2026
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Add LDAP relay server to ntlmrelayx #2026
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I only tested impacket-based clients, works very nice for that. It should also work with Windows clients when they support NTLM, but currently it would only works when NTLM is their highest priority MechType.
Also did you experiment with ommiting LDAP_CAP_ACTIVE_DIRECTORY_LDAP_INTEG_OID in the initial searchrequest? In the MS docs it says that with NTLM auth this is used as a capabitlity for signing, would be interesting if dropping this could lead a client to not set the signing bits in the NTLM negotiation.
| logging.debug("LDAP: Extracted mech_token: %r" % mech_token) | ||
|
|
||
| # Search for the NTLMSSP header | ||
| ntlm_header = b'NTLMSSP\x00' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this assumes that the client is sending the NTLMSSP header, but they could also just send their Kerberos ticket, and say that they also support NTLMSSP, for example on my windows 11:

Then we need to renegotiate.
I tried it in 3796872 , but I haven't tested it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just reading through the code this looks like it will work, but I'd need to set up an environment to test this. If someone else wants to try and beat me to it, it'd be much appreciated :)
Co-authored-by: Romern <[email protected]>
Co-authored-by: Romern <[email protected]>
Co-authored-by: Romern <[email protected]>
Co-authored-by: Romern <[email protected]>
Co-authored-by: Romern <[email protected]>
|
I just tested it in my lab and it seems like with the current ROOT query response, Windows does not do GSSAPI at all, only NTLMSSP. So maybe it isn't even needed to renegotiate the mechtype at all. Also I stumbled upon the CLDAP ping message which is sometimes done in Windows before any actual LDAP requests to confirm that the server is up. This seems to be only needed when no connection in the current user session has been established. If it is not send in a session, no LDAP connection seems to be established. |
|
With CLDAP (implemented with scapy and pyasn1_ldap (somehow the regular LDAPMessage from ldap3 and impacket do cannot parse these CLDAP messages properly?): 5f00665 ) I get GSSAPI authentications, but somehow without support for NTLM (Windows 11 24H2 and Server 2025 without signing and sealing). Sometimes I also get siciliy authentications. Could someone try this in their lab? And this impacket branch: https://github.com/rtpt-romankarwacik/impacket/tree/ntlmrelayx-ldap-server And reset the Ethernet controller of a windows client in the network, this should trigger DNS requests to LDAP, then CLDAP and then LDAP. If this does not work, just click on the user in the start menu on Windows 11, this also triggers an LDAP request. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would put the CLDAP stuff in another PR when its ready, for other LDAP clients this works nicely 👍
Added support for incoming LDAP credentials and the ability to relay them using things like the
-iinteractive shell.Useful for things like finding printers with LDAP configured and changing the hostname to your own host.