NF1.4 The Zeek Log Directory Structure

Tier 1 — conn.log: The Investigation Foundation

conn.log is the single most important Zeek log. It records every TCP and UDP connection the sensor observes. Every investigation starts here.

Every connection that crosses the sensor gets one conn.log entry. The entry records: timestamp (ts), a unique connection ID (uid), source IP (id.orig_h), source port (id.orig_p), destination IP (id.resp_h), destination port (id.resp_p), protocol (proto), service detected (service), duration in seconds (duration), bytes sent by the originator (orig_bytes), bytes sent by the responder (resp_bytes), connection state (conn_state), and the Community ID hash (community_id).

The fields you'll query most are the 5-tuple (source/destination IPs and ports plus protocol), duration, and byte counts. These three dimensions answer the majority of investigation questions: who connected to whom (5-tuple), how long the connection lasted (duration), and how much data was transferred (byte counts).

The uid field is the universal join key across Zeek logs. When you find a suspicious connection in conn.log, the uid lets you find the same connection's DNS query in dns.log, TLS handshake in ssl.log, HTTP request in http.log, and files in files.log. This is how you pivot from "this connection looks suspicious" to "this is what the connection did."

Common conn.log queries:

# All connections from a specific source IP
cat conn.log | zeek-cut ts id.orig_h id.resp_h id.resp_p duration orig_bytes | grep "10.0.1.15"

# Top destinations by connection count
cat conn.log | zeek-cut id.resp_h | sort | uniq -c | sort -rn | head -10

# Connections with high outbound byte counts (potential exfiltration)
cat conn.log | zeek-cut ts id.orig_h id.resp_h orig_bytes | awk -F'\t' '$4 > 10000000' | sort -t$'\t' -k4 -rn

# Long-duration connections (potential C2)
cat conn.log | zeek-cut ts id.orig_h id.resp_h duration | awk -F'\t' '$4 > 3600' | sort -t$'\t' -k4 -rn

Tier 1 — dns.log: Where Every Attack Chain Starts

dns.log records every DNS query and response. The attacker's domain had to be resolved before the first connection was made — dns.log captures that moment.

Every DNS query that crosses the sensor produces a dns.log entry. The key fields are: query name (query), query type (qtype_name — A, AAAA, CNAME, MX, TXT, etc.), response code (rcode_name — NOERROR, NXDOMAIN, SERVFAIL), and answers (answers — the resolved IP addresses or other records).

DNS investigation patterns you'll use repeatedly:

# All queries for a specific domain
cat dns.log | zeek-cut ts id.orig_h query answers | grep "suspicious-domain.com"

# Queries that resolved to a specific IP
cat dns.log | zeek-cut ts query answers | grep "203.0.113.88"

# High-frequency query sources (potential DNS tunnelling)
cat dns.log | zeek-cut id.orig_h | sort | uniq -c | sort -rn | head -10

# TXT record queries (common in DNS tunnelling and C2)
cat dns.log | zeek-cut ts id.orig_h query qtype_name | grep "TXT"

# NXDOMAIN responses (potential DGA activity)
cat dns.log | zeek-cut ts id.orig_h query rcode_name | grep "NXDOMAIN" | head -20

Module NF3 covers DNS investigation in depth — tunnelling detection, passive DNS analysis, DGA identification, and the challenges of encrypted DNS.

Tier 1 — ssl.log: Encrypted Traffic Investigation

ssl.log records TLS handshake details for every encrypted connection. In 2026, most traffic is encrypted — ssl.log is your primary window into what those connections are.

Every TLS handshake produces an ssl.log entry. The key fields are: server name indication (server_name — the domain the client requested), TLS version (version), cipher suite (cipher), certificate subject (subject), certificate issuer (issuer), JA3 client fingerprint (ja3), and JA3S server fingerprint (ja3s).

JA3 and JA3S are TLS fingerprints calculated from the handshake parameters. Different TLS implementations produce different fingerprints. A web browser has a different JA3 hash than a Python requests library, which has a different hash than Cobalt Strike's beacon. JA3 fingerprinting lets you identify the client software without seeing the encrypted content — crucial for C2 detection.

# TLS connections to a specific server
cat ssl.log | zeek-cut ts server_name subject issuer ja3 | grep "suspicious-domain.com"

# Self-signed certificates (no issuer, or issuer equals subject)
cat ssl.log | zeek-cut ts server_name subject issuer | awk -F'\t' '$3 == $4'

# Connections with a specific JA3 hash (known C2 fingerprint)
cat ssl.log | zeek-cut ts id.orig_h id.resp_h server_name ja3 | grep "KNOWN_JA3_HASH"

# All unique JA3 fingerprints (baseline profiling)
cat ssl.log | zeek-cut ja3 | sort | uniq -c | sort -rn | head -20

Tier 2 — Protocol-Specific Logs

http.log captures HTTP requests and responses for unencrypted traffic. Key fields: method, host, URI, user_agent, status_code. In 2026, http.log is sparse for most environments because the majority of web traffic is HTTPS. Where it appears — internal web applications, proxy connections, malware download cradles on port 80 — it's highly valuable because you can see the full request details.

files.log records every file observed in network traffic, regardless of protocol. Key fields: filename, MIME type, file hash (MD5, SHA1, SHA256), file size, and source/destination. files.log is protocol-agnostic — it captures files transferred over HTTP, SMB, FTP, SMTP, and other protocols. Hash the file contents against threat intelligence to identify known malware.

smtp.log captures email message metadata — sender, recipient, subject, and relay chain. Valuable for phishing investigation (identifying the inbound phishing email) and mail exfiltration detection (unusual outbound SMTP to external servers).

ssh.log captures SSH connection details — authentication method, version, direction, key exchange algorithms, and auth_success. The auth_success field is critical for brute force detection: hundreds of entries with auth_success=F followed by auth_success=T from the same source is a successful brute force.

Tier 3 — Specialized Logs

smb_files.log and smb_mapping.log capture SMB file operations and share mappings. Essential for lateral movement investigation — when the attacker uses PsExec, maps a share, or transfers files over SMB. Module NF5 covers SMB investigation in depth.

notice.log contains Zeek's own detection findings — anomalies, protocol violations, and policy violations that Zeek identifies through its scripting engine. Not as specific as Suricata signatures, but valuable for unusual protocol behavior that doesn't match a known attack signature.

x509.log records detailed certificate information — separate from ssl.log, which records the TLS handshake context. x509.log contains the full certificate fields: subject, issuer, validity period, key length, signature algorithm. Useful for identifying expired, self-signed, or anomalous certificates.

Operational Logs

capture_loss.log records packet loss — gaps in the capture. Any non-zero packet loss means your sensor missed traffic, which means your evidence has gaps. Check this log regularly.

reporter.log records Zeek errors and warnings. Check this after any configuration change or upgrade.

packet_filter.log records the BPF filter applied to the capture interface. Verify this matches your intended filter — an incorrect BPF filter silently excludes traffic from analysis.