Zeek Network Monitoring Guide: Logs, Scripts, Hunting

Most security teams can see what their endpoints and cloud control planes did, but cannot answer simple questions about what crossed the network last Tuesday. Zeek fills that gap by turning raw traffic into compact, structured logs of every connection and the application protocols inside it. This guide explains what Zeek produces, how its scripting and cluster model work, how to deploy sensors safely and feed a SIEM, and which hunts its logs make practical, including baselines for machine and API traffic. It is written for SOC analysts, detection engineers and network security architects.

Key takeaways

Zeek is a log generator, not a signature IDS. Its own documentation positions it between full packet capture and alerts: transaction logs, extracted files and notices.
The uid ties everything together. Each connection gets a unique identifier that appears in conn.log and in every protocol log it produced, so one query pivots from a flow to its DNS, TLS, HTTP and file records.
Sensor placement decides the value. Monitor where original source addresses are still visible, using a tap where possible and a SPAN port where not.
Hunting is where Zeek pays back. Long connections, rare certificates, odd DNS and unexpected service account destinations are all queries over Zeek logs, not new products.
Logs are sensitive data. DNS queries, URIs, user agents and file hashes describe people's activity, so retention and access need the same discipline as any other monitoring data.

What the tool does

The Zeek documentation describes Zeek as "a passive, open-source network traffic analyzer" that many operators use as a network security monitor. It watches a network interface (or reads a pcap) and writes well structured tab separated or JSON logs: a record of every connection plus application layer transcripts for HTTP, DNS, TLS, SMTP and many other protocols. All of Zeek's default analyses, including logging, are implemented in its own Turing complete scripting language rather than hard coded, which is what makes it extensible.

The documentation is equally clear about what Zeek is not. It is "not optimized for byte matching", and users seeking signature detection are pointed to IDS engines such as Suricata. It is not a frame level protocol analyser like Wireshark, and it is not a system for storing traffic as pcap. Zeek was created by Vern Paxson at Lawrence Berkeley National Laboratory in 1995 under the name Bro, renamed Zeek in 2018, and released as Zeek 3.0 in 2019. It is distributed under a permissive BSD licence, with Corelight acting as the project's custodian.

The logs you will use most

Log	What it records	Typical security questions
conn.log	Every TCP, UDP and ICMP connection: uid, endpoints and ports, service, duration, orig_bytes, resp_bytes, conn_state, history	Who talked to whom, for how long, how much data left
dns.log	Queries and responses, query type, answers, response codes	Rare domains, NXDOMAIN bursts, long or random looking names
http.log	Method, host, URI, user agent, status, MIME types	Cleartext API calls, unusual user agents, downloads
ssl.log	TLS version, cipher, server name, ALPN next protocol, validation status	Legacy TLS, unexpected server names, self signed services
x509.log	Certificate subject, issuer, validity, key details	New or rare issuers, short lived or expired certificates
files.log	Files seen in traffic, MIME type, hashes, source protocol	Executables over HTTP, file hash matches
notice.log	Situations explicitly detected by scripts	The closest Zeek output to an alert
weird.log	Protocol oddities flagged by analysers	Evasion, broken implementations; high volume, review selectively

Other logs include ssh, smtp, ftp, dhcp, ntp, smb, kerberos, ntlm, ldap, quic, rdp, tunnel, pe, software, known_hosts, known_services and known_certs, plus capture_loss.log and reporter.log for sensor health. Two details from the documentation matter in practice. First, conn.log's history field encodes what each side did, with uppercase for the originator and lowercase for the responder: ShADadFf is a handshake, data both ways and a graceful close, matching conn_state SF. Second, there is no x509.log entry for TLS 1.3 sessions, because the certificate is encrypted in the handshake, so certificate hunting increasingly relies on ssl.log server names.

Scripting in general terms

Zeek scripts react to events (a new connection, a DNS reply, a certificate seen) and can log fields, keep state and raise notices through the Notice framework. A notice has a Notice::Type, for example the bundled SSH::Password_Guessing, and policy decides the action: Notice::ACTION_LOG writes it to notice.log, Notice::ACTION_EMAIL also emails it, and suppression intervals stop repeats flooding the log. Site customisation lives in local.zeek, and community packages are installed with the Zeek package manager. Treat scripts and packages as code: review them, pin versions and test them against recorded pcaps with zeek -r before they reach production sensors.

Defender use cases

Alert enrichment: the documentation describes pivoting from an IDS alert to Zeek logs, using the Community ID flow hash where the IDS supports it, so a terse alert gains DNS, TLS and file context. See the Suricata IDS Guide.
Incident scoping without touching the host: querying stored Zeek logs reveals what a suspect system contacted without alerting an intruder or changing the asset's state. See the Network Forensics Guide.
Indicator matching: search weeks of logs for IP addresses, domains, server names, user agents or file hashes from threat intelligence.
Hypothesis driven hunting: the documentation distinguishes "matching" known indicators from "hunting", which tests a hypothesis about how adversary behaviour would appear in the data. See the Threat Hunting Guide.
Asset and service discovery: known_hosts, known_services and software logs show what is actually running, often surfacing unmanaged services.

Hunts that work well on Zeek data

Hunt	Logs and fields	Related ATT&CK technique
Long lived or highly regular outbound connections (beaconing)	conn.log duration, interval between ts values per pair, orig_bytes	T1573 Encrypted Channel
Rare or new TLS certificates and server names	x509.log issuer and subject, ssl.log server_name, validation status; count first seen values	T1573 Encrypted Channel
DNS anomalies: long labels, high query volume to one domain, TXT heavy traffic	dns.log query length, qtype, rcode, unique subdomains per parent	T1071.004 DNS; T1572 Protocol Tunneling
Large outbound transfers on unusual protocols	conn.log orig_bytes far above resp_bytes, service	T1048 Exfiltration Over Alternative Protocol
Traffic with no recognised application protocol	conn.log entries with empty service on uncommon ports	T1095 Non-Application Layer Protocol

Where identity fits: NHI and API traffic baselines

Service accounts, workloads and AI agents are noisy but predictable on the network, which makes them good baseline candidates. Build per source baselines from conn.log and ssl.log for build servers, integration hosts and agent runtimes: which API endpoints (by server name) they call, at what volume and at what times. Alert or hunt when a workload starts reaching a new cloud API, a paste site or a model provider it has never used, which is a common sign that a token or API key is being abused from inside. Any http.log record of an Authorization header or API key over cleartext HTTP is a finding to rotate immediately. See the API Key Management Guide and the LLMjacking Guide.

Deployment and safe use

Write down scope and approval. Record which segments are monitored, why, what is logged and for how long. Zeek's original name was chosen as a reminder that monitoring comes with privacy risk; take legal advice where staff traffic is in scope. See the Employee Monitoring and Privacy Guide.
Choose the sensor location. The documentation's requirement is a point with maximum visibility where devices keep their original source IP addresses, which usually means inside NAT, at internet egress and at key internal choke points. It notes that professional users prefer powered network taps and treat SPAN ports as an acceptable alternative.
Pilot on recorded traffic. Run zeek -r sample.pcap LogAscii::use_json=T against captures from your own network to confirm parsing, field names and volume before going live.
Start standalone, then cluster. ZeekControl (zeekctl) manages deployments from node.cfg: start with one node, then move to a cluster. A cluster has workers that sniff and analyse traffic, a manager, one or more proxies (one is usually enough for four or fewer workers) and optionally a logger that receives all logs. A front end load balancer splits traffic symmetrically so each worker sees both directions of its flows.
Harden the sensor. Use a dedicated capture interface with no IP address, a separate management interface, restricted administrative access and timely Zeek updates. Monitor capture_loss.log: a sensor dropping packets produces incomplete logs that look complete.
Ship and protect logs. Prefer JSON output, set Log::default_rotation_interval (the default 0 seconds disables rotation), forward to the SIEM or data lake over an encrypted channel, and restrict who can query DNS and HTTP logs.
Configure file extraction deliberately. files.log records files seen, but extraction to disk happens only for types you configure. Extract narrowly (for example executables) and quarantine the output.
Roll back safely. Keep previous local.zeek and package versions under version control so a script that breaks or floods logs can be reverted with a redeploy.

SIEM integration

The documentation notes that external databases or SIEM products can consume, store and present Zeek data. Normalise field names once (Zeek's dotted fields such as id.orig_h often need mapping), keep the uid as a join key, and size storage for conn.log and dns.log first because they dominate volume. See the SIEM Guide and the Log Management and Retention Guide.

Detection and hardening value

Framework	Reference	How Zeek contributes
NIST CSF 2.0	DE.CM-01, DE.AE-02, DE.AE-03	Network monitoring, analysis of adverse events, correlation with endpoint and identity data
NIST SP 800-53 Rev. 5	SI-4, AU-12, AU-6, AU-11	System monitoring, record generation, review, retention of network records
CIS Controls v8.1	Control 13 Network Monitoring and Defense; Control 8 Audit Log Management	Network traffic flow logging, centralised log collection
ISO/IEC 27001:2022	Annex A 8.15 Logging, 8.16 Monitoring activities	Evidence that network activity is logged and reviewed
MITRE D3FEND	D3-NTA, D3-DNSTA, D3-CA, D3-PMAD	Network traffic, DNS traffic, certificate and protocol metadata anomaly analysis

Zeek also has hardening value that is easy to miss: ssl.log reveals legacy TLS versions still in use, http.log reveals cleartext authentication, and software.log reveals outdated client and server versions, each of which becomes a remediation ticket.

Metrics

Percentage of internet egress and critical internal segments covered by a Zeek sensor.
Capture loss percentage per sensor per day, trended against traffic peaks.
Log delivery latency from sensor to SIEM.
Number of hunts run per quarter on Zeek data and the detections they produced.
Share of network alerts closed with Zeek context attached.
Count of service accounts and workloads with a documented network baseline.

Alternatives

Option	Strength	Choose it when
Suricata	Signature IDS and IPS with protocol logging	You need real time alerts on known patterns; many teams run it alongside Zeek
NetFlow or IPFIX from network devices	No sensors needed, low storage	You only need who talked to whom; no application detail
Wireshark and TShark	Frame level depth	Investigating a bounded set of packets; see the Wireshark for Security Analysis Guide
Security Onion	Packaged Zeek, Suricata, full packet capture and search	A small team wants an integrated open source stack; see the Security Onion Guide
Commercial NDR	Detection models, support, managed sensors	Staff to build and tune a pipeline are not available; see the NDR Guide

Small vs large organisations: a small organisation can run one standalone Zeek sensor at egress and ship JSON logs to an existing SIEM. A large one needs clustered sensors per site, a logger tier, capacity planning for log volume and a detection engineering team that owns scripts and hunts. Encryption limits both: Zeek sees TLS metadata, not content, and DNS over HTTPS hides queries from dns.log, so endpoint and resolver logs remain necessary. See the DNS Security Guide.

Practitioner checklist

Document monitoring scope, legal basis, retention and access for Zeek logs.
Place sensors where original source addresses are visible, using taps where possible.
Test scripts and packages against recorded pcaps before deploying.
Emit JSON, enable rotation and forward logs encrypted to the SIEM with uid preserved.
Alert on capture loss and on sensors that stop sending logs.
Configure file extraction only for defined types and quarantine output.
Run a monthly hunt on long connections, rare certificates and DNS anomalies.
Baseline network behaviour of service accounts, build systems and AI agents.
Keep local.zeek and package versions under version control for rollback.

Zeek Network Monitoring Guide: Network Logs, Scripts and Threat Hunting