Found in environments protected by: Microsoft EOP, Cisco Ironport
By Elmer Hernandez, Cofense Phishing Defense Center (PDC)
Abuse of the Interplanetary File System (IPFS) has kept its momentum and shows no signs of slowing down. Two months into 2023, the Cofense Phishing Defense Center (PDC) has seen malicious IPFS content reported by users on an almost daily basis. More and more attackers are realizing the potential of decentralization through IPFS and other Web3 technologies. Cofense analyzed and tracked this trend showing as much as a 482% increase in the number of campaigns leveraging Web3 technologies during the first three quarters of 2022. Let’s review some of the examples the Cofense Phishing Defense Center (PDC) has observed as well as some of the ways attackers have switched up their tactics.
The IPFS Nuts and Bolts
IPFS refers to a protocol for distributed storage and access of files and the peer-to-peer (P2P) network using it. A P2P network content delivery network does not depend on a single central entity but is instead fetched from several nodes in the system. In order to locate content IPFS relies on Content Identifiers (CID), character strings based on, among other things, the cryptographic hash of the content. This is known as content addressing and is different from day to day browsing of the web in which we primarily identify resources by the location, not the actual content.
Accessing the IPFS network can be done through IPFS software or gateways. Gateways serve as special points of entry to the network for applications that might not natively “speak” IPFS, think of a web browser that normally retrieves content using protocols such as http and ftp. A lot of these gateways are public, free for anyone to use; thus, they are how most average users will come into contact with IPFS, intentionally or not.
How do I know I accessed IPFS through a gateway?
You will normally see a URL in one of two formats:
- Path style
https://{gateway URL}/ipfs/CID/optional path to specific resource
- Subdomain style
https://CID.ipfs.{gateway URL}/optional path to specific resource
Although it is possible to map human-readable names to IPFS CIDs, most campaigns seen by the Cofense Phishing Defense Center (PDC) kept the CID in its raw form.
With these basics in mind let’s look at some examples.
IPFS Credential Phishing
IPFS phishing campaigns are no different from those seen in your standard phishing email. Figure 1 is in the form of a fake DocuSign request by an insurance company, figure 2 is spoofing proof of a settled payment, and Figure 3 is a generic account confirmation request.
Figure 1
Figure 2
Figure 3
Interacting with any of these emails will eventually lead the user to an IPFS phishing page displayed with the help of a public gateway. Figure 4 is a Microsoft phishing page accessed through the main ipfs.io gateway, maintained by Protocol Labs, the organization behind IPFS. Figure 5 is a similar phishing landing page, but it’s accessed through Cloudflare’s own gateway. Both have a path–style URL.
Figure 4
Figure 5
Some phishing pages will detect the user’s email domain in the URL and fetch the right customization elements to appear more genuine to users. Figure 6 shows an example where we provided a fake Cofense address; the page displays our logo in the “Sign In” box as well as a copy of our homepage as the background. This page was accessed through a gateway belonging to Portuguese researchers, but with a subdomain style URL.
Figure 6
Since public gateways are just a means of access to IPFS, any CID-gateway combination (and, therefore, several different URLs) can be used to access a specific CID’s content. This means that public gateways do not host or store any content and are not themselves responsible for it. The same cannot be said of paid services.
Pinning and Dedicated Gateways
Pinning in IPFS means that certain content is saved to avoid deletion when a node clears out unused content. An IPFS pinning service provides a series of nodes that pin users’ content; this content can then be made available through unique gateways known as dedicated gateways. Unsurprisingly, attackers abuse these services to ensure their malicious pages remain accessible.
Figure 7 is a Microsoft phishing page accessed through a dedicated gateway provided by IPFS pinning service Pinata. Dedicated gateways often provide the option of customizing the gateway URL; in this case, the attacker has made the URL look like Microsoft SharePoint (Figure 8). Unlike public gateways, IPFS pinning services are responsible for storing and pinning content in their own nodes.
Figure 7
Figure 8
Combining Techniques
The Cofense Phishing Defense Center (PDC) has previously analyzed the use of online translation tools to disguise phishing pages, particularly Google Translate. Threat actors don’t use these tools to translate a webpage but to generate a URL that is more likely to evade detection. IPFS phishing benefits from this make-over, as it can help shorten or somewhat disguise the long and strange-looking CIDs.
Figure 9 shows the original version of an IPFS phishing page, while Figure 10 is the Google translation. The public gateway in this case belongs to web3.storage.
Figure 9
Figure 10
Google Translate is not alone. Yandex translate and turbopages are also being used for similar purposes as seen in the URL of Figure 11, however, the corresponding site was not available. The public gateway is from Starton, another Web3 technology company.
Figure 11
Whether Web3 technologies represent the future of the web remains to be seen. At present, IPFS is being abused in several ways to launch phishing campaigns. IPFS is unlikely to be part of most companies’ current operational reality, if so any user access to gateways of any kind should be flagged as a potential security event.
IoCs
| Content Identifiers |
|---|
| bafybeihzsf7bdghqvgkfy4wzwp2tcryranbtwb37bwsg6zlncjpqull7wm |
| bafybeig42fsrlqq4jdlhsvgjpdodl2mxbycklxfbvxgcfynalio5ovr5by |
| bafybeiamjhzqo6s2pt4ue6ifk7jpd47cwtmjulb35z32sdoivxs3sj7tg4 |
| bafkreievz6qpx737jmgicjzhggmrce2merur6nz3a27vkzoc5hyub4aprq |
| bafkreid7rkj7dwva2o2xxth2pdrk2qht4nzlc2vjib6c7cimayzgcr4dge |
| QmcRterqNSB415BdAFcQfxbRF9wfot84mXgeutWmXMAYBX |
| QmevoyZy34tAgu72vjBD76rhyY169z7N3D1oTrdqmVbfCf |
All third-party trademarks referenced by Cofense whether in logo form, name form or product form, or otherwise, remain the property of their respective holders, and use of these trademarks in no way indicates any relationship between Cofense and the holders of the trademarks. Any observations contained in this blog regarding circumvention of end point protections are based on observations at a point in time based on a specific set of system configurations. Subsequent updates or different configurations may be effective at stopping these or similar threats. Past performance is not indicative of future results.
The Cofense® and PhishMe® names and logos, as well as any other Cofense product or service names or logos displayed on this blog are registered trademarks or trademarks of Cofense Inc.
