Zeek-Intelligence-Feeds: A Combined Intel Feed for Zeek, But Verify the Update Path
Zeek-Formatted Threat Intelligence Feeds. Zeek Intel Threat Feed w/ Combined Indicators This is a public feed based on Public Threat Feeds and CRITICAL PATH SECURITY gathered data.
At a glance
- What is it?
- CriticalPathSecurity/Zeek-Intelligence-Feeds bundles public and proprietary threat indicators into Zeek's native intel format. The setup is straightforward, but the update mechanism is a raw git reset, so you need to check what you are pulling.
- Who is it for?
- Adopt this feed if you run Zeek 3.0 or later, want a single intel.log source for multiple public indicators, and accept the maintenance burden of a cron-driven git reset. Do not adopt it if you need guaranteed update reliability, per-source licensing clarity, or a managed feed service.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Zeek, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 14, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What This Feed Solves for Zeek Operators
Zeek's intel framework matches network activity against indicator files, but populating those files is the hard part. This repository aggregates indicators from public sources and Critical Path Security's own collection into a single set of Zeek-formatted .intel files. It is for Zeek users who want threat intelligence without writing their own collection scripts. The README states the feed is based on public threat feeds and Critical Path Security gathered data. The target user is someone who can install Zeek from source and manage a cron job. The value is not in a single groundbreaking indicator, but in the convenience of having multiple sources in one place, ready for Zeek to load.
The Mechanism: Zeek Intel Files and a Single Load Line
The repository is a directory of .intel files, each following Zeek's intel input format. The README instructs you to clone the repository into the Zeek site directory and add one line to local.zeek: @load Zeek-Intelligence-Feeds. That line tells Zeek to read the intel files at startup. Each file is named after its source, such as abuse-ch-urlhaus.intel or tor-exit.intel. Zeek's intel framework then matches observed domains, IPs, and other indicators against these files, writing hits to intel.log. The data flow is simple: git clone, load, deploy, and Zeek handles the rest. There is no transformation step in the README; the files are already in the expected format.
Installation: From Zeek Source to Deploy
The README gives a complete path. First install Zeek dependencies with apt-get: sudo apt-get install cmake make gcc g++ flex bison libpcap-dev libssl-dev python-dev swig zlib1g-dev. Then clone the Zeek source into /opt and build it with ./configure && make && sudo make install. After Zeek is installed, clone this repository into /usr/local/zeek/share/zeek/site/Zeek-Intelligence-Feeds. Add the load line with echo "@load Zeek-Intelligence-Feeds" >> /usr/local/zeek/share/zeek/site/local.zeek. Then run ./zeekctl deploy from /usr/local/zeek/bin/. The README also shows a sample update script that does git fetch, git reset --hard FETCH_HEAD, and git clean -df. That script is intended to run via cron, with an example entry of 5 * * * * sh /opt/zeek_update.sh. Logs land in /usr/local/zeek/logs/current/intel.log.
The Update Script Is a Double-Edged Sword
The update mechanism is the weakest part of this project. The README's script uses git reset --hard FETCH_HEAD and git clean -df. That means every update discards any local changes in the repository directory. If you modify a .intel file to remove a false positive, or if you add your own indicator, the next cron run will erase it. The script also assumes the repository is a git clone, which it is, but it does not check for conflicts or merge issues. It simply forces the remote state. For a feed that is meant to be updated as often as possible, this is a blunt approach. A better design would use git pull with a merge strategy or a separate staging directory. As written, the update is reliable in the sense that it always matches the remote, but it is destructive to local customizations.
Source Coverage and Licensing Gaps
The README includes a table of sources with filenames, providers, and license or terms-of-use columns. Many entries say 'Not Defined' or just list a homepage. For example, Amnesty_NSO_Domains.intel has 'Not Defined' as its license. The scumbots.intel entry says permission was given by Paul Melson for free usage. This means you cannot assume every feed is safe to redistribute or use commercially. The project itself is MIT licensed, but that license covers the repository's code and structure, not necessarily the indicator data. Each source may have its own terms. The README does not provide a consolidated license summary. Before deploying, you should check the terms for each source you actually use, especially if your organization has compliance requirements. The table lists 27 files, but the actual contents of each file are not shown in the README, so you cannot verify indicator quality without cloning the repo.
A Real Alternative: Zeek's Built-In Intel Feeds or a Feed Manager
Zeek itself does not ship with a default threat feed, but you can write your own intel files from any data source. The alternative is to skip this repository and build your own feed pipeline. For example, you could write a script that downloads abuse.ch's URLhaus CSV and converts it to Zeek's intel format, then load that single file. That approach gives you full control over the format, update frequency, and local modifications. Another alternative is to use a platform like MISP or a commercial feed service that exports Zeek intel files. The difference is that this repository is a static aggregation, updated by a cron job, whereas a feed manager can handle incremental updates, deduplication, and conflict resolution. The trade-off is convenience versus control. This project gives you a quick start with many sources, but you inherit the update script's limitations.
Maintenance Cost and Upgrade Path
The maintenance cost is moderate. The cron script runs daily, but there is no versioning or release process. The repository has no recent releases listed, so you are always on the master branch. That means updates are not pinned to a tested version. If a source changes its format, the .intel file might break, and you will only notice when Zeek fails to parse it. The README does not mention any testing or validation of the feed files. Upgrading Zeek itself is a separate task, but the feed depends on Zeek 3.0 or greater, so older Zeek versions will not work. The git reset update approach also means you need to re-clone if the repository is ever deleted or if the remote history is rewritten. For a production sensor, you should consider a more controlled update process, such as a separate script that downloads individual files and checksums them.
Editorial conclusion
Adopt this feed if you run Zeek 3.0 or later, want a single intel.log source for multiple public indicators, and accept the maintenance burden of a cron-driven git reset. Do not adopt it if you need guaranteed update reliability, per-source licensing clarity, or a managed feed service. Before deploying, verify the current contents of each .intel file, confirm the git history is clean, and test the update script on a staging instance. The project is a useful aggregation, but its update mechanism is a blunt instrument that can overwrite local changes without warning.
Community notes