hack3rs.ca network-security
/learning/tools/zeek :: tool-guide-3

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

Zeek

Network telemetry

Zeek provides rich, structured network telemetry that helps defenders investigate incidents, hunt suspicious behavior, and understand protocol activity at scale without relying only on signatures.

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

Study the tool in layers: first what problem it solves, then how to run it safely, then how to interpret output, and finally how to combine it with other evidence. This is how beginners become reliable analysts.

  • $Know when the tool is the right choice (and when it is not).
  • $Run a safe baseline command in a lab or authorized environment.
  • $Interpret the output in context instead of treating it as truth by itself.
  • $Correlate with other evidence sources (logs, packets, assets, owner context).
  • $Document findings and next actions so another analyst can reproduce your work.

preflight-checklist-before-using-tool

  • $Confirm authorization, target scope, and acceptable impact before running commands.
  • $Define the question first (troubleshooting, validation, hunting, triage, remediation proof).
  • $Identify the evidence source you will use to confirm or challenge tool output.
  • $Record time, host, interface/segment, and command used so results are reproducible.
  • $Decide what 'normal' should look like before testing edge cases or suspicious behavior.

how-experts-read-output

  • $Field recognition: Which fields actually matter for the question you asked?
  • $Scope validation: Does this output represent the host/segment/time window you intended?
  • $Confidence check: Is this direct evidence, inference, or a heuristic guess?
  • $Correlation step: Which second source should confirm this result (logs, PCAP, ticket, CMDB, host telemetry)?
  • $Decision step: What action should follow (close, escalate, tune, scan deeper, validate manually)?

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 have authorization to monitor traffic and where privacy requirements are understood. Even metadata and protocol logs can reveal user behavior, internal services, and sensitive operational details.

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

Define retention, access controls, and acceptable use policies for Zeek logs. Telemetry is powerful and should be treated as sensitive security data with role-based access and auditability.

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 hunting after new indicators or incident findings appear.
  • +Protocol-level context for suspicious outbound traffic and beaconing investigations.
  • +DNS and HTTP telemetry for threat hunting and anomaly review.
  • +Network-side validation to enrich endpoint or SIEM alerts.

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 is a network analysis framework that produces structured logs about network activity. Instead of focusing only on signatures, Zeek emphasizes protocol parsing and metadata generation, which gives defenders a rich source of evidence for investigations and hunting.

Zeek shines when you need context: connection histories, DNS requests, HTTP metadata, TLS details, files metadata, notices, and many other protocol records. This makes it useful for retrospective analysis and for building custom detections around behavior.

For blue teams, Zeek often fills the gap between raw packet capture and high-level alerts. It preserves key protocol visibility without the storage cost and sensitivity footprint of full packet capture everywhere.

2. Core Zeek Logs and How To Read Them

The most important starting logs for defenders are often conn.log, dns.log, http.log, ssl/tls logs, and notice.log. These reveal who communicated, when, over what protocol, and with what basic application-level metadata.

Zeek logs are structured and consistent, which makes them friendly for SIEM ingestion and ad hoc analysis. Learn how to read timestamps, unique IDs, origin/response hosts, durations, byte counts, and protocol-specific fields before building advanced queries.

A strong Zeek analyst learns to pivot across logs. A suspicious domain in dns.log can be traced to connections in conn.log, then to HTTP or TLS context, then matched against host or alert data in your broader stack.

3. Zeek Deployment and Sensor Placement

Zeek value depends heavily on placement. Place sensors where they can see meaningful traffic: internet edges, VPN concentrators, critical server segments, and strategic east-west choke points. A perfectly configured Zeek sensor in the wrong place yields limited value.

Understand what traffic is mirrored and what is not. Asymmetric routing, SPAN oversubscription, cloud mirroring choices, and encryption visibility all affect what Zeek can observe. Analysts should document these limitations to avoid false assumptions during investigations.

Start small and stable. A well-instrumented pilot segment with reliable logging and clear retention is more useful than a rushed large deployment that no one can parse or maintain.

4. Threat Hunting and Retrospective Analysis with Zeek

Zeek is excellent for hunting because it preserves behavior-oriented metadata across time. Analysts can query unusual DNS patterns, rare destinations, odd protocol usage, suspicious user agents, or beacon-like connection intervals without needing packet payloads.

Retrospective analysis is where Zeek often pays off. After an incident indicator appears, defenders can look back through historical logs to identify earliest activity, lateral movement patterns, and related systems that communicated with the same infrastructure.

Zeek does not eliminate the need for endpoint and identity logs. Its strength is correlation: it helps you build a network-side narrative that can be combined with host evidence for faster and more confident incident scoping.

5. Custom Detections and Zeek Scripting Mindset

Zeek can be extended with scripts and packages to generate notices or enrich telemetry. Many teams start with stock logging and gradually add custom logic once they understand what “normal” looks like in their environment.

Defensive scripting should be hypothesis-driven. Write logic for a specific behavior you care about (for example unusual DNS query volume from a host class, or protocol use on unexpected ports), test it in a lab, and validate false-positive behavior before rolling out widely.

Treat custom Zeek logic like production code: version control it, document assumptions, and review changes after incidents or environment shifts. This reduces silent drift and keeps detections maintainable.

6. Operational Challenges and Tuning

Zeek can produce large volumes of data. Success requires planning around retention, parsing, indexing, and query performance. Do not deploy Zeek without deciding where the logs go and who will use them.

Tuning is not only about volume. It is also about choosing which logs to prioritize, how to enrich them, and how to present them to analysts. High-quality queries and dashboards often matter more than collecting every available log type on day one.

Health monitoring matters too. Sensor drops, mirror issues, and parsing pipeline failures can quietly degrade visibility. Treat Zeek sensors and pipelines as production systems with monitoring and maintenance.

7. Learning Zeek Effectively

Begin with PCAP replay in a lab so you can compare packet evidence and Zeek logs side by side. This builds intuition about what Zeek extracts and what remains only in packets.

Learn one investigation workflow well: suspicious domain -> DNS log -> connection log -> TLS/HTTP log -> host log correlation. Repeat it until it becomes muscle memory.

As your skills grow, add scripting, package usage, and telemetry quality reviews. Zeek expertise compounds over time because better understanding of protocols produces better hunts and better custom detections.

scenario-teaching-playbooks

Use these scenario patterns to practice choosing the tool appropriately. The point is not just running commands; it is learning when and why the tool helps in a real defensive workflow.

1. Retrospective hunting after new indicators or incident findings appear.

Suggested starting block: PCAP Replay For Learning

  • $Define the question you are trying to answer and the scope you are allowed to inspect.
  • $Collect baseline evidence using the selected command block.
  • $Interpret the result using known-good behavior and environment context.
  • $Correlate with another source (host logs, SIEM, tickets, inventory, or packet data).
  • $Record findings, confidence level, and the next defensive action.

2. Protocol-level context for suspicious outbound traffic and beaconing investigations.

Suggested starting block: Basic Log Exploration

  • $Define the question you are trying to answer and the scope you are allowed to inspect.
  • $Collect baseline evidence using the selected command block.
  • $Interpret the result using known-good behavior and environment context.
  • $Correlate with another source (host logs, SIEM, tickets, inventory, or packet data).
  • $Record findings, confidence level, and the next defensive action.

3. DNS and HTTP telemetry for threat hunting and anomaly review.

Suggested starting block: Service Deployment (Environment-Specific)

  • $Define the question you are trying to answer and the scope you are allowed to inspect.
  • $Collect baseline evidence using the selected command block.
  • $Interpret the result using known-good behavior and environment context.
  • $Correlate with another source (host logs, SIEM, tickets, inventory, or packet data).
  • $Record findings, confidence level, and the next defensive action.

4. Network-side validation to enrich endpoint or SIEM alerts.

Suggested starting block: PCAP Replay For Learning

  • $Define the question you are trying to answer and the scope you are allowed to inspect.
  • $Collect baseline evidence using the selected command block.
  • $Interpret the result using known-good behavior and environment context.
  • $Correlate with another source (host logs, SIEM, tickets, inventory, or packet data).
  • $Record findings, confidence level, and the next defensive action.

cli-workflows

Practical defensive workflows and lab-safe commands. Validate in a sandbox or authorized environment before using them in production.

cli-walkthroughs-with-expected-output

Start with one representative command from each workflow block. Read the sample output and explanation so you know what to look for when you run it yourself.

PCAP Replay For Learning

Beginner
Command
mkdir -p zeek-lab && cd zeek-lab
Example Output
# review output for expected fields, errors, and warnings
# compare against a known-good baseline in your environment

$ how to read it: Check for expected fields first, then validate whether the output actually answers your question. If not, refine scope or collect a second evidence source before concluding.

Basic Log Exploration

Intermediate
Command
cut -f 1-8 conn.log | head -20
Example Output
# review output for expected fields, errors, and warnings
# compare against a known-good baseline in your environment

$ how to read it: Check for expected fields first, then validate whether the output actually answers your question. If not, refine scope or collect a second evidence source before concluding.

Service Deployment (Environment-Specific)

Advanced
Command
sudo zeekctl deploy
Example Output
# review output for expected fields, errors, and warnings
# compare against a known-good baseline in your environment

$ how to read it: Check for expected fields first, then validate whether the output actually answers your question. If not, refine scope or collect a second evidence source before concluding.

command-anatomy-and-expert-usage

This breaks down each command so learners understand intent, risk, and interpretation. Expert use is not about memorizing syntax; it is about selecting the right command for the right question and reading the result correctly.

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: run this command only when it answers a clear defensive question.
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 
# review output for expected fields, errors, and warnings
# compare against a known-good baseline in your environment

$ expert reading pattern: Confirm the output matches your intended scope, identify the key fields, then validate with a second source before making decisions.

PCAP Replay For Learning

Beginner
Command
zeek -r sample.pcap
Command Anatomy
  • $Base command: zeek
  • $Primary arguments/options: -r sample.pcap
  • $Operator goal: run this command only when it answers a clear defensive question.
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: Confirm the output matches your intended scope, identify the key fields, then validate with a second source before making decisions.

PCAP Replay For Learning

Beginner
Command
ls *.log
Command Anatomy
  • $Base command: ls
  • $Primary arguments/options: *.log
  • $Operator goal: run this command only when it answers a clear defensive question.
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 
# review output for expected fields, errors, and warnings
# compare against a known-good baseline in your environment

$ expert reading pattern: Confirm the output matches your intended scope, identify the key fields, then validate with a second source before making decisions.

PCAP Replay For Learning

Beginner
Command
head -20 conn.log
Command Anatomy
  • $Base command: head
  • $Primary arguments/options: -20 conn.log
  • $Operator goal: run this command only when it answers a clear defensive question.
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 
# review output for expected fields, errors, and warnings
# compare against a known-good baseline in your environment

$ expert reading pattern: Confirm the output matches your intended scope, identify the key fields, then validate with a second source before making decisions.

PCAP Replay For Learning

Beginner
Command
head -20 dns.log
Command Anatomy
  • $Base command: head
  • $Primary arguments/options: -20 dns.log
  • $Operator goal: run this command only when it answers a clear defensive question.
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 
# review output for expected fields, errors, and warnings
# compare against a known-good baseline in your environment

$ expert reading pattern: Confirm the output matches your intended scope, identify the key fields, then validate with a second source before making decisions.

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: run this command only when it answers a clear defensive question.
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 
# review output for expected fields, errors, and warnings
# compare against a known-good baseline in your environment

$ expert reading pattern: Confirm the output matches your intended scope, identify the key fields, then validate with a second source before making decisions.

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: run this command only when it answers a clear defensive question.
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 
# review output for expected fields, errors, and warnings
# compare against a known-good baseline in your environment

$ expert reading pattern: Confirm the output matches your intended scope, identify the key fields, then validate with a second source before making decisions.

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: run this command only when it answers a clear defensive question.
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 
# review output for expected fields, errors, and warnings
# compare against a known-good baseline in your environment

$ expert reading pattern: Confirm the output matches your intended scope, identify the key fields, then validate with a second source before making decisions.

Service Deployment (Environment-Specific)

Advanced
Command
sudo zeekctl deploy
Command Anatomy
  • $Base command: sudo
  • $Primary arguments/options: zeekctl deploy
  • $Operator goal: run this command only when it answers a clear defensive question.
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 
# review output for expected fields, errors, and warnings
# compare against a known-good baseline in your environment

$ expert reading pattern: Confirm the output matches your intended scope, identify the key fields, then validate with a second source before making decisions.

Service Deployment (Environment-Specific)

Advanced
Command
sudo zeekctl status
Command Anatomy
  • $Base command: sudo
  • $Primary arguments/options: zeekctl status
  • $Operator goal: run this command only when it answers a clear defensive question.
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 
# review output for expected fields, errors, and warnings
# compare against a known-good baseline in your environment

$ expert reading pattern: Confirm the output matches your intended scope, identify the key fields, then validate with a second source before making decisions.

Service Deployment (Environment-Specific)

Advanced
Command
sudo zeekctl diag
Command Anatomy
  • $Base command: sudo
  • $Primary arguments/options: zeekctl diag
  • $Operator goal: run this command only when it answers a clear defensive question.
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 
# review output for expected fields, errors, and warnings
# compare against a known-good baseline in your environment

$ expert reading pattern: Confirm the output matches your intended scope, identify the key fields, then validate with a second source before making decisions.

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 hunting after new indicators or incident findings appear.
  • $Protocol-level context for suspicious outbound traffic and beaconing investigations.
  • $DNS and HTTP telemetry for threat hunting and anomaly review.
  • $Network-side validation to enrich endpoint or SIEM alerts.

common-mistakes

  • $Deploying Zeek without a plan for log ingestion, storage, or analyst consumption.
  • $Assuming sensor placement sees all traffic when routing or mirroring creates blind spots.
  • $Collecting many logs but building no repeatable hunting or triage workflows.
  • $Writing custom detections before establishing a baseline of normal behavior.

expert-habits-for-free-self-study

This site is a free teaching resource. Use this loop to train yourself like a working defender: ask a question, collect evidence, interpret carefully, validate, document, and repeat.

  • $Start with the least invasive command that can answer your question.
  • $Write down why you ran the command before interpreting the output.
  • $Treat output as evidence, not truth, until validated against another source.
  • $Save exact commands used so another analyst can reproduce your findings.
  • $Capture 'normal' examples during calm periods for future comparison.
  • $Escalate only after you can explain what you observed and why it matters.

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 sample PCAPs and map packet events to Zeek logs.
# Build a small set of hunts using conn.log, dns.log, and HTTP/TLS logs.
# Document sensor placement assumptions and known coverage gaps.
# Create one custom Zeek detection hypothesis and test it in a lab.

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.

<- previous tool Nmap -> next tool Suricata