/analyzing-network-traffic

name: analyzing-network-traffic
description: Analyze packet captures and network telemetry for intrusion evidence — capture and handling, the Wireshark/tshark triage funnel, Zeek log mining, Suricata rule runs, beacon and DNS-tunnel detection, TLS/JA3 fingerprinting, HTTP and file carving, exfiltration hunting, and IOC handoff. Use when a `.pcap` or `.pcapng` capture lands on your desk, when a suspected C2 beacon needs confirming, when there is data exfiltration to investigate, when malware network behaviour must be characterized from what it emitted, when a Zeek or Suricata alert needs running down, or when DNS tunneling or unusual TLS is suspected.
verified: 2026-07-26

Analyzing Network Traffic

Packet capture is ground truth the endpoint can lie about but the wire cannot: every connection, DNS lookup, and byte transferred is recorded, whether or not the host's logs survived. The analysis is turning a flat capture into a story — who talked to whom, over what protocol, whether the pattern was human or automated, and what left the network. You are reconstructing intent from frames, not reading a verdict off a tool.

When to Use

• A `.pcap` / `.pcapng` capture needs forensic review for intrusion evidence
• A suspected C2 beacon must be confirmed and its interval, jitter, and channel characterized
• Data exfiltration is suspected and you need to size it, time it, and name the destination
• Malware network behaviour must be documented from the traffic it actually emitted
• A Zeek `notice.log` or Suricata `eve.json` alert needs to be run down to a verdict
• DNS tunneling, a DGA, or anomalous TLS (odd certs, rare JA3, SNI mismatch) is suspected

When NOT to Use

• **Proactively sweeping endpoint, network, cloud, and identity telemetry for

undetected compromise** — use `hunting-threats`; this skill dissects one capture, a hunt spans data sources

• **Running the wider incident** — use `responding-to-incidents`; traffic

analysis is one evidence stream feeding that process

• **Detonating a sample to *produce* the traffic** — use `analyzing-malware`;

come here to analyze the pcap it emitted, not to run the binary

• **The evidence is cloud control-plane activity, not packets** (CloudTrail,

VPC flow gaps, API calls) — use `investigating-aws-incidents`

• **Actively testing a live application** rather than analyzing a capture of

it — use `testing-web-applications`

Capture and Handling

Get the capture right or every later step inherits the gap. A truncated snaplen or a dropped-packet capture cannot be fixed after the fact.

# Full-frame capture, no name resolution, write to disk (never parse live)
tcpdump -i eth0 -nn -s 0 -w case.pcap
# -s 0 takes full frames; a default snaplen truncates payloads and breaks carving

# Ring buffer for long-running capture: 20 files of 200 MB, oldest recycled
tcpdump -i eth0 -nn -s 0 -w case-%Y%m%d-%H%M%S.pcap -G 3600 -C 200 -W 20

# Capture without dropping under load: raise the kernel buffer, filter tightly
tcpdump -i eth0 -nn -s 0 -B 4096 'not port 22' -w case.pcap
# Confirm drops after: the summary line reports "packets dropped by kernel"

Check whether the capture is intact and what you are holding:

capinfos case.pcap        # packet count, duration, drop stats, snaplen, file type
tshark -r case.pcap -q -z io,phs   # protocol hierarchy — is the snaplen truncating?

• **pcapng vs pcap**: pcapng carries per-packet interface, comments, and name

records; classic `.pcap` is a flat single-link format. `editcap -F libpcap in.pcapng out.pcap` downgrades for a tool that only reads pcap.

• **Split a huge file** so tools and memory cope:

`editcap -c 1000000 big.pcap chunk.pcap` (per packet count) or `editcap -i 600 big.pcap chunk.pcap` (per 600 seconds).

• **Merge** related captures onto one timeline: `mergecap -w all.pcap a.pcap

b.pcap` (sorts by timestamp).

• **Trim to a window** before shipping: `editcap -A "2026-07-26 00:00:00" -B

"2026-07-26 06:00:00" case.pcap window.pcap`.

• **Anonymize** before sharing externally: `tcprewrite`/`bittwiste` to rewrite

addresses, or `editcap -s <snaplen>` to truncate each packet to the first `snaplen` bytes (keeping headers, dropping trailing payload); TraceWrangler for deeper header/payload sanitization. Record what you changed so the recipient does not chase your rewrite as an artifact.

Hash the original and work on copies. `sha256sum case.pcap` goes in the case notes; the evidence file is read-only from here on.

The Triage Funnel

Start wide, narrow to the flows that matter. In Wireshark, work top-down:

• **Statistics > Protocol Hierarchy** — what protocols exist and in what

proportion. Cleartext where you expected TLS, or a sliver of DNS carrying most of the bytes, is the first tell.

• **Statistics > Conversations** — sort by bytes and by duration. The longest

and the largest flows are your first two leads (beacon vs bulk transfer).

• **Statistics > Endpoints** — which hosts talk to the most peers; map internal

vs external at a glance.

• **Follow > TCP/HTTP/TLS Stream** — reassemble one conversation to read it as

the application saw it.

Everything Wireshark does interactively, `tshark` does scriptably — which is how you extract fields across a whole capture instead of clicking:

# Top talkers by bytes
tshark -r case.pcap -q -z conv,tcp

# Extract just the fields you want, tab-separated, for further processing
tshark -r case.pcap -T fields -E separator=/t \
  -e frame.time_epoch -e ip.src -e ip.dst -e tcp.dstport -e frame.len \
  -Y 'tcp.flags.syn==1 && tcp.flags.ack==0'   # every connection attempt

# Every HTTP request: host, method, URI, user-agent
tshark -r case.pcap -T fields -e http.host -e http.request.method \
  -e http.request.uri -e http.user_agent -Y http.request

Display-Filter Fluency

Display filters are the scalpel. The highest-value ones:

| Filter | Surfaces | | --- | --- | | `http.request` | Every outbound H