There's No Domain to Seize: Malware Is Quietly Moving to IPFS, and Our Board Just Lit Up on a Fresh Cluster

Every takedown you have ever read about rests on a single assumption: that malicious content lives at an address someone can revoke. Seize the domain, null-route the IP, pull the server, and the link dies. That assumption is how abuse desks, registrars, and hosting providers do their job. IPFS quietly breaks it, and the technique has been scaling under the radar for the better part of a year. Our own infrastructure board just flagged a fresh cluster, so it is worth explaining plainly what this is and why the usual playbook has no answer for it.

What IPFS actually changes

IPFS — the InterPlanetary File System — is a peer-to-peer network for storing and serving files. The one idea that matters is content addressing. On the normal web you fetch a file by where it lives: a hostname and a path pointing at a server. On IPFS you fetch a file by what it is. The system hashes the file's contents, and that hash becomes the address — the content identifier, or CID, the long strings that begin with bafybei or bafkrei. Ask the network for that CID and any machine holding a bit-for-bit identical copy will serve it. Change one byte and it is a different CID entirely.

Most victims cannot run an IPFS client, so attackers route them through public HTTP gateways — bridges that turn a CID into an ordinary web link. The one lighting up our board is Protocol Labs' own gateway, dweb.link, which produces URLs like a long CID followed by .ipfs.dweb.link. Cloudflare, ipfs.io, and a long tail of community gateways do the same job. The phishing or malware page inherits the gateway's real TLS certificate and clean reputation for free — the same platform-native-abuse move we have tracked on Cloudflare Pages and Vercel, only one layer more takedown-proof.

What we actually see — the honest numbers

This is not a brand-new threat, and we are not going to pretend it is. Across our indicator corpus we carry more than 1,500 dweb.link indicators, roughly 3,000 on ipfs.io, and over 7,000 tied to Cloudflare's IPFS gateway, with records going back to the summer of 2025. IPFS-hosted malware has been a steady, growing presence for a year — quiet, not absent.

What is new is the movement. Our precursor-signal system, the same board that watches for staging before a wave, lit its decentralized-command-and-control signal to 0.85 this weekend on a fresh cluster of 65 recent indicators, every one of them a CID served through dweb.link. A signal at that level is the board saying a technique that usually simmers is, right now, bubbling.

One honest caveat, because it is the same lesson we wrote about the holiday weekend: some of that recent bump is likely the intelligence feeds coming back online after the long weekend, not a pure spike in attacker activity. The durable story here is not the 65-count. It is the technique, and the technique is real regardless of this week's number.

Why the takedown playbook has no answer

There is no domain to seize, because the content is not addressed by where it lives. There is no single server to raid, because as long as one node anywhere still pins — keeps — the file, the CID resolves. You can ask a gateway operator to stop serving a specific CID, and the good ones will, but the content simply reappears through the next gateway with the identical address, because the address is the file. Domain-blocking, the reflex every security team reaches for first, does essentially nothing.

Where the defender actually has an opening

Here is the part attackers do not advertise. Unlike Tor, IPFS does not anonymize anything. When a node offers to serve a CID, it publishes a provider record that ties that content to a peer identity and, through that, to a real transport address — a real hosting IP that resolves to a real network and country. The thing that makes IPFS takedown-resistant at the content layer leaves the hosting layer fully exposed.

So the leverage is not where teams instinctively look. You cannot block the domain, but you can do three concrete things. Alert on the tells — any fetch of a hostname containing .ipfs., or any CID beginning bafybei or bafkrei, is worth a second look in a corporate environment where almost nobody legitimately loads content that way. Block at the gateway layer, since a handful of public gateways carry the overwhelming majority of the abuse. And the real move: resolve the provider records to the actual hosting IPs and block those — the same way we already publish and enforce any other command-and-control infrastructure. That is exactly the direction we are pointing our own collection next, extending the network-mapping discipline we use on Tor to the IPFS provider layer, so that a takedown-proof CID still leads us straight to a blockable IP.

We hold this at about 95 percent, as we hold everything. The composition and the technique are solid and reproducible against our own feed. The one number we are explicitly not leaning on is this week's intensity, because a long holiday distorts every counter we own — and knowing which of your numbers to trust is the whole discipline.

---

Her name was Renee Nicole Good.

His name was Alex Jeffery Pretti.