Fix custom LDAP port specification and improve scheme handling

[emilyastranova]

Description

This PR addresses an issue where custom ports specified with nxc ldap --port were not being properly respected or passed to the underlying Impacket LDAP connection. Additionally, it allows the user to manually specify protocol scheme (ldap vs ldaps) and defaults to LDAPS.

Key Changes

1. Impacket LDAPConnection Monkey Patch: Added a monkey patch for impacket.ldap.ldap.LDAPConnection to support custom ports in the connection URL (ldap://host:port or ldaps://host:port), which is not natively supported by Impacket.
2. Refactored Protocol Arguments: Modified the argument parser in proto_args.py to use --scheme instead of capturing the protocol under a conflicting scheme destination.
3. Accurate Logging: Refactored nxc/protocols/ldap.py logging statements to use the dynamically computed scheme and port instead of hardcoding protocol names based on standard port numbers.

How and why we fixed

I tried to use the --port option in an environment where a DC had a custom LDAP port set, not a standard one (no idea why) and realized only the default LDAP and LDAPs ports worked, not ports like 1111. I leaned on socat until I managed to write this patch. Much easier after this patch.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Deprecation of feature or functionality
• This change requires a documentation update
• This requires a third party update (such as Impacket, Dploot, lsassy, etc)
• This PR was created with the assistance of AI (list what type of assistance, tool(s)/model(s) in the description)

Setup guide for the review

Any target with an LDAP service running on a non-standard port, I used 1111.

Testing Performed

Tests run:

• Verified that nxc ldap <ip> --port <custom_port> connects to the correct custom port.

• Verified that nxc ldap <ip> --scheme ldap defaults to connecting to port 389.

• Verified that nxc ldap <ip> --scheme ldaps (or the default behavior) defaults to connecting to port 636.

  Checklist:

  • I have ran Ruff against my changes
  • I have added or updated the tests/e2e_commands.txt file if necessary
  • If reliant on changes of third party dependencies, I have linked the relevant PRs
  • I have linked relevant sources that describes the added technique
  • I have performed a self-review of my own code (not an AI review)
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation

[NeffIsBack]

Hi and thanks for the bug fix PR!

Looking at the patch I am kinda not happy that we have to introduce a --scheme arg because that might encourage users to overwrite NetExec's automatic scheme discovery mechanisms, but it seems like there is no solution if we have a custom port (besides maybe trying out).

Regarding the custom port, please contribute this fix to impacket. When that is merged we can just supply the port properly.

[Dfte]

Agree with you @NeffIsBack , this is something I have been struggling before with Impacket but I wouldn't monkey patch it for NetExec. I'd rather modify the LDAP logic so that it connects to the submitted port via LDAPS first, then fallback to LDAP in case it didn't work ^^

[emilyastranova]

Hi and thanks for the bug fix PR!

Looking at the patch I am kinda not happy that we have to introduce a --scheme arg because that might encourage users to overwrite NetExec's automatic scheme discovery mechanisms, but it seems like there is no solution if we have a custom port (besides maybe trying out).

Regarding the custom port, please contribute this fix to impacket. When that is merged we can just supply the port properly.

Will do, figured I'd get this created for anyone who needs it now. Impacket merges are... not quick 😆

[NeffIsBack]

Hi and thanks for the bug fix PR!

Looking at the patch I am kinda not happy that we have to introduce a --scheme arg because that might encourage users to overwrite NetExec's automatic scheme discovery mechanisms, but it seems like there is no solution if we have a custom port (besides maybe trying out).

Regarding the custom port, please contribute this fix to impacket. When that is merged we can just supply the port properly.

Will do, figured I'd get this created for anyone who needs it now. Impacket merges are... not quick 😆

Fair point😁