The Power of Web Shells

Published: 2016-07-13
Last Updated: 2016-07-14 06:04:06 UTC
by Xavier Mertens (Version: 1)
8 comment(s)

[Warning: this diary contains many pictures and may take some time to load on slow links]

Web shells are not new in the threats landscape. A web shell is a script (written in PHP, ASL, Perl, ... - depending on the available environment) that can be uploaded to a web server to enable remote administration. If web shells are usually installed for good purposes, many of them are installed on compromised servers. Once in place, the web shell will allow a complete takeover of the victim's server but it can also be used to pivot and attack internal systems.

In a recent investigation, I found on a shared platform a compromised website that was delivering phishing pages. I was able to get access to the archive containing the phishing kit but also a web shell. It was also installed on the server and the location was easy to guess. The web shell is presenting itself as "RC-SHELL" and is not a brand new one (I found reference to it in 2013) but it has a very low detection rate in VT (4/55) and was uploaded for the first time a few hours before me. Maybe it has been improved or updated?

Modern web shells are very powerful and offer plenty of features to the attacker. Because some pictures are worth a thousand words, I decided to make a tour of the interface to give you more details about modern web shells and to show their power. This web shell is written in PHP and, as usual, access to the web interface is restricted via hardcoded credentials. The login / password hashes are in the source code. A quick search in rainbow tables returned "test" for the login and password!? This time, it was even easier: the access was open (the authentication was disabled in the code). Note that the source code also contained the e-mail address of the owner.

When you access the URL, here is the default screen:

On top of the screen, you can see details about the host and basic PHP settings like the "safe-mode" status, available databases support. Then, the single-line menu to access all the features. Let's review them.

The menu "Files" gives access to a file manager that can be used to browse the local file system (with the web user UID restrictions) and perform actions on files (copy, delete, rename, move, etc):

The menu "Search" performs file search operations (think about the "find" Linux command) but you can also search for specific contain inside files (like "grep"):

The "Upload" menu transfers files on the local file system. Files can be uploaded from the local drive (on the attacker's computer) or fetched from a remote location (using common protocols like HTTP, FTP):

The "Cmd" menu executes shell commands on the target (this is really the core feature of a web shell). Commands are executed (with the web server UID rights) and output is returned in the browser: 

The "Eval" menu offers the same features as "Cmd" but executes native PHP code. This is a "PHP Shell":

The "FTP" menu gives access to a powerful FTP client like WinSCP or any other graphical tool:

The "SQL" menu provides tools like PHPMysqlAdmin. It allows to interact with SQL servers:

The "Mailers" menu, as the name suggests, is a tool to send spam. Simple emails can be send but also campaigns based on a CSV file:

The "Calc" menu is a toolbox which provides tools like hash calculators, encoders, converters:

The "Tools" menu is my preferred one. It offers many tools to pivot internally and attack other resources: brute-force, code injection, shell binder, port-scanner, etc:

Finally, the two last menus are used to manage processes on the box (à la "top") and to display system information about the host (CPU, memory, file systems, ...):

As you can see a modern web shell is a powerful tool. Keep in mind that a web shell will be executed with the rights and permissions of the web server (ex: "www-data" on a Linux system). To reduce the risks, apply best practices like:

  • Run the web server in a restricted environment (a VM, a Docker container, a chroot() jail).
  • Do NOT allow access to privileged access via commands like sudo.
  • Do NOT give full DBA access to your database, restrict access to required database/tables and allow required SQL commands only.
  • Implement egress filters and restrict communications with the outside world.
  • Protect your web server directories against write operations

Do not hesitate to share your stories about web shells. Did you find one, how, where?

Xavier Mertens (@xme)
ISC Handler - Freelance Security Consultant

Keywords: webshell
8 comment(s)


Thank you for this article, webshell evolution through time is really impressive.

In addition to conclusions, I would say that in PHP :

- A simple way to limit the file system access to the attacker is the PHP configuration 'open_basedir'.
Ex : open_basedir = "/var/www" will disallow access to any other directory to PHP.

- A common way to prevent from webshell is to prohibit some dangerous functions calls with 'disable_functions'.
Ex : disable_functions = exec, shell_exec, system, proc_open, passthru, popen,curl_exec, curl_multi_exec, show_source, eval, base64_decode , parse_ini_file

Both are set in php.ini file.

Interesting post. Agree, webshells are not new, yet very challenging to detect/find/hunt during the engagements.

Recently, we looked at commercial webshells observed in the wild and documented it:
as well as documented a small case study of a targeted attack that used webshells:

Hope this answers your question and give more insights to other folks in community.
Thanks for sharing the information! Nice read.
XME --- was that webshell multi-platform?
This one is written in PHP and targets UNIX servers.
Is the download address available?
[quote=comment#39141]Is the download address available?[/quote]

Such web shells are easy to find on!
ok,thank you!

Diary Archives