zeek-mcp

Active

A real investigation means grepping conn, then dns, then http, then ssl by hand, pivoting on a UID you keep pasting between awk one-liners. zeek-mcp hands the whole sensor to your agent: Zeek and Suricata logs queried, correlated, and hunted over stdio, so it follows the pivot for you.

39 tools2 resources4 promptsread-onlyNode 20+MIT

See it work

one question, the tools it calls, the answer

representative session · claude + zeek-mcp
Anything on 203.0.113.45 look like C2? Follow the trail if you see it.
zeek_detect_beaconing{ src: "203.0.113.45", jitter_max: 0.15 }
1 candidate 203.0.113.45 -> 198.51.100.7:443 interval ~60s jitter 0.06 142 conns ssl
zeek_investigate_host{ host: "203.0.113.45" }
ssl SNI cdn-update[.]info self-signed JA3 72a589da586844d7f0818ce684948eea dns 14x NXDOMAIN, high-entropy labels notice Scan::Port_Scan earlier same host
203.0.113.45 is beaconing to 198.51.100.7 every ~60s with near-zero jitter, over a self-signed cert whose JA3 matches CobaltStrike. That plus the DGA-looking DNS is a strong C2 signal. I would isolate it and open a TheHive case.

Representative session. Illustrative values, RFC 5737 addresses. Read-only, and your logs never leave the box.

What it does

Point any MCP client at zeek-mcp and your Zeek and Suricata sensor becomes tools the agent can call: search connection, DNS, HTTP, SSL, files, notice, and SSH logs, follow a connection UID across every log type, and cross-reference Suricata alerts back to the Zeek context that explains them. It exists because network telemetry lives in dense per-protocol log files that are tedious to grep under pressure, and an LLM is good at pivoting across them once you give it structured access. It differs from a generic log-reader MCP by speaking Zeek and Suricata natively: it parses both TSV and JSON, matches CIDR and wildcards with IPv6 support, walks gzipped and date-rotated archives, and ships purpose-built detections (beaconing by interval regularity, DNS tunneling by entropy, JA3 hunting, anomaly and baseline analysis) instead of handing the model raw text. It is read-only against your telemetry and speaks stdio, so there is no new network surface; the only writes are the optional TheHive and MISP tools, and only when you supply credentials.

Capabilities

39 tools across the sensor

Protocol queries11 tools
Search conn, DNS, HTTP, SSL, files, notice, SSH, and DHCP logs with CIDR, wildcard, and range filters.
Detections & analytics9 tools
Beaconing, DNS tunneling, JA3 fingerprints and hunt, anomaly and baseline outlier detection, DGA and expired-cert checks.
Cross-log investigation3 tools
Follow a UID or host across every log type and inventory detected software.
Suricata IDS4 tools
Query and summarize eve.json alerts, correlate them back to Zeek context, and read engine stats.
PCAP & sensor3 tools
List captures, replay a PCAP through Zeek, and check live sensor health and log freshness.
Incident response6 tools
Opt-in TheHive alerts and cases plus MISP IOC lookups and events, only when you supply credentials.
Full reference on GitHub →

Set it up

npx -y zeek-mcp

Set ZEEK_LOG_DIR, ZEEK_LOG_FORMAT (json or tsv), and SURICATA_EVE_LOG to your sensor paths. Optional MISP_* / THEHIVE_* / PCAP_DIR vars enable IR and replay.

MCP client config
{ "mcpServers": { "zeek": { "command": "npx", "args": ["-y", "zeek-mcp"], "env": { "ZEEK_LOG_DIR": "/opt/zeek/logs/current", "ZEEK_LOG_FORMAT": "tsv", "SURICATA_EVE_LOG": "/opt/suricata/logs/eve.json" } } } }
[ shield ]

Read-only against Zeek and Suricata telemetry: it queries logs, never runs the sensor, mutates capture, or writes to your data. It retains nothing between calls and opens no network listeners. The only writes are the optional TheHive and MISP tools, which create alerts, cases, and events only when you supply credentials. PCAP replay confines every filename to PCAP_DIR and rejects anything resolving outside it.

39
MCP tools
16
log types
0
writes by default
MIT
license