Webshells
We’ve all seen one, if we’ve been unlucky. For the fortunate, a webshell is a file containing a high-level scripting language (usually PHP, JSP, ASP etc) that provides a custom web interface for an attacker when it is uploaded to a victim web server. A webshell may be implanted by several mechanisms, but by far the most popular over the last decade within our observations has been via arbitrary file upload vulnerabilities, whereby a web upload function does not have sufficient restrictions and validations enforced upon incoming files. In recent years, however, there has been a rise in leveraging remote code execution/command injection vulnerabilities to implant a webshell or at least to gain a foothold on a victim server and then implant a webshell thereafter.
Scale
Sadly, for all of us, the scale of incoming webshell upload attempts from attackers is significant; the rate of attempts we see in Fortra's Threat Intelligence IDS alerts from customer environments ranges from as low as 1,000 and as high as 50,000 unique attempts daily. Whenever a new arbitrary file upload vulnerability appears within a popular web software, that rate will jump; our record a few years ago, after a vulnerability disclosure for a particular WordPress plugin, was >300,000 attempts across two days. Webshells are a still a big problem.
Categories
We break webshells down into three types:
Webshell
Most commonly observed for: Command-and-Control (C2) for Actions-on-Objective
Common size range: 50kB – 150kB
These are the classic, fully formed web interface, which may have rich HTML with CSS styling and potentially even mature JavaScript if the developer is so inclined. These shells offer a comprehensive set of features such as file upload, code or script execution, file editing, filesystem navigation or as a web GUI file explorer, with functions that may even allow an attacker to compromise multiple software stacks beyond web on the host (SQL or FTP server) or to use the compromised server to attack others. For the initiated, think of the old names such as C99 and its variants, WSO, b374k etc.
Figure 1: Legacy classic C99 interface example
These are the most common examples people will think of when hearing the word “webshell” but, these days, they are by far the least common within attempts we observe against our customers, though these types of shell do still appear.
Minishell
Most commonly observed for: Foothold/staging (with some C2)
Common size range: 1kB – 15kB
Whilst these usually offer a small, simple interface, they are not as fully featured and offer only 2-4 functions such as file upload, directory listing/navigation or command execution; it is as common to see these with CSS or similar styling (such as below) as without.
Figure 2: A common minishell, offering uploading, editing, renaming and deletion of files
A common use-case we have observed with these over the years has been to use them as the initial foothold from which to deploy a second payload; we have even seen a minishell used to upload and deploy a full webshell on more than one occasion.
Microshell
Most commonly observed for: Recon
Common size range: 40B – 500B
These files are the smallest and most common types of attempt we currently see. Microshells are usually one-liner PHP snippets that will perform one or two basic functions such as echoing a string or a file or executing a hardcoded OS command in response to a request to show successful implantation, ergo successful compromise by whichever vulnerability or attack was attempted.
Figure 3: Give a minimal response header and return a hardcoded string with predetermined OS command output
In the majority of cases, these shells do not afford any interaction to the attacker and simply return an expected response, although we do still observe one-liner PHP shells which will accept and execute a command passed as a request parameter, affording C2
Figure 4: Echo a string in response to show successful exploitation of CVE-2024-4577
Management of analysis
Attempting to analyse, for example, 3,417 PHP-based webshell upload attempts (our intake for 3rd Oct 2024) across the customer base would be nonsensical for humans to do without some form of automation and deduplication. The good news is that, after scraping those shells out of the network streams and processing them for deduplication, those >3,000 attempts were comprised of only 33 unique webshell payloads. Manual analysis of ~33 or more webshells a day, every day, is still a tall order; taking it a step further, only two of those webshells were unique enough that maybe we haven’t seen them before, so this would take the daily workload to two (for PHP shells at least). Even at a greatly reduced work rate, this scenario still tasks a human with daily, manual review of webshells, which is only one of the many types of malicious files that we must care about, so we can do better.
Automation for existing coverage tests
Enter ShellBase, our continuous webshell testing pipeline. For every unique enough shell (more on this below) we import into our analysis and storage framework, we throw the shell into an ephemeral container appropriate for the shell language; a PHP shell will cause a containerised Apache with PHP to spin up and accept the shell upload. Whilst capturing network traffic, we send a request to the implanted shell to determine what the first response from the shell will be, which is what we then want to model within IDS detection logic to spot the same response if it is sent from a customer environment. After the request/response, the traffic capture is then sent over for processing with our IDS detection logic to see if our existing coverage will alert on the shell.
Figure 5: Traffic capture generated via ShellBase automation
We are now in a position where the human needs only to spend time analysing novel webshells not already covered although, frustratingly, many of these shells are quite old and quite broken, so at times manual tweaking may be required for the shell to work at all and then test for existing coverage again.
Clustering
Automation pipelines are a great help, but with the “Don’t trust, just verify” mindset required when dealing with malicious file coverage, we still want to have a good understanding across everything we collect. So, we are back to dealing with the entire corpus which, after heavy deduplication, that still leaves us with ~11,300 webshells, which is the total for just the PHP collection.
A while ago, we discovered an excellent project (Wallace, 2014; Wallace, 2015) using similarity comparison of ssdeep hashes for clustering a collection of webshells into groups to enumerate “families” of shells. An early attempt to use the project tooling for this purpose with our webshells produces a fairly nice demonstration of groupings; although clustering for images is great for display and communication, this doesn’t afford an optimisation for workflow as-is.
Figure 6: Clustering visualisation of collected webshells with Gephi, using output of ssdc tooling (Wallace, 2014)
Influenced by this prior work (Wallace, 2015), we have implemented the process of using ssdeep hashes for clustering within our internal malware storage and analysis API framework, so that we can attack the groupings for coverage development rather than having to group manually or, worse, tackle shells individually. The research process now is as follows:
Pick a bucket of malicious files (in this case, all PHP webshells) and send off an API request to cluster the bucket in bulk
Review a few examples of the group to find file components less likely to change across the family
Confirm that the hypothetically unchanging components do indeed exist across all members of the clustered groups
Create the appropriate detection logic proposals incorporating the confirmed unchanging components
Test the new detection logic, via the ShellBase traffic capture pipeline, to confirm alerts fire successfully
Show and shell
The first thing people will notice when they cluster webshells with bulk analysis is the significant incidence of “vanity forks”; the time-honoured behaviour of changing a name, title or similar component of a malicious file to indicate ownership/authorship without changing the fundamental functional code of the file. Within the clustered groups, we see this a lot:
Figure 7: Same shell, different dev
The other discovery we want to find is a singular actor or group using the same shell but modifying the secondary or tertiary C2 IoCs. We may be able to use the future IDS data from a shell-specific signature to extract these ephemeral IoCs with a different processing pipeline and be able to
Track the shell usage for the actor/group across campaign pushes or infrastructure iterations over time.
Produce additional, post-compromise coverage signatures which detect outbound requests from customer environments to enumerated C2 infrastructure if the ephemeral IoCs are remote IP addresses or domains
A minishell example below utilises an email callback mechanism to alert the threat actor of successful implantation; these two shells were harvested from attack attempts over a month apart and can reasonably be used for campaign tracking based on the other “vanity” components of the shell not changing.
Figure 8: Same shell, different mail
A common observation in clustered microshells is an ephemeral remote host being used to create a recon callback or even to deliver a secondary file payload via outbound web request. The below shell examples, attempting to masquerade as an image file to bypass common filetype upload restrictions, would send an outbound request to popular OAST (Portswigger, no date) public testing domains used for exploitation attempts where success may not generate an inline response for confirmation:
Figure 9: Spot the GIFference
With the dual approach of continuous, automated coverage testing to unearth new samples for review and periodic bulk analysis of everything, we aim to keep on top of the problem as thoroughly and efficiently as possible whilst striving to take away as many tasks as possible that humans should no longer have to sink time into.
References
Portswigger (no date). Out-of-band application security testing (OAST). Available at: https://portswigger.net/burp/application-security-testing/oast (Accessed: 04 October 2024).
Wallace, B. (2014) ssdeep Cluster. GitHub. Available at: https://github.com/blaquee/ssdc (Accessed: 04 October 2024).
Wallace, B. (2015) ‘Optimizing ssDeep for use at scale’, virusbulletin, 27 November. Available at: https://www.virusbulletin.com/virusbulletin/2015/11/optimizing-ssdeep-use-scale (Accessed: 04 October 2024).
Discover Fortra's Alert Logic's Threat Research
Keep pace with the ever-changing threat landscape with Fortra's Alert Logic's multi-vector approach to threat research.
