A malicious code detection method, device, computer, and readable storage medium

Abstract

The present application relates to a malicious code detection method, apparatus, computer, and readable storage medium. The malicious code detection method includes: monitoring, by a monitoring process, an action of returning from the kernel mode to the user mode, and obtaining a system call instruction that causes a monitored process to enter the kernel mode for execution; determining whether a module where the system call instruction executed by the monitored process is located is a trusted Windows library; if not, determining that the system call is an abnormal system call; and recording the abnormal system call to form an abnormal system call sequence; comparing and analyzing the abnormal system call sequence with a malicious program system call sequence to determine whether the monitored program is malicious code. By monitoring the action of returning from the kernel mode to the user mode in the monitoring process, corresponding system call information is obtained, and the system call executed by an untrusted Windows library is recorded as the abnormal system call sequence; the abnormal system call sequence is compared with the malicious system call sequence to determine the behavioral characteristics of the program.

Description

Technical Field

[0001] This application relates to the field of computer information security, and particularly to a malicious code detection method, device, computer, and readable storage medium. Background Art

[0002] Currently, mainstream terminal security software obtains the API call sequence during program execution by hijacking and hooking various levels of APIs (including Win32 API and Native API, etc.) in the program user mode; puts the obtained API call sequence information into a malicious code detection model for analysis; and the malicious code detection model discovers malicious code behavior based on the API sequence and related parameters, combined with threat intelligence.

[0003] Existing methods or technologies for malicious code detection obtain the API call sequence during program execution by hooking the program user-mode API, and then achieve malicious code detection through the analysis of the API call sequence. However, during some APT attacks, malware can effectively avoid the monitoring of user-mode API calls by terminal security software by using direct system calls, making it impossible for terminal security software to obtain the program's API call sequence, and thus unable to determine the behavior characteristics of the program. Summary of the Invention

[0004] Embodiments of this application provide a malicious code detection method, device, computer, and readable storage medium to at least solve the problem in the prior art that terminal security software cannot accurately obtain the API call sequence of a program, and thus cannot determine the behavior characteristics of the program.

[0005] In a first aspect, embodiments of this application provide a malicious code detection method, including:

[0006] Monitoring the actions returning from the kernel mode to the user mode through a monitoring process, and obtaining the system call instructions that cause the monitored process to execute in the kernel mode;

[0007] Judging whether the module where the system call instruction executed by the monitored process is located is a trusted Windows library; if not, judging that the system call instruction is generated by an abnormal system call; and recording the abnormal system call to form an abnormal system call sequence;

[0008] Comparatively analyzing the abnormal system call sequence and the malicious program system call sequence, and if the abnormal system call sequence conforms to the malicious program system call sequence, judging that the monitored program is malicious code.

[0009] In some of these embodiments, the steps of monitoring, through a monitoring process, the action of returning from kernel mode to user mode, and obtaining the system call instruction that causes the monitored process to enter kernel mode for execution include:

[0010] Implement monitoring of the monitored process returning from kernel mode to user mode by setting a callback function;

[0011] When it is found that the monitored process returns from kernel mode to user mode, determine whether the operation of the monitored process entering kernel mode from user mode is generated by a system call. If so, record the system call information.

[0012] In some of these embodiments, the steps of determining whether the operation of the monitored process entering kernel mode from user mode is generated by a system call include:

[0013] Disassemble and analyze the call instructions near the return address;

[0014] Based on the result of the disassembly analysis, determine whether the operation of the monitored process entering kernel mode from user mode is generated by a system call.

[0015] In some of these embodiments, the steps of determining whether the module where the system call instruction executed by the monitored process is located is a trusted Windows library; if not, determine that the system call is an abnormal system call; and record the abnormal system call to form an abnormal system call sequence include:

[0016] Obtain the module where the system call instruction is located according to the position of the system call instruction executed in the monitored process;

[0017] Determine whether the module is a trusted Windows library;

[0018] If not, determine that the system call instruction is generated by a user program executing a system call, and record the system call in the abnormal system call sequence.

[0019] In some of these embodiments, the steps of determining whether the module is a trusted Windows library include:

[0020] Calculate the digital signature of the module;

[0021] Determine whether the module is a trusted Windows library according to the digital signature.

[0022] In some of these embodiments, the steps of comparing and analyzing the abnormal system call sequence and the malicious program system call sequence, and if the abnormal system call sequence matches the malicious program system call sequence, determining that the monitored program is malicious code include:

[0023] Construct a malicious program system call sequence based on the obtained threat intelligence;

[0024] Compare and analyze the abnormal system call sequence of the program to be monitored and the malicious program system call sequence. If the abnormal system call sequence matches the malicious program system call sequence, determine that the program to be monitored is malicious code.

[0025] In a second aspect, an embodiment of the present application provides a malicious code detection device, which is characterized by including:

[0026] A monitoring module, which is used to monitor the actions returning from the kernel mode to the user mode through the monitored process, and obtain the system call instructions that cause the monitored process to enter the kernel mode for execution;

[0027] A processing module, which is used to determine whether the module where the system call instruction executed by the monitored process is located is a trusted Windows library; if not, determine that the system call instruction is generated by an abnormal system call; and record the abnormal system call to form an abnormal system call sequence;

[0028] A judgment module, which is used to compare and analyze the abnormal system call sequence and the malicious program system call sequence. If the abnormal system call sequence matches the malicious program system call sequence, determine that the program to be monitored is malicious code.

[0029] In some embodiments, the monitoring module includes:

[0030] A monitoring unit: The monitoring unit is used to implement the monitoring of the monitored process returning from the kernel mode to the user mode by setting a callback function;

[0031] A recording unit: The recording unit is used to determine whether the operation of the monitored process entering the kernel mode from the user mode is generated by a system call when it is found that the monitored process returns from the kernel mode to the user mode. If so, record the system call information.

[0032] In some embodiments, the recording unit is further used for:

[0033] Disassemble and analyze the call instructions near the return address;

[0034] According to the result of the disassembly analysis, determine whether the operation of the monitored process entering the kernel mode from the user mode is generated by a system call.

[0035] In some embodiments, the processing module includes:

[0036] An acquisition unit, where the acquisition unit is configured to acquire the module where the system call instruction is located according to the position of the system call instruction executed in the process to be monitored;

[0037] A processing unit, where the processing unit is configured to determine whether the module is a trusted Windows library;

[0038] If not, it is determined that the system call instruction is generated by a user program executing a system call, and the system call is recorded in the abnormal system call sequence.

[0039] In some embodiments, the processing unit is further configured to:

[0040] Calculate the digital signature of the module;

[0041] Determine whether the module is a trusted Windows library according to the digital signature.

[0042] In some embodiments, the determination module includes:

[0043] A construction unit, where the construction unit is configured to construct a malicious program system call sequence according to the obtained threat intelligence;

[0044] A determination unit, where the determination unit is configured to compare and analyze the abnormal system call sequence of the program to be monitored and the malicious program system call sequence. If the abnormal system call sequence matches the malicious program system call sequence, it is determined that the program to be monitored is malicious code.

[0045] In a third aspect, an embodiment of the present application provides a computer, including a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the computer program, it implements a malicious code detection method as described in the first aspect.

[0046] In a fourth aspect, an embodiment of the present application provides a readable storage medium, on which a computer program is stored. When the program is executed by a processor, it implements a malicious code detection method as described in the first aspect.

[0047] Compared with the related art, a malicious code detection method provided by an embodiment of the present application monitors the actions of the kernel state returning to the user state in a process, obtains corresponding system call instruction information, analyzes the source of system calls in the monitored program, and searches for system calls executed by untrusted Windows libraries; obtains all system calls executed by untrusted Windows libraries in the monitored program to form an abnormal system call sequence; puts the obtained abnormal system call sequence into a malicious code analysis model for judgment, that is, compares the abnormal system call sequence with the malicious system call sequence to generate a malicious code detection and analysis result, so as to judge the behavior characteristics of the program and monitor potential malicious code.

[0048] Details of one or more embodiments of the present application are set forth in the following drawings and description, so that other features, objects, and advantages of the present application will become more concise and understandable. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments and descriptions of the present application are used to explain the present application and do not constitute an improper limitation of the present application. In the drawings:

[0050] Figure 1 is a flowchart of the malicious code detection method in the first embodiment of the present application;

[0051] Figure 2 is a flowchart of the malicious code detection method in the second embodiment of the present application;

[0052] Figure 3 is a structural block diagram of the malicious code detection device in the third embodiment of the present application;

[0053] Figure 4 is a schematic diagram of the hardware structure of a computer in the fourth embodiment of the present application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0054] In order to make the purpose, technical solution, and advantages of the present application clearer, the present application will be described and explained below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application. Based on the embodiments provided by the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts fall within the scope of protection of the present application.

[0055] Obviously, the accompanying drawings in the following description are only some examples or embodiments of the present application. For those of ordinary skill in the art, without creative efforts, the present application can also be applied to other similar scenarios based on these drawings. In addition, it can also be understood that although the efforts made in such a development process may be complex and lengthy, for those of ordinary skill in the art related to the content disclosed in the present application, some design, manufacturing, or production changes based on the technical content disclosed in the present application are only conventional technical means and should not be understood as insufficient disclosure of the present application.

[0056] Reference to "embodiment" in the present application means that a particular feature, structure, or characteristic described in connection with the embodiment can be included in at least one embodiment of the present application. The phrase appears in various places in the specification and does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment mutually exclusive with other embodiments. It is explicitly and implicitly understood by those of ordinary skill in the art that the embodiments described in the present application can be combined with other embodiments without conflict.

[0057] Unless otherwise defined, the technical terms or scientific terms involved in the present application should have the ordinary meaning understood by those of ordinary skill in the art in the technical field to which the present application belongs. The words "a", "an", "one", "the", and similar words involved in the present application do not indicate a limitation in quantity and can represent singular or plural. The terms "including", "comprising", "having", and any variations thereof involved in the present application are intended to cover non-exclusive inclusion; for example, a process, method, product, or device that includes a series of steps or modules (units) is not limited to the listed steps or units, but may also include unlisted steps or units, or may further include other steps or units inherent to these processes, methods, products, or devices. The words "connected", "coupled", and similar words involved in the present application are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect. The term "plurality" involved in the present application refers to two or more. "And / or" describes the association relationship of associated objects and indicates that three relationships can exist. For example, "A and / or B" can represent: A exists alone, A and B exist simultaneously, and B exists alone. The character " / " generally represents an "or" relationship between the preceding and following associated objects. The terms "first", "second", "third", etc. involved in the present application are only used to distinguish similar objects and do not represent a specific order for the objects.

[0058] Currently, mainstream terminal security software obtains the API call sequence during the program execution process by hijacking and hooking various levels of APIs in the user mode of the program (including Win32 API, Native API, etc.); puts the obtained API call sequence information into the malicious code detection model for analysis; and the malicious code detection model discovers malicious code behaviors based on the API sequence and related parameters, combined with threat intelligence.

[0059] Existing methods or technologies for malicious code detection obtain the API call sequence during the program execution process by hooking the user-mode APIs of the program, and then achieve malicious code detection through the analysis of the API call sequence. However, during some APT attacks, malware can effectively avoid the monitoring of user-mode API calls by the terminal security software by using direct system calls, making it impossible for the terminal security software to obtain the API call sequence of the program, and thus unable to judge the behavioral characteristics of the program.

[0060] Moreover, since Windows Vista x64, the Windows system kernel has adopted the Patchguard technology for protection, making it impossible for the terminal security software to hook system kernel tables such as SSDT / IDT / GDT in the kernel to monitor the APIs called by the program; the terminal security software can only hijack the Native APIs of the program process to achieve user-layer hooking to judge the behavioral characteristics of the program and monitor potential malicious code, while malware developers can effectively avoid the monitoring of user-mode API calls by the terminal security software by using direct system calls, and can avoid the malicious code being detected and killed because of calling some sensitive API sequences.

[0061] In addition, for easy understanding, the above APT is: A kind of advanced persistent threat attack activity that is continuously effective carried out by an organization against a specific target. This attack activity has extremely strong concealment and pertinence, and usually uses various means such as infected media, supply chain, and social engineering to implement advanced, persistent, and effective threats and attacks.

[0062] In summary, the first embodiment of the present invention provides a malicious detection method. Figure 1 It is a flowchart of a malicious code detection method according to an embodiment of the present application, as Figure 1 shown, and this process includes the following steps:

[0063] Step S101, monitor the action of returning from the kernel mode to the user mode through a monitoring process, and obtain the system call instruction or information that causes the monitored process to enter the kernel mode for execution. For easy understanding, the Windows system call is as follows: in the Windows system, by calling a specific interface (system call) and using instructions such as sysenter, syscall, or int 2eh, it is possible to enter the kernel mode from the user mode. In this step, monitor the system call that returns from the kernel mode to the user mode in the monitoring process, so as to obtain the system call instruction or information that causes the monitored process to enter the kernel mode for execution.

[0064] Step S102, determine whether the module where the system call instruction or information executed by the monitored process is a trusted Windows library; if not, determine that the system call instruction or information is generated by an abnormal system call; and record the abnormal system call to form an abnormal system call sequence. Specifically, in this step, the above-mentioned "trusted Windows library" includes Windows libraries digitally signed by Microsoft, and the above-mentioned "abnormal system call" includes that the module where the system call is located is a Windows library not digitally signed by Microsoft, and the above-mentioned "system call sequence" is a set of system calls arranged in the execution order.

[0065] Step S103, compare and analyze the abnormal system call sequence with the malicious program system call sequence. If the abnormal system call sequence conforms to the malicious program system call sequence, determine that the monitored program is malicious code. In this step, the above-mentioned malicious program system call sequence is a pre-set system call sequence that can be confirmed to conform to malicious behavior characteristics, that is, a malicious code analysis model is formed according to the above-mentioned malicious system call sequence, and the abnormal system call sequence is put into the malicious code analysis model for judgment. If the above-mentioned abnormal program sequence conforms to the malicious program system call sequence, it can be determined that the above-mentioned monitored program is malicious code.

[0066] In the above steps S101 to S103, by monitoring the action of returning from the kernel mode to the user mode in the monitoring process, obtain the corresponding system call instruction or information, analyze the source of the system call in the monitored program, and find the system call executed by the untrusted Windows library; obtain all the system calls executed by the untrusted Windows library in the monitored program to form an abnormal system call sequence; put the obtained abnormal system call sequence into the malicious code analysis model for judgment, that is, compare the abnormal system call sequence with the malicious system call sequence to generate a malicious code detection and analysis result, so as to judge the behavior characteristics of the program and monitor potential malicious code.

[0067] The second embodiment of this application also provides a malicious code detection method. Figure 2It is a flowchart of another malicious code detection method according to an embodiment of the present application. As Figure 2 shown, this process includes the following steps:

[0068] Step S201: Implement the monitoring of the monitored process returning from the kernel mode to the user mode by setting a callback function. In this step, specifically, by setting a callback function, monitor the actions of the process returning from the kernel mode to the user mode, and thereby obtain the system call instructions or information that cause the monitored process to enter the kernel mode for execution.

[0069] Step S202: When it is found that the monitored process returns from the kernel mode to the user mode, disassemble and analyze the call instructions near the return address;

[0070] According to the result of the disassembly analysis, determine whether the operation of the monitored process entering the kernel mode from the user mode is generated by a system call. If so, record the system call information. In some application scenarios of this embodiment, when it is found that the monitored process returns from the kernel mode to the user mode, by disassembling and analyzing the system call instructions near the return address, determine whether the process operation is generated by a system call. If it is generated by a system call, record its system call number. If not, ignore this operation and do not execute the subsequent steps.

[0071] Step S203: Obtain the module where the system call instruction is located according to the position of the system call instruction executed in the monitored process. Specifically, in this step, the above module includes the software that executes the above system call.

[0072] Step S204: Calculate the digital signature of the module;

[0073] Judge whether the module is a trusted Windows library according to the digital signature. Specifically, in this step, the above "trusted Windows library" includes the Windows libraries digitally signed by Microsoft. If this module is a "trusted Windows library", it is determined that this module has no malicious behavior, ignore this operation, and do not execute the subsequent steps.

[0074] Step S205: If not, determine that the system call instruction is generated by a user program executing a system call, and record the system call into the abnormal system call sequence. Specifically, in this step, if the above module is an "untrusted Windows library", it means that this module may have malicious behavior, and record this system call into the abnormal call sequence.

[0075] Step S206: Construct a malicious program system call sequence based on the obtained threat intelligence. In this step, the above threat intelligence includes target features that have been determined to have malicious behavior, and a corresponding malicious program system call sequence is constructed through the above target features.

[0076] Step S207: Compare and analyze the abnormal system call sequence of the monitored program with the malicious program system call sequence. If the abnormal system call sequence conforms to the malicious program system call sequence, it is determined that the monitored program is malicious code. Specifically, in this step, by comparing and analyzing the system calls from the "untrusted Windows library" with the malicious program system call sequence, if it conforms to the above target features, it can be determined that the monitored program is malicious code.

[0077] In the above steps S201 to S207, the monitoring of the actions from user mode to kernel mode is achieved by setting a callback function, and by disassembling and analyzing the system call instructions, the source module of the system calls in the monitored program is obtained, that is, the system calls executed by the untrusted Windows library are found; and all the system calls executed by the untrusted Windows library in the monitored program are obtained to form an abnormal system call sequence; the obtained abnormal system call sequence is put into the malicious code analysis model for judgment, that is, the abnormal system call sequence is compared with the malicious system call sequence to generate a malicious code detection and analysis result to judge the behavior characteristics of the program and monitor potential malicious code.

[0078] The third embodiment of the present application also provides a malicious code detection device, which is used to implement the above embodiment and preferred implementation manners, and those that have been described will not be repeated. As used hereinafter, terms such as "module", "unit", "sub-unit", etc. can be a combination of software and / or hardware that can achieve a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, implementation in hardware, or a combination of software and hardware is also possible and contemplated.

[0079] Figure 3 is a structural block diagram of a malicious code detection device according to an embodiment of the present application. As Figure 3 shown, the device includes: a monitoring module 10, a processing module 20, and a judgment module 30; wherein,

[0080] The monitoring module 10 is used to monitor the actions returning from kernel mode to user mode through a monitoring process, and obtain the system call instructions or information that cause the monitored process to enter kernel mode for execution;

[0081] The processing module 20 is used to determine whether the module where the system call instruction or information executed by the monitored process is located is a trusted Windows library; if not, it determines that the system call is an abnormal system call; and records the abnormal system call to form an abnormal system call sequence.

[0082] The judgment module 30 is used to compare and analyze the abnormal system call sequence with the malicious program system call sequence. If the abnormal system call sequence matches the malicious program system call sequence, it determines that the monitored program is malicious code.

[0083] Specifically, the monitoring module 10 includes:

[0084] Monitoring unit: The monitoring unit is used to monitor the return of the monitored process from the kernel mode to the user mode by setting a callback function.

[0085] Recording unit: The recording unit is used to determine whether the operation of the monitored process entering the kernel mode from the user mode is generated by a system call when it is found that the monitored process returns from the kernel mode to the user mode. If so, it records the system call information.

[0086] Specifically, the recording unit is further used for:

[0087] Disassembling and analyzing the call instructions near the return address.

[0088] According to the result of the disassembly analysis, determine whether the operation of the monitored process entering the kernel mode from the user mode is generated by a system call.

[0089] Specifically, in this embodiment, the processing module 20 includes:

[0090] Acquisition unit, the acquisition unit is used to obtain the module where the system call instruction is located according to the position of the system call instruction executed in the monitored process.

[0091] Processing unit, the processing unit is used to determine whether the module is a trusted Windows library.

[0092] If not, it determines that the system call instruction or information is generated by the user program executing a system call, and records the system call in the abnormal system call sequence.

[0093] In this embodiment, the processing unit is further used for:

[0094] Calculating the digital signature of the module.

[0095] According to the digital signature, determine whether the module is a trusted Windows library.

[0096] The judgment module 30 includes:

[0097] a construction unit configured to construct a malicious program system call sequence according to the obtained threat intelligence;

[0098] a judgment unit configured to compare and analyze the abnormal system call sequence of the monitored program with the malicious program system call sequence, and if the abnormal system call sequence conforms to the malicious program system call sequence, determine that the monitored program is malicious code.

[0099] In summary, the malicious detection device in this embodiment monitors the actions of entering the kernel state from the user state by setting a callback function in the monitoring module 10, and disassembles and analyzes the system call instructions or information through the processing module 20 to obtain the source of the system calls in the monitored program, that is, to find the system calls executed by untrusted Windows libraries; and obtains all the system calls executed by untrusted Windows libraries in the monitored program to form an abnormal system call sequence; the obtained abnormal system call sequence is put into a malicious code analysis model by the judgment module 30 for judgment, that is, the abnormal system call sequence is compared with the malicious system call sequence to generate a malicious code detection and analysis result, so as to judge the behavior characteristics of the program and monitor potential malicious code.

[0100] It should be noted that each of the above modules can be a functional module or a program module, and can be implemented either by software or by hardware. For the modules implemented by hardware, each of the modules can be located in the same processor; or each of the modules can also be located in different processors in any combined form.

[0101] A fourth embodiment of the present application provides a computer. It can be understood that the principles mentioned in the malicious code detection device in this embodiment correspond to the malicious code detection method in the second embodiment of the present application. For the relevant principles not described, please refer to the second embodiment for corresponding reference, and details will not be repeated here.

[0102] The computer may include a processor 81 and a memory 82 storing computer program instructions.

[0103] Specifically, the above-mentioned processor 81 may include a central processing unit (CPU), or an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of the present application.

[0104] Among them, the memory 82 may include a mass storage for data or commands. By way of example and not limitation, the memory 82 may include a hard disk drive (HDD), a floppy disk drive, a solid state drive (SSD), a flash memory, an optical disc, a magneto-optical disc, a magnetic tape, or a universal serial bus (USB) drive, or a combination of two or more of these. Where appropriate, the memory 82 may include removable or non-removable (or fixed) media. Where appropriate, the memory 82 may be internal or external to the data processing device. In a particular embodiment, the memory 82 is a non-volatile memory. In a particular embodiment, the memory 82 includes a read-only memory (ROM) and a random access memory (RAM). Where appropriate, the ROM may be a mask-programmed ROM, a programmable ROM (PROM), an erasable PROM (EPROM), an electrically erasable PROM (EEPROM), an electrically alterable ROM (EAROM), or a flash memory, or a combination of two or more of these. Where appropriate, the RAM may be a static random access memory (SRAM) or a dynamic random access memory (DRAM), where the DRAM may be a fast page mode dynamic random access memory (FPMDRAM), an extended date out dynamic random access memory (EDODRAM), a synchronous dynamic random access memory (SDRAM), etc.

[0105] The memory 82 can be used to store or cache various data files required for processing and / or communication, as well as possible computer program commands executed by the processor 81.

[0106] The processor 81 reads and executes the computer program commands stored in the memory 82 to implement any one of the malicious code detection methods in the above embodiments.

[0107] In some of the embodiments, the computer may further include a communication interface 83 and a bus 80. Among them, as Figure 4 shown, the processor 81, the memory 82, and the communication interface 83 are connected through the bus 80 and complete communication with each other.

[0108] The communication interface 83 is used to implement communication between the various modules, devices, units, and / or devices in the embodiments of the present application. The communication interface 83 can also implement data communication with other components such as external devices, image / data acquisition devices, databases, external storage, and image / data processing workstations, etc.

[0109] Bus 80 includes hardware, software, or both, and couples components of a computer to each other. Bus 80 includes, but is not limited to, at least one of the following: Data Bus, Address Bus, Control Bus, Expansion Bus, Local Bus. By way of example and not limitation, Bus 80 may include an Accelerated Graphics Port (AGP) or other graphics bus, an Extended Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), a Hyper Transport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an InfiniBand interconnect, a Low Pin Count (LPC) bus, a memory bus, a Micro Channel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local Bus (VLB) bus, or other suitable bus or a combination of two or more of these. Where appropriate, Bus 80 may include one or more buses. Although embodiments of the present application describe and illustrate specific buses, the present application contemplates any suitable bus or interconnect.

[0110] In addition, in combination with the malicious detection method in the above embodiments, a fifth embodiment of the present application provides a readable storage medium. A computer program command is stored on the readable storage medium; when the computer program command is executed by a processor, any one of the malicious detection methods in the above embodiments is implemented.

[0111] The technical features of the above-described embodiments can be combined arbitrarily. For the sake of brevity of description, not all possible combinations of the technical features in the embodiments are described. However, as long as there is no contradiction in the combination of these technical features, it should be considered to be within the scope described in this specification.

[0112] The embodiments described above merely represent several implementation manners of the present application. The description is relatively specific and detailed, but it should not be construed as a limitation on the scope of the invention patent. It should be noted that for those of ordinary skill in the art, without departing from the concept of the present application, several modifications and improvements can still be made, and these all fall within the protection scope of the present application. Therefore, the protection scope of the patent of the present application shall be subject to the appended claims.

Claims

1. A malicious code detection method, characterized in that Including: Monitoring, by a monitoring process, system call actions returning from kernel mode to user mode, and obtaining system call instructions that cause the monitored process to enter kernel mode for execution; the user mode enters the kernel mode through specific system calls using sysenter, syscall, or int 2eh instructions; Judging whether the module where the system call instruction executed by the monitored process is located is a trusted Windows library; if not, judging that the system call instruction is generated by an abnormal system call; and recording the abnormal system call to form an abnormal system call sequence; Comparatively analyzing the abnormal system call sequence and the malicious program system call sequence, and if the abnormal system call sequence conforms to the malicious program system call sequence, judging that the monitored program is malicious code; Among them, the step of monitoring, by a monitoring process, system call actions returning from kernel mode to user mode and obtaining system call instructions that cause the monitored process to enter kernel mode for execution includes: implementing monitoring of the monitored process returning from kernel mode to user mode by setting a callback function; when it is found that the monitored process returns from the kernel mode to the user mode, judging whether the operation of the monitored process entering the kernel mode from the user mode is generated by the system call, and if so, recording the system call instruction.

2. The malicious code detection method according to claim 1, wherein The step of judging whether the operation of the monitored process entering the kernel mode from the user mode is generated by a system call includes: Performing disassembly analysis on the call instructions near the return address; Judging, according to the result of the disassembly analysis, whether the operation of the monitored process entering the kernel mode from the user mode is generated by a system call.

3. The malicious code detection method according to claim 1, wherein The step of judging whether the module where the system call instruction executed by the monitored process is located is a trusted Windows library; if not, judging that the system call is an abnormal system call; and recording the abnormal system call to form an abnormal system call sequence includes: Obtaining the module where the system call instruction is located according to the position of the system call instruction executed in the monitored process; Judging whether the module is a trusted Windows library; If not, judging that the system call instruction is generated by a user program executing a system call, and recording the system call in the abnormal system call sequence.

4. The malicious code detection method according to claim 3, wherein The step of judging whether the module is a trusted Windows library includes: Calculating the digital signature of the module; Judging whether the module is a trusted Windows library according to the digital signature.

5. The malicious code detection method according to claim 1, wherein The step of comparatively analyzing the abnormal system call sequence and the malicious program system call sequence, and if the abnormal system call sequence conforms to the malicious program system call sequence, judging that the monitored program is malicious code includes: Constructing a malicious program system call sequence according to the obtained threat intelligence; Comparatively analyzing the abnormal system call sequence of the monitored program and the malicious program system call sequence, and if the abnormal system call sequence conforms to the malicious program system call sequence, judging that the monitored program is malicious code.

6. A malicious code detection device, characterized in that, Including: Monitoring module, which is used to monitor system call actions returning from the kernel mode to the user mode through a monitoring process, and obtain the system call instructions that cause the monitored process to enter the kernel mode for execution; the user mode enters the kernel mode through specific system calls using sysenter, syscall or int 2eh instructions; Processing module, which is used to determine whether the module where the system call instruction executed by the monitored process is located is a trusted Windows library; if not, it is determined that the system call instruction is generated by an abnormal system call; and record the abnormal system call to form an abnormal system call sequence; Judgment module, which is used to compare and analyze the abnormal system call sequence with the malicious program system call sequence. If the abnormal system call sequence matches the malicious program system call sequence, it is determined that the monitored program is malicious code; Among them, the monitoring module includes: Monitoring unit: The monitoring unit is used to monitor the return of the monitored process from the kernel mode to the user mode by setting a callback function; Recording unit: The recording unit is used to determine whether the operation of the monitored process entering the kernel mode from the user mode is generated by the system call when it is found that the monitored process returns from the kernel mode to the user mode. If so, record the system call instruction.

7. The malicious code detection device according to claim 6, wherein The recording unit is further used for: Disassembling and analyzing the call instructions near the return address; According to the result of the disassembling and analyzing, determine whether the operation of the monitored process entering the kernel mode from the user mode is generated by the system call.

8. The malicious code detection device according to claim 6, wherein The processing module includes: Obtaining unit, which is used to obtain the module where the system call instruction is located according to the position of the system call instruction executed in the monitored process; Processing unit, which is used to determine whether the module is a trusted Windows library; If not, it is determined that the system call instruction or information is generated by the user program executing the system call, and record the system call in the abnormal system call sequence.

9. A computer, comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the malicious code detection method according to any one of claims 1 to 5.

10. A readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the malicious code detection method according to any one of claims 1 to 5.

Images