Skip to content

Conversation

@Wyndoo
Copy link

@Wyndoo Wyndoo commented Dec 16, 2025

Description

Based on the "get-info-users" which outputs the info field of users, this module enumerates the scriptPath attribute of all AD users.

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

  • Users with the scriptPath attribute set.

Screenshots (if appropriate):

get-scriptpath-screen

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)
Signed-off-by: Wyndoo <wyndo101@gmail.com>
Signed-off-by: Wyndoo <wyndo101@gmail.com>
@Dfte
Copy link
Contributor

Dfte commented Dec 18, 2025

Heyo! First thanks for the PR. What about simply adding that into the --get-users-info directly ?
@NeffIsBack thoughts ? That's an interesting information to have considering sometimes we can backdoor these

@NeffIsBack
Copy link
Member

Thanks also from my side for the work!

Agreed with @Dfte. Not sure in which module we should start grouping these enumerations, but I think we should accumulate those. We start to have a bunch of modules that just queries one interesting attribute that exist in rare cases (get-users-info, get-userPassword, get-UnixUserPassword etc.)

@Wyndoo
Copy link
Author

Wyndoo commented Dec 19, 2025

Sure, which are the modules that you would want to group? Should the module query all the interesting attributes at once or the user can specify what attribute to enumerate in the module options?

@NeffIsBack
Copy link
Member

I think let's just leave the module as is and we will group it in a bigger module once we have found a good name.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

3 participants