Abnormality detection method, system and device in shared environment and storage medium

Abstract

The invention relates to the technical field of network security, in particular to an anomaly detection method, system and device in a shared environment and a storage medium, and the method comprises the steps: collecting behavior data of a plurality of hosts in the shared environment, and converging the behavior data to construct a process call tree; selecting candidate processes meeting preset candidate conditions according to the process call tree, and aggregating corresponding application role domains according to the candidate processes; in each application role domain, process capability categories are divided, and a tail segment process chain is constructed according to the divided capability categories; and performing anomaly detection on the tail-segment process chain according to a preset judgment condition to obtain an anomaly detection result. The unknown attack behavior is detected under the environment of multi-service coexistence and multi-node deployment during shared operation, and the detection accuracy is improved at the same time.

Description

Technical Field

[0001] This disclosure relates to the field of network security technology, and in particular to an anomaly detection method, system, device and storage medium in a shared environment. Background Technology

[0002] In the field of host security and endpoint detection and response, existing technologies widely employ malicious signature databases, static rules, process behavior monitoring, and anomaly detection methods based on process call chains. A typical approach involves collecting process creation events to construct a process call tree or process chain, and then performing detection based on pre-defined parent-child process combination rules. For example, this might prevent certain office software from directly launching command-line interpreters, script parsers, or download tools. Once a process chain combination is detected that does not match a pre-configured whitelist or blacklist, it is considered suspicious behavior. While these methods are simple to implement, they rely heavily on rule maintenance, making it difficult to adapt to new attack paths and complex business differences. Overly coarse rules are prone to false positives, while overly granular rules lead to excessively high maintenance costs.

[0003] Another approach involves statistically modeling process call chains at the container or host level. A typical approach is to merge process call trees within a specific time window, using container images or hosts as units, to obtain a merged call tree or overall behavioral baseline. Statistical analysis is then performed on parent-child process time intervals, command parameter dispersion, etc., and the degree of deviation from the baseline is used to identify abnormal chains or nodes. While this method can identify unknown abnormal behavior to some extent in containerized scenarios, the modeling unit is usually at the "host / container" granularity, making it difficult to distinguish behavioral differences between different business applications running under the same runtime. When multiple businesses share the same runtime, behavioral patterns become confused, and the baseline is easily widened.

[0004] Therefore, existing technologies are insufficient to detect unknown attack behaviors in environments with shared runtime, coexistence of multiple services, and deployment of multiple nodes, resulting in false positives and false negatives. Summary of the Invention

[0005] To address the aforementioned technical issues, this disclosure provides an anomaly detection method, system, device, and storage medium in a shared environment.

[0006] This disclosure provides an anomaly detection method in a shared environment, including: Collect behavioral data from multiple hosts in a shared environment, and aggregate the behavioral data to construct a process call tree; Candidate processes that meet preset candidate conditions are selected based on the process call tree, and the corresponding application role domains are aggregated based on the candidate processes; Within each of the application role domains, process capability categories are divided, and a tail process chain is constructed based on the divided capability categories. Anomaly detection is performed on the tail process chain according to preset judgment conditions to obtain anomaly detection results.

[0007] Furthermore, the step of selecting candidate processes that meet preset candidate conditions based on the process call tree, and aggregating the corresponding application role domains based on the candidate processes, includes: Select candidate processes that meet the preset candidate conditions from the process call tree; The candidate processes are extracted to obtain multidimensional feature vectors; Based on the multidimensional feature vector of each candidate process, the feature similarity between the candidate processes is obtained through similarity partitioning; Based on the feature similarity, at least one of the candidate processes is merged into an application process role and aggregated into a corresponding application role domain.

[0008] Furthermore, the step of dividing process capability categories within each application role domain and constructing a tail process chain based on the divided capability categories includes: Within each application role domain, process nodes within the application role threshold are labeled according to preset capability categories; Based on the labels of the process nodes, the application process role nodes are expanded along the child processes, and the call chain is divided into a business segment view and a command segment view according to the capability type of the child processes. Based on the command segment view, the tail process chain under the application role domain is constructed through the process path from the application process role node to the first occurrence of the command execution class node.

[0009] Furthermore, the step of dividing the call chain into a business segment view and a command segment view based on the subprocess capability type includes: Starting from the application process role node, if the first node that appears is a business or task scheduler, then the current call chain is divided into a business segment view; Starting from the application process role node, if the first node that appears is a command execution node, then the current call chain is divided into a command segment view.

[0010] Furthermore, the feature is that, before the step of collecting behavioral data from multiple hosts and aggregating the behavioral data to construct a process call tree, the method further includes: Obtain historical behavior data of the multiple hosts; Based on the historical behavior data, obtain tail process samples for each application role domain and each type of anchor process; The features of each tail process sample are encoded to obtain a structural feature library.

[0011] Furthermore, the step of performing anomaly assessment on the tail process chain according to preset judgment conditions to obtain anomaly assessment results includes: An anomaly comparison is performed between the tail process chain and the structural feature library within the corresponding application role domain. If the deviation between the tail process chain and the structural feature library meets the first preset judgment condition, then the first anomaly score of the tail process chain is obtained. An anomaly score is obtained by comparing the tail process chain with the command structure in the corresponding application role domain. If the command structure of the tail process chain meets the second preset judgment condition, the second anomaly score of the tail process chain is obtained. An anomaly score is obtained by comparing the tail process chain with the command parameters in the corresponding application role domain. If the tail process chain and the command parameters in the structural feature library meet the third preset judgment condition, the third anomaly score of the tail process chain is obtained. The anomaly assessment result of the tail process chain is obtained by using the first anomaly score, the second anomaly score, and the third anomaly score.

[0012] Furthermore, it also includes: Based on the anomaly assessment results, the risk level is classified as low-risk or high-risk. When the tail process chain is of low risk level, and the number of occurrences within a preset time window is less than the preset number of samples and meets the preset time span threshold, the abnormal evaluation results of the tail process chain will be removed. When the tail process chain is classified as high-risk and its occurrence count exceeds a preset sample number within a preset time window, the tail process chain will be frozen.

[0013] This disclosure also provides an anomaly detection system in a shared environment, including: The data acquisition module is used to collect behavioral data from multiple hosts in a shared environment and aggregate the behavioral data to construct a process call tree. The aggregation module is used to select candidate processes that meet preset candidate conditions according to the process call tree, and aggregate the corresponding application role domains according to the candidate processes; The partitioning module is used to partition the process capability categories within each application role domain and construct the tail process chain based on the partitioned capability categories. The evaluation module is used to perform anomaly detection on the tail process chain according to preset judgment conditions and obtain anomaly detection results.

[0014] This disclosure also provides a computer device, including a memory and a processor, wherein the memory stores computer-readable instructions, and the processor executes the computer-readable instructions to implement the steps of the anomaly detection method in a shared environment.

[0015] This disclosure also provides a computer-readable storage medium storing computer-readable instructions, which, when executed by a processor, implement the steps of the anomaly detection method in a shared environment.

[0016] The technical solution provided in this disclosure has the following advantages compared with the prior art: By collecting behavioral data from multiple hosts in a shared environment and aggregating this data to construct a process call tree, candidate processes meeting preset criteria are selected from the call tree, and their corresponding application role domains are aggregated. Within each application role domain, process capability categories are categorized, and a tail-end process chain is constructed based on these categories. Anomaly detection is performed on the tail-end process chain according to preset judgment criteria to obtain anomaly detection results. This approach enables the detection of unknown attack behaviors in a shared runtime, multi-service coexistence, and multi-node deployment environment, while improving detection accuracy. Attached Figure Description

[0017] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure.

[0018] To more clearly illustrate the technical solutions in the embodiments of this disclosure or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, those skilled in the art can obtain other drawings based on these drawings without creative effort.

[0019] Figure 1 This is a schematic diagram of an anomaly detection method in a shared environment provided in the embodiments of this disclosure; Figure 2 A schematic diagram of the aggregated application role domain provided in this embodiment of the disclosure; Figure 3 This is a schematic diagram of an anomaly detection system in a shared environment provided in an embodiment of this disclosure. Detailed Implementation

[0020] To better understand the above-mentioned objectives, features, and advantages of this disclosure, the solutions disclosed herein will be further described below. It should be noted that, unless otherwise specified, the embodiments and features described herein can be combined with each other.

[0021] Numerous specific details are set forth in the following description in order to provide a full understanding of this disclosure, but this disclosure may also be implemented in other ways different from those described herein; obviously, the embodiments in the specification are only some, and not all, of the embodiments of this disclosure.

[0022] Figure 1 This is a schematic diagram of an anomaly detection method in a shared environment provided in the embodiments of this disclosure; as shown Figure 1 As shown, this disclosure provides an anomaly detection method in a shared environment, including: Step S1: Collect behavioral data from multiple hosts in a shared environment, and aggregate the behavioral data to construct a process call tree; For example, a shared environment (i.e. a shared runtime environment) is a runtime environment in which multiple different business applications share the same runtime execution engine or binary (such as a unified script scheduling service process) within the same physical host or the same container instance.

[0023] Specifically, behavioral data such as process creation, process termination, parent-child process relationships, system calls, and access to critical resources are continuously collected from multiple hosts. This data is then time-aligned, deduplicated, and uniformly modeled to ultimately form a process call tree that reflects the true evolution path of a process. The reason for using multi-host behavioral data and constructing a process call tree, rather than analyzing only a single host or isolated events, is that modern application systems and attack behaviors generally exhibit distributed characteristics. Single-point data is insufficient to fully depict the contextual relationships and causal chains of a process. A process call tree, however, can clearly describe the complete path of a process from its initial entry point to subsequent derivation, calls, and evolution, thus providing structured and traceable foundational data for subsequent analysis. This significantly reduces the fragmentation of behavioral data, allowing abnormal behavior to be understood and judged within the complete execution chain, improving the accuracy and interpretability of the overall analysis.

[0024] Step S2: Select candidate processes that meet the preset candidate conditions according to the process call tree, and aggregate the corresponding application role domains according to the candidate processes; For example, an application role domain refers to a group of processes belonging to the same application process role that are treated as a single behavior modeling domain across multiple hosts and container instances, and a unified behavior baseline is established within that domain.

[0025] Specifically, based on the constructed process call tree, processes corresponding to nodes in the tree are filtered according to preset candidate conditions. Candidate conditions may include processes located at a specific level in the call tree, having abnormal parent-child relationships, exhibiting cross-user or cross-permission boundary behavior characteristics, calling sensitive interfaces, or frequently spawning child processes. After filtering out candidate processes, they are further aggregated into the corresponding application role domains based on their functional attributes, deployment location, service affiliation, or business tags. Directly performing unified analysis on all processes is not only computationally expensive but also easily leads to key information being overwhelmed by the behavior of a large number of normal processes. However, initial screening through candidate conditions can effectively focus on processes with potential risks or analytical value. At the same time, the concept of application role domains allows processes to be analyzed within their actual business and application context, avoiding misjudging normal differences in different business scenarios as abnormalities, reducing false alarm rates, and providing a more business-logic-aligned analytical boundary for subsequent refined analysis.

[0026] Step S3: Within each application role domain, process capability categories are divided, and tail process chains are constructed based on the divided capability categories. For example, the tail process chain (RCE tail process chain) refers to the process path (which may include a small number of child processes of the RCE anchor process) between the application process role node and a certain RCE anchor process node within a certain application role domain. This process sub-chain is the focus of modeling and detection in this solution.

[0027] Specifically, within each application role domain, candidate processes are further categorized based on their capabilities. These capabilities can be defined by factors such as system call capabilities, resource access capabilities, network communication capabilities, privilege escalation capabilities, or script execution capabilities. After categorizing the capabilities, a tail process chain reflecting the behavioral characteristics at the end of execution is constructed according to the execution order and capability evolution relationship of the processes in the call tree. This is because many abnormal or malicious behaviors are not manifested in the early stages of process startup, but rather concentrated in the later stages of the execution chain, such as during privilege acquisition, lateral movement, or data transfer. By categorizing capabilities and constructing the tail process chain, the changing trends of process capabilities and the locations where abnormal behaviors are concentrated can be highlighted, making the exposure of abnormal behaviors more focused and explicit, thereby improving the sensitivity of detection and the efficiency of localization.

[0028] Step S4: Perform anomaly detection on the tail process chain according to preset judgment conditions and obtain anomaly detection results.

[0029] Specifically, the constructed tail process chain is subjected to anomaly assessment based on preset judgment conditions. Judgment conditions may include the anomaly of capability combination, the anomaly of call order, the degree of deviation from historical baselines or similar role domains, and whether it meets known attack patterns or risk rules, and finally outputs the anomaly assessment result. By limiting the anomaly assessment to the high-value, high-risk behavior set of the tail process chain, the computational complexity and the risk of misjudgment can be effectively controlled while ensuring the detection effect. It can obtain more credible and operable anomaly assessment conclusions with lower analysis costs, and provide a reliable basis for subsequent alarms, source tracing or automated handling.

[0030] Figure 2 This is a schematic diagram of the aggregated application role domain provided in the embodiments of this disclosure; as shown below. Figure 2 As shown, in some possible implementations, step S2, selecting candidate processes that meet preset candidate conditions based on the process call tree, and aggregating the corresponding application role domains based on the candidate processes, includes: step S21, selecting candidate processes that meet preset candidate conditions from the process call tree; step S22, extracting multi-dimensional feature vectors from the candidate processes; step S23, obtaining feature similarity between candidate processes based on the multi-dimensional feature vectors of each candidate process through similarity partitioning; and step S24, merging at least one candidate process into an application process role and aggregating it into the corresponding application role domain based on the feature similarity.

[0031] Specifically, firstly, candidate processes that meet preset candidate conditions are selected from the process call tree, and multi-dimensional features are extracted from these candidate processes. These multi-dimensional features can include parent-child relationship features, startup path, executing user, permission level, system call distribution, resource access mode, and network behavior, etc., thereby constructing multi-dimensional feature vectors for the candidate processes. Based on these multi-dimensional feature vectors, the feature similarity between candidate processes is calculated. Through similarity partitioning, at least one candidate process with high similarity is merged into the same application process role and aggregated into the corresponding application role domain. In real production environments, the same business application often exists in multiple process forms on different hosts, different instances, and even at different times. It is difficult to accurately identify its business attributes from the perspective of a single process. However, feature similarity aggregation can automatically discover semantically and behaviorally consistent process sets, thereby forming stable and reusable application role domains. This significantly enhances the business consistency and cross-host generalization capability of process analysis, laying the foundation for subsequent role-based anomaly detection.

[0032] In some possible implementations, within each application role domain, process capability categories are divided, and a tail process chain is constructed based on the divided capability categories. This includes: within each application role domain, labeling process nodes within the application role threshold according to preset capability categories; expanding application process role nodes along child processes based on the process node labels, and dividing the call chain into a business segment view and a command segment view based on the child process capability type; and constructing a tail process chain under the application role domain based on the command segment view through the process path from the application process role node to the first occurrence of the command execution class node.

[0033] Specifically, firstly, process nodes within the application role domain are tagged according to preset capability categories. Capability categories may include business processing, task scheduling, command execution, script interpretation, and access control. Then, the call chain is expanded along the child process direction, starting from the application process role node. Many security events or abnormal behaviors often do not occur in the business logic itself, but are reflected in the tail-end behaviors such as command execution, script calls, or system tool calls derived from the business process. Through capability tags and view division, normal business behavior and potential risk behavior can be effectively distinguished. The effect is that anomaly detection focuses on high-risk links, reducing the interference of normal business complexity on the detection results.

[0034] In some possible implementations, the call chain is divided into a business segment view and a command segment view based on the subprocess capability type. This includes: expanding from the application process role node, if the first node that appears is a business or task scheduling node, then the current call chain is divided into a business segment view; expanding from the application process role node, if the first node that appears is a command execution node, then the current call chain is divided into a command segment view.

[0035] Specifically, the call chain is divided into a business segment view and a command segment view based on the capability type of the subprocess. If the first node is a business or task scheduling node, the call chain is classified as a business segment view; if the first node is a command execution node, the call chain is classified as a command segment view. Finally, in the command segment view, the tail process chain is constructed based on the process path from the application process role node to the first command execution node. On the one hand, this allows for the rapid and accurate differentiation between normal business logic-driven process expansion behavior and potentially risky command execution behavior without relying on complex rules or manual annotation, thus ensuring smooth business processing and system integration. The control or command execution flow is naturally separated in structure, thus avoiding the misjudgment of legitimate business calls as anomalies. On the other hand, this division method naturally focuses the analysis of the call chain on the command segment view, effectively highlighting the key nodes in the application process's transition from business mode to control mode, which facilitates subsequent refined modeling and anomaly detection of the tail process chain. In addition, through unified view division rules, similar application roles on different hosts, instances, and deployment environments can form a consistent call chain expression, enhancing the comparability and reusability of analysis results, and achieving the comprehensive technical effect of reducing false alarm rate, improving anomaly detection sensitivity, and enhancing the overall system interpretability.

[0036] In some possible implementations, the feature is that, before the step of collecting behavioral data from multiple hosts and aggregating the behavioral data to construct a process call tree, the method further includes: obtaining historical behavioral data from multiple hosts; obtaining tail process samples for each application role domain and each type of anchor process based on the historical behavioral data; and encoding the features of each tail process sample to obtain a structural feature library.

[0037] Specifically, by collecting historical behavior data from multiple hosts, the system identifies and stores tail process samples under each application role domain and each anchor process type. The system then uniformly encodes the structural features, capability sequence features, and command pattern features of each tail process sample to form a structural feature library. Single or short-term behavior samples are difficult to distinguish between abnormal and low-frequency but normal behavior patterns. However, by building a structural feature library from long-term historical data, the system can form the behavioral baseline of the application role domain itself, significantly improving the stability and reliability of anomaly detection and reducing reliance on static rules or human experience.

[0038] In some possible implementations, anomaly assessment of the tail process chain is performed based on preset judgment conditions to obtain anomaly assessment results, including: comparing the tail process chain with the structural feature library within the corresponding application role domain; if the deviation between the tail process chain and the structural feature library meets a first preset judgment condition, a first anomaly score is obtained for the tail process chain; comparing the tail process chain with the command structure within the corresponding application role domain; if the command structure of the tail process chain meets a second preset judgment condition, a second anomaly score is obtained for the tail process chain; comparing the tail process chain with the command parameters within the corresponding application role domain; if the command parameters of the tail process chain and the structural feature library meet a third preset judgment condition, a third anomaly score is obtained for the tail process chain; and obtaining the anomaly assessment result of the tail process chain based on the first, second, and third anomaly scores.

[0039] Specifically, by comparing the current tail process chain with the structural feature library, command structure, and command parameters within the corresponding application role domain in multiple dimensions, when the degree of structural deviation, command structure abnormality, or command parameter abnormality meets the corresponding preset judgment conditions, the first abnormality score, the second abnormality score, and the third abnormality score are calculated, and the abnormality assessment result of the tail process chain is obtained by combining the above abnormality scores. Different types of abnormalities often manifest at different levels, and relying on a single indicator is prone to missed detection or misjudgment. However, the multi-score fusion mechanism can comprehensively assess risks from three levels: structure, semantics, and details, thereby improving the accuracy and robustness of abnormality identification.

[0040] Some possible implementation methods include: classifying the anomaly assessment results into low-risk or high-risk levels; when the tail process chain is at a low-risk level, and the number of occurrences within a preset time window is less than a preset number of samples and meets a preset time span threshold, the anomaly assessment results of the tail process chain will be removed; when the tail process chain is at a high-risk level, and the number of occurrences within a preset time window is greater than a preset number of samples, the tail process chain will be frozen.

[0041] Specifically, by classifying anomaly assessment results into low-risk or high-risk levels and dynamically adjusting them in conjunction with preset time windows, frequency of occurrence, and time span thresholds, anomaly results are automatically removed from low-risk and infrequently occurring tail process chains, while high-risk and frequently occurring tail process chains are frozen. In actual operating environments, there are a large number of occasional, transient, and harmless anomalies. If all of them are alarmed or dealt with, it will seriously affect system availability. However, by comprehensively judging the frequency and time dimensions, automatic diversion of risk self-regression and risk enhancement can be achieved. While ensuring security, alarm noise and operation and maintenance costs are effectively controlled, realizing a sustainable and evolvable anomaly detection and handling mechanism.

[0042] In some possible implementations, host behavior collection and cross-host process chain aggregation are employed: the system deploys monitoring components in the protected host or container environment, or utilizes existing auditing frameworks, to continuously collect process-related behavioral data. The collected data includes at least: process creation and exit events: process ID (PID), parent process ID (PPID), creation time, exit time, etc.; process static attributes: executable file path, command-line arguments, running user, working directory, file hash, etc.; process runtime attributes: listening port, local / remote IP, protocol type, long-term connection mode, etc.; file access behavior: read and write records of configuration files, log files, script files, etc.; container and orchestration metadata: container ID, image name, namespace, deployment name, tag information, etc.; and, when necessary, system call summary statistics to help distinguish process capability categories.

[0043] The security management center aggregates the aforementioned data from multiple hosts and containers, and constructs a basic process call tree or call chain structure based on time windows and host dimensions. Unlike analysis performed only within a single machine, subsequent steps analyze similar processes across hosts as a unified candidate set, providing a foundation for constructing application process roles and application role domains.

[0044] Construction of application process roles and application role domains in a shared runtime scenario: The system first selects application process role candidates from the aggregated process data. Candidate processes typically exhibit characteristics such as long lifecycles, stable listening ports, and frequent appearances as parent processes of other processes. For these candidate processes using the same runtime executable file, the system extracts the following multi-dimensional features to construct feature vectors: Path and directory features: full path of the executable file, parent directory, and installation path pattern; Command-line argument features: JAR package name, main class name, configuration file path, environment identifier, and business system name; Network listening features: listening port, local address binding method, protocol type, and typical inbound connection pattern; Container and orchestration features: image name, namespace, deployment name, and service tag; Running user and working directory features: corresponding business account and working directory path system; External dependency features: database address for long-term connections, message queue address, and internal service IP.

[0045] The system integrates application process role candidates from multiple hosts and containers into a single feature space. Through clustering or similarity partitioning, processes with similar features and consistent deployment attributes are merged into a single application process role, which is then aggregated across hosts to form an application role domain. For example, JVM processes (Java Virtual Machines) on multiple nodes that host an OA (Office Automation System) are clustered into one OA application process role, and all corresponding instances constitute the OA application role domain. Similarly, JVM processes on multiple nodes that host an ERP (Enterprise Resource Planning) system are clustered into another ERP application process role, and the corresponding instances constitute the ERP application role domain (the name can be extracted based on features such as image name, or it can be randomly generated or modified by the user).

[0046] In this way, cross-host application role domains are formed within the cluster or cloud platform, linked by a shared runtime. Processes with the same runtime, similar deployment characteristics, and similar external dependencies are grouped into the same application role domain, thereby enabling more granular asset identification in shared runtime scenarios. All subsequent RCE (Remote Code Execution) tail process chain modeling and command behavior analysis are performed separately within these application role domains, effectively avoiding interference between behaviors of different services.

[0047] RCE tail process chain construction based on capability category segmentation: In order to focus on the tail anomaly characteristics that often appear in remote code execution attacks, the process capability categories are divided within each application role domain, and an RCE tail process chain is constructed accordingly.

[0048] The system assigns capability category tags to process nodes based on executable file type, command-line mode, system call characteristics, etc., including but not limited to: business framework classes: such as Java Virtual Machine, .NET Runtime, php-fpm, Web Server, etc., used to carry business logic; middleware scheduling classes: such as scheduled task scheduler, internal script execution service, job execution agent, etc., used to handle task distribution and script invocation; command execution classes: such as script interpreter, download / network tool, used to directly execute commands or establish external connections; other auxiliary classes: such as compression / decompression tools, file synchronization tools, etc., which can be included in the command execution class or modeled separately as appropriate.

[0049] After the application role domain is determined, the system expands each process call chain within that domain from the application process role node along the child process direction. Combining capability categories, the call chain is split into a business segment view and a command segment view. The business segment view starts from the application process role node and expands along the business framework class and middleware scheduling class nodes, depicting the relationship between business entry points and task scheduling. The command segment view starts from the first command execution class node (i.e., the RCE anchor process), along with its short-lived child processes, external connection operations, etc., forming a command execution behavior view.

[0050] The path from the application process role node to the first RCE anchor process node is defined as the RCE tail process chain under that application role domain. When necessary, the RCE anchor process and its key child nodes can be attached to model the near-end context of command execution. This RCE tail process chain excludes a large number of common business framework calls in the prefix while retaining the structural information of the critical path from the business entry point to command execution. It is the smallest effective behavioral unit that distinguishes normal script calls from abnormal command execution.

[0051] During the training phase, the system collects RCE tail process chain samples that occur during normal business operations for each application role domain and each type of RCE anchor process. Features such as node capability category, process name, path, running user, and time interval in each tail chain are encoded to form a comparable structural feature representation. Within that role domain, tail behavior patterns are identified through rule matching, statistical learning, or other pattern extraction methods, resulting in several tail behavior patterns that represent different types of legitimate script call patterns under that application role domain, such as log archiving, backup, and health check patterns. The specific algorithm used is not limited to a particular model; rule-based, traditional statistical, or sequence modeling methods can be selected according to implementation needs. This invention does not limit the specific algorithm type.

[0052] During the detection phase, when a new RCE tail process chain appears, the system evaluates its structural characteristics and tail behavior patterns within the corresponding application role domain. If the tail chain differs significantly from any pattern in terms of capability category combination, node order, time interval, etc., it is considered abnormal at the structural and behavioral level.

[0053] Command template and parameter type decomposition and role domain co-modeling: In many business scenarios, application process roles need to periodically call script interpreters or download tools to execute legitimate tasks. Simply relying on the presence of command execution processes is insufficient to distinguish between normal and abnormal behavior. Especially in shared runtime environments, a single runtime process may handle multiple script tasks. If only overall similarity is assessed based on complete command strings, it's highly likely that normal scripts will be misjudged as abnormal during routine operations, while commands truly deviating from the business scope will be diluted by numerous normal changes. Therefore, within the context of application process roles and the RCE tail process chain, command templates and parameter types are decomposed for the command lines of RCE anchor processes. Furthermore, within the application role domain, feature extraction and distribution representation methods that better align with the semantics of different parameter types are adopted. This ensures that the modeling results adapt to business evolution while highlighting truly abnormal behavior.

[0054] For each RCE anchor process, the system parses its command-line string, breaking it down into components such as program name, subcommands, option parameters, and positional parameters. Then, based on preset rules and context information, the relatively stable parts (such as program name, subcommands, parameter names, and fixed directory prefixes) are retained as template content, while the parts strongly related to resource location or target object and subject to significant changes are abstracted as parameter placeholders, forming the command template. For example, for the command `bash -c'cp / var / log / oa / app-2025-11-22.log / backup / oa / app.log'`, the system can abstract it into the command template `bash -c 'cp'`.<LOG_PATH><BACKUP_PATH> ',in<LOG_PATH> and<BACKUP_PATH> These are placeholders for parameters. This templated approach allows us to focus on whether the structural pattern has changed within the application's role domain, rather than being distracted by minor differences such as specific filenames or dates.

[0055] After abstracting the command template, this solution further identifies the types of each specific parameter. The system combines path prefixes, directory levels, file extensions, IP address network segments, port ranges, domain name structures, and known configurations of application process roles to determine the semantic type of the parameter. For example, / var / log / oa / app-2025-11-22.log is identified as a log path (LOG_PATH), / etc / app / config.yaml as a configuration path (CONFIG_PATH), / tmp / oa / tmp1234 as a temporary directory (TEMP_PATH), 10.0.12.7 as an internal IP address (INTERNAL_IP), 198.51.100.23 as a remote IP address (REMOTE_IP), 443 as a port number (PORT), and api.example.com as a domain name (DOMAIN), etc. Different types of parameters have significant differences in semantics and variation patterns. If a completely uniform set of features and statistical methods are used for modeling, it is easy to mix normal changes with real out-of-bounds behaviors. Therefore, after completing type identification, more suitable feature extraction and distribution representation methods are selected for different types of parameters.

[0056] Specifically, for file path parameters such as log paths, configuration paths, and temporary paths, the system focuses on the path structure and directory range. For log paths (LOG_PATH), the system extracts their directory prefix (e.g., / var / log / oa / ), path depth (number of directory levels), and filename pattern (whether it contains a date, a fixed prefix, or has a .log extension, etc.), and maintains a set of valid log directory prefixes and a small set of file naming patterns within the application role domain. If a new log path deviates from the existing directory range or file naming rules, it will receive a higher deviation score on this parameter type dimension. For configuration paths (CONFIG_PATH), the system focuses on whether it is located under the expected configuration directory (e.g., / etc / app / , / opt / app / conf / , etc.) and whether the filename belongs to a limited set of configuration files. Once a path pointing to a non-configuration directory or an unknown configuration file name appears, the abnormal signal can be significantly amplified on this type. For temporary directories (TEMP_PATH), the system allows for significant variations in filenames and extensions, but the key constraint is that they must be located within the expected temporary directory tree (such as / tmp / , / var / tmp / , or the application's own temp directory). If the temporary file path crosses these ranges or falls directly into a sensitive system directory, a higher deviation score is given for this type. The above path-type features can be implemented through string prefix matching, path hierarchy statistics, and finite set judgment, which are simple and feasible in engineering.

[0057] For network identification parameters such as internal IP addresses, remote IP addresses, and domain names, the system focuses on network segment range, attribution category, and historical access distribution. For internal IPs (INTERNAL_IP), the system pre-maintains a set of network segments that are allowed to be accessed within the enterprise and statistically analyzes the set of commonly used target IPs and their access frequency within the application role domain. Newly appearing IPs that are not in the whitelisted network segments or have not appeared for a long time will receive a higher deviation score for this type. For remote IPs (REMOTE_IP), the system can use an IP geodatabase or Autonomous System (AS) information to map IPs to countries / regions, carriers, or cloud service providers, and analyze the historical distribution of the "country / AS + port" combination in conjunction with port information. Once an application role domain shows a "country or autonomous system that has never been accessed before + unconventional port combination," the abnormal behavior will be significantly amplified for this type. For a domain name (DOMAIN), the system extracts the main domain (eTLD+1), subdomain level depth, and subdomain token (such as api, cdn, static, etc.), and maintains a set of commonly used main domains and typical subdomain patterns within the application role domain; when an unknown main domain or a subdomain with significantly different structure and high randomness appears, the deviation score is increased in the domain name type.

[0058] For numerical parameters such as port numbers (PORT), the system focuses on constraints between the business port set and the regular port range. Within an application role domain, the system records the set of commonly used service ports (such as business HTTP ports, database ports, etc.) and maintains a simple statistical distribution of port values. Newly appearing ports that are neither in the business port set nor within the regular low-risk port range receive a higher deviation score for this parameter type. The implementation of port-related features can be achieved through integer range judgment and finite set lookup, resulting in low engineering complexity.

[0059] During the training phase, the system aggregates commands at the granularity of "application role domain + RCE anchor type + command template," and establishes historical distribution baselines for various parameters within each combination based on the aforementioned features. These distribution baselines can be expressed using simple frequency statistics, common value sets, value ranges, directory prefix sets, network segment whitelists, and other data structures to characterize the parameter variation space of a command template under normal conditions within that application role domain. For example, in a certain OA application role domain, the LOG_PATH of the log archiving command template is consistently located in the / var / log / oa / directory with filenames conforming to the pattern "fixed prefix + date + .log," while the BACKUP_PATH is consistently located in the / backup / oa / directory. In practice, the historical distribution baseline can be estimated through simple statistics, distribution fitting, or by combining machine learning models to describe the normal variation range of the command template and various parameters within that application role domain. The choice of algorithm does not constitute a limitation of this invention.

[0060] During the detection phase, when a new command line appears within an application role domain, the system first uses the application process role and the RCE tail process chain context to map the command to the corresponding command template set, determining whether it belongs to an existing template or has sufficient structural similarity to a template. For cases where no matching template can be found, a higher anomaly score is directly given at the command template level. For cases where a template can be matched, the system further evaluates the deviation of each parameter in the command from the corresponding type distribution baseline based on the parameter type: for example, if LOG_PATH exceeds the existing log directory range or file naming pattern, REMOTE_IP points to a country or network segment that the application role domain has never accessed before, and DOMAIN belongs to an unknown primary domain, a higher deviation score is given for the corresponding parameter type; if the template is slightly adjusted but each type of parameter still falls within the historical normal range, a lower parameter anomaly score is given. Ultimately, these categorized deviation results, along with the structural anomaly score of the RCE tail process chain, are used together for subsequent risk scoring and tiered response.

[0061] In the command-line level modeling process, it does not rely on a fixed dangerous command feature library or suspicious command feature library. Instead, it is based on the organizational structure of "application role domain + RCE tail process chain + command template / parameter type distribution". It automatically learns the parameter space of normal behavior within the role domain and identifies anomalies by deviation from the typified features and distribution. In this way, while maintaining engineering feasibility, it remains sensitive to new commands and script behaviors that do not appear in the feature library.

[0062] Multidimensional risk scoring and application role domain-based hierarchical response: By comprehensively utilizing deviation information from three aspects—structural behavior, command templates, and parameter type distribution—a multi-dimensional risk score is performed on each "application role domain + RCE anchor process" tail process chain. Specifically, this includes: Structural behavior anomaly score: based on the distance or density between the RCE tail process chain and historical tail behavior patterns within the application role domain, reflecting the degree of deviation of the sub-chain from the normal baseline in terms of capability category combination, node order, and time interval; Command template anomaly score: based on the matching degree and frequency of occurrence of the RCE anchor command template with the existing command template set within the application role domain, reflecting whether the command structure belongs to a newly emerging or rarely occurring pattern within the role domain; Parameter anomaly score: based on the deviation of command parameters from the historical distribution of various parameter types under the corresponding command template within the application role domain, paying particular attention to changes in path range, IP / domain name attribution, port range, and network segment range. The above structural behavior anomaly scores, command template anomaly scores, and parameter anomaly scores can be obtained through threshold comparison, similarity calculation, density estimation, etc., or can be output by a trained scoring model. Within the application role domain, behaviors are classified as high-risk, medium-risk, and low-risk. For high-risk behaviors, an alarm can be generated immediately through the security management platform, and host protection capabilities can be linked to implement measures such as blocking, process termination, and connection reset. For medium-risk behaviors, they can be included in a gray list for continuous monitoring and pushed to security operations personnel for review. The review results can be fed back to the subsequent behavior pattern state machine module. For low-risk behaviors, they are regarded as normal events and are only used as candidate samples for updating the behavior baseline.

[0063] Behavioral pattern state machine and baseline update control for RCE scenarios: To maintain the stability of the behavior baseline during long-term operation and to prevent abnormal behaviors from being merged into the baseline without confirmation while allowing normal business evolution, this solution constructs a behavior pattern state machine at the granularity of "application role domain + anchor type + behavior pattern", including states such as candidate, learning, whitelist, frozen and blacklist.

[0064] During normal business operations, when a certain tail-end behavior pattern or command-line behavior pattern consistently appears in a low-risk manner within an application role domain, the system can gradually upgrade its status from candidate to learning, and then to whitelist, based on the frequency of occurrence, time span, and risk score. This whitelisted pattern is then incorporated into the normal behavior baseline within that application role domain to improve adaptability to routine changes in business scripts. For behavior patterns that have not reappeared for an extended period or have been replaced by business systems, a frozen state can be implemented according to a strategy to reduce interference from outdated patterns in the judgment of new behaviors.

[0065] For RCE scenarios, fine-grained control is added to the baseline update process in the behavior pattern state machine. When a combination of "application role domain + anchor type + behavior pattern" is detected to trigger high-risk or medium-high-risk scores multiple times within a preset time window, or when its comprehensive risk score remains consistently high for a period of time, the system automatically switches the behavior pattern from the candidate, learning, or whitelist state to the frozen state. In the frozen state, the system still detects and alerts on the subsequent RCE tail-end process chain generated by the pattern, but no longer automatically merges new samples into the behavior baseline, avoiding modification of the baseline before the conclusion is clear.

[0066] After confirmation by security operations personnel or external intelligence, if the behavior pattern is identified as anomalous, its status can be further changed to a blacklist. In subsequent detection, identical or highly similar RCE tail process chains will be directly blocked or trigger strong alarms. If the behavior pattern is confirmed to be a newly introduced legitimate script pattern, it can be manually extracted into new command templates and parameter type distribution baselines, and the behavior pattern status can be restored to learning or whitelisted, so that subsequent samples can be incorporated into the normal baseline. Through this baseline update control based on the behavior pattern state machine, while possessing adaptive learning capabilities, the clear boundaries and interpretability of the behavior baseline are maintained.

[0067] Figure 3 This is a schematic diagram of an anomaly detection system in a shared environment provided in an embodiment of this disclosure; as shown below. Figure 3 As shown, this disclosure also provides an anomaly detection system in a shared environment, including: The acquisition module 401 is used to acquire behavioral data from multiple hosts in a shared environment and aggregate the behavioral data to construct a process call tree; The aggregation module 402 is used to select candidate processes that meet preset candidate conditions according to the process call tree, and aggregate the corresponding application role domains according to the candidate processes; The partitioning module 403 is used to partition the process capability categories within each application role domain and construct the tail process chain based on the partitioned capability categories. The evaluation module 404 is used to perform anomaly detection on the tail process chain according to preset judgment conditions and obtain anomaly detection results.

[0068] This disclosure also provides a computer device, including a memory and a processor, wherein the memory stores computer-readable instructions, and the processor executes the computer-readable instructions to implement the steps of an anomaly detection method in a shared environment.

[0069] This disclosure also provides a computer-readable storage medium storing computer-readable instructions, which, when executed by a processor, implement the steps of an anomaly detection method in a shared environment.

[0070] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0071] The above description is merely a specific embodiment of this disclosure, enabling those skilled in the art to understand or implement it. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this disclosure. Therefore, this disclosure is not to be limited to the embodiments described herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. An anomaly detection method in a shared environment, characterized in that, include: Collect behavioral data from multiple hosts in a shared environment, and aggregate the behavioral data to construct a process call tree; Candidate processes that meet preset candidate conditions are selected based on the process call tree, and the corresponding application role domains are aggregated based on the candidate processes; Within each of the application role domains, process capability categories are divided, and a tail process chain is constructed based on the divided capability categories. Anomaly detection is performed on the tail process chain according to preset judgment conditions to obtain anomaly detection results.

2. The anomaly detection method in a shared environment according to claim 1, characterized in that, The step of selecting candidate processes that meet preset candidate conditions based on the process call tree, and aggregating the corresponding application role domains based on the candidate processes, includes: Select candidate processes that meet the preset candidate conditions from the process call tree; The candidate processes are extracted to obtain multidimensional feature vectors; Based on the multidimensional feature vector of each candidate process, the feature similarity between the candidate processes is obtained through similarity partitioning; Based on the feature similarity, at least one of the candidate processes is merged into an application process role and aggregated into a corresponding application role domain.

3. The anomaly detection method in a shared environment according to claim 1, characterized in that, Within each application role domain, the process capability categories are divided, and a tail process chain is constructed based on the divided capability categories, including: Within each application role domain, process nodes within the application role threshold are labeled according to preset capability categories; Based on the labels of the process nodes, the application process role nodes are expanded along the child processes, and the call chain is divided into a business segment view and a command segment view according to the capability type of the child processes. Based on the command segment view, the tail process chain under the application role domain is constructed through the process path from the application process role node to the first occurrence of the command execution class node.

4. The anomaly detection method in a shared environment according to claim 1, characterized in that, The method of dividing the call chain into a business segment view and a command segment view based on the subprocess capability type includes: Starting from the application process role node, if the first node that appears is a business or task scheduler, then the current call chain is divided into a business segment view; Starting from the application process role node, if the first node that appears is a command execution node, then the current call chain is divided into a command segment view.

5. The anomaly detection method in a shared environment according to any one of claims 1 to 4, characterized in that, Before the step of collecting behavioral data from multiple hosts and aggregating the behavioral data to construct a process call tree, the method further includes: Obtain historical behavior data of the multiple hosts; Based on the historical behavior data, obtain tail process samples for each application role domain and each type of anchor process; The features of each tail process sample are encoded to obtain a structural feature library.

6. The anomaly detection method in a shared environment according to claim 5, characterized in that, The step of performing anomaly assessment on the tail process chain according to preset judgment conditions to obtain anomaly assessment results includes: An anomaly comparison is performed between the tail process chain and the structural feature library within the corresponding application role domain. If the deviation between the tail process chain and the structural feature library meets the first preset judgment condition, then the first anomaly score of the tail process chain is obtained. An anomaly score is obtained by comparing the tail process chain with the command structure in the corresponding application role domain. If the command structure of the tail process chain meets the second preset judgment condition, the second anomaly score of the tail process chain is obtained. An anomaly score is obtained by comparing the tail process chain with the command parameters in the corresponding application role domain. If the tail process chain and the command parameters in the structural feature library meet the third preset judgment condition, the third anomaly score of the tail process chain is obtained. The anomaly assessment result of the tail process chain is obtained by using the first anomaly score, the second anomaly score, and the third anomaly score.

7. The anomaly detection method in a shared environment according to any one of claims 1 to 4, characterized in that, Also includes: Based on the anomaly assessment results, the risk level is classified as low-risk or high-risk. When the tail process chain is of low risk level, and the number of occurrences within a preset time window is less than the preset number of samples and meets the preset time span threshold, the abnormal evaluation results of the tail process chain will be removed. When the tail process chain is classified as high-risk and its occurrence count exceeds a preset sample number within a preset time window, the tail process chain will be frozen.

8. An anomaly detection system in a shared environment, characterized in that, include: The data acquisition module is used to collect behavioral data from multiple hosts and aggregate the behavioral data to construct a process call tree; The aggregation module is used to collect behavioral data from multiple hosts in a shared environment and aggregate the behavioral data to construct a process call tree; The partitioning module is used to partition the process capability categories within each application role domain and construct the tail process chain based on the partitioned capability categories. The evaluation module is used to perform anomaly detection on the tail process chain according to preset judgment conditions and obtain anomaly detection results.

9. A computer device, characterized in that, The method includes a memory and a processor, wherein the memory stores computer-readable instructions, and the processor executes the computer-readable instructions to implement the steps of the anomaly detection method in a shared environment as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-readable instructions, which, when executed by a processor, implement the steps of the anomaly detection method in a shared environment as described in any one of claims 1 to 7.

Images