"The goal of threat hunting is to find evidence of an intrusion that has already evaded your automated detection systems. It begins where automated detection ends." -- Richard Bejtlich, The Practice of Network Security Monitoring, Ch 6
Lecture (100 min -- second of two NSM weeks; includes forensics deep-dive)
7.1 Threat Hunting vs Signature-Based Detection
Weeks 6-7 form a two-week NSM module. Week 6 built the infrastructure: clustered Suricata + Zeek pipeline + SIEM. Week 7 addresses the analyst-layer above the infrastructure: threat hunting and network forensics.
Signature-based detection (Suricata rules, Zeek signature framework) is reactive: it flags known-bad patterns. A novel attacker, a living-off-the-land campaign, or a targeted intrusion using legitimate tools generates no alerts in a signature-only system.
Threat hunting is proactive: the analyst forms a hypothesis ("this network may have a host communicating with a C2 channel disguised as HTTPS traffic") and searches the NSM corpus to confirm or refute it. The hypothesis comes from threat intelligence, peer community reports, attack-pattern research, or anomaly detection.
Bejtlich's Ch 6 describes the hunt process in terms of the four data types: start with statistical anomalies (unusual destination ASNs, unusual port distributions, unusual connection-count spikes), pivot to session data to characterize the anomaly, pivot to full-content when the session data is suggestive, and generate a Suricata signature from the confirmed pattern so the next instance is automatically detected.
7.2 Statistical Anomaly Detection in Practice
Statistical anomalies require a baseline. Before you can detect "unusual destination AS," you need to know what "usual destination ASes" look like for this network.
Zeek-based baseline generation:
# Extract all destination ASNs from Zeek conn.log (with GeoIP/ASN enrichment via Zeek's GeoIP module)
zeek-cut id.resp_h < conn.log | sort | uniq -c | sort -rn > resp_host_freq.txt
# Extract DNS query names
zeek-cut query < dns.log | sort | uniq -c | sort -rn > dns_query_freq.txt
# Extract certificate subjects from SSL log
zeek-cut subject < ssl.log | sort | uniq -c | sort -rn > cert_subject_freq.txt
JA3/JA3S fingerprinting: Zeek's ssl module generates JA3 fingerprints for TLS ClientHello (JA3) and ServerHello (JA3S). Malware families tend to have distinctive JA3 fingerprints because they use embedded TLS libraries with specific cipher-suite orders. A JA3 fingerprint appearing on internal hosts that has no known-good classification is a hunt trigger.
RITA (Real Intelligence Threat Analytics): an open-source threat-hunting tool that ingests Zeek logs and runs automated analysis for beaconing (periodic connections), long connections, DNS tunneling (high-entropy FQDN labels, large TXT responses), and data-size anomalies. RITA surfaces candidates for analyst review; the analyst determines whether each candidate is malicious or benign.
# Import Zeek logs into RITA
rita import /path/to/zeek/logs/2026-05-28/ hunt_dataset_20260528
# Show beaconing candidates
rita show-beacons hunt_dataset_20260528
# Show DNS tunneling candidates
rita show-long-connections hunt_dataset_20260528
7.3 Network Forensics: Reconstructing the Attack Timeline
Davidoff and Ham's Network Forensics takes a different frame than Bejtlich: where Bejtlich focuses on ongoing operational monitoring, Davidoff and Ham focus on post-incident reconstruction. The forensics analyst's job is to answer: "Given this set of packet captures and logs, what happened, when, in what sequence, and what did the attacker exfiltrate?"
The four-phase attack lifecycle in network traffic:
| Phase | Network evidence | Forensic recovery tool |
|---|---|---|
| Reconnaissance | Scan traffic; DNS lookups; web crawling patterns | Zeek conn.log scan detection; Suricata scan sigs; passive DNS |
| Initial access | Exploit delivery (HTTP/SMTP); C2 channel establishment | Wireshark protocol dissection; HTTP/SMTP log reconstruction |
| Lateral movement | SMB/WinRM/DCOM/RPC lateral traffic; Pass-the-Hash patterns | Zeek smb.log; Kerberos.log; ntlm.log |
| Exfiltration | DNS tunneling; HTTP POST to unusual destinations; large transfers | Zeek dns.log entropy analysis; files.log; Wireshark follow-stream |
7.4 Wireshark at Forensics Depth
Wireshark skills at Belt-5 go beyond "apply a display filter." A forensics analyst uses Wireshark as a protocol reconstruction tool:
TCP stream reassembly: Follow > TCP Stream reconstructs the application-layer payload from a fragmented TCP session. HTTP requests/responses, SMTP email content, and plaintext command-and-control traffic become readable.
Export objects: File > Export Objects > HTTP extracts all HTTP-transferred files from a capture. A forensics analyst working a suspected malware download pcap uses this to extract the dropped EXE without executing it.
Statistical analysis in Wireshark: Statistics > Conversations and Statistics > Protocol Hierarchy give an immediate picture of traffic composition. A host with 90% of traffic to one destination on an unusual port is a hunt trigger.
tshark for scriptable analysis:
# Extract all HTTP hosts from a pcap
tshark -r intrusion.pcap -Y http -T fields -e http.host | sort | uniq -c | sort -rn
# Extract DNS queries with high-entropy names (pipe to entropy calculation)
tshark -r intrusion.pcap -Y dns.qry.name -T fields -e dns.qry.name | \
python3 -c "
import sys, math, collections
for line in sys.stdin:
s = line.strip()
if not s: continue
freq = collections.Counter(s)
entropy = -sum((f/len(s)) * math.log2(f/len(s)) for f in freq.values())
if entropy > 3.5: # high entropy threshold
print(f'{entropy:.2f} {s}')
"
NetworkMiner: a passive network forensics tool that reassembles file transfers, credentials, and session content from pcap files without active capture. NetworkMiner's host view shows all observed hosts with their operating system fingerprints, open ports, credentials, and files transmitted.
7.5 Multi-Phase Intrusion Timeline Reconstruction
The capstone artifact in Lab 9 is a reconstructed attack timeline. The process:
Step 1: Import the pcap into Zeek
zeek -r intrusion-lateral.pcap LogAscii::use_json=T
# Generates conn.log, dns.log, http.log, ssl.log, smb.log, etc.
Step 2: Timeline by timestamp
# All events sorted by time (Zeek logs have a 'ts' field)
cat *.log | python3 -c "
import sys, json
events = []
for line in sys.stdin:
try:
e = json.loads(line)
if 'ts' in e:
events.append((e['ts'], e))
except: pass
for ts, e in sorted(events):
print(ts, e.get('_path','?'), json.dumps(e)[:120])
" | head -100
Step 3: Pivot from anomaly to context
When the timeline reveals a suspicious event (unusual outbound connection at 02:14 UTC), pivot:
- What destination? Zeek
conn.loghas dst IP and port - Is the dst IP malicious? Check Suricata alert log for same IP; check threat intel feed
- What protocol? Zeek
ssl.log,http.log,dns.logfor the same timeframe - What preceded it? Walk backward in the timeline: what connection, DNS query, or HTTP request established the context?
Step 4: Characterize the C2 channel
A well-established C2 channel has a characteristic network fingerprint:
- Beaconing: periodic connection intervals; look for standard deviation of inter-connection times < 5% of mean
- Low-throughput long connections: 1-2 KB/hour to a single external IP; legitimate browsing doesn't look like this
- JA3 mismatch: TLS ClientHello from a system that also generates Office365 ClientHellos; different JA3 is suspicious
Davidoff & Ham Weave
Davidoff and Ham's Network Forensics is structured around case studies: a financial fraud investigation, a data exfiltration investigation, a botnet analysis. Each case study walks the evidence from raw pcap to reconstructed event sequence. At NET-301 depth, the key lesson from Davidoff and Ham is that forensic conclusions require a chain of evidence: each step in the reconstruction must be supported by a specific timestamp, a specific packet, and a specific log entry. "It looks like lateral movement" is not a forensic conclusion; "at 02:14:33 UTC, source 10.0.1.15 connected to 10.0.3.20 on TCP/445, transmitted 147 KB, consistent with SMB share enumeration per Zeek smb.log entry {...}" is.
Lab 8 Introduction
Lab 8 is the threat-hunt lab. Using the academy NSM corpus (four pcap files: normal-traffic-24h, intrusion-lateral, c2-beacon, exfiltration-dns), you will:
- Import each pcap into Zeek and generate logs
- Run RITA against the beaconing-corpus pcap; identify the C2 candidate
- Confirm the candidate via JA3 analysis in Wireshark
- Reconstruct the lateral-movement timeline from the intrusion pcap to 3-event granularity (initial access, pivoting event, exfiltration event)
- Write one new Suricata signature that would have detected the C2 channel; verify it fires against the corpus pcap
Independent Practice (6 hr)
- Bejtlich Practice of Network Security Monitoring Ch 6-7 (threat hunting + NSM operations)
- Davidoff & Ham Network Forensics Ch 1-3 (intro + HTTP + SMTP forensics)
- RITA documentation:
github.com/activecountermeasures/rita-- install + quickstart; 30 min - Lab 8 -- Part A (Zeek import + RITA analysis of beaconing corpus)
- Supplemental: read the Mandiant M-Trends 2024 report detection timeline statistics (~20 min; publicly available); frames what "days to detect" looks like in practice and why threat hunting closes the gap