PhishLabs is looking forward to joining our colleagues in Prague to continue the fight against cyber-crime and online fraud.

ABOUT the Counter eCrime Operations Summit

CeCOS VI, the second APWG conference held in Europe, is an open conference for members of the electronic-crime fighting community, hosted by the APWG and its Conference Partner AVG, Program Partners: The Council of Europe and Organization for Security and Cooperation in Europe, and sponsored by AVG, Google, Microsoft, MarkMonitor, ESET, Telefonica and ICANN. The CeCOS programs are widely considered the most vital events to investigators and managers of electronic crime from across the private and public sectors.

AGENDA

http://apwg.org/events/2012_cecos.html#agenda

CONFERENCE REGISTRATION:

http://secure.lenos.com/lenos/antiphishing/cecos2012/

In this case a WordPress blog was hacked, probably with the recent TimThumb vulnerability which has been massively exploited by phishers, to upload the following phishing site:

In this case, the legitimate web site page has been altered to prompt for an email address in password.    Apparently the scammers are simply stealing email credentials for future spam and phishing scams.

PhishLabs has reported the phishing site to the web hosting company involved.

Users receive an email message which appears as follows:

From: ach@nacha.org [mailto:ach@nacha.org]
Sent: Thursday, February 24, 2011 9:47 AM
To: Denise Muns
Subject: Your ACH transaction

The ACH transfer , recently sent from your checking account (by you or any other person), was rejected by the Electronic Payments Association.

Please click here to view report

——————————————————————

Hal Vance,
Fraud Department

The link in the email includes one of nearly 400 domain names which in turn redirects to the site DF1C.CO.CC.    This site hosts an exploit pack which infects the user with malware.

The malware downloaded is a Zeus Banking trojan, MD5 = a1d090f5c26eb8ff1b20b87a43fe0f25, and is currently detected by 25 of 42 anti-virus vendors on VirusTotal.   Threat Expert report here.

PhishLabs is in the process of analyzing the malware binaries to determine what organizations are being targeted.    Please contact us at info -at-phishlabs.com for additional information.

PhishLabs has recently seen some advancements in how redirectors are being used in phishing.   But first, let’s look at how these redirectors are typically used.   There are several ways that theu can be implemented:

PHP

The php header() function will send the browser an arbitrary HTTP header response.   The attackers use the Location: header to redirect users to the phishing site:

<?php
header('Location: http://hacked.com/phish/page.html');
?>

Javascript

There are several javascript functions that will redirect users to another site.    The following code examples demonstrate how redirects can be implemented:

<script type="text/javascript" language="javascript">
location.replace("page.htm");
</script>

In addition to location.replace(), other functions include window.location.replace(), window.location.href(), document.location(), document.location.replace(), and I’m sure there are other possibilities.

HTML

The deprecated, but still widely supported <meta> tag with the http-equiv=”refresh” parameter still works and is often used as well.

<meta http-equiv="refresh" content="0;url=http://phishsite.com/" />

Flash

Adobe Flash can also be used to redirect users to another URL.   We have seen a few cases of this used with phishing attacks.    It’s likely used less often because it requires a bit more work on the part of the attacker (but not much).    Example Flash ActionScript:

getURL("http://site.com/phish.html","_top");

Recently, PhishLabs has detected some advanced forms of using redirect functions via PHP programs.   In samples programs we have recovered, attackers have expanded functionality to redirect users to one of several phishing sites and to check if those phishing sites are still available first.    The following are relevant pieces of the code used:

First they setup an array of sites.   In the examples discovered they also included the legitimate bank web site as a redirect destination of last resort:

$a = array(
'http://hackedsite1.com/dir/bankname/index.php',
'http://anotherhackedsite.com/dir/bankname/ssl.php',
'http://www.bank.com/',
'http://www.bank.com/'
);

Next the attackers use some code to test each of the URLs in order to find out if it working by checking for a 2xx HTTP response code:

 $g = 'HEAD '.
 (isset($p['path']) ? $p['path'] : '/').
 (isset($p['query']) ? '?'.$p['query'] : '').
 ' HTTP /1.0'."\r\n".
 'Host: '.$p['host']."\r\n".
 'Connection: Close'."\r\n\r\n";
 fwrite($f, $g);
 while (!feof($f)) $d .= @fgets($f, 1024);
 fclose($f);
 return (trim($d) == '' || count(explode('HTTP 1.1 4', $d, 2)) == 2  ... )

And finally they use the old PHP header() function to send an HTTP location: header and redirect the user’s browser:

header('Location: '.($r ? $l : $r));

Attackers continue to evolve their tactics and so too must we continue to evolve our defenses and countermeasures.

Would-be victims are seeing a web page form in the browser, but it almost looks like they’re viewing a PDF document that’s making use of javascript forms.      Like most tax related phish it promises them a refund if they’ll only provide their bank card details.

In case you’re not familiar, a formmail script is a CGI web application which receives data from a form on a web page and sends it off via email.    They’re commonly used for things like ‘Contact Us’ forms, support requests, feedback, etc.    Matt Wright claims that his formmail script has been downloaded over 2 million times since 1997.   Matt’s version and lots of others are everywhere.

And that’s the problem.   Many people have written their own without understanding the security and abuse implications.   Written correctly, they restrict the destination of any generated emails to the address of the webmaster or appropriate contact for that web site.    Written incorrectly, they can be used to send any message content to any address – including that of a cyber-criminal on a phishing expedition.

Recently, PhishLabs examined the prevalance of formmailer abuse by phishers.     After reviewing two weeks of phishing sites, we estimate that 10% of all phishing abuses formmailer scripts.     That’s significant.    Many phishers use open formailers in combination with free web hosting.    For example, t35.com provides free web hosting, but they don’t support ability to send emails from their web servers.    So instead the attackers set-up the phishing site so that the HTML pages send victim data to another site with the open formmailer.    The formmail script then emails the compromised account information to the attacker.      Without the open formmailer, the attacker would have to hack into a legitimate web site instead.    Get rid of open formmailers you get rid of (most) phisher’s who can’t hack.

Of the approximately 100 open formmailers we detected being used for phishing, the following are the top 10 worst offenders.

1. http://cgi.mywebserv.com/cgi-bin/formmail.pl
2. http://homepage.eircom.net/cgi-bin/auto_mail.cgi
3. http://www.hotspace.com.au/ccgi/mailform.asp
4. http://www.infonet.com.br/cgi-bin/mailto/comments.exe/msg.txt
5. http://iceworm.com/temp/form.php
6. http://www.necasa.org.uk/cgi-bin/mailform.pl
7. http://www.iolfree.ie/cgi-bin/responder
8. http://home.ism.com.br/cgi-bin/scripts/mail_form.pl
9. http://www.boomsoft.com.pl/images/wmail.php
10. http://www.magnet.pl/cgi-bin/mailform.cgi

We hope that the responsible parties will restrict access to these scripts or remove them.    Also, it would be great if web content filtering companies would also block access to them.   It would certainly prevent some phishing victims.

In case you haven’t heard the details yet, there’s a vulnerability in Adobe Acrobat Reader that allows attackers to execute arbitrary code.    In real world exploits, the attackers use Acrobat javascript to fill memory with their code which when executed downloads and installs malicious files to the victim’s system.    Sourcefire has revealed a suprisingly amount of detail about the vulnerability on their blog.

I say the amount of deal is surprising because very little information has come out about how to mitigate this attack.    As a former IT security guy, this is extremely frustrating.    Even in Adobe’s security advisory about the incident, they only information one is left with is to watch until March 11th for a patch.    If you’re responsible for protecting users, there’s not much to do but hope your AntiVirus and other security products catch the attack.

While the attacks seen leverage Acrobat javascript, it’s important to note that in this particular case the actual vulnerability is not in javascript.    However, because javascript is being used in real-world attacks and there have been other javascript vulnerabilities in Acrobat Reader, it makes sense to completely disable it.    But what to do if you need to disable it across hundreds or thousands of machines?

PhishLabs spent some investigating which registry keys hold the javascript settings of Acrobat and found that the magic key is:

HKCU\Software\Adobe\Acrobat Reader\9.0\JSPrefs\bEnableJS

Set this to 0×0 or 0×1 to disable or enable it respectively.

We’ve put together a simple batch file which automates this for you.   Click here to down it.

Note that it has only been tested on Adobe Acrobat Reader 9.0.0 Standard US on Windows XP SP3.   Use at your own risk.

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

<?
if(!function_exists(“http_build_query”))
{
 function http_build_query($a) {
  $p=”";
  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);
  curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, FALSE);
  $page = curl_exec($ch);
  curl_close($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.

First a little bit about us.  PhishLabs was founded by John LaCour in September 2008.  Our vision is to do more to stop cybercrime than the status quo model of detecting, counting, categorizing, and (sometimes) reporting attacks.   The media is full of stories with interesting statistics about the number of cyber attacks going up ‘X’ percent with attacks mostly coming from certain countries.    Vendors and even free Internet community groups report cybercrime to ISPs who shutdown attacks just to have another one replace it.  Measuring the number of attacks and stopping them is better than ignoring them, but ultimately does almost nothing to stop cybercrime from reoccurring.

PhishLabs aims to change that by providing our clients with information about the identity of cyber-criminals, how they operate, why and when their scams are successful, thereby  providing actionable intelligence for the affected organization, and if desired, law enforcement. This is accomplished by going much deeper than detecting and shutting down individual attacks.

While we take on a variety of initiatives, our focus is within three main areas:

Advisory Services:
We help clients review their anti-fraud programs within the context of their peer group and industry leading best practices.   Where appropriate we drive the implementation of program improvements (both technical and non-technical) to reduce or eliminate online fraud.

Intelligence:
We investigate specific criminal groups, actors, and fraud methods and provide recommendations to reduce or eliminate their impact.  We also work with law enforcement and related groups like the NCFTA to provide information they can use to ultimately arrest and prosecute cyber criminals.

Incident Response:
While there are often day-to-day attacks which can be managed with in-house expertise or security operations vendors, responses to new types of attacks or dramatic changes in attack volume may require some outside help.    Whether it is a rock-phish attack or a new type of malware, PhishLabs helps clients by rapidly assessing complex attacks and rapidly developing and implementing a cost-effective plan of action.

In addition to helping our clients with the services outlined above, we strongly believe in sharing with the security community.   In the coming days and weeks, please check back with this blog to find information about hacker techniques and tools, pointers to academic research of to fighting cybercrime, as well as advice on the steps you can take to protect your organization and customers from online fraud.    Of course we’ll also be sure to keep you updated on the latest developments at PhishLabs.

Thanks for reading and please keep in touch.

John LaCour, CISSP
President, PhishLabs
jal@phishlabs.com