Network Forensics

Analysis

Network forensics reconstructs what communicated, when, how much data moved, and which controls observed it. Use PCAP, DNS, proxy, firewall, NetFlow, EDR, and cloud flow logs together; no single source tells the whole story.

Preserve Raw Logs First

Export raw PCAPs and logs before filtering or enrichment. Keep the original timezone, collection source, query filters, and hash values so the investigation can be reproduced.

PCAP Triage Workflow

Answer the timing question first, because every later question depends on it. Extract fields with -T fields and carry frame.time_epoch through the pipeline, then sort on that column numerically — a plain sort -u reorders the output lexically and destroys the sequence you are trying to establish.

network-forensics-triage.sh

# Capture or inspect metadata
tcpdump -nn -r capture.pcap | head
capinfos capture.pcap
sha256sum capture.pcap > capture.pcap.sha256

# Protocol and conversation overview
tshark -r capture.pcap -q -z io,phs
tshark -r capture.pcap -q -z conv,ip
tshark -r capture.pcap -q -z endpoints,ip

# Start, duration and byte counts per TCP conversation
tshark -r capture.pcap -q -z conv,tcp

# Per-minute activity, to see when traffic began and stopped
tshark -r capture.pcap -q -z io,stat,60

# DNS queries in arrival order, de-duplicated on the queried name
tshark -r capture.pcap -Y "dns.qry.name" -T fields \
  -e frame.time_epoch -e ip.src -e dns.qry.name -E separator=/t \
  | awk -F'\t' '!seen[$3]++' | sort -t $'\t' -k1,1g

# HTTP requests, chronological (tshark emits in frame order)
tshark -r capture.pcap -Y "http.request" -T fields -e frame.time_epoch -e ip.src -e http.host -e http.request.uri

# Zeek protocol extraction
zeek -r capture.pcap
cat conn.log
cat dns.log
cat http.log
cat ssl.log
cat files.log

The awk stage keeps the first occurrence of each query name in frame order, so the timestamp you keep is the one that matters for first contact; the final numeric sort then guarantees the reader sees ascending time rather than hash order. If you only need the shape of the activity, io,stat,60 answers "when did it start and stop" faster than any field extraction.

Investigation Questions

Scope

Which internal systems contacted the indicator?
Was traffic inbound, outbound, or lateral?
When did communication start and stop?
Which identity or host telemetry correlates with the session?

Impact

How much data moved and in which direction?
Were files, credentials, tokens, or archives transferred?
Did TLS inspection or proxy logs reveal hostnames or URLs?
Did controls block, allow, or alert on the activity?

Common Signals

Signal	Why It Matters	Correlate With
Regular beacon intervals	May indicate automated callback or health check behavior.	EDR process tree, DNS logs.
Long DNS labels	Can indicate tunneling or encoded data.	Resolver logs, endpoint command history.
Large outbound transfers	Potential exfiltration or backup/sync behavior.	Proxy, DLP, cloud storage audit logs.
Rare user agents	Can reveal non-standard tooling or outdated libraries.	Asset inventory, application logs.

Reporting Output

network-forensics-finding.yaml

finding: suspicious outbound transfer
source: firewall-flow-export
window_utc: 2026-05-26T14:10:00Z/2026-05-26T14:40:00Z
internal_hosts:
  - 10.10.24.15
external_destinations:
  - example[.]net
volume: 1.8GB outbound
correlation:
  - endpoint process created archive before transfer
  - proxy allowed destination with no category
  - no DLP alert generated
recommended_actions:
  - preserve endpoint image and user context
  - block destination pending review
  - tune egress alerting for high-volume rare destinations

Linux Forensics

The host-side logs — journald, sudo, cron — that explain who ran the process behind a flow.

Incident Response

Turning a network finding into contain-or-monitor decisions without destroying the packets.

Timeline Analysis

Merging flow, DNS and host events into one normalized timeline.