Anatomy of a Man-in-the-Middle Phishing Campaign on CoinbaseMay 29, 2018
In the summer after my freshman year of college, I had an internship with a startup that tries to defeat phishing attacks against enterprise corporations. As such, I spent a lot of time staring at phishing sites. Once, I showed a phishing campaign against MIT’s OWA email portal to my boss, and he blew my mind when he dug through the site and managed to find a publicly-accessible text file where the attackers were logging all the password attempts.
Ever since, I’ve been trying to replicate that same experience on every phishing attempt that comes my way, and for the first time since then, I managed to do it! The attack was targeting Coinbase, probably the most popular site for buying and selling cryptocurrencies. I’ll first describe the campaign, and then show how I discovered the password log file.
On Wednesday, May 16 at 4:20PM I received the following text message:
Several things should raise your suspicions immediately: first of all, no one is going around handing out 27 BTC (around $226,000 at the time) to random phone numbers. Secondly, the domain name that we’re linked to, tx-app.com, is not associated with Coinbase. (Incidentally, the “FRM” address was almost certainly generated through keyboard-mashing: there are no 1’s present at all, there are no repeated digits, and there are long strings of ascending or descending sequences like “98765”).
When we click on the link we’re redirected from tx-app.com to coinbase.tx-app.com and are taken to a website that looks pretty similar to Coinbase’s login screen:
Honestly, it’s a much better replica than most phishing attempts I’ve seen. The one thing that stands out is that the logo in the upper-left corner is not quite at full resolution. The bigger giveaway is the lack of a little green lock icon in the url. Because the site is served over HTTP instead of HTTPS and includes a form, instead we see:
Anyways, the phishing site was good enough to fool plenty of people as we’ll see later.
The phishing attack
Most phishing attempts are purely passive: the site will log your username and password when you try to sign in, and then will redirect you to the real site. However, since Coinbase enables 2-factor authentication for all its users, a username and password won’t get attackers very far.
Instead, these phishers launched a man-in-the-middle, or relay attack, in which they sit in between the user and the real coinbase.com site, and pass data back and forth between the two. When you enter an email and password, the site actually tries to log-in on the real Coinbase website, and throws up an error if your credentials aren’t valid.
Once a user gives a valid email and password pair, Coinbase will ask for a six digit code from the user’s phone. So, the phishers ask for the code as well:
Once a user enters the code, the phishing site forwards it to Coinbase. However, Coinbase still has one last defense: since the attackers are logging in from a new IP and device, Coinbase will send an email to the user and ask them to confirm the log-in attempt by clicking on the link.
Furthermore, this link must be clicked by the same device that the user is trying to log-in on:
So, how do our phishers get around this? Ingeniously, they actually ask that the user paste the url of the confirmation link in their form:
That way, the attackers can access the page from the device they’re trying to sign-in on, and Coinbase will never know the difference. Once you paste the link, the attackers will redirect you to coinbase.com and drain all the balance from any cryptocurrencies accounts you have.
Digging through the site files
Seeing this, I pointed DirBuster at the site and let it run. DirBuster is a nifty little tool that bruteforces common directory and file names in order to find unintentionally publicly-accessible files on a website. Relatively quickly, it found three new directories:
/vendor directory contains a bunch of PHP scripts. In particular, it has the full source code for the PHP Curl Class, which the attackers presumably use to make the requests to coinbase.com.
/proxy directory contains two PHP scripts and three text files which list a bunch of IP addresses and associated ports.
Unfortunately, the server tries to run any PHP scripts that are requested, so I couldn’t get the source code of these. I suspect that the server was proxying its requests to Coinbase through these IPs in order to evade blacklisting.
The real jackpot was in
/data. It contained five different text files, all of which were logs of various parts of the phishing process.
Three of them (
codes.txt) included a couple of emails and passwords, but mostly just logged errors during various aspects of the Coinbase authentication process. Much more interesting was
composer.txt which listed around 300 log-in attempts and included emails, passwords, IP addresses, user agents, and in some cases, cryptocurrency account balances:
Of course, some of these are people trying to login multiple times. I count 132 unique email addresses listed, including obviously fake ones like
OK, so over 100 people gave up their email and password to the attackers, but can we tell how many actually had their accounts drained? It turns out, we can. This brings us to the last text file:
success.txt, in which the phishers logged every time they successfully transferred cryptocurrency out of an account. Amusingly, this happened a grand total of three times:
As you can see, the attackers managed to exfiltrate 0.0124 ETH and 0.0031 BTC, which at the time was worth around $45 USD. Not particularly impressive.
blockchain, blockchain, blockchain
One neat aspect of all this that is specific to cryptocurrencies is that we can actually see these transactions happening on the blockchain since the log lists the attacker’s Bitcoin and Ethereum addresses. You can checkout the two Ethereum transactions here and here, and you can see the Bitcoin transaction here. I’ve also shown the Bitcoin transaction below:
As far as I can tell, the ether quickly gets exchanged with ShapeShift and the trail runs cold. Similarly, the bitcoin seems to get run through what seems like a tumbler. I am by no means an expert in this field, so if someone knows more about blockchain reconnaissance than I do, feel free to let me know what you find.
One last thing of note is that while the phishing site was taken down relatively soon after the initial attack, the Ethereum address continues to receive small amounts of currency, suggesting that the phishers are continuing to run the scam on new domain names.
All told, the attackers have received around $415 worth of Ethereum since they started (which, to be honest, is still not very impressive given how much work it must have been to create and run the phishing site).
So, what accounts for the dismal performance of the scam? The attackers had a number of things working against them. First was the choice to serve the site over HTTP instead of HTTPS. On unencrypted sites that include a form, Chrome includes a “Not Secure” message next to the URL. In fact, Chrome will actually get even more aggressive with non-HTTPS pages starting in October 2018:
One has to wonder why the phishers didn’t bother getting a free certificate from Let’s Encrypt to make the page more believable. Since the average person doesn’t know enough about domain names to understand that coinbase.com is owned by Coinbase, while coinbase.tx-app.com is not, we’ve entered a dangerous period where anyone can create a reasonably convincing phishing site just by obtaining a certificate.
Thankfully, Chrome is slowly phasing out the green locks entirely, making HTTPS the accepted default instead of some special status:
The other major factor was Coinbase’s two-factor authentication. There’s a widespread myth that two-factor authentication can prevent phishing. As we ve seen, this is untrue—to really stop phishing attacks you need to use a hardware token like a Yubikey paired with some cryptographic protocol like U2F or WebAuthn which binds to the TLS session. Coinbase currently doesn’t support any such method. Still, two-factor authentication clearly mitigated the damage, if only by making it so hard for users to login that they stopped trying midway through getting phished.
Finally, the largest determinant was Google’s Safe Browsing initiative which flagged the site only a couple hours after the text message was sent to me.
Once a site has been flagged, Google displays a giant red page to users, warning them that they’re about to phished. Once this happens, the attackers have pretty much no hope of extracting that much more currency from additional users.
Domain Name: TX-APP.COM Registry Domain ID: 2264223847_DOMAIN_COM-VRSN Registrar WHOIS Server: whois.hostinger.com Registrar URL: https://www.hostinger.com Updated Date: 2018-05-16T19:42:48Z Creation Date: 2018-05-16T19:42:47Z Registrar Registration Expiration Date: 2019-05-16T19:42:47Z Registrar: Hostinger, UAB Registrar IANA ID: 1636 Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited Registry Registrant ID: Not Available From Registry Registrant Name: beatrice agatha agatha Registrant Organization: beatrice agatha agatha Registrant Street: RUDDY CREEK Registrant City: CHESTERFIELD Registrant State/Province: VA Registrant Postal Code: 23234 Registrant Country: US Registrant Phone: +1.8042149939 Registrant Phone Ext: Registrant Fax: Registrant Fax Ext: Registrant Email: [email protected] Registry Admin ID: Not Available From Registry Admin Name: beatrice agatha agatha Admin Organization: beatrice agatha agatha Admin Street: RUDDY CREEK Admin City: CHESTERFIELD Admin State/Province: VA Admin Postal Code: 23234 Admin Country: US Admin Phone: +1.8042149939 Admin Phone Ext: Admin Fax: Admin Fax Ext: Admin Email: [email protected] Registry Tech ID: Not Available From Registry Tech Name: beatrice agatha agatha Tech Organization: beatrice agatha agatha Tech Street: RUDDY CREEK Tech City: CHESTERFIELD Tech State/Province: VA Tech Postal Code: 23234 Tech Country: US Tech Phone: +1.8042149939 Tech Phone Ext: Tech Fax: Tech Fax Ext: Tech Email: [email protected] Name Server: ns1.hostinger.com Name Server: ns2.hostinger.com Name Server: ns3.hostinger.com Name Server: ns4.hostinger.com DNSSEC: Unsigned Registrar Abuse Contact Email: [email protected] Registrar Abuse Contact Phone: +37064503378 URL of the ICANN WHOIS Data Problem Reporting System: http://wdprs.internic.net/
The last thing I tried was querying
whois for information on the domain name. All the information is of course, fraudulent (I believe the listed phone number and address belongs to BAE Systems). Still, it’s not completely useless. We can do a reverse whois lookup to find other domains registered with the same fake data:
Reverse Whois results for [email protected] ============== There are 4 domains that matched this search query. These are listed below: Domain Name Creation Date Registrar bn-ap.com 2018-05-16 HOSTINGER UAB lt-pd.com 2018-05-16 HOSTINGER UAB mq-tx.com 2018-05-16 HOSTINGER UAB tx-app.com 2018-05-16 HOSTINGER UAB
Unfortunately, all of these have since been taken down.