A webshell is a script uploaded to a web server that provides remote command execution through the web interface. They are one of the most common post-exploitation tools in web-facing attacks because they are small, persistent, and difficult to detect without proper monitoring.
How they get installed
The most common upload vectors are unrestricted file upload functionality, exploited file inclusion vulnerabilities, and compromised CMS plugins with file write capability. Once a webshell is on the server it survives reboots and persists until specifically removed, which can be weeks or months after the initial compromise if nobody is actively looking for it.
China Chopper
China Chopper is widely deployed because of its tiny size. The server-side component is a single line of PHP:
<?php @eval($_POST["password"]);?>The @ operator suppresses error output. The eval executes whatever PHP code is sent in the POST parameter. The client-side component is a Windows binary providing a GUI for browsing the remote filesystem, executing commands, and managing the connection. One line of server code provides a full remote access tool.
Detection: any PHP file containing eval with a POST parameter as the argument, especially in upload directories. File integrity monitoring on the web root catches new files. Web application logs showing POST requests to PHP files in directories that should not contain PHP will also surface this.
C99 and ASPX shells
C99 is a more feature-rich PHP shell with a web-based GUI built into the shell file itself. It includes a file manager, command execution, database connection tools, and network utilities. Typically hundreds of lines long and heavily obfuscated. ASPX shells serve the same purpose on IIS servers running ASP.NET and are common in attacks against Microsoft web infrastructure.
Persistence via IIS native modules
A more sophisticated persistence variant on IIS is registering a malicious IIS native module (a DLL) that intercepts HTTP requests at the server level. Unlike a PHP file in the web root, an IIS module runs as part of the IIS worker process itself and is not visible as a file in the web application directory. It can intercept any HTTP request to any site on the server and survives CMS reinstallations.
Get-WebConfiguration system.webServer/globalModules | Select name, image
%windir%\system32\inetsrv\appcmd list moduleAny module entry pointing to a DLL outside of expected Windows and IIS directories is worth investigating.
Detection approach
At the filesystem level: new PHP or ASPX files in directories that should not contain them. At the network level: POST requests to static resource directories or filenames that do not match expected application paths. At the process level: web server worker processes spawning cmd.exe or PowerShell. That last indicator should trigger an immediate alert in any environment with process creation monitoring enabled.