Zeek-Intelligence-Feeds: A Zeek Intel Feed Bundle for Network Monitoring

What Zeek-Intelligence-Feeds actually ships

The repository is a directory of .intel files plus a small amount of Zeek script. The README describes it as "a public feed based on Public Threat Feeds and CRITICAL PATH SECURITY gathered data," updated "as often as possible." The top-level listing shows the shape of that claim: Amnesty_NSO_Domains.intel, abuse-ch-ipblocklist.intel, abuse-ch-malware.intel, abuse-ch-threatfox-ip.intel, abuse-ch-urlhaus.intel, alienvault.intel, binarydefense.intel, censys.intel, cobaltstrike_ips.intel, compromised-ips.intel, cps-collected-iocs.intel, openphish.intel, sans.intel, tor-exit.intel, and more, alongside __load__.zeek and main.zeek.

The intended audience is narrow and worth stating plainly: someone already running a Zeek sensor who wants indicator matching in their logs without wiring up a dozen provider APIs. If you do not run Zeek, this repository is not a standalone threat intelligence product. It has no query interface, no dashboard, and no export format for other tools. The .intel files are inputs to Zeek's Intel framework, and their only consumer is Zeek itself.

The README's source table is the most useful artifact in the repository. It maps each filename to a provider, a homepage, a list URL, and a licence or terms-of-use link. That table is also where the project's legal surface becomes visible, because the entries are not uniform.

How the .intel files reach Zeek's Intel framework

Zeek ships an Intel framework that reads files in the .intel format and turns each record into an indicator that scripts can match against observed traffic. This repository supplies those files in bulk. The __load__.zeek file at the top level is what the @load directive pulls in, and main.zeek carries the project's own script logic.

The data flow is one-directional and file-based. There is no service, no daemon, and no API client in the repository. The README's update mechanism is a git fetch against the master branch followed by a hard reset, which means the working tree is replaced wholesale on each run. Whatever the upstream repository contains at that moment is what your sensor sees next.

That design has a consequence the README does not discuss. Because the .intel files are committed into the repository rather than fetched at load time, the freshness of any individual indicator depends on when the maintainer last refreshed that file. The README says the feed "will be updated as often as possible," which is not a schedule. If you need to know how stale the abuse.ch entries are relative to the abuse.ch source, the repository does not give you a per-file timestamp to check.

The source table also shows uneven provenance. Some entries are large public blocklists with published terms, such as the Abuse.CH lists and the Tor exit address list. Others are marked "Not Defined" for licence (Amnesty_NSO_Domains.intel) or have no homepage and no list URL at all (scumbots.intel, which the table credits to Paul Melson with "Permission given by Paul Melson - Free Usage"). Several Critical Path Security entries point at the vendor homepage rather than a specific list URL.

Installing the feed into a Zeek site directory

The README assumes Zeek 3.0 or greater is a dependency and gives the build prerequisites for Zeek itself. If you already have Zeek installed and working, skip the build steps and go to the clone. The README's own instructions clone the feed repository directly into the Zeek site directory and append a load line to local.zeek.

First, clone into the path the README specifies, which is where Zeek looks for site scripts:

cd /opt
git clone https://github.com/CriticalPathSecurity/Zeek-Intelligence-Feeds.git /usr/local/zeek/share/zeek/site/Zeek-Intelligence-Feeds
echo "@load Zeek-Intelligence-Feeds" >> /usr/local/zeek/share/zeek/site/local.zeek

After that, the README directs you to deploy from the Zeek bin directory. This is the step that actually reloads the configuration and starts matching indicators:

cd /usr/local/zeek/bin/
./zeekctl deploy

When the deploy completes without errors, the README states that logs are written to /usr/local/zeek/logs/current/intel.log. That file is the first place to look for confirmation that indicators are being read and matched. If the path does not exist after deploy, the load line did not take effect or the site directory path differs from the README's assumption.

The README also offers a refresh script. It writes a shell script to /opt/zeek_update.sh containing a fetch, a hard reset, and a clean, then makes it executable and schedules it. Note that the README's prose says "24 hour updates" while the cron entry it gives runs at minute 5 of every hour, which is hourly, not daily. That mismatch is in the README as written, and you should decide which cadence you actually want before copying the line.

#!/bin/sh
cd /usr/local/zeek/share/zeek/site/Zeek-Intelligence-Feeds && git fetch origin master
git reset --hard FETCH_HEAD
git clean -df

The licence table is the part that needs your attention

The repository's own code is MIT licensed, and the LICENSE file sits at the top level. That covers the Zeek scripts and the packaging. It does not cover the indicator data inside the .intel files, and the README's source table makes this explicit by listing a separate licence or terms-of-use link per provider.

Read that column carefully. Amnesty_NSO_Domains.intel is listed as "Not Defined." The Abuse.CH entries point at their respective abuse.ch pages for terms. OpenPhish points at openphish.com/terms.html. Emerging Threats points at its OPEN download instructions. Inversion points at a LICENSE file in a different GitHub repository. ScumBots has no homepage, no list URL, and a note that permission was given by Paul Melson for free usage.

What this means in practice is that installing the repository under MIT does not settle the question of whether you may redistribute, retain, or act on any particular indicator set. The README does not attempt to reconcile these terms, and it should not be read as doing so. If you plan to redistribute the combined feed, or to use it in a commercial product, the per-provider terms are the thing to check, not the repository's MIT file. This is not legal advice; it is a description of what the table says.

Where this feed set is the wrong tool

The most common mismatch is expecting feed management. This repository does not let you enable or disable individual sources through configuration. There is no documented per-file toggle in the README, and the load mechanism pulls in the whole set. If you want to run the abuse.ch lists but exclude, say, the Tor exit list because your environment has legitimate Tor traffic, the README does not describe a supported way to do that. You would be editing files or the load path yourself, which puts you off the documented path.

A second mismatch is freshness tolerance. The update script replaces the working tree with whatever is on master at fetch time. If a provider's indicators change faster than the maintainer refreshes the corresponding .intel file, your sensor is matching against older data with no visible signal that it is older. For feeds where the provider publishes a timestamp or a TTL, the repository does not carry that through in a way the README documents.

A third is scope. Several files are named for specific campaigns or malware families rather than broad blocklists: lockbit_ip.intel, log4j_ip.intel, cobaltstrike_ips.intel, fangxiao.intel, gru-aa25.intel, stalkerware.intel. If your requirement is comprehensive coverage of a category, a single campaign file is a point-in-time artifact, and the README gives no indication of how it is maintained after the campaign fades. Conversely, if your requirement is a small, high-confidence list, bundling roughly forty files together means you inherit the false-positive profile of every provider at once, and the README offers no confidence scoring or per-source tuning.

How it compares to pulling feeds yourself

The obvious alternative is not another project but the manual approach: write your own script that fetches each provider's list and formats it as .intel. That is the real comparison, because Zeek's Intel framework is the consumer either way, and the format is not proprietary to this repository.

The difference in approach is who maintains the conversion. With this repository, the maintainer does the formatting and commits the result, and you get one git remote to track. With a self-built pipeline, you control the refresh interval per source, you can drop a source without editing a shared file, and you can attach your own confidence values. The cost is that you now own parsing for every provider format, from abuse.ch's exports to the SANS ISC API endpoint listed in the table to plain text banlists. That parsing work is exactly what this repository has already done for the files it contains.

A middle path exists and the repository's structure supports it: clone the repository and load it, but treat the source table as a checklist for which providers you would eventually want to fetch directly. The table gives you the homepage and list URL for each one, which is the starting point for a self-built pipeline. What it does not give you is a machine-readable manifest, so extracting that list means reading the README table by hand.

Maintenance cost and what the repository does not tell you

The repository is not archived, and the README's source table carries a timestamp line reading "Sat Aug 29 09:02:34 UTC 2026," which appears to be when the table was last generated. The last push date for the repository is not available, so the current commit cadence cannot be stated. Treat the table timestamp as the only recency signal visible from the outside.

Upgrade cost is low by design. The update script does a fetch, a hard reset, and a clean, so there is no merge conflict surface and no migration path to manage. The risk that replaces it is silent: a hard reset discards any local edits you made to the .intel files, including any indicators you added yourself. If you extend the feed locally, the README's update script will erase that work on the next hourly run. The README does not document rollback, and it does not warn about this interaction.

The other maintenance item is the dependency floor. The README requires Zeek 3.0 or greater and gives the build prerequisites for Zeek itself (cmake, make, gcc, g++, flex, bison, libpcap-dev, libssl-dev, python-dev, swig, zlib1g-dev). If your sensor runs a Zeek version below that floor, the README does not describe compatibility, and there is no version matrix in the repository listing to check against.

Editorial conclusion

Adopt it if you already run Zeek and want a single git clone to populate the Intel framework with roughly forty public and vendor-gathered indicator files, and you can accept that several upstream licences are marked "Not Defined" or are governed by third-party terms of use. Do not adopt it if you need per-source enable and disable controls, a documented refresh cadence, or a feed manager that pulls each provider's API on its own schedule; this repository gives you files and a suggested cron line, nothing more. Before deploying, verify two things yourself: that your Zeek install is 3.0 or greater as the README requires, and that each upstream provider's terms permit your use of its list.

Frequently asked questions

Official sources

1. Official README
2. Project repository