James Stanley

Someone used my IPFS gateway for phishing

Thu 4 October 2018

At 02:43 this morning, I received an abuse complaint email. It was sent by PhishLabs to DigitalOcean, and DigitalOcean forwarded it to me.

During an investigation of fraud, we discovered a compromised website (hardbin.com) that is being used to attack our client and their customers.


First detection of malicious activity: 10-02-2018 19:06:26 UTC Most recent observation of malicious activity: 10-02-2018 19:28:25 UTC Associated IP Addresses:

No "compromised website" here! The machine in question is my public IPFS gateway, which I run for the purpose of providing a convenient introduction to hardbin.

Around the same time that this email was forwarded to me, DigitalOcean disabled the network interface on my VPS in order to stop the phishing attack from working. Fair enough, can't really expect them to do any more than that.

When I woke up and read this email, I visited the URL to verify that it is phishing, and immediately blocked the offending IPFS hash (QmUyT6vFaGxgcyD7o7eX4eifvV5fVxxKyfSfNC8oP6JG1B) in my nginx config, and replied to DigitalOcean at 08:38 explaining that I have blocked the hash and could they please switch my networking back on.

I decided to take a look at what exactly this phishing site was doing.

So it's just a standard Google sign-in phish. Probably the victim receives an email telling them that they need to login to their Google account in order to resolve a problem, and the hyperlink goes to the URL given above.

You'll note the URL has some random-looking text in the URL fragment:


so our first guess might be that some of the content is encrypted to avoid detection, and this is a key that then decrypts the content.

The HTML source is odd, however. It includes a mention of http://toast.bitty.site/. It turns out that "bitty.site" is a tool that allows you to encode the entire content of a small web page in the URL fragment! And indeed, that is what is being done here.

The random-looking text in the URL fragment is actually the content of the page, compressed with LZMA and encoded with base64. If we reverse this, we get:

$ echo "XQAAAASQAAAAAAAAAAAeGgqG70rZWojk3J5AyyC5pdYwyJfWHIBHUGivJcLcQVE/oHjdV3pvUtyMRW499SqeMLLi7x4fSaIAi0Izhe+oGbBKFh28KmaEAtiTUDAZuJULtdxsBAqWIUpOddytlgEdBqFdM6cEiQ44qWXdB1OipKFu0hVNKIAA" | base64 -d | lzcat


It seems all this is doing is redirecting to a file called GMA.html hosted in somebody's OneDrive folder. Using Firefox "Network Tools" verifies that the site is indeed fetching content from this OneDrive URL (it's worth verifying this even though it is pretty obvious, because otherwise a sneaky attacker could slip any plausible content into the URL fragment in order to frame an innocent third-party).

I also compared the HTML content that my server was returning to the content generated by "bitty.site" and it was identical, which proves there is nothing else up the attacker's sleeve.

So this is an interesting conundrum: since my server isn't actually returning any phishing content for the requested URL, should I even be blocking it? The content returned by my IPFS gateway for this URL is just a generic HTML renderer. My server is no more complicit in the phishing campaign than the user's web browser is! I reported my findings to DigitalOcean at 09:13 and asked if they would be happy for me to unblock the URL. There is certainly an argument that I shouldn't unblock it, since blocking it demonstrably prevents the phishing attack. But it is also hard to argue that completely benign content should be blocked just because somebody somewhere is phishing.

Interestingly, the source of the OneDrive URL actually checks whether the ?z=a parameter is present. If so it deobfuscates the page content using atob, and if not it redirects via hardbin.com. I'm not sure why.

I looked up the OneDrive URL in VirusTotal:

Only 3 of the 70 anti-phishing companies are actually classifying this URL as a phish. That is surprisingly poor.

In the past I have been very impressed with DigitalOcean's abuse response staff. I used to run a Tor exit node on DigitalOcean and they were extremely patient with me, so I was expecting my networking to be switched back on promptly. However, by 7pm (nearly 11 hours after I blocked the URL in question) I had still received no further correspondence from DigitalOcean. And my networking was still switched off. This was very annoying.

My friend Miles Armstrong suggested taking a snapshot of the droplet and restoring it to a new droplet, and switching the hostname over to point at the new droplet. I thought that was a splendid idea, so I did it, and 15 minutes later hardbin.com was back online. Hurrah! I did inform DigitalOcean about what I'd done, but they still haven't replied about that either.

So the problem is resolved for now, from my perspective (although I am still blocking a completely-benign IPFS hash, which I don't feel good about). It's worth noting that the completely-malicious GMA.html file is still not blocked by OneDrive (although their hosting provider doesn't appear to have switched their networking off).

I am surprised that the phisher decided to host the actual content on OneDrive instead of putting the entire phish in the URL fragment. Given that OneDrive haven't been very proactive in taking it down, it seems to have worked out, but the site would certainly be harder to take down if it only existed in the URL fragment.

And if you know a hosting provider that is less likely to switch your networking off, I'm all ears.

If you like my blog, please consider subscribing to the RSS feed or the mailing list:

James Stanley - james@incoherency.co.uk | ricochet:it2j3z6t6ksumpzd | jesblogfnk2boep4.onion | /ipns/jes.xxx/ | [rss]