Note: This is the first post in a series of in-depth investigations into threats that have been detected by the CodeGuardMalwareGone tool. In each post, we will pick a specific kind of malware, trojan, virus, backdoor, rootkit, etc. to dissect and discuss. We will also provide manual removal instructions at the end, just in case you’re not yet usingCodeGuard.
For this inaugural post, we will be looking at a modified version of the WSO FilesMan backdoor, which is a php webshell designed to control the whole system. Here is just a piece of the PHP file that was named prbnts.php and located in the /wp-includes/js/jquery/ui/ folder, which usually only holds javascript files (.js):
<?phpeval(gzinflate(base64_decode("5b37W9tG0zD8c+7r6v8gVLeyG2NsQ9IUsBNCICEHSDkkaSCv
(...)
?>
As you can see, the file is encoded in base64 and compressed with the PHP core gzdeflate function . When we decode and decompress the file we get something more readable:
$color = "#df5";$default_action = 'FilesMan';
$default_use_ajax = true;
$default_charset = 'windows-1251';
if(!empty($_SERVER['HTTP_USER_AGENT'])) {
$userAgents = array("nouseragenthere");
if(preg_match('/' . implode('|', $userAgents) . '/i', $_SERVER['HTTP_USER_AGENT'])) {
header('HTTP/1.0 404 Not Found');
exit;
}
}
This gives us some clues that file is malicious and shouldn’t be there. Even if you aren’t tech savvy, just searching for the first four lines on Google will show you some hints that this file is a backdoor and the first findings date back to the end of 2010. More specifically, the malicious file is a PHP Web Shell, or just PHP Shell, which is a shell wrapped in a PHP script and it uses built-in PHP functions to execute commands on the system. With it, we can do basically anything on the server where it is located like upload or download files, install, run or delete programs and sometimes even create or delete users, depending on the web server’s user permissions. It is a bit similar to having an SSH (Secure SHell) connection to the server. Can you imagine the damage this could do? If you have your web shell on a server you literally “own” it. Now you know why people say someone got owned when their site gets hacked!
Here are some functions used to execute commands in PHP:
system() Execute an external program and display the output exec() Execute an external program shell_exec() Execute command via shell and return the complete output as a string passthru() Execute an external program and display raw outputYou may be asking why would someone want to put a webshell and control my server? That is a great question! An attacker might need your server for many different reasons. First and foremost, a web shell is a backdoor. It gives them direct access to your server without having to exploit a vulnerability over and over, so it gives them a persistent way to access the server (unless you find and remove the file). Another reason would be to use your server as a zombie in a botnet, and make it execute attacks along with other infected machines. Some attackers also use infected machines to hide themselves from the police by pivoting their connection through these servers and making it harder for the law enforcement to investigate and detect the source of the attacks.
This brings us the question that any CodeGuard customer would ask themselves why was my website hacked? How did it get infected? Well, just like viruses, web malware has variations as well. Malware developers might change a thing or two to avoid detection from pattern based tools. In this particular case, our client had the WordPress version 4.4.2 which is 7 months old already and might be one of the causes of the infection. But let’s dig deeper before jumping to conclusions.
Looking to find the source of the hack on WordPress websites, we usually look first at the themes and plugins folders since those are the most common way to exploit a vulnerability and place a web shell or some other kind of malware. The WordPress development team has done a great job at hardening the WordPress core (which includes wp-admin and wp-includes folders, and root files), but themes and plugins are mostly third-party code.
The contents of /wp-content/themes
As we can see the themes folder has only default WordPress themes. The first thing we recommend is removing anything from the website that you are not using. In any event, if someone finds a vulnerability in a plugin or theme that you have on your website but aren’t using it, they might still be able to exploit the vulnerability and compromise your site. Removing unused themes and plugins reduces the attack surface a malicious user has on your website.
The contents of /wp-content/plugins
Now, the plugins folder has something that caught our attention: the jetpack plugin. This plugin is made by the WordPress.com team and it is widely used on many WordPress websites. It is well maintained and updated very often by their development team. The problem is that Jetpack has multiple public vulnerabilities as we can see at wpvulndb.com :
Can you guess what version of the Jetpack plugin was on the website? Congratulations if you guessed version 2.5.2 (released on September 2013). While it is hard to detect the exact flaw a hacker was able to exploit on your website without going through all the logs (if you have access to them), I’m pretty sure this three-year-old version of the plugin was probably the cause of the compromise.
What could you do if your site is infected? Well, if you’d like to check if your website might have one of these malicious files you can do this:
Sign into your server using SSH (Secure Shell) Go to your WordPress folder Run this command: “grep -r eval(gzinflate(base64_decode *” If any of the results have a long encoded string after this code, then you’re probably infected.If you already infected, but don’t have access to your server via SSH or don’t know how to that, you can start by doing this:
Download the same version of WordPress you use on your site via worpress.org Remove the wp-admin and wp-includes folder from your site (either using SSH or SFTP/S) Extract the zip file and upload only the new wp-admin and wp-includes folders to your website (Don’t just replace the folders as it may have new files in there, and they won’t be removed!) If that didn’t fix your site at least now you have narrowed the problem down to the wp-content folder and can start looking for suspicious files. Check your plugins and themes folder. Remove anything that you are not currently using on your site. Most FTP clients have search mechanisms that you can use to look for strings like “base64_decode”.If you have any questions or comments please don’t hesitate tocontact us!
Re
