Over a million developers have joined DZone.

Detection and Prevention: An Introduction to Web-Shells, Part 5

DZone's Guide to

Detection and Prevention: An Introduction to Web-Shells, Part 5

In this series, we've talked a lot about how hackers use web-shells. Today, we're going to go over how to prevent web-shells from infecting your system.

· Security Zone ·
Free Resource

Discover how to provide active runtime protection for your web applications from known and unknown vulnerabilities including Remote Code Execution Attacks.

In part 4 of this series, we looked at web shells in action by using Weevely as an example. In the final part of this series, we’ll be looking at web shell detection and how to prevent them.


If an administrator suspects that a web-shell is present on their system (or during a routine check), the following are some things to examine.

Firstly, the server access and error logs must be filtered for common keywords that are being used by web-shells. This includes filenames and/or parameter names. The example below looks for the string ‘file’ in URLs in Apache HTTP Server’s access log

root@secureserver:/var/www/html# cat /var/log/apache2/access.log | awk -F\" ' { print $1,$2 } ' | grep "file"

--> - - [30/Apr/2016:08:30:53 +0100] GET /demo/shell.php?file=/etc/passwd

The filesystem (usually the web server root) must be searched for common strings in files or filenames.

root@secureserver:/var/www/html/demo# grep -RPn "(passthru|exec|eval|shell_exec|assert|str_rot13|system|phpinfo|base64_decode|chmod|mkdir|fopen|fclose|readfile) *\("

--> Shell.php:8: eval($string);
eval.php:1:?php system($_SERVER['HTTP_USER_AGENT']); ?>
Ad.php:9: eval($string);

Search for very long strings which may indicate encoding. Some backdoors have thousands of lines of code.

root@secureserver:/var/www/html/demo# awk 'length($0)>100' *.php

--> eval(gzinflate(base64_decode('HJ3HkqNQEkU/ZzqCBd4t8V4YAQI2E3jvPV8/1Gw6orsVFLyXefMcFUL5EXf/yqceii7e8n9JvOYE9t8sT8cs//cfWUXldLpKsQ2LCH7EcnuYdrqeqDHEDz+4uJYWH3YLflGUnDJ40DjU/AL1miwEJPpBWlsAxTrgB46jRW/00XpggW00yDI/H1kD7UqxI/3qjQZ4vz7HLsfNVW1BeQKiVH2VTrXtoiaKYdkT4o/p1E8W/n5eVhagV7GanBn0U7OCfD7zPbCQyO0N/QGtstthqJBia5QJsR6xCgkHpBo1kQMlLt6u++SBvtw5KSMwtG4R2yctd0mBNrlB3QQo4aQKGRgRjTa0xYFw1vVM9ySOMd44sSrPe…

Search for modified files in the last X number of days. In the following example, we searched for *.php files changed within the last 24 hours, but it is recommended to search for any file changes as a web-shell can also be embedded into an image or any other file.

root@secureserver:/var/www/html/# find -name '*.php' -mtime -1 -ls

--> root@secureserver:/var/www/html/# find -name '*.php' -mtime -1 -ls
2885788 4 drwxrwxr-x 2 secuser secuser 4096 Apr 30 06:590 /demo/shell.php
2886629 4 -rw-rw-r-- 1 secuser secuser 260 Apr 29 11:25 /demo/b.php
2897510 4 -rw-r--r-- 1 root root 35 Apr 29 13:46 /demo/source.php
2883635 4 -rw-r--r-- 1 www-data www-data 1332 Apr 29 12:09 ./ma.php

Monitor your network for unusual network traffic and connections.

root@secureserver:/var/www/html/demo# netstat -nputw

--> Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 ESTABLISHED 2150/nc
tcp 0 0 ESTABLISHED 2001/sshd: secuser
tcp6 1 0 ::1:46672 ::1:631 CLOSE_WAIT 918/cups-browsed
tcp6 0 0 ESTABLISHED 1766/apache2
tcp6 1 0 ::1:46674 ::1:631 CLOSE_WAIT 918/cups-browsed

Analyze .htaccess files for modifications. The following are examples of changes an attacker might make to .htaccess files.

# The AddType directive maps the given filename extensions onto the specified content type
AddType application/x-httpd-php .htaccess
AddType application/x-httpd-php .jpg


The following is a non-exhaustive list of preventive measures to take in relation to web-shells.

  1. If not used, disable potentially dangerous PHP functions such as exec(), shell_exec(), passthru(), system(), show_source(), proc_open(), pcntl_exec(), eval() and assert()
  2. If it’s an absolute necessity to have those commands enabled, make sure that unauthorized users do not have access to these scripts. Additionally, use escapeshellarg() and escapeshellcmd() to ensure that user input can not be injected into shell commands, resulting in command execution vulnerabilities.
  3. If your web application is using upload forms, make sure they are secure and that they only allow whitelisted file types to be uploaded.
  4. Never trust user input.
  5. Do not blindly use code that you may find on online forums or websites.
  6. In the case of WordPress, try to avoid installing third-party plugins if you do not need them. If you need to make use of a plugin, ensure it is reputable and frequently updated.
  7. Disable PHP execution in sensitive directories, like images or uploads
  8. Lock-down your web server’s user permissions.

Final Remarks

As we have seen, coding and using a web-shell is not difficult. Unfortunately, many web servers are setup in such a way where even a simple script is enough to cause significant damage. This is the main reason as to why there are thousands of publicly available web-shells. The fact that so many variations exist, make it difficult for intrusion detection and intrusion prevention systems (IDS/IPS) to detect them; especially if they are using signatures to detect such web-shells. Some web-shells are very sophisticated and they are almost impossible to detect, even with behavioral analysis.

Having said this, early on in this article series, we had established that web-shells are post-exploitation tools. This means that the best way to prevent exploitation is to prevent them from being uploaded in the first place.

Find out how Waratek’s award-winning application security platform can improve the security of your new and legacy applications and platforms with no false positives, code changes or slowing your application.

security ,web-shells ,vulnerabilities ,php

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}