Feature request: add `sswmi` (WMI shadow snapshot) dump method to `--sam`/`--lsa`/`--ntds`

[hakimonr]

Please Describe The Problem To Be Solved

During a recent internal engagement against EDR-protected Windows hosts, I could not use the current credential gathering options of the SMB protocol:

• --sam / --lsa (both regdump and secdump) were blocked — remote registry hive access and reg save are heavily monitored by the endpoint protection,
• --ntds vss was blocked — it creates a service and runs vssadmin remotely,
• --ntds drsuapi was blocked as well.

The same targets were fully dumpable with impacket-secretsdump -use-remoteSSWMI. That method creates a Shadow Snapshot via WMI (Win32_ShadowCopy), downloads SAM, SYSTEM and SECURITY (and optionally NTDS.dit) over SMB from the snapshot, and deletes the snapshot afterwards. There is no code execution on the target at all: no service creation, no reg save, no vssadmin. In my testing, this approach produced no EDR alert, while every other method did.

NetExec is the de-facto standard tool for this kind of work, so having this method built-in would help a lot of people facing the same problem.

Scope: add a third, opt-in method next to the existing ones. The behaviour of regdump, secdump, vss and drsuapi stays unchanged.

Suggest A Solution

Add an sswmi choice to --sam, --lsa and --ntds, plus an optional --sswmi-volume (default C:\) for DCs where NTDS.dit lives on another volume:

nxc smb <target> -u user -p pass --sam sswmi
nxc smb <target> -u user -p pass --lsa sswmi
nxc smb <target> -u user -p pass --ntds sswmi
nxc smb <target> -u user -p pass --sam sswmi --ntds sswmi --sswmi-volume D:\

Implementation notes:

• impacket's RemoteOperations already ships createSSandDownloadWMI() (the backend of -use-remoteSSWMI), and the impacket revision NetExec pins already contains it — no dependency change is needed.
• Flow: WMI Win32_ShadowCopy.Create → read the hives back over SMB from the snapshot → delete the snapshot → parse locally (bootkey taken from the downloaded SYSTEM hive), same as the LOCAL mode of secretsdump.
• When several of --sam/--lsa/--ntds are combined with sswmi, one snapshot is created and shared between them.
• Existing options (--history, --kerberos-keys, --enabled, --user) keep working with the new method.

Tradeoffs / caveats:

• Requires local admin, same as the other methods.
• Requires DCOM/WMI (135) to be reachable; the volume needs to support shadow copies.
• WMI itself can be monitored by some EDRs, but the signal profile is much lower than service creation or reg save.

I have a working prototype (2 files changed, no new dependencies) and can open a PR with it. The underlying approach (-use-remoteSSWMI) was verified by me in a real EDR-protected environment; the nxc integration is lint-clean and passes the existing test suite, but has not been tested against a live target yet — I will do that as soon as the direction is agreed.

[NeffIsBack]

Hi and thanks for the feature request.

read the hives back over SMB from the snapshot

This is the critical part why there is no wmi sam/lsa/ntds dumping via the wmi protocol yet, we have not figured out how to properly transmit larger files via wmi yet. If this is solved we could easily implement it directly into wmi.

Please note that communication on this repository should be human to human (see AI policy), so please respond in your own words. Issues should also not be AI generated.

[hakimonr]

Hi Alex, thanks for the feedback. And also thanks for AI policy reminder.

To clarify file transfer via the wmi protocol: the files are not transferred over wmi. Wmi is only used to create the shadow copy on the target. After that, the hives are downloaded over the normal SMB connection impacket already has this exact code path (createSSandDownloadWMI) and it is in the version NetExec currently pins, so no need for a new dependency.

I put this on the smb protocol since smb already has file transfer capability, so the "large files over wmi" problem never comes up here.

I have a prototype ready (only 2 files changed, no new deps). I verified the approach in an EDR-protected environment during an engagement as i mentioned before, nxc code passes the existing tests but i haven't tested it against a live target yet since the engagement is already done. Happy to open a PR if you'd like to see it.

[NeffIsBack]

To clarify file transfer via the wmi protocol: the files are not transferred over wmi. Wmi is only used to create the shadow copy on the target. After that, the hives are downloaded over the normal SMB connection impacket already has this exact code path (createSSandDownloadWMI) and it is in the version NetExec currently pins, so no need for a new dependency.

I put this on the smb protocol since smb already has file transfer capability, so the "large files over wmi" problem never comes up here.

Hi, yeah that is kind of the point. It would have been nice to finally have sam/lsa dumps over the WMI protocol and since this is native wmi anyway it would have been a good opportunity, but then let's add it to SMB for now to bypass the file download restriction until we find a good solution. Feel free to open up a PR so we can take a look at it.

[hakimonr]

Thanks for the quick reply, I really appreciate it. I am opening the pr in a minute.