fix(ldap): resolve group members via 'member' fallback for missing 'm…

[amikuss]

…emberOf' backlinks

Description

Added a fallback checking "members" attribute for the --groups "GROUP" argument.

If a user's "memberOf" backlink has not been populated, the current memberOf/primaryGroupID check does not return the user when running --groups "GROUP", even though --groups returns the correct number of group members.

I ran into this issue in a HTB CAPE environment, where a Foreign Security Principal's memberOf was not set, even though it was a member of a group. See screenshots below.

AI disclosure: Claude Sonnet 5 was used for some coding help.

Type of change

Insert an "x" inside the brackets for relevant items (do not delete options)

• 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

I have been unable to reproduce this issue as the memberOf attribute is dynamically maintained, including FSPs.
I was unable to figure out why this was not the case in the CAPE lab environment and honestly unsure if this PR is necessary given that this seems like a very environment-specific quirk.

Screenshots (if appropriate):

Before:

After:

Checklist:

Insert an "x" inside the brackets for completed and relevant items (do not delete options)

• I have ran Ruff against my changes (poetry: poetry run ruff check ., use --fix to automatically fix what it can)
• I have added or updated the tests/e2e_commands.txt file if necessary (new modules or features are required to be added to the e2e tests)
• If reliant on changes of third party dependencies, such as Impacket, dploot, lsassy, etc, I have linked the relevant PRs in those projects
• I have linked relevant sources that describes the added technique (blog posts, documentation, etc)
• 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 (PR here: https://github.com/Pennyw0rth/NetExec-Wiki)

[NeffIsBack]

Thanks for the bug fix PR!

So far, the search preparation and display logic was separated because there were only small differences in both code branches. Since this is much more logic now, please just make a big if/else to separate between searching all groups and looking at a specific group.

[NeffIsBack]

LGTM:

@amikuss please retest if the changes still solve your problem. In my case, the unresolved group members were foreign domain members and therefore the DC returned a referral error. In such cases I have simply added the dn as fallback.