Mandiant's gopacket is a complete Go port of impacket shipping 63 CLI tools and 24 protocol libraries, intended for authorized Active Directory assessments and defensive research.

gopacket is Mandiant's ground-up Go reimplementation of the venerable impacket library, and the scale of the port is the first thing that stands out: 63 command-line tools and 24 reusable protocol packages, all compiling to native Go binaries with no Python runtime dependency. The README positions it explicitly as a framework, not just a script collection — you can import the packages under pkg/ independently and build your own tooling on top of them. The author, Jacob Paullus, frames the project as solving a perennial operational annoyance: impacket is powerful but drags a Python interpreter and dependency tree everywhere it goes, while a Go build gives you compile-once, run-anywhere binaries.

The README is candid about maturity. A prominent beta warning states the code is highly experimental, that core tools have been tested against Active Directory lab environments, and that protocol quirks and edge cases are expected. The suggested debugging workflow is telling: reproduce the same operation with original impacket side-by-side and attach both outputs to bug reports, which cleanly distinguishes gopacket-specific bugs from shared protocol limitations. That instruction doubles as evidence of how faithful the port aims to be — behavioral parity with impacket is the acceptance criterion.

Installation is handled by a single script: ./install.sh after cloning the repository. The default native build targets Linux and macOS, installing into /usr/local/bin, while --target portable produces static Linux binaries and --target windows cross-compiles .exe files into ./dist/windows/. The native path requires Go 1.24.13+, GCC, and libpcap development headers (libpcap-dev on Debian-family systems, libpcap-devel on RHEL, or brew install libpcap on macOS), because a handful of tools bind to packet capture through cgo. An --uninstall flag exists, and make build is offered as an alternative entry point — small operational hygiene details that suggest this is meant for real toolchains, not disposable containers.

The platform matrix is more nuanced than a casual read suggests. Full 63-tool availability only exists on Linux/macOS with cgo enabled. A CGO_ENABLED=0 Linux build drops to 61 tools, with sniff and split becoming stubs, and a Windows build drops to 60, additionally stubbing sniffer. The engineering decision here is worth appreciating: rather than failing the build, gopacket substitutes stubs that print a clear message and exit with status 1, so go build ./... always succeeds and the install layout stays consistent across platforms. Anyone maintaining cross-platform tooling knows this is the difference between a clean release pipeline and a debugging session.

The tool inventory mirrors impacket's familiar taxonomy almost one-to-one. Remote execution utilities include psexec, smbexec, wmiexec, dcomexec, and atexec. Credential-related tooling covers secretsdump for SAM/LSA/NTDS extraction and DCSync, plus dpapi, esentutl, and registry-read for offline artifact parsing. The Kerberos suite is unusually complete — getTGT, getST, GetUserSPNs, GetNPUsers, ticketer, ticketConverter, describeTicket, getPac, keylistattack, and raiseChild — and the AD enumeration set spans GetADUsers, GetADComputers, GetLAPSPassword, findDelegation, lookupsid, samrdump, rpcdump, net, netview, CheckLDAPStatus, and more. From a documentary standpoint, the value is that every capability is documented and therefore mappable to detection engineering.

The single largest component is ntlmrelayx, a full NTLM relay framework. The README details capture servers for SMB, HTTP/HTTPS, WCF (ADWS), RAW, RPC, and WinRM, relay clients for SMB, LDAP/LDAPS, HTTP, MSSQL, WinRM, and RPC, and a long list of downstream attack modules including delegation manipulation, ACL abuse, shadow credentials, ADCS ESC8, and DNS manipulation, plus operational infrastructure like a SOCKS5 proxy with protocol-aware plugins, an interactive console, a REST API, and multi-target round-robin. For defenders, this paragraph of the README is effectively a curriculum: every named capability corresponds to a hardening control and a detection opportunity.

Proxy support receives unusual engineering attention, and it is the most technically interesting part of the README for anyone who has fought Go binaries and proxychains. Because Go's runtime handles DNS and networking internally, it normally bypasses the LD_PRELOAD hooks proxychains depends on; gopacket works around this by linking against the system C library for network operations so interception works normally. Independently, every tool accepts a -proxy flag routing outbound TCP through a SOCKS5 server (socks5 or socks5h schemes), with ALL_PROXY as an environment fallback — for example gopacket-secretsdump -proxy socks5h://127.0.0.1:1080 in a lab. The two mechanisms chain, and UDP-dependent features are deliberately disabled under -proxy rather than silently leaking packets outside the tunnel, a leak-avoidance decision documented in KNOWN_ISSUES.md.

Authentication is uniform across all network tools, which matters for both operators and blue teams. Three methods are supported: plaintext password, NTLM hash via -hashes LMHASH:NTHASH, and Kerberos via -k -no-pass with a KRB5CCNAME ticket file. Common flags — -dc-ip, -target-ip, -port, -debug — follow the impacket convention, which flattens the learning curve for anyone migrating. The consistent authentication surface is also analytically useful: from the defensive side, it means tool behavior is predictable and the resulting Windows event log signatures (logon events, Kerberos ticket requests, DRSUAPI replication) are stable baselines for detection rules.

The library layer under pkg/ is arguably the strategic piece. The 24 packages include smb (SMB2/3 with NTLM and Kerberos), ldap (with NTLM/Kerberos bind), dcerpc (with roughly 20 service implementations such as DRSUAPI, SAMR, SVCCTL, LSARPC, WINREG, NETLOGON, and EPMAPPER), kerberos (including ticket parsing and S4U extensions), ntlm, and relay. A wiki serves as the Library Developer Guide with API documentation and architecture notes for building custom tools. This shifts gopacket from a script replacement toward a foundation — the same trajectory impacket itself took as it became the substrate beneath much of the AD attack tooling ecosystem.

Where does this fit in an authorized workflow? For consultants and internal red teams, the pitch is operational simplicity: a single static binary set that runs on hardened assessment hosts without dependency churn, with clean SOCKS5 integration for lab pivot architectures. For purple teams, the parity with impacket means existing detection content for impacket-style activity — service creation from psexec-family tools, DCSync replication patterns, Kerberoasting ticket requests, NTLM relay logon anomalies — can be validated against a second independent implementation, which is genuinely useful for ruling out tool-specific false positives.

Caveats worth flagging: this is a beta, the maintainer's own warning says edge cases are expected, and libpcap-dependent tools are platform-conditional. Anyone adopting it for engagements should version-pin builds, test in a lab first as the README itself instructs, and keep original impacket on hand for differential testing. But as an engineering artifact — a complete, proxied, statically compiled reimplementation of the most important Windows protocol toolkit in the field — gopacket is a significant release, and the 707 stars it has collected suggest the community has noticed.

Educational analysis for authorized security professionals. Use only in controlled, authorized environments.