CN106778244B

CN106778244B - Virtual machine-based kernel vulnerability detection process protection method and device

Info

Publication number: CN106778244B
Application number: CN201611071694.3A
Authority: CN
Inventors: 李琦
Original assignee: Beijing Qihoo Technology Co Ltd; Qizhi Software Beijing Co Ltd
Current assignee: Beijing Qizhi Business Consulting Co ltd; Beijing Qihoo Technology Co Ltd; 360 Digital Security Technology Group Co Ltd
Priority date: 2016-11-28
Filing date: 2016-11-28
Publication date: 2019-12-06
Anticipated expiration: 2036-11-28
Also published as: CN106778244A

Abstract

The invention discloses a kernel vulnerability detection process protection method and device based on a virtual machine. The method comprises the following steps: acquiring relevant information of each detection subprocess, and writing the relevant information of each detection subprocess into a process filtering list; acquiring relevant information of a current context process and relevant information of an operation target process by using a hook technology before calling a specified API; judging whether the relevant information of the operation target process is recorded in the process filtering list or not and whether the relevant information of the current context process is not recorded in the process filtering list or not; if yes, terminating the calling of the specified API. By using the method and the device, the address space of the detection process running in the virtual machine sandbox isolation environment can be protected, the malicious sample process escaping from the sandbox is prevented from accessing, the confidential information is prevented from being stolen, and the security of kernel vulnerability detection in the virtual machine sandbox isolation environment is improved.

Description

Virtual machine-based kernel vulnerability detection process protection method and device

Technical Field

The invention relates to the technical field of computer security, in particular to a kernel vulnerability detection process protection method and device based on a virtual machine.

Background

The network malicious behavior refers to the behavior that hardware, software of a network system and data in the system are damaged, changed and leaked under the attack of malicious codes, so that the system cannot continuously, reliably and normally run, and network service is interrupted. With the popularization of informatization, a great amount of new applications of networks appear, behaviors presented by network malicious codes are also endless, and at present, the most popular network malicious behaviors are webpage horse hanging, account stealing, port scanning, vulnerability scanning, ARP (Address Resolution Protocol) cheating, IP (Internet Protocol) hijacking, DDOS (Distributed Denial of Service) attack, overflow attack, trojan attack and the like.

A vulnerability is a flaw in the hardware, software, protocol implementation, or system security policy that may allow an attacker to access or destroy the system without authorization. The kernel is used as the core of the operating system, and how to detect kernel bugs is the central importance of security protection work. In the prior art, when a hacker invades a system, the highest authority of the system is often obtained in a way of privilege escalation, so that the control right of an operating system is obtained. In short, the privilege escalation is to elevate a user with low privilege and much restricted to the highest privilege (such as administrator privilege) in the system. The authority control is a system safety foundation stone and is a foundation stone of all safety software, and once the threshold is broken, any defense measures are invalid. Therefore, how to effectively detect the kernel vulnerability and prevent hackers from performing system attacks in an authorization manner becomes an urgent problem to be solved in the prior art. In the kernel vulnerability detection process, how to avoid malicious sample processes from accessing the detection process is also an important problem for damaging the detection process.

disclosure of Invention

in view of the above, the present invention is proposed to provide a virtual machine based kernel vulnerability detection process protection method and apparatus that overcomes or at least partially solves the above problems.

According to one aspect of the invention, a kernel vulnerability detection process protection method based on a virtual machine is provided, the method runs in a virtual machine sandbox isolation environment, and comprises the following steps:

Acquiring relevant information of each detection subprocess, and writing the relevant information of each detection subprocess into a process filtering list;

Acquiring relevant information of a current context process and relevant information of an operation target process by using a hook technology before calling a specified API;

Judging whether the relevant information of the operation target process is recorded in the process filtering list or not and whether the relevant information of the current context process is not recorded in the process filtering list or not;

If yes, terminating the calling of the specified API.

according to another aspect of the present invention, there is provided a kernel vulnerability detection process protection apparatus based on a virtual machine, the apparatus operating in a virtual machine sandbox isolation environment, the apparatus including:

The writing module is suitable for acquiring relevant information of each detection subprocess and writing the relevant information of each detection subprocess into the process filtering list;

The hook processing module is suitable for acquiring the related information of the current context process and the related information of the operation target process by utilizing a hook technology before calling the appointed API;

The judging module is suitable for judging whether the relevant information of the operation target process is recorded in the process filtering list or not and whether the relevant information of the current context process is not recorded in the process filtering list or not;

And the termination module is suitable for terminating the calling of the appointed API if the judgment module judges that the relevant information of the operation target process is recorded in the process filtering list and the relevant information of the current context process is not recorded in the process filtering list.

According to the kernel vulnerability detection process protection method and device based on the virtual machine, provided by the invention, the relevant information of each detection sub-process is written into the process filtering list, the relevant information of the current context process and the relevant information of the operation target process are obtained by using the hook before the appointed API is called, and whether the calling of the appointed API is terminated is judged by matching the relevant information of the current context process and the relevant information of the operation target process with the process filtering list. By using the method and the device, the address space of the detection process running in the virtual machine sandbox isolation environment can be protected, the malicious sample process escaping from the sandbox is prevented from accessing, the confidential information is prevented from being stolen, and the security of kernel vulnerability detection in the virtual machine sandbox isolation environment is improved.

The foregoing description is only an overview of the technical solutions of the present invention, and the embodiments of the present invention are described below in order to make the technical means of the present invention more clearly understood and to make the above and other objects, features, and advantages of the present invention more clearly understandable.

Drawings

Various other advantages and benefits will become apparent to those of ordinary skill in the art upon reading the following detailed description of the preferred embodiments. The drawings are only for purposes of illustrating the preferred embodiments and are not to be construed as limiting the invention. Also, like reference numerals are used to refer to like parts throughout the drawings. In the drawings:

FIG. 1 is a flowchart illustrating a method for virtual machine-based kernel vulnerability detection, according to an embodiment of the present invention;

FIG. 2 is a flowchart illustrating a virtual machine-based kernel vulnerability detection method according to another embodiment of the present invention;

FIG. 3 is a flowchart illustrating a virtual machine-based kernel vulnerability detection method according to another embodiment of the present invention;

FIG. 4 is a flowchart illustrating a virtual machine-based kernel vulnerability detection method according to another embodiment of the present invention;

FIG. 5 is a flowchart illustrating a method for protecting a kernel vulnerability detection process based on a virtual machine according to an embodiment of the present invention;

FIG. 6 is a flowchart illustrating a method for virtual machine-based kernel vulnerability detection file protection, according to an embodiment of the present invention;

FIG. 7 is a functional block diagram of a kernel vulnerability detection apparatus based on a virtual machine according to an embodiment of the present invention;

FIG. 8 is a functional block diagram of a kernel vulnerability detection apparatus based on a virtual machine according to another embodiment of the present invention;

FIG. 9 illustrates a functional block diagram of virtual machine-based kernel vulnerability detection process protection, according to one embodiment of the present invention;

FIG. 10 illustrates a functional block diagram of virtual machine-based kernel vulnerability detection file protection, according to one embodiment of the present invention.

Detailed Description

Exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be embodied in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

fig. 1 is a flowchart illustrating a virtual machine-based kernel vulnerability detection method according to an embodiment of the present invention. The method runs in a sandbox isolation environment of a virtual machine at a server side and is used for performing dynamic kernel vulnerability utilization detection on a specified sample file. As shown in fig. 1, the method comprises the steps of:

Step S101, starting a communication agent process, wherein the communication agent process monitors a designated port, waits for and receives a detection packet and a sample file transmitted by an external host of the virtual machine, and respectively stores the detection packet and the sample file into a detection directory and a temporary directory.

The communication agent process is responsible for data interaction and file transfer with an external host of the virtual machine. When the operation system of the virtual machine at the server is started, the communication agent process is started automatically. And the communication agent process monitors the designated port, waits for and receives the detection packet and the sample file transmitted by the relevant process of the external host of the virtual machine. The communication agent process decompresses the detection packet and stores the decompressed file in a detection directory; in addition, the communication agent process stores the sample file under a temporary directory. Subsequently, the communication agent thread starts a scheduling management and control process in the detection packet.

Step S102, starting a scheduling control process in the detection package, wherein the scheduling control process acquires a sample file storage path, identifies the type of the sample file, and selects a detection mode and each detection function point according to configuration options in a general detection configuration file to create a target detection configuration file aiming at the sample file.

After the scheduling control process is started, the scheduling control process acquires a sample file storage path and identifies the type of the sample file. And then, the scheduling management and control process reads the self-associated general detection configuration file, selects a detection mode and each detection function point according to the type of the sample file, initializes each function of the scheduling management and control process, and creates a target detection configuration file aiming at the sample file. Then, the scheduling management and control process starts the auxiliary detection process, and transfers the storage path (which may be a URL) of the sample file to the auxiliary detection process in a parametric manner.

step S103, starting an auxiliary detection process, wherein the auxiliary detection process controls the on-off of each detection function point by using the target detection configuration file.

after the auxiliary detection process is started, the auxiliary detection process is initialized according to the target detection configuration file, a driving program of the core detection process is loaded, and the target detection configuration file is used for controlling the on-off of each detection function point.

And step S104, starting a core detection process, wherein the core detection process receives the related information of the sample file and the switch information of each detection function point sent by the auxiliary detection process, executes the detection of the vulnerability, generates a log file according to the detection result, and stores the log file into a log directory.

And after the auxiliary detection process loads the driver of the core detection process, the core detection process is started. And the core detection process receives the related information of the sample file and the switch information of each detection function point sent by the auxiliary detection process and executes initialization operation. And then, executing the detection of the sample file according to the related information of the sample file and the switch information of each detection function point, generating a log file according to the detection result, and storing the log file into a log directory.

The kernel vulnerability detection method based on the virtual machine provided by this embodiment operates in a virtual machine sandbox isolation environment, realizes data interaction and file transfer with an external host of the virtual machine through a communication agent process, and assists a core detection process to realize detection of a sample file by means of a scheduling management and control process and an auxiliary detection process. The method isolates the detection of the kernel vulnerability from the outside, provides a closed detection environment for the suspicious sample, does not cause damage to the server side even if the suspicious sample really has the vulnerability, and provides a safe and efficient kernel vulnerability detection mechanism.

Fig. 2 is a flowchart illustrating a virtual machine-based kernel vulnerability detection method according to another embodiment of the present invention. The method describes an overall scheme of kernel vulnerability detection based on a virtual machine, and particularly the method runs in a sandbox isolation environment of the virtual machine at a server side and is used for performing dynamic kernel vulnerability utilization detection aiming at a specified sample file. As shown in fig. 2, the method comprises the steps of:

Step S201, when the operating system of the server-side virtual machine is started, the communication agent process is self-started.

The communication agent process is responsible for data interaction and file transfer with an external host of the virtual machine. When the operation system of the virtual machine at the server is started, the communication agent process is started automatically.

Step S202, the communication agent process monitors the appointed port and waits for data.

the server-side virtual machine provides a designated port for accessing to the virtual external host, and the communication agent process monitors the designated port after starting and waits for data sent by the virtual external host.

Step S203, the communication agent process receives the detection packet and the sample file transmitted by the external host of the virtual machine, and stores the detection packet and the sample file in the detection directory and the temporary directory respectively.

After receiving a detection packet and a sample file transmitted by an external host of the virtual machine through a designated port, the communication agent process decompresses the detection packet, and stores the decompressed file into a detection directory, wherein the detection directory can be a randomly generated directory; in addition, the communication agent process stores the sample file under a temporary directory.

Step S204, the communication agent process starts a scheduling management and control process.

And the communication agent process sends a starting command for starting the scheduling management and control process.

Step S205, the communication agent process creates a message communication thread, and establishes a communication connection with the scheduling management and control process.

After the scheduling management and control process is started, the communication agent process creates a message communication thread, and optionally, establishes a communication connection with the scheduling management and control process through a Remote Procedure Call (RPC) Protocol. Here, RPC is a mechanism in the XMLRPCLIB library, and XML RPC is a remote procedure call mechanism using HTTP protocol as a transport protocol, and transmits commands and data using XML text. By using the communication connection, the subsequently received message data packet from the scheduling control process can be forwarded to the external host of the virtual machine in real time.

In step S206, the scheduling management and control process initializes its own function.

and after the scheduling control process is started, the scheduling control process acquires a sample file storage path and identifies the type of the sample file. And then, the scheduling management and control process reads the self-associated general detection configuration file, selects a detection mode and each detection function point according to the type of the sample file, and initializes each function of the scheduling management and control process. In addition, the scheduling management and control process selects a timeout limiting condition according to the configuration options in the general detection configuration file, wherein the timeout limiting condition specifically limits the duration of the detection executed by the core detection process. By configuring the overtime limiting condition, the subsequent detection aiming at a certain sample file is prevented from occupying too long time, and the detection efficiency is improved.

Step S207, the scheduling management and control process creates a screen capturing thread and/or a mouse simulation clicking thread.

Optionally, the scheduling management process creates a screen-shot thread and/or a mouse-simulated click thread. The screen capturing thread is used for capturing a screen of a server where the virtual machine is located, and captured screen images can be sent to an external host of the virtual machine through a communication agent process. The mouse simulation click thread is used for randomly simulating mouse click operation aiming at the screen coordinates and simulating the mouse click operation aiming at the specific control.

Step S208, the scheduling management and control process creates a target detection configuration file aiming at the sample file, starts the auxiliary detection process, and transmits the storage path of the sample file to the auxiliary detection process in a parameter mode.

And the scheduling management and control process selects and configures the configuration options by reading the general detection configuration file to obtain a target detection configuration file for the sample file. For different types of sample files, detection modes and configured detection function points are different, and the scheduling management and control process can create customized target detection configuration files for the different types of sample files. And then, the scheduling management and control process starts an auxiliary detection process, and the storage path of the sample file is transmitted to the auxiliary detection process in a command line parameter mode.

In step S209, the screen capture thread captures the screen image every predetermined time, and sends the captured screen image to the communication agent process in real time.

Step S210, the mouse click simulation thread randomly simulates mouse click operation aiming at the screen coordinate and simulates mouse click operation aiming at the specific control.

And step S211, initializing the auxiliary detection process according to the target detection configuration file, and controlling the switch of each detection function point by using the target detection configuration file.

The auxiliary detection process initializes the self functions by analyzing the command line parameters and the target detection configuration file. Specifically, the auxiliary detection process analyzes and obtains basic information such as a sample file storage path, a detection mode, each detection function point, and other detection function configuration options, calculates the MD5 of the sample file, and controls the switch of each detection function point. The MD5 of the sample file obtained through calculation can associate sample data generated in a subsequent detection process with task data, and one sample file may correspond to a plurality of detection tasks. Sample data may also be associated with trojan information, VT, meta-killing engines by MD 5. In addition, the MD5 can also be used for classifying and displaying URL, Trojan and APT samples which are stored uniformly.

In step S212, the auxiliary detection process loads a driver of the core detection process to start the core detection process.

Step S213, the auxiliary detection process sends the related information of the sample file and the switch information of each detection function point by means of the IO control code.

And the auxiliary detection process sends the related information of the sample file and the switch information of each detection function point to the core detection process in an IO control code mode so as to start the monitoring of the kernel layer vulnerability exploitation behavior.

Step S214, the auxiliary detection process starts a sample process, so that the sample process runs the sample file.

In step S215, the kernel detection process performs an initialization operation.

When the driver of the kernel detection process is loaded, relevant data structure objects and variables required by the driver are initialized, and the relevant data structure objects and variables are closely associated with each function detection point.

In step S216, the core detection process creates a logging thread.

In order to facilitate recording of the detection process, a logging thread is created for recording logs generated during the detection process.

Step S217, the core detection process receives the relevant information of the sample file and the switch information of each detection function point, which are sent by the auxiliary detection process in the IO control code manner.

And the core detection process receives various IO control codes sent by the auxiliary detection process, and analyzes the IO control codes to obtain the related information of the sample file and the switch information of each detection function point. And controlling to start the monitoring of the corresponding detection function points according to the switch information of each detection function point.

In step S218, the kernel detection process performs vulnerability detection.

The bugs detectable by the core detection process include URLs relating to malicious web pages and sample targets relating to various bugs, viruses, trojans, attacks. In addition, the sample object further includes: 0Day, NDay, exposure period 0Day, location hang horse information, important web sites, location hang horse follow-up, etc. Where 0Day is a vulnerability that has been discovered (and possibly unpublished), and no relevant patch has been available to the authorities. These vulnerabilities are exploited immediately after discovery, e.g., registry modification, file download, running system files with 0 Day. The format of the sample object may be a file, an executable program, etc., and the present invention is not limited thereto.

Step S219, the log recording thread generates a log file according to the detection result, and stores the log file into a log directory.

The subsequent authentication engine can read the log file, capture various required log information in the authentication engine (statically and dynamically), analyze and screen the detection result, and judge the basic rule. Wherein the rules of the background can be up to several hundreds. The analysis summary is to identify the hazard level of a sample (black, white, grey) by using rule and association analysis in combination with static and dynamic log data. The screening mainly has the function of filtering out samples which hit the detected behavior characteristics and some samples with high suspicious behavior characteristics, and distributing the data according to the requirements of different groups.

Step S220, in the above detection process, determining whether the timeout limiting condition is met in real time, if yes, ending the detection process, packaging the detection result into a data packet, and sending the data packet to the communication agent process, so that the communication agent process sends the data packet to the external host of the virtual machine.

The kernel vulnerability detection method based on the virtual machine provided by this embodiment operates in a virtual machine sandbox isolation environment, realizes data interaction and file transfer with an external host of the virtual machine through a communication agent process, and assists a core detection process to realize detection of a sample file by means of a scheduling management and control process and an auxiliary detection process. The method isolates the detection of the kernel vulnerability from the outside, provides a closed detection environment for the suspicious sample, does not cause damage to the server side even if the suspicious sample really has the vulnerability, and provides a safe and efficient kernel vulnerability detection mechanism. According to the method, the scheduling control process selects the overtime limiting condition according to the configuration options in the general detection configuration file, and the overtime limiting condition is configured, so that the follow-up detection for a certain sample file is prevented from occupying too long time, and the detection efficiency is improved. The scheduling management and control process creates a screen capturing thread and/or a mouse simulation clicking thread, images displayed by a server screen can be transmitted to the external host of the virtual machine, a user of the external host of the virtual machine can check the progress and specific conditions of the detection process, and the visualization effect is good.

Fig. 3 is a flowchart illustrating a virtual machine-based kernel vulnerability detection method according to another embodiment of the present invention. The embodiment mainly explains the working process of the core detection process in detail, and describes the specific content of vulnerability detection executed by the core detection process in detail. However, it should be noted that the method of the present embodiment is an independent solution for implementing vulnerability detection, and it can be implemented without depending on the environment and premise described in the foregoing embodiments. The method of this embodiment operates in a virtual machine sandbox isolated environment, as shown in fig. 3, and includes the following steps:

in step S301, a driver is loaded.

When the kernel detects the driver loading of the process, the relevant data structure objects and variables needed by the driver are initialized. The method comprises the steps of recording a process ID of at least one system process, and recording at least one key function pointer value stored in a HAL routine address table (HalDispatctTable), such as a function pointer value of HALQuerySystemInformatica and the like.

Step S302, receiving the related information of the sample file and the switch information of each detection function point sent by the user layer process.

In this embodiment, the user layer process may refer to the auxiliary detection process described in the above embodiments. And the core detection process receives various IO control codes sent by the auxiliary detection process, and analyzes the IO control codes to obtain the related information of the sample file and the switch information of each detection function point.

And step S303, starting a kernel layer behavior monitoring master control switch according to the switch information of each detection function point.

And step S304, when the system creates a new process, adding the new process to the process creation record list.

When the system starts a sample process to run a sample file, the sample process is identified as a new process created, and the sample process is added to the process creation record list.

step S305 detects each operation behavior of the kernel layer of the new process.

in this embodiment, the detection of each operation behavior of the kernel layer of the new process is realized by a hook technology. Specifically, after the core detection process receives the IO control code sent by the auxiliary detection process, the IO control code is analyzed and identified to obtain a "kernel utilization monitoring" flag, and then the IO control code is selected to enter a corresponding distribution processing routine according to data entering a Buffer (Buffer). According to the related information of the sample file and the switch information of each detection function point, a designated API and NtQueryInterval Profile aiming at each function detection point in a Hook (Hook) SSDT (System Services Descriptor Table).

And executing a self-defined function by using a hook before a system calls a specified API and the NtQueryIntervalProfile, so as to realize the detection of each operation behavior of the kernel layer.

And step S306, generating a log file according to the detection result, and storing the log file into a log directory.

The kernel vulnerability detection method based on the virtual machine provided by the embodiment operates in a virtual machine sandbox isolation environment, and starts a kernel layer behavior monitoring master control switch according to the related information of a sample file sent by a user layer process and the switch information of each detection function point; and monitoring the new process created by the system, and detecting each operation behavior of the kernel layer of the new process. The method isolates the detection of the kernel vulnerability from the outside, provides a closed detection environment for the suspicious sample, does not cause damage to the server side even if the suspicious sample really has the vulnerability, and provides a safe and efficient kernel vulnerability detection mechanism.

Fig. 4 is a flowchart illustrating a virtual machine-based kernel vulnerability detection method according to another embodiment of the present invention. In this embodiment, based on the method shown in fig. 3, the working process of the core detection process is further elaborated, and as shown in fig. 4, the method includes the following steps:

In step S401, a driver is loaded.

In step S402, a logging thread is created.

step S403, receiving the related information of the sample file and the switch information of each detection function point, which are sent by the user layer process through the IO control code.

Specifically, the core detection process recognizes the "kernel utilization monitoring" flag by analyzing the IO control code, and then selects to enter a corresponding distribution processing routine according to data entering a Buffer (Buffer).

Step S404, according to the related information of the sample file and the switch information of each detection function point, a specific API and ntqueryiintervalprofile for each function detection point in the SSDT are hooked.

In this embodiment, the detection of each operation behavior of the kernel layer of the new process is realized by a hook technology. And according to the related information of the sample file and the switch information of each detection function point, hooking the designated API and the NtQueryIntervalProfile aiming at each function detection point in the SSDT. The hooked API is specifically a key ntipi for operations such as memory, privileges, registry, process/thread, file, etc. And setting a process creation notification routine, and entering the process creation notification routine to execute relevant operations when a new process is created in the system.

And S405, starting a kernel layer behavior monitoring master control switch according to the switch information of each detection function point.

In step S406, when the system creates a new process, the new process is added to the process creation record list.

When the system creates a new process, a process creation notification routine is first entered, in which attribute values of the created new process are recorded, for example: privileges, UserSID, OwnerSID, etc. The new process is then added to the process creation record list.

Step S407, detecting each operation behavior of the kernel layer of the new process.

When a new process calls NtQueryIntervalProfile, firstly judging whether the new process is in a process creation record list, if not, adding the new process into the process creation record list; and when the new process calls the appointed API, judging whether the new process is in the process creation record list, and if not, adding the new process into the process creation record list.

Under the condition of ensuring that a new process is added to a process creation record list, detecting each operation behavior of a kernel layer of the new process by using a hook technology, wherein the method specifically comprises the following implementation modes:

(1) HalDispatcutTable detection

Acquiring at least one key function pointer value stored in HalDispatchTable by using a hook technology before calling NtQueryIntervalProfile; comparing at least one key function pointer value stored in the obtained HalDispatch Table with at least one key function pointer value stored in the HalDispatch Table recorded in the process of loading the driver; and if the comparison of the at least one key function pointer value is inconsistent, detecting that the new process has the right-lifting behavior.

(2) Token replacement detection

Acquiring an EPROCESS structure address of at least one system process and acquiring an EPROCESS structure address of a new process simultaneously according to the process ID of the at least one system process recorded in the process of loading the driver before calling a corresponding designated API by using a hook technology; comparing the pointer value of the Token domain in the EPROCESS structural address of the new process with the pointer value of the Token domain in the EPROCESS structural address of at least one system process; and if the pointer value of the Token domain in the EPROCESS structural address of the new process is consistent with the pointer value of the Token domain in the EPROCESS structural address of one system process in comparison, detecting that the new process has the privilege-withdrawing behavior.

Here, the specified API may be: create process (NtCreateUserProcess), create and read and write memory to other processes (NtAllocateVirtualMemory/NtProtectVirtualMemory/NtReadVirtualMemory), open other processes/threads (NtOpenThread/NtOpenProcess/ntsetcontentthread), register read and write, file read and write, and so on.

(3) Token attribute value detection

Acquiring an attribute value of the new process by using a hook technology before calling a corresponding specified API; comparing the obtained attribute value of the new process with the attribute value of the new process recorded in the process creation notification routine; and if the comparison is inconsistent, detecting that the new process has the right-lifting behavior.

and during specific comparison, comparing the acquired Privileges, TokenUser and/or TokenOwner of the new process with Privileges, TokenUser and/or TokenOwner of the new process recorded in the process creation notification routine, and if one of the comparisons is inconsistent, detecting that the new process has an authorization behavior.

Here, the specified API refers to a function related to Token.

(4) Token attribute value null detection

By utilizing a hook technology, before calling a corresponding designated API, inquiring whether an ACL in a Token domain in an EPROCESS structural address of a new process is empty; and if so, detecting that the new process has the right-lifting behavior.

(5) Kernel ROP (Return ordered Programming, a new type of attack based on code reuse technology) detection

Currently, a common kernel ROP is used to close SMEP (supervisory Mode Execution Protection) or modify a CR4 register, and the method uses a hooking technique to check whether a call stack is a call stack that allows a CR4 register to modify an instruction or to detect whether the call stack calls an instruction that disables SMEP before the call stack operates a CR4 register; and if so, detecting that the new process has the right-lifting behavior.

(6) Bitmap utilization detection

And for the behavior of converting the limited kernel address writing operation into the kernel random address reading and writing operation by using the Bitmap, detecting the behavior, and if the behavior exists, detecting that the new process has the right-giving behavior.

Step S408, generating a log file according to the detection result, and storing the log file into a log directory.

And dotting according to a preset format to generate a log, and inserting the log into a log buffer list. And continuously checking whether a new log is inserted into the log buffer list in the log recording thread, if so, additionally writing the new log into a log file of a specified path in the configuration option, and releasing the node of the new log in the log buffer list.

The generation form of the dotting detection log is dotting in a cache mode. The detected journal is temporarily stored in a journal buffer list. The log recording thread polls the log buffer list and processes each log node in turn in FIFO mode, the log content is added and written into the log file, and the external related scheduling module process acquires and processes the log file after the detection is finished.

The dotting data of the scheme comprises: environment and file basic information, check function point trigger data, etc. The environment and file basic information is output in the form of a running log, and the detection function point triggers data to be output in the form of a behavior log. Wherein the environment and file basic information comprises: sample process file MD5, sample file path, and main system module name and file version, etc. For HalDispatchTable detection, detecting functional point trigger data comprises: a process ID, a thread ID, a name of a tampered function, a tampered pointer value, a Hooked API (NtQueryIntervalProfile) in which the tampered function is located when detected, and the like; for Token replacement detection, the detection function point trigger data comprises: process ID, thread ID, Token address, hit system process name, Hooked API when detected, etc. For Token attribute value detection, the detection function point trigger data includes: process ID, thread ID, Privileges mask description sequence, UserSID, OwnerSID, and Hooked API when detecting. The trigger data of the detection function points in other detection modes are similar to the trigger data, and are not described in detail herein.

The kernel vulnerability detection method based on the virtual machine provided by the embodiment operates in a virtual machine sandbox isolation environment, and starts a kernel layer behavior monitoring master control switch according to the related information of a sample file sent by a user layer process and the switch information of each detection function point; and monitoring the new process created by the system, and detecting each operation behavior of the kernel layer of the new process. The method isolates the detection of the kernel vulnerability from the outside, provides a closed detection environment for the suspicious sample, does not cause damage to the server side even if the suspicious sample really has the vulnerability, and provides a safe and efficient kernel vulnerability detection mechanism. According to the method, hook functions are set aiming at the APIs corresponding to the detection function points provided by the user layer process through a hook technology, detection operation is executed before the APIs are called, the problems of right lifting, utilization and the like can be timely and effectively found, and the kernel vulnerability detection efficiency is improved.

Fig. 5 is a flowchart illustrating a method for protecting a kernel vulnerability detection process based on a virtual machine according to an embodiment of the present invention. The method provided by the embodiment is mainly used for protecting the address space of the detection process running in the virtual machine sandbox isolation environment, preventing the malicious sample process escaped by the sandbox from accessing, releasing or leaking, and avoiding the theft of confidential information. As shown in fig. 5, the method includes the steps of:

step S501, obtaining the relevant information of each detection subprocess, and writing the relevant information of each detection subprocess into a process filtering list.

after the auxiliary detection process loads a drive program of the core detection process, reading related fields in the target detection configuration file, analyzing to obtain process names of one or more detection subprocesses, acquiring process IDs of the detection subprocesses according to the process names, and sending the process IDs of the detection subprocesses to the core detection process through IO control codes.

And the core detection process receives the process ID of each detection subprocess sent by the auxiliary detection process (user layer process) through the IO control code. Specifically, after receiving the IO control code marked as "process ID filtering", the core detection process obtains the process ID transmitted at this time from the input buffer, and obtains the relevant information of the detection sub-process according to the process ID. In the method, the related information may be an EPROCESS structure address. And after the core detection process acquires the EPROCESS structure address of each detection sub-process, writing the EPROCESS structure address of each detection sub-process into a process filtering list.

Step S502, using the hook technology, before calling the appointed API, obtaining the relevant information of the current context process and the relevant information of the operation target process.

The method hooks the appointed API about the operation of the process, the thread and the memory address space, and realizes the steps S502 to S504 in the self-defined function after Hook appoints the API. In step S502, an EPROCESS structure address of the current context process and an EPROCESS structure address of the operation target process are acquired.

Step S503, judging whether the relevant information of the operation target process is recorded in the process filtering list and whether the relevant information of the current context process is not recorded in the process filtering list, if so, executing step S504; if not, step S505 is executed.

optionally, it is determined whether the EPROCESS structure address of the operation target process is recorded in the process filter list, and whether the EPROCESS structure address of the current context process is not recorded in the process filter list.

step S504 terminates the call specification API.

If the EPROCESS structure address of the operation target process is judged to be recorded in the process filtering list, and the EPROCESS structure address of the current context process is not recorded in the process filtering list, it is indicated that other processes try to access a certain detection sub-process, and blocking is needed. For example, a status code denying access is returned, terminating the call to the specified API.

Step S505 continues to call the specified API, and returns the return value of the specified API to the caller.

If the EPROCESS structure address of the operation target process is judged not to be recorded in the process filtering list, or the EPROCESS structure address of the current context process is judged to be recorded in the process filtering list, the specified API is continuously called, and a return value of the specified API is returned to the caller.

According to the kernel vulnerability detection process protection method based on the virtual machine, relevant information of each detection sub-process is written into a process filtering list, before a specified API is called, relevant information of a current context process and relevant information of an operation target process are obtained through a hook, and whether calling of the specified API is stopped or not is judged by matching the relevant information of the current context process and the relevant information of the operation target process with the process filtering list. By the method, the address space of the detection process running in the virtual machine sandbox isolation environment can be protected, malicious sample processes escaping from the sandbox are prevented from accessing, confidential information is prevented from being stolen, and the security of kernel vulnerability detection in the virtual machine sandbox isolation environment is improved.

FIG. 6 is a flowchart illustrating a method for protecting a kernel vulnerability detection file based on a virtual machine according to an embodiment of the present invention. The method provided by the embodiment is mainly used for protecting the detection files generated in the detection process, such as log files and the like, preventing malicious sample processes escaping from the sandbox from accessing, tampering, encrypting or damaging, avoiding detection failure or result abnormity caused by the access, tampering, encrypting or damage, and maintaining the stability and performance of the sandbox system. As shown in fig. 6, the method includes the steps of:

Step S601, obtaining the relevant information of each detection subprocess, and writing the relevant information of each detection subprocess into a process filtering list.

Step S602, obtaining the storage path information of the detection file, and writing the storage path information of the detection file into the private directory list.

after the auxiliary detection process loads a driver of the core detection process, reading related fields in the target detection configuration file, analyzing to obtain one or more storage paths of the detection files, and sending the storage paths of the detection files to the core detection process through IO control codes.

And the core detection process receives the storage path of each detection file sent by the auxiliary detection process (user layer process) through the IO control code. Specifically, after receiving the IO control code marked as "private directory", the core detection process obtains a storage path of the detection file that is currently transferred from the input buffer, constructs a character string object as storage path information of the detection file according to the storage path of the detection file, and writes the storage path information of the detection file into the private directory list.

Step S603, when the file access operation occurs, determines whether the storage path information of the file access object is recorded in the private directory list.

The implementation of detecting file protection in this embodiment is mainly implemented in the function body of the IRP distribution function. For example, in a self-implementation function body of a distribution function such as READ, WRITE, CREATE, SET _ INFORMATION, direct _ CONTROL, or the like, it is implemented to determine whether the storage path INFORMATION of the file access object is recorded in the private DIRECTORY list, and if so, step S604 is executed; if not, go to step S606.

Step S604, determining whether the relevant information of the current context process is recorded in the process filtering list.

If the storage path information of the file access object is recorded in the private directory list, further determining whether the related information of the current context process is recorded in the process filtering list, specifically, determining whether the EPROCESS structure address of the current context process is recorded in the process filtering list, if so, executing step S606; if not, go to step S605.

Step S605, if it is determined that the relevant information of the current context process is not recorded in the process filter list, the file access operation is rejected.

If the storage path information of the file access object is recorded in the private directory list, and the related information of the current context process is not recorded in the process filter list, which indicates that other processes try to access the detection file, the IPR does not distribute downwards, and the file access operation is refused.

Step S606, if it is determined that the storage path information of the file access object is not recorded in the private directory list, or it is determined that the related information of the current context process is recorded in the process filter list, continuing to respond to the file access operation.

If the storage path information of the file access object is not recorded in the private directory list, which indicates that the accessed file is not the detection file needing protection, the IPR continues to distribute downwards and responds to the file access operation. If the storage path information of the file access object is recorded in the private directory list and the related information of the current context process is recorded in the process filter list, which indicates that the detection subprocess tries to access the detection file, the IPR continues to distribute downwards and responds to the file access operation.

According to the kernel vulnerability detection file protection method based on the virtual machine, relevant information of each detection sub-process is written into a process filtering list, storage path information of a detection file is written into a private directory list, when file access operation is generated, the storage path information of a file access object and the relevant information of a current context process are respectively matched with the process filtering list and the private directory list, and whether the file access operation is rejected is judged. By using the method, the detection file generated in the virtual machine sandbox isolation environment can be protected, the malicious sample process escaped by the sandbox is prevented from accessing, tampering, encrypting or damaging, the detection failure or result abnormity caused by the access or tampering, and the stability and performance of the sandbox system are maintained.

Fig. 7 shows a functional block diagram of a kernel vulnerability detection apparatus based on a virtual machine according to an embodiment of the present invention. The device specifically runs in a server-side virtual machine sandbox isolation environment and is used for performing dynamic kernel vulnerability utilization detection on a specified sample file. As shown in fig. 7, the apparatus includes: the system comprises a communication agent module 701, a scheduling management and control module 702, an auxiliary detection module 703 and a core detection module 704.

The communication agent module 701 is adapted to start a communication agent process, so that the communication agent process monitors the designated port, waits for and receives a detection packet and a sample file transmitted by an external host of the virtual machine, and stores the detection packet and the sample file in the detection directory and the temporary directory respectively. The communication agent process is responsible for data interaction and file transfer with an external host of the virtual machine. When the operation system of the virtual machine at the server is started, the communication agent process is started automatically. And the communication agent process monitors the designated port, waits for and receives the detection packet and the sample file transmitted by the relevant process of the external host of the virtual machine. The communication agent process decompresses the detection packet and stores the decompressed file in a detection directory; in addition, the communication agent process stores the sample file under a temporary directory. Subsequently, the communication agent thread starts a scheduling management and control process in the detection packet.

The scheduling management and control module 702 is adapted to start a scheduling management and control process in the detection package, so that the scheduling management and control process obtains a sample file storage path, identifies a sample file type, and selects a detection mode and each detection function point according to configuration options in a general detection configuration file to create a target detection configuration file for the sample file. After the scheduling control process is started, the scheduling control process acquires a sample file storage path and identifies the type of the sample file. And then, the scheduling management and control process reads the self-associated general detection configuration file, selects a detection mode and each detection function point according to the type of the sample file, initializes each function of the scheduling management and control process, and creates a target detection configuration file aiming at the sample file. Then, the scheduling management and control process starts the auxiliary detection process, and transfers the storage path (which may be a URL) of the sample file to the auxiliary detection process in a parametric manner.

The auxiliary detection module 703 is adapted to start an auxiliary detection process, so that the auxiliary detection process controls the on/off of each detection function point by using the target detection configuration file. After the auxiliary detection process is started, the auxiliary detection process is initialized according to the target detection configuration file, a driving program of the core detection process is loaded, and the target detection configuration file is used for controlling the on-off of each detection function point.

The core detection module 704 is adapted to start a core detection process, so that the core detection process receives the related information of the sample file and the switch information of each detection function point sent by the auxiliary detection process, executes vulnerability detection, generates a log file according to a detection result, and stores the log file in a log directory. And after the auxiliary detection process loads the driver of the core detection process, the core detection process is started. And the core detection process receives the related information of the sample file and the switch information of each detection function point sent by the auxiliary detection process and executes initialization operation. And then, executing the detection of the sample file according to the related information of the sample file and the switch information of each detection function point, generating a log file according to the detection result, and storing the log file into a log directory.

The communication agent module 701 is further adapted to: and enabling the communication agent process to create a message communication thread and establish communication connection with the scheduling management and control process. After the scheduling management and control process is started, the communication agent process creates a message communication thread, and optionally, establishes a communication connection with the scheduling management and control process through an RPC. By using the communication connection, the subsequently received message data packet from the scheduling control process can be forwarded to the external host of the virtual machine in real time.

the schedule management module 702 is further adapted to: enabling a scheduling control process to create a screen intercepting thread and intercepting screen images at preset time intervals; and sending the intercepted screen image to the communication agent process in real time by utilizing the communication connection established between the scheduling control process and the communication agent process.

The communication agent module 701 is further adapted to: and enabling the communication agent process to send the intercepted screen image to an external host of the virtual machine.

The schedule management module 702 is further adapted to: enabling the scheduling control process to create a mouse simulation click thread, randomly simulating mouse click operation aiming at the screen coordinate, and simulating the mouse click operation aiming at the specific control.

The schedule management module 702 is further adapted to: enabling the scheduling management and control process to select a timeout limiting condition according to the configuration options in the general detection configuration file; and in the detection process of executing the sample file, judging whether an overtime limiting condition is met, if so, ending the detection process, packaging the detection result into a data packet, and sending the data packet to the communication agent process so that the communication agent process can send the data packet to an external host of the virtual machine.

The core detection module 704 is further adapted to: and enabling the core detection process to receive the related information of the sample file and the switch information of each detection function point, which are sent by the auxiliary detection process in an IO control code mode.

The kernel vulnerability detection device based on the virtual machine provided by this embodiment operates in a virtual machine sandbox isolation environment, and realizes data interaction and file transfer with an external host of the virtual machine through a communication agent process, and assists a core detection process to realize detection of a sample file by means of a scheduling management and control process and an auxiliary detection process. The device isolates the detection of the kernel vulnerability from the outside, provides a closed detection environment for the suspicious sample, does not cause damage to the server side even if the suspicious sample really has the vulnerability, and provides a safe and efficient kernel vulnerability detection mechanism. In the device, the scheduling management and control process selects the overtime limiting condition according to the configuration options in the general detection configuration file, and the overtime limiting condition is configured, so that the follow-up detection for a certain sample file is prevented from occupying too long time, and the detection efficiency is improved. The scheduling management and control process creates a screen capturing thread and/or a mouse simulation clicking thread, images displayed by a server screen can be transmitted to the external host of the virtual machine, a user of the external host of the virtual machine can check the progress and specific conditions of the detection process, and the visualization effect is good.

Fig. 8 is a functional block diagram of a kernel vulnerability detection apparatus based on a virtual machine according to another embodiment of the present invention. The apparatus operates in a virtual machine sandbox isolated environment, as shown in fig. 8, the apparatus includes: a loading module 801, a receiving module 802, a starting module 803, an adding module 804, a detecting module 805 and a log storing module 806.

The loading module 801 is adapted to load a driver. The loading module 801 initializes the relevant data structure objects and variables required by the driver when loading the driver. The method comprises the steps of recording a process ID of at least one system process, and recording at least one key function pointer value stored in a HAL routine address table (HalDispatctTable), such as a function pointer value of HALQuerySystemInformatica and the like.

The receiving module 802 is adapted to receive related information of the sample file sent by the user layer process and switch information of each detection function point. In this embodiment, the user layer process may refer to the auxiliary detection process described in the above embodiments. The receiving module 802 receives various IO control codes sent by the auxiliary detection process, and analyzes the IO control codes to obtain related information of the sample file and switch information of each detection function point. Specifically, the tag of "kernel utilization monitoring" is identified by parsing the IO control code, and then the corresponding distribution processing routine is selected to be entered according to the data entered into the Buffer.

And the starting module 803 is suitable for starting the kernel layer behavior monitoring master control switch according to the switch information of each detection function point.

An adding module 804 adapted to add the new process to the process creation record list when the system creates the new process.

The detecting module 805 is adapted to detect each operation behavior of the kernel layer of the new process.

And the log storage module 806 is adapted to generate a log file according to the detection result, and store the log file in a log directory.

further, the apparatus further comprises: the hook configuration module 807 is adapted to hook the specified API and ntqueryiintervalprofile for each function detection point in the SSDT, according to the related information of the sample file and the switch information of each detection function point. The device realizes the detection of each operation behavior of the kernel layer of the new process through a hook technology. And according to the related information of the sample file and the switch information of each detection function point, hooking the designated API and the NtQueryIntervalProfile aiming at each function detection point in the SSDT. The hooked API is specifically a key ntipi for operations such as memory, privileges, registry, process/thread, file, etc.

Further, the apparatus further comprises: a routine setting module 808 adapted to set a process creation notification routine; recording attribute values of the created new process in the process creation notification routine. When the system creates a new process, the routine setup module 808 records the attribute values of the created new process in a process creation notification routine, such as: privileges, UserSID, OwnerSID, etc.

The detection module 805 is further adapted to: acquiring at least one key function pointer value stored in an HAL routine address table before calling NtQueryIntervalProfile by using a hook technology; comparing at least one item of key function pointer value stored in the obtained HAL routine address table with at least one item of key function pointer value stored in the HAL routine address table recorded in the process of loading the driver; and if the at least one item of key function pointer value is inconsistent in comparison, detecting that the new process has an authority-raising behavior.

The detection module 805 is further adapted to: acquiring an EPROCESS structure address of at least one system process according to the process ID of at least one system process recorded in the process of loading a driver and acquiring the EPROCESS structure address of the new process simultaneously by using a hook technology before calling a corresponding designated API; comparing the pointer value of the Token domain in the EPROCESS structural address of the new process with the pointer value of the Token domain in the EPROCESS structural address of at least one system process; and if the pointer value of the Token domain in the EPROCESS structural address of the new process is consistent with the pointer value of the Token domain in the EPROCESS structural address of one system process in comparison, detecting that the new process has the privilege-withdrawing behavior.

The detection module 805 is further adapted to: acquiring an attribute value of the new process by using a hook technology before calling a corresponding specified API; comparing the obtained attribute value of the new process with the attribute value of the new process recorded in the process creation notification routine; and if the comparison is inconsistent, detecting that the new process has the right-lifting behavior.

The detection module 805 is further adapted to: and comparing the acquired Privileges, TokenUser and/or TokenOwner of the new process with the Privileges, UserSID and/or OwnSID of the new process recorded in the process creation notification routine.

The detection module 805 is further adapted to: inquiring whether an ACL in a Token domain in the EPROCESS structure address of the new process is empty or not before calling a corresponding designated API by using a hook technology; and if so, detecting that the new process has the right-lifting behavior.

The detection module 805 is further adapted to: by using a hook technology, before a call stack operates a CR4 register, checking whether the call stack is a call stack which allows a CR4 register to modify an instruction or detecting whether the call stack calls an instruction which disables SMEP; and if so, detecting that the new process has the right-lifting behavior.

The detection module 805 is further adapted to: and detecting whether the behavior of converting the limited kernel address writing operation into the kernel random address reading and writing operation exists, and if so, detecting that the new process has the right-giving behavior.

The kernel vulnerability detection device based on the virtual machine provided by the embodiment operates in a virtual machine sandbox isolation environment, and starts a kernel layer behavior monitoring master control switch according to related information of a sample file sent by a user layer process and switch information of each detection function point; and monitoring the new process created by the system, and detecting each operation behavior of the kernel layer of the new process. The device isolates the detection of the kernel vulnerability from the outside, provides a closed detection environment for the suspicious sample, does not cause damage to the server side even if the suspicious sample really has the vulnerability, and provides a safe and efficient kernel vulnerability detection mechanism. The device sets a hook function aiming at the API corresponding to each detection function point provided by the user layer process through a hook technology, executes detection operation before calling the API, can timely and effectively find the problems of privilege escalation, utilization and the like, and improves the efficiency of kernel vulnerability detection.

FIG. 9 shows a functional block diagram of protection of a virtual machine-based kernel vulnerability detection process, according to an embodiment of the present invention. The device provided by the embodiment is mainly used for protecting the address space of the detection process running in the virtual machine sandbox isolation environment, preventing malicious sample processes escaping from the sandbox from accessing, releasing or leaking, and avoiding the theft of confidential information. As shown in fig. 9, the apparatus includes: a write module 901, a hook processing module 902, a judgment module 903, and a termination module 904. Optionally, the method further comprises: a receiving module 905 and a calling module 906.

The receiving module 905 is adapted to receive the process ID of each detection sub-process sent by the user layer process.

A receiving module 905 in the core detection process receives the process ID of each detection sub-process sent by the auxiliary detection process (user layer process) through the IO control code. Specifically, the receiving module 905 acquires the process ID of the current transfer from the input buffer after receiving the IO control code marked as "process ID filtering".

The writing module 901 is adapted to obtain relevant information of each detection sub-process, and write the relevant information of each detection sub-process into the process filtering list.

The writing module 901 obtains the relevant information of the detected sub-process according to the process ID. The related information may be an EPROCESS structure address. After the write module 901 obtains the EPROCESS structure address of each detected sub-process, the EPROCESS structure address of each detected sub-process is written into the process filter list.

The hooking processing module 902 is adapted to obtain the relevant information of the current context process and the relevant information of the operation target process before calling the specified API by using a hooking technique.

The hooking processing module 902 hooks the specified APIs related to the operations of the process, the thread, and the memory address space, and after Hook specifies the APIs, the functions of the determining module 903 and the terminating module 904 are implemented in the custom function. The hook processing module 902 first obtains an EPROCESS structure address of the current context process and an EPROCESS structure address of the operation target process.

The determining module 903 is adapted to determine whether the relevant information of the operation target process is recorded in the process filter list, and whether the relevant information of the current context process is not recorded in the process filter list. Specifically, the determining module 903 determines whether the EPROCESS structure address of the operation target process is recorded in the process filter list, and whether the EPROCESS structure address of the current context process is not recorded in the process filter list.

A terminating module 904, adapted to terminate the call of the specified API if the determining module 903 determines that the relevant information of the operation target process is recorded in the process filtering list and the relevant information of the current context process is not recorded in the process filtering list.

The calling module 906 is adapted to continue calling the specified API and return a return value of the specified API to the caller if the determining module 903 determines that the relevant information of the operation target process is not recorded in the process filter list or the relevant information of the current context process is recorded in the process filter list.

According to the kernel vulnerability detection process protection device based on the virtual machine, relevant information of each detection sub-process is written into a process filtering list, before a specified API is called, relevant information of a current context process and relevant information of an operation target process are obtained through a hook, and whether calling of the specified API is stopped or not is judged by matching the relevant information of the current context process and the relevant information of the operation target process with the process filtering list. By using the device, the address space of the detection process running in the virtual machine sandbox isolation environment can be protected, malicious sample processes escaping from the sandbox are prevented from accessing, confidential information is prevented from being stolen, and the security of kernel vulnerability detection in the virtual machine sandbox isolation environment is improved.

FIG. 10 illustrates a functional block diagram of virtual machine-based kernel vulnerability detection file protection, according to one embodiment of the present invention. The device provided by the embodiment is mainly used for protecting detection files such as log files and the like generated in the detection process, preventing malicious sample processes escaping from the sandbox from accessing, tampering, encrypting or damaging, avoiding detection failure or result abnormity caused by the access, tampering, encrypting or damage, and maintaining the stability and performance of the sandbox system. As shown in fig. 10, the apparatus includes: a first writing module 1001, a second writing module 1002, a first judging module 1003, a second judging module 1004, and a rejecting module 1005; optionally, the apparatus further comprises: a receiving module 1006 and a response module 1007.

The receiving module 1006 is adapted to receive a storage path of the detection file sent by the user layer process.

After the auxiliary detection process loads a drive program of the core detection process, reading related fields in the target detection configuration file, analyzing to obtain process names of one or more detection subprocesses and storage paths of one or more detection files, obtaining process IDs of the detection subprocesses according to the process names, and sending the process IDs of the detection subprocesses and the storage paths of the detection files to the core detection process through IO control codes.

A receiving module 1006 in the core detection process receives the process ID of each detection sub-process and the storage path of each detection file, which are sent by the auxiliary detection process (user layer process) through the IO control code. Specifically, after receiving an IO control code marked as "process ID filtering", the core detection process acquires a process ID transmitted at this time from the input buffer; and after receiving the IO control code marked as the private directory, the core detection process acquires a storage path of the detection file transmitted at the time from the input buffer area.

The first writing module 1001 is adapted to obtain relevant information of each detection sub-process, and write the relevant information of each detection sub-process into the process filter list.

the first write module 1001 acquires information related to detecting a child process from the process ID. In the method, the related information may be an EPROCESS structure address. After the first write module 1001 acquires the EPROCESS structure address of each detected sub-process, the EPROCESS structure address of each detected sub-process is written into the process filter list.

The second writing module 1002 is adapted to obtain the storage path information of the detected file, and write the storage path information of the detected file into the private directory list.

The second writing module 1002 constructs a character string object according to the storage path of the detection file as storage path information of the detection file, and writes the storage path information of the detection file into the private directory list.

The first determining module 1003 is adapted to determine whether the storage path information of the file access object is recorded in the private directory list when the file access operation is generated.

the implementation of detecting file protection in this embodiment is mainly implemented in the function body of the IRP distribution function. For example, in a self-implementation function body of a distribution function such as READ, WRITE, CREATE, SET _ INFORMATION, direct _ CONTROL, or the like, the determination of whether or not the storage path INFORMATION of the file access object is recorded in the private DIRECTORY list is implemented.

The second determining module 1004 determines whether the relevant information of the current context process is recorded in the process filtering list if the first determining module 1003 determines that the storage path information of the file access object is recorded in the private directory list.

If the storage path information of the file access object is recorded in the private directory list, the second determining module 1004 further determines whether the relevant information of the current context process is recorded in the process filtering list, specifically, whether the EPROCESS structure address of the current context process is recorded in the process filtering list.

The rejecting module 1005 is adapted to reject the file access operation if the second determining module 1004 determines that the related information of the current context process is not recorded in the process filter list.

a response module 1007, adapted to continue to respond to the file access operation if the first determining module 1003 determines that the storage path information of the file access object is not recorded in the private directory list, or the second determining module 1004 determines that the relevant information of the current context process is recorded in the process filtering list.

According to the kernel vulnerability detection file protection device based on the virtual machine provided by the embodiment, relevant information of each detection sub-process is written into a process filtering list, storage path information of a detection file is written into a private directory list, when a file access operation is generated, the storage path information of a file access object and the relevant information of a current context process are respectively matched with the process filtering list and the private directory list, and whether the file access operation is rejected is judged. By utilizing the device, the detection file generated in the virtual machine sandbox isolation environment can be protected, the malicious sample process escaping from the sandbox is prevented from being accessed, tampered, encrypted or damaged, the detection failure or result abnormity caused by the malicious sample process is avoided, and the stability and the performance of the sandbox system are maintained.

The invention can be applied to a plurality of fields such as network security, terminal security, cloud security, application security, security management and security service. The products comprise high-medium-low-end next-generation firewalls, intrusion prevention systems, DDoS attack prevention systems, virtual integrated service gateways, sandboxes, big data security analysis systems and other products, and corresponding solutions aiming at traditional threats and unknown threats.

The algorithms and displays presented herein are not inherently related to any particular computer, virtual machine, or other apparatus. Various general purpose systems may also be used with the teachings herein. The required structure for constructing such a system will be apparent from the description above. Moreover, the present invention is not directed to any particular programming language. It is appreciated that a variety of programming languages may be used to implement the teachings of the present invention as described herein, and any descriptions of specific languages are provided above to disclose the best mode of the invention.

In the description provided herein, numerous specific details are set forth. It is understood, however, that embodiments of the invention may be practiced without these specific details. In some instances, well-known methods, structures and techniques have not been shown in detail in order not to obscure an understanding of this description.

Similarly, it should be appreciated that in the foregoing description of exemplary embodiments of the invention, various features of the invention are sometimes grouped together in a single embodiment, figure, or description thereof for the purpose of streamlining the disclosure and aiding in the understanding of one or more of the various inventive aspects. However, the disclosed method should not be interpreted as reflecting an intention that: that the invention as claimed requires more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive aspects lie in less than all features of a single foregoing disclosed embodiment. Thus, the claims following the detailed description are hereby expressly incorporated into this detailed description, with each claim standing on its own as a separate embodiment of this invention.

Those skilled in the art will appreciate that the modules in the device in an embodiment may be adaptively changed and disposed in one or more devices different from the embodiment. The modules or units or components of the embodiments may be combined into one module or unit or component, and furthermore they may be divided into a plurality of sub-modules or sub-units or sub-components. All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and all of the processes or elements of any method or apparatus so disclosed, may be combined in any combination, except combinations where at least some of such features and/or processes or elements are mutually exclusive. Each feature disclosed in this specification (including any accompanying claims, abstract and drawings) may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise.

Furthermore, those skilled in the art will appreciate that while some embodiments described herein include some features included in other embodiments, rather than other features, combinations of features of different embodiments are meant to be within the scope of the invention and form different embodiments. For example, in the following claims, any of the claimed embodiments may be used in any combination.

The various component embodiments of the invention may be implemented in hardware, or in software modules running on one or more processors, or in a combination thereof. Those skilled in the art will appreciate that a microprocessor or Digital Signal Processor (DSP) may be used in practice to implement some or all of the functions of some or all of the components in a virtual machine based kernel vulnerability detection apparatus according to embodiments of the present invention. The present invention may also be embodied as apparatus or device programs (e.g., computer programs and computer program products) for performing a portion or all of the methods described herein. Such programs implementing the present invention may be stored on computer-readable media or may be in the form of one or more signals. Such a signal may be downloaded from an internet website or provided on a carrier signal or in any other form.

It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be able to design alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. The word "comprising" does not exclude the presence of elements or steps not listed in a claim. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. The invention may be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In the unit claims enumerating several means, several of these means may be embodied by one and the same item of hardware. The usage of the words first, second and third, etcetera do not indicate any ordering. These words may be interpreted as names.

Claims

1. a kernel vulnerability detection process protection method based on a virtual machine is operated in a virtual machine sandbox isolation environment, and comprises the following steps:

Receiving a process ID of each detection subprocess sent by a user layer process through an IO control code, acquiring relevant information of each detection subprocess, and writing the relevant information of each detection subprocess into a process filtering list;

If yes, terminating the calling of the specified API.

2. The method according to claim 1, wherein the related information is in particular an EPROCESS fabric address.

3. The method of claim 1, further comprising: if the relevant information of the operation target process is judged not to be recorded in the process filtering list, or the relevant information of the current context process is judged to be recorded in the process filtering list, the specified API is continuously called, and a return value of the specified API is returned to a caller.

4. A kernel vulnerability detection process protection device based on a virtual machine, the device running under a virtual machine sandbox isolation environment, the device comprising:

The receiving module is suitable for receiving the process ID of each detection subprocess sent by the user layer process through the IO control code;

5. The apparatus of claim 4, wherein the related information is an EPROCESS structure address.

6. the apparatus of claim 4, further comprising: and the calling module is suitable for continuing calling the specified API and returning a return value of the specified API to a caller if the judging module judges that the relevant information of the operation target process is not recorded in the process filtering list or the relevant information of the current context process is recorded in the process filtering list.