A method and system for locating processes in blind spots of security system monitoring

Abstract

This application belongs to the field of network security technology and relates to a method and system for locating processes in blind spots of security system monitoring. The method for locating processes in blind spots of security system monitoring includes: in the target system, calling an application programming interface to generate a transient image containing active process information; traversing the transient image using pre-built regular expression rules to obtain injection module features associated with security products from a structured AV / EDR feature library; obtaining the file paths and file contents of the process list and performing a first enumeration matching and verification with pre-stored path pattern rules and summaries in the injection module features to obtain the first enumeration matching result; performing a second enumeration in the transient image to obtain the second enumeration matching result; performing differential matching comparison to obtain differential initial processes; and analyzing memory mitigation strategies to form target processes, resulting in a target process list.

Description

Technical Field

[0001] This application belongs to the field of network security technology, and in particular relates to a process location method and system for blind spots in security system monitoring. Background Technology

[0002] In cybersecurity offense and defense, modern endpoint security products build multi-layered defense systems. These systems use kernel-level monitoring technology to intercept processes such as process creation, DLL loading, and memory operations in real time. Combined with behavioral pattern analysis and signature matching mechanisms, they implement comprehensive monitoring of attack chain links such as code injection and privilege escalation. Their monitoring scope has extended from user-space processes to low-level operations such as thread scheduling and memory allocation, significantly reducing the stealth of traditional attack techniques.

[0003] Currently, attackers primarily rely on two types of techniques to bypass monitoring:

[0004] Static feature matching technology

[0005] Based on a predefined whitelist of "trusted processes" (including system authentication processes and common applications), injection targets are filtered through process enumeration and path matching. Although this method is simple to operate, it has significant static limitations: it cannot adapt to dynamic policy updates of security products (such as hot update mechanisms that adjust the whitelist), and it has poor cross-environment compatibility.

[0006] Dynamic memory analysis technology

[0007] Targets are filtered by scanning process memory attributes (such as detecting readable and writable execution regions and ASLR / DEP status). While it can adapt to system configurations in real time, it has a one-sided flaw: it only focuses on memory protection status, ignores real-time injection monitoring of security components, and frequent calls to high-risk APIs (such as memory scans) will trigger abnormal behavior detection.

[0008] Both types of technologies face exposure risks: traditional tools rely on processes such as enumeration and memory read / write operations to generate distinctive system call sequences, which security products can identify through machine learning models (such as high-frequency process scanning). Furthermore, collaborative operation of multiple tools generates scattered but correlated log events, further increasing the probability of exposure.

[0009] Therefore, there is an urgent need for a process location method and system for blind spots in security system monitoring. Summary of the Invention

[0010] Therefore, it is necessary to provide a process location method and system for blind spots in security system monitoring to address the aforementioned technical problems.

[0011] Firstly, this application provides a method for locating processes in blind spots of security system monitoring, including:

[0012] Acquire security products and security-related information in the local dynamic analysis environment, and build a structured AV / EDR feature library;

[0013] In the target system, the application programming interface is called to generate a transient image containing active process information, and the transient image is traversed through the constructed regular expression rules to obtain the injection module features associated with the security product in the structured AV / EDR feature library;

[0014] Obtain the file paths and file contents of the process list in the target system, and perform a first enumeration matching and verification with the path pattern rules and digests pre-stored in the features of the injection module to obtain the first enumeration matching result.

[0015] In the transient image, the module list of the current process is enumerated a second time, and the injected module features are applied again for matching and verification to obtain the second enumeration matching result;

[0016] The first enumeration matching result and the second enumeration matching result are compared with the process list of the current security product to obtain a differentiated initial process;

[0017] The initial process is analyzed for memory mitigation strategies to identify processes that have not been injected by the regular monitoring module and have opened the dynamic code loading interface, thus forming target processes and obtaining a list of target processes.

[0018] In some feasible methods, the steps of acquiring security products, analyzing security-related information in a local dynamic environment, and constructing a structured AV / EDR feature library include:

[0019] The core information from public intelligence platforms and local dynamic analysis environments is obtained, formatted, and typical naming patterns are abstracted by combining wildcards and regular expressions to obtain standardized process names.

[0020] The directory paths in the core information are subjected to directory structure feature extraction to obtain standardized paths;

[0021] Perform a hash calculation on the file name in the core information to obtain the hash digest of the file name;

[0022] The hash digests of the normalized process names, normalized paths, and file names are stored in the form of structured entries to obtain a structured AV / EDR feature library.

[0023] In some feasible methods, the step of calling the application programming interface in the target system to generate a transient image containing active process information, and traversing the transient image using pre-constructed regular expression rules to obtain the injection module features associated with the security product in a structured AV / EDR feature library, includes:

[0024] In the target system, the API function interface in the system API is called to generate a snapshot containing information about all active processes;

[0025] Iterate through all process entries in the snapshot containing all active process information, and read the key fields from the structure of the process entry to obtain the executable file name key field and the process number key field.

[0026] Based on the feature matching engine, the key fields of the executable file name and process number are compared one by one with the constructed regular expression rules to obtain the comparison results;

[0027] If the comparison result is not empty, it is determined that there is a known security product process in the target system;

[0028] Based on the known progress of security products, the relevant content is retrieved from the structured AV / EDR feature library to obtain the features of the injected module.

[0029] In some feasible methods, the step of obtaining the file paths and file contents of the process list in the target system, and performing a first enumeration matching and verification with the path pattern rules and digests pre-stored in the injection module features to obtain the first enumeration matching result includes:

[0030] Obtain the handle of the process list in the target system, and determine the handle list of loaded modules based on the handle;

[0031] Based on the list of handles of the loaded modules, determine the file path and file content of the modules;

[0032] The file path and file content of the module are matched and verified against the pre-stored path pattern rules and digest in the features of the injection module for the first enumeration, and the first enumeration matching result is obtained.

[0033] In some feasible methods, the step of performing a second enumeration of the module list of the current process in the transient image, and again applying the injected module features for matching and verification to obtain the second enumeration matching result includes:

[0034] In the transient image, for the module list of the current process, the file path and file content corresponding to each module are obtained;

[0035] Based on the file path and file content corresponding to each module, a second enumeration matching and verification is performed with the pre-stored path pattern rules and digest in the features of the injection module to obtain the second enumeration matching result.

[0036] In some implementable methods, the step of performing a differential matching comparison between the first enumeration matching result and the second enumeration matching result and the process list of the current security product to obtain a differential initial process includes:

[0037] The first enumeration matching result and the second enumeration matching result are sequentially verified to obtain the dual module enumeration mechanism;

[0038] For each process of the current security product, a dual module enumeration mechanism is executed. When no monitoring module is found in either enumeration, a differentiated initial process is obtained.

[0039] In some feasible methods, the steps of analyzing the initial process for memory mitigation strategies, identifying processes that have not been injected by conventional monitoring modules and have exposed dynamic code loading interfaces, forming target processes, and obtaining a list of target processes include:

[0040] Based on the modification strategy of the initial process, determine the dynamic code execution protection strategy of the initial process;

[0041] If the dynamic code execution protection strategy of the initial process contains a contiguous executable memory region and a dynamic code loading interface, a target process is formed;

[0042] Based on the multiple target processes, the target process list is obtained.

[0043] Secondly, this application provides a process location system for blind spots in security system monitoring, applied to the aforementioned process location method for blind spots in security system monitoring. The system includes:

[0044] The building unit is used to acquire security products and security-related information in the local dynamic analysis environment, and to build a structured AV / EDR feature library;

[0045] The generation unit is used to call the application programming interface in the target system to generate a transient image containing active process information, and to traverse the transient image through the constructed regular expression rules to obtain the injection module features associated with the security product in the structured AV / EDR feature library.

[0046] The first enumeration unit is used to obtain the file path and file content of the process list in the target system, and to perform the first enumeration matching and verification with the path pattern rules and digests pre-stored in the features of the injection module to obtain the first enumeration matching result.

[0047] The second enumeration unit is used to enumerate the module list of the current process a second time in the transient image, and apply the injected module features again for matching and verification to obtain the second enumeration matching result;

[0048] The first enumeration matching result and the second enumeration matching result are compared with the process list of the current security product to obtain a differentiated initial process;

[0049] The initial process is analyzed for memory mitigation strategies to identify processes that have not been injected by the regular monitoring module and have opened the dynamic code loading interface, thus forming target processes and obtaining a list of target processes.

[0050] Thirdly, this application provides a computer storage medium storing a computer program thereon, wherein the computer program, when executed by a processor, implements the steps of the aforementioned process location method for blind spots in security system monitoring.

[0051] Fourthly, this application provides a computer program that, when executed by a processor, implements the steps of the aforementioned process location method for blind spots in security system monitoring.

[0052] Beneficial Effects: This method for process localization in blind spots of security system monitoring acquires security product and security-related information from the local dynamic analysis environment, and constructs a structured AV / EDR feature library. In the target system, an application programming interface (API) is invoked to generate a transient image containing active process information. The transient image is then traversed using pre-constructed regular expression rules to obtain injection module features associated with security products from the structured AV / EDR feature library. The file paths and contents of the process list in the target system are obtained and matched and verified against pre-stored path pattern rules and summaries in the injection module features, yielding the first enumeration matching result. In the transient image, the module list of the current process is enumerated a second time, and the injection module features are applied again for matching and verification, yielding the second enumeration matching result. The first and second enumeration matching results are compared with the process list of the current security product for differential matching to obtain differentiated initial processes. Memory mitigation strategies are analyzed for the initial processes to identify processes that have not been injected by conventional monitoring modules and have opened dynamic code loading interfaces, forming target processes and obtaining a target process list. Using the above methods, a system can be built that can efficiently and covertly locate process blind spots that are not yet covered by endpoint protection products in complex security environments. Attached Figure Description

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

[0054] Figure 1 This is a flowchart of a process location method for blind spots in security system monitoring, as shown in one embodiment.

[0055] Figure 2 This is a flowchart illustrating the process lookup process for a process location method targeting blind spots in security system monitoring, as described in one embodiment.

[0056] Figure 3 This is a flowchart illustrating the feature library construction process of a process localization method for blind spots in security system monitoring, as shown in one embodiment.

[0057] Figure 4 This is a flowchart illustrating a process matching method for locating blind spots in security system monitoring, as described in one embodiment.

[0058] Figure 5 This is an injection detection flowchart of a process location method for blind spots in security system monitoring, as shown in one embodiment.

[0059] Figure 6 This is a memory detection flowchart of a process location method for blind spots in security system monitoring, as shown in one embodiment. Detailed Implementation

[0060] To facilitate understanding of this application, a more complete description will be provided below with reference to the accompanying drawings, which illustrate embodiments of the present application. However, the present application can be implemented in many different forms and is not limited to the embodiments described herein. Rather, these embodiments are provided so that the disclosure of this application will be thorough and complete.

[0061] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The term "and / or" as used herein includes any and all couplings of one or more of the associated listed items.

[0062] It is understood that the terms “first,” “second,” etc., used in this application may be used herein to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish one element from another.

[0063] The following explanations of some terms used in this application are provided to aid in understanding the application:

[0064] SHA-256, Secure Hash Algorithm 256-bit, is a cryptographic hash function belonging to the SHA-2 family. Its core function is to convert input data of arbitrary length (such as files or messages) into a fixed-length 256-bit (32-byte) hash value (usually represented as a 64-bit hexadecimal string) through irreversible computation.

[0065] AV, Antivirus software, is a computer program used to prevent, detect, and remove malware; it is commonly known as antivirus software.

[0066] EDR, or Endpoint Detection and Response, is an endpoint security solution. It logs behavior on endpoints, uses data analytics and context-based information detection to detect anomalies and malicious activity, and records data about malicious activity, enabling security teams to investigate and respond to incidents. Endpoints can be PCs or laptops, servers, cloud systems, mobile devices, or IoT devices, etc. EDR solutions typically provide threat searching, detection, analysis, and response capabilities.

[0067] The CreateToolhelp32Snapshot interface is an API function provided by the Windows system used to create a read-only snapshot of the current system state. This snapshot can capture information about system resources such as processes, threads, modules (DLLs), and heap memory, essentially "freezing" the system state at a certain moment for subsequent analysis or traversal by the program.

[0068] A DLL, or Dynamic Link Library, is a method used by Microsoft to implement the concept of shared function libraries in the Windows operating system. It contains code, data, and resources that can be dynamically loaded and used by programs.

[0069] DLL injection is a special programming technique involving computer information security. It can force a process to load a dynamic link library to run specified code (often malicious code) within its private address space. A common method of DLL injection is to overwrite a program's original DLL library with an external DLL library, aiming to achieve results not intended by the program's author. For example, the injected code can hook system messages or system calls to achieve dangerous purposes such as reading the contents of a password field, which cannot be achieved by general programming methods.

[0070] A handle is a resource access credential in the Windows operating system; essentially, it is an index identifier for the kernel object table.

[0071] A hook is a computer programming term referring to various techniques used to modify or extend the behavior of an operating system, application, or other software components by intercepting function calls, message passing, and event passing between software modules. It involves the code that processes the intercepted function calls, events, and messages.

[0072] API, or Application Programming Interface, is a connection between computers or computer programs. It is a software interface that provides services to other software.

[0073] ASLR, or Address Space Layout Randomization, is a computer security technique used to prevent the exploitation of memory corruption vulnerabilities. It prevents attackers from reliably jumping to specific memory locations to exploit functions by randomly placing the address space of a process's critical data regions.

[0074] DEP, or Data Execution Prevention, is a set of hardware and software technologies that perform additional checks on memory to help prevent malicious code from executing on a system.

[0075] In cybersecurity attack and defense, attackers need to use technical means to verify the blind spots of the defense system. Modern endpoint security products have built multi-layered defense systems based on kernel-level monitoring technology. Security solutions, represented by endpoint detection and response systems, intercept key behaviors such as process creation, dynamic link library loading, and memory operations in real time. Combined with behavioral pattern analysis and signature matching mechanisms, they implement three-dimensional monitoring of code injection, privilege escalation, and persistent persistence in the attack chain. These systems not only cover the routine operations of user-space processes but also deeply monitor key system components through kernel callback mechanisms. Their monitoring scope has extended from process lifecycle management to low-level operations such as thread scheduling and memory allocation strategies. This technological evolution has significantly reduced the stealth of traditional attack techniques, and attackers face extremely high exposure risks when simulating high-level threat behaviors. Against this backdrop, how to locate process blind spots outside the monitoring coverage of security products has become a key technical challenge in breaking through modern defense systems.

[0076] While security product monitoring mechanisms are becoming increasingly sophisticated, their actual coverage is constrained by multiple objective conditions. The complexity of operating system kernels and vendor compatibility requirements force security vendors to balance security and system stability when designing monitoring strategies. For example, core processes involving hardware driver interaction, virtualization components, or underlying scheduling services may be excluded from real-time monitoring due to resource preemption risks or critical function protection requirements; some high-privilege third-party applications may be included in whitelists and subject to lenient monitoring policies due to compatibility with older software versions or special operating environments; furthermore, version iterations of security components, hot policy updates, or emergency configuration adjustments may dynamically change the scope of monitoring rules, creating temporary blind spots with significant timeliness differences. These blind spots theoretically provide attackers with covert operational space, but in actual attack and defense scenarios, due to the lack of systematic and dynamic location methods, attackers find it difficult to quickly identify and verify the exploitability of processes within these blind spots.

[0077] The core contradiction in the current technological field lies in the fact that the monitoring strategies of security products are highly dynamic and scenario-dependent, while traditional location methods lack the ability to perceive changes in these strategies in real time. Furthermore, the defense mechanisms of modern security products have evolved from single-behavior detection to multi-dimensional correlation analysis. If the system call sequences, memory access patterns, or process traversal behaviors generated during the location process do not conform to the typical characteristics of legitimate applications, they may directly trigger the abnormal alarm mechanisms of security components, thus exposing the attack intent within the location operation itself.

[0078] This application focuses on constructing a blind zone process localization system that dynamically adapts to changes in the security environment, integrates multi-dimensional process state data, and possesses stealth protection. Its core objective is to solve the following technical problems: how to covertly collect multi-dimensional state data such as process permission levels, module loading integrity, and memory region protection attributes through legitimate system call chains or low-level interfaces, thereby constructing an accurate blind zone determination model; and how to verify the actual usability of process memory strategies in complex system environments, such as identifying processes that have not enabled unsigned module loading restrictions, possess readable and writable execution memory regions, or have not enabled stack protection mechanisms. Through the deep integration of layered and progressive detection logic and covert operation techniques, this application aims to break through the technical barriers of existing security monitoring mechanisms, providing attackers with an efficient, reliable, and resistant-to-detect blind zone localization solution.

[0079] In the field of cybersecurity, the offensive and defensive battles have always revolved around evasion and detection techniques. Attackers primarily employ two types of methods to bypass the monitoring of security products: process injection techniques based on static feature matching and policy filtering techniques based on dynamic memory analysis.

[0080] The core of injection techniques based on static feature matching lies in the attacker's pre-construction of a "trusted process" whitelist, typically including operating system authentication processes and widely used third-party application processes. This whitelist is used to filter injection targets, evading monitoring and protection. During implementation, the attack tool first enumerates the executable filenames and paths of all processes in the system, then compares them one by one with a predefined list or matching rules. If a match is found, code loading or function hooking is executed within that process, achieving the goal of running malicious logic within a trusted context. The advantage of static matching lies in its simple logic and ease of implementation: once the list is built, the entire process requires only a few system calls to complete the filtering and injection, making it suitable for rapid deployment and integration with automated toolchains. Furthermore, this method often relies on static attributes such as file paths, process names, and signing certificates to determine the trustworthiness of the target, making the injection behavior appear legitimate and difficult for detection engines based on dynamic behavior analysis to capture.

[0081] Dynamic memory analysis focuses on evaluating the memory protection status of target processes at runtime to select processes that have enabled writable and executable memory regions or have not enabled security policies such as Address Space Layout Randomization (ASLR) for injection. This process generally includes scanning process memory region attributes, detecting memory page permissions, and identifying stack execution protection mechanisms. First, the attack program opens handles to active processes in the system one by one and queries their memory allocation information. By analyzing the read, write, and execute permission flags of each memory block, it filters out usable space with read, write, and execute permissions simultaneously. Subsequently, it may further detect the enabling status of protection mechanisms such as ASLR and Data Execution Protection (DEP) to ensure that the injected code can execute normally and persist in the process memory. Compared with static methods, dynamic analysis can adapt to environmental differences and generate target lists in real time for different system configurations, making attacks more flexible and targeted. However, its limitations are also significant: it only focuses on memory protection status while ignoring real-time monitoring coverage of security components, and frequent high-risk API calls can easily trigger abnormal behavior detection. For example, even if a process does not have a memory protection policy enabled, if it has been injected into the monitoring module by a security component, the injection operation will still be intercepted in real time; and large-scale memory scanning behavior itself may be marked as suspicious activity by security products.

[0082] Although both methods have been widely used in attack and defense exercises, they rely on static or single-memory dimension judgments, respectively, but fail to fully integrate the multi-dimensional security posture during process runtime, often only achieving results in specific scenarios. The limitations of existing technologies are mainly reflected in three aspects: static defects, one-sided defects, and exposure defects.

[0083] Static signature matching technology relies heavily on predefined lists of trusted processes, whose updates lag behind the policy iterations of security products. For example, security vendors can dynamically adjust monitoring whitelists through hot update mechanisms, making it difficult for attackers to capture such changes in a timely manner. Furthermore, static lists cannot adapt to cross-environmental differences; the same process may face completely different monitoring intensities in security products from different vendors. While dynamic memory analysis technology can partially solve the policy adaptability problem, its detection dimensions are too singular and one-sided: it only focuses on memory protection status, ignoring key factors such as security component injection monitoring and system trust chain verification.

[0084] Operational exposure risk is another major drawback of existing technologies. Traditional tools rely on high-risk API calls (such as process enumeration and memory read / write) to perform scans, which generate obvious system call traces. Security products can accurately identify attack behaviors by correlating and analyzing features such as API call sequences and operation frequencies. For example, the behavior pattern of performing memory attribute scans on multiple processes in a short period of time can easily trigger machine learning-based anomaly detection models. In addition, the collaborative operation of multiple tools (such as separating process scanning tools from injection tools) generates scattered but correlated log events, further increasing the exposure risk.

[0085] To address the aforementioned issues, this application proposes a technical solution that can adapt to dynamic changes in protection strategies and integrate multi-dimensional process states for comprehensive evaluation. Through in-depth analysis of security product monitoring strategies and system group policies, dynamic adjustment of process filtering conditions is achieved. In a multi-dimensional coupled analysis model, information such as process permission levels, module signature integrity, memory protection configurations, and dynamic code loading restrictions are uniformly evaluated to accurately identify monitoring blind spots. All eligible blind spot processes are efficiently output, providing a solid basis for subsequent security assessments and high-level threat simulations.

[0086] like Figures 1 to 6 As shown, in a first aspect, this application provides a process location method for blind spots in security system monitoring, the method comprising:

[0087] like Figure 3 As shown, S100 acquires security products and security-related information in the local dynamic analysis environment, and builds a structured AV / EDR feature library.

[0088] The construction of the feature library begins with in-depth analysis and feature extraction of the operational behavior of various security protection products, aiming to form a set of rules capable of accurately identifying and distinguishing monitoring processes and their loaded modules (dynamic link library files). The process of building a structured AV / EDR feature library is as follows: data acquisition - generating matching rules - creating structured feature entries - storing and dynamically updating the feature library, such as... Figure 3 .

[0089] Specifically, constructing a structured AV / EDR feature library may include the following steps:

[0090] S101 acquires core information from public intelligence platforms and local dynamic analysis environments, normalizes the format, and abstracts typical naming patterns using a combination of wildcards and regular expressions to obtain standardized process names.

[0091] Specifically, obtain the official websites and vulnerability platforms of security vendors, and extract the naming characteristics of security processes (such as CSFalconService.exe and SentinelAgent.exe). Run EDR / AV products in a sandbox, monitor their process tree behavior, and record process derivation relationships (e.g., the main process csagent.exe loading the monitoring module csa.dll).

[0092] It should be noted that core information of the target product is systematically collected from public intelligence platforms and local dynamic analysis environments, including executable file names, version identifiers, digital signature certificates, and possible injection module path patterns.

[0093] The acquisition method is a public method permitted by the party being acquired.

[0094] Furthermore, to improve the universality and scalability of the rules, during the data preprocessing stage, the format of all process names is normalized, and typical naming patterns are abstracted by combining wildcards and regular expressions. For example, names such as "MySecurityAgent.exe" and "UserMonitor.exe" are uniformly summarized as [A-Za-z]+Agent\.exe or. Monitor.exe ensures that subsequent matching covers naming styles from different manufacturers and versions. It adapts to differences in installation paths and version directories, preventing feature failures due to minor path changes.

[0095] S102, extract the directory structure features from the core information to obtain the standardized path.

[0096] For example, path feature decomposition:

[0097] System directory identifier: Marks the core path of the operating system (such as C:\Windows\System32\, %ProgramFiles%\).

[0098] Vendor directory pattern: Extracting the unique directory characteristics of security software (e.g., C:\Program Files\CrowdStrike\) \).

[0099] Wildcard embedding: Dynamic path segment replacement .

[0100] Such as C:\Program Files\CrowdStrike\CS_1234\bin\csagent.dll;

[0101] Change to: C:\Program Files\CrowdStrike\ \bin\ .dll.

[0102] S103, perform a hash calculation on the file name in the core information to obtain a hash digest of the file name.

[0103] Specifically, the binary content (not the filename) of the module file can be read and a unique digest (such as 7d8e1a2b3c...) can be generated using the SHA-256 algorithm.

[0104] S104. The hash digests of the normalized process name, the normalized path, and the file name are stored in the form of structured entries to obtain a structured AV / EDR feature library.

[0105] Specifically, the structured entries form the organization and storage of security product feature information according to a predefined logical framework. This can be achieved through JSON format, ensuring that the feature library dynamically adapts to security product version iterations, supports hot updates, and allows for auditing of change history.

[0106] In summary, the entire feature library is ultimately stored persistently in a lightweight JSON format, and the update process is strictly managed through a version control system to ensure rapid response to new version releases of major protection products and to achieve real-time compatibility and expansion of new features.

[0107] S200, in the target system, the application programming interface is called to generate a transient image containing active process information, and the transient image is traversed through the constructed regular expression rules to obtain the injection module features associated with the security product in the structured AV / EDR feature library.

[0108] like Figure 4 As shown, the process matching process is as follows: create a process snapshot - traverse process entries - feature matching - obtain feature information.

[0109] Specifically, obtaining the injection module features associated with the security product in the structured AV / EDR feature library may include the following steps:

[0110] S201, in the target system, call the API function interface in the system API to generate a snapshot containing information about all active processes.

[0111] During the target system execution phase, a snapshot containing information about all active processes can be generated by calling API functions in the Windows API (such as the CreateToolhelp32Snapshot interface). For example, the parameter TH32CS_SNAPPROCESS (TH32CS_SNAPPROCESS is a flag parameter in the Windows API used by the CreateToolhelp32Snapshot function, specifying the creation of a system process snapshot for enumerating all currently running processes) ensures a complete capture of the list of running processes in the system.

[0112] The kernel generates a read-only memory image, captures the instantaneous system process state, and returns a snapshot handle (such as 0x00007F) for subsequent operations.

[0113] The snapshot mechanism ensures the consistency of process states and avoids list misalignment caused by process creation / exit during traversal.

[0114] S202, traverse all process entries in the snapshot containing all active process information, and read the key fields from the structure of the process entry to obtain the executable file name key field and the process number key field.

[0115] For example, the Process32First and Process32Next functions (the Process32First and Process32Next functions are core functions in the Windows API used to traverse process snapshots (created by CreateToolhelp32Snapshot). When used together, they read process information one by one in a manner similar to "linked list traversal") can be used sequentially to traverse all entries of the snapshot and read key fields such as szExeFile (executable file name) and th32ProcessID (process ID) from the PROCESSENTRY32 structure.

[0116] Specifically, Process32First is called to obtain the first process information. Next, the PROCESSENTRY32 structure is populated, and Process32Next is called continuously until FALSE is returned. In each round, th32ProcessID and szExeFile are read. Only 2 API calls are needed to traverse the full number of processes.

[0117] S203, based on the feature matching engine, compare the key fields of the executable file name and process number with the constructed regular expression rules one by one to obtain the comparison results.

[0118] Specifically, load pre-compiled regular expressions (e.g.). (Agent|Monitor)\.exe$).

[0119] Perform a match on szExeFile for each process:

[0120] Case insensitive (matches CSAgent.exe). agent\.exe);

[0121] Supports wildcards (CrowdStrike_ .exe matches any version number.

[0122] Output matching results:

[0123] Success: Returns the matching rule name (e.g., CrowdStrike_Pattern_v1);

[0124] Failure: Returns null.

[0125] Based on this, the feature matching engine compares each process name with the constructed regular expression rules one by one.

[0126] It should be noted that regular expression rules are created in advance to obtain pre-constructed regular expression rules. These pre-constructed regular expression rules are then associated with the structured AV / EDR feature library.

[0127] In addition, the constructed regular expression rules can be stored in a structured AV / EDR feature library as needed.

[0128] Specifically, regular expression rules can be created by staff.

[0129] S204, if the comparison result is not empty, then it is determined that there is a known security product process in the target system.

[0130] Specifically, the comparison results are used to make a judgment. If the comparison results indicate that the feature matching engine compares each process name with the constructed regular expression rules one by one, once any rule is matched, it is determined that there is a known AV / EDR security protection product process in the system.

[0131] S205: Based on the known progress of security products, retrieve the associated content from the structured AV / EDR feature library to obtain the injection module features.

[0132] Specifically, based on the identifier information associated with the regular expression rule in the structured AV / EDR feature library, the structured AV / EDR feature library is retrieved. Next, key features of the monitoring module associated with the current security process are extracted from the structured AV / EDR feature library, including:

[0133] Path pattern: wildcard path rules;

[0134] Hash list: A set of SHA-256 hashes of module files that are legally loaded for the purpose of implementing monitoring functions;

[0135] Certificate constraints: Digital signature requirements (e.g., O=CrowdStrike).

[0136] Furthermore, the features of the associated injection modules are retrieved from the structured AV / EDR feature library, laying the foundation for subsequent module loading verification.

[0137] S300, obtain the file path and file content of the process list in the target system, and perform a first enumeration matching and verification with the path pattern rules and digests pre-stored in the injection module features to obtain the first enumeration matching result.

[0138] Step S300 is used to verify whether the target process has loaded the monitoring module (DLL) of the security product, and to identify the security process (such as SecurityAgent.exe) through the process matching stage.

[0139] Specifically, obtaining the first enumeration matching result may include the following steps:

[0140] S301, Obtain the handle of the process list in the target system, and determine the handle list of loaded modules based on the handle.

[0141] Specifically, for the identified monitoring processes, the loading status of the modules within them is precisely checked through a dual module enumeration mechanism.

[0142] For example, the process handle is obtained by calling OpenProcess (a Windows API core function used to obtain the handle of a specified process) with PROCESS_QUERY_INFORMATION privileges, and then the EnumProcessModules function is used to enumerate the list of handles of all loaded modules in the process.

[0143] It should be noted that the system function OpenProcess is called with the PROCESS_QUERY_INFORMATION permission declared (to read process information only, avoiding high-risk operations from triggering alarms).

[0144] For example, the EnumProcessModules function is called, passing in the process handle, to scan the module list structure (PEB structure) in the process's memory.

[0145] Output: Returns an array of module handles (hModules[]), where each handle corresponds to a loaded module (such as the main program DLL or an injected monitoring DLL). Each module handle uniquely corresponds to a loaded module (such as a DLL file), and the array of module handles (hModules[]) contains multiple module handles, so a process corresponds to multiple module handles (1:N relationship).

[0146] When the EnumProcessModules function is called:

[0147] Input: Process handle (pointing to the target process).

[0148] Operation: Traverse the process's module list (maintained by the Windows kernel, recording the base address of all loaded modules).

[0149] Output: Returns an array (hModules[]), where: array length = total number of modules loaded by the process (e.g., 10 DLLs). Each element = a module handle (e.g., [0x7FFA1A2B0000, 0x7FFA0C3A0000, ...]), and each handle points to an independent module.

[0150] Each handle corresponds to a module entity.

[0151] S302, determine the file path and file content of the module based on the handle list of the loaded modules.

[0152] Specifically, file path extraction: Call the GetModuleFileNameEx function (an extended function to get the file name of a module in a specified process, which requires OpenProcess to obtain permissions), pass in the module handle, and parse the complete path of the module on the disk (such as C:\Program Files\Agent\Monitor.dll).

[0153] File content retrieval: The file content is read through the module handle, but only its cryptographic digest value (hash value) is calculated, not the complete content.

[0154] It should be noted that directly reading the file content may trigger behavior monitoring, so only the SHA-256 hash (fixed-length digest, efficient and irreversible) is calculated.

[0155] S303, the file path and file content of the module are matched and verified by the path pattern rules and the digest pre-stored in the features of the injection module for the first enumeration, and the first enumeration matching result is obtained.

[0156] Specifically, in the pre-stored path pattern rules within the injected module features, the path rule matching is as follows:

[0157] Rule type: Wildcard paths pre-stored in the feature library (e.g., ...) \Agent\ The .dll file matches all DLLs in the Agent directory.

[0158] Matching logic: The module path is compared with each rule. If the path matches any rule, it proceeds to the next stage; otherwise, it is marked as a "non-monitored module".

[0159] The hash digest verification of the injected module features is as follows:

[0160] For modules that match paths, the hash value generated from the file content within the module is compared with pre-stored hash values ​​in the feature database. The specific judgment logic is as follows:

[0161] If a match is successful, mark the module as a "monitoring module" (to confirm that the process has been injected);

[0162] When a match fails, the module is marked as an "unmonitored module" (even if the path matches, the content may have been tampered with).

[0163] It should be noted that hash comparison does not involve additional file reading and writing; it only involves in-memory computation, thus circumventing behavioral detection.

[0164] It should also be noted that the purpose of path rules is to quickly filter potential targets (low computational overhead). The purpose of hash digest is to authoritatively verify the authenticity of files (prevent path spoofing). These two steps effectively improve work efficiency and accuracy.

[0165] Finally, through matching and verification, it is determined whether the module is a known monitoring module, resulting in the first enumeration matching result. It should be noted that determining whether a module is a known monitoring module refers to the module in step S302. Each specific module loaded by the process is authenticated, ultimately determining whether it is a monitoring module defined in the signature database.

[0166] like Figure 5 As shown in step S400, in the transient image, the module list of the current process is enumerated for the second time, and the injected module features are applied again for matching and verification to obtain the second enumeration matching result.

[0167] Specifically, obtaining the second enumeration matching result may include the following steps:

[0168] S401, in the transient image, for the module list of the current process, obtain the file path and file content corresponding to each module.

[0169] Specifically, calling CreateToolhelp32Snapshot(TH32CS_SNAPMODULE, pid) (creates a 32-bit process module help snapshot) generates a corresponding module-level snapshot (independent of the process snapshot) for the current process in the snapshot containing active process information corresponding to the transient image.

[0170] For example, the system further calls Module32First and Module32Next to directly extract the module list from the process memory snapshot a second time. That is, Module32First obtains the MODULEENTRY32 structure of the first module, and Module32Next loops until it returns FALSE.

[0171] This creates an anti-hiding design, allowing direct reading of kernel-level snapshots, bypassing user-mode hooks, achieving integrity guarantees, and obtaining the module paths hidden by SSDT hooks.

[0172] S402, based on the file path and file content corresponding to each module, perform a second enumeration matching and verification with the pre-stored path pattern rules and digest in the features of the injection module to obtain the second enumeration matching result.

[0173] Specifically, steps S302 and S303:

[0174] File path extraction: Call the GetModuleFileNameEx function (an extended function to get the full file path of a module in a specified process, which needs to be used in conjunction with OpenProcess to obtain permissions), pass in the module handle, and parse the full path of the module on the disk (such as C:\Program Files\Agent\Monitor.dll).

[0175] File content retrieval: The file content is read through the module handle, but only its cryptographic digest value (hash value) is calculated, not the complete content.

[0176] Next, the file path and file content of the module are matched and verified a second time against the pre-stored path pattern rules and digest in the injected module features, similar to steps S302 and S303, and will not be repeated here. The final result of the second enumeration matching is then obtained.

[0177] S500, the first enumeration matching result and the second enumeration matching result are compared with the process list of the current security product to obtain a differentiated initial process.

[0178] Specifically, the initial process of obtaining differentiation may include the following steps:

[0179] S501, the first enumeration matching result and the second enumeration matching result are sequentially verified to obtain a dual module enumeration mechanism.

[0180] Specifically, the dual-module enumeration mechanism formed by the first and second enumeration matching results is a sequential verification system rather than a simple combination.

[0181] Furthermore, the specific implementation is as follows:

[0182] Output the security product process PID (e.g., 1045), and output a binary status (matched / not matched).

[0183] The triggering mechanism is that the second enumeration is activated only if the monitoring module is not found during the first enumeration.

[0184] It should be noted that the essence of the dual-module enumeration mechanism is a conditional trigger chain (not data merging), and the secondary enumeration is only activated when necessary (to save resources).

[0185] S502, for each process of the current security product, a dual module enumeration mechanism is executed. When no monitoring module is found in either enumeration, a differentiated initial process is obtained.

[0186] Specifically, after this double verification, any process that has not loaded any monitoring modules defined in the feature library is added to the candidate list, awaiting subsequent security policy analysis.

[0187] If executed Figure 5 The steps are as follows: EnumProcessModules enumerates the module list - GetModuleFileNameEx obtains the module path - compares the module features with the feature library - Module32First and Module32Next obtain the module again - compare the module features with the feature library again - obtain the information of the uninjected process.

[0188] like Figure 6 As shown in step S600, the initial process is analyzed for memory mitigation strategies to identify processes that have not been injected by the regular monitoring module and have opened the dynamic code loading interface, thus forming target processes and obtaining a list of target processes.

[0189] Specifically, obtaining the list of target processes may include the following steps:

[0190] S601, Based on the modification strategy of the initial process, determine the dynamic code execution protection strategy of the initial process.

[0191] Specifically, you can call OpenProcess(PROCESS_QUERY_INFORMATION) to obtain the process handle, and use the GetProcessMitigationPolicy function (process mitigation policy query function) to query the dynamic code policy and specify the ProcessDynamicCodePolicy (process dynamic code policy) flag.

[0192] For example, the DYNAMIC_CODE_POLICY.ProhibitDynamicCode flag is checked. When it is 0, loading unsigned modules (open interfaces) is allowed; when it is 1, dynamic code loading is prohibited (candidates are excluded).

[0193] Query the policy status through legitimate APIs to avoid high-risk operations such as modifying process memory.

[0194] S602, if the dynamic code execution protection strategy of the initial process contains a continuous executable memory region and a dynamic code loading interface, a target process is formed.

[0195] Specifically, to achieve the target process, two conditions need to be met:

[0196] Firstly, the dynamic code loading interface is open; the verification standard can be ProhibitDynamicCode (dynamic code prohibition flag) == 0, that is, the process has not enabled the "prohibit loading of unsigned modules" policy;

[0197] Secondly, if a contiguous executable memory region exists, the memory space is traversed to identify the MEMORY_BASIC_INFORMATION.Protect (memory page protection attribute flag), the validity flag, and PAGE_EXECUTE_READWRITE (read-write execution). For example, the quantification standard is: a contiguous memory block ≥ 4KB is considered usable.

[0198] S603, Based on the multiple target processes, obtain the target process list.

[0199] Specifically, finally, a deep analysis of the memory mitigation strategies for the aforementioned candidate processes is performed to ensure that they allow dynamic loading and execution of external code. The system (Windows operating system (the underlying platform of the target system)) calls GetProcessMitigationPolicy and specifies the ProcessDynamicCodePolicy flag to query the process's dynamic code execution protection policy; if the policy does not prohibit the loading of unsigned modules, the system will further use VirtualQueryEx to scan memory attributes to detect whether there is a contiguous executable memory region with the PAGE_EXECUTE_READWRITE attribute.

[0200] If such memory blocks exist and meet the conditions for subsequent exploitation, it confirms that the process has neither been injected by conventional monitoring modules nor has it exposed a dynamic code loading interface, thus becoming an ideal target for further research and security testing. Finally, the system outputs a list of candidate processes. This complete list includes all candidate processes that have not been injected by monitoring modules and whose memory policy allows for dynamic loading, providing a reliable basis for subsequent in-depth security analysis and attack drills.

[0201] Example: Figure 2 As shown, this application presents a process localization method for blind spots in security system monitoring. It achieves highly concealed attack surface identification by constructing a feature library of security products such as EDR / AV and implementing a multi-level process filtering mechanism. The technical advantages are reflected in three aspects:

[0202] (1) In the early stage, through in-depth analysis of the process, registry and other related data of security products such as AV / EDR, the feature library of security products such as AV / EDR is extracted to obtain the information features of monitoring components;

[0203] (2) Detect whether the AV / EDR process of the detection system has AV / EDR. By analyzing the difference between the process module list and the feature library, if AV / EDR exists, filter the processes that do not contain the AV / EDR module, and further determine whether there are any processes that do not contain the AV / EDR module. If AV / EDR does not exist, locate the process that has not been injected with the monitoring module, check the process memory protection strategy to see if it meets the exploitation conditions, and generate the final process list to end. Otherwise, end directly.

[0204] (3) Integrate a memory protection strategy detection module to ensure that the selected process has both availability and concealment.

[0205] Below is the core pseudocode for each of the four main steps in the detailed steps:

[0206] / / Assume there is a JSON library for output

[0207] struct FeatureEntry {

[0208] string namePattern; / / Regular expression for process name

[0209] string modulePath; / / Injection module path pattern

[0210] string moduleHash; / / Module file hash

[0211] };

[0212] vector <featureentry>buildFeatureDatabase() {

[0213] vector <featureentry>db;

[0214] / / 1) Collect raw data from intelligence sources and dynamic analysis results

[0215] auto rawList = collectIntelligence(); / / External implementation

[0216] / / 2) Normalization process name, generate regular expression

[0217] for (auto&item :rawList) {

[0218] FeatureEntry entry.

[0219] entry.namePattern = normalizeToRegex(item.exeName);

[0220] entry.modulePath = extractPathPattern(item.modulePath);

[0221] entry.moduleHash = calcSHA256(item.moduleFile);

[0222] db.push_back(entry);

[0223] }

[0224] / / 3) Serialize to JSON and write to a file

[0225] saveAsJson("features.json", db);

[0226] return db;

[0227] }

[0228] struct ProcessMatch {

[0229] DWORD pid;

[0230] string exeName;

[0231] / / Module injection features extracted from the feature library

[0232] vector <pair<string / Module path pattern / , string / Module hash <>moduleFeatures;

[0233] };

[0234] vector <processmatch>scanProcesses(const vector <featureentry>&db) {

[0235] vector <processmatch>matches

[0236] / / Create process snapshot

[0237] HANDLE hSnap = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0);

[0238] PROCESSENTRY32 pe = { sizeof(pe)};

[0239] if (Process32First(hSnap,&pe)) {

[0240] do {

[0241] string exe = pe.szExeFile;

[0242] / / Match each feature library entry

[0243] for (auto&f :db) {

[0244] if (regex_match(exe, regex(f.namePattern))) {

[0245] / / Once a match is found, collect the associated features of the injected module.

[0246] ProcessMatch pm;

[0247] pm.pid = pe.th32ProcessID;

[0248] pm.exeName = exe;

[0249] pm.moduleFeatures.push_back({ f.modulePath, f.moduleHash});

[0250] matches.push_back(pm);

[0251] break

[0252] }

[0253] }

[0254] } while (Process32Next(hSnap,&pe));

[0255] }

[0256] CloseHandle(hSnap);

[0257] return matches;

[0258] }

[0259] vector <processinfo>filterByModules(const vector <processinfo>&procs,

[0260] const vector <featureentry>&db) {

[0261] vector <processinfo>candidates

[0262] for (auto&p : procs) {

[0263] HANDLE hProc = OpenProcess(PROCESS_QUERY_INFORMATION |PROCESS_VM_READ,

[0264] FALSE, p.pid);

[0265] if (!hProc) continue;

[0266] / / First enumeration of loaded modules

[0267] vector <string>loaded1 = enumModules(hProc);

[0268] / / Secondary memory snapshot enumeration

[0269] vector <string>loaded2 = enumModulesBySnapshot(p.pid);

[0270] / / Merge result

[0271] set <string>allModules(loaded1.begin(), loaded1.end());

[0272] allModules.insert(loaded2.begin(), loaded2.end());

[0273] bool injected = false;

[0274] / / Check whether each module matches the feature library

[0275] for (auto&path :allModules) {

[0276] string hash = calcSHA256File(path);

[0277] for (auto&f :db) {

[0278] if (path.find(f.modulePath) !=string::npos

[0279] &&hash == f.moduleHash) {

[0280] injected = true;

[0281] break;

[0282] }

[0283] }

[0284] if (injected) break;

[0285] }

[0286] if (!injected)

[0287] candidates.push_back(p);

[0288] CloseHandle(hProc);

[0289] }

[0290] return candidates;

[0291] }

[0292] vector <processinfo>verifyMemoryPolicy(const vector <processinfo>&procs) {

[0293] vector <processinfo>result

[0294] for (auto&p : procs) {

[0295] HANDLE hProc = OpenProcess(PROCESS_QUERY_INFORMATION, FALSE,p.pid);

[0296] if (!hProc) continue;

[0297] / / Query dynamic code strategy

[0298] DYNAMIC_CODE_POLICY policy = {};

[0299] if (GetProcessMitigationPolicy(hProc,

[0300] ProcessDynamicCodePolicy,&policy, sizeof(policy))) {

[0301] / / If unsigned module loading is allowed

[0302] if (!policy.ProhibitDynamicCode) {

[0303] / / Scan memory blocks to obtain memory read / write status

[0304] if (hasRWXPages(hProc)) {

[0305] result.push_back(p);

[0306] }

[0307] }

[0308] }

[0309] CloseHandle(hProc);

[0310] }

[0311] return result;

[0312] }

[0313] In summary, this application provides a process location method for blind spots in security system monitoring, which has the following beneficial effects:

[0314] This paper proposes a method to efficiently and covertly locate process blind spots not covered by endpoint protection products in complex security environments. The core of this method lies in collecting multi-dimensional state information such as process permissions, module loading, and memory protection through legitimate system interfaces, and then integrating and evaluating this information within a unified framework to determine whether a target process is in a "monitoring blind spot." First, the method utilizes standard process enumeration and module query interfaces to compare the integrity and signature status of loaded modules for each process, ensuring that candidate processes without static whitelists can be identified without relying on them. Then, it comprehensively tests the memory region protection attributes and dynamic code loading restrictions of these candidate processes to confirm that they simultaneously possess a policy environment that allows for unsigned code loading and read / write execution of memory regions. The entire process is completed while adhering to common system call behavior characteristics, effectively reducing the risk of triggering adversarial strategies.

[0315] First, by using a multi-dimensional status acquisition module, combined with process permission levels, module signature verification, and memory region attributes, accurate location of processes outside the monitoring coverage area can be achieved.

[0316] Second, a two-round process and module traversal technique is adopted to ensure the integrity of the regular enumeration results on the one hand, and to eliminate the misleading influence of traditional hiding techniques through cross-validation on the other hand.

[0317] Third, design a covert operation process that matches the system call, so that all detection behaviors appear as legitimate, low-frequency system activities, thereby avoiding triggering abnormal alarms from security products.

[0318] In summary, this application constitutes a complete "multi-dimensional data collection - unified evaluation - covert execution" process, continuously and reliably locating blind spots in endpoint security monitoring. By dynamically constructing a security product feature library, combined with a dual-module enumeration verification mechanism and memory strategy analysis, it identifies process blind spots not covered by the security system's monitoring. This method can proactively discover monitoring blind spots in the endpoint protection system, helping security personnel detect the risk of protection strategy failures and promptly strengthen the defense chain. Simultaneously, it uses legitimate system interfaces to achieve covert detection, avoiding triggering security product alarms, providing key technical support for building an adaptive security protection system, and effectively improving overall security defense capabilities.

[0319] Secondly, this application provides a process location system for blind spots in security system monitoring, applied to the aforementioned process location method for blind spots in security system monitoring. The system includes:

[0320] The building unit is used to acquire security products and security-related information in the local dynamic analysis environment, and to build a structured AV / EDR feature library;

[0321] The generation unit is used to call the application programming interface in the target system to generate a transient image containing active process information, and to traverse the transient image through the constructed regular expression rules to obtain the injection module features associated with the security product in the structured AV / EDR feature library.

[0322] The first enumeration unit is used to obtain the file path and file content of the process list in the target system, and to perform the first enumeration matching and verification with the path pattern rules and digests pre-stored in the features of the injection module to obtain the first enumeration matching result.

[0323] The second enumeration unit is used to enumerate the module list of the current process a second time in the transient image, and apply the injected module features again for matching and verification to obtain the second enumeration matching result;

[0324] The first enumeration matching result and the second enumeration matching result are compared with the process list of the current security product to obtain a differentiated initial process;

[0325] The initial process is analyzed for memory mitigation strategies to identify processes that have not been injected by the regular monitoring module and have opened the dynamic code loading interface, thus forming target processes and obtaining a list of target processes.

[0326] Thirdly, this application provides a computer storage medium storing a computer program thereon, wherein the computer program, when executed by a processor, implements the steps of the aforementioned process location method for blind spots in security system monitoring.

[0327] Fourthly, this application provides a computer program that, when executed by a processor, implements the steps of the aforementioned process location method for blind spots in security system monitoring.

[0328] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0329] The various embodiments in this disclosure are described in a progressive manner. The same or similar parts between the various embodiments can be referred to each other. Each embodiment focuses on describing the differences from other embodiments.

[0330] The scope of protection of this disclosure is not limited to the embodiments described above. Obviously, those skilled in the art can make various modifications and variations to this disclosure without departing from its scope and spirit. If such modifications and variations fall within the scope of the claims of this disclosure and their equivalents, then the intent of this disclosure also includes such modifications and variations.< / processinfo> < / processinfo> < / processinfo> < / string> < / string> < / string> < / processinfo> < / featureentry> < / processinfo> < / processinfo> < / processmatch> < / featureentry> < / processmatch> < / featureentry> < / featureentry>

Claims

1. A process positioning method for monitoring blind areas of a security system, characterized in that the method The application comprises the following steps: Obtaining security products and security-related information in a local dynamic analysis environment, and constructing a structured AV / EDR feature library; In a target system, calling an application programming interface to generate a transient mirror containing active process information, and traversing the transient mirror through a constructed regular expression rule to obtain injection module features associated with the security products in the structured AV / EDR feature library; Obtaining the file path and file content of the process list in the target system, and matching and verifying the first enumeration result with the pre-stored path pattern rule and the injection module features to obtain the first enumeration matching result; In the transient mirror, performing a second enumeration on the module list of the current process, and applying the injection module features again for matching and verification to obtain the second enumeration matching result; Differentially matching and comparing the first enumeration matching result and the second enumeration matching result with the process list of the current security product to obtain a differential initial process; Analyzing the memory mitigation strategy of the initial process to determine the process that is not injected by a conventional monitoring module and opens a dynamic code loading interface, forming a target process to obtain a target process list.

2. The process positioning method for monitoring blind areas of security systems according to claim 1, characterized in that, The step of obtaining security products and security-related information in a local dynamic analysis environment, and constructing a structured AV / EDR feature library comprises the following steps: Obtaining core information in a public intelligence platform and a local dynamic analysis environment, performing format normalization, and abstracting typical naming patterns in a combination of wildcards and regular expressions to obtain standardized process names; Performing directory structure feature extraction on the directory path in the core information to obtain standardized paths; Performing hash calculation on the file name in the core information to obtain a hash digest of the file name; Storing the standardized process names, standardized paths, and hash digests of the file names in the form of structured entries to obtain a structured AV / EDR feature library.

3. The process positioning method for monitoring blind areas of security systems according to claim 1, characterized in that, The step of calling an application programming interface in a target system to generate a transient mirror containing active process information, and traversing the transient mirror through a constructed regular expression rule to obtain injection module features associated with the security products in the structured AV / EDR feature library comprises the following steps: In the target system, calling an API function interface in the system API to generate a snapshot containing all active process information; Traversing all process entries in the snapshot containing all active process information, and reading key fields in the process entry structure to obtain executable file name key fields and process number key fields; According to the feature matching engine, comparing the executable file name key fields and the process number key fields with the constructed regular expression rule one by one to obtain a comparison result; If the comparison result is not empty, it is determined that there is a process of a known security product in the target system. According to the known security product process, the content associated with the structured AV / EDR feature library is retrieved to obtain the injection module feature.

4. The process positioning method for monitoring blind areas of security systems according to claim 3, characterized in that, The step of obtaining the file path and file content of the process list in the target system, and matching and verifying the pre-stored path pattern rule and the first enumeration summary in the injection module feature to obtain the first enumeration matching result, comprises: Obtaining the handle of the process list in the target system, and determining the handle list of the loaded module according to the handle; According to the handle list of the loaded module, the file path and file content of the module are determined; The file path and file content of the module are matched and verified with the pre-stored path pattern rule and the first enumeration summary in the injection module feature respectively to obtain the first enumeration matching result.

5. The process positioning method for monitoring blind areas of security systems according to claim 1, characterized in that, The step of performing the second enumeration on the module list of the current process in the transient image and applying the injection module feature again for matching and verification to obtain the second enumeration matching result, comprises: In the transient image, the module list of the current process is obtained, and the file path and file content corresponding to each module are obtained; According to the file path and file content corresponding to each module, the second enumeration matching and verification are performed with the pre-stored path pattern rule and the summary in the injection module feature to obtain the second enumeration matching result.

6. The process positioning method for monitoring blind areas of security systems according to claim 1, characterized in that, The step of differentiating the initial process by matching and comparing the first enumeration matching result and the second enumeration matching result with the process list of the current security product, comprises: The first enumeration matching result and the second enumeration matching result are sequentially verified to obtain a double module enumeration mechanism; For each process of the current security product, the double module enumeration mechanism is executed, and when no monitoring module is found in both enumerations, the differentiated initial process is obtained.

7. The process positioning method for monitoring blind areas of security systems according to claim 1, characterized in that, The step of analyzing the memory mitigation strategy of the initial process to determine the process that is not injected by a regular monitoring module and opens a dynamic code loading interface to form a target process and obtain a target process list, comprises: According to the modification strategy of the initial process, the dynamic code execution protection strategy of the initial process is determined; If there is a continuous executable memory area and a dynamic code loading interface in the dynamic code execution protection strategy of the initial process, a target process is formed; According to a plurality of target processes, the target process list is obtained.

8. A process positioning system for blind spots in security system monitoring, characterized in that, The process positioning method for the security system monitoring blind area according to any one of claims 1-7, the system comprises: A construction unit for obtaining security product and security-related information in a local dynamic analysis environment, and constructing a structured AV / EDR feature library; A generation unit for calling an application programming interface in a target system to generate a transient image containing active process information, and traversing the transient image through the regular expression rule constructed to obtain the injection module feature associated with the security product in the structured AV / EDR feature library; The first enumeration unit is configured to obtain file paths and file contents of a process list in the target system, and perform first enumeration matching and verification on the file paths and the file contents with pre-stored path pattern rules and summaries in the injection module features to obtain first enumeration matching results. The second enumeration unit is configured to perform second enumeration on a module list of a current process in the transient mirror image, and perform matching and verification on the module list again by using the injection module features to obtain second enumeration matching results. The first enumeration matching results and the second enumeration matching results are compared with a process list of the current security product to obtain differential initial processes. The initial processes are analyzed by using a memory mitigation strategy to determine processes that are not injected by a conventional monitoring module and that open a dynamic code loading interface, and target processes are formed to obtain a target process list.

9. A computer storage medium having stored thereon a computer program, characterized in that The computer program is executed by the processor to implement the steps of the process positioning method for the security system monitoring blind area according to any one of claims 1 to 7.

10. A computer program, characterized in that, The computer program is executed by the processor to implement the steps of the process positioning method for the security system monitoring blind area according to any one of claims 1 to 7.

Images