Recent Posts

Recent Blog Posts

The PhishLabs Blog

Man-in-the-Server Phishing

Posted by John LaCour on Nov 17, '08

Most phish sites are the boring ‘dinosaur’ phish that simply mimic the legitimate site and send the stolen credentials off to some email address. Today I stumbled across something different – an instance of something similar to the “universal phish kit“. While this is nothing brand new, it’s pretty rare and I haven’t seen the details of these kits discussed in depth anywhere.

Why would phishers go this route instead of use the traditional phishing site? Two possible reasons:

1) To validate the credentials as real and working.

Often times when people receive a phishing an email, they may visit the phishing site and fill in the site with bogus information – many times I’ve seen choice expletives which are directed at the criminals. In some cases, the bank or their anti-phishing vendor may also dilute the phish with fake information. Sorting through all of that is a pain for the criminals so they may want to only save the good stuff.

2) To capture authentication cookies. As well see in a moment, this particular phishing kit saves the session cookies associated with the victim’s session with the legitimate site. This may be because the authentication system used by this particular bank also uses information about the user such as their browser version, language settings, and other details that help indicate if the user is the same user that visited previously. Perhaps authentication is not possible if there’s a mismatch or perhaps additional layers of security are avoided if the right user environment details are also provided.

In this case, the phish site isn’t proxying the entire connection. Instead, they’re showing a phishing page and sending the would-be-victim the same javascript from the real bank web site in order to generates specific information about the user’s system and web browser in exactly the same manner as the bank. Then, that information is sent along with the userid and password to the bank site and the authentication and session cookies are saved into a file that can be used later.

So let’s look at the source code (edited and for brevity and to protect the targeted organization):

function http_build_query($a) {
foreach ($a as $key=>$val) $p.=”{$key}={$val}&”;
return $p;

This function is used to parse the variables posted to the phishing page and is used to generate the form data that is sent to the legitimate bank web site. This is important because obfuscated javascript is sent by the real site which causes the user’s browser to send the browser version, language, and other details about the end-user system. The phishing site is able to get the user to generate the same data by including the same javascript in it’s copy of the page.

$cookfile = “/tmp/”.md5($_SERVER['REMOTE_ADDR']);

The user’s IP address is hashed and that’s used as a file name to store their cookies.

A page is fetched from the real web site by passing in the information stolen including the specially crafted form data about the user’s system.

function fetch($url, $post)
{ global $cookfile;

$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt ($ch, CURLOPT_RETURNTRANSFER, 1); 

if($post) {
curl_setopt ($ch, CURLOPT_POST, 1);
curl_setopt ($ch, CURLOPT_POSTFIELDS, $post);
curl_setopt($ch, CURLOPT_HTTPHEADER, _headers());
curl_setopt($ch, CURLOPT_COOKIEFILE, $cookfile);
curl_setopt($ch, CURLOPT_COOKIEJAR, $cookfile);
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1);
$page = curl_exec($ch);
return $page;

The criminals also take the time to email off the results of their work to an email address hosted at Gmail which has been reported for shut down.

By looking at the contents of the /tmp folder on phishing server, I can see that these bad guys may have stolen as many as 30 accounts. At least that’s how many cookie files there were with authentication variables set.

What can this bank, or other banks, do about these kits? 

The first is to realize as this kit demonstrates, that any information the real site requests about the users system, the phishers can do that as well. The user environment should not be considered a reliable authentication factor.

Also, pay attention to your web site log files. There’s no reason that 30 people should be logging in from the same IP address of a web site in a country other than the country that this bank serves. In this particular example, the kit did not even use a valid User-Agent field. No normal user is going to have a web browser that doesn’t send a User-Agent header.

Topics: Phishing, Threat Analysis

What's this all about?

The PhishLabs Blog is where we share our insights and thoughts on cybercrime and online fraud.

Recent Posts

Subscribe to Email Updates

Posts by Topic

see all