Attackers Keep Hiding Malware on IPFS Because They Think It's Un-Seizable. We've Quietly Resolved 349 of Those 'Takedown-Proof' Payloads to the Real Host Serving Them.
- Patrick Duggan
- 21 hours ago
- 5 min read
Yesterday's AsyncAPI supply-chain attack pulled its second-stage payload — a RAT called Miasma — from IPFS, the distributed content-addressed file network. That is a deliberate choice, and it is becoming a common one. Attackers reach for IPFS because there is no single server to seize. You cannot send a takedown notice to a content hash. It reads as un-seizable, and that is exactly why we have been building against it since early July.
We resolved yesterday's payload to the machine serving it in a single request. That was not a lucky one-off. It is a standing capability, and behind it sits a quieter number that is the real story: we are now holding 349 mappings from a known-malicious IPFS hash to the live host that is actually serving it. This post is about what those 349 look like, and why the thing attackers treat as takedown-proof is nothing of the sort.
What Attackers Think IPFS Gives Them
IPFS addresses content by what it is, not where it lives. A file has a content identifier — a hash — and anyone on the network who has that file can serve it. Take down one host and the content survives wherever else it is pinned. For a malware operator that looks like a dream: durable payload hosting with no domain to sinkhole, no server to subpoena, no registrar to lean on. Host your encrypted second stage on IPFS, bake the hash into your dropper, and let the network keep it alive.
The whole appeal is durability. And the operators keep making one specific mistake: they treat durability as if it were anonymity. Those are not the same property, and the gap between them is where we live.
The Flaw in the Plan
To download content from IPFS, some node has to be announcing that it holds that content and telling the network how to reach it. That announcement is not a secret. It is the mechanism the network runs on — the distributed routing table that lets anyone find anyone. Ask the network who is providing a given hash and it answers with an address. Right now. Live.
So durability cuts both ways. The same property that keeps a malicious payload alive — that some node is always willing to announce and serve it — is the property that hands you the announcing node's IP. The content is takedown-proof. The host is not. It has to raise its hand to do its job, and when it raises its hand, we write down where it is.
What We Built, and What the 349 Look Like
In early July we stood up a collector that does exactly that. It takes IPFS hashes we already know are malicious — from our own indicators, from campaign disclosures — and resolves each one through IPFS's own routing to the host currently announcing it. The output is a compact, current-state map: malicious hash on the left, live host IP on the right, enriched with the network it sits on.
That map now holds 349 entries, and the shape is the interesting part. The hosting is not scattered across the internet at random. It concentrates, hard, on cheap commercial virtual-private-server providers — Hetzner, Scaleway, Contabo, OVH, DigitalOcean, Linode — with Germany as the clear center of gravity. These are not compromised home routers or incidental caching nodes. They are rented boxes on budget European hosting, stood up to pin malicious content, and the concentration itself is a signal. When the same handful of VPS networks keep showing up as the announcers for unrelated malicious hashes, that is a hosting choice, and hosting choices are attribution surface.
The confidence model leans on the most defensible signal available: how many distinct malicious hashes a single host is announcing. A box serving one bad hash could be noise. We have hosts in this set announcing as many as six distinct malicious payloads at once. That is not a coincidence and it is not a home user who accidentally pinned something. That is a distribution node, and its job description is written in the routing table.
Why We Do Not Just Block All 349
Here is the discipline, and it is load-bearing. The collector collects. It does not automatically push these hosts to our blocklist, because a provider announcing a hash is telling you it is serving that content — not that it authored it, and in rare cases not that the content is even the thing you think it is. An IPFS node can cache and re-announce content it merely fetched. So promotion to the enforced blocklist is a human decision, made only when the evidence is clean: the host is announcing content that is malware and nothing else.
That is exactly what happened with yesterday's AsyncAPI payload. Both of the Miasma content hashes resolved to a single host, one peer identity announcing both, and both hashes carried malware-only payloads. That cleared the bar, so we promoted that one host by hand — it is now on the feed our edge blocklist enforces. The other 349 are intelligence until a human says otherwise. We would rather under-block and stay honest than auto-block and knock a benign node off the internet because it cached the wrong file. Ninety-five percent confident is a real number; a hundred percent is a lie, and on IPFS specifically the last five percent is where the caching edge cases live.
The Pattern Worth Naming
Content-addressed storage is quietly becoming the bulletproof-hosting layer of the moment. It shows up in supply-chain droppers like AsyncAPI's, in staged payloads, in the parts of a campaign the operator most wants to keep alive. The reason is always the same — durability — and the mistake is always the same: mistaking durability for anonymity.
They are different. Durability means the content is hard to remove. Anonymity would mean the host is hard to find. IPFS gives you the first and, by the very mechanism that provides it, denies you the second. Every node that keeps the payload alive is a node announcing where it is. The more durable an operator makes their hosting — the more nodes pinning and re-announcing — the more addresses they hand us. It is a protocol that trades hosting resilience for location privacy, and the operators reaching for it do not seem to have read that clause.
We have read it. Three hundred and forty-nine times so far, and counting every day.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.