Deconstructing a Dropbox Phish

Today  I was asked by a friend to take a look at a strange email they were seeing in their organization that contained a “bit.ly” URL.   I found it to be a fascinating phish!   A few of the things that made it interesting to me ...

• This DropBox phish pulls its phishing content FROM DROPBOX
• The "data" type makes a Base64-encoded phish from a URL
• The ".site" TLD was hard to "whois" - found a great resource to solve that

Bit.ly statistics

Because the URL is on “Bit.ly” we can just add a “+” to the end of the URL to get some information about the popularity of the campaign.  In this case, we see that the phishing URL using this bit.ly page has been accessed nearly 2,000 times!  This is actually good news for my friend -- it is a "broadly targeted" phish -- not someone focused on his organization.

Number of Clicks - 200 of these in past hour

An interesting feature of the phish is that it was "tested" a few times before the broad attack began.  40 times on May 30th and 14 times on May 31st before the "big blast" of spam went out.

Clicks per date

Certainly this indicates that the spam was mostly sent to North Americans ... but what does the high count of Burkino Faso clickers indicate?  Is this where our Phisher lives?

Geographic Distribution of clickers

Bit.ly Redirection

The Shortened URL redirects to:

    bakosport.eu  /   media   /   mailto  /    load_content.php

(spaces added to the URL for your safety)

After clicking there, the webpage that is displayed looks like this:

Page One of three

The page shown here is NOT A WEBSITE in the typical sense.  That strange long-URL actually contains THE ENTIRE WEBPAGE being displayed here.  (Heather McCalley from PhishMe is the first person that I know that observed this behavior, a couple years back).

All of the graphics, etc, are embedded in that extremely long URL.  The URL type “data” allows a URL that actually *is* the content to be displayed.  The first few characters tell us that it is a Base64-encoded string, and that it should be rendered as an .html file -- “data:text/html;charest=utf-8;base64” -- followed by a very long base64 encoded string that contains the graphics and everything else shown.

But where does it COME FROM?  It’s actually coming from DropBox!  DropBox is HOSTING THEIR OWN PHISH!!!    

 The first page of our phish is NOT being loaded from "bakosport".   When we capture the network traffic, we see that the content is actually being loaded from:

https://  dl.dropboxusercontent.com    /s/sc3fwytdedslpq5/    ncpete67-0000.html   

(again, spaces added for your safety)

which populates that URL with the Base64-encoded data.

The source of this page looks like this:

"view source" of Page One of phish

 We can easily "decode" this by removing the "%" signs and converting from Hex to ASCII to get a more reasonable source code:

"decoded" Page One source

 Whether the user clicks on “Download PDF” or “View Online” the phish advances to another Base64-encoded webpage, which is ALSO BEING DOWNLOADED FROM DROPBOX!!!

https://   dl.dropboxusercontent.com   /s/   oz9s7duiidrvoke/    ncpete67-0001.html

This page does the same trick of pushing the full URL into a Base64-encoded string and forwarding the browser to that URL:

Page Two of Three asks for email address and password

When the "Sign In" button is clicked, the form is “Validated” using a Javascript validator found on Google Drive at this location:

And then the ACTION sends the stolen credentials to the PHP file on the phisher's website:

  http://dlbox-content.site   /ncpete67   /finish.php

WHOIS on the new ICANN TLDs

.site is one of the new ICANN Top Level Domains -- and one of those that behaves poorly.  As an example, when we try to use common WHOIS tools to learn who registered "dlbox-content.site" we end up with nothing but errors.   

That is because most WHOIS services do not yet have a "whois.conf" that knows what to do with those Top Level Domains.  A fabulous Blog Post on WHOIS for new TLDs has the solution to this ... which is to put ALL of the new TLDs into your "/etc/whois.conf" file.

Here's a "snip" from that file (including our ".site" TLD):

 \.sh$ whois.nic.sh
\.shiksha$ whois.afilias.net
\.shoes$ whois.donuts.co
\.show$ whois.donuts.co
\.shriram$ whois.afilias-srs.net
\.si$ whois.register.si
\.singles$ whois.donuts.co
\.site$ whois.centralnic.com
\.sk$ whois.sk-nic.sk
\.ski$ whois.ksregistry.net
\.sky$ whois.nic.sky
\.sm$ whois.nic.sm
\.sn$ whois.nic.sn
\.sncf$ whois-sncf.nic.fr
\.so$ whois.nic.so
\.soccer$ whois.donuts.co
\.social$ whois.unitedtld.com
\.software$ whois.rightside.co
\.sohu$ whois.gtld.knet.cn
\.solar$ whois.donuts.co

I used that post to learn that I could look up ".site" TLDs at whois.centralnic.com.

While it is unfortunate that, like most cyber criminals, our phisher used a Privacy Protection service, we at least now know that the site was registered at NameCheap, which tells us who we can contact to get the domain killed!

Domain Name: DLBOX-CONTENT.SITE
Domain ID: D21072193-CNIC
WHOIS Server: whois.namecheap.com
Referral URL:
Updated Date: 2016-05-19T15:53:06.0Z
Creation Date: 2016-05-19T15:53:03.0Z
Registry Expiry Date: 2017-05-19T23:59:59.0Z
Sponsoring Registrar: Namecheap
Sponsoring Registrar IANA ID: 1068
Domain Status: serverTransferProhibited https://icann.org/epp#serverTransferProhibited
Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
Registrant ID: C51510053-CNIC
Registrant Name: WhoisGuard Protected
Registrant Organization: WhoisGuard, Inc.
Registrant Street: P.O. Box 0823-03411
Registrant City: Panama
Registrant State/Province: Panama
Registrant Postal Code: 00000
Registrant Country: PA
Registrant Phone: +507.8365503
Registrant Phone Ext:
Registrant Fax: +51.17057182
Registrant Fax Ext:
Registrant Email: a4d5abab04904005b1c3f150108ceaa6.protect@whoisguard.com

Now the Criminal uses his "finish.php" script to send the victim's email address and password to himself, and then to forward to Page Three of the phish, again, downloading the phishing page from DropBox and then loading the Base64 content as a new webpage:

WireShark shows us the Page Forwarding to grab DropBox content

Finish.php forwards and fetches the next page from:

https://   dl.dropboxusercontent.com   /s/   wftzfratbq3173u/   ncpete67-0002.html

which uses the same "data" trick to push the browser a Base64-encoded page three of the phish:

Page Three of Three - asks for the Victim Telephone Number

The “Validate” button on that form is going to hit the phisher’s domain, “dlbox-content.site” again.

http://dlbox-content.site/  ncpete67/  validate.php

After sending the telephone number to himself, the phisher exits by pushing the visitor to the real DropBox website.