Zeek (Bro) Network Protocol Logs

Zeek does not alert. It records. Every connection, every DNS query, every HTTP request, every SSL certificate — structured, timestamped, and queryable. For incident responders working a network intrusion, Zeek logs are frequently the single most valuable data source available — providing the ground truth of what actually traversed the wire, independent of endpoint telemetry that may have been tampered with or destroyed.

What Is Zeek?

Zeek (formerly Bro) is an open-source network security monitor that performs passive traffic analysis on network links. Originally developed in 1994 by Vern Paxson at Lawrence Berkeley National Laboratory (LBNL) and the International Computer Science Institute (ICSI), Zeek was renamed from Bro in 2018 to reflect its evolution from a research prototype into a production-grade network analysis framework used by governments, critical infrastructure operators, and enterprises worldwide.

Unlike traditional intrusion detection systems (Snort, Suricata) that match packets against signature rulesets and produce alerts, Zeek operates as a protocol analyzer. It reassembles TCP streams, parses application-layer protocols (HTTP, DNS, SSL/TLS, SMB, SSH, SMTP, FTP, MODBUS, DNP3, and dozens more), and generates structured log entries for every observed transaction. A single HTTP request produces a log entry containing the timestamp, source and destination IPs, destination port, HTTP method, Host header, URI, User-Agent, referrer, response code, response body length, and MIME type. This level of detail is not available from NetFlow, firewall logs, or packet captures without manual dissection.

Zeek operates at the session layer and above. It does not store raw packets (that is the job of PCAP). Instead, it distills every network transaction into a structured, searchable record. A 24-hour PCAP from a moderately active network might consume 500 GB of disk. The equivalent Zeek logs for the same traffic typically consume 2–5 GB — a 100x reduction — while retaining the metadata investigators actually need: who talked to whom, on what port, using what protocol, for how long, and how many bytes in each direction.

Zeek’s architecture consists of an event engine that processes packets and generates events, and a policy script interpreter (written in the Zeek scripting language) that decides what to log. This scripting layer is what makes Zeek extensible: organizations can write custom scripts to extract fields from proprietary protocols, flag specific patterns, or enrich logs with threat intelligence. Corelight, the commercial company founded by Zeek’s creator, provides enterprise-grade Zeek sensors with additional protocol parsers, encrypted traffic analysis, and cloud integrations.

Location & Format

Default Paths

Log Format

By default, Zeek writes logs in TSV (tab-separated values) format. Each log file begins with header lines (prefixed with #) that define the field separator, field names, and field types. This self-describing format makes Zeek logs grep-friendly and parseable with standard Unix tools (awk, cut, sort). Zeek can also be configured to output in JSON format (via @load policy/tuning/json-logs), which is preferred for SIEM ingestion and tools like jq.

Key Log Files

What It Reveals

Zeek logs answer a comprehensive class of investigative questions that span network reconnaissance, lateral movement, command-and-control, and data exfiltration. The following questions are directly answerable from Zeek data:

• What hosts communicated, and with whom? — conn.log records every connection between any two IP addresses observed on the monitored segment. Internal-to-external, internal-to-internal, and external-to-internal traffic are all captured.
• What protocols were used? — The service field in conn.log identifies the application-layer protocol (http, dns, ssl, ssh, smb, ftp, smtp), even when traffic runs on non-standard ports. Zeek performs protocol detection independent of port number.
• How much data was transferred in each direction? — orig_bytes and resp_bytes in conn.log record the payload bytes (excluding headers) sent by the originator and responder respectively. A connection with 4.2 GB in orig_bytes and 12 KB in resp_bytes is a one-directional data transfer — exfiltration.
• What DNS queries resolved C2 domains? — dns.log records every query and response, including the resolved IP addresses. Cross-referencing against threat intelligence feeds identifies known C2 infrastructure before the connection is even analyzed.
• What HTTP URIs were accessed? — http.log records the full host + uri for every HTTP request, including POST requests to webshell endpoints, downloads from staging servers, and exfiltration over HTTP PUT/POST.
• What SSL certificates were presented? — ssl.log and x509.log capture certificate subject, issuer, validity dates, and Subject Alternative Names (SANs). Self-signed certificates, expired certificates, and Let’s Encrypt certificates on recently registered domains are strong indicators of malicious infrastructure.
• What are the JA3/JA3S fingerprints? — JA3 fingerprints the TLS Client Hello parameters (ciphers, extensions, elliptic curves); JA3S fingerprints the Server Hello response. Known malware families produce distinctive JA3 hashes that persist across IP rotation and domain changes. Cobalt Strike, Metasploit, and many commodity RATs have well-documented JA3 signatures.
• What files were transferred, and what are their hashes? — files.log records MD5, SHA1, and SHA256 hashes for files extracted from HTTP, FTP, SMTP, and SMB traffic. These hashes can be immediately checked against VirusTotal, YARA rules, or internal malware repositories.
• Are there beaconing patterns? — Regular-interval connections from an internal host to an external IP (e.g., every 60 seconds with 5% jitter) are the hallmark of C2 beacons. conn.log timestamps and byte counts reveal these patterns through statistical analysis.
• What unknown devices are on the network? — For OT/ICS networks, Zeek’s conn.log combined with MAC address OUI (Organizationally Unique Identifier) lookup identifies every device communicating on the monitored segment, including rogue devices and implants that have not been registered in asset inventories.

Forensic Use Cases

1. C2 Beacon Detection

Command-and-control beacons are designed to blend into normal traffic, but they cannot hide their timing patterns from statistical analysis of conn.log. An implant configured to call home every 60 seconds with 10% jitter produces connections at intervals of 54–66 seconds. Over 24 hours, this generates approximately 1,440 connections to the same destination — a pattern that is trivially detectable in Zeek data. The investigator extracts all connections from a suspect host, computes the inter-arrival time distribution, and identifies clusters with low standard deviation. The orig_bytes and resp_bytes fields further confirm the pattern: C2 heartbeats produce consistent, small payload sizes (check-in requests of 200–400 bytes, responses of 100–200 bytes), with occasional larger responses when the operator issues commands or stages payloads.

2. DNS Tunneling

DNS tunneling encodes data in DNS queries (typically TXT or CNAME records) to exfiltrate information through networks that allow DNS but block other outbound protocols. Zeek’s dns.log captures the full query string, response type, and answer content. Indicators include: abnormally long subdomain labels (base64-encoded data produces 40–60 character subdomains), high query volume to a single domain (thousands of TXT queries to data.evil.com in an hour), low TTL values in responses, and query types that are unusual for the queried domain (TXT records for domains that serve no legitimate TXT content). A single domain receiving more than 500 unique subdomain queries per hour from a single internal host is almost certainly DNS tunneling — legitimate DNS activity for a single domain rarely exceeds 10–20 queries per hour per host.

3. Data Exfiltration Over HTTP/HTTPS

When an adversary exfiltrates data over HTTP, http.log records the full URI, including the target host, path, and query parameters. Large POST requests to cloud storage APIs (api.mega.co.nz, content.dropboxapi.com, storage.googleapis.com) with request_body_len in the megabyte range are direct evidence of exfiltration. For HTTPS exfiltration, the payload is encrypted, but conn.log still records the total bytes transferred: a connection to a suspicious IP with 2.8 GB in orig_bytes and 4 KB in resp_bytes is a unidirectional outbound transfer regardless of encryption. The ssl.log JA3 fingerprint can further identify the tool used (curl, wget, rclone, and custom malware all produce distinctive JA3 hashes).

4. Lateral Movement Detection

Zeek monitors internal-to-internal traffic on the segments where its sensor is deployed. Lateral movement via SMB/RDP/WinRM produces characteristic conn.log entries: internal source IP to internal destination IP on ports 445, 3389, or 5985/5986. smb_mapping.log records share mappings including administrative shares (C$, ADMIN$, IPC$) that are commonly used for tool staging and remote execution. kerberos.log captures authentication events, enabling detection of pass-the-hash, pass-the-ticket, and Kerberoasting attacks. A workstation initiating SMB connections to 15 servers within a 10-minute window — especially using ADMIN$ shares — is a textbook lateral movement pattern.

5. OT/ICS Network Anomaly Detection

In operational technology environments, Zeek provides visibility into protocols that traditional security tools cannot parse. With the appropriate protocol analyzers loaded, Zeek can log MODBUS, DNP3, BACnet, EtherNet/IP, and S7comm transactions. In our Volt Typhoon OT investigation, a Zeek sensor deployed on a SPAN port of the ICS network switch identified a Raspberry Pi implant beaconing to an external IP every 300 seconds. The device was not in the asset inventory, and its MAC OUI resolved to “Raspberry Pi Trading Ltd” — a manufacturer that had no business being on an industrial control network. Without Zeek, the implant would have continued operating undetected: the OT network had no endpoint detection, no firewall logging, and no packet capture. Zeek’s conn.log was the only evidence that the device existed and was communicating externally.

Acquisition & Deployment

Sensor Deployment

Zeek requires visibility into raw network traffic. There are two primary methods for providing this visibility:

• SPAN/Mirror Port — The network switch is configured to copy all traffic from one or more ports (or VLANs) to a designated monitoring port where the Zeek sensor’s network interface is connected. Simple to configure, but can drop packets under heavy load if the SPAN port bandwidth is exceeded.
• Network TAP (Test Access Point) — A passive hardware device inserted inline on the network link. TAPs provide a complete, lossless copy of all traffic in both directions. Preferred for production deployments and forensic-quality data collection. Failing closed (traffic passes through even if the TAP loses power) is a standard safety feature.

Log Collection

# SecurityOnion: Current (live) logs
ls /nsm/zeek/logs/current/
# conn.log  dns.log  http.log  ssl.log  files.log  x509.log  ...

# SecurityOnion: Archived logs by date
ls /nsm/zeek/logs/2026-03-15/
# conn.15:00:00-16:00:00.log.gz  dns.15:00:00-16:00:00.log.gz  ...

# Standalone Zeek: Same structure under /opt/zeek/logs/
ls /opt/zeek/logs/current/
ls /opt/zeek/logs/2026-03-15/

# Collect all logs from a specific date range for analysis
mkdir -p /evidence/zeek-collection
cp -r /nsm/zeek/logs/2026-03-10/ /evidence/zeek-collection/
cp -r /nsm/zeek/logs/2026-03-11/ /evidence/zeek-collection/
cp -r /nsm/zeek/logs/2026-03-12/ /evidence/zeek-collection/

# Decompress archived logs for analysis
gunzip /evidence/zeek-collection/2026-03-10/*.gz

Remote Collection via SCP

# Collect from remote sensor over SSH
scp -r analyst@sensor01:/nsm/zeek/logs/2026-03-10/ /evidence/zeek/sensor01/
scp -r analyst@sensor01:/nsm/zeek/logs/2026-03-11/ /evidence/zeek/sensor01/

# Alternatively, use rsync for large collections with resume capability
rsync -avz --progress analyst@sensor01:/nsm/zeek/logs/ /evidence/zeek/sensor01/ \
      --include='2026-03-1*/' --include='2026-03-1*/**' --exclude='*'

Parsing Tools & Analysis

zeek-cut: Native Field Extraction

# Extract source IP, destination IP, destination port, and bytes from conn.log
cat conn.log | zeek-cut id.orig_h id.resp_h id.resp_p orig_bytes resp_bytes

# Find all connections to a specific C2 IP
cat conn.log | zeek-cut ts id.orig_h id.resp_h id.resp_p service duration orig_bytes | \
    grep "198.51.100.47"

# List all DNS queries sorted by frequency (top talkers)
cat dns.log | zeek-cut query | sort | uniq -c | sort -rn | head -20

# Find HTTP requests with suspicious User-Agent strings
cat http.log | zeek-cut ts host uri user_agent | grep -i "python-requests\|curl\|wget\|powershell"

# Extract all SSL certificates that are self-signed
cat ssl.log | zeek-cut ts server_name subject issuer validation_status | \
    grep "self signed"

# Find all file transfers with MD5 hashes (for VirusTotal lookup)
cat files.log | zeek-cut ts source mime_type filename md5 sha256 total_bytes | \
    grep -v "^#" | grep -v "^$"

RITA: Automated Beacon Detection

# Import Zeek logs into RITA database
rita import /evidence/zeek/2026-03-10/ --database case_2026_03

# Analyze for beaconing behavior
rita show-beacons case_2026_03

# Output: Source, Destination, Connections, Score, Avg Bytes, Intvl Range
# 10.10.5.22    198.51.100.47    1437    0.982    287    54-66
# Score of 0.982 = near-certain beacon (1.0 = perfect regularity)

# Show DNS tunneling indicators
rita show-exploded-dns case_2026_03

# Show long-duration connections (potential C2 or persistent tunnels)
rita show-long-connections case_2026_03

Python: Beaconing Detection Script

# Detect C2 beaconing patterns in conn.log

import pandas as pd
import numpy as np

# Load conn.log (TSV format, skip comment lines)
df = pd.read_csv('/evidence/zeek/conn.log', sep='\t', comment='#',
                 names=['ts','uid','orig_h','orig_p','resp_h','resp_p',
                        'proto','service','duration','orig_bytes',
                        'resp_bytes','conn_state','local_orig',
                        'local_resp','missed_bytes','history',
                        'orig_pkts','orig_ip_bytes','resp_pkts',
                        'resp_ip_bytes','tunnel_parents'])

# Group by source-destination pair
pairs = df.groupby(['orig_h', 'resp_h'])

for (src, dst), group in pairs:
    if len(group) < 50:  # Need sufficient samples
        continue

    # Calculate inter-arrival times
    times = group['ts'].sort_values().diff().dropna()
    mean_interval = times.mean()
    std_interval = times.std()

    # Jitter ratio: low std/mean = regular beaconing
    if mean_interval > 0:
        jitter = std_interval / mean_interval
        if jitter < 0.15 and 10 < mean_interval < 3600:
            print(f"BEACON: {src} -> {dst}"
                  f" | conns={len(group)}"
                  f" | interval={mean_interval:.1f}s"
                  f" | jitter={jitter:.3f}")

Retention & Persistence

Anti-Forensics Resilience

Zeek logs are a network-level artifact generated on a dedicated sensor that is architecturally separate from the systems being monitored. This separation provides inherent resilience against anti-forensics techniques that target endpoints.

MITRE ATT&CK Detection Mapping

Zeek logs provide evidentiary support for detecting the following MITRE ATT&CK techniques:

Related Artifacts & Case Studies

Corroborating Artifacts

Case Study

References

1. Zeek Project, “Zeek Documentation” — https://docs.zeek.org/
2. SecurityOnion Solutions, “SecurityOnion Documentation” — https://docs.securityonion.net/
3. Active Countermeasures, “RITA — Real Intelligence Threat Analytics” — https://www.activecountermeasures.com/free-tools/rita/
4. Corelight, “Zeek and Network Detection and Response” — https://corelight.com/blog
5. SANS Institute, “SEC503: Network Monitoring and Threat Detection In-Depth” — https://www.sans.org/cyber-security-courses/network-monitoring-threat-detection/
6. Salesforce Engineering, “JA3 — A Method for Profiling SSL/TLS Clients” — https://github.com/salesforce/ja3
7. Brim Data, “Zui (formerly Brim) — Desktop App for Zeek and PCAP” — https://zui.brimdata.io/
8. Vern Paxson, “Bro: A System for Detecting Network Intruders in Real-Time,” Computer Networks, 1999 — https://www.icir.org/vern/papers/bro-CN99.pdf