SPARSE: Semantic Tracking and Path Analysis for Attack Investigation in Real-time

Recent literature has leveraged the concept of data provenance, i.e., instead of manually piecing together individual evidence from raw logs, provenance-based systems can construct dependency graphs that explain the relationships between each event, simplifying the attack investigation. Specifically, a dependency graph $G(E,\ V)$ is a heterogeneous graph consisting of nodes $V$ representing system entities and edges $E$ representing inter-entity events. The attributes of entities and events are carefully selected from raw audit logs, which are lean and critical. For entities, we choose processes ($\langle ProcessName,\ ProcessID\rangle$) , files ($\langle FileName\rangle$), and sockets ($\langle IP\ :\ Port\rangle$). For events, we made selections as shown in Table II. For any edge $e\in E$, there is $e=(u,v,t)$, where $u$ represents the subject, $v$ represents the object, and $t$ represents the timestamp of the event. For the two edges in the dependency graph, $e1=(u_{1},v_{1},t_{1})$, $e2=(u_{2},v_{2},t_{2})$, we consider that there is a dependence (causality) between $e_{1}$ and $e_{2}$ if $v_{1}=u_{2}$ and $t_{1}<t_{2}$.

The goal of attack investigation using dependency graphs [12, 15, 13, 16, 20, 18, 14, 23, 32] is to identify all critical events and critical components related to the POI event. A critical component is a subgraph of the dependency graph that retains internal information critical to the attack investigation and eliminates irrelevant system activity. Typically this analysis includes tracing the flow of data through the graph to identify potentially relevant events, and examining the properties of nodes and edges to identify signs of compromise. The goal of an attack investigation is to determine both the source and scope of the attack, ascertain the extent of damage or disruption, and develop remediation and prevention strategies.

As shown in Figure 1, this is a typical data leakage attack. The attacker exploited a vulnerability in apache2 and downloaded the malicious artifact gather.sh. After executing the malware, the attacker collected sensitive data from the target host and saved it in the form of the file leaked.vm2. After using gpg to compress leaked.vm2 into the file leaked, the attacker transferred leaked to the C2 server 192.168.2.3:xx via process ssh.

In Figure 1, the black dashed box denotes the backtracking graph obtained by performing backward causality analysis [29], which includes all events causal-related to the alert. The blue dashed box denotes the suspicious semantic graph obtained by using suspicious semantic transfer, which includes all events suspicious semantic-related to the alert. The red dashed box denotes the critical component graph obtained by analyzing the path-level contextual semantics, which includes all events attack-related to the alert.

Obviously, the number of attack-related critical events ($\sim$ 22) is a drop in the ocean compared to the number of causal-related non-critical events ($\sim$ 200,000). This turns the attack investigation into a needle-in-a-haystack process, making it challenging for analysts to complete the investigation in the optimal time (600s) [24]. However, existing technique such as DEPIMPACT [18], as shown in Section V, has exhibited poor performance. It requires 6,464s ($\gg$ 600s) to generate dependency graphs with 2,473 false positives on average. In addition, it needs to load raw audit logs, resulting in an endless memory overhead. Therefore, we need an attack investigation system with low false positives, low latency and low overhead.

First, we assume that the event logs and digital signatures are credible, similar to previous work [33, 34, 27, 15, 29, 17, 13, 18]. In addition, events related to the attack did not occur before the logs were processed.

Second, we assume that the attacker is external to the system and carries out their attack remotely. This may involve exploiting vulnerabilities within the system or employing social engineering tactics to convince a user to download and run a file containing malicious code. Therefore, we do not support side-channel attacks and insider attacks where the attacker has a legitimate way to access the machine without going through them.

Third, we exclude mimicry attacks [35] from consideration in our threat model. These attacks are designed to evade intrusion detection systems by creating a seemingly benign chain of events within an enterprise environment. Existing intrusion detection systems [36, 37, 38] often rely on heuristics or analysis of individual events, making them vulnerable to such attacks. While detecting mimicry attacks is a limitation of current detection systems, it falls outside the scope of our work. Our focus is on identifying relevant events of alert generated by the detection system as contextual information to investigate the attack.

In this section, we describe the architecture of SParse shown in Figure 2. Given a POI event, SParse can automatically identify the critical component of the dependency graph. SParse consists of two phases: (I) suspicious semantic graph construction (SSGC) and (II) path-level contextual analysis (PCA).

In Phase I, SParse makes use of mature auditing systems [4, 39, 40, 41, 42] to access kernel-level streaming logs and process them into specific data structures. Then SParse proposes a suspicious semantic transfer rule and storage strategy to maintain the suspicious entity list and related event table with low memory overhead. Given a POI event, SParse can construct the suspicious semantic graph (SSG) in real-time.

In Phase II, SParse first performs edge compaction on the suspicious semantic graph. Then SParse proposes a suspicious flow path extraction algorithm to identify possible propagation paths of the data/control flow in the suspicious semantic graph (i.e., suspicious flow paths). Next, SParse performs path-level contextual analysis, scores each suspicious flow path, and determines how relevant the path is to the POI event. Finally, SParse filters out all events that only exist in irrelevant paths from suspicious semantic graph to generate the critical component graph (CCG) as the output.

SParse makes use of mature auditing systems [4, 39, 40, 41, 42] to access kernel-level logs and obtain the required data. At the entity level, SParse focuses on three entity types: file, process, and socket. To differentiate, SParse needs to construct unique identifiers for all entities. For the file, SParse records the absolute path as the unique identifier. For the process, SParse concatenates the PID and name as the unique identifier. For the socket, SParse constructs the 4-tuple (<srcip, srcport, dstip, dstport>) as the unique identifier. At the event level, SParse focuses on three event types: process interactions, file IO events, and network IO events. To the best of our knowledge, existing auditing systems are rich in semantics and meet the data requirements of SParse.

The letter P in APT stands for persistence, which means that an attacker can lurk for a long time until achieves the goal. To support real-time investigation and long-term monitoring, SParse utilizes a state-based structure and suspicious semantic transfer rule to record state changes and associated events for each entity. We next describe the specific data structure and transfer rule in turn.

A suspicious semantic graph often contains multiple parallel edges between two nodes. This is because operating systems typically complete read/write tasks (e.g., file read/write) by proportionally allocating data to multiple system calls. Inspired by recent work for graph reduction [44], SParse merges the edges between two nodes if the time difference between them is less than a given threshold. We ultimately chose 10 seconds as it demonstrates reasonable results in terms of various system calls, such as file transfers and network connections.

In order to perform path-level contextual analysis, it is first necessary to identify possible propagation paths of the data/control flow in the suspicious semantic graph (i.e., suspicious flow paths). SParse proposes a suspicious flow path extraction algorithm that can efficiently handle complex graph structures. In brief, as shown in Figure 4, SParse transforms the suspicious semantic graph into a multiway tree and then traverses it to obtain all suspicious flow paths.

Specifically, as shown in lines 1 to 5 of Algorithm 2, $Q$ and $V$ are the queue structures, where $Q$ holds the events to be traversed and $V$ holds the events that have been traversed. $T$ is the multiway tree structure, which holds the topological information. As shown in lines 6 to 9 of Algorithm 2, SParse traverses event $e$, identifying all incoming edge $ies$ ($ies=G.inEdges(e_{U_{s}})$). As shown in lines 10-13 of Algorithm 2, SParse determines that the incoming edge $ie$ ($ie\in ies$) occurred earlier than event $e$ and has not been traversed ($ie\notin V$), then creates node $ie$ in the multiway tree $T$ and the parent of that node is $e$. Finally, SParse traverses the multiway tree $T$ to obtain all paths from the root node to the leaf nodes, which are output as suspicious flow paths.

The suspicious flow path extraction algorithm takes into account the timeliness and directionality of the data/control flow and is able to handle the complex graph structure efficiently, as demonstrated in Section V-C, where SParse extracts over 140 suspicious flow paths in one second on average. Finally, it is important to note that events exist as nodes in the multiway tree and suspicious flow paths, as shown in Figure 4.

After extracting the suspicious flow paths, SParse needs to perform contextual analysis at the path-level to quantify the degree of influence of the entire path on the POI event (Key Insight (1) in Section IV-A2). Furthermore, the degree of impact between events is determined by the event attributes and the neighboring relationships between events (Key Insight (2) in Section IV-A2).

For each suspicious flow path $p$, SParse calculates the $PathScore$ using the following equation:

where $e$ denotes an event and $E$ denotes the set of all events contained in the path $(e\in E)$. $EventScore$ denotes the degree of impact of event $e$ on the parent node, as defined later. $Len(p)$ denotes the number of events in the path and is used to normalize the $PathScore$.

SParse calculates the $EventScore$ using the following equation:

where $parent(e)$ denotes the parent of event $e$, and $child(f)$ denotes all the children of event $f$ in the multiway tree. $Impact(e,f)$ denotes the degree of impact that event $e$ exerts on event $f$, as defined later. $\alpha$ is an inflation factor to mitigate the problem of decreasing relative impact due to triage (a parent node with multiple children). As shown in Equation 3, $\alpha$ is controlled by the super parameter $C$ and the number of child nodes. It is negatively correlated with $C$ and positively correlated with the number of child nodes.

SParse picks two features (i.e., data flow amount and time), to calculate the $Impact$ using the following equation:

where $e1$ and $e2$ are two events and $e2$ is the parent node of $e1$ (i.e., $e2=parent(e1)$). $e_{D}$ and $e_{T}$ denote the data flow and occurrence time of event $e$, respectively. $Nor(\cdot)$ denotes normalization, which removes differences in $e_{D}$ and $e_{T}$ on the scale. $CS(\cdot)$ denotes the computation of cosine similarity.

Intuitively, we assume that if the data flow amount between parent node and child node is similar, then there is a causal relation between them (e.g., a process reads 526 bytes from the network and then immediately writes 526 bytes to a file, which may be the same content). Similarly, if the timestamps are similar, then there is a causal relation between the events since we think that the exploitation is automated and its steps quickly follow each other.

SParse will iteratively calculate the scores of all suspicious flow paths and consider the path whose score is below a threshold $T$ as an $irrelevant\ path$. Then, SParse filters out events that only exist in the $irrelevant\ path$ and outputs the retained part as a critical component graph to help analysts in attack investigation.

We deploy our implementation of SParse on a computer with Intel (R) Core (TM) i9-10900K CPU @ 3.70GHz and 64GB memory. SParse processes streaming logs from the auditing systems Sysdig [41] and SPADE [5], extracts information in the format as described in Section II-A, and runs continuously in a low-overhead state.

There has been a lot of graph-based related work on attack investigation [12, 47, 48, 21, 44, 18, 15, 13]. However, HOLMES[12] and RapSheet[13] rely solely on defined TTP-like (Tactics, Techniques, and Procedures) rules for detection and investigation. Such approaches suffer from heavy reliance on manual efforts and cannot effectively address zero-day vulnerabilities. HERCULE[47] and WATSON[21] address attack investigation problems by discovering communities (i.e., behavioral abstractions) on the provenance graph. Their purpose is to assist analysts in identifying attack stages from a community perspective, enabling a quick understanding of the purpose of a subgraph in the provenance graph (e.g., file compilation and uploading). HERCULE and WATSON (subgraph-level) differ in granularity from SPARSE (event-level). Hence, we do not compare our work with them.

Here, we compare the performance of SParse with 3 state-of-the-art approaches: SLEUTH [48], NODOZE [15], and DEPIMPACT [18], which are more relevant in terms of methodology (anomaly-score based) and granularity (event-level) for our evaluation. SLEUTH defines TTP-like rules with the added constraint that these rules only fire when certain confidentiality or integrity conditions are satisfied according to a tag-based information flow propagation. NODOZE measures the rarity of different events in the environment and based on this assigns anomaly scores to each event in the dependency graph. We use logs that only contain normal behavior (captured outside of attack periods) as execute profiles (i.e., statistics of events) to satisfy NODOZE. DEPIMPACT assigns anomaly scores to edges based on a number of characteristics (including time, data flow amount, and node access), and then aggregates the scores to determine the entry points through a propagation algorithm. DEPIMPACT then takes as output the overlap events of the forward graph of the entry point and the backward graph of the alert point. Finally, we also perform an ablation experiment on SParse to evaluate the output of different phases.

Table V shows the performance of attack investigation for different techniques in all cases. Lower FP/FPR indicate a better ability to filter irrelevant edges and lower FN/FNR indicate a better ability to retain critical edges. The results show that SParse (SSG + PCA) performs the best. On average, the critical component graph generated by SParse ($\sim$ 113 edges) is 8849 $\times$ smaller than the original dependency graph ($\sim$ 1,000,000 edges), 22 $\times$ smaller than the second-best result (i.e., DEPIMAPCT with $\sim$ 2,487 edges). SParse demonstrates the best capability in filtering irrelevant edges while preserving the attack sequences (FP = 99, FPR = 0.043*$10^{-2}$), 25 $\times$ more effective than DEPIMPACT (FP = 2,473, FPR = 1.087*$10^{-2}$). Moreover, SParse does not miss any critical edges (i.e., FN = 0, FNR = 0). Note that Column “SSGC” and Column “SFP” denote the suspicious semantic graph construction and suspicious flow path of the intermediate product of SParse, respectively.

SLEUTH investigates attack scenarios by defining confidentiality and integrity labels for label propagation. However, SLEUTH cannot ensure to cover all the attack-related edges and therefore performed the worst in FNR (FN = 5.73, FPR = 42.54*$10^{-2}$), resulting in ineffective support for attack investigation. NODOZE performed better than SLEUTH in including critical edges but worse in FPR (FP = 16,682, FPR = 7.329*$10^{-2}$; FN = 2, FNR = 14.85*$10^{-2}$), resulting in the ineffective reduction of investigation cost for analysts. The reason is that the performance of NODOZE relies on whether the execution profile comprehensively covers all benign behaviors but ignores information in the form of streams. DEPIMPACT heuristically selects 3 entry points (one each for files, processes, and sockets), which amplifies the attack surface. DEPIMPACT directly takes the intersection between the forward graph of the entry points and the backward graph of the alert point as output, which introduces massive attack-irrelevant events (FP = 2,473, FPR = 1.087*$10^{-2}$). Regarding the reduction results, SParse exhibits the best performance (FP = 99, FPR = 0.043*$10^{-2}$), we attribute the good performance of our system to (1) SParse employs insight of semantic transfer to construct a suspicious semantic graph related to the POI event that inherently filters out a significant number of irrelevant events (FP = 403, FPR = 0.177*$10^{-2}$), and (2) SParse evaluates the relevance of context to POI events at the path-level rather than in isolation.

In summary, we believe that SParse can satisfy the requirement of low false positives in practice.

In this section, we evaluate the efficiency of SParse when deployed in a real scenario. First, we evaluate SParse on the real-time performance by comparing data generation rate and data consumption rate. Table VI shows that SParse can consume events 15 $\times$ faster than the events generation rate of the host on average, which shows the real-time of SParse is feasible. Then we evaluate the overheads of each component of SParse on time, memory, CPU, and disk, as shown in Table VII. In addition, we conduct comparative experiments with the baseline method DEPIMPACT.

Time and Memory. SParse can perform path-level contextual analysis of the suspicious semantic graph and construct the critical component graph in 2s on average, which is 4091 $\times$ faster than DEPIMPACT ($\sim$ 6,464s). DEPIMPACT uses an impact propagation algorithm to identify entry points. However, when the number of edges in the backtracking graph is high (e.g., case “Hide File”), it takes an extremely long time to reach global convergence (19,814s). In terms of memory overhead, three causes are making SParse smaller than DEPIMAPCT: (1) SParse only stores suspicious nodes in memory when processing streaming logs, so the memory overhead grows extremely slowly and can be seen as constant in scale (i.e., 30MB). (2) The suspicious semantic graphs ($\sim$ 403 edges) read in by SParse are much smaller than the dependency graphs ($\sim$ one million edges) read in by DEPIMPACT. (3) The suspicious flow path extraction algorithm applied in PCA only traverses the graph structure once (a complexity of $O(E)$) and generates a smaller number of SFPs (230 on average). For these reasons, the memory overhead of PCA (132.82 MB) is 2.4 $\times$ smaller than that of DEPIMAPCT (320.81 MB). Finally, it is important to emphasize that SParse is real-time for suspicious semantic graph construction (SSGC), so we do not perform a time overhead evaluation for this component.

CPU and Disk. SParse stores the relevant event table (RET) in the database when processing streaming logs. To evaluate the overhead of SParse on the hard disk, we also perform the relevant experiments. As shown in Table VII, SParse requires only 21.03 MB of disk space, which is 9 $\times$ smaller than the original logs (204.87 MB). This is because SParse only retains events of suspicious semantic relevance, whereas other techniques [10, 15, 18, 28, 17] require the whole logs, which significantly increases overhead on the disk. In addition, the CPU overhead of SParse is 4.5%, due to the simple yet intuitive and effective algorithm.

In summary, we believe that SParse outperforms the latest work DEPIMPACT in all aspects of overhead and can satisfy the requirements of low overhead and latency in application scenarios.

As shown in Section IV-F, there are two super parameters in SParse that need to be set: (1) the $C$ affects the expansion factor, (2) the $T$ filters the paths. As shown in Equation 3, the larger $C$, the smaller the expansion factor $\alpha$, the lower the path score, and the fewer events will be retained by SParse. Parameter $T$, on the other hand, indicates the severity of SParse for path selection; the larger $T$ is, the fewer events will be retained by SParse.

We demonstrate the sensitivity of SParse in parameter selection by testing all combinations of the hyper-parameters $C$ and $T$ through grid search methodology. Specifically, we set the minimum value of $C$ to be 1, the maximum value to be 9, and the step size to be 1; set the minimum value of $T$ to be 0.1, the maximum value to be 0.9, and the step size to be 0.1; and test the performance of SParse on the metrics FP/FN as shown in Figure 5. As parameter $C$ increases, SParse reduces the path score and retains fewer events, hence the FP decreases. At the same time, SParse misses some critical events, causing FN to rise. As the threshold $T$ increases, SParse blocks more paths and preserves fewer events, so FP falls while FN rises. As shown in Figure 5(a), FP decreases gradually from the upper left to the lower right; as shown in Figure 5(b), FN increases gradually from the upper left to the lower right. The effects of these parameter changes on the SParse are in line with our predictions.

Obviously, FP and FN are two evaluation metrics that we both want to be as low as possible, but there is a trade-off between their performance for a system (i.e., a rise in one leads to a fall in the other). Finally, we choose $C$ = 5 and $T$ = 0.5 as the default parameters for SParse. Of course, the manufacturer can adapt these parameters to the specific scenario.