The public IOC feed.

Attacker-controlled domains: phishing infrastructure, malware distribution, C2. Built for DNS sinkholes and blocklists — pi-hole, pfSense, OPNsense, FortiGate external feeds.

IPv4 and IPv6 addresses observed as attacker infrastructure in current reporting — scanners, exploit sources, C2 endpoints. Ready for firewall deny-lists.

MD5, SHA-1 and SHA-256 hashes of malware samples named in current reporting. For EDR blocklists, SIEM watchlists and retro-hunting across your own telemetry.

Cryptocurrency addresses controlled by attackers — ransom payments, exchange thefts, scam proceeds. Bitcoin, Ethereum and Monero.

These are for chain analysis and payment screening, not for a firewall — which is why they are a separate list and never appear in the network blocklist. Every address is checksum-validated before it ships, so a mistyped or truncated one never reaches the feed.

Unlike a domain or an address on the network lists, a wallet never changes hands — it is bound to whoever holds the key. The full list stays accurate however old it gets.

The network blocklist (domains + IPs together) in three formats, plus everything above under one URL scheme. Stable paths, hourly refresh — point a cron at them and forget.

The JSON feed carries the evidence: per-indicator reasons, first/last seen dates, and up to five source citations each. Need STIX 2.1, MISP, hourly windows or authenticated volume? That's the full format matrix.

Every high-confidence indicator we have recorded since November 2025, with the date we first saw it. For retro-hunting and enrichment, not for blocking.

Read this before you use it. The lists above are the block-ready set: recent, corroborated, safe to point a firewall at. This one is the archive. Infrastructure ages — a C2 IP from last winter may since have been reallocated to somebody uninvolved, and blocking it would hit them, not the actor. Hunt with it, enrich with it, search your logs against it. Don't sinkhole it.

File hashes are the safest of the three: a hash names one exact file forever, so it can never be reassigned the way a domain or an address can. Add ?min_sources=2 to the JSON feed for indicators corroborated by two or more independent publishers.

Not indicators — stories. The same clustering, as an RSS feed: the 50 latest threat clusters, one entry per story instead of one per outlet. Point a reader, a SIEM, or a Teams channel at it.

Each item is a title, a link, and a short summary — the full analysis, sources and IOCs live on the cluster page. The dark-web feed tracks ransomware leak-site victims with sector and country — the structured versions are in the next section.

These are the highlights. There are thirteen public feeds in total — CVEs, weaponised exploits, the blocklist in TXT/JSON/CSV, dark-web victims, onions and groups in CSV/JSON, MISP and SmartNews — all listed on the feeds page, with an OPML bundle that imports the RSS ones in one go.

Ransomware leak-site victims and the onion infrastructure behind them. Not indicators for a blocklist — an observation record of who has been named, by which group, and where the post lives.

Rows we read off the leak site ourselves carry first_party=yes alongside the group's claimed data size, file count and the leak_url the claim came from. The onion feed marks each address up or down from our own probe.

Prefer a versioned copy? The same files are snapshotted daily into Jam0k/Ransomware-Intel on GitHub — including a victims-firstparty.csv of only the rows we read off the leak sites ourselves — so git log tells you when a victim first appeared.

These are claims published by the groups themselves. A listing is not confirmation that a breach occurred, that the data is genuine, or that the named company has been compromised. Groups routinely re-post old victims, exaggerate, and name organisations they never breached. Treat it as reporting on what was posted.

Victims carry group, country, sector and the leak-site post URL. The onion, market, forum and group lists add the site name, claimed operator, language, whether a login or captcha gate blocks access, and a link to our own screenshot of the page where we have one. The JSON adds company enrichment — legal name, headquarters, data volume — for the minority of posts that included it.

Screenshots are ours: captured by our crawler, face-blurred and watermarked before upload. Victim rows carry no screenshot — those images are hosted by a third party, so we link the leak-site post instead of redistributing someone else's file.

The CSV window is 90 days and the JSON 30; add ?days=365 for a year. Unlike the IOC lists there's no false-positive filtering here — a leak-site posting is an observed fact rather than a claim about a third party's infrastructure, so it's published as seen. Aggregated from /dark-web.

Because everything here gets blocked by someone's firewall the hour we publish it. This feed optimises for being safe to consume blind — which means most candidate indicators don't make it.

• High confidence only, 30-day window. An indicator ships when current reporting supports it — stale infrastructure ages out automatically.
• Roughly 30 candidates rejected for every one published. In a typical month our validators discard over a thousand domains extracted from articles — victims, vendors, government portals, research sites — that a naive extractor would have shipped as "IOCs".
• A false positive is remembered forever. Any value ever marked as a false positive is permanently barred from every export, even if later reporting re-extracts it.
• A last-line guard at the exit. Every export re-checks each value against government/academic suffixes, national e-gov portals, freemail providers and impersonation-victim markers — independent of what the database says.
• One-business-day removals. Spot a false positive? [email protected] — it comes out within one business day and never returns.