mirror of
https://github.com/mandiant/gopacket
synced 2026-06-21 13:57:02 +00:00
psycep
abbdbc19be
Two entries in KNOWN_ISSUES.md described the relay samdump/secretsdump attacks as broken in ways they aren't, or fixable in ways we hadn't tried. Verified both live against GOAD and retired them. KNOWN_ISSUES #1 ("SMB Relay Registry Access Denied") Reproduced by coercing WINTERFELL$ via PetitPotam to relay-samdump against srv02: BaseRegOpenKey(SYSTEM\Select) returns 0x00000005 as documented. Then reproduced the documented "workaround works" direction with NORTH\administrator direct auth (dumps cleanly). Then the test the entry never tried: relayed a user with admin on the target via cmd /c net use \\relay\IPC$ /user:north\eddard.stark (Domain Admin) on dc02, watched it flow through our relay to srv02. Result: dumped Administrator, Guest, DefaultAccount, WDAGUtilityAccount, vagrant SAM hashes cleanly. So the relay transport does not drop privilege. The symptom the entry captured was simply "relayed principal doesn't have admin on target", which is the same precondition Impacket's ntlmrelayx samdump has, and the same constraint a direct secretsdump has. Rewrote the entry to say that plainly and flag the PetitPotam pitfall (DC$ machine accounts aren't admin on member servers, so coercion-to-relay against member servers with default inventory always hits this). Small alignment-with-Impacket change while there: pkg/dcerpc/winreg/ remote.go and pkg/relay/secretsdump_attack.go now request MAXIMUM_ALLOWED on the boot-key subkey opens instead of KEY_READ, matching rrp.hBaseRegOpenKey's default in Impacket. KEY_READ demands the full read bundle; MAXIMUM_ALLOWED returns a handle with whatever the token actually has. Doesn't fix the ACCESS_DENIED on a no-admin token, but reduces the surface for partial-access edge cases. KNOWN_ISSUES #3 ("Intermittent PIPE_NOT_AVAILABLE on winreg") Same failure mode the standalone secretsdump handles already: if RemoteRegistry is stopped or disabled, opening the winreg named pipe fails with STATUS_PIPE_NOT_AVAILABLE. Standalone tools/secretsdump opens svcctl first, starts RemoteRegistry, runs the attack, then stops the service (and restores SERVICE_DISABLED if it was disabled). The relay path wasn't doing any of that. Factored the "ensure started on entry / restore on exit" flow into pkg/relay/remoteregistry.go and wired it into both relay samdump and secretsdump attacks via TreeConnect("IPC$"), open svcctl, manage RemoteRegistry, proceed with winreg. Failures to manage the service are logged as warnings rather than returned as errors: if the relayed token lacks SERVICE_* access, the attack still tries the winreg open and often succeeds (if the service happens to be running already). Verified live: set srv02 RemoteRegistry to Stopped+Manual, relayed eddard.stark (Domain Admin via net use), watched: [*] Service RemoteRegistry is in stopped state [*] Starting service RemoteRegistry [*] Target system bootKey: 0x... [*] Dumping local SAM hashes Administrator:500:...:...::: (etc) [*] Cleanup complete Cleanup's attempt to stop the service after dumping gets a STATUS_OBJECT_NAME_NOT_FOUND (pipe was closed by the post-attack session teardown); that warning is cosmetic. The service's start-type was preserved (Manual), only its current state stayed Running. Leaving that as a minor follow-up rather than blocking the fix. KNOWN_ISSUES.md renumbered to reflect the two retirements.