Webshell Security Detection: Traffic-based Detection

First. Overview

Webshell generally has three detection methods:

Traffic-based
Based on agent mode (essentially analyze webshell files directly)
Based on log analysis mode
The author of the classification of Webshell summarizes as follows:



Some time ago, due to the needs of the work, I completed a Webshell detection system. According to the needs at that time, I wrote an article about using Agent-based models and log-based analysis models to detect whether the files on the server are Webshell. The original text can be found in:

http://www.sec-un.org/ideas-like-article-espionage-webshell-method.html



Second, traffic-based webshell detection thinking
After studying the detection of the above two models, I have always considered to implement Webshell analysis and detection on network traffic. After all, the cost of implementing the Agent model and the log analysis model is too large to consider not only compatibility issues but also performance and security issues. If traffic-based detection is used, the cost and deployment difficulty will be reduced a lot.

To achieve Webshell detection through network traffic, first of all, you need to "visualize" the traffic. The "visualization" method can refer to some mature frameworks on the market to achieve here. There is no more explanation here. We mainly discuss that Webshell is uploaded to the server. And Webshell is accessed in these two processes, the payload feature in the network traffic to achieve Webshell detection.

Third. Payload during upload
We know that normal websites usually allow uploading some "harmless" files but need to upload files in the form of script files such as PHP, ASP, JSP, etc., and Webshell uses this script. The file exists and is parsed by the server. Although some attack payloads will not appear during the upload process. But to upload files to the server, it will also generate some payloads related to the upload. Below we discuss two common forms of uploading Webshell, namely uploading "Malaysia" and "Pony".

3.1 Direct upload of Webshell
In this way, a Webshell file is directly uploaded through POST or simply transformed and then uploaded to the server in the form of:

2009-02-10 06:32:58 W3SVC77065997 8.8.8.8 POST /lesson_manage/upload/40/ASP.asp – 80 – 118.122.124.103 Mozilla/4.0+compatible;+MSIE+6.0; 200 0 0

From the above log, the following key features can be found: POST upload ASP.asp 200 Through these key features, you can determine that ASP.php is a suspected Webshell file.

3.2 Upload a sentence Webshell
In the case where the Webshell cannot be uploaded directly, the intruder usually uploads a "pony" to assist in uploading the "pony" or upload a sentence of Webshell and cooperate with a client to implement the control server. Here we will not discuss how to upload the "pony" "And a sentence Webshell. We only discuss how to use "Pony" to upload "Malaysia".

The special point of this method is that the file is not transmitted in the traffic but a parameter is transmitted in the traffic, so the method may be either GET or POST. Let's look at a real example below:



In the above screenshots, it is not difficult to find that there are many key features and methods.

Fourth. Payload during access
Because Webshell is made to control the server or steal confidential information. To achieve these capabilities, an attacker must send some control commands to the Webshell to operate the Webshell. The control commands usually contain obvious attack payloads. Let's observe the following types of payloads:



The figure above clearly shows that Webshell is trying to connect to the database of the website, and the attacker used POST to submit connection parameters to Webshell.

Let's take another look at the command that the kitchen knife remotely controls the kitchen knife and sends it to the kitchen knife:



It can be seen from the above figure that "chopper" uses base64 to encrypt the command sent to "chopper". Through analysis, we can see two key parameters z1 and z2:

Default
z1=Y21k& z2=Y2QgL2QgIkQ6XHd3d1xxaHJkd3dcIiZ3aG9hbWkmZWNobyBbU10mY2QmZWNobyBbRV0%3D
z1=Y21k& z2=Y2QgL2QgIkQ6XHd3d1xxaHJkd3dcIiZ3aG9hbWkmZWNobyBbU10mY2QmZWNobyBbRV0%3D
We can easily decrypt the base64 ciphertext it uses, and the decrypted result is:

Default
z1=cmd z2=cd /d "D:\www\qhrdww\"&whoami&echo [S]&cd&echo [RV0
z1=cmd z2=cd /d "D:\www\qhrdww\"&whoami&echo [S]&cd&echo [RV0
Obviously, the features are particularly obvious after decryption. After detecting and extracting this attack-prone payload, it can be used for in-depth analysis of Webshell. The traffic analysis engine formed based on the above ideas can be embedded into the existing gateway device or cloud and implement in-depth analysis of Webshell.