Description

Add the INTERESTING_ONLY boolean option to the daclread module. This allows filtering a response of 50+ ACEs into 1-5 relevant entries. It does so by removing ACE entries that can be performed with users/groups whose SID is below 1000 (default groups that share common permissions), and excluding Read capabilities, which are in 99% considered irrelevant. This allows the user to see permissions such as "John Doe can change the email address of Will Smith" in a matter of a couple of seconds.

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)

Setup guide for the review

Run the command using the

netexec ldap <target> -u <user> -p <password> -M daclread -o ACTION=read TARGET=<target_user> INTERESTING_ONLY=True

and

netexec ldap <target> -u <user> -p <password> -M daclread -o ACTION=read TARGET=<target_user> INTERESTING_ONLY=False

whilst targeting a user that can be modified by a non-default user/group.

Screenshots (if appropriate):

Running the command without the flag executes the default module behavior of listing all ACEs.

Running the command with the option flag enabled returns an actionable list of ACEs.

Checklist:

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

• I have ran Ruff against my changes (via poetry: poetry run python -m ruff check . --preview, 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)
• New and existing e2e tests pass locally with my changes
• 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 performed a self-review of my own code
• 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)