Network Forensics with Zeek and PCAP Analysis for Defenders

The network sees everything that moves between machines, which makes it one of the most honest witnesses a defender has. An attacker can delete logs on a host, wipe files and unload a rootkit, but if the traffic crossed a monitored link, a record of it can exist independently of the compromised endpoint. Network forensics is the discipline of capturing, reconstructing and interpreting that traffic to understand an incident, and two tools sit at its centre: PCAP, the raw packet capture that preserves the traffic verbatim, and Zeek (formerly Bro), a network security monitor that turns raw packets into rich, structured logs of connections and protocol activity. This guide takes a blue-team perspective: how these tools work, which artefacts answer which questions, how to recognise the signatures of command-and-control and data exfiltration, and the pitfalls that lead to wrong conclusions. The framing is understand in order to defend, focused on detection, hunting and hardening rather than on attacking anyone.

Why network forensics matters#

Endpoint evidence can be tampered with, but the network provides an external vantage point that an attacker who owns a host cannot easily rewrite. If you capture traffic at a choke point such as a firewall span port, a TAP or a cloud traffic mirror, you obtain an independent account of who talked to whom, when, using which protocol and, absent encryption, what was said. This is invaluable for reconstructing the timeline of an intrusion, identifying command-and-control channels, spotting lateral movement between internal hosts, and quantifying what data may have left the environment. Network evidence also scales: a single sensor observes thousands of hosts at once. The trade-off is that pervasive encryption limits content visibility, so modern network forensics leans heavily on metadata, behavioural patterns and protocol anomalies rather than on reading payloads, which is exactly where Zeek excels.

PCAP: the ground truth of traffic#

A PCAP file is a byte-for-byte record of packets as they crossed the wire, captured with tools such as tcpdump, Wireshark's dumpcap, or a dedicated capture appliance. It is the ground truth from which everything else is derived, and its great strength is completeness: given a full-fidelity capture you can reconstruct sessions, extract transferred files, and re-examine the same traffic with new questions later. Its weaknesses are volume and searchability. Full packet capture consumes enormous storage, so many organisations keep only a rolling window of PCAP and retain summarised logs for longer. Analysts open PCAP in Wireshark for deep manual inspection of a specific session, use display filters to isolate conversations, and follow TCP streams to see an exchange in order. PCAP answers the question "exactly what bytes were exchanged?" but it is impractical as the primary hunting surface across weeks of traffic, which is where Zeek's summaries take over.

Zeek: turning packets into evidence#

Zeek watches traffic and produces structured logs describing what happened at the connection and protocol level, rather than alerting on single signatures. From the same traffic it emits conn.log (every connection with duration, bytes and state), dns.log (queries and answers), http.log, ssl.log and x509.log (TLS handshakes and certificates), files.log (files seen traversing the wire with hashes), notice.log (Zeek's own findings) and many more. These logs are compact, searchable and ideal for hunting across long time ranges, and they are commonly shipped into a SIEM or a platform such as the Elastic Stack or Corelight for correlation. The defensive power of Zeek is that it records behaviour, so even when payloads are encrypted you still see the connection metadata, the DNS lookups, the TLS certificate details and the timing, which together reveal a great deal about intent. Zeek is scriptable, so detections can be encoded as policy that runs over live or replayed traffic.

The logs that matter most#

A few Zeek logs carry disproportionate investigative weight. conn.log is the backbone: it lets you profile who talked to whom, how much data moved and in which direction, and it is where beaconing and large outbound transfers first become visible. dns.log exposes name resolution, which matters because malware frequently resolves algorithmically generated or newly registered domains and may abuse DNS itself as a covert channel. ssl.log and x509.log reveal TLS metadata such as server names, certificate issuers and validity, letting you spot self-signed or anomalous certificates without decrypting. http.log shows user agents, hosts and URIs for cleartext web traffic. files.log records transferred files with hashes you can check against threat intelligence. Learning to pivot fluidly between these logs, following a suspicious connection from conn.log into its DNS, TLS and file activity, is the core investigative skill of Zeek-based forensics.

Detecting command-and-control#

Command-and-control traffic is how an attacker steers implants inside your network, and it leaves behavioural fingerprints even when encrypted. The classic signal is beaconing: an implant calls home at regular intervals, producing many small, similarly sized connections to the same destination with a telltale periodicity. In conn.log this appears as a host contacting one external endpoint repeatedly with low but consistent byte counts and near-constant timing, sometimes with a small random jitter that analysts learn to see through. DNS-based C2 shows up as an unusual volume of queries to a single domain or as abnormally long, high-entropy subdomain labels that encode data. TLS-based C2 may present self-signed certificates, rare JA3 client fingerprints or server names that do not match the destination. The defensive method is to baseline normal behaviour and then hunt for the periodic, the rare and the mismatched, corroborating any candidate with endpoint and threat-intelligence evidence before acting.

Detecting data exfiltration#

Exfiltration is the theft of data out of the environment, and network forensics is often the clearest place to detect it. The most direct signal is asymmetric volume: a host that normally receives far more than it sends suddenly transmits a large amount outbound, visible in conn.log as unusually high sent-bytes to an external or unfamiliar destination. Attackers try to blend in by tunnelling data over ordinary-looking protocols, so watch for oversized DNS traffic with long encoded labels, HTTP or HTTPS POSTs of unexpected size, and transfers to newly seen cloud storage or paste sites. Slow, low-and-slow exfiltration spreads the theft over time to stay under volume thresholds, which is why baselining per-host normal transfer volumes and alerting on deviation matters more than any single threshold. Correlating the destination against DNS and TLS metadata, and the timing against business hours, sharpens a noisy signal into an actionable one.

Hardening and building detection capability#

Network forensics is only possible if you capture the right traffic in the right places, so the first hardening step is visibility: deploy sensors at internet egress, between network segments and at critical east-west boundaries, and ensure encrypted traffic still yields metadata by logging TLS and DNS. Retain Zeek logs long enough to investigate slow intrusions, typically far longer than full PCAP, and keep a rolling PCAP window for deep dives. Baseline normal behaviour per host and per segment so anomalies stand out, and encode known-bad patterns as Zeek policy and SIEM correlation rules. Enrich logs with threat intelligence, asset inventory and identity so a raw IP becomes a named host with an owner. Practise the pivots before an incident, protect the sensors and their logs from tampering, and segment the network so that lateral movement crosses a monitored boundary and thus generates evidence rather than travelling invisibly.

Common pitfalls#

Several mistakes recur in network investigations. The first is capturing in the wrong place, so the traffic of interest never crosses the sensor and the absence of evidence is misread as absence of activity. The second is assuming encryption blinds you completely; in reality metadata, timing and certificate details remain highly informative, and treating encrypted traffic as unanalysable throws away real signal. A third is drowning in volume without baselines, so genuine anomalies hide in noise. Analysts also over-trust single indicators, such as flagging every periodic connection as C2 when software updates and telemetry also beacon, which produces false positives; context and corroboration are essential. Finally, poor time synchronisation across sensors and endpoints makes timeline reconstruction unreliable, and failing to preserve capture integrity and chain of custody can undermine findings if a case becomes formal. Each pitfall is avoidable with deliberate sensor placement, baselining, corroboration and documentation.

Investigation checklist#

Use this checklist to structure a network investigation. 1) Confirm where traffic was captured and that the sensor covered the relevant path. 2) Verify time synchronisation across all sensors and correlated logs. 3) Start in conn.log to profile the suspect host's connections and data volumes. 4) Pivot to dns.log for suspicious or high-entropy domain lookups. 5) Examine ssl.log and x509.log for anomalous certificates and server names. 6) Check files.log hashes against threat intelligence. 7) Hunt for beaconing periodicity and asymmetric outbound volume. 8) Open the matching PCAP for byte-level confirmation of a key session. 9) Correlate every network finding with endpoint and identity evidence. 10) Preserve captures and logs with hashes and document the chain of custody throughout.

Frequently asked questions#

Can I do network forensics if most traffic is encrypted? Yes. While encryption hides payload content, it does not hide connection metadata, DNS lookups, TLS handshake details, certificates, timing or data volumes, and these are frequently sufficient to detect beaconing, exfiltration and anomalous destinations. Zeek is designed precisely to extract this metadata at scale. Do I need full PCAP, or are Zeek logs enough? The two are complementary. Zeek logs are compact, searchable and ideal for hunting across long time ranges, so they are your primary surface. Full PCAP is expensive to store but irreplaceable when you need byte-level proof of a specific session, so most mature programmes keep long-retention Zeek logs alongside a shorter rolling PCAP window for deep dives.

Conclusion#

Network forensics gives defenders an independent, tamper-resistant view of an intrusion that complements endpoint evidence and often survives when host logs do not. PCAP provides the byte-level ground truth, while Zeek transforms that raw traffic into compact, structured logs that make hunting across weeks of activity practical. Together they let you reconstruct timelines, expose command-and-control beaconing, quantify data exfiltration and identify lateral movement, even in a largely encrypted world, because behaviour and metadata remain visible. The craft lies in placing sensors where the traffic actually flows, baselining normal so anomalies surface, pivoting fluidly between the logs that matter, and corroborating every finding with endpoint and identity evidence. Build the visibility before the incident, practise the pivots, and protect the captures, and the network becomes the honest witness that ties an investigation together.