# VEDRANDO: A Novel Way to Reveal Stealthy Attack Steps on Android through Memory Forensics
## 2 Background
### Just-in-Time Memory Forensics (JIT-MF)
In the case of stealthy benign app attacks, existing log sources, such as third-party application logs, do not provide enough context to enable anomaly detectors to detect a specific app event as anomalous. The additional JIT-MF logs containing evidence from memory collected by VEDRANDO's events collector provide the necessary additional context with which standard anomaly detection methods can observe a difference between normal app usage and benign app hijack, thus enabling the detection of anomalous events as hijacked benign app events, even in the case of stealth attacks. While attack steps from hijacked apps can be detected through the logs produced by the events collector component, stealth attacks may consist of several steps, whose footprints are dispersed across many separate logs on different victims' devices. The attack detector component of VEDRANDO comprises the detection algorithm outlined in Algorithm 1. The algorithm uses an existing, standard anomaly detection method to detect anomalies in the JIT-MF logs, then correlates anomalies with events collected from other logs found on the device, to reconstruct all the attack steps, including the malware entry point (addressing **R4**). The algorithm takes as input the logs produced by the events collector component, comprising JIT-MF logs with evidence objects from app memory and other logs found on the device (see Table 1), and a user-defined configuration _Config c_. The configuration variable _Config c_ holds settings related to generating the anomaly detection model. Namely, it comprises: (i) the anomaly detection method (_a_); (ii) associated features selected (\([f_{1}\dots f_{n}]\)); (iii) the anomaly threshold value \(t\), which will be used to identify data points as anomalous; and (iv) a list of app-specific regex keywords (\([p_{1}\dots p_{n}]\)) used during the correlation of events. The algorithm outputs a list of events _Correlated_Events e_ attributed to the complete attack steps. #### 4.2.1 Anomaly Detection

All the entries from different log sources are parsed (_line 1_ in Algorithm 1), so each entry has three main fields: (i) timestamp, (ii) log source, and (iii) activity. JIT-MF logs are filtered to remove duplicates. Furthermore, in the case of both the third-party app and JIT-MF logs, we further filter the logs so that only sources of evidence related to the evidence object are considered. For instance, in a messaging hijack attack, where the evidence object is a message sent from the user's phone, the evidence collected from the app is its database, comprising many tables and possibly also containing data unrelated to messaging, e.g., app themes, which may cloud the investigation. The function _GetAnomalies_\(()\) is then called, with the following parameters: (i) parsed JIT-MF logs (_J_); (ii) logs from other sources (_O_); and (iii) configuration settings (_Config c_). The function _GetAnomalies_\(()\) first generates a machine learning anomaly detection model based on the machine learning method and features defined in the user-inputted configuration (_line 4_). The model \(m\) is then applied on the parsed and filtered set of JIT-MF logs \(J\) using the threshold defined in the configuration settings (_line 5_). The anomalous JIT-MF log entries revealed by the anomaly detection model are considered anomalous JIT-MF events. These are then correlated (_line 6_) with other log events (JIT-MF logs and logsfrom other sources) using the app-specific correlation regex keywords given parameter (\([p_{1}\_..p_{n}]\)). The function returns the result of the \(\textit{Correlate}()\) function.