NF0.5 The Toolchain Overview

Zeek — The Investigation Foundation

Zeek produces the structured metadata logs that you'll query in every investigation. If you learn one network forensics tool, learn Zeek.

Zeek observes network traffic on a sensor interface and produces structured logs — one log file per protocol, with fields organized for querying. You deploy Zeek once, and it continuously generates the evidence you'll need for every future investigation. The output isn't alerts or dashboards. It's data — structured, queryable, storable data that answers investigation questions.

In the methodology, Zeek is the tool for Steps 1-3. You query conn.log to find connections of interest, dns.log to find domain resolutions, ssl.log to fingerprint TLS sessions, http.log to examine web traffic, and files.log to inventory file transfers. You query with command-line tools: zeek-cut extracts specific fields from Zeek's tab-separated log format, grep and awk filter and process, and jq handles JSON-format logs.

Zeek's protocol parsing depth is what makes it superior to NetFlow for investigation. NetFlow tells you a 5-tuple connection existed. Zeek tells you the connection existed AND the HTTP user-agent was "rclone/v1.62.2" AND the TLS certificate was self-signed AND the DNS query preceding it resolved to an IP first seen yesterday. That context is what turns a connection record into an investigation lead.

Module NF1 walks through Zeek deployment. Every subsequent module uses Zeek logs as the primary investigation data source.

Suricata — Signature Detection

Suricata tells you when known-bad patterns appear in your traffic. It's fast and specific — but blind to anything it doesn't have a rule for.

Suricata inspects network traffic against a library of rules and fires alerts when traffic matches. The Emerging Threats (ET Open) community ruleset covers thousands of known threats — malware families, C2 frameworks, exploit kits, and attack tools. You can write custom rules for your environment: specific domains, internal network patterns, or organization-specific indicators.

In the methodology, Suricata is a parallel input to Step 2 (Identify). While you're querying Zeek logs for connections of interest, you also check Suricata alerts for the same scope window. Suricata may flag sessions that look normal in conn.log but match a known malicious signature — a Cobalt Strike beacon that uses legitimate-looking HTTPS, for example, fires a Suricata alert based on the TLS fingerprint rather than the connection metadata.

The Suricata-Zeek relationship is complementary. Suricata says "this traffic is bad." Zeek says "here's everything about the session." You need both because Suricata alone can't tell you what else happened in the same connection, and Zeek alone can't tell you whether a connection matches a known threat signature.

Community ID is the bridge. Both tools generate a Community ID hash for every flow, calculated from the same 5-tuple. When Suricata fires alert SID 2025927 on Community ID 1:abc123, you find that same Community ID in Zeek's conn.log, dns.log, and ssl.log for full context.

Module NF1 covers Suricata deployment alongside Zeek. Module NF8 covers rule writing and tuning.

Wireshark and tshark — Packet Analysis

Wireshark is the tool you already know. In this course, it's used for Step 4 (Reconstruct) — targeted analysis of specific sessions, not general-purpose browsing of traffic.

Wireshark provides interactive, graphical packet analysis with protocol dissectors for hundreds of protocols. tshark is its command-line counterpart — same dissection engine, scriptable output. Both read PCAP files and display packets with full protocol decoding.

In the methodology, Wireshark appears at Step 4. By the time you open Wireshark, you've already identified the sessions of interest from Zeek metadata (Steps 1-2) and correlated across tools (Step 3). You open a PCAP file filtered to a specific conversation — not the full capture. This targeted approach is what makes Wireshark effective for forensics rather than frustrating.

The practical workflow: identify a suspicious conn.log entry → note the 5-tuple and timestamp → filter the PCAP file to that conversation using tshark or editcap → open the filtered PCAP in Wireshark → examine the protocol-level detail. Modules NF3-NF7 teach this workflow for each protocol.

tshark is often faster than Wireshark for specific extraction tasks. Extracting all HTTP user-agent strings from a PCAP, listing all TLS certificates, or computing statistics on connection durations — these are one-line tshark commands that would require manual navigation in the GUI.

zeek-cut and jq — Log Processing

These are the query tools that make Zeek data usable. zeek-cut handles Zeek's native tab-separated format. jq handles JSON output.

zeek-cut extracts specific columns from Zeek's tab-separated log files. A typical query looks like:

cat conn.log | zeek-cut ts id.orig_h id.resp_h id.resp_p duration orig_bytes resp_bytes | grep "203.0.113.88"

This extracts timestamp, source IP, destination IP, destination port, duration, and byte counts for all connections to a specific IP. zeek-cut handles Zeek's header format and outputs clean, pipeable data.

jq serves the same purpose for JSON-formatted Zeek logs. Many organizations configure Zeek to output JSON (for SIEM ingestion), and jq provides the field extraction and filtering that zeek-cut provides for the native format. The queries are structurally similar but syntactically different.

Both tools compose with standard Unix utilities — grep, awk, sort, uniq, head, tail, wc. The investigation query patterns you'll use throughout this course are combinations of zeek-cut (or jq) with Unix pipes. Module NF1 establishes the query patterns.

Arkime — Enterprise PCAP at Scale

Arkime (formerly Moloch) is the tool for when your PCAP data exceeds what Wireshark can handle — terabytes of captures that need indexing, searching, and retention management.

Arkime captures full network traffic, indexes it in Elasticsearch, and provides a web-based interface for searching, session reconstruction, and file extraction. It solves the PCAP-at-scale problem: when you have weeks of full-packet capture across multiple sensors, Arkime makes it searchable.

In the methodology, Arkime is an alternative to Wireshark/tshark at Step 4 — for environments where the PCAP volume requires enterprise tooling. You search for sessions by IP, port, protocol, or content, and Arkime returns the matching packets from potentially terabytes of stored captures.

Arkime is covered in depth in NF13 (NSM Architecture for Production). In the early modules of this course, you'll use Wireshark/tshark directly against PCAP files from the lab packs.

NetworkMiner — Object Extraction

NetworkMiner pulls files, images, certificates, and other objects out of PCAP captures. It answers the question: what was transferred in this session?

NetworkMiner reads a PCAP file and extracts objects transferred over network protocols — HTTP downloads, email attachments, SMB file transfers, DNS responses, TLS certificates. It presents the extracted objects in a GUI organized by host, file type, and protocol.

In the methodology, NetworkMiner is used at Step 4 when the investigation requires knowing what was transferred, not just that a transfer occurred. Zeek's files.log tells you a file was observed in network traffic. NetworkMiner extracts the actual file for analysis — hash it against threat intelligence, submit it to a sandbox, or examine its contents.

NetworkMiner is covered in NF4 (HTTP/HTTPS analysis) and NF12 (Network Evidence in IR).