What Zeek is

Zeek began life as Bro, written by Vern Paxson in the 1990s. It later took its present name. The Zeek Project maintains it under a BSD licence. It is passive. It reads traffic from an interface or from a saved capture and never blocks anything, so it is a monitor and not a firewall or an intrusion prevention system. An event engine takes the packet stream apart up to the application layer and scripts written in Zeek's own language react to events such as a new connection, a DNS answer, an HTTP request or a file transfer. The default scripts write a set of logs, one per protocol or activity, such as conn for every connection, dns, http, ssl and files, in tab-separated or JSON form. Community packages installed with the zkg package manager add parsers and detections.

An investigator meets Zeek in two ways. Either a sensor has been running and its logs already cover the period of interest, or Zeek is run after the fact over a capture to produce logs from it. Every connection carries a unique identifier that appears in all the logs it touched, so an analyst can go from a suspicious DNS answer to the connection it led to and on to the file that was downloaded and its hash. The project's installation guide lists packages for Linux distributions through the openSUSE Build Service, Homebrew on macOS, ports on FreeBSD and OpenBSD and Docker images. At the time of checking the long-term support line was 8.0 and the latest feature release 8.1.

Primary applications

Where it is used

  • Building a connection timeline from a large capture without opening it packet by packet
  • Listing DNS, HTTP, TLS and SSH activity host by host
  • Extracting files seen in traffic and hashing them for comparison with malware samples
  • Feeding structured logs to Timesketch, a SIEM or Arkime for search
  • Running community detection packages over past traffic
  • Continuous monitoring on a sensor so logs exist before an incident is known

Who uses it

  • Network forensic analysts
  • Security operations engineers running sensors
  • Incident responders working from sensor logs
  • Researchers studying protocol behaviour

Capabilities and limits

Major capabilities

  • Passive analysis of live interfaces or saved captures
  • Protocol analysers up to the application layer, including HTTP, DNS, SSL/TLS and SSH
  • Structured transaction logs in tab-separated or JSON form, linked by a connection identifier
  • A scripting language for custom logging, detection and extraction
  • File extraction and hashing from supported protocols
  • Package manager and community packages for added parsers and detections
  • Cluster deployment across several worker processes and sensors
  • Runs on hardware, virtual or cloud sensors

Technical limitations

  • It logs only what a script asks for. An unparsed protocol appears as a bare connection record
  • Encrypted sessions give the handshake fields and sizes, not the content
  • No packets are kept. Full packet capture needs Arkime or tcpdump alongside it
  • A sensor that drops packets under load produces silent gaps in the logs
  • The scripting language takes time to learn and most laboratory use depends on it
  • The project publishes no Windows build

Learning with DFRTI

Independent professional education covering the principles and workflows of Zeek. DFRTI is not a vendor training centre and its courses are not vendor certifications.

Courses that cover this tool

Product names and trademarks belong to their respective owners. DFRTI is an independent educational and research institute. Inclusion in this directory does not imply manufacturer endorsement, partnership or authorisation. Facts are checked against the manufacturer's public documentation on the date shown and may have changed since.

Go deeper with DFRTI

Free pages explain the ground. Structured courses, lab work and a mentor take you from knowing about it to doing it on a case.