Credential-stealing phishing is constantly evolving, nevertheless, some aspects of it – by necessity – stay the same. One thing, which is constant, is the need for a credential gathering mechanism, and although threat actors have come up with a number of alternatives to simply hosting a fake login page somewhere (e.g., using a third-party “forms” service[1] or attaching an entire phishing page to an e-mail[2]), the old approach of placing a phishing page on an internet-connected server and linking to it from e-mail messages is commonly used to this day.

Still, even when it comes to this kind of phishing, interesting trends do emerge from time to time. One such recent trend seems to be connected with an increased use of IPFS and R2 buckets to host phishing pages.

IPFS, or the InterPlanetary File System is Web3 storage system – a distributed, peer-to-peer data sharing network, originally conceived back in 2015[3] – which has been used by threat actors to host malicious content since at least 2022[4,5,6]. The R2 is a Cloudflare object storage service[7], which enables owners of buckets to expose their content publicly on the r2.dev domain[8]. The service was rolled out by Cloudflare in 2022 and threat actors started to use it to host malicious files the same year[9].

Although the use of IPFS and R2 buckets to host phishing pages is therefore nothing new, I did notice a significant increase in the number of new phishing campaigns that used these hosting options starting around the middle of February… You can see this increase in the following chart.

Since the beginning of February, messages from 84 previously unobserved phishing campaigns were caught by my spam traps. Over half of these linked to pages hosted on IPFS or in R2 buckets (38.1% and 13.1% respectively). And although data from my few spam traps can hardly be considered representative for the internet as a whole, changes visible in the chart seem to point to at least some deviation from the usual state of affairs…

It should be noted that the chart above shows only newly observed campaigns, not the volume of messages associated with them. Since for some campaigns, multiple messages were caught by the spam traps, when it came to overall amount of phishing, the use of IPFS and R2 was even more pronounced – 52.9% of all messages linked to IPFS and 16.9% linked to R2 buckets.

All the messages alluded to were run-of-the-mill phishing, as the example bellow shows, and as such, were most likely easily identified by most e-mail filters out there…

Any potential increase in the number of these messages/increase in the use of IPFS and R2 should therefore hardly present a meaningful threat to most organizations. Nevertheless, since content currently hosted on IPFS has minimal (if any) business relevance for most organizations, and most content hosted on the r2.dev domain will probably have limited business relevance as well, it might be worthwhile to consider limiting user access to IPFS and R2 content in any organizational setting (e.g., through DNS or URL filtering).

In the case of Cloudflare’s buckets, this would be quite straightforward (i.e., blocking access to *.r2.dev), however in case of IPFS – due to its distributed nature – this would be somewhat more challenging… That is, if it were not for the fact that from the regular web, IPFS may only be accessed through a small number of specialized gateways operating on known domains, which can easily be blocked[10].

Although limiting access to R2 and IPFS in this way would only be a minor addition to any security program, given how long threat actors have been using both of these services, it might at least be worth considering. Most phishing messages that point to these services will undoubtedly be stopped by automatic security solutions, however if one does get through and its recipient has a “brain freeze” at the same time, it may save an organization a small headache associated with stolen credentials…

For IPFS, blocking access outright should have no negative impact, however for R2 buckets, it would probably be worth checking on whether they are being used for anything business-relevant first.

[1] https://www.tripwire.com/state-of-security/google-forms-used-call-back-phishing-scam
[2] https://isc.sans.edu/diary/Phishing+with+a+selfcontained+credentialsstealing+webpage/25580
[3] https://en.wikipedia.org/wiki/InterPlanetary_File_System
[4] https://www.theregister.com/2022/07/29/ipfs_phishing_trustwave/
[5] https://www.trendmicro.com/en_us/research/22/l/web3-ipfs-only-used-for-phishing---so-far.html
[6] https://isc.sans.edu/forums/diary/IPFS+phishing+and+the+need+for+correctly+set+HTTP+security+headers/29638/
[7] https://developers.cloudflare.com/r2/
[8] https://developers.cloudflare.com/r2/buckets/public-buckets/
[9] https://www.netskope.com/blog/evasive-phishing-campaign-steals-cloud-credentials-using-cloudflare-r2-and-turnstile
[10] https://github.com/ipfs/public-gateway-checker/blob/main/gateways.json

-----------
Jan Kopriva
@jk0pr
Nettles Consulting