CSP-CERT® Resources:
Webshells, An Introduction

by CSP-CERT Research Science Team
posted September 2018

I often get asked, how do you analyze a webshell? And I don't really know how to reply without going into a long winded answer.

I guess the short answer is, it depends… :)

To really answer the question, I think people first need to understand what a webshell is.

What is A Webshell?

A webshell in itself is just a webpage (web) that can run commands in a system (shell).

It comes in all sorts and forms of size and language. For example if you have a php webpage, then the webshell would be in PHP as well.

It can be a very small simple webshell that just runs system commands, or it can be a very large one that has all sorts of functionalities like file upload/download and database connections.

How Do you get a Webshell?

When a webshell is discovered on the webserver, it usually means one of these things (although there may be other ways that aren't included).

  1. A vulnerability or a misconfiguration in the webserver was exploited which allowed for the upload of the webshell. This is often what happens. There are a lot of exploits out in the wild that is either meant for the webserver itself (apache, MS IS) or exploits targeting web applications like WordPress.
  2. The network has been compromised by advanced attackers and they placed webshells in the webserver as a secondary backdoor.
  3. An insider put the webshell (someone logged in physically and copied over the webshell).

The Why of Webshells

There's a lot of different purposes for an attacker to utilize a webshell. Below are some of the ways I have personally seen attackers do.

  1. As a stepping stone to gain better access in to the system. In cases of exploits in a webserver/web application, an attacker can upload a simple webshell that executes system commands. Once an attacker establishes a webshell, it is an easy job to convert that webshell into an interactive shell (a command shell that users can interact or send inputs to).
    Once an attacker has an interactive shell, he/she can now move more freely to do reconnaissance on the system to gain privileged escalation.
  2. Having a webshell installed means an attacker don't have to re-exploit vulnerabilities. Once dropped, they don't have to go through the first step (exploitation) and just use the webshell to gain access into the system.
  3. In cases of APTs, attackers drop webshells on the webservers that they find as a backup backdoor into the system. They don't utilize it during the attack but they know it's there. When the victim perform remediation, this can be missed and an attacker just waits out the cleanup and once all activity has gone down, go back in again on the network and resume their attack, this time by utilizing the webshell as an entry point.
    This is one of the reasons why it is important to do proper scoping and checking what an attacker has done on a system once logged in.
  4. As a way to utilize the victim's resources. I've seen attackers drop webshells that takes inputs for email and sends it through the victim's mail. This is prevalent on spamming cases. First, they don't have to use their own machines for the spam and second, the IP of the victim is what's seen on the spam which would have a higher chance of getting through spam filters that look at blacklisted IPs.

2 Cases of Webshell

But the question is how do I analyze a webshell? The analysis of the webshell itself is pretty easy, you just have to know how to read code. Webshells, as said above are just webpages that are coded in whatever language the webserver is running on, for example php, jsp, asp scripts. Even if the attackers utilize obfuscation techniques, there is always a way to deobfuscate it and read the actual code that it's trying to execute.

But knowing what a webshell does is one thing, knowing how the attacker utilized the webshell is another. Remember, when you find a webshell in a webserver, that usually means that the server has been compromised. It is now up to the security analyst to determine how the webshell is being used to know what to do next.

Did the attacker just use it to generate spam? Was it used to gain an interactive shell? Did the attacker gain administrative privilege via the webshell? Was it used to move laterally into the network?

The questions above will need more than checking the code of the webshell. A security analyst would now have to rely on different things in order to get the full picture. Having a complete log of the webserver or having full pcap capture helps greatly with this.

Below are two use cases of webshells that can serve as an example. Note that there are many more ways, but the two below should give a better picture on how to analyze webshells in terms of an incident.

**The scenarios below are based on real cases and emulated on a safe environment for the article's purposes.

The case of the simple one

A webshell is discovered with the code below:

Reading the code, the webshell gets the URL query 'cmd' value and executes it via the php system command.

In other words, it executes whatever command is passed on to it on the affected webserver. For example ifconfig.

How to analyze?

Since we know what the filename of the webshell is, and how it is used, we can check our access logs for it.

Command: cat access.log |grep simple.php

We can see there are hits with our search and we know that the webshell was accessed. Let's see if we can get a cleaner output.

Command: cat access.log |grep simple.php |cut -d " " -f 1,6

By utilizing the cut command, I was able to clean up the output and only get the ones I want.

Note that access logs can have other useful values like the referrer, user agents and if you have them enabled XFF values are valuable in getting the original attacker IP. The example above is just a simple way of analyzing the attacker activity.

The case of the advanced one

More advanced webshells doesn't mean harder to analyze. They just have more features.

Some features of advanced webshells:

  1. Command execution
  2. Database connection
  3. Reverse shell/Bind shell connections
  4. Listing of processes
  5. Upload/Download of files

One example is the b374k webshell. It's usually easier to get the webshell in a safe environment and access the features from there.

B374k File System view where edit/rename/upload and download is possible

Listing of Processes

System command execution (cat /etc/passwd)

How to analyze?

Then comes the question, how do we analyze this? Notice that the URI doesn't really give much.

In fact, as far as we know there's only 4 variations and only two that we could make signatures on. I don't really have that much confidence in just using a two characters to detect this but how many websites employ ?! Or ?| in their URI?

Still, this doesn't help us in terms of knowing what the attacker did. This is where employing a full packet capture helps.

By employing this pcap capture, I was able to list all the HTTP POST request that was sent to this webshell.

http.request.uri contains "b374k" and http.request.method == POST

Let's try to examine some of them.

The first POST request was for logging in which actually shows the password used for the webshell. In this case it's "b374k".

In the response part, it set some cookie values, among them is a cookie for b374k itself.

If we were creating signatures this would be one thing I would look for in a header.

Also notice that the response data is encoded in gzip. Before, we had to extract the contents and gunzip the data offline to know what is in the stream. In later versions of wireshark however, all you have to do is click Follow HTTP Stream instead of TCP stream.

Doing this gives a better output like below

Going through each of the POST request, I can now see both the command passed as well as the output (response).

Process listing Example

To be able to view it better, we can actually just extract the whole page and view it offline.

Example:

Reverse Shell Example, below is an example of a reverse shell request.

A snort signature can be created from the RS POST data by checking for
rshost_back_php=<IP>&rsport_back_php=<port>

Now supposed you are pressed for time, you have a big pcap and there are lots and lots of POST requests to go through.

Checking how to interact with the webshell and getting the specific commands can be done through proper parsing of the HTTP POST data.

Let's take one and look into how wireshark parses it.

Going through the HTTP Protocol in wireshark, we can see that the commands are passed through a HTML Forms.

So what we want is the Key and the Value that is passed through the HTML Forms.

Firing up tshark.exe (command-line equivalent of wireshark), we can quickly get all commands that was passed by the attacker.

Let's break down the command.

tshark.exe -r b374k.pcap -Y "http.request.uri contains b374k and http.request.method == POST" -T fields -e frame.time -e ip.src -e http.request.uri -e urlencoded-form.key -e urlencoded-form.value

-r b374k.pcap - to read the saved pcap
-Y "http.request.uri contains b374k and http.request.method == POST" - This is the filter I used so that it only gets packets for HTTP POST requests and have b374k on the URI.
-T fields -e frame.time -e ip.src -e http.request.uri -e urlencoded-form.key -e urlencoded-form.value - This basically tells tshark to just output the different fields that I have specified.
frame.time - time of the packet
ip.src - ip source address, also known as the attacker's IP address (can be used to filter other things that the attacker did)
http.request.uri - URI of the shellcode accessed
urlencoded-form.key - command used by the attacker
urlencoded-form.value - the value of the command used.

For example on the last line:

rshost_back_php,rsport_back_php,back_php,x 40.114.37.41,13123,Go !,rs

This would be the reverse shell command of the webshell.

rshost_back_php = 40.114.37.41 (attacker IP)
rsport_back_php = 13123 (port used for the reverse shell)
back_php = Go ! (submit button)
x=rs (type of command/page)

If you notice there are x=ps, x=info in the key value pairs. This corresponds to the page where the attacker is.

For example x=info would correspond to this screenshot below by clicking the "info" tab.

Note that the filters and fields that I used above would not be applicable to other webshells.

An analyst would have to understand and interact with the webshell to find out the fields needed to show them. This means that an analyst would have to be flexible enough in his knowledge to react to different kinds of webshells.

There are other webshells that are more specialized, some are meant as just mass mailers/spammers, some are meant as tunnellers, the point is, a webshell can be used for any purposes that an attacker wants it for. It will be up for the analyst on how flexible they can be with analyzing them and gathering up the information about an attacker's activity using every available resource that they have, be it logs, packet capture or just plain google search to check for analysis or any online resource that resembles the webshell.