CN114329467A - Memory WebShell detection method and device and electronic equipment - Google Patents

Abstract

The application discloses a memory WebShell detection method, a memory WebShell detection device and electronic equipment, wherein the method comprises the following steps: acquiring all classes of a target application pair, and screening M first classes with memory WebShell risk in all classes; determining codes corresponding to each byte code of the first type in the memory; performing memory WebShell risk detection on the M code files through K first preset rules to obtain N code files with memory WebShell risks; and marking the classes corresponding to the N code files, and taking the marked classes as a first memory WebShell detection result. Based on the method, risk detection is carried out on the code file corresponding to the byte codes in the slave memory, the method is suitable for the non-text memory WebShell, can also be suitable for the encryption processing and the text memory WebShell after the confusion processing, and can improve the accuracy of the memory WebShell detection.

Description

A memory WebShell detection method, device and electronic device

technical field

The present application relates to the technical field of information security, and in particular, to a memory WebShell detection method, device and electronic device.

Background technique

The network background management script WebShell is a malicious script file that exists in the form of a file in a Web container. Through WebShell, the server can be controlled to execute arbitrary instructions, thereby stealing sensitive data or credentials or serving as a springboard for attacking intranet hosts. However, with the vigorous development of the Internet, the increase in the scope of offensive and defensive actual combat drills, and the gradual improvement of defense methods by defenders, the difficulty of attacking WebShell that exists in a Web container in the form of a file is gradually increasing. Therefore, the attacker adopts more sophisticated attack methods, such as the memory-based WebShell attack method. When this attack method has the authority of a Web container process execution user, the attacker can completely control the data and data in the address space corresponding to the process. code, and then achieve the purpose of controlling the server. In the face of attacks based on in-memory WebShell, traditional protection methods are insufficient. Therefore, a WebShell detection method is urgently needed to detect in-memory WebShell.

The current detection methods for in-memory WebShell are mainly based on WebShell file entity detection methods, such as feature detection method, which extracts malicious features from known WebShell samples and performs pattern matching to detect in-memory WebShell; another example is statistical analysis method , this method uses some statistical methods to identify and detect WebShell files, and then extracts features such as feature code, information entropy, longest word, coincidence index, compression and other features in WebShell files for abnormal detection, thereby discovering memory WebShell; Learning method, this method uses decision tree, deep learning and other methods to train samples to obtain a detection model, and then use the detection model to detect the memory WebShell.

However, the above-mentioned detection methods based on WebShell file entities are difficult to detect non-text WebShells, and cannot detect textual WebShells that have been processed by obfuscation, encryption, etc. Or the machine learning method, there is a large possibility of false positives and false negatives.

SUMMARY OF THE INVENTION

The present application provides a memory WebShell detection method, device and electronic device. After preliminary screening of all classes in the virtual machine corresponding to the target application, it is not necessary to compare the bytecode file corresponding to the target application process information with the original bytes. In the case of comparing the code files, the code files corresponding to the bytecodes of the filtered classes in the memory are further detected and marked with in-memory WebShell. This method is suitable for non-text class in-memory WebShell detection, and can also be adapted to encryption processing. And the in-memory WebShell detection of the obfuscated text class improves the accuracy of in-memory WebShell detection.

In a first aspect, the present application provides a memory WebShell detection method, the method comprising:

Acquiring all classes in the virtual machine corresponding to the target application, and screening out M first classes with risks of memory WebShell from all the classes, wherein M is an integer greater than or equal to 1;

Determine the code corresponding to the bytecode in the memory of each first class in the M first classes, and obtain M code files;

Perform memory WebShell risk detection on the M code files through K first preset rules to obtain N code files with memory WebShell risks, wherein one of the first preset rules corresponds to a memory WebShell risk, Both K and N are integers greater than or equal to 1;

Risk marking is performed on the classes corresponding to the N code files with the first preset identifier, and the class containing the first preset identifier is used as the first memory WebShell detection result.

Through the above method, after preliminary screening of all classes in the virtual machine corresponding to the target application, without the need to compare the bytecode file corresponding to the target application process information with the original bytecode file, the filtered The code file corresponding to the bytecode of the class in the memory is further detected and marked by the memory WebShell to reduce the false positive rate. At the same time, since the code file is converted from the bytecode extracted from the memory, it is suitable for non-text classes. In-memory WebShell detection can also be adapted to encrypted and obfuscated text-based in-memory WebShells. Therefore, the detection accuracy of in-memory WebShells can be improved.

Further, the M first classes with WebShell risks are screened out from all the classes, including:

Screening out a second category that does not have source bytecode files locally among all the categories, and using the second category as the first category with WebShell risks; and/or

A third category matching any one of the H second preset rules is screened out from all the categories, and the third category is used as the first category with WebShell risk, wherein , one of the second preset rules corresponds to a memory WebShell risk, and H is an integer greater than or equal to 1.

Through the above method, all classes in the virtual machine corresponding to the target application are preliminarily screened, and the scope of subsequent code risk scanning is narrowed. WebShell has a good targeting effect, improving the detection accuracy and detection accuracy of memory WebShell.

Further, the code corresponding to each of the first categories is determined respectively, and M code files are obtained, including:

Extract the M bytecodes of the first category corresponding to the memory respectively;

Convert the bytecode into code files of M preset types.

Through the above method, the bytecode in the memory corresponding to the extracted class is converted into a code file of a preset type, which is convenient for further code risk investigation. The processed text-like in-memory WebShell improves the detection accuracy of the in-memory WebShell.

Further, the described M code files are subjected to memory WebShell risk detection by K first preset rules to obtain N code files with memory WebShell risks, including:

Matching the text corresponding to each code file in the M code files with the preset risk level character string respectively;

If there is a first character string consistent with the preset risk level character string in the text corresponding to any code file, determine that the code text to which the first character string belongs has an in-memory WebShell risk; and/or

Detect the number of preset risk characters in the corresponding text of each code file in the M code files;

judging whether the numerical value is greater than a preset threshold;

If there is a first code text whose number of risk characters is greater than a preset threshold, it is determined that the first code text has a memory WebShell risk.

Through the above method, the M first types are detected by using K first preset rules for detecting different risk types, which can adapt to different types of memory WebShell risks and improve the accuracy of memory WebShell detection.

In a possible design, before acquiring all the classes in the virtual machine corresponding to the target application, it also includes:

Scan all currently running applications to obtain basic information corresponding to all applications and process information corresponding to all applications respectively, wherein the basic information at least includes complete class information of application entry;

According to the basic information corresponding to all applications, a target application is selected from all the applications;

The basic information corresponding to the target application and the process information corresponding to the target application are loaded into the virtual machine corresponding to the target application.

Through the above method, a lot of information about the virtual machine corresponding to the target application is obtained when the target application is running. Compared with accessing and analyzing static files or obtaining information through external access to the running target application, the information that can be obtained is more comprehensive. detection accuracy.

In a possible design, after using the first preset identifier to perform risk labeling on the classes corresponding to the N code files, and using the class containing the first preset identifier as the first memory WebShell detection result, Also includes:

Determine that the first memory WebShell detection result includes the risk type corresponding to the class of the first preset identifier;

The information corresponding to the risk type is added to the first in-memory WebShell detection result to obtain a second in-memory WebShell detection result.

Through the above method, the risk type corresponding to the class with memory WebShell risk is further determined, the risk information corresponding to the memory WebShell in the memory WebShell detection result is improved, and the detection accuracy of the memory WebShell is improved.

Further, it is determined that the first memory WebShell detection result contains the risk type corresponding to the class of the first preset identifier, including:

Matching the second code file of the preset type corresponding to the class of the first preset identifier in the first memory WebShell detection result with any one of the first preset rules;

If the matches are consistent, the memory WebShell risk corresponding to the first preset rule that matches the second code file is used as the risk type.

Through the above method, the risk type corresponding to the class with memory WebShell risk is determined as string risk and/or character risk according to different rules, the memory WebShell detection result is refined, and the detection accuracy is improved.

In a possible design, after using the first preset identifier to perform risk labeling on the classes corresponding to the N code files, and using the class containing the first preset identifier as the first memory WebShell detection result, Also includes:

Marking the third category with a second preset identifier, wherein the second preset identifier corresponds to a memory WebShell risk;

Adding the marked third category to the first memory WebShell detection result to obtain the third memory WebShell detection result; or

The marked third category is added to the second memory WebShell detection result to obtain the third memory WebShell detection result.

Through the above method, the class matching the second preset rule is marked, and the marked class is added to the memory WebShell detection result, so that the memory WebShell detection result is more comprehensive and the detection accuracy is improved.

In a second aspect, the present application provides a memory WebShell detection device, the device comprising:

A screening module, configured to obtain all the classes in the virtual machine corresponding to the target application, and screen out M first classes with risks of memory WebShell from all the classes, wherein the M is an integer greater than or equal to 1;

The first determination module is used to determine the code corresponding to the bytecode of each first type in the memory of the M first types, and obtain M code files;

The detection module is used to perform memory WebShell risk detection on the M code files through K first preset rules, and obtain N code files with memory WebShell risks, wherein one of the first preset rules corresponds to a In-memory WebShell risk, K and N are both integers greater than or equal to 1;

The first labeling module is configured to use a first preset identifier to perform risk annotation on the classes corresponding to the N code files, and use the class including the first preset identifier as the first memory WebShell detection result.

Further, the screening module is specifically used for:

Screening out a second category that does not have source bytecode files locally among all the categories, and using the second category as the first category with WebShell risks; and/or

A third category matching any one of the H second preset rules is screened out from all the categories, and the third category is used as the first category with WebShell risk, wherein , one of the second preset rules corresponds to a memory WebShell risk, and H is an integer greater than or equal to 1.

Further, the first determining module is specifically used for:

Extract the M bytecodes of the first category corresponding to the memory respectively;

Convert the bytecode into code files of M preset types.

Further, the detection module is specifically used for:

Matching the text corresponding to each code file in the M code files with the preset risk level character string respectively;

If there is a first character string consistent with the preset risk level character string in the text corresponding to any code file, determine that the code text to which the first character string belongs has an in-memory WebShell risk; and/or

Detect the number of preset risk characters in the corresponding text of each code file in the M code files;

judging whether the numerical value is greater than a preset threshold;

If there is a first code text whose number of risk characters is greater than a preset threshold, it is determined that the first code text has a memory WebShell risk.

In a possible design, the device further includes:

a scanning module, configured to scan all currently running applications to obtain basic information corresponding to all applications and process information corresponding to all applications respectively, wherein the basic information at least includes application entry complete class information;

A selection module, used for selecting a target application among all the applications according to the basic information corresponding to all the applications;

The loading module is configured to load the basic information corresponding to the target application and the process information corresponding to the target application to the virtual machine corresponding to the target application.

In a possible design, the device further includes:

a second determination module, configured to determine the risk type corresponding to the class containing the first preset identifier in the first memory WebShell detection result;

The first adding module is configured to add the information corresponding to the risk type to the first memory WebShell detection result to obtain the second memory WebShell detection result.

Further, the second determining module is specifically used for:

Matching the second code file of the preset type corresponding to the class of the first preset identifier in the first memory WebShell detection result with any one of the first preset rules;

If the matches are consistent, the memory WebShell risk corresponding to the first preset rule that matches the second code file is determined as the risk type.

In a possible design, the device further includes:

A second labeling module, configured to label the third category with a second preset identifier, wherein the second preset identifier corresponds to a memory WebShell risk;

The second adding module is used to add the marked third category to the first memory WebShell detection result to obtain the third internal memory WebShell detection result; or add the marked third category to the second internal memory WebShell In the detection result, a third memory WebShell detection result is obtained.

In a third aspect, the present application provides an electronic device, comprising:

memory for storing computer programs;

The processor is configured to implement the steps of the above-mentioned memory WebShell detection method when executing the computer program stored in the memory.

In a fourth aspect, the present application provides a computer-readable storage medium, where a computer program is stored in the computer-readable storage medium, and when the computer program is executed by a processor, the above steps of the memory WebShell detection method are implemented.

Based on the above memory WebShell detection method, after preliminary screening of all classes in the virtual machine corresponding to the target application, without comparing the bytecode file corresponding to the target application process information with the original bytecode file, the The code file corresponding to the bytecode in the memory of the filtered class is further detected and marked by the memory WebShell to reduce the false positive rate. At the same time, since the code file is converted from the bytecode extracted from the memory, it is suitable for detecting non-text in-memory WebShells, and can also adapt to encrypted and obfuscated text-type in-memory WebShells. Therefore, it can Improve memory WebShell detection efficiency.

For each aspect of the above-mentioned second aspect to the fourth aspect and the possible technical effect achieved by each aspect, reference is made to the above description of the technical effect achieved by the first aspect or various possible solutions in the first aspect, which will not be repeated here.

Description of drawings

Fig. 1 is the flow chart of a kind of memory WebShell detection method that the application provides;

2 is a schematic diagram of a memory WebShell detection method provided by the application;

3 is a schematic structural diagram of a memory WebShell detection device provided by the application;

FIG. 4 is a schematic structural diagram of an electronic device provided by the present application.

Detailed ways

In order to make the objectives, technical solutions and advantages of the present application clearer, the present application will be further described in detail below with reference to the accompanying drawings. The specific operation methods in the method embodiments may also be applied to the apparatus embodiments or the system embodiments. It should be noted that, in the description of this application, "a plurality" is understood as "at least two". "And/or", which describes the association relationship of the associated objects, means that there can be three kinds of relationships, for example, A and/or B, which can mean that A exists alone, A and B exist at the same time, and B exists alone. A and B are connected, which can be expressed as two cases: A and B are directly connected and A and B are connected through C. In addition, in the description of this application, words such as "first" and "second" are only used for the purpose of distinguishing and describing, and cannot be understood as indicating or implying relative importance, nor can they be understood as indicating or implying order.

The embodiments of the present application will be described in detail below with reference to the accompanying drawings.

The current detection methods for in-memory WebShell are mainly based on WebShell file entity detection methods, such as feature detection method, which extracts malicious features from known WebShell samples and performs pattern matching to detect in-memory WebShell; another example is statistical analysis method , this method uses some statistical methods to identify and detect WebShell files, and then extracts the feature code, information entropy, longest word, coincidence index, compression and other features in the WebShell file for abnormal detection, thereby discovering the memory WebShell; Learning method, which uses decision tree, deep learning and other methods to train samples to obtain a detection model, and then uses the detection model to detect the memory WebShell.

However, the above detection methods based on WebShell file entities are difficult to detect non-text WebShells, and cannot detect textual WebShells that have been processed by obfuscation, encryption, etc. Or the machine learning method, there is a large possibility of false positives and false negatives, resulting in low accuracy of memory WebShell detection.

In order to solve the above problems, the present application provides a memory forensics method. After preliminarily screening all classes in the virtual machine corresponding to the target application, the code files corresponding to the bytecodes in the memory of the filtered classes are further processed into memory. WebShell detection and annotation, because the code file is converted from bytecode extracted from memory, it is suitable for detecting non-text in-memory WebShell, and can also adapt to encrypted and obfuscated text-type in-memory WebShell, Improve memory WebShell detection efficiency.

The methods and devices described in the embodiments of the present application are based on the same technical concept. Since the principles of the problems solved by the methods and devices are similar, the embodiments of the devices and methods can be referred to each other, and repeated descriptions are omitted.

As shown in Figure 1, the flow chart of a three-dimensional model generation method provided by the application specifically includes the following steps:

S11, obtain all classes in the virtual machine corresponding to the target application, and screen out M first classes with risks of memory WebShell from all classes;

In the embodiment of the present application, before performing the memory WebShell detection on the target application, it is first necessary to select the target application from all currently running applications, and load the relevant information of the target application into the virtual machine corresponding to the target application. It can be:

Scan all applications running on the host, and obtain the basic information corresponding to each application and the process information corresponding to each application in all applications, wherein the basic information includes at least the complete class information of the application entry, and can also include the name and version number. , permissions, signature summary information, etc. During this process, if the current application is a JAVA application, you can use the sun.jvmstat.monitor package to write scan code, and scan the current application according to the scan code. Among them, the process information of the current code It can also be obtained by using the command JPS to display all current process information provided by the software development kit JDK, or by the process information command provided by the application platform;

Next, according to the basic information corresponding to each application, a target application is selected from all applications based on user requirements, and then the basic information corresponding to the target application and the process information corresponding to the target application are loaded into the virtual machine corresponding to the target application, For example, if the target application is a JAVA application, the Agent program can be written in the Native method and through the JavaInstrumentation interface, and then the process information corresponding to the target application and the basic information corresponding to the target application can be loaded as parameters through the Agent program. In the JAVA virtual machine (Java Virtual Machine, JVM) corresponding to the target application, the specific loading time may be before the JVM is started, or may be during the running of the JVM.

After the basic information corresponding to the target application and the process information corresponding to the target application are loaded into the virtual machine corresponding to the target application, all classes in the virtual machine are obtained, and the M first ones with memory WebShell risks are screened out from all classes. class, where M is an integer greater than or equal to 1, and the specific screening method can be:

Detect the local source bytecode file path information for each class in all classes. If any class does not have local source bytecode file path information, it indicates that the class without path information does not have a local source bytecode file. , and then filter out the second class that does not have source bytecode files locally in all classes, and use the second class as the first class with WebShell risk;

In addition to the above methods, the specific method to filter out the M first types of memory WebShell risks in all classes can also be:

Determine H second preset rules, where H is an integer greater than or equal to 1, the second preset rules are set according to the memory WebShell characteristics of the preset type, and one second preset rule corresponds to a memory WebShell risk For example, if the WebShell feature of the preset type is that no entity file exists, then the first preset rule corresponding to the WebShell feature is used to detect the memory WebShell risk that no entity file exists. After the second preset rule is determined, each of all the classes is matched with each of the H second preset rules respectively, and will be matched with any one of the second preset rules Consistent third category, as the first category with WebShell risk.

The above two screening methods can be used simultaneously or separately.

Through the above method, all classes in the virtual machine corresponding to the target application are preliminarily screened to narrow the scope of subsequent code risk scanning. The memory WebShell has a good targeting effect, improving the detection accuracy and detection efficiency of the memory WebShell.

S12, determine the codes corresponding to the bytecodes in the memory of each first class in the M first classes, and obtain M code files;

In the application embodiment, after preliminarily screening out M first categories that have memory WebShell risks from all categories, further processing is required for the M first categories, and the specific processing method may be:

Use bytecode enhancement technology to extract M bytecodes corresponding to the first type in memory, and then convert the bytecodes into M code files of preset types, where the preset type can be JAVA or other types. Types of code files, which are specific to user needs.

Through the above processing method, the bytecode in the memory is converted into the corresponding code, so that the subsequent further code risk investigation can be applied to the non-text memory WebShell, and can also be applied to the encrypted and obfuscated WebShell.

S13, perform memory WebShell risk detection on M code files through K first preset rules, and obtain N code files with memory WebShell risks;

In the embodiment of the present application, after the M first types are respectively converted into corresponding M code files, further, K first preset rules are used to perform memory WebShell risk detection on the M code files, where K is greater than or An integer equal to 1, where a first preset rule corresponds to a memory WebShell risk, and the memory WebShell risk corresponding to the first preset rule and the WebShell risk type corresponding to the second preset rule may be different. In other words, the detection method corresponding to the first preset rule may be:

Match the text corresponding to each code file in the M code files with the preset risk level character string respectively, wherein the preset risk level character string is set in advance and can be divided into high risk character string and medium risk character string strings and low-risk strings. Of course, the strings with preset risk levels can also be divided into 1-level risk strings, 2-level risk strings, or 3-level risk strings, etc. The specific risk level classification method is not limited here;

If there is a first character string consistent with the preset risk level character string in the text corresponding to any code file, it is determined that the code text to which the first character string belongs has a memory WebShell risk. For example, when there is a string consistent with a high-risk string in the text corresponding to the code file, it can be determined that the code file has a memory WebShell risk, and the risk level is high risk.

In addition, the detection method corresponding to the first preset rule may also be:

Detect the number of preset risk characters in the text corresponding to each code file in the M code files. For example, if "a" and "b" are preset risk characters, when the text corresponding to the existing code file contains "a" or "" b", then the sum of the number of "a" and the number of "b" is the number of preset risk characters;

Determine whether the value is greater than the preset threshold;

If there is a first code text whose number of risk characters is greater than the preset threshold, it is determined that the first code text has a memory WebShell risk.

Of course, regular matching rules can also be used to perform memory WebShell risk detection on the above M code files, and the specific detection method is not described in detail here.

Through the above method, by performing memory WebShell risk detection on M code files, N code files with memory WebShell risks can be screened, where N is an integer greater than or equal to 1.

S14: Use the first preset identifier to perform risk annotation on the classes corresponding to the N code files, and use the class including the first preset identifier as the first memory WebShell detection result.

In the embodiment of the present application, after determining N code files with risks of memory WebShell, further, use the first preset identifier to carry out risk labeling on the classes corresponding to the N code files, and label the classes corresponding to the N code files with the first preset identifier. Class as the first in-memory WebShell detection result.

In a possible design, in order to make the information contained in the first memory WebShell detection result more comprehensive, the risk types of the classes corresponding to the above N code files may also be added to the first memory WebShell detection result, specifically:

First, determine the risk type corresponding to the class containing the first preset identifier in the first memory WebShell detection result, and the specific method for determining the risk type is:

Match the second code file of the class corresponding to the preset type of the first preset identifier in the first memory WebShell detection result with any first preset rule; if the matching is consistent, the second code file that is consistent with the second code file will be matched The memory WebShell risk corresponding to a preset rule is used as the risk type.

For example, match the second code file of the preset type corresponding to the class containing the first preset identifier in the first memory WebShell detection result with the preset risk level string; If the level string is consistent, the risk type is determined to be a string risk.

For another example, the number of preset risk characters in the second code file is detected, and it is determined whether the number is greater than the preset threshold; if yes, the risk type is determined to be character risk.

Further, the information corresponding to the risk type is added to the first memory WebShell detection result to obtain the second memory WebShell detection result.

Through the above method, the risk type corresponding to the class with memory WebShell risk is further determined, the risk information corresponding to the memory WebShell in the memory WebShell detection result is improved, and the detection accuracy of the memory WebShell is improved.

In a possible design, the third category that matches any of the second preset rules in the detection method shown in FIG. 1 is marked, and the marked third category is added to the above-mentioned first memory WebShell detection Or in the second memory WebShell detection, improve the memory WebShell detection accuracy, specifically:

Marking the third category with a second preset identifier, wherein the second preset identifier corresponds to a memory WebShell risk;

Adding the marked third category to the first memory WebShell detection result to obtain the third memory WebShell detection result; or

The marked third category is added to the second memory WebShell detection result to obtain the third memory WebShell detection result;

The third memory WebShell detection result is used as the final memory WebShell detection result.

Through the above method, the class matching the second preset rule is marked, and the marked class is added to the memory WebShell detection result, so that the memory WebShell detection result is more comprehensive and the detection accuracy is improved.

Based on the memory WebShell detection method provided by this application, after preliminary screening of all classes in the virtual machine corresponding to the target application, there is no need to compare the bytecode file corresponding to the target application process information with the original bytecode file Next, the code file corresponding to the bytecode of the filtered class in the memory is further detected and marked with the memory WebShell to reduce the false positive rate. At the same time, since the code file is converted from the bytecode extracted from the memory, It is suitable for detecting non-text in-memory WebShells, and can also adapt to encrypted and obfuscated text-type in-memory WebShells. Therefore, it can improve the detection accuracy of in-memory WebShells.

Further, in order to describe the memory WebShell detection method provided in the embodiments of the present application in more detail, the method provided by the present application is described in detail below through specific application scenarios.

Specifically, referring to Figure 2, in Figure 2, before performing memory WebShell detection on the target application, first scan the JAVA applications running on the host, and list the basic information and process information of all JAVA applications, and scan all the JAVA applications on the host. The methods of JAVA application include but are not limited to: directly use JPS provided by JDK to obtain all JAVA process information; use sun.jvmstat.monitor package to write scanning code; obtain process information instructions on the platform.

Next, according to the basic information corresponding to each JAVA application in all JAVA applications, select the target JAVA application among all JAVA applications, and then use the JAVA Agent technology to convert the basic information corresponding to the target JAVA application and the process information corresponding to the target JAVA application. Loaded into the target JVM corresponding to the target JAVA application.

Further, obtain all the classes currently loaded in the target JVM, wherein, the method of obtaining all the classes loaded in the target JVM includes but is not limited to using the Instrumentation interface.

Next, preliminarily extract class information and bytecodes that have WebShell risks from all classes. In this example, two methods are used, one of which is to extract classes that do not have local bytecode files in all classes. Information and bytecode, that is: search for the path information of the source bytecode file in all class information. If there is no path information for any class, it means that the corresponding bytecode file does not exist locally for this class. At this time, Extracting this type of information and its in-memory bytecode, wherein the in-memory bytecode is extracted using bytecode enhancement technology; another method is to extract using the first custom rule, wherein the first custom Rules include, but are not limited to, feature matching rules.

Further, perform the first risk determination and labeling on all the classes with WebShell risks extracted in the above process. In the process of extracting classes, each extracted class corresponds to a rule, and each rule is directed to A Java application memory WebShell risk.

Further, the bytecodes in the memory corresponding to all the extracted classes are converted into JAVA codes, and the process of converting the bytecodes into Java codes can be realized by using open-source decompilation technology or implemented decompilation tools.

Further, use the second custom rule to detect the JAVA code, wherein the second custom rule may be to detect the JAVA code by means of conventional string matching, frequency matching, or regular matching, etc., and perform the first step on the class according to the detection result. Secondary risk determination and labeling, where the risk includes but is not limited to the existence of a specified high-risk string, or the occurrence frequency of the risk string exceeds a specified threshold, or the regular matching method is used to match the risk string, etc. In this way, the detection result can be risk-marked.

Finally, all classes with memory WebShell risks in the above process, the first risk determination and annotation information, and the second risk determination and annotation information are used as the detection results of the in-memory WebShell of the target JAVA application.

Through the above-mentioned memory WebShell detection method, after preliminary screening of all classes in the target JVM, the first memory WebShell detection risk determination and labeling are performed on the preliminarily screened classes, so as to narrow the investigation scope of subsequent code risk scanning, and The code file corresponding to the bytecode in the memory of the filtered class is used for the second memory WebShell detection and annotation. In the process of two risk determination and annotation, the bytecode file corresponding to the target application process information is not required. Compared with the original bytecode file, the false positive rate can be reduced. At the same time, since the code file is converted from the bytecode extracted from the memory, it is suitable for detecting non-text in-memory WebShells, and can also adapt to encrypted and obfuscated text-type in-memory WebShells. In-memory WebShell detection accuracy. Finally, the results of the two risk determinations and annotations are used as the in-memory WebShell detection results of the target JAVA application, which can further improve the in-memory WebShell detection accuracy.

Based on the same inventive concept, an embodiment of the present application also provides a memory WebShell detection device, as shown in FIG. 3 , which is a schematic structural diagram of a memory WebShell detection device in the present application, and the device includes:

The screening module 31 is used to obtain all the classes in the virtual machine corresponding to the target application, and screen out M first classes with risks of memory WebShell from all the classes, wherein the M is an integer greater than or equal to 1;

The first determination module 32 is used to determine the code corresponding to the bytecode of each first type in the memory of the M first types, and obtain M code files;

The detection module 33 is configured to perform memory WebShell risk detection on the M code files through K first preset rules, and obtain N code files with memory WebShell risks, wherein one of the first preset rules corresponds to An in-memory WebShell risk, where K and N are both integers greater than or equal to 1;

The first labeling module 34 is configured to use the first preset identifier to perform risk annotation on the classes corresponding to the N code files, and use the class including the first preset identifier as the first memory WebShell detection result.

Further, the screening module 31 is specifically used for:

Screening out a second category that does not have source bytecode files locally among all the categories, and using the second category as the first category with WebShell risks; and/or

A third category matching any one of the H second preset rules is screened out from all the categories, and the third category is used as the first category with WebShell risk, wherein , one of the second preset rules corresponds to a memory WebShell risk, and H is an integer greater than or equal to 1.

Further, the first determining module 32 is specifically used for:

Extract the M bytecodes of the first category corresponding to the memory respectively;

Convert the bytecode into code files of M preset types.

Further, the detection module 33 is specifically used for:

Matching the text corresponding to each code file in the M code files with the preset risk level character string respectively;

If there is a first character string consistent with the preset risk level character string in the text corresponding to any code file, determine that the code text to which the first character string belongs has an in-memory WebShell risk; and/or

Detecting the preset risk character value in the corresponding text of each code file in the M code files;

judging whether the numerical value is greater than a preset threshold;

If there is a first code text whose number of risk characters is greater than a preset threshold, it is determined that the first code text has a memory WebShell risk.

In a possible design, the device further includes:

a scanning module, configured to scan all currently running applications to obtain basic information corresponding to all applications and process information corresponding to all applications respectively, wherein the basic information at least includes application entry complete class information;

A selection module, used for selecting a target application among all the applications according to the basic information corresponding to all the applications;

The loading module is configured to load the basic information corresponding to the target application and the process information corresponding to the target application to the virtual machine corresponding to the target application.

In a possible design, the device further includes:

a second determination module, configured to determine the risk type corresponding to the class containing the first preset identifier in the first memory WebShell detection result;

The first adding module is configured to add the information corresponding to the risk type to the first memory WebShell detection result to obtain the second memory WebShell detection result.

Further, the second determining module is specifically used for:

Matching the second code file of the preset type corresponding to the class of the first preset identifier in the first memory WebShell detection result with any one of the first preset rules;

If the matches are consistent, the memory WebShell risk corresponding to the first preset rule that matches the second code file is determined as the risk type.

In a possible design, the device further includes:

A second labeling module, configured to label the third category with a second preset identifier, wherein the second preset identifier corresponds to a memory WebShell risk;

The second adding module is used to add the marked third category to the first memory WebShell detection result to obtain the third internal memory WebShell detection result; or add the marked third category to the second internal memory WebShell In the detection result, a third memory WebShell detection result is obtained.

Based on the above-mentioned memory WebShell detection device, after preliminarily screening all classes in the virtual machine corresponding to the target application, the code files corresponding to the bytecodes of the filtered classes in the memory are further detected and marked with the memory WebShell. It is converted from the bytecode extracted from the memory. It is suitable for detecting non-text in-memory WebShells, and can also adapt to encrypted and obfuscated text-type in-memory WebShells, improving the detection accuracy of in-memory WebShells.

Based on the same inventive concept, an embodiment of the present application also provides an electronic device, which can implement the functions of the aforementioned memory WebShell detection device. Referring to FIG. 4 , the electronic device includes:

At least one processor 41 and the memory 42 connected to the at least one processor 41, the specific connection medium between the processor 41 and the memory 42 is not limited in the embodiments of the present application, and in FIG. Take the connection through the bus 40 as an example. The bus 40 is represented by a thick line in FIG. 4 , and the connection manners between other components are only for schematic illustration and are not intended to be limiting. The bus 40 can be divided into an address bus, a data bus, a control bus, etc. For convenience of illustration, only one thick line is used in FIG. 4 , but it does not mean that there is only one bus or one type of bus. Alternatively, the processor 41 may also be called a controller, and the name is not limited.

In this embodiment of the present application, the memory 42 stores instructions that can be executed by at least one processor 41 , and the at least one processor 41 can execute the memory WebShell detection method discussed above by executing the instructions stored in the memory 42 . The processor 41 can implement the functions of each module in the apparatus shown in FIG. 3 .

Among them, the processor 41 is the control center of the device, and can use various interfaces and lines to connect various parts of the entire control device, by running or executing the instructions stored in the memory 42 and calling the data stored in the memory 42, the Various functions and processing data of the device to monitor the device as a whole.

In a possible design, the processor 41 may include one or more processing units, and the processor 41 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface and application programs etc., the modem processor mainly deals with wireless communication. It can be understood that, the above-mentioned modulation and demodulation processor may not be integrated into the processor 41 . In some embodiments, the processor 41 and the memory 42 may be implemented on the same chip, and in some embodiments, they may be implemented separately on separate chips.

Processor 41 may be a general-purpose processor, such as a central processing unit (CPU), digital signal processor, application specific integrated circuit, field programmable gate array or other programmable logic device, discrete gate or transistor logic device, discrete hardware components, may The methods, steps, and logic block diagrams disclosed in the embodiments of the present application are realized or executed. A general purpose processor may be a microprocessor or any conventional processor or the like. The steps of the memory WebShell detection method disclosed in conjunction with the embodiments of the present application may be directly embodied as being executed by a hardware processor, or executed by a combination of hardware and software modules in the processor.

The memory 42, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs and modules. The memory 42 may include at least one type of storage medium, such as flash memory, hard disk, multimedia card, card-type memory, random access memory (Random Access Memory, RAM), static random access memory (Static Random Access Memory, SRAM), Programmable Read Only Memory (PROM), Read Only Memory (ROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Magnetic Memory, Disk , CD, etc. Memory 42 is, but is not limited to, any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer. The memory 42 in this embodiment of the present application may also be a circuit or any other device capable of implementing a storage function, for storing program instructions and/or data.

By designing and programming the processor 31, the code corresponding to the memory WebShell detection method introduced in the foregoing embodiment can be solidified into the chip, so that the chip can execute the memory WebShell detection method of the embodiment shown in FIG. 1 when running. A step of. How to design and program the processor 41 is known to those skilled in the art, and details are not described here.

Based on the same inventive concept, an embodiment of the present application also provides a storage medium, where computer instructions are stored in the storage medium, and when the computer instructions are executed on a computer, the computer executes the memory WebShell detection method discussed above.

In some possible implementations, various aspects of the memory WebShell detection method provided by the present application can also be implemented in the form of a program product, which includes program code, and when the program product runs on the device, the program code is used to make the The control device executes the steps in the memory WebShell detection method according to various exemplary embodiments of the present application described above in this specification.

As will be appreciated by those skilled in the art, the embodiments of the present application may be provided as a method, a system, or a computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein.

The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present application. It will be understood that each flow and/or block in the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to the processor of a general purpose computer, special purpose computer, embedded processor or other programmable data processing device to produce a machine such that the instructions executed by the processor of the computer or other programmable data processing device produce Means for implementing the functions specified in a flow or flow of a flowchart and/or a block or blocks of a block diagram.

These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory result in an article of manufacture comprising instruction means, the instructions The apparatus implements the functions specified in the flow or flow of the flowcharts and/or the block or blocks of the block diagrams.

These computer program instructions can also be loaded on a computer or other programmable data processing device to cause a series of operational steps to be performed on the computer or other programmable device to produce a computer-implemented process such that The instructions provide steps for implementing the functions specified in the flow or blocks of the flowcharts and/or the block or blocks of the block diagrams.

Obviously, those skilled in the art can make various changes and modifications to the present application without departing from the spirit and scope of the present application. Thus, if these modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is also intended to include these modifications and variations.

Claims (18)

1. A memory WebShell detection method is characterized by comprising the following steps:

acquiring all classes in a virtual machine corresponding to a target application, and screening M first classes with memory WebShell risk in all the classes, wherein M is an integer greater than or equal to 1;

determining codes corresponding to the byte codes of each first type in the M first types in the memory respectively to obtain M code files;

performing memory WebShell risk detection on the M code files through K first preset rules to obtain N code files with memory WebShell risks, wherein one first preset rule corresponds to one memory WebShell risk, and K and N are integers greater than or equal to 1;

and carrying out risk marking on the classes corresponding to the N code files by using a first preset identifier, and taking the class containing the first preset identifier as a first memory WebShell detection result.

2. The method of claim 1, wherein said screening M first classes among said all classes for risk of WebShell comprises:

screening out a second class which does not have a source byte code file locally in all the classes, and taking the second class as the first class which has the WebShell risk; and/or

And screening out a third class matched with any one of H second preset rules from all the classes, and taking the third class as the first class with the WebShell risk, wherein one second preset rule corresponds to the memory WebShell risk, and H is an integer greater than or equal to 1.

3. The method of claim 1, wherein said determining the code corresponding to each of said first classes, respectively, to obtain M code files, comprises:

extracting byte codes in M first classes respectively corresponding to the memories;

and converting the byte codes into M code files of preset types.

4. The method as claimed in claim 1, wherein the performing memory WebShell risk detection on the M code files through K first preset rules to obtain N code files with memory WebShell risk comprises:

respectively matching the text corresponding to each code file in the M code files with a preset risk level character string;

if a first character string consistent with the preset risk level character string exists in a text corresponding to any code file, determining that the code text to which the first character string belongs has a memory WebShell risk; and/or

Detecting the number of preset risk characters in the text corresponding to each code file in the M code files;

judging whether the numerical values are larger than a preset threshold value or not;

and if the first code text with the risk character number larger than the preset threshold exists, determining that the memory WebShell risk exists in the first code text.

5. The method of claim 1, prior to obtaining all classes in the virtual machine corresponding to the target application, further comprising:

scanning all currently running applications to obtain basic information corresponding to each application in all the applications and process information corresponding to each application, wherein the basic information at least comprises complete class information of an application entrance;

selecting a target application from all the applications according to the basic information corresponding to each application in all the applications;

and loading the basic information corresponding to the target application and the process information corresponding to the target application to a virtual machine corresponding to the target application.

6. The method as claimed in claim 1, wherein after performing risk labeling on the classes corresponding to the N code files by using a first preset identifier and using the class containing the first preset identifier as a first memory WebShell detection result, the method further comprises:

determining a risk type corresponding to the class containing the first preset identifier in the first memory WebShell detection result;

and adding the information corresponding to the risk type into the first memory WebShell detection result to obtain a second memory WebShell detection result.

7. The method as claimed in claim 6, wherein determining the risk type corresponding to the class including the first preset identifier in the first memory WebShell detection result includes:

matching a second code file of a preset type corresponding to the class containing the first preset identification in the first memory WebShell detection result with any one first preset rule;

and if the matching is consistent, determining the memory WebShell risk corresponding to the first preset rule which is consistent with the matching of the second code file as a risk type.

8. The method as claimed in claim 2 or claim 6, wherein after performing risk labeling on the classes corresponding to the N code files by using a first preset identifier and taking the class containing the first preset identifier as a first memory WebShell detection result, the method further comprises:

marking the third category by using a second preset identification, wherein the second preset identification corresponds to a memory WebShell risk;

adding the labeled third class into the first memory WebShell detection result to obtain a third memory WebShell detection result; or

And adding the labeled third class into the second memory WebShell detection result to obtain a third memory WebShell detection result.

9. A memory WebShell detection device, the device comprising:

the system comprises a screening module, a judging module and a judging module, wherein the screening module is used for acquiring all classes in a virtual machine corresponding to a target application and screening M first classes with memory WebShell risk in all the classes, and M is an integer greater than or equal to 1;

a first determining module, configured to determine codes corresponding to the bytecode of each of the M first classes in the memory, to obtain M code files;

the detection module is used for carrying out memory WebShell risk detection on the M code files through K first preset rules to obtain N code files with memory WebShell risks, wherein one first preset rule corresponds to one memory WebShell risk, and K and N are integers greater than or equal to 1;

and the first marking module is used for carrying out risk marking on the classes corresponding to the N code files by using a first preset identifier, and taking the class containing the first preset identifier as a first memory WebShell detection result.

10. The apparatus of claim 9, wherein the screening module is specifically configured to:

screening out a second class which does not have a source byte code file locally in all the classes, and taking the second class as the first class which has the WebShell risk; and/or

And screening out a third class matched with any one of H second preset rules from all the classes, and taking the third class as the first class with the WebShell risk, wherein one second preset rule corresponds to the memory WebShell risk, and H is an integer greater than or equal to 1.

11. The apparatus of claim 9, wherein the first determining module is specifically configured to:

extracting byte codes in M first classes respectively corresponding to the memories;

and converting the byte codes into M code files of preset types.

12. The apparatus of claim 9, wherein the detection module is specifically configured to:

respectively matching the text corresponding to each code file in the M code files with a preset risk level character string;

if a first character string consistent with the preset risk level character string exists in a text corresponding to any code file, determining that the code text to which the first character string belongs has a memory WebShell risk; and/or

Detecting the number of preset risk characters in the text corresponding to each code file in the M code files;

judging whether the numerical values are larger than a preset threshold value or not;

and if the first code text with the risk character number larger than the preset threshold exists, determining that the memory WebShell risk exists in the first code text.

13. The apparatus of claim 9, wherein the apparatus further comprises:

the system comprises a scanning module, a processing module and a processing module, wherein the scanning module is used for scanning all currently running applications to obtain basic information respectively corresponding to all the applications and process information respectively corresponding to all the applications, and the basic information at least comprises application entry complete class information;

the selection module is used for selecting a target application from all the applications according to the basic information corresponding to all the applications;

and the loading module is used for loading the basic information corresponding to the target application and the process information corresponding to the target application to the virtual machine corresponding to the target application.

14. The apparatus of claim 9, wherein the apparatus further comprises:

a second determining module, configured to determine a risk type corresponding to the class including the first preset identifier in the first memory WebShell detection result;

and the first adding module is used for adding the information corresponding to the risk type into the first memory WebShell detection result to obtain a second memory WebShell detection result.

15. The apparatus of claim 14, wherein the second determining module is specifically configured to:

matching a second code file of a preset type corresponding to the class containing the first preset identification in the first memory WebShell detection result with any one first preset rule;

and if the matching is consistent, determining the memory WebShell risk corresponding to the first preset rule which is consistent with the matching of the second code file as a risk type.

16. The apparatus of claim 10 or claim 14, wherein the apparatus further comprises:

the second marking module is used for marking the third category by using a second preset identification, wherein the second preset identification corresponds to a memory WebShell risk;

the second adding module is used for adding the labeled third class to the first memory WebShell detection result to obtain a third memory WebShell detection result; or adding the labeled third class to the second memory WebShell detection result to obtain a third memory WebShell detection result.

17. An electronic device, comprising:

a memory for storing a computer program;

a processor for implementing the method steps of any one of claims 1-8 when executing the computer program stored on the memory.

18. A computer-readable storage medium, characterized in that a computer program is stored in the computer-readable storage medium, which computer program, when being executed by a processor, carries out the method steps of any one of claims 1-8.

Images