# VEDRANDO: A Novel Way to Reveal Stealthy Attack Steps on Android through Memory Forensics
## 2 Background
### Just-in-Time Memory Forensics (JIT-MF)
```
1:JITMF Logs \(J\), Other Logs \(O\), Config \(c\)= {Anomaly Detection Method \(a\), Anomaly Detection Features \([f_{1}\_..f_{n}]\), Anomaly Detection Threshold \(t\), Correlation Keywords Regex \([p_{1}\_..p_{n}]\)
2:Correlated_Events e=\([\emptyset]\)
3:\(J,O\leftarrow\textit{Parse}Logs(J,O)\)
4:\(J,O\leftarrow\textit{GetAnomalies}(J,O,c)\)
5:functionGetAnomalies(JITMF Logs \(J\), Other Logs \(O\), Config \(c\) )
6:\(m\leftarrow\textit{GenerateModel}(O,J,c[a],c[[f_{1}\_..f_{n}]])\)
7:\(j\_itmf\_anomalous\_log\_entries\leftarrow\textit{DetectAnomalies}(J,m,c[t])\)
8:\(e\leftarrow\textit{Correlate}(jitmf\_anomalous\_log\_entries,J,O,c[[p_{1}\_..p_{n}]])\)
9:return e
10:endfunction
11:functionCorrelate(\(jitmf\_anomalous\_log\_entries\), JITMF Logs \(J\), Other Logs \(O\), Correlation Keywords Regex \([p_{1}\_..p_{n}]\))
12: Events e=\([\emptyset]\)
13:for each\(\textit{an}\in jitmf\_anomalous\_log\_entries\)do
14:\(j\_itmf\_log\_entry\leftarrow\textit{Get}JITMFLogEntryAt(an)\)
15:else
16:\(j\_itmf\_log\_entry\leftarrow\textit{an}\)
17:endif
18:\(obj\leftarrow\textit{GetEvidenceObject}(jitmf\_log\_entry)\)
19:
20:\(/*Feature-based\textit{ correlation}*/\)
21:for each\(\textit{p}_{i}\in[p_{1}\_..p_{n}]\)do
22:if\(obj\_.match(\textit{p}_{i})\)then
23:\(keyword\leftarrow\textit{obj}[p_{i}]\)
24:\(e\leftarrow e\bigcup FindEventsWithKeyword(O,J,p_{i})\)
25:endif
26:endfor
27:endfor
28:\(/*Time-based\textit{ correlation}*/\)
29:\(j\_itmf\_anomalous\_logs\leftarrow\textit{SortByTime}(jitmf\_anomalous\_log\_entries)\)
31:\(start\_time\leftarrow\textit{GetFirstEventTime}(jitmf\_anomalous\_logs)\)
32:\(end\_time\leftarrow\textit{GetLastEventTime}(jitmf\_anomalous\_logs)\)
33:\(e\leftarrow e\bigcup GetEventsInTime(O,start\_time,end\_time)\)
34:return e
35:endfunction
```

**Algorithm 1** Anomaly detection and correlation algorithm

#### 4.2.2 Correlation

JIT-MF log events include a timestamp and metadata of the _Evidence_object_ definition as described in the JIT-MF driver. Regardless of the driver implementation or the app, the contents of the _Evidence_object_ can be parsed to derive relevant keywords used during the attack step. App-specific correlation keyword regex retrieves the relevant keywords from anomalous JIT-MF log entries. The _Evidence_object_'s makeup is app-specific; therefore, the regex pattern used to retrieve this metadata or identifier from a log entry must also be app-specific. That said, there are cases where the keyword regex is the same across apps, due to formatting standards, e.g., the object ID may be in UUID format, which is a standard format. The \(\textit{Correlate}()\) function accepts as input the anomalies detected, JIT-MF logs, logs from other sources, and the app-specific correlation regex keywords. If the anomaly is a timestamp (as is the case with time-based anomaly detection), JIT-MF logs at that time are retrieved (_lines_12-17_ in Algorithm 1). The \(\textit{Evidence\_object}\) of the anomalous JIT-MF log entry is retrieved (_lines_18) and used to perform correlation, as follows: The algorithm correlates anomalous JIT-MF log events with events in other log sources, based on two mechanisms: (i) feature-based correlation and (ii) time-based correlation. It is unlikely that normal events have identical keywords in their \(\textit{Evidence\_object}\). However, in the case of malware, especially during propagation, \(\textit{Evidence\_objects}\) containing matching keywords are expected. Therefore, events in other log sources that contain identical keywords to those found in anomalous JIT-MF log events (_lines_21-26) are considered further attack steps, and are added to the list of \(\textit{Correlated\_Events}\)\(e\). This is referred to as feature-based correlation. Any other attack steps performed in the attack are assumed to have happened in the period within which the correlated list of attack steps occurred. Therefore time-based correlation is used to search for other events that occurred in other logs when the JIT-MF log anomalies were detected (_lines_30-33).