Zeek-Intelligence-Feeds packages dozens of curated threat intelligence sources into ready-to-load .intel files so authorized defenders can match malicious IPs, domains and URLs against live traffic.
| Tool | CriticalPathSecurity/Zeek-Intelligence-Feeds — a collection of Zeek-formatted threat intelligence indicators aggregated from public feeds and Critical Path Security's own research |
| Category | Threat intelligence feeds for network intrusion detection |
| Primary Use | Loading curated Intel::ItemId indicators into a Zeek sensor so connections, DNS queries and file activity matching known-bad hosts trigger intel.log hits during authorized monitoring |
| Safe Use | Intended for defenders operating their own Zeek deployments on networks they are authorized to monitor — SOC detection pipelines, lab sensors and incident-response engagements |
| Telemetry Note | Purely defensive: matches are recorded locally in /usr/local/zeek/logs/current/intel.log; the tool sends no traffic and leaves no footprint on third-party systems |
Zeek-Intelligence-Feeds is a defensive project that solves one of the most tedious problems in network monitoring: getting threat intelligence into a format a sensor can actually consume. Rather than writing custom parsers for CSV feeds or paying for a commercial intel platform, defenders can clone this repository, add a single @load Zeek-Intelligence-Feeds line to local.zeek, and immediately begin matching traffic against hundreds of thousands of indicators. It is maintained by Critical Path Security, who blend public feeds with indicators gathered from their own research operations, and the repository is MIT-licensed with roughly four hundred stars and a primary language tag of Zeek.
The mechanics rely entirely on Zeek's built-in Intelligence Framework. Each file in the repository is a plain-text .intel file following the tab-separated Intel::ItemId format, which Zeek natively understands without any scripting glue. Once loaded, the framework automatically expands certain indicator types: a domain indicator like example.com also matches every subdomain beneath it, and hash indicators match file activity seen through the files framework. This means a URLHaus URL or a ThreatFox IP becomes actionable the moment the dpd and intelligence hooks see relevant traffic, with no additional configuration beyond the initial load directive.
What makes the project genuinely useful is the breadth of its sourcing. The README documents 26 distinct feed files spanning reputation blocklists, malware infrastructure and targeted-actor tradecraft. On the reputation side you have alienvault.intel, binarydefense.intel, abuse-ch-ipblocklist.intel and sans.intel from the SANS Internet Storm Center. Malware distribution infrastructure is covered by abuse-ch-urlhaus.intel, abuse-ch-malware.intel and abuse-ch-threatfox-ip.intel. Phishing URLs flow in from openphish.intel. Each source is documented with its provider, homepage, list URL and license terms in a table — a detail that matters commercially, since feed licensing is a common legal trap when aggregating intelligence.
The most operationally interesting entries are the actor-specific feeds. cobaltstrike_ips.intel pulls high-confidence CobaltStrike C2 addresses from threatview.io, while Critical Path Security contributes their own cps_cobaltstrike_domain.intel and cps_cobaltstrike_ip.intel. Ransomware ecosystems get dedicated coverage through lockbit_ip.intel and ragnar.intel, and log4j_ip.intel aggregates infrastructure associated with Log4Shell exploitation from multiple sources. There are also niche but high-signal collections like fangxiao.intel from Cyjax covering a Chinese threat actor, Amnesty_NSO_Domains.intel documenting NSO Group infrastructure, and stalkerware.intel — an unusually thoughtful inclusion that helps defenders detect commercial spyware on monitored networks.
Installation is straightforward for anyone already running Zeek 3.0 or greater. The README's deployment path clones the repository directly into the Zeek site tree and appends the load directive, roughly: git clone https://github.com/CriticalPathSecurity/Zeek-Intelligence-Feeds.git /usr/local/zeek/share/zeek/site/Zeek-Intelligence-Feeds followed by echo "@load Zeek-Intelligence-Feeds" >> /usr/local/zeek/share/zeek/site/local.zeek. A subsequent ./zeekctl deploy from /usr/local/zeek/bin/ pushes the updated scripts to all nodes in a cluster, which is worth noting — the feeds propagate to every worker, not just the node where you cloned the repository.
Freshness is where most static feed deployments fail, and the README addresses it with a scheduled update pattern. The suggested /opt/zeek_update.sh script performs git fetch origin master, git reset --hard FETCH_HEAD and git clean -df inside the feed directory, which guarantees the working tree exactly mirrors upstream regardless of local drift. Wired into cron with a 24-hour cadence — the example uses 5 * * * * — this keeps indicators current, though defenders should remember that a zeekctl deploy is still needed after updates for cluster nodes to actually reload the new data. Building that reload into the update script is an obvious improvement.
Detection output lands in /usr/local/zeek/logs/current/intel.log, and understanding how to operationalize that log is what separates a working deployment from a checkbox exercise. Each matching event writes the indicator, its source feed, the matching connection metadata and the seen fields describing where the hit occurred — an HTTP host header, a DNS query, an SSL server name indication. A SOC triaging these alerts should treat feed hits as leads rather than verdicts; blocklists like tor-exit.intel (which mirrors the Tor Project's published exit addresses) and scumbots.intel are contextual rather than inherently malicious, and the Emerging Threats compromised-ips.intel by definition flags machines that are victims themselves.
From an architecture perspective, the project's simplicity is its strength. There is no daemon, no API client, no dependency chain beyond Zeek itself — just versioned text files and git. That makes it trivially auditable: you can inspect every indicator you are loading, diff feed changes between commits, and selectively disable a source by removing a single @load of its parent directory or pruning the file. For environments with compliance constraints around data provenance, the README's license table is the starting point for verifying that each upstream provider's terms of use permit redistribution and operational use, and a few entries honestly state Not Defined, which deserves review before production reliance.
There are sensible caveats a senior operator should weigh. The predict_intel.intel entry from Georgia Tech Research Institute and several Critical Path proprietary feeds (illuminate.intel, cps-collected-iocs.intel, filetransferportals.intel) point to top-level homepages rather than raw list URLs, meaning their refresh provenance is opaque — you are trusting the maintainer's update discipline rather than a verifiable upstream. Indicator quality also varies by design: a high-confidence CobaltStrike C2 IP carries a different weight than a bulk IP blocklist, and triage workflows should encode that difference, perhaps by routing intel.log into a SIEM where the seen_indicator source drives scoring.
In an authorized workflow, this repository slots neatly into passive detection on networks you are contractually permitted to monitor: corporate sensors, MSSP customer environments, and lab ranges used for detection engineering. Because Zeek's intelligence matching is passive — it observes traffic rather than generating any — the deployment carries no risk to third parties and no network footprint beyond the normal Zeek process itself. The intel.log output then becomes a defensible evidentiary record correlating internal activity with externally documented adversary infrastructure, which is exactly the artifact an incident responder wants during scoping.
For defenders on the receiving end of intelligence like this, the project is also instructive in reverse. The feed list is effectively a curated map of which public sources the practitioner community considers worth ingesting, and the actor-specific files (lockbit_ip.intel, cps_cobaltstrike_domain.intel, stalkerware.intel) double as watchlists for hunting in historical conn.log and dns.log data even outside a live deployment. That retrospective hunting use case — importing the .intel files into a notebook or SIEM lookup and scanning archived logs — requires no Zeek instance at all and is often the fastest first win.
Overall, Zeek-Intelligence-Feeds is a well-executed piece of defensive plumbing: unglamorous, auditable and immediately useful. Its value is not in any single indicator but in the aggregation discipline — a git-pullable, license-documented, Zeek-native bundle that turns a bare sensor into one that recognizes named adversary infrastructure. Run it with a scheduled update and reload, tune your triage to the confidence tier of each source, and it earns its place in the detection stack.
CriticalPathSecurity/Zeek-Intelligence-Feeds.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.