Add safe_shares SMB module: share permission enumeration module that does not write files to disk#1138
Add safe_shares SMB module: share permission enumeration module that does not write files to disk#1138e-nzym3 wants to merge 3 commits intoPennyw0rth:mainfrom
Conversation
e-nzym3
requested review from
Marshall-Hallenbeck,
NeffIsBack,
mpgn and
zblurx
as code owners
|
whereas this module will check for WRITE permissions safely, and still report them where possible |
Signed-off-by: e-nzym3 <jack@enzym3.io>
|
Thanks for the PR! I think we should either integrate it into the default |
Replaces the single GENERIC_WRITE check with a multi-mask approach covering FILE_ADD_FILE, FILE_ADD_SUBDIRECTORY, WRITE_DAC, and WRITE_OWNER. Plain WRITE suppresses the more granular labels when redundant. Dynamic column widths added.
|
Actually, as I was digging more into the SharpShares logic, I realized it had some gaps that could be tightened down to make this proposed module less prone to false positives by adding checks for some other permissions as well, such as Another bonus I added was To clarify on the false positive concern: the module is not reading the DACL directly, it's calling Worth flagging if you're considering merging the logic:
I created a test share setup to display when this module would trigger
Here is what the module ran through nxc would report: |
3 participants
Preface
On a recent engagement, I stumbled upon a situation where Netexec's
--sharesflaggenerated a bunch of artifacts on shares where my user did not possess DELETE permissions.
Artifact:
Perms on share folder:
First time I ran into this, but nonetheless, it sent me down a path of identifying
a better (safer) way of gathering share permissions, even with some slight downsides.
This proposed module comes with a slight downside, since share ACL and NTFS ACL may
differ, some WRITE permissions may be missed. Here's what output looks like when ran
against a share where my authenticating user has a DENY on DELETE permissions:
And here's the output from
--shares, correctly reporting WRITE permissions, butat the same time leaving an artifact behind on disk (pictured in the first screenshot above).
My thought: I'd rather have the option of running a safer check for WRITE permissions
and miss some, rather than potentially risk leaving a bunch of artifacts behind for clean-up.
In normal cases, it will report WRITE access as expected:
Description
Adds a new SMB module
safe_sharesthat enumerates share READ/WRITE permissionswithout writing any files to disk — an OPSEC-safe alternative to the built-in
--sharesflag. Effectively, an NXC implementation of SharpShares (https://github.com/djhohnstein/SharpShares).Problem with existing
--shares: Write access is tested by creating atemporary file/directory, then deleting it. This leaves artifacts during
the creation-deletion window.
This module's approach (inspired by SharpShares):
listPath()— same non-destructive approach NXC already uses\) withGENERIC_WRITEdesiredaccess and
FILE_OPEN(0x1) create disposition — opens the existing directoryhandle, never creates any object on disk. If the server grants the handle,
write access is confirmed.
No third-party dependencies beyond impacket (already bundled with NXC).
AI Assistance: This module was developed with the assistance of Claude Code
(Anthropic). The technique research, impacket API usage, and module architecture
were AI-assisted; the code has been manually reviewed and tested.
Type of change
used for implementation and impacket API research)
Setup guide for the review
Any authenticated SMB session against a Windows target with shares is sufficient.
No special configuration required. Tested against:
Screenshots
See Preface above for inline screenshots. Terminal output:
Checklist
tests/e2e_commands.txtfile(will open NetExec-Wiki PR after this is merged)