The embedded gokrb5/v8 library hard-coded net.DialTimeout for AS/TGS
exchanges, bypassing -proxy and leaking the operator's source IP to the
KDC (UDP/88 first, TCP/88 fallback). The DCERPC Kerberos auth path used
a separate library (oiweiwei/gokrb5.fork/v9 via go-msrpc) that leaked the
same way.
Vendor jcmturner/gokrb5/v8 in-tree at pkg/third_party/gokrb5 with a
required KDCDialer first argument on every client constructor, so
proxy-bypass becomes a compile error. Wire kerberos.TransportKDCDialer
everywhere a gokrb5 client is built. Stamp udp_preference_limit=1 and
dns_lookup_kdc/realm=false unconditionally so KRB5 is TCP-only and the
OS resolver is never consulted; /etc/krb5.conf and $KRB5_CONFIG are
deliberately not read.
For DCERPC: set krbConfig.KDCDialer on every krb5.Config, pass
dcerpc.WithDialer(transport.ContextDialer{}) on every dcerpc.Dial, and
use the "ncacn_ip_tcp:" StringBinding prefix on the OXID-pivot dial so
go-msrpc's hard-coded pre-dial net.LookupIP is skipped (defers FQDN
resolution to the SOCKS5 proxy).
Verified against a live GOAD lab: 8 Kerberos-touching tools plus 5
NTLM/password/PtH regressions all operate through SOCKS5 with zero
direct packets to the AD subnet. Negative control (no -proxy)
immediately emits direct SYNs to the KDC, confirming both the leak
class and the fix.
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.
readCell trusted the cell's size header without bounds-checking the
positive side, so any cell whose raw size field was 0 or a negative
value with absolute magnitude smaller than the 4-byte cell header
produced an inverted slice expression (h.data[pos+4 : pos+size] with
size < 4) and crashed the process. Reported as a runtime panic
`slice bounds out of range [5052:5048]` in secretsdump's cached
domain logon parse path.
Treat raw size >= 0 as free/invalid (return error) and require the
allocated size to be at least 4 bytes so the data slice is never
inverted. Regression test synthesizes a minimal hive with each of
the previously-panicking inputs.
Removes the now-resolved entry from KNOWN_ISSUES.md and renumbers
the remaining sections.
- README.md: expand "Proxychains Support" into "Proxy Support" with
two subsections (proxychains via LD_PRELOAD, and the new -proxy
SOCKS5 flag). Adds -proxy to the Common Flags table, adds a quick
example, and updates the final Notes line so "all tools work
through proxychains" also covers -proxy.
- KNOWN_ISSUES.md: add entry #8 "UDP Features Disabled Under -proxy"
with a table mapping affected tools to concrete workarounds
(supply -port directly, pass -dc-host / -dc-ip / -target-ip,
supply -parent-dc). Renumbers "Remaining Gaps" to #9.
Jacob Paullus