Webshell Security Detection

Webshell Security Detection

0x00 traffic-based detection

1. Overview

I have been paying attention to the security analysis of webshell, And I will share my experiences in this period of time.

Webshell generally has three detection methods:

The traffic-based mode is based on the agent Mode (essentially the direct analysis of webshell files) and the log analysis mode.

The classification of Webshell is summarized as follows:

Some time ago, a Webshell Detection System was completed due to work needs, according to the current requirements, I wrote an article about using the Agent-based model and log analysis model to check whether files on the server are webshells. For the original article, see:

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

2. Thoughts on traffic-based webshell Detection

After studying the detection of the above two models, we will consider whether we can implement Webshell analysis and detection on network traffic. After all, it is too costly to implement the Agent model and log analysis model, not only the compatibility issue, but also the performance and security issues) the cost and deployment difficulty will be much reduced, so this article introduces the Webshell Detection Method Based on the traffic (GATEWAY.

To implement Webshell detection through network traffic, you must first "Visualize" the traffic ", there are many "Visualization" methods that can be implemented using some mature frameworks on the market. We mainly discuss how to implement Webshell detection by using payload generated by network traffic during Webshell upload to the server and Webshell access.

3. Payload during upload

We know that normal websites generally allow uploading of "harmless" files when necessary, but do not allow uploading of files in the form of script files, such as PHP, ASP, and JSP, webshell exists in the form of a script file and is parsed by the server. In the upload process, although there will be no attack payload. However, to upload files to the server, some upload-related Payload will also be generated. Next we will discuss two common Webshell upload Methods: Upload "Trojan" and "Pony ".

3.1 upload "Dama"

This method uploads a Webshell file directly through POST or after simple deformation and then uploads it to the server, as shown in the following example:

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

From the above access record, we can find the following key features: POST upload ASP. asp 200 can analyze these key features to find that ASP. php may be a suspected Webshell.

3.2 upload "Pony"

When the "Trojan" Webshell cannot be uploaded directly, hackers usually upload a "Pony" to help upload the "Trojan" or upload a Webshell sentence and use it with a client to control the server, we will not discuss how to upload "Pony" and a Webshell statement here. We will only discuss how to use the pony to upload the Trojan ".

The special point of this method is that not a complete file is transmitted over the network, but a parameter in the HTTP protocol is transmitted over the network, the transmission parameter method may be GET or POST. Let's look at the following example:

In this case, we can easily find that a Webshell script code is being uploaded using a one-sentence Trojan client in the form of POST, and the content is written to a body in the same directory of the one-sentence Trojan. asp files to upload the "Trojan ". We can find payload in the intercepted traffic data, such as: act = body. asp value = Execute. By detecting these payloads, we can analyze webshells and their behaviors during the upload process.

4. Payload during access

Webshell is used to control the server or steal confidential information. To implement these capabilities, attackers must send some control commands to Webshell to operate Webshell. The control commands usually contain payload attacks with obvious features. Let's take a look at the following payload types:

It is obvious that Webshell is trying to connect to the database of the website, and the attacker uses the POST method to submit the connection parameters to Webshell. The payload can be found to be: action = sqladmin, dbhost = localhost, dbport = 3306, dbuser = root, dbpass = 1qaz2wsx, connect = connect, etc.

Let's look at the traffic data of a famous Webshell management tool "kitchen knife" that remotely controls the "kitchen knife horse" and sends instructions:

We can see that the "kitchen knife" uses base64 to encrypt the command sent to the "kitchen knife Horse". Through analysis, we can observe two key payload z1 and Z2.

z1=Y21k& z2=Y2QgL2QgIkQ6XHd3d1xxaHJkd3dcIiZ3aG9hbWkmZWNobyBbU10mY2QmZWNobyBbRV0%3D 

You can obtain the decrypted payload by decrypting the encrypted content.

z1=cmd z2=cd /d “D:\www\qhrdww\”&whoami&echo [S]&cd&echo [E]7 

The decrypted payload is especially obvious. We can find cd/d cmd whoami echo [S] & cd & echo [E] 7 and other payloads.

A Webshell analysis engine based on traffic analysis can be formed by combining payload accumulation and rule customization with other detection processes, in addition, this engine can be easily embedded into existing gateway devices or on the cloud for in-depth analysis of webshells.

0x01 deep into the user's heart

1. What is WEBSHELL? What does it mean?

What is Webshell from different perspectives?

Programmer: an executable web script file. It means a script. Hacker: something that can be used to control the website. Meaning: the website has been fixed. Try to hide your identity and avoid further damages. User (webmaster): When Webshell is found, it is troublesome. Serious administrators will think of many problems. The website has vulnerabilities and has been attacked by others. What should I do?

2. What is the difference between Webshell detection tools and products (systems?

There are a variety of open-source and free tools on the Internet, not to mention their recognition rate. Why are these things just a tool?

The author believes that what is a tool is mainly characterized by the following:

Only targeted problems can be solved. Using tools requires a lot of technical accumulation and security knowledge. (non-professional people cannot use them) only professional results will be presented, it still requires a lot of ability and knowledge to solve the problem. (Not applicable to non-professionals) the tool does not fully consider user requirements and user experience.

3. What are the real needs of users?

Understanding user requirements is indeed an art of deep understanding. user demand analysis actually reflects the vision and capabilities of a product manager or decision maker. Is this requirement just needed? Or not just needed? Are explicit or implicit requirements? Are user requirements or user requirements? How urgent is the demand? What is the frequency of demand? (Currently, we all talk about user stickiness, and low-frequency demand is difficult to sell.) Is it a requirement or a demand? Does it solve users' pain points and itch points? Do not confuse the pain points with the itch points. The pain points are charcoal in the snow, and the itch points are icing on the cake. (A little out-of-the-box, a lot more difficult, fully understand the needs, from the perspective of human nature products can be more accepted by the market ).

For Webshell, why do users want to detect webshells? Why do users want to analyze logs? If the target group is the Webmaster (Administrator), what do they care about. They are actually a series of question marks.

Has our website been hacked? Where did the hacker come from? How did you intrude in? Why attack me? What have you done when you come in? (Who is the hacker? From there? What do you want ?) What are website vulnerabilities? How to fix vulnerabilities and prevent hackers from entering the system? When hackers come in, they may have done a lot of bad things, stolen data, and possibly listened to many sensitive information in the intranet. There are no other vulnerabilities. Do not be attacked again? Are there any other security improvement measures such as modifying the system password and setting permissions to prevent system attacks in the same region .......

To put it simply, how can I avoid the occurrence of similar situations and concern about the hacker's source identity and other information (hacker profiles)? So what is the purpose of the Webshell detection system? It is a platform (or service) that covers the post-event handling of WEB security events ).

Main functions:

Check whether the website has been infiltrated. Find the attacker's IP address based on the traffic. This vulnerability is characterized by external threat intelligence to provide comprehensive information to users. Traffic-based attack scenarios can be restored. Analyze website Vulnerabilities Based on attack scenarios. Provide users with repair and reinforcement solutions based on vulnerabilities.

4. What effect does the user want?

The alarm is accurate (the report does not report the Report ). Intuitive and visual alarms. (Visualized) low deployment cost: it is best to deploy the service at zero cost, or to conveniently obtain access alerts (such as SMS notifications ). (Users don't have time to go to the product interface every day. In the future, there will be almost no interface for monitoring product alarm information, or a few visualization charts for the leaders to see, of course, statistical reports are still needed.) Easy to handle alerts: one-click Processing Guide. When I see alerts, I can handle webshell events automatically or manually based on automated one-click scenarios. (Dummies)

Let's say five more things: Useful, nice-looking, easy-to-use, convenient, and easy-to-use.

0x02 discover "unknown Webshell" based on Behavior Analysis"

1. "known" or "unknown"

Known, known, unknown, and unknown, the security industry has talked a lot recently. Currently, the hot "threat intelligence" in the circle should actually be "known unknown ", it is an unknown threat to the local device. It is actually a threat that has already occurred elsewhere. What should we do with the true "unknown"? Although the probability of occurrence of the first threat on us is very small, however, at present, many attacks steal the Administrator's identity or legitimate user identity to perform some seemingly legal operations. These internal "exceptions" occur, no external "threat intelligence" or other data can be compared.

Encryption will gradually become the norm of network traffic, and security threat detection based on "protocol exceptions or behavior exceptions" will become an important means of interpreting security threats in content scenarios. Detects threats based on content detection and behavior detection. Exceptions are not necessarily threats, but generally they must first be exceptions. It also expresses the importance of abnormal behavior analysis based on the whitelist.

One feature of the current security attack and defense is that there will be more and more unknown attacks, and the attack tool you are facing may have never been used (or you have never seen the monitoring field of view ), there are more webshell samples in your hands. Attackers can always create a webshell with more lightweight functions. How can they discover unknown webshells? How can we achieve the wide recovery of Skynet without leaking?

2. Traffic-based Webshell behavior detection

After webshell is run, B/S data is interacted through HTTP, and clues can be found in HTTP requests/responses. This is a dynamic feature detection. We have previously mentioned that webshell communication is an HTTP protocol. Payload-based behavior analysis not only detects known webshells, but also identifies unknown and pseudowebshells.

(1) Conduct Association Analysis on webshell access features (IP/UA/Cookie), payload features, path features, and time features, and use time as the index to restore attack events.

(2) exception-based HTTP requests

Webshell always has an HTTP request. If HTTP requests are monitored at the network layer (Apache/IIS logs are not monitored ), one day, a new PHP file request or a file that is usually a GET request suddenly has a POST request and returns 200. This is a problem.

(3) combined with threat intelligence, conduct in-depth analysis on the source and author of webshell to fully picture who? When? How? Why? (For what purpose? Competitors or malicious attackers) how? (Attack methods)

3. Behavior Characteristics Analysis Based on Sandbox Technology

We know that middleware needs to be started by a system account, and all WEB script files use middleware to complete corresponding actions, by monitoring system processes and SQL queries used by middleware, You Can preliminarily determine the existence and running of webshells on the website. Then, the specific script file for the final launch operation can be determined through the middleware to achieve the final detection and Webshell discovery.

In this section, I have a limited understanding. I will simply list several methods to discover specific webshells.

Database-level detection: Generally, all database operations on a normal website are performed through a unified API, if a script file tries to operate the database in another way, the specific file can be traced. Middleware-level detection: the third-party customized plug-ins can be combined with middleware to detect the script files that initiate the operation. The system-level behavior detection: webshell can execute system commands and there will be processes. For example, in Linux, the nobody User starts bash, and in windows, the IIS User starts cmd. These are dynamic features. 0x03 example of traffic-based Webshell Analysis

1. Typical operations of "Dama"

After a full introduction to the previous articles, I think everyone has some knowledge about how to detect webshells. Today we will discuss how to detect and discover webshells from network traffic.

We know that the purpose of "da ma" is to escalate permissions and control them. The common "Trojan" is generally a complex structure with many functions. "multi-functionality of a single file" is one of the purposes of the "Trojan" design, on the other hand, it is large in size. It is not difficult to summarize the typical functions in various categories of "Trojan.

File Operations: Upload, download, edit, and delete. Database Operations: connect to, detach, and insert data. Command Execution: Submit custom commands and pre-fabricated commands of "Trojan.

Of course, generally speaking, the "Trojan" function is far more than that, but we will discuss how to discover these three features in traffic by attackers and then discover webshells.

2. Payload for typical operations

2.1 File Operations

Let's perform an upload operation with a simple elevation tool. Through Webshell, we can do this:

After the file is successfully sent to the server, let's take a look at the records we captured from the network traffic on the server:

Next, let's take a look at the content of the packet returned by the server from the traffic:

By capturing the actual network traffic to obtain a Payload pair, they appear in the access request and the data returned by the server respectively:

Request Payload：POST|upfiles|pr.exeReturn Payload：200

Through the above Payload, We can summarize the following conclusions:

The server may have been infiltrated and successfully uploaded Webshell backdoor, attackers are trying to exploit Microsoft Windows RPCSS to isolate Local Privilege Escalation Vulnerability (MS09-012) vulnerability for Elevation of Privilege, it also means that the server may have a long time without installing system security patches.

2.2 database operations

Let's take a look at an example of a real MySQL Data operation:

The traffic information obtained through the packet capture tool on the server is as follows:

The traffic information returned by the server is also taken out:

We can see that a large amount of Payload is generated during the operation of a database connection. The simple URL Decoding of POST data can be more obvious:

auth[driver]=server&auth[server]=localhost&auth[username]=root&auth[password]=&auth[db]=mysql&auth[permanent]=1

Next, let's analyze the Payload pair:

Request Payload：POST|localhost|root|mysqlReturn Payload：localhost|root|mysql|200|*.sql|user

Through the preceding paired Payload, we can draw the following conclusions:

Attackers are attempting to access the MySQL database and accessing the table information in the mysql database. Attackers can export the tables in the mysql database to the. SQL file.

2.3 Command Execution

Finally, let's look at the operation process of a command:

Check the traffic data obtained by the server:

Check the traffic returned by the server to obtain the following data:

In this case, an attacker sends a command to the server to view the current permission. The server runs the command after receiving the command and reports the result to the attacker through the response topic. Let's analyze the Payload.

Request Payload：POST|act=cmd|cmd=who|precmdReturn Payload：200|net authority\|system

Through the Payload summarized above, we can draw the following conclusions:

The server has been intruded. attackers try to send the operating system permission used to query the middleware running time to the server and obtain satisfactory results. Then the tragic outcome of this server can be imagined.

Compared with a single Webshell management tool, the Payload in the access process is relatively simple and more obvious, and it is relatively easy to detect, but there is no absolute thing, the encrypted and premade Webshell can completely escape the above Payload detection process.

0x04 Analysis of webshell's "seeing" Capability

1. Typical attack sequence diagram of webshell

A piece of Rsa analysis material provides a convenient description of the visibility capability. The traffic-based analysis method is compared with the traditional IDS \ IPS \ SIEM.

2. Analyze the "visibility" capability of each stage from killchain

From the perspective of kill chain, it is difficult to see behavior in the first two stages of Reconnaissance and Weaponise by collecting the system's own traffic technical means. (Combined with threat intelligence, we can see the information of these two stages in a wider range). Traffic-based payload analysis technology can be used in Delivery, Exploit, Installation, Command & Control (C2) and Action.

3. From the perspective of protection capabilities

Security protection capabilities are classified into several levels

Detect: Can you see/find it? (Can the attack be detected?) Deny: Can you stop it from happening? (Can you avoid attacks?) Disrupt: Can you stop it while it's happening? (Can you stop ongoing attacks?) Degrade: Can you make it not worth it? (Can attackers feel the attack is not worthwhile and reduce the attack level) Deceive: Can you trick them [the adversary]? (Can you trick or redirect attacks?) Destroy: Can you blow it up? (Whether attackers can be destroyed)

Summary of web security protection capabilities:

4. Three Methods for Webshell Detection

From the perspective of security protection capabilities, detection is the top priority. webshell detection mainly includes the following methods:

(1) Traffic-based webshell detection engine

Easy to deploy and analyze original information through traffic images. Payload-based behavior analysis not only detects known webshells, but also identifies unknown and pseudowebshells. Perform Association Analysis on webshell access features (IP/UA/Cookie), payload features, path features, and time features, and use time as an index to restore attack events.

(2) file-based webshell analysis engine

Checks whether webshell features are included, such as common functions. Checks whether encryption (obfuscation processing) is used to determine whether it is a webshell file hash detection, creates a webshell sample hashing library, and compares and analyzes suspicious files. Checks the file creation time, modification time, and file permission to check whether the file is a webshell sandbox technology. It is determined based on the behavior characteristics of the Dynamic Language sandbox runtime.

(3) log-based webshell analysis engine

Supports common log formats. By modeling Website access behaviors, You can effectively identify webshell uploads and other behaviors to perform comprehensive analysis on logs and trace back the entire attack process.

The three detection methods are file-based detection. In many cases, the deployment cost of obtaining samples is relatively high, and the entire attack process cannot be seen only by samples. Some log-based behavior information is not visible in the log. In general, the "traffic"-based information is the most visible, and the entire attack process can be fully restored.