If you cite this paper, please use the EuroS&P reference: Zeya Umayya, Manan Aggarwal, Manan Chugh, Mann Nariya, Yogesh Kaushik, and Sambuddho Chakravarty. The Invisible Ink of the Android Malware World: A Longitudinal Study on the Usage of Covert Communication Channels. 2026 IEEE 11th European Symposium on Security and Privacy (EuroS&P). IEEE, 2026.
The Invisible Ink of the Android Malware World: A Longitudinal Study on the Usage of Covert Communication Channels
Zeya Umayya, Manan Aggarwal, Manan Chugh, Mann Nariya, Yogesh Kaushik, Sambuddho Chakravarty
arXiv:2606.13107v1 [cs.CR] 11 Jun 2026
IIIT Delhi, India Email: {zeyau, manan22273, manan21335, mann22278, yogesh20163, sambuddho}@iiitd.ac.in
Abstract—Proxies, VPNs and Tor have long helped the privacy community and users in censored regions to fight censorship. However, the same tools can be maliciously exploited by malware and botnets to conceal their communication to external command and control servers. Despite being a critical concern fueled by the proliferation of malware based attacks, no longitudinal studies have analyzed how malware applications use covert channels (CC) to evade detection. We fill this gap by performing the first study of the usage of covert channels in the Android malware ecosystem. To that end, we develop a complex multistage pipeline that combines static and dynamic analysis to investigate both system and network-level features. We applied this pipeline on a corpus of 3.5M Android malware spanning 2009 to July 2025 (one of the largest sample for such a study). Our carefully crafted static validation rules uncovered 288K APKs that used CCs spanning 511 malware families and CC usage growing exponentially from 0.30% (2012) to 50% (2025). The dynamic execution of a subset of these applications on physical mobile phones not only confirmed the results of static analysis based results but also enabled a deeper analysis. Overall, we identified 19,308 unique IP addresses being contacted in 85 countries, out of which we were able to explicitly validate the presence of CCs for 59 IP addresses across 17 countries. Further, we performed a longitudinal dataset study spanning over 16 years for CC based malware and found that CC usage has evolved, e.g., some malware adopted by using more than one CCs (one family used more than 5 CCs); others switched between them periodically (one family switched CC usage 40 times from 2019 to 2025). Lastly, we tested two state-of-the-art malware detection solutions on CC-based malware identified in our work. We found that they fail miserably, yielding high false rates (> 50%), underscoring the need to consider the effect of CCs on malware detectors. Overall, we believe that our work advances the community’s understanding of CC based malware and lays the groundwork for future studies to consider CC usage when developing malware detectors. Index Terms—Anonymization tools, Android Malware.
1. Introduction Often malware use tools like Tor [1], its bridges [2], I2P [3] VPNs [4] and proxies to hide communication with Command & Control (C2) servers or peer bots. Multiple articles indicate that alongside desktop malware [5], [6], [7], [8], [9], Android malware increasingly employ such
mechanisms [10], [11], [12], [13], [14]. We collectively refer to such tools as covert channels (CC). While there exists work on studying CCs (VPNs/Tor/PTs/Proxies/I2P), there is a clear research gap on investigating and characterizing Android malware that uses CCs. Further, it is unclear if current state-ofthe-art malicious traffic detection methods1 effectively identify such APK traffic. Our preliminary evaluation in Section 5.3 suggests these methods often fail to detect malware APKs that employ CC tools/packages. Thus, there is an urgent need for a dedicated study to find and investigate such malware and their evolution. Challenges and missing ground truth: Identifying APKs that use CCs across millions of malware samples is challenging on multiple fronts, as evidence of their usages are currently fragmented across disparate blogs, reports by security researchers and industry analysts. Firstly, the hashes cited in existing blog posts seldom point to the actual APKs employing CCs [10], [15]. Instead, they usually correspond to payload or ELF executables embedded within malware. Thus to the best of our knowledge, no curated datasets are publicly available to academics, or prominent security symposia like Defcon/Blackhat [16], [17]. Secondly, while VirusTotal (VT) [18] has long served as a reliable and de-facto source for obtaining generic malware related information and heavily cited in prior works e.g., [19], [20], [21], [22], [23], [24], it does not explicitly identify the use of such communication tools. Existing work over third party libraries [25], [26], [27], mostly look for a collection of general libraries found in malware APKs and does not pin-point towards CC usage. Thus we do not have ground-truth of such malware APKs to begin with. Further, dynamically executing every malware APK available today to observe CC creation is infeasible at scale. Moreover, there is a lack of methods to check CC creation at runtime. Thus such complexities are an imperative to explore novel methods involving static analysis, which can scale rapidly and cover millions of malware. Thus to address such issues, we develop a framework that first identifies Android malware that use CCs, and then analyzes them using static code inspection and selective dynamic execution. Our contributions are presented under three components: static analysis, dynamic analysis, and the characterization of the collected data. Static analysis: The purpose of performing static analysis 1. These solutions are positioned mostly at edge router observing organizational traffic at a large scale.
is to obtain indicators of CC usage in the form of specific rules, which we term static validation rules (SVR). Due to the absence of ground truth, we adopted an exploratory approach to identify and characterize such malware. To collect a seed list of APKs, we look for potential keywords related to each CC in malware VT reports. Since it is not known how malware creators may have incorporated those CCs, we search for CC usage indicators in seed malware APKs, following how they are usually integrated in their benign counterparts. Since each CC demands a very different type of requirement and setup to work, their indicators of CC usage require dedicated efforts respectively. After each CC has been studied, collected information is converted into SVRs and then it is applied on millions of malware in an automated manner. As a first contribution, we explain how we design SVRs for each CC. To refine our approach, we analyzed how CC tools are integrated into third-party APKs by manually reviewing relevant documentation on the former’s websites. For Tor/TorPT/I2P, we identified Android packages (libraries) used for integration, making their presence a strong indicator of Tor/I2P usage. Other relevant rules include the presence of Tor/I2P binary identified upon static inspection of malware APKs. For VPNs, we identified Google Playstore’s VPN APKs and decompiled them to determine package used. Unlike most VPNs, proxy APKs in app stores usually have other functionalities as well (e.g. doubling up as VPNs). Thus, we first aggregated all possible provider names from prior research works [28], [29], [30], [31], and inspected their APKs to identify packages2 specifically used for proxy functionality (Section 3.2). Additionally, we verified runtime usage of proxy/VPN package methods by instrumenting and dynamically executing 50 APKs (see Section A.13 for details). Since APKs are often obfuscated [32], [33], SVRs may not always apply. Additionally, if malware creators have modified the original CC packages, then our SVRs may fail. To ensure we didn’t ignore such cases, we try to find similarity of already identified CC APKs at two levels—firstly matching CC library using LibScan [25] to determine if a given APK has a particular library packaged in it (even for obfuscated APK). And secondly, matching two APKs entire code using MatchScope [34] where the first is a validated malware APK and the second is a non-validated one (for results see Sections 5.1.1 and 5.1.2). Although LibScan and MatchScope are state-of-the-art tools, they are still far from handling all types of obfuscations (as described ahead in Section 5.4). Dynamic analysis: Thus, at the end of the static validation process, we have a set of potentially covert malware that use Tor/PTs/I2P/VPNs/proxies as CC. As a second contribution, we develop dynamic validation rules to validate potentially covert malware. Dynamic analysis involves executing malware APKs either on an emulator or on a real device. It is widely known that the dynamic analysis of malware often falls short of full success [35], [36]. For example, malware attempts to bypass the underlying test environment, either slowing down its functionality or completely masking its true nature due to the absence of a live C2 or its peers. To overcome these challenges, we set 2. Packages have downloads in millions , see sections A.9 and A.10.
up physical devices to run malware and provide a 5-minute window for malware to create CC and exhibit its true behavior, while also not extending the period beyond this, in accordance with ethical practices (see Section A.1). To develop dynamic validation rules, we examined evidence at both network and system levels. Network traces helped identify Tor relays and detect VPN traffic using regex-based [37] and nDPI [38] analyses across multiple protocols (e.g., OpenVPN, WireGuard). Systemlevel inspection of logs and process traces revealed that each CC generated unique, identifiable patterns, forming the basis of our dynamic validation approach. Discovery and characterization of covert malware: After both static and dynamic validation processes, we perform PCM characterization based on their presence across years, their evolution, and their static and dynamic behavior, as our third contribution. While considering 3.6M malware APKs (with VT-score > 0) from AndroZoo [39], between 2009 and 2025 (16 years data), we applied both SVRs on APKs and keyword searches on VT reports. Overall, for 3.6M malware, keyword searches over their VT reports flagged 102k APKs, where 81k were false positives, while our static validation rules over these APKs alone discovered 288k APKs. Thus, our static validation pipeline flagged approximately 288k APKs using some CC: 150 (Tor), 3.5k (TorPT), 2.4k (I2P), 17k (VPN), and 271k (proxies). It contains 511 distinct families overall, with 12, 39, 23, 127, and 477 families that use Tor, TorPT, I2P, VPN, and Proxy, respectively. Additionally, 215k singleton samples were also identified. It has 124k unique APKs based on their package names. Proxy has more unique APKs (119k) than Tor, which has the least number of unique APKs (80). To further trace back the developers of these malware and find other such malicious APKs from the same developers, we statically inspected their certificates. Interestingly, it revealed widespread use of common certificate keys and fake organization names across thousands of APKs (see Section 4.3.2). We also analyzed the evolution of malware APKs and their families to understand how they transitioned between different covert channels over time. Our dataset, spanning 2009–2025, offers a broad temporal scope to capture and study these shifts in communication strategies. We found numerous instances where the same malware APKs transitioned from using one CC to multiple. There were such malware that continuously changed their CCs. It may be to hide and change the signature of their APK to avoid anti-virus engines that detect APKs using their hash values (Section 4.4). Dynamic Results: For dynamic level validation and characterization, we executed randomly sampled 13.7k malware (out of the 288k) APKs across all categories on Google Pixel-5 phones3 . We didn’t provide any user input apart from allowing permission to create VPN tunnels (since the purpose is to observe covert behavior). Highly sophisticated malware often bypasses dynamic execution to conceal its true behavior [35], [36]. Despite the inherent limitations of dynamic analysis, we conducted this experiment as a pragmatic necessity to accurately study malware behavior. Overall, it resulted in 6.4k successful runs, out of the 13.7k APKs. Figure 20 shows that APKs from 3. Refer to Section A.1 for ethics consideration.
2019 onwards had more than 40% of execution success rate. Though 13.7k APKs appear less, they span various periods and are executed on real devices, unlike studies using emulators (Mercaldo et al. [40]). Upon analyzing the dynamic execution data, we observed that malware try connecting to Tor, VPN and proxy servers spread across the globe in countries like China, USA, Germany, France etc. (Section 4.6). We also observed that some malware use the same IP endpoints for connecting to their CCs. Such trends may shift with longer analysis. Overall, we make the following contributions: • We conduct the first systematic investigation of Android malware leveraging covert channels (CCs) such as Tor, Tor pluggable transports, I2P, VPNs, and proxies, highlighting gaps in existing detection approaches. • We design and implement a novel static analysis framework based on carefully curated SVRs to identify indicators of CC usage in APKs, enabling scalable analysis across millions of samples despite the absence of ground truth. • We develop dynamic validation rules based on networkand system-level artifacts, and validate malware behavior through large-scale execution on physical devices, capturing realistic CC usage patterns. • Large-scale dataset and characterization: Applying our pipeline to 3.6M APKs, we identify ≈288K malware samples across 511 families using covert channels, and perform in-depth characterization of their distribution, evolution, and behavior over 14 years. We have released the resulting dataset, comprising malware hashes and accompanying analysis code, through a publicly available GitHub repository [41] to facilitate further dynamic and static analyses. Overall, we believe that our work advances the community’s understanding of sophisticated malware enabling studies over Android malware evolution, shedding light on how adversaries continuously adapt and refine their malicious designs.
2. Background 2.1. Covert Channels (CC) There are many ways of communication over the internet without revealing one’s digital identity (particularly IP address) such as Tor, VPNs, proxies, pluggable transports and I2P. We provide a brief of each CC. Tor: It was proposed in 2004 as an anonymous routing tool [1]. Its network comprises relays, running as proxies, usually known as onion routers. A Tor client communicates with a server (i.e., destination) by relaying traffic via a cascade of relays, called guard, middle and exit, collectively referred to as a circuit. Tor is widely used as a censorship circumvention tool. The client to relay traffic reveals no information about the actual destination of the messages. Pluggable Transports (TorPT): Tor relay IPs are publicly advertised through directory services [42]. Often relay IPs are blocked by censors. To bypass the censor, TorPT relay Tor traffic through alternate methods such as tunneling (Dnstt, WebTunnel etc.), proxying (Snowflake, Meek etc.), mimicking other protocols (Cloak, Marionette etc.) and wrapping data in new encrypted protocols (Obfs4 etc.)
[2], [43]. This way a censor cannot spot Tor relay IPs in flows and thus may not attempt to block them. These are sometimes known as bridges. We will refer to these as TorPT throughout the paper. VPN: Virtual Private Networks (VPN) [44] were created to virtually connect to the private address spaces. VPNs tunnel the traffic of such address in a manner that an observer only sees the public IPs of the tunnel end-points, and not those of the private networks. A VPN client usually establishes such tunnels with VPN servers/gateways, using popular protocols like OpenVPN [45], Wireguard [46] etc. Due to their similarity with proxies, they are also used to evade censorship by hiding the actual destination IP from an eavesdropping adversary. Free Proxies: Free proxies have always attracted more users, because they are free and often faster than VPNs [47]. These are most commonly used for bypassing censorship and geo-blocking. They commonly support HTTP and SOCKS protocol. HTTP proxy is used for accessing web content and SOCKS by default supports multiple applications over it [29]. I2P: I2P [3], akin to Tor hidden service, ensures twoway anonymity i.e., initiator and responder, using garlic routing [48] to exchange messages between nodes. It establishes inbound and outbound tunnels between I2P nodes, re-established every 10 minutes. Its first mobile application was released for Android in 2011 [49]. 2.1.1. Exploitation by malware. All the above CCs are also used by malware to hide the network communication to end-points such as C2 servers or peer bots. As per the reports by multiple security researchers [5], [6], [7], [8], [9] malware have started using Tor, domain fronting (also used by meek and snowflake [50], [51]) for stealthy C2 communications. Specific to Android: As per multiple reports [10], [15], [11], [52], [53], [14], Android malware also use such CCs for hiding their traffic. Some famous malware families such as Hydra, Gafgtyt etc. have been found using Tor to hide their C2 communications. It is a complex process to integrate covert communication tools into an APK, other than the original one (i.e., the covert application’s) its developers envisaged. There are many ways to integrate CC functionalities into an APK. These include using libraries (or packages), or by directly loading compatible binaries of available covert communication applications like I2P, Tor and TorPTs. The complications arise due to how malware creators implement the functionality of covert communication into APKs. Intuitively simpler integration options may lead to more malware APKs using them. Generally, malware creators leverage the development efforts by the providers of such CCs, which were originally meant for benign APKs.
2.2. APK Analysis Challenges No standard methods exist to integrate covert communication functionality into APKs, making it hard to detect such channels in their source code. One approach is to run APKs on phones and monitor for CC creation, but dynamically analyzing millions of malware is infeasible and time-consuming with execution challenges. Instead,
we used faster static analysis to reduce the search space of approximately 4M APKs.
TABLE 1: Yearwise count of APKs. Total available APKs: 24.5M ; Total number of APKs with VT-Score > 0: 3.6M Year
2.2.1. Static analysis challenges. Although static analysis is more efficient compared to dynamic, but it has its own challenges. E.g., while searching for the presence of CC code, it is not known prior whether the APK is obfuscated or not. Apart from APKiD tool [54], there is none other that can detect APK obfuscation. But this also has its limitations, making it unsuitable for majority of the APKs. Thus, for multiple APKs, static analysis does not result in successful identification of the CC, and such APKs are skipped from further analysis even though they might be using such mechanisms. As a solution to detect obfuscated libraries or code, we use state-of-the-art tools such as LibScan [25] (to match library) or MatchScope [34] (to match entire code). However, these tools can handle only a few types of obfuscation. Thus, our final dataset will represent a lower bound of the number of CC APKs that might be present in the wild. 2.2.2. Dynamic analysis challenges. Our work also requires dynamic analysis of APKs for validating if they are indeed using CCs, and also to observe their runtime behavior. There are different challenges with each type of CC. E.g., some of the VPN-based APKs require user input before establishment of the VPN tunnels. Thus, we need to automatically detect such pop-ups and grant the necessary permissions. Other high profile malware corrupt the operating system itself, and thus leave the device stuck in an unknown state that prevents dynamic analysis. In such extreme cases, manual intervention is required to reset the device by debugging the issues at hand. Although we run malware APKs on mobile phones to observe CC creation, the former may not always create them immediately upon execution. As a result, detecting CC connection attempts within the limited duration of dynamic analysis might not always be possible.
3. Proposed Approach Overview: We provide an overview of the complete pipeline in Figure 1 to discover malware that use CCs 1 involves inspection of APKs for communication. Step ⃝ filtered using specific channels’ keywords on VT reports, so as to determine what heuristics/rules that are required 2 applies these rules on to identify such channels. Step ⃝ all APKs from 2009 to 2025 (Section 3.1). It involves statically analyzing APKs and then applying the rules to them, to spot the use of CCs. These APKs are then 3 takes a set of the collected into a new dataset. Step ⃝ APKs from this dataset and performs dynamic analysis by running them on real phones. The purpose is to first dynamically validate if CCs are actually established, and secondly to study the runtime behavior of such malware APKs. Additionally, it also involves static analysis of the entire dataset for determining the behavior of these malware especially with respect to how and when they use the CC. The outcomes of third step are combined and 4 . This final step performs different types fed to step-⃝ of measurement analysis (detailed in later sections) and presents insightful statistics and behavioral results. We
2009 2011 2013 2015 2017 2019 2021 2023 2025
All Available 1 4169 618951 508419 561345 2034351 3538073 2603080 132274
VT-Score >0 0 32 219123 131981 123704 432544 342327 88738 2454
Year 2010 2012 2014 2016 2018 2020 2022 2024 Total
All Available 15 60125 1614685 2308774 2146286 3014674 4862188 636821 24511957
VT-Score >0 0 9970 541250 606736 350343 269584 386492 25399 3652832
first provide details about the malware we considered for our study and then move through each step in detail.
3.1. Android Malware Collection Table 1 presents the statistics of our dataset, which includes malware APKs from the years 2009 to 20254 (Android OS was released in 2008). We consider the maximum possible time duration to study the evolution of such malware over the years. For APK downloads, we used AndroZoo repository [39] containing millions of APKs. For each APK hash having VirusTotal (VT) score of atleast one (as provided by the meta-data file in AndroZoo), we also download its VT report using VirusTotal API. For this we subscribed to VT Academic API [18] which provides more API requests per day than in general. VT reports, updated dynamically [55], may differ from AndroZoo’s snapshot-based reports. Thus, we used the latest VT reports as ground truth.
3.2. Formation of Static Validation Rules For this work, we considered popular CCs such as Tor, VPNs, proxies, I2P, and TorPT being used for hiding the communication with command and control servers mostly. 1 in detail. Next, we next will explain step ⃝ 3.2.1. Filtering hashes using keywords. The purpose of forming keywords is to search them in VT reports. All VT reports with such keywords may or may not be actually related to the respective CC. Formation of relevant keywords for each CC requires a thorough understanding of each channel and its usage styles in multiple platforms such as Linux or Android. For each CC, we formed some keywords generally referring these. We provide those keywords in Table 4 (in Section A.3). 1 , we initially generated VT reports for As per ⃝ malware hashes and then applied keyword filtering over it. Further, we manually analyzed each report for false positives while searching for valid reports. After extensive efforts, we came across some APKs actually using Tor, VPN, proxy, TorPT or I2P. Upon statically analyzing them, we found some examples of such CCs being used in APKs. Overall, VT keyword filtering mostly generated false positives (details in Section 4.1). Thus, we conducted deeper static analyses of the APKs to find indicator of usages related to CCs. 4. Data collected till July month for 2025.
1 : Formation of static validation rules that can be applied on APKs using static Figure 1: Complete Work Pipeline. ⃝ 2 : Application of channel’s (Tor/VPN/Proxy/TorPT/I2P) rules over APKs from 2009-2025. ⃝ 3: analysis over them. ⃝ 4 : Results analysis and presentation of the measurement results. Static and dynamic analysis on the dataset. ⃝ 3.2.2. APK inspection to create rules. While searching for keywords in VT reports, we observed that most of the matches led to false positive samples. Thus we concluded that searching keywords in VT reports is not effective in discovering such APKs. Thus, we looked for additional ways by which APKs could be using CC through the latter’s official webpages. For Tor and TorPT, we found multiple possible ways to integrate them to an APK. These are listed as follows: 1) Presence of Tor binary at res/raw/tor or assets/tor 2) Presence of libTor.so, tor.so or torrc configuration files 3) Presence of packages such as a) com.netzarchitekta.IPtProxy, b) info.guardianproject.onionkit, c) info.guardianproject.netcipher, d) org.torproject.jni.TorService, and e) org.torproject.iptproxy.IPtProxy These packages should never be the same as the main package of the APK, because that only happens for APKs of these CCs themselves. Such condition makes sure that we are not flagging the original CC channel APKs themselves. For VPN, while analyzing filtered APKs, we found different packages in each APK, and a specific Android permission (BIND_VPN_SERVICE5 ) required to establish tunnels. Unlike Tor, there are many VPN service providers. Thus, it is not trivial to fetch the list of all packages providing the functionalities of a VPN service. Since we were unsure about whether the packages that we found in VT reports were related specifically to VPNs, we took a different path and hypothesized that malware creators maybe re-using existing VPN APKs’ packages available through official stores. For this, we scrapped through Playstore, F-droid, and Github, first to fetch all VPN APKs through keyword search and discovered that their packages carry out the tasks of VPN management. 5. Introduced in 2011 for Android v4 and above.
We found 49 such APKs and thus 49 unique packages. We provide their details in Section A.9, showing millions of downloads per APK. We used these as a seed list. For a final confirmation regarding permission, we also thoroughly inspected a benign APK about how a VPN connection is made and what permissions are required for it to function properly. We finalized that along with a VPN package the APK under test must also mention BIND_VPN_SERVICE in its manifest file. The permission or the package alone are not sufficient since many malware creators add unnecessary permissions to confuse malware detectors trained on such features [56]. Similar to VPNs, for proxy, VT reports were not very helpful either. Thus we took a different route. We looked for prior research on free proxies in Android OS [30], [28], [29], [31]. We observed that proxy APKs are also usually distributed through their providers. On Playstore, we did not find many APKs with only proxy functionality. For a clean SVR of proxy usage, we first required to have APKs providing only proxy as a service, and nothing else. As a result, we decided to find such APKs on proxy providers’ websites. Thus we unified all 58 proxy providers names from multiple sources [30], [57], [31], [29]. We collected 10 APKs that were mentioned on the websites of these developers. The purpose was to find out how the proxies are implemented in a benign APK. After decompilation and inspection of the APK code we found that these APKs themselves use third-party packages. For completeness, we also considered all previous versions of these APKs which amounted to be 165 in total. Specifically, each APK was decompiled and analyzed to extract its package structure, to identify newly introduced or third-party packages. We then examined the usage of these packages within the application codebase to determine whether they were actively invoked and whether their functionality aligned with proxy CC behavior. Through this process, we identified a total of 15 distinct third-party packages that implement
proxy or CC-related functionality (listed in Section A.10). These packages were observed across an initial set of 10 APKs, with additional libraries emerging through versionwise analysis. For I2P, we inspected benign and VT-filtered APKs to craft static validation rules, and four integration methods: 1) Presence of I2P .so files such as libjbigi.so, li bi2p.so, libi2pd.so, and libinvizible.so in lib folder. 2) Configuration/help files such as i2ptunnel_conf ig, help_i2ptunnel.html, and i2pd.config files in res/raw folder, i2pcrt.crt in assets folder. 3) Presence of packages like: a) net.i2p.android.lib.helper, b) net.i2p.android.router.service, c) net.i2p.crypto.eddsa.math, d) net.i2p.data.i2cp 4) Presence of strings e.g., logger.record.net.i2 p,i2np.ntcp.enable,i2np.udp.enable,r outer.inboundPool,router.outboundPoo l in configuration files. 3.2.3. Special case: Obfuscated and modified library code. Obfuscated libraries: In Android, benign/malware creators obfuscate the APKs to generally hide their source code and impede correct decompilation [35]. Thus applying above static validation rules on such obfuscated APKs may not work. Thus for obfuscated APKs we devised another strategy. Similar to how we looked for the presence of specific libraries for each CC, we tried to find the libraries in obfuscated APKs. Instead of searching for the exact library name, we searched for the contents of the libraries present in a malware APK. For this we used Wu et al.’s LibScan tool [25]. To get the source code of all possible versions of a covert library, we first applied the static validation rules on each APK and obtained the first set of CC APKs. Then, we extracted libraries used in them6 and search them in other non-flagged APKs to find their presence in case the malware creators tried to hide them using obfuscation. LibScan works for six obfuscation types and thus we are also limited by this7 . Modified code: Malware creators modify the known libraries as per their needs, and also to bypass static analysis. Even after such modifications, the semantic meaning of the code should not change. To find known modified libraries code, we employ MatchScope [34] on nonvalidated APKs. This is done in two steps – (1) applying it to known libraries’ codes to group them into semantically similar codebases. This clusters the validated APKs into fewer groups, reducing the searches required to find the correct match between these groups and the non-validated APKs. Next, in (2) the non-validated APKs are matched against these groups, thereby helping spot the presence of CC usage in their modified codes. 2 , we applied all SVRs over malware APKs Thus, in ⃝ from 2009 to 2025. At the end of static validation, we 6. We implemented the library extraction code ourselves as it was not present in LibScan’s codebase. 7. Types: identifier renaming, code addition, dead code removal, package flattening/repackaging, string encryption, control-flow randomization, manifest transformation, and data alignment.
Figure 2: Logcat output in each covert APK.
Figure 3: Ps output in each covert APK. obtained the dataset of APKs having CC present in them. 3 for a After this step, the dataset was passed to step ⃝ detailed APK analysis along with dynamic validation.
3.3. Formation of Dynamic Validation Dynamic setup: Static validation rules help discover APKs that use CCs for network communication. To find out if indeed these malware establish CCs, we first execute these on real Android devices for five minutes and observe 3 in Figtheir network behavior by capturing the traffic (⃝ ure 1). Standard practice for dynamic analysis is 1-2 min. (Kuchler et al. [58] and Umayya et al. [59]). However, we extended it to 5 min. to provide enough time for the malware to create tor-circuits/vpn/proxy connections, which may take 2 min. We also store relevant system-level information about the events that occur while the malware runs (using netstat, ps, lsof and logcat). The purpose of capturing dynamic data is first to verify the establishment of CC and then further study their runtime behavior. Unlike static, dynamic analysis may not always produce concrete results. Not all malware APKs will try to establish CC connection immediately after installing and executing. It maybe the case that they require CCs at particular events, and not always. Next, we explain how we form the dynamic validation steps for each CC. 3.3.1. Tor validation. To connect to the Tor network, APK executes the Tor client program and downloads the necessary data by contacting the Tor network directory authorities. Once it bootstraps to 100%, it creates circuits where the first communication end-point is a guard node in the Tor network. Network-level validation: Information about the running Tor relays is publicly announced by the Tor directory servers [60]. These documents contain metadata about all currently reachable relays, including their IP addresses, ports, and roles (e.g., Guard, Exit). A client can fetch this information from these servers using the stem library [61]. Thus, every IP present in the pcap collected above can be checked against the list of guard nodes’ IPs in Tor network’s relays’ information. Given the dynamic
churn of Tor relays, we ensure that the consensus, data used to match relay IPs and ports, closely correlated to the time window during which the PCAP traces were collected. This reduces inaccuracies arising from such relay churn. System-level validation: We can validate Tor execution through logcat logs as shown in Figure 2. This can also be found by running ps command and looking for the libTor.so entry. Additionally, we fetch the data section of an APK under test, from the device. We check this to see if there are files there that are populated/updated, and that may be necessary for Tor circuit creation. Once the APK is installed, it creates a directory named app_torfiles with 7 files in it viz. – geoip, geoip6, lock, pid, state, tor, torrc. Their presence is a strong indicator that the installed APK is likely going to connect to Tor. We use this observation as a rule for dynamic validation. 3.3.2. VPN validation. To connect to a VPN server, an APK utilizes the VPN API provided by Android OS and requires BIND_VPN_SERVICE permission. Other methods include adding native libraries and third-party SDKs. Network-level validation: By capturing the network traffic, we can verify if an end-point IP:Port pair belongs to a VPN. To do this we relied on methods suggested by Maghsoudlou et al. [37]. In their approach, the authors send crafted probe packets, corresponding to different VPN services (OpenVPN, WireGuard, PPTP, and SSTP), to IP:port pairs they may wish to check. A legitimate response, determined by observing specific patterns in the probe responses, indicate that the end-point runs a VPN service. In our approach, we also inspected the response packets, corresponding to an APK’s communication, for similar patterns. We enlist these patterns in Section A.7. Apart from above method, we also used another tool nDPI (v4.12) [38] to find out the protocol used. It can detect 15 different types of VPN protocols (IPsec, GRE, PPTP, OpenVPN, CiscoVPN, WireGuard, FortiClient, Softether, CloudflareWarp, ProtonVPN, NordVPN, SurfShark, CactusVPN, TunnelBear, and OperaVPN). System-level validation: The logcat and ps commands log the creation of VPN connection establishment and trials. Figures 2 and 3 shows the statements that usually appear in logs. While looking for new files created in the data folder, we observed one JSON file with a random string in its name8 . 3.3.3. Proxy validation. There are many ways in which an APK can connect to either a SOCKS/HTTP proxy server. These include OkHttp Android client utility, creating sockets using the Android class, proxy, using VPN API of Android, or using third-party proxy libraries. Thus, for each proxy connection method, there would be a “footprint” in dynamic analysis data. Network-level validation: We again used passive method and searched for the type of protocol of the APKs communication, using nDPI tool. It supports four proxy protocols named as HTTP Connect, HTTP Proxy, Socks, and HAProxy. 8. We found it in many APKs with fields similar to a VPN auth-token.
System-level validation: The proxy creation and connection establishment messages generally gets logged in logcat. We present the type of logs that are generated in Figures 2 and 3. In both figures, the last line shows the system log. 3.3.4. Tor-Bridge/TorPT validation. APKs connect to Tor bridges using the Tor client program developed by the Guardian Project [62]. There have been several developments in the recent past for easier integration of TorPT, into an APK. Network-level validation: At network level, it is almost impossible to detect if the (IP, port) to which the APK is connecting to is running a Tor bridge/PT. System-level validation: At system level, we can observe if the service related to a specific TorPT has started, or specific bridge libraries have been loaded. E.g., in Figures 2 and 3, we show that obfs4’s and snowflake PT’s information are visible through logcat and ps commands output. 3 , along with dynamic validation, we also perform In ⃝ static analysis of APKs present in the dataset obtained 2 . Next, we provide details about step ⃝ 4 that from step ⃝ processes the the output data from both static and dynamic analysis. 3.3.5. I2P validation. Every node (sender/receiver) becomes a part of the I2P network by default. Once its application starts, it acts as a router to create tunnels and send encrypted messages to peers. The router process downloads a copy of the netdb (information of other nearby routers in the network) and starts building inbound/outbound tunnels. Network-level validation: Similar to TorPT, it is not possible to detect I2P traffic using ports or addresses since it uses random high-value ports. In the absence of central databases of peers, or reseed servers9 , manual peer discovery [63]10 , a non-trivial task, is the only resort. System-level validation: Once the I2P router starts and reseeding begins, we may observe that one (or more) RouterInfo files (router-<randomstring>.dat) are downloaded. These files have peers’ IP-port pairs, some of which the router connects to, identifiable from network traffic. Another log file, generally named Eventlog.txt, can be inspected for reseed attempts.
3.4. Characteristics of Flagged APKs 2 in After applying SVR to 3.6M malware APKs (⃝ Figure 1), we obtain final dataset of malware APKs that integrate CC. To the best of our knowledge, this is the first such dataset. We considered APKs between 2009 and 2025, i.e., from the inception of Android OS until present. We perform deeper code analysis on the obtained APKs to understand their behavioral characteristics. Along with deeper code level static analysis data, we also combine dynamic data, to further understand the dynamic behavior of a portion of APKs. Thus we use both static as well as dynamic data to find the properties of the flagged APKs (for results, see Sections 4.3 and 4.6). 9. A process that periodically gathers info from routers. 10. The I2P’s official website [64] uses such measures to determine peers, but for ethical reasons anonymizes their IPs.
Figure 4: Yearwise cumulative count of statically validated malware APKs.
Figure 5: Distribution of APKs across individual CCs and co-occurrence of multiple CCs. Overall, one could monitor the trends of such APKs, over the years and prominent families using such CCs. We performed deep code analysis of a few APKs from each category (i.e., Tor, TorPT, I2P, VPN, and proxy) in an attempt to understand the usage of CCs by malware creators. We also observed the evolution in the usage of CCs by looking at the presence of their relevant code simultaneously in a single APK. Using dynamic analysis data, we observed network level characteristics of these malware such as where they are connecting or what ports they are using etc..
4. Measurement Results We present the results of our measurement study in this section, starting with the inaccuracies observed in keyword filtering, the dataset obtained after applying SVRs, and their detailed static and dynamic analysis.
4.1. Static Validation over Keyword Filtering As per our pipeline in Figure 1, we performed keyword search e.g., ‘tor’, ‘vpn’ on VirusTotal (VT) reports to come up with static validation rules for APKs already analyzed by VT. However, as already mentioned in Section 3.2.2, our goal was not to only rely on VT reports. Instead, extract the source code for malware APKs (to develop SVRs), especially for the ones, not analyzed by VT (e.g., upcoming APKs). Additionally, one would require VT subscription to obtain reports for thousands of malware APK hashes. While explaining the rule formation process in Section 3.2.2, we pointed out that VT reports are not accurate in spotting APKs that use CC. Thus for finding out such APKs we had to perform static validation on all
the malware APKs that were present in any year (with VTscore > 0). It significantly increased the time to discover such APKs (45 days for the complete static validation). After running keyword filtering (KF) and static validation (SV) of APKs, we compare their statistics (in terms of accuracy). We collected and analyzed 3.6M VT reports, and SV has been performed on 3.6M APKs. We compared the results of both the process – (1) KF and (2) SV. We observe that KF identified around 102k CC APKs, while SV spotted 288k. Considering SV as a reference, KF is 20% accurate and it has 79% false rates. More precisely, precision and recall values are 20% and 7%, respectively.
4.2. CC Malware Dataset After applying the SVRs on 3.6M APKs from 20092025, we curated our final dataset of 288k APKs with 150, 3532, 2474, 17724, and 271762 samples, using Tor, TorPT, I2P, VPN, and proxies, respectively. We present their yearwise cumulative counts in Figure 411 . As evident, in 2016 there were under 25k CC APKs which dramatically increased to 288k by 2025. It shows that a lot of malware APKs have the presence of CC in their code (i.e., 7.88% of malware present in AndroZoo (3.6M)). Overall, we observed that the percentage of APKs using CC increased from 0.30% (in 2012) to 50% (in 2025)—a rise of 99.4%, indicating that CC usage is growing at an alarming rate. Our dataset reveals a complex behavior among malware creators, who often embed multiple CCs within a single APK. Figure 5 illustrates this phenomenon. The leftmost bar highlights the count of APKs to be 267k that only use proxies. The sixth bar (from left), represents 2.4k APKs that include both VPNs and proxies for covert communication. Our final dataset has 6.7k APKs with 23 CC combinations (out of 32 possible ones), showing the technical sophistication of malware creators. Figures 5 and 6 collectively shows that proxy usage is highest individually as well as in combination with other CCs. As evident from the yearwise statistics in Figure 6, most CC APKs use proxies, with Tor being least frequently used (under 200). There seems to be a common pattern of increasing CC APK counts from 2018. The reason could be attributed to the increased malware curation and identification by AndroZoo, 2018 onwards and the dip after 2022 can be attributed to the low number of available malware in years 2023/24/25. (see Table 1).
4.3. Static Study on Our Dataset of CC APKs To find which prominent families are involved, we passed all APKs’ VT reports through AVClass2 tool [23]. We discovered 511 distinct malware families, covering our dataset. More specifically, for Tor, TorPT, I2P, VPN, and proxy, we spotted 12, 39, 23, 127 and 477 unique families, respectively. We observed that there are families that have APKs using diverse CCs. Figure 7 shows the top 25 families and highlights an interesting observation, that these are not reported in security blogs even though their counts are quite high. We present the data of 6 families and various singletons in Figure 8 where it shows that bian family has different APKs 11. For package level statistics, see Section A.11.
(a) Tor
(b) TorPT
(c) VPN
(d) Proxy
(e) I2P
Figure 6: Yearwise count of malware APKs in each covert channel. 4.3.2. APK certificates:. Using the certificates embedded in APKs, one can track malware creators and take preemptive steps by eliminating or flagging them as potentially malicious software. Developer certificates have information regarding owner, issuer, serial number, validity, certificate fingerprints, signature algorithms and version. We observed that 75 most frequently occurring certificates (by their owner information) were present in at least 100 APKs. The most frequently occurring certificate was present in 4405 APKs. We also observed that majority of the malware APKs mentioned “Google” to be their organization, which is misleading12 . Figure 7: Top-25 malware families in our final dataset.
Figure 8: Malware families using multiple CCs.
that uses Tor, VPN and proxy CCs. Similarly, smsreg family uses I2P, VPNs and proxies, as CCs. We present the broader picture of top-25 families along their APK counts in Figure 15. Apart from specific family counts, we observed that for a significant portion of the dataset, AVClass2 labeled it as singletons, while for others their VT-score went down to zero. And for almost 32k APKs, their VT-score have reduced to zero, earlier reported to be non-zero by AndroZoo. This shows that the anti-virus engines’ reports are inconsistent (refer to Figure 9 for yearwise VT-scores and count of APKs). This is a well known phenomenon of engines since they frequently update their backends to improve accuracy and efficiency [65], [66], [67]. 4.3.1. Extensive code resue by malware creators:. We determine the number of unique APKs by counting the number of unique main packages. We observe that about 124k (≈ 43% of 288k) were unique. The multiple APKs with same main package names are likely different versions of the same APK. The top few highest version APKs are com.qihoo.appstore (2306), com.qiyi.vid eo (489), com.m4399.gamecenter (468), and com .sogou.androidtool (357). These statistics indicate that malware creators heavily reuse their codebases.
4.3.3. Permissions used by APKs:. We present the trend of permissions used in Figure 21. It includes internet, access_network_state and access_wifi_st ate. Individually for each CC, we observed the same permissions in abundance. Interestingly, there were 22 dangerous permissions among the 50 most frequently used permissions by malware. 4.3.4. Presence of .onion and .i2p:. We statically inspected 8k (in each CC) APKs to find any presence of .onion and .i2p domains in APK codes. We found 15 such APKs for .onion. In this set, two APKs had the same domain 13 . The other 13 APKs had implementation to visit onion sites through Tor. For I2P, we found 21 APKs with majority having strings such as [email protected] 2p, [email protected] etc..
4.4. CC Usage Evolution Trend We speculated that malware APKs might be evolving over time in terms of how they use CCs. To measure this, we extracted the main package (MP) names of each APK in our dataset, across years. We found that many APKs that appear in a year, have the same MPs. Thus, we selected APKs from each year and then searched for versions of the same appearing in subsequent years to study changes in CC usage. To our surprise, we found multiple APKs switching from one CC to multiple ones, and again moving back to the previous one. Moreover, the number of CC combinations has also been increasing over the years e.g., it increased from 7 to 16 combinations in a span of only three years (2017-2020) observed over complete data. Such types of evolution can be visualized using Figure 10. For the sake of better visibility, we have only shown the evolution for six years (2020-2025) and we reduced 12. There were 94k APKs with certificates having organization as Google Inc., Mountain View and California. 13. b2nkt5doeamvdmjzfz7g42hk5vdtlnktlgzhel2bgjcc 4v4jhnx2qrqd.onion
Figure 9: VT-scores and count of APKs for years from 2020-25. Heatmap for all years is shown in Section A.5.
Figure 10: Evolution in the usage of CC by malware APKs from 2020 to 2025. It includes all APKs present atleast twice across the years in our dataset. The colors represent different CC combinations found in APKs.
Figure 11: Evolution in the usage of 13 CC families present in all years from 2019 to 2024. the number of APKs in proxy CC as its in thousands. An example of evolution is an APK from 2021 with MP com .appatomic.vpnhub. It earlier used VPN but later in 2022 also accommodated proxy packages. There are those APKs that earlier used both VPNs and proxies, but later switched to only using VPNs. Another interesting APK, m e.talkyou.app.im continuously switched from using VPNs and proxies to VPNs only, and then back to the combination, and finally to proxy only, between 2020 and 2023. We found a total of unique 378 such changes in CC preferences in our APKs. The actual number of transitions could be much higher. Correlation between family labeling and CCintegration: Family labels are provided by VirusTotal and aggregated using AVClass2 tool. There were 13 families (out of 511) which were consistently present in years from 2019-24. These are autoins, smsreg, hiddad, smssend, umpay, triada, ewind, cryxos, dianjin, traca, smsspy, dataeye and kreditspy. We present their yearwise CC evolution in Figure 11. We observed an interesting trend that CC integrations do not correlate with family
labels provided by VT’s anti-virus engines. Thus, it suggests that VT engines might not be taking CC usage in consideration while making rules for family detection. We also observed that the top CC-integrated families appearing in 2019-2024, changed their CC channels over time, except for those that use Tor. This potentially shows that Tor might not be as popular, compared to other CCs.
4.5. Dynamic validation Since our final statically validated dataset contained over 288k APKs, it wasn’t feasible to perform dynamic validation for all the APKs. Thus, we selected APKs from each category in a manner that we covered all CC. For Tor and I2P, we selected all their flagged APKs. And for others we selected upto 100 APKs from each month from all years. Thus overall, we dynamically executed 13,697 APKs and captured pcaps for around 6,495. Remaining APKs did not produce any traffic, likely evaded the execution environment. We present success rate of dynamic runs over years in Figure 20. The dynamic execution took around 90 days to complete. We first extracted IPs from
(a) IPs across the globe.
(b) Time to first packet and their counts. (c) Connection durations and their counts.
Figure 12: Dynamic analysis results with respect to validated CC connections. the pcaps and used our methods explained in Section 3.3 for each type of CC. As a result, the number of distinct validated IPs were 5914 . Apart from these, we observed 1014 unique IPs with unknown protocols. Upon checking the unknown protocol IPs in whatismyip.com service, it returned 80 services with 19 proxies, 60 VPN servers and 1 Tor exit node, respectively (see Figure 18). We performed system-level validation steps on the dynamic data of successfully executed APKs. We observed logcat entries for 15, 6, 10 and 16 APKs from Tor, TorPT, VPN and proxy categories. We could not find network-level evidences for these APKs except for one VPN and two Tor-based APKs. Thus, a total of 87 APKs have been validated at either system or network level, except for 3 with both type of validations.
4.6. Dynamic Study of APKs 4.6.1. Network level behavior. Malware connects to different CCs across world. To observe this, we first performed IP geolocation using MaxMind web-services [68]. As per Gharaibeh et al. [69] MaxMind has 95% countrylevel accuracy. We present the results in Figure 12a using heatmap of validated IPs present in different countries. MaxMind could not identify the country for a few IPs, which were for APKs using VPNs. We observed maximum concentration IPs in US (13), Germany(7) and France(6). Overall we saw connections to 17 different countries . This might happen because the C2 servers (or peer bots) are located in countries closer to the VPN end-points. Apart from the validated CC IPs, we observed that there were around 19k non-Google IPs (i.e., largely unrelated to Android services) where malware tried to connect, spread across 85 countries15 . We also observed an interesting trend where multiple malware tried connecting to the same CC end-point IP. However, on each IP, we only found one kind of CC service running. Apart from that, we observed 42, 11 and 6 unique IPs corresponding to Tor, VPNs and proxies, respectively, to which the APKs connected. For Tor, we observed 12 unique destination ports (80, 443, 995, 6881, 8080, 9001, 9002, 9004, 9200, 9090, 30006, 60784). Tor ports such as 9200, 30006 or 60784 appear across multiple consensus files; e.g., 72 unique guards used port 9200 in Dec.’24 [70]. Similarly, we observed, four ports (80, 443, 1194, 8090) for VPNs and three ports (80, 8090, 50000) for proxies. 14. Maghsoudlou et al. [37]’s tool detected incorrect protocols (Figure 17). 15. We present the world heatmap in Figure 22
4.6.2. Liveness of CC servers. Figure 12b shows the time to first CC packet. We can see that 80% of connections receive their first packet in under 20 sec; for the remaining, it goes up to 160 sec. Further, Figure 12c shows connection durations. Some Tor-based apps maintain active CC connections for the full 5 minutes, while proxy apps often terminate within seconds corroborating with the findings of Mehanna et al. [29]. Certain VPN apps disrupt internet connectivity during runtime. 4.6.3. rDNS lookups. Upon inspecting the packet types, we observed that only 42 malware performed DNS lookups before making connections. The majority used Tor as CC. We also performed rDNS (revere DNS) on IPs seen in the traffic in order to find out the domain names associated with them. Overall, 3154 queries succeeded. We observed that in Tor, the majority of domains were i p-api.com (used for IP geo-location), while for VPNs, they mostly were for surfshark.com, and a few for Google services. For proxies, we observed that the majority used HTTP proxies and performed DNS queries for jovotech.com and afdvr.com16 .
5. Discussion 5.1. Lessons Learned 5.1.1. Matching at code-level. Using Matchscope [34], we compare two APKs, generating a summary that maps classes and methods from the first to the second. This work focuses on class-level matching, considering APKs matched if the first APK’s packages, classes and methods, have a correspondence in the second APK. Otherwise, the second is deemed to have a different implementation of the CC. Application over proxy-based APKs: Analyzing 11 proxy APKs with MatchScope, we identified 9 groups with similar codes. Matching these across 200k+ proxy APKs yielded 1,679 matches (i.e., 0.6%, see Table 6). The low success rate likely stems from considering only one version of each proxy APK, as malware creators reuse code but modify them to suit their needs, resulting in multiple library versions. 5.1.2. Obfuscation handling. We used LibScan to identify CC in obfuscated APKs, by matching validated CC libraries, in invalidated APKs. For this, we considered 8053 statically validated APKs, including all type of CC 16. jovotech:It shows domain for sale. It might have been active at malware origin. afdvr:Some agency working on surveillance.
Figure 13: Source code and corresponding logcat output. APKs. Library extraction succeeded in only half the cases (i.e., 3863), each bearing a CC library. Testing these 3863 libraries on 6985 APKs, we found only 39 that appeared in 5482 APKs, alongside a highly suspicious one matching almost every APK (5106)17 . It shows the difficulty in handling obfuscated APKs, and the need for efforts to understand packing/obfuscations. 5.1.3. Reality of dynamic analysis. We automated APK dynamic analysis using methods similar to COMEX[59], but observing CC creation was inconsistent, as it totally depends on when the malware would want to create CC. Running malware for extended periods raises ethical concerns. Thus the absence of evidence doesn’t always rule out CC creation at later stages. Future efforts should focus on artificially trigger CC creation, on the lines of Davanian et al. [71]18 .
5.2. Use Case: APK Behavior Analysis We selected a few APKs and observed their runtime behavior to spot CC creation and network communication. Case-I VPN APK=com.junkcleanner.cleanmas ter.supercleaner: It was flagged with VPN SVR. Upon installation and execution, and on running ps, we observed an entry named do_epoll_wait along with the APK’s main package name. Further, the application sought permission to establish global-level VPNs, but eventually it used only app-level VPN connection through a new process. Every second the app collected information about nearby wifi networks and sent it over the VPN to a remote server. Further, on the collected pcap, when we applied nDPI, it confirmed the VPN connection establishment. We present the relevant source code, logcat and nDPI output in Figure 13. Case-II Proxy APK=com.jovision.kowasmart: Similar to VPN APKs, upon installation and execution, and on running ps command, we observed a similar entry against do_epoll_wait. Upon code inspection, we discovered a Java class StatConstants with static strings of URLs to a website like qq.com and its subdomains. Logcat shows connection attempts, by some obfuscated class of com.tencent.stat, to a local process running at 0.0.0.1. Multiple attempts seemed to 17. Its close inspection revealed that it contains code snippets for all type of CCs. And thus matching with almost every APK. Its hash is o 6_7b50b0fa883e72c339796973e2a3140a761fbae61d7036 d96fab4bad35d6e50f. 18. Although their case was for IoT malware where they clearly mentioned that it won’t work for malware using CCs.
fail reporting ‘socket is in use’ log information. At the same time, we also observed in pcap, an HTTP proxy connection with 172.233.148.27. The number of connections were above 40 and in each connection it showed a transfer of 10-12 packets with a few KBs of data. Case-III Tor APK=com.uh88ctwr.og2w6oc:We observed that all APKs relying on Tor, used obfuscation techniques to hide their source code. For one APK (hash=533 ef52c0f797cf7e2933860034cbd8c4c2cab040c 11cb3c55a599c96e519e67), we could only observe the creation of Tor circuits through logcat logs. For example, we discovered IOnionProxyManager:St artingTor and I*oxyManagerEventHandler: message:severity:NOTICE,msg:Bootstrapp ed75%:Loadingrelaydescriptors messages in logcat. Case-IV I2P APK=pan.alexander.tordnscrypt .stable: Similar to Tor, for I2P we could only verify the execution at system level. It has integrated one I2P binary named as libi2pd.so. Upon installation and execution, it loads the binary and starts the I2P router as observed in the output of ps and logcat commands. These logs look like u0_a279Slibi2pd.so and pan .alexander.TPDCLogs:readTextFileSynchro noustake/data/user/0/pan.alexander.tord nscrypt.stable/app_data/i2pd/i2pd.confs uccess.
5.3. Recreation of SOTA We used two state-of-the-art (SOTA) malicious traffic detectors over collected pcaps to spot malicious (covert) traffic generated by malware. We recreated Barradas et al.’s [72] (SOTA-I) and Qing et al. [73]’s work (SOTAII). We used the source code and data to train the models mentioned in their paper (since the training data is not dependent on the testing malware APKs). In SOTA-I, we get four models named as C-behav-rf, C-behav-dt, Ccert-rf, C-cert-dt. In SOTA-II, we obtain a single model after training. To test these models, we selected 15 benign APKs (for each CC) and 28 malware APKs (7 of each CC category). We collected network traffic of all the APKs by executing them on a mobile phone for 5 minutes. Except, in case of the benign APKs, we ran them and accessed Tranco [74] top-20 websites using them. We extracted features as per the SOTA’s for each pcap and tested those against the respective models. Results are presented in Table 2. Each row has the results (FPR/FNR) for the
TABLE 2: Traffic detection results on state-of-the-art solutions (SOTA). Here for SOTA-I, we are only presenting Cbehav-rf model results. For the rest three refer to Section A.4. Benign APKs Covert Channel Tor VPN Proxy TorPT I2P
SOTA-I [72] Flows FPR (%) 62 12.90 4460 2.06 908 2.06 29 0.00 9 11.11
Malware APKs SOTA-II [73] Flows FNR (%) 34 0.00 333 9.00 809 22.86 295 2.03 1265 22.37
SOTA-II [73] Flows FPR (%) 9 100 2194 89.65 717 98.46 18 83.33 4 50.00
SOTA-I [72] Flows FNR (%) 58 89.65 642 96.72 1687 96.79 568 97.53 2623 95.15
corresponding category tested for both benign/malware flows against each SOTA. Each SOTA has its specific flow and feature extraction methods, and thus the number of extracted flows, in each case, is different (see Flows columns). We followed the paper implementation as is to avoid any self-introduced biases that can effect the solutions. For benign APKs, it shows the percentage of flows predicted as malicious i.e., FPR. And, for malware, it shows the percentage of flows predicted as benign, i.e., FNR. We observe that even though SOTA-I performs well on benign flows, it makes errors upto 90% for malware flows (high false negatives). On the contrary, SOTA-II performs well on malware flows but produces false positives, upto 98%, which can be detrimental for benign users. Note that our analysis results are limited to our dataset only. While we observed SOTA detector failures, precise root-cause attribution is nontrivial because these approaches are black boxes, requiring extensive feature analysis and XAI-based explainability studies. Thus, we conclude that further efforts are necessary to comprehend CC traffic.
6. Related Work
5.4. Limitations & Future Work 1) Limited to AndroZoo: We considered all malware APKs with a non-zero VT-score on AndroZoo [39] which is cumulatively 3.6M. AndroZoo itself collects APKs from 15 different sources including VirusShare [91] and GooglePlay. Thus, the study might provide a comprehensive picture of majority of malware to date. 2) Static validation limitation: Several malware download their payload or necessary execution files at runtime. Thus, static validation rules cannot discover such files/libraries which get downloaded upon APK execution. Current SVRs for APKs apply only to unobfuscated/unmodified code segments. For obfuscated/modified APKs, the entire library code must be matched against known libraries. We conducted this experiment, with results detailed in Sections 5.1.1 and 5.1.2. 3) Automation for new CC: Creating static validation rules without manually analyzing APKs—e.g., permissions, text signatures, native library loading, or new class instantiation—is challenging. Establishing such rules requires appropriate knowledge of the signatures of new CCs, which is relatively non-trivial to automate. 4) Future work: We will expand the study by including other CCs that malware uses for C2/bot communications, across other platforms. Some examples include social media and IM applications (e.g., signal, telegram), game servers (e.g. Pubg, Clash of Clans) etc..
There are some research works highlighting the presence of malware that use CCs. But no work has previously studied their evolution over years, and nor are there readily available tools/pipelines to discover such channels in new Android malware, thousands of which appear daily. We divided the related works into three categories. The first includes works that identify such CCs in malware. The second includes works that study the ecosystem of various CCs. These are not categorically related to the malicious usages. And the third one includes works that explore various state-of-the-art traffic analysis methods to see if they can be used to spot malicious (covert) traffic generated by malware. Category-I Malware using covert channel: There are no longitudinal studies that explore the usage of proxy-based CCs such as Tor, VPN, free proxies and TorPTs by malware. Table 3 highlights that there is one work on Android by Anagnostopoulos et al. [77] where authors proposed novel designs of botnets using Tor hidden services. There are works for other platforms such as Windows, Linux etc. [75], [76], [22], [78], [79], [80], [81], [88]. TorBot stalker [75], Li et al. [76] and Dodia et al. [22] worked on developing detection methods to distinguish non-Tor from Tor traffic. Only Dodia et al. [22] tried to search for real malware that uses Tor. However, they found 362 such cases for Windows, which might not represent the diversities of Tor-based malware in the wild19 . Hopper et al. [78] proposed solutions to protect Tor from botnet abuse reported in August 2013 [93]. In contrast, following the same incident, Kang et al. [81] and Sanatinia et al. [80] proposed design for better botnets that cannot be easily removed. Additionally, the efforts by Novo et al. [88] also aim to identify malware traffic that uses CCs. To that end, they proposed the creation of an adversarially strong DL model. However, they did not test it on real malware traffic but only used synthetic flows emulating that of a C2 server. Category-II Proxy based covert channel ecosystem: Several works highlight the ecosystem of the CCs themselves and their security/privacy guarantees. But most do not describe their malicious usage in malware network communications. Zhang et al. [84], Ikram et al. [85] and Heijligenberg et al. [86] performed security analysis of Android-based VPN APKs. Apart from Android, others have also performed such analyses for Windows/Linux/MacOS based covert communication tools[82], [83], [37], [87], [30], [31], [57], [29], [28], [43], [2], [63], [90]. 19. As per VirusTotal weekly stats [92], Windows based malware are the top occurring in the wild. (As of Jan 2025)
TABLE 3: Type of Study: [Cov: About the usage of covert channel in malware, Eco: Eco-system of the covert channel, Long. Years: Longitudinal years of study, we mention the years if it exceeds a year.]. Covert Channel Tor
VPN
Proxy
TorPT I2P All Above
Platform Android Others ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
Type of Study Cov ✓ ✓ ✓
Eco
✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
Long. Years ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ 2016-19 ✗ ✗ ✗ ✗, 2022-23 ✗ 2009-25
Category-III Malicious traffic detection: This is a wellexplored and complex research area. Most allied works involve some form of traffic analysis to distinguish malicious from benign flows. Here we only provide an overview of the most important state-of-the-art (SOTA) detection solutions published in top-tier venues in recent years. We explored these solutions to find out if SOTA is able to distinguish between benign and malicious covert traffic. Among others like [94], [95], [96], [97], [98], [88], [99], we attempted to recreate some latest SOTA on malicious traffic detection such as [100], [73], [72] 20 . We present the results later in Section 5.3. Overall, we conclude that the SOTA has high FPs and thus requires more understanding of traffic that use CCs. Thus, firstly there is no longitudinal study over Android malware using CCs for hiding their communications. Secondly and eventually, there is an absence of tools/pipelines for discovering such APKs. As per Table 3, this is the first longitudinal study involving malware APKs that have appeared in the last 16 years (since Android’s inception) that explores how CCs have been used, along with a framework to continue the research forward.
Most Relevant Related Work
TorBot Stalker [75], Li et al. [76], Dodia et al. [22] Anagnostopoulos et al. [77] Hopper et al. [78], Casenove et al. [79], OnionBots [80], Kang et al. [81] Vpnalyzer [82] Khan et al. [83] Zhang et al. [84] Ikram et al. [85], Heijligenberg et al. [86] Maghsoudlou et al. [37], Xue et al. [87] Novo et al. [88] Mi et al. [30], Choi et al. [57] Mi et al. [31] Mehanna et al. [29], Bian et al. [28] Khattak et al. [43], PTPerf [2] Muller et al. [89], Hoang et al. [63], Yin et al. [90] This Work
study reveals using SOTA mechanism to tell malicious and non-malicious traffic apart, report high FPR, underscoring the need for better solutions in the future.
8. Acknowledgments We thank our colleagues and anonymous reviewers for their valuable feedback and suggestions.
References [1]
R. Dingledine, N. Mathewson, P. F. Syverson et al., “Tor: The Second-Generation Onion Router.” in Proceedings of the 13th USENIX Security Symposium, vol. 4, 2004, pp. 303–320.
[2]
Z. Umayya, D. Malik, D. Gosain, and P. Kumar Sharma, “Ptperf: On the performance evaluation of tor pluggable transports,” in Proceedings of the ACM Internet Measurement Conference (IMC), 2023, pp. 501–525.
[3]
I2P, “The invisible internet project,” https://geti2p.net/en/, 2025.
[4]
Kaspersky, “What is vpn? how it works, types of vpn,” https: //www.kaspersky.com/resource-center/definitions/what-is-a-vpn, 2025.
[5]
Balaji, “Domain fronting – a new technique for hiding malware command and control (c2) traffic within a content delivery network,” https://gbhackers.com/domain-fronting-a-new-technique -for-hiding-malware-command-and-control-c2-traffic-within-a-c ontent-delivery-network/, 2018.
[6]
B. P. Paganini, “New mirai botnet hides c2 server in the tor network to prevent takedowns,” https://securityaffairs.com/89 237/malware/mirai-botnet-tor-c2.html, 2019.
[7]
N. Warfield, “Not with a bang but a whisper: The shift to stealthy c2,” https://threatpost.com/tactics-attackers-stealthy-c2/176853/, 2021.
[8]
B. Toulas, “Thousands of hackers flock to ’dark utilities’ c2-asa-service,” https://www.bleepingcomputer.com/news/security/tho usands-of-hackers-flock-to-dark-utilities-c2-as-a-service/, 2022.
[9]
C. Talos, “Attackers leveraging dark utilities ”c2aas” platform in malware campaigns,” https://blog.talosintelligence.com/dark-utili ties/, 2022.
[10]
B. P. Arntz, “Android devices caught in matryosh botnet,” https: //www.malwarebytes.com/blog/news/2021/02/android-devices-c aught-in-matryosh-botnet, 2021.
[11]
B. B. Toulas, “Socks5systemz proxy service infects 10,000 systems worldwide,” https://www.bleepingcomputer.com/news/secu rity/socks5systemz-proxy-service-infects-10-000-systems-world wide/, 2023.
7. Conclusion Android malware increasingly seem to exploit covert channels (CC) like Tor, I2P, VPNs and proxies to evade detection. Despite widespread use, no longitudinal study has examined their evolution and prevalence. We present a novel pipeline for detecting CC usage in malware APKs. It begins with a static validation, combining automation and manual efforts, followed by fully automated steps. Applied to 3.6M APKs (between 2009–2025), it identified 288k that used CC–Tor (150), TorPT (3k), I2P (2k), VPNs (17k) and proxies (271k), spread across 511 families. Dynamic validation and analysis, using real devices, and collecting runtime network/system data (using pcaps, logcat, ps, lsof, and netstat), revealed that malware connected to CCs over 59 unique IPs across 17 countries. APK’s evolutionary study revealed that malware constantly adapt CC strategies. Further, preliminary 20. Since Fu et al.’s source code was not public, we could not recreate it. We were able to recreate the rest.
[12]
B. Alex.Turing and H. Wang, “The leethozer botnet,” https://blog .netlab.360.com/the-leethozer-botnet-en/, 2020.
[13]
B. E. Smith and the Falcon OverWatch Elite Team, “Walking through walls: Four common endpoint tools used to facilitate covert c2,” https://www.crowdstrike.com/en- us/blog/4- com mon-endpoint-tools-used-to-facilitate-covert-c2/, 2023.
[14]
B. R. Lakshmanan, “Systembc malware’s c2 server analysis exposes payload delivery tricks,” https://thehackernews.com/2024/0 1/systembc-malwares-c2-server-analysis.html, 2024.
[15]
l. By Alex.Turing, Hui Wang, “New threat: Matryosh botnet is spreading,” https://blog.netlab.360.com/matryosh-botnet-is-sprea ding-en/, 2021.
[16]
Blackhat, “Blackhat,” https://blackhat.com/us-23/briefings/sched ule/?, 2023.
[17]
Defcon, “Defcon,” https://infocondb.org/con/def-con/def-con-31/, 2023.
[18]
VirusTotal, “Virustotal api v3 overview,” https://docs.virustotal. com/reference/overview, 2025.
[19]
D. Arp, M. Spreitzenbarth, M. Hubner, H. Gascon, K. Rieck, and C. Siemens, “Drebin: Effective and explainable detection of android malware in your pocket.” in Proceedings of the Network and Distributed System Security Symposium (NDSS), vol. 14, 2014, pp. 23–26.
[31]
X. Mi, S. Tang, Z. Li, X. Liao, F. Qian, and X. Wang, “Your phone is my proxy: Detecting and understanding mobile proxy networks,” in Proceeding of ISOC Network and Distributed System Security Symposium (NDSS), 2021.
[32]
Y. Duan, M. Zhang, A. V. BHASKAR, H. Yin, X. Pan, T. Li, X. Wang, and X. Wang, “Things you may not know about android (un) packers: a systematic study based on whole-system emulation,” in Proceedings of the Network and Distributed System Security Symposium (NDSS), 2018.
[33]
S. Siddiqui and T. A. Khan, “An overview of techniques for obfuscated android malware detection,” SN Computer Science, vol. 5, no. 4, p. 328, 2024.
[34]
R. Feng, Z. Zhang, Y. Zhou, Z. Yan, and Y. Zhang, “Accurate and efficient code matching across android application versions against obfuscation,” in Proceedings of the 2024 IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER). IEEE, 2024, pp. 204–215.
[35]
A. Ruggia, D. Nisi, S. Dambra, A. Merlo, D. Balzarotti, and S. Aonzo, “Unmasking the veiled: A comprehensive analysis of android evasive malware,” in Proceedings of the 19th ACM Asia Conference on Computer and Communications Security (CCS), 2024, pp. 383–398.
[36]
MBC, “Mbc-breakdown,” https://github.com/MBCProject/mbc-m arkdown/tree/main/anti-behavioral-analysis, 2025.
[20]
K. Xu, Y. Li, R. H. Deng, and K. Chen, “Deeprefiner: Multilayer android malware detection system applying deep neural networks,” in 2018 Proceedings of the IEEE European Symposium on Security and Privacy (EuroS&P). IEEE, 2018, pp. 473–487.
[37]
A. Maghsoudlou, L. Vermeulen, I. Poese, and O. Gasser, “Characterizing the vpn ecosystem in the wild,” in International Conference on Passive and Active Network Measurement (PAM). Springer, 2023, pp. 18–45.
[21]
Y. Wu, X. Li, D. Zou, W. Yang, X. Zhang, and H. Jin, “Malscan: Fast market-wide mobile malware scanning by social-network centrality analysis,” in Proceedings of the IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE, 2019, pp. 139–150.
[38]
L. Deri, M. Martinelli, T. Bujlow, and A. Cardigliano, “ndpi: Open-source high-speed deep packet inspection,” in 2014 International Wireless Communications and Mobile Computing Conference (IWCMC). IEEE, 2014, pp. 617–622.
[39]
AndroZoo, “Androzoo,” https://androzoo.uni.lu/, 2016.
[22]
P. Dodia, M. AlSabah, O. Alrawi, and T. Wang, “Exposing the rat in the tunnel: Using traffic analysis for tor-based malware detection,” in Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security (CCS), 2022, pp. 875–889.
[40]
F. Mercaldo, F. Martinelli, A. Santone et al., “An explainable convolutional neural network for dynamic android malware detection.” in Proceedings of the The International Conference on Information Systems Security and Privacy (ICISSP), 2023, pp. 305–312.
[23]
S. Sebastián and J. Caballero, “Avclass2: Massive malware tag extraction from av labels,” in Proceedings of the 36th Annual Computer Security Applications Conference (ACSAC), 2020, pp. 42–53.
[41]
Z. Umayya, “Invisible ink codebase,” https://github.com/zeya2u9 /The-Invisible-Ink, 2026.
[42]
Tor, “Directory authorities,” https://community.torproject.org/rel ay/governance/policies-and-proposals/directory-authority/, 2025.
[43]
S. Khattak, T. Elahi, L. Simon, C. M. Swanson, S. J. Murdoch, and I. Goldberg, “Sok: Making sense of censorship resistance systems,” Proceedings on Privacy Enhancing Technologies, vol. 2016, no. 4, pp. 37–61, October 2016.
[44]
C. Scott, P. Wolfe, and M. Erwin, Virtual private networks. O’Reilly Media, Inc.”, 1999.
[45]
OpenVPN, “What is openvpn?” https://openvpn.net/faq/what-i s-openvpn/, 2025.
[46]
J. A. Donenfeld, “Wireguard: Next generation kernel network tunnel.” in Network and Distributed Systems Security Symposium, 2017, pp. 1–12.
[47]
B. K. S. Blogs, “Vpn vs. proxy server: What’s the difference, and which should you be using?” https://www.kaspersky.com/resour ce-center/preemptive-safety/vpn-vs-proxy-server, 2025.
[48]
I2P, “Garlic routing,” https://geti2p.net/en/docs/how/garlic-routi ng, 2025.
[49]
——, “i2p.android.base,” https://github.com/i2p/i2p.android.bas e/tags?after=android-0.9.12-0 b1-API8, 2025.
[50]
D. Fifield, “Snowflake,” https://github.com/keroserene/snowflake, 2025.
[51]
N. F. Arlo Breault, Chang Lan, “Meek,” https://github.com/arlol ra/meek, 2014.
[52]
B. T. Seals, “Puzzling gwmndy botnet focuses on low-volume proxy connections,” https://threatpost.com/gwmndy-botnet-proxy -connections/146963/, 2019.
[24]
M. Alecci, P. J. R. Jiménez, K. Allix, T. F. Bissyandé, and J. Klein, “Androzoo: A retrospective with a glimpse into the future,” in Proceedings of the 21st International Conference on Mining Software Repositories (MSR), 2024, pp. 389–393.
[25]
Y. Wu, C. Sun, D. Zeng, G. Tan, S. Ma, and P. Wang, “LibScan: Towards more precise third-party library identification,” in Proceedings of the 32nd USENIX Security Symposium (USENIX Security 23), 2023, pp. 3385–3402.
[26]
[27]
X. Zhan, T. Liu, L. Fan, L. Li, S. Chen, X. Luo, and Y. Liu, “Research on third-party libraries in android apps: A taxonomy and systematic literature review,” IEEE Transactions on Software Engineering, vol. 48, no. 10, pp. 4181–4213, 2021. Z. Zhang, W. Diao, C. Hu, S. Guo, C. Zuo, and L. Li, “An empirical study of potentially malicious third-party libraries in android apps,” in Proceedings of the 13th ACM Conference on Security and Privacy in Wireless and Mobile Networks, 2020, pp. 144–154.
[28]
R. Bian, S. Hao, H. Wang, and C. Cotton, “Shining a light on dark places: A comprehensive analysis of open proxy ecosystem,” Computer Networks, vol. 208, p. 108893, 2022.
[29]
N. Mehanna, W. Rudametkin, P. Laperdrix, and A. Vastel, “Free proxies unmasked: A vulnerability and longitudinal analysis of free proxy services,” arXiv preprint arXiv:2403.02445, 2024.
[30]
X. Mi, X. Feng, X. Liao, B. Liu, X. Wang, F. Qian, Z. Li, S. Alrwais, L. Sun, and Y. Liu, “Resident evil: Understanding residential ip proxy as a dark service,” in 2019 IEEE Symposium on Security and Privacy (S&P). IEEE, 2019, pp. 1185–1201.
”
[53]
B. B. L. Labs, “New hiatusrat router malware covertly spies on victims,” https://blog.lumen.com/new-hiatusrat-router-malware-c overtly-spies-on-victims/, 2023.
[54]
B. USA, “Apkid: Fast identification of mobile rasp sdks,” https: //www.blackhat.com/us-23/arsenal/schedule/#apkid-fast-identific ation-of-mobile-rasp-sdks-32577, 2023.
[55]
VirusTotal, “Vtdoc,” https://docs.virustotal.com/docs/how-it-wor ks, 2025.
[56]
R. Sun, M. Xue, G. Tyson, T. Dong, S. Li, S. Wang, H. Zhu, S. Camtepe, and S. Nepal, “Mate! are you really aware? an explainability-guided testing framework for robustness of malware detectors,” in Proceedings of the 31st ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering, 2023, pp. 1573–1585.
[74]
V. L. Pochat, T. Van Goethem, S. Tajalizadehkhoob, M. Korczyński, and W. Joosen, “Tranco: A research-oriented top sites ranking hardened against manipulation,” arXiv preprint arXiv:1806.01156, 2018.
[75]
O. Fajana, G. Owenson, and M. Cocea, “Torbot stalker: Detecting tor botnets through intelligent circuit data analysis,” in 2018 IEEE 17th International Symposium on Network Computing and Applications (NCA). IEEE, 2018, pp. 1–8.
[76]
Z. Li, M. Wang, X. Wang, J. Shi, K. Zou, and M. Su, “Identification domain fronting traffic for revealing obfuscated c2 communications,” in 2021 IEEE Sixth International Conference on Data Science in Cyberspace (DSC). IEEE, 2021, pp. 91–98.
[77]
M. Anagnostopoulos, G. Kambourakis, P. Drakatos, M. Karavolos, S. Kotsilitis, and D. K. Yau, “Botnet command and control architectures revisited: Tor hidden services and fluxing,” in Web Information Systems Engineering–WISE 2017: 18th International Conference, Puschino, Russia, October 7-11, 2017, Proceedings, Part II 18. Springer, 2017, pp. 517–527.
[78]
N. Hopper, “Challenges in protecting tor hidden services from botnet abuse,” in Financial Cryptography and Data Security: 18th International Conference, FC 2014, Christ Church, Barbados, March 3-7, 2014, Revised Selected Papers 18. Springer, 2014, pp. 316–325.
[57]
J. Choi, M. Abuhamad, A. Abusnaina, A. Anwar, S. Alshamrani, J. Park, D. Nyang, and D. Mohaisen, “Understanding the proxy ecosystem: A comparative analysis of residential and open proxies on the internet,” IEEE Access, vol. 8, pp. 111 368–111 380, 2020.
[58]
A. Küchler, A. Mantovani, Y. Han, L. Bilge, and D. Balzarotti, “Does every second count? time-based evolution of malware behavior in sandboxes,” in NDSS 2021, Network and Distributed Systems Security Symposium. Internet Society, 2021.
[59]
Z. Umayya, D. Malik, A. Nandi, A. Kumar, S. Karapoola, and S. Chakravarty, “Comex: Deeply observing application behavior on real android devices,” in Proceedings of the 17th Cyber Security Experimentation and Test Workshop, 2024, pp. 100–109.
[79]
M. Casenove and A. Miraglia, “Botnet over tor: The illusion of hiding,” in 2014 6th International Conference On Cyber Conflict (CyCon 2014). IEEE, 2014, pp. 273–282.
[60]
Tor, “Public tor-consensus,” https://collector.torproject.org/archi ve/relay-descriptors/consensuses/, 2026.
[80]
[61]
D. Johnson, “Stem Library ,” https://stem.torproject.org/, 2025.
[62]
G. Project, “Tor on mobile,” https://gitlab.com/guardianproject/t ormobile, 2025.
A. Sanatinia and G. Noubir, “Onionbots: Subverting privacy infrastructure for cyber attacks,” in 2015 45th Annual IEEE/IFIP International Conference on Dependable Systems and Networks. IEEE, 2015, pp. 69–80.
[81]
[63]
N. P. Hoang, P. Kintis, M. Antonakakis, and M. Polychronakis, “An empirical study of the i2p anonymity network and its censorship resistance,” in Proceedings of the internet measurement conference 2018, 2018, pp. 379–392.
L. Kang, “Efficient botnet herding within the tor network,” Journal of Computer Virology and Hacking Techniques, vol. 11, pp. 19–26, 2015.
[82]
R. Ramesh, L. Evdokimov, D. Xue, and R. Ensafi, “Vpnalyzer: systematic investigation of the vpn ecosystem,” in Network and Distributed System Security Symposium, vol. 10, 2022.
[83]
M. T. Khan, J. DeBlasio, G. M. Voelker, A. C. Snoeren, C. Kanich, and N. Vallina-Rodriguez, “An empirical analysis of the commercial vpn ecosystem,” in Proceedings of the Internet Measurement Conference 2018, 2018, pp. 443–456.
[64]
I2P, “I2p metrics,” https://i2p-metrics.np-tokumei.net/overview, 2025.
[65]
M. Botacin and H. Gomes, “Towards more realistic evaluations: The impact of label delays in malware detection pipelines,” vol. 148. Elsevier, 2025, p. 104122.
[66]
S. Zhu, J. Shi, L. Yang, B. Qin, Z. Zhang, L. Song, and G. Wang, “Measuring and modeling the label dynamics of online {AntiMalware} engines,” in Proceedings of the 29th USENIX Security Symposium (USENIX Security 20), 2020, pp. 2361–2378.
[84]
Q. Zhang, J. Li, Y. Zhang, H. Wang, and D. Gu, “Oh-pwn-vpn! security analysis of openvpn-based android apps,” in International Conference on Cryptology and Network Security. Springer, 2017, pp. 373–389.
[67]
J. Wang, L. Wang, F. Dong, and H. Wang, “Re-measuring the label dynamics of online anti-malware engines from millions of samples,” in Proceedings of the 2023 ACM on Internet Measurement Conference, 2023, pp. 253–267.
[85]
M. Ikram, N. Vallina-Rodriguez, S. Seneviratne, M. A. Kaafar, and V. Paxson, “An analysis of the privacy and security risks of android vpn permission-enabled apps,” in Proceedings of the 2016 internet measurement conference, 2016, pp. 349–364.
[68]
MaxMind, “Ip geolocation and intelligence databases and web services,” https://www.maxmind.com/en/solutions/ip-geolocation -databases-api-services, 2025.
[86]
[69]
M. Gharaibeh, A. Shah, B. Huffaker, H. Zhang, R. Ensafi, and C. Papadopoulos, “A look at router geolocation in public and commercial databases,” in Proceedings of the 2017 Internet Measurement Conference, 2017, pp. 463–469.
T. Heijligenberg, O. Lkhaouni, and K. Kohls, “Leaky blinders: Information leakage in mobile vpns,” in International Conference on Applied Cryptography and Network Security. Springer, 2022, pp. 481–494.
[87]
N. Xue, Y. Malla, Z. Xia, C. Pöpper, and M. Vanhoef, “Bypassing tunnels: leaking {VPN} client traffic by abusing routing tables,” in Proceedings of the 32nd USENIX Security Symposium (USENIX Security 23), 2023, pp. 5719–5736.
[88]
C. Novo and R. Morla, “Flow-based detection and proxy-based evasion of encrypted malware c2 traffic,” in Proceedings of the 13th ACM Workshop on Artificial Intelligence and Security, 2020, pp. 83–91.
[89]
J. H. Müller, “Analysis of the i2p network: Information gathering and attack evaluations,” Bachelor’s thesis, Bern University of Applied Sciences, June 2016, bSc in Computer Science (ITSecurity).
[90]
H. Yin and Y. He, “I2p anonymous traffic detection and identification,” in Proceedings of the 2019 5th International Conference on Advanced Computing & Communication Systems (ICACCS). IEEE, 2019, pp. 157–162.
[91]
VirusShare, “Virusshare,” https://virusshare.com/, 2025.
[70]
Tor, “Tor-consensus,” https://collector.torproject.org/archive/relay -descriptors/consensuses/consensuses-2024-12.tar.xz, 2026.
[71]
A. Davanian, M. Faloutsos, and M. Lindorfer, “C2miner: Tricking iot malware into revealing live command & control servers,” in Proceedings of the 19th ACM Asia Conference on Computer and Communications Security, 2024, pp. 112–127.
[72]
D. Barradas, C. Novo, B. Portela, S. Romeiro, and N. Santos, “Extending c2 traffic detection methodologies: From tls 1.2 to tls 1.3-enabled malware,” in Proceedings of the 27th International Symposium on Research in Attacks, Intrusions and Defenses, 2024, pp. 181–196.
[73]
Y. Qing, Q. Yin, X. Deng, Y. Chen, Z. Liu, K. Sun, K. Xu, J. Zhang, and Q. Li, “Low-quality training data only? a robust framework for detecting encrypted malicious network traffic,” arXiv preprint arXiv:2309.04798, 2023.
[92]
VirusTotal, “Virustotal stats,” https://www.virustotal.com/gui/sta ts, 2025.
A.2. Other Anonymity Networks
[93]
B. D. A. Veluz, “Adware Gone Bad: The Adware and MEVADE/SEFNIT Connection,” https://www.trendmicro.com /vinfo/in/threat-encyclopedia/web-attack/136/adware-gone-bad-t he-adware-and-mevadesefnit-connection, 2014.
[94]
X. Hu, Y. Gao, G. Cheng, H. Wu, and R. Li, “An adversarial learning-based tor malware traffic detection model,” in GLOBECOM 2022-2022 IEEE Global Communications Conference. IEEE, 2022, pp. 74–79.
Apart from Tor and I2P, there are other anonymity networks such as Hyphanet (earlier Freenet), GNUNet, ZeroNet and Hopr. Among these, only Hyphanet has released an Android APK.
[95]
J. Bergman and O. B. Popov, “Recognition of tor malware and onion services,” Journal of Computer Virology and Hacking Techniques, vol. 20, no. 2, pp. 261–275, 2024.
[96]
C. Wang, C. Redino, A. Rahman, R. Clark, D. Radke, T. Cody, D. Nandakumar, and E. Bowen, “Discovering command and control (c2) channels on tor and public networks using reinforcement learning,” in SoutheastCon 2024. IEEE, Mar. 2024, p. 427–433. [Online]. Available: http: //dx.doi.org/10.1109/SoutheastCon52093.2024.10500045
[97]
N. Polatidis, E. Pimenidis, M. Trovati, and L. Iliadis, “Vpndroid: Malicious android vpn detection using a cnn-rf method,” in International Conference on Artificial Neural Networks. Springer, 2023, pp. 444–453.
[98]
S. Seraj, S. Khodambashi, M. Pavlidis, and N. Polatidis, “Mvdroid: an android malicious vpn detector using neural networks,” Neural Computing and Applications, vol. 35, no. 29, pp. 21 555– 21 565, 2023.
[99]
E. Chiapponi, M. Dacier, O. Thonnard, M. Fangar, and V. Rigal, “Badpass: Bots taking advantage of proxy as a service,” in International Conference on Information Security Practice and Experience. Springer, 2022, pp. 327–344.
[100] Z. Fu, M. Liu, Y. Qin, J. Zhang, Y. Zou, Q. Yin, Q. Li, and H. Duan, “Encrypted malware traffic detection via graph-based network analysis,” in Proceedings of the 25th International Symposium on Research in Attacks, Intrusions and Defenses, 2022, pp. 495–509. [101] T. L. Beauchamp, “The belmont report,” Tech. Rep., 2008. [102] I. Clarke, O. Sandberg, B. Wiley, and T. W. Hong, “Freenet: A distributed anonymous information storage and retrieval system,” in Designing privacy enhancing technologies: international workshop on design issues in anonymity and unobservability Berkeley, CA, USA, July 25–26, 2000 Proceedings. Springer, 2001, pp. 46–66. [103] J. Samhi and A. Zeller, “Androlog: Android instrumentation and code coverage analysis,” in Companion Proceedings of the 32nd ACM International Conference on the Foundations of Software Engineering, 2024, pp. 597–601.
A.2.1. Hyphanet/Freenet. Hyphanet is a peer-to-peer network proposed in 2001 [102]. We analyzed Hyphanet’s APK in detail and constructed its static validation rules as follows: Static validation rules: To statically check if a given APK integrates Hyphanet or not, we check for the presence of files having certain keys in them. 1) Configuration files (e.g., freenet.ini) with keys - con sole.enabled, fproxy.enabled, fproxy. port, fproxy.bindTo, node.listenPort, n ode.storeSize, node.storeType, node.b indTo, node.opennet.enabled, node.ope nnet.listenPort, node.opennet.bindTo. 2) Information about seed nodes for Freenet in files (e.g., seednodes.fref ) with keys - identity=, location=, opennet=, sigP256=, physical.udp=, End. Application of the above rules on malware APKs from AndroZoo in Table 1 does not flag any malware APK apart from its official one, which we are not considering as a part of our dataset. A.2.2. Possible reasoning for non-usage in malware. There are a number of reasons why malware creators would not prefer to integrate Hyphanet in their APKs. The first one is its non-real-time communication nature, where data may take time to propagate to the network nodes. Secondly, it is geared towards working as an anonymous distributed file sharing solution, lacking the servicebased models considered by other CCs like Tor, VPNs, and proxies, making it less amenable for hiding C2/bot communication. The third reason could be the absence of support, otherwise available for projects like Tor, that are maintained and upgraded for multiple integration methods.
A.3. List of Keywords
Appendix A. Appendix A.1. Ethics Considerations Our dynamic validation step require installation and execution of malware APKs on mobile phones so that we can monitor live CC establishments. Thus we carefully planned our experiments using Belmont’s report [101]. We submitted a detailed IRB proposal to the institute’s board. However, we were exempted from it since as per our institute’s regulations, studies with no human subject involvement do not require approval. Still, we isolated the phones from our network so that the malware discovered none (vulnerable) to infect. The phones have been procured commercially, and are dedicated to our research. Further, to minimize the risk, we did not leave any malware running for too long to minimize the levels of exposure on the Internet.
For each category there is a different list of keywords. We present all these in Table 4.
A.4. SOTA-I Results Section A.4 presents results on three models namely - C-behav-dt, C-cert-dt, and C-cert-rf.
A.5. Heatmap of VT-scores Figure 14 presents the yearwise count of statically validated APKs.
A.6. Families using multiple CCs We present the statistics of malware families using multiple covert channels in Figure 15.
Figure 14: VT-scores and yearwise count of APKs. TABLE 4: List of keywords for each covert channel. Covert Channel Tor
VPN
Proxy
TorPT
I2P
Keywords dark web, *.onion, tor, torrc, orbot, onion, hidden service, tor.apk, tor2web, Ahmia, socks proxy, Tor browser, orxify, TorServices, onion service, Orchid, OnionKit virtual private network, vpn, nord, express, proton, proxy, outline, zerotier, openvpn, rav vpn, psiphon, v2ray, nymVPN, freenet, freedom network, JonDonym, Java Anon Proxy, shadowsocks redsocks, stunnel, cntlm, http, socks, https, proxy, Proxychains, squid, Privoxy, SOCKS5, Web, Forward, Reverse, SSH, Mitmproxy, HAProxy, Switcher, Tinyproxy, Proxifier, Tunnel, SSL decoy routing, domain fronting, snowflake, obfs4, meek, lantern, webtunnel, conjure, lyrebird, obfs, minecruft, dnstt, TorCloak, cloak, marionette, stegotorus, camoufler, massbrowser, protozoa, stegozoa, deltashaper, facet, mailet, cloudTransport, covertcast, freewave, balboa, domain shadowing *.i2p, i2p, i2pd, NTCP, NTCP2, SSU, SSU2, eepsite, i2psnark, i2pbote, BOB, SAM, SAM V2, SAM V3, I2PTunnel, i2cp, garlic routing, clients.config, router.config, i2ptunnel.config, SusiMail, i2np, garlic message
Figure 15: Heatmap of malware families using several CCs together.
A.7. Strings/Regex in Pcaps & Results We present the regex/strings in Figure 16.
A.8. MatchScope Results Figure 16: Strings/regex to search for in packets.
A.9. List of VPN packages & Corresponding APK Downloads 1) tun.proxy, 500+ 2) com.v2ray.ang, 40.5k 3) com.zzy.vpnservicedemo, 36 4) com.example.android.toyvpn, 18 5) com.moduscreate.vpn.study, 9 6) app.rdtunnel.pro, 100k+ 7) com.buzz.vpn, 617 8) com.nordvpn.android, 50M+
9) com.fast.free.unblock.secure.vpn, RMP21 10) free.vpn.unblock.proxy.turbovpn, 100M+ 11) com.jrzheng.supervpnfree, RMP 12) com.cloudflare.onedotonedotonedotone, RMP 13) com.fast.free.unblock.thunder.vpn, RMP 14) free.vpn.unblock.proxy.turbovpn.lite, 50M+ 15) octohide.vpn, 10M+ 16) com.expressvpn.vpn, 10M+ 21. RMP: Removed From Playstore
TABLE 5: Traffic detection results on SOTA-I [72]. FPR/FNR (%): Shows wrong prediction percentage. Covert Channel Tor VPN Proxy TorPT I2P
Flows 62 4460 908 29 9
Benign APKs C-behav-dt C-cert-rf FPR (%) FPR (%) 3.22 0.00 2.06 0.00 1.76 0.00 0.00 0.00 11.11 0.00
C-cert-dt FPR (%) 0.00 0.00 0.00 0.00 0.00
Flows 58 642 1687 568 2623
Malware APKs C-behav-dt C-cert-rf FNR (%) FNR (%) 94.82 100.0 96.72 100.0 97.09 100.0 97.88 100.0 95.50 100.0
C-cert-dt FNR (%) 100.0 100.0 100.0 100.0 100.0
Figure 19: Yearwise percentage of statically validated malware APKs. Figure 17: Detected VPN Protocols in network flows and their counts.
Figure 20: Yearwise success rate of dynamic analysis.
Figure 18: Presence of CC services running on (unknown protocol) IPs found via whatismyip.com. TABLE 6: Matching proxy APK codes to their original APKs. Proxy Groups com.giamping.socks5, net.typeblog.socks, com.didsoft.myiphide, io.oxylabs.proxymanager com.purevpn.proxy org.apache.http libv2ray, okhttp3.internal io.netty.handler org.littleshoot com.huawei.hms
Matched APKs 0
Total APKs 0
0 684 879 90 0 26
1 78562 143519 1010 21 3150
17) com.free.vpn.super.hotspot.open, 100M+ 18) ch.protonvpn.android, 50M+ 19) com.windscribe.vpn, 10M+ 20) com.pawxy.browser, 1M+ 21) com.surfshark, 10M+ 22) com.security.xvpn.z35kb, RMP 23) de.blinkt.openvpn, 10M+ 24) net.ivpn.client, 500k+ 25) com.wireguard.android, 5M+
26) se.leap.riseupvpn, 500k+ 27) com.zerotier.one, 1M+ 28) io.nekohasekai.sfa, 100k+ 29) com.psiphon3, 50M+ 30) kittoku.osc, 100k+ 31) org.calyxinstitute.vpn, NF22 32) free.vpn.unblock.proxy.opensource, NF 33) com.avg.android.vpn, 5M+ 34) com.gaditek.purevpnics, 5M+ 35) tech.hexa, 5M+ 36) com.symantec.securewifi, 10M+ 37) com.softek.xnordvpnpro, 1k+ 38) com.lazycoder.cakevpn, 387 39) com.vpn.powervpn2, 10M+ 40) com.cybernetvpn.cybernetvpn, 34 41) com.frogobox.viprox, 21 42) asia.buzz.freevpn, 500k+ 43) com.gaditek.purevpnics, 5M+ 44) com.proxidize.legacy.android, 306 45) com.k3.k3pler, NF 46) com.vesvault.vesmail, 11 47) com.ashrafi.webi, 27 48) com.speedy.vpn, 50M+ 49) free.vpn.unblock.proxy.vpn.master.pro, 100M+
A.10. List of Proxy Packages & Corresponding APK Downloads 1) libv2ray, 100k+ 22. NF: Not Found
9) io.oxylabs.proxy, 100k+ 10) io.oxylabs.proxymanager, NF 11) org.apache.http, RMP 12) com.didsoft.myiphide, 500k+ 13) net.typeblog.socks, 1M+ 14) com.huawei.hms.ads.identifier, RMP 15) com.gorillasoftware.everyproxy.service.http, 1M+
A.11. Frequency of VPN and Proxy packages Figure 21: Top 10 permissions used by malware APKs.
Figure 22: Malware IP connections across the globe.
We present the count of packages in statically validated APKs with the help of Figure 23. We list the corresponding package names as follows For VPN - com.qihoo.appstore.installse curity.vpn.LocalVPNService,de.blinkt.op envpn.core.OpenVPNService,org.strongswa n.android.logic.CharonVpnService,com.so gou.androidtool.service.SgToolVpnServic e,net.openvpn.openvpn.OpenVPNService,co m.anchorfree.vpnsdk.vpnservice.AFVpnSer vice,com.tencent.pangu.utils.vpn.LocalV PNService,org.bitvise.SSHTunnelService, unified.vpn.sdk.AFVpnService,com.wiregu ard.android.backend.GoBackend$VpnServic e,com.quickbird.mini.vpn.vpn.LocalVpnSe rvice,com.apld.av.vs,com.qihoo360.mobil esafe.vpn.VpnCoreService,com.v2ray.ang. service.V2RayVpnService,com.anchorfree. hydrasdk.vpnservice.AFVpnService,spt.w0 pw0p.vpnlib.core.OpenVPNServicecom.tech nore.tunnel.service.OpenVPNService,eu.f aircode.netguard.ServiceSinkhole,com.sl ipkprojects.ultrasshservice.tunnel.vpn. TunnelVpnService,org.hola.vpn_svc For proxy - okhttp3.internal.proxy,org.a pache.http,com.huawei.hms.ads.identifie r,io.netty.handler.proxy,libv2ray,org.l ittleshoot.proxy.impl,net.typeblog.sock s,com.didsoft.myiphide,com.giamping.soc ks5,com.purevpn.proxy.core
A.12. Implementation Details
Figure 23: Frequency of VPN (only top-20) and proxy packages in validated APKs. 2) de.blinkt.openvpn, 10M+ 3) com.giamping.socks5, 100k+ 4) io.netty.handler.proxy, 1M+ 5) org.littleshoot.proxy.impl, 1M+ 6) com.purevpn.proxy.core, RMP 7) com.purevpn.proxy, RMP 8) okhttp3.internal.connection, NF
We used machines running Ubuntu Linux, having atleast 16GB RAM and 6C/12T CPUs. We used VirusTotal APIv3.0 to download VT reports and used API keys provided by AndroZoo to download APKs. In total, we downloaded 3.6M VT reports and 288k APKs which amounts to ≈ 100GB and ≈ 7TB, respectively. For malware labeling, we used AVClass v2.8.10. For static analysis, we used Androguard v3.4.0a1. For dynamic analysis, we used Google Pixel-5 phones. For packet analysis we used nDPI v4.12.0, dpkt v1.9.8 and Zeek v6.0.4.
A.13. APK Instrumentation and Execution To verify the usage of flagged libraries in VPN and proxy categories, we instrumented and executed a few flagged APKs and observed their runtime logcat results. We instrumented 30 flagged APKs from the proxy category and 20 flagged APKs from the VPN
category using AndroLog tool [103]. Upon inspecting the logs, we observed that various library functions are being called at runtime. For example, in a VPN APK (208e8183dd41a02c5c0d2cc1b3154fe2dcaca 400522ba5a178e2814cc7862124) flagged with unified.vpn.sdk.AFVpnService, it populated it’s class objects, and called methods related to the VPN connection initiation e.g., android.net.VpnService: void onCreate().