In order to maintain its presence on an infected system, malware employs a variety of persistence techniques. Although persistence is a well-known tactic of modern malware, our community lacks a comprehensive understanding of the types and prevalence of techniques adopted by Windows malware.

Machine Learning (ML) malware detectors rely heavily on crowd-sourced AntiVirus (AV) labels, with platforms like VirusTotal serving as trusted sources of malware annotations. But what if attackers could manipulate these labels to classify benign software as malicious? We introduce label spoofing attacks, a new threat that contaminates crowd-sourced datasets by embedding minimal and undetectable malicious patterns into benign samples. These patterns coerce AV engines into misclassifying legitimate files as harmful, enabling poisoning attacks against ML-based malware classifiers trained on those data. We demonstrate this scenario by developing AndroVenom, a methodology for polluting realistic data sources and launching subsequent poisoning attacks against ML malware detectors. Experiments show that not only are state-of-the-art feature extractors unable to filter such injections, but various ML models experience Denial-of-Service (DoS) with as little as 1% poisoned samples. Additionally, attackers can flip decisions for specific unaltered benign samples by modifying only 0.015% of the training data, threatening their reputation and market share, while evading anomaly detectors operating on the training data. We conclude by raising concerns about the trustworthiness of ML training processes based on AV annotations and argue that further investigation is needed to develop more reliable labeling strategies.

The prevalence of sophisticated evasion techniques employed by phishing attacks in circumventing anti-phishing and email security measures is on the rise. The present study offers an exhaustive analysis of user-reported phishing messages pertaining to five companies over a ten-month period. These messages are of particular interest as they evaded all state of the art security layers in place and were identified by the recipients themselves.To study these elusive phishing attempts, we developed an analysis infrastructure, CrawlerBox, designed to overcome cloaking tactics that exploit browser fingerprinting and bot detection challenges. CrawlerBox is made available as an open-source tool to assist other researchers in pursuing further studies.Over the course of ten months, we gathered 1,551 user-reported messages that were confirmed to be malicious, with a particular focus on those targeting the harvesting of corporate credentials. Our analysis infrastructure enabled us to scan these messages and crawl any associated web resources, including URLs, embedded HTML, and JavaScript content.Our findings indicate that the majority of observed phishing attacks are low-volume but meticulously planned, exhibiting a high degree of premeditation and strategic preparation. In particular, a substantial number of sites were registered and had obtained TLS certificates several weeks before the attacks in order to avoid being flagged based on their young age, a common practice used by products to defeat phishing websites. Furthermore, it was observed that phishing pages are now safeguarded by advanced evasion mechanisms, such as bot detection services and open-source fingerprinting libraries. Notably, QR codes are increasingly used to embed phishing content. The victim needs to use a personal phone to flash the code and access the site; this activity will typically fall outside the perimeter of the corporate security defenses. These findings underscore the evolving sophistication of phishing threats and the urgent need for resilient systems to counter these advanced techniques, further emphasizing the critical role of robust infrastructures like CrawlerBox in enhancing the security and dependability of email systems.

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.

ML-based malware detection on dynamic analysis reports is vulnerable to both evasion and spurious correlations. In this work, we investigate a specific ML architecture employed in the pipeline of a widely-known commercial antivirus, with the goal to harden it against adversarial malware. Adversarial training, the most reliable defensive technique that can confer empirical robustness, is not applicable out of the box in this domain, for the principal reason that gradient-based perturbations rarely map back to feasible problem-space programs. We introduce a novel Reinforcement Learning approach for constructing adversarial examples, a constituent part of adversarially training a model against evasion. Our approach comes with multiple advantages. It performs modifications that are feasible in the problem-space, and only those; thus it circumvents the inverse mapping problem. It also makes it possible to provide theoretical guarantees on the robustness of the model against a well-defined set of adversarial capabilities. Our empirical exploration validates our theoretical insights, where we can consistently reach 0% Attack Success Rate after a few adversarial retraining iterations.

Many studies have proposed machine-learning (ML) models for malware detection and classification, reporting an almost-perfect performance. However, they assemble ground-truth in different ways, use diverse static- and dynamic-analysis techniques for feature extraction, and even differ on what they consider a malware family. As a consequence, our community still lacks an understanding of malware classification results: whether they are tied to the nature and distribution of the collected dataset, to what extent the number of families and samples in the training dataset influence performance, and how well static and dynamic features complement each other.

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.

Nowadays, more than two billions of mobile devices run Android OS. At the core of this success are the open source nature of the Android Open Source Project and vendors’ ability to customize the code base and ship it on their own devices. While the possibility of customizations is beneficial to vendors, they can potentially lead to compatibility and security problems. To prevent these problems, Google developed a set of requirements that must be satisfied for a vendor to brand its devices as "Android," and recently introduced Project Treble as an effort to partition vendor customizations. These requirements are encoded as part of a textual document (called Compatibility Definition Document, or CDD) and various automated tests. This paper performs the first longitudinal study on Android OEM customizations. We first built a dataset of 2,907 ROMs, spanning across 42 different vendors, and covering Android versions from 1.6 to 9.0 (years 2009–2020). We then developed an analysis framework and pipeline to extract each ROM’s customization layers and evaluate it across several metrics. For example, we analyze ROMs to determine whether they are compliant with respect to the various requirements and whether their customizations negatively affect the security posture of the overall device. In the process, we focus on various aspects, ranging from security hardening of binaries, SELinux policies, Android init scripts, and kernel security hardening techniques. Our results are worrisome. We found 579 over 2,907 (~20%) of the ROMs have at least one violation for the CDD related to their Android version — incredibly, 11 of them are branded by Google itself. Some of our findings suggest that vendors often go out of their way to bypass or "comment out" safety nets added by the Android security team. In other cases, we found ROMs that modify init scripts to launch at boot outdated versions (with known CVEs and public POCs) of programs as root and reachable from a remote attacker (e.g., tcpdump ). This paper shows that Google’s efforts are not enough, and we offer several recommendations on how to improve the compliance check pipelines.

Resource-constrained systems are becoming more and more common as users migrate from PCs to mobile devices and as IoT systems enter the mainstream. At the same time, it is not acceptable to reduce the level of security hence it is necessary to accommodate the required security into the system-imposed resource constraints. This paper introduces BAdDroIds, a mobile application leveraging machine learning for detecting malware on resource constrained devices. BAdDroIds executes in background and transparently analyzes the applications as soon as they are installed, i.e., before infecting the device. BAdDroIds relies on static analysis techniques and features provided by the Android OS to build up sound and complete models of Android apps in terms of permissions and API invocations. It uses ad-hoc supervised classification techniques to allow resource-efficient malware detection. By exploiting the intrinsic nature of data, it has been possible to implement a state-of-the-art data-driven model which provides deep insights on the detection problem and can be efficiently executed on the device itself as it requires a very limited computational effort. Besides its limited resource footprint, BAdDroIds is extremely effective: An extensive experimental evaluation shows that it outperforms the currently available solutions in terms of accuracy, which is around 99 percent.

Modern versions of Android have introduced a number of features in the name of convenience. This paper shows how two of these features, mobile password managers and Instant Apps, can be abused to make phishing attacks that are significantly more practical than existing ones. We have studied the leading password managers for mobile and we uncovered a number of design issues that leave them open to attacks. For example, we show it is possible to trick password managers into auto-suggesting credentials associated with arbitrary attacker-chosen websites. We then show how an attacker can abuse the recently introduced Instant Apps technology to allow a remote attacker to gain full UI control and, by abusing password managers, to implement an end-to-end phishing attack requiring only few user's clicks. We also found that mobile password managers are vulnerable to "hidden fields" attacks, which makes these attacks even more practical and problematic. We conclude this paper by proposing a new secure-by-design API that avoids common errors and we show that the secure implementation of autofill functionality will require a community-wide effort, which this work hopes to inspire.

Android apps are generally over-privileged, i.e., they request more permissions than they actually need to execute properly. Prior to version 6 users can install an app only by accepting all its requested permissions, while newer Android versions allow users to dynamically grant/deny groups of permissions. Since some them impact on users' privacy, we argue that users should be granted control at the granularity of the single permission. We propose a novel approach, which does not require any change to the underlying OS, allowing users to selectively remove permissions from apps before installing them, and with a finer granularity. \nWe developed \tool, an open-source tool, that implements our methodology, and we present the viability of our approach via an empirical assessment on 81K apps, \nunderlining that, in the worst case, up to 86% of the apps can execute without crashing when none of the requested privacy-related permissions are granted.