Thursday, June 02, 2016

TodayI 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:

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.

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!

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: