It’s nothing new to say that every moment hundreds of thousands requests with malicious payloads are hitting web servers around the world with bad intentions. Probably you’ve seen it many times in many different forms. I would like to take a deeper look at some of them: webshells.
These attacks are really common nowadays because of the nature of the Internet. Millions of web servers seems to be attractive targets for attackers. When you think about the role of the web servers in the organizations then the attractiveness of such targets is even greater.
Intro - before you start testing your luck
First act - try and you might get lucky today
Hiding webshell code inside the well-known file format
Below is a log entry presenting an attempt to execute code using RFI vulnerability.
1 2 3 4
Many of the common RFI exploit scripts, as well as attack payloads sent by hackers append the
? symbol to the included (malicious) URL. In order to avoid the issues with developer supplied strings appended to the URL by the application. It is similar to SQL injection utilizing comment specifiers (
#) at the end of their payloads.
Attacker tried to trick the web application to include a JPG file from the remote server. Is it really a JPG image? Let’s take a closer look:
1 2 3 4 5 6
As you can see above, it’s not an image at all - although it contains a valid GIF file header. Trustwave has an interesting blog post that provides more details on how attackers can hide malicious code in the image files. Let’s analyze the beginning of the PHP code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
pBot defines an array with all the config information. Probably
port fields caught your attention as it provides information about C&C that potential bot will be trying to communicate to. Before we check what is behind the
irc.malink.biz, I would like to know something more about domain
malink.biz itself. Using Passivetotal service we can check the history of that domain and actual whois records.
Owner from USA with all personal data available?! Is this what you would expect from suspicious domain? Maybe a homepage will give us some answers…
nothingsecure…OK, now it seems to be more logical :) Info from IRC is also giving clear answer about intentions:
Ok, so let’s take another step forward and focus on
1 2 3 4
They care about failover ;)
To sum up geo - server in Paris received a crafted request from host in Madrid with a link to the domain
sxxxxxxo.no (Columbus, OH) to download a file
byroe.jpg with embedded webshell. Inside of the file, we found IRC server
irc.malink.biz which resolves to more than one IP - load balancing DNS records using round robin method (Germany, UK, Canada).
How does it look like ? :)
Virustotal confirms AV detection rates seems not too bad. At this point, it’s worth to mention that it’s NOT good to upload any files to VT as a first step of the analysis. Start with OSINT research. For example, before you upload the file, check if file’s hash is not already stored in VT database. Sharing potentially malicious files (remember that VT database is public!) might warn an attacker and give him a chance react quickly.
Images are not the only way how attackers try to bypass the WAF.
Hiding webshell using code obfuscation
The attackers might try to hide their intentions by encoding and compressing the malicious code. This allow to bypass some of the filters and signatures used by WAFs. Another RFI attack:
1 2 3
Content of the suspicious file:
This is a typical example of obfuscated PHP code. It will be passed to the eval() function for execution, but before that it needs to be:
- base64 decoded
There is also a more troublesome version of this. Imagine multiple layers of obfuscated code using the same functions as presented before. Obtaining the original code requires repeated decoding, so manual work with the PHP interpreter ceases to be comfortable. In case you stumble upon such sample then I suggest to use
Here’s the code after deobfuscation:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70
First part of the code is sending email confirmation about infection to
firstname.lastname@example.org. After that there is a code responsible for command execution on infected system and printing output on the page. “Production” example found on the Internet:
As you can see an attacker uploaded a few more “add-ons” like
Again I use VirusTotal to check AV detection ratio:
This time not so good - most of AV engines did not recognize file as suspicious.
Delivering webshell using SQL Injection
Take a closer look at the following example:
First of all attacker needs a SQL Injection vulnerability. Next a specially crafted request will inject PHP code which will be saved on the server.
This is a simple webshell that will be used to execute commands on the web server. Depending on the SQL injection vulnerability attacker needs to place it in appropriate column. In this example the table has three columns. Code will be placed in the second one with others set to NULL.
This SQL command allows attacker to write the webshell code to an arbitrary file.
Path where webshell will be stored. Important thing to note is that attacker needs to find directory on the server with write access e.g. temporary folders. In addition to that crooks have to find a way to force application to execute webshell script in this case this can be achieved via LFI. Following example includes all the above dependencies.
After executing the SQL query the webshell file is created. Now the attacker can interact with the webshell by simply sending a HTTP GET request and defining the following URL:
The directory listing of
/var/www will be returned by the server. Et voilà!
At the end, check how VirusTotal looks for that simple one-line webshell:
Perfectly invisible ;)
With three brief examples we’ve just scratched the surface of this interesting topic. There are many other different ways to place and execute arbitrary code on a remote server and interact with OS. In the second part I’d like to focus on a case which shows how dangerous webshells can be for a business infrastructure and describe methods to protect against them.