Analyzing Web Malware – 2016 Edition

This article was originally written in September 2016. Read with caution! =)

In this article, we will be looking at a modified version of the WSO FilesMan backdoor, which is a PHP webshell designed to control the whole compromised system. WSO stands for “Web Shell by Orb” and has the ability to masquerade as an error page containing a hidden login form. Here is just a piece of the code that was named prbnts.php and placed inside the /wp-includes/js/jquery/ui/ folder, which usually only holds JavaScript files (.js):

<?php
eval(gzinflate(base64_decode(“5b37W9tG0zD8c+7r6v8gVLeyG2NsQ9IUsBNCICEHSDkkaSCv
(…)
?>

As you can see, the file is encoded in base64 and compressed with the PHP core gzinflate function. When we decode and decompress it we get something in a more human-readable format:

$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 code gives us some clues that the file seems malicious and shouldn’t be there. Even if you aren’t tech-savvy, just searching for the first four lines online will already 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 that it uses built-in PHP functions to execute commands on the system. With it, we can do anything on the server where it is located like upload and download files, install, run or delete programs and sometimes even create or delete users, depending on the webserver user’s permissions. It is similar to having an SSH (Secure SHell) connection to the server.

Can you imagine the damage it can do? If you have your web shell on a server you literally “own” that server. Got it? Now you know why people say someone got owned when they were hacked. =)

Here are some of the functions used to execute system commands with PHP, according to the official documentation:

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

Well, and 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 again, so it gives them a persistent way to access the server (unless you find out about it and remove the file). Another reason would be to use your server as a zombie computer that is part of a botnet and force it to execute attacks along with other infected machines. Some attackers also use infected machines to hide from the police by pivoting their connection through these servers and making it harder for law enforcement to investigate and detect the source of the attacks.

This brings us to the question: Why was my website hacked? How did it get infected? Well, just like viruses, web malware has many different variations as well. Malware developers might change a thing or two to avoid detection from pattern-based tools. In this particular case, the victim was using the WordPress version 4.4.2 which was already 7 months old at the time of the attack and could very well 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 developed by other people or organizations that you don’t know and can’t trust. That’s why it is important to validate those before you start using in on your site! Application Security tools that do Software Composition Analysis (SCA) may be able to help with that task.

untitled3
The contents of /wp-content/themes

As we can see the themes folder has only a few default WordPress themes that come with the software installation. The first thing I’d recommend here is removing anything from the website that you are not using, including those themes. Why you may ask? Well, in an event that someone finds a vulnerability in a plugin or theme that you have on your website but are not using it at that time, they might still be able to exploit the vulnerability and compromise your site! Removing unused themes and plugins reduces the attack surface that a malicious user may have on your website.

untitled
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 WPScan:

Search results for “jetpack” on WPScan.com

Can you guess what version of the Jetpack plugin was on the website? Congratulations if you guessed version 2.5.2! It was released in September 2013. Three years before when this analysis was originally made! While it is hard to detect the specific flaw an attacker was able to exploit on the website without going through all the logs (if you have access to them) I’m confident this outdated version of the plugin was probably one of the causes of this 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:

  1. Sign in to your server using SSH (Secure Shell)
  2. Go to your WordPress folder
  3. Run this command: “grep -r eval(gzinflate(base64_decode *”
  4. If any of the results have a long encoded string after this code, then it is best to investigate it further.

If you are already infected, but don’t have access to your server via SSH or don’t know how to do that, and only have FTP access to it, you can do this:

  1. Download the same version of WordPress you use on your site via worpress.org
  2. Remove the wp-admin and wp-includes folders from your site (either using SSH or SFTP/S)
  3. Extract the zip file and upload only the new wp-admin and wp-includes folders to your website (Warning: Do not just replace the folders as it may have new files in there, and they won’t be removed! Remove the old ones before uploading the new folders )
  4. If that didn’t fix your site yet at least now you have narrowed the problem down to the wp-content folder and can start looking for suspicious files there. Check your plugins and themes folder. Remove anything that you are not currently using on your site. Make sure your plugins are up to date and don’t have any publicly known vulnerabilities.
  5. Most FTP clients have search mechanisms that you can use to search for strings such as “base64_decode”. Start with that!

Well, we hope this helps! If you have any other tips and tricks feel free to send them my way and I’ll update this article! There are some reference links below if you would like more information on protecting against webshells and learn how to do a proper hardening on your WordPress site.

Stay safe! #staysafe #wearamask

References:

https://www.us-cert.gov/ncas/alerts/TA15-314A

http://php.net/manual/en/book.exec.php

Tips on Hardening WordPress