Web servers have become one of the main targets for cyber-attacks. Virtually every server runs web applications that are deployed once and then forgotten. A lack of maintenance and updates then creates weak points which are vulnerable to attack. Our own analysis of commonly found CMS versions (Webseite gehackt? Selbst schuld!) shows that 73% (!) of deployed web applications feature publicly know security problems.
When such a vulnerability is identified by an attacker they often try to install a back-door by inserting additional code into the original application. This keeps their target accessible to them, even if the original security hole is closed. When referring to such code, the information security community coined the term “webshells”.
Neither Wikipedia nor Google searches provide comprehensive definitions of the term “webshell”. We are here to change this.
The term “webshell” obviously is a combination of “web” and “shell”.
The “shell” part can be understood as a Unix shell in the sense that the malware provides similar capabilities. It is often used to execute code or commands, list the content of directories or edit files. This really means that a webshell aims to give an attacker as many administrative capabilities as possible on an infected server.
The “web” parts means we are talking about malware that is targeting the web environment. Webshells are usually accessible through the web server of an infected machine using the HTTP protocol. They then either provide a graphical web interface of their own or acts as an endpoint for API requests from the attacker.
Let us sum this all up in a definition:
“Webshell” describes a group of malware that enables an attacker to remotely administer an infected host and is accessible through the host’s web server.
Since webshells are run by the web server of an infected host and because most web server provide the ability to run PHP most webshells are written in PHP. We also encountered webshells for ASP, ASP.NET, Perl, Python or Ruby, but these rare occurrences are dwarfed by the large variety of PHP based ones.
The definition above is intentionally vague about webshell capabilities. The provided function set differs greatly between different webshells and their different approaches. Nearly all webshells provide at least the ability to either run arbitrary commands on the host’s Unix shell or to run arbitrary code.
Some webshell consist of nothing more than the following PHP code:
eval ( $_REQUEST["x"] ); ?>
This small code fragment already enables an attacker to execute arbitrary PHP code sent in a HTTP request and subsequently retrieve its output. The capabilities of this webshell are only limited by the creativity of an attacker and the tools used to access the webshell.
On the other end of the spectrum are webshells that provide an attacker with a rich graphical web interface used to navigate and further compromise the host. They include easy to use file managers, command and script execution, database access and much more.
Some webshells are advertised as legitimate administrations tools:
This is useful for system/web admin to do remote management without opening cpanel, connecting using ssh, ftp etc. All actions take place within a web browser. —* (we are happy to provide reference upon request)*
While these claims are valid from the creator’s perspective, the sad truth is that in our experience webshells are hardly ever used for legitimate system administration.
Search and Destroy – How to protect your web application
Most general purpose anti virus engines rely on signatures to detect webshells and can detect thus only known webshells. This approach only allows a limited amount of modification to the webshell before the signatures will fail. Signatures also fail to detect webshells that are generated by tools (like from the open source project https://github.com/epinna/weevely/), because they share no common pattern.
A good open source tool to detect obfuscated and suspicious files on an web server is NeoPI (https://github.com/Neohapsis/NeoPI). It uses a variety of statistical methods to detect obfuscated and encrypted content, but requires some expert knowledge about webshells to be used effectively.
Our monitoring solution nimbusec uses an unique approach to identify webshells:
In order to be executable by web servers webshells must in an easily analyzable format (i.e. source code). We use this fact run an in depth code behavior analysis. This enables nimbusec to not only find well know webshells, but also heavily specialized, modified or completely new variations. nimbusec’s heuristic engine understands the underlying capabilities of an PHP file regardless of their form or obfuscation used. On top of that nimbusec also monitors any new or modified files and alarms if suspicious behavior is found. Any malicious activity by an attacker is tracked and can be mitigated before damage is done.
Are you in doubt whether a specific file shows suspicious behavior? Give our free scanning service Shellray a try to find out: https://shellray.com/