Malware authors have seen obfuscation as the mean to bypass malware detectors based on static analysis features. For Android, several studies have confirmed that many anti-malware products are easily evaded with simple program transformations. As opposed to these works, ML detection proposals for Android leveraging static analysis features have also been proposed as obfuscation-resilient. Therefore, it needs to be determined to what extent the use of a specific obfuscation strategy or tool poses a risk for the validity of ML Android malware detectors based on static analysis features. To shed some light in this regard, in this article we assess the impact of specific obfuscation techniques on common features extracted using static analysis and determine whether the changes are significant enough to undermine the effectiveness of ML malware detectors that rely on these features. The experimental results suggest that obfuscation techniques affect all static analysis features to varying degrees across different tools. However, certain features retain their validity for ML malware detection even in the presence of obfuscation. Based on these findings, we propose a ML malware detector for Android that is robust against obfuscation and outperforms current state-of-the-art detectors.

From a little research experiment to an essential component of military arsenals, malicious software has constantly been growing and evolving for more than three decades. On the other hand, from a negligible market share, the Android operating system is nowadays the most widely used mobile operating system, becoming a desirable target for large-scale malware distribution. While scientific literature has followed this trend, one aspect has been understudied: the role of native code in malicious Android apps. Android apps are written in high-level languages, but thanks to the Java Native Interface (JNI), Android also supports calling native (C/C++) library functions. While allowing native code in Android apps has a strong positive impact from a performance perspective, it dramatically complicates its analysis because bytecode and native code need different abstractions and analysis algorithms, and they thus pose different challenges and limitations. Consequently, these difficulties are often (ab)used to hide malicious payloads. In this work, we propose a novel methodology to reverse engineering Android apps focusing on suspicious patterns related to native components, i.e., surreptitious code that requires further inspection. We implemented a static analysis tool based on such methodology, which can bridge the “Java” and the native worlds and perform an in-depth analysis of tag code blocks responsible for suspicious behavior. These tags benefit the human facing the reverse engineering task: they clearly indicate which part of the code to focus on to find malicious code. Then, we performed a longitudinal analysis of Android malware over the past 10 years and compared the recent malicious samples with actual top apps on the Google Play Store. Our work depicts typical behaviors of modern malware, its evolution, and how it abuses the native layer to complicate the analysis, especially with dynamic code loading and novel anti-analysis techniques. Finally, we show a use case for our suspicious tags: we trained and tested a machine learning algorithm for a binary classification task. Even if suspicious does not imply malicious, our classifier obtained a remarkable F1-score of 0.97, showing that our methodology can be helpful to both humans and machines.

Since Android is the most widespread operating system, malware targeting it poses a severe threat to the security and privacy of millions of users and is increasing from year to year. The response from the community was swift, and many researchers have ventured to defend this system. In this cat-and-mouse game, attackers pay special attention to flying under the radar of analysis tools, and the techniques to understand whether their app is under analysis have become more and more sophisticated. Moreover, these evasive techniques are also adopted by benign apps to deter reverse engineering, making this phenomenon pervasive in the Android app ecosystem.

A mobile banking app just started up, and the notification "App updated, click here to restart" appears. The graphic theme is the same as the bank. Can we trust it? What if we cannot even trust that tapping an app actually loads the original one? More generally, what if Android notifies an attacker when her victim has just launched the target app of her phishing campaign so that she could cast the hook at the perfect moment?In this paper, we abuse inotify APIs, a mechanism for monitoring file system events, to mount a state inference-based phishing attack from a malicious app installed on the victim's smartphone. We also verified the novelty of our work analyzing 10,000 recent Android malware, and although we found some cases where malware uses inotify for their petty purposes, our attack seems to be publicly unknown.However, since Android constantly evolves year after year, we studied its feasibility over different Android versions and attacker's capabilities. By analyzing 4, 863 of the most popular apps, the most disconcerting finding is that if the attacker knows the installation path of the target app, all Android apps are vulnerable, regardless of the system version. Getting the installation path of an app is a capability that is only protected by a normal permission, and to make matters worse, there are workarounds to get it even without such permission.Even if this capability is denied, we propose different attack models under which this attack is still possible; however, at the end of our work, we provide the remediation to eradicate once and for all these attacks. Through this work, we reported three vulnerabilities to Google. Two were acknowledged as bugs of moderate severity, while the last one was already known but not public.

IoT repackaging refers to an attack devoted to tampering with a legitimate firmware package by modifying its content (e.g., injecting some malicious code) and re-distributing it in the wild. In such a scenario, the firmware delivery and update processes are central to ensuring firmware integrity. Unfortunately, several existing solutions lack proper integrity verification, exposing firmware to repackaging attacks. If this is not the case, they still require an external trust anchor (e.g., signing keys or secure storage technologies), which could limit their adoption in resource-constrained environments. In addition, state-of-the-art frameworks do not cope with the entire firmware production and delivery process, thereby failing to protect the content generated by the firmware producers through the whole supply chain. To mitigate such a problem, in this paper, we introduce PARIOT, a novel self-protecting scheme for IoT that injects integrity checks, called anti-tampering (AT) controls, directly into the firmware. The AT controls enable the runtime detection of repackaging attempts without needing signing keys, internet connection, secure storage technologies, or external trusted parties. PARIOT can be adopted on top of existing state-of-the-art solutions ensuring the widest compatibility with current IoT ecosystems and update frameworks. Also, we have implemented this scheme into PARIOTIC, a prototype to protect C/C++ IoT firmware automatically. The evaluation phase of 50 real-world firmware samples demonstrated the proposed methodology’s feasibility and robustness against practical repackaging attacks without altering the firmware behavior or severe overheads.

A growing trend in repackaging attacks exploits the Android virtualization technique, in which malicious code can run together with the victim app in a virtual container. In such a scenario, the attacker can directly build a malicious container capable of hosting the victim app instead of tampering with it, thus neglecting any anti-repackaging protection developed so far. Also, existing anti-virtualization techniques are ineffective since the malicious container can intercept - and tamper with - such controls at runtime. So far, only two solutions have been specifically designed to address virtualization-based repackaging attacks. However, their effectiveness is limited since they both rely on static taint analysis, thus not being able to evaluate code dynamically loaded at runtime.