Add sensitive_files SMB module - enumerate shares for sensitive file extensions

[Char0n1507]

Description

Adds a new SMB enumeration module sensitive_files that crawls all accessible
shares on a host and flags files with sensitive extensions.

Default extensions hunted: .kdbx, .pfx, .p12, .pem, .key, .ppk, .ovpn,
.config, .conf, .cfg, .xml, .ini, .env, .rdp, .id_rsa, .vnc

Module options:

• EXTENSIONS: custom comma-separated list
• MAX_DEPTH: recursion depth (default 5)
• OUTPUT: save findings to file
• SHARE: scan a specific share only

No new dependencies required.

AI assistance: Module structure and debugging assisted by Claude (claude.ai).
Design, testing, and decisions were human-driven and verified against a live
impacket smbserver test environment.

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 (Claude via claude.ai - code structure and debugging)

Setup guide for the review

• OS: Kali Linux, Python 3.13
• No additional software required beyond impacket (already a dependency)

Test steps:
sudo impacket-smbserver testshare /tmp/smb-test -smb2support &
touch /tmp/smb-test/passwords.kdbx /tmp/smb-test/server.pfx /tmp/smb-test/app.config
nxc smb 127.0.0.1 -u '' -p '' -M sensitive_files

Expected: 3 sensitive files flagged with full UNC paths.

Screenshots (if appropriate):

[paste your terminal screenshot from the successful test]

Checklist:

• I have ran Ruff against my changes (0 errors)
• 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
• 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 PR.

However, this is pretty much the exact same that would be able to do with --spider --pattern .pfx ....

[Char0n1507]

Hi @NeffIsBack, thanks for the review!

I understand the overlap with --spider --pattern.

The key differences I was trying to add were:

1. Pre-configured default extensions list covering common credential files
   (.kdbx, .pfx, .p12, .pem, .ppk, .ovpn, .env, .id_rsa etc.)
2. A dedicated module so operators don't need to remember the extension
   list during engagements
3. OUTPUT option to save findings directly to file

Would it be worth keeping as a convenience module, or would you prefer
I instead contribute by improving the --spider --pattern documentation
or adding these default extensions as a built-in preset? Happy to pivot!

[NeffIsBack]

Hi @NeffIsBack, thanks for the review!

I understand the overlap with --spider --pattern.

The key differences I was trying to add were:

1. Pre-configured default extensions list covering common credential files

   (.kdbx, .pfx, .p12, .pem, .ppk, .ovpn, .env, .id_rsa etc.)

2. A dedicated module so operators don't need to remember the extension

   list during engagements

3. OUTPUT option to save findings directly to file

Would it be worth keeping as a convenience module, or would you prefer

I instead contribute by improving the --spider --pattern documentation

or adding these default extensions as a built-in preset? Happy to pivot!

Hi, yes, I think we should not duplicate functionality here, but rather add missing functionality to --spider. Regarding the file extensions I think this is something we should document in the wiki e.g. as an example or "knowledge base".

[Dfte]

1. .kdbx, .pfx, .p12, .pem, .ppk, .ovpn, .env, .id_rsa etc

So I personally use manspider for that usage but I believe we can have this on NXC as well. The easier would be to have a text file in nxc/data with each default extensions we are looking for. Then add a boolean such as --default-extensions that will load these extensions. Later we'll even be able to implement a "search by keyword" option based on the same text files And obviously the --output-dir to store all found items :P

[Char0n1507]

Hi @Dfte, @NeffIsBack — that's a great direction!

I love the idea of:

1. A text file in nxc/data/ with default sensitive extensions
2. A --default-extensions flag to load them automatically
3. --output-dir to save findings

I can implement this approach instead. This would make it
genuinely additive to --spider rather than duplicating it.

Would you be open to me updating this PR with that implementation?

[Dfte]

To me that looks like a great addition! And then we will be able to replicate these files for others protocols such as winrm, nfs. Afterall, it's all about looping over directories and files!

The only question I have is rather how we will manage these "words/extensions list". How do we allow people contributing ? Do we add anythng ?

For the extensinos for examples, may be we could somehting like:

• --extension loads the default extension list
• --extension /home/me/ext_files.txt loads the specified extension files

[Char0n1507]

Hi @Dfte great question on managing the extensions list! Here's what I've implemented and validated:

How EXTENSIONS works:

Usage	Behaviour
(not set)	loads nxc/data/sensitive_extensions.txt (built-in defaults, community-maintained via PR)
EXTENSIONS=/path/to/file.txt	loads a custom file (comments/blank lines ignored)
EXTENSIONS=.pfx,.kdbx	comma-separated list used directly

For community contributions anyone can PR new extensions directly to nxc/data/sensitive_extensions.txt, no code changes needed. Keeps it clean and reviewable.

Live SMB test (all 3 files detected):

[*] Scanning share: TESTSHARE
[TESTSHARE] \app.config
[TESTSHARE] \server.pfx
[TESTSHARE] \passwords.kdbx
[+] Found 3 sensitive file(s) on 127.0.0.1

Unit tests: 8/8 pass (default load, custom file, comma list, MAX_DEPTH, OUTPUT_DIR, SHARE filter)

Before I push do you prefer the option named EXTENSIONS or something else? And should the default list stay minimal or be more comprehensive out of the box?

[Char0n1507]

Hi @Dfte, great question on managing the extensions list! Here's what I've implemented and validated:

How EXTENSIONS works:

Usage	Behaviour
(not set)	loads nxc/data/sensitive_extensions.txt (built-in defaults, community-maintained via PR)
EXTENSIONS=/path/to/file.txt	loads a custom file (comments/blank lines ignored)
EXTENSIONS=.pfx,.kdbx	comma-separated list used directly

For community contributions anyone can PR new extensions directly to nxc/data/sensitive_extensions.txt, no code changes needed.

Additional validation — extension filtering confirmed working (commit 9de4ad01):

# Single extension — returns only matching files
$ nxc smb 127.0.0.1 -u '' -p '' -M sensitive_files -o EXTENSIONS=.pfx
[*] Scanning share: TESTSHARE
[TESTSHARE] \backup.pfx
[+] Found 1 sensitive file(s) on 127.0.0.1

# Non-existent extension — returns no findings
$ nxc smb 127.0.0.1 -u '' -p '' -M sensitive_files -o EXTENSIONS=.xyz
[*] Scanning share: TESTSHARE

Test	Result
Default extensions	✅ Pass
OUTPUT_DIR — per-host file written correctly	✅ Pass
EXTENSIONS via file path	✅ Pass
EXTENSIONS inline comma-separated	✅ Pass
SHARE filter	✅ Pass
Single extension filter (.pfx → 1 result)	✅ Pass
Non-matching extension (.xyz → 0 results)	✅ Pass
No SyntaxWarnings	✅ Pass

Open to feedback on naming conventions or adjustments to the default extension list. Happy to revise based on review.

[Dfte]

Alright! That looks great but as @NeffIsBack mentionned, I'd rather have these options in the core alongside --spider

[Char0n1507]

Updated per review feedback

Replaced the standalone sensitive_files module with a native --spider-sensitive flag as requested by @NeffIsBack and @Dfte.

Changes:

• Removed nxc/modules/sensitive_files.py
• Added --spider-sensitive to core SMB spider args
• Curated extensions baked in: .kdbx .pfx .p12 .pem .key .ppk .ovpn .rdp .config .conf .cfg .env .xml .ini .id_rsa .vnc
• Works alongside existing --pattern and --regex flags

Test output:

[Dfte]

Thank you! I will have some times this week to check that out and benchmark speed with other tools such as Manspider for example!!

[NeffIsBack]

To me that looks like a great addition! And then we will be able to replicate these files for others protocols such as winrm, nfs. Afterall, it's all about looping over directories and files!

Actually that's a great idea. We should probably - one day - merge --spider and -M spider_plus into one spider module and make this universally available to multiple protocols. So we simply have one crawling logic that is extensible to all protocols that provide file access.

[Char0n1507]

Thanks @NeffIsBack — really glad the direction landed well! The idea of unifying --spider and -M spider_plus into one protocol-agnostic crawling layer makes a lot of sense. A single crawl engine that works across SMB, WinRM, NFS etc. would be much cleaner than per-protocol duplicates.

Happy to help with that consolidation if you decide to pursue it. For now I'll keep this PR focused on the --spider-sensitive flag so it's reviewable and mergeable on its own.

@Dfte looking forward to the Manspider benchmark — let me know if you want me to set up a reproducible test environment to make the comparison fair.

[Char0n1507]

Hi @Dfte @NeffIsBack — just following up on this PR when you get a chance.

I’ve kept the implementation focused on the --spider-sensitive approach based on the review feedback, and the latest changes are ready for review. I know you mentioned benchmarking against Manspider, so I’m happy to make any additional changes or provide a reproducible test setup if that would help.

No rush just wanted to check in and see if there’s anything else needed from my side to move this forward. Thanks!