Introducing PacketStreamer: Distributed Packet Capture for Cloud Native Platforms

PacketStreamer is an open source tool that captures network traffic from multiple remote sources concurrently and aggregates the data into a single pcap log file. It is written in golang and supports network capture from Kubernetes nodes, Docker hosts, and bare-metal/virtual-machine servers.

You can build and install PacketStreamer from GitHub.

Why Network Capture?

One foundation of a good cybersecurity practice is the ability to capture attack actor TTPs (Tactics, Techniques, and Procedures) from across and behind the attack surface. Tools such as Sysdig Falco capture TTP signals from running workloads (process changes, filesystem access, etc.), and can give indications of local compromise, but these signals alone only tell the late-stage story of an attack event.

Organizations need to see a bigger context, and that’s where network capture and analysis comes into play. Observing network traffic can reveal attacker behaviors before a successful compromise, such as reconnaissance activity and weaponization that is targeted at specific vulnerabilities. Observing traffic can also reveal lateral spread and exfiltration activities.

For example, in a log4j exploit, almost all of the initial signals are network-based. The initial JNDI recon against multiple workloads, the JNDI request that then triggers an outgoing request (beacon) to an attacker’s listener, the subsequent request that retrieves the Java class to be run… all of these are network activities and cannot be identified by on-workload sensors. The first signal you get from on-workload telemetry may be the installation of an exploit kit (a crypto-miner for example).

What Can I Do with PacketStreamer?

With PacketStreamer, you can extend your traffic capture activities to span large numbers of target systems. For example, if you run honeypot servers to gather attack TTPs, you can use PacketStreamer to listen for traffic and aggregate all captured traffic on a central receiver.

In the following example, we install PacketStreamer on three honeypot servers: a host with a basic WordPress installation, one with an inviting NGINX configuration that responds to every request with a 200 OK message, and a host running the honeydb service.

Honeypot Server

Our honeypot servers run a range of web and other services, and routinely receive recon traffic from remote hosts. We’ll use packetstreamer to capture the traffic and forward it to the target receiver:

# update sensor-remote.yaml to send traffic to the target
# receiver IP address and port

sudo packetstreamer sensor \
--config contrib/config/sensor-remote.yaml

Receiver Server

Our receiver server is located behind the firewall, listening on port 8081 for traffic from the honeypot sensors:

packetstreamer receiver --config contrib/config/receiver.yaml

The receiver server writes the aggregated capture traffic to a log file, such as /tmp/dump_file. You can watch and process that log file in a variety of ways, such as using tshark to decode selected protocols:

tail -c +1 -f /tmp/dump_file | tshark -r — -Y http
10388 66.320435 178.62.5.62 → 94.200.83.110 HTTP 312 HTTP/1.1 200 OK
10389 66.489650 94.200.83.110 → 178.62.5.62 HTTP 125 POST /wr54jj HTTP/1.1
11905 794.572402 86.171.162.177 → 46.101.77.119 HTTP 416 GET /wp-includes/js/wp-emoji-release.min.js?ver=5.8.4 HTTP/1.1
11907 794.573117 86.171.162.177 → 46.101.77.119 HTTP 441 GET /wp-includes/css/dist/block-library/style.min.css?ver=5.8.4 HTTP/1.1
11909 794.573576 86.171.162.177 → 46.101.77.119 HTTP 408 GET /wp-includes/js/wp-embed.min.js?ver=5.8.4 HTTP/1.1
12558 1204.781243 109.237.103.9 → 178.62.5.62 HTTP 295 GET /.env HTTP/1.1
12580 1205.040161 109.237.103.9 → 178.62.5.62 HTTP 307 GET /.aws/credentials HTTP/1.1
12593 1205.194548 109.237.103.9 → 178.62.5.62 HTTP 86 POST /.aws/credentials HTTP/1.1 (application/x-www-form-urlencoded)
13393 1352.414459 92.53.64.29 → 46.101.77.119 HTTP 599 POST /boaform/admin/formLogin HTTP/1.1 (application/x-www-form-urlencoded)Continuation
19020 3475.869367 91.98.167.220 → 178.62.5.62 HTTP 522 POST /tvm5f7 HTTP/1.1 Continuation
19027 3476.218166 91.98.167.220 → 178.62.5.62 HTTP 522 POST /ep6j56 HTTP/1.1
19042 3478.949728 91.98.167.220 → 178.62.5.62 HTTP 518 POST /y4p8vy HTTP/1.1
22661 4197.353628 2.50.89.16 → 178.62.5.62 HTTP 517 POST /q7e8vf HTTP/1.1 Continuation
22676 4198.930334 2.50.89.16 → 178.62.5.62 HTTP 520 POST /devret HTTP/1.1
24057 4763.594258 92.53.64.29 → 178.62.5.62 HTTP 593 POST /boaform/admin/formLogin HTTP/1.1 (application/x-www-form-urlencoded)Continuation

How Does Deepfence Use PacketStreamer?

PacketStreamer is also an integral part of the Deepfence ThreatStryker product. ThreatStryker gathers attack actor TTPs from cloud workloads and from network traffic. It classifies them to determine the TTP type and potential intent, and correlates the signals to determine how an attack is unfolding in real time.

To the best of our knowledge, there is no other simple, lightweight, scalable method to capture and stream packets from virtualized environments (K8s, VMs, AWS Fargate) and across multiple clouds. We’re open sourcing this tool to enable users to:

• Capture and retain traffic for post facto analysis and forensics
• Support threat-hunting activities across a broad target infrastructure
• Experiment with new approaches such as ML against network traffic to detect anomalies

We’d welcome any feedback, contributions and suggestions. Please start with the PacketStreamer GitHub repository, and feel welcome to join the Deepfence Community Slack.