hack3rs.ca network-security

/learning/tools/zeek :: tool-guide-3

defender@hack3rs:~/learning/tools$ open zeek

Zeek

Network telemetry

Zeek network monitoring produces structured, protocol-aware logs that defenders use to investigate incidents, hunt suspicious behavior, and correlate network-side evidence with host telemetry — without requiring signatures for every threat.

how-to-learn-this-tool-like-a-defender

Work through the stages in order. Each one builds on the previous. Skipping straight to 'run a command' without knowing what the output means is how analysts end up misreading evidence under pressure.

$Name the specific question this tool answers — and one question it cannot answer alone.
$Run the simplest command in a lab against a host you control; read every field in the output before moving on.
$Identify which output fields are direct evidence and which are inferences the tool made on your behalf.
$Pull a second source — a log, a PCAP, a SIEM event — that either confirms or contradicts what the tool reported.
$Write down the exact command you ran, what you expected, what you got, and what you are doing next.

preflight-checklist-before-using-tool

$Confirm in writing: who authorized this, what hosts are in scope, and what the maximum acceptable impact is.
$State the question you are trying to answer — not 'run the tool' but 'confirm whether port 443 is open on 10.10.20.15'.
$Name the second source you will use if the tool output is ambiguous (log, PCAP, CMDB, another tool).
$Record the start time, the host or interface you ran it on, and the exact command — enough for another analyst to reproduce it.
$Know what normal output looks like for this host before you run anything in anger.

how-experts-read-output

$Field recognition: identify the two or three fields that directly answer your question and ignore the rest for now.
$Scope check: confirm the output covers the host, interface, and time window you intended — not a cached or adjacent result.
$Evidence type: is this a direct observation (packet captured, port open) or an inference the tool made (service guessed from banner)?
$Correlation: name the one other source — a log line, a PCAP stream, a CMDB entry — that would confirm or contradict this.
$Decision: close the question, escalate with evidence, refine the scope, or collect another source — pick one and do it.

official-links

open docs Official Zeek documentation script reference Zeek script package and script reference zeek package manager Extending Zeek with packages

ethical-use-and-defense-scope

Deploy Zeek where you are authorized to monitor traffic and where privacy requirements are clearly understood. Protocol metadata and connection logs can reveal user behavior, internal service relationships, and sensitive operational details — even without payload content.

Use Zeek for defensive visibility, incident response, and understanding normal network behavior. Do not use it to covertly monitor people or networks outside your documented security and compliance scope.

Define retention periods, access controls, and acceptable use policies for Zeek logs before you start collecting. Treat telemetry as sensitive security data with role-based access and an audit trail.

tool-history-origin-and-purpose

$When created: Initial version designed in 1995 as Bro; first deployed in 1996; renamed to Zeek in 2018 (Zeek-branded releases followed).
$Why it was created: Traditional perimeter controls and simple alerts were not enough for understanding complex network activity. The goal was to observe and log protocol behavior in real time so defenders could detect intrusions and investigate events with richer telemetry.

Vern Paxson developed Bro (later Zeek) at Lawrence Berkeley National Laboratory as a research and operational network security monitor to provide deep, scriptable visibility into network behavior.

why-defenders-still-use-it

People use Zeek because it produces structured, high-value protocol logs for hunting, retrospective analysis, and detection engineering. It is especially useful when defenders need metadata and behavior context at scale rather than raw packets for everything.

How the tool evolved

+Began as a research-driven network monitor and became a widely deployed open-source NSM platform.
+Built a strong scripting and package ecosystem for custom telemetry and detections.
+Renamed from Bro to Zeek to better reflect community values and project evolution.

when-this-tool-is-a-good-fit

+Retrospective investigation after a new indicator surfaces — look back through conn.log and dns.log to find earliest activity.
+Beaconing and C2 pattern detection using connection timing, size regularity, and destination frequency in conn.log.
+DNS and HTTP metadata analysis for threat hunting without requiring full packet payloads.
+Network-side context to enrich and validate endpoint alerts with what the wire actually shows.

when-to-use-another-tool-or-source

!When you need host process/user context, pair with endpoint or OS logs.
!When you need ownership and business impact, pair with CMDB/ticketing/asset context.
!When the tool output is ambiguous, validate using a second evidence source before concluding.
!When production risk is high, test in a lab first and use change coordination.

1. What Zeek Is and Why Defenders Use It

Zeek parses network traffic and writes structured logs for each protocol session. Rather than matching signatures, it extracts metadata: connection tuples, DNS queries and responses, HTTP headers, TLS handshake details, file transfers, and notices. That metadata becomes the evidence base for investigations and hunting.

The logs are what make Zeek useful at scale. conn.log, dns.log, http.log, ssl.log, and files.log give you a durable record of network behavior without storing full packet payloads everywhere. You can answer most network investigation questions from those logs alone.

For blue teams, Zeek fills the gap between raw packets and high-level alerts. It preserves the protocol context that makes the difference between “something happened” and “here is exactly what the client requested and what the server returned.”

2. Core Zeek Logs and How To Read Them

Start with conn.log, dns.log, http.log, ssl.log, and notice.log. These five cover the majority of network investigation questions: who talked to whom, over what protocol, when, for how long, and with what application-level behavior.

Zeek logs are tab-separated with consistent field names, which makes them easy to ingest into a SIEM and practical for ad hoc command-line analysis. Before you write queries, learn to read the raw fields: timestamps, unique connection IDs, origin/response hosts, durations, byte counts, and the protocol-specific fields like dns.qry.name or ssl.server_name.

The key skill is pivoting across logs using the unique connection ID (uid). A suspicious domain in dns.log links to a connection in conn.log, which links to the TLS handshake in ssl.log. That chain is what turns a single data point into a narrative.

3. Zeek Deployment and Sensor Placement

Sensor placement determines what Zeek can see. Put sensors where traffic is meaningful: internet edges, VPN aggregation points, critical server segments, internal chokepoints. A well-configured Zeek instance in the wrong spot tells you almost nothing useful.

Know what is and is not visible from each sensor. Asymmetric routing means you may see only one direction of a conversation. SPAN port oversubscription causes drops. Cloud traffic mirroring has its own gaps. Document these limitations — analysts who do not know the blind spots will draw wrong conclusions from absence of evidence.

Start small. One well-monitored segment with reliable log delivery and a clear retention policy is more valuable than a rushed deployment covering six segments with inconsistent data and no query workflow.

4. Threat Hunting and Retrospective Analysis with Zeek

Zeek is built for retrospective analysis. When a new indicator surfaces — a malicious domain, a suspicious IP, a known malware C2 pattern — you can query historical logs to find the first occurrence, identify other hosts that contacted the same infrastructure, and reconstruct the timeline.

Hunting with Zeek means querying behavior, not matching signatures. Unusual DNS query volume from a workstation class, protocol use on unexpected ports, beaconing intervals in conn.log, or user agents that do not match your known software inventory — these are the kinds of patterns that reward a Zeek analyst who knows the data.

Zeek network monitoring complements endpoint and identity telemetry rather than replacing either. Its strength is building the network-side narrative — who connected to what, when, and how — that confirms or extends host-based evidence.

5. Custom Detections and Zeek Scripting Mindset

Zeek scripts and packages let you add custom notices or enrich telemetry beyond the stock logs. Most teams should start with the built-in logs and gradually add custom logic only after they understand what normal behavior looks like for their environment.

Write custom logic for a specific hypothesis, not because scripting is available. “Alert when any workstation queries more than 50 unique domains in five minutes” is a specific, testable behavior. Test it against real traffic in a lab, measure false positive rate, and only then deploy.

Treat Zeek scripts like production code: version control, documented assumptions, change reviews. Silent drift in detection logic is how gaps appear without anyone noticing.

6. Operational Challenges and Tuning

Zeek generates a lot of data. Before you deploy, decide where the logs go, how long they are retained, and who will query them. A Zeek deployment without an ingestion pipeline and a query workflow produces telemetry that no one reads.

Volume tuning is only part of the problem. Choosing which logs to prioritize, which fields to enrich with asset context, and which queries to pre-build for analysts matters as much as raw data collection. Good queries and dashboards often deliver more value than adding more log types.

Monitor the sensors themselves. Dropped packets, mirror failures, and pipeline stalls quietly reduce your coverage with no visible error. Treat Zeek infrastructure as a production system with its own health checks.

7. Learning Zeek Effectively

Replay a pcap in a lab and look at the Zeek logs and the Wireshark view side by side. This teaches you what Zeek extracts and what only lives in the raw packets — and builds intuition about when you need to go back to the pcap versus when the logs are enough.

Learn one investigation chain end to end: suspicious domain in dns.log → uid in conn.log → TLS context in ssl.log → correlated host alert. Run it on lab traffic until it is comfortable. Then run it under time pressure.

Add scripting, packages, and telemetry quality reviews as your skills grow. Understanding protocols deeply makes your hunts better and your custom detections more precise — Zeek expertise compounds over time.

scenario-teaching-playbooks

Work through each scenario step by step. The goal is to practice making decisions with the tool — not just executing commands — so the workflow becomes automatic before you need it under pressure.

1. Retrospective investigation after a new indicator surfaces — look back through conn.log and dns.log to find earliest activity.

Suggested starting block: PCAP Replay For Learning

$Write the question you need to answer and the exact hosts or segments you are authorized to inspect.
$Run the first command from the selected command block; note the timestamp and interface used.
$Read the output field by field — identify what the tool confirmed versus what it inferred.
$Check a second source (host log, SIEM alert, PCAP, ticket, or CMDB record) that covers the same time window.
$Write one sentence stating your finding, your confidence level, and the next action.

2. Beaconing and C2 pattern detection using connection timing, size regularity, and destination frequency in conn.log.

Suggested starting block: Basic Log Exploration

$Write the question you need to answer and the exact hosts or segments you are authorized to inspect.
$Run the first command from the selected command block; note the timestamp and interface used.
$Read the output field by field — identify what the tool confirmed versus what it inferred.
$Check a second source (host log, SIEM alert, PCAP, ticket, or CMDB record) that covers the same time window.
$Write one sentence stating your finding, your confidence level, and the next action.

3. DNS and HTTP metadata analysis for threat hunting without requiring full packet payloads.

Suggested starting block: Service Deployment (Environment-Specific)

$Write the question you need to answer and the exact hosts or segments you are authorized to inspect.
$Run the first command from the selected command block; note the timestamp and interface used.
$Read the output field by field — identify what the tool confirmed versus what it inferred.
$Check a second source (host log, SIEM alert, PCAP, ticket, or CMDB record) that covers the same time window.
$Write one sentence stating your finding, your confidence level, and the next action.

4. Network-side context to enrich and validate endpoint alerts with what the wire actually shows.

Suggested starting block: PCAP Replay For Learning

$Write the question you need to answer and the exact hosts or segments you are authorized to inspect.
$Run the first command from the selected command block; note the timestamp and interface used.
$Read the output field by field — identify what the tool confirmed versus what it inferred.
$Check a second source (host log, SIEM alert, PCAP, ticket, or CMDB record) that covers the same time window.
$Write one sentence stating your finding, your confidence level, and the next action.

cli-workflows

Lab-safe commands for authorized environments. Run each one, read the output, and note what field or value tells you something useful before moving to the next.

cli-walkthroughs-with-expected-output

One command per block, with sample output. Study the output before you run the command yourself — you should recognize what you are looking at when it appears on your screen.

PCAP Replay For Learning

Beginner

Command

mkdir -p zeek-lab && cd zeek-lab

Example Output

# no output — directory created successfully

$ how to read it: Read the key fields — host, port, protocol, state — then ask whether the output answers the question you started with. If it raises a new question instead, collect a second source before drawing a conclusion.

Basic Log Exploration

Intermediate

Command

cut -f 1-8 conn.log | head -20

Example Output

1711267200.000000	Cx1ab2	192.168.1.10	54321	93.184.216.34	443	tcp	ssl
1711267201.500000	Cx1cd3	192.168.1.10	54322	8.8.8.8	53	udp	dns

Service Deployment (Environment-Specific)

Advanced

Command

sudo zeekctl deploy

Example Output

stopping zeekd ... stopping.
starting zeekd ... done.
# Zeek deployed and writing logs to /opt/zeek/logs/current/

command-anatomy-and-expert-usage

Each card explains what the command is for, what can go wrong, and what the output means. Syntax is easy to look up; knowing which command to reach for — and what to ignore in the output — is the skill worth building.

PCAP Replay For Learning

Beginner

Command

mkdir -p zeek-lab && cd zeek-lab

Command Anatomy

$Base command: mkdir
$Primary arguments/options: -p zeek-lab && cd zeek-lab
$Operator goal: know what answer you expect before you run it; if the output surprises you, investigate before concluding.

Use And Risk

$ intent: Generate or operate network telemetry logs for investigations.

$ risk: Review command impact before running; validate in lab first if uncertain.

$ learning focus: Baseline command: learn what normal output looks like.

Show sample output and interpretation notes

# no output — directory created successfully

$ expert reading pattern: Check that the scope matches what you intended, pick out the two or three fields that answer your question, then find one other source that confirms before you act.

PCAP Replay For Learning

Beginner

Command

zeek -r sample.pcap

Command Anatomy

$Base command: zeek
$Primary arguments/options: -r sample.pcap
$Operator goal: know what answer you expect before you run it; if the output surprises you, investigate before concluding.

Use And Risk

$ intent: Generate or operate network telemetry logs for investigations.

$ risk: Review command impact before running; validate in lab first if uncertain.

$ learning focus: Intermediate step: refine scope or extract more useful evidence.

Show sample output and interpretation notes

reading sample.pcap ...
writing conn.log dns.log http.log ssl.log

$ expert reading pattern: Check that the scope matches what you intended, pick out the two or three fields that answer your question, then find one other source that confirms before you act.

PCAP Replay For Learning

Beginner

Command

ls *.log

Command Anatomy

$Base command: ls
$Primary arguments/options: *.log
$Operator goal: know what answer you expect before you run it; if the output surprises you, investigate before concluding.

Use And Risk

$ intent: Collect, validate, or document evidence in a defensive workflow.

$ risk: Review command impact before running; validate in lab first if uncertain.

$ learning focus: Intermediate step: refine scope or extract more useful evidence.

Show sample output and interpretation notes

conn.log  dns.log  files.log  http.log  notice.log  ssl.log  weird.log

$ expert reading pattern: Check that the scope matches what you intended, pick out the two or three fields that answer your question, then find one other source that confirms before you act.

PCAP Replay For Learning

Beginner

Command

head -20 conn.log

Command Anatomy

$Base command: head
$Primary arguments/options: -20 conn.log
$Operator goal: know what answer you expect before you run it; if the output surprises you, investigate before concluding.

Use And Risk

$ intent: Quick evidence extraction from logs or command output.

$ risk: Review command impact before running; validate in lab first if uncertain.

$ learning focus: Intermediate step: refine scope or extract more useful evidence.

Show sample output and interpretation notes

#separator \x09
#fields	ts	uid	id.orig_h	id.orig_p	id.resp_h	id.resp_p	proto	service	duration	orig_bytes	resp_bytes	conn_state
1711267200.000000	Cx1ab2	192.168.1.10	54321	93.184.216.34	443	tcp	ssl	1.234	1024	4096	SF
1711267201.500000	Cx1cd3	192.168.1.10	54322	8.8.8.8	53	udp	dns	0.003	44	88	SF

$ expert reading pattern: Check that the scope matches what you intended, pick out the two or three fields that answer your question, then find one other source that confirms before you act.

PCAP Replay For Learning

Beginner

Command

head -20 dns.log

Command Anatomy

$Base command: head
$Primary arguments/options: -20 dns.log
$Operator goal: know what answer you expect before you run it; if the output surprises you, investigate before concluding.

Use And Risk

$ intent: Quick evidence extraction from logs or command output.

$ risk: Review command impact before running; validate in lab first if uncertain.

$ learning focus: Advanced step: use after baseline and validation are understood.

Show sample output and interpretation notes

#separator \x09
#fields	ts	uid	id.orig_h	id.orig_p	id.resp_h	id.resp_p	proto	trans_id	query	qtype_name	rcode_name	answersTTLs	answers
1711267200.100000	Dx2ef4	192.168.1.10	12345	8.8.8.8	53	udp	12345	example.com	A	NOERROR	300	93.184.216.34
1711267201.200000	Dx2ef5	192.168.1.10	12346	8.8.8.8	53	udp	12346	www.lab.local	A	NOERROR	60	192.168.1.1

$ expert reading pattern: Check that the scope matches what you intended, pick out the two or three fields that answer your question, then find one other source that confirms before you act.

Basic Log Exploration

Intermediate

Command

cut -f 1-8 conn.log | head -20

Command Anatomy

$Base command: cut
$Primary arguments/options: -f 1-8 conn.log | head
$Operator goal: know what answer you expect before you run it; if the output surprises you, investigate before concluding.

Use And Risk

$ intent: Quick evidence extraction from logs or command output.

$ risk: Review command impact before running; validate in lab first if uncertain.

$ learning focus: Baseline command: learn what normal output looks like.

Show sample output and interpretation notes

1711267200.000000	Cx1ab2	192.168.1.10	54321	93.184.216.34	443	tcp	ssl
1711267201.500000	Cx1cd3	192.168.1.10	54322	8.8.8.8	53	udp	dns

$ expert reading pattern: Check that the scope matches what you intended, pick out the two or three fields that answer your question, then find one other source that confirms before you act.

Basic Log Exploration

Intermediate

Command

grep -i example dns.log | head

Command Anatomy

$Base command: grep
$Primary arguments/options: -i example dns.log | head
$Operator goal: know what answer you expect before you run it; if the output surprises you, investigate before concluding.

Use And Risk

$ intent: Quick evidence extraction from logs or command output.

$ risk: Review command impact before running; validate in lab first if uncertain.

$ learning focus: Intermediate step: refine scope or extract more useful evidence.

Show sample output and interpretation notes

1711267201.200000	Dx2ef5	192.168.1.10	12346	8.8.8.8	53	udp	12346	example.com	A	NOERROR	300	93.184.216.34

$ expert reading pattern: Check that the scope matches what you intended, pick out the two or three fields that answer your question, then find one other source that confirms before you act.

Basic Log Exploration

Intermediate

Command

zeek-cut ts id.orig_h id.resp_h query < dns.log | head

Command Anatomy

$Base command: zeek-cut
$Primary arguments/options: ts id.orig_h id.resp_h query <
$Operator goal: know what answer you expect before you run it; if the output surprises you, investigate before concluding.

Use And Risk

$ intent: Generate or operate network telemetry logs for investigations.

$ risk: Review command impact before running; validate in lab first if uncertain.

$ learning focus: Advanced step: use after baseline and validation are understood.

Show sample output and interpretation notes

1711267200.100000	192.168.1.10	8.8.8.8	example.com
1711267201.200000	192.168.1.10	8.8.8.8	www.lab.local
1711267202.300000	192.168.1.10	8.8.8.8	api.github.com

$ expert reading pattern: Check that the scope matches what you intended, pick out the two or three fields that answer your question, then find one other source that confirms before you act.

Service Deployment (Environment-Specific)

Advanced

Command

sudo zeekctl deploy

Command Anatomy

$Base command: sudo
$Primary arguments/options: zeekctl deploy
$Operator goal: know what answer you expect before you run it; if the output surprises you, investigate before concluding.

Use And Risk

$ intent: Generate or operate network telemetry logs for investigations.

$ risk: Review command impact before running; validate in lab first if uncertain.

$ learning focus: Baseline command: learn what normal output looks like.

Show sample output and interpretation notes

stopping zeekd ... stopping.
starting zeekd ... done.
# Zeek deployed and writing logs to /opt/zeek/logs/current/

$ expert reading pattern: Check that the scope matches what you intended, pick out the two or three fields that answer your question, then find one other source that confirms before you act.

Service Deployment (Environment-Specific)

Advanced

Command

sudo zeekctl status

Command Anatomy

$Base command: sudo
$Primary arguments/options: zeekctl status
$Operator goal: know what answer you expect before you run it; if the output surprises you, investigate before concluding.

Use And Risk

$ intent: Generate or operate network telemetry logs for investigations.

$ risk: Review command impact before running; validate in lab first if uncertain.

$ learning focus: Intermediate step: refine scope or extract more useful evidence.

Show sample output and interpretation notes

Name         Type       Host          Status    Pid    Started
zeekd        standalone localhost     running   4231   17 Mar 10:00:00

$ expert reading pattern: Check that the scope matches what you intended, pick out the two or three fields that answer your question, then find one other source that confirms before you act.

Service Deployment (Environment-Specific)

Advanced

Command

sudo zeekctl diag

Command Anatomy

$Base command: sudo
$Primary arguments/options: zeekctl diag
$Operator goal: know what answer you expect before you run it; if the output surprises you, investigate before concluding.

Use And Risk

$ intent: Generate or operate network telemetry logs for investigations.

$ risk: Review command impact before running; validate in lab first if uncertain.

$ learning focus: Advanced step: use after baseline and validation are understood.

Show sample output and interpretation notes

[Wed Mar 17 10:05:00 2026] zeekd: Normal exit
# No crash detected — check /opt/zeek/logs/current/reporter.log for policy warnings

$ expert reading pattern: Check that the scope matches what you intended, pick out the two or three fields that answer your question, then find one other source that confirms before you act.

PCAP Replay For Learning

mkdir -p zeek-lab && cd zeek-lab
zeek -r sample.pcap
ls *.log
head -20 conn.log
head -20 dns.log

Basic Log Exploration

cut -f 1-8 conn.log | head -20
grep -i example dns.log | head
zeek-cut ts id.orig_h id.resp_h query < dns.log | head

Service Deployment (Environment-Specific)

sudo zeekctl deploy
sudo zeekctl status
sudo zeekctl diag

defensive-use-cases

$Retrospective investigation after a new indicator surfaces — look back through conn.log and dns.log to find earliest activity.
$Beaconing and C2 pattern detection using connection timing, size regularity, and destination frequency in conn.log.
$DNS and HTTP metadata analysis for threat hunting without requiring full packet payloads.
$Network-side context to enrich and validate endpoint alerts with what the wire actually shows.

common-mistakes

$Deploying Zeek without a log ingestion destination, retention policy, or query workflow.
$Trusting that a sensor sees all traffic without documenting routing and mirroring limitations.
$Collecting logs from every protocol but building no repeatable hunting or triage workflow.
$Writing custom Zeek scripts before establishing a baseline of what normal looks like.

expert-habits-for-free-self-study

Free teaching resource. The loop that makes analysts better: ask a precise question, collect evidence, read it carefully, validate against a second source, document what you found, and repeat with a harder question.

$Pick the least disruptive command that can still answer the question — then run that one first.
$Before you look at output, write one sentence stating what you expect to see.
$Mark each output field as 'observed' or 'inferred by tool' before acting on it.
$Save the exact command with flags and target — not a paraphrase — so another analyst can run the same thing.
$During a quiet period, capture what normal output looks like from key hosts; store those samples where you can find them during an incident.
$When you escalate, include the command output, the timestamp, and one sentence on why it matters — not just 'looks suspicious'.

knowledge-check

?What question is this tool best suited to answer first?
?What permissions or scope approvals are needed before using it?
?Which second evidence source should you pair with it for higher confidence?
?What does normal output look like for your environment?

teaching-answer-guide

Show teaching hints

#Start from the tool’s role and the scenario you are investigating.
#Never rely on one tool alone for high-confidence incident decisions.
#Document normal output patterns during calm periods so anomalies are easier to spot.
#Prefer lab validation for new commands, rules, or scans before production use.

practice-plan

# Replay a pcap file and compare the Zeek logs to the Wireshark view of the same traffic.
# Build three hunts: one DNS-based, one on conn.log connection patterns, one on TLS/HTTP metadata.
# Document your sensor placement, what traffic it sees, and what its blind spots are.
# Write one custom detection hypothesis — specific behavior, not "anything suspicious" — and test it in a lab.

related-learning-modules

Study the core concepts and workflows behind this tool so your usage stays evidence-driven and repeatable.

open /learning/network-security-monitoring-zeek-suricata Network Security Monitoring with Zeek and Suricata open /learning/threat-informed-defense-attack-technique-mapping Threat-Informed Defense Using ATT&CK-Style Technique Mapping

related-threat-workflows

See where this tool fits into threat-specific detection, triage, and remediation workflows.

open /threats/dns-abuse-tunneling-and-command-control DNS abuse, tunneling, and command-and-control open /threats/lateral-movement-after-initial-access Lateral movement after initial access open /threats/supply-chain-and-third-party-compromise Supply chain and third-party compromise

related-tools-in-this-path

Continue within the same guided track. These tools are commonly studied next in the path(s) this page belongs to.

Network Ops Path

open path

open tcpdump tcpdump open wireshark-tshark Wireshark / TShark open ncat Ncat open socat socat

<- previous tool Nmap -> next tool Suricata