A method for detecting a memory horse
By debugging and monitoring system processes and threads, and utilizing hook functions and stack backtracking techniques, the problem of detecting dynamic memory malware was solved, enabling precise location of memory malware and tracing of attack behavior, thus improving the comprehensiveness and accuracy of network security detection.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- HARBIN ANTIY TECH
- Filing Date
- 2022-12-28
- Publication Date
- 2026-07-14
AI Technical Summary
Existing memory malware detection tools are ineffective at detecting dynamic memory malware, and lack effective means of locating and obtaining its behavioral information, making network security detection and forensics difficult.
By debugging system processes, determining the existence of target functions, monitoring the execution process of each thread, and using hook functions and stack backtracking techniques, we can detect memory space allocation and code signing certificates, determine the characteristics of memory malware behavior, and achieve dynamic detection.
It can effectively detect dynamic memory malware, making up for the shortcomings of existing tools, achieving accurate location of memory malware and tracing of attack behavior, and improving the comprehensiveness and accuracy of network security detection.
Smart Images
Figure CN116257848B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of network security technology, and in particular to a method for detecting memory malware. Background Technology
[0002] In recent years, with the development of network security technology, the detection technology for webshell files has improved to some extent. However, existing detection technologies still struggle to effectively detect memory malware. Existing EDR analysis software can only capture some dangerous and sensitive functions and actions. When encountering memory malware attacks, the behavioral characteristics and stealth of these attacks make detection difficult. Existing memory malware detection tools can only identify static memory malware and cannot effectively detect dynamic memory malware. The lack of effective means to locate memory malware and obtain its behavioral information poses numerous challenges to the detection and forensics work of network security and operations personnel. Summary of the Invention
[0003] In view of this, the present invention provides a method for detecting memory malware. This method involves debugging the system processes of the system to be detected to determine whether a target function has been injected into the system processes. If so, the execution process of each thread is further monitored to determine whether there are target execution behaviors that conform to the characteristics of memory malware. If so, it is determined that the system to be detected is at risk of a memory malware attack. The present invention can dynamically monitor and effectively detect memory malware, at least partially solving the problems existing in the prior art.
[0004] The specific content of the invention is as follows:
[0005] A method for detecting memory malware, comprising:
[0006] Identify the system to be tested and obtain the system processes of the system to be tested.
[0007] The system process is debugged to determine whether there is a system process containing the target function. If so, the corresponding system process is identified as a suspicious process. The target function is an executable function that is injected later.
[0008] The execution process of each thread in each suspicious process is monitored to determine whether there is any target execution behavior that matches the characteristics of a memory malware. If so, the system under test is determined to be at risk of a memory malware attack.
[0009] Furthermore, before obtaining the system processes of the system, the method further includes:
[0010] Obtain system administrator privileges for the system under test.
[0011] Furthermore, the determination of whether a system process containing a target function exists includes:
[0012] The system processes are filtered using hook functions to determine the system processes that are injected into the target function.
[0013] Furthermore, the monitoring of the execution process of each thread contained in each suspicious process includes:
[0014] By traversing the stack back, each thread in each suspicious process is examined, and the traversal process is monitored.
[0015] Furthermore, the determination of whether there is a target execution behavior that conforms to the characteristics of a memory malware includes:
[0016] When an execution behavior that requests memory space outside the memory space executed by each thread is detected, and the requested memory space is marked with an MZ identifier, the corresponding execution behavior is identified as the target execution behavior.
[0017] Furthermore, the determination of whether there is a target execution behavior that conforms to the characteristics of a memory malware includes:
[0018] The code signing certificates executed during the execution of each thread are monitored. When a target code signing certificate is detected, the execution behavior of executing the target code signing certificate is determined as the target execution behavior. The target code signing certificate includes expired code signing certificates and invalid code signing certificates.
[0019] Furthermore, the determination of whether there is a target execution behavior that conforms to the characteristics of a memory malware includes:
[0020] Monitor the functions executed during the execution of each thread to identify functions containing digital signatures.
[0021] Determine whether the digital signature of each function containing a digital signature has expired. If it has expired, then the execution behavior of the corresponding function is determined as the target execution behavior.
[0022] Furthermore, after determining whether the digital signature of each of the functions containing digital signatures has expired, the method further includes:
[0023] If it has not expired, obtain the information of each program module of each function, and determine whether the program module contains a digital signature that is the same as the digital signature contained in the corresponding function. If it does not contain a digital signature, determine the execution behavior of the corresponding program module as the target execution behavior.
[0024] Furthermore, after determining the corresponding execution behavior as the target execution behavior, the method further includes:
[0025] The system monitors each memory space marked with an MZ identifier. When an executable file is detected, the source of the executable file is determined based on its input path, and the execution process of the executable file is monitored to locate the security risks of memory malware and identify its attack behavior.
[0026] Furthermore, after determining the target execution behavior, the method further includes:
[0027] The thread corresponding to the target execution behavior is identified in order to locate the security risk of memory malware.
[0028] A memory malware detection device, comprising:
[0029] The process acquisition module is used to identify the system to be tested and acquire the system processes of the system to be tested.
[0030] The process debugging module is used to debug the system processes and determine whether there is a system process containing the target function. If so, the corresponding system process is identified as a suspicious process. The target function is a post-injected executable function.
[0031] The memory malware risk assessment module is used to monitor the execution process of each thread in each suspicious process to determine whether there is a target execution behavior that matches the characteristics of a memory malware. If so, the system under test is determined to be at risk of a memory malware attack.
[0032] A computer device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the aforementioned memory malware detection method.
[0033] A computer-readable storage medium storing one or more programs that can be executed by one or more processors to implement the aforementioned memory malware detection method.
[0034] The beneficial effects of this invention are reflected in:
[0035] This invention enables dynamic detection of memory malware, overcoming the limitation of existing detection tools that can only identify static memory malware, thus filling a gap in memory malware detection technology. This invention debugs and monitors system processes and threads to detect memory malware, providing a method of detection from the technical level and root cause. It can filter each system execution behavior to identify suspicious processes and actions, thereby achieving effective detection of memory malware. This invention can be integrated with detection tools such as EDR analysis software for more comprehensive and accurate detection of network attacks, further safeguarding network security. Attached Figure Description
[0036] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0037] Figure 1 This is a flowchart of a memory malware detection method according to an embodiment of the present invention;
[0038] Figure 2 This is a flowchart of another memory malware detection method according to an embodiment of the present invention;
[0039] Figure 3 This is a structural diagram of a memory malware detection device according to an embodiment of the present invention. Detailed Implementation
[0040] The embodiments of the present invention will now be described in detail with reference to the accompanying drawings.
[0041] It should be noted that, in the absence of conflict, the following embodiments and features can be combined with each other; and, based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.
[0042] It should be noted that various aspects of embodiments within the scope of the appended claims are described below. It will be apparent that the aspects described herein can be embodied in a wide variety of forms, and any particular structure and / or function described herein is merely illustrative. Based on this disclosure, those skilled in the art will understand that one aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of aspects set forth herein can be used to implement the device and / or practice the method. Additionally, this device and / or method can be implemented using structures and / or functionalities other than one or more of the aspects set forth herein.
[0043] This invention provides an embodiment of a memory malware detection method, such as... Figure 1 As shown, it includes:
[0044] S11: Determine the system to be tested and obtain the system process of the system to be tested.
[0045] S12: Debug the system process to determine if there is a system process containing the target function. If so, identify the corresponding system process as a suspicious process. The target function is a post-injected executable function. Memory malware attacks require injecting executable functions into system processes to achieve their attack objectives. The specific attack is carried out by leveraging the execution of the system process. Therefore, it is necessary to debug the system process to identify the system process into which the executable function has been injected. Such a system process is suspected of being exploited by attackers and is therefore identified as a suspicious process.
[0046] S13: Monitor the execution process of each thread within each suspicious process to determine if there are target execution behaviors that match the characteristics of a memory malware. If so, the system under test is deemed to be at risk of a memory malware attack. These memory malware behaviors include requesting additional memory space, executing expired or invalid code signing certificates, and using expired digital signatures. Execution behaviors exhibiting these characteristics are evasive and can easily evade detection, thus becoming the procedural execution means used by memory malware to carry out attacks.
[0047] Figure 1 The embodiment first debugs the system process of the system to be detected to determine whether the target function has been injected into the system process. If so, it further monitors the execution process of each thread of the corresponding system process to determine whether there is a target execution behavior that matches the characteristics of a memory horse attack. If so, it is determined that the system to be detected is at risk of a memory horse attack. Figure 1 The embodiments described above can dynamically detect memory malware, which overcomes the shortcomings of existing detection tools that can only identify static memory malware and fills the gap in memory malware detection technology. Figure 1 The embodiments described herein debug and monitor system processes and threads to detect memory malware. This is a method of detection from the technical level and root cause, which can filter each system execution behavior, identify suspicious processes and execution behaviors, and thus achieve effective detection of memory malware. Figure 1 The embodiments described above can be used in conjunction with detection tools such as EDR analysis software to conduct more comprehensive and accurate detection of network attack behaviors, thereby further safeguarding network security.
[0048] Preferably, before obtaining the system processes of the system, the method further includes:
[0049] Obtain system administrator privileges for the system under test. Some system processes with higher privilege levels require administrator privileges to access and debug. Therefore, obtaining system administrator privileges allows access to all system processes in the system under test, enabling a comprehensive test and preventing security risks caused by missed detections.
[0050] Preferably, determining whether a system process containing a target function exists includes:
[0051] The system processes are filtered using hook functions to identify those injected with the target function. Hook functions are part of the system message processing mechanism. By setting hook functions, all messages and events can be filtered at the system level, allowing access to messages that are normally inaccessible, and also detecting whether a function has been injected into a system process.
[0052] Preferably, monitoring the execution process of each thread contained in each suspicious process includes:
[0053] Stack backtracing is used to traverse each thread within a suspicious process, monitoring the traversal process. Each thread contains an executable function, and the execution of each thread involves multiple levels of function calls. During the call process, the processor pushes the address of the next instruction after the function call instruction onto the stack. By analyzing the current stack, the stack frame address of the upper-level function is found, and then the stack frame address of the function above that is found. This process is called stack backtracing. By tracing back to the top-level function, a path of function execution is formed. This path allows us to determine the call order of each thread. Monitoring the execution process of each thread within a suspicious process through stack backtracing clearly outlines the call and execution logic of each thread, clarifying the execution behavior of each thread. This is beneficial for detecting and locating target execution behavior, providing support for network security personnel and operations and maintenance personnel in detection and forensics work.
[0054] Preferably, determining whether there is a target execution behavior that matches the characteristics of a memory malware includes:
[0055] When execution behavior that requests memory space outside the memory space of each thread is detected, and the requested memory space is marked with the MZ identifier, the corresponding execution behavior is identified as the target execution behavior. Taking Windows system as an example, each system process and thread generally executes within the .text segment of memory and does not request additional memory space for execution. However, memory malware, as a fileless trojan, will use the VirtualAlloc function to request additional memory space in memory. According to the analysis of known memory malware, the additional memory space it requests is marked with the MZ identifier. The purpose of requesting additional memory space is to execute attack code. The attack code is generally input into the memory space marked with the MZ identifier in the form of a standard executable file, and the corresponding executable file has great stealth, such as a highly stealthy rootkit that is difficult to detect, or shellcode that exploits software vulnerabilities. Memory-based malware typically doesn't immediately use the memory space it allocates; it remains empty and untouched. Only when the malware, through other threads, stealthily executes the attack code packaged as a standard executable, is the corresponding executable sent to the separately allocated memory space for execution, thus carrying out the attack. Therefore, allocating memory space separately is a crucial step in the malware's attack; monitoring execution behavior that allocates memory space outside the memory spaces used by individual threads is a key step in detecting memory-based malware.
[0056] Preferably, determining whether there is a target execution behavior that matches the characteristics of a memory malware includes:
[0057] The code signing certificates executed during the execution of each thread are monitored. When a target code signing certificate is detected, the execution behavior of executing the target code signing certificate is determined as the target execution behavior. The target code signing certificate includes expired code signing certificates and invalid code signing certificates.
[0058] Preferably, determining whether there is a target execution behavior that matches the characteristics of a memory malware includes:
[0059] Monitor the functions executed during the execution of each thread to identify functions containing digital signatures.
[0060] Determine whether the digital signature of each function containing a digital signature has expired. If it has expired, then the execution behavior of the corresponding function is determined as the target execution behavior.
[0061] Preferably, after determining whether the digital signature of each of the functions containing digital signatures has expired, the method further includes:
[0062] If the function has not expired, the information of each program module for each function is obtained, and it is determined whether the program module contains a digital signature that is the same as the digital signature contained in its corresponding function. If not, the execution behavior of the corresponding program module is determined as the target execution behavior. There are two situations where the program module does not contain a digital signature that is the same as the digital signature contained in its corresponding function: either the program module does not contain a digital signature, or the digital signature it contains is different from the digital signature contained in its corresponding function.
[0063] In the aforementioned embodiments, executing expired or invalid code signing certificates, using expired digital signatures, etc., are all procedural execution behaviors of memory malware attacks. These covert execution behaviors call system functions or embed malicious code or instructions to achieve the ultimate attack objective. Therefore, monitoring these target execution behaviors can more comprehensively detect memory malware and avoid missed detections.
[0064] Preferably, after determining the corresponding execution behavior as the target execution behavior, the method further includes:
[0065] The system monitors each memory space marked with an MZ identifier. When an executable file is detected, the source of the executable file is determined based on its input path, and the execution process of the executable file is monitored to locate the security risks of memory malware and identify its attack behavior.
[0066] Preferably, after determining the target execution behavior, the method further includes:
[0067] The thread corresponding to the target execution behavior is identified in order to locate the security risk of memory malware.
[0068] The aforementioned preferred solution can pinpoint the specific location of memory malware security risks in the system and determine the specific attack behaviors carried out by the memory malware. This provides support for network security personnel and operations and maintenance personnel to carry out detection and forensics work. At the same time, it is conducive to tracing the source of attack behaviors, analyzing their attack paths, and further helping network security personnel to optimize security protection strategies and better maintain user network security.
[0069] To further illustrate the method described in this invention, another embodiment of a memory malware detection method is given in conjunction with the foregoing preferred embodiment, such as... Figure 2 As shown, it includes:
[0070] S21: Identify the system to be tested and obtain system administrator privileges for the system to be tested.
[0071] S22: Obtain the system process of the system to be tested.
[0072] S23: Debug the system processes, filter the system processes using hook functions, and determine the system process to which the target function is injected. The target function is a post-injected executable function.
[0073] S24: Traverse each thread contained in each suspicious process by stack backtracking.
[0074] S25: Monitor the traversal process and proceed to S251, S252, and S253 respectively.
[0075] S251: Determine whether there is an execution behavior that requests memory space outside the memory space executed by each thread, and the requested memory space is marked with MZ. If so, determine the corresponding execution behavior as the target execution behavior and proceed to S26; otherwise, return to S25.
[0076] S252: Monitor the code signing certificate executed during the execution of each thread, determine whether a target code signing certificate exists, if so, determine the execution behavior of executing the target code signing certificate as the target execution behavior, and proceed to S27; otherwise, return to S25; the target code signing certificate includes expired code signing certificates and invalid code signing certificates.
[0077] S253: Monitor the functions executed during the execution of each thread, identify functions containing digital signatures, and determine whether the digital signature of each function containing a digital signature has expired. If it has expired, determine the execution behavior of the corresponding function as the target execution behavior and proceed to S27; if it has not expired, obtain the program module information of each function, determine whether the program module contains a digital signature that is the same as the digital signature contained in the corresponding function, if it does not contain a digital signature, determine the execution behavior of the corresponding program module as the target execution behavior and proceed to S27; if it contains a digital signature, return to S25.
[0078] S26: Monitor each memory space marked with MZ in memory. When an executable file is detected, determine the source of the executable file based on its input path and monitor its execution process to locate the memory malware security risk and identify the attack behavior of the memory malware.
[0079] S27: Determine the thread corresponding to the target execution behavior in order to locate the security risk of memory malware.
[0080] Figure 2 The embodiments described above can dynamically detect memory malware, which overcomes the shortcomings of existing detection tools that can only identify static memory malware and fills the gap in memory malware detection technology. Figure 2The embodiments described herein debug and monitor system processes and threads to detect memory malware. This is a method of detection from the technical level and root cause, which can filter each system execution behavior, identify suspicious processes and execution behaviors, and thus achieve effective detection of memory malware. Figure 2 The embodiments described above can be used in conjunction with detection tools such as EDR analysis software to conduct more comprehensive and accurate detection of network attack behaviors, thereby further safeguarding network security. Figure 2 The embodiment described above monitors the execution process of each thread in each suspicious process through stack backtrace, which can clearly sort out the calling and execution logic of each thread and clarify the execution behavior of each thread. This is conducive to the detection and location of target execution behavior and provides support for the detection and evidence collection work of network security personnel and operation and maintenance personnel. Figure 2 The embodiments described above can pinpoint the specific location of memory malware security risks in the system and determine the specific attack behaviors carried out by the memory malware. This provides support for network security personnel and operations and maintenance personnel to carry out detection and forensics work. At the same time, it is beneficial to trace the source of attack behaviors, analyze their attack paths, and further help network security personnel optimize security protection strategies to better maintain user network security.
[0081] Figure 2 The embodiments are based on Figure 1 The preferred embodiment described above is thus obtained; therefore, for Figure 2 The description of the embodiments is relatively simple; please refer to relevant details. Figure 1 The embodiment described above.
[0082] This invention provides an embodiment of a memory malware detection device, such as... Figure 3 As shown, it includes:
[0083] The process acquisition module 31 is used to determine the system to be detected and acquire the system processes of the system to be detected.
[0084] The process debugging module 32 is used to debug the system process and determine whether there is a system process containing the target function. If so, the corresponding system process is identified as a suspicious process. The target function is an executable function that is injected later.
[0085] The memory malware risk assessment module 33 is used to monitor the execution process of each thread in each suspicious process, and to determine whether there is a target execution behavior that matches the characteristics of a memory malware. If so, it is determined that the system under test has a memory malware attack risk.
[0086] Figure 3The embodiment first debugs the system process of the system to be detected to determine whether the target function has been injected into the system process. If so, it further monitors the execution process of each thread of the corresponding system process to determine whether there is a target execution behavior that matches the characteristics of a memory horse attack. If so, it is determined that the system to be detected is at risk of a memory horse attack. Figure 3 The embodiments described above can dynamically detect memory malware, which overcomes the shortcomings of existing detection tools that can only identify static memory malware and fills the gap in memory malware detection technology. Figure 3 The embodiments described herein debug and monitor system processes and threads to detect memory malware. This is a method of detection from the technical level and root cause, which can filter each system execution behavior, identify suspicious processes and execution behaviors, and thus achieve effective detection of memory malware. Figure 3 The embodiments described above can be used in conjunction with detection tools such as EDR analysis software to conduct more comprehensive and accurate detection of network attack behaviors, thereby further safeguarding network security.
[0087] Preferably, before acquiring the system processes of the system, the process acquisition module 31 is further configured to:
[0088] Obtain system administrator privileges for the system under test.
[0089] Preferably, determining whether a system process containing a target function exists includes:
[0090] The system processes are filtered using hook functions to determine the system processes that are injected into the target function.
[0091] Preferably, monitoring the execution process of each thread contained in each suspicious process includes:
[0092] By traversing the stack back, each thread in each suspicious process is examined, and the traversal process is monitored.
[0093] Preferably, determining whether there is a target execution behavior that matches the characteristics of a memory malware includes:
[0094] When an execution behavior that requests memory space outside the memory space executed by each thread is detected, and the requested memory space is marked with an MZ identifier, the corresponding execution behavior is identified as the target execution behavior.
[0095] Preferably, determining whether there is a target execution behavior that matches the characteristics of a memory malware includes:
[0096] The code signing certificates executed during the execution of each thread are monitored. When a target code signing certificate is detected, the execution behavior of executing the target code signing certificate is determined as the target execution behavior. The target code signing certificate includes expired code signing certificates and invalid code signing certificates.
[0097] Preferably, determining whether there is a target execution behavior that matches the characteristics of a memory malware includes:
[0098] Monitor the functions executed during the execution of each thread to identify functions containing digital signatures;
[0099] Determine whether the digital signature of each function containing a digital signature has expired. If it has expired, then the execution behavior of the corresponding function is determined as the target execution behavior.
[0100] Preferably, after determining whether the digital signature of each of the functions containing digital signatures has expired, the memory malware risk determination module 33 is further configured to:
[0101] If it has not expired, obtain the information of each program module of each function, and determine whether the program module contains a digital signature that is the same as the digital signature contained in the corresponding function. If it does not contain a digital signature, determine the execution behavior of the corresponding program module as the target execution behavior.
[0102] Preferably, after determining the corresponding execution behavior as the target execution behavior, the memory malware risk determination module 33 is further configured to:
[0103] The system monitors each memory space marked with an MZ identifier. When an executable file is detected, the source of the executable file is determined based on its input path, and the execution process of the executable file is monitored to locate the security risks of memory malware and identify its attack behavior.
[0104] Preferably, after determining the target execution behavior, the memory malware risk determination module 33 is further configured to:
[0105] The thread corresponding to the target execution behavior is identified in order to locate the security risk of memory malware.
[0106] Figure 3 The embodiment is as follows: Figure 1 , Figure 2 The device embodiments corresponding to the method embodiments described herein include some implementation processes and technical effects. Figure 1 , Figure 2 The embodiments described are similar, therefore, for Figure 3 The description of the embodiments is relatively simple; please refer to relevant details. Figure 1 , Figure 2 The embodiment described above.
[0107] The present invention also provides an embodiment of a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the method described in the foregoing embodiments, the method of which can be found in [reference needed]. Figure 1 , Figure 2 The description of the embodiments will not be repeated here.
[0108] This invention also provides a computer-readable storage medium storing one or more programs that can be executed by one or more processors to implement the methods described in the foregoing embodiments.
[0109] This invention enables dynamic detection of memory malware, overcoming the limitation of existing detection tools that can only identify static memory malware, thus filling a gap in memory malware detection technology. This invention debugs and monitors system processes and threads to detect memory malware, providing a method of detection from the technical level and root cause. It can filter each system execution behavior to identify suspicious processes and actions, thereby achieving effective detection of memory malware. This invention can be integrated with detection tools such as EDR analysis software for more comprehensive and accurate detection of network attacks, further safeguarding network security.
[0110] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.
Claims
1. A method for detecting memory malware, characterized in that, include: Identify the system to be tested and obtain the system processes of the system to be tested; The system process is debugged to determine whether there is a system process containing the target function. If so, the corresponding system process is identified as a suspicious process. The target function is an executable function that is injected later. The execution process of each thread in each suspicious process is monitored to determine whether there is a target execution behavior that matches the characteristics of a memory horse attack. If so, the system under test is determined to be at risk of a memory horse attack. The target execution behaviors that conform to the characteristics of memory malware include requesting additional memory space, executing expired or invalid code signing certificates, and using expired digital signatures. The determination of whether there is a target execution behavior that conforms to the characteristics of memory horse behavior includes: when an execution behavior that requests memory space outside the memory space executed by each thread is detected, and the requested memory space has an MZ identifier, the corresponding execution behavior is determined as the target execution behavior.
2. The method according to claim 1, characterized in that, Prior to obtaining the system processes of the system, the method further includes: Obtain system administrator privileges for the system under test.
3. The method according to claim 1, characterized in that, The determination of whether a system process containing a target function exists includes: The system processes are filtered using hook functions to determine the system processes that are injected into the target function.
4. The method according to claim 1, characterized in that, The monitoring of the execution process of each thread within each suspicious process includes: By traversing the stack back, each thread in each suspicious process is examined, and the traversal process is monitored.
5. The method according to claim 1, characterized in that, The determination of whether there is a target execution behavior that matches the characteristics of a memory malware includes: The code signing certificates executed during the execution of each thread are monitored. When a target code signing certificate is detected, the execution behavior of executing the target code signing certificate is determined as the target execution behavior. The target code signing certificate includes expired code signing certificates and invalid code signing certificates.
6. The method according to claim 1, characterized in that, The determination of whether there is a target execution behavior that matches the characteristics of a memory malware includes: Monitor the functions executed during the execution of each thread to identify functions containing digital signatures; Determine whether the digital signature of each function containing a digital signature has expired. If it has expired, then the execution behavior of the corresponding function is determined as the target execution behavior.
7. The method according to claim 6, characterized in that, After determining whether the digital signature of each of the functions containing digital signatures has expired, the method further includes: If it has not expired, obtain the information of each program module of each function, and determine whether the program module contains a digital signature that is the same as the digital signature contained in the corresponding function. If it does not contain a digital signature, determine the execution behavior of the corresponding program module as the target execution behavior.
8. The method according to claim 1, characterized in that, After determining the corresponding execution behavior as the target execution behavior, the method further includes: The system monitors each memory space marked with an MZ identifier. When an executable file is detected, the source of the executable file is determined based on its input path, and the execution process of the executable file is monitored to locate the security risks of memory malware and identify its attack behavior.
9. The method according to any one of claims 1-8, characterized in that, After determining the target execution behavior, the method further includes: The thread corresponding to the target execution behavior is identified in order to locate the security risk of memory malware.