Ninety Minutes Ago, Blocking IPFS-Hosted Malware Was Theoretical. Here's the Host Map, Live in Our Feed.
- Patrick Duggan
- 11 minutes ago
- 3 min read
This morning we wrote that malware is moving to IPFS, where there's no domain to seize and the takedown playbook has no answer. That post ended on a defender's opening — IPFS isn't anonymous, so the provider hosting the content leaks a real IP. That was the theory. Ninety minutes later it is not theory anymore. We built the resolver, wired it to our block feed, and verified the result by hand. Here is the map.
The host map
We now walk each malicious content identifier through the IPFS network to the machines currently serving it, resolve those to real IP addresses, and enrich each one to its hosting network and country. The picture is not shadowy bulletproof providers. It is mainstream commercial hosting: Hetzner leads, followed by Contabo, OVH, Scaleway, DigitalOcean, and netcup, scattered across Germany, France, Finland, the Netherlands, and North America.
The signal that separates a deliberate malware node from a home user who happens to run the software is simple and hard to fake: how many distinct malicious payloads a single host is serving. The hosts we flag are each serving several at once. That is not an accident of shared hosting. That is a node doing a job. Those hosts, above our confidence bar, now flow automatically into the block feed our edge shield enforces.
Don't trust — verify
Here is the part we care about most, because it is the difference between a claim and a capability. When the pipeline reported that it had promoted the hosts into the block feed, we did not believe it. A success log is not a blocked IP. So we pulled the actual feed the edge worker consumes — the plain list of IPs it enforces — and searched it for the hosts we had just resolved. They were there. Not in an internal report, not in a database we control the meaning of, but in the live feed the shield actually reads.
That check caught a real bug on the way. The first run logged a failure, because the write to our large indicator store finishes asynchronously and our impatient verification checked too early. The infrastructure had actually succeeded; the log was lying in the pessimistic direction. We would never have known which kind of lie it was without going to the feed and looking. A green checkmark that says "done" and a red one that says "failed" are equally worthless until you verify the thing they claim to describe. We verified. It works.
Who's getting got — the honest version
Now the human question. And here the honest answer is more useful than a confident one. Content-addressing is built to hide the victim: the address is a hash of the payload, so it tells you the file is a specific malicious thing and nothing about who it is dressed up to fool. The lure lives inside the content, not in the address. So when we resolve the host, we learn where it is served from, not who it targets. Our own indicators reflect this — tagged generically as malware, scam, and phishing, without clean brand attribution. We could invent a victim list. We won't.
What we can say honestly is the victim profile the technique is known for, and it is aimed at individuals, not enterprises. Crypto is the heaviest theme — wallet and seed-phrase theft, the kind of page that only needs to load once. Credential theft is next — webmail and single-sign-on clones that harvest the password that unlocks everything. And third is the fake browser-update class we track constantly, which drops stealers and loaders on whoever clicks. The victim is a person; the thing stolen is a wallet, a password, or a session.
The reframe
For content-addressed hosting, "who's getting got" is partly the wrong question, because the technology is specifically designed to hide the answer. The question that has a real answer is where it is served from and how you block that — and as of ninety minutes ago, we can give you that answer host by host, and act on it. Anyone who hands you a precise per-campaign victim brand off IPFS infrastructure is reading the payload hash and guessing. We would rather show you the host, and block it.
We hold this at about 95 percent, as always. The host map and the block wiring are solid and verified against the live feed. The missing five percent is the precise per-campaign victim, which the content-addressing genuinely obscures — and that is exactly the part we will not pretend to know.
Her name was Renee Nicole Good.
His name was Alex Jeffery Pretti.




Comments