Netting phish in the IPFS ocean

The InterPlanetary File System (IPFS) was designed to address one of the Internet's biggest shortcomings: pervasive centralization. It works by assigning each file a hash derived from its content, known as Content Identifier (CID), which can then be stored and served by one or more peers. This approach makes content distribution more efficient and resilient. Today, IPFS powers NFT metadata, software distribution, digital archives, and a wide range of decentralized applications where data persistence and availability are essential.

Unfortunately, the same properties that make IPFS attractive for legitimate applications also make it appealing to attackers. In recent years, phishing campaigns have increasingly leveraged IPFS to host credential-stealing websites, particularly via public IPFS HTTP gateways. These gateways allow such pages to be accessed through ordinary web browsers and may inadvertently make them look as legitimate as the gateways themselves.

Despite this growing threat, phishing on IPFS remains poorly understood. Unlike the traditional web, where websites are typically tied to domains and centralized hosting infrastructure, IPFS introduces new challenges for phishing detection, attribution, and mitigation.

We developed and presented the first systematic framework for monitoring and characterizing phishing across the IPFS ecosystem in our recent ACM WWW 2026 paper. Our work combines IPFS network measurements, passive DNS data, large-scale content analysis, and campaign clustering. We provide the first comprehensive view of i) how phishing campaigns operate on IPFS, ii) how attackers exploit public gateways, and iii) why many traditional web-based phishing defenses fail in decentralized environments.

This blog summarizes the key findings from our research. You can read the full paper here.

How phishers leverage IPFS

Phishing websites typically rely on rented hosting infrastructure and registered domain names. This creates several opportunities for defenders - hosting providers can suspend malicious websites, domain registrars can seize malicious domains, and blocklists can quickly flag known-malicious URLs.

IPFS fundamentally changes this model. Rather than publishing content on a web server, attackers simply add files to the network (see Figure 1 below). The phishing page is assigned a CID derived from its content, which can then be used to retrieve it through public HTTP IPFS gateways. Note that the content itself is immutable. Once published, it cannot be modified without generating an entirely new CID. For example, changing a single character in an HTML file would produce a completely different content identifier. As a result, maintaining simple blocklists of malicious CIDs quickly becomes impractical, as attackers can generate new identifiers with minimal effort.

Public IPFS gateways are critical for phishing distribution. A gateway translates ordinary HTTP/HTTPS requests into IPFS requests, allowing users to access an IPFS-hosted webpage exactly as they would access any normal website. To the victim, the experience often looks nearly identical.

Overall, this creates a challenge for defenders. Blocking one CID does not completely stop a phishing campaign. Attackers can make tiny changes to the phishing kit and immediately generate an entirely new CID while preserving almost identical functionality. The result is an ecosystem where campaigns often consist of many related phishing pages rather than a single malicious website. Detecting these relationships requires looking beyond CIDs alone.

Detecting IPFS phishing at scale

We developed the first large-scale measurement framework dedicated to detecting and monitoring phishing content across the IPFS network. Figure 2 provides an overview of the framework.

The platform continuously discovers newly published IPFS content through passive DNS and network monitoring, thus automatically detecting phishing pages. This is done by extracting HTML features and calculating similarity scores using SimHashes. We then cluster related pages into campaigns and continuously monitor gateways to measure the availability of phishing content over time.

During the 11-month measurement period in 2024-2025, our platform identified 10,489 phishing CIDs across the IPFS network. These phishing pages were highly interconnected: having clustered them, we identified 448 distinct phishing campaigns.

Even more striking was the concentration of activity. Nearly 80% of all detected phishing CIDs originated from only 69 campaigns. This suggests that phishing on IPFS is dominated by a relatively small number of large, highly active campaigns that continuously republish modified versions of the same phishing kits. From a defender's perspective, this is encouraging: disrupting a handful of dominant campaigns could significantly reduce the overall volume of phishing content on the network.

Our study also revealed a much broader gateway ecosystem than previously recognized. We identified 588 public HTTP gateways involved in serving phishing content, 573 of those not included in public gateway lists. This highlights that the publicly visible gateway ecosystem represents only a small fraction of the infrastructure actually being used to access IPFS content.

Perhaps the most concerning finding involves gateway caching. Public gateways often cache frequently requested content to improve performance and reduce network load. While this behavior benefits legitimate users, it can also unintentionally benefit attackers. Once a phishing page has been cached by multiple gateways, it may remain accessible long after the original publisher has disconnected from the network. Therefore, reputable gateways can unknowingly amplify the availability and lifetime of phishing campaigns, making malicious content more persistent and more difficult to remove.

Taken together, these findings demonstrate that phishing on IPFS is a standalone ecosystem with its own infrastructure, attacker strategies, and persistence mechanisms. They also show that current IPFS blocklisting mechanisms are insufficient on their own. Addressing phishing in decentralized environments requires detection techniques that focus on campaign behavior and content similarity, rather than relying solely on URLs or individual content identifiers.

Discussion

Mitigation efforts should focus on the parts of the ecosystem where defenders have the greatest leverage.

One of the most effective intervention points is the public IPFS gateway ecosystem. Because gateways bridge the decentralized network and the traditional web, they are often the first point of contact for users accessing IPFS content. Strengthening gateway security can therefore significantly reduce user exposure to phishing attacks.

Importantly, focusing mitigation at gateways preserves the core design principles of IPFS. Attempting to block or remove content directly from the peer-to-peer network would conflict with the protocol's decentralized, content-addressed architecture and its goal of providing resilient, blocking-resistant content distribution. Gateways, by contrast, already act as policy enforcement points between the decentralized network and end users, making them a practical place for implementing phishing protections without altering the underlying operation or philosophy of IPFS itself.

Concretely, we propose the following recommendations for gateway operators:

• Enable IPFS denylists. Adopt and maintain shared phishing denylists using the existing IPFS blocklisting mechanisms.
• Reduce unnecessary content propagation. Avoid automatically re-providing phishing content to the IPFS network after it has been requested. This limits the unintended replication of malicious data and reduces opportunities for attackers to increase content availability.
• Shorten cache retention periods for suspicious content. While gateway caching improves performance, it can also prolong the lifetime of phishing pages long after the original publisher has gone offline. More conservative cache policies can reduce this persistence without significantly impacting legitimate content delivery.

Finally, we recommend extending existing phishing defenses with IPFS-aware threat intelligence. As phishing increasingly moves to decentralized platforms, security vendors, browsers, and email providers should incorporate IPFS-specific indicators such as CIDs and gateway URLs into their detection pipelines.

Together, these measures offer practical improvements that can be deployed without requiring changes to the underlying IPFS protocol.

Conclusions

We developed the first systematic measurement platform to detect phishing on IPFS, providing a comprehensive view of how phishing campaigns operate across the network. Over an 11-month observation period, the platform detected 10,489 phishing CIDs, revealing widespread campaign reuse rather than isolated attacks. We also identified 573 previously undocumented public gateways involved in content dissemination and demonstrated how gateway caching unintentionally extends the availability of phishing pages.

Most importantly, our findings show that traditional phishing detection approaches are not sufficient for decentralized environments. Techniques built around domains, URLs, and centralized hosting infrastructure struggle when content is immutable, distributed, and accessible through hundreds of gateways.

For more details on our methodology, measurements, and findings, please refer to the full paper: Netting Phish in the IPFS Ocean: Real-Time Monitoring and Characterization of Decentralized Phishing Campaigns