Simplifying module structure

[lodos2005]

Hi everyone,

Previously, I worked on PR #300, where I merged several modules like PetitPotam, dfscoerce, shadowcoerce, printerbug and mseven into a single unified module.

Now, I’m planning to do something similar for modules such as drop-sc.py, slinky.py, and scuffy.py — as well as for file types like #657 .searchConnector-ms, .URL, etc.

The goal is to consolidate these modules into a single one that:
• Supports same parameters (e.g., target file name, delete flag, etc.),
• Simplifies usage and improves maintainability,
• Reduces fragmentation while preserving modularity.

I can handle the necessary testing and submit a PR.

This idea doesn’t have to be limited to file-drop modules only. We could consider a similar approach for other module categories as well.

For example, LSASS dumping could benefit from a unified module structure. I know lsassy already supports multiple methods, but we also have tools like nanodump, procdump, handlekatz, etc. Consolidating these into a common module might improve usability and make maintenance easier.

Similarly, for credential harvesting, which I’m currently working on (as a Lazagne-style module), there might be value in merging modules like vnc.py, winscp.py, veeam.py, putty.py, mremoteng.py, mobaxterm.py, iis.py, and firefox.py.

However, before moving forward, I wanted to open up this discussion:
Do you think merging these modules into one is a good idea from a long-term sustainability or modularity perspective?
Could this impact usability or future development negatively in ways I might be overlooking?

I’m open to feedback on whether this kind of consolidation aligns with NetExec’s design philosophy.

Looking forward to hearing your thoughts and suggestions!

[mpgn]

The maintainability of one module for all can be a lot harder and the options on modules are not ideal, which will make things harder like

-M nanodump will become -M dumplsass -O METHOD=nanodump etc

Which kind a break the simplicity of it

[zblurx]

I agree with Mpgn, a module that bundle multiple modules is a huge file with a lot of code, so harder to debug and maintain

On the other hand, I like the Lazagne idea of grouping credential dumping modules. For now, if you want to test every credential dumping modules, you need to chain them in a command, and we are starting to have a bunch of them.

It could be nice to have some king of shortcut to use them all at one, but in the same time still being able to use only one, because sometimes you want to check only veeam stuff for example.

Maybe a module that "just" launch multiple modules ?

[mpgn]

you can do -M nanodump procdump handlekatz

[zblurx]

Dumping LSASS : looser
Dumping LSASS 3 times : absolute goat 😎

[lodos2005]

maybe -M nanodump procdump handlekatz sounds a bit strange, if they all succeed, the same data will come. but when i call -M cred_loot, defining an "alias" like -M wifi vnc winscp veeam putty mremoteng mobaxterm firefox etc etc might be a solution.

[Adamkadaban]

I like the idea of one module calling others. There would still be code separation (so hopefully it'll be relatively easy to maintain), but it'll be easier for users.

I used to be able to easily identify and use any module I needed when I looked at every PR in the nxc discord, but now that I haven't had the time to look at each one, the number of new modules has been overwhelming to parse through and remember.

As for design, I'm not sure what would happen. I can imagine logically separating modules into folders? iirc modules imports are dynamically resolved, so hopefully that wouldn't matter too much.

I'd imagine a directory structure like:

independent_module.py
lsass_module.py
lsass/
    handlekatz.py
    nanodump.py

Maybe people could view submodules with nxc smb -L lsass

Thoughts?

Regardless, I would love a feature to make modules more manageable, especially since people will continue to write more and more.

Eventually, I'm sure nxc ... -L will be pages and pages long

[lodos2005]

frankly, I opened this topic because this list is getting longer. Maybe soon we will “search” and select “1, 2, 3” etc interactively like msfconsole. 👯

[Marshall-Hallenbeck]

Folders might be a good idea. @NeffIsBack introduced the "admin" vs "user" privilege thing. Instead of folders we could maybe do tags?

[NeffIsBack]

So in my opinion this depends on the module. I think for modules that share a lot of similarities like coercing modules, streamlining and merging these modules can improve maintainability if done correctly.

E.g. i can see that being the case for the lsass dump modules, where you often have a binary and then a specific command on how to execute them (simply put). Merging these with a bit of work to make a good code base could be very nice, so you only have one class&module for lsass dumping and could then specify what exactly you want: -M lsass -o METHOD/BINARY=procdump/nanodump/lsassy....
However, to make this worth the code base have to be simple enough, that it is just a matter of swapping executables&commands, otherwise this could get very messy (probably what @mpgn is fearing).

With modules like vnc, veeam, putty, mremoteng etc i don't see this being useful. These modules are just way to different in what they are doing. That would just be a giant file of code chained together. And like @zblurx i also want to pick out some of these modules against specific hosts. I could see something like a "lazagne" module where it just calls a few other modules under the hood, but with that we should also be careful or at least advice, that this can take a ton of time when running against multiple hosts at once (imagine running 10 modules against a /16 range).

However in the long term this does not solve the underlying problem that we will get more and more modules which in turn will make the list more and more confusing. Not sure how to solve that honestly. Maybe folders like @Adamkadaban suggested? Maybe tags? Maybe something like Metasploit is doing? I am not sure yet how we could solve that problem in the long term.

That is at least my take :)

[lodos2005]

Since one of the concerns mentioned was time, I’d like to point something out. Running both the rdcman and wifi modules separately across a /16 network can be slower compared to running a combined module that handles both. That’s because each module will independently call expensive functions like collect_masterkeys_from_target.

What I meant by a “lazagne-like” module is mainly about reducing these repeated functions and minimizing confusion. This could be solved via categories, tags, or alias-like functionality. For instance, running -M Browsers could internally trigger -M firefox, -M chromium (I’m planning a PR for that soon), and so on. Similarly, -M Sysadmin could trigger modules like vnc, winscp, keepass, rdcman. This way, when a new module like filezilla is introduced, it could be automatically included without constantly checking -L or reading changelogs.

Of course, this alias idea won’t inherently prevent repeated executions of collect_masterkeys_from_target. However, we could solve that by using a global variable (e.g., via a helper like get_masterkeys) and doing a small refactor across modules—something like “only call collect_masterkeys_from_target if _masterkeys is not already set”. That way, we avoid reading DPAPI keys multiple times unnecessarily.

This also leads us to the need for proper documentation around module development—e.g., listing available helper functions and how/when to use them. Such documentation could help speed up both the review process and module development overall.

[mpgn]

I see your point.

Modules are for the community—for people to contribute to NXC easily without having to dig into the core features.

Of course, there are some downsides to this approach, like you mentioned—the repetition of steps.

[NeffIsBack]

Regarding the runtime, i think we could indeed integrate the masterkey looting into the smb protocol and streamline it for modules👍
Something like connection.get_masterkeys() which either returns already queried masterkeys for the host or starts collecting them.

Imo also a lazagne like function could be a good option, but we probably have to pick out specific modules. Imo running something like the veeam module against many hosts won't make much sense because this is limited to the backup infrastructure (which is usually 1 to 2-3 hosts at most). Similar, although i would count tools like "lsassy"/"handlekatz" as credential dumping modules, including all of them into --lazagne wouldn't much sense either.

However, in the end i agree with @mpgn. Modules are the best way to easily start contributing to NetExec and to utilizes it's authentication infrastructure. Grouping or functionalizing modules could raise the entry barrier for contributions, so at the core modules should stay as they are. Maybe categories could be a solution to the intermediate future.

I thought of something like 2-3 categories, similar to how we group the netexec wiki. Perhaps Enumeration, Credential harvesting, Other? Or maybe an additional group such as Privilege Escalation (e.g. for pi, schtask_as, mssql_link_cmd...)? Similar to the Current grouping of high priv/low priv we could furthermore divide it into these subgroups and print them (if modules for the respective group exist). You could also query only one group like smb -L enumeration which would filter for that category. That would be relatively easy to implement: module listing could be just filter for a specific category on the module, while on the module we would just need to add one attribute.

Visual POC:

[Adamkadaban]

I thought of something like 2-3 categories, similar to how we group the netexec wiki. Perhaps Enumeration, Credential harvesting, Other?

I think that's a great idea. Definitely helps with organization. PoC looks perfect

[Dfte]

Ayo guyz, so I have just submitted a draft PR to experiment with the --lsass core option:

#785

As of now I believe it is better to rely entirely on a single tool (LSASSY) that does handle pretty much everything we need. I also believe we should PR LSASSY when adding new dump methods instead of NXC directly.

Now that I have worked on that option, I believe we can also factorize multiple options such as:

• --sam / --lsa that could take an argument (method) allowing to specify how to dump hives (export-print, backup exploit, simple reg save and so on) ;
• --wcc that could be use to check multiple configuration options (something like --wcc bitlocker would only check for the bitlocker configuration while --wcc would fire up all checks).
• --dpapi METHOD, we could rely on DonPapi direclty as it already integrated recycle_bin, notepad, ntoepad++, dpapi related stuff with dploot etc etc.
• --ntds METHOD that would allow us dumping NTDS using multiple methods (backup, drsuapi dump, vss, certsync)
• --lnk could be done as well considering we have 5 modules that creates different types of lnk files used for coerce
• --coerce

I'm keen working on these changes so let me know what you think about it :)!