A method and apparatus for detecting cross-process malicious behavior in Windows systems

Abstract

This invention discloses a method for detecting cross-process malicious behavior in Windows systems. The method includes: monitoring user-mode programs' calls to cross-process memory write APIs by hooking the Windows system service scheduling table or filtering drivers; when a source process is detected performing a memory write operation to a target process; when the target process is detected performing a predefined sensitive behavior operation, obtaining the thread call stack address sequence corresponding to the sensitive behavior operation in real time; comparing the thread call stack address sequence with the injection operation record; if at least one instruction address in the call stack falls within the memory address range written by the source process to the target process, the sensitive behavior operation is determined to constitute malicious behavior initiated by the source process. By monitoring cross-process memory write operations to establish a basis for tracing injection behavior, and combining the address space matching mechanism of the sensitive behavior call stack, accurate behavioral tracing of remote code injection attacks is achieved for the first time.

Description

Technical Field

[0001] This invention relates to the field of software detection technology, and in particular to a method and apparatus for detecting cross-process malicious behavior in Windows systems. Background Technology

[0002] In the field of Windows system security detection, remote code injection has become a mainstream technique for malicious programs to launch attacks. This type of attack typically manifests as a malicious process (e.g., process A) injecting code fragments into the memory space of a target process (e.g., process B) for execution, making it difficult for security software to trace the true source of the attack. Currently, mainstream security solutions, when detecting that the injected process (process B) is performing high-risk and sensitive behavior (such as creating fake files in the system directory, modifying critical registry entries, or initiating malicious network connections), can only generate alerts based on the process where the behavior occurred (process B).

[0003] The existing technology has a significant flaw: when an alert message indicates that process B has triggered risky behavior, although it can confirm the authenticity of the behavior, it cannot reveal that the behavior is actually caused by malicious code injected by process A. This lack of tracing capability leads to two serious consequences: first, users may mistakenly allow the alerted process to proceed because it is a trusted system process (such as a whitelisted process), thus letting the real attack source process A go undetected; second, malicious programs can actively exploit this flaw to inject malicious code into whitelisted processes trusted by security software, thereby bypassing the detection mechanism.

[0004] The more fundamental technical bottleneck lies in the fact that existing solutions lack the ability to fine-grained monitor cross-process memory write behavior. Security software cannot correlate sensitive behaviors in process B with injected code regions in its memory, nor can it trace back to the source process A through code execution. This makes it difficult for security protection systems to achieve accurate malicious behavior tracing in process injection scenarios, severely limiting the effectiveness of threat detection. Summary of the Invention

[0005] The purpose of this invention is to provide a method and apparatus for detecting cross-process malicious behavior in Windows systems. By monitoring cross-process memory write operations, a basis for tracing injection behavior is established. Combined with the address space matching mechanism of sensitive behavior call stack, accurate behavior tracing of remote code injection attacks is achieved for the first time.

[0006] To address the aforementioned technical problems, a first aspect of this invention provides a method for detecting cross-process malicious behavior in a Windows system, comprising the following steps:

[0007] By hooking the system service scheduler table or filtering the driver in the Windows system, the system monitors the user-mode program's calls to the cross-process memory write API. When it detects that the source process is performing a memory write operation to the target process, it records the injection operation record containing the source process identifier, the target process identifier, the starting address of the memory to be written, and the size of the write operation.

[0008] When the target process is detected to be performing a predefined sensitive behavior operation, the thread call stack address sequence corresponding to the sensitive behavior operation is obtained in real time. The sensitive behavior operation includes at least one of the following: creating a fake system file in the system directory, modifying a key system registry key, or initiating a malicious network connection.

[0009] The thread call stack address sequence is compared with the injection operation record. If at least one instruction address in the call stack falls within the memory address range written by the source process to the target process, the sensitive behavior operation is determined to constitute a malicious behavior initiated by the source process.

[0010] Furthermore, when a memory write operation is detected from a source process to a target process, the injection operation record, which includes the source process identifier, the target process identifier, the starting address of the memory write, and the write size, is recorded, including:

[0011] By hooking the system service scheduler or loading a filter driver, the user-mode program's calls to the cross-process memory write API are intercepted at the Windows system kernel layer;

[0012] When the cross-process memory write API is detected to be called, its call parameters are captured and parsed in real time. The call parameters include at least: the source process identifier that initiates the write, the target process identifier that is being written to, the starting virtual address of the memory to be written in the target process, and the length of the data to be written.

[0013] The call parameters are associated with the current system timestamp to generate a structured injection operation record and store it in the kernel-mode storage area;

[0014] When the target process is detected to have exited, all injection operation records associated with the target process are cleaned up.

[0015] Furthermore, the step of obtaining the thread call stack address sequence corresponding to the sensitive behavior operation in real time when the target process is detected to be performing a sensitive behavior operation includes:

[0016] The system behavior of the target process is intercepted in real time by the kernel-mode driver. When the target process is detected to be performing a predefined sensitive behavior operation, the thread performing the sensitive behavior operation is stopped and a call stack capture instruction is triggered.

[0017] Perform a stack backtracking operation on the thread performing the sensitive behavior operation, extract the instruction pointers of several stack frames from low to high call level, and obtain the thread call stack address sequence;

[0018] Based on the call stack address sequence, sensitive operation type identifier, and capture timestamp, a matching behavior unit is generated. The matching behavior unit is used to perform address space matching with the injection operation record.

[0019] Furthermore, the step of intercepting the system behavior of the target process in real time through a kernel-mode driver, and stopping the thread executing the sensitive behavior operation and triggering a call stack capture instruction when the target process is detected to be performing a predefined sensitive behavior operation, includes:

[0020] Register at least one system behavior monitoring point in the kernel-mode driver. The monitoring point is associated with a preset sensitive operation type identifier, including file system monitoring point, registry operation monitoring point and network connection monitoring point.

[0021] When the target process triggers any system behavior monitoring point, the behavior feature parameters of the current operation are extracted. The behavior feature parameters include: file operation path, registry key path or network connection destination IP and port. The behavior feature parameters are matched with the preset sensitive behavior feature rule base in real time. If a high-risk sensitive rule is matched, a sensitive operation type identifier is generated.

[0022] When a sensitive operation type identifier is generated, the processor context of the thread executing the current operation is saved to the kernel-mode non-paged memory area;

[0023] Based on the thread identifier and the associated sensitive operation type identifier, a call stack capture instruction is generated and passed to the stack backtracking module.

[0024] Furthermore, before generating the matching behavior unit based on the call stack address sequence, sensitive operation type identifier, and capture timestamp, the method further includes:

[0025] Before generating the behavior unit to be matched, it is verified that all instruction pointers in the call stack address sequence are within the user-mode virtual address space of the target process. If a kernel-mode address exists, the call stack address sequence is discarded.

[0026] Further, the thread call stack address sequence is compared with the injection operation record, including:

[0027] Based on the target process identifier and capture timestamp in the behavior unit to be matched, a subset of records is obtained from the injection operation record. The target process identifier of the subset of records is the same as the target process identifier in the current behavior unit to be matched, or the timestamp of the subset of records is earlier than the capture timestamp of the behavior unit to be matched.

[0028] Traverse all injection operation records in the record subset and perform an address space inclusion determination operation. When there is at least one instruction pointer value in the call stack address sequence that is within the address range of the corresponding injection operation record, determine that the instruction pointer falls into the memory address region written by the source process to the target process.

[0029] From a number of injection operation records that meet the address space inclusion determination operation conditions, the source process identifier of the injection operation record with the earliest timestamp is identified as the malicious injection source of the current sensitive behavior operation.

[0030] Further, the step of obtaining a subset of records from the injection operation record based on the target process identifier and capture timestamp in the target behavior unit includes:

[0031] In the kernel-mode non-paged memory area, an injection operation record storage area with a key / value pair structure is constructed, wherein the key is the target process identifier and the value is a linked list of injection operation records arranged in ascending order of timestamp;

[0032] Using the target process identifier in the target behavior unit as the retrieval key, extract all injection operation records associated with the target process identifier from the injection operation record storage area to form an initial record set;

[0033] Traverse the initial record set and filter out injection operation records whose timestamps are earlier than the capture timestamps of the behavior units to be matched;

[0034] The filtered injection operation records are subjected to address space validity verification. Only injection operation records that are valid and have not been released within the virtual address space of the target process are retained, based on the address range defined by the memory start address and the write size.

[0035] The verified injection operation records are reassembled in ascending order of timestamps to generate a dynamic subset of records for address space matching.

[0036] Furthermore, the operation of determining address space inclusion includes:

[0037] Determine whether there exists at least one instruction pointer in the call stack address sequence whose value falls within the address range from the start virtual address to the end virtual address of the injection operation record;

[0038] The termination virtual address is the sum of the starting virtual address and the length of the written data.

[0039] Accordingly, a second aspect of the present invention provides a Windows system cross-process malicious behavior detection device.

[0040] Accordingly, a third aspect of the present invention provides an electronic device, including: at least one processor; and a memory connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to cause the at least one processor to perform the above-described Windows system cross-process malicious behavior detection method.

[0041] Accordingly, a fourth aspect of the present invention provides a computer-readable storage medium having computer instructions stored thereon, which, when executed by a processor, implement the above-described method for detecting cross-process malicious behavior in a Windows system.

[0042] The above-described technical solutions of the embodiments of the present invention have the following beneficial technical effects:

[0043] 1. By dynamically correlating monitored cross-process memory write operations with real-time call stack analysis of sensitive operations occurring in subsequent target processes, the problem of traditional solutions being able to only alert the target process but not identify the true source of the malicious activity is solved. When sensitive behavior is detected, by determining whether the instruction address in its call stack falls within the previously recorded injection memory range, it is possible to accurately determine that the behavior was caused by the source process that initiated the injection, which significantly improves the accuracy of attack tracing and, in particular, effectively solves the problem of the untraceable source of behavior after malicious code is injected into a trusted process.

[0044] 2. To address the common tactic of malware injecting malicious code into trusted system processes to bypass security detection, this solution proposes a proactive defense mechanism based on memory address space matching. By capturing sensitive behaviors in real time at the kernel level to obtain precise call stack information, and combining this with historical injection operations, it can clearly identify that even malicious behaviors executed within trusted processes originate from external malicious injection source processes. This breaks the attacker's strategy of using the system's trust in whitelisted processes to conceal their own behavior, filling a critical gap in security defense for tracing the source of malicious injection behaviors within whitelisted processes.

[0045] 3. Automatically clean up related memory injection records upon target process exit, effectively preventing resource waste caused by the accumulation of invalid data. Simultaneously, employing an efficient storage structure combined with address space validity verification ensures that during behavior source matching, only a small number of valid and relevant records require rapid address range comparison. This optimization keeps the overhead of core matching operations at a low and predictable level, guaranteeing the system's real-time responsiveness under high load scenarios. Furthermore, by operating on critical data in the kernel's non-paged memory area, it avoids the latency risks that memory paging might cause, thereby maintaining the stability of the entire system. Attached Figure Description

[0046] Figure 1 This is a flowchart of a Windows system cross-process malicious behavior detection method provided in an embodiment of the present invention;

[0047] Figure 2 This is a block diagram of a Windows system cross-process malicious behavior detection device module provided in an embodiment of the present invention.

[0048] Figure label:

[0049] 1. Memory monitoring module, 2. Address call module, 3. Behavior determination module. Detailed Implementation

[0050] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to specific embodiments and the accompanying drawings. It should be understood that these descriptions are merely exemplary and not intended to limit the scope of the invention. Furthermore, descriptions of well-known structures and techniques are omitted in the following description to avoid unnecessarily obscuring the concept of the invention.

[0051] In the field of computer science, an API (Application Programming Interface) is a set of predefined functions provided by an operating system or software library to developers to implement specific functionalities.

[0052] Please refer to Figure 1 The first aspect of this invention provides a method for detecting cross-process malicious behavior in a Windows system, comprising the following steps:

[0053] Step S100: Monitor user-mode programs' calls to the cross-process memory write API by hooking the Windows system service scheduler or filtering the driver. When a source process is detected performing a memory write operation to the target process, record the injection operation record containing the source process identifier, the target process identifier, the starting address of the memory to be written, and the write size.

[0054] By hooking into the Windows kernel-level System Service Scheduler Table (SSDT) ​​or loading filter drivers, deep monitoring of user-mode program calls to cross-process memory write APIs (such as NtWriteVirtualMemory) is achieved. Key parameters during system service calls are intercepted: when a source process (e.g., process A) is detected performing a virtual memory write operation to a target process (e.g., process B), the source process ID, target process ID, start address of the write memory, and length of the written data are simultaneously captured and structurally recorded. Leveraging the high privileges of kernel mode, all cross-process memory operations are ensured to be recorded without omission, forming a traceable injection operation log. The recorded content is stored in the kernel's non-paged memory area to avoid the risk of data loss due to memory paging, while also providing spatiotemporal anchors for subsequent behavior correlation.

[0055] Step S200: When the target process (B) is detected to be performing a predefined sensitive behavior operation, the thread call stack address sequence corresponding to the sensitive behavior operation is obtained in real time. The sensitive behavior operation includes at least one of the following: creating a fake system file in the system directory, modifying a critical system registry key, or initiating a malicious network connection.

[0056] Dynamic monitoring is implemented for sensitive behaviors of the target process (i.e., the injected process B), and pre-defined system behavior hooks (such as file creation, registry modification, and network connection) are registered through kernel-mode drivers. When the target process triggers a high-risk sensitive behavior (e.g., creating a malicious file impersonating svchost.exe in the system directory), a stack backtrace operation is performed to extract the thread call stack address sequence. This sequence is essentially a set of instruction pointers arranged according to the call hierarchy, representing the code execution path at the moment the behavior is triggered. The definition of sensitive behaviors focuses on commonly used attacker techniques and tactics (such as system file tampering, registry persistence, and C2 communication), ensuring that monitoring covers mainstream malicious behavior patterns.

[0057] Step S300: Compare the thread call stack address sequence with the injection operation record. If at least one instruction address in the call stack falls within the memory address range written by the source process to the target process, the sensitive behavior operation is determined to constitute a malicious behavior initiated by the source process.

[0058] Behavior tracing is achieved based on a dual rule of spatiotemporal correlation and memory address inclusion: First, based on the target process ID and timestamp of the sensitive behavior, previously recorded memory injection operation records related to that process are filtered. Second, the call stack address sequence of the unit to be matched is compared with the memory address range (start address to start address + write length) in the injection record. If an instruction pointer in the call stack falls into the memory range of a certain injection, it is determined that the sensitive behavior was driven by the source process (process A) that initiated the injection. This mechanism breaks through the limitation of traditional security schemes that only rely on process ID for alerts, and accurately distinguishes the behavior attribution of native code and injected code within a process through instruction-level address space matching.

[0059] By dynamically correlating kernel-level memory injection monitoring with the call stack of sensitive behaviors, the problem of untraceable source of malicious code injected into whitelisted processes is solved. The granularity of behavior tracing is elevated from the process level to the memory address level: even if malicious behavior occurs within a trusted target process, the actual source process initiating the attack can still be accurately located based on the inclusion relationship between the call stack address and the injected memory range. This also avoids misjudgments caused by traditional solutions relying on process behavior characteristics, and ensures system performance stability through automatic cleanup of injection records and an efficient storage structure (such as a time-sorted linked list of target process ID indexes). Ultimately, this achieves accurate, real-time, and low-overhead detection of cross-process malicious behavior.

[0060] Furthermore, in step S100, when a memory write operation from the source process to the target process is detected, an injection operation record is recorded, including the source process identifier, the target process identifier, the starting address of the memory write, and the write size.

[0061] Step S110 involves intercepting user-mode programs' calls to cross-process memory write APIs at the Windows system kernel level by hooking the System Service Descriptor Table (SSDT) ​​or loading a filter driver.

[0062] By hooking the Windows kernel's System Service Scheduler Table (SSDT) ​​or loading a filter driver, user-mode programs' calls to cross-process memory write APIs (such as NtWriteVirtualMemory) are intercepted at the kernel level. SSDT hooking redirects API calls to a custom monitoring function by modifying the entry address of the system service call table; the filter driver deeply intercepts memory operation events by registering callback routines (such as PsSetCreateProcessNotifyRoutine). This design ensures that all cross-process write operations are captured by the kernel without omission, establishing a low-level data foundation for subsequent behavior tracing.

[0063] Step S120: When the cross-process memory write API is detected to be called, its call parameters are captured and parsed in real time. The call parameters include at least: the source process ID that initiates the write, the destination process ID that is being written to, the starting virtual address of the memory to be written in the target process, and the length of the data to be written.

[0064] When the monitoring function detects a cross-process memory write API call at the kernel level, it uses kernel-mode privileges to parse the call parameters in real time. By directly accessing the registers and stack frame data of the calling thread, it accurately captures the source process ID to determine the initiator of the injection (e.g., the PID of process A), the destination process ID to locate the injected process (e.g., the PID of process B), the base address to record the starting position of the memory write in the target process (e.g., 0x000002079C950000), and the buffer length to define the address range boundary of the injected memory block (from the starting address to the starting address + length, e.g., 4096 bytes forming the range [0x000002079C950000, 0x000002079C951000]). This completes the spatiotemporal and spatial characteristics of the cross-process memory operation, ensuring the real-time and accuracy of information capture.

[0065] Step S130: Associate the call parameters with the current system timestamp to generate a structured injection operation record and store it in the kernel-mode storage area.

[0066] The parsed call parameters are bound to a high-precision system timestamp to generate a structured injection operation record (e.g., {source PID, target PID, starting address, length, timestamp}). This record is stored in a kernel-mode non-paged memory pool to avoid data access delays or loss caused by memory paging. The introduction of timestamps provides timing constraints for subsequent sensitive behavior associations (e.g., only matching records whose injection time is earlier than the time the behavior occurred), while structured storage supports efficient retrieval and matching operations.

[0067] Step S140: When the target process is detected to have exited, clean up all injection operation records associated with the target process.

[0068] By registering process exit callback notifications (such as PsSetCreateProcessNotifyRoutine Ex), the lifecycle status of the target process (e.g., process B) is monitored in real time. When the target process terminates, a cleanup mechanism is automatically triggered: all injection operation records associated with the target process ID are quickly located and deleted. This design avoids invalid data occupying kernel memory resources for a long time, prevents storage space expansion caused by frequent process creation / exit, and ensures system stability and low overhead during long-term operation.

[0069] By employing deep kernel-level monitoring (achieving comprehensive capture through SSDT hooking or filtering drivers), precise parameter parsing (real-time acquisition of source / target process identifiers, starting virtual addresses, and write lengths), time-sequential storage (associating timestamps and storing them in non-paged memory areas to ensure real-time performance), and an intelligent cleanup mechanism (automatically clearing associated records upon target process exit), a full lifecycle tracking system for cross-process memory injection behavior has been constructed. Its core value lies in ensuring that all cross-process write operations are fully recorded. It defines the memory range by starting address and length and establishes a spatiotemporal anchoring relationship by combining timestamps. At the same time, it achieves efficient resource management by relying on non-paged memory access and automatic cleanup mechanisms, thereby providing a complete, low-noise, and highly available injection operation data foundation for accurate tracing of subsequent sensitive behaviors.

[0070] Furthermore, in step S200, when the target process is detected to be performing a sensitive operation, the sequence of thread call stack addresses corresponding to the sensitive operation is obtained in real time, including:

[0071] Step S210: The system behavior of the target process is intercepted in real time by the kernel-mode driver. When the target process is detected to be performing a predefined sensitive behavior operation, the thread performing the sensitive behavior operation is stopped and the call stack capture instruction is triggered.

[0072] By deploying a driver in kernel mode, the target process is monitored in real time. When the process attempts to perform a preset sensitive operation, the driver immediately intercepts the operation, forcibly suspends the thread performing the operation, and synchronously triggers a mechanism to capture the thread's current complete call stack information.

[0073] Step S220: Perform a stack backtracking operation on the thread performing the sensitive behavior operation, extract the instruction pointers of several stack frames from low to high according to the call level, and obtain the thread call stack address sequence.

[0074] Based on the thread context, a stack walk operation is performed: First, starting from the current stack frame pointer (such as the RBP or RSP register value), the stack frame chain structure is parsed level by level; second, the instruction pointer of each stack frame is extracted from the call hierarchy from low to high (i.e., from the most recently called function to the initially called function), forming an ordered address sequence (such as [0x77F960AC, 0x77F960AF, ...]); third, stack frame boundaries are dynamically identified (to address frame pointer omissions caused by compiler optimizations), and the module information associated with the address is parsed through the symbol engine (such as kernel32.dll + 0x1A2B). This sequence is essentially a code execution path fingerprint at the moment the sensitive behavior is triggered, providing crucial address space information for subsequent determination of whether the behavior originates from injected code.

[0075] Step S230: Generate a behavior unit to be matched based on the call stack address sequence, sensitive operation type identifier (Operation Type ID) and capture timestamp. The behavior unit to be matched is used to perform address space matching with the injected operation record.

[0076] The system integrates the instruction pointer sequence output from the stack backtrace, predefined sensitive operation type identifiers (such as FILE_CREATE_SPOOF indicating spoofed system file creation behavior), and high-precision system capture timestamps to generate structured behavior units to be matched (data structure example: {target process ID, sensitive operation type ID, timestamp, [call stack address 1, address 2,...]}). This process has three core elements: the address sequence accurately represents the code execution path when the sensitive behavior is triggered, providing a basis for subsequent address space matching; the operation type identifier distinguishes different high-risk behavior patterns (such as file tampering, registry modification, or malicious network connection), supporting differentiated tracing strategies; and the timestamp establishes strict timing constraints, ensuring that only injection records occurring earlier than the sensitive behavior are associated. The behavior units are stored in the kernel's non-paged memory area, avoiding paging latency and achieving millisecond-level address space matching with the injection records from step S100.

[0077] This end-to-end operation, which involves real-time interception of sensitive behaviors by kernel drivers, extraction of instruction pointers through execution stack backtracking, and generation of behavior units by fusing spatiotemporal information, achieves deep instruction-level analysis of high-risk operations in the target process. Real-time thread state freezing ensures the integrity of call stack capture and completely avoids execution path distortion caused by asynchronous sampling; the instruction pointer sequence refines the granularity of behavior tracing from the process level to the code address level, providing an atomic basis for distinguishing between native code within the target process and externally injected code; and the spatiotemporal behavior unit integrates operation semantics, execution path, and occurrence sequence to construct a standardized interface that efficiently associates with injection records.

[0078] Furthermore, in step S210, the system behavior of the target process is intercepted in real time by the kernel-mode driver. When the target process is detected to be performing a predefined sensitive operation, the thread performing the sensitive operation is stopped and a call stack capture instruction is triggered, including:

[0079] Step S211: Register at least one system behavior monitoring point in the kernel-mode driver. The monitoring point is associated with a preset sensitive operation type identifier (Operation Type ID), including file system monitoring point, registry operation monitoring point and network connection monitoring point.

[0080] Multi-dimensional system behavior monitoring points are registered in the kernel-mode driver, including file system monitoring points (intercepting operations such as IRP_MJ_CREATE through the file system micro-filter driver), registry operation monitoring points (capturing key-value modification events using CmRegisterCallback), and network connection monitoring points (monitoring TCP / UDP connections based on the Windows Filtering Platform (WFP) framework). Each monitoring point is associated with a pre-defined sensitive operation type identifier (such as OP_FILE_SPOOF indicating the creation of counterfeit system files), forming a mapping relationship between behavior types and monitoring logic, providing a classification basis for subsequent differentiated responses.

[0081] Step S212: When the target process triggers any system behavior monitoring point, extract the behavior feature parameters of the current operation. The behavior feature parameters include: file operation path, registry key path or network connection destination IP and port. Match the behavior feature parameters with the preset sensitive behavior feature rule base in real time. If a high-risk sensitive rule is matched, generate a sensitive operation type identifier.

[0082] When the target process triggers any monitoring point (such as attempting to create a fake file named svchost.exe in the C:\Windows\System32 path), the behavioral characteristic parameters of the current operation are extracted in real time: the full path in file operations, the key path in registry operations (such as HKCU\Software\Microsoft\Windows\Run), or the target IP and port in network connections (such as 192.168.1.100:443). The driver performs real-time matching of the characteristic parameters with the sensitive behavior characteristic rule base (a predefined malicious pattern library, such as a blacklist of high-risk files in the system directory, malicious registry key rules, and a known C2 server IP library): if the path contains a system directory and the file name is similar to the system core module, or the connection IP matches the malicious intelligence database, a corresponding sensitive operation type identifier (such as OP_FILE_SPOOF) is generated.

[0083] Step S213: When a sensitive operation type identifier is generated, the thread executing the current operation is immediately suspended, and the processor context of the thread executing the current operation is saved to the kernel-mode non-paged memory area.

[0084] When a rule match generates a sensitive operation type identifier, a kernel-mode thread suspension primitive (such as KeSuspendThread) is immediately invoked to freeze the thread currently executing the operation, preventing the execution of subsequent instructions. Simultaneously, the thread's processor context (including register states RIP, RSP, RBP, and stack memory snapshots) is completely saved to the kernel's non-paged pool, ensuring that critical execution states are not affected by paging or memory reclamation, and providing an atomically consistent thread snapshot for stack backtracking.

[0085] Step S214: Based on the thread identifier (Thread ID) of the suspended thread and the associated sensitive operation type identifier, generate a call stack capture instruction and pass it to the stack backtracking module.

[0086] Based on the thread identifier (Thread ID) of the suspended thread and the associated sensitive operation type identifier (such as OP_REG_KEY_MODIFY), a structured call stack capture instruction (containing thread ID, operation type, and context storage address) is generated. This instruction is passed to a dedicated stack backtracking module through the kernel event notification mechanism (such as KeSetEvent), triggering the subsequent stack frame parsing process, realizing fully automated scheduling of the monitoring → suspension → analysis process.

[0087] A high-precision sensitive behavior capture chain was constructed through multi-dimensional monitoring point registration, real-time behavioral feature matching, and automated transmission of analysis commands. Relying on kernel-mode permissions, a microsecond-level response from behavior triggering to blocking operation is achieved, ensuring that malicious operations are interrupted immediately before completion. A rule-driven sensitive operation identification mechanism transforms behavioral semantics into quantifiable type labels, providing a structured basis for cross-process tracing.

[0088] Furthermore, before generating the matching behavior unit based on the call stack address sequence, the sensitive operation type identifier (OperationType ID), and the capture timestamp in step S230, the following is also included:

[0089] Step S221: Before generating the behavior unit to be matched, verify that all instruction pointers in the call stack address sequence are within the user-mode virtual address space of the target process. If a kernel-mode address exists, discard the call stack address sequence.

[0090] Before generating the behavior unit to be matched, perform strict user-mode address space verification on the call stack address sequence extracted by the stack traceback module: obtain the boundary of its user-mode virtual address space by accessing the EPROCESS structure of the target process (usually 0x0000000000000000 to 0x00007FFFFFFF0000 in the Windows x64 system), and verify that each instruction pointer in the sequence falls within this range address by address. If it is detected that any address exceeds the user-mode space (such as above the kernel-mode range 0xFFFF080000000000), it is determined that the stack traceback process may have captured the system call context or kernel stack frame (such as state pollution caused by thread switching), and immediately discard the entire call stack address sequence. This verification relies on directly calling the memory manager interface (such as MmIsAddressValid) with kernel-mode permissions to complete in milliseconds, ensuring that only pure user-mode execution path data is retained for subsequent matching use.

[0091] By forcibly verifying the pure user-mode attribute of the call stack address sequence, contaminated data caused by the mixing of kernel stack frames is eliminated at the source. On the one hand, it avoids the risk of false matching caused by system call or interrupt context interference (such as misjudging kernel API addresses as injected code), improving the credibility of behavior traceability; on the other hand, it ensures that the behavior unit to be matched only contains the code execution path of the target process itself, providing an atomic input that conforms to the process memory model for address space matching, fundamentally guaranteeing the rigor and accuracy of the cross-process malicious behavior determination logic.

[0092] Further, the comparison of the thread call stack address sequence with the injection operation record in step S300 includes:

[0093] Step S310, according to the target process identifier and capture timestamp in the behavior unit to be matched, obtain a record subset from the injection operation record, where the target process identifier of the record subset is the same as the target process identifier in the current behavior unit to be matched or the timestamp of the record subset is earlier than the capture timestamp of the behavior unit to be matched.

[0094] Based on the target process identifier and capture timestamp in the behavior unit to be matched, filter the dynamic record subset from the injection operation record pool. The filtering is performed with two constraints: first, accurately match the target process ID (ensuring that only operation records related to the same injected process are associated), and second, filter records with timestamps earlier than the occurrence time of the sensitive behavior (only retaining chronologically valid records of injection before behavior). For example, when process B triggers a sensitive behavior at time T2, only extract the injection records for process B before that (T1 < T2). This mechanism excludes interference data of unrelated processes or lagged injections through spatio-temporal correlation, forming a highly relevant record subset to be matched.

[0095] Step S320: Traverse all injection operation records in the record subset and perform an address space inclusion determination operation. When there is at least one value of the instruction pointer (IP) in the call stack address sequence within the corresponding address range of the injection operation record, it is determined that the instruction pointer falls into the memory address area written by the source process to the target process.

[0096] Perform an address space inclusion determination by traversing each injection operation record in the record subset: First, calculate the injection memory range (from the start address to the end address, for example, the start address (0x000002079C950000) and the end address (start address + write length = 0x000002079C951000)); then compare the call stack sequence of the behavior unit to be matched address by address (such as [0x77F960AC, 0x000002079C95034D,...]). If there is at least one value of the instruction pointer (IP) falling within the address range of a certain injection (for example, 0x000002079C95034D is within the range of [0x000002079C950000, 0x000002079C951000]), it is determined that the execution path of this sensitive behavior contains the injected code. This determination relies on a bit comparison and interval inclusion algorithm (logical expression: if(IP >= StartAddr && IP < StartAddr + Length)) to achieve nanosecond-level efficient matching and accurately associate the behavior source to the injecting process.

[0097] Step S330: Among several injection operation records that meet the conditions of the address space inclusion determination operation, identify the source process identifier of the injection operation record with the earliest timestamp as the malicious injection source of the current sensitive behavior operation.

[0098] When there are multiple injection records that meet the address inclusion conditions (such as both process A1 and A2 injecting code into process B), adopt the principle of earliest injection first: Screen out the injection record with the earliest timestamp (such as process A1 injecting at time T0), and identify its source process identifier (the PID of A1) as the malicious injection source of the current sensitive behavior. The attack chain logic is that the earliest injector is most likely the initial attacker, avoiding attribution confusion caused by multiple injections. The determination result is output to the security alert engine to generate an accurate alert containing the source process ID (such as "Process A1 executes file forgery by injecting into process B").

[0099] By employing a three-tiered analysis approach—spontaneous and spatial constraint filtering, address range inclusion determination, and tracing the earliest injection source—precise attribution of cross-process malicious behavior is achieved. A physical evidence chain between the injected code and sensitive behavior is established using address space inclusion relationships (e.g., instruction pointers falling into the injection memory range), verifying the behavior's attribution at the binary level. Combined with a timing priority strategy, the initial attack source is pinpointed, resolving source ambiguity in multi-process injection scenarios. Ultimately, the traditional security alert is upgraded from "process B has encountered an anomaly" to "process A has injected into process B to perform malicious operations," completely resolving the core flaw of the background technology: "untraceable source of behavior."

[0100] Further, step S310, which involves obtaining a subset of records from the injection operation record based on the target process identifier and capture timestamp in the behavior unit to be matched, includes:

[0101] Step S311: Construct a key / value pair structure for injection operation record storage area in the kernel-mode non-paged memory area, where the key is the target process identifier (Destination Process ID) and the value is a linked list of injection operation records arranged in ascending order of timestamps.

[0102] A key-value pair storage area for injection operation records is constructed in the kernel-mode non-paged memory region. The physical address continuity of non-paged memory ensures that critical data remains accessible during interrupt handling, avoiding latency and uncertainty caused by paging. The key is designed as the Destination Process ID, directly linking to the uniqueness of the injected process. Values ​​are arranged in ascending order by timestamp, using dynamic node addition and deletion for efficient timing management. This avoids the capacity limitations of fixed arrays and maintains the timing logic chain through singly linked list pointers, providing underlying support for subsequent time-window-based retrieval. The storage area is built at the system driver layer, isolated from user space, ensuring the integrity and tamper resistance of monitoring data.

[0103] Step S312: Using the target process identifier in the behavior unit to be matched as the retrieval key, extract all injection operation records associated with the target process identifier from the injection operation record storage area to form an initial record set.

[0104] Using the target process identifier of the behavior unit to be matched as the retrieval key, extract the associated record set from the injection operation record storage area; rely on the hash mapping mechanism of key-value pairs to achieve fast positioning with a time complexity of nearly O(1), and directly hit the historical injection operation set of the target process. The extracted initial record set completely retains all cross-process write operations (such as NtWriteVirtualMemory calls) during the life cycle of the target process, covering key metadata such as the source process ID, write address, size, and precise timestamp, providing an original data pool for behavior tracing, ensuring that subsequent analysis is strictly limited to the context of the same target process, and avoiding cross-process interference.

[0105] Step S313, traverse the initial record set and filter out the injection operation records whose timestamps are earlier than the capture timestamp of the behavior unit to be matched.

[0106] Traverse the initial record set and strictly filter out the records whose timestamps are earlier than the capture timestamp of the behavior unit to be matched; based on the logic that injection precedes behavior: malicious code needs to be written into the target process memory first before subsequent sensitive behaviors can be triggered. Through time window filtering (t_inject < t_behavior), exclude the invalid injection records generated after the target behavior occurs, ensuring that only the candidate injection operations that may trigger the behavior are retained. The timestamp comparison uses a high-precision timer in the kernel state (such as KeQueryPerformanceCounter) to achieve microsecond-level timing determination, ensuring the validity premise of behavior tracing at the logical level.

[0107] Step S314, perform an address space validity check on the filtered injection operation records, and only retain the injection operation records whose defined address range by the start address of the written memory and the written size is valid within the virtual address space of the target process and has not been released.

[0108] Perform an address space validity check on the records filtered by timing, and verify the survival status of the injection memory range (start address to start address + written size) in the virtual address space of the target process. Through the memory management interface (such as MmIsAddressValid), confirm that this range has not been released or swapped out of physical memory, and still belongs to the legal private space of the target process. For countermeasures against malware, attackers can quickly release the injection area to avoid detection. A failed check indicates that the injected code has been cleared and cannot be associated with subsequent behaviors. By dynamically tracking the memory status, ensure that only the injection records in the active executable code area are retained, eliminating the source of false positives.

[0109] Step S315, reorganize the injection operation records that pass the check in ascending order of timestamps to generate a dynamic record subset for address space matching.

[0110] Reorganize the verified injection records in ascending order of timestamp to generate a final dynamic record subset for address matching. The ascending order establishes a matching order with recency priority, optimizing the retrieval efficiency; the dynamic feature reflects the real-time memory state feedback, ensuring that the subset only contains valid, legal, and chronologically reasonable injection records. This subset serves as the input for step S320, providing an accurate and lightweight data source for stack address range matching and avoiding the performance loss caused by traversing all records.

[0111] Construct a high-confidence injection behavior record subset through four progressive processes: kernel-mode key-value storage, process context isolation, chronological causal filtering, and dynamic address verification. On the premise of ensuring nanosecond-level matching efficiency, completely eliminate the interference of invalid, expired, or adversarial injection records, enabling subsequent address space matching to accurately lock the real injection source process (such as process A) that triggers sensitive behaviors, fundamentally solving the problem of distorted alarm information caused by the traditional solution's inability to distinguish between the self-owned code and injected code of process B, and achieving precise traceability of the source of malicious behaviors.

[0112] Furthermore, the operation of determining the inclusion of the execution address space in step S320 includes:

[0113] Step S321, determine whether there is at least one value of the instruction pointer (IP) in the call stack address sequence within the address range from the starting virtual address (BaseAddress) to the ending virtual address of the injection operation record. Here, the ending virtual address is the sum of the starting virtual address and the written data length (BufferLength).

[0114] Verify the code source of sensitive behaviors through the address space attribution of the instruction pointer (IP). When the target process (such as process B) triggers a suspicious behavior, the system captures its call stack address sequence (i.e., the set of memory addresses of the code execution path). For each injection record in the dynamic record subset (such as the code segment written from process A to process B), calculate its physical memory range: from the starting virtual address (BaseAddress) to the ending virtual address (BaseAddress + BufferLength), forming a continuous address space range. By traversing each IP value in the call stack (representing the instruction position during code execution), use a bit comparison algorithm (such as IP >= BaseAddress && IP < BaseAddress + BufferLength) to determine whether each address falls within this injection range one by one. If there is at least one IP that hits this range, it proves that the execution flow of the current sensitive behavior contains the injected code segment, confirming at the computer architecture level that this behavior is actually triggered by the injection source (such as process A), rather than the self-owned code of the target process.

[0115] Based on instruction-level address space matching, this approach overcomes the limitations of traditional solutions that rely solely on overall process behavior analysis. By precisely correlating the instantaneous execution address of sensitive behaviors with historical injected memory ranges, it empirically demonstrates the causal relationship of malicious code execution at the binary level. This elevates the granularity of behavior source tracing from the process level to the code block level, completely resolving the misjudgment problem caused by the simultaneous presence of both proprietary and injected code in the target process (e.g., whitelisted process B). This ensures that alert information always points to the true malicious initiator (e.g., process A), and the judgment process relies on address comparison instructions natively supported by the processor to achieve nanosecond-level efficiency, providing underlying technical support for real-time threat tracing.

[0116] Accordingly, please refer to Figure 2 A second aspect of this invention provides a Windows system cross-process malicious behavior detection device, which performs cross-process malicious behavior detection based on the above-described Windows system cross-process malicious behavior detection method, including:

[0117] The memory monitoring module 1 is used to monitor user-mode programs' calls to the cross-process memory write API by hooking the system service scheduling table or filtering the driver in the Windows system. When it detects that the source process is performing a memory write operation to the target process, it records the injection operation record containing the source process identifier, the target process identifier, the starting address of the memory to be written, and the size of the write operation.

[0118] Address call module 2 is used to obtain the thread call stack address sequence corresponding to the sensitive behavior operation in real time when the target process is detected to be performing a predefined sensitive behavior operation. The sensitive behavior operation includes at least one of the following: creating a fake system file in the system directory, modifying a key system registry key, or initiating a malicious network connection.

[0119] The behavior determination module 3 is used to compare the thread call stack address sequence with the injection operation record. If at least one instruction address in the call stack falls within the memory address range written by the source process to the target process, the sensitive behavior operation is determined to constitute a malicious behavior initiated by the source process.

[0120] Accordingly, a third aspect of the present invention provides an electronic device, including: at least one processor; and a memory connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to cause the at least one processor to perform the above-described Windows system cross-process malicious behavior detection method.

[0121] Accordingly, a fourth aspect of the present invention provides a computer-readable storage medium having computer instructions stored thereon, which, when executed by a processor, implement the above-described method for detecting cross-process malicious behavior in a Windows system.

[0122] The embodiments of the present invention aim to protect a method and apparatus for detecting cross-process malicious behavior in Windows systems, which has the following effects:

[0123] 1. By dynamically correlating monitored cross-process memory write operations with real-time call stack analysis of sensitive operations occurring in subsequent target processes, the problem of traditional solutions being able to only alert the target process but not identify the true source of the malicious activity is solved. When sensitive behavior is detected, by determining whether the instruction address in its call stack falls within the previously recorded injection memory range, it is possible to accurately determine that the behavior was caused by the source process that initiated the injection, which significantly improves the accuracy of attack tracing and, in particular, effectively solves the problem of the untraceable source of behavior after malicious code is injected into a trusted process.

[0124] 2. To address the common tactic of malware injecting malicious code into trusted system processes to bypass security detection, this solution proposes a proactive defense mechanism based on memory address space matching. By capturing sensitive behaviors in real time at the kernel level to obtain precise call stack information, and combining this with historical injection operations, it can clearly identify that even malicious behaviors executed within trusted processes originate from external malicious injection source processes. This breaks the attacker's strategy of using the system's trust in whitelisted processes to conceal their own behavior, filling a critical gap in security defense for tracing the source of malicious injection behaviors within whitelisted processes.

[0125] 3. Automatically clean up related memory injection records upon target process exit, effectively preventing resource waste caused by the accumulation of invalid data. Simultaneously, employing an efficient storage structure combined with address space validity verification ensures that during behavior source matching, only a small number of valid and relevant records require rapid address range comparison. This optimization keeps the overhead of core matching operations at a low and predictable level, guaranteeing the system's real-time responsiveness under high load scenarios. Furthermore, by operating on critical data in the kernel's non-paged memory area, it avoids the latency risks that memory paging might cause, thereby maintaining the stability of the entire system.

[0126] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0127] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0128] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0129] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0130] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit it. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the specific implementation of the present invention. Any modifications or equivalent substitutions that do not depart from the spirit and scope of the present invention should be covered within the protection scope of the claims of the present invention.

Claims

1. A method for detecting cross-process malicious behavior in Windows systems, characterized in that, Includes the following steps: By hooking the system service scheduler table or filtering the driver in the Windows system, the system monitors the user-mode program's calls to the cross-process memory write API. When it detects that the source process is performing a memory write operation to the target process, it records the injection operation record containing the source process identifier, the target process identifier, the starting address of the memory to be written, and the size of the write operation. When the target process is detected to be performing a predefined sensitive behavior operation, the thread call stack address sequence corresponding to the sensitive behavior operation is obtained in real time. The sensitive behavior operation includes at least one of the following: creating a fake system file in the system directory, modifying a key system registry key, or initiating a malicious network connection. The thread call stack address sequence is compared with the injection operation record. If at least one instruction address in the call stack falls within the memory address range written by the source process to the target process, the sensitive behavior operation is determined to constitute a malicious behavior initiated by the source process. When a memory write operation from the source process to the target process is detected, an injection operation record is recorded, including the source process identifier, the target process identifier, the starting address of the memory write, and the write size. By hooking the system service scheduler or loading a filter driver, the user-mode program's calls to the cross-process memory write API are intercepted at the Windows system kernel layer; When the cross-process memory write API is detected to be called, its call parameters are captured and parsed in real time. The call parameters include at least: the source process identifier that initiates the write, the target process identifier that is being written to, the starting virtual address of the memory to be written in the target process, and the length of the data to be written. The call parameters are associated with the current system timestamp to generate a structured injection operation record and store it in the kernel-mode storage area; When the target process is detected to have exited, all injection operation records associated with the target process are cleaned up.

2. The method for detecting cross-process malicious behavior in Windows systems according to claim 1, characterized in that, When a sensitive behavior operation is detected to be performed by a target process, the sequence of thread call stack addresses corresponding to the sensitive behavior operation is obtained in real time, including: The system behavior of the target process is intercepted in real time by the kernel-mode driver. When the target process is detected to be performing a predefined sensitive behavior operation, the thread performing the sensitive behavior operation is stopped and a call stack capture instruction is triggered. Perform a stack backtracking operation on the thread performing the sensitive behavior operation, extract the instruction pointers of several stack frames from low to high call level, and obtain the thread call stack address sequence; Based on the call stack address sequence, sensitive operation type identifier, and capture timestamp, a matching behavior unit is generated. The matching behavior unit is used to perform address space matching with the injection operation record.

3. The method for detecting cross-process malicious behavior in Windows systems according to claim 2, characterized in that, The method involves intercepting the system behavior of the target process in real time via a kernel-mode driver. When the target process is detected to be performing a predefined sensitive action, the thread executing the sensitive action is stopped and a call stack capture instruction is triggered, including: Register at least one system behavior monitoring point in the kernel-mode driver. The monitoring point is associated with a preset sensitive operation type identifier, including file system monitoring point, registry operation monitoring point and network connection monitoring point. When the target process triggers any system behavior monitoring point, the behavior feature parameters of the current operation are extracted. The behavior feature parameters include: file operation path, registry key path or network connection destination IP and port. The behavior feature parameters are matched with the preset sensitive behavior feature rule base in real time. If a high-risk sensitive rule is matched, a sensitive operation type identifier is generated. When generating a sensitive operation type identifier, the processor context of the thread executing the current operation is saved to the kernel-mode non-paged memory area; Based on the thread identifier and the associated sensitive operation type identifier, a call stack capture instruction is generated and passed to the stack backtracking module.

4. The method for detecting cross-process malicious behavior in Windows systems according to claim 2, characterized in that, Before generating the matching behavior unit based on the call stack address sequence, sensitive operation type identifier, and capture timestamp, the method further includes: Before generating the behavior unit to be matched, it is verified that all instruction pointers in the call stack address sequence are within the user-mode virtual address space of the target process. If a kernel-mode address exists, the call stack address sequence is discarded.

5. The method for detecting cross-process malicious behavior in Windows systems according to claim 3, characterized in that, Comparing the thread call stack address sequence with the injection operation record includes: Based on the target process identifier and capture timestamp in the behavior unit to be matched, a subset of records is obtained from the injection operation record. The target process identifier of the subset of records is the same as the target process identifier in the current behavior unit to be matched, or the timestamp of the subset of records is earlier than the capture timestamp of the behavior unit to be matched. Traverse all injection operation records in the record subset and perform an address space inclusion determination operation. When there is at least one instruction pointer value in the call stack address sequence that is within the address range of the corresponding injection operation record, determine that the instruction pointer falls into the memory address region written by the source process to the target process. From a number of injection operation records that meet the address space inclusion determination operation conditions, the source process identifier of the injection operation record with the earliest timestamp is identified as the malicious injection source of the current sensitive behavior operation.

6. The method for detecting cross-process malicious behavior in Windows systems according to claim 5, characterized in that, The step of obtaining a subset of records from the injection operation record based on the target process identifier and capture timestamp in the behavior unit to be matched includes: In the kernel-mode non-paged memory area, an injection operation record storage area with a key / value pair structure is constructed, wherein the key is the target process identifier and the value is a linked list of injection operation records arranged in ascending order of timestamp; Using the target process identifier in the target behavior unit as the retrieval key, extract all injection operation records associated with the target process identifier from the injection operation record storage area to form an initial record set; Traverse the initial record set and filter out injection operation records whose timestamps are earlier than the capture timestamps of the behavior units to be matched; The filtered injection operation records are subjected to address space validity verification. Only injection operation records that are valid and have not been released within the virtual address space of the target process are retained, based on the address range defined by the memory start address and the write size. The verified injection operation records are reassembled in ascending order of timestamps to generate a dynamic subset of records for address space matching.

7. The method for detecting cross-process malicious behavior in Windows systems according to claim 5, characterized in that, The execution address space inclusion determination operation includes: Determine whether there exists at least one instruction pointer in the call stack address sequence whose value falls within the address range from the start virtual address to the end virtual address of the injection operation record; The termination virtual address is the sum of the starting virtual address and the length of the written data.

8. A device for detecting cross-process malicious behavior in Windows systems, characterized in that, Cross-process malicious behavior detection based on the Windows system cross-process malicious behavior detection method as described in any one of claims 1-7 includes: The memory monitoring module is used to monitor user-mode programs' calls to cross-process memory write APIs by hooking the Windows system service scheduling table or filtering drivers. When it detects that the source process is performing a memory write operation to the target process, it records the injection operation record containing the source process identifier, target process identifier, memory start address, and write size. The address invocation module is used to obtain the thread call stack address sequence corresponding to the sensitive behavior operation in real time when the target process is detected to be performing a predefined sensitive behavior operation. The sensitive behavior operation includes at least one of the following: creating a fake system file in the system directory, modifying a key system registry key, or initiating a malicious network connection. The behavior determination module is used to compare the thread call stack address sequence with the injection operation record. If at least one instruction address in the call stack falls within the memory address range written by the source process to the target process, the sensitive behavior operation is determined to constitute a malicious behavior initiated by the source process.

9. An electronic device, characterized in that, include: At least one processor; And a memory connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to cause the at least one processor to perform the Windows system cross-process malicious behavior detection method as described in any one of claims 1-7.

Images