Web Shell Detection and Prevention (Web Shells Part 5)

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 their use.

---

Detection

If an administrator suspects that a web shell is present on their system or is just making 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 lets you search for the string file in URLs in the access log of the Apache HTTP Server.

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

--> 192.168.5.26 - - [30/Feb/2020: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 files that were modified in the recent X days. In the following example, we searched for *.php files changed within the last day but it is recommended to search for any file change 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 the 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 192.168.5.25:37040 192.168.5.26:8181 ESTABLISHED 2150/nc
tcp 0 0 192.168.5.25:22 192.168.5.1:52455 ESTABLISHED 2001/sshd: secuser
tcp6 1 0 ::1:46672 ::1:631 CLOSE_WAIT 918/cups-browsed
tcp6 0 0 192.168.5.25:80 192.168.5.26:39470 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 that 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

Prevention

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 that 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 web server user permissions.

Final Remarks

As we have seen, coding and using a web shell is not difficult. Unfortunately, many web servers are set up in such a way that 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 makes 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.

Since the Acunetix vulnerability scanner tests websites and web applications for thousands of vulnerabilities, including code execution and arbitrary file upload vulnerabilities, it can find entry points that could allow attackers to upload web shells.

Additionally, when using the AcuSensor technology, since a sensor is deployed inside the web application, the scanner can retrieve a list of files on the server back end, meaning that the scanner can detect web shells and other malicious scripts even if they are buried deep within directories.

---