CN113176926A - API dynamic monitoring method and system based on virtual machine introspection technology - Google Patents
API dynamic monitoring method and system based on virtual machine introspection technology Download PDFInfo
- Publication number
- CN113176926A CN113176926A CN202110367511.7A CN202110367511A CN113176926A CN 113176926 A CN113176926 A CN 113176926A CN 202110367511 A CN202110367511 A CN 202110367511A CN 113176926 A CN113176926 A CN 113176926A
- Authority
- CN
- China
- Prior art keywords
- monitoring
- address
- monitored
- api
- dll
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45591—Monitoring or debugging support
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
Abstract
The invention discloses an API dynamic monitoring method and system based on a virtual machine introspection technology. The method comprises the following steps: 1) reading and analyzing a set monitoring strategy configuration file, and acquiring 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 monitoring the API which is loaded to the memory and needs to be monitored; monitoring a dynamic link library which is not loaded into a system memory, confirming whether the dynamic link library is a dynamic link library needing to be monitored or not after the dynamic link library is loaded into the system, and monitoring an API function needing to be monitored in the dynamic link library if the dynamic link library is the dynamic link library needing to be monitored; 3) when the API function to be monitored is triggered, the memory of the current operating system is analyzed, 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 is extracted, and the information is written into a log.
Description
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.
Claims (9)
1. 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.
2. The method of claim 1, wherein the method for the policy loading module to read and analyze the configured monitoring policy configuration file comprises:
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.
3. The method of claim 2, wherein the monitoring setting module monitors the API to be monitored by:
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.
4. The method of claim 3, wherein the semantic conversion module parses the current operating system memory by:
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.
5. The method of claim 1, wherein the method for the dynamic link library not loaded into the system memory by the dynamic monitoring module is as follows:
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.
6. 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.
7. The system of claim 6, wherein the method for the policy loading module to read and parse the configured monitoring policy configuration file is as follows: 1) reading a monitoring strategy configuration file, and acquiring an API (application programming interface) to be monitored and a Dynamic Link Library (DLL) to which the API belongs; 2) initializing a first hash table of an API to be monitored and the address and state of the API, and initializing a second hash table of the API to be monitored and a Dynamic Link Library (DLL) to which the API belongs; 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; 4) finding a PEB structure body of the process from the EPROCESS structure body according to the monitored operating system EPROCESS member offset; 5) finding a PEB _ LDR _ DATA structural body of the process from the PEB structural body of the process according to the PEB member offset of the monitored operating system; 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; 7) inquiring the second hash table for the DLL mapped into the memory of the operating system to find an API function to be monitored, 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; 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.
8. The system of claim 7, wherein the monitoring setting module monitors the API to be monitored by: 21) acquiring a virtual address of an API function to be monitored and an EPROCESS structure address of a current process;
22) taking out a page directory table base address of the current process from the EPROCES structure address according to the monitored operating system EPROCES member offset; 23) finding a page directory table of a 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; 24) if the physical address is not found, loading the CR2 register into a virtual address, triggering a system page-changing mechanism, and changing the corresponding memory page into the memory again; 25) repeating the step 23), inquiring the physical address corresponding to the virtual address again, and finding out the physical address corresponding to the virtual address; 26) and monitoring the physical address corresponding to the virtual address, storing the machine code of the corresponding position, generating an interrupt event and returning to a monitoring setting state.
9. The system of claim 6, wherein the method for the dynamic monitoring module to monitor the dynamic link library not loaded into the system memory comprises: 31) 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; 32) searching base addresses of a process dynamic loading DLL (dynamic link library) and a process static loading DLL according to the operating system offset; 33) monitoring dynamic process loading DLL library and static process loading DLL library; 34) 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 36); 35) 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; 36) the newly loaded DLL is verified and functions that need to be monitored but are not monitored are monitored.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110367511.7A CN113176926B (en) | 2021-04-06 | 2021-04-06 | API dynamic monitoring method and system based on virtual machine introspection technology |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110367511.7A CN113176926B (en) | 2021-04-06 | 2021-04-06 | API dynamic monitoring method and system based on virtual machine introspection technology |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN113176926A true CN113176926A (en) | 2021-07-27 |
| CN113176926B CN113176926B (en) | 2023-09-05 |
Family
ID=76923068
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110367511.7A Active CN113176926B (en) | 2021-04-06 | 2021-04-06 | API dynamic monitoring method and system based on virtual machine introspection technology |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113176926B (en) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114629711A (en) * | 2022-03-21 | 2022-06-14 | 广东云智安信科技有限公司 | Method and system for detecting special Trojan horse of Windows platform |
| CN117573292A (en) * | 2024-01-15 | 2024-02-20 | 麒麟软件有限公司 | Method for Xen running general RTOS virtual machine |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2014012504A1 (en) * | 2012-07-20 | 2014-01-23 | Tencent Technology (Shenzhen) Company Limited | Method, device, and mobile terminal for api interception |
| CN105740046A (en) * | 2016-01-26 | 2016-07-06 | 华中科技大学 | Virtual machine process behavior monitoring method and system based on dynamic library |
| CN108920253A (en) * | 2018-06-20 | 2018-11-30 | 成都虫洞奇迹科技有限公司 | A kind of the virtual machine monitoring system and monitoring method of no agency |
-
2021
- 2021-04-06 CN CN202110367511.7A patent/CN113176926B/en active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2014012504A1 (en) * | 2012-07-20 | 2014-01-23 | Tencent Technology (Shenzhen) Company Limited | Method, device, and mobile terminal for api interception |
| CN105740046A (en) * | 2016-01-26 | 2016-07-06 | 华中科技大学 | Virtual machine process behavior monitoring method and system based on dynamic library |
| CN108920253A (en) * | 2018-06-20 | 2018-11-30 | 成都虫洞奇迹科技有限公司 | A kind of the virtual machine monitoring system and monitoring method of no agency |
Non-Patent Citations (1)
| Title |
|---|
| BIN SHI ET AL.: "ShadowMonitor: An Effective In-VM Monitoring Framework with Hardware-Enforced Isolation", 《SPRINGER NATURE SWITZERLAND AG 2018》, pages 670 * |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114629711A (en) * | 2022-03-21 | 2022-06-14 | 广东云智安信科技有限公司 | Method and system for detecting special Trojan horse of Windows platform |
| CN114629711B (en) * | 2022-03-21 | 2024-02-06 | 广东云智安信科技有限公司 | Method and system for detecting special Trojan horse on Windows platform |
| CN117573292A (en) * | 2024-01-15 | 2024-02-20 | 麒麟软件有限公司 | Method for Xen running general RTOS virtual machine |
| CN117573292B (en) * | 2024-01-15 | 2024-04-09 | 麒麟软件有限公司 | Method for Xen running general RTOS virtual machine |
Also Published As
| Publication number | Publication date |
|---|---|
| CN113176926B (en) | 2023-09-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8117660B2 (en) | Secure control flows by monitoring control transfers | |
| CN104598809B (en) | Program monitoring method and defending method thereof, as well as relevant device | |
| RU2679175C1 (en) | Method of behavioral detection of malicious programs using a virtual interpreter machine | |
| KR101493076B1 (en) | Apparatus and method of preventing virus code execution through buffer overflow control | |
| CA2856268C (en) | Methods of detection of software exploitation | |
| US20050108562A1 (en) | Technique for detecting executable malicious code using a combination of static and dynamic analyses | |
| KR101740604B1 (en) | Generic unpacking of applications for malware detection | |
| WO2015113052A1 (en) | Detecting and preventing execution of software exploits | |
| US11176247B2 (en) | System and method for container assessment using sandboxing | |
| US9900324B1 (en) | System to discover and analyze evasive malware | |
| JP2000172512A (en) | Method for executing byte code and data processing system | |
| EP3903183A1 (en) | Automatic mitigation of corrupted or compromised compute resources | |
| CN113176926B (en) | API dynamic monitoring method and system based on virtual machine introspection technology | |
| Dai et al. | Behavior-based malware detection on mobile phone | |
| CN109857520B (en) | Semantic reconstruction improvement method and system in virtual machine introspection | |
| US10311233B2 (en) | Generic unpacking of program binaries | |
| US8407787B1 (en) | Computer apparatus and method for non-intrusive inspection of program behavior | |
| Salehi et al. | Detecting malicious applications using system services request behavior | |
| CN111444504A (en) | Method and device for automatically identifying malicious codes during software running | |
| Ruan et al. | Analyzing android application in real-time at kernel level | |
| Moffie et al. | Hunting trojan horses | |
| US11914711B2 (en) | Systems and methods for automatically generating malware countermeasures | |
| CN110825496A (en) | VMI-based kernel data monitoring method and monitoring system | |
| Zaidenberg et al. | Hypervisor memory introspection and hypervisor based malware honeypot | |
| US12001543B2 (en) | System and method for container assessment using sandboxing |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |