Automated fine-grained log labeling method

Abstract

This application relates to an automated fine-grained log annotation method, comprising: running a preset attack scenario and collecting log information including unannotated logs, alignment information logs, delimiter logs, attack flags, and attack logs based on the running results; constructing an initial source map based on audit logs in the alignment information logs; associating application logs and traffic logs with audit logs using the alignment information logs; identifying anchor points in the initial source map based on the association results using attack flags and attack logs; dividing nodes in the initial source map that meet preset segmentation conditions into multiple execution units using delimiter logs to obtain a refined source map; connecting all anchor points based on the refined source map to form an attack sub-graph; and obtaining annotated logs based on the attack sub-graph. This reduces the workload of manual annotation, enables simultaneous annotation of traffic, audit, and application logs, achieves precise annotation of individual log entries, and ensures the accuracy and completeness of annotation.

Description

Technical Field

[0001] This application relates to the field of network security technology, and in particular to an automated fine-grained log annotation method. Background Technology

[0002] In recent years, Advanced Persistent Threats (APTs) have become a significant concern in the cybersecurity field. These persistent and targeted attacks are typically planned and carried out by well-funded and well-organized groups, and are known for their long-term and covert nature. Attackers often remain lurking within the victim's network for extended periods, using intermediary hosts to expand the attack's reach or steal sensitive data.

[0003] Log analysis techniques are crucial for detecting, preventing, and tracking APT attacks. For example, network-based intrusion detection systems (NIDS) detect anomalies at the network layer by analyzing network traffic logs. System-level audit logs are used to create source maps for post-attack anomaly detection and forensic analysis. Application logs, such as web server logs, provide high-level insights into attack methods. These techniques all rely on large log datasets, which are essential for training models, evaluating performance, and benchmarking. The effectiveness of these processes is highly dependent on the quality of log annotations.

[0004] Existing automatic log labeling methods typically fail to meet these requirements:

[0005] Time-window-based method: This method uniformly labels all log entries within a specific time window as attack behavior. Since APT attacks often disguise themselves as normal activities, the labeling granularity of this method is too coarse, leading to insufficient accuracy of the results.

[0006] Behavioral Profiles (BP) annotation methods, based on behavioral models, automatically generate normal and attack traffic by simulating network behavior characteristics, allowing for direct annotation during traffic generation. However, this method cannot annotate real traffic and cannot be applied to audit logs and application logs.

[0007] Detection-based methods utilize cybersecurity tools, such as sniffers and honeypot systems, to identify and label attack behaviors. However, the accuracy and completeness of this method's labeling are highly dependent on the performance of the detection tools, and it cannot guarantee that all attack-related logs are accurately identified and recorded.

[0008] Rule-based matching methods: Traditional methods annotate logs by matching rules such as IP addresses line by line. The Kyoushi method optimizes this by combining the context and sequence of events to improve matching accuracy. However, the Kyoushi method still requires a significant amount of manual input: each trace left by an APT attack from each data source requires a separate matching rule, resulting in a very large number of rules and a heavy reliance on domain knowledge; moreover, it is difficult to prove the accuracy and completeness of the annotation rules. Summary of the Invention

[0009] This application provides an automated fine-grained log annotation method to address the problems of current automatic log annotation methods, such as coarse granularity, insufficient coverage of different log types, and excessive reliance on manual work and domain expertise.

[0010] The first aspect of this application provides an automated fine-grained log annotation method, comprising the following steps: running a preset attack scenario and collecting log information including unannotated logs, alignment information logs, delimiter logs, attack flags, and attack logs based on the running results; constructing an initial source map based on the audit logs in the alignment information logs, associating application logs and traffic logs with the audit logs using the alignment information logs, and identifying anchor points in the initial source map based on the association results using the attack flags and the attack logs; dividing nodes in the initial source map that meet preset segmentation conditions into multiple execution units using the delimiter logs to obtain a refined source map, connecting all anchor points based on the refined source map to form an attack sub-graph, and obtaining annotated logs based on the attack sub-graph.

[0011] Optionally, associating the application logs and traffic logs with the audit logs using the alignment information logs includes: disabling the application's buffer, injecting the timestamp and thread ID from the alignment information logs into the application logs to obtain the modified application and the modified application logs; executing the modified application to regenerate the alignment information logs, and using the timestamp and thread ID from the regenerated alignment information logs to establish an association between the modified application logs and the audit logs.

[0012] Optionally, associating the application logs and traffic logs with the audit logs using the alignment information logs further includes: obtaining the timestamps and four-tuple information for each TCP connection and UDP session in the traffic logs, and obtaining the four-tuple information in the audit logs; based on the UDP session timestamps and four-tuple information in the traffic logs, searching in the audit logs for network system calls that are closest to the UDP session timestamps and four-tuple information in the traffic logs; and within the lifetime of the traffic file descriptor corresponding to the closest network system call, batch matching all system calls with the same four-tuples to establish the association between the traffic logs and the audit logs.

[0013] Optionally, the step of identifying anchor points in the initial source map using the attack flag and the attack log includes: using a preset attack flag scanner to detect all IP addresses and the addresses corresponding to the scenario reversal in the attack scenario; identifying connections in the IP address header of the traffic log with reserved bits set to 1, and marking the connections in the IP address header with reserved bits set to 1 as anchor points in the traffic log.

[0014] Optionally, the step of identifying anchor points in the initial source map using the attack flag and the attack log further includes: integrating a preset kernel module to hook into system calls and injecting the attack flag into the attack payload; intercepting system calls using a preset attack flag scanner, restoring the attack payload to its pre-attack state, and executing the restored attack payload; identifying system call parameters with attack flags in the audit log, and marking the corresponding log entries in the audit log as anchor points based on the system call parameters with attack flags.

[0015] Optionally, when no anchor point is identified in the initial source graph, the method includes: recording the attacker's behavior log, wherein the behavior log includes a timestamp, attack parameters, and a preset matching rule; refining the scope of the preset matching rule using the timestamp, and detecting the attack log signature by combining the attack parameters and the preset matching rule, considering event combinations, context, and attack parameters; and identifying the anchor point in the initial source graph based on the attack log signature.

[0016] Optionally, when connecting all anchor points based on the refined source graph to form an attack subgraph, the process includes: constructing a handler derivation tree; determining handlers with shared derivation relationships through the handler derivation tree, and classifying system calls in the handlers with shared derivation relationships as belonging to the same execution unit.

[0017] Optionally, when connecting all anchor points based on the refined source map to form an attack subgraph, the process includes: constructing an initial handler tree; evaluating the number of accept calls in each subtree of the initial handler tree, and deleting nodes with an accept call count greater than or equal to a preset number to obtain a target handler tree, so as to define different execution units according to the target handler tree.

[0018] Optionally, the step of connecting all anchor points based on the refined source graph to form an attack subgraph, and obtaining labeled logs based on the attack subgraph, includes: processing nodes without outgoing edges in reverse topological order based on the refined source graph; maintaining a set for each node and updating the set for each new node; obtaining all marked path edges by taking the union of the sets of all direct successor nodes and subtracting all intersections, wherein if a node is a starting point, all paths originating from the starting point are marked, and the set of each node is adjusted to obtain all marked path edges; and connecting all marked path edges to form the attack subgraph.

[0019] Optionally, after forming the attack subgraph, the process includes: checking whether all anchor points in the refined source map have been connected to form an attack path; if there are unconnected anchor points, determining the location of the unconnected anchor points and prompting the user to add them.

[0020] In the above implementation, a preset attack scenario is run, and log information including unlabeled logs, alignment information logs, delimiter logs, attack flags, and attack logs is collected based on the running results. An initial source map is constructed based on the audit logs in the alignment information logs. The application logs and traffic logs are associated with the audit logs using the alignment information logs. Based on the association results, the anchor points in the initial source map are identified using the attack flags and attack logs. The nodes in the initial source map that meet the preset segmentation conditions are divided into multiple execution units using the delimiter logs to obtain a refined source map. All anchor points are connected based on the refined source map to form an attack sub-graph, and the labeled logs are obtained based on the attack sub-graph. This addresses the problems of current automatic log labeling methods, such as coarse granularity, insufficient coverage of different log types, and excessive reliance on manual work and domain expertise. It reduces manual workload, minimizes human involvement and dependence on domain expertise, covers multiple data sources, and can simultaneously label traffic, audit, and application logs. It provides fine-grained labels: enabling precise labeling of individual log entries, identifying specific connection, audit event, and application log entries, ensuring the accuracy and completeness of labeling, avoiding the inclusion of entries unrelated to the attack, and minimizing missing attack logs.

[0021] Additional aspects and advantages of this application 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 this application. Attached Figure Description

[0022] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein:

[0023] Figure 1 This is a flowchart of an automated fine-grained log annotation method provided according to an embodiment of this application;

[0024] Figure 2 This is a flowchart of an automated fine-grained log annotation method according to an embodiment of this application;

[0025] Figure 3 This is a schematic diagram of the code for log matching according to an embodiment of Algorithm 1 of this application;

[0026] Figure 4 This is a schematic diagram illustrating the matching of traffic logs and audit logs according to one embodiment of this application;

[0027] Figure 5 This is a schematic diagram of system calls included in a matching traffic log according to an embodiment of this application;

[0028] Figure 6 This is a schematic diagram of the code for scanning the attack flag according to Algorithm 2 of an embodiment of this application;

[0029] Figure 7 This is a schematic diagram illustrating an example of an execution model according to an embodiment of this application;

[0030] Figure 8 This is a schematic diagram of a service application used in an experiment according to an embodiment of this application;

[0031] Figure 9 This is a schematic diagram illustrating the accuracy of APP-audit log matching according to one embodiment of this application;

[0032] Figure 10 This is a schematic diagram illustrating the matching accuracy of APP audit logs according to one embodiment of this application;

[0033] Figure 11 This is a schematic diagram illustrating the traffic-audit log matching success rate according to one embodiment of this application;

[0034] Figure 12 This is a schematic diagram illustrating traffic log anchor point verification according to an embodiment of this application;

[0035] Figure 13This is a schematic diagram illustrating audit log anchor point identification according to one embodiment of this application;

[0036] Figure 14 This is a schematic diagram of a server application audit log unit partitioning experiment according to an embodiment of this application;

[0037] Figure 15 This is a schematic diagram of static analysis time according to an embodiment of this application;

[0038] Figure 16 This is a schematic diagram of runtime load and occupancy load according to an embodiment of this application;

[0039] Figure 17 This is a schematic diagram illustrating the audit log space overhead according to one embodiment of this application;

[0040] Figure 18 This is a schematic diagram of an attack tracing diagram according to an embodiment of this application;

[0041] Figure 19 This is a schematic diagram of instrumentation points in Python according to an embodiment of this application;

[0042] Figure 20 This is a schematic diagram of instrumentation points in NODE.JS according to one embodiment of this application;

[0043] Figure 21 This is a schematic diagram of an instrumentation point in NGINX according to an embodiment of this application;

[0044] Figure 22 This is a schematic diagram of a staking point in REDIS according to an embodiment of this application;

[0045] Figure 23 This is a schematic diagram illustrating the injection of attack flags in a traffic log according to one embodiment of this application. Detailed Implementation

[0046] The embodiments of this application are described in detail below. Examples of these embodiments are shown 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 this application, and should not be construed as limiting this application.

[0047] The following describes an automated fine-grained log annotation method according to embodiments of this application with reference to the accompanying drawings. Addressing the problems mentioned in the background art regarding current automated log annotation methods, such as coarse granularity, insufficient coverage of different log types, and excessive reliance on manual work and domain expertise, this application provides an automated fine-grained log annotation method. In this method, a preset attack scenario is run, and log information including unannotated logs, alignment information logs, delimiter logs, attack flags, and attack logs is collected based on the running results. An initial source map is constructed based on the audit logs in the alignment information logs. The application logs and traffic logs are associated with the audit logs using the alignment information logs. Based on the association results, the anchor points in the initial source map are identified using attack flags and attack logs. Nodes in the initial source map that meet preset segmentation conditions are divided into multiple execution units using the delimiter logs to obtain a refined source map. All anchor points are connected based on the refined source map to form an attack sub-graph, and the annotated logs are obtained based on the attack sub-graph. This addresses the problems of current automatic log labeling methods, such as coarse granularity, insufficient coverage of different log types, and excessive reliance on manual work and domain expertise. It reduces manual workload, minimizes human involvement and dependence on domain expertise, covers multiple data sources, and can simultaneously label traffic, audit, and application logs. It provides fine-grained labels: enabling precise labeling of individual log entries, identifying specific connection, audit event, and application log entries, ensuring the accuracy and completeness of labeling, avoiding the inclusion of entries unrelated to the attack, and minimizing missing attack logs.

[0048] Given that APT attacks can last for months and generate large amounts of log data from multiple sources, manual log annotation becomes extremely time-consuming and labor-intensive. Therefore, there is an urgent need for an automated log annotation method to generate benchmark datasets that meet the following requirements:

[0049] (1) Reduce manual workload: Minimize human involvement and reduce reliance on domain expertise;

[0050] (2) Covers multiple data sources: It can simultaneously label traffic, audit, and application logs;

[0051] (3) Provide fine-grained labels: enable precise labeling of individual log entries to identify specific connection, audit event and application log entries;

[0052] (4) Ensure the accuracy and completeness of the annotations: avoid including entries that are irrelevant to the attack and minimize missing attack logs.

[0053] Current status of traffic log annotation: Several researchers reviewed 28 traffic datasets using various annotation methods: Time Window (TW), Behavioral Profile (BP), and Detection Tool (DT). Some datasets used combinations of these techniques. TW was used in 12 datasets, BP in 12 datasets, and DT in 19 datasets, making them the most common methods.

[0054] Current status of audit log annotation: Currently available benchmark datasets for audit logs, used for training and performance evaluation, include the DARPATC series, CERT series, LANL series, StreamSpot series, Unicorn series, Alchemist series, and Atlas series. Among them...

[0055] The DARPA TC series datasets only provide coarse-grained attack scenarios and do not provide precise log annotations at the audit log entry level.

[0056] The CERT and LANL datasets define malicious activity based on user identity. This approach has limitations in APT scenarios because it is often impossible to distinguish between legitimate and malicious users under APT attacks.

[0057] The StreamSpot and Unicorn datasets have log annotations at the scene level, but do not provide precise log annotations at the audit log entry level.

[0058] Datasets like Atlas and Alchemist offer author-manual log annotation based on domain knowledge, but this manual approach requires significant manpower and lacks scalability.

[0059] Many studies use private audit log datasets that are not publicly available and only provide narrative descriptions of attacks. These internal datasets rely on manual annotation by experts, a costly and difficult-to-replicate approach.

[0060] The current approach to multi-source log annotation involves parsing logs into a semi-structured format and using rule-based methods for matching, simultaneously annotating audit, traffic, and application logs. However, this requires numerous domain-specific rules to cover all attack-related logs, making it time-consuming and difficult to ensure the accuracy and completeness of the rules.

[0061] The technical solution of this application embodiment is as follows:

[0062] A source graph is a directed graph used to represent the relationships between subjects (such as processes and threads) and objects (such as files and network sockets) within a system, with the direction of the edges indicating data flow. Source graphs are primarily constructed from audit logs, where each edge may correspond to multiple audit log entries. Currently, attack investigation methods based on source graphs have been widely proposed. These methods generate source graphs from audit logs and then analyze and extract attack-related subgraphs from the source graph, starting with symptom events (i.e., attack events).

[0063] Inspired by this, a novel approach is proposed to address the automatic log labeling problem, simplifying it to automatically obtaining accurate and complete attack subgraphs from the source graph. Once the attack subgraph is identified, relevant logs can be labeled based on the correspondence between edges in the source graph and log entries. However, this approach faces the following challenges:

[0064] Challenge 1: In addition to audit logs, application logs and traffic logs also need to be labeled. Therefore, establishing accurate relationships between these logs and building a unified traceability graph to integrate multi-source logs is a challenge.

[0065] Challenge 2: A prerequisite for extracting the attack subgraph is having an accurate set of symptom events. A key challenge is how to automatically locate the edges (called anchors) corresponding to these symptom events in a unified source graph.

[0066] Challenge 3: In the process of constructing the attack subgraph from anchor points, the classic dependency explosion problem will inevitably be encountered. Dependency explosion causes edges unrelated to the attack to be included in the attack subgraph, thus reducing its accuracy. Automatically, systematically, and universally solving the dependency explosion problem in log annotation tasks is a challenge.

[0067] The dependency explosion problem is a classic problem in attack investigation in source graph tracing. A long-running process typically performs many input and output operations, resulting in a large number of incoming and outgoing edges connected to the corresponding nodes, which greatly complicates the attack investigation process.

[0068] BEEP first proposed dividing long-running applications into execution units to achieve more precise attack attribution. MPI, Omegalog, and TeSec further advanced this process, handling asynchronous models such as multi-process, multi-thread, thread pools, and task queues.

[0069] MPI can track dependencies by annotating data structures, thus tracking thread pools. However, its implementation complexity and the deep code knowledge required may limit its practical application, especially in applications using modern asynchronous models.

[0070] Omegalog can automatically handle multi-process and multi-threaded scenarios, but it struggles to handle asynchronous task queues.

[0071] TeSec proposes a solution that can accommodate various execution models, including asynchronous task queues and thread pools. While it offers improvements, TeSec does not fully address the complexities introduced when these models are combined, such as using asynchronous task queues and thread pools simultaneously in applications like Node.js.

[0072] In automatic annotation, the accuracy of cell partitioning is crucial because it determines whether a log is relevant to an attack. Currently, there is no practical, general-purpose technique that can automatically partition cells across various modern asynchronous execution models and combinations thereof.

[0073] This application focuses on automated log labeling in the context of Advanced Persistent Threats (APTs), where attackers typically launch attacks from an application on one server and then extend their activities to multiple servers. We assume the target is a Linux server with a built-in audit logging mechanism (e.g., sysdig) capable of capturing the start and end times of syscalls, as well as the caller's PID / TID information. The system also allows for the insertion of custom kernel modules to intercept and modify network and syscalls, without involving client applications with a graphical interface.

[0074] Furthermore, it is assumed that all applications involved in the scenario are open-source server applications, which allows for source code analysis and instrumentation modifications, and ensures the reproducibility of the dataset.

[0075] Furthermore, we assume that AUTOLABEL users can collect network traffic logs and application logs from relevant applications. All audit logs, application logs, network traffic logs, and logs generated by AUTOLABEL must be protected from tampering by attackers. This assumption is widely required in log analysis methodologies. Additionally, the integrity of control flow must be maintained to ensure the validity of audit logs.

[0076] This application presents AUTOLABEL, a system designed for automating fine-grained log annotation. The AUTOLABEL workflow can be divided into three stages:

[0077] 1) Preparation Phase: AUTOLABEL modified the experimental environment and applications related to the attack scenario to generate necessary auxiliary information during the attack execution phase. Furthermore, AUTOLABEL adjusted the attack plans and tools used by attackers to inject attack markers for identification.

[0078] 2) Attack Execution Phase: The attacker executes the attack, and AUTOLABEL collects various logs, including auxiliary information. These logs include untagged logs, alignment information logs (used to establish relationships between different logs), delimiter logs (used for unit partitioning), and attack logs and attack flags (used to identify anchor points in the source graph).

[0079] 3) Annotation Stage: This is the core stage of Autolabel, consisting of five steps:

[0080] (1) Constructing a source graph: AUTOLABEL uses audit logs to construct a source graph.

[0081] (2) Log association: AUTOLABEL uses alignment information logs to associate application logs and traffic logs with audit logs, solving challenge 1.

[0082] (3) Locating anchor points: AUTOLABEL uses attack flags and attack logs to identify anchor points in the source map, solving challenge 2.

[0083] (4) Unit Segmentation: Using delimiter logs, AUTOLABEL segments nodes in the source graph that may lead to dependency explosion into multiple units, resulting in a refined source graph. This part addresses Challenge 3.

[0084] (5) Extracting attack subgraphs: AUTOLABEL extracts a complete and accurate attack subgraph starting from the anchor point, ensuring that all attack-related logs (i.e., traffic, audit, and application logs) are accurately and comprehensively labeled, thus solving challenge 3.

[0085] This application also evaluates AUTOLABEL's performance through experiments, assessing its performance across various attack scenarios, covering different types of server applications, attack tools, and vulnerabilities. Experimental results show that for six server applications, as long as the audit logs are complete, the accuracy of correlating application / traffic logs with audit logs consistently reaches 100%. Furthermore, tests were conducted using eight common attack tools and four typical vulnerabilities. In all cases, AUTOLABEL successfully identified anchors in both audit and traffic logs. For the dependency explosion problem, AUTOLABEL has been validated in seven server applications. For a complete attack story involving multi-source logs, AUTOLABEL has achieved accurate and comprehensive log tagging. Regarding performance overhead, the additional load introduced by AUTOLABEL is acceptable, with a maximum overhead of 8.5% (runtime overhead) and 53.7% (space overhead).

[0086] As a scenario embodiment of this application:

[0087] Alice, a security expert, aimed to create a log dataset containing APT attacks to train her log-based security model. She built a network of multiple servers and applications, made the entry point public, and invited security expert Bob to conduct a seven-day penetration test. Simultaneously, she organized multiple users to use the application normally.

[0088] During the attack, Bob documented his attack methods. Alice collected traffic logs between hosts, system audit logs for each host, and application logs. Here is an example of one attack step Bob documented: 1) A malicious request was sent. 2) The Nginx proxy processed it and forwarded it to the backend server. 3) The backend Flask application processed it and forked a child process to execute the malicious command.

[0089] Annotation was performed using existing methods. Following the attack, Alice collected millions of traffic logs, billions of bytes of audit logs, and billions of bytes of application logs. To train and evaluate the security model, Alice needed to accurately annotate these logs at the log entry level. Given the sheer volume of logs, manual annotation was clearly impractical.

[0090] Alice attempted to use a rule-based matching approach for log annotation, writing rules across different data sources for each attack step. Relevant logs included network logs, Nginx logs, application logs, and audit logs from Flask and fork processes. However, she faced two difficulties: (1) The sheer volume of log traces made ensuring the completeness of log annotation difficult. For a simple attack step, Alice needed to write matching rules for five different types of logs. Even after writing these rules, it was difficult to determine whether all relevant logs were covered. (2) Writing robust matching rules was challenging. API logs only recorded the requested URLs without parameters, providing limited information; audit logs lacked high-level readable information about network connectivity; and advanced attack techniques made writing rules for traffic logs particularly complex.

[0091] To use AUTOLABEL for dataset annotation, the following preparations are required:

[0092] For Alice: First, she used the AUTOLABEL tool to automatically detect Nginx and Flask applications. Then, she installed the AUTOLABEL kernel module in her experimental environment. Finally, she modified the startup commands of the Nginx and Flask applications to load the dynamic libraries provided by AUTOLABEL.

[0093] For Bob: He slightly modified his attack strategy based on the tools and guidance provided by AUTOLABEL to ensure that malicious requests and forked child processes were injected with attack flags.

[0094] After the attack, Alice doesn't need to write any rules. AUTOLABEL will automatically create a source graph from the collected logs. By locating the anchor point by finding the injected attack markers in the source graph, AUTOLABEL outputs an attack subgraph and automatically labels all relevant log entries. This process not only simplifies the labeling work but also ensures the completeness and accuracy of the labeled logs.

[0095] Specifically, Figure 1 This is a flowchart illustrating an automated fine-grained log annotation method provided in an embodiment of this application.

[0096] like Figure 1 As shown, this automated fine-grained log annotation method includes the following steps:

[0097] In step S101, a preset attack scenario is run, and log information including unlabeled logs, alignment information logs, delimiter logs, attack flags, and attack logs is collected based on the running results.

[0098] Specifically, during the preparation phase, AUTOLABEL performs two types of modifications:

[0099] (1) AUTOLABEL modifies the environment and applications in the attack scenario. These modifications enable the environment to generate the auxiliary information required for automatic labeling during the attack execution phase.

[0100] (2) AUTOLABEL makes slight modifications to the attacker’s attack plan and the attack tools used, thereby allowing attack flags to be injected into the attack process and leaving attack traces in the logs.

[0101] The auxiliary information generated from these two types of modifications will be used in different steps of the annotation phase. Specifically, the modifications include the following components:

[0102] Modify the application in the attack scenario:

[0103] a) Alignment Information Logger: The functionality of the alignment information logger is woven into the target application using dynamic link hooks and kernel module registration. This enables them to generate alignment information logs to correlate application logs and audit logs, while also logging application logs. This information will be used in the log correlation step during the annotation phase.

[0104] b) Delimiter Logger: Automated analysis of the asynchronous execution model of the target application. Using instrumentation technology, AUTOLABEL weaves the functionality of the delimiter logger into the target applications, enabling them to automatically generate delimiter logs, including information on cell partitioning, cell derivation relationships, and context switching. This information will be used in the cell partitioning step of the annotation phase.

[0105] Modify attack plans and tools: Make minor modifications to the attack process to ensure that traffic packets and system calls generated during the attack contain attack flags that can be identified by an attack flag scanner. These adjustments are lightweight, and methods for modifying attack tools are provided for common attack patterns, and these methods are transparent to attackers.

[0106] Modifying the attacked environment: Due to adjustments to the attack plan and tools, attack flags were injected into traffic and system calls, causing the attack to fail. Therefore, it is necessary to restore the injected traffic and system calls. To this end, embodiments of this application implement an attack flag scanner as a kernel module, the main objectives of which are: 1) During the attack execution phase, scan and extract attack flags from traffic and audit logs, providing information that can accurately locate the labeling stage of key events; 2) To prevent attack failure or leaving irreversible traces in the logs, also remove the attack flags from the attack payload, restoring the payload to its state before modification.

[0107] In step S102, an initial source map is constructed based on the audit log in the alignment information log. The application log and traffic log are associated with the audit log using the alignment information log. Based on the association result, the anchor points in the initial source map are identified using the attack flag and attack log.

[0108] Optionally, in some embodiments, the application log and traffic log are associated with the audit log using the alignment information log, including: disabling the application's buffer, injecting the timestamp and thread ID from the alignment information log into the application log to obtain the modified application and the modified application log; executing the modified application to regenerate the alignment information log, and using the timestamp and thread ID from the regenerated alignment information log to associate the modified application log with the audit log.

[0109] Optionally, in some embodiments, associating application logs and traffic logs with audit logs using alignment information logs further includes: obtaining the timestamp and four-tuple information for each TCP connection and UDP session in the traffic log, and obtaining the four-tuple information in the audit log; based on the UDP session timestamp and four-tuple information in the traffic log, searching in the audit log for the network system call that is closest to the UDP session timestamp and four-tuple information in the traffic log; and within the lifetime of the traffic file descriptor corresponding to the closest network system call, batch matching all system calls with the same four-tuple to establish the association between the traffic log and the audit log.

[0110] Optionally, in some embodiments, the anchor points in the initial source map are identified using attack flags and attack logs, including: using a preset attack flag scanner to detect all IP addresses in the attack scenario and the addresses corresponding to the scenario reversal; identifying connections in the IP address header of the traffic log with reserved bits set to 1, and marking the connections with reserved bits set to 1 in the IP address header as anchor points in the traffic log.

[0111] Optionally, in some embodiments, identifying anchor points in the initial source map using attack flags and attack logs further includes: integrating a preset kernel module to hook into system calls and injecting attack flags into the attack payload; using a preset attack flag scanner to intercept system calls, restoring the attack payload to its pre-attack state, and executing the restored attack payload; identifying system call parameters with attack flags in the audit log, and marking the corresponding log entries in the audit log as anchor points based on the system call parameters with attack flags.

[0112] Optionally, in some embodiments, when no anchor point is identified in the initial source map, the method includes: recording an attacker's behavior log, wherein the behavior log includes a timestamp, attack parameters, and a preset matching rule; refining the scope of the preset matching rule using the timestamp, and using the attack parameters and the preset matching rule, combined with consideration of event combinations, context, and attack parameters, to detect the attack log signature; and identifying the anchor point in the initial source map based on the attack log signature.

[0113] During the attack execution phase, the attack scenario begins to run, the attacker launches the attack, and AUTOLABEL collects various logs. The generated information includes:

[0114] Unlabeled logs are logs that need to be labeled;

[0115] Alignment information logs are used to correlate application logs and audit logs, and are used in the log correlation step of the annotation phase;

[0116] The delimiter log is used for unit partitioning, specifically in the unit partitioning step of the annotation phase;

[0117] Attack markers are key attack indicators used in the anchor point localization step of the annotation phase.

[0118] Attack logs are records of the attack process and are used in the anchoring step of the annotation phase. These logs include timestamp ranges for each attack step and some log records that can be used for rule matching.

[0119] The annotation phase includes five steps:

[0120] (1) Constructing a source graph: AUTOLABEL uses the collected audit logs to construct a source graph, where each edge corresponds to multiple audit log entries.

[0121] (2) Log Association (Solving Challenge 1): AUTOLABEL uses alignment information logs to map traffic logs and application logs to audit logs. Therefore, the edges in the source graph are attached not only to audit logs, but also to traffic logs and application logs.

[0122] (3) Anchor point location (solving challenge 2): By analyzing attack flags and optional annotation rules in attack logs, AUTOLABEL identifies attack-related edges in the source graph, which are called anchor points.

[0123] (4) Unit partitioning (solving challenge 3): AUTOLABEL uses delimiter logs to partition applications that may cause dependency explosion problems into units, splitting dependency explosion-related nodes into multiple unit nodes.

[0124] (5) Attack subgraph extraction (solving challenge 3). Finally, AUTOLABEL connects the anchor points to form a complete attack subgraph.

[0125] To achieve annotation across three different log sources, we need to associate application logs and traffic logs with audit logs. The methods for associating application logs and traffic logs are described below.

[0126] The specific method for linking application logs and audit logs is as follows:

[0127] The main difficulty in matching application logs with audit logs is the lack of matching information. Furthermore, it's impossible to ensure a one-to-one correspondence between application log entries and audit log entries. To address this issue, AUTOLABEL performs the following three phases of tasks:

[0128] 1) Preparation phase: (1) To ensure that each API call used to write to the application log (generating a log entry) corresponds to a file write system call, the application's buffer needs to be disabled. (2) To accurately match each application log entry with the underlying file write system call, we need to enhance the application log by injecting the timestamp and thread ID of the system call (i.e., alignment information log) into the application log.

[0129] 2) Attack execution phase: During the attack, the application generates logs including alignment information logs.

[0130] 3) Log association steps in the annotation phase: Use alignment information logs to match application logs with the corresponding audit logs.

[0131] Specifically, disabling buffering mechanisms: The following is a review of how server programs log application data. Programs use specific logging functions to write to the log, such as `printf` in C, `logging.info` in Python, or `logger.info` in Java's Log4j. These functions typically use buffering mechanisms, accumulating data until a threshold is reached or a newline character is encountered, and then flushing it to the output device. Finally, a write system call is triggered, writing the data to the file, creating a new application log entry and a corresponding audit log entry.

[0132] Buffering mechanisms vary across different programming languages ​​and frameworks. For basic languages ​​like C / C++, functions like printf follow the standard library implementation. High-level languages, such as Python and Java, have internal buffering mechanisms in their logging libraries.

[0133] If buffering is enabled, it is theoretically impossible to directly match log entries with system calls. We take the following steps during the preparation phase to disable buffering:

[0134] For basic languages ​​such as C / C++, buffering can be disabled by hooking dynamic link libraries, for example, by using setbuf in the glibc library to disable buffering and then file handle acquisition functions such as fdopen.

[0135] For high-level languages, global buffering settings can be easily adjusted. For example, in Python's logging, buffering can be set to 0 using Monkey-Patching, and in Java's Log4j, buffering can be disabled by configuring it in the log4j.properties file.

[0136] Further insertion of alignment information log:

[0137] A precise match between the application and the audit logs is achieved using accurate timestamps and thread IDs. While long-running applications may use a multi-process or multi-threaded model, system calls from a single thread are sequential. By inserting a kernel module to hook write system calls and configuring it to identify log-related file writes, each log entry can be tagged with a thread ID and a precise timestamp (e.g., using `ktime_get_real_ts64`). During the attack execution phase, this tagging is applied to each write operation.

[0138] Further matching of logs during the annotation phase:

[0139] In the log-related steps of the annotation phase, Algorithm 1 is as follows: Figure 3 As shown, the audit logs are sorted by thread ID, and the application logs are matched with the timestamps of the most recent system calls, thus ensuring that the matching process is efficient with a time complexity of O(n).

[0140] The specific steps for linking traffic logs and audit logs are as follows:

[0141] The goal is to match each TCP connection and UDP session in the traffic log with the corresponding network-related system calls in the audit log.

[0142] The audit logs already contain detailed information to facilitate matching: the four-tuple of IP addresses and port numbers at both ends of the network traffic can correspond one-to-one with a TCP connection or UDP session.

[0143] The matching process is as follows, and in Figure 4 The description (the system calls involved in this process are in) Figure 5 (Listed in the middle):

[0144] (1) Match the closest system call: Identify the network system call that is closest to the timestamp and quadruple of each entry in the traffic log.

[0145] (2) Locate the lifecycle of traffic file descriptors: Track the creation and destruction of file descriptors used for system calls in the process's audit log to establish matching boundaries.

[0146] (3) Batch matching within intervals: Treat all system calls that share the same quadruple as matching the traffic log.

[0147] To correlate traffic logs and audit logs in O(n) time complexity, embodiments of this application develop a two-step scanning algorithm that can be used in the log correlation step of the annotation phase. First, we scan the audit logs to track the lifecycle of each network file descriptor (fd) associated with a network system call. Then, we scan the traffic logs to determine the audit log entry e whose timestamp most closely matches the current quadruple. For this log entry e, we locate all relevant audit log entries sharing the same quadruple within the lifecycle of fd, thereby integrating it with the traffic logs.

[0148] Furthermore, anchor points are identified in the traffic logs and audit logs:

[0149] Anchor points are log entries representing attack activity, corresponding to edges in the source graph. These points can be categorized by type: traffic logs and audit logs.

[0150] There are some difficulties when trying to find anchor points by writing rules:

[0151] Regarding traffic logs: Attackers may use tools like Burp Suite to intercept and modify browser requests, making them appear as regular user activity with only minor but critical API changes. Furthermore, attackers can bypass rule-based intrusion detection systems (IDS), requiring deep domain knowledge to accurately match these complex logs.

[0152] Regarding audit logs: Attackers may manipulate normal business processes, such as changing configuration files, to perform malicious operations. These operations often mimic legitimate activities, generating the same system calls and log entries, complicating rule-based log matching.

[0153] To address these issues, this application modifies the attack tools and strategies by injecting attack flags into the payload. These flags can be directly associated with entries in traffic and audit logs to help identify anchor points. However, this raises two questions: 1) How to ensure the effectiveness of the attack: Attack payloads, such as parameters in the traffic, are often finely tuned. The payload needs to be modified without jeopardizing the success of the attack. 2) How to ensure the integrity of the logs: Irreversible changes cannot be introduced into the logs.

[0154] To address these issues, an attack flag scanner was designed as a kernel module in the target environment during the preparation phase. The scanner intercepts all traffic and system calls, detects attack flags, and restores them to their original state. This ensures the attack's success without interruption and leaves no trace in the logs.

[0155] We will further discuss methods for identifying anchor points in traffic logs and audit logs.

[0156] The specific method for annotating anchor points in traffic logs is as follows: To annotate anchor points in traffic logs, attack flags are injected using the destination address of the traffic. The destination address is usually under the attacker's control and can be manipulated in scenarios such as external attacks or lateral movement within the network. Specifically, AUTOLABEL reverses the destination IP address (an IP address is created by reversing a 32-bit number using a logical NOT operation. The reversed IP address avoids conflicts with the network destination, ensuring uniqueness and stealth. Subnet consistency remains unchanged, making it easier for tools like nmap to scan and attack settings).

[0157] During the preparation phase, the scanner records all IP addresses in the scenario and their inverted corresponding addresses. During the attack execution phase, once the scanner detects an inverted IP address, it leaves an attack flag and then sets the reserved bit in the IP header to 1 (unused reserved bits in the IP header are set to 0, carrying non-destructive information. This bit remains unchanged during transmission, preserving tracking functionality. Once an anchor is found, this bit is reset to 0, restoring the data packet). During the annotation phase, connections with reserved bits set to 1 in the IP header are marked as anchors during anchor identification.

[0158] In Description A, embodiments of this application detail how AUTOLABEL ensures that IP address modifications remain transparent to attackers.

[0159] The approach to designing the attack flag scanner is as follows: To ensure the attack proceeds successfully, even after the destination address has been modified, we designed and implemented a kernel module—an attack flag scanner based on the Netfilter framework—to intercept and modify traffic. This interception and modification needs to be applied to both inbound and outbound traffic because the upper-layer application generating the forged traffic is unaware that the underlying destination address has changed. If the destination address of the response traffic is incorrect, it may cause abnormal behavior in the application.

[0160] Algorithm 2 as follows Figure 6 As shown, outbound traffic and inbound traffic are processed separately:

[0161] For outbound traffic:

[0162] 1. Traffic is intercepted at the NF_INET_LOCAL_OUT hook. If the destination is not an inverted IP address, it is forwarded directly. Otherwise, proceed to the next step.

[0163] 2. The reserved bit is set to 1, and the destination address is restored to its original value. The new source address is calculated based on the routing table to ensure correct routing, and this address is set as the new source.

[0164] 3. The actual destination address and source port number are recorded in hack_connection for adjustment in response traffic.

[0165] For inbound traffic:

[0166] 1. Traffic is intercepted at the NF_INET_LOCAL_IN hook. If the source address and destination port do not match any entry in the hack_connection, the traffic is forwarded directly; otherwise, proceed to the next step.

[0167] 2. The reserved bit is set to 1, and the source address is changed to prevent application-level exceptions. The new destination address is calculated based on the routing table to ensure correct delivery.

[0168] The specific method for annotating anchor points in audit logs is as follows: To annotate anchor points in audit logs, focus on the main injection points in file read / write operations (file names and contents) and command parameters (command parameters) during command execution. These elements are usually under the attacker's control, such as writing malicious trojans, accessing sensitive files, or executing harmful commands. Include these attack markers in the attack payload, and demonstrate their effects through disk operations and command execution-related system calls.

[0169] During the preparation phase, this embodiment integrates a kernel module to hook into system calls and inject attack flags into the attack payload. For example, when writing a malicious Trojan, a flag is added to the file content. During the attack execution phase, an attack flag scanner intercepts system calls, restores them to their pre-attack state, and then executes the payload. For example, in the case of the malicious Trojan, the file content is restored to its original form during the system call writing process. In the anchoring step of the annotation phase, attack-related logs are easily identified because audit logs capture system call parameters with attack flags. After identification, the attack flags are removed, and the logs are restored.

[0170] This application employs specific methods to insert and remove attack flags in system calls, related file operations, and command execution:

[0171] In file operations, for the `openat` system call, a fixed-length identifier is added before the filename. The pointer (rdi) is then moved forward by that length to access the original filename.

[0172] During a file write operation: In the `write` system call, a fixed-length identifier is added before the content. The content pointer (rsi) is moved forward by this length to restore the original content.

[0173] Command parameters during execution: For `execve`, a special identifier is inserted as a new parameter. Detection of this identifier prompts subsequent parameters to shift forward one position to restore the original command state. After execution, parameters are shifted backward to maintain consistency in the user-space program.

[0174] A similar approach applies to variations of these system calls.

[0175] In section B, it is detailed how AUTOLABEL can modify existing attack tools, subtly altering command execution, filenames, and file contents without warning the attacker.

[0176] If the key anchor points cannot be identified using conventional methods, AUTOLABEL will adopt the rule matching strategy proposed by Kyoushi.

[0177] During the attack execution phase, attackers may choose to log their actions in the attack log, including:

[0178] Timestamps mark the start and end of an attack: Timestamps help refine the scope of rule matching, improve accuracy, and minimize false positives.

[0179] Attack parameters: Record specific details, such as IP address or traffic parameters, for accurate matching.

[0180] Specific matching rules: Utilizing Kyoushi's nested rule method, log signatures are detected by considering event combinations, context, and attack parameters.

[0181] In the anchor point localization step of the annotation phase, AUTOLABEL integrates attack logs to accurately locate anchor points, thereby addressing any shortcomings left by earlier methods.

[0182] In step S103, the nodes in the initial source map that meet the preset segmentation conditions are divided into multiple execution units using the delimiter log to obtain a refined source map. All anchor points are connected based on the refined source map to form an attack sub-graph, and the labeled log is obtained based on the attack sub-graph.

[0183] Optionally, in some embodiments, when connecting all anchor points based on a refined source graph to form an attack subgraph, the process includes: constructing a handler derivation tree; determining handlers with shared derivation relationships through the handler derivation tree, and classifying system calls in handlers with shared derivation relationships as belonging to the same execution unit.

[0184] Optionally, in some embodiments, when connecting all anchor points based on a refined source map to form an attack subgraph, the process includes: constructing an initial handler tree; evaluating the number of accept calls in each subtree of the initial handler tree, and deleting nodes whose accept call count is greater than or equal to a preset number, to obtain a target handler tree, so as to define different execution units according to the target handler tree.

[0185] Optionally, in some embodiments, an attack subgraph is formed by connecting all anchor points based on a refined source graph to obtain labeled logs. This includes: processing nodes without outgoing edges in reverse topological order based on the refined source graph; maintaining a set for each node and updating the set for each new node; obtaining all marked path edges by taking the union of the sets of all direct successor nodes and subtracting all intersections; where if a node is a starting point, marking all paths originating from the starting point and adjusting the set of each node to obtain all marked path edges; and connecting all marked path edges to form an attack subgraph.

[0186] Optionally, in some embodiments, after forming the attack subgraph, the process includes: checking whether all anchor points in the refined source map have been connected to form an attack path; if there are unconnected anchor points, determining the location of the unconnected anchor points and prompting the user to add them.

[0187] The specific methods to solve the dependency explosion problem in attack subgraph extraction are as follows:

[0188] 1) Divide the execution units and refine the traceability diagram;

[0189] 2) Expand from the anchor points in the refined source map to construct an attack subgraph.

[0190] Unit Partitioning Principle: Before dividing execution units, it is necessary to define what an execution unit is. In Autolabel, an execution unit refers to all the operations performed by an application while processing a single request. Because applications may use an asynchronous execution model, these operations may occur across different threads and times, but their common goal is to accomplish the same task.

[0191] In the asynchronous execution model, the completion of a task is broken down into multiple handlers, each handling a portion of the task. These handlers have a derivative relationship, meaning that derived handlers are still processing the same task.

[0192] like Figure 7 As shown, here are some specific examples of execution units used in four common execution models when a request arrives:

[0193] 1) Sequential task processing: Each processing program directly corresponds to a request, thus forming an execution unit.

[0194] 2) Asynchronous task queue: A request is processed by multiple handlers. For example, request 1 is initially processed by handler 1, and then handlers 3 and 6 are derived. Handlers 1, 3, and 6 together constitute an execution unit.

[0195] 3) Creating additional threads: When a request is accepted by a handler on the main thread, it creates a new thread to serve the request. The handler on the main thread and the handlers on the threads it creates together constitute an execution unit.

[0196] 4) Thread Pool: When a request is accepted by a handler on the main thread, an idle worker thread in the thread pool is scheduled to serve the request. Worker threads process different tasks sequentially, with each segment corresponding to a handler. Therefore, the combination of the handler on the main thread and the handlers corresponding to the derived tasks forms an execution unit.

[0197] This illustration only shows an operation using a single execution model. However, modern applications often use a combination of multiple execution models. For example, a common pattern is that the main thread uses an asynchronous event queue, while long-running tasks are submitted to a background thread pool for maintenance.

[0198] Based on the above discussion, the embodiments of this application adopt the following two steps to partition the execution unit:

[0199] 1) Divide all system calls within a thread into different handlers. Record the handler ID at the start of each handler to determine when to switch and which handler begins execution. For example, in an asynchronous task queue, record where each event callback is executed; in a thread pool, record where each task is executed.

[0200] 2) Construct a handler derivation tree (called the handler tree). Derivation relationships are recorded where new handlers are created, along with the ID of the new handler. This allows linking the current handler with newly derived handlers. For example, in an asynchronous task queue, this recording occurs at the event registration point; in a thread pool, it happens where the task is submitted.

[0201] By following these steps, all system calls of an application can be partitioned into different handlers, and a tree can be built to capture their derivation relationships. Therefore, system calls in handlers that share a derivation relationship belong to the same execution unit.

[0202] The embodiments of this application have manually injected the official asynchronous libraries of Python, Node.js, and Java to enable execution partitioning. This is a one-time task, and details are as described in Description D.

[0203] Cell Partitioning: Automated Metering. While high-level languages ​​and frameworks using popular asynchronous libraries allow for cell partitioning of server applications with only one manual metering step, server applications developed in C still require manual identification of meter points, which demands significant domain knowledge and effort. To address this issue, embodiments of this application propose an automated method for analyzing and metering C language projects to facilitate cell partitioning.

[0204] The main difficulties currently faced include:

[0205] 1) Automatically locate processor execution and derivation points.

[0206] 2) Identify the top-level processor that accepts the request and aggregate its system calls and their descendants into a single execution unit.

[0207] To address the first difficulty, this application's embodiments employ the following steps:

[0208] 1) Static Analysis: We analyze the characteristics of the C code, using static matching of the Abstract Syntax Tree (AST) to initially identify and instrument the code executed and registered by the processor. Specifically, in C, processors are typically implemented as function pointers in a class structure, similar to event → procedure (event). Using tools such as clangd, we generate and traverse the AST to identify all function pointer calls and assignments, corresponding to processor execution and derivation. This embodiment uses macro wrappers to record the event addresses of these points.

[0209] 2) Dynamic Analysis: Accurately identifying processor activity based on the dynamic behavior of the code. Specifically, after instrumentation, the software is recompiled and run to collect logs, including event addresses. This application embodiment applies three rules to further refine this process:

[0210] Variable event address: The event address should indicate mutability, suggesting dynamic assignment rather than a static function pointer.

[0211] Repeated processor calls: Evaluate the execution interval of each function pointer, record their first and last executions, and then merge any overlapping intervals. The longest interval identifies the function pointer active in the event loop, while shorter or non-overlapping intervals indicate function pointers used before the start of the event loop or after its end.

[0212] The processor is at the top of the call stack: The processor should primarily be located at the top of the call stack during execution.

[0213] This precise set of function pointers marks the location of processor execution and derivation, and this approach has been successfully implemented in projects such as Nginx, HAproxy, Redis, and Libuv.

[0214] To address the second challenge, this embodiment constructs a handler tree and evaluates the number of accept calls in each node's subtree. Nodes with more than two accept calls may not correspond to a single request. By removing these nodes, we refine the handler tree into multiple independent trees, each rooted at a handler directly linked to the TCP connection, thus defining distinct execution units.

[0215] This automated process simplifies code injection and cell partitioning for long-running C server applications.

[0216] The steps for extracting the attack subgraph are as follows:

[0217] After identifying anchor points in the source graph, the goal of this embodiment is to connect them into an attack subgraph. This embodiment only marks the path edges between two anchor points if a unique path exists between them. To efficiently accomplish this process, an O(kn) algorithm based on topological sorting is designed, where k is the number of anchor points. The steps are as follows:

[0218] 1) Define the starting node of the edge corresponding to all anchor points as the "starting point".

[0219] 2) Utilize the structure of the source graph, i.e., the directed acyclic graph, and start from the node with no outgoing edges, processing in reverse topological order.

[0220] 3) Maintain a set Si for each node i, which contains all starting points that can be reached from i via a unique path.

[0221] 4) Update Si for each new node i, take the union of the sets of all direct successor nodes, and then subtract any intersections to ensure that the path starting from i remains unique.

[0222] This step requires careful handling of various complex scenarios, such as distinguishing between pointer and variable usage, and embedded function pointer calls.

[0223] 5) If i is a starting point, mark all paths starting from i and adjust Si to include only i, since paths to other points in Si must pass through i.

[0224] If any anchors remain unconnected after this process, it indicates that the current anchors are insufficient to cover all attack paths. In this case, AUTOLABEL will indicate the location of these unconnected anchors and prompt the user to add more anchors or write rules to enhance the attack subgraph construction.

[0225] After addressing the three challenges, this application embodiment obtains an attack subgraph containing attack-related nodes and edges. Given the correlation between application, network, and audit logs, multi-source logs related to each edge connecting to attack-related nodes in the attack subgraph are further labeled, resulting in a fully labeled log dataset.

[0226] The Linux server used for the experiment has an Intel 13th generation Core i9-13900H CPU with a power output of 2.60 GHz to 5.40 GHz and 32 GB of RAM, running Ubuntu 22.04.3LTS.

[0227] Environment setup: A network topology and containers that mimic a real-world host were created using Docker.

[0228] The advantages of using containers include:

[0229] 1) Easily manage startup and shutdown through automated operations.

[0230] 2) Native support for setting the LD_PRELOAD environment variable, which is crucial for AUTOLABEL's dynamic link hooks.

[0231] 3) Kernel modules can be easily inserted on all hosts; they only need to be implemented once on the master server to affect all containers. Kernel modules distinguish containers by recognizing the namespace of the current process.

[0232] Log collection: Use sysdig to collect audit logs, use tcpdump to collect traffic logs by monitoring Docker's virtual network devices, and direct application logs to a specified directory.

[0233] Attack Launch: The attack originated from a host running the Ubuntu desktop version, equipped with custom attack tools and a pre-configured terminal that automatically sets the necessary environment variables. We also registered the required kernel modules on this machine.

[0234] Accuracy assessment of log matching: The log matching process, which combines application logs with audit logs and traffic logs with audit logs, was evaluated. For example... Figure 8 As shown, the experiments in this application embodiment involve six server applications, representing common categories, generating a large amount of traffic, application, and audit logs.

[0235] Application Logs to Audit Logs: This test verified whether AUTOLABEL could accurately map application logs to the corresponding audit logs.

[0236] One-to-one matching evaluation: Alignment information logs for each application log line were checked to ensure that different entries were not mixed in the same buffer.

[0237] Match accuracy assessment: Using Sysdig, it was confirmed that the prefix of the content written by the write system call matched the prefix in the application log.

[0238] Buffering mechanisms differ between applications:

[0239] Nginx and PythonLogging use a custom log buffer, which is configurable and disabled by default.

[0240] Apache, Morgan (Node.js), Redis, and MySQL Server (excluding MySQL binlog) rely on buffers in the C standard library.

[0241] Results (e.g.) Figure 9 and Figure 10 The image shows a successful one-to-one log mapping for all applications, except that Apache experiences lost audit log entries under higher concurrency (over 50). This issue can be resolved by using a more reliable audit logging framework.

[0242] Traffic logs to audit logs: This records both traffic logs and audit logs, while simultaneously accessing the aforementioned applications. For example... Figure 11 As shown, all traffic log entries found their corresponding quadruples in the audit log, confirming a successful match for all entries.

[0243] Evaluate the practicality of anchor point positioning:

[0244] AUTOLABEL uses attack flags to identify attack points, ensuring accurate anchor detection. The feasibility of this method was tested in traffic and audit logs by modifying attack tools and plans.

[0245] 1) Locating anchor points in traffic logs: To demonstrate the feasibility of this method, such as... Figure 12 As shown, eight experiments were conducted, using common attack tools to inject attack flags, as described in Note E. The results show that all attack flags were injected and all anchors were successfully identified.

[0246] 2) Locating anchor points in audit logs: Four scenarios involving arbitrary command execution and file operations were reproduced, and attack flags were injected at key points. All anchor points were successfully identified by AUTOLABEL, such as... Figure 13 Record.

[0247] Effectiveness in solving the dependency explosion problem

[0248] exist Figure 14 In this implementation, cell partitioning was used in the audit log for various applications, and the consistency and correctness of log entries within the cell were evaluated.

[0249] For Nginx and HAproxy, multiple reverse proxy rules were configured. The evaluation checked whether audit log writes and network system calls matched within the unit.

[0250] For Redis, the standard is the consistency of the four-tuple of network system calls within each unit.

[0251] For Express.js and Fast API applications, the consistency of the write system calls for the audit logs of API requests and file writes within the cell was evaluated.

[0252] For Apache using Prefork MPM, cell partitioning is based on a sequence of audit logs with accept system calls as delimiters, using an evaluation method similar to that of Nginx and HAproxy.

[0253] For MySQL Server, with each connection managed by a single thread, the identical SQL statements in the cell logs were evaluated and verified.

[0254] Experimental results show that all evaluation criteria were met and the execution units were correctly partitioned (e.g., Figure 14 (As shown in the last column of the image).

[0255] Evaluate performance across the entire dataset:

[0256] The effectiveness of AUTOLABEL's tagging was evaluated in a real-world network environment involving a 10-step attack between four hosts, with normal user activity in the background. Manual verification confirmed the accuracy and completeness of the tagging logs.

[0257] To demonstrate AUTOLABEL's capabilities, Description C details a selected attack step on a host, showing how AUTOLABEL extracts the attack graph and tags the logs. In this detailed description, we outline the manual work required for this complete instance of AUTOLABEL and explain how each log is tagged.

[0258] Evaluate performance overhead:

[0259] During the preparation phase, automated annotation analysis for C language projects primarily involves static analysis, which is time-consuming because it requires traversing the project's Abstract Syntax Tree (AST) and identifying annotation points. The analysis time depends on the complexity of the project. Figure 15 The static analysis time for HAProxy was the longest, reaching 90 seconds, while Redis, Nginx, and libuv had relatively shorter times.

[0260] During the attack execution phase: Concurrent access tests were conducted on various applications with a test concurrency of 255 to evaluate runtime and space overhead.

[0261] During the attack execution phase, runtime overhead includes two aspects:

[0262] Application execution: For log correlation, a kernel module is inserted to print alignment information logs and hooks are applied to the dynamic link library to disable buffering; to identify attack points, the kernel module intercepts system calls; to execute unit segmentation, delimited logs are printed at specific locations.

[0263] Traffic transmission: In order to identify attack points, kernel modules are inserted to intercept traffic.

[0264] Figure 16 The blue section records the changes in request access time for each application before and after the attack. It can be seen that Redis has the highest runtime overhead, reaching 8.5%.

[0265] During the attack execution phase, the space overhead mainly includes:

[0266] Attack flags are injected into the sysdig log. Since the system calls involved in an APT attack only account for a small portion of the audit log, this load is negligible.

[0267] Alignment information logs are injected into the application logs. Since each line of the application log corresponds to an alignment information log entry, this will generate significant space overhead. Figure 16 The red portion represents the changes in the application logs, with the maximum increase in application log space reaching 53.7%.

[0268] Delimited Logs: Since the goal of delimited logs is to segment the audit log, this increase is considered "audit space overhead." For example... Figure 17 As shown, the largest overhead in the audit logs occurred in the Haproxy application, and did not exceed 8%.

[0269] During the annotation phase:

[0270] The time complexity of each step in the annotation phase is linearly related to the number of log entries, essentially involving multiple scans of the log; therefore, the time consumption is acceptable. Furthermore, since the annotation phase is a post-analysis step, sufficient time is available. In our hardware environment, using Python to traverse the three types of logs results in approximately 105 entries per second, which is considered acceptable.

[0271] Discussion of the limitations of the study and interpretation of the results.

[0272] 1) Autolabel Support for GUI Applications. Autolabel annotation faces challenges with GUI applications because system logs fail to fully capture complex UI events such as malicious clicks or keystrokes. The multifaceted nature of GUI applications complicates the identification of logs associated with malicious activity. Improving automated annotation for GUI applications is a key future challenge.

[0273] 2) Injecting attack flags into audit logs requires domain knowledge. AUTOLABEL relies on attackers injecting attack flags to identify anchors in audit logs, requiring a deep understanding of the attack. While modifying attack tools is discussed in Note B, it is not always feasible, especially when using custom PoC scripts. Although modifying the attack payload may seem straightforward to a knowledgeable attacker, further research is needed to find more subtle ways to inject attack flags. Automating the identification of instrumentation points in attack tool code can simplify and improve the annotation process.

[0274] 3) Static analysis within cell partitions needs to consider special cases. Our static analysis for C projects automatically identifies and encapsulates function pointer calls and assignments using macros. However, function pointer calls hidden within macros or complex expressions require advanced handling. We have added extensive logic to address these issues, and future work aims to refine this approach and cover more special cases and advanced C functions.

[0275] Related Work

[0276] Automatic labeling of multi-source logs has been relatively little explored. Kyoushi is noteworthy for parsing multi-source logs into a semi-structured format and applying rule templates, such as query and sequence rules. However, it struggles with writing large amounts of rules, integrating different log types, and identifying complex attacks.

[0277] In traffic log labeling, time-window-based methods utilize specific timeframes to distinguish between normal and malicious traffic, but they encounter difficulties when granularity is required in complex attacks. Behavioral model-based methods generate and label network traffic through summaries of normal and malicious behavior. While GANs and tools like the CREME toolkit simulate real traffic to augment datasets, they are primarily applicable to synthetic traffic and cannot be directly applied to real-world traffic. Detection tool-based methods use NIDS and statistical tools to improve labeling; however, their effectiveness largely depends on the detection tools used.

[0278] Methods for addressing dependency explosion. To address dependency explosion, BEEP suggests dividing long-running applications into several execution units to improve attack traceability. However, BEEP's straightforward approach of training and analyzing loops and memory dependencies can lead to incorrect partitioning. MPI improves partitioning by using data structure annotations and tracking indicator variables, although this approach is complex and difficult to apply in complex asynchronous code. Omegalog and Alchemist use application logs to partition audit logs, but they rely on specific log content and format, limiting their applicability. TeSec, which focuses on web applications, addresses different asynchronous models but fails to consider their combined use in frameworks like Express.js, resulting in inaccurate unit partitioning.

[0279] Unit partitioning methods based on taint analysis have been proposed to achieve finer-grained attack traceability by incorporating low-level data flow information outside of system calls. However, these methods cannot guarantee accurate taint propagation. Log annotation tasks require deterministic algorithms and 100% accuracy, therefore they are unsuitable for log annotation.

[0280] Conclusion

[0281] This application describes AUTOLABEL, an automatic log labeling system. AUTOLABEL merges audit, traffic, and application logs to create a source graph, identifying and labeling entries relevant to APT attacks. By subtly adjusting the attack tools, AUTOLABEL injects identifiers during the attack to achieve automatic labeling, thereby eliminating human intervention. It reduces the need for manual labeling and improves accuracy and completeness. In testing, AUTOLABEL achieved 100% labeling accuracy, with runtime and space overhead within 8.5% and 53.7%, respectively, demonstrating its practicality.

[0282] Explanation A

[0283] Methods to covertly modify the destination address of traffic

[0284] By dynamically hooking into link-layer functions, the destination address of network traffic can be secretly modified, thereby injecting attack flags into traffic logs without the attacker's knowledge.

[0285] This application involves intercepting the connect and sendto functions in the glibc library, which are crucial for network operations in Linux:

[0286] The connect function initiates a connection request with the server.

[0287] The sendto function sends data packets to a specific address in a connectionless network.

[0288] We use the LD PRELOAD trick to load a custom library to modify these functions. When the application uses these functions, our library first verifies whether the destination IP is part of the target cluster. If so, it modifies the address and forwards it to the original library function.

[0289] The modifications are transparent and automatic, seamlessly integrating into the attacker's tools.

[0290] Setting the LD PRELOAD variable in the attacker's terminal ensures that all network applications inherit this modification without requiring additional configuration.

[0291] Setting LD PRELOAD in a compromised internal network ensures that all network tools can covertly modify their communication addresses.

[0292] Attackers unfamiliar with the environment configuration can use pre-configured tools or terminals with the necessary settings already applied.

[0293] Explanation B

[0294] Methods for covertly modifying the attack payload in attack tools

[0295] Various attack tools have been improved to secretly inject attack flags into the payload, affecting file and command-related system calls without the attacker's knowledge.

[0296] Many advanced attack tools offer backdoor management capabilities after establishing a foothold:

[0297] Tools like Antsword, Godzilla, and Behinder have graphical user interfaces for file and command management, including drag-and-drop and file renaming capabilities. The Metasploit Framework provides Meterpreter sessions for similar purposes.

[0298] Examining the source code of these tools revealed common file management and command execution functions, such as the file manager and terminal modules in Antsword, and meterpreter / extensions in the Metasploit Framework.

[0299] By modifying these unified functions to automatically insert attack flags into the parameter inputs, we can alter the payload without the attacker's knowledge.

[0300] Attackers using integrated backdoor management tools can modify similar functions themselves, or use pre-modified versions of Antsword and Metasploit Framework provided in the embodiments of this application.

[0301] Explanation C

[0302] A complete workflow example for AUTOLABEL

[0303] Figure 18 The source graph is described, which includes red nodes and edge-marked anchors. Blue indicates audit logs, and yellow edges indicate connections during the extraction of the attack subgraph.

[0304] Attack Scenario Description: To penetrate this host, the attacker previously implanted frpc in the internal network, establishing a SOCKS5 tunnel. Through this tunnel, the attacker could directly attack the target host. Simultaneously, the target host had a web application developed using the FastAPI framework.

[0305] The attack involved:

[0306] • The first attack step: Use SQL injection to retrieve administrator credentials.

[0307] • Second attack step: Using these credentials, upload a malicious backup file through a file upload vulnerability and set it to execute a cron job.

[0308] • The third attack step: Execute commands through the cron job to probe the host.

[0309] • Fourth attack step: Use nc to establish a reverse shell and gain control of the host.

[0310] Marking method:

[0311] 1) Identifying anchor points in traffic logs: First, the address accessed by frpc to frps is reversed, and the target address accessed by the attacker is also reversed. This allows attack flags to be directly injected into the proxy's traffic. Additionally, when nc executes a reverse shell, the entered target address is reversed, allowing attack flags to be injected into the reverse shell traffic. This step marks all red nodes and edges.

[0312] 2) Identify anchor points in the audit logs: The commands that attackers fill into the backup file include attack flags in the parameters. This step marks all blue nodes and edges.

[0313] 3) Segmenting and connecting paths within the FastAPI application: After identifying anchor points, logs that are still not considered include:

[0314] • Other information within the FastAPI unit, such as malicious SQL traffic sent and API records in the application logs.

[0315] • There is a process derivation and file read / write relationship between backup file writing and malicious command execution.

[0316] By dividing the data into units and connecting anchor points, we obtained a connected attack subgraph that marks all yellow nodes and edges.

[0317] Through these three steps, we achieved accurate and complete tagging of attack-related logs in this attack scenario.

[0318] Explanation D

[0319] Example of environmental unit division

[0320] Example 1: Python language. The Python language includes the official asynchronous library Asyncio and the official thread pool ThreadPoolExecutor. Figure 19 The instrumentation point is shown in the image. For FastAPI applications developed using Python, the subtree formed by the handlers of the `_accept_connection2` function can be considered as a single unit because this function corresponds one-to-one with the `accept` system call.

[0321] Example 2: Node.js language. Node.js includes the libuv library, which provides an event loop. For file read and write operations, Node.js uses the thread pool provided by libuv. The libuv event loop has seven types of handlers; it also implements the uv__work class to encapsulate the thread pool handlers. Figure 20The instrumentation point is indicated in the code. For Express.js applications developed using Node.js, each TCPWRAP handler corresponds directly to the accept system call, and its subtree can be considered as a unit.

[0322] Example 3: Java. Java provides the official thread pool ThreadPoolExecutor.

[0323] The execution of the handler is implemented in the beforeExecute method.

[0324] The derivation of the handler is implemented in the execute method.

[0325] Example 4: Nginx. Nginx implements an event loop. There are three types of handlers: IO type (usually implemented by epoll on Linux); Posted type; and Timer type. Figure 21 The insertion point is indicated in the text.

[0326] Example 5: Redis. Redis implements an event loop. There are two types of handlers: file event handlers and time event handlers. Figure 22 The document indicates the implementation points.

[0327] Example 6: Haproxy. Haproxy implements a task-based event loop, represented by the struct task.

[0328] The execution of the handler is implemented in run_tasks_from_lists.

[0329] The derivation of the handler is implemented in the task_queue function.

[0330] Explanation E

[0331] Description of attack flag injection methods in attack tools and traffic logs

[0332] To verify the practicality of locating anchor points in traffic logs, such as Figure 23 As shown, experiments were conducted using common attack tools. Below are descriptions of these tools and methods for injecting attack flags:

[0333] Nmap is a network scanning tool used to discover devices and services on a network. Attack flags can be injected by directly modifying the target address being scanned.

[0334] BurpSuite is an integrated platform for testing the security of web applications. Changing the IP address accessed by BurpSuite can inject attack flags.

[0335] Antsword is a web shell management tool. When connecting to a backdoor, specify the backdoor's modified IP address.

[0336] Bash Reverse Shell allows remote command execution and modifies the IP address when the IP address of the target to be jumped to is specified.

[0337] DNS Shell uses the DNS protocol for covert command and control communication. When an attacker-controlled DNS server address is specified, the DNS server's IP address is changed to the modified IP address.

[0338] Frpc & Frps are network penetration tools; Frpc modifies the IP address specified for Frps.

[0339] SSH Tunnel & Proxychains4 can establish a communication tunnel using a socks5 proxy. Configuration includes the SSH target address, the Proxychains4 proxy address, and the internal network address accessed through the socks5 proxy. Modifying all these addresses can inject attack signals into all traffic.

[0340] Metasploit Framework is a versatile penetration testing framework suitable for all stages of penetration testing. By combining modification of the target and reverse shell address, attack flags can be injected.

[0341] According to the automated fine-grained log annotation method proposed in this application, a preset attack scenario is run, and log information including unannotated logs, alignment information logs, delimiter logs, attack flags, and attack logs is collected based on the running results. An initial source map is constructed based on the audit logs in the alignment information logs. The application logs and traffic logs are associated with the audit logs using the alignment information logs. Based on the association results, the anchor points in the initial source map are identified using the attack flags and attack logs. The nodes in the initial source map that meet the preset segmentation conditions are divided into multiple execution units using the delimiter logs to obtain a refined source map. All anchor points are connected based on the refined source map to form an attack sub-graph, and the annotated logs are obtained based on the attack sub-graph. This addresses the problems of current automatic log labeling methods, such as coarse granularity, insufficient coverage of different log types, and excessive reliance on manual work and domain expertise. It reduces manual workload, minimizes human involvement and dependence on domain expertise, covers multiple data sources, and can simultaneously label traffic, audit, and application logs. It provides fine-grained labels: enabling precise labeling of individual log entries, identifying specific connection, audit event, and application log entries, ensuring the accuracy and completeness of labeling, avoiding the inclusion of entries unrelated to the attack, and minimizing missing attack logs.

[0342] In the description of this specification, the 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 this application. 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. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0343] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "N" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0344] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more N executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.

Claims

1. An automated fine-grained log annotation method, characterized in that, Includes the following steps: Run preset attack scenarios and collect log information based on the results, including unlabeled logs, alignment information logs, delimiter logs, attack flags, and attack logs. An initial source map is constructed based on the audit logs in the alignment information log. The application logs and traffic logs are associated with the audit logs using the alignment information logs. Based on the association results, the attack flags and the attack logs are used to identify anchor points in the initial source map. The nodes in the initial source graph that meet the preset segmentation conditions are divided into multiple execution units using the delimiter log to obtain a refined source graph. All anchor points are connected based on the refined source graph to form an attack subgraph, and the labeled log is obtained based on the attack subgraph. When no anchor point is identified in the initial source map, including: Record attacker behavior logs, wherein the behavior logs include timestamps, attack parameters, and preset matching rules; The timestamp is used to refine the range of the preset matching rules, and the attack parameters and preset matching rules are used in combination to detect the attack log signature, taking into account event combinations, context and attack parameters. The anchor points in the initial source graph are identified based on the attack log signature.

2. The method according to claim 1, characterized in that, The step of associating application logs and traffic logs with the audit logs using the alignment information logs includes: Disable the application's buffer, inject the timestamp and thread ID from the alignment information log into the application log, and obtain the modified application and the modified application log. The modified application is executed to regenerate the alignment information log, and the timestamp and thread ID of the regenerated alignment information log are used to associate the modified application log with the audit log.

3. The method according to claim 1, characterized in that, The method of associating application logs and traffic logs with the audit logs using the alignment information logs also includes: Obtain the timestamp and four-tuple information for each TCP connection and UDP session in the traffic log, and obtain the four-tuple information in the audit log; Based on the UDP session timestamp and four-tuple information in the traffic log, find the network system call in the audit log that is closest to the UDP session timestamp and four-tuple information in the traffic log; Within the lifetime of the traffic file descriptor corresponding to the closest network system call, batch match all system calls with the same four-tuple, and establish the association between the traffic log and the audit log.

4. The method according to claim 1, characterized in that, The step of identifying anchor points in the initial source map using the attack flags and attack logs includes: The pre-defined attack flag scanner is used to detect all IP addresses and the addresses corresponding to the inverted scenario in the attack scenario; Identify connections whose reserved bits in the IP address header of the traffic log are set to 1, and mark the connections whose reserved bits in the IP address header are set to 1 as anchors in the traffic log.

5. The method according to claim 1, characterized in that, The step of identifying anchor points in the initial source map using the attack flag and the attack log further includes: The system calls are hooked into the pre-defined kernel module, and the attack flag is injected into the attack payload. The system call is intercepted using a preset attack flag scanner, the attack payload is restored to its pre-attack state, and the restored attack payload is executed. Identify system call parameters with attack flags in the audit log, and mark the corresponding log entries in the audit log as anchors based on the system call parameters with attack flags.

6. The method according to claim 1, characterized in that, When connecting all anchor points based on the refined source map to form an attack subgraph, the following is included: Construct the derivation tree of the processing procedure; By using the process derivation tree, processes with shared derivation relationships are identified, and system calls within these processes are categorized as belonging to the same execution unit.

7. The method according to claim 1, characterized in that, When connecting all anchor points based on the refined source map to form an attack subgraph, the following is included: Construct the initial handler tree; The number of accept calls in each subtree of the initial handler tree is evaluated, and nodes with an accept call count greater than or equal to a preset number are deleted to obtain the target handler tree, so that different execution units can be defined according to the target handler tree.

8. The method according to claim 1, characterized in that, The process of connecting all anchor points based on the refined source map to form an attack subgraph, and obtaining labeled logs based on the attack subgraph, includes: Based on the refined source graph, the topological order is reversed from the nodes with no outgoing edges; Maintain a set for each node and update the set for each new node. Obtain all marked path edges by taking the union of the sets of all direct successor nodes and subtracting all intersections. If a node is the starting point, mark all paths starting from the starting point and adjust the set of each node to obtain all marked path edges. Connect all the marked path edges to form the attack subgraph.

9. The method according to claim 8, characterized in that, After forming the attack subgraph, the following is included: Check whether all anchor points in the refined source map have been connected to form an attack path; If there are unconnected anchor points, determine their locations and prompt the user to add them.

Images