Container escape detection method, device, equipment and medium

Abstract

The invention relates to a container escape detection method and device, equipment and a medium. The method comprises the steps that original process behavior data running in a container environment are collected; performing container environment adaptation processing on the original process behavior data to generate a standardized event stream carrying a container identifier; based on a predefined container engine normal behavior rule base, detecting an escape behavior in the standardized event stream; and when the escape behaviors are detected, aggregating the associated escape behaviors and generating an incremental attack traceability map. The method has the advantages that the detection rate of escape attacks is increased, the traceability of attack behaviors is enhanced, and a more effective technical means is provided for safety protection of the container virtualization environment.

Description

Technical Field

[0001] This invention belongs to the field of container virtualization environment security technology, and particularly relates to container escape detection methods, devices, equipment and media. Background Technology

[0002] In the current container virtualization environment, although container technologies such as Docker and Kubernetes are widely used in virtualization platforms, bringing advantages such as rapid deployment and elastic scaling, they have also introduced new security threats, especially container escape attacks. The essence of a container escape attack is to break through the isolation boundaries built by mechanisms such as namespaces and cgroups, allowing attackers to gain privileged code execution permissions on the host machine, read and write files outside the container's visible scope, and even further spread the attack to the underlying infrastructure or other tenants. Because containers share the host machine's Linux kernel, the level of container isolation is low, making the host machine more vulnerable to threats. Existing container escape detection methods are mainly based on whitelists, blacklists, and machine learning models, but due to the variability of container environments and their images, these methods suffer from high false positive rates, low detection efficiency, and incomplete coverage. Furthermore, the introduction of containers poses challenges to traditional process behavior collection and tracing systems, especially since these systems lack container awareness capabilities and cannot effectively detect and handle behavior within containers, further contributing to the low escape detection rate in container virtualization environments under current technologies. Summary of the Invention

[0003] The purpose of this invention is to overcome the shortcomings of the prior art and provide a method, apparatus, equipment and medium for detecting container escape.

[0004] Firstly, a container escape detection method is provided, including: S110. Collect raw process behavior data running in the container environment; S120. Perform container environment adaptation processing on the original process behavior data to generate a standardized event stream carrying container identifiers; S130. Based on a predefined container engine normal behavior rule library, detect escape behavior in the standardized event stream; S140. When the escape behavior is detected, the associated escape behaviors are aggregated and an incremental attack tracing graph is generated.

[0005] Preferably, S110 includes: S111. Deploy probes in the system kernel's call interface; the call interface includes a call entry point and an exit point; S112. Monitor the preset system call types using the probe; S113. When the probe captures a call event corresponding to a preset system call type, it extracts the call context information to form the original process behavior data; the original process behavior data includes a control group identifier used to identify the container environment to which the process belongs.

[0006] Preferably, S120 includes: S121. Parse the control group identifier in the process behavior data, and obtain the corresponding container identifier according to the preset container identifier mapping table; S122. Establish the mapping relationship between process identifiers inside the container and process identifiers on the host machine, as well as the mapping relationship between virtual file paths inside the container and real file paths on the host machine. S123. Based on the mapping relationship, convert the process identifier inside the container to the host process identifier, and convert the virtual file path inside the container to the real file path on the host. S124. Output a standardized event stream carrying the container identifier, the host process identifier, and the host real path.

[0007] Preferably, S130 includes: S131. Construct a predefined container engine normal behavior rule library; the container engine normal behavior rule library is used to characterize the legal operation mode within the container. S132. Match the standardized event stream with the container engine normal behavior rule base to detect escape behavior in the standardized event stream; the escape behavior is an abnormal behavior that deviates from the legal operation mode.

[0008] Preferably, S132 includes: S1321. Detect the behavior of critical processes executing non-whitelisted commands; the whitelisted commands are defined by the container engine's normal behavior rule library; S1322. Detect the behavior of processes within the container accessing sensitive files on the host machine; S1323. Detect the behavior of processes within a container connecting to the container-managed socket.

[0009] Preferably, S140 includes: S141. Starting from the detected escape behavior, backtrack along the process relationship chain to locate the source of the attack; the source of the attack is the root process of the container engine. S142. Based on the root process of the container engine, associate the file modification nodes and network connection nodes of the escape behavior to construct an attack operation chain; S143. Aggregate related escape behaviors within a dynamic time window to generate an incremental attack tracing map containing the complete attack path.

[0010] Preferably, in S143, the length of the dynamic time window is adjusted according to the characteristics of the escape behavior, including: When the number of alarms for the escape behavior exceeds a preset threshold within a preset time period, the time window is reduced. When the alarm associated with the escape behavior is cross-container, the time window is expanded.

[0011] In a second aspect, a container escape detection device is provided for performing any of the methods described in the first aspect, including: The data acquisition unit is used to collect raw process behavior data running in the container environment; A standardized event stream generation unit is used to perform container environment adaptation processing on the original process behavior data and generate a standardized event stream carrying a container identifier. An escape behavior detection unit is used to detect escape behavior in the standardized event stream based on a predefined container engine normal behavior rule library. The attack attribution graph generation unit is used to aggregate the associated escape behaviors and generate an incremental attack attribution graph when the escape behavior is detected.

[0012] Thirdly, a computer device is provided, the computer device including a memory and a processor connected to the memory; the memory is used to store a computer program; the processor is used to run the computer program stored in the memory to perform the steps of the method as described in any of the first aspects.

[0013] Fourthly, a computer-readable storage medium is provided, the storage medium storing a computer program, the computer program including program instructions that, when executed by a processor, can perform the steps of the method as described in any of the first aspects.

[0014] The beneficial effects of this invention are: In this invention, raw process behavior data is collected in real time via dynamically mounted kernel probes. The collected raw process behavior data is then adapted to the container environment, generating a standardized event stream carrying container identifiers. Subsequently, based on predefined normal behavior rules of the container engine, the system performs in-depth detection of escape behaviors in the standardized event stream, enabling rapid identification of potential attack behaviors. When escape behavior is detected, the system promptly aggregates relevant escape behavior information and generates an incremental attack tracing graph, allowing security administrators to quickly trace attack paths and analyze attacker behavior patterns. This method not only improves the detection rate of escape attacks but also enhances the ability to trace the source of attack behaviors, providing a more effective technical means for the security protection of container virtualization environments. Attached Figure Description

[0015] Figure 1 A flowchart of the container escape detection method provided by the present invention; Figure 2 This is a first sub-flowchart of the container escape detection method provided by the present invention; Figure 3 This is a sub-flowchart of the second sub-flowchart of the container escape detection method provided by the present invention; Figure 4 The third sub-flowchart of the container escape detection method provided by the present invention; Figure 5 The fourth sub-flowchart of the container escape detection method provided by the present invention; Figure 6 The fifth sub-flowchart of the container escape detection method provided by the present invention; Figure 7 A schematic block diagram of the unit of the container escape detection device provided by the present invention; Figure 8 A schematic block diagram of a computer device provided for an embodiment of the present invention. Detailed Implementation

[0016] The present invention will be further described below with reference to embodiments. The description of the embodiments below is only for the purpose of helping to understand the present invention. It should be noted that those skilled in the art can make several modifications to the present invention without departing from the principle of the present invention, and these improvements and modifications also fall within the protection scope of the claims of the present invention.

[0017] Example 1: To address the security shortcomings in existing technologies when integrating AI agents with backend servers, Embodiment 1 of this application provides a container escape detection method, such as... Figure 1 As shown, the steps include the following: S110. Collect raw process behavior data running in the container environment.

[0018] S120. Perform container environment adaptation processing on the original process behavior data to generate a standardized event stream carrying container identifiers.

[0019] S130. Based on a predefined container engine normal behavior rule library, detect escape behavior in the standardized event stream.

[0020] S140. When the escape behavior is detected, the associated escape behaviors are aggregated and an incremental attack tracing graph is generated.

[0021] In the method of this invention, firstly, a probe module based on eBPF technology is dynamically mounted at the kernel layer. This probe module is deployed at key system call points, such as sys_execve and sys_open, to capture real-time behavioral data of processes within the container. The probe employs a dynamic loading mechanism, allowing for flexible adjustment of the monitoring scope according to container security policies. For example, full system call monitoring can be enabled for privileged containers, while only high-risk calls, such as mount and ptrace, are monitored for ordinary containers. The collected raw data includes key information such as process ID, system call type, parameters, and timestamps.

[0022] Then, the collected raw data undergoes container environment adaptation processing. The container ID to which the process belongs is obtained by querying the container runtime interface, and combined with cgroup and namespace information, the raw events are associated with a specific container. The container runtime interface used for querying is either containerd or CRI-O. This processing employs timestamp alignment technology to ensure the temporal consistency of events across containers, ultimately generating a standardized event stream carrying complete container identifiers.

[0023] Subsequently, standardized event flows are analyzed based on a predefined container engine behavior rule base. The rule base includes known escape behavior characteristics, such as tampering with ` / proc / self / exe` and mounting sensitive directories. It also incorporates machine learning models, such as the Isolation Forest algorithm, to detect anomalous behavior sequences deviating from the normal baseline. The normal behavior baseline is dynamically updated by analyzing historical runtime data from the same container image to improve detection accuracy.

[0024] Finally, when escape behavior is detected, the system aggregates related events such as process derivation chains and file access sequences, and dynamically constructs an incremental attack attribution graph. This graph is presented as a directed graph, with nodes representing entities such as processes and files, and edges representing behavioral relationships. The graph uses an incremental update mechanism, updating only newly added events, significantly reducing computational overhead. Simultaneously, the system assigns confidence scores to key nodes to assist security personnel in quickly locating attack paths.

[0025] Example 2: Based on Example 1, Example 2 of this application provides a more specific method for detecting container escape, including the following steps: S110. Collect raw process behavior data running in the container environment.

[0026] like Figure 2 As shown, S110 includes: S111. Deploy probes in the system kernel's call interface; the call interface includes a call entry point and an exit point.

[0027] The term "system kernel" refers to the operating system kernel of the host machine, specifically the Linux kernel. Within the Linux kernel, the entry and exit points of system calls are used as key monitoring locations, such as syscallenter / exit tracepoints. In practice, a probe module based on eBPF technology is first deployed in the kernel space. The probe sets hooks at key call points in the kernel. eBPF probes are then attached to pre-defined system call monitoring points using either kprobe or tracepoint dynamic tracing mechanisms. For container environments, they rely entirely on the host machine's Linux kernel to run; the system kernel is the physical foundation upon which the container environment exists and operates.

[0028] S112. Monitor the preset system call types using the probe.

[0029] The preset system call types include, but are not limited to, critical calls such as process management calls (e.g., clone, execve), file operation calls (e.g., open, read, write), and privileged operation calls (e.g., mount, ptrace).

[0030] S113. When the probe captures a call event corresponding to a preset system call type, it extracts the call context information to form the original process behavior data; the original process behavior data includes a control group identifier used to identify the container environment to which the process belongs.

[0031] Specifically, when the probe detects a pre-defined system call, the system immediately extracts the call's context information, primarily including the call parameters, the caller's process information, the call's timestamp, and the target resource. To enhance the accuracy of behavioral analysis, the probe pays particular attention to the call's control group identifier, extracting the control group ID from the system call's context. The control group ID is a unique identifier for container management, representing that the behavior occurred within a specific container instance. By collecting the control group identifier, behaviors in different container environments can be clearly distinguished, providing foundational data for subsequent behavior association and tracing. The control group identifier is obtained by parsing the process's cgroupfs mount point information, accurately identifying the container instance to which the process belongs. Simultaneously, the probe also collects auxiliary information such as call timestamps and return values, collectively forming complete raw process behavior data.

[0032] In terms of specific implementation details, the probe module employs a dynamic loading mechanism, which allows for flexible adjustment of the set of system call types monitored based on actual monitoring needs. For example, for containers running database services, the focus can be on monitoring file I / O related calls; for network service containers, the focus is on monitoring socket related calls. This dynamic adjustment capability is implemented through a user-space control module, which communicates with the kernel probe via BPF mapping to update the monitoring strategy in real time.

[0033] This embodiment enables efficient monitoring of key system behaviors and extraction of contextual information, especially the marking of control group identifiers. This allows for accurate association of the container instance to which each behavioral event belongs in subsequent behavior analysis and escape detection, providing a solid foundation of data support for detecting container escape behavior.

[0034] S120. Perform container environment adaptation processing on the original process behavior data to generate a standardized event stream carrying container identifiers.

[0035] like Figure 3 As shown, S120 includes: S121. Parse the control group identifier in the process behavior data, and obtain the corresponding container identifier according to the preset container identifier mapping table.

[0036] Control group identifiers (CBIs) are internal technical identifiers used by the kernel for resource management, while container identifiers are external logical identifiers used by users for business management. The raw data collected by the monitoring system at the kernel layer is technical and container-independent, while users and security analysis require business-level information related to specific container instances. To convert the kernel-perspective CBIs captured by probes into business-perspective container identifiers understandable by users and security systems, thus achieving a seamless transition from low-level monitoring to high-level security analysis, mapping CBIs to container identifiers is essential.

[0037] Specifically, the system maintains a preset container identifier mapping table, which records the correspondence between control group identifiers and unique container identifiers, such as Docker container IDs or Kubernetes Pod names. It should be noted that the container identifier referred to in this invention refers to a common attribute shared by all Docker containers, while the unique container identifier refers to a unique attribute possessed by each Docker container. When collecting raw process behavior data in S113, the acquired raw data already includes the in-container process identifier of the calling process within the container. After obtaining the control group identifier from the raw process behavior data, the system queries this mapping table to determine the container identifier to which the current process belongs. During this query, not only is the container identifier to which the process belongs determined, but the correspondence between the virtual in-container process identifier and the real in-container process identifier on the host machine is also obtained. This mapping relationship is dynamically constructed through periodic scanning of the container runtime interface, ensuring accurate reflection of the currently running container instance. Through this query, the specific container identifier to which each behavioral event belongs can be accurately obtained.

[0038] S122. Establish the mapping relationship between process identifiers inside the container and process identifiers on the host machine, as well as the mapping relationship between virtual file paths inside the container and real file paths on the host machine.

[0039] In S122, to achieve cross-level association of behaviors, the system establishes and maintains a mapping relationship between process identifiers within containers and real process identifiers on the host machine. This mapping relationship is mainly implemented through a mapping table established at the kernel level, ensuring that the virtual PID in the container can be correctly associated with the actual PID on the host machine when behavior data is standardized, providing a foundation for subsequent path translation.

[0040] In addition, when collecting file operation behavior, the system will combine the container's file system mount information to establish a mapping relationship between the virtual path and the host machine path.

[0041] S123. Based on the mapping relationship, convert the process identifier inside the container to the host process identifier, and convert the virtual file path inside the container to the real file path on the host.

[0042] In S123, the process identifiers within the container are converted to host process identifiers. This process is achieved by parsing the process status file in the / proc file system and reading the NSpid field to obtain the mapping between the PID in the container namespace and the PID on the host machine. For example, a process with PID 123 seen inside the container might have PID 4567 on the host machine. This mapping relationship is crucial for subsequent cross-container analysis.

[0043] In addition, the system needs to convert the virtual file paths involved in the behavioral events—that is, the virtual paths inside the container—into real file paths on the host machine. This conversion process needs to take into account the container's mount namespace. Specifically, this is done by parsing the ` / proc / [pid] / mountinfo` file to obtain the container's mount point information, and then performing path conversion based on this information. For example, the ` / app / config` file inside the container might correspond to the ` / var / lib / docker / overlay2 / ... / merged / app / config` path on the host machine. Through this conversion, the file path information in the behavioral events can reflect their actual location on the host machine, thus providing accurate contextual information for the subsequent detection of dangerous behaviors.

[0044] S124. Output a standardized event stream carrying the container identifier, the host process identifier, and the host real path.

[0045] In S124, after the aforementioned mapping and path conversion processes, the system generates a standardized event stream. This stream carries two core pieces of information: first, the container identifier to which the behavioral event belongs, facilitating attribution analysis; and second, the actual host machine path corresponding to the behavior, providing specific environmental details of the occurrence of the behavior. Each standardized event includes the following key fields: container identifier, host machine PID, converted actual file path, original system call information, and precise timestamp. This standardized format ensures that subsequent analysis modules can uniformly process monitoring data from different containers. Furthermore, the event stream is serialized using a binary encoding format such as Protocol Buffers and transmitted to downstream analysis modules via a message queue (such as Kafka). This standardized event stream, output in a unified format, provides clear and accurate foundational data for subsequent rule matching, behavioral analysis, and escape behavior detection, effectively enhancing the accuracy and reliability of detection.

[0046] S130. Based on a predefined container engine normal behavior rule library, detect escape behavior in the standardized event stream.

[0047] like Figure 4 As shown, S130 includes: S131. Construct a predefined container engine normal behavior rule library; the container engine normal behavior rule library is used to characterize the legal operation mode within the container.

[0048] In S131, the system builds a complete set of normal behavior rules by deeply analyzing the standard workflows of container engines such as Docker and containerd. The construction process of this rule base includes: collecting typical operation sequences in the container lifecycle, such as image pulling, container startup, and service running; analyzing system call patterns generated during container runtime; and statistically analyzing the standard behavioral characteristics of common applications such as Nginx and MySQL within containers. These rules are described using declarative syntax, such as "During container initialization, execve is allowed to call / bin / sh but calls to / bin / mount are prohibited," etc.

[0049] Based on the above construction process, the system builds a set of predefined normal behavior rules for the container engine. These rules can be expressed as patterns of behavior sequences, time windows of behavior, whitelists or blacklists of specific system calls, and reasonable ranges of operation paths.

[0050] S132. Match the standardized event stream with the container engine normal behavior rule base to detect escape behavior in the standardized event stream; the escape behavior is an abnormal behavior that deviates from the legal operation mode.

[0051] In S132, the system loads predefined normal behavior rules and compares the behavior data in the standardized event stream in real time. Specifically, the system matches the behavioral features in each event stream to determine whether they conform to the normal behavior rules. In practice, the system loads these predefined normal behavior rules and compiles them into an efficient matching engine. This engine employs a multi-level detection strategy: the first level performs fast pattern matching to identify operations that clearly violate container security boundaries, such as directly accessing the host machine's / proc file; the second level performs context-related analysis to detect seemingly legal but suspicious sequences of behavior, such as consecutive calls to setuid and mount within a short period; the third level applies machine learning models to identify abnormal patterns that deviate from the normal behavior baseline. During the detection process, the system dynamically adjusts the rule weights, for example, applying stricter detection strategies to privileged containers.

[0052] Furthermore, the rule engine employs the Rete algorithm for efficient matching, enabling it to process tens of thousands of standardized events per second. Each rule includes the following elements: triggering conditions, contextual constraints, and response actions. The system also maintains a dynamic anomaly scoring table, accumulating scores when suspicious behavior is detected; scores exceeding a threshold are considered escape behavior. To adapt to different scenarios, the rule base supports hot updates, allowing new rules to be added or existing rules to be adjusted dynamically through the management interface.

[0053] Furthermore, it can adapt to the adaptive learning function of behavioral baselines. The system continuously analyzes historical behavioral data of container workloads and automatically adjusts the parameter thresholds of normal behavior rules. For example, for CI / CD containers that frequently execute scripts, the restrictions on execve calls are appropriately relaxed; for long-running service containers, file system access control is strengthened. This dynamic adjustment mechanism effectively reduces the false positive rate while maintaining sensitivity to the detection of real escape attacks.

[0054] Specifically, such as Figure 5 As shown, S132 includes: S1321. Detect the behavior of critical processes executing non-whitelisted commands; the whitelisted commands are defined by the container engine's normal behavior rule library.

[0055] Specifically, the system detects whether processes within a container are executing commands not on the whitelist. Normally, container behavior is strictly limited, executing only predefined legal commands and operations. To this end, the system defines a whitelist of allowed commands in a rule base. This whitelist is dynamically generated by analyzing the container image build history and runtime characteristics, and includes allowed binary file paths and their hash values. During detection, the system monitors the `execve` system call. When it detects a critical process executing commands outside the whitelist, such as ` / bin / sh` or ` / tmp / malicious scripts`, it immediately marks this as suspicious behavior and escalates the security event level. To improve accuracy, the whitelist mechanism supports differentiated configurations based on container roles, such as applying stricter whitelist policies to privileged containers.

[0056] S1322. Detect the behavior of processes inside the container accessing sensitive files on the host machine.

[0057] Specifically, the system detects whether processes within containers access sensitive files on the host machine. Normal container operations should adhere to resource isolation principles and should not access critical configuration files or sensitive directories on the host machine. For detecting container processes accessing sensitive host files, the system identifies cross-boundary access by analyzing mount namespace information and file path translation results. This is implemented by: establishing a list of sensitive host files, such as / etc / shadow and / proc / kcore; real-time monitoring of file system calls such as open and read; and identifying escape behavior when a path accessed by a process within the container matches the sensitive list after translation. To improve detection efficiency, the system uses the inotify mechanism to monitor sensitive files, performing detailed analysis only on actual access behavior. Additionally, for common container volume mounting scenarios, the system specifically checks the access permissions of mount points to prevent indirect access to host resources via mounting.

[0058] S1323. Detect the behavior of processes within a container connecting to the container-managed socket.

[0059] Specifically, the system also detects whether processes within the container are connecting to container management sockets. These sockets are critical interfaces for container management and control; normally, applications within the container should not directly connect to or manipulate the host machine's management sockets. If a process within the container is detected attempting to connect to these management sockets, it may indicate that an attacker is attempting to use the sockets for privilege escalation or control of the host machine, thereby achieving escape. For detecting processes within the container connecting to container management sockets, the system monitors the `socket` and `connect` system calls, focusing on identifying connection attempts to container runtime management interfaces, such as ` / var / run / docker.sock` and ` / var / run / containerd / containerd.sock`. During detection, the system analyzes the target address and port of the connection and makes a comprehensive judgment based on process context information. This context information refers to the container to which the process belongs, the user executing the process, etc. To combat advanced escape techniques, the system also detects socket paths leaked through environment variables and connections using Unix domain sockets with abstract namespaces. All detected suspicious connections are compared with legitimate management operations generated by the container's normal normal workload to reduce the false positive rate.

[0060] S140. When the escape behavior is detected, the associated escape behaviors are aggregated and an incremental attack tracing graph is generated.

[0061] like Figure 6 As shown, S140 includes: S141. Starting from the detected escape behavior, backtrack along the process relationship chain to locate the origin of the attack; the origin of the attack is the root process of the container engine.

[0062] Specifically, upon detecting potential container escape behavior, the system immediately initiates the process of constructing behavior correlation and source tracing graphs to achieve comprehensive tracking and visualization of the attack chain. Starting with the detected escape behavior event, the system traces back along the process call relationship chain to the root process of the container engine. This process analyzes the process addresses and corresponding parent-child relationships in the behavior event, tracing upwards layer by layer until reaching the root process of the container engine, thereby identifying the starting process and attack source of the escape behavior. In practice, the system obtains the parent process address (PPID) of the current process and recursively queries until tracing back to the root process of the container engine. During the backtracking process, the system records the complete process lineage and marks key turning points, such as processes that escalate privileges via setuid. To improve efficiency, the system uses a caching mechanism to store recently queried process relationships, avoiding repeated parsing of the / proc filesystem.

[0063] S142. Based on the root process of the container engine, associate the file modification node and network connection node of the escape behavior to construct an attack operation chain.

[0064] Specifically, after identifying the container engine root process, the system correlates and analyzes file modification nodes and network connection nodes involved in the escape behavior to construct a complete attack operation chain. For file modification nodes, the system analyzes system call records such as `open` and `write` to identify tampered configuration files or implanted malware; for network connection nodes, it uses `socket` and `connect` call records to discover suspicious internal and external communication behaviors. These correlation analyses are based on precise timestamp sorting to ensure accurate reconstruction of the attack sequence. The system uses a graph database to store the attack operation chain, where nodes represent processes, files, or network connections, and edges represent operation relationships.

[0065] S143. Aggregate related escape behaviors within a dynamic time window to generate an incremental attack tracing map containing the complete attack path.

[0066] Within a dynamic time window, the system aggregates all related escape behaviors to generate an incremental attack attribution graph. Determining the correlation between escape behaviors does not require complete consistency in the attack operation chain. As long as their attack chains have partial consistency or connection at key nodes such as processes, files, or networks, the system considers them to belong to the same or related attack activity and aggregates them into the same dynamic attack attribution graph. The time window is dynamically adjusted according to the attack complexity, automatically extending when persistent attacks are detected. The graph generation process uses an incremental update algorithm, updating only the local graph structure for new events to avoid the overhead of full graph reconstruction. The generated graph includes the following key elements: attack entry point, lateral movement path, escape path, and scope of impact. Furthermore, the attack attribution graph supports visualization, using different colors and shapes to distinguish various nodes, facilitating a quick understanding of the overall attack by security personnel.

[0067] Through the systematic source tracing analysis in this embodiment, not only can a single escape event be reconstructed, but also complex multi-stage attack chains can be discovered.

[0068] Furthermore, in S143, the length of the dynamic time window is adjusted according to the characteristics of the escape behavior, including: When the number of alarms for the escape behavior exceeds a preset threshold within a preset time period, the time window is reduced. When the alarm associated with the escape behavior is cross-container, the time window is expanded.

[0069] Specifically, the time window length is dynamically adjusted based on the characteristics of the escape behavior. When the system detects that the number of escape behavior alarms within a preset time period exceeds a preset threshold, it indicates that the attacker is rapidly executing a multi-stage attack. At this point, the system automatically reduces the time window to 50% of its original length. This reduction operation improves timing accuracy, more accurately captures densely occurring attack steps, and avoids confusion between different stages of the attack due to an excessively large window. The window reduction process employs a smooth transition algorithm to avoid interruptions in correlation analysis caused by abrupt changes.

[0070] When an escape behavior alert is detected involving cross-container associations, such as through analysis of inter-container network connections or shared storage access, the system automatically expands the time window to 150% of its original length. This expansion takes into account the time overhead required for an attacker to perform lateral movement, ensuring that the entire cross-container attack chain can be captured. The window expansion algorithm pays particular attention to dependencies between containers, such as multiple container instances belonging to the same service or container groups sharing a storage volume. The system records the history of window adjustments to prevent fluctuations in analysis results caused by frequent adjustments.

[0071] In terms of technical implementation, the dynamic adjustment of the time window is achieved through a sliding window algorithm, which maintains a circular buffer to store time-series events. When the window is adjusted, the temporal relationships of the events in the buffer are recalculated, and the time constraint edges in the graph are updated. The system also sets minimum and maximum window boundaries to prevent over-adjustment in extreme cases. Changes in window size are reported to the security administrator in real time and visually displayed in the visualization graph using the timeline zoom function.

[0072] The container escape detection method proposed in this invention has broad application prospects in the field of cloud-native security. This method collects process behavior data through dynamic kernel probes, combined with container environment adaptation processing and intelligent behavior analysis, to achieve efficient detection and tracing of container escape attacks. It can be widely applied to various scenarios such as cloud computing platform security protection, DevSecOps processes, hybrid cloud, and multi-cloud environments.

[0073] In terms of cloud computing platform security, this method can be integrated into the security modules of mainstream container platforms such as Kubernetes and OpenShift, providing real-time container escape protection capabilities for cloud service providers and large enterprise users. Its low-overhead characteristics make it particularly suitable for large-scale container cluster environments, effectively defending against attempts to breach container isolation mechanisms without impacting business performance. For example, in the cloud-native transformation of the financial industry, this method can protect core business systems from supply chain attacks launched through container vulnerabilities.

[0074] In DevSecOps processes, this method can be embedded in CI / CD pipelines as a crucial component of continuous security monitoring. By analyzing the behavioral characteristics of containers during runtime, this method can identify potential escape risks early in the testing phase, enabling security shift left. Its incremental source mapping also provides security teams with intuitive attack path analysis, significantly reducing incident response time. Statistics show that enterprises adopting similar technologies can reduce the average response time for container security incidents from hours to minutes.

[0075] In hybrid and multi-cloud environments, this method's standardized event flow and unified detection framework enable consistent container security protection across different cloud platforms. Its container identification mechanism based on control group identifiers effectively solves the challenge of unified container management in heterogeneous environments. In particular, for resource-constrained container deployments in edge computing scenarios, the method's lightweight probes and intelligent sampling mechanisms still maintain reliable detection capabilities.

[0076] With the popularization of cloud-native technologies and the continuous evolution of container escape attack methods, the method of this invention also has unique advantages in the following emerging fields: In the field of serverless security, its monitoring capability for short-lifecycle processes can be extended to the function computing environment; in microservice mesh, its cross-container correlation analysis can enhance the security isolation between services; in confidential computing scenarios, its behavioral baseline analysis can supplement the security visibility in encrypted environments.

[0077] It should be noted that the parts in this embodiment that are the same as or similar to those in Embodiment 1 can be referred to each other, and will not be repeated in this application.

[0078] Example 3: Based on Embodiment 2, Embodiment 3 of this application provides a container escape detection device 600, which can be configured in a terminal such as a desktop computer, tablet computer, or smartphone.

[0079] like Figure 7 As shown, the container escape detection device 600 includes: The data acquisition unit 610 is used to collect raw process behavior data running in the container environment; The standardized event stream generation unit 620 is used to perform container environment adaptation processing on the original process behavior data and generate a standardized event stream carrying a container identifier. Escape behavior detection unit 630 is used to detect escape behavior in the standardized event stream based on a predefined container engine normal behavior rule library; The attack attribution graph generation unit 640 is used to aggregate the associated escape behaviors and generate an incremental attack attribution graph when the escape behavior is detected.

[0080] Specifically, the data acquisition unit 610 includes: The probe deployment subunit is used to deploy probes at the system kernel's call interface; the call interface includes a call entry point and an exit point; The security proxy interception subunit is used to monitor preset system call types through the probe; The credential validity verification subunit is used to extract the call context information of a system call event corresponding to a preset system call type when the probe captures such an event to form the raw process behavior data. The raw process behavior data includes a control group identifier used to identify the container environment to which the process belongs. The standardized event stream generation unit 620 includes: The container identifier acquisition subunit is used to parse the control group identifier in the process behavior data and obtain the corresponding container identifier according to the preset container identifier mapping table. The mapping relationship establishment subunit is used to establish the mapping relationship between process identifiers inside the container and process identifiers on the host machine, as well as the mapping relationship between virtual file paths inside the container and real file paths on the host machine. The file path conversion subunit is used to convert the process identifier inside the container into the host process identifier and the virtual file path inside the container into the real file path on the host machine according to the mapping relationship. The standardized event stream output subunit is used to output a standardized event stream carrying the container identifier, the host process identifier, and the actual path of the host machine.

[0081] The escape behavior detection unit 630 includes: The normal behavior rule library construction subunit is used to construct a predefined container engine normal behavior rule library; the container engine normal behavior rule library is used to characterize the legal operation mode within the container; An escape behavior capture subunit is used to match the standardized event stream with the container engine's normal behavior rule base to detect escape behavior in the standardized event stream; the escape behavior is an abnormal behavior that deviates from the legal operation mode.

[0082] The escape behavior capture subunit further includes: The whitelist verification module is used to detect the behavior of critical processes executing commands not listed in the whitelist. The sensitive file access detection module is used to detect the behavior of processes inside the container accessing sensitive files on the host machine; The socket behavior detection module is used to detect the behavior of processes within a container connecting to the container's managed sockets.

[0083] Attack attribution mapping generation unit 640 includes: The location subunit is used to trace back along the process relationship chain starting from the detected escape behavior to locate the source of the attack; the source of the attack is the root process of the container engine. An attack operation chain construction unit is used to construct an attack operation chain based on the root process of the container engine, associating the file modification nodes and network connection nodes of the escape behavior. The incremental attack attribution graph aggregation generation sub-unit is used to aggregate related escape behaviors within a dynamic time window to generate an incremental attack attribution graph containing complete attack paths.

[0084] The incremental attack attribution mapping aggregation generation subunit is also used for: When the number of alarms for the escape behavior exceeds a preset threshold within a preset time period, the time window is reduced. When the alarm associated with the escape behavior is cross-container, the time window is expanded.

[0085] The aforementioned container escape detection device 600 can be implemented as a computer program, which can, for example... Figure 8 It runs on the computer device shown.

[0086] Please see Figure 8 , Figure 8 This is a schematic block diagram of a computer device 500 provided in an embodiment of this application. The computer device 500 can be a terminal or a server. The terminal can be an electronic device with communication functions, such as a desktop computer, tablet computer, or smartphone. The server can be a standalone server or a server cluster composed of multiple servers.

[0087] See Figure 8 The computer device 500 includes a processor 502, a memory, and a network interface 505 connected via a system bus 501. The memory may include a non-volatile storage medium 503 and internal memory 504.

[0088] The non-volatile storage medium 503 may store an operating system 5031 and a computer program 5032. The computer program 5032 includes program instructions that, when executed, cause the processor 502 to perform a container escape detection method.

[0089] The processor 502 provides computing and control capabilities to support the operation of the entire computer device 500.

[0090] The internal memory 504 provides an environment for the execution of the computer program 5032 in the non-volatile storage medium 503. When the computer program 5032 is executed by the processor 502, the processor 502 can execute a container escape detection method.

[0091] This network interface 505 is used for network communication with other devices. Those skilled in the art will understand that... Figure 8 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device 500 to which the present application is applied. The specific computer device 500 may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0092] The processor 502 is used to run a computer program 5032 stored in a memory to implement the steps of the above method.

[0093] It should be understood that in the embodiments of this application, the processor 502 may be a central processing unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0094] It will be understood by those skilled in the art 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 includes program instructions and can be stored in a storage medium, which is a computer-readable storage medium. The program instructions are executed by at least one processor in the computer system to implement the process steps of the embodiments of the above methods.

[0095] Therefore, the present invention also provides a storage medium. This storage medium can be a computer-readable storage medium. The storage medium stores a computer program, wherein the computer program includes program instructions. When executed by a processor, the program instructions cause the processor to perform the steps of the above-described method.

[0096] The storage medium can be any computer-readable storage medium capable of storing program code, such as a USB flash drive, portable hard drive, read-only memory (ROM), magnetic disk, or optical disk.

[0097] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0098] In the several embodiments provided by this invention, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For example, the division of each unit is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.

[0099] The steps in the method of this invention can be adjusted, merged, or reduced in order according to actual needs. The units in the device of this invention can be merged, divided, or reduced according to actual needs. Furthermore, the functional units in the various embodiments of this invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0100] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a terminal, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention.

[0101] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method of container escape detection, characterized in that, The method comprises the following steps: S110, collecting original process behavior data running in a container environment; S120, performing container environment adaptation processing on the original process behavior data to generate a standardized event stream carrying a container identifier; S130, detecting an escape behavior in the standardized event stream based on a pre-defined container engine normal behavior rule library; S140, when the escape behavior is detected, aggregating the associated escape behavior and generating an incremental attack trace graph.

2. The container escape detection method of claim 1, wherein, S110 comprises: S111, deploying a probe at a call interface of a system kernel; the call interface comprises a call entry point and an exit point; S112, monitoring a preset system call type through the probe; S113, when the probe captures a call event corresponding to the preset system call type, extracting a call context information thereof to form the original process behavior data; the original process behavior data comprises a control group identifier for identifying a container environment to which a process belongs.

3. The container escape detection method according to claim 2, characterized in that, S120 comprises: S121, analyzing the control group identifier in the process behavior data, and obtaining a corresponding container identifier according to a pre-set container identifier mapping table; S122, establishing a mapping relationship between a container process identifier and a host process identifier, and a mapping relationship between a container virtual file path and a host real file path; S123, converting the container process identifier into the host process identifier and converting the container virtual file path into the host real file path according to the mapping relationship; S124, outputting a standardized event stream carrying the container identifier, the host process identifier and the host real path.

4. The container escape detection method according to claim 3, characterized in that, S130 comprises: S131, constructing a pre-defined container engine normal behavior rule library; the container engine normal behavior rule library is used to represent a legal operation mode in a container; S132, matching the standardized event stream with the container engine normal behavior rule library to detect an escape behavior in the standardized event stream; the escape behavior is an abnormal behavior deviating from the legal operation mode.

5. The container escape detection method of claim 4, wherein, S132 comprises: S1321, detecting a behavior of a key process executing a non-whitelist command; the whitelist command is defined by the container engine normal behavior rule library; S1322, detecting a behavior of a container process accessing a host sensitive file; S1323, detecting a behavior of a container process connecting a container management socket.

6. The container escape detection method of claim 5, wherein, S140 comprises: S141, taking the detected escape behavior as a starting point, backtracking along a process relationship chain to locate an attack initiation source; the attack initiation source is a container engine root process; S142, based on the container engine root process, associating a file modification node and a network connection node of the escape behavior to construct an attack operation chain; S143, aggregating the associated escape behavior in a dynamic time window to generate an incremental attack trace graph containing a complete attack path.

7. The container escape detection method of claim 6, wherein, In S143, the length of the dynamic time window is adjusted according to the characteristics of the escape behavior, comprising: when the number of alarms of the escape behavior in a unit preset time length exceeds a preset threshold, the time window is reduced; When the alert correlation of the escape behavior is cross-container, the time window is expanded.

8. A container escape detection apparatus characterized by, A computer device for executing the method according to any one of claims 1 to 7, comprising: a data collection unit configured to collect raw process behavior data running in a container environment; a standardized event stream generation unit configured to perform container environment adaptation processing on the raw process behavior data to generate a standardized event stream carrying a container identifier; an escape behavior detection unit configured to detect escape behavior in the standardized event stream based on a predefined container engine normal behavior rule library; an attack trace graph generation unit configured to aggregate the associated escape behavior and generate an incremental attack trace graph when the escape behavior is detected.

9. A computer device, comprising: The computer device comprises a memory and a processor connected to the memory; the memory is configured to store a computer program; and the processor is configured to run the computer program stored in the memory to execute the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The storage medium stores a computer program, and the computer program comprises program instructions which, when executed by a processor, can implement the steps of the method according to any one of claims 1 to 7.

Images