CN116074031A

CN116074031A - Webshell detection method, device and related system

Info

Publication number: CN116074031A
Application number: CN202111300506.0A
Authority: CN
Inventors: 杨利东
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2021-11-04
Filing date: 2021-11-04
Publication date: 2023-05-05

Abstract

The embodiment of the application provides a Webshell detection method, a Webshell detection device and a related system. The Webshell detection method is performed by a guard device deployed between a web server and a client. The protection device detects a first traffic between the web server and the client. If the suspected Webshell file is detected from the first traffic, the protection device provides the suspected Webshell file to the sandboxed device. The protection device continues to monitor a second traffic transmitted between the website server and the client after the first traffic, obtains a first PCAP package file based on the second traffic, and then sends the first PCAP package file to the sandboxed device to enable the sandboxed device to replay the first PCAP package file. The protection equipment receives alarm information sent by the sandboxed equipment, wherein the alarm information indicates that the suspected Webshell file is a Webshell file. According to the embodiment of the application, the protection equipment and the sandbox detection equipment are linked, the Webshell files are dynamically monitored from the network side, the detection accuracy of the protection equipment on the Webshell files is effectively improved, and the false alarm rate of the protection equipment is reduced.

Description

Webshell detection method, device and related system

Technical Field

The present invention relates to the field of communications technologies, and in particular, to a Webshell detection method, device, and related system.

Background

A Webshell (Webshell) is a code execution environment in the form of a Web file such as a dynamic server page (Active Server Pages, asp), a hypertext preprocessor (Hypertext Preprocessor, php), a Java service page (Java Server Pages, jsp) or a universal gateway interface (Common Gateway Interface, cgi), and is mainly used for operations such as Web site (Web) server management and rights management. Webshell works on the principle of uploading a code file to a web server, which can be accessed through a web site. By accessing the code file, the user can perform a plurality of daily operations, and the management of the website server by the user is greatly facilitated. For this reason, a malicious attacker can use the code file as a backdoor program to achieve the purpose of controlling the website server.

Webshell files have the characteristics of isolated files, mature running environment and obvious functional effect. The normal web page files are usually associated with each other, but the isolation of the Webshell files is shown in that the association between the files is not usually present, and the normal web page files and the Webshell files are obviously distinguished in the association. Secondly, the malicious attacker generally aims at controlling the website server, so the Webshell has definite action function. When a malicious attacker attacks by using the Webshell file, the Webshell file needs to be uploaded to a website server, and the Webshell function is used in an interactive mode after the Webshell file is uploaded. After a malicious attacker successfully uploads the Webshell file to the website server, the probability of successful attack is high because the Webshell file operates stably.

There are several schemes for detecting and alerting Webshell documents. In the first scheme, network devices such as an intrusion prevention system (Intrusion Prevention System, IPS) or an intrusion detection system (intrusion Detection system, IDS) detect Webshell files by analyzing traffic in a network. The detection capability of IPS and IDS depends on a detection library preset in IPS or IDS. The detection library preset in the IPS or IDS is pre-programmed by the programmer. After the network flow passes through the detection of the Webshell malicious features in the detection library, the network equipment for detection outputs corresponding alarms, and the alarm analysis personnel analyzes the alarms and then outputs reports.

The detection method in the first scheme depends on a preset characteristic. In the practical use process, a large number of false positives can be generated when the IPS and the IDS detect. Second, in the first approach, the feature bypass scenario cannot be resolved based on the detected feature.

In the second scheme, terminal detection and response systems (Endpoint detection and response, EDR) or terminal detection software based on Host-based intrusion detection system (HIDS) and the like or terminal detection equipment can detect Webshell malicious files by analyzing files in an operating system, and the detection capability depends on a detection library preset in the EDR or the HIDS. The detection library preset in EDR or HIDS is pre-written by a programmer. After the files in the operating system pass through the Webshell malicious features in the detection library, the terminal detection software or the terminal detection equipment for detection outputs corresponding alarms, and the alarm analysis personnel analyzes the alarms and then outputs reports.

The detection mode in the second detection scheme also depends on the preset characteristics. In the practical use process, a large number of false positives can be generated when EDR and HIDS are detected. Second, in the second scheme, feature bypassing scenes cannot be solved based on feature detection. Meanwhile, as software needs to be deployed at the terminal when detection is carried out through EDR and HIDR, the cost is high and the system performance is easily affected.

Disclosure of Invention

The embodiment of the application provides a Webshell detection method, a Webshell detection device and a related system. According to the method, the Webshell file is dynamically monitored from a network side by linking the sandbox detection equipment with protection equipment such as IPS/IDS/firewall and the like. The detection accuracy of the protective equipment to the Webshell files is effectively improved, the false alarm rate of the protective equipment is reduced, and the self value of the protective equipment is improved.

In a first aspect, an embodiment of the present application provides a Webshell detection method, where the method is performed by a guard device deployed between a website server and a client, and the method includes: detecting a first flow between a website server and a client; if a suspected Webshell file is detected from the first flow, providing the suspected Webshell file to sandboxed equipment; monitoring a second flow transmitted between a website server and a client after the first flow, and obtaining a first PCAP package file based on the second flow, wherein the first PCAP package file comprises at least one message generated by accessing a suspected Webshell file; transmitting the first PCAP package file to the sandboxed equipment so that the sandboxed equipment plays back the first PCAP package file; and receiving alarm information sent by the sandbox device, wherein the alarm information is obtained by detecting the replay process of the sandbox device, and the alarm information indicates that the suspected Webshell file is a Webshell file.

According to the Webshell detection method, after the protection equipment transmits suspected Webshell files detected from the traffic transmitted between the website server and the client to the sandboxed equipment, the interaction traffic between the website server and the client is continuously monitored. And providing request traffic (for example, in the form of PCAP package files) for accessing the suspected Webshell files in the interactive traffic transmitted between the website server and the client to the sandboxed equipment, so that the sandboxed equipment can replay the PCAP files according to the received suspected Webshell files, and further verify whether the suspected Webshell files are the Webshell files or not. The detection accuracy of the protective equipment to the Webshell files is effectively improved, and the false alarm rate of the protective equipment is reduced.

In one possible implementation, providing the suspected Webshell file to the sandboxed device includes: obtaining a second PCAP package file based on the first flow, wherein the second PCAP package file comprises at least one message used for transmitting the suspected Webshell file; and sending the second PCAP package file to the sandboxed equipment so that the sandboxed equipment can obtain the suspected Webshell file by replaying the second PCAP package file.

That is, when the protection device provides the suspected Webshell file to the sandboxed device, the obtained suspected Webshell file can be directly uploaded to the sandboxed device in a PCAP package file mode, so that the operation on the protection device is simplified.

In one possible implementation, providing suspected Webshell files to a sandboxed device includes: obtaining a suspected Webshell file based on at least one message used for transmitting the suspected Webshell file in the first flow; and sending the suspected Webshell file to the sandboxed equipment.

That is, the guard device provides suspected Webshell files when it wants the sandboxed device. After the PCAP package file containing the suspected Webshell is obtained, the suspected Webshell file in the PCAP package can be restored or extracted on the protection device and then sent to the sandbox device. The operation time of the sandboxed equipment is saved.

In one possible implementation, monitoring a second traffic transmitted by the website server and the client after the first traffic, and obtaining the first PCAP package file based on the second traffic includes: acquiring a destination address and a uniform resource locator carried by at least one message for transmitting the suspected Webshell file based on at least one message for transmitting the suspected Webshell file in the first flow, wherein the uniform resource locator is used for indicating an uploading path of the suspected Webshell file on a website server; and monitoring the second flow, and if the destination address and the uniform resource locator of at least one access request in the second flow are respectively the same as the destination address and the uniform resource locator carried by at least one message for transmitting the suspected Webshell file, acquiring the first PCAP packet file based on the second flow.

That is, the guard device is after uploading the suspected Webshell file to the sandbox. And the protective equipment acquires the request flow transmitted between the website server and the client for accessing the suspected Webshell file according to the destination address and the uniform resource locator carried by the message for transmitting the suspected Webshell file. The acquired request traffic is guaranteed to be related to suspected Webshell files.

In one possible implementation, the alert information includes: at least one of a source address of an attacker, a destination address of the attacker, a uniform resource locator, a status code, a network transmission protocol, and an alarm level.

That is, at least one or more of the source address of the attacker, the destination address of the attacker, the uniform resource locator, the status code, and the network transmission protocol are displayed in the alarm information, so that the receiving party of the alarm information can block the subsequent access request according to the received alarm information.

In one possible implementation, the alert information includes a uniform resource locator, and after receiving the alert information generated by the sandboxed device, the method further includes: monitoring a third flow transmitted between the website server and the client after the second flow, and detecting a uniform resource locator carried in the third flow; and if at least one uniform resource locator carried by the access request in the third flow is the same as the uniform resource locator in the alarm information, blocking the access request of which the uniform resource locator carried in the third flow is the same as the uniform resource locator in the alarm information.

That is, after the protection device receives the alarm information of the sandbox, the protection device may directly block the subsequent access request transmitted between the website server and the client according to the uniform resource locator carried in the alarm information, which is the same as the uniform resource locator carried in the alarm information, and directly generate the alarm information. On the premise of ensuring the accuracy of the protective equipment in judging the Webshell files, the subsequent judging process of the traffic transmitted between the website server and the client is simplified.

In one possible implementation, the sandboxed apparatus is deployed at a cloud server.

That is, when the sandboxed equipment is deployed on the cloud server, the combination of the local and cloud is realized when the suspected Webshell file is detected.

In a second aspect, an embodiment of the present application provides a Webshell detection method, where the method is performed by a sandboxed device deployed on a cloud server, and the method includes: receiving a suspected Webshell file and storing the suspected Webshell file in sandboxed equipment; receiving a first PCAP package file, wherein the first PCAP package file comprises at least one message generated by accessing a suspected Webshell file; replaying the first PCAP package file, and detecting suspected Webshell files stored in sandboxed equipment based on the replaying process to determine whether the suspected Webshell files are Webshell files or not; based on the suspected Webshell file as the Webshell file, generating alarm information and sending the alarm information to the protective equipment.

That is, according to the Webshell detection method provided by the embodiment of the present application, the sandboxed device does not analyze the suspected Webshell file or the PCAP package file related to the suspected Webshell file alone. The attack process is replayed according to the suspected Webshell file and the PCAP package file related to the suspected Webshell file. The sandboxed device then analyzes the replay process to determine whether the suspected Webshell file is a Webshell file. The accuracy of the sandboxed equipment to the detection of the Webshell files is guaranteed.

In one possible implementation, receiving a suspected Webshell file includes: receiving a second PCAP package file, wherein the second PCAP package file comprises at least one message used for transmitting a suspected Webshell file; and replaying the second PCAP package file to obtain a suspected Webshell file.

That is, the sandboxed device may receive the suspected Webshell file directly or may receive the PCAP package file. When the sandboxed device receives the PCAP package file containing the suspected Webshell file, the suspected Webshell file may be obtained by replaying the PCAP package file. In this implementation, the manner in which the sandboxed device receives the suspected Webshell file is not limited.

In one possible implementation, the method for protecting suspected Webshell files in sandboxed equipment includes: acquiring a destination address of the suspected Webshell file based on at least one message used for transmitting the suspected Webshell file in the second PCAP packet file, wherein the destination address is the address of a website server on which the suspected Webshell file is uploaded; and modifying the destination address of the suspected WebShell file in at least one message into the address of a Web Server container in the sandbox device so as to store the suspected WebShell file in the sandbox device, or modifying the address of the Web Server container into the destination address of the suspected WebShell file so as to store the suspected WebShell file in the sandbox device.

That is, after the sandboxed device receives the suspected Webshell file, the received suspected Webshell file needs to be deployed in the Web Server of the sandboxed device. The Web Server container is an interface set between the component and the platform in the application Server, and can provide an environment for normal operation of Webshell files.

In one possible implementation, in a case that the destination address of the suspected Webshell file is modified to be an address of a Web Server container in the sandboxed device, replaying the first PCAP package file includes: acquiring an access request message in a first PCAP package file, wherein the access request message comprises a uniform resource locator of a suspected Webshell file and request main body data; modifying the destination address of the suspected Webshell file carried in the access request message into a Web Server container address, thereby obtaining a new access request message; and interacting with the Web Server container according to the new access request message.

That is, the request flow for accessing the suspected Webshell file is constructed according to the file request parameters carried in the acquired first PCAP package file. And the process of interacting with the Web server container according to the request flow is the replay process of the first PCAP package file. Further, the destination address of the suspected Webshell file contained in the constructed request flow is modified according to the deployment mode of the suspected Webshell file in the Web Server container. The constructed request flow can be interacted with a Web Server container deployed with suspected Webshell files.

In one possible implementation, detecting suspected Webshell files stored in the sandboxed device based on the replay process includes: recording a process of executing function call of the suspected Webshell file through a hook function when the first PCAP package file is replayed; and judging whether the suspected Webshell file is the Webshell file or not according to the process of executing the function call by the suspected Webshell file.

That is, when detecting the playback process of the first PCAP package file, the function call during the playback process may be recorded by a hook function. And then executing a calling function process rule according to the file to be detected to judge whether the file to be detected is a Webshell file.

In a third aspect, an embodiment of the present application provides a Webshell detection device, where the device includes:

the detection module is used for detecting the first flow between the website server and the client;

the sending module is used for providing the suspected Webshell files for the sandboxed equipment when the suspected Webshell files are detected from the first flow;

the detection module is further used for monitoring second traffic transmitted by the website server and the client after the first traffic, and acquiring a first PCAP package file based on the second traffic, wherein the first PCAP package file comprises at least one message generated by accessing the suspected Webshell file;

the sending module is further used for sending the first PCAP package file to the sandboxed equipment so that the sandboxed equipment plays back the first PCAP package file;

the receiving module is used for receiving alarm information sent by the sandboxed equipment, wherein the alarm is obtained by detecting the replay process of the sandboxed equipment, and the alarm information indicates that the suspected Webshell file is a Webshell file.

In one possible implementation manner, the detection module is further configured to obtain a second PCAP package file based on the first traffic, where the second PCAP package file includes at least one packet for transmitting the suspected Webshell file;

The sending module is further configured to send the second PCAP package file to a sandboxed device, so that the sandboxed device obtains the suspected Webshell file by replaying the second PCAP package file.

In one possible implementation manner, the detection module is further configured to obtain a suspected Webshell file based on at least one packet used to transmit the suspected Webshell file in the first traffic;

the sending module is also used for sending the suspected Webshell file to the sandboxed equipment.

In one possible implementation, monitoring a second traffic transmitted by the website server and the client after the first traffic, and obtaining the first PCAP package file based on the second traffic includes:

acquiring a destination address and a uniform resource locator carried by at least one message for transmitting the suspected Webshell file based on at least one message for transmitting the suspected Webshell file in the first flow, wherein the uniform resource locator is used for indicating an uploading path of the suspected Webshell file on a website server;

and monitoring the second flow, and if the destination address and the uniform resource locator of at least one access request in the second flow are respectively the same as the destination address and the uniform resource locator carried by at least one message for transmitting the suspected Webshell file, acquiring the first PCAP packet file based on the second flow.

In one possible implementation, the alarm information includes a uniform resource locator, and the detection module is further configured to monitor a third flow transmitted between the website server and the client after the second flow, and detect the uniform resource locator carried in the second flow;

and if at least one uniform resource locator carried by the access request in the third flow is the same as the uniform resource locator in the alarm information, blocking the access request of which the uniform resource locator carried in the third flow is the same as the uniform resource locator in the alarm information.

In a fourth aspect, embodiments of the present application provide a Webshell detection device, where the Webshell detection device includes:

the receiving module is used for receiving the suspected Webshell file and storing the suspected Webshell file in the Webshell detection device;

the receiving module is further used for receiving a first PCAP package file, wherein the first PCAP package file comprises at least one message generated by accessing the suspected Webshell file;

The processing module is used for replaying the first PCAP package file, detecting the suspected Webshell file stored in the Webshell detection device based on the replaying process to determine whether the suspected Webshell file is the Webshell file or not; generating alarm information based on the suspected Webshell file as the Webshell file;

and the sending module is used for sending alarm information to the protective equipment.

In one possible implementation, receiving a suspected Webshell file includes:

receiving a second PCAP package file, wherein the second PCAP package file comprises at least one message used for transmitting a suspected Webshell file;

and replaying the second PCAP package file to obtain a suspected Webshell file.

After receiving the suspected Webshell file in one possible implementation, the processing module is further configured to:

acquiring a destination address of the suspected Webshell file based on at least one message used for transmitting the suspected Webshell file in the second PCAP packet file, wherein the destination address is the address of a website server on which the suspected Webshell file is uploaded;

and modifying the destination address of the suspected WebShell file in at least one message into the address of a Web Server container in the WebShell detection device so as to store the suspected WebShell file in the WebShell detection device, or modifying the address of the Web Server container into the destination address of the suspected WebShell file so as to store the suspected WebShell file in the WebShell detection device.

In one possible implementation, in a case where the destination address of the suspected Webshell file is modified to be the address of the Web Server container in the Webshell detection device, the processing module is further configured to,

acquiring an access request message in the first PCAP package file, wherein the access request is used for requesting to access the suspected Webshell file, and the file request parameters comprise a uniform resource locator and request main body data of the suspected Webshell file;

modifying the destination address of the suspected Webshell file carried in the access request message into the address of a Web Server container, thereby obtaining a new access request message; and interacting with the Web Server container according to the new access request message.

In one possible implementation, the processing module is further configured to,

recording a process of executing function call of the suspected Webshell file through a hook function when the first PCAP package file is replayed;

and judging whether the suspected Webshell file is the Webshell file or not according to the process of executing the function call by the suspected Webshell file.

In one possible implementation, the Webshell detection device is deployed on a cloud server.

In a fifth aspect, embodiments of the present application provide a Webshell detection device, including:

At least one memory for storing a program;

at least one processor for executing the program stored in the memory, the processor being adapted to perform the method provided by the first aspect when the program stored in the memory is executed.

In a sixth aspect, embodiments of the present application provide a Webshell detection sandbox, including:

at least one memory for storing a program;

at least one processor for executing the program stored in the memory, the processor being adapted to perform the method provided by the second aspect when the program stored in the memory is executed.

In a seventh aspect, an embodiment of the present application provides a cloud server, where a Webshell detection sandbox is deployed on the cloud server, where the server includes:

at least one memory for storing a program;

at least one processor for executing the program stored in the memory, the processor being for use in the method provided in the second aspect when the program stored in the memory is executed.

In an eighth aspect, embodiments of the present application provide a Webshell detection system, including the guard device provided in the third aspect and the detection device provided in the fourth aspect, or including the detection device provided in the fifth aspect and the sandbox provided in the sixth aspect.

In a ninth aspect, embodiments of the present application provide a computer-readable medium having instructions stored therein, which when run on a computer, cause the computer to perform the method provided in the first or second aspect.

In a tenth aspect, embodiments of the present application provide a computer program product comprising instructions which, when run on a computer, cause the computer to perform the method provided in the first or second aspect.

In an eleventh aspect, embodiments of the present application provide a chip, including a memory for storing computer instructions, and a processor for calling and executing the computer instructions from the memory to perform the method in any possible implementation of the first aspect and the first aspect, or to perform the method in any possible implementation of the second aspect and the second aspect.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings required for the description of the embodiments will be briefly described below, it being obvious that the drawings in the following description are only some embodiments of the present invention, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

Fig. 1 is a system architecture diagram of a Webshell detection system provided in an embodiment of the present application;

FIG. 2 is a schematic diagram of the structure of an IPS/IDS;

FIG. 3 is a schematic structural diagram of a sandbox device according to an embodiment of the present disclosure;

fig. 4 is a schematic diagram of a Webshell detection process provided in an embodiment of the present application;

fig. 5 is a schematic flow chart of a Webshell detection method provided in an embodiment of the present application;

fig. 6 is a schematic flow chart of another Webshell detection method according to an embodiment of the present application;

fig. 7 is a schematic structural diagram of a Webshell detection device according to an embodiment of the present application;

fig. 8 is a schematic structural diagram of a detection device for Webshell detection according to another embodiment of the present application.

Detailed Description

In order to make the objects, technical solutions and some of the embodiments of the present application more clear, the technical solutions in the embodiments of the present application will be described below with reference to the accompanying drawings.

In the description of the embodiment of the present application, it is "and/or" merely one association relationship describing the association object, and the representation may have three relationships, for example, a and/or B may represent: a alone, B alone, and both A and B. In addition, unless otherwise indicated, the term "plurality" means two or more. For example, a plurality of systems means two or more systems, and a plurality of screen terminals means two or more screen terminals.

Furthermore, the terms "first," "second," and the like, are used for descriptive purposes only and are not to be construed as indicating or implying relative importance or implicitly indicating an indicated technical feature. Thus, a feature defining "a first" or "a second" may explicitly or implicitly include one or more such feature. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless expressly specified otherwise.

Fig. 1 is a system architecture diagram of a Webshell detection system provided in an embodiment of the present application. As shown in fig. 1, the system includes: a WEB server 11, a protection device 12, a sandboxed device 13 and a client 14. When an attacker initiates an attack on the WEB server 11, the attacker can access the WEB server 11 in the quarantine (demilitarized zone, DMZ) area through the internet. When an attacker accesses the WEB server 11 in the DMZ area, the guard 12 disposed between the WEB server 11 and the client 14 detects traffic transmitted between the client 14 where the attacker is located and the WEB server 11. When the protection device 12 detects a suspected Webshell file in the traffic transmitted between the client 14 and the WEB server 11, the protection device 12 captures the traffic transmitted between the client 14 and the WEB server 11. The guard device 12 uploads the captured suspected Webshell file to the sandboxed device 13. The protection device 12 then continues to detect traffic transmitted between the client 14 and the WEB server 11. When the destination address and the uniform resource locator of at least one access request in the traffic transmitted between the client 14 and the WEB server 11 are respectively the same as the destination address and the uniform resource locator carried by at least one message for transmitting the suspected Webshell file, the protection device 12 acquires the access request parameter carried in the traffic transmitted between the client 14 and the WEB server 11, and uploads the access request parameter to the sandboxed device 13. The sandboxed device 13 replays the attack procedure of the attacker according to the received suspected Webshell file and the access request parameter for accessing the suspected Webshell file. Then, the sandboxed apparatus 13 determines whether the received suspected Webshell file is a Webshell file according to the playback process. When the sandboxed device 13 determines that the suspected Webshell file uploaded by the protection device 12 is a Webshell file, the sandboxed device 13 generates alarm information and sends the alarm information to the protection device 12. The protection device 12 blocks part of the access requests between the client 14 and the WEB server 11 according to the uniform resource locator carried in the alarm information, wherein the uniform resource locator carried by the blocked access requests is the same as the uniform resource locator in the alarm information.

Alternatively, the sandboxed apparatus 13 in fig. 1 is integrated in the same physical device as the guard apparatus 12, or the sandboxed apparatus 13 is a dedicated sandboxed apparatus bypass-connected to the guard apparatus 12.

Alternatively, the sandboxed device 13 in fig. 1 is a server or a server cluster connected to the protective device 12 via the internet, and provides cloud sandboxed services to the protective device 12 in a free license or a fee-based license.

Next, an attack procedure in the network will be described, which generally includes the following stages.

(1) An attacker accesses the WEB server 11 in the DMZ area through a browser. It should be noted that an attacker refers to an attack initiator from the internet or from outside.

(2) When an attacker finds that the WEB server in the DMZ area has a vulnerability, the prepared Webshell file is uploaded to the WEB server 11 in the DMZ area.

(3) When the Webshell file is successfully uploaded to the WEB server 11 in the DMZ area, an attacker starts to access the Webshell file. The attacker realizes the interaction process with the Webshell file by accessing the Webshell file, namely, the process of remotely controlling the WEB server 11 in the DMZ area by the attacker.

The above is an introduction to the Webshell detection system related in the present solution. The following describes the components of the Webshell detection system described above and shown in fig. 1.

First, the WEB server 11 is described. In the embodiment of the present application, the WEB server 11 refers to a WEB server located in the DMZ area. DMZ is a solution for network architecture. A common architecture scheme is to establish an intermediate public access area or independent network between an untrusted external network and a trusted internal network. The aim is to prevent external users from directly accessing an intranet to ensure the safety of an internal network environment while providing online services to the outside. The DMZ zones are generally accessible to users of the external network but cannot actively initiate connection requests to the internal network.

Next, the protective apparatus 12 is described. In the embodiment of the present application, the protection device 12 may be a firewall device, IDS, IPS, EDR, HIDS, or other network security device with detection and protection functions. When in use, one network security device can be independently deployed as a protective device. Multiple network security devices can be combined and deployed to achieve a better protection effect. The manner of deployment of the protective equipment 12 is not particularly limited in the embodiments of the present application.

In one example, an IPS/IDS is presented as an example. As shown in fig. 2, the IPS/IDS includes: processor 201, memory 202, network port 203. Optionally, the IPS/IDS also includes a forwarding chip 204, a content addressable device 205. The memory 202 is used for storing program instructions and data, such as the acquired suspected Webshell file or access request parameters related to the suspected Webshell file, and program instructions for implementing the Webshell detection method. Processor 201 is the computational core and control core of the IPS/IDS. The processor 201 reads the program instructions and data stored in the memory, thereby executing the Webshell detection method.

The network port 203 is the gateway between the IPS/IDS and the external communication. Further, the content addressable device 206 is a memory that is addressed by content, and is a special memory array RAM. The forwarding chip 204 is configured to forward the packet passing through the protection device according to forwarding information such as an address port mapping table, an access control list, and the like stored in the content addressable device 206.

Then, the sandboxed apparatus 13 is described. As shown in fig. 3, the sandboxed apparatus 13 includes: a processor 301, a network interface 302, a memory 303. Optionally, the sandboxed apparatus 13 further comprises an input device 304, a display 305. Wherein the processor 301, the network interface 302, the memory 303, the input device 304, the display 305 may be connected by a bus or other means.

Memory 303 is a memory device of sandboxed device 13 for storing programs and data, such as suspected Webshell files and PCAP package files sent by guard device 12. The memory 303 provides a storage space storing an operating system of the server and program instructions of program instructions to implement the Webshell detection method. Operating systems include, but are not limited to: windows (an operating system), linux (an operating system), hong (an operating system), and the like, without limitation.

In this scenario, processor 301 (alternatively referred to as a central processing unit (central processing unit, CPU)) is the compute core and control core of sandboxed apparatus 13. The processor 301 reads the program instructions and data held in the memory 303, thereby executing the Webshell detection method. Processor 301 reads the program instructions stored in memory 303, and then stores the received suspected Webshell file, so as to replay the received PCAP package file related to the suspected Webshell file. Processor 301 may then determine whether the received suspected Webshell file is a Webshell file according to the replay process.

The network interface 302 may include a standard wired interface, a wireless interface (e.g., WI-FI, mobile communication interface, etc.). The network interface 302 is controlled by the processor 301 to transmit and receive data. Such as a suspected Webshell file or PCAP package file sent by the receiving guard 12. The input device 304 is configured to receive input information of a user, for example, a decision rule input in advance by the user for a suspected Webshell file. The display 305 is used for displaying the determination rule input by the user in advance or displaying the determination result of the processor 301.

Finally, client 14 is introduced. In the embodiment of the present application, the client 14 may refer to an electronic device used by an attacker who attacks the WEB server 11. The electronic device in the embodiment of the application may be a mobile phone, a tablet computer, a notebook computer, and the like.

The above is an introduction to the Webshell detection system related to the scheme, and each component part in the detection system. Next, a detailed description will be given of a Webshell detection scheme involved in the present scheme based on the Webshell detection system described in fig. 1 and the Webshell detection process shown in fig. 4. As described in detail below.

(1) An attacker uploads Webshell files to the WEB server 11 in the DMZ area or downloads Webshell files from the internet area by the WEB server 11 in the DMZ area.

(2) The IPS/IDS/firewall device detects that there is interactive traffic in the network that contains suspected Webshell files, captures the traffic, and provides the suspected Webshell files to the sandboxed device 13.

In this scenario, an exemplary IPS/IDS/firewall device may be used as the guard device 12 described above. The IPS/IDS/firewall device detects the traffic of interactions between the WEB server 11 and the client 14. In one possible example, a feature matching method is employed in determining whether the interaction traffic transmitted between the web server and the client includes suspected Webshell files. The judgment process of the feature matching method depends on character matching. For example, webshell documents typically include the character fopen, fwrite, where x is a wildcard character. The characters to be matched that can be set are fopen, fwrite. When judging by using the feature matching method, matching characters contained in a message transmitted between the website server and the client with characters to be matched. When characters contained in a message for transmitting the suspected Webshell file meet a matching rule, determining that the first flow contains the suspected Webshell file.

Further, when the IPS/IDS/firewall device detects the suspected Webshell file from the interactive traffic between the WEB server 11 and the client 14, the IPS/IDS/firewall device obtains the suspected Webshell file based on the interactive traffic.

The IPS/IDS/firewall device may obtain a suspected Webshell file based on at least one message in the interactive traffic for transmitting the suspected Webshell file, and upload the suspected Webshell file to the sandboxed device 13.

The IPS/IDS/firewall device may also obtain a second PCAP package file based on the interactive traffic, where the PCAP package file includes at least one message for transmitting the suspected Webshell file. The IPS/IDS/firewall device uploads the second PCAP package file to sandboxed device 13 so that sandboxed device 13 may obtain the suspected Webshell file by replaying the second PCAP package file.

(3) The sandboxed device 13 receives the suspected Webshell file and saves the suspected Webshell file in the sandboxed device 13.

In this solution, the sandboxed apparatus 13 comprises: the system comprises a PCAP package file replay module, a Web Server container module, a background monitoring module and an alarm module.

After the sandboxed device 13 receives the suspected Webshell file, the destination address of the suspected Webshell file is obtained, and the destination address is the address of the WEB server 11 where the suspected Webshell file is uploaded. Then, the sandboxed device 13 modifies the destination address of the obtained suspected Webshell file to the address of the Web Server container in the sandboxed device, thereby saving the suspected Webshell file in the sandboxed device 13. Alternatively, the sandboxed apparatus 13 modifies the address of the Web Server container to the destination address of the suspected Webshell file so as to save the suspected Webshell file in the sandboxed apparatus 13.

(4) The IPS/IDS/firewall equipment monitors an access path carried in the interactive traffic in the network and the transmitted file, captures the interactive traffic carrying the same access path as the suspected Webshell file, and generates a first PCAP packet file.

In the scheme, after the IPS/IDS/firewall equipment acquires the suspected Webshell file, the destination address and the uniform resource locator carried by at least one message for transmitting the suspected Webshell file are acquired based on the at least one message for transmitting the suspected Webshell file.

And then the IPS/IDS/firewall equipment monitors the interactive traffic in the network according to the acquired destination address and the uniform resource locator. And when the destination address and the uniform resource locator of at least one access request in the interactive flow in the network are respectively the same as the destination address and the uniform resource locator carried by at least one message for transmitting the suspected Webshell file, acquiring the first PCAP packet file based on the interactive flow.

(5) The IPS/IDS/firewall device uploads the first PCAP packet file to the sandboxed device.

In this scheme, the IPS/IDS/firewall device uploads the first PCAP package file to the sandboxed device 13, so that the sandboxed device 13 may obtain the access request parameters for accessing the suspected Webshell file by replaying the package file.

The IPS/IDS/firewall device may also extract access request parameters for accessing the suspected Webshell file in the first PCAP package file. The IPS/IDS/firewall device then uploads the extracted access request parameters to the sandboxed device 13.

(6) Sandboxed device 13 plays back the received first PCAP package file according to the pre-stored suspected Webshell file.

In this solution, the PCAP package file replaying module in the sandboxed device 13 may replay the received first PCAP package file to obtain the access request message in the first PCAP package file. And then, the PCAP packet file replay module replays the attack process according to the acquired access request message and the suspected Webshell file placed in the Web Server container.

Optionally, in one example, the PCAP package file replaying module obtains the access request message in the first PCAP package file, and modifies the destination address of the suspected Webshell file carried in the access request message into the Web Server container address, thereby obtaining a new access request message. The PCAP playback module then interacts with the Web Server container via the new request message.

(7) The Webshell container in the sandboxed device 13 detects the playback process of the first PCAP package file, and determines whether the suspected Webshell file stored in the Web server container is a Webshell file.

In the scheme, the background monitoring module can record the process of executing the function call of the suspected Webshell file through the hook function. And then the PCAP replay module judges whether the suspected Webshell file is the Webshell file or not according to the process of executing the function call by the suspected Webshell file.

(8) Based on the suspected Webshell file stored in the Web server container being a Webshell file, the sandboxed device 13 generates alarm information and issues the alarm information to the IPS/IDS/firewall device.

In the scheme, when the PCAP replay module judges that the suspected Webshell file placed in the Web Server container is the Webshell file, an alarm module in the sandbox device 13 generates alarm information and sends the alarm information to the IPS/IDS/firewall device. Wherein, the alarm information includes: at least one of a source address of an attacker, a destination address of the attacker, a uniform resource locator, a status code, a network transmission protocol, and an alarm level.

Next, a description is given of a data processing method provided in the embodiment of the present application based on the Webshell detection scheme described above. It will be appreciated that this approach is another expression of the Webshell detection scheme described above, both in combination. The method is based on the Webshell detection scheme described above, and some or all of the content of the method can be found in the description of the data processing scheme above.

Referring to fig. 5, fig. 5 is a flow chart of a Webshell detection method according to an embodiment of the present application. Fig. 5 mainly describes the Webshell detection method from the perspective of the protection device. Optionally, the method is performed by the guard device 12 in the Webshell detection system described in fig. 1. As shown in fig. 5, the method includes steps S501 to S504.

In step S501, a first traffic transmitted between a web server and a client is detected.

The protection device serves as a bridge between the attacker and the WEB server in the DMZ area, and detects traffic transmitted between the attacker and the WEB server in the DMZ area. When an attacker initiates an attack on the WEB server in the DMZ area, the Webshell file is firstly required to be uploaded to the WEB server in the DMZ area. In this embodiment of the present application, the first traffic transmitted between the website server and the client refers to traffic carrying suspected Webshell files transmitted between the website server and the client.

In one example, traffic transmitted between an attacker and a WEB server in the DMZ zone includes: the client where the attacker is located sends HTTP protocol request flow to the WEB server in the DMZ area and response flow to the client where the attacker is located by the WEB server in the DMZ area.

Examples of the request message included in the request traffic are as follows:

POST/admin/upload/test.php HTTP/1.1// method including request, URL of request and protocol version

Host:147.17.2:80

Connection:close

Content-Length:84

Accept:application/json,text/javascript,*/*；q＝0.01

X-Requested-With:XMLHttpRequest

Sec-ch-ua-mobile:？0

User-Agent:Mozilla/5.0(Windows NT 10.0；Win64；x64)AppleWebkit/537.36(KHTML,like Gecko)

Chrome/91.0.4472.124Safari/537.36

Accept-Encoding:gzip,deflate

Accept-Language:zh-CN,zh；q＝0.9

Cmd＝whoami&pass＝23

Examples of response messages contained in the response traffic are as follows:

HTTP/1.1 200OK

Strict-transport-security:max-age＝31536000；includeSubDomains

Accept-ranges:bytes

Etag:W/“781-1615348834000”

Last-modified:Wed,10Mar 2021 04:00:34GMT

Content-type:text/html

Content-length:781

Date:Tue,20Jul 2021 12:40:55GMT

Connection close

Server:product only

success

specifically, the HTTP protocol request traffic sent by the client where the attacker is located to the WEB server in the DMZ area includes: request IP, domain name, uniform resource locator, request parameters. The response flow sent by the WEB server in the DMZ area to the client where the attacker is located comprises the following steps: a Response status code, a Response, etc.

Step S502, based on the suspected Webshell file included in the first traffic transmitted between the website server and the client, the suspected Webshell file is provided to the sandboxed device.

And detecting the traffic transmitted between the WEB server and the client in the DMZ area through the protective equipment. And judging whether the flow transmitted between the WEB server and the client side comprises suspected Webshell files or not. Optionally, the protection device detects whether the first traffic transmitted between the website server and the client contains the suspected Webshell file by using a feature matching or abnormal behavior detection method.

In one example, webshell files are as follows:

<？php

if($_POST)

{

$f=fopen ($post [ "f" ], w "); the #f parameter receives the file name to be written

The if (fwrite ($f, $post [ "c" ]) #c parameter receives the content to be written

echo“<font color＝red>OK！</font>”；

else

echo“<font color＝blue>Error！</font>”；

}

？>

<title>Webshell</title>

</form>

<p></p>

Optionally, in one example, the protection device adopts a feature matching method when determining whether the first traffic transmitted between the website server and the client includes the suspected Webshell file. The feature matching method performs character matching based on features of known WebShell files in a feature library, and judges whether the first flow contains suspected WebShell files according to feature matching results. For example, features of the Webshell file are known to include the character fopen, fwrite, etc., where x is a wildcard character. When judging by using the feature matching method, the protection equipment matches characters contained in a message in a first flow transmitted between the website server and the client with features in a feature library. When characters contained in a message for transmitting the suspected Webshell file meet a discriminant rule formulated based on the characteristics, determining that the first flow includes the suspected Webshell file.

Further, when it is determined that the first traffic transmitted between the WEB server and the client includes suspected Webshell files, the first traffic is captured by a guard device disposed between the WEB server and the client. Then, the protection device uploads the suspected Webshell file contained in the captured traffic to the sandboxed device.

Optionally, in one example, after capturing the first traffic sent between the website server and the client, the guard obtains the suspected Webshell file based on at least one message in the first traffic to transmit the suspected Webshell file. And then, the protection equipment uploads the obtained suspected Webshell file to the sandboxed equipment.

Alternatively, in another example, the guard may capture packets through a tcpdump tool or a wireframe tool as the first traffic transmitted between the web server and the client is captured. The protection device saves the packet grabbing result on a memory as a PCAP packet file after grabbing the packet through a tcpdump or a wireshark tool. And uploading the PCAP package file to sandboxed equipment by the protection equipment, so that the sandboxed equipment can obtain a suspected Webshell file contained in the PCAP package file by replaying the PCAP package file. It should be noted that the data in the PCAP packet file may not be the original network byte stream, but a new data format formed after the original network byte stream is reassembled.

Optionally, in one example, the protection device further generates local suspected alert information while uploading the suspected Webshell file to the sandbox. The suspected alarm information comprises: source address (Srcip), destination address (Dstip), uniform resource locator, status code, network transport protocol, etc. Specifically, the suspected alarm information generated by the local protection equipment is Srcip:123.23.2.1, dstinp: 156.87.6.2, uniform resource locator: admin/upload/test.php, status code: 200, network transmission protocol: HTTP, grade: high risk.

In step S503, a second traffic transmitted between the web server and the client after the first traffic is monitored, a first PCAP package file is obtained based on the second traffic, and the obtained first PCAP package file is transmitted to the sandboxed device.

After the attacker successfully uploads the Webshell file to the WEB server in the DMZ area, the interaction process between the attacker and the Webshell file is the process of remotely controlling the WEB server in the DMZ area by the attacker. In this embodiment of the present application, the second traffic transmitted between the website server and the client refers to traffic generated by interaction between the attacker and Webshell files on the WEB server.

The protection equipment deployed between the website server and the client acquires a destination address and a uniform resource locator carried by at least one message for transmitting the suspected Webshell file through a tcpdump or a Wireshark tool. And then, the protective equipment continuously monitors the request flow for accessing the suspected Webshell file according to the acquired destination address and the uniform resource locator.

In one example, the source address of the attacker, srcip:123.23.2.1, and the destination address, dstinp: 156.87.6.2, are obtained by the guard device. The uniform resource locator acquired by the protective equipment is as follows: admin/upload/test.php. The protection equipment detects the interactive flow transmitted between the WEB server and the client. When the protection equipment detects that the destination address contained in at least one access request message in the interactive traffic transmitted between the WEB server and the client is 156.87.6.2 and the path request of the file to be accessed is test.php, the protection equipment captures the interactive traffic transmitted between the WEB server and the client through a tcpdump or a wireshare tool so as to acquire the PCAP packet file. The acquired PCAP package file is then uploaded by the guard device into the sandboxed device. The PCAP package file includes an access request message, where the request message carries a file request parameter, and the file request parameter includes a uniform resource locator and a request body parameter. The uniform resource locator is used for indicating path information for accessing suspected Webshell files.

In one example, the protection device may directly upload the PCAP package file acquired based on the second traffic to the sandboxed device, or may upload the request parameter to the sandboxed device after extracting the file request parameter included in the access request message in the PCAP package file.

Step S504, receiving alarm information sent by sandboxed equipment.

After the suspected Webshell file and the first PCAP package file are uploaded to the sandboxed equipment by the protection equipment, the sandboxed equipment replays the first PCAP package file according to the suspected Webshell file. And if the sandboxed equipment determines that the suspected Webshell file uploaded to the sandboxed equipment is a Webshell file according to the replay process of the first PCAP packet. The sandboxed apparatus generates the alarm information and transmits the alarm information to the protection apparatus.

In this application, the sandboxed device replaying the first PCAP package file according to the suspected Webshell file refers to replaying an interaction process between an attacker and the suspected Webshell file according to the received suspected Webshell file and a request parameter included in an access request message in the first PCAP package file.

In one example, after the guard device receives the alert information sent by the sandboxed device, the guard device continues to monitor the traffic of interactions between the website server and the client. And the protection equipment detects the uniform resource locator carried in the interactive flow transmitted between the website server and the client according to the uniform resource locator in the received alarm information. When at least one uniform resource locator carried by the access request is the same as the uniform resource locator in the alarm information in the interactive flow between the website server and the client, blocking the access request and generating the alarm information.

In the embodiment of the application, the suspected Webshell file is primarily judged through the protective equipment. When the protection equipment detects that the suspected Webshell file is transmitted between the website server and the client, the protection equipment acquires the suspected Webshell file and access request parameters related to the suspected Webshell file based on the traffic transmitted between the website server and the client. The protection equipment sends the suspected Webshell file and the access request parameters related to the suspected Webshell file to the sandbox equipment, so that the sandbox equipment judges the received suspected Webshell file again. The method has the advantages that multiple judgments on suspected Webshell files are realized through linkage of the protective equipment and the sandboxed equipment, detection accuracy of the protective equipment on the Webshell files is effectively improved, false alarm rate of the protective equipment is reduced, and self value of the protective equipment is improved.

Based on the Webshell detection scheme described above, the embodiment of the application also provides a flow diagram of a Webshell detection method, as shown in fig. 6. Fig. 6 mainly describes the Webshell detection method from the viewpoint of sandboxed equipment. Alternatively, the method is performed by a sandboxed apparatus 13 in the Webshell detection system described in fig. 1. The method shown in fig. 6 includes steps S601 to S604.

Step S601, receiving suspected Webshell files and storing the suspected Webshell files in sandboxed equipment.

In one example, the sandboxed device directly receives the suspected Webshell file uploaded by the protective device.

In another example, the sandboxed device receives a PCAP package file uploaded by the protective device, the PCAP package file including suspected Webshell files. The sandboxed device may obtain the suspected Webshell file contained in the PCAP package file by replaying the PCAP package file.

After the sandbox device obtains the suspected Webshell file, the sandbox device determines the destination address of the suspected Webshell file according to the destination address carried by at least one message for transmitting the suspected Webshell file. And the sandbox device modifies the destination address of the suspected Webshell file into the address of a Web Server container in the sandbox device, so that the suspected Webshell file is stored in the sandbox device. Or the sandbox device modifies the address of the Web Server container in the sandbox device into the destination address of the suspected Webshell file so as to store the suspected Webshell file in the sandbox device.

Step S602, a first PCAP package file is received, wherein the first PCAP package file comprises at least one message generated by accessing a suspected Webshell file.

The sandboxed device may directly receive the request parameters contained in the first PCAP package file. The first PCAP package file may also be received and then the access request message in the first PCAP package file may be obtained. The request message contains request parameters, and the request parameters contain a uniform resource locator and request main body data of suspected Webshell files uploaded to sandboxed equipment. The uniform resource locator is used for indicating path information for accessing the suspected Webshell file.

The sandboxed equipment can construct a new access request message according to the received request parameters, wherein the request message is used for accessing suspected Webshell files in the sandboxed equipment. At this time, the sandbox plays an attacker role, and the Web Server container in the sandbox device plays a Web Server in the DMZ area.

In one example, when saving a suspected Webshell-like file based on the sandboxed device, the sandboxed device modifies the destination address of the suspected Webshell file to the address of a Web Server container in the sandboxed device. When the sandbox device constructs a new request message, the destination address of the suspected Webshell file carried in the constructed request message needs to be modified into the address of the Web Server container.

Step S603, replaying the first PCAP package file, and detecting a suspected Webshell file stored in the sandboxed device according to the replay process.

The process of replaying the first PCAP package file in the sandboxed device is a process in which the sandboxed device interacts with the suspected Webshell file according to the constructed request message.

Upon playback of the first PCAP package file, the sandboxed device records the process of performing a function call with the suspected Webshell file via a hook function (hook). And then, the sandboxed equipment judges whether the suspected Webshell file is the Webshell file or not according to the process of executing the function call by the suspected Webshell file.

In one example, two function calls, fopen and fwrite, are used in the Webshell file. Therefore, when the sandboxed device replays the first PCAP package file, the functions called by the suspected Webshell file in the replay process and the calling process of the called functions can be recorded in a hook mode. When the sandboxed equipment detects that the suspected Webshell file simultaneously calls the functions of fopen and fwrite, the suspected Webshell file can be determined to be the Webshell file.

Step S604, generating alarm information based on the suspected Webshell file as the Webshell file, and sending the alarm information to the protection equipment.

When the sandboxed equipment determines that the suspected Webshell file uploaded by the protective equipment is the Webshell file, the sandboxed equipment generates alarm information and sends the alarm information to the protective equipment.

In one example, the alert information generated by the sandboxed apparatus includes: at least one of a source address of an attacker, a destination address of the attacker, a uniform resource locator, a status code, a network transmission protocol, and an alarm level.

In one possible embodiment, the sandboxed apparatus may be deployed on a cloud server. When the sandbox device is deployed on the cloud server, the detection process of the sandbox device on the received suspected Webshell file is the same as steps S601 to S604, and will not be described here again.

In one possible embodiment, the sandboxed apparatus may also be deployed on a WEB server. When the sandbox device is deployed on the WEB server, the detection process of the sandbox device on the suspected Webshell file is the same as that in steps S601 to S604, and will not be described again here.

In one possible embodiment, the sandboxed apparatus may also be deployed on a protective apparatus. When the sandbox device is deployed on the protection device, the detection process of the sandbox device on the suspected Webshell file is the same as that of steps S601 to S604, and will not be described again here.

In the embodiment of the application, the sandboxed equipment comprehensively judges whether the received suspected Webshell file is the Webshell file or not according to the received suspected Webshell file and the access request parameter related to the suspected Webshell file, so that the detection accuracy of the Webshell file is effectively improved.

Fig. 7 is a schematic structural diagram of a Webshell detection device provided in an embodiment of the present application. The Webshell detection device shown in fig. 7 is provided to realize the function of the protection device in the scheme described in the above embodiment. Optionally, the Webshell detection device shown in fig. 7 performs the function of the protection device described in any one of the embodiments shown in fig. 4 and 5, and by matching with the sandboxed device, the detection accuracy of Webshell files transmitted in the network can be improved.

The Webshell detection device shown in fig. 7 includes: a detection module 701, a transmission module 702, a reception module 703 and a storage module 704.

The detection module 701 is configured to detect a first traffic between a website server and a client.

The sending module 702 is configured to provide the detected suspected Webshell file to the sandboxed device when the suspected Webshell file is detected from the first traffic.

The detection module 701 is further configured to monitor a second traffic transmitted by the web server and the client after the first traffic, and obtain the first PCAP package file based on the second traffic. The first PCAP package file includes at least one message generated by accessing the suspected Webshell file.

The sending module 702 is further configured to send the first PCAP package file to a sandboxed device, so that the sandboxed device plays back the first PCAP package file;

The receiving module 703 is configured to receive alarm information sent by the sandboxed device, where the alarm information is obtained by detecting, by the sandboxed device, a playback process of the first PCAP package file. The alarm information indicates that the suspected Webshell file is a Webshell file.

The storage module 704 is configured to store the suspected Webshell file and the first PCAP package file acquired by the detection module 701. The storage module 704 is further configured to store the alarm information received by the receiving module 703.

Optionally, the Webshell detection device detects Webshell files in the interactive traffic transmitted between the website server and the client, please refer to the description of the related embodiment of fig. 5 above, and the description is not repeated here.

Optionally, after the receiving module 703 receives the alarm information sent by the sandboxed device. The checking module 701 is further configured to monitor a third traffic transmitted between the website server and the client after the second traffic, and detect a uniform resource locator carried in the third traffic. If there is at least one uniform resource locator carried by the access request in the third flow, the uniform resource locator is the same as the uniform resource locator in the alarm information received by the receiving module 703. The detection module 701 blocks the access request that is carried in the third flow and has the same uniform resource locator as the uniform resource locator in the alarm information.

The Webshell detection apparatus shown in fig. 7 can perform other functions as described in the foregoing method embodiments.

The Webshell detection device provided by the embodiment of the application performs preliminary judgment on the Webshell files transmitted between the WEB server and the client. When the Webshell detection device detects the suspected Webshell file, the Webshell detection device acquires the suspected Webshell file and access request parameters related to the suspected Webshell file based on traffic transmitted between the WEB service and the client. And then the Webshell detection transpose suspected Webshell file and access request parameters related to the suspected Webshell file are sent to sandboxed equipment, so that the sandboxed equipment can judge the received suspected Webshell file again. The detection device and the sandbox device are linked to realize multiple judgment of suspected Webshell files, so that the detection accuracy of the protective equipment on the Webshell files is effectively improved, the false alarm rate of the protective equipment is reduced, and the self value of the protective equipment is improved.

Fig. 8 is a schematic structural diagram of a Webshell detection device provided in an embodiment of the present application. The Webshell detection device shown in fig. 8 is provided to realize the functions of the sandbox device in the scheme described in the above embodiment. Optionally, the Webshell detection device shown in fig. 8 performs the functions of the sandboxed device described in any one of the embodiments shown in fig. 4 and fig. 6, and by matching with the protection device, the detection accuracy of Webshell files transmitted in the network can be improved.

The Webshell detection device shown in fig. 8 includes: a receiving module 801, a processing module 802, a transmitting module 803, and a storage module 804.

The receiving module 801 is configured to receive a suspected Webshell file. The suspected Webshell file received by the receiving module 801 is then saved by the storage module 804.

The receiving module 801 is further configured to receive a first PCAP package file, where the first PCAP package file includes at least one message generated by accessing a suspected Webshell file;

the processing module 802 is configured to replay the first PCAP package file, and detect a suspected Webshell file stored in the Webshell detection device based on a replay process to determine whether the suspected Webshell file is a Webshell file. Based on the suspected Webshell file received by the receiving module 801 being a Webshell file, the processing module 802 generates alert information.

The sending module 803 is configured to send the alarm information generated by the processing module 802 to the protection device.

Optionally, the process of the Webshell detection device for detecting the received suspected Webshell file is described with reference to the related embodiment of fig. 6, and will not be repeated here.

The Webshell detection apparatus shown in fig. 8 can perform other functions as described in the foregoing method embodiments.

According to the WebShell detection device provided by the embodiment of the invention, whether the received suspected WebShell file is the WebShell file or not is comprehensively judged according to the received suspected WebShell file and the access request parameter related to the suspected WebShell file, so that the detection accuracy of the WebShell file is effectively improved.

The embodiment of the apparatus depicted in fig. 7 and 8 is merely illustrative. For example, the division of modules is merely a logical function division, and there may be another division manner in actual implementation, for example, multiple modules or components may be combined or may be integrated into another system, or some features may be omitted, or not performed. The functional modules in the embodiments of the present application may be integrated into one processing module, or each module may exist alone physically, or two or more modules may be integrated into one module.

For example, each module in fig. 7 may be implemented in the form of hardware or in the form of a software functional module. For example, when implemented in software, the detection module 701 may be implemented by a software functional module that is generated by at least one processor 201 in fig. 2 after reading the program code stored in the memory 202. The foregoing modules in fig. 7 may also be implemented separately by different hardware in the Webshell detection apparatus, for example, the detection module 701 may be implemented by a portion of processing resources (e.g., one core in a multi-core processor) in at least one processor 201 in fig. 2, and the sending module 702 and the receiving module 703 may be implemented by the network port 203 in fig. 2 and the remaining portion of processing resources (e.g., other cores in the multi-core processor) in at least one processor 201, or may be implemented by a programmable device such as an FPGA or a coprocessor. It is obvious that the above-mentioned functional modules may also be implemented by a combination of software and hardware, for example, the transmitting module 702 and the receiving module 703 are implemented by a hardware programmable device, and the detecting module 701 is a software functional module generated after the CPU reads the program code stored in the memory.

For example, each module in fig. 8 may be implemented in the form of hardware or in the form of a software functional module. For example, when implemented in software, the processing module 802 may be implemented by a software functional module that is generated by at least one processor 301 in fig. 3 after reading the program code stored in the memory 303. The foregoing modules in fig. 8 may also be implemented separately by different hardware in the Webshell detection apparatus, for example, the processing module 802 may be implemented by a portion of the processing resources in at least one processor 301 in fig. 3 (e.g., one core in a multi-core processor), and the receiving module 801 and the sending module 803 may be implemented by the network interface 302 in fig. 3 and the remaining portion of the processing resources in at least one processor 301 in the multi-core processor (e.g., other cores in the multi-core processor), or by using a programmable device such as an FPGA, or a coprocessor. It is obvious that the above-mentioned functional modules may also be implemented by a combination of software and hardware, for example, the receiving module 801 and the transmitting module 803 are implemented by a hardware programmable device, and the processing module 802 is a software functional module generated after the CPU reads the program code stored in the memory.

The embodiment of the application also provides a Webshell detection system which comprises at least one Webshell detection device (shown in the accompanying drawings 2 or 7) and a Webshell detection sandbox (shown in the accompanying drawings 3 or 8). Please refer to fig. 1 or fig. 4 for a schematic diagram of the Webshell detection system.

In this specification, each embodiment is described in a progressive manner, and identical and similar parts of each embodiment are all referred to each other, and each embodiment mainly describes differences from other embodiments. In particular, for system embodiments, since they are substantially similar to method embodiments, the description is relatively simple, as relevant to see a section of the description of method embodiments.

Those of ordinary skill in the art will appreciate that aspects of the present application, or the possible implementations of aspects, may be embodied as a computer program product. The computer program product refers to computer readable program code stored in a computer readable medium.

The computer readable medium may be a computer readable signal medium or a computer readable storage medium. The computer-readable storage medium includes, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. Such as Random Access Memory (RAM), read Only Memory (ROM), erasable Programmable Read Only Memory (EPROM), or portable read only memory (CD-ROM).

It will be apparent to those skilled in the art that various modifications and variations can be made to the present invention without departing from the scope of the invention. Thus, if such modifications and variations of the present application fall within the scope of the claims of the present invention, the present invention is intended to include such modifications and variations as well.

Claims

1. A Webshell detection method, wherein the method is performed by a guard device deployed between a web server and a client, the method comprising:

detecting a first flow between the website server and the client;

if a suspected Webshell file is detected from the first flow, providing the suspected Webshell file to sandboxed equipment;

monitoring a second flow transmitted between the website server and the client after the first flow, and obtaining a first PCAP package file based on the second flow, wherein the first PCAP package file comprises at least one message generated by accessing the suspected Webshell file;

sending the first PCAP package file to the sandboxed equipment so that the sandboxed equipment plays back the first PCAP package file;

and receiving alarm information sent by the sandbox device, wherein the alarm information is obtained by detecting the replay process by the sandbox device, and the alarm information indicates that the suspected Webshell file is a Webshell file.

2. The method of claim 1, wherein the providing the suspected Webshell file to a sandboxed device comprises:

obtaining a second PCAP package file based on the first flow, wherein the second PCAP package file comprises at least one message used for transmitting the suspected Webshell file;

and sending the second PCAP package file to the sandboxed equipment so that the sandboxed equipment can obtain the suspected Webshell file by replaying the second PCAP package file.

3. The method of claim 1, wherein providing the suspected Webshell file to a sandboxed device comprises:

obtaining the suspected Webshell file based on at least one message used for transmitting the suspected Webshell file in the first flow;

and sending the suspected Webshell file to the sandboxed equipment.

4. The method of any of claims 1-3, wherein the monitoring a second traffic transmitted by the web server and client after the first traffic, obtaining a first PCAP package file based on the second traffic, comprises:

acquiring a destination address and a uniform resource locator carried by at least one message for transmitting the suspected Webshell file based on at least one message for transmitting the suspected Webshell file in the first flow, wherein the uniform resource locator is used for indicating an uploading path of the suspected Webshell file on the website server;

5. The method of any one of claims 1-4, wherein the alert information comprises: at least one of a source address of an attacker, a destination address of the attacker, a uniform resource locator, a status code, a network transmission protocol, and an alarm level.

6. The method of any of claims 1-5, wherein the alert information includes a uniform resource locator, and wherein after receiving the alert information generated by the sandboxed device, the method further comprises:

monitoring a third flow transmitted between the website server and the client after the second flow, and detecting a uniform resource locator carried in the third flow;

7. The method of any of claims 1-6, wherein the sandboxed apparatus is deployed at a cloud server.

8. A Webshell detection method, wherein the method is performed by sandboxed equipment deployed on a cloud server, the method comprising:

receiving suspected Webshell files and storing the suspected Webshell files in the sandboxed equipment;

receiving a first PCAP package file, wherein the first PCAP package file comprises at least one message generated by accessing the suspected Webshell file;

replaying the first PCAP package file, and detecting the suspected Webshell file stored in the sandboxed equipment based on the replay process to determine whether the suspected Webshell file is a Webshell file or not;

and generating alarm information based on the suspected Webshell file as the Webshell file, and sending the alarm information to protective equipment.

9. The method of claim 8, wherein the receiving the suspected Webshell file comprises:

receiving a second PCAP package file, wherein the second PCAP package file comprises at least one message used for transmitting the suspected Webshell file;

and replaying the second PCAP package file to obtain a suspected Webshell file.

10. The method of claim 8 or 9, wherein the saving the suspected Webshell file in the sandboxed device comprises:

acquiring a destination address of the suspected Webshell file based on at least one message used for transmitting the suspected Webshell file in the second PCAP package file, wherein the destination address is an address of a website server on which the suspected Webshell file is uploaded;

and modifying the destination address of the suspected Webshell file in the at least one message into an address of a Web Server container in the sandbox device so as to store the suspected Webshell file in the sandbox device, or modifying the address of the Web Server container into the destination address of the suspected Webshell file so as to store the suspected Webshell file in the sandbox device.

11. The method of claim 10, wherein the replaying the first PCAP package file with the destination address of the suspected Webshell file modified to an address of a Web Server container in the sandboxed device comprises:

acquiring an access request message in the first PCAP package file, wherein the access request message comprises a uniform resource locator and request main body data of the suspected Webshell file;

Modifying the destination address of the suspected Webshell file carried in the access request message into the Web Server container address, thereby obtaining a new access request message;

and interacting with the Web Server container according to the new access request message.

12. The method of claim 8, wherein the detecting the suspected Webshell file stored in the sandboxed device based on the replay process comprises:

recording the process of executing function call of the suspected Webshell file through a hook function when the first PCAP package file is replayed;

and judging whether the suspected Webshell file is a Webshell file or not according to the process of executing function call of the suspected Webshell file.

13. A Webshell detection device, comprising:

the sending module is used for providing the suspected Webshell file to sandboxed equipment when the suspected Webshell file is detected from the first flow;

the detection module is further configured to monitor a second flow transmitted by the website server and the client after the first flow, and obtain a first PCAP package file based on the second flow, where the first PCAP package file includes at least one message generated by accessing the suspected Webshell file;

The sending module is further configured to send the first PCAP package file to the sandboxed device, so that the sandboxed device plays back the first PCAP package file;

the receiving module is used for receiving alarm information sent by the sandboxed equipment, wherein the alarm information is obtained by detecting the replay process by the sandboxed equipment, and the alarm information indicates that the suspected Webshell file is a Webshell file.

14. The apparatus of claim 13, wherein the detection module is further configured to obtain a second PCAP package file based on the first traffic, the second PCAP package file including at least one message for transmitting the suspected Webshell file;

the sending module is further configured to send the second PCAP package file to the sandboxed device, so that the sandboxed device obtains the suspected Webshell file by replaying the second PCAP package file.

15. The apparatus of claim 13, wherein the detection module is further configured to obtain the suspected Webshell file based on at least one message in the first traffic used to transmit the suspected Webshell file;

the sending module is further configured to send the suspected Webshell file to the sandboxed device.

16. The apparatus of any of claims 13-15, wherein monitoring a second traffic transmitted by the web server and client after the first traffic, obtaining a first PCAP package file based on the second traffic, comprises:

17. The apparatus according to any one of claims 13-16, wherein the alert information comprises: at least one of a source address of an attacker, a destination address of the attacker, a uniform resource locator, a status code, a network transmission protocol, and an alarm level.

18. The apparatus of any one of claims 13-17, wherein the alert information includes a uniform resource locator, the detection module is further configured to,

19. A Webshell detection device, comprising:

the receiving module is used for receiving the suspected Webshell files and storing the suspected Webshell files in the Webshell detection device;

the receiving module is further configured to receive a first PCAP package file, where the first PCAP package file includes at least one message generated by accessing the suspected Webshell file;

the processing module is used for replaying the first PCAP package file, and detecting suspected Webshell files stored in the Webshell detection device based on the replaying process to determine whether the suspected Webshell files are Webshell files or not; generating alarm information based on the suspected Webshell file as a Webshell file;

And the sending module is used for sending the alarm information to the protective equipment.

20. The apparatus of claim 19, wherein the receiving the suspected Webshell file comprises:

and replaying the second PCAP package file to obtain a suspected Webshell file.

21. The apparatus of claim 19 or 20, wherein after receiving the suspected Webshell file, the processing module is further configured to:

and modifying the destination address of the suspected Webshell file in the at least one message into an address of a Web Server container in a Webshell detection device so as to store the suspected Webshell file in the Webshell detection device, or modifying the address of the Web Server container into the destination address of the suspected Webshell file so as to store the suspected Webshell file in the Webshell detection device.

22. The apparatus of claim 21, wherein the processing module is further configured to, in the event that the destination address of the suspected Webshell file is modified to an address of a Web Server container in the Webshell detection apparatus,

the method comprises the steps that an access request message in a first PCAP package file is obtained, the access request is used for requesting to access the suspected Webshell file, and the file request parameters comprise a uniform resource locator and request main body data of the suspected Webshell file;

modifying the destination address of the suspected Webshell file carried in the access request message into the address of the Web Server container, thereby obtaining a new access request message; and interacting with the Web Server container according to the new access request message.

23. The apparatus of claim 19, wherein the processing module is further configured to,

and judging whether the suspected Webshell file is a Webshell l file or not according to the process of executing function call of the suspected Webshell file.

24. The apparatus of claim 19, wherein the Webshell detection apparatus is deployed on a cloud server.

25. A Webshell detection device, comprising:

at least one memory for storing a program;

at least one processor for executing the memory-stored program, which processor is adapted to perform the method of any of claims 1-7 when the memory-stored program is executed.

26. A Webshell detection sandbox, comprising:

at least one memory for storing a program;

at least one processor for executing the memory-stored program, which processor is adapted to perform the method according to any of claims 8-12, when the memory-stored program is executed.

27. A cloud server having Webshell detection sandboxes deployed thereon, the server comprising:

at least one memory for storing a program;

28. Webshell detection system comprising a guard according to any of claims 13-18 and a detection device according to any of claims 19-23, or a detection apparatus according to claim 25 and a sandbox according to claim 26.

29. A computer readable medium having instructions stored therein which, when run on a computer, cause the computer to perform the method of any of claims 1-7 or claims 8-12.

30. A computer program product comprising instructions which, when run on a computer, cause the computer to perform the method of any of claims 1-7 or claims 8-12.

31. A chip comprising a memory for storing computer instructions and a processor for invoking and executing the computer instructions from the memory to perform the method of any of claims 1-7 or 8-12.