A look at a PayPal phish in the making

A look at a PayPal phish in the making

A couple of weeks ago, we blogged about a surge in PayPal phishing emails. These were not only were after stealing your credentials but also tried to install malware on your system.

A recent tweet from Fiddler‘s creator Eric Lawrence about another PayPal phishing page prompted me to check it out in greater details.

Something odd happened when I disabled the browser protection to actually view what the site looked like (you should not do that unless you know what you are doing):

browser_comparison

This phishing page would not load if the user was running Google Chrome, instead displaying a generic:

“Sorry, this website isn’t compatible with Google Chrome.

I tried a multitude of User-Agents using the built-in Fiddler feature that can fake the client request:

user-agents

but only Chrome and ChromeBook were getting that error message. In fact, mobile User-Agents (for example the iPad’s) were served the page just fine.

This phish, like many others, asks for your email address, password, DOB, address and credit card information:

IE_phish

I decided to check out the page’s source code to find some clues to identify the origin of this phish. I was looking for unique strings that could lead to a hit on a Google search or other security related database.

It turns out the hacker that had set up that phishing site used source code that has been uploaded to pastebin.com and was public:

pastebin

It’s always good to see the server side of things (PHP) because html only shows you what is displayed but not necessarily the internals. A search for “Chrome” immediately returned the code I was looking for:

disable_chrome

Now we know how the Google Chrome error message worked but we still don’t know why the hacker would not want Chrome users to access the phishing page.

If this was a Traffic Distribution System (TDS) leading to an exploit kit, it would make sense to avoid wasting everybody’s time since exploits that run on Chrome are just too rare. But a simple phishing page with a standard html form should not be an issue that the backend server can’t handle.

Google Chrome does have a good anti-phishing filter but again, the hacker would have known that sooner or later most browsers would be blocking the site too.

But there was a simpler explanation. A day after the site was originally spotted, we noticed a change in the server’s structure. All of the sudden, the root of the domain was browsable:

indexof

This is probably due to an incorrect configuration in the Apache config files and shows that the author was actively working on it.

directory

Even the phishing page itself was being updated to a newer one:

phish

It looks like the hacker was simply in the process of building his own phishing site by re-using some source code he had found elsewhere and adapting it along the way.

A new look (a couple days later):

final_phish

But the next day, the design once again completely changed:

This may be the last version the hacker settles on. It looks a lot more professional and authentic now, using a smart two-step process for asking the information (instead of asking it all at once).

The phishing URL is semi randomized (the domain remains the same) so that if you refresh the page, you get a different subdirectory (named after an MD5 hash):

http://serviceloginsecure .com/pp/c868ba65f7816826f13fad2f1be52b82/ http://serviceloginsecure .com/pp/a89eb605a97972b9b86567d4ba5b0318/ http://serviceloginsecure .com/pp/c81e8115283313b7356f932023fa516b/ etc.

This is done by using PHP’s microtime function which returns the current Unix timestamp in microseconds. Then an MD5 hash of it gives you a somewhat random (at least new) string:

microtime

If we keep looking through the code we can see the important data fields containing personal information from the victim:

info

Once you fill in the information (user name, password, credit card details etc), everything is sent to a Gmail address:

sending_info

When your information has been stolen, a command logs you out of PayPal (in case you were already logged in):

refresh

and then attempts to sign you back in again:

securitychallenge
redirect

For this last part to work, you may need to have entered a valid and existing PayPal email address and password. The goal is to create a seamless experience for the victim that has just been phished and can’t even tell it.

As always, please be very careful whenever you are about to login into a site. Checking the URL is a good thing but not enough. Always ask yourself how you got there: was it by clicking a link within an email or was it a pop-up that suddenly appeared? You’re better off bookmarking the site or typing it by hand, watching out for typosquatting of course!

We have notified the phishing site’s hosting provider and hope the site will be taken down shortly.

@jeromesegura

ABOUT THE AUTHOR

Jérôme Segura

Principal Threat Researcher