Method and system for detecting linux malicious code based on virtual machine introspection

Abstract

The application discloses a Linux malicious code detection method and system based on virtual machine introspection, which comprises a virtual machine management layer subsystem, a monitoring virtual machine subsystem and a malicious code execution virtual machine subsystem; the kernel function behavior of a malicious code process is intercepted and analyzed through an inline hook and a memory hiding technology, and the sensitive read-write behavior of the malicious code to a key kernel memory is intercepted and analyzed through an extended page table hook technology, so that the specific flow and sensitive memory operation information of the malicious code execution are acquired. The application realizes the monitoring of the malicious code execution flow by the virtual machine management layer outside the operating system under the condition that the malicious code is not perceived and normally operated, does not need a separate monitoring process to be run inside the operating system, makes it difficult for the malicious code to be detected and to resist the monitoring system, effectively reduces the attack on the monitoring system, improves the monitoring transparency, and can accurately detect complex Linux kernel Rootkit and other malicious codes.

Description

Technical Field

[0001] This invention relates to the field of computer security technology, and in particular to a method and system for detecting Linux malicious code based on virtual machine introspection. Background Technology

[0002] In recent years, the types and numbers of malware have increased dramatically. Complex malware attacks, exemplified by APTs (Advanced Persistent Threats), pose a serious challenge to network security and traditional detection and defense solutions. Currently, the most common approach to detecting malware on Linux systems is sandboxing technology. This involves constructing an isolated threat detection environment, then isolating and analyzing malicious samples within the sandbox to ultimately determine whether malicious behavior has been exposed.

[0003] However, in current traditional detection methods, the security software responsible for monitoring is usually at the same privilege level as the malware, generally operating at the kernel level. Detection is achieved through methods such as hooking Linux system calls or utilizing special mechanisms provided by the Linux system, like probes. But this approach inherently has certain flaws. Firstly, because security software and malicious code are at the same level, the security software inevitably exposes a large attack surface, making it an easy target for malicious code. Malicious code can directly confront the security software; once it finds a vulnerability, it can exploit it to disable the security software or even gain root privileges to engage in further illegal activities. Secondly, traditional detection methods struggle to check whether Linux kernel modules are malicious, such as kernel rootkits. And the security threats we face today are becoming increasingly complex; highly complex malware like rootkits poses a particularly serious challenge to traditional malware detection methods. Summary of the Invention

[0004] To overcome the shortcomings of the prior art, this invention provides a Linux malware detection system based on virtual machine introspection. This system can monitor the execution process of malware at the virtual machine management layer outside the operating system without the malware being aware of it and while it is running normally. It does not require a separate monitoring process to run inside the operating system, making it difficult for malware to detect and counter the monitoring system. This effectively reduces the attack surface of the monitoring system, improves the transparency of monitoring, and can accurately detect complex malware such as Linux kernel rootkits.

[0005] The technical solution provided by this invention is:

[0006] A Linux malware detection method based on virtual machine introspection intercepts and analyzes the behavior of kernel functions called by malicious code processes using inline hooks (a technique that modifies function execution flow at runtime) combined with memory hiding techniques. It also intercepts and analyzes sensitive read / write operations on critical kernel memory by malicious code at the virtual machine management layer using extended page table hooks, thereby accurately and transparently obtaining the specific execution flow and sensitive memory operation information of the malicious code. The method mainly includes: a detection rule determination stage, a transparent malware injection stage, a malicious code function call interception stage, a malicious code memory read / write interception stage, and a behavior analysis and judgment stage. Each stage in this invention is transparent and imperceptible to the malicious code, improving the accuracy, security, and transparency of the detection system.

[0007] in:

[0008] The following steps are performed during the determination of detection rules:

[0009] Step 1: Analyze and summarize the malicious behavior information that the malicious code may expose, including but not limited to the malicious code's calls to Linux system kernel functions and its read and write behavior on sensitive memory (malicious code behavior);

[0010] Step 2: Based on the malicious code behavior information to be detected, formalize it into specific detection rules. The detection rules include, but are not limited to: executing the kernel function corresponding to the sensitive system call, reading sensitive kernel memory, and modifying sensitive kernel memory.

[0011] The following steps are performed during the transparent injection phase of malicious code:

[0012] Step 3: At the outer layer of the malicious code execution virtual machine (the underlying layer of the operating system), write the program bytes of the malicious code into the Linux system kernel running the execution virtual machine, and simulate the Linux thread creation process to start the malicious code process, thereby injecting the malicious code into the execution virtual machine transparently and without the user's awareness.

[0013] The following steps are performed during the malicious code function call interception phase:

[0014] Step 4: Insert an interception point at the corresponding kernel function location using inline hooking technology, and at the same time, use memory hiding technology to hide the memory data modified by the inline hook, and record it without the process noticing when the interception point is triggered.

[0015] The following steps are performed to intercept malicious code during the memory read / write phase:

[0016] Step 5: Use EPT (Extended Page Table) hook technology to set memory read interception or memory write interception in the corresponding memory page, and record it without the process's awareness when reading and writing sensitive memory;

[0017] The behavior analysis and judgment phase involves the following steps:

[0018] Step 6: During the execution of the malicious code process, identify and filter the function call behavior and memory read / write behavior related to the malicious code and its child processes, record and intercept them, and allow processes that are not within the scope of monitoring to run.

[0019] Step 7: Based on the function call behavior intercepted in Step 6, parse the function call parameters, structure, return value, and other information. Based on the memory read / write behavior intercepted in Step 6, parse the memory segment attributes, memory read / write content, and other information.

[0020] Step 8: Compare the information parsed in Step 7 with the formalized detection rules in Step 2 to determine whether the malicious code behavior matches known malicious behavior.

[0021] Step 9: Output the judgment result.

[0022] The aforementioned Linux malware detection method based on virtual machine introspection can achieve transparent and unobtrusive monitoring of malware process function call behavior and sensitive memory operation behavior, and efficiently capture malware process function call behavior and sensitive memory operation behavior.

[0023] Malicious code can traverse the current system process list to find suspicious processes, thereby detecting whether it is running in the monitored environment. The method of this invention can transparently inject and run malicious code processes without any proxy processes, making it impossible for malicious code to detect the monitored environment through the system's running status.

[0024] Malicious code can read critical Linux system functions and detect whether it is running in a monitored environment by checking whether the system function instructions have been modified. This invention uses memory hiding technology to conceal the modified instruction memory, preventing malicious code from reading the correct memory information and thus preventing it from detecting the monitored environment based on memory characteristics.

[0025] Highly complex malware, such as kernel rootkits, can self-hide and evade monitoring environments by modifying critical Linux kernel code and data structures. This invention addresses this by using EPT (Extended Page Table Transmission) to intercept malicious code at the page table level, directly targeting physical memory. This prevents the malware from concealing its malicious operations, achieving both accuracy and intuitiveness in malware detection.

[0026] Using the above-mentioned Linux malware detection method based on virtual machine introspection, this invention implements a corresponding Linux malware detection system based on virtual machine introspection, including a virtual machine management layer subsystem, a virtual machine monitoring subsystem, and a malware execution virtual machine subsystem.

[0027] The virtual machine management layer subsystem is located below the monitoring virtual machine subsystem and the malicious code execution virtual machine subsystem. It can manage and control the monitoring virtual machine and the malicious code execution virtual machine. It includes the monitoring virtual machine interaction module and the malicious code execution virtual machine interaction module. The malicious code execution virtual machine interaction module can obtain data from the upper-layer malicious code execution virtual machine system. The monitoring virtual machine interaction module can forward various events generated in the malicious code execution virtual machine to the monitoring virtual machine system, so that the upper-layer monitoring virtual machine can obtain various behavioral data of the malicious code execution virtual machine, thereby performing specific monitoring and detection.

[0028] The monitoring virtual machine subsystem sits above the virtual machine management layer subsystem, at the same level as the malicious code execution virtual machine subsystem. It is responsible for monitoring and detecting malicious code running within the malicious code execution virtual machine subsystem. This includes modules for transparent malicious code injection, malicious code process tracing, transparent function execution monitoring, transparent memory read / write monitoring, behavior parsing, and behavior determination. The monitoring virtual machine subsystem can achieve comprehensive monitoring and detection of malicious code running within the malicious code execution virtual machine through the virtual machine management layer subsystem.

[0029] The malicious code execution virtual machine subsystem resides above the virtual machine management layer subsystem, at the same level as the monitoring virtual machine subsystem, and is responsible for executing malicious code processes. This subsystem contains no modules, ensuring its own transparency. Because the malicious code execution virtual machine subsystem and the monitoring virtual machine subsystem belong to different virtual machine systems, they possess inherent isolation. This unique architecture hides the existence of the monitoring subsystem, preventing malicious code from being aware that it is being monitored, and enabling more accurate and comprehensive acquisition of behavioral information regarding the normal execution process of malicious code.

[0030] Compared with the prior art, the beneficial effects of the present invention are:

[0031] This invention provides a Linux malware detection scheme and system based on virtual machine introspection. By setting interception points on the upper-layer Linux system kernel functions and memory read / write operations outside the virtual machine where the malware executes, the behavior of the malware is acquired and analyzed. Since the monitoring virtual machine and the malware execution virtual machine reside on different machines, this architecture effectively reduces the attack surface exposed to malware by the monitoring system. This prevents malware from being aware of its own virtual execution environment, thus hindering its camouflage and countermeasures, and improving the security, transparency, and stealth of the detection system. Furthermore, this invention directly intercepts the physical memory corresponding to the virtual memory of the upper-layer Linux system, making it impossible for malware to hide its malicious modifications. It can effectively detect highly complex malware samples, such as kernel rootkits, improving the detection capability and accuracy of the system. Attached Figure Description

[0032] To more clearly illustrate the technical solutions of the present invention, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0033] Figure 1 This is a structural block diagram of a Linux malware detection system based on virtual machine introspection, provided in an embodiment of the present invention.

[0034] Figure 2 This is a flowchart of the Linux malware detection method based on virtual machine introspection according to the present invention. Detailed Implementation

[0035] To make the objectives, technical solutions, and advantages of the present invention clearer, the present invention will be further described below with reference to the accompanying drawings and embodiments, but this does not limit the scope of the present invention in any way.

[0036] Reference Figure 1 , Figure 1 This is a structural block diagram of a Linux malware detection system based on virtual machine introspection provided in an embodiment of the present invention. The Linux malware detection system based on virtual machine introspection includes the following subsystems:

[0037] Subsystem 1: Virtual Machine Management System;

[0038] Subsystem 2: Monitoring the virtual machine system;

[0039] Subsystem 3: Malicious code execution virtual machine system.

[0040] Subsystem 1 is located below subsystems 2 and 3, and can manage and control subsystems 2 and 3. It includes the following modules:

[0041] Module 1, Monitoring Virtual Machine Interaction Module, is responsible for forwarding various events generated in the virtual machine where malicious code is executed by Subsystem 3 to Subsystem 2, which monitors the virtual machine system. This allows Subsystem 2, located at the upper layer, to obtain various behavioral data of Subsystem 3 for specific monitoring and detection.

[0042] Module 2, the Malicious Code Execution Virtual Machine Interaction Module, is responsible for controlling the startup, shutdown, and snapshot restoration of the malicious code execution virtual machine system in Subsystem 3, and for obtaining data from the upper-layer malicious code execution virtual machine system;

[0043] Modules 2 and 3 together form the control module of subsystem 1.

[0044] Subsystem 2 is located above Subsystem 1 and at the same level as Subsystem 3. It is responsible for monitoring and detecting malicious code running in Subsystem 3, and includes the following modules:

[0045] Module 3, the transparent injection module for malicious code, injects malicious code into the Linux operating system in Subsystem 3 transparently and without the user's awareness. The Linux system in Subsystem 3 does not need to run any agent programs.

[0046] Module 4, the Malicious Code Process Tracking Module, includes child processes and child threads created by malicious code through methods such as exec and fork in the tracking scope, ensuring comprehensive information acquisition;

[0047] Module 5, the Function Execution Transparency Monitoring Module, intercepts Linux system kernel functions in Subsystem 3 through inline hooking and memory hiding techniques, and obtains the execution status of intercepted functions in Subsystem 3 in real time;

[0048] Module Six, the Transparent Memory Read / Write Monitoring Module, uses EPT (Extended Page Table) technology to intercept sensitive memory read / write behaviors of the Linux system in Subsystem Three and obtains the memory read / write status of processes in Subsystem Three in real time.

[0049] Module 7, the Behavior Analysis Module, parses the function execution information obtained from the Function Execution Transparent Monitoring Module in Module 5, and extracts prototype information such as function call parameters and structures. It also parses the information obtained from the Memory Read / Write Transparent Monitoring Module in Module 6, and extracts information such as memory read / write addresses and memory attributes.

[0050] Module 8, Behavior Determination Module, determines whether the process behavior is legal based on the detection rules of the information parsed from Module 7.

[0051] Subsystem 3 is located above Subsystem 1 and at the same level as Subsystem 2. It is responsible for executing malicious code processes. Subsystem 3 does not contain any modules and is an independent virtual machine system from Subsystem 2, thus they are isolated from each other.

[0052] Reference Figure 2 , Figure 2 This is a flowchart of the Linux malware detection method based on virtual machine introspection according to the present invention. The specific implementation includes five stages:

[0053] Phase 1: Determining the testing rules;

[0054] Phase Two: Transparent Malicious Code Injection Phase;

[0055] Phase Three: Intercepting Malicious Code Function Calls;

[0056] Phase Four: Intercepting Malicious Code Memory Read / Write;

[0057] Phase Five: Behavioral Analysis and Judgment Phase;

[0058] Phase One includes the following steps:

[0059] Step 1: Analyze and summarize the malicious behavior information that the malicious code may expose;

[0060] Furthermore, the malicious information in question includes, but is not limited to:

[0061] The process executed sensitive kernel functions, including suspicious kernel functions such as sys_connect, do_sys_open, and do_sys_write.

[0062] Modifying kernel code behavior involves the process using inline hooks to modify critical kernel function instruction bytes in the executable segment of the Linux kernel to transfer control flow.

[0063] Modifying kernel data behavior, the process intercepts system calls by modifying the sys_call_table system call table in the Linux kernel data segment;

[0064] Modifying the behavior of critical registers allows the process to intercept system calls by changing the address of the system call routine through the MSR register, by changing the address of the segment descriptor pointed to by the IDTR and GDTR registers, and by changing the page table translation process through the CR register to hide its own behavior.

[0065] Step 2: Formulate the malicious code behavior information to be detected into specific detection rules;

[0066] Furthermore, the detection rules include, but are not limited to:

[0067] When malicious code executes network connection-related kernel functions such as sys_connect, and the function parameter is a suspicious address, rules are triggered to detect suspicious network behavior of the malicious code.

[0068] When malicious code executes file-related kernel functions such as do_sys_write, and the function parameter is a sensitive file, rules are triggered to detect suspicious file read and write behavior of the malicious code.

[0069] Malicious code modifies a segment of the Linux kernel code, and the modified segment corresponds to the address of a critical kernel function, triggering rules to detect the behavior of rootkits and other malicious kernel code hijacking kernel functions;

[0070] Malicious code modifies the Linux kernel data segment, and the tampered data segment corresponds to the address of the system call table, triggering rules to detect the behavior of rootkits and other kernel malicious code hijacking Linux system calls;

[0071] Malicious code modifies the MSR register, triggering rules to detect the hijacking of system calls by kernel-based malicious code such as rootkits;

[0072] Malicious code modifies the CR register, triggering rules to detect the behavior of rootkits and other kernel-based malicious code that tamper with the page table translation process to hide itself.

[0073] Phase Two includes the following steps:

[0074] Step 3: Inject malicious code transparently and without the user's awareness into the execution virtual machine;

[0075] Specifically, the detailed implementation scheme for transparent injection is as follows:

[0076] The monitoring virtual machine locates the address of the Linux kernel system call processing routine that malicious code executes, writes an INT3 instruction (the INT3 instruction is a special instruction used to support debugging, corresponding to machine code 0xCC) at this address, and enables the INT3 instruction event callback in the monitoring virtual machine.

[0077] Furthermore, the monitoring virtual machine allocates a kernel space within the Linux system inside the malicious code execution virtual machine and writes the program bytes injected by the agent program into the allocated space;

[0078] Furthermore, when malicious code executes arbitrary system calls within the Linux system inside the virtual machine, it will execute the INT3 instruction. At this point, the INT3 instruction event is captured by the hypervisor, generating a virtual machine exit event, and the control flow is transferred to the monitored virtual machine.

[0079] Furthermore, the agent program is monitored to execute the injected virtual machine. The agent program writes the malicious code bytes to be injected into the Linux system kernel space inside the malicious code execution virtual machine. It then calls the kernel functions call_usermodehelper_setup and call_usermodehelper_exec in sequence to create a user thread from the operating system kernel mode, which is the kernel thread corresponding to the malicious code process.

[0080] The third stage includes the following steps:

[0081] Step 4: An interception point is embedded at the corresponding kernel function location using inline hooking technology. At the same time, memory hiding technology is used to hide the memory data modified by the inline hook, and the data is recorded without the process noticing when the interception point is triggered.

[0082] Specifically, the detailed implementation plan is as follows:

[0083] Based on the kernel function names in step 2, locate the Linux system kernel symbol table in the malicious code execution virtual machine to determine the kernel function addresses;

[0084] Furthermore, the kernel function instruction information is parsed, and at appropriate instruction locations, the kernel function instructions are modified into jump instructions. The jump target is a pre-set trampoline instruction sequence, which contains vmcall instructions. When malicious code executes the Linux system in the virtual machine and reaches the interception point, the vmcall instruction is triggered, generating a virtual machine exit event. This allows control flow to transfer through the virtual machine management layer to the monitoring virtual machine. If any instructions involve memory addressing during this process, relocation operations are required.

[0085] Furthermore, the monitoring virtual machine records the address of the modified instruction, and sets up EPT extended page table read interception at this address. When a process in the virtual machine reads the memory information at this address, the original memory data before modification is returned, thus achieving memory hiding and making the malicious code unaware that it is in a modified monitoring system.

[0086] The fourth stage includes the following steps:

[0087] Step 5: Use EPT (Extended Page Table) technology to set up memory read interception or memory write interception on the corresponding memory page in the malicious code execution virtual machine, and record it without the process's awareness when reading or writing sensitive memory.

[0088] Specifically, the detailed implementation plan is as follows:

[0089] Based on the sensitive memory regions in step 2, such as the Linux kernel code segment, the starting and ending virtual addresses of the kernel code segment are first located according to the Linux kernel load address and kernel symbol table in the malicious code execution virtual machine, and the physical address corresponding to the virtual address is obtained through page table translation.

[0090] Furthermore, obtain the EPT Entry corresponding to the physical address page. If the current EPT Entry supports subpage permissions, the subsequent operations will be performed at a more granular level to the subpage.

[0091] Furthermore, if memory read interception is enabled, the read flag of the EPT page table is set to invalid; if memory write interception is enabled, the write flag of the EPT page table is set to invalid. Thus, when malicious code executes the virtual machine to access memory, the invalid page flag triggers EPT Violation, generating a virtual machine exit event, and control flow is transferred through the virtual machine management layer to the monitoring virtual machine.

[0092] Furthermore, monitor the virtual machine's handling of EPT Violation events, parse and record memory access information in the virtual machine when malicious code executes.

[0093] The fifth stage includes the following steps:

[0094] Step 6: During the execution of the malicious code process, identify and filter the function call behavior and memory read / write behavior related to the malicious code and its child processes, and record and intercept them.

[0095] Furthermore, the specific implementation scheme is as follows: First, obtain the PID of the malicious code's starting process and put it into the monitoring chain. If the malicious code performs actions such as executing exec or fork to create and copy child processes, then parse the child process data structure to obtain information such as the process PID, and add the child process to the monitoring chain. Finally, record the execution information of all monitored processes.

[0096] Step 7: Based on the function call behavior intercepted in Step 6, parse the function call parameters, structure, return value, and other information. Based on the memory read / write behavior intercepted in Step 6, parse the memory segment attributes, memory read / write content, and other information.

[0097] Furthermore, the data that needs to be parsed includes, but is not limited to:

[0098] The name of the function being called;

[0099] The process name of the called function;

[0100] The command line of the called function process;

[0101] The called function should include its parameters and return value.

[0102] Addresses of sensitive memory that may be read or modified;

[0103] The symbol corresponding to the address of a sensitive memory read or modification;

[0104] Information about processes that read or modify sensitive memory;

[0105] The function call stack that reads or modifies sensitive memory;

[0106] Step 8: Compare the information parsed in Step 7 with the formalized detection rules in Step 2 to determine whether the malicious code behavior matches known malicious behavior.

[0107] Step 9: Output the judgment result.

[0108] Through the above five stages of operation, Linux malware detection based on virtual machine introspection is achieved.

[0109] It should be noted that the purpose of disclosing the embodiments is to help further understand the present invention. However, those skilled in the art will understand that various substitutions and modifications are possible without departing from the scope of the present invention and the appended claims. Therefore, the present invention should not be limited to the content disclosed in the embodiments, and the scope of protection of the present invention is defined by the scope of the claims.

Claims

1. A Linux malware detection method based on virtual machine introspection, characterized in that, By intercepting and analyzing the kernel function calls of malicious code processes through inline hooking and memory hiding techniques, and by intercepting and analyzing the sensitive read and write behavior of malicious code on critical kernel memory through extended page table hooking techniques at the virtual machine management level, the specific execution process and sensitive memory operation information of malicious code can be obtained accurately and transparently. This mainly includes: the stage of determining detection rules, the stage of transparent malicious code injection, the stage of intercepting malicious code function calls, the stage of intercepting malicious code memory read and write operations, and the stage of behavior analysis and judgment; among which: The following steps are performed during the determination of detection rules: Step 1: Obtain information on malicious behavior exposed by malicious code, including malicious code calls to Linux system kernel functions and read / write operations on sensitive memory; Step 2: Formalize the malicious code behavior to be detected into specific detection rules. The detection rules include: executing the kernel function corresponding to the sensitive system call, reading sensitive kernel memory, and modifying sensitive kernel memory. The following steps are performed during the transparent injection phase of malicious code: Step 3 involves writing the malicious code's bytes into the Linux system kernel running on the outer layer of the malicious code execution virtual machine, i.e., the underlying operating system. This is done by simulating the Linux thread creation process to launch the malicious code process, thus transparently and imperceptibly injecting malicious code into the execution virtual machine. This includes: 31) Locate the address of the Linux kernel system call processing routine that malicious code executes by monitoring the virtual machine, write the INT3 instruction at the processing routine address, and enable the INT3 event callback in the monitored virtual machine; 32) By monitoring the virtual machine, a kernel space is allocated in the Linux system inside the malicious code execution virtual machine, and the program bytes of the injected agent program are written into the allocated space; 33) When malicious code executes arbitrary system calls on the Linux system inside the virtual machine and reaches the INT3 instruction, the hypervisor captures the INT3 event, generates a virtual machine exit event, and transfers control flow to the monitored virtual machine. 34) By monitoring the virtual machine, the malicious code bytes to be injected are written into the Linux system kernel space inside the malicious code execution virtual machine, and the operating system kernel function is called to create a user thread from the system kernel mode, that is, the kernel thread corresponding to the malicious code process; The following steps are performed during the malicious code function call interception phase: Step 4: An interception point is embedded at the corresponding kernel function location using inline hooking technology. Simultaneously, memory data modified by the inline hook is hidden using memory hiding technology, and recorded imperceptibly when the process triggers the interception point; including: 41) Locate the Linux system kernel symbol table in the malicious code execution virtual machine based on the kernel function name to determine the kernel function address; 42) Parse kernel function instruction information, modify the kernel function instruction at the instruction location to a jump instruction, and the jump target is a pre-set trampoline instruction sequence; when the malicious code executes the Linux system in the virtual machine and reaches the interception point, it triggers the vmcall instruction in the trampoline instruction sequence, generates a virtual machine exit event, and thus the control flow is transferred to the monitoring virtual machine through the virtual machine management layer; during this process, if any instruction involves memory addressing, a relocation operation is performed; 43) By monitoring the virtual machine to record the address of the modified instruction, an extended page table read interception is set at that address. When a process in the virtual machine reads the memory information at this address, the original memory data before modification is returned, thereby achieving memory hiding and making the malicious code unable to realize that it is in a modified monitoring system. The following steps are performed to intercept malicious code during the memory read / write phase: Step 5: Use extended page table hooking technology to set memory read interception or memory write interception at the corresponding memory page, so that the process reads and writes sensitive memory without being aware of it; including: 51) Based on the sensitive memory region, first locate the start and end virtual addresses of the kernel code segment according to the Linux kernel loading address and kernel symbol table in the malicious code execution virtual machine, and obtain the physical address corresponding to the virtual address through page table translation; 52) Obtain the EPT Entry corresponding to the physical address page; when the current EPT Entry supports subpage permissions, subsequent operations will be performed at a more granular level of subpage permissions; 53) When memory read interception is set, the read flag of the EPT page table is set to invalid; when memory write interception is set, the write flag of the EPT page table is set to invalid. Thus, when malicious code executes the virtual machine to access memory, the page flag is invalid, triggering EPT Violation, generating a virtual machine exit event, and the control flow is transferred to the monitoring virtual machine through the virtual machine management layer. 54) By monitoring the virtual machine's handling of EPT Violation events, analyze and record memory access information in the virtual machine used by malicious code execution; The behavior analysis and judgment phase involves the following steps: Step 6: During the execution of the malicious code process, identify and filter the function call behavior and memory read / write behavior related to the malicious code and its child processes, record and intercept them, and allow processes that are not within the scope of monitoring to run. Step 7: Based on the function call behavior intercepted in Step 6, parse the function call information; based on the memory read / write behavior intercepted in Step 6, parse the memory segment attributes and memory read / write content information. Step 8: Compare the information parsed in Step 7 with the formalized detection rules in Step 2 to determine whether the malicious code behavior matches known malicious behavior. Step 9: Output the judgment result; The above steps enable Linux malware detection based on virtual machine introspection.

2. The Linux malware detection method based on virtual machine introspection as described in claim 1, characterized in that, In step 34), the kernel function call is specifically the sequential call of the kernel functions call_usermodehelper_setup and call_usermodehelper_exec.

3. The Linux malware detection method based on virtual machine introspection as described in claim 1, characterized in that, In step 1, the malicious information includes: actions such as executing sensitive kernel functions, modifying kernel code, modifying kernel data, and modifying critical registers; among which: Executing sensitive kernel functions refers to the process executing suspicious kernel functions such as sys_connect, do_sys_open, and do_sys_write. Modifying kernel code behavior refers to the behavior of a process that modifies critical kernel function instruction bytes in the executable segment of the Linux kernel through inline hooking to transfer control flow. Modifying kernel data behavior refers to the process's behavior of intercepting system calls by modifying the sys_call_table system call table in the Linux kernel data segment; Modifying critical register behavior refers to the process intercepting system calls by modifying the MSR register to change the address of the system call routine, the process intercepting system calls by modifying the IDTR and GDTR registers to change the address of the segment descriptor, and the process hiding itself by modifying the CR register to change the page table translation process.

4. The Linux malware detection method based on virtual machine introspection as described in claim 1, characterized in that, In step 2, the detection rules include: When malicious code executes kernel functions related to establishing network connections, and the function parameters are suspicious addresses, rules are triggered to detect suspicious network behavior of the malicious code. When malicious code executes kernel functions related to files, and the function parameter is a sensitive file, rules are triggered to detect suspicious file read / write behavior of the malicious code. Malicious code modifies Linux kernel code segments, and the addresses of critical kernel functions corresponding to the modified code segments are tampered with, triggering rules to detect the behavior of rootkit kernel malicious code hijacking kernel functions; Malicious code modifies the Linux kernel data segment and alters the address of the system call table corresponding to the data segment, triggering rules to detect the behavior of rootkit kernel malicious code hijacking Linux system calls; Malicious code modifies the MSR register, triggering rules to detect the behavior of rootkit kernel malicious code hijacking system calls; Malicious code modifies the CR register, triggering rules to detect the rootkit kernel malicious code's behavior of tampering with the page table translation process to hide itself.

5. The Linux malware detection method based on virtual machine introspection as described in claim 1, characterized in that, The specific implementation method of step 6 includes: First, obtain the PID of the malicious code's starting process and add it to the monitoring list; When malicious code performs actions such as creating and copying child processes, the child process data structure is parsed to obtain process information, and the child process is also added to the monitoring list; Then record the execution information of all monitored processes.

6. The Linux malware detection method based on virtual machine introspection as described in claim 1, characterized in that, In step 7, the data to be parsed includes: the name of the called function; the name of the process of the called function; the command line of the process of the called function; the parameters and return value of the called function; the address of the sensitive memory read or modified; the symbol corresponding to the address of the sensitive memory read or modified; the process information of the sensitive memory read or modified; and the function call stack of the sensitive memory read or modified.

7. A system implemented using the Linux malware detection method based on virtual machine introspection as described in claim 1, characterized in that, This includes a virtual machine management layer subsystem, a virtual machine monitoring subsystem, and a malicious code execution virtual machine subsystem; among which: The virtual machine management layer subsystem is located below the monitoring virtual machine subsystem and the malicious code execution virtual machine subsystem. It is used to manage and control the monitoring virtual machine and the malicious code execution virtual machine. It includes a monitoring virtual machine interaction module and a malicious code execution virtual machine interaction module. The malicious code execution virtual machine interaction module is used to obtain data from the upper-layer malicious code execution virtual machine system. The monitoring virtual machine interaction module is used to forward various events generated in the malicious code execution virtual machine to the monitoring virtual machine system, so that the upper-layer monitoring virtual machine can obtain various behavioral data of the malicious code execution virtual machine, thereby performing specific monitoring and detection. The monitoring virtual machine subsystem is located above the virtual machine management layer subsystem and at the same level as the malicious code execution virtual machine subsystem. It is used to monitor and detect malicious code running in the malicious code execution virtual machine subsystem. It includes a transparent malicious code injection module, a malicious code process tracing module, a transparent function execution monitoring module, a transparent memory read / write monitoring module, a behavior parsing module, and a behavior judgment module. The monitoring virtual machine subsystem achieves comprehensive monitoring and detection of malicious code running in the malicious code execution virtual machine through the virtual machine management layer subsystem. The malicious code execution virtual machine subsystem is located above the virtual machine management layer subsystem and at the same level as the monitoring virtual machine subsystem. It is used to execute malicious code processes. This subsystem does not contain any modules. The malicious code execution virtual machine subsystem and the monitoring virtual machine subsystem are independent of each other and belong to different virtual machine systems. The existence of the monitoring virtual machine subsystem is hidden, so that the malicious code cannot realize that it is being monitored. This allows the malicious code to obtain behavioral information about the normal execution process of the malicious code.

Images