PHP Shells

July 16, 2012, by | Start Discussion

Hi boyz’n’girls.

This is my first appearance on ClubHack, hope not the last. 😀

Anyway straight to the point.

I will talk about “PHP shells”.

PHP shells are used by Blackhats to maintain persistence into a compromised machine, typically a webserver.

A “shell” is the common name given to a Command Line Interface (CLI) used to interact with the Operating System, even at low level. The usage requires the knowledge of a discrete set of commands that are often different among different Operating Systems (e.g. Unix/DOS).

After a successful breach into a vulnerable system, the attacker could adopt a “Shell” as a payload in order to taking control of the victim system.

Nowadays these shells, derived from the DOS Shells of the nineties, are generally easier to use, with a “friendly” interface and, they require low “skill” to control the target system.

Few words on .php

The PHP was developed in 1994, in a very embryonic stage compared to the actual language, as a scripting language for pages available through web servers; it also can be used directly from the CLI.

The PHP shell

A PHP Shell is a shell wrapped in a PHP script to execute arbitrary commands or browse the file system on a remote webserver.

It could replace a telnet connection, and to a lesser degree a SSH connection.

The main advantage is to simplify the management and administration of the compromised machine.

In other words, PHP shells are PHP scripts that allow the attacker to execute a number of commands on a remote server through a simple web-based interface.

Figure 1 – Example of a PHP Shell: C9

They are used by Blackhats to easily manage the compromised server, install new tools, attack other sites, etc.

During the last decade a large number of shells have been developed to fulfill this task, the following is a non-exhaustive list of names:

  • Ajan
  • c99
  • casus15
  • cmd
  • CyberEye
  • CyberSpy5
  • EFSO_2
  • elmaliseker
  • iMHaPFtp
  • indexer
  • klasvayv
  • ntdaddy
  • phpinj
  • phpshell
  • phvayv
  • r57shell

Many of these shells have multiple versions, ranging from simple mods to the introduction of new features.

In terms of functionality, a basic set of commands includes:
–> File system management (listing of directories, changing the attributes of files),
–> File upload,
–> Command Execution.

More advanced features allow the attacker to connect to databases, install trojans, inject HTML text (e.g., iframes) into all the web pages on the server, or brute-force FTP credentials.

Some shells have the ability to check for updates and to self-remove from the remote server.
In conclusion, we can affirm that there are many PHP shell published and used by Blackhats each more evolved than the other.

Some samples implement encryption, for data transmission, and encoding to obfuscate the presence of malware on the compromised server.

Usually the shell injection is the result of exploited vulnerabilities in web applications, such as server configuration errors or the ftp account weakness.

Recently the proliferation of these shells has transformed the phenomenon in a real menace because their access could be sold or rent to large number of people looking to perform malicious activities.

Figure 2 – r57 shell example

One of the most used attack vectors is the Remote File Inclusion (RFI).

The RFI is an attack technique used to exploit "dynamic file include" mechanisms in web applications.

When web applications take user input (URL, parameter value, etc.) and pass them into file include commands, the web application can be tricked into including remote files with malicious code.

Remote File Inclusion Attack Vector

Remote File Inclusion vulnerabilities are common in poorly written or poorly controlled code.

The presence and the exploitation of this vulnerability depend mainly on the configuration of web servers and from the specific parameter values register_globals and allow_url in the php.ini file.

RFI attacks are used to force the inclusion of a remotely (or even local) running code into the web server.

File inclusion is used for packaging common code into separate files that are lately referenced by main application modules. When a web application references an include file, the code in this file may be executed implicitly or explicitly by calling specific procedures. If the choice of module to load is based on elements from the HTTP request, the web application might be vulnerable to RFI.

A classic example may be found into a section of website page code that allows the choice of display language. Consider the following PHP code snippet:

if (isset( $_GET['LANG'] ) ) { $lang = $_GET['LANG'];}

else { $lang = 'en';}
include( $lang . '.php' );

****** caption:- Snippet 1 – PHP code defining the display language ****

The code that handles this mechanism occurs if a particular language is chosen through the $LANG parameter.

If it is true it assigns that value to the variable lang, otherwise it assigns the default EN (English) value.

After this, the code proceeds the execution by including the file related to the language using the include command.

The programmer who wrote this code did not expect much input as en or fr (or more) and decide that there is no need to "sanitize" the statement.

This implies that the programmer does not perform further checks on the parameter $LANG.

The attack goal is to exploit the missing check to the $LANG variable.

The exploitation permits, for example, to include another local file and obtain its execution from the Server, with the subsequent access to it.

For example (please refers to fig.2) the file includes may be the PHP Shell.

Consider the following URL:

In this case the included file name will resolve to:

Thus, the remote file will be included and any code in it will be run by the server.

PHP is particularly vulnerable to RFI attacks due to the extensive use of "file includes" in PHP programming and due to default server configurations that increase susceptibility to an RFI attack.

Figure 3 – Remote File Inclusion Attack scheme

A Shell example: MadSpot Shell

In order to explain the topic I will introduce a recently coded PHP Shell.
This shell is called “MadspotShell”, it takes the name from The MadSpot
Team, a Crew involved in its development.

The version of MadSpot Shell (v.1.0) is composed of a single PHP page:
•    madspotshell.php

The package, which can be found on their site (, once extracted, is composed of the following elements:

Figure 4 – MadSpot Shell Package

I will not talk about the early stage of the attack that allows the installation of the Shell because it is trivial. Usually a good web scanner on a bulletproof server is all the blackhat needs in order to identify and exploit the victim.

Once the shell files are uploaded, the attacker can navigate to the relative URL to check whether the file is present. In our case I’ve taken these screenshot from my lab on a LAMP Linux box at:

Figure 5 – PHP Home shell

This is the home where we can see the list of files, and the menu with other options.

Below the list of file, we can see a small "Panel" (depicted in Figure 6) showing following details:

Figure 6 – MadSpot Shell details

This “Panel” is always visible to the user and the available functions are:

  • Mk File
  • Mk Dir
  • Delete
  • Ch Mod
  • Change Dir
  • Http Download
  • Execute

In the box "Mk File" you can enter the name of the file to be created. The option "Mk Dir", instead, creates a directory and the "Delete" function can delete a file.

"Ch Mod" command can be used to change files permissions.

Immediately below we see the box "Change Dir" through which we can change the directory.

Then there is "Execute" where we can enter text commands or load a file to being executed.

Finally, we find the "HTTP Download" box where we can enter a URL to download a file directly from a web address.

In the next tab "Process" we find everything related to the processes of the machine:

Figure 7 – Injected Webserver Processes

These are the sub-menu that we find in this section:

  • Process status
  • Syslog
  • Resolv
  • Hosts
  • Passwd
  • Cpuinfo
  • Version
  • Sbin
  • Interrupts
  • lsattr
  • Uptime
  • Fstab
  • HDD Space

There are many options to "Process Status" where we can see the details about active processes, "Syslog" for system logs and other options on the machine and its processes.

In the tab "Eval" we find three options:

  • PHP Info
  • Extension

In "INI_INFO" we can find a "text box" where we can write code and then click on "Eval" button for execute. In "PhpInfo" there are all information about the PHP installation and configuration on the machine, including the extensions and their details. However clicking on the button "extensions", we can see the list of extensions without the details.

Going forward, the next tab is "SQL":

Figure 8 – SQL Tab

With this function, the attacker can configure a connection to a database.

This is useful for a Blackhat in order to track server accesses and other tricks.

Continuing with the pages, we found "HASH", where encoding options are available (Figure 9):

Figure 9 – HASH function

The next tab is "Connect" (Figure 10), here it is possible set the parameters for a backdoor, in PERL or PHP, choosing the IP address and PORT.

Figure 10 – Connect Tab

In the "ZONE-H" section (Figure 11), we found a "notifier", useful to announce the defacement of the site that the attacker has corrupted.

Figure 11 – Zone-H notifier

Continuing our browsing in MadSpot Shell tabs we can find the "DDOS" tab (Figure 12), where the attacker can launch a DDoS attack by entering parameters such as, host, time, and the door.

Figure 12 – DDoS Tab

This tool creates a socket toward the Host selected into the box and, for the given period of time, it sends a large number of UDP Packets filled with the “X” character to it. The number ranges from 1 to 65000.

By considering the packet fragmentation (potentially inside a variable MTU network path) the number of data unit transmitted during the given time frame could reach high values.

The source code of this part of the shell is shown in Figure 13.

Figure 13 – DDoS function code

The result of this action is flooding a large number of UDP fragmented packets:

Figure 14 – UDP Flood generated by fragmented packet streams

In this picture you can see the content of a single datagram:

Figure 15 – UDP packet Payload

Despite there are even more feature-richest shells the MadSpot is a good example of what can be done once the shell is on the webserver. Think about it next time you leave an easy to guess root password on your Apache…

Mitigation against PHP Shells

The main cause of PHP infections are three:

  1. Badly coded Web applications, subject to SQL injection and remote file inclusion,
  2. Weak passwords scheme for Web Services maintenance
  3. Poor security measures on FTP Server side.

The highest rates of compromise are due to weak password protected FTP accounts. Automated attacks are often able to undercut access FTP taking control of the web space first and then the entire server.
If the machine does not implement security measures, the platform could easily fall prey of automated or semi-automated scanner.

Typically, shells are found in standalone files.

The best way to remove the shell is to delete the file from the server.

If the code is found inside an existing file, replacing the file with an original copy that is known to be clean could be enough. In case you do not have an original copy, you may try cleaning the code although this leaves chances for hidden code not being removed.

You should also search for any references to the shell files within other files.

They may contain include statements or additional malicious code. Those files should be cleaned or deleted.

A common technique to spot shells is to find for some known filenames. The downside of this approach is that there are so many filenames that is quite impossible to enlist them all. Moreover PHP Shells may be found with random filenames or names that look similar to legitimate files.

In addition, PHP shells usually try to hide themselves using random combinations of base64_encode, gzdeflate, etc.

You’re going to get plenty of false positives using this method, by using common sense and this simple command line it’s possible to weed out most popular exploits which are either standalone files or embedded into existing files.

Replace the path below with the absolute path of the directory you want to recursively scan. For example, you could recursively scan from the working directory:

grep "((eval.*(base64_decode|gzinflate))|r57|c99|sh(3(ll|11)))" . -roE --include=*.php*

********** caption:- Snippet 2 ***********

Scan all public-facing web folders on a cPanel box:

/home/*/public_html/ -roE --include=*.php*

********** caption:- Snippet 2 ***********

To summarize, some suggestions in order to mitigate these attacks from happening into your server would be:

  • Lock down directory security in IIS and Apache.
  • Don’t allow for 777 permissions to directories,
  • Make sure the 3rd party web apps are up to date and running with least privileges needed.

The web-based applications are gradually gaining more and more importance and their growing complexity and dynamism provides an wide "attack surface" to attackers.

It is essential to consider the exposure offered by low quality web code and bad administration of public platform.

There are many other things to look at when securing a Web application, but the above certainly are the basics and must be considered when preparing a web application for the big internet.

Author bio not avialable

Leave a Reply