Netcap turns packets into typed audit records, then links them back to a connection

Packets in, typed records out, and why that differs from tcpdump

Netcap converts network packets into structured, type-safe Protocol Buffer audit records. It is positioned for security monitoring, forensic analysis and machine learning.

The distinction from a packet tool is worth being precise about. A capture tool gives you packets, which are bytes with timestamps. Netcap gives you records, which are typed fields with meaning: a DNS query record has a question name and an answer set, an HTTP record has a method and a status, a TLS record has a JA4 fingerprint. Once you have typed records, they can be indexed, filtered by field and joined with each other, which is what makes the analysis features possible.

The decode coverage is stated precisely. 83 packet-layer decoders covering Ethernet, IPv4 and IPv6, TCP, UDP, DNS, DHCP, ARP, TLS ClientHello and ServerHello, ICMP, NTP, SIP, OSPF, BGP, MPLS, GRE, VXLAN and 802.11 among others. 40+ stream decoders covering TLS, SSH, HTTP/2, QUIC, SMB, FTP, SMTP, POP3, IMAP, IRC, Kerberos and DCERPC. Industrial protocols get their own line: Modbus, S7Comm, DNP3, OPC-UA, PROFINET, BACnet, CIP and IEC 62351. There is full TCP and UDP stream reassembly with configurable limits.

That last clause is the practical constraint. Stream reassembly is where a decoder either becomes useful or becomes a memory leak, and "configurable limits" is how Netcap admits it needs bounds.

It is packaged as a single Go binary with a concurrent architecture and a built-in web UI. The web UI is React with Vite and TypeScript, running in service mode.

Evidence linking: from any record back to the connection, DNS answer and alerts

The recent release titles say what the project is working on: v0.12.0 added hunting evidence, and v0.13.0 added linked hunting evidence. Both landed within two days of each other in October 2026, and v0.11.0 the day before.

The feature they refer to is the part of Netcap with real analyst leverage. From any record you can list the records of the same connection, the DNS answer that resolved its destination, the connections opened to an answered address, and any alerts, presented as a timeline. Related-evidence timeline appears on both alerts and connections in the web UI.

That is correlation assembled for you. The alternative is to write the joins yourself across whatever query interface you have, and the join keys are the hard part: matching a flow to the DNS answer that named its destination, then to every other flow that went to that resolved address, then to the alert that fired on any of them.

Hunting evidence is the substrate under it. The README describes DNS query and response pairing with RTT, retransmission and unanswered or late status over both UDP and TCP. DCE/RPC calls attributed to interface and operation with fault outcomes. Periodic connection detection tagged `c2.beacon`. And a signed producer to consumer byte ratio per connection.

DNS pairing is the one that changes what you can ask. A query without an answer, or a query answered late, is a different signal from a query answered immediately, and if your records only contain the two halves separately you have to reconstruct that pairing yourself.

For OT and ICS, function-code level Siemens S7comm detection covers write, logic download, logic theft, PLC stop and CPU restart, mapped to CISA advisory AA26-231A, and the example rule ships at `internal/rules/examples/s7comm_hunt.yml`.

Detection rules are YAML categories evaluated by an expression engine

Netcap ships 30+ YAML rule categories covering reconnaissance, exfiltration, web attacks and industrial ports among others, evaluated by an expression engine rather than hardcoded logic.

The engine features named in the README are specific enough to be useful. Source to distinct-destination cardinality, which is fan-out detection: one source talking to many destinations is the shape of both scanning and exfiltration. An approved-workstation allowlist exposed as `IsApprovedWorkstation`, so that hosts you have decided are scanners do not generate noise. And time-of-day helpers, `IsBusinessHours` and `HourOfDay`, which let a rule care about when something happened.

That last category is the interesting one for a tool that also monitors OT environments, where the answer to "is this connection unusual" is often "not at 4am on a Sunday in a plant that is shut down".

Rules live as YAML and can be expressed as policy. The network detection layer is separate and enabled at capture time independently of baseline approval, with `-network-detection=false` to turn it off and `-network-detection-config policy.json` to load bounded JSON thresholds, authorised source IPs and CIDRs, and versioned indicators.

Alongside rules sit three analysis features worth distinguishing from each other. JA4 TLS client fingerprinting, where the README notes JA4 is BSD licensed while external JA4+ support is available only in opt-in local source builds subject to the FoxIO License. YARA scanning with compiled yara-x rules for malware detection. And Magika, Google's AI-based file type classification, applied to extracted files.

File extraction covers HTTP, FTP, SMTP, POP3, IMAP, SMB and IRC, with MD5, SHA1 and SHA256 hashing and MIME detection. Credential harvesting is described as configurable and protocol-aware.

Building it: libpcap, or the nodpi tag that drops the C dependency

Pre-built binaries are on the Releases page, so building is optional. If you do build, the choice is between three variants, and the reason for the second is the interesting part.

The README presents them as a single commented block:

# Build (requires libpcap)
go build -o net ./cmd/net/

# Build without DPI (fewer C dependencies)
go build -tags=nodpi -o net ./cmd/net/

The DPI line is optional Deep Packet Inspection through nDPI or libprotoident. Because that is a C library, the default build needs cgo and its headers, which is the portability tax on the whole tool. The `nodpi` tag trades that capability for a binary that builds anywhere Go builds.

The third variant adds acceleration:

CGO_ENABLED=1 go build -tags hyperscan -o net ./cmd/net/

That requires libhs via pkg-config, with `brew install vectorscan` given as the macOS example, and the README states what it buys: a multi-pattern regex prefilter for nmap service probes at roughly 2.2 times faster, CMS and web framework detection at roughly 1.4 times, and the rule engine's `MatchesPattern` up to about 6 times on miss-heavy detection traffic. Those speedup figures are the project's own documentation claims, not measurements made elsewhere, and the miss-heavy qualifier matters because the gain is largest exactly where you have many non-matches.

Then three ways to run it:

./net capture -read traffic.pcap
sudo ./net capture -iface en0
./net capture -read traffic.pcap --service

The last starts the web UI. The `-iface` form needs root, which is the ordinary requirement for reading a live interface.

The `go.mod` declares `go 1.27.0`, while the README badge reads Go 1.25. Trust the `go.mod`, since that is what the toolchain enforces.

Output formats and enrichment decide where the records can go next

Four output formats are documented, and they map to four different downstream choices.

Protocol Buffers is the default, described as compact binary and accessible from any language. CSV has configurable separators for data analysis pipelines. JSON is the human-readable structured option. And Elasticsearch goes direct via bulk indexing for ELK stack analysis.

The default matters because it commits you early. Protocol Buffers is the right answer if you will query the records programmatically, since the record types are generated and typed, but it locks you into the schema as of the version that produced it. JSON costs more space for the same data and is the one to choose if a human is going to read the output.

Enrichment is what happens before a record is written, and the list shows how much of the metadata Netcap resolves on its own: DNS reverse resolution, GeoIP geolocation and ASN, and MAC vendor lookup.

The GeoIP detail is a licensing and configuration choice rather than a technical one. A bundled DB-IP Lite database ships with optional user-installed GeoLite2, and providers are selected with `-geoProviders dbip,geolite2` in that default order, or through the Databases page in the web UI.

Integrations are listed as Prometheus with Grafana for real-time metrics, Elasticsearch with Kibana for full-text search, and Maltego for 45+ OSINT entity types and transforms. The Maltego integration is the unusual one: it exports Netcap's decoded records into a graph tool built for pivoting, which is a different analytical workflow from querying a log store.

Distributed capture puts a TLS trust boundary between agent and collector

Netcap can run capture on many hosts and collect centrally, and the transport design is the part worth examining.

Agents stream audit records to a collection server over mutually authenticated TLS 1.3, with pinned keys, acknowledged delivery and reconnects. The documentation lives at `docs/distributed-collection.md`.

Each of those four properties addresses a specific failure. Mutual authentication means an agent will not ship your traffic to a collector that cannot prove it is your collector. TLS 1.3 with pinned keys means a compromised certificate authority cannot be used to intercept. Acknowledged delivery means the sender knows whether records landed, which turns a silent drop into a retryable event. And reconnects means a collector restart does not require restarting every agent.

That is a careful design for the component that leaves your network boundary, which is the component that matters most.

The repository layout suggests a more conventional development setup than the feature list implies. There is a Makefile whose header notes that building, releasing, code generation and the Docker images are driven by `zeus`, with `zeus/commands.yml` holding 81 commands, and the Makefile itself covering test and coverage entrypoints. The test targets are unusually granular: unit tests with `-short -race` and coverage, integration tests behind a build tag, regression tests that compare complete captures across worker counts and runs, golden file verification, Wireshark corpus tests, and separate fuzz, benchmark and Hyperscan targets.

The regression tests are worth noting for anyone worried about correctness of a concurrent decoder: they assert that the same capture produces the same output regardless of how many workers process it, and that repeated runs are repeatable.

What it costs and where it is the wrong tool

Two things to weigh before committing.

The first is the build and dependency surface. The default build needs libpcap and cgo; DPI adds nDPI or libprotoident; Hyperscan adds libhs. The `go.mod` is large, pulling in yara-x, gopacket, go-elasticsearch, Maltego bindings, Chromaprint-style TLS tooling, Prometheus client, Magika-adjacent dependencies, MCP tooling and others. That is a lot of native surface for a network sensor, and it is why the `nodpi` tag exists.

The second is licensing, and it is not uniform. The project is GPL-3.0, which is the licence you adopt for the software itself. JA4 fingerprinting is BSD licensed. External JA4+ support is available only in opt-in local source builds and is subject to the FoxIO License, so shipping a binary with JA4+ compiled in is a different licensing question from shipping the default build. There is a `legal/` directory and a `licenses.go` with a corresponding `licenses_test.go` at the repository root, which suggests the project tracks its own dependency licences deliberately rather than incidentally.

As for when not to use it: if you want a lightweight live tap that forwards flows to a collector and nothing else, Netcap is the wrong shape, because you are taking on a full decoding framework and its storage. If you have no need for packet-derived records at all, a flow-level tool answers a different and cheaper question.

On maintenance, the repository is not archived and the last push was on 2026-10-13, with v0.13.0 tagged on 2026-10-09. Three releases in four days is a fast cadence, which suits an actively developed tool and makes version pinning in long-lived deployments worth doing deliberately.

Editorial conclusion

Adopt Netcap if you need long-term packet-derived records you can query, index and correlate across connections, on Linux, macOS or Windows, with a Go toolchain at 1.27 or newer to build from source. Do not adopt it as a lightweight live sensor, since it is a full decoding and storage framework rather than a minimal tap, and note the licensing split before shipping JA4+ to anyone. Verify first that you can build it, either with libpcap or with the `nodpi` tag that drops the C dependency, and that the output format you need is one of the four documented, Protocol Buffers, CSV, JSON or Elasticsearch.

Frequently asked questions

Official sources

1. dreadl0ck/netcap on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases