Deploying passive network security monitoring at key network choke points for continuous visibility
Generating structured connection, DNS, HTTP, SSL, and file transfer logs for SIEM ingestion and threat hunting
Writing custom Zeek scripts to detect organization-specific threats, policy violations, or beaconing behavior
Performing retrospective analysis on network metadata to investigate security incidents
Complementing IDS solutions with protocol-level metadata analysis that signature-based tools may miss
Do not use as a replacement for inline IDS/IPS that can actively block traffic, for monitoring encrypted payloads without TLS inspection, or on endpoints where host-based agents are more appropriate.
Detection Gaps & Validation
SPAN/tap drops create silent blind spots: an oversubscribed mirror or NIC offload (GRO/LRO reassembly) makes Zeek miss frames, so beacons look intermittent. Confirm ethtool -k eth1 shows offloads off, check capture_loss.log / zeekctl netstats for drops, and verify the Site::local_nets in networks.cfg actually match your subnets or every internal/external test breaks.
Encrypted C2 evades content checks: DoH/DoT and TLS beacons leave no dns.log query or HTTP user_agent. Pivot to ssl.log (JA3, server_name, validation_status) and conn.log timing/byte-asymmetry instead of relying on the DNS/HTTP long-query scripts.
Beacon jitter beats fixed thresholds: the SumStats beacon_threshold=50/1hr count misses low-and-slow or randomized intervals. Score on inter-connection interval regularity (low stddev) per id.orig_h→id.resp_h:id.resp_p, and consider RITA for connection-count + interval analysis.
DNS-tunneling script gaps:max_query_length=50 and a per-source query count miss short-label tunnels and answer-side (TXT/NULL) exfil. Add qtype_name/answers inspection and unique-subdomain-per-parent counting.
Validate scripts actually load and fire: run zeekctl deploy then zeekctl diag (no script errors), replay a known-bad pcap (zeek -r c2.pcap local), and confirm shows /. A clean notice.log on known-bad traffic means the script isn't loaded in or the threshold/ is wrong.
notice.log
DNS_Tunneling_Detected
Possible_Beaconing
local.zeek
local_nets
FP tuning: exclude Windows Update, AV update, NTP, and CDN/cloud IP ranges from beacon detection before alerting, or legitimate periodic traffic floods notice.log.
Prerequisites
Zeek 6.0+ installed from source or package manager (zeek --version)
Network interface configured on a span port, network tap, or virtual switch mirror for passive capture
Sufficient disk storage for log files (estimate 1-5 GB/day per 100 Mbps of monitored traffic)
Familiarity with Zeek's scripting language for writing custom detections
Log aggregation system (Splunk, Elastic, Graylog) for centralized analysis
Workflow
Step 1: Install and Configure Zeek
# Install Zeek on Ubuntu/Debiansudo apt install -y zeek
# Or install from source for latest version
git clone --recursive https://github.com/zeek/zeek
cd zeek && ./configure --prefix=/opt/zeek && make -j$(nproc) && sudo make install
export PATH=/opt/zeek/bin:$PATH# Configure the monitoring interfacesudo vi /opt/zeek/etc/node.cfg
# Disable NIC offloading for accurate packet capturesudo ethtool -K eth1 rx off tx off gro off lro off tso off gso off
# Deploy Zeeksudo zeekctl deploy
# Verify Zeek is runningsudo zeekctl status
Step 2: Understand and Navigate Zeek Logs
# Zeek generates structured log files in /opt/zeek/logs/current/ls /opt/zeek/logs/current/
# Key log files:# conn.log - All network connections (TCP, UDP, ICMP)# dns.log - DNS queries and responses# http.log - HTTP requests and responses# ssl.log - SSL/TLS handshake details# files.log - File transfers observed on the network# notice.log - Alerts from Zeek detection scripts# weird.log - Protocol anomalies and errors# x509.log - X.509 certificate details# smtp.log - SMTP email transactions# ssh.log - SSH connection details# View connection log with zeek-cut for column selectioncat /opt/zeek/logs/current/conn.log | zeek-cut ts id.orig_h id.orig_p id.resp_h id.resp_p proto service duration orig_bytes resp_bytes
# View DNS logcat /opt/zeek/logs/current/dns.log | zeek-cut ts id.orig_h query qtype_name answers
# View HTTP logcat /opt/zeek/logs/current/http.log | zeek-cut ts id.orig_h host uri method status_code user_agent
Step 3: Write Custom Detection Scripts
# Create a custom detection script directorysudomkdir -p /opt/zeek/share/zeek/site/custom-detections
Create a script for detecting DNS tunneling:
# /opt/zeek/share/zeek/site/custom-detections/dns-tunneling.zeek
@load base/frameworks/notice
module DNSTunneling;
export {
redef enum Notice::Type += {
DNS_Tunneling_Detected,
DNS_Long_Query
};
# Threshold: number of unique queries per source in time window
const query_threshold: count = 200 &redef;
const time_window: interval = 5min &redef;
const max_query_length: count = 50 &redef;
}
# Track query counts per source IP
global dns_query_counts: table[addr] of count &create_expire=5min &default=0;
event dns_request(c: connection, msg: dns_msg, query: string, qtype: count, qclass: count)
{
local src = c$id$orig_h;
# Check for unusually long domain queries (base64-encoded data)
if ( |query| > max_query_length )
{
NOTICE([
$note=DNS_Long_Query,
$msg=fmt("Unusually long DNS query from %s: %s (%d chars)", src, query, |query|),
$src=src,
$identifier=cat(src, query)
]);
}
# Track query volume per source
dns_query_counts[src] += 1;
if ( dns_query_counts[src] == query_threshold )
{
NOTICE([
$note=DNS_Tunneling_Detected,
$msg=fmt("Possible DNS tunneling: %s sent %d queries in %s", src, query_threshold, time_window),
$src=src,
$identifier=cat(src)
]);
}
}
zeek-cut: Zeek utility for extracting specific columns from tab-separated Zeek log files for quick analysis
zeekctl: Zeek management tool for deploying, monitoring, and managing Zeek instances across single or clustered deployments
RITA (Real Intelligence Threat Analytics): Open-source tool that analyzes Zeek logs for beaconing, DNS tunneling, and other threat indicators
Filebeat: Elastic agent for shipping Zeek JSON logs to Elasticsearch for centralized analysis and visualization
Common Scenarios
Scenario: Detecting Command-and-Control Beaconing in Enterprise Traffic
Context: A threat intelligence report indicates that a specific threat actor uses HTTPS beaconing with 60-second intervals to compromised hosts. The SOC team needs to analyze Zeek logs to identify any hosts exhibiting this pattern across the enterprise network carrying 2 Gbps of traffic.
Approach:
Deploy Zeek on a network tap at the internet egress point with AF_PACKET for high-throughput capture
Enable the custom beacon detection script with thresholds tuned for 60-second intervals over 1-hour observation windows
Query conn.log for connections to external IPs with consistent duration and inter-connection timing: filter connections where the standard deviation of inter-arrival times is less than 5 seconds
Cross-reference suspicious destination IPs against threat intelligence feeds loaded into Zeek's Intel framework
Examine ssl.log for the associated TLS certificates -- check for self-signed certificates, unusual issuer names, or certificates with short validity periods
Generate a notice for each identified beaconing source and feed into the SIEM for SOC triage
Pitfalls:
Not tuning beacon detection thresholds for the environment, resulting in false positives from legitimate update services (Windows Update, AV updates)
Failing to exclude CDN and cloud service provider IP ranges that naturally receive many repeat connections
Running Zeek without sufficient CPU cores, causing packet drops on high-throughput links
Not enabling JSON log output, making SIEM integration unnecessarily complex with custom parsers
Output Format
## Zeek Network Anomaly Detection Report
**Sensor**: zeek-sensor-01 (10.10.1.250)
**Monitoring Interface**: eth1 (span port from Core-SW1)
**Analysis Period**: 2024-03-15 00:00 to 2024-03-16 00:00 UTC
**Total Connections Logged**: 2,847,392
### Anomalies Detected
| Notice Type | Source | Destination | Details |
|-------------|--------|-------------|---------|
| DNS_Tunneling_Detected | 10.10.3.45 | 8.8.8.8 | 847 queries to suspect-domain.xyz in 5 min |
| Possible_Beaconing | 10.10.5.12 | 203.0.113.50:443 | 62 connections with 59.8s avg interval |
| SSL::Invalid_Server_Cert | 10.10.8.22 | 198.51.100.33:443 | Self-signed cert, CN=localhost |
| SSH::Password_Guessing | 45.33.32.156 | 10.10.20.11:22 | 487 failed attempts in 30 min |
### Recommendations
1. Isolate 10.10.3.45 and investigate for DNS tunneling malware
2. Block 203.0.113.50 at firewall and forensically image 10.10.5.12
3. Investigate self-signed TLS certificate on 198.51.100.33
4. Block 45.33.32.156 and enforce SSH key-only authentication
