CN113176926A

Movatterモバイル変換

Info

Publication number: CN113176926A
Application number: CN202110367511.7A
Authority: CN
Inventors: 丁振全; 郝志宇; 屈天恒; 程丰; 刘永继; 秦文雨
Original assignee: Institute of Information Engineering of CAS
Current assignee: Institute of Information Engineering of CAS
Priority date: 2021-04-06
Filing date: 2021-04-06
Publication date: 2021-07-27
Anticipated expiration: 2041-04-06
Also published as: CN113176926B

Abstract

Translated fromChinese

本发明公开了一种基于虚拟机自省技术的API动态监控方法及系统。本方法为：1)读取并解析设定的监控策略配置文件，获取所需监控的API以及API所属的动态链接库DLL；2)遍历已加载到系统内存的动态链接库，对已加载到内存中且需要监控的API进行监控；对未加载入系统内存的动态链接库进行监控，当其载入系统内后，确认是否是需要监控的动态链接库，如果是，则对该动态链接库内需要监控的API函数进行监控；3)当所需监控API函数被触发后，对当前操作系统内存进行解析，提取出当前进程、进程ID、当前线程、线程ID、当前进程名、所调用API、所属动态链接库信息，并写入日志。

The invention discloses an API dynamic monitoring method and system based on virtual machine introspection technology. The method is: 1) read and parse the set monitoring policy configuration file, obtain the API to be monitored and the dynamic link library DLL to which the API belongs; 2) traverse the dynamic link library loaded into the system memory, Monitor the APIs that are in memory and need to be monitored; monitor the dynamic link library that is not loaded into the system memory, when it is loaded into the system, confirm whether it is a dynamic link library that needs to be monitored, and if so, then the dynamic link library 3) After the API function to be monitored is triggered, the current operating system memory is parsed, and the current process, process ID, current thread, thread ID, current process name, and called API are extracted. , the dynamic link library information to which it belongs, and write it to the log.

Description

API dynamic monitoring method and system based on virtual machine introspection technology

Technical Field

The invention belongs to the technical field of network security, relates to a virtualization monitoring method, and particularly relates to an API dynamic monitoring method and system based on a virtual machine introspection technology.

Background

The virtualization technology is that a software layer named as a Virtual Machine Manager (VMM) is added on a computer hardware layer through hardware level virtualization in a drawing method, and the software layer is also called as hypervisor. The VMM performs necessary hardware resource virtualization for each virtual machine, and the virtual machine can install different operating systems according to the requirement and access required hardware physical resources under the monitoring and management of the VMM. Intuitively, virtualization technology multiplexes hardware resources, allowing multiple virtual machines, i.e., multiple guest operating systems, to run simultaneously. On a hardware platform provided with the VMM, the VMM realizes isolation of an operating system and hardware by coordinating the instruction sent by the operating system of the client machine, and the existing virtualization technology is divided into full virtualization and paravirtualization.

The virtual machine introspection technology (VMI) is to analyze the internal system state (software and hardware) of a virtual machine to know the internal state of the virtual machine outside the virtual machine. Because the virtual machine manager has good isolation of host-based intrusion detection system (HIDS), the virtual machine introspection can monitor the virtual machine by means of the Virtual Machine Manager (VMM). The virtual machine manager is typically a stand-alone and trusted virtual machine with very good security isolation since the virtual machine is independent of the monitored client. The virtual machine manager can read the memory pages, registers and interrupt events of the virtual machine outside the monitored virtual machine, and a user can analyze the low-level events such as the memory pages, the registers and the interrupts by using the technology to finally obtain information such as the process, the kernel module and the system call of the virtual machine.

Current virtual machine monitoring technologies are classified into virtual machine internal monitoring (In-VM) and virtual machine external monitoring (Out-of-VM). The internal monitoring of the virtual machine refers to acquiring information such as behaviors and events occurring in the virtual machine by loading a module and a plug-in the target virtual machine. The internal monitoring has the advantages that the event occurring in the target virtual machine medium or system acquires the information with the operating system semantic meaning, semantic reconstruction is not needed, and the overhead on performance is reduced. However, this approach requires running the agent in the target system, which can have an impact on system performance. In addition, the acquired information is easily deceived by the kernel-mode Rookit, and real system information cannot be acquired. With the development of information technology, the novel trojan has the capabilities of anti-sandbox detection and strong self-destruction and anti-evidence obtaining capabilities, when the trojan detects that a virus trojan detection tool runs, the attack behavior is immediately interrupted, and the attack trace is self-destroyed and erased.

The external monitoring of the Virtual Machine refers to detecting an event occurring inside the Virtual Machine by using a Virtual Machine Introspection (VMI) mechanism outside the Virtual Machine. The obtained information is the bottom layer information of the host system. The problem of how to reduce it to a semantic character sequence or data structure is called the semantic gap (semantic gap) problem. Without any prior knowledge of the host machine and the virtual machine, it is very difficult to obtain information of the virtual machine. At present, the semantic gap problem is mainly solved by methods such as manual analysis, debugger-assisted analysis, compiler-assisted analysis and binary analysis. XenAccess is a class library for monitoring memory and disk information under Xen environment; virttuoso monitors system operating state information by extracting binary generated VMI code. Based on Libvmi, Watson et al also proposed a virtual machine process information detection scheme based on VMM assistance. For monitoring the API, the external monitoring technology of the virtual machine must load the corresponding API in the memory when the program runs, or monitor the reading, writing and mapping of the file, which results in abnormal system performance loss.

Disclosure of Invention

The invention aims to provide an API dynamic monitoring method and system based on a virtual machine introspection technology. According to the API dynamic monitoring method and device, on the basis of the virtual machine monitoring technology, the bottom layer information such as the memory and the register acquired by the virtual machine monitoring technology is analyzed, the memory introspection technology is utilized to monitor the process of loading the API of the system, and when the API is just loaded by the system, the relevant API of the system is dynamically monitored, so that the API dynamic monitoring technology based on the virtual machine introspection technology is realized on the basis of reducing the performance loss of an operating system. Compared with the disclosed method, the method has the following advantages:

(1) out-of-band monitoring, in-band undetectable

The invention relates to a virtual machine external monitoring system based on a virtual machine introspection technology. The virtual machine monitoring system is installed on a host machine and used for monitoring a virtual machine (a monitored host machine). Both sides have very good isolation. Therefore, the monitored host cannot find the fact that the monitored host is monitored, and the anti-detection and anti-debugging capabilities of the Trojan horse cannot play a role.

(2) User layer host interception analysis

Most of the current external monitoring systems of virtual machines adopt the memory mapping behavior of monitoring files, which results in a large number of false triggering events. The invention analyzes the process after the user layer loads all dynamic link libraries by analyzing the process starting process, analyzes all loaded dynamic libraries at one time, and also avoids a large amount of error touch operation caused by the memory mapping behavior of the monitoring file.

(3) Dynamic monitoring DLL and internal functions

The invention can dynamically monitor DLL (Dynamic Link Library), and monitor the API which is mapped to the memory in the current operating system according to the configuration file, and for the API which is not mapped into the memory, the invention can continuously monitor the memory and monitor the memory at the first time when the API is mapped into the memory.

(4) Efficient interception mechanism

The invention can define the information of API name, number, DLL and the like to be intercepted, not only can intercept the system DLL, but also can intercept the API in user and third party DLL.

The behavior monitoring system of the virtual machine disclosed by the invention is shown in fig. 1 and comprises a policy loading module, a monitoring setting module, a dynamic monitoring module and a semantic conversion module. The policy loading module is responsible for reading user monitoring policies (information of processes to be monitored, function types and functions to be monitored, modules to be monitored and the like), analyzing the policies, converting the policies into user policy structure bodies which can be identified by programs and are believed to contain the functions to be monitored, the modules to which the functions belong and the processes to be monitored), and judging the states of the policies. The monitoring setting module is responsible for setting the monitoring module, traverses the user policy structure, and performs virtual address search, virtual address and physical address conversion and trap setting on the API to be monitored. The dynamic monitoring module is responsible for monitoring the DLL which is mapped to the internal memory of the operating system, and after confirming that functions in the DLL need to be monitored, the monitoring setting module is called to monitor the functions which need to be monitored in the DLL. The semantic conversion module is used for processing the extraction and analysis of system information when the monitored function is executed, and finally converting the machine language of the bottom layer into high-level semantic information which can be identified by a user.

The specific operation mode of the system is as follows:

1: the system reads the user monitoring strategy configuration file, the strategy loading module analyzes the configuration file, and the API required to be analyzed by the user and the DLL (dynamic link library) to which the API belongs are analyzed from the configuration file. And then, traversing the dynamic link library loaded into the memory, and calling a monitoring setting module to monitor the API which is loaded into the memory and needs to be monitored.

2: for the dynamic link library which is not loaded into the memory of the operating system, the system monitors two functions of LdrpInitializeProcessand LdrpLoadDll, so as to obtain the dynamic link library loaded into the memory in real time. After the dynamic link library loaded into the memory is obtained, the dynamic monitoring module will submit it to the policy loading module to determine whether it is a module to be monitored (the dynamic link library is called a module after being loaded into the memory). If yes, calling a monitoring setting module to monitor the API needing to be monitored in the dynamic link library, and ensuring that all functions needing to be monitored can be monitored.

3: when the monitored function is triggered, the semantic conversion module analyzes the current operating system memory, overcomes the semantic gap, extracts the information of the current process, the process ID, the current thread, the thread ID, the current process name, the called API, the affiliated dynamic link library, the calling parameter and the like, and writes the information into the log.

The virtual machine introspection technology refers to a function of monitoring the operation of a running virtual machine, and includes various monitoring such as monitoring a CPU \ a memory, and the like. The functions mentioned in the present invention are all realized by the virtual machine introspection technology.

The technical scheme of the invention is as follows:

an API dynamic monitoring method based on virtual machine introspection technology comprises the following steps:

1) the method comprises the following steps that a strategy loading module reads and analyzes a set monitoring strategy configuration file to obtain an API required to be monitored and a Dynamic Link Library (DLL) to which the API belongs;

2) traversing the dynamic link library loaded to the system memory, and calling a monitoring setting module to monitor the API which is loaded to the system memory and needs to be monitored; monitoring a dynamic link library which is not loaded into a system memory, and after the dynamic link library is loaded into the system, a dynamic monitoring module submits the dynamic link library to a strategy loading module for judgment to determine whether the dynamic link library is the dynamic link library needing monitoring, and if the dynamic link library is the dynamic link library needing monitoring, a monitoring setting module is called to monitor the API function needing monitoring in the dynamic link library;

3) when the API function to be monitored is triggered, the semantic conversion module analyzes the memory of the current operating system, extracts the information of the current process, the process ID, the current thread, the thread ID, the current process name, the called API and the affiliated dynamic link library and writes the information into a log.

Further, the method for the policy loading module to read and analyze the set monitoring policy configuration file includes:

1-1) reading a monitoring strategy configuration file, and acquiring an API (application programming interface) required to be monitored and a Dynamic Link Library (DLL) to which the API belongs;

1-2) initializing a first hash table of an API to be monitored and the address and state thereof, and initializing a second hash table of the API to be monitored and a dynamic link library DLL to which the API belongs;

1-3) acquiring a head node address of an operating system process chain according to a program database file PDB corresponding to a current operating system kernel file ntoskrnl.exe, wherein each node of the process chain corresponds to an EPROCES structure, each EPROCES structure corresponds to one process in an operating system, and the EPROCES structure internally comprises a process ID, a process page directory table base address, a process name and disk file storage position information of the process;

1-4) searching a PEB structure body of a process corresponding to an EPROCESS structure body in the EPROCESS structure body according to the monitored operating system EPROCESS member offset;

1-5) finding a PEB _ LDR _ DATA structure of the process from the PEB structure of the process according to the PEB member offset of the monitored operating system;

1-6) traversing the PEB _ LDR _ DATA bidirectional linked list, and taking out the virtual base address of each DLL which is mapped to the current process;

1-7) inquiring the second hash table for searching an API function required to be monitored for the DLL mapped into the memory of the operating system, and then acquiring the offset of the API function relative to the DLL base address according to a program database file (PDB); adding the offset to the virtual base address of the DLL to which the API function belongs to obtain the virtual address of the API function to be monitored, and monitoring the API function;

1-8) if the monitoring is successful, updating the state and the address of the API function; if not successful, the original state is kept unchanged.

Further, the method for monitoring the API to be monitored by the monitoring setting module includes:

2-1) acquiring a virtual address of the API function to be monitored and an EPROCESS structure address of the current process;

2-2) taking out the page directory table base address of the current process from the EPROCESS structure address according to the monitored operating system EPROCESS member offset;

2-3) finding a page directory table of the process according to a page directory table base address of the process, sequentially querying a multi-level page table according to the virtual address, and searching a physical address corresponding to the virtual address;

2-4) if the physical address is not found, loading a CR2 register into a virtual address, triggering a system page-changing mechanism, and changing the corresponding memory page into the memory again;

2-5) repeating the step 2-3), inquiring the physical address corresponding to the virtual address again, and finding out the physical address corresponding to the virtual address;

2-6) monitoring the physical address corresponding to the virtual address, storing the machine code at the corresponding position, generating an interrupt event and returning to the monitoring setting state.

Further, the method for analyzing the memory of the current operating system by the semantic conversion module comprises the following steps:

3-1) taking out an interrupt event and suspending the monitored operating system;

3-2) searching a first hash table according to the physical address of the trigger event stored in the interrupt event, and determining a corresponding API;

3-3) obtaining the calling parameter of the API and reducing the calling parameter to obtain the original parameter and storing the original parameter in a buffer area;

3-4) analyzing the PDB file of the monitored operating system kernel module, acquiring a KPCR structure address of the operating system, finding a corresponding KPRCB structure, and finding a KTHREAD structure of the current running thread from the KPRCB structure according to the KPRCB structure offset; then, reading the process and thread related information triggering the interrupt event from the KTHREAD structural body and the EPROCESS structural body;

3-5) writing the information obtained in the step 3-3) and the step 3-4) into a database, and recovering the running of the virtual machine.

Further, the method for monitoring the dynamic link library which is not loaded into the system memory by the dynamic monitoring module comprises the following steps:

21) selecting a non-system kernel process from the process chain of the operating system, and searching the virtual base address of each DLL mapped into the currently selected process;

22) searching base addresses of a process dynamic loading DLL (dynamic link library) and a process static loading DLL according to the operating system offset;

23) monitoring dynamic process loading DLL library and static process loading DLL library;

24) for the callback triggered by the process static loading DLL library, reading the address of the ESP/RSP register of the current process, setting monitoring for the address, and then canceling the monitoring for the process static loading DLL library; turning to step 26);

25) for the call-back triggered by the dynamic loading DLL (delay locked loop) library of the process, reading the address of an ESP/RSP (ESP/RSP) register of the process, and monitoring the address; then acquiring a virtual address of the DLL loaded to the memory from the eax/rax register; then, traversing a process DLL chain to obtain the address of the newly loaded DLL;

26) the newly loaded DLL is verified and functions that need to be monitored but are not monitored are monitored.

An API dynamic monitoring system based on a virtual machine introspection technology is characterized by comprising a strategy loading module, a monitoring setting module, a dynamic monitoring module and a semantic conversion module; wherein

The policy loading module is used for reading and analyzing the set monitoring policy configuration file and acquiring an API required to be monitored and a Dynamic Link Library (DLL) to which the API belongs;

the monitoring setting module is used for monitoring the API which is loaded into the memory and needs to be monitored;

the dynamic monitoring module is used for monitoring a dynamic link library which is not loaded into a system memory, and after the dynamic link library is loaded into the system, the dynamic link library is delivered to the strategy loading module for judgment to determine whether the dynamic link library is a dynamic link library needing to be monitored, and if the dynamic link library is the dynamic link library needing to be monitored, the monitoring setting module is called to monitor the API function needing to be monitored in the dynamic link library;

and the semantic conversion module is used for analyzing the memory of the current operating system after the API function to be monitored is triggered, extracting the current process, the process ID, the current thread, the thread ID, the current process name, the called API and the information of the affiliated dynamic link library and writing the information into a log.

Compared with the prior art, the invention has the following advantages:

the invention discloses an API dynamic monitoring system based on a virtual machine introspection technology, which reads the monitoring requirement of a user on host behavior, monitors the dynamic link library which is not loaded into a memory through the process of loading the dynamic link library by a monitoring system and a program running flow besides monitoring the API loaded into the memory, and monitors related functions at the moment of loading the dynamic link library into the memory. Compared with the disclosed method, the method has the following advantages: 1) the isolation is excellent, and the monitoring party and the monitored party have very good isolation. The virtualization technology has the characteristic of excellent isolation, the monitored host cannot discover the monitored fact of the monitored host, and the anti-detection and anti-debugging capabilities of the Trojan horse cannot play a role. 2) The user layer host machine intercepts and analyzes, and reduces the false touch rate under all conditions of interception and capture. The technology analyzes the process after the user layer loads all dynamic link libraries by analyzing the process starting process, analyzes all loaded dynamic libraries at one time, and also avoids a large amount of error touch operation caused by the memory mapping behavior of the monitoring file. 3) And dynamic monitoring, which can monitor functions which are not loaded into the system. The present invention continuously monitors the memory and monitors the API as soon as it is mapped into the memory. 4) The interception is efficient and free, the information such as the name, the number and the affiliated DLL of the API to be intercepted can be customized, the system DLL can be intercepted, and the API in a user and a third party DLL can also be intercepted.

Drawings

FIG. 1 is a framework diagram of an API dynamic monitoring system based on the virtual machine introspection technology;

FIG. 2 is a GAP addressing flow diagram;

FIG. 3 is a flow chart of a policy update method;

FIG. 4 is a flowchart of a ring event buffer store;

FIG. 5 is a flow chart of a behavior analysis method.

Detailed Description

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

The invention discloses an API dynamic monitoring system based on a virtual machine introspection technology, which mainly comprises a strategy loading module, a monitoring setting module, a dynamic monitoring module and a semantic conversion module.

Fig. 2 shows a workflow diagram of the policy loading module, which includes the following specific steps:

(1) and reading and analyzing the user strategy to obtain the API which the user wants to monitor and the dynamic link library to which the user belongs.

(2) And initializing the hash table of the API to be monitored, the address and the state and the hash table of the DLL and the API to be monitored, so that query is facilitated.

(3) According to pdb (program database file) corresponding to the kernel file ntoskrnl.exe of the current operating system, a head node address of an operating system process chain is obtained from an export variable PsInitialSystemProcess, and each node of the process chain is an EPROCESS structure. Each EPROCESS structure body corresponds to a process of an operating system, and the structure body internally comprises process related information such as process ID, process page directory table base address, process name, disk file storage position and the like of the process. And traversing the EPROCESS chain, and analyzing (4) - (8) for each EPROCESS structural body.

(4) And finding the PEB structure body of the process corresponding to the EPROCESS structure body from each EPROCESS structure body according to the monitored operating system EPROCESS member offset. Each EPROCESS structure corresponds to one process.

(5) And finding the PEB _ LDR _ DATA structure of the process according to the member offset of the PEB structure of the monitored operating system from the PEB structure of the process. The PEB _ LDR _ DATA structure is a node of a PEB _ LDR _ DATA bi-directional linked list, and each node of the bi-directional linked list stores DLL information mapped to the process space, including information such as DLL names, module names and DLL base addresses. Each PEB corresponds to one process, and the address of one process is stored in the whole chain table of the PEB _ LDR _ DATA.

(6) And traversing the PEB _ LDR _ DATA doubly linked list, and taking out the virtual base address of each DLL which is mapped in the process.

(7) And inquiring the DLL mapped into the memory and the API hash table to find the function needing monitoring inside. The offset of the function relative to the DLL base address is then obtained from an analysis of the DLL's corresponding PDB or function derivation table. And adding the offset to the virtual base address of the DLL to which the function belongs to obtain the virtual address of the API to be monitored. And transmitting the EPROCESS base address of the process and the virtual address of the API needing to be monitored to monitor the function.

(8) And if the monitoring is successful, updating the state and the address of the API. If not successful, the original state is kept unchanged.

Fig. 3 shows a work flow diagram of the monitoring setting module, which includes the following steps:

(1) and acquiring the incoming virtual address of the API to be monitored and the EPROCESS structure address.

(2) And taking out the address of directoryttablebase, namely the page directory table base address of the process from the EPROCESS structure address according to the monitored operating system EPROCESS member offset.

(3) And finding the page directory table of the process according to the page directory table base address of the process, sequentially querying the multi-level page tables according to the virtual address, and searching the physical address corresponding to the virtual address.

(4) If the physical address is not found, the process indicates that the memory page of the physical address at the moment is not in the memory. At this time, the CR2 register is loaded with the virtual address, and the system page-swap mechanism is triggered to swap the memory page where the physical address is located back into the memory. Only one address, and the address that last triggered the page fault interrupt, can be stored in the CR2 register (i.e., the page fault linear address register). The operating system triggers a page-change mechanism based on the address therein.

(5) Repeating the operation in the step (3), and inquiring the physical address corresponding to the virtual address again to find the physical address.

(6) Setting monitoring, reading physical address, saving machine code of corresponding position, and writing int3 instruction. The int3 instruction is one of the operating system interrupt instructions, and when the operating system executes the int3 instruction, it triggers an interrupt No. 3 to generate an interrupt event.

(7) And returning the monitoring setting state to the calling module.

Fig. 4 shows a work flow diagram of the dynamic monitoring module, which includes the following steps:

(1) selecting a process except the process No. 4 (the process ID of the system process is 4, and the process is a system kernel process) from the process chain, repeating the steps of the strategy loading modules (4) - (6), and searching the base address of the NTDLL module according to the DLL name (the NTDLL module is a module after the NTDLL dynamic library of the system is mapped into the system, and the module provides interaction between a layer 0 and a layer 3 of the system and is loaded into a memory when the system is normally used).

(2) The base addresses of the LdrpLoadDll function and ldrppinitializprocess function are found from the ntdll module based on the operating system offset (which can be obtained from the pdb or function derivation table).

(3) And calling a monitoring setting module to set monitoring for LdrpLoadDll (process dynamic loading DLL library) and LdrpIntializazeProcess (process static loading DLL library).

(4) For the callback triggered by the LdrpInterlizeProcess function, the address of the ESP/RSP register of the current process is read, monitoring is set for the address, and then the monitoring for the LdrpInterlizeProcess is cancelled. When the new setting monitoring is triggered again, the steps of the strategy loading modules (4) to (6) are repeated from the current process EPROCESS to find out the DLL chain. Then go to step 6.

(5) For the callback triggered by the LdrpLoadDll function, the address of the ESP/RSP register of the process is read, and the monitoring is set for the address. When a callback is triggered, the last pointer of the current DLL linked list is passed. And acquiring the virtual address of the dynamic link library loaded into the memory from the eax/rax register. The process DLL chain is traversed to obtain the address of the newly loaded DLL (preventing LdrpLoadDll nested calls).

(6) The newly loaded DLL is verified and functions that need to be monitored but are not monitored are monitored.

Fig. 5 shows a work flow diagram of the semantic conversion module, which includes the following specific steps:

(1) an interrupt event (referring to an interrupt event triggered by the operating system executing int 3) is fetched while the monitored virtual machine is suspended.

(2) Storing a physical address of a trigger event and a CPU ID number of the trigger event in the interrupt event, and obtaining which API is called according to the matching of the physical address and a hash table;

(3) according to the field values of a register RIP, an RCX and the like, taking out the current API call parameter, calling a libvmi library to complete the reduction of the original parameter, and opening up a buffer area to store the original parameter;

(4) by analyzing the PDB file of the monitored operating system kernel module, the KPCR structure address of the operating system can be obtained. And finding a KPRCB structural body from the KPCR structural body according to the KPCR structural body offset, finding a KTHREAD structural body of the current running thread from the KPRCB structural body according to the KPRCB structural body offset, wherein the KTHREAD stores information such as the ID of the current thread, the EPROCESS base address of the process to which the current thread belongs, the stack address and the like. And reading the process and thread related information of the current process from the KTHREAD structural body and the EPROCESS structural body. The current process is the process of triggering the event and is also the process of calling the monitored API;

(5) and writing the parameters acquired by the parameter information, the API triggering callback, the process ID, the thread ID and the like into the database. And resumes virtual machine operation.

The foregoing is merely a preferred embodiment of the present invention, and it should be understood that various changes and modifications may be made by those skilled in the art without departing from the spirit and scope of the invention. The present invention should not be limited to the disclosure of the embodiments and drawings in the specification, and the scope of the present invention is defined by the scope of the claims.