Most likely the phisher is attempting to circumvent additional security measures by the bank such as telephone based authentication systems or they may be attempting change the customers account information via a call center.     For most banks, you would need additional information that online banking credentials for such an attack to be successful.

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/

It is not clear if the intention of the responsible miscreants is to steal photos, email credentials, or Facebook credentials.    It is probably the latter given the phishing site redirects to Facebook after stealing an email address and password.   However, it does seem clear that with Facebook’s announced acquisition of Instagram all over the news lately and the rise in popularity of the photo sharing service, attackers have found a new brand to abuse.

But it is important to note there is nothing really special about Instagram to cyber-thieves.    This incident is part of a trend of attackers using the brand name of any well known company as part of the lure.    Many other companies that do not even have a consumer online presence have been used in phishing lures in recent months.    Examples include real estate agencies and fast food chains.

In the future, we anticipate that virtually all well known brands will be used in phishing campaigns for no other reason than to leverage the trust in the brand to trick the user into divulging credentials or infecting themselves with malware.

As always, Heads-Up: Stop, Think, Click (or don’t!).

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.

• eitaepiephohthieleibesha.com
• llakjshbeyrv3421jbs88xc.com
• nmbnxcbjbh3hbhbdhjb3l4kjbn.com
• nzytgero34xbhsbc8484kk.com

PhishLabs registered the domains and then pointed them to a server under our control and began logging requests.    We analyzed the data and learned a number of interesting things.

This particular Zeus Trojan had infected approximately 270,000 systems.    This is based upon the number of unique IP addresses and is only a rough approximately since IP addresses may change when using home broadband connections and in some cases multiple systems may be behind the same IP address such is the case with a corporate gateway and some ISPs.

There was a broad geographic distribution of infected users.    We were not able to determine the original infection source, but given the geographic distribution we suspect it was not a targeted email campaign, but used drive-by exploits or similar to infect any system that could be.

PhishLabs has reported the IP addresses of infected systems to our clients and have now redirected these domains to our friends at Shadow Server who are helping get the data out to the right service providers.

Xfire “is a free tool that automatically keeps track of when and where gamers are playing PC games online and lets their friends join them easily.”   PhishLabs recently discovered a phishing page targeting Xfire users that used a clever trick to warn potential victims.

By using cascading style sheets (.css) files that are generated on the fly, users visiting the phishing page are, you could say, “Hoff-rolled”, into viewing some pictures of the former Baywatch and Knight Rider star.    Not only are they shown the banner above warning them of the phishing site, but they also have the following image set as their browser background:

If this does not make you turn away from a phishing site, what will?

Original phishing page here:

hXXp://www.xfirevideo1.blogcu.com/www.metin2xfire.somee.com

Warning it has not been checked for browser exploits or other malware attacks.

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.

These criminals continue to distribute their ZeuS trojans and steal funds from banking accounts.   They have resorted to the old tactic of attaching the malware file directly to the email.

Recent scam emails have targeted Verizon Wireless and Vodafone with emails claiming that “Your credit balance is over its limit”.    Today’s scam announces that “your mailbox has been deactivated” (despite sending you a message to your mailbox!).

Malicious email with attachment

In all three cases, the emails contain a .zip file which contains a Zeus banking trojan.    Currently, this trojan is detected by 22 of 41 antivirus products according to VirusTotal.   The malware also “phones home” to the same servers previously seen in Rock phish zeus malware.   Details in this ThreatExpert report.

Let’s clear it up once and for all.

There are actually 3 distinct but related types of malware being used to commit various scams by one or more criminal groups.

Cutwail aka PushDo is a spamming trojan being used to send out massive amounts of spam with links (or lures) to phishing pages or pages that ask the users to download and run programs.    Those programs invariably turn out to be instances of the Zeus/ZBot/WNSPOEM banking Trojan.    There are also unrelated criminals that also use Zeus Trojans to steal online banking information that are not related to this set of scams.    The Avalanche botnet is the middle-step between the spamming botnet and Trojans that steal banking information.    It is basically a hosting platform used by the attackers.    Because the Avalanche bots act as a simple proxy, and there are thousands of them, it has been exceedingly difficult to shutdown the phish pages.   Instead most Anti-Phishing organizations have focused on shutting down the domain names that were used in the phishing URLs.

PhishLabs recently presented new information about the Avalanche botnet at the recent Anti-Phishing Working Group (APWG) fall conference.   We were able to acquire a copy of the bot software and analyze it.    What we learned is that the malware is actually rather simple.    It listens on TCP port 80 for incoming connections and simply relays data receives to another server that hosts the actual phishing pages and malware files.

In an effort to help service providers and others clean-up Avalanche infected machines, here are the key details:

Removing the Avalanche bot components is as simple as deleting the two files and one registry key.

PhishLabs has also been able to determine the IP addresses for a large number of the infected systems.  Service Providers are invited to contact us at info -at- phishlabs.com for a list.     We have also shared this information with our friends at ShadowServer who are helping report infected systems as well.

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.

Interestingly, one such free phish kit distribution site added flag counter which shows exactly where site visitors are coming from.    By a huge margin, the number one source is Morocco.

The Notorious Mr. Brain and crew hail from this region of the world and seem to have adopted phishing as a full-time hobby.    After rock phish, these folks are responsible directly or indirectly for most of the phishing out there.

After Morocco, Nigeria is next on the list.    Nigeria is not just responsible for advance fee fraud (aka 419 scams), but these a lot of phishers hail from West Africa as well.

Rounding out the top 10:

1. Morocco
2. Nigeria
3. Egypt
4. United States
5. Indonesia
6. United Kingdom
7. Algeria
8. Serbia
9. France
10. Unknown – Satellite Provider (probably West Africa)

I encourage anyone who is interested in understanding how phishing really works to read the paper, but here are a few of the key take-aways:

• Over 75% of phishing sites are hosted on hacked web sites
• Despite legend to the contrary, there is no data to support the notion that phishers use phish URL blacklists (like PhishTank) to find vulnerable web sites
• About 9% of phishing web sites are hacked again and another phish added within 4 weeks

Also see Dr. Clayton’s blog posting on Light Blue Touch Paper for more.

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.

There are various kinds of tools that phishers use to faciliate building an email list.    Recently PhishLabs discovered a Spanish language tool called the “EVIL Code” email extracter.

It is a straight forward HTML page with a PHP backend.   It allows the user to specify keywords to search for, select one of several search engines, and also select the country (actually language) which will be specified as part of the search engine query.    To get around the potential lack of system access to run wget or another utility to fetch the web search results, the PHP programs open a socket directly to the search engine web server.   However, the PHP program does require write access to the local directory to save the results.

 Just in case you don’t have access to a web site to host your PHP email extractor, there are commercial software programs that run on Windows to do that job.   One one phishing kit site, in addition to free kits you’ll find a version of the Tarantula email extraction software for Windows.   Normally this is commercial software that requires a license, but Dr. Jad or Jihad-One was also kind enough to provide a crack that removes the licensing requirement.

Like the PHP extractor, this software allows you to select search engines to use and query terms, but it lacks country/language support.    However, it has some nice status indicators that show you a total number of results returned, URLs spidered, elapsed time, etc.

In our tests of these tools, both performed similarly.   On average they return about one email address per page spider and roughly 100 email address per minute.

We’ll be sharing these tools with our friends at the major search engines so that they might limit the ability of phishers to harvest email addresses.    Obviously, the best advice we can give is not to publish your email address any where where it could eventually end up being indexed in a search engine.

Why do the bad guys do it this way?   Generally, because they’re using free web hosting to install phishing HTML pages, but the free hosting services does not support any server-side scripting like PHP (or .NET, CGI, etc.).     All the phishers have to do is upload the HTML files and point them towards some other web site’s  poorly configured formmail script.   Voila!   Insta-spoof!

So how often do phishers actually use a formmail script?   PhishLabs set out to find out by reviewing the HTML source code of over 33,000 phish in our archives over the last 4 months.  It turns out that after ignoring botnet hosted (e.g. fast-flux) phishing sites, that formmail phish represent roughly 4% of attacks.

Unfortunately, the biggest facilitators are not “mom-and-pop” web sites but in some instances well known companies.   One of the world’s largest domain registrars has an ecommerce subsidiary that has an open formmailer program that is responsible for helping at least 200 phishers over the last few months.  ISPs, web hosters, and universities are also complicit in helping phishers.

By “back of the napkin” estimates, if each phish attack costs banks (and consumers) $1000, then ill-configured formmail programs are costing us all roughly $3 million per year.    Dear web developers – if you’re going to use a formmail script, check referrers (even though they can be spoofed) and hard code the destination email address in the back-end script rather than allow it to passed by the web client.

The silver lining in this is that the phishers’ email addresses are usually exposed in the HTML of the phishing site when they use this tactic.   PhishLabs has turned over a list of 513 email addresses to ISP and law enforcement cyber-crime investigators.

Recently, cybercriminals sent out the following email scam to tempt users in to installing malware on their systems:

CAIXA Brasil Scam Email

 

 

 

 

 

 

 

 

The text says essentially that they’re doing upgrade on their servers and users need to install the update at the link to maintain their Internet Access.

While the URL looks like it’s point to a government site in Brasil, it is actually pointing to a server in France and leads to a malicious software program name “sistema.exe” (MD5=2ce0b316d8ada0c52a6a154ba7a1b3ff).    Currently 16 of 38 AntiVirus vendor’s detect this program according to Virus Total.

 

This attack uses tactics not commonly seen.   The malware does not intercept or alter communication with a legitimate web site, nor does it redirect the user to a phishing site.   Instead it prompts the user through a series of screens directly:

CAIXA Attack - First Screen

CAIXA Attack - Second Screen

There are several more screens prompting users for account information, personal information, passwords and PINs.   Upon submitting the information, the malware application the sends the stolen information out to a couple of email addresses.

Since I received several comments and questions from vendors after the first round of testing, I decided to do a follow-up test with the same files to see if anything has changed.   With one exception, not much has changed.   Big kudos go out to the Fortinet Team that moved from detecting only 17% of these backdoors to 98%.   Unfortunately, they were the only vendor of the 24 tested to move into one of the top 10 spots.

Here are the entire updated results for all 24 vendors (note some companies use a scan engine from others – hence the duplicate results):

As I mentioned in my previous posting, not all of these vendors develop antivirus products that are designed for server environments and therefore it may be appropriate for them not to detect these files in some cases.    That said, certainly web gateway products should prevent these backdoors from being installed via RFI attacks which is one of the more common methods used by phishers to install them.   Another common tactic of phishers is to use web applications meant to allow users to upload photos or avatars.   Far too often, these applications fail to check that the image file is actually an image or in other words fail the fundamental tenet of application security: don’t trust user input.  Gateway antivirus products can help with both cases and should detect these malicious programs.    Another class of antivirus product that should detect these files are those that can be configured to run “headless” or only on-demand.    It’s not unusual for webhosting companies and system administrators to scan web servers that they suspect to have been compromised for malicious files.    If products that support on-demand scanning would do a better job of detecting these files, they could help prevent phishing and other types of cybercrime.

Just in case you’re thinking that these PHP shells and backdoors are only used on Linux systems, don’t forget that PHP does in fact run on Windows.   Many of these malicious programs have functionality to detect whether they are running on a Linux system or Windows system and adjust appropriately.   Also, there do exist .NET backdoors as well.    They are relatively rare compared to the wide variety of PHP shells, but they are out there and in the wild too.    To see if the antivirus products had a PHP or .NET bias, I decided to test 7 .NET backdoors against the suite of 24 antivirus products as well.    It’s hard to draw any conclusions about bias, but clearly these programs are not well detected.   While most products detected at least one file, only 4 products detected at least 3 of the 7 files: BitDefender, ClamAV, Ikarus, and SecureWeb.

While I’ll continue my quest to have security products better detect malicious programs used by phishers, the next project will focus on the vulnerabilities exploited to gain access to web servers for phishing.    I’ll be working with my colleagues at the AntiPhishing Working Group on this project and look forward to publishing the results from our study next year some time.

13 UK Banks Phished in 1

A few months ago we noticed a single phish kit being used which targeted 13 UK banks at once.    It included a web page that listed all of the banks and would-be victims were instructed to click the link that corresponded to their bank and complete the subsequent forms.

Now it seems that the attackers have created an Indian version of their kit.  This new kit uses the ruse that the Central Bank of India requires that users update their accounts.   Three of the largest Indian banks are the targets: ICICI, Axis, and HDFC.  

3 Indian Phish in 1 Kit

The credits in the code for each phish are:

“Nameless” – ICICI Phish Kit

“Dr Spamer” – HDFC Phish Kit

“Darklyte” – Axis Phish Kit

However, all of the phish ‘drop’ stolen credentials to the same gmail address which has been reported to Google for shut down.

Whomever is behind the use of these kits, they sure are prolific.  It turns out the site where the 3-in-1 Indian phish were discovered also contains the 13-UK phish site as well as phish targeting Bank of America, America Online, Poste Italiane, a separate ICICI phish, and a separate HDFC phish.

 

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.

The most often uploaded malicious files are PHP shells.   A PHP shell is a PHP program which provides a hacker with access to the web server as well as many tools and features:

• Find, Edit, Rename, Download Files
• Point-and-click Directory and File Navigator
• Shell Command Execution
• PHP Statement Evaluation
• Find Vulnerable Files and Directories
• Upload / Download files from FTP Servers
• Dump MySQL Databases
• Create a proxy server
• Create a back-connect shell
• Encode / Decode Base64, URL escape encoding, etc.
• Show running processes, system name, kernel version, IP addresses, etc.
• Show PHP configuration (php.ini), safe-mode, register globals, etc.
• FTP brute-force password cracker
• Emailer (spammer)
• Self-update and self-remove

c99 shell

 The most common PHP shells are the C99 shell from the Captain Crunch Security Team and the r57 shell from the Rush Security Team / GHC.    However, some PHP shells are simple one-box forms used to enter a command which will be executed on the server.

Top 10 Detection Rates for PHP Backdoors

The results are a bit disheartening, but there are some caveats worth mentioning:  

Not all vendors have a Linux based product.    Almost always (but not quite), the compromised system which has a PHP shell installed on it is running a version of Linux.   So it’s perfectly reasonable not to detect files that generally are only used on an operating system on which your product doesn’t run.

Some anti-virus products are geared as gateway products and not file scanners.   That means, that some anti-virus products might detect the HTML generated by these backdoors, identify them as unwanted web applications, and block access to the PHP shell.   That’s easy enough to test, but wasn’t tested here.

Some of the PHP programs could be considered dual-use applications – used for evil or for good.   That argument is some what constrained by the fact that the tested files were all from compromised web sites and nearly all were made by hackers for hackers.

Another argument is that it’s more important to focus resources on catching desktop malware.   I disagree.  Server compromises often lead to more desktop malware, more end-user phishing, and more distribution of spam.   If every web site on the Internet were secure, almost all of the badness we see every day on the Internet would go away.

So how about it anti-virus vendors!   Time to start detecting PHP backdoors?

Today I started seeing reports of a PayPal phishing attack using using the URL (line wrapped for readability):

http://secure.paypal.com.session-

id99464376173882452045040350355179058532566734394749600500
117946024993835998207694.ssl89.ru

The only problem is that it’s impossible to resolve this hostname.   If you look carefully, you’ll see the label that starts ‘session-’ following by a bunch of numbers is 91 characters long.   That is longer than the maximum of 63 allowed by RFC 2181.

The phishers never notice this themselves because their nameservers have wild-card entries that allow any hostnames and sub-domains to resolve (assuming the query get to their servers).

The good and the bad thing about phishers are that most of them are not very sophisticated.   In most cases the phishers are not very technical and therefore do not have the skills to create a phishing kit.   Instead, they generally use free kits provided by other cyber criminals.   It’s the authors of the kits that are a bit more sophisticated and who ultimately drive a large portiion of the phishing sites that we see.

Earlier this year, Netcraft blogged about certain Mr. Brain phishing kits that contained backdoors.   These backdoors cause an email to be sent to the kit authors whenever a victim provides their information to a phishing site.   What has not been talked about much is how ‘Mr. Brain’ has continually updated his/their phishing kits and have been distributing them one site after another.   Lately, they’re being advertised in underground IRC forums:

IRC message advertising free phishing kits

At my last count, Mr. Brain kits have been distributed over at least 10 sites in the past year alone.

Mr. Brain is not alone in distributing free phishing kits though.    Others often use free webhosting at sites like by.ru, 100webspace.net, and others to host their scams.   While there are plenty of free and paid services to detect and shutdown phishing sites themselves, it seems like many of the phish kit distribution sites stay up for long periods of time.   For example, the following phish kit distribution site has been up for about 18 months now:

by.ru free phish kits

Because so many of the phishing sites we see are the result of ‘ankle-biters’ using free phish kits, going after the phish kits distribution sites themselves can have a positive impact.    Barring a significant increase in arrests, we can’t make phishing go away, but if we aggressively go after these bottom feeders will be able to see who the real bad guys are and get rid of the noise.   One way to do that is stop allowing free tools like phish kits to be so easy to find.

In his post, Antonio discusses the merits and pitfalls of diluting phishing sites with different types of bogus data. The last case, where phishers automatically validate the data from within the phishing site itself is especially interesting because it can be used against the phishers in a variety of ways. In the underground, the phishers call these phishing kits ‘true-logins’. Typically, they use ‘curl’ to post the data received from a would-be victim to the legitimate site and verify that it actually works. Here’s a snippet of PHP code from an actual phish kit.

How can we use the phishing kit behavior against the phishers? There are a few ways:

In this example, the User-Agent is set to “Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4″. That may be a perfectly legitimate User-Agent that is seen often, but there shouldn’t be multiple users from the same IP address with the same User-Agent attempting to login within a short period of each other.

Ok. This is hard, but it does represent an opportunity to spot and find phishing sites as well as bogus transactions. In the particular phishing kit with the above sample, the PHP code progresses through the following list of URLs:

https://www.bank.com/index.jsp

https://sitekey.bank.com/sas/signon.do

https://sitekey.bank.com/sas/signon.do?&detect=0

https://sitekey.bank.com/sas/challengeQandA.do

https://sitekey.bank.com/sas/verifyImage.do

Though the code isn’t shown for space reasons, looking through it, there are some obvious things that are wrong. The phish kit doesn’t fetch images like a browser does, it doesn’t run javascript, in some cases it doesn’t send a Referer: header. These are all big red flags that something is phishy!

The bottom line is that by performing some detailed analysis of your legitimate site’s web server logs, you can leverage the behavior of true-logins kits against the phishers to rapidly find their sites and fraudulent transactions.

If you’re a security researcher or bank and want some ‘true logins’ kits to take a look at, drop me a line and I’ll send some your way.

-John
jal@phishlabs.com

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