PCAP Agent

Why the packet capture agent is local

PCAP Agent is for looking at traffic on a network interface you have chosen and are allowed to capture from. Privileged packet capture happens in a native local Go agent through libpcap or Npcap; the browser is the dashboard, not the capture engine. That split lets the site present useful observations without pretending a web page can directly inspect a visitor's network.

The local agent observes selected TCP, UDP, and ICMP traffic, keeps selected metadata in memory, and makes it available to a browser dashboard. It is a practical way to inspect flows, DNS activity, protocol statistics, top talkers, and a few deliberately conservative observations without claiming to be an IDS. In normal mode, the hosted dashboard connects back to an agent on the same machine over a loopback WebSocket.

Metadata analysis, not payload relay

selected interface → local Go agent → in-memory metadata → loopback WebSocket → browser dashboard

The capture filter is installed before packets enter the analysis path. PCAP Agent tracks flow and TCP-session metadata, DNS questions and available answers, aggregate counters, protocol distribution, and MAC/vendor context where available. It can point out periodic connection attempts, retransmissions, resets, and possible scan patterns, but those are observations for investigation—not proof that a host is compromised.

Raw packet payloads are neither placed in WebSocket messages nor sent to the optional relay. That boundary matters: flow, endpoint, DNS, and statistics data can support local reasoning while payload content carries a different privacy and handling burden. Relay mode requires confirmation before flow metadata is sent to the service and provides a session-specific dashboard URL; normal local mode stays on 127.0.0.1 with ws://localhost:7777/ws.

What it takes to run

Live capture has platform realities. Windows needs Npcap and an elevated terminal; Linux needs libpcap headers plus an appropriate capture permission; macOS uses libpcap with suitable privilege. Building from source also needs Go, CGO, a C compiler, and capture headers. Prebuilt releases avoid the build toolchain but not the capture driver and permission boundary.

The normal workflow is to start the local agent, let it select an interface or choose one explicitly, and then open the dashboard. A virtual adapter, VPN, VM, or container host is a good reason to inspect the available interfaces rather than relying on automatic selection.

pcap-agent list-interfaces
pcap-agent start --interface <interface>

What the observations mean

Encrypted protocol contents are not decrypted. The default filter intentionally excludes traffic outside TCP, UDP, and ICMP. DNS support is query and answer visibility only; PCAP Agent does not claim DNS-tunneling detection, and threat-intelligence enrichment is not wired into the capture pipeline. The separate Security Enrichment service can provide indicator context, but it is not part of a PCAP Agent capture result today.

Network behavior is noisy. A periodic connection is not automatically malware, a retransmission is not automatically an attack, a reset is not automatically malicious, and a locally administered MAC can be a normal privacy feature. Possible scan-like activity needs packet context, endpoint ownership, and operator judgment before it becomes a security conclusion.

Sources and further reading

PCAP Agent README (commit eb8519c) · Agent entrypoint (commit eb8519c)