Built-in feeds (abuse.ch)

Built-in feeds bundle three free, continuously-updated threat-intelligence sources from abuse.ch — the Swiss anti-abuse community that’s been the backbone of open malware tracking for over a decade. Every Mimir tenant can ingest them with no commercial license, no account creation, no vendor evaluation. They’re the lowest-friction way to give the agent fleet a baseline of “known-bad” indicators on day one.

What you get

Three sources, each curated by abuse.ch’s analyst community:

Malware Bazaar publishes file hashes for malware samples seen in active campaigns — one of the largest free hash repositories in the industry. Mimir matches these against every file your agents observe: process executables, downloaded payloads, DLLs loaded by running processes, files cataloged by osquery’s file table during scheduled sweeps. When a Bazaar hash matches a file on one of your endpoints, that’s a strong signal — abuse.ch only includes hashes from confirmed malware samples, not unconfirmed reports. Daily volume: thousands of fresh hashes added.

URLhaus publishes URLs known to deliver malware payloads, plus the C2 (command-and-control) and dropper domains those URLs resolve to. Mimir matches these against agent network activity — DNS lookups via osquery’s dns_lookup_events table and outbound connections via socket_events. URLhaus catches the network layer of attacks: a workstation resolving a known dropper domain or beaconing to a malware C2 is a clear indicator of compromise even when no malicious file made it to disk.

ThreatFox publishes mixed indicators (hashes, IPs, domains, URLs) tied to specific malware families and active campaigns. Where Bazaar and URLhaus give you raw “this is bad” data, ThreatFox adds attribution: an alert sourced from ThreatFox tells you not just that something matched but which family (Emotet, QakBot, IcedID, Cobalt Strike, AsyncRAT, etc.) and which campaigns it’s been observed in. That context turns a generic alert into a starting point for triage.

All three feeds refresh continuously upstream; Mimir polls on the schedule you configure (60 minutes is the typical default).

Why use them

Three reasons to enable built-in feeds before any other:

No friction. Free, no account, no commercial agreement. The typical tenant has them running within five minutes of clicking into Settings → Threat Feeds.
High signal-to-noise. abuse.ch indicators are vetted by analysts before publication — false positives are rare. Some commercial feeds publish with looser thresholds and produce noisier alerts; abuse.ch errs toward signal.
Coverage of commodity malware. Most security incidents start with commodity malware — phishing droppers, ransomware-as-a-service, credential stealers. abuse.ch focuses heavily on this layer. If you only had one feed, this is the one to start with.

A typical tenant running just abuse.ch sees alerts within hours: any endpoint that downloads a known-bad attachment, resolves a malware C2, or executes a sample documented in active campaigns will trigger an alert with full source attribution.

How Mimir uses the data

When you add a built-in feed, Mimir:

Polls the feed on your schedule. Default 60 minutes. The bridge sidecar polls abuse.ch upstream on its own cadence (every 5 minutes), so you don’t gain freshness by polling Mimir-side faster than that.
Imports indicators into your IOC database. Each indicator is tagged with the source feed and a confidence score (default 70 for feed-imported IOCs).
Runs a 90-day historical scan retroactively. Every newly-imported indicator is checked against the last 90 days of host activity. If any agent has already seen a file matching one of the new hashes, that historical match becomes an alert — even though the indicator wasn’t known at the time.
Matches in real-time going forward. Every new file the agents observe, every DNS lookup, every outbound connection is checked against the active IOC set. Matches generate alerts on the Alerts page with source attribution back to the feed.
Decays stale indicators. Threat intelligence goes stale — a C2 domain hot in March is often inactive by September. Mimir reduces the confidence score of every feed-imported IOC by 5 points per day. When confidence drops below 20 the IOC is auto-deactivated (kept in history, no longer matched). A successful poll that re-emits the same indicator boosts confidence back up.

This design lets you leave a feed enabled long-term without accumulating stale-IOC alert noise.

Prerequisites

Built-in feeds are served via the mimir-feeds-bridge sidecar — a small auxiliary container that polls abuse.ch upstream on Mimir’s behalf and re-publishes the feed in the standard STIX 2.1 format. Two implications for you as an admin:

Heads up Your Mimir deployment must include the bridge sidecar. If your sysadmin or platform team deployed Mimir from the standard Docker Compose stack with the feeds profile enabled, the bridge is already running. If you don’t see the Add built-in feed button in Settings, or the bridge URL fails to connect, ask whoever deployed your Mimir tenant whether the bridge sidecar is enabled. The full deployment guide is in ../operations/threat-feeds.md.

The bridge serves on a private hostname (typically inside your container network) with a self-signed TLS certificate. Mimir’s “trust bridge” allowlist is what permits the connection — this is configured at deploy time (MIMIR_BRIDGE_HOSTS environment variable) and you don’t need to touch it as an admin.

You’ll also need:

Admin access to Mimir. Adding feeds requires the Admin role. Check by visiting Settings → Threat Feeds: if you don’t see an Add built-in feed button, you don’t have permission. Ask your Mimir admin to grant you the role.
Your bridge URL. Your sysadmin will provide it. It looks like https://feeds-bridge.your-domain/feeds-bridge/v1/all/objects/ — a TAXII 2.1 endpoint on a hostname inside your environment.

Setting up

Open Settings → Threat Feeds.
Click Add built-in feed.
Fill in the form:
- Name — anything memorable. Suggested: abuse.ch (built-in). This is what shows up in alert source attribution and in the feeds table.
- Bridge URL — paste the URL your sysadmin provided. Must end in /feeds-bridge/v1/<collection>/objects/ or /feeds-bridge/v1/<collection>/. The page rejects URLs that don’t match the bridge shape — if you see “this doesn’t look like a mimir-feeds-bridge URL”, you’re probably looking for Add custom STIX/TAXII feed instead, or the URL is wrong.
- Poll interval — 60 minutes is typical. Lower values just check the bridge more often; the bridge polls upstream every 5 minutes either way.
Click Add feed. The first poll runs within a minute.

That’s it. No API key, no account setup, no test connection step. The bridge is already authenticated to abuse.ch on your behalf and your Mimir deployment is already configured to trust it.

What you’ll see after adding

Within a few minutes:

The new feed appears in the Threat Feeds table with a BUILT-IN tag.
The IOCs column shows a count — typically thousands of hashes plus a few hundred URLs and domains, depending on which abuse.ch collection your bridge is configured to expose.
The Last synced column updates to the current time.

Within hours (or sooner, depending on how active your fleet is):

New IOC alerts begin appearing on the Alerts page when any agent observes a match. Each alert links back to this feed as the source.
Historical alerts fire for any indicator that retroactively matches agent activity from the last 90 days. These are tagged as “late match” and linked to the campaign or file event that originally occurred.
The Indicators page (filterable by source) shows every IOC currently active from this feed. You can search, sort by date, inspect each indicator’s metadata, and selectively deactivate any individual indicator that produces unwanted noise in your environment.

Choosing a poll interval

The bridge polls abuse.ch every 5 minutes regardless of your Mimir poll interval. Your interval controls how often Mimir checks the bridge — not how fresh the data is at the bridge.

Interval	When to use
15-30 min	High-tempo environments where minutes matter. Slight extra database write load.
60 min (default)	Most tenants. Catches new indicators within an hour, low overhead.
240 min	Low-traffic tenants where the database is shared with other heavy workloads.
1440 min (daily)	Not recommended — you’ll miss the same-day attribution window for new campaigns.

The minimum is 5 minutes. Going below 15 typically isn’t worth the overhead — abuse.ch’s own cadence is 5 minutes upstream, so polling faster than that is just polling the bridge’s cache.

Troubleshooting

The IOC count stays at 0 after several polls. The bridge sidecar isn’t reachable from the Mimir server. Click Details on the feed row — the Recent polls section will show the connection error. Most likely cause is the bridge container isn’t running or MIMIR_BRIDGE_HOSTS doesn’t include your bridge hostname. This is a deployment-side fix; ask your sysadmin and point them at ../operations/threat-feeds.md.

The poll succeeds but no alerts fire. Alerts require an actual match between a feed indicator and observed agent activity. With healthy endpoints and a fresh deployment, expect alerts to be sparse — that’s the system working correctly. Check the Indicators page to confirm IOCs are being imported, then wait. ThreatFox-attributed indicators tend to fire first because they cover active campaigns affecting current targets.

The feed paused itself. A feed with a long failure streak gets auto-disabled to prevent repeated noisy errors. Click Edit, fix the URL or auth issue (or coordinate with your sysadmin if the bridge is down), then click Resume.

TLS certificate error in Recent polls. The bridge uses a self-signed certificate. Mimir’s TLS bypass for the bridge requires the bridge hostname to be in the deployment-time MIMIR_BRIDGE_HOSTS allowlist. If this error appears, your bridge URL doesn’t match the allowlist. Ask your sysadmin to either fix the URL or update the allowlist.

An indicator is too noisy in my environment. Open Settings → Threat Feeds → Details → View N IOCs from this feed. Find the noisy indicator and click its Deactivate toggle. This stops Mimir from matching it without removing it from the database — if the feed re-imports it on a future poll, your deactivation is preserved. Common cases: the feed lists a CDN IP that’s also legitimate traffic in your environment, or a hash for a tool that your security team uses (e.g., Mimikatz on a red-team workstation).

Replacing or removing the feed

Edit changes name, URL, or interval. The bridge URL doesn’t contain credentials, so editing is straightforward.
Pause stops polling without losing any imported IOCs. They keep matching against agent activity until they decay below the deactivation threshold (~10 days at default decay rate).
Remove deletes the feed but keeps the IOCs (they become orphaned with no source attribution; still searchable on the Indicators page, still subject to confidence decay).

If you want to wipe the imported IOCs as well, filter the Indicators page by source before removing the feed, then bulk-delete the rows there.

Licensing

abuse.ch publishes all three sources under CC0 1.0 (effectively public domain), with a request for attribution. Every indicator imported into Mimir carries a STIX external_references entry with source_name: "abuse.ch" and the originating feed URL — attribution is automatic.

Where to next

MISP feeds — the other zero-account option, complements abuse.ch with broader community-curated indicators.
Custom STIX/TAXII — if you want to add AlienVault OTX (free, account required) or any commercial CTI vendor.
Indicators page — see what’s been imported, search across feeds, selectively deactivate noisy IOCs.
Hunts — turn imported IOCs into proactive sweeps across your fleet rather than waiting for matches to arrive.