CN104715202A - Hidden process detecting method and hidden process detecting device in virtual machine - Google Patents

Abstract

The invention discloses a method for detecting a hidden process in a virtual machine, wherein the method includes: intercepting a process exit event in a specified virtual machine, and intercepting a process creation event in the specified virtual machine; according to the intercepted specified Process exit and process creation events in the virtual machine, maintaining a trusted process list that records the real running process in the specified virtual machine; by traversing the relevant data structure that records the process information in the specified virtual machine, the recorded One or more untrusted process lists of the processes in the specified virtual machine; by comparing the trusted process list and the untrusted process list, the hidden process in the specified virtual machine is determined. Compared with the prior art, the technical solution provided by the present invention is more comprehensive and effective in detection, especially capable of detecting attacks on kernel objects, and meets the common needs of cloud service providers and users.

Description

Method and device for detecting hidden processes in a virtual machine

technical field

The invention relates to the field of computer technology, in particular to a method and device for detecting hidden processes in a virtual machine.

Background technique

Virtualization technology realizes the virtualization of computing, storage, network and other IT resources, and is the basis for the rapid development of the cloud computing industry. Virtual Machine (Virtual Machine) is the most basic form of service provided by the cloud environment. Cloud service providers provide individual and organizational users with a single virtual machine or a virtual network composed of multiple virtual machines to meet the needs of users for easy maintenance, Requirements for highly available elastic cloud services. In a virtualized environment, services are provided to users in the form of virtual machines, and cloud service providers can only use interfaces such as Libvirt to obtain resource allocation and usage information such as CPU, memory, disk, and network of the target virtual machine from outside the virtual machine , and cannot monitor the granularity of the process behavior running in the virtual machine. Once the virtual machine is controlled by malware implanted by the attacker, it will have a huge impact on the security of the virtual machine in the same virtual network and even the security and stability of the cloud platform itself. Therefore, security monitoring of virtual machine runtime has become a common requirement of cloud service providers and users.

One of the most important reasons why malware is difficult to detect is the hidden technology widely used by malware. Malware injects executable code into the host process to run, which is itself a method of hiding the process. In addition, this type of malware often performs some hidden operations on the injected code to increase the difficulty of detection; independent execution like Rootkit The program is to modify the execution path or execution result of the normal kernel code in the kernel through IAT HOOK, SSDT HOOK or Inline Hook, and is often used in conjunction with viruses, Trojan horses, zombies, etc. to achieve hidden effects. Therefore, in view of the hidden features generated by malware infection, it is necessary to study the detection method of hidden features at the virtualization level.

In the prior art, the kernel data structure of the Linux operating system is analyzed, the user view projection technology is adopted, and the trusted view of the client is obtained by traversing the semantically reconstructed process control block, and compared with the process list obtained by the internal agent program, To determine whether there are hidden processes, this method has the problem of not being able to detect attacks against kernel objects.

Contents of the invention

In view of the above problems, the present invention is proposed to provide a hidden process detection method and device in a virtual machine that overcomes the above problems or at least partially solves the above problems.

According to one aspect of the present invention, a method for detecting hidden processes in a virtual machine is provided, the method comprising:

Intercepting a process exit event in a specified virtual machine, and intercepting a process creation event in the specified virtual machine;

According to the intercepted process exit and process creation events in the specified virtual machine, maintain a trusted process list that records the real running process in the specified virtual machine;

Obtaining one or more untrusted process lists recording processes in the specified virtual machine by traversing a related data structure that records process information in the specified virtual machine;

By comparing the trusted process list and the untrusted process list, the hidden process in the specified virtual machine is determined.

Optionally, the step of obtaining one or more untrusted process lists that record the processes in the specified virtual machine by traversing the relevant data structure that records the process information in the specified virtual machine includes:

By traversing one or more of the _EPROCESS data structure in the kernel address space, the PspCidTable handle table or the csrss.exe handle table, correspondingly obtain one or more groups of process information in the virtual machine;

According to the obtained one or more sets of process information, corresponding one or more untrusted process lists are generated.

Optionally, the intercepting the process exit event in the specified virtual machine includes:

Obtain the address of the key location of process exit; among them, the system will call the NtTerminateProcess service routine in the kernel to process the process exit, and the NtTerminateProcess service routine will put the address of the _EPROCESS management structure of the exit process in the process management structure after completing the operation of closing the process The linked list is unlinked and released to the specified address, and the specified address is used as the address of the key position for process exit;

The monitoring process exits the key position address execution event, when the code at this address is called, it indicates that a process ends, and the address of the _EPROCESS management structure of the exiting process is obtained from this address.

Optionally, obtaining the process exit key location address includes: obtaining the address of the NtTerminateProcess service routine, and obtaining the process exit key location address according to the address of the NtTerminateProcess service routine;

The address of obtaining the NtTerminateProcess service routine includes:

Obtain the address of the KeServiceDescriptorTable data structure;

Obtain the address of the SSDT table from the KeServiceDescriptorTable data structure and determine the offset of the NtTerminateProcess service routine in the SSDT table;

Gets the address of the NtTerminateProcess service routine at the specified offset in the SSDT table.

Optionally, the acquisition of the process exit key location address according to the address of the NtTerminateProcess service routine includes:

Obtain the address offset by 0x13c relative to the address of the NtTerminateProcess service routine, which is the address of the ecx register.

Optionally, the execution event of the monitoring process exiting the key location address includes:

When the specified virtual machine occurs when the virtual machine enters the VM_ENTRY event: the address in the specified debug address register in the VCPU of the specified virtual machine is set as the process exit key location address; the debug control register in the VCPU of the specified virtual machine is set Execute the control bit corresponding to the specified debug address register in the specified virtual machine; set the TRAP_debug control bit in the virtual machine control domain VMCS data structure of the specified virtual machine;

When the specified virtual machine has a virtual machine exit VM_EXIT event: if it is a debugging abnormal event, it is judged whether the address that generates the exception is the address of the key position of the process exit, and if it is, read the _ of the exit process saved in the key position address of the process exit The address of the EPROCESS management structure.

Optionally, the intercepting the process creation event in the specified virtual machine includes:

maintaining a list of currently running processes on the specified virtual machine;

Monitor the process switching event that occurs inside the specified virtual machine, and obtain the value in the CR3 register of the VCPU of the specified virtual machine when the event is monitored; the value in the CR3 register is the relevant information of the switched process;

Judging whether the value in the obtained CR3 register exists in the list of currently running processes, if it does not exist, it means that a process has been created, and adding the value obtained in the CR3 register to the list of currently running processes;

When the exit event of a process in the specified virtual is intercepted, the exited process is deleted from the list of currently running processes.

Optionally, the monitoring process switching events occurring inside the specified virtual machine includes:

Set the CPU_BASED_CR3_LOAD_EXITING control bit in the virtual machine control domain VMCS data structure of the specified virtual machine; this control bit is located at the virtual machine execution control domain for processor events of the VMCS data structure, and determines when the virtual machine executes the Move to CR3 instruction that is the process Whether the virtual machine exits VM_EXIT event occurs when switching.

Optionally, said maintaining a trusted process list that records the real running process in the specified virtual machine includes:

When intercepting a process creation event in the specified virtual machine, it is judged whether the process is in the trusted process list, if not, the process is added to the trusted process list;

When a process exit event in the specified virtual machine is intercepted, the process is deleted from the trusted process list.

According to another aspect of the present invention, a hidden process detection device in a virtual machine is provided, the device comprising:

A process event intercepting unit, adapted to intercept a process exit event in a specified virtual machine, and a process creation event in the specified virtual machine;

The trusted process list maintenance unit is adapted to maintain a trusted process list recording the real running process in the specified virtual machine according to the intercepted process exit and process creation events in the specified virtual machine;

The untrusted process list maintenance unit is adapted to obtain one or more untrusted process lists that record the processes in the specified virtual machine by traversing the relevant data structures that record the process information in the specified virtual machine;

The comparing unit is adapted to determine the hidden process in the specified virtual machine by comparing the trusted process list and the untrusted process list.

Optionally, the untrusted process list maintenance unit is adapted to obtain one or more of the _EPROCESS data structure in the kernel address space, the PspCidTable handle table or the csrss.exe handle table correspondingly in the virtual machine. One or more sets of process information; according to the obtained one or more sets of process information, generate corresponding one or more untrusted process lists.

Optionally, the process event intercepting unit includes:

The process exit event interception subunit is suitable for obtaining the address of the key location of the process exit; among them, the system will call the NtTerminateProcess service routine in the kernel to process the process exit. The address of the EPROCESS management structure is unlinked in the linked list formed by the process management structure and released to the specified address, and the specified address is used as the address of the key position of the process exit; and it is suitable for monitoring the execution event of the key position address of the process exit, when the code at the address is executed When called, it indicates that a process is about to end, and the address of the _EPROCESS management structure of the exiting process is obtained from this address.

Optionally, the process exit event intercepting subunit obtains the address of the NtTerminateProcess service routine, and obtains the address of the key location of the process exit according to the address of the NtTerminateProcess service routine; it is specifically suitable for obtaining the address of the KeServiceDescriptorTable data structure, from the KeServiceDescriptorTable data structure Obtain the address of the SSDT table and determine the offset of the NtTerminateProcess service routine in the SSDT table, and obtain the address of the NtTerminateProcess service routine at the specified offset of the SSDT table.

Optionally, the process exit event intercepting subunit obtains an address offset by 0x13c relative to the address of the NtTerminateProcess service routine, which is the address of the ecx register, and this address is used as the address of the key position of process exit.

Optionally, the process exit event interception subunit is adapted to,

When the specified virtual machine occurs when the virtual machine enters the VM_ENTRY event: the address in the specified debug address register in the VCPU of the specified virtual machine is set as the process exit key location address; the debug control register in the VCPU of the specified virtual machine is set Execute the control bit corresponding to the specified debug address register in the specified virtual machine; set the TRAP_debug control bit in the virtual machine control domain VMCS data structure of the specified virtual machine;

When the specified virtual machine has a virtual machine exit VM_EXIT event: if it is a debugging abnormal event, it is judged whether the address that generates the exception is the address of the key position of the process exit, and if it is, read the _ of the exit process saved in the key position address of the process exit The address of the EPROCESS management structure.

Optionally, the process event intercepting unit includes:

The process creation event intercepting subunit is adapted to maintain a list of currently running processes about the specified virtual machine; monitor the process switching event that occurs inside the specified virtual machine, and obtain the VCPU of the specified virtual machine when the event is monitored The value in the CR3 register; the value in the CR3 register is the relevant information of the process after switching; judge whether the value in the obtained CR3 register exists in the current running process list, if it does not exist, it means that one is created process, will obtain the value in the CR3 register and add it to the list of currently running processes; when intercepting the exit event of a process in the specified virtual, delete the exited process from the list of currently running processes.

Optionally, the process creation event interception subunit is adapted to set the CPU_BASED_CR3_LOAD_EXITING control bit in the virtual machine control domain VMCS data structure of the specified virtual machine; the control bit is located in the virtual machine for processor event of the VMCS data structure The execution control domain determines whether the virtual machine exits the VM_EXIT event when the virtual machine executes the Move to CR3 instruction, that is, process switching.

Optionally, the trusted process list maintenance unit is adapted to, when intercepting a process creation event in the specified virtual machine, judge whether the process is in the trusted process list, and if not, add the process to the trusted process in the list; when a process exit event in the specified virtual machine is intercepted, the process is deleted from the trusted process list.

The technical solution provided by the present invention aims at the hidden characteristics of the virtual machine after being infected by malicious software, respectively maintaining the trusted process list recording the real running process in the specified virtual machine and the untrusted process list recording the process in the specified virtual machine , by comparing the list of trusted processes and the list of untrusted processes, it is determined that the process hiding behavior in the virtual machine exists. Compared with the existing technology, the detection of this scheme is more comprehensive and effective. In particular, it can detect the attack on kernel objects, which meets the common needs of cloud service providers and users.

The above description is only an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention, it can be implemented according to the contents of the description, and in order to make the above and other purposes, features and advantages of the present invention more obvious and understandable , the specific embodiments of the present invention are enumerated below.

Description of 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 embodiment. The drawings are only for the purpose of illustrating a preferred embodiment and are not to be considered as limiting the invention. Also throughout the drawings, the same reference numerals are used to designate the same parts. In the attached picture:

FIG. 1 shows a flowchart of a method for detecting hidden processes in a virtual machine according to an embodiment of the present invention;

Fig. 2 shows a schematic diagram of a doubly linked list made up of _EPROCESS data structure according to one embodiment of the present invention;

Fig. 3 shows the flow chart of the exit of Windows process according to one embodiment of the present invention;

FIG. 4 shows a schematic diagram of a data structure related to an NtTerminateProcess service routine according to an embodiment of the present invention;

Fig. 5 shows a schematic diagram of DR7 control bits according to one embodiment of the present invention;

FIG. 6 shows a flow chart of the Xen kernel intercepting a process exit event in a virtual machine according to another embodiment of the present invention;

FIG. 7 shows a schematic diagram of address translation in shadow page table mode according to an embodiment of the present invention;

FIG. 8 shows a schematic diagram of memory mapping in extended page table mode according to an embodiment of the present invention;

FIG. 9 shows a flow chart of maintaining a trusted process list that records a real running process in a specified virtual machine according to an embodiment of the present invention;

FIG. 10 shows a schematic diagram of a hidden process detection device in a virtual machine according to an embodiment of the present invention;

Fig. 11 shows a schematic diagram of a process event intercepting unit in a hidden process detection device in a virtual machine according to an embodiment of the present invention.

Detailed ways

Exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although 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 by the embodiments set forth herein. Rather, these embodiments are provided for more thorough understanding of the present disclosure and to fully convey the scope of the present disclosure to those skilled in the art.

Fig. 1 shows a flowchart of a method for detecting a hidden process in a virtual machine according to an embodiment of the present invention. As shown in Figure 1, the method includes:

Step S110, intercepting the process exit event in the specified virtual machine, and intercepting the process creation event in the specified virtual machine.

Step S120, according to the intercepted process exit and process creation events in the specified virtual machine, maintain a trusted process list that records the real running process in the specified virtual machine.

Step S130, by traversing the relevant data structures that record the process information in the specified virtual machine, to obtain one or more untrusted process lists that record the processes in the specified virtual machine.

Step S140, by comparing the trusted process list and the untrusted process list, determine the hidden process in the specified virtual machine.

It can be seen that the method shown in Figure 1 aims at the hidden characteristics of the virtual machine after it is infected by malware, respectively maintains and records the trusted process list of the real running process in the specified virtual machine and records the untrustworthy process of the specified virtual machine. The process list, by comparing the trusted process list and the untrusted process list, determines the existence of the process hiding behavior in the virtual machine. Compared with the existing technology, the detection of this scheme is more comprehensive and effective. In particular, it can detect the attack on kernel objects, which meets the common needs of cloud service providers and users.

The Windows operating system uses a doubly linked list with the _EPROCESS data structure as a node to maintain the process information in operation in the kernel address space, and Fig. 2 shows a schematic diagram of a doubly linked list formed according to an embodiment of the present invention. , the tools in the operating system including the task manager and the common system calls including ZwQuerySystemInformation can obtain the process list by traversing the doubly linked list shown in Figure 2. Unlinking does not affect the scheduling operation of the system, so it has become the most used means of hiding processes in Direct Kernel Object Manipulation (DKOM, Direct Kernel Object Manipulation). It can be seen that traversing the _EPROCESS data structure in the kernel address space can be used as an unavailable One of the ways to send process list. In addition, the untrusted process list can also be constructed by traversing the PspCidTable handle table or the csrss.exe handle table, and multiple untrusted process lists are constructed so that the result of comparing the trusted process list and the untrusted process list in the method shown in Figure 1 is more accurate. comprehensive.

Therefore, based on the above description, in one embodiment of the present invention, step S130 of the method shown in FIG. 1 obtains one or Multiple untrusted process lists include:

Step S131, by traversing one or more of the _EPROCESS data structure in the kernel address space, the PspCidTable handle table or the csrss.exe handle table, correspondingly obtain one or more groups of process information in the specified virtual machine;

Step S132, according to the obtained one or more sets of process information, generate corresponding one or more untrusted process lists.

The operating system divides the runtime permission state into user mode and kernel mode. Applications run in user mode most of the time, and enter kernel mode when encountering privileged instructions. In this way, the system kernel is isolated and protected. . The system call is the interface provided by the operating system kernel to the application program in the user mode. The application program implements the call to the service provided by the kernel through the system call. When the application program uses the system call, the operating system enters through the int 0x2E interrupt or fast system call In the kernel mode, the kernel calls the system call service routine to realize the processing of the system call.

There are many different ways for a process to exit in user mode, including returning after the normal entry function is executed, actively calling the process exit API provided by the win32 interface, receiving a process shutdown signal sent by other processes, etc. However, whether it is actively or passively terminated Every process has to go through the whole process of transition from user mode to kernel mode. Fig. 3 has shown the flowchart of the exit of Windows process according to one embodiment of the present invention, as shown in Fig. 3, the process that produces exit behavior needs to call the service routine in win32 interface, Native API and kernel mode successively, in this process Among them, the process of calling the Native API by the win32 interface is carried out by the operating system. There are many ways for a process to exit, but the function call relationship of these ways will eventually be concentrated on two Native APIs, namely Nt/ZwTerminateProcess. These two APIs have corresponding service routines in the kernel, but the ZwTerminateProcess service routine will Call the NtTerminateProcess service routine to complete the resource release function of the process termination.

From the description of the process exit process shown in Figure 3 above, it can be seen that the operating system will call the NtTerminateProcess service routine in the kernel to process the process exit. By reverse analyzing the assembly code of the service routine, it is known that : When a process exit event occurs in the virtual machine, the system will call the NtTerminateProcess service routine. After the NtTerminateProcess service routine finishes closing the process, it will unlink the address of the _EPROCESS management structure of the exiting process in the linked list composed of the process management structure And released to the specified address, the present invention uses the specified address as the process exit key position address. It can be seen that by monitoring the address of the process exit key location, the interception of the process exit event in the specified virtual machine can be realized. Specifically, in one embodiment of the present invention, step S110 of the method shown in FIG. 1 intercepts the specified The process exit event in the virtual machine includes: obtaining the address of the key location of process exit; monitoring the execution event of the address of the key location of process exit, when the code at this address is called, it indicates that a process ends, and the _EPROCESS management structure of the exit process is obtained from this address address.

Wherein, the acquisition of the address of the key location for process exit depends on the analysis of the NtTerminateProcess service routine. Therefore, in one embodiment of the present invention, the above-mentioned acquisition of the address of the key location for process exit includes: obtaining the address of the NtTerminateProcess service routine, according to the NtTerminateProcess service The address of the routine obtains the address of the key location of the process exit. In order to obtain the address of the NtTerminateProcess service routine, the present invention reversely analyzes the management structure related to the system call service routine in the Windows kernel, and Fig. 4 shows a schematic diagram of the relevant data structure of the NtTerminateProcess service routine according to an embodiment of the present invention , as shown in Figure 4, the data structures related to the NtTerminateProcess service routine include: KeServiceDescripterTable and SSDT table, KeServiceDescripterTable is a data structure derived by the kernel, which stores the base address of the SSDT table and the number of service routine entries in the SSDT table; SSDT The table saves the entry address of each service routine in the form of an array. Therefore, in one embodiment of the present invention, obtaining the address of the NtTerminateProcess service routine includes the following processes: first, obtain the address of the KeServiceDescriptorTable data structure; secondly, obtain the address of the SSDT table and determine that the NtTerminateProcess service routine is in the KeServiceDescriptorTable data structure offset in the SSDT table; finally, the address of the NtTerminateProcess service routine is obtained at the specified offset in the SSDT table.

In a specific embodiment of the present invention, by reversely analyzing the assembly code of the NtTerminateProcess service routine, it is known that after the service routine completes the closing process operation, it will execute the _EPROCESS management structure of releasing the exit process at the 0x13c offset function, the code snippet is as follows:

It can be seen that before calling the ObfDereferenceObject function, the NtTerminateProcess service routine will put the parameter information into the ecx register. At this time, the address of the _EPROCESS management structure of the exiting process is put into the ecx register. Therefore, it will be relative to the NtTerminateProcess service routine The address with an address offset of 0x13c is used as the monitoring object, that is, as the key address of the process exit described above. Therefore, in one embodiment of the present invention, after obtaining the address of the NtTerminateProcess service routine, obtaining the process exit key position address according to the address of the NtTerminateProcess service routine includes: obtaining the address offset 0x13c relative to the address of the NtTerminateProcess service routine Address, the address is the address of the ecx register, and it is also the address of the key location of the process exit. When the address is executed, it means that a process will end, and the address of the _EPROCESS management structure of the process can be obtained from the ecx register to determine the target process where the exit event occurs.

Based on the descriptions of the above-mentioned embodiments, it can be seen that the present invention intercepts the process exit event in the virtual machine by intercepting the event of the virtual machine executing to the key position address of the process exit. This method combines the characteristics of virtualization technology and the debugging mechanism provided by the CPU. In general, step S110 of the method shown in FIG. 1 intercepts the method of process exit event in the specified virtual machine can be divided into the following two steps:

First, set the control bit and address of the debug register in the virtual machine VCPU; in this way, when the virtual machine executes to the key position address of the process exit, a debugging exception will be generated.

Secondly, the Xen kernel intercepts the debugging exception event generated in the virtual machine, and judges whether the address triggering the debugging event is the key location address of the process that needs to be monitored, thereby realizing the monitoring function executed on the address.

In order to support the debugging mechanism, the CPU of X86 architecture (including physical CPU and VCPU) provides eight debugging registers, DR0~DR7. By setting these debugging registers, the function of triggering debugging exceptions by specifying data breakpoints and instruction breakpoints can be realized. DR0~DR3 are called debug address registers, which are used to store the linear addresses of breakpoints, that is to say, debugging and monitoring of up to 4 linear addresses can be realized at the same time; DR6 is called a debug status register, which records exceptions when debugging exceptions occur Information such as which debug address register is generated and the conditions for abnormal triggering; DR7 is called the debug control register, through which the debug address register takes effect and the trigger condition for the breakpoint is set. Fig. 5 shows the schematic diagram of DR7 control bit according to an embodiment of the present invention, as shown in Fig. 5, Ln (n=0,1,2,3) control bit setting shows that the address that DRn sets is only triggered under the current process Breakpoint; the Gn (n=0,1,2,3) control bit setting indicates that the address set by DRn will trigger a breakpoint in all processes; the GD bit is used to enable the function of protecting the debug address register; R/Wn (n= 0,1,2,3) consists of two bits, indicating the condition of DRn address triggering debugging exception, including instruction execution (00), data writing (01), I/O reading and writing (10) and not including instruction reading The data reading and writing (11); LENn (n=0, 1, 2, 3) consists of two bits, indicating the length of the DRn monitoring address.

Compared with executing to a specific address to generate debugging exceptions, the interception method of the Xen kernel for debugging exceptions is relatively straightforward. The VMCS control structure provides a control bit for intercepting debugging exceptions in the exception bitmap area. Setting this control bit can realize Interception of debug exceptions.

Based on the above analysis, in one embodiment of the present invention, in the step S110 of the method shown in Figure 1, the Xen kernel monitoring process exits the execution event of the key location address, so as to intercept the process exit event in the specified virtual machine and include:

Step S111, when a virtual machine enters a VM_ENTRY event in the specified virtual machine: the address in the specified debugging address register in the VCPU of the specified virtual machine is set as the process exit key position address; the debugging control in the VCPU of the specified virtual machine is set The execution control bit corresponding to the specified debug address register in the register; the TRAP_debug control bit in the virtual machine control domain VMCS data structure of the specified virtual machine is set.

In this step, the execution control bit corresponding to the specified debug address register in the debug control register in the VCPU of the specified virtual machine is set to make the specified debug address register take effect, and, in order to realize the interception of the process exit event by the Xen kernel, the Xen The function of processing the virtual machine entry event in the kernel has added the part of setting the virtual CPU debug register and the implementation of setting the TRAP_debug control bit.

Step S112, when the virtual machine exits the VM_EXIT event in the specified virtual machine: if it is a debugging abnormal event, then judge whether the address that generates the exception is the address of the process exit key location, and if so, read the exit process stored in the process exit key location address The address of the _EPROCESS management structure.

Fig. 6 shows the flow chart of the Xen kernel intercepting the process exit event in the virtual machine according to another embodiment of the present invention. In the specific embodiment shown in Fig. 6, the process exit key location address is A, and the designated debug address The register is DR3, and the debug control register is DR7. When a virtual machine exits VM_EXIT event occurs in the specified virtual machine: if it is a debugging exception event, it is judged whether the abnormal address is the address of the process exit key position, and if it is, read the process exit The address of the _EPROCESS management structure of the exit process saved in the key location address; further, this embodiment also reads the page directory address U of the exit process, and since the process has exited, U is recorded from the linked list of CR3 in this domain Delete, transfer U to Domain0, delete the exiting process from the process list, and restore the settings related to the debug register in the VCPU.

The method of intercepting the process exit event was introduced earlier. Compared with the process exit event that can be intercepted by intercepting NtTerminateProcess, the process creation process in the Windows system is much more complicated than the process exit process. Although the operating system provides the NtCreateProcess system similar to NtTerminateProcess Call, but process creation is not equivalent to NtCreateProcess being called, and process creation can also be realized without calling NtCreateProcess. In addition, the system calls for executing the process creation function of each version of Windows are different, from NtCreateProcess, NtCreateProcessEx to the current NtCreateUserProcess. Considering these two problems, a scheme suitable for process creation behavior interception in virtualization environment is proposed.

In order to support multi-task scheduling and management, the CPU provides a series of control registers, among which the CR3 register is a very important control register for the operating system to implement the segment page memory management technology. Depending on whether the operating system is running in physical address extension (PAE) mode, different contents are stored in the CR3 register: when the operating system is running in non-PAE mode, the address space is divided into two levels: Page Directory Table (PDT) And page table (Page Table), where the page directory records the address of the next-level page table, so that a process can have multiple page tables. In this case, the CR3 register stores the physical address of the page directory of the current process; when the operating system is running in PAE mode, the address space is divided into three levels, and a page directory pointer table is added to the upper level of the page directory (Page Directory-Pointer Table, PDPT), so that a process can have multiple page directories. In this case, the CR3 register stores the physical address of the page directory pointer table of the current process.

The PDT/PDPT address stored in the CR3 register has the following characteristics: a PDT/PDPT address will be allocated when the process is created, and the address will not change during the running of the process and is fixed; the currently running process has its own PDT The /PDPT address is unique; as long as the process is scheduled, it will load the PDT/PDPT address into the CR3 register, which is necessary. Considering that the address stored in the CR3 register is fixed, unique and necessary, a new address in the CR3 register can be used as a sign of process creation.

In a virtualization environment, the Xen kernel maintains information such as virtual registers of each VCPU of a virtual machine for context switching during scheduling. The CR3 register in the virtual machine stores different address types according to different methods of memory virtualization. There are the following types of addresses in the virtualization environment: Virtual machine virtual address (Guest Virtual Address, GVA): this address corresponds to the virtual address in the ordinary physical machine, and is converted into a virtual physical address through the paging mechanism; virtual machine physical address (Guest PhysicalAddress , GPA): corresponds to the physical address of an ordinary physical machine, but because of the introduction of virtualization technology, the physical address of the virtual machine is not a real physical address, but also a logical address space; the host virtual address (Hardware Virtual Address, HVA) : The Xen kernel manages memory through the paging mechanism, so it also has a virtual address; Host Physical Address (Hardware Physical Address, HPA): This address is the real physical address for the virtualization platform to access the memory.

Virtualization technology provides two solutions to support memory virtualization, namely the shadow page table solution and the extended page table (Extended Page Table) solution.

FIG. 7 shows a schematic diagram of address translation in shadow page table mode according to an embodiment of the present invention. As shown in Figure 7, in the shadow page table scheme, the Xen kernel maintains the same structure and number of page tables as the virtual machine for each process in the virtual machine. When the page table in the virtual machine is added, modified, or deleted When changing, the shadow page table also needs to change accordingly. Unlike the original page table, the shadow page table stores the mapping relationship from GVA to HPA. When the virtual machine process switches, it is actually loaded into the CR3 register. is the page directory address in the shadow page table. With the development of hardware technology, the current CPU has provided hardware support for memory virtualization, that is, Extended Page Table Technology (Extended Page Table, EPT), adding hardware support for GPA to HPA conversion, as shown in Figure 7. The Xen kernel maintains a set of page tables for mapping from GPA to HPA and a pointer EPT pointer to the highest-level page table for each virtual machine. Every memory access request of a virtual machine needs to go through this set of page tables and EPT pointers. assisted to complete the conversion from GPA to HPA, the virtual machine still completes the conversion from GVA to GPA through the local page table, and the process has not changed. At this time, GPA is stored in CR3.

FIG. 8 shows a schematic diagram of memory mapping in extended page table mode according to an embodiment of the present invention. It can be seen that in the EPT mode memory virtualization solution, the virtual machine CR3 register stores the virtual machine physical address, so it has the same fixedness, uniqueness and necessity as the address in the physical machine CR3 register, so it can still be A new address appears in the CR3 register as a sign of process creation.

Similar to the method used to intercept process exit events, in order to intercept process creation events, it is also necessary to set the control bit in the VMCS control structure, that is, the CPU_BASED_CR3_LOAD_EXITING control bit, which is located in the virtual machine execution control of the VMCS for processor events. Domain, which determines whether the VM_EXIT event occurs when the virtual machine executes the Move to CR3 instruction, that is, process switching. In addition, the currently running CR3 address list is maintained for each virtual machine in the Xen kernel. When a process switch occurs inside the virtual machine, the CR3 value of the current VCPU is obtained. If the value does not appear in the CR3 address list, it means that A new process adds this value to the CR3 address list.

Based on the above description, in one embodiment of the present invention, step S110 of the method shown in FIG. 1 intercepting the process creation event in the specified virtual machine includes:

Step S113, maintaining a list of currently running processes of the specified virtual machine.

Step S114, monitor the process switching event that occurs inside the specified virtual machine, and obtain the value in the CR3 register of the VCPU of the specified virtual machine when the event is monitored; the value in the CR3 register is the relevant information of the switched process.

Step S115, judging whether the obtained value in the CR3 register exists in the current running process list, if not, it means that a process has been created, and adding the obtained value in the CR3 register to the current running process list.

Step S116, when intercepting the exit event of a process in the specified virtual, delete the exited process from the list of currently running processes.

Wherein, in one embodiment, the above-mentioned step S114 monitors the process switching event that occurs inside the specified virtual machine includes: setting the CPU_BASED_CR3_LOAD_EXITING control bit in the virtual machine control domain VMCS data structure of the specified virtual machine; the control bit is located in the VMCS data structure for The virtual machine execution control domain of the processor event determines whether the virtual machine exits the VM_EXIT event when the virtual machine executes the Move to CR3 instruction, that is, process switching.

Through the interception technology of process creation and exit events in the virtual machine, it is possible to reliably monitor the complete life cycle of each process in the virtual machine, thereby establishing a list of processes actually running in the virtual machine. Specifically, Fig. 9 shows a flow chart of maintaining a trusted process list that records a real running process in a specified virtual machine according to an embodiment of the present invention. As shown in Fig. 9, the Xen kernel code saves the running virtual Add the linked list structure process_cr3_list to save the trusted process list in the data structure struct hvm_domain of machine information.

In another embodiment of the present invention, step S120 of the method shown in FIG. 1 maintains a trusted process list that records the real running process in the specified virtual machine, including:

Step S121, when intercepting a process creation event in the specified virtual machine, judge whether the process is in the trusted process list, if not, add the process to the trusted process list;

Step S122, when a process exit event in the specified virtual machine is intercepted, the process is deleted from the trusted process list.

Fig. 10 shows a schematic diagram of an apparatus for detecting hidden processes in a virtual machine according to an embodiment of the present invention. As shown in Figure 10, the hidden process detection device 1000 in the virtual machine includes:

The process event intercepting unit 1010 is adapted to intercept the process exit event in the specified virtual machine, and intercept the process creation event in the specified virtual machine;

The trusted process list maintenance unit 1020 is adapted to maintain a trusted process list that records the actual running process in the specified virtual machine according to the intercepted process exit and process creation events in the specified virtual machine;

The untrusted process list maintenance unit 1030 is adapted to obtain one or more untrusted process lists that record the processes in the specified virtual machine by traversing the relevant data structures that record the process information in the specified virtual machine;

The comparison unit 1040 is adapted to determine the hidden process in the specified virtual machine by comparing the trusted process list and the untrusted process list.

It can be seen that the device shown in Figure 10 maintains and records the trusted process list of the real running process in the specified virtual machine and records the untrustworthy process of the specified virtual machine in view of the hidden characteristics of the virtual machine after being infected by malware. The process list, by comparing the trusted process list and the untrusted process list, determines the existence of the process hiding behavior in the virtual machine. Compared with the existing technology, the detection of this scheme is more comprehensive and effective. In particular, it can detect the attack on kernel objects, which meets the common needs of cloud service providers and users.

In one embodiment of the present invention, the untrusted process list maintenance unit 1030 is adapted to obtain the corresponding process by traversing one or more of the _EPROCESS data structure in the kernel address space, the PspCidTable handle table, or the csrss.exe handle table. One or more sets of process information in the virtual machine; and one or more corresponding untrusted process lists are generated according to the obtained one or more sets of process information.

Fig. 11 shows a schematic diagram of an apparatus for detecting hidden processes in a virtual machine according to another embodiment of the present invention. As shown in Figure 11, in this embodiment, on the basis of the hidden process detection device in the virtual machine shown in Figure 10, wherein the process event interception unit 1010 includes: a process exit event interception subunit 1011 and a process creation event interception Subunit 1012.

The process exit event intercepting subunit 1011 is adapted to obtain the address of the key location of the process exit; wherein, the system will call the NtTerminateProcess service routine in the kernel for the process exit process, and the NtTerminateProcess service routine will exit the process after completing the closing process operation. The address of the _EPROCESS management structure is unlinked in the linked list composed of the process management structure and released to the specified address, and the specified address is used as the address of the key position of process exit; and the address execution event suitable for monitoring the key position of process exit, when the code When called, it indicates that a process is about to end, and the address of the _EPROCESS management structure of the exiting process is obtained from this address.

In one embodiment of the present invention, the process exit event intercepting subunit 1011 obtains the address of the NtTerminateProcess service routine, and obtains the process exit key location address according to the address of the NtTerminateProcess service routine; it is specifically suitable for obtaining the address of the KeServiceDescriptorTable data structure, from Obtain the address of the SSDT table in the KeServiceDescriptorTable data structure and determine the offset of the NtTerminateProcess service routine in the SSDT table, and obtain the address of the NtTerminateProcess service routine at the specified offset of the SSDT table.

In one embodiment of the present invention, the process exit event interception subunit 1011 obtains an address offset by 0x13c relative to the address of the NtTerminateProcess service routine, which is the address of the ecx register, and is used as the process exit key position address .

In one embodiment of the present invention, the process exit event intercepting subunit 1011 is adapted to: when a virtual machine entry VM_ENTRY event occurs in the specified virtual machine: set the address in the specified debug address register in the VCPU of the specified virtual machine to The process exits the key location address; the corresponding execution control bit in the debug control register in the VCPU of the specified virtual machine is set; the TRAP_debug in the virtual machine control domain VMCS data structure of the specified virtual machine is set Control bit; when the virtual machine exits the VM_EXIT event in the specified virtual machine: if it is a debugging exception event, then it is judged whether the abnormal address is the address of the process exiting the key position, and if it is, the exit stored in the process exiting the key position address is read The address of the process's _EPROCESS management structure.

In one embodiment of the present invention, the process creation event interception subunit 1012 is adapted to maintain a list of currently running processes of the specified virtual machine; Obtain the value in the CR3 register of the VCPU of the specified virtual machine during the event; the value in the CR3 register is the relevant information of the process after switching; judge whether the value in the obtained CR3 register exists in the current running process list, if it does not exist, it means that a process has been created, and the value in the CR3 register will be obtained and added to the current running process list; when the process exit event in the specified virtual is intercepted, from the current running process list delete the exiting process.

In one embodiment of the present invention, the process creation event interception subunit 1012 is adapted to set the CPU_BASED_CR3_LOAD_EXITING control bit in the VMCS data structure of the virtual machine control domain of the specified virtual machine; the control bit is located in the processor-specific The virtual machine execution control domain of the event determines whether the virtual machine exits the VM_EXIT event when the virtual machine executes the Move to CR3 instruction, that is, process switching.

In one embodiment of the present invention, the trusted process list maintenance unit 1020 is adapted to, when intercepting a process creation event in the specified virtual machine, determine whether the process is in the trusted process list, and if not, set the The process is added to the trusted process list; when a process exit event in the specified virtual machine is intercepted, the process is deleted from the trusted process list.

The specific implementation principles and embodiments of the above-mentioned units in the implementation process have been described in detail above, and will not be repeated here.

To sum up, the technical solution provided by the present invention aims at the hidden characteristics of the virtual machine after being infected by malware, respectively maintains and records the trusted process list of the real running process in the specified virtual machine and records the process in the specified virtual machine The untrusted process list of the virtual machine is determined by comparing the trusted process list with the untrusted process list to determine the existence of the process hiding behavior in the virtual machine. Compared with the existing technology, the detection of this scheme is more comprehensive and effective. In particular, it can detect the attack on kernel objects, which meets the common needs of cloud service providers and users.

It should be noted:

The algorithms and displays presented herein are not inherently related to any particular computer, virtual appliance, or other device. Various general purpose devices can also be used with the teachings based on this. The structure required to construct such an apparatus will be apparent from the foregoing description. Furthermore, the present invention is not specific to any particular programming language. It should be understood that various programming languages can be used to implement the content of the present invention described herein, and the above description of specific languages is for disclosing the best mode of the present invention.

In the description provided herein, numerous specific details are set forth. However, it is understood 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 the understanding of this description.

Similarly, it should be appreciated that in the foregoing description of exemplary embodiments of the invention, in order to streamline this disclosure and to facilitate an understanding of one or more of the various inventive aspects, various features of the invention are sometimes grouped together in a single embodiment, figure, or its description. This method of disclosure, however, is not to be interpreted as reflecting an intention that the claimed invention 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 can understand that the modules in the device in the embodiment can be adaptively changed and arranged in one or more devices different from the embodiment. Modules or units or components in the embodiments may be combined into one module or unit or component, and furthermore may be divided into a plurality of sub-modules or sub-units or sub-assemblies. All features disclosed in this specification (including accompanying claims, abstract and drawings) and any method or method so disclosed may be used in any combination, except that at least some of such features and/or processes or units are mutually exclusive. All processes or units of equipment are combined. Each feature disclosed in this specification (including 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 understand that although some embodiments described herein include some features included in other embodiments but not others, combinations of features from 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 present 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 should understand that a microprocessor or a digital signal processor (DSP) may be used in practice to implement some or all of the components in the device for detecting hidden processes in a virtual machine according to an embodiment of the present invention Or full functionality. The present invention can also be implemented as an apparatus or an apparatus program (for example, a computer program and a computer program product) for performing a part or all of the methods described herein. Such a program for realizing the present invention may be stored on a computer-readable medium, or may be in the form of one or more signals. Such a signal may be downloaded from an Internet site, or provided on a carrier signal, or provided 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 can be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In a unit claim enumerating several means, several of these means can be embodied by one and the same item of hardware. The use of the words first, second, and third, etc. does not indicate any order. These words can be interpreted as names.

The invention discloses A1, a hidden process detection method in a virtual machine, wherein the method includes:

Intercepting a process exit event in a specified virtual machine, and intercepting a process creation event in the specified virtual machine;

According to the intercepted process exit and process creation events in the specified virtual machine, maintain a trusted process list that records the real running process in the specified virtual machine;

Obtaining one or more untrusted process lists recording processes in the specified virtual machine by traversing a related data structure that records process information in the specified virtual machine;

By comparing the trusted process list and the untrusted process list, the hidden process in the specified virtual machine is determined.

A2. The method as described in A1, wherein, by traversing the relevant data structure that records the process information in the specified virtual machine, one or more untrusted process lists that record the processes in the specified virtual machine are obtained include:

By traversing one or more of the _EPROCESS data structure in the kernel address space, the PspCidTable handle table or the csrss.exe handle table, correspondingly obtain one or more groups of process information in the virtual machine;

According to the obtained one or more sets of process information, corresponding one or more untrusted process lists are generated.

A3. The method as described in A1, wherein the intercepting the process exit event in the specified virtual machine includes:

Obtain the process exit key location address; monitor the process exit key location address execution event, when the code at this address is called, it indicates that a process ends, and obtain the address of the _EPROCESS management structure of the exit process from this address.

A4. The method as described in A3, wherein obtaining the process exit key location address comprises: obtaining the address of the NtTerminateProcess service routine, and obtaining the process exit key location address according to the address of the NtTerminateProcess service routine;

The address of obtaining the NtTerminateProcess service routine includes:

Obtain the address of the KeServiceDescriptorTable data structure;

Obtain the address of the SSDT table from the KeServiceDescriptorTable data structure and determine the offset of the NtTerminateProcess service routine in the SSDT table;

Gets the address of the NtTerminateProcess service routine at the specified offset in the SSDT table.

A5, the method as described in A4, wherein, the address acquisition process exit key location address according to the NtTerminateProcess service routine includes:

Get the address at offset 0x13c relative to the address of the NtTerminateProcess service routine.

A6. The method as described in A3, wherein the monitoring process exiting the execution event of the key location address includes:

When the specified virtual machine occurs when the virtual machine enters the VM_ENTRY event: the address in the specified debug address register in the VCPU of the specified virtual machine is set as the process exit key location address; the debug control register in the VCPU of the specified virtual machine is set Execute the control bit corresponding to the specified debug address register in the specified virtual machine; set the TRAP_debug control bit in the virtual machine control domain VMCS data structure of the specified virtual machine;

When the specified virtual machine has a virtual machine exit VM_EXIT event: if it is a debugging abnormal event, it is judged whether the address that generates the exception is the address of the key position of the process exit, and if it is, read the _ of the exit process saved in the key position address of the process exit The address of the EPROCESS management structure.

A7. The method according to A1, wherein the intercepting the process creation event in the specified virtual machine includes:

maintaining a list of currently running processes on the specified virtual machine;

Monitor the process switching event that occurs inside the specified virtual machine, and obtain the value in the CR3 register of the VCPU of the specified virtual machine when the event is monitored; the value in the CR3 register is the relevant information of the switched process;

Judging whether the value in the obtained CR3 register exists in the list of currently running processes, if it does not exist, it means that a process has been created, and adding the value obtained in the CR3 register to the list of currently running processes;

When the exit event of a process in the specified virtual is intercepted, the exited process is deleted from the list of currently running processes.

A8. The method according to A7, wherein the monitoring the process switching event occurring inside the specified virtual machine includes:

Set the CPU_BASED_CR3_LOAD_EXITING control bit in the virtual machine control domain VMCS data structure of the specified virtual machine; this control bit is located at the virtual machine execution control domain for processor events of the VMCS data structure, and determines when the virtual machine executes the Move to CR3 instruction that is the process Whether the virtual machine exits VM_EXIT event occurs when switching.

A9. The method as described in A1, wherein said maintaining a list of trusted processes that records the real running processes in the specified virtual machine includes:

When intercepting a process creation event in the specified virtual machine, it is judged whether the process is in the trusted process list, if not, the process is added to the trusted process list;

When a process exit event in the specified virtual machine is intercepted, the process is deleted from the trusted process list.

The present invention also discloses B10, a hidden process detection device in a virtual machine, wherein the device includes:

A process event intercepting unit, adapted to intercept a process exit event in a specified virtual machine, and a process creation event in the specified virtual machine;

The trusted process list maintenance unit is adapted to maintain a trusted process list recording the real running process in the specified virtual machine according to the intercepted process exit and process creation events in the specified virtual machine;

The untrusted process list maintenance unit is adapted to obtain one or more untrusted process lists that record the processes in the specified virtual machine by traversing the relevant data structures that record the process information in the specified virtual machine;

The comparing unit is adapted to determine the hidden process in the specified virtual machine by comparing the trusted process list and the untrusted process list.

B11. The device as described in B10, wherein,

The untrusted process list maintenance unit is adapted to obtain one or more groups in the virtual machine by traversing one or more of the _EPROCESS data structure in the kernel address space, the PspCidTable handle table or the csrss.exe handle table Process information; according to one or more sets of obtained process information, generate corresponding one or more untrusted process lists.

B12. The device according to B10, wherein the process event interception unit includes:

The process exit event interception subunit is suitable for obtaining the address of the key position of process exit; and it is suitable for monitoring the execution event of the key position address of process exit. When the code at this address is called, it indicates that a process is about to end, and the _ of the exit process is obtained from this address. The address of the EPROCESS management structure.

B13. The device of B12, wherein,

The process exit event intercepts the subunit, obtains the address of the NtTerminateProcess service routine, and obtains the process exit key position address according to the address of the NtTerminateProcess service routine; it is specifically suitable for obtaining the address of the KeServiceDescriptorTable data structure, and obtains the SSDT table from the KeServiceDescriptorTable data structure The address and the offset of the NtTerminateProcess service routine in the SSDT table are determined, and the address of the NtTerminateProcess service routine is obtained at the specified offset of the SSDT table.

B14. The device of B13, wherein,

The process exit event intercepting subunit obtains an address offset by 0x13c relative to the address of the NtTerminateProcess service routine, and uses this address as the address of a key location for process exit.

B15. The device according to B12, wherein the process exit event intercepting subunit is adapted to,

When the specified virtual machine occurs when the virtual machine enters the VM_ENTRY event: the address in the specified debug address register in the VCPU of the specified virtual machine is set as the process exit key location address; the debug control register in the VCPU of the specified virtual machine is set Execute the control bit corresponding to the specified debug address register in the specified virtual machine; set the TRAP_debug control bit in the virtual machine control domain VMCS data structure of the specified virtual machine;

When the specified virtual machine has a virtual machine exit VM_EXIT event: if it is a debugging abnormal event, it is judged whether the address that generates the exception is the address of the key position of the process exit, and if it is, read the _ of the exit process saved in the key position address of the process exit The address of the EPROCESS management structure.

B16. The device according to B10, wherein the process event interception unit includes:

The process creation event intercepting subunit is adapted to maintain a list of currently running processes about the specified virtual machine; monitor the process switching event that occurs inside the specified virtual machine, and obtain the VCPU of the specified virtual machine when the event is monitored The value in the CR3 register; the value in the CR3 register is the relevant information of the process after switching; judge whether the value in the obtained CR3 register exists in the current running process list, if it does not exist, it means that one is created process, will obtain the value in the CR3 register and add it to the list of currently running processes; when intercepting the exit event of a process in the specified virtual, delete the exited process from the list of currently running processes.

B17. The device of B16, wherein,

The process creation event interception subunit is adapted to set the CPU_BASED_CR3_LOAD_EXITING control bit in the VMCS data structure of the virtual machine control domain of the specified virtual machine; the control bit is located in the virtual machine execution control domain for processor events of the VMCS data structure, Determines whether the virtual machine exits VM_EXIT event when the virtual machine executes the Move to CR3 instruction, that is, process switching.

B18. The device of B10, wherein,

The trusted process list maintenance unit is adapted to determine whether the process is in the trusted process list when intercepting a process creation event in the specified virtual machine, and if not, add the process to the trusted process list; When a process exit event in the specified virtual machine is intercepted, the process is deleted from the trusted process list.

Claims (10)

1. A hidden process detection method in a virtual machine, wherein the method comprises: Intercepting a process exit event in a specified virtual machine, and intercepting a process creation event in the specified virtual machine; According to the intercepted process exit and process creation events in the specified virtual machine, maintain a trusted process list that records the real running process in the specified virtual machine; Obtaining one or more untrusted process lists recording processes in the specified virtual machine by traversing a related data structure that records process information in the specified virtual machine; By comparing the trusted process list and the untrusted process list, the hidden process in the specified virtual machine is determined. 2. The method according to claim 1, wherein, the one or more untrustworthy records for recording the process in the specified virtual machine are obtained by traversing the relevant data structure recorded with the process information in the specified virtual machine The process list includes: By traversing one or more of the _EPROCESS data structure in the kernel address space, the PspCidTable handle table or the csrss.exe handle table, correspondingly obtain one or more groups of process information in the virtual machine; According to the obtained one or more sets of process information, corresponding one or more untrusted process lists are generated. 3. The method according to claim 1, wherein said intercepting a process exit event in a specified virtual machine comprises: Obtain the process exit key location address; monitor the process exit key location address execution event, when the code at this address is called, it indicates that a process ends, and obtain the address of the _EPROCESS management structure of the exit process from this address. 4. The method according to claim 3, wherein obtaining the process exit key location address comprises: obtaining the address of the NtTerminateProcess service routine, and obtaining the process exit key location address according to the address of the NtTerminateProcess service routine; The address of obtaining the NtTerminateProcess service routine includes: Obtain the address of the KeServiceDescriptorTable data structure; Obtain the address of the SSDT table from the KeServiceDescriptorTable data structure and determine the offset of the NtTerminateProcess service routine in the SSDT table; Gets the address of the NtTerminateProcess service routine at the specified offset in the SSDT table. 5. The method according to claim 4, wherein said obtaining process exit key position address according to the address of the NtTerminateProcess service routine comprises: Get the address at offset 0x13c relative to the address of the NtTerminateProcess service routine. 6. A device for detecting hidden processes in a virtual machine, wherein the device comprises: A process event intercepting unit, adapted to intercept a process exit event in a specified virtual machine, and a process creation event in the specified virtual machine; The trusted process list maintenance unit is adapted to maintain a trusted process list recording the real running process in the specified virtual machine according to the intercepted process exit and process creation events in the specified virtual machine; The untrusted process list maintenance unit is adapted to obtain one or more untrusted process lists that record the processes in the specified virtual machine by traversing the relevant data structures that record the process information in the specified virtual machine; The comparing unit is adapted to determine the hidden process in the specified virtual machine by comparing the trusted process list and the untrusted process list. 7. The apparatus of claim 6, wherein, The untrusted process list maintenance unit is adapted to obtain one or more groups in the virtual machine by traversing one or more of the _EPROCESS data structure in the kernel address space, the PspCidTable handle table or the csrss.exe handle table Process information; according to one or more sets of obtained process information, generate corresponding one or more untrusted process lists. 8. The device according to claim 6, wherein the process event interception unit comprises: The process exit event interception subunit is suitable for obtaining the address of the key position of process exit; and it is suitable for monitoring the execution event of the key position address of process exit. When the code at this address is called, it indicates that a process is about to end, and the _ of the exit process is obtained from this address. The address of the EPROCESS management structure. 9. The apparatus of claim 8, wherein, The process exit event intercepts the subunit, obtains the address of the NtTerminateProcess service routine, and obtains the process exit key position address according to the address of the NtTerminateProcess service routine; it is specifically suitable for obtaining the address of the KeServiceDescriptorTable data structure, and obtains the SSDT table from the KeServiceDescriptorTable data structure The address and the offset of the NtTerminateProcess service routine in the SSDT table are determined, and the address of the NtTerminateProcess service routine is obtained at the specified offset of the SSDT table. 10. The apparatus of claim 9, wherein, The process exit event intercepting subunit obtains an address offset by 0x13c relative to the address of the NtTerminateProcess service routine, and uses this address as the address of a key location for process exit.