go-secdump reads the Windows registry over SMB without putting hives on disk

Registry secrets over SMB, with nothing written to disk

go-secdump is described as a tool built to remotely extract hashes from the SAM registry hive as well as LSA secrets and cached hashes from the SECURITY hive without any remote agent and without touching disk.

That last clause is the whole design goal. The conventional way to extract these secrets is to save the hives with reg save and parse them locally, and every environment you use that in leaves a SAM and SECURITY copy in a temp directory on a machine you may not own. Reading the keys directly over the Remote Registry service avoids that artifact entirely.

The implementation sits on the go-smb library and uses it to communicate with the Windows Remote Registry to retrieve registry keys directly from memory. The go.mod pins github.com/jfjallid/go-smb at v0.11.0.

The author is explicit about the provenance. The code is inspired by and taken from Impacket's secdump, but converted to access the Windows registry remotely and to only access the required registry keys. So the parsing logic is borrowed from a well known Python tool and the transport is the new part.

The README also states plainly that the tool was built as a learning experience and as a proof of concept that it should be possible to remotely retrieve the NT hashes from the SAM hive and the LSA secrets as well as domain cached credentials without having to first save the registry hives to disk and then parse them locally.

That framing matters for how you read the rest of it. This is a red team tool that an author wrote to understand the mechanism, and the release history shows it being actively refined. The last push was on 2026-07-06, with the newest release v0.7.2 on the same day.

The permission problem, and the privilege that solves it cleanly

The interesting technical content is in the section on why the tool works at all.

The main problem to overcome was that the SAM and SECURITY hives are only readable by NT AUTHORITY\SYSTEM. The first approach the author found was that the local group administrators had the WriteDACL permission on the registry hives and could thus be used to temporarily grant read access to itself to retrieve the secrets and then restore the original permissions.

That works, and it is the technique behind several older tools. The problem is that it modifies the target.

A better approach was discovered in February 2025 by Julien Egloff at Synacktiv. The BaseRegOpenKey request used to open handles to registry keys has an option to assert the SeBackupPrivilege, which allows the registry keys to be opened without first changing the DACLs.

The tool has been updated to prefer this new approach and only change the DACLs if asked nicely. That is a significant change in behaviour and it is visible in the command line. The --modify-dacl flag is the explicit opt-in to the old path, and the README notes it is only required if keys cannot be opened using SeBackupPrivilege, with a default of false.

So the current default is the clean path: assert a privilege you already hold and read the keys without touching their permissions. The DACL rewrite is now the fallback rather than the mechanism.

The Synacktiv publication, LSA Secrets: revisiting secretsdump, is credited as the source of the idea, and the README links it alongside references on registry structure and encryption from Passcape and Beginning to See the Light.

Authentication: password, hash, Kerberos or keytab

The command line is long, and the authentication section of it is the part worth reading in full because it shows how much of the red team operator's toolkit has been folded in.

Usage: ./go-secdump [options]

options:
      --host <target>        Hostname or ip address of remote server. Must be hostname when using Kerberos
  -P, --port <port>          SMB Port (default 445)
  -d, --domain <domain>      Domain name to use for login
  -u, --user <username>      Username
  -p, --pass <pass>          Password
  -n, --no-pass              Disable password prompt and send no credentials
      --hash <NT Hash>       Hex encoded NT Hash for user password
      --local                Authenticate as a local user instead of domain user
  -k, --kerberos             Use Kerberos authentication. (KRB5CCNAME will be checked on Linux)

Password authentication is the obvious case, with --no-pass available for a null session attempt that sends no credentials. Passing a hex encoded NT hash with --hash is the pass-the-hash route, and --local switches the login from a domain user to a local user.

Kerberos is a first-class option rather than an add-on. The -k flag turns it on and the tool notes that KRB5CCNAME will be checked on Linux, which is the standard environment variable for a Kerberos credential cache. Three flags support it further: --dc-ip to point at a specific KDC, --target-ip to give the target's address separately from the hostname, and --aes-key to supply a hex encoded AES128/256 key.

The --keytab-file option implies Kerberos, and the README states that the user and domain are taken from the first keytab entry if not specified. There is also --dns-host to override the system's default DNS resolver and --dns-tcp to force lookups over TCP, which the help text says is the default when using --socks-host.

The dependency list matches. github.com/jfjallid/gokrb5/v9 at v9.1.0 handles Kerberos, golang.org/x/crypto and golang.org/x/net are present, and software.sslmate.com/src/go-pkcs12 appears as an indirect dependency, which is the usual way a Kerberos client picks up keytab and PFX support.

Selective targets, and dumping the hives when you need them

By default the tool extracts everything it can, and the four explicit target flags narrow that to specific hives.

--sam extracts secrets from the SAM hive explicitly. --lsa extracts LSA secrets explicitly. --dcc2 extracts DCC2 caches, which are the cached domain credentials of domain users logged in to the machine. --misc extracts misc registry secrets such as the Winlogon DefaultPassword.

Each of those help strings ends with the same sentence: only other explicit targets are included. In other words, specifying one target restricts the run to that target rather than adding to the default set.

There is also --history, which includes historical, OldVal, LSA secrets in addition to current values. That is the mechanism by which a previous SYSTEM user's secrets are recovered.

Then there is --dump, which saves the SAM and SECURITY hives to disk and transfers them to the local machine. That is the opposite of the tool's default behaviour and exists for the cases where you want the raw hives rather than parsed secrets.

Output handling is flexible in a way that suggests the tool is used inside pipelines. The -o flag writes results to a file, defaulting to stdout, and will append to the file if it exists. The --output-format flag takes text as the default, or json, or hashcat. The hashcat format is the one to note, because it means the output drops straight into a cracking workflow.

For quieter use there is -q, which suppresses informational headers and prints only secrets, and -v for the version.

Relay, SOCKS and the DACL restoration problem

Two options stand out because they change what the tool does beyond dumping.

--relay starts an SMB listener that relays incoming NTLM authentications to the remote server and uses that connection. The help text carries a warning that this forces SMB 2.1 without encryption. That is a meaningful downgrade, and it is the sort of thing that is easy to miss in a long option list.

--relay-port sets the listening port, defaulting to 445, which is the same port SMB normally uses, so the listener is trying to be the local endpoint for a redirected connection.

There is also a SOCKS5 path. --socks-host establishes the connection through a SOCKS5 proxy server and --socks-port sets its port, defaulting to 1080.

The DACL handling deserves its own note, and the README has a section on it. Changing DACLs is now an optional feature enabled with --modify-dacl, and the tool automatically tries to modify and then restore the DACLs of the required registry keys. The failure mode is stated: if something goes wrong during the restoration part, such as a network disconnect or other interrupt, the remote registry will be left with the modified DACLs.

That is the kind of state change an assessor has to remember. Three flags help. --backup-dacl saves the original DACLs to disk before modification. --restore-dacl restores the DACLs using the disk backup, which the README says could be useful if the automated restore fails. And --backup-file names that backup file, defaulting to dacl.backup.

So there is a manual recovery path for the one irreversible thing the tool can do to a target.

Building it, and what the dependency list says about scope

There is no install command in the README, so the build path is the Makefile at the top of the repository, and it cross-compiles for both platforms with CGO disabled.

all:
	GOOS=linux GOARCH=amd64 CGO_ENABLED=0 go build -ldflags "-s -w" -o go-secdump
	GOOS=windows GOARCH=amd64 CGO_ENABLED=0 go build -ldflags "-s -w" -o go-secdump.exe .

The -s -w flags strip the symbol table and DWARF data, and CGO_ENABLED=0 makes the build fully static, which is what you want for a binary you are going to push onto a target machine.

The module path is github.com/jfjallid/go-secdump and the go directive is 1.24.0. The direct dependencies are the go-smb library, gokrb5 for Kerberos, golog for logging, and the golang.org/x/crypto, x/net and x/term modules.

The repository itself is small and tells you what the project considers its own code. There is main.go for the command line, sam.go for the SAM parsing, and utils.go, with sam_test.go, utils_test.go and sam_fuzz_test.go beside them. The fuzz test is worth noting, because parsing binary structures that came out of a Windows registry is exactly the kind of code where a fuzzer finds the crash.

There is also a GitHub Actions workflow directory, and the release history shows a v0.5.0 in February 2025 and a v0.4.0 in December 2024, with the v0.7.2 in July 2026. That version progression lines up with the SeBackupPrivilege change in February 2025 mentioned in the README.

The licence is MIT, and the tool is a single maintainer's project with a Discord-free, wiki-free documentation surface: everything an operator needs is in the README's usage block.

Where go-secdump is the wrong tool

Three cases, and the first is the one to settle before anything else.

This tool extracts credential material from Windows machines. It needs existing administrative rights on the target to work at all, because the registry keys it reads are restricted, and it is built for engagements where you hold those rights under a scope agreement. Pointed at a machine you do not own or have permission to test, it is simply credential theft, and the MIT licence says nothing about authorisation.

The second is that the tool is narrow. It reads specific registry keys and parses specific structures. It does not enumerate, it does not move laterally on its own, and it is not a replacement for a full post-exploitation toolkit. If you want to survey a domain's trust paths or read a credential store, there are broader tools that do that and this one is the wrong shape.

The third is operational risk in the DACL path. Even with SeBackupPrivilege available, there are environments where the privilege cannot be asserted and the tool falls back to modifying permissions on the target's registry. If the connection drops during restoration, the target is left in a state you have to fix by hand from a backup file. The README says so plainly, which is to its credit, but it means the tool is not safe to point at a fragile network link without thinking about it.

There is also the relay option to weigh, because it forces SMB 2.1 without encryption. That is a deliberate trade for the operator's convenience in some setups, and it is a downgrade in the security of the channel you are using to hold the credentials you just extracted.

Editorial conclusion

Adopt go-secdump if you are running authorised Windows assessments and want registry secret extraction without writing hives to the target's disk, since that avoids leaving a file behind on a machine you have to clean up. Do not adopt it outside a scope you are authorised to test, and do not expect it to be a general privileged access tool, because it reads specific registry keys and does nothing else. Verify first whether the SeBackupPrivilege path works in your environment, since the DACL modification fallback leaves the remote registry altered if the session drops before restoration.

Frequently asked questions

Official sources

1. Issues
2. jfjallid/go-secdump on GitHub
3. License: MIT
4. README
5. Releases