Container escape real-time detection method based on eBPF and knowledge graph

Abstract

The invention relates to a container escape real-time detection method based on an eBPF and a knowledge graph, and belongs to the field of network security. The method comprises the following steps: capturing multiple types of key events related to container escape in real time through a kernel-level probe by adopting an eBPF technology, and filtering irrelevant behaviors according to a preset triggering condition, extracting corresponding key information fields from the key events, and uniformly packaging the key information fields into a standard event structure; converting event data of the collected standard event structure into nodes and relationships in a container security knowledge graph, forming a semantic network representing a system operation state, and constructing the container security knowledge graph; and according to information in the container security knowledge graph, carrying out mapping analysis on a key event accessed in real time, and judging whether container escape occurs or not through predefined rule matching and abnormal behavior analysis. According to the method, implementation does not depend on a probe in a container, and eBPF deployment is convenient and fast; known mode recognition and unknown anomaly discovery are both considered, and missing report is reduced.

Description

Technical Field

[0001] This invention relates to the field of network security technology, and in particular to a real-time container escape detection method based on eBPF and knowledge graph. Background Technology

[0002] Containerization and cloud-native technologies have become the mainstream forms of computing infrastructure, with businesses being orchestrated at high speed and elastically in the form of microservices. Container escape is one of the most destructive runtime threats: attackers breach the container space and enter the host machine. Common methods include exploiting high-risk mounts and privileged configurations, abusing runtimes such as runc / containerd, executing critical system calls such as pivot_root / unshare, or combining kernel vulnerabilities (such as DirtyPipe) to tamper with critical host files and permission boundaries. Once an escape is successful, it will lead to lateral movement, persistence, and supply chain diffusion, making it difficult for traditional host-based auditing to timely and accurately depict its cross-boundary links.

[0003] eBPF (Extended Berkeley Packet Filter) is a sandbox virtual machine technology that runs in the Linux kernel. It allows users to dynamically inject custom programs into the kernel without modifying the kernel source code or loading kernel modules, enabling efficient monitoring, tracing, network filtering, and performance analysis of kernel behavior.

[0004] eBPF has been widely used in the cloud-native field for network and performance observability, and a few studies have begun to apply eBPF to container-related detection. However, overall, it still focuses on operational metrics and traffic observation, lacking systematic modeling oriented towards "escape semantics." Traditional security solutions based on container logs and static rules struggle to reliably obtain global context across hosts, containers, and processes, and are prone to latency, missing information, or tampering in high-concurrency and short-lifecycle environments, leading to insufficient identification of cross-boundary links. Container escape detection that relies solely on eBPF events faces the challenge of transforming a large number of discrete kernel-level observation points into interpretable, inferable, and reusable security semantics to support real-time, low-false-positive escape detection.

[0005] Container escape is one of the most destructive threats to cloud-native runtimes, essentially stemming from the attack process breaching container isolation and impacting the host machine. While eBPF is widely used in cloud-native environments, it primarily serves network and performance observability. Existing technologies attempt to apply eBPF to container-related security detection; however, they still lack systematic modeling of "escape semantics" and stable, interpretable detection paths. The shortcomings of existing technologies are mainly reflected in:

[0006] 1. Detection methods based on container logs / static rules / policy baselines:

[0007] (a) The observation perspective is fragmented, making it difficult to form an overall relationship across hosts, containers, processes, accounts and key resources, and making it impossible to stably restore the "cross-boundary link";

[0008] (b) In high-concurrency and short-lifecycle environments, log delays, missing logs, or log tampering are likely to occur, and key evidence is easily lost, making it difficult to control false alarms / missed alarms.

[0009] (c) Relying on static rule matching results in poor robustness to variations and unknown techniques, high rule maintenance costs, and weak portability.

[0010] 2. Detection method based directly on eBPF event stream:

[0011] (a) It mainly uses kernel event rule matching, which has low latency but a single-point event perspective, making it difficult to depict the global relationship across hosts, containers, processes and resources;

[0012] (b) Monitoring based on features such as capabilities / namespaces relies on preset selectors, which makes it difficult to cover multi-step, cross-domain links and variations;

[0013] (c) Events are mostly associated externally via logs / JSON, lacking native graph semantics, and the evidence chain and tracing mainly rely on external systems or manual rules.

[0014] 3. General behavioral statistics / machine learning and event correlation methods:

[0015] (a) Relying on a large number of samples and a stable baseline, cloud-native scenarios suffer from rapid data drift, high annotation costs, and unstable models.

[0016] (b) Insufficient explainability and controllability make it difficult to effectively inject safety expert knowledge to form a closed-loop engineering process.

[0017] (c) The computation and parameter tuning costs are high, making it difficult to run stably on high-frequency real-time streams. Summary of the Invention

[0018] The purpose of this invention is to at least address one of the aforementioned technical deficiencies.

[0019] Therefore, the purpose of this invention is to propose a real-time container escape detection method based on eBPF and knowledge graph, which achieves the goal of not relying on internal container probes and convenient eBPF deployment; it also takes into account both known pattern recognition and unknown anomaly detection, reducing false negatives.

[0020] To achieve the above objectives, embodiments of the present invention provide a real-time container escape detection method based on eBPF and knowledge graph, comprising:

[0021] S1 uses eBPF technology to capture multiple key events related to container escape in real time through kernel-level probes, and filters irrelevant behaviors according to preset trigger conditions. It extracts corresponding key information fields from the key events and encapsulates them into a standard event structure. The standard event structure includes: timestamp, process context, container context, event-specific fields, and risk level.

[0022] S2 transforms the collected event data with a standard event structure into nodes and relationships in a container security knowledge graph, forming a semantic network representing the system's operational state, including:

[0023] S21, standardize the event data, complete its semantics, and perform path normalization and context attribution determination;

[0024] S22, construct the core entities of the container security knowledge graph from the processed event data, which serve as nodes of the graph;

[0025] S23, establish attribution relationships, behavioral relationships, target relationships and temporal relationships for each node, which serve as edges of the graph;

[0026] S24. Construct a container security knowledge graph based on the nodes and edges of the obtained graph;

[0027] S3, based on the information in the container security knowledge graph, perform graph-based analysis on key events of real-time access, and determine whether container escape has occurred through predefined rule matching and abnormal behavior analysis, including:

[0028] S31. Select cross-domain and high-risk facts as anchor points according to the anchor point rules, and extract local subgraphs from the global graph centered on the anchor point events. The local subgraph Focus on the context of potential anomalies;

[0029] S32, for the local subgraph Perform similarity detection of known escape patterns and detection of behavioral baseline deviations, respectively;

[0030] S33, the detection results of similarity detection of known escape patterns and deviation from behavioral baseline are fused to obtain the fused total score. The total score of the fusion With preset threshold Comparison, if If container escape occurs, an alarm and a subgraph will be output. It is used as evidence for explanation and interpretation.

[0031] Furthermore, in S1, the various key events related to container escape include: container lifecycle and runtime control events, namespace and root switching events, permission and capability events, and file mount access events.

[0032] Furthermore, in S21, the event data is standardized, including: unifying and organizing the basic fields of the collected events, the basic fields including: event type, timestamp, process information and container clue;

[0033] Semantic completion of time data includes: completing key attributes of escape analysis, including execution scope, context migration, root directory change and access method.

[0034] Furthermore, in S21, the event data path is normalized, including: parsing aliases and symbolic links, and unifying the file path format;

[0035] Contextual attribution of event data includes: determining a unique container_id based on mount point, namespace, and container evidence chain.

[0036] Furthermore, in S23,

[0037] The attribution relationship indicates the dependency relationship between a process and a container;

[0038] The behavioral relationship represents the relationship between the occurrence of processes and events;

[0039] The target relationship represents the connection between the event and the object acting upon it;

[0040] The temporal relationship refers to the chronological order of events.

[0041] Furthermore, in S24, nodes and edges are grouped according to the same process and the same container in the same process dimension, and adjacent events are connected according to the occurrence time to construct a container security knowledge graph.

[0042] Furthermore, in S31, during the sliding time window... Within the graph, after events are standardized and written into the graph, cross-domain and high-risk facts are selected as anchor points according to preset anchor point rules. Centered on the anchor point event, the graph is expanded by a preset step size k along the time sequence before and after the same process chain or container, and directly connected process, file, and container events are retained to obtain candidate subgraphs. .

[0043] Furthermore, in S32, the local subgraph... Similarity calculations are performed on link samples with known escape patterns to identify whether there are event chains similar to known escape attacks, and a similarity score is generated. ;

[0044] For the local subgraph Detect behavioral baseline deviations, determine whether they are abnormal relative to historical data, and generate baseline deviation scores. .

[0045] Furthermore, the extracted subgraphs Perform matching analysis with a template library T of known container escape samples to calculate the subgraph. Template rating for each escape pattern in the template library ;

[0046] Take the highest template score as the similarity score. :

[0047] .

[0048] Furthermore, regarding subgraphs Calculate the frequency for each standardized suspicious event. Frequency of all suspicious events The frequency score F is obtained by unweighted aggregation;

[0049] The directed relationship between any two suspicious events is used as temporal evidence. If the time and process constraints are satisfied, an event pair is formed, and a rarity score is calculated for each event pair. Rarity score of all suspicious event pairs Aggregation yields time series fractions ;

[0050] Frequency score F and time series score The baseline deviation score is obtained by unweighted fusion. .

[0051] Compared with the prior art, the advantages and beneficial effects of the present invention are as follows:

[0052] This invention, without relying on internal container logs, focuses on the stable collection of eBPF runtime data for container escape detection. It uses a security knowledge graph to transform fragmented observations into structured "entity-relationship-time sequence" semantic carriers, explicitly expressing the hierarchy, affiliation, and interaction across hosts / containers / processes / critical resources. Based on this, a container escape detection method matching the graph structure is designed, incorporating expert priors in the form of path templates, weights, and constraints. It also combines metrics such as structural deviation and historical baselines to detect known and unknown variants and output subgraphs. Through a collaborative system of "eBPF targeted data collection—knowledge graph—container escape detection," it balances real-time performance, interpretability, and engineering scalability, forming a systematic solution for container escape detection.

[0053] 1. This invention does not rely on internal container probes, making eBPF deployment convenient. This invention only uses eBPF on the host machine to observe and standardize critical system calls / kernel functions, without needing to install an agent or collect application logs within the business container; it can obtain high-fidelity evidence and output traceable evidence subgraphs without relying on container logs.

[0054] 2. This invention organizes security semantics using a knowledge graph, resulting in a clear structure that can incorporate escape knowledge. By unifying discrete events into a knowledge graph, key semantics such as cross-context switching, root directory changes, and host-sensitive access can be directly queried and reused on the graph.

[0055] 3. This invention combines known pattern recognition with the detection of unknown anomalies, reducing false negatives. It simultaneously performs two types of detection on the image: template similarity and behavioral baseline deviation.

[0056] 4. This invention outputs a "minimum evidence subgraph," which is complete in key links and highly interpretable. The alarm result carries a minimum evidence subgraph consisting of anchor events, process sequence (NEXT_EVENT), and affected targets (EVENT_TARGET), intuitively presenting the critical path of "condition-action-result";

[0057] 5. This invention retains the interpretability and controllability of expert knowledge, while also possessing the ability to discover variants and zero-days, thus forming a system advantage in terms of accuracy, real-time performance, and engineering scalability.

[0058] Additional aspects and advantages of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

[0059] The above and / or additional aspects and advantages of the present invention will become apparent and readily understood from the description of the embodiments taken in conjunction with the following drawings, in which:

[0060] Figure 1 This is a flowchart of a real-time container escape detection method based on eBPF and knowledge graph according to an embodiment of the present invention;

[0061] Figure 2 This is a schematic diagram of the data acquisition structure according to an embodiment of the present invention;

[0062] Figure 3 To construct a logical graph for the knowledge graph according to embodiments of the present invention;

[0063] Figure 4 This is a schematic diagram of the container safety knowledge graph structure according to an embodiment of the present invention;

[0064] Figure 5This is a schematic diagram of the overall detection method and data flow according to an embodiment of the present invention;

[0065] Figure 6 This is a schematic diagram illustrating the escape of a dangerous vehicle according to an embodiment of the present invention. Detailed Implementation

[0066] Embodiments of the present invention are described in detail below, examples of which are illustrated in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain the present invention, and should not be construed as limiting the present invention.

[0067] This invention proposes a real-time container escape detection method based on eBPF and a knowledge graph, relating to the field of network security, particularly container security. The method utilizes container escape data collected by eBPF to construct a security knowledge graph and a corresponding container escape detection algorithm, enabling real-time monitoring and analysis of escape threats during container operation.

[0068] This invention uses a knowledge graph to structure fragmented runtime signals into a "entity-relationship" security semantic carrier, uniformly expressing the hierarchy, affiliation, and interaction between hosts, containers, processes, events, and critical resources. Based on this, this invention implements similarity detection using known escape pattern templates and anomaly detection methods based on the historical structure of container graphs.

[0069] like Figure 1 As shown in the figure, the real-time container escape detection method based on eBPF and knowledge graph of this invention includes:

[0070] S1 uses eBPF technology to capture multiple key events related to container escape in real time through kernel-level probes, and filters irrelevant behaviors according to preset trigger conditions, extracts corresponding key information fields from key events, and encapsulates them into a standard event structure.

[0071] Specifically, this invention employs eBPF technology to embed probes in the kernel, deploying eBPF probes only on the host machine side to observe kernel interfaces highly relevant to container escape. For example, it observes process execution, namespace switching, root directory changes, mounting, access to sensitive files, and capability authentication. Then, it captures multiple key events related to container escape in real time.

[0072] In this invention, four key events related to container escape are captured in real time: container lifecycle and runtime control events, namespace and root switching events, permission and capability events, and file mount access events.

[0073] 1. Container lifecycle and runtime control

[0074] The `sys_enter_execve` function matches management commands such as `docker`, `podman`, `containerd`, `runc`, and `chroot`, focusing on the container startup and management process. When the command name is `runc`, the container ID, configuration path, and key parameters are further parsed, and the underlying container identifier is obtained by combining the startup parameters of the `containerd-shim` process. By associating and merging these multi-source clues at the collection end, it is ensured that any subsequent kernel events can be accurately anchored to the correct container instance and host environment.

[0075] 2. Namespace and Root Switching

[0076] For critical cross-boundary actions, the behavior of creating a new mount namespace is captured in sys_exit_unshare, and the behavior of adding an existing namespace is captured in sys_exit_setns. Details such as the target namespace type, target inode, and file descriptor are recorded simultaneously.

[0077] During the data collection phase, an attempt is made to reverse-engineer the target namespace's ownership, mapping it to a specific host or other container context, and marking whether a cross-context switch has occurred. Simultaneously, the new and old root paths are recorded on `sys_enter_chroot` and `sys_enter_pivot_root`, preserving the original paths and the actual resolved locations to verify whether the root switch points to the host file system. Through this set of events, out-of-bounds (`setns`) and root modification (`chroot / pivot_root`) form a self-verifying chain, providing strong evidence for subsequent rule matching and anomaly detection.

[0078] 3. Permissions and Capabilities

[0079] To reconstruct the preconditions for escape, process information is collected on `sys_enter_setuid` and `sys_enter_setreuid`. Simultaneously, only authentication requests for high-risk capabilities such as `CAP_SYS_ADMIN`, `CAP_SYS_MODULE`, and `CAP_SYS_CHROOT` are retained at `kprobe:cap_capable`. By sequentially linking privilege escalation and capability acquisition with subsequent events such as mounting, namespace switching, and root switching, a "condition-action-result" chain is formed, improving the interpretability and reliability of subsequent decisions.

[0080] 4. File / Mount Access

[0081] To address the impact of escape landings, unconventional mount operations are recorded in `sys_enter_mount` (filtering common system mounts), retaining the source, target, type, and flags. `sys_enter_openat` performs strict matching for sensitive paths such as ` / etc / shadow`, ` / etc / sudoers`, and ` / var / run / docker.sock`. Furthermore, `sys_enter_splice` preserves relevant call characteristics for DirtyPipe exploits. The data acquisition end combines the current process's mount namespace and path resolution to determine the file ownership scope (host / container / unknown) for each access, thus clarifying whether "the container has accessed host resources" before the data enters the graph, aligning the consequential evidence with the aforementioned pre-access / boundary-crossing actions on the timeline.

[0082] like Figure 2 As shown, each event collection point corresponds to a specific system call or kernel function, which is mounted via tracepoint or kprobe. Trigger conditions are set to filter irrelevant behaviors (e.g., using white / black lists, path / command filtering), and key information fields are extracted and uniformly encapsulated into a standard event structure.

[0083] In this invention, the triggering conditions vary depending on the runtime environment. Experiments revealed that some system calls generate a lot of irrelevant logs. For example, `execve` only needs to focus on commands like `docker|runc|containerd-shim`. It should be noted that the key information fields differ for different event types. All event fields consist of a unified field plus specific fields.

[0084] The standard event structure of this invention includes: timestamp, process context, container context, event-specific fields, and risk level. All events uniformly include timestamp, process context (process ID, process name, parent process, etc.), container context (container identifier, name, image, etc.), as well as event-specific fields and risk level, which standardizes the processing of raw kernel events and facilitates subsequent analysis.

[0085] The purpose of risk levels: Because a large number of logs are collected, the logs are classified as follows: 1. CRITICAL: Strong evidence behavior, such as chrooting to the host machine;

[0086] 2. HIGH: May serve as a prerequisite for escape, such as a change in permissions; 3. MEDIUM: Container-related logs, such as container management and file mounting; 4. LOW: Other logs. The risk levels of this invention can provide data support for the implementation of subsequent anchor events.

[0087] S2 converts the collected event data in a standard event structure into nodes and relationships in a container security knowledge graph, forming a semantic network representing the system's operating status.

[0088] This step transforms the discrete events collected by S1 into a semantic network of "host-container-process-event-resource". The graph only carries objective facts and does not directly detect escape.

[0089] The structure of the container safety knowledge graph will be explained below.

[0090] First, let's explain the node types in the graph:

[0091] 1. Host: Represents the host machine currently running the container environment. Table 1 shows the attribute names and descriptions of Host.

[0092] Table 1

[0093]

[0094] 2. Container: Represents a running container instance. Table 2 shows the attribute names and descriptions of Container.

[0095] Table 2

[0096]

[0097] 3. Process: Represents a process within a container or host machine, uniquely identified by a combination of (pid, container_id). Table 3 lists the attribute names and descriptions for Process.

[0098] Table 3

[0099]

[0100] 4. File: Represents file resources in the system, including files within containers and on the host machine. Table 4 shows the attribute names and descriptions for File.

[0101] Table 4

[0102]

[0103] 5. Event: A unified entity that carries system calls / commands / actions; different types are distinguished by event_type. Table 5 lists the attribute names and descriptions of Event.

[0104] Table 5

[0105]

[0106] The container safety knowledge graph is organized according to the "attribution-behavior-target-time sequence". Table 6 shows the relationship types of the graph.

[0107] Table 6

[0108]

[0109] The descriptions of each relation type are as follows:

[0110] (1) Attribution (HOST_HAS_CONTAINER, PROCESS_IN_CONTAINER, EVENT_IN_CONTAINER) determines the attribution of an event to a subject / context;

[0111] (2) The behavior (PROCESS_PERFORMED_EVENT) records "who did what";

[0112] (3) The target (EVENT_TARGET) points to the file / container resource being accessed;

[0113] (4) The time series (NEXT_EVENT) is grouped by (pid, container_id) in the same process dimension, and a singly linked list is built for adjacent events according to timestamp_ns. The edges are only connected within the same subject / context and do not cross processes or containers.

[0114] like Figure 3 As shown, based on the structure of the container security knowledge graph, this invention stably converts the discrete kernel events collected by S1 into an objective fact graph of "host-container-process-event-resource", explicitly depicting four types of relationships: attribution, behavior, target, and timing.

[0115] S21 standardizes and semantically completes the event data, and performs path normalization and context attribution determination.

[0116] In this step, the event data is standardized, including: unifying and organizing the basic fields of the collected events. The basic fields include: event type, timestamp, process information (pid / ppid / comm) and container clues (cgroup / runtime / ns).

[0117] Semantic completion is performed on the time data, including: completing key attributes for escape analysis, such as execution scope (exec_scope), context transition (transition), root directory change (new_root / put_old), and access mode (access_mode).

[0118] Event data paths are normalized, including resolving aliases and symbolic links, and standardizing file path formats.

[0119] Context attribution determination is performed on event data, including: determining a unique container_id based on mount point, namespace, and container evidence chain.

[0120] This invention determines the container or host environment to which each event belongs by normalizing event paths and merging namespaces and container identifiers, and registers new containers immediately upon discovery. Runtime facts are stored in a structured manner: "host—container—process—event—resource".

[0121] S22, construct the core entities of the container security knowledge graph from the processed event data, and use them as nodes of the graph.

[0122] In this step, five core entities are created: Host, Container, Process, File, and Event.

[0123] S23 establishes attribution, behavior, target, and temporal relationships for each node, which serve as edges in the graph.

[0124] In this invention, the attribution relationship represents the subordinate relationship between a process and a container, the behavior relationship represents the generation relationship between a process and an event, the target relationship represents the connection relationship between an event and its target object, and the temporal relationship represents the chronological order of events.

[0125] S24. Construct a container security knowledge graph based on the nodes and edges of the obtained graph.

[0126] Specifically, within the same process dimension, nodes and edges are grouped according to the same process and the same container, and adjacent events are connected according to their occurrence time to construct a container security knowledge graph.

[0127] The above method is used to construct, as follows Figure 4 The container security knowledge graph shown is continuously updated with all event and entity data. The uniqueness constraint of nodes and the contextual attribution logic ensure data consistency and lay the foundation for subsequent graph-based escape detection algorithms: it can conveniently query all related behaviors of a container / process, and can also use the graph structure and historical baselines to discover anomalies.

[0128] S3 performs graph-based analysis on key events that are accessed in real time based on information in the container security knowledge graph. Through predefined rule matching and abnormal behavior analysis, it determines whether container escape has occurred.

[0129] like Figure 5As shown, this invention utilizes information provided by a knowledge graph to perform graph-based analysis of real-time eBPF events. By combining predefined rule matching and abnormal behavior analysis, it determines whether container escape occurs, thereby identifying typical escape links and detecting unknown attacks. It should be noted that detecting escape links and detecting unknown attacks are the same process. Because some escape techniques exploit Linux kernel vulnerabilities, this invention has a significant advantage over rule-based matching of kernel vulnerability features if new kernel vulnerabilities emerge.

[0130] S31. Select cross-domain and high-risk facts as anchor points according to the anchor point rules, and extract local subgraphs from the global graph centered on the anchor point events. Local subgraph Focus on the context of potential anomalies.

[0131] In the sliding time window Within the graph, after events are standardized and written into the graph, cross-domain and high-risk events (such as namespace switching, root directory changes, sensitive mounts, sensitive read / write operations on the host) are selected from the global graph according to preset anchor point rules as anchor points. Centered on the anchor point event, the graph is expanded forward and backward along the same process chain or container time sequence by a preset step size k, while retaining directly connected process, file, and container events, thus obtaining candidate subgraphs. It should be noted that, if necessary, multiple anchor points can be merged within the same container to construct a subgraph to be analyzed. .

[0132] Specifically, in the sliding time window Within the graph, after events are standardized and written into the graph, cross-domain / high-risk events are first selected as anchor points according to rules, including: namespace switching (SETNS_SYSCALL); privilege escalation (such as PRIVILEGE_ESCALATION_SETUID); root file system changes (PIVOT_ROOT_OPERATION, CHROOT_SYSCALL); sensitive mounts / sensitive file read / write, etc. ( / var / run / docker.sock, host authentication files, etc.).

[0133] Then, taking the anchor point (cross-boundary fact) event as the center, expand k steps (default k=8) before and after the NEXT_EVENT of the same process chain or container, and retain the Process / File / Container events directly connected to it to obtain the candidate subgraph. .

[0134] It should be noted that when multiple related anchors exist within a short period of time (triggered by different processes in the same container), it is permissible to merge subgraphs through common container nodes to fully cover the same escape context.

[0135] S32, for local subgraphs Similarity detection of known escape patterns and deviation from behavioral baseline are performed separately.

[0136] (1) For local subgraphs Similarity calculations are performed on link samples with known escape patterns to identify whether there are event chains similar to known escape attacks, and a similarity score is generated. .

[0137] Maintain an extensible escape pattern example library (with steps and order as core features). For each evidence subgraph, compare the steps according to their meaning and order of occurrence, and provide similarity and hit details to quickly identify known typical escape paths and their variations.

[0138] Specifically, for the extracted subgraph Pattern matching analysis is performed to evaluate its similarity to known container escape attack chain samples. Internally, a template library of known container escape samples is maintained, with each escape pattern... This is a sequence of event steps ordered by time.

[0139] Each step It corresponds to one Event.event_type, and is accompanied by a small number of field constraints (e.g., command_name, / argv, / access_mode, / is_cross_context, / ns_type_name, etc.) and relationships (e.g., EVENT_TARGET or EVENT_IN_CONTAINER, etc.).

[0140] For subgraph For each escape mode Find an ordered mapping such that adjacent steps of the template appear sequentially in NEXT_EVENT, allowing a span of no more than [number missing]. For each irrelevant event, calculate the following for the matched steps:

[0141] Order consistency rate The percentage of adjacent steps appearing in sequence;

[0142] Attribute Hit Rate The percentage of entries that satisfy the field constraints;

[0143] Relationship hit rate : The percentage of items that satisfy relational assertions.

[0144] Based on experience, a weighted sum is used, and the weights are set as follows: Computational subgraph Template rating for each escape pattern in the template library :

[0145] (1)

[0146] Take the highest template score as the similarity score:

[0147] (2)

[0148] It should be noted that, The value is not limited to the examples above and can be set as needed.

[0149] (2) For local subgraphs Detect behavioral baseline deviations, determine whether they are abnormal relative to historical data, and generate baseline deviation scores. .

[0150] Maintain a historical baseline based on the container dimension, and evaluate the deviation of the current subgraph from historical behavior from both frequency and temporal perspectives. For the subgraph... Calculate the frequency for each standardized suspicious event. Frequency of all suspicious events The frequency score F is obtained by unweighted aggregation; the directed relationship between any two suspicious events is used as temporal evidence. If the time and process constraints are satisfied, an event pair is formed, and a rarity score is calculated for each event pair. Rarity score of all suspicious event pairs Aggregation yields time series fractions ; Combine frequency score F with time series score The baseline deviation score is obtained by unweighted fusion. .

[0151] Specifically, this invention performs historical baseline deviation analysis to evaluate subgraphs from the perspective of statistical anomaly detection. The degree of anomaly. The system maintains a historical cumulative count of escape-related behaviors for each container, measuring the anomaly relative to the history from both frequency and time-series perspectives. Define a deterministic mapping. Suspicious events in the subgraph Merge into a unique key.

[0152] A. Host Reach

[0153] (3)

[0154] HT: Represents a host-triggered event, expressed as a string, and so on.

[0155] : Indicates the event's reach path

[0156] This represents a deterministic mapping, where the same input events HT and The same result will be obtained, but different e.file_paths will produce different results.

[0157] B. Boundary relocation

[0158] (4)

[0159] SETNS: indicates a namespace switching event. Indicates which namespace to switch to. This indicates whether a boundary has been crossed.

[0160] CHROOT: Indicates a process root directory change event. Indicates a new path.

[0161] PIVOT_ROOT: Indicates a root file system switch event. Indicates a new root. This is the location where the old directory is mounted.

[0162] MOUNT: Indicates a mount event. Indicates the file type. Indicates the mount path.

[0163] Each type of event is calculated and maintained separately. Let the set of events appearing in this subgraph be denoted as .

[0164] (5)

[0165] Subgraph All events in the process are standardized, with host reach and boundary migration events being defined as follows: , forming a set

[0166] Standardized suspicious events Statistical count

[0167] (6)

[0168] And maintain online monitoring of suspicious events within the same container. The historical cumulative total is :

[0169] (7)

[0170] The following analysis examines frequency and time series separately:

[0171] Given the single responsibility of containers in a microservices scenario, a greater number of such instances in the past often indicates an anomaly. Similarly, consider processing each standardized suspicious event. Perform frequency calculations separately:

[0172] (8)

[0173] All suspicious events The score is obtained by unweighted aggregation:

[0174] (9)

[0175] It should be noted that if a specific action (such as "reading / etc / shadow" or "chrooting to / host-root") has a very rare history but occurs frequently in this instance, then its... A higher score directly increases the frequency score. If multiple keys are abnormal simultaneously, the product term decreases further, reflecting the cumulative risk. , .

[0176] Any two suspicious events The directed relationship between them serves as temporal evidence. Event pairs are formed and included in the temporal score if the time and process constraints are satisfied. The occurrence of event pairs in the current instance and their historical rarity for that container are statistically analyzed. For each... Searching for the most recent predecessor event within the same container ,satisfy:

[0177] 1. Time constraints: Only closely related temporal relationships are valuable. Here, i and j represent the order of time. Represents the first event, Events that occurred after the representative Indicates the time when the event occurred.

[0178] 2. Process constraints (one of the following is sufficient):

[0179] (1) Same process: Backtrack along NEXT_EVENT, allowing a span of no more than 1000 steps. irrelevant events (default) =3);

[0180] (2) Parent and child processes: Each process chain is backtracked / forwarded and the same time window and hop count constraints are applied.

[0181] If the conditions are met, then directed event pairs are formed. Each Only the most recent predecessor is retained, and the set of event pairs that are hit in this instance is denoted as . For each Count And maintain the historical accumulation of the same container. Calculate the rarity score.

[0182] (10)

[0183] Aggregate all suspicious event pairs to obtain a score:

[0184] (11)

[0185] Fuse frequency and time-series evidence in an unweighted manner:

[0186] (12)

[0187] S33, the detection results of similarity detection of known escape patterns and deviation from behavioral baseline are fused to obtain the fused total score. The total score will be integrated. With preset threshold Comparison, if If container escape occurs, an alarm and a subgraph will be output. It is used as evidence for explanation and interpretation.

[0188] Specifically, similarity will be divided Deviation from baseline Combined into the final total score:

[0189] (13)

[0190] (14)

[0191] like Output: and evidence sub-graph .

[0192] In summary, the method of this invention employs eBPF data acquisition, container security knowledge graph construction, and container escape detection. The specific process is as follows:

[0193] 1) Deploy eBPF probes only on the host machine side to observe kernel interfaces that are highly related to container escape (such as process execution, namespace switching, root directory changes, mounting, access to sensitive files, capability authentication, etc.).

[0194] 2) Perform path normalization and namespace and container identifier merging on events to determine the container or host environment to which each event belongs, and register it immediately when a new container is discovered. Store runtime facts in a structured manner of "host—container—process—event—resource".

[0195] 3) Mark cross-domain or high-risk actions (such as namespace switching, root directory changes, sensitive mounts, host sensitive read / write, etc.) as anchors; extend several steps forward / backward around the anchors in the time chain of the same process, and merge multiple anchors in the same container if necessary to construct the subgraph to be analyzed.

[0196] 4) Maintain a scalable escape pattern example library (with steps and sequence as core features). For each evidence subgraph, compare the steps according to their meaning and order of appearance, and provide similarity and hit details to quickly identify known typical escape paths and their variations.

[0197] 5) The case container dimension maintains a historical baseline, assessing the degree of deviation between the current subgraph and historical behavior from both frequency and temporal perspectives. This result is then combined with the results of "known pattern recognition" to form a unified risk score.

[0198] 6) When the risk score exceeds the threshold, output an alarm and the minimum evidence subgraph.

[0199] The following is for reference. Figure 6 The method of the present invention will be described using a dangerous vehicle escape as an example.

[0200] Container C1 has a dangerous mount of / var / run / docker.sock. An attacker could use this mount configuration within C1 to control the host Docker container, create a privileged container C2 and mount it to the host root directory; after performing a root switch within C2, the attacker could read sensitive files on the host container and escape.

[0201] (1) Anchor point and subgraph generation

[0202] The system hit two dangerous anchor mounts (E1) and a root switch to / host (E2) within the window, and extracted a subgraph based on the process event chain around P2. And merged into the same evidence context through the E0→C2 link.

[0203] (2) Container escape detection

[0204] The "mount → chroot" link was hit, perfectly matching the pattern of dangerous mount escape, with extremely high similarity. Furthermore, in the C2 container, both the mount to / host and chroot actions were occurring for the first time, resulting in a very high anomaly score. Ultimately, the fusion score exceeded the threshold, and the system determined it to be container escape, ultimately outputting a subgraph. Related scores.

[0205] In the description of this specification, references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0206] It will be readily understood by those skilled in the art that this invention includes any combination of the inventive description and specific embodiments outlined in the foregoing specification, as well as the various parts shown in the accompanying drawings. Due to space limitations and for the sake of brevity, not all of these combinations have been described in detail. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

[0207] Although embodiments of the present invention have been shown and described above, it is to be understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of the present invention without departing from the principles and spirit of the invention. The scope of the present invention is defined by the appended claims and their equivalents.

Claims

1. A real-time container escape detection method based on eBPF and knowledge graph, characterized in that, include: S1 uses eBPF technology to capture multiple key events related to container escape in real time through kernel-level probes, and filters irrelevant behaviors according to preset trigger conditions. It extracts corresponding key information fields from the key events and encapsulates them into a standard event structure. The standard event structure includes: timestamp, process context, container context, event-specific fields, and risk level. S2 transforms the collected event data with a standard event structure into nodes and relationships in a container security knowledge graph, forming a semantic network representing the system's operational state, including: S21, standardize the event data, complete its semantics, and perform path normalization and context attribution determination; S22, construct the core entities of the container security knowledge graph from the processed event data, which serve as nodes of the graph; S23, establish attribution relationships, behavioral relationships, target relationships and temporal relationships for each node, which serve as edges of the graph; S24. Construct a container security knowledge graph based on the nodes and edges of the obtained graph; S3, based on the information in the container security knowledge graph, perform graph-based analysis on key events of real-time access, and determine whether container escape has occurred through predefined rule matching and abnormal behavior analysis, including: S31. Select cross-domain and high-risk facts as anchor points according to the anchor point rules, and extract local subgraphs from the global graph centered on the anchor point events. The local subgraph Focus on the context of potential anomalies; S32, for the local subgraph Perform similarity detection of known escape patterns and detection of behavioral baseline deviations, respectively; S33, the similarity detection results of known escape patterns and the detection results of behavioral baseline deviation are fused to obtain the fused total score. The total score of the fusion With preset threshold Comparison, if If container escape occurs, an alarm and a subgraph will be output. It is used as evidence for explanation and interpretation.

2. The real-time container escape detection method based on eBPF and knowledge graph according to claim 1, characterized in that, In S1, the various key events related to container escape include: container lifecycle and runtime control events, namespace and root switching events, permission and capability events, and file mount access events.

3. The real-time container escape detection method based on eBPF and knowledge graph according to claim 1, characterized in that, In S21, the event data is standardized, including: unifying and organizing the basic fields of the collected events, which include: event type, timestamp, process information and container clues; Semantic completion of time data includes: completing key attributes of escape analysis, including execution scope, context migration, root directory change and access method.

4. The real-time container escape detection method based on eBPF and knowledge graph according to claim 1, characterized in that, In S21, event data paths are normalized, including: resolving aliases and symbolic links, and unifying file path formats; Contextual attribution of event data includes: determining a unique container_id based on mount point, namespace, and container evidence chain.

5. The real-time container escape detection method based on eBPF and knowledge graph according to claim 1, characterized in that, In S23, The attribution relationship indicates the dependency relationship between a process and a container; The behavioral relationship represents the relationship between the occurrence of processes and events; The target relationship represents the connection between the event and the object acting upon it; The temporal relationship refers to the chronological order of events.

6. The real-time container escape detection method based on eBPF and knowledge graph according to claim 1, characterized in that, In S24, nodes and edges are grouped according to the same process and the same container in the same process dimension, and adjacent events are connected according to the occurrence time to construct a container security knowledge graph.

7. The real-time container escape detection method based on eBPF and knowledge graph according to claim 1, characterized in that, In S31, in the sliding time window Within the graph, after events are standardized and written into the graph, cross-domain and high-risk facts are selected as anchor points according to preset anchor point rules. Centered on the anchor point event, the graph is expanded by a preset step size k along the time sequence before and after the same process chain or container, and directly connected process, file, and container events are retained to obtain candidate subgraphs. .

8. The real-time container escape detection method based on eBPF and knowledge graph according to claim 1, characterized in that, In S32, the local subgraph Similarity calculations are performed on link samples with known escape patterns to identify whether there are event chains similar to known escape attacks, and a similarity score is generated. ; For the local subgraph Detect behavioral baseline deviations, determine whether they are abnormal relative to historical data, and generate baseline deviation scores. .

9. The real-time container escape detection method based on eBPF and knowledge graph according to claim 8, characterized in that, For the extracted subgraph Perform matching analysis with a template library T of known container escape samples to calculate the subgraph. Template rating for each escape pattern in the template library ; Take the highest template score as the similarity score. : 。 10. The real-time container escape detection method based on eBPF and knowledge graph according to claim 8, characterized in that, For subgraph Calculate the frequency for each standardized suspicious event. Frequency of all suspicious events The frequency score F is obtained by unweighted aggregation; The directed relationship between any two suspicious events is used as temporal evidence. If the time and process constraints are satisfied, an event pair is formed, and a rarity score is calculated for each event pair. Rarity score of all suspicious event pairs Aggregation yields time series fractions ; Frequency score F and time series score The baseline deviation score is obtained by unweighted fusion. .

Images