In this module
NF0.11 Interactive Lab — Exploring Zeek Logs
This lab gives you your first hands-on interaction with Zeek log data from a Northgate Engineering incident. You'll query conn.log, dns.log, and ssl.log using zeek-cut and standard command-line tools to answer investigation questions — applying the methodology from NF0.4 against real-format data.
No sensor setup is required for this lab. You'll work with pre-generated Zeek logs from INC-NE-2026-0418. Module NF1 builds your sensor from scratch; this lab focuses on the query patterns you'll use throughout the course.
Deliverable: Answers to five investigation questions using only Zeek log queries, demonstrating the Scope → Identify → Correlate methodology.
Lab Setup
Download the NF0 lab pack from the course downloads page. The pack contains three Zeek log files from a 72-hour capture on NE's egress sensor covering April 15-18, 2026:
conn.log— 847,293 connection recordsdns.log— 231,456 DNS query recordsssl.log— 189,234 TLS handshake records
The logs are in Zeek's native tab-separated format. Each file has a header (lines starting with #) that describes the columns. You'll use zeek-cut to extract specific fields. If you don't have zeek-cut installed, the same queries can be performed with awk — equivalent commands are provided for each exercise.
Exercise 1 — Scope the Investigation
The investigation trigger is a Suricata alert for "ET MALWARE Cobalt Strike Beacon Activity" at 2026-04-18T06:12:00Z from source IP 10.0.1.15 (IT03-NGE) to destination IP 185.193.125.44.
Using conn.log, determine: how many total connections did IT03-NGE (10.0.1.15) make to 185.193.125.44 during the 72-hour capture?
cat conn.log | zeek-cut id.orig_h id.resp_h | grep "10.0.1.15.*185.193.125.44" | wc -lExpected output: Approximately 3,600 connections (one every ~60 seconds over 72 hours with some variation).
Exercise 2 — Identify the Beacon Pattern
Extract the timestamps, duration, and byte counts for the connections identified in Exercise 1.
cat conn.log | zeek-cut ts id.orig_h id.resp_h duration orig_bytes resp_bytes | grep "10.0.1.15.*185.193.125.44" | head -20What to look for: Consistent ~60-second intervals between connection timestamps. Consistent byte counts (300-500 bytes each direction). Short duration (0.3-0.5 seconds per connection). This is the C2 beacon pattern.
Exercise 3 — Find the DNS Trail
Using dns.log, find the DNS queries from IT03-NGE that resolved to 185.193.125.44.
cat dns.log | zeek-cut ts id.orig_h query answers | grep "185.193.125.44"What to look for: The domain name that resolved to the C2 IP. When was the first query? Was the domain queried before the first connection, confirming DNS resolution preceded the C2 channel?
Exercise 4 — Check for Other Compromised Hosts
Using conn.log, determine whether any other internal hosts (10.0.0.0/8) communicated with 185.193.125.44.
cat conn.log | zeek-cut id.orig_h id.resp_h | grep "185.193.125.44" | awk -F'\t' '{print $1}' | sort -uExpected output: If only IT03-NGE communicated with the C2 IP, the scope is limited to one host. If additional hosts appear, the compromise is wider than the initial alert suggested. This is Step 3 (Correlate) of the methodology — using network evidence to scope the incident beyond the initial indicator.
Exercise 5 — Find the Exfiltration
Using conn.log, find the largest outbound transfers from any NE host (10.0.0.0/8) to external IPs during the 72-hour window. Sort by originator bytes.
cat conn.log | zeek-cut id.orig_h id.resp_h id.resp_p orig_bytes resp_bytes | awk -F'\t' '$4 > 1000000000 {print}' | sort -t$'\t' -k4 -rnWhat to look for: Any connection with originator bytes exceeding 1 GB. The exfiltration should appear as a large outbound transfer from FS01-NGE (10.0.2.10) to 185.193.125.44 — the same C2 IP, but with dramatically different byte counts than the beacon traffic.
Lab Debrief
This lab demonstrated the core investigation workflow that runs through every module in this course. You started with an alert (Scope), queried conn.log and dns.log to characterize the activity (Identify), checked for additional compromised hosts (Correlate), and found the exfiltration (Reconstruct). No packet analysis was required — metadata answered every question.
The queries you ran in this lab are the same patterns you'll use in every subsequent module, adapted for protocol-specific investigation. NF1 builds the sensor that generates this data. NF2 onwards teaches you to apply these patterns to specific attack techniques.
You've built the sensor and mapped the evidence landscape.
NF0 established why network evidence matters when every other source is compromised. NF1 built your Zeek + Suricata sensor with the 10 investigation query patterns. From here, every module teaches protocol-specific investigation against real attack scenarios.
- DNS deep dive (NF3) — tunnelling detection, DGA analysis, passive DNS infrastructure mapping, and the INC-NE-2026-0227 AiTM phishing DNS trail
- Protocol analysis (NF4–NF7) — HTTP/HTTPS, SMB lateral movement, SSH tunnelling, and email protocol investigation with Zeek metadata and PCAP
- Detection and hunting (NF8–NF11) — Suricata rule writing, C2 beacon detection with JA3, NetFlow analytics, and proactive network threat hunting
- NSM architecture (NF13) — production sensor deployment at 1–10 Gbps with Arkime, Security Onion, and enterprise storage planning
- INC-NE-2026-0830 capstone (NF14) — multi-stage investigation using only network evidence: phishing → domain-fronted C2 → lateral movement → DNS tunnel exfiltration
Cancel anytime