The recent wave of cryptocurrencies contributed to the debut of a new malware class called cryptominers, cryptojackers, or simply miners. After infecting a device, these applications start solving computationally hard puzzles that support the cryptocurrency network, getting rewards for their work that are accumulated on the miner developer’s account. The ease of monetization and the anonymity factors enabled a quick growth of the mining malware. In 2017, the skyrocketing price of cryptocurrencies caused by the enormous attention to these technologies has played a huge role in the cryptojacking proliferation . Not surprisingly, miners have quickly gained popularity and appeared among the top security threats in 2018 [8, 34]. Security researchers have also paid attention, with many papers focusing on browser-based mining [16, 11, 24, 30, 20, 31, 25, 29] and binary mining  appearing in the last year.
Due to the cryptocurrencies boom, end-user demand for mining applications has emerged. Prior to July 2018 everybody could simply find mining applications on Google Play and attempt to generate a few coins on the mobile device. Yet, as the smartphone-based mining no longer generates interesting profits for the benign user [31, 6], the interest to these apps has significantly diminished. Now Google has removed mining applications from Google Play, but they are still available on alternative markets. The “crash” of the cryptocurrency market in the end of 2018 forced the operation of several mining services to shut down. For instance, recently the most popular service Coinhive has announced discontinuation of its service . Still, there are many alternatives, like CryptoLoot and JSEcoint, which are important cyber threats today and that may further proliferate during the next crypto boom111https://blog.checkpoint.com/2019/04/09/march-2019s-most-wanted-malware-cryptomining-still- dominates-despite-coinhive-closure/,222https://blog.malwarebytes.com/cybercrime/2019/05/cryptojacking-in-the-post-coinhive-era/.
The Android ecosystem itself is huge, comprising not only mobile devices but also wearable technology, TVs and cars. It is therefore a lucrative target for adversaries due to the number of potential victims. Even smart TV appliances can now be infected with mining Android apps333http://blog.netlab.360.com/adb-miner-more-information-en/. Recent security industry reports mention that mining capabilities are being introduced to existing malware families or added into repackaged Android applications [8, 34, 10].
Indeed, mobile mining has certain advantages for the attackers. The mining code packaged as an application (app for short) can be more persistent than website visits, by running in the background and when the user is not present. The cost of creating and distributing a miner is negligible, given the ease of application repackaging  on Android and the availability of mining libraries . But miners are particularly dangerous for mobile devices. The extensive computations performed during the mining process drain the battery and increase the temperature of the device, what can render the device unusable. For example, a malicious family called Loapi causes the mobile devices to explode . Therefore, there is an urgent need to study the Android miner phenomenon and to be able to detect such applications.
Contributions. To the best of our knowledge, our paper is the first systematic study of Android miners. We make the following contributions.
We have collected a large dataset of mining Android apps, which includes both Web-based and binary-based cryptocurrency miners. As our focus is on the Android mining phenomenon, our dataset contains malicious mining applications, and also honest miners that declare their mining activity upfront and could be solicited by the users. We also include samples of non-mining applications that can confuse the basic detection approaches (scam, wallet apps, etc.). Our dataset has been fully confirmed by manual analysis. We share our labelled dataset and the metadata with the community444The dataset is available upon request at https://standash.github.io/android-miners-dataset/..
At least 5 miners from our dataset have previously never been uploaded to the popular VirusTotal service. We have also found 16 apps, including both malicious and honest miners, that are not detected by any VirusTotal scanner. Finally, we have ranked the antivirus engines at VirusTotal based on our dataset.
Using our verified dataset as the ground truth, we performed dynamic analysis of the miners and compared the results with randomly selected benign applications. We identified a set of dynamic metrics that are the most efficient for accurate classification results, achieving 95% of accuracy and the AUC score of 0.9880.009. Based on our findings, we propose a tool called BrenntDroid that can be used to detect miners dynamically and to check if an app indeed mines cryptocurrencies (to combat scam).
2.1 Android Applications
Android apps are distributed as archive files (.apk) that consist of the compiled Java code (.dex), the application manifest (AndroidManifest.xml) containing the requested Android permissions and subscriptions to system events, application resource files (e.g., Web-based resources such as .js and .html files), and native libraries (.so files).
The contents of .apk archives can be extracted with apktool  that, among other things, disassembles the .dex files and transforms the disassembled Java classes into smali  – a low-level human-readable code representation for Java code in Android platform.
Listing 2 shows how a native library can be called via the System.loadLibrary(...) interface: a Java wrapper class has to be created in the Android app, where the .so library has to be loaded (line 3) and the corresponding native methods declared (line 5). Listing 3 illustrates how a shell command can be executed from the Java code of an Android app.
2.2 Android Cryptocurrency Miners
Both of the two mining approaches can be used to create either legitimate or illicit miners: the miners that belong to the former category explicitly ask the user consent for mining, while the latter attempt to hide the fact that they are mining. Also, the Web-based approach is typically used by the authors of malicious websites, while the binary approach is favored by the authors of the traditional computer malware. It is important to stress, that both of these approaches can be used within Android apps.
Software that mines cryptocurrencies typically rely upon drive-by mining services such as CoinHive555https://krebsonsecurity.com/2018/03/who-and-what-is-coinhive/ that provide the necessary infrastructure to mine cryptocurrencies such as Monero. This is particularly attractive for regular users, as Monero can be mined using the CPU, instead of expensive GPU or other specialized hardware . There exist other “lightweight” cryptocurrencies, such as Litecoin and Ethereum that can be mined using the commodity hardware. However, according to various reports, Monero significantly dominates them [8, 31, 11]. Also, to facilitate cryptocurrency mining with comparatively weak hardware, mining service providers support creating mining pools, when several devices combine their computational power to perform mining collectively. Therefore, when multiple devices are combined into a single mining pool, mining the lightweight cryptocurrencies becomes profitable.
Listing 4 shows an example of an initialization script that, when embedded into a Web page, starts mining the Monero cryptocurrency once that page is loaded. The “SITE_KEY” needs to be substituted by the actual hash of the public site key, which is connected to a certain cryptocurrency wallet tat willh receive the mining reward (the mining credentials). In this example, the anonymous version of the CoinHive API has been used: any device that loads the script will perform the mining, however the reward will be received only by the owner of the site key. Moreover, a wallet can have multiple public site keys associated to it, and the “identity” of the wallet behind the miner cannot be inferred. Such a simple mining initalization script is particularly popular in malicious website mining, as it is takes no effort for embedding it, and provides anonymity .
2.3 Our Terminology
To summarize, in this paper, we distinguish the following categories of cryptocurrency miners:
Illicit miners are applications that try to perform stealth mining, i.e. they do not warn users explicitly about the mining process, or selfish mining, i.e., they mine cryptocurrencies explicitly, but redirect the profits to the attacker, not the user.
Legitimate or benign miners are applications that both declare their mining activities and the user is the sole benefactor of the mining process.
Miner-related apps are applications that match many mining string patterns, but do not perform cryptocurrency mining (e.g., wallet apps).
Scam miners are applications that pretend to perform mining activity, but do not actually perform any mining.
Binary miners are applications that include binary mining payload.
3 Dataset Collection
We started by collecting several samples of Android miners. These applications have been found based on relevant security industry blog posts and whitepapers, e.g., the SophosLabs report , that had explicitly mentioned the hashes of illicit Android miners. We have also collected several miners from different Android app stores (Google Play777This research had started before Google decided to remove all mining apps from Google Play on ., F-droid, etc.). This initial dataset has been used to create a set of strings and rules in the YARA notation888http://virustotal.github.io/yara/ indicating mining payload in the code and metadata.
The initial set of miner-related strings and YARA rules contained only a few generic keywords, such as “Monero”, “Litecoin”, generic mining API calls such as CoinHive.Anonymous(), CRLT.Anonymous(), and CoinHive.User(), and domain names of the popular mining pools such as “us.litecoinpool.org” “mine.xmrpool.net”. Yet, while such strings are already useful for finding some potential miners, they are insufficient.
During already the first iterations of the dataset collection, we realized that a fully automatic search against many diverse apps is inevitably prone to errors. This was unacceptable, as we aimed to build a reliable collection of apps that could be used as the ground truth for detecting Android miners. Therefore, we manually analyzed each app with at least a single match to the miner-related strings. We were looking for characteristics of the mining activity and the intended interactions with user: (a) the mining code (e.g., the code that initializes mining and the mining libraries); (b) how the mining can be triggered by a user (by interacting with an app in a certain way or by simply launching its main activity); (c) supported cryptocurrencies; (d) the declared functionality of the app and whether it tries to “hide” its intentions. We also aimed to find more string patterns that can be used to extend our sample of miners. Once we had found a new pattern, we added it to our set of miner-related strings, and re-ran the string search against the apps that had no previous matches and a new batch of apps that we have been downloading.
To summarize, we performed many iterations of the following steps: (1) find a large sample of potential Android miners using string search, and download them; (2) perform a manual analysis to find the evidence that these apps are miners, and discard false-positives; (3) update the search strings used at the step (1) with new patterns discovered at the step (2). We repeated these steps multiple times, increasing our dataset of Android miners and improving its quality.
3.1 Main Application Sources
To find a large set of potential miners, we used the popular platforms VirusTotal999https://www.virustotal.com/ and Koodous101010https://koodous.com/. Services provided by these platforms are quite different, but they both allow to search for Android apps that match specific criteria, and to download them. Below, we briefly introduce these platforms and describe how we utilized them.
VirusTotal checks user-submitted binaries (including Android apps) against several popular anti-virus engines. Currently, VirusTotal allows not only to perform scans in the black-box manner, but also to search over the dynamic data of apps (e.g., the URLs that apps try to connect to), and to perform string pattern search over its application database.
We first used the Private API111111https://www.virustotal.com/en/documentation/private-api of VirusTotal to search and download the apps from our original dataset by their hashes, and to collect their metadata. From this metadata we extracted the information about the malware families that these apps potentially correspond to, and manually compiled a list of the families related to cryptocurrency mining (as reported by the anti-virus engines used by VirusTotal). Next, we used the file search functionality121212https://www.virustotal.com/intelligence/help/file-search/ of VirusTotal, and downloaded all Android apps that have been recently detected by at least one of the anti-virus engines and belong to at least one malware family from our list. Additionally, we checked the dynamic information of apps against a set of known miner-related strings (e.g., mining pools and domain names listed in [20, 16]), and downloaded the matching apps as well.
Koodous is collaborative platform that allows to download Android apps, analyze them, and share the analysis results. Koodous performs static and dynamic analyses of apps using the state-of-art Android analysis tools like Androguard131313https://github.com/androguard/androguard and the Cuckoo sandbox141414https://cuckoosandbox.org/. Users can also write custom YARA rules151515https://yara.readthedocs.io/en/v3.4.0/writingrules.html for finding and downloading the matching apps. We used this functionality to create our own YARA rulesets for searching and downloading potential Android miners from Koodous, based on the set of miner-related strings we identified during our manual analysis over the sample retrieved from VirusTotal (see Section 3.2). We also searched for the YARA rules that had been already written by the community to detect miner apps, and incorporated them into our ruleset as well.
3.2 Manual Analysis
4 Dataset Description
|Category||# samples (%)|
|Binary illicit||51 (6.69%)|
Top Android permissions and system events used.
Permissions and system events subscriptions are widely used as features to detect Android malware [2, 36], and it is interesting to see whether the miner population uses the same permissions and listens to the same system events as generic malware.
Wang et al. , Jiang and Zhou , and Feldman et al.  have previously compared Android malware and benign apps in terms of requested permissions. Table 3 lists the top 10 requested Android permissions across our sample of miners. It is evident that the only permission needed for Android miners to properly function is the android.permission.INTERNET, which is the only permission requested by 286 miners. This permission is not considered dangerous anymore, and is granted by the Android system without user consent . Comparing the statistics in the works of Wang et al.  and Jiang and Zhou with Table 3, we can conclude that miners generally do not request permissions that are very prevalent in malicious samples only, e.g., READ_SMS.
Table 3 lists the top 10 most occurring system event subscriptions, else called filtered intents. Most of the miners have subscribed to android.intent.action.BOOT_COMPLETED, which means that they will attempt to resume their work as soon as the device has been booted. This system event is highly indicative of malicious apps . We see also that a significant number of miners tries to monitor the battery consumption and the network connection status.
Only 39 miners from our sample can be characterized as generic malware with respect to their behavior, while 30 of these miners are actively forcing users to allow them administrative privileges, and monitor whether they receive the role of the device administrator, and whether users try to revoke this role.
|CoinHive Android SDK||https://github.com/theapache64/coin_hive_android_sdk||437|
8 third-party mining libraries have been identified in our sample. Table 4 lists these libraries and the number of apps from our sample that rely on them. In total, these libraries are used by 671 miners. We could not identify the origin of the mining code for the remaining 57 miners. This was either due to the fact that they might be using a custom mining library that we could not identify (mostly the case for legitimate miners), or the library has been heavily changed and obfuscated so that we could not match it to any of the original libraries (mostly the case for illicit miners).
We observed that in many cases the third-party libraries have been used “as is”, however in some cases the original library is changed by the authors of miners. For instance, the original CoinHive Android SDK library has had large modifications in at least 64 illicit miners from our sample. In all these cases the changes were non-significant to the core functionality of the library (perhaps, made only for evading detection): e.g., package name has been changed, several classes not related to mining have been removed, variable names have been changed, etc. For example, in 8 of these cases, the “engine.html” file, which is the core of the library, has been totally unchanged (we checked the hashes of the files against the original file provided by the library). In 56 cases the “engine.html” file has been renamed into “coinhive.html” and modified, yet the original mining functionality was intact.
Overall, these observations favor the intuition that, given the small hash rate for smartphone-based mining , the malicious actors would not spend resources on implementing the mining functionality from scratch, but rather use the libraries that are already available.
By looking at the used third-party libraries and the code of the miners from our sample, we were able to determine that 586 miners target the Monero cryptocurrency, 5 miners target Ethereum, 5 miners target Litecoin, and 3 miners have been created to test the capability of mobile devices for mining Bitcoin. 91 binary miners in our sample rely on third-party mining libraries that can be used to mine multiple cryptocurrencies (Monero, Litecoin, Ethereum, Bitcoin, and others).
Similarly to previous works Konoth et al.  and Hong et al. , we tried to identify the mining campaigns by grouping the sets of miners that are likely to share the same origin, and therefore may share the benefits from the mined cryptocurrency. As most of the miners from our sample reuse the same third-party mining libraries, it is difficult to identify the same origin by looking at the similar code patterns in the apps. Therefore, we assume that two miners belong to the same campaign only if they share the same mining credentials used for authentication with the mining services (e.g., the cryptocurrency wallet id and/or CoinHive site key).
Figure 1 shows the distribution of the sizes of the mining campaigns found within our sample. Overall, we found 94 unique mining campaigns, with the largest campaign enclosing 342 miners, two smaller campaigns enclosing 56 and 24 miners respectively, and 91 small campaigns of 10 miners and less. The rest of the apps are benign miners that did not contain any mining credentials, or illicit miners for which we could not retrieve these credentials. Therefore, we could not consider such miners to be a part of a mining campaign.
At this stage we cannot conclude whether the small mining campaigns that we found are indeed small “in the wild”, as this requires further large-scale data collection and analysis. However, the two relatively large campaigns suggest that in the wild there may be many Android apps created or, more likely, repackaged by the same malicious developer that is actively trying to maximize her mining profit. Indeed, it is relatively inexpensive to repackage an already existing app and insert only the mining code. We have seen many examples that support this conclusion, see Section 5.
When searching for the mining credentials used in the biggest mining campaign that we identified, we found that a security researcher has already reported191919https://twitter.com/fs0c131y/status/950082654891802630 this mining campaign. Still, our sample contains more apps than it was originally reported (342 versus 291). Moreover, at least 24 of apps from our sample that belong to this campaign do not share similar code (unlike the apps seen by the researcher), suggesting that the campaign might be even bigger in the wild. In our sample there are another 64 miners that correspond to 17 mining campaigns which mining credentials have been reported in whitepapers and blogposts by other researchers. Yet, we have collected 173 miners that correspond to 76 campaigns that have not been previously reported. In particular, the second largest illicit campaign shown on Figure 1 is has not been reported before.
We have also encountered 34 Android apps that we refer to as miner-related. While these apps do not perform any cryptocurrency mining, they are riddled with keywords, links, and mining credentials relevant to the real mining apps. Such apps may pose additional challenges for automated miner detection approaches, and it is therefore important to consider their presence “in the wild”. We include these apps as a separate category in the dataset we have built, because they are valuable confusing data points. Below we briefly describe them.
12 of these apps have useful functionality: e.g., they either monitor the value of cryptocurrencies, or serve as cryptocurrency wallets, or simply ask for donations in cryptocurrencies (for apps of the latter case we found a match for a cryptocurrency wallet). These applications can serve as confusion points since various static indicators would suggest the presence of mining code (see Section 5.1). The rest of 22 miner-related apps are scam. They do not have any useful functionality, and claim to be legitimate mining apps. Their monetization comes from either showing paid ads, or tricking their users into paying for an “upgraded” version of the app: for example, the “basic” version may claim that it does not support transferring the mined funds, until a sufficient amount of a cryptocurrency is mined. In particular, 2 of these apps employ a trick to improve their ratings: from the start they promise the user 50,000 Satoshis (0.0005 Bitcoins) for “free” if the user rates the app. Such apps correspond to another possible source of confusion for automated detection approaches: while, an app claims it is a cryptocurrency miner and should be immediately considered as a positive data point (e.g., by classification approaches from the area of machine learning), they neither contain the mining code, nor manifest the runtime behavior typical to the mining apps (see Section 5.2).
Table 6 summarizes top 10 permissions requested by miner-related applications, and Table 6 shows top 10 system events that miner-related apps subscribe to. The requested permissions and monitored system events in these apps largely coincide with the statistics reported for the mining sample in Tables 3&3. This further shows that lightweight, keyword-based detection approaches for miners may produce many false-positives. At the same time, permissions and system events may indicate that miner-related apps, especially of the scam type, are supplied by malicious actors. Yet, our sample of miner-related applications in the dataset is relatively small; thus a larger investigation of a larger population of such applications is warranted.
4.1 Examples of Mining Applications
The screens in Figures 1(a) and 1(b) demonstrate examples of two mining applications. The first app is an illicit miner202020SHA256 a3f376a5c74e1fe112786b4ad450a6b3976226e2164b106653483522adf6bced. It looks like an app that was created just for fun and provides very basic functionality playing a funny song. However, invisibly it mines the Monero cryptocurrency in a hidden Web browser. The second example is a legal miner created specifically for mining Bitcoin on ARM devices212121SHA256 727cd092ed478453c2f19d180e1aa8fd22e43dc9cf24772c5ae2ca36cf9dbc4e. In this miner users need to configure their own mining credentials and run the miner. It is a binary miner that exploits a standalone executable minerd. Both apps have been previously hosted on Google Play.
4.2 VirusTotal Analysis Results
We checked each sample from our mining dataset using the VirusTotal service. Using their API, we downloaded the VirusTotal extended analysis reports for each app in our dataset, obtaining the latest report version for the time of writing. If a report was not found, i.e., a sample had not been uploaded to VirusTotal before, we submitted the application on our own.
We were the first who found and uploaded at least 5 samples to VirusTotal222222We have not collected this statistics from the start, therefore, we can confirm only 5 cases.. Among previously seen samples, an app from our dataset was checked by VirusTotal at the earliest in October 2013, while the most recent one was uploaded in March, 2019.
All applications from our dataset have been checked by at least 1 out of 77 antivirus products aggregated on the platform. Figure 3
shows the Cumulative Distribution Function (CDF) representing the amount of antivirus scanners that detected each application from our dataset. On average, a sample in our list is marked as malicious by22 scanner. Maximum, a sample in our dataset is detected by 43 different scanners. This shows that even old, well-known samples are not recognized by all scanners.
In Figure 3, we can spot three high steps at 3, 10 and 35 detections (63, 57 and 59 new samples correspondingly). These steps could have appeared because some scanners have similar detection engines, or they share antivirus databases. Indeed, Table 7 proves this assumption. It shows that the results of some scanner pairs are either identical or highly correlated.
|Scanner 1||Scanner 2||Correlation|
Interestingly, 16 miners are not detected by any antivirus product. Table 8 reports SHA256 hashes of these miners and the accompanied data that we extracted from VirusTotal reports. We determined 10 out of these 16 apps as legitimate miners, and 6 of them as illicit. The miners from this table are not new: the oldest is dated back to 2013. However, even the illicit miners among these apps are still not recognized as malicious or unwanted. For 4 apps this can be explained by the fact that the mining script is stored in the encrypted form and is being decrypted at runtime, and 2 of the undetected apps use obfuscation. Based on these results, we cannot not draw firm conclusions whether mining functionality is deemed malicious by VirusTotal scanners, as 10 legitimate miners are also detected as malware. It could be also that our miners contain some other malicious payloads, even though our analysis have not revealed such evidence for legitimate miners (but there were “also-malicious” illicit miners).
|SHA256||Illicit||First seen||Last seen||Amount of||Amount of|
Figure 3(a) shows how many times a sample from our dataset has been submitted to VirusTotal. On average, this value is around 1.85. Indeed, 558 samples have been uploaded to VirusTotal only once, while the most frequently submitted sample has been uploaded 26 times.
Using the information on the date when a sample was submitted to VirusTotal first time, we evaluated if our dataset is relatively new. To achieve this goal, we aggregated the samples by months when they have been first spotted on VirusTotal. Figure 3(b) shows the timeline when the apps from our list were submitted to VirusTotal for the first time. Several interesting observations can be derived from this figure. First, we can see that our dataset is relatively new: the majority of applications have been first spotted on VirusTotal in 2018. Second, the figure shows that before the last quarter of 2017 there were a few submissions of new miners, while in the beginning of 2018 we observe huge spike. This phenomenon can be explained by cryptocurrencies popularity in general. Indeed, before 2017 the interest to the cryptocurrencies was mostly driven by niche experts and geeks. However, in 2017 the price of Bitcoin and other cryptocurrencies started to grow exponentially. This attracted the attention of malware developers, who started to explore this market. Clearly, a miner is a very attractive type of malicious application because it directly earns money for the developer, while almost no efforts need to be spent on its preparation and distribution through repackaging. Not surprisingly, in the end of 2017 antivirus companies started to consider Android miners as harmful applications [37, 8].
We have also ranked the VirusToal scanners according to their ability to detect mining applications on our the dataset of manually confirmed miners and their detection results. We assigned +1 point to each true positive and -1 point to each false negative; if a scanner failed to scan a sample or VirusTotal does not have the data, we gave 0 points. The final score is calculated as sum of these points. Table 9 reports the top 10 VirusTotal scanners based on this score.
Note that Table 9 shows the rating based only on our dataset consisting on the samples from one class (miners). This could introduce a deviation in our ranking because a scanner that marks all submitted files as malicious would take the first place in our ranking. To make a more fair list, we would need to get also the list of benign applications and test the scanners on them. However, a comprehensive evaluation of the VirusTotal scanners is out of our scope for this work.
5 Detecting Android Miners
5.1 Static Indicators
In this Section we describe the heuristics that we identified and used when performing manual analysis of potential miner apps (Section3). These heuristics can be used as static indicators for pinpointing potential Android miners across large amounts of apps.
The authors of binary miners typically place the mining libraries (e.g., “libcpuminer.so”) or standalone executables (e.g., “minerd” ELF executable) under the “res/raw/” or the “assets/” folder of an app archive. These libraries are invoked either via the Android “System.loadLibrary(...)” interface, or by spawning separate application processes for executables (the Android-specific code looks similar to the examples we made in Listing 2 and 3).
We also looked for the mining credentials (e.g., cryptocurrency wallet and site key identifiers) passed into the mining initialization code – the presence of known mining credentials in apps immediately indicates that they are most likely miners. In general, we observed that illicit miners contain the mining credentials somewhere in the app code (577 illicit miners from our sample have hardcoded mining credentials). Therefore, to significantly reduce the effort of quickly pinpointing new miners we built a collection of such identifiers.
Finally, to search through the apps for which we could not easily find known mining credentials or code patterns, we used potential mining domains242424We compiled a large list of known mining domains from various sources such as https://github.com/hoshsadiq/adblock-nocoin-list/blob/master/nocoin.txt. and simple keywords such as miner, bitcoin, stratum, monero, hashrate, etc. While the keyword search allows to find new previously unseen miners (which helped us a lot at the initial stages of our work), using it alone is prone to large amounts of false-positives. For example, many non-miner apps that we encountered contain an adblock functionality that actively tries to block known cryptocurrency mining domains (and thus, there will be a match to our miner domain list).
We found cases when illicit miners apply various evasion techniques and their combination to avoid detection: the code fragments that initialize the mining process and contain the mining credentials may be not shipped with the miner app itself, or this code can be encrypted within an app and only be decrypted at runtime.
For example, we found cases when an illicit miner loads the mining credentials from a remote server upon the application startup. The download link is present within the code of the miner, but it has been obfuscated. However, when we launched the app in the Android emulator, the logcat utility allowed us to see which link the app is trying to connect to, and that it downloads a JSON file. Upon further inspection of the file252525The link is still available at the time of writing: https://raw.githubusercontent.com/cryptominesetting/setting/master/setting.txt, it became clear that it contained the mining credentials. We provide a screenshot of this file in Figure 5. In this figure, we can see the settings for the mining script, including the wallet address, the preferred mining pool, and some configurations that allow to start mining when the device is charging and not charging. By examining the public GitHub repository262626https://github.com/cryptominesetting/setting where the link is hosted, we found several other files that had similar structure but different mining wallets. We added these wallets to our miner-related strings, however we have not found any apps that use them yet. This could be due to some other ways of hiding the mining payload that we are not yet aware of, or possibly the owner of this repository is creating illicit cryptocurrency miners for other application platforms (e.g., Google Chrome extensions).
We also found an interesting case when an illicit miner consists of heavily obfuscated code (thus we initially flagged it only as suspicious after a keyword match). The app actively tries to obtain the administrative permissions from its users, and contains an encrypted file “assets/5a240bed02ae6”. Upon thorough inspection of the app, we we found the decryption key and were able to decrypt the file: we realized that the file contains a miner initialization code which is being decrypted at runtime and dynamically called at via the Dalvik classloader (the main reason why the app needs the admin privileges).
We have also found that the majority of scam miners in our dataset are obfuscated, probably, to hinder inspection and to make repackaging more difficult. Thus, it is necessary to perform runtime mining detection, not only in the cases, when the mining code is not shipped within the Android app and/or is heavily obfuscated, but also to identify scam miners that do not mine. To achieve dynamic detection, we have developed an approach described in the next section.
5.2 Dynamic Detection
One of the most effective approaches to detect miners is to observe their dynamic behavior. Indeed, in order to gain maximum profit for the developers, a miner should use all available resources . At the same time, in order to persist on the device, an illicit miner should conceal its mining activity, e.g., by applying throttling or doing this when the user does not use the phone.
In this section, we propose an approach and a prototype called BrenntDroid that leverage machine learning for detecting the Android miners using dynamic features. In order to build this prototype we selected a dataset consisting of 200 Android applications: 100 miners and 100 benign apps.
For the miners dataset, we selected 100 apks from our sample that start the mining process immediately after they have launched. This is a valid assumption because our tool is supposed to constantly monitor applications on a device and, thus, can detect the moment when an app starts mining. Moreover, dormant miners do not cause damage for the user.
As the benign dataset, we randomly selected 100 apps from the local Google Play store among the “Trending”, “Top Apps”, and “Top Grossing” application groups. These apps include various categories such as “Gaming”, “Education”, “Sports” and “Shopping”, and their number of downloads ranged from 100 to more than 500M.
For each of these apps, we collected a set of traces that contain different dynamic parameter values generated by the corresponding application. We used the Snapdragon Profiler  to collect these traces. This is a tool developed by Qualcomm Technologies to profile execution of an Android app by collecting CPU, GPU, DSP, memory, power, thermal, and network data in order to find and fix performance issues. We ran each application from our dataset on LG Nexus 5 powered by the Snapdragon 800 system-on-chip running the Lineage OS 14.1 operating system (based on Android 7.1), and collected data about the low-level system events. Each application was exercised for 300 seconds.
In a nutshell, each low-level system event is represented by 4 values: Process name, Timestamp, Metric name, and Metric Value. We consider as a metric timeseries
a sequence of the values with the corresponding timestamps that share the same application and profiled metric. For each application, we collected 15 different metrics: 1) Battery Current; 2) Battery Power; 3) CPU Branch Misses; 4) CPU Clock; 5) CPU Context Switches; 6) CPU Cycles; 7) CPU Cycles/Instruction; 8) CPU Instructions; 9) CPU Page Faults; 10) CPU Task Clock; 11) CPU Utilization Percent; 12) Memory Usage; 13) Rx Bytes (Total); 14) Tx Bytes (Total); and 15) Temperature. For each of the timeseries, we calculated 10 simple statistical values: 1) Minimum (Min); 2) Maximum (Max); 3) Average (Mean); 4) Median (Median); 5) Unbiased kurtosis (Kurt); 6) Unbiased skew (Skew); 7) Unbiased standard error of the mean (Sem); 8) Standard deviation (Std); 9) Mean absolute deviation (Mad); 10) Coefficient of variation (CV). Thus, for every application we obtained a feature vector consisting of 150 values.
This amount of features is large, considering the size of our dataset. Therefore, we applied two feature selection techniques to eliminate excessive variables. It should be mentioned that we used the filtering techniques that perform cleaning only based on the internal properties of the dataset, without considering its connection to our application classes. First, we removed the features that have low variance in our dataset (threshold=0.1) using the scikit-learn library. This operation removed 20 features from our dataset. Second, we eliminated highly correlated features (Pearson correlation coefficient is more than 0.9). After this procedure, only 67 features were left to be used further (see Figure 6 for the list).
To detect the strongest features in our dataset282828This information can be further used to collect only a subset of strong features on a device.27] on our dataset. Figure 6
lists the extracted features and shows their importance. The first two positions in this figure occupy the Maximum CPU Utilization % and Average Battery Power features. The corresponding Kernel Density Estimation (KDE) plots292929We omit the rest of the KDE plots due to the space limitations. are shown in Figures 6(a) and 6(b).
Several observations can be taken from these graphs. First, in Figure 6(a), a huge spike around 100% could be observed for miners. This confirms that miners try to utilize all CPU resources on the device. At the same time, we also see some spikes around 30% tick. This proves that some miners in our dataset throttled their mining capability, or used a subset of all available CPU cores.
Second, the Maximum CPU Utilization % KDE for benign applications is almost uniformly distributed along theaxis. That means that there is no specific pattern of CPU utilization by benign apps. I.e., different applications consume on average different amount of CPU resources. The more intensive tasks a processor executes, the more power it requires. During our experiment, the phone collecting the dataset was attached to the computer through a USB cable. As a side-effect, during the dataset collection the phone was also charging. It can be seen on Figure 6(b) that when a benign application is executed the phone was actually charging (the extremum value is on the positive side). At the same time, the miners were consuming so much energy that the battery was even draining, even though the phone was attached to a source of energy.
We evaluated our model using the 10-fold stratified cross validation applying the Random Forest classifier , using all our selected features. Figure 8 shows the Receiver Operating Characteristic (ROC) curve – the dependency between False Positive (FPR) and True Positive (TPR) Rates. The graph confirms that even with simple statistical dynamic features, it is possible to detect mining activity with high confidence. Indeed, in our experiment we managed to achieve 95% of accuracy with the Area Under Curve (AUC) score equal to 0.9880.009. Our prototype model proves that it is possible to build a very accurate detection tool working at runtime that is able to detect and block mining activities on a device.
We admit that collection of dynamic features is connected with large power consumption overheads. This means that implementation of BrenntDroid to run on a user device could be impractical. Moreover, the obtained machine learning model is valid in our testbed and may be not transferable to any device. However, the developed approach could be applied during application vetting process . In this case, app stores could inspect an application and use BrenntDroid as one of the tests. Indeed, in controlled environment an app could be tested on a particular device, which a priori has a trained model.
6 Threats to Validity
In this paper we have presented our findings from a large sample of Android cryptominers and proposed an approach to dynamically detect mining (or verify its absence). These results could be subject to several threats to validity.
The internal validity of the presented results depends upon our interpretation of the collected data and the analysis we performed. The main source of this threat in our case may be posed by the heuristics we employed to detect miners among the general population of apps that we have downloaded. To mitigate this threat, we manually checked every app from the resulting miner sample looking for the evidence of the mining code. We have also ran each app to collect more evidence that would support the fact that it is indeed mining.
The external validity of our results may be affected by how well they generalize to the entire population of Android cryptocurrency miners in the wild. We acknowledge that our current sample is skewed towards one big campaign, and that we have not processed all available Android applications (which is infeasible) looking for the mining code. It would be interesting to validate our findings working with a large security company that has already privately collected many mining samples in its networks.
We are aware that there exist three main approaches to hide the presence of mining code and hinder detection: CPU throttling, payload hiding and mining script obfuscation [16, 10]. We could have failed to identify certain cryptocurrency miners among the apps that we have been downloading from Koodous and VirusTotal due to complex obfuscation and evasion techniques employed by the authors of miners, bugs in the apktool, or the lack of a major popularity of miners present at these services. Yet, our main goal was not to capture every miner that is available in the wild, but to obtain and to study a significantly large sample of real-world Android cryptocurrency miners and to pave possible directions for detecting them.
7 Related Work
To the best of our knowledge, ours is the first work reporting on Android cryptomining applications. Previously, cryptojacking has been investigated in the context of traditional binary malware [26, 18], and there have been several papers focusing on browser-based cryptojacking [20, 24, 30, 11, 31, 29].
7.1 Cryptojacking in Other Contexts.
Browser-based cryptojacking. The ease of integration of Coinhive-like services into websites has led to the proliferation of drive-by cryptomining attacks. Eskandari et al.  have applied keyword-based search to the website code on the PublicWWW database, and have reported finding more than 30K occurrences of the Coinhive library and some occurrences of its alternatives, such as Crypto-Loot and JSECoin. Konoth et al.  have found 20 active crypto-mining campaigns and 28 crypto-mining services in Alexa’s Top 1 Million websites. They have used keyword-based search in web traffic logs, followed by manual analysis. Like in our approach, their keywords included mining services’ names and specific strings pertinent to these services (in the miner initialization code and in the Wasm/asm.js, i.e., web assembly, mining payload), Stratum protocol keywords, WebSocket communication. They have also used a high number of WebWorker threads in a web site as a feature pertinent to mining. Similarly, Musch et al.  report that 0.25% websites from Alexa Top 1 Million are serving crypto-mining code. They have applied CPU usage profiling and presence of web assembly code and several WebWorkers as indicators. Hong et al.  have proposed a run-time mining detection tool CMTracker that integrates hash computation-based and stack structure-based profilers.
Ruth et al.  have seeded their mining website dataset from the NoCoin list  and have proposed a fingerprinting technique for Wasm code. Rauchberger et al.  have proposed the MiningHunter technique to detect browser-based miners by analysing Web logs.
Saad, Khormali and Mohaisen  have used public services (Pixalate and Netlab 360) to acquire a list of websites with mining code embedded. Using these sites as ground truth, they have developed dynamic mining script profiles with respect to CPU usage, battery drain and network usage. Machine learning-based approach to browser-based miner detection has also been outlined in Carlin et al. , where opcode traces have been used as features, and in Draghicescu et al. , where the CPU allocation features and the threads and socket connections have been captured. Inlined reference monitoring for Web cryptojackers have been proposed by Wang et al. .
Binary-based cryptojacking. Malicious Bitcoin cryptominers have been investigated by Huang et al.  already in 2014. Division into campaigns and profits generated by the recent binary-based cryptominers have been analysed by Pastrana and Suarez-Tangil . The data collection approach used in  is similar to ours, as the authors crawled public services for malicious samples and then applied static and dynamic analysis heuristics to select only miners.
In contrast to the aforementioned works related to browser-based and binary-based cryptojacking, ours focuses on the mining applications in the Android ecosystem. Our results show that the Android platform is affected by both Web-based and binary cryptojackers. Yet, we collected and analyzed not only malicious cryptominers, as in , but also bona fide miners that some users might want to explore. We have also reported about the phenomenon of scam miners, that only pretend to be mining cryptocurrencies, while, at best, only serving ads to the users.
To the best of our knowledge, the SophosLabs report on mining Android apps  is the only paper analyzing Android mining malware and providing some samples. We have used this report to seed our miner dataset, as it only mentions a few samples hashes (not all samples were obtainable through our main app sources, VirusTotal and Koodous, and available application markets or the app database AndroZoo ).
7.1.1 Energy and CPU Consumption Evaluation.
Our dynamic detection approach relies on evaluation of many dynamically profiled features of Android applications, including CPU usage and battery drain caused by computation-intensive mining code. In contrast to [31, 4], our solution for dynamic miner detection is based on comparison of mining apps with benign but fully functional ones.
7.1.2 Android malware detection.
As our analysis of VirusTotal results and security industry reports show , mining functionality can be delivered as a part of malicious payload. There exist a large body of work that focuses on Android malware detection, e.g., [19, 2, 14, 42, 39, 41, 45, 36], to name just a few. Particularly, the cross-language Dual-Force technique  has a big potential for Web-based miner detection.
Cryptojacking poses a serious threat to mobile devices. At best, illicit cryptocurrency miners deplete the battery of mobile devices fast. However, they may cause more serious damage: from monetary loss to physical harm to the device’s owner due to overheating. In order to better comprehend this threat, we collected a dataset of 728 Android mining apps, and dissected them. To the best of our knowledge, this is the first work that looks into cryptojacking applications on Android. Our analysis confirms the public knowledge in this area is largely insufficient. For example, we found 173 illicit miners from 76 mining campaigns that have been not previously reported.
In addition, we performed the analysis of the miners from our sample with VirusTotal. Our findings are very interesting: 16 miners from our dataset are not detected by any antivirus engine, and a single miner has been detected by at most 39 out of the total of 74 scanners available at VirusTotal, meaning that there is no consistency among the scanner engines.
With the clean dataset available, we performed a dynamic analysis of the miners and compared the results with benign applications. We identified a set of dynamic metrics that contribute the most to the accurate classification results. Indeed, based on our dataset, we managed to achieve 95% of accuracy with the AUC score of whoping 0.9880.009, according to the 10-fold cross validation. Based on our findings, we proposed a tool called BrenntDroid that can be used to detect miners at runtime.
For the future work, we plan to extend our dataset with more illicit cryptocurrency miners that use heavy code obfuscation and to study them. We also plan to extend BrenntDroid with reliable techniques that account for various static and dynamic evasion methods such as network traffic obfuscation, CPU throttling, and evading user interaction (e.g., mining only when a user does not interact with a device, or at night).
-  Allix, K., Bissyandé, T. F., Klein, J., and Le Traon, Y. Androzoo: Collecting millions of android apps for the research community. In Mining Software Repositories (MSR), 2016 IEEE/ACM 13th Working Conference on (2016), IEEE, pp. 468–471.
-  Arp, D., Spreitzenbarth, M., Hubner, M., Gascon, H., and Rieck, K. Drebin: Effective and explainable detection of android malware in your pocket. In Proc. of NDSS (2014), pp. 23–26.
-  Canfora, G., Medvet, E., Mercaldo, F., and Visaggio, C. A. Acquiring and analyzing app metrics for effective mobile malware detection. In Proceedings of the 2016 ACM on International Workshop on Security And Privacy Analytics (2016), ACM, pp. 50–57.
-  Carlin, D., O’Kane, P., Sezer, S., and Burgess, J. Detecting cryptomining using dynamic analysis. In 2018 16th Annual Conference on Privacy, Security and Trust (PST) (2018), IEEE, pp. 1–6.
Caviglione, L., Gaggero, M., Lalande, J.-F., Mazurczyk, W., and
Seeing the unseen: revealing mobile malware hidden communications via energy consumption and artificial intelligence.IEEE Transactions on Information Forensics and Security 11, 4 (2016), 799–810.
-  Clay, J., Hargrave, A., and Sridhar, R. A power analysis of cryptocurrency mining: A mobile device perspective. In 2018 16th Annual Conference on Privacy, Security and Trust (PST) (2018), IEEE, pp. 1–5.
-  Coinhive. Discontinuation of coinhive, February 2019.
-  Cyber Threat Alliance. The illicit cryptocurrency mining threat, https://www.cyberthreatalliance.org/wp-content/uploads/2018/09/CTA-Illicit-CryptoMining-Whitepaper.pdf, 2018.
-  Draghicescu, D., Caranica, A., Vulpe, A., and Fratu, O. Crypto-mining application fingerprinting method. In 2018 International Conference on Communications (COMM) (2018), IEEE, pp. 543–546.
-  Eitzman, R., Goody, K., Wolcott, B., and Kennelly, J. How the rise of cryptocurrencies is shaping the cyber crime landscape: The growth of miners, https://www.fireeye.com/blog/threat-research/2018/07/cryptocurrencies-cyber-crime-growth-of-miners.html, 2018.
-  Eskandari, S., Leoutsarakos, A., Mursch, T., and Clark, J. A first look at browser-based cryptojacking. arXiv (2018).
-  Feldman, S., Stadther, D., and Wang, B. Manilyzer: automated android malware detection through manifest analysis. In Mobile Ad Hoc and Sensor Systems (MASS), 2014 IEEE 11th International Conference on (2014), IEEE, pp. 767–772.
-  Gao, X., Liu, D., Liu, D., and Wang, H. On energy security of smartphones. In Proceedings of the Sixth ACM Conference on Data and Application Security and Privacy (2016), ACM, pp. 148–150.
-  Grace, M., Zhou, Y., Zhang, Q., Zou, S., and Jiang, X. Riskranker: scalable and accurate zero-day android malware detection. In Proceedings of the 10th international conference on Mobile systems, applications, and services (2012), ACM, pp. 281–294.
-  Hoffmann, J., Neumann, S., and Holz, T. Mobile malware detection based on energy fingerprints—a dead end? In International Workshop on Recent Advances in Intrusion Detection (2013), Springer, pp. 348–368.
-  Hong, G., Yang, Z., Yang, S., Zhang, L., Nan, Y., Zhang, Z., Yang, M., Zhang, Y., Qian, Z., and Duan, H. How you get shot in the back: A systematical study about cryptojacking in the real world. In Proc. of CCS (2018).
-  hoshsadiq. Nocoin adblock list https://github.com/hoshsadiq/adblock-nocoin-list, 2019.
-  Huang, D. Y., Dharmdasani, H., Meiklejohn, S., Dave, V., Grier, C., McCoy, D., Savage, S., Weaver, N., Snoeren, A. C., and Levchenko, K. Botcoin: Monetizing stolen cycles. In NDSS (2014), Citeseer.
-  Jiang, X., and Zhou, Y. Dissecting android malware: Characterization and evolution. In Proc. of S&P (2012).
-  Konoth, R. K., Vineti, E., Moonsamy, V., Lindorfer, M., Kruegel, C., Bos, H., and Vigna, G. Minesweeper: An in-depth look into drive-by cryptocurrency mining and its defense. In Proc. of CCS (2018).
-  Luo, T., Hao, H., Du, W., Wang, Y., and Yin, H. Attacks on webview in the android system. In Proc. of ACSAC (2011).
-  Ma, W., Campbell, J., Tran, D., and Kleeman, D. Password entropy and password quality. In Proc. of NSS (2010).
-  Merlo, A., Migliardi, M., and Fontanelli, P. Measuring and estimating power consumption in android to support energy-based intrusion detection. Journal of Computer Security 23, 5 (2015), 611–637.
-  Musch, M., Wressnegger, C., Johns, M., and Rieck, K. Web-based cryptojacking in the wild. arXiv preprint arXiv:1808.09474 (2018).
-  Papadopoulos, P., Ilia, P., and Markatos, E. P. Truth in web mining: Measuring the profitability and cost of cryptominers as a web monetization model. arXiv preprint arXiv:1806.01994 (2018).
-  Pastrana, S., and Suarez-Tangil, G. A first look at the crypto-mining malware ecosystem: A decade of unrestricted wealth. arXiv preprint arXiv:1901.00846 (2019).
-  Pedregosa, F., Varoquaux, G., Gramfort, A., Michel, V., Thirion, B., Grisel, O., Blondel, M., Prettenhofer, P., Weiss, R., Dubourg, V., Vanderplas, J., Passos, A., Cournapeau, D., Brucher, M., Perrot, M., and Duchesnay, E. Scikit-learn: Machine learning in Python. Journal of Machine Learning Research 12 (2011), 2825–2830.
-  Qualcomm Technologies, Inc. Snapdragon profiler https://developer.qualcomm.com/software/snapdragon-profiler, 2019.
-  Rauchberger, J., Schrittwieser, S., Dam, T., Luh, R., Buhov, D., Pötzelsberger, G., and Kim, H. The other side of the coin: A framework for detecting and analyzing web-based cryptocurrency mining campaigns. In Proceedings of the 13th International Conference on Availability, Reliability and Security (2018), ACM, p. 18.
-  Rüth, J., Zimmermann, T., Wolsing, K., and Hohlfeld, O. Digging into browser-based crypto mining. In Proc. of IMC (2018).
-  Saad, M., Khormali, A., and Mohaisen, A. End-to-end analysis of in-browser cryptojacking. arXiv preprint arXiv:1809.02152 (2018).
-  Salem, A., Paulus, F. F., and Pretschner, A. Repackman: a tool for automatic repackaging of android apps. In Proceedings of the 1st International Workshop on Advances in Mobile App Analysis (2018), ACM, pp. 25–28.
-  smali/backsmali. https://github.com/JesusFreke/smali, 2018.
-  Sophos Labs. Coinminer and other malicious cryptominers targeting android, 2018.
-  Sufatrio, D. J. T., Chua, T.-W., and Thing, V. Securing android: a survey, taxonomy, and challenges. ACM Computing Surveys (CSUR) 47, 4 (2015), 58.
-  Tam, K., Feizollah, A., Anuar, N. B., Salleh, R., and Cavallaro, L. The evolution of android malware and android analysis techniques. ACM Computing Surveys (CSUR) 49, 4 (2017), 76.
-  Tung, L. Android security: Coin miners show up in apps and sites to wear out your cpu, October 2017.
-  Wang, W., Ferrell, B., Xu, X., Hamlen, K. W., and Hao, S. Seismic: Secure in-lined script monitors for interrupting cryptojacks. In European Symposium on Research in Computer Security (2018), Springer, pp. 122–142.
-  Wang, W., Wang, X., Feng, D., Liu, J., Han, Z., and Zhang, X. Exploring permission-induced risk in android applications for malicious application detection. IEEE Transactions on Information Forensics and Security 9, 11 (2014), 1869–1882.
-  Wiśniewski, R., and Tumbleson, C. Apktool - A tool for reverse engineering 3rd party, closed, binary Android apps.https://ibotpeaches.github.io/Apktool, 2017.
-  Xu, L., Zhang, D., Jayasena, N., and Cavazos, J. Hadm: Hybrid analysis for detection of malware. In Proc. of IntelliSys (2016).
-  Yang, W., Xiao, X., Andow, B., Li, S., Xie, T., and Enck, W. Appcontext: Differentiating malicious and benign mobile app behaviors using context. In Proceedings of the 37th International Conference on Software Engineering (2015), pp. 303–313.
-  Zhauniarovich, Y., and Gadyatskaya, O. Small changes, big changes: an updated view on the android permission system. In Proc. of RAID (2016), Springer, pp. 346–367.
-  Zhauniarovich, Y., Gadyatskaya, O., and Crispo, B. Demo: Enabling trusted stores for android. In Proc. of CCS (2013), pp. 1345–1348.
-  Zhu, Z., and Dumitras, T. Featuresmith: Automatically engineering features for malware detection by mining the security literature. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security (2016), ACM, pp. 767–778.