Automatic Investigation Framework for Android Malware Cyber-Infrastructures

06/23/2018 ∙ by ElMouatez Billah Karbab, et al. ∙ Concordia University 0

The popularity of Android system, not only in the handset devices but also in IoT devices, makes it a very attractive destination for malware. Indeed, malware is expanding at a similar rate targeting such devices that rely, in most cases, on Internet to work properly. The state-of-the-art malware mitigation solutions mainly focus on the detection of the actual malicious Android apps using dy- namic and static analyses features to distinguish malicious apps from benign ones. However, there is a small coverage for the In- ternet/network dimension of the Android malicious apps. In this paper, we present ToGather, an automatic investigation framework that takes the Android malware samples, as input, and produces a situation awareness about the malicious cyber infrastructure of these samples families. ToGather leverages the state-of-the-art graph theory techniques to generate an actionable and granular intelligence to mitigate the threat imposed by the malicious Internet activity of the Android malware apps. We experiment ToGather on real malware samples from various Android families, and the obtained results are interesting and very promising



There are no comments yet.


page 5

page 9

page 10

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1. Introduction

Mobile devices are important gadgets in our lives. Nowadays, mobile systems, especially Android, and their applications (apps) dominate most of our daily economic and social interactions. Android has the biggest share in the mobile computing industry (idc2016smartphone, ) due to its open-source distribution and sophistication. Besides, it became not only the dominant platform for mobile phones and tablets, but is also gaining increasing attention and penetration in the realm of Internet of Things (IoT) (android_wear, ; brillokey, ). The ubiquitous nature and popularity of Android OS made it the first target of malicious threats in mobile computing platforms (GData_2015_stats, ). Indeed, malware apps are not only targeting conventional devices such as phones and tablets, but also more critical systems such as home IoT devices. The latter could allow the adversary to achieve more severe attacks, which could inflict physical damages (android_auto, ) as the attacker could gain access to physical system controllers of cars, air conditioning systems, refrigerators, etc.

Mobile and IoT devices are more critical than personal computers in many ways: (i) In contrast with personal computers, they are equipped with sophisticated sensors, from cameras and microphone to gyroscope and GPS. These various sensors open a whole new world of applications for end-users. However, they also unleash unprecedented potential cyber-threats that could be committed by adversaries who gain access to these resources through Android malware apps. (ii) Thin devices (smart handsets and IoT devices) have limited resources in terms of computation, energy power, and network bandwidth compared to PCs. This makes extensive security analyses very expensive, if not impossible in some cases, to track maliciousness indicators whether dynamic or static in nature. Therefore, the adversary needs less sophisticated malicious apps compared to PC ones to achieve the attack. (iii) A thin device could inflict more damage than a PC due to its high portability, and hence could infect/damage a large number of networks (e.g., work, home, restaurant, airport). Indeed, infected thin devices could play the role of a payload transporter to harm other systems and networks. (iv) In terms of deployment, the number of thin devices (including Android ones) is by far larger than the number of PCs. Therefore, an adversary that leverages malicious apps could infect more IoT devices than PCs. The attacker could infect and control (tens of) thousands of PCs and use them as her/his malicious cyber-infrastructure. Nowadays, malicious cyber-infrastructures could reach (tens of) millions of devices if we include devices in TVs, smart watches, connected cars, etc. (v) Finally, the centralized mechanism through which Android apps are distributed using App repositories (google_play, ) allows for the distribution of malicious apps that bypass vetting systems and hence be available on a huge number of end-user devices.

The aforementioned factors highlight the urgent need to design and implement new methodologies, techniques and tools to mitigate cyber-threats against Android mobile and IoT devices, especially that we are witnessing a convergence between Android and IoT devices. IoT devices could run Android OS or a lightweight version of it. In this context, Google proposes AndroidThing (brillokey, ), an Android-based IoT operating system. On the other hand, Android may animate other IoT devices that control systems such as smart homes or smart buildings. To mitigate these cyber-threats (GData_2015_stats, ), we need to have an accurate situational awareness of the threat landscape. The state-of-the-art Android security solutions mainly concentrate on: (i) Static analysis (arp2014drebin, ; karbab2016dna, ; feng2014apposcopy, ; yang2014apklancet, ), where the emphasis is on the actual Android malware file (Android Packaging APK): Here, the community tends to fingerprint Android malware using approximate fingerprints or learning models that leverage statistical features engineered from the static content. Static analysis is not generally effective in the presence of obfuscation techniques. (ii) Dynamic analysis (canfora2016acquiring, ; spreitzenbarth2013mobile, ; ali2016aspectdroid, ; zhang2013vetting, ) based on the reports generated after executing the actual malware in a sandboxing system: The security analysis leverages these reports to discover and fingerprint malicious behaviours of Android malware samples. The dynamic analysis tends to be more resilient against obfuscation. However, it is more time consuming compared to static analysis. (iii) Hybrid approaches (yuan2014droid, ; grace2012riskranker, ; bhandari2015draco, ; vidas2014a5, ) leverage both static and dynamic analyses techniques to achieve a higher detection performance.

However, current Android malware solutions do not address the network dimension of mobile and IoT security. Furthermore, a common important characteristic between IoT devices and smart handsets is Internet access. Therefore, having malicious apps could allow the adversary to connect to infected devices at any time. Besides, Internet access is far from being a suspicious permission in Android vetting system. More precisely, the gap resides in the lack of situational awareness about malicious cyber-infrastructures that relate Android malware apps and their families. By cyber-infrastructure, we mean all the domains and IP addresses, i.e., the network information that is used by the adversary to control, download, upload, or at least, collect sensitive information through malicious apps that are already installed on infected Android devices (e.g. smart handset and IoT devices). Solutions, such as (boukhtouta2015graph, ) (nadji2013connected, ), address malicious infrastructures in general focusing on malware samples and their families but without a special emphasis on Android-based platforms. In other words, there is a need for online solutions that leverage the large number of detected Android malware samples from different families. The latter should be the starting point of security solutions to achieve a situational awareness about malicious cyber-infrastructures underlying daily Android malware at different granularity levels. In other terms, the intention is to achieve a better understanding and focus on the malicious cyber-infrastructures underlying one Android malware sample, one malware family of samples, or several families at the same time.

In this respect, we propose ToGather, an automatic investigation framework for Android malware cyber infrastructures. ToGather framework is a set of techniques and tools together with security feeds to automatically achieve a situational awareness about Android malware. Actually, ToGather characterizes the cyber-infrastructure of a given malware sample, a set of samples, family or families as a multipartite graph that relates malware samples and the corresponding network footprint in terms of IPs and domains. ToGather goes even a step further by dividing this cyber-infrastructure into sub-infrastructure components based on the connectivity between the nodes. The result is in fact multiple network communities representing many sub-cyber-infrastructures that are related to the Android malware sample or family. To this end, ToGather leverages the enormous amount of cyber-threat intelligence that is derived from various sources such as spam, Windows malware, darknet, and passive DNS to ascribe cyber-threats to the corresponding cyber-infrastructure. Accordingly, the input of ToGather framework is made of malware samples, and the output is networks of cyber-infrastructures together with their network footprint, which would give the security practitioner an overview of Android malware cyber-activities on the Internet.

The process of ToGather framework starts by taking, as input, Android malware samples. First, we extract network information from these malicious apps. For this purpose, we use a hybrid approach, where both static and dynamic analyses are applied on malware. The resulting network information (IPs and domain names) of the malware sample represents the malicious nodes of its malicious cyber-infrastructure. However, the network information could be very noisy, as it might include several benign domain names of well-known sites, and the same applies to IP addresses. Hence, ToGather filters these entries through whitelisting in order to remove such IPs and domain names. Afterwards, ToGather correlates the network footprint with a passive DNS database to enrich the network information in two ways: (i) Get the IP addresses resolved from the current domain names list. (ii) Get the domain names that point to the collected IP addresses. The result is an enriched network information that has more coverage in terms of malicious cyber activity of the input malware samples. However, this information could be richer if we structure it; hence, ToGather builds from the network information a multi-partite graph connecting the hashes of malware samples to the corresponding IP addresses and domain names. The heterogeneous graph is used to derive abstract homogenous graphs where the emphasis is put on the network information while abstracting away from the malware hashes (since they have the same family in a typical use case). The homogeneous graphs, namely threat networks, represent cyber-infrastructures of Android malware. ToGather applies a highly scalable community detection algorithm (fast08blondel, ) on this threat network to extract sub-threat networks with high connectivity aiming to give a more granular view to the security practitioner. Besides, we apply page ranking algorithm on these sub-cyber-infrastructures in order to rank the nodes (information network) according to their importance in terms of connectivity among sub-graphs. This indeed results in actionable intelligence that could be leveraged for instance to take-down operations. Finally, for each sub-threat network, we correlate the resulting cyber-infrastructure with well-known malicious information networks to label the underlying malicious activities. ToGather framework automates the previous steps to help security analysts achieve a great deal of situational awareness on Android malware and its activities on the Internet. As such, our contribution is essentially the framework as a whole and not only the components.

The main contributions of this paper are:


We design and implement ToGather, a simple, yet practical framework to generate a granular situational awareness report on the malicious cyber infrastructures underlying Android malware.


We propose a correlation mechanism with multiple cyber-threat intelligence feeds, which enrich, not only the resulting malicious cyber-infrastructure intelligence, but also the labeling of the tracked malicious activities.


We evaluate ToGather framework on real Android malware samples from Drebin malware dataset. The evaluation shows promising and interesting findings.

2. Overview

2.1. Threat Model

We position ToGather as a detector of malicious cyber-infrastructures of Android malware. It is designed to uncover threat networks and the sub-networks from a seed of Android malware samples. However, malware detection is described in existing proposals (arp2014drebin, ; karbab2016dna, ; canfora2016acquiring, ; spreitzenbarth2013mobile, ; yuan2014droid, ; grace2012riskranker, ) and is out of the scope of this paper. ToGather does not guarantee zero false-positives due to the large number of benign domain names and IP addresses that might not be filtered out with ToGather whitelists. ToGather is very resilient to obfuscation during the extraction of the network information from Android malware because it applies both static and dynamic analyses. Hence, if the static content is heavily obfuscated, ToGather is still able to collect IP addresses and domain names from dynamic analysis reports.

2.2. Usage Scenarios

ToGather is designed to be practical and efficient in the hands of security practitioners.

  • Security analyst uses ToGather framework as an investigation tool to minimize the efforts of generating threat networks for a given Android malware family. The analyst leverages the IP addresses and domain names ordered by their importance in the generated threat network to prioritize the takedown and mitigation operations.

  • ToGather acts as a monitoring system. It analyzes a malware feed of Android malware family (e.g., new samples on a daily basis) to generate a snapshot for threat network and uncover the malicious activities (spam, phishing, scanning, and others). Periodic reporting gives insights into the cyber evolution and the malicious behaviors of a given malware family over time.

  • ToGather measures the Android malware activity on top of cloud vendors by reporting that a given Android malware family is using a specific cloud vendor infrastructure for its malicious activity during a period of time.

3. Methodology

In this section, we present the overall workflow of ToGather framework, as shown in Figure 1, starting from the Android malware samples ending with the produced relevant security intelligence:

Figure 1. Approach Overview

1) The first step in ToGather framework consists of deriving network information from Android samples in a given window analysis (e.g., day, week, month) whether they are from the same malware family or not. However, we consider one malware family as a typical use-case of ToGather, as presented in the evaluation section. ToGather conducts dynamic and static analyses where each analysis produces a report for each Android malware sample. Therefore, a given malware has two reports from dynamic and static analyses. Leveraging both analysis types enhances the resiliency of ToGather against common obfuscation techniques. The latter aims to hide relevant information about malicious activities such as domain names and IP addresses (network information). Afterwards, ToGather extracts network information strings from the analysis reports. At this point, we apply a simple text pattern search to find IP addresses and domain names. In static analysis, we mainly concentrate on the Dalvik compiled code (classes.dex) for the extraction. We collect network information more efficiently from dynamic analysis reports since they are more structured and have labeled fields.

2) Next, we filter the extracted network identifiers from noise information such as non-routed IP addresses. Also, we filter domain names and URLs that use Unicode characters. For the current ToGather implementation, we do not consider domain names and URLs written in other languages such as Japanese or Arabic. In the case of URL links, we keep only domains. To this end, we have a set of valid IP addresses and domain names found in Android malware. It is important to notice here that each network information is tagged by the underlying malware hash and this tag will be kept during all the workflow steps of ToGather. To minimize false positives, ToGather applies whitelisting mechanisms. For domain names, ToGather leverages the complete Alexa (alexatop_web, ) and Quantcast (quantcast_web, ) (more than one million domain name). However, the number of white domain names is a hyper-parameter in ToGather that we could use to control the amount of false positives. In the case of IP addresses, we leverage a set of public white IPs such as Google DNS servers and other ones (tracemyip_web, ). It is important to stress that ToGather considers public cloud vendor IPs and domain names as a whitelist. The aim is to observe and then gain insight into the use the cloud infrastructure by Android malware. This idea originates from the observation that Android malicious apps (and malware in general) make more use of the cloud as a low-cost infrastructure for their malicious activity.

3) In this step, we propose a mechanism to enhance and enrich the malicious network information to cover related domains and IPs. In essence, ToGather aims at answering the following questions: (i) What are the IP addresses of current malicious domains? Here we investigate the IP addresses of server machines that host malicious activities. The latter are most likely related to the analyzed Android malware. (ii) What are the domain names pointing to the current malicious IP addresses? The intuition is that a malicious server machine with a given IP address could host various malicious contents and the adversary could use multiple domains pointing to such contents. To answer this question, ToGather has a module to enrich network information by using passive DNS replication. The latter is a technology that builds zones replicate without the cooperation from zone administrators, based on captured name server responses, as presented in Section 6.1. We use the network information, whether IP addresses or domains, as parameters to two functions applied on a passive DNS database. The goal of the function is to enrich the list of domains and IP addresses that could be part of the adversary threat network. The enrichment services are: (i) GetIP(Domain): This function takes a domain as a parameter to query passive DNS database. The result is all IP addresses the domain points to. (ii) GetDomain(IP): This function gets all the domains that resolves to the IP address given as a parameter.

We consider passive DNS correlation for two reasons: (i) A small number of Android malware samples generally yields limited network information. (ii) Security practitioners aim at having a more comprehensive situational awareness about malware Internet activity. As such, they would like to consider all related IPs and domain names. The result of the correlation is a set of IP addresses and domains enriched using passive DNS, related to Android malware apps. The correlation results could, however, overwhelm the investigation process. Passive DNS correlation is therefore optional if we have a big number of samples from a given Android family. ToGather applies network information enrichment using the passive DNS replication. The correlation with passive DNS could produce some known benign entries. For this reason, we filter the likely harmless network information by matching the newly found ones against top Alexa (alexatop_web, ) and Quantcast (quantcast_web, ) domain names and known public IP addresses (amazonip_web, ).

5) At this stage, we have a set of network information tagged by malware hashes. To extract relevant and actionable intelligence, ToGather aggregates all the previous records into a heterogeneous network with different types of nodes: malware hashes, IP addresses and domain names. We consider the heterogeneous network that is extracted from a given Android malware family as the malicious activity map of that family on the Internet. We call such a heterogenous network, a threat network. Furthermore, ToGather produces homogenous networks by executing multiple projections according to the node type (IP address or domain name). For example, in the IP projection, the projection of a malware hash connecting two IP addresses would be only the two IPs connecting to each other. Therefore, ToGather produces three homogeneous graphs, one only considers IP addresses connections, and the other only considers domain names connections. Finally, we consider a threat network with IPs and domains as one type network information. The goal of homogenizing the connection network is to apply graph analyses that need the graph homogeneity (i.e., IP threat network), domain threat network, and network information threat network.

Figure 2. Graph Analysis Overview

6) Further, ToGather aims at producing more granular graphs (see Figure 2) from the generated threat networks derived in the previous step. In this respect, ToGather checks the possibility of community identification in these threat networks based on the connectivity between nodes. The higher is the connectivity between the nodes in a particular area of the network, the more is the possibility to have a malicious community in such area. For community detection (Section 4), we adopt a highly scalable algorithm (fast08blondel, ) to enhance ToGather community detection module. The intuition behind using the community concept is: (i) Considering ToGather typical usage scenario, where we enter Android malicious apps from the same family, the community could define different threat networks that are related to the malicious activities. In other words, either one adversary is using these threat networks as backups or we have instead multiple adversaries. In the case of Android malware, the second hypothesis is more plausible because of the cheap repackaging of existing malware samples to suit the need of the perpetrator. (ii) In case ToGather receives Android malware from different families, the communities could be interpreted as the threat networks of different Android malware families to focus on the relation between them. The output of this step is a set of threat networks related to IPs, domains, and network information and their communities (sub-threat networks).

7) To produce actionable cyber-threat intelligence, we leverage Google page ranking algorithm (Section 5) to produce ranking scores for critical nodes of a given (sub) threat network. Consequently, the investigator would have some priority list when it comes to mitigation or take down of nodes that are associated with a malicious cyber-infrastructure. As a result, ToGather produces each (sub) threat network of the Android malware family together with the ranking of each node. Because ToGather generates multiple homogeneous graphs based on the node type (IP, domain, network information), it produces different ranking lists based on the node type. Therefore, the security practitioner will have the opportunity of selecting the node type when executing the mitigation or the take down to protect his system. In such case, an IP node could be more suitable as it could be blacklisted for instance. Also, it is important to mention that it is expensive for the adversary to get new IP addresses. In contrast, domain names could be frequently changed due to their affordability.

8) We do not focus only on Android malware. Instead, we aim at gaining insights into the shared network IP and domains with other platform malware families. Indeed, the adversary tends to have many malicious weapons in several operating systems to achieve the maximum coverage. Therefore, similarly to the first step, we conduct dynamic and static analyses on Windows and Linux malware samples to extract the corresponding network information. The same step is applied to this network information. Afterwards, we correlate the Android network information with the non-Android malware information to discover another dimension of the adversary network. The result will be all the IP addresses and the domains of Android malware in addition to all network records of a given non-Android malware family if they share some network information. It is important to notice that the information networks of non-Android malware are also labeled by malware families. Therefore, the result of this step is the previous (sub) threat networks tagged by Android malware family in addition to tags of other platform malware. So, the security analyst would have a clearer view on the Android cross-platform malicious activity.

9) In this final step of ToGather workflow, we leverage another cyber-threat source, namely sub-threat networks, to label malicious activities that are committed by the produced communities. Specifically, we leverage network information that is collected from different security data. The current ToGather implementation includes the correlation with spam emails, reconnaissance traces and phishing URLs. Therefore, the investigator will not only have the cyber-infrastructure of the Android malicious family but also if it is part of other cyber malicious activities that are conducted by the infrastructure.

We consider ToGather

as an active service that receives at every epoch time (day, week, month) Android malware with its corresponding family (the typical use case) and produces valuable intelligence about this malware family.

4. Threat Communities Detection

A scalable community detection algorithm is essential to extract communities from the threat network. For this reason, we empower ToGather with the Fast Unfolding Community Detection algorithm (fast08blondel, ), which can scale to billions of network links. The algorithm achieves excellent results by measuring the modularity of communities. The latter is a scalar value that measures the density of edges inside a given community compared to the edges between communities. The algorithm uses an approximation of the modularity since finding the exact value is computationally hard (fast08blondel, ). Our main reason to choose the algorithm proposed in (fast08blondel, ) is its scalability. As depicted in Figure 3, we apply the community detection on a million-node graph with a medium density (probability of node A is another node B), which we believe has a similar density to the threat network generated from Android malware samples. For the sake of completeness, we perform the same experiment on graphs with a different probability . As presented in Figure 4(c), we are able to detect communities in -node graphs with ultra density (unrealistic) in a relatively small (compared to the time dedicated to the investigation) amount of time ().

Figure 3. Scalability of the Community Detection
(a) Medium
(b) High
(c) Very High
(d) Ultra High
Figure 4. Graph Density Versus Scalability

The previous algorithm requires a homogeneous network, as input, to work correctly. In our case, the threat network generated from the network information is a heterogeneous network because it contains two main node types: (i) The malware sample identifier, which is the cryptographic hash of the malware sample. (ii) The network information: the domain names and the IPv4 addresses. In the current implementation, we do not consider IPv6 addresses and domain names in other languages. Also, we apply the projection on the first heterogeneous network to generate homogeneous graphs. To do so, ToGather makes the graph projection by abstracting away from the malware identifier and only takes the network information, i.e., if the malware identifier connects to two IPs, the projection would produce only the two IPs connecting to each other. To this end, we get different projection results based on the node abstraction: (i) General threat network contains both IP addresses and domain names. (ii) IP threat network contains only IP addresses. (iii) Domains threat network contains only domain names.

Furthermore, ToGather could mine sub-threat networks that have highly connected nodes compared to the rest of the cyber-threat network. The intuition here is that each sub-threat network could be a different malicious infrastructure that is used by an adversary. The security practitioner could automatically segregate possible cyber-infrastructures that could lead to different attacks even if we use only one Android malware family. To achieve such scenario, we apply the previous community detection algorithm on the different threat network to check for possible sub-graphs. Also, ToGather filters nodes (IPs, domains) with weak links to others nodes, as we interpret them as false positives (leaves or parts of tiny sub-graphs).

5. Actions Prioritization

From the community detection, ToGather checks if there is possible sub-graphs in the threat networks based on node connectivity. Even though the sub threat networks zoom into malicious cyber-infrastructures of a given Android malware family, the security practitioner could not mitigate against the whole threat network at once. For this reason, ToGather proposes an action priority system. The latter takes the IP, domain or both, and threat network and produces an action priority list based the maliciousness of each node. By leveraging the graph structure of the threat network, we measure the maliciousness of a given node by its degree, meaning, the number of edges that relate it to other nodes. From a security point of view, the more connections an IP or domain has, the more it is important for a malicious cyber-infrastructure. Therefore, our goal is to build a priority list sorted by the damage, an IP or a domain, which can inflict in terms of malicious activity. The importance of nodes in a network graph is known as node’s centrality. The latter represents a real-valued function produced to provide a ranking, which identifies the most relevant nodes ((borgatti2005centrality, )). For this purpose, some algorithms have been defined, such as Hypertext Induced Topic Search (HITS) algorithm ((kleinberg1999authoritative, )) and Google’s PageRank algorithm ((brin1998anatomy, )). In our approach, we adopt Google’s PageRank algorithm due to its efficiency, feasibility, less query time cost, and less susceptibility to localized links ((nidhi2012comparative, )). In the following, we briefly introduce the PageRank algorithm and the random surfer model.

5.1. PageRank Algorithm

Definition 5.1 ().

(PageRank). Let be the set of vertices that link to a vertex and let be the out-degree centrality of a vertex . The PageRank of a vertex , denoted by , is provided in Eq. :


The constant is called damping factor, assumed to be set to (brin1998anatomy, ). Eq. produces one equation per node with an equal number of unknown values. The PageRank algorithm tries to find out iteratively different PageRank values, which sum up to 1 (). The authors of the PageRank algorithm considers the use case of web surfing, where the user starts from a web page and randomly moves to another one through a web link. If the web surfer is on page with a probability or a damping factor , then the probability to change page is . The user could follow the links and teleport to a random web page in with probability. The described surfing model is a stochastic process, and is a stochastic transition matrix, where node ranking values are computed as presented in Eq. :


The stochastic matrix

is defined as follows:

if a vertex is linked to

The notation

stands for a vector where its

element is (PageRank of ). The notation stands for a vector having all elements equal to . The computation of PageRank values is done iteratively by defining a convergence stopping criterion . At each computation step , a new vector is generated based on previous vector values . The algorithm stops computing values when the condition is satisfied.

6. Security Correlation

6.1. Network Enrichment Using Passive DNS

Passive DNS (weimer2005passive, ) replication is the process of capturing live DNS queries and/or their responses, and using this data to build partial replicas of as many DNS zones as possible. Passive DNS aims to make replication of the domain zones without the collaboration of zone administrators. A DNS sensor is used to capture the inter-server DNS communications. Afterwards, the records of passive DNS are stored in a database where they can be queried. We can benefit from the passive DNS database in many ways. For instance, we can know the history of a domain name as well as the IP addresses it is/was pointing to. We can also find what domain names are hosted on a given name server or what domains are/(have been) pointing to a given IP address. There are a lot of use cases of passive DNS for security purposes (e.g., mapping criminal cyber-infrastructure (antonakakis2010building, ), tracking spam campaigns, tracking malware command and control systems, detection of fast-flux networks, security monitoring of a given cyber-infrastructure and botnet detection). In our context, we correlated ToGather with a passive DNS database (Billion record) to enrich the investigation of Android malware by: (i) Finding suspicious domains that are pointing to a malicious IP address extracted from the analysis of a malware sample. (ii) Finding suspicious IP addresses that are resolved from a malicious domain that is extracted from the analysis of malware sample. (iii) Measuring the maliciousness magnitude of an IP address: a server identified by a malicious IP address that hosts many malicious activities. We could measure the maliciousness by counting the number of domains that resolve to this malicious IP address. Typically, these domains could be related to different malicious activities or a single one. (iv) Filtering outdated domain names: The passive DNS query generally returns timestamp information. ToGather could leverage the timestamps to filter out old domain names that are no longer active.

Figure 5. Threat Network With&(out) Correlation

We consider passive DNS correlation as an optional component in ToGather workflow for two reasons. First, passive DNS could be missing to reproduce ToGather framework, since the security practitioner may not have access to such database. Second, the corpus of Android malware samples is enormous, and there are new feeds of malware samples every day. Hence, such large number of samples could fill the gap of passive DNS correlation due to the amount of the extracted network information. For example, as presented in Figure 5, the threat network generated from three malware samples could be enhanced by the correlation with passive DNS.

6.2. Threat Network Tagging

ToGather produces, from Android malware samples, a threat network that summarizes their malicious activities. Afterwards, ToGather detects and produces threat sub-networks if any. Besides, it helps prioritizing the actions to be taken to mitigate this threat using the PageRank algorithm. In this section, we go a step further towards the automatic investigation by leveraging other security feeds. Specifically, we aim at correlating threat networks with spam intelligence, reconnaissance intelligence, etc. The objective is to give a multi-dimensional view about the malicious activities that are related to the investigated Android malware family. Moreover, ToGather considers the correlation with network information from other platform malware; in the current setup, we correlate with PC malware from different operating systems.

PC Malware:

The adversary tends to have different malware samples in their arsenals to achieve their goal. Besides, different types of malware could be used to cover distinct platforms. The used malware samples run on many platforms, but they might share the elements of the same cyber-infrastructure run by the attacker. Therefore, finding other platform malware that share a similar threat network with a given Android malware sample, could help discovering other malware that is in the attackers’ cyber-arsenals. Considering the previous case, ToGather tags every produced threat network by leveraging a database of network information extracted from PC malware VirusShare (virusshare, ). The malware database is continuously updated. The obtained information is identified by the malware hash and its malware family. The latter helps identifying PC malware (and their families) that share network information with the Android threat network.


ToGather takes advantage of a spam database ( Million record) to report the relationship between spamming campaigns and a given threat network. This information is precious for security analysts who are tracking spam campaigns.


Similarly to the spamming activity, we consider the phishing activity in ToGather tagging. Phishing activities aim at stealing sensitive information using fake web pages that are similar to known trusted ones. Typically, the attacker spread phishing sites using malicious URLs. We extract only the domain name and store it in a phishing database ( Million record).


Probing (panjwani2015experimental, ) is the activity of scanning networks over the Internet. The aim is to find vulnerable services. Probing is a significant concern in cyber-security because 50% of cyber-attacks are preceded by network scanning activity (panjwani2015experimental, ). For this reason, ToGather considers tags of the threat network nodes if they are part of a probing activity. This pre-supposes the availability of a probing database ( Million record) that contains IP addresses that have been part of scanning activities within the same epoch. Probing could be derived from darknet traffic and the probing IP addresses could be persisted in a probing database.

7. Experimental Results

In this section, we present the evaluation results of our proposed system. The evaluation’s goal is to assess the effectiveness of ToGather framework on giving a situational awareness from a set of Android malware samples. In our experimentation, we consider two cases of the entered malware samples: (a) The samples belong to the same Android malware family; here we look at the threat network of the given family and its sub ones. (b) The samples belong to different Android malware families; here we investigate the relation between the various families of Drebin dataset and how the threat network of the families could be distinguishable from other ones. Notice that the network information will be hidden in the result due the sensibility and confidentiality of this information (i.e., domains and IP addresses). Instead, we focus on the cyber-infrastructure of the malware samples, i.e., how the sub-threat networks could be apparent in the global threat network of Android malware family. Finally, we show the tagging result of the resulting threat network.

7.1. Android Malawre Dataset

In the evaluation, we use a real Android malware dataset from Drebin (arp2014drebin, ), a known dataset that contains samples labeled with their families. Drebin dataset (Drebin_Dataset, ) contains labeled malware samples from families (Drebin_Dataset, )., as shown in Table 1.

It is important to stress that Drebin contains all the samples of Genome dataset (Android_Malware, ). As a ground truth for the malware labeling, we take the label provided by Drebin since there are some differences between Genome and Drebin dataset labeling. For example, Genome recognizes different versions of DroidKungFu malware (1, 2 and 4), where Drebin has only DroidKungFu.

Malawre Family Number of Samples
0 FakeInstaller 925
1 DroidKungFu 667
2 Plankton 625
3 Opfake 613
4 GinMaster 339
5 BaseBridge 330
6 Iconosys 152
7 Kmin 147
Table 1. Dataset Description By Malware Family

7.2. Implementation

We have implemented ToGather using Python programming language. In the static analysis, to perform reverse engineering of the Dex byte-code, we use dexdump, a tool provided with Android SDK. We extract the network information from the Dex dis-assembly using regular expressions. Beside, ToGather extracts network information from static text content in the APK file of Android malware.

Figure 6. Sandboxing with Multi-Instance System

In the dynamic analysis, a cornerstone in ToGather framework is the sandboxing system, which heavily influences the produced analysis reports. We use DroidBox (droidbox_github, ), a well-established sandboxing environment based on the Android software emulator (android_emulator, ) provided by Google Android SDK (android_sdk, ). Running the app may not lead to a sufficient coverage of the executed app. As such, to simulate the user interaction with the apps, we leverage MonkeyRunner (monkeyrunner, ), which produces random UI actions aiming for a broader execution coverage. However, this makes the app execution non-deterministic since MonkeyRunner generates random actions. Therefore, this yields different analysis reports for every execution, where the accuracy of the results may vary. To tackle this issue, we run the app in a sandboxing environment for a long time to assure the maximum of information in the resulting report. On the other hand, a long time could lead to execution bottleneck since DroidBox can only handle one app at a time. In this context, executing the dataset apps in a sandboxing environment is a computation bottleneck in ToGather. To overcome this challenge, we develop a multi-worker sandboxing environment to exploit the maximum available resources and boost the sandboxing task. as depicted in Figure 6. Finally, since the generated reports are semi-structured (JSON files), we straightforwardly extract the network information from the specific fields.

7.3. Drebin Threat Network

In this section, we present the results of applying ToGather framework on the samples of Drebin dataset with all the families. Figure 7 depicts the threat network information (domain names and IP addresses) of Drebin dataset, where each family is represented by a different color. Although the threat network is noisy, we could visually distinguish some connected communities with the same nodes’ color, i.e., the same malware family. This initial observation enhances the need for the community detection module in the ToGather framework. The community here is a set of graph nodes that are highly connected even though they share some links with external nodes. In Figure 8, we consider only the domain names; here we could distinguish more sub threat networks having nodes from the same malware family. We choose to filter all the IP addresses for Drebin dataset due to our observation during the experimentation process: (i) Some malware samples contain a significant malware number of IP addresses; exceeding, in some cases, IPs such as Plankton sample with MD5 hash 3f69836f64f956a5c00aa97bf1e04bf2. The adversary could aim to deceive the investigator by overwhelming the app with fake IP addresses along with used ones; this issue will be discussed in Section 9. (ii) A big portion of the IP addresses are part of cloud companies infrastructure; we filter most of the public ones, but there are plenty of less known infrastructures in other countries. (iii) In most cases, the adversary utilizes domains for the malicious activity due to the low cost and the flexibility compared to IP addresses. In this experimentation, we consider only the domain names, but the security analyst could include the IP addresse when needed.

Figure 7. Network Information Drebin Dataset

Using all Drebin dataset ( malware families) to produce the Threat Network is an extream use case for ToGather framework; few malware families is a typical use case when we aim to investigate the threat networks relations. However, even with all Drebin dataset, ToGather, as presented in Figure 8, shows promising results, where we could see many sub-threat networks with(out) links to other nodes. By considering only domain names in Figure 8, it is noticeable that the size of the threat network significantly decreases by removing the IP addresses; normally there are significantly more domains than IP addresses in the Android apps. However, this is due to the extream whitelisting of domains compared to IPs (more than 1 million domain) and the size of Drebin dataset. At this stage, we do not present the community detection and page ranking on the threat network; this will be conducted on a one-family use case in the next section.

Figure 8. Domain Names Drebin Dataset

ToGather leverages different malicious datasets, as previously described in Section 6.2, to tag the nodes of the produced threat network. Figure 2 depicts the diverse malicious activities of the nodes from Drebin threat network. First, the table shows the top PC malware families which have shared network information with the Drebin threat network. For families’ names, we adopt the Kaspersky malware naming as our ground truth. Besides, Figure 2 shows the percentage of each malicious type in the Drebin threat network. The result shows that of the shared nodes have a spamming activity, are related to PC malware, Scanning, and Phishing activities. Notice that the previous percentages are only from the shared nodes and not from all the threat network. Also, as we will discuss in Section 9, these results are not exhaustive because of the correlation datasets that obviously do not contain every malicious activity. We could extend the current correlation datasets to cover more suspicious activities in future work.

# Family Hits 1 Agent 111Kaspersky Naming 1268 2 VBNA 283 3 Adload 152 4 EgroupDial 121 5 TrustAsia 120 6 Vobfus 88 7 KuPlays 74 8 Pipibo 72 9 Sality 62
Table 2. Drebin Dataset Tagging Results

7.4. Family Threat Networks

In this section, we present the results of ToGather in its typical usage scenario where malware samples from the same family are analyzed. Figure 9 shows the steps of generating the threat networks from the DroidKungFu family sample. First, ToGather produces the threat network including network information collected from the DroidKungFu analysis and Passive DNS correlation, as shown in Figure 9(a). Afterward, ToGather filters the whitelist network information. The results, as in Figure 9(b), depict bright separated sub-threat networks without applying the community detection algorithm. This could be an insightful result for the security practitioner, especially that this sub-threat network contains network information exclusively from some samples. ToGather

goes a step ahead by applying both community detection (Resolution hyperparameter

) and page ranking algorithms (damping factor and stopping criterion hyperparameters) to divide the network and rank the importance of the nodes respectively. The result is multiple sub-threat networks, with high interconnection and low intra-connection, representing the cyber-infrastructures of DroidKungFu malware family.

(a) Unfiltered
(b) Filtered
(c) Divide
(d) Ranking
Figure 9. DroidKungFu Malware Threat Network

Figure 10 shows ToGather results using Android malware samples from BaseBridge family. Similarly, after the filtering operation, we could easily distinguish small sub-threat networks. In same cases, the community detection task could be optional due to the clear separation between the sub-threat networks. For instance, Figure 11 depicts the threat networks for GinMaster, Adrd, and Plankton Android malware families before and after the community detection task. Here, Adrd family clearly has multiple sub-threat networks without the need of the community detection function since it does not affect much the results. In the case of Plankton, it is necessary to detect and extract the sub-threat network.

(a) Unfiltered
(b) Filter&Divide
(c) Ranking
Figure 10. Basebrigde Malware Threat Network
(a) Ginmaster (1)
(b) Adrd (1)
(c) Plankton (1)
(d) Ginmaster (2)
(e) Adrd (2)
(f) Plankton (2)
Figure 11. Android Families From Drebin Dataset

Tables 3 and 4 show the top PC malware families and samples that share the network information with BaseBredge and DroidKungFu threat networks. An important factor in the correlation is the explainability, where we could determine which network information is shared between the Android malware and the PC malware. This could help the security investigator to track the other dimension of the adversary cyber-infrastructure.

# Sample Hits 1 ed7621ec4d 222 MD5 Hash First 10 Chars 2 2 e3bc76d14c 2 3 503902c503 1 4 bd9b87869b 1 5 8e0cf0a1ba6 1 6 f8a5cac12dc 1 7 14db95e5f6 1 8 9b5b576ef3 1 9 2ec2abc28d 1 # Family Hits 1 Agent 333Kaspersky Naming 23 2 Vobfus 21 3 EgroupDial 13 4 Badur 9 5 LMN 7 6 WBNA 4 7 Pipibo 2 8 Blocker 2 9 Virut 2
Table 3. Top PC Malware Related To BaseBridge Family

In addition to the PC malware tagging, we correlate with other cyber malicious activity datasets over the Internet. Figure 12 presents the malicious activities of DroidKungFu and BaseBridge families that are related to their threat network. Here, we found that both families could be part of a spam campaign and have some scanning activity. Notice that these results represent a fraction of the actual activity because of the limited datasets. However, the previous fraction could be a good indicator for the security practitioner in the investigation process.

# Sample Hits 1 74529155cc 444 MD5 Hash First 10 Chars 3 2 bd5a9f768cf 2 3 259a244ab1 2 4 52da75225 1 5 11786afada 1 6 ad5e6d577b 1 7 9f4215bfc3 1 8 3c76ff67d0 1 9 117f21550 1 # Family Hits 1 Agent 555Kaspersky Naming 33 2 Adload 24 3 TrustAsia 13 4 KuPlays 11 5 Pipibo 8 6 FangPlay 5 7 StartPage 4 8 Injector 4 9 Turbobit 4
Table 4. Top PC Malware Related To DroidKungFu Family
(a) BaseBridge
(b) DroidKungFu
Figure 12. Maliciousness Tagging Per Family

8. Discussion

The results in the previous section show promising insights about the underlying cyber-infrastructures of the Android malware families. The produced threat networks could show one side of the adversary infrastructure, which is the Android malware one; this side could lead to the complete threat network. Furthermore, all the previous results could be extracted automatically and periodically from a feed of Android malware samples belonging to one or various families. This requires fixing the hyperparameter related to the used algorithms, the community detection and the page ranking algorithms, as we did in our experimentation. Moreover, the number of the malware samples and their families could be a major hyperparameter that impacts the produced result. ToGather framework could tolerate having different Android malware families as presented previously, where we consider all the families of Drebin dataset ( Families). Another important parameter is the whitelisting hyperparameter, which contains the number of domains from the top Alexa & Quantcast lists. The latter could affect the result by introducing a lot of false positive domains. In our case, we consider the complete lists, which leads to very few false positives. However, this could introduce false negatives by removing a site that is malicious.

The concept of sub-threat network gives an insight on the possibility of having different threat networks, meaning multiple adversaries are reusing a family sample or one adversary uses distinct threat networks. Moreover, the sub-threat network helps the security analyst to tackle the cyber-threat sequentially, by focusing on one sub-threat network. Finally, passive DNS database has a paramount role in discovering the related domains and IPs without having all the samples of the malware family. Therefore, with a relatively small set of samples, we could discover the threat network of the family. Finally, in the current implementation, we consider only the PC malware, spamming, phishing, and scanning, but the tagging could be extended to other security feeds.

9. Limitation And Future Work

ToGather results depend mainly on the input malware samples, which could affect the result in two ways. First, the adversary could include noisy network information in the actual Android package, thus overwhelming the process of detecting the threat network. In the current ToGather setup, we consider both static and dynamic analyses to detect the network information. Afterward, we merge the result of each analysis to correlate with passive DNS and generate the threat network. This setup is venerable to such noise attack, but this could be mitigated by simply considering the intersection instead of the union of the network information analysis. Since the dynamic analysis result is more credible than the static one, the intersection of both analyses is much more credible. Also, the filtering operation could help mitigating such problem by removing possible noise that is part of the white list. To this end, ToGather adopts only static whitelisting, and we are planning to build a dynamic filtering system based on reputation similar to Notos (antonakakis2010building, ). Second, the Android malware family may rely on other means to connect the threat network by not using direct IPs or domains connection. Instead, the adversary could leverage legitimate services such as Twitter accounts to operate the malicious cyber-infrastructure. In this case, ToGather could not detect such threats since it relies mainly on network information. We consider such problem as future work, where we investigate different network information, including Twitter and IRC communication. Finally, ToGather’s current design produces a static threat network and sub-network; the time dimension is not provided. A workaround for this issue is to analyze the same malware family for different timestamps and keep the result of each timestamp. The latter could help in the study of the threat network over time. We plan to tackle this issue more rigorously in future work.

10. Related Work

Previous works on Android malware mainly concentrate the actual malware sample using two basic approaches: static and dynamic analyses. Static analysis-based approaches (arp2014drebin, ; karbab2016dna, ; feng2014apposcopy, ; karbab2016cypider, ; karbab2017android, ; karbab2018maldozer, ; yang2014apklancet, ; zhongyang2013droidalarm, ; sanz2014anomaly, )

rely on static features extracted from the app, such as requested permissions and APIs, to detect malicious apps. These methods are not resistant to obfuscation. On the other hand, dynamic analysis-based approaches

(canfora2016acquiring, ; karbab2017dysign, ; spreitzenbarth2013mobile, ; ali2016aspectdroid, ; zhang2013vetting, ; amos2013applying, ; wei2012android, ; wei2012android, ; huang2014asdroid, ) aim to identify a behavioral signature or anomaly of the running app. These methods are more resistant to obfuscation than the static ones as there are many ways to hide the malicious code, while it is difficult to hide the malicious behavior. The hybrid analysis methods (yuan2014droid, ; grace2012riskranker, ; bhandari2015draco, ; vidas2014a5, )combine between static and dynamic analyses. A significant number of papers has been recently proposed to detect repackaged apps by performing similarity analysis. The latter either identifies the apps that use the same malicious code (i.e., detection of malware families) (kim2015structural, ; ali2015opseq, ; deshotels2014droidlegacy, ; zhou2012hey, ; gascon2013structural, ; suarez2014dendroid, ; kang2015detecting, ; lin2013identifying, ; faruki2015androsimilar, ), or those that repackage the same original app (i.e., code reuse detection) (chen2015finding, ; sun2015droideagle, ; zhou2012detecting, ; hanna2012juxtapp, ; crussell2012attack, ; zhou2013fast, ; crussell2013andarwin, ). However, most of them consider only malware sample detection and not the network dimension of the Android malware samples and their families. Differently, our work is novel in the sense that it represents the Android malware family by the underlying malicious cyber-infrastructure (i.e., threat network). The most similar work to our proposal is (boukhtouta2015graph, ) (nadji2013connected, ), which studies the malicious threat networks in general. Our work is different from (boukhtouta2015graph, ) (nadji2013connected, ) by considering the Android malware sample as the seed to build the threat network. However, (boukhtouta2015graph, ) (nadji2013connected, ) deal with various sources as seeds. Besides, we propose ToGather as an online system to continuously generate the threat network of Android malware families in each epoch.

11. Conclusion

In this paper, we presented ToGather framework, a set of techniques, tools and mechanisms and security feeds bundled to automatically build a situational awareness about a given Android malware. ToGather leverages the stat-of-art of graph theory and multiple security feeds to produce insightful, granular, as well as actionable intelligence about malicious cyber-infrastructures related to the Android malware samples. We experiment ToGather on real malware from Drebin Dataset(arp2014drebin, ).


  • [1] Drebin Dataset -, 2015.
  • [2] Genome Dataset -, 2015.
  • [3] Alexa Top Sites -, 2016.
  • [4] Amazon IP Space -, 2016.
  • [5] Android Auto -, 2016.
  • [6] Android Emulator -, 2016.
  • [7] Android SDK -, 2016.
  • [8] Android Wear -, 2016.
  • [9] Brillo -, 2016.
  • [10] DroidBox -, 2016.
  • [11] G DATA Mobile Malware Report -, 2016.
  • [12] Google Play -, 2016.
  • [13] Market Share -, 2016.
  • [14] MonkeyRunner -, 2016.
  • [15] Quantcast Sites -, 2016.
  • [16] Tracemyip - Https://, 2016.
  • [17] Virusshare -, 2016.
  • [18] Aisha Ali-Gombe, Irfan Ahmed, Golden G Richard III, and Vassil Roussev. AspectDroid: Android App Analysis System. In ACM Conf. Data Appl. Secur. Priv., 2016.
  • [19] Aisha Ali-Gombe, Irfan Ahmed, Golden G Richard III, Vassil Roussev, Aisha Ali Gombe, Irfan Ahmed, Golden G Richard III, and Vassil Roussev. OpSeq: Android Malware Fingerprinting. In Proc. 5th Progr. Prot. Reverse Eng. Work., 2015.
  • [20] Brandon Amos, Hamilton Turner, and Jonathan White.

    Applying machine learning classifiers to dynamic android malware detection at scale.

    In Wirel. Commun. Mob. Comput. Conf., 2013.
  • [21] Manos Antonakakis, Roberto Perdisci, David Dagon, Wenke Lee, and Nick Feamster. Building a Dynamic Reputation System for DNS. USENIX Secur., 2010.
  • [22] Daniel Arp, Michael Spreitzenbarth, Hubner Malte, Hugo Gascon, Konrad Rieck, Malte Hubner, Hugo Gascon, and Konrad Rieck. DREBIN: Effective and Explainable Detection of Android Malware in Your Pocket. In Symp. Netw. Distrib. Syst. Secur., 2014.
  • [23] Shweta Bhandari, Rishabh Gupta, Vijay Laxmi, Manoj Singh Gaur, Akka Zemmari, and Maxim Anikeev. DRACO: DRoid analyst combo an android malware analysis framework. In Int. Conf. Secur. Inf. Networks, 2015.
  • [24] Vincent D. Blondel, Jean-Loup Guillaume, Renaud Lambiotte, and Etienne Lefebvre. Fast unfolding of communities in large networks. J. Stat. Mech. Theory Exp., 2008.
  • [25] Stephen P. Borgatti. Centrality and network flow. Soc. Networks, 27, 2005.
  • [26] Amine Boukhtouta, Djedjiga Mouheb, Mourad Debbabi, Omar Alfandi, Farkhund Iqbal, May El Barachi, and May El Barachi. Graph-theoretic characterization of cyber-threat infrastructures. Digit. Investig., 2015.
  • [27] Sergey Brin and Lawrence Page. The anatomy of a large-scale hypertextual Web search engine. Comput. Networks ISDN Syst., 1998.
  • [28] Gerardo Canfora, Eric Medvet, Francesco Mercaldo, and Corrado Aaron Visaggio. Acquiring and Analyzing App Metrics for Effective Mobile Malware Detection. In 2016 ACM Int. Work. Secur. Priv. Anal., IWSPA ’16, 2016.
  • [29] Kai Chen, Peng Wang, Yeonjoon Lee, XiaoFeng Wang, Nan Zhang, Heqing Huang, Wei Zou, and Peng Liu. Finding Unknown Malice in 10 Seconds: Mass Vetting for New Threats at the Google-Play Scale. In USENIX Secur. Symp., 2015.
  • [30] Jonathan Crussell, Clint Gibler, and Hao Chen. Attack of the clones: Detecting cloned applications on android markets. In Eur. Symp. Res. Comput. Secur. Proc. 2012.
  • [31] Jonathan Crussell, Clint Gibler, and Hao Chen. AnDarwin: Scalable Detection of Semantically Similar Android Applications. In Eur. Symp. Res. Comput. Secur. Egham, 2013.
  • [32] Luke Deshotels, Vivek Notani, and Arun Lakhotia. Droidlegacy: Automated familial classification of android malware. In Proc. ACM SIGPLAN Progr. Prot. Reverse Eng. Work., 2014.
  • [33] Parvez Faruki, Vijay Laxmi, Ammar Bharmal, M. S. Gaur, and Vijay Ganmoor. AndroSimilar: Robust signature for detecting variants of Android malware. 2015.
  • [34] Yu Feng, Saswat Anand, Isil Dillig, and Alex Aiken. Apposcopy: Semantics-based detection of android malware through static analysis. In ACM SIGSOFT Int. Symp. Found. Softw. Eng., 2014.
  • [35] Hugo Gascon, Fabian Yamaguchi, Daniel Arp, and Konrad Rieck. Structural detection of android malware using embedded call graphs. In ACM Work. Artif. Intell. Secur., 2013.
  • [36] Michael Grace, Yajin Zhou, Qiang Zhang, Shihong Zou, and Xuxian Jiang. Riskranker: scalable and accurate zero-day android malware detection. In Proc. 10th Int. Conf. Mob. Syst. Appl. Serv., 2012.
  • [37] Steve Hanna, Ling Huang, Edward XueJun Wu, Saung Li, Charles Chen, and Dawn Song. Juxtapp: A scalable system for detecting code reuse among android applications. In Detect. Intrusions Malware, Vulnerability Assess. Springer, 2012.
  • [38] Jianjun Huang, Xiangyu Zhang, Lin Tan, Peng Wang, and Bin Liang. AsDroid: Detecting stealthy behaviors in android applications by user interface and program behavior contradiction. In Proc. 36th Int. Conf. Softw. Eng., 2014.
  • [39] Hyunjae Kang, Jae-wook Jang, Aziz Mohaisen, and Huy Kang Kim. Detecting and classifying android malware using static analysis along with creator information. Int. J. Distrib. Sens. Networks, 2015.
  • [40] ElMouatez Billah Karbab, Mourad Debbabi, Saed Alrabaee, and Djedjiga Mouheb. DySign: Dynamic fingerprinting for the automatic detection of android malware. 2016 11th International Conference on Malicious and Unwanted Software, MALWARE 2016, pages 139–146, 2017.
  • [41] ElMouatez Billah Karbab, Mourad Debbabi, Abdelouahid Derhab, and Djedjiga Mouheb. Cypider: Building Community-Based Cyber-Defense Infrastructure for Android Malware Detection. In ACM Computer Security Applications Conference (ACSAC), volume 5-9-Decemb, pages 348–362. ACM, 2016.
  • [42] ElMouatez Billah Karbab, Mourad Debbabi, Abdelouahid Derhab, and Djedjiga Mouheb.

    Android Malware Detection using Deep Learning on API Method Sequences.

  • [43] ElMouatez Billah Karbab, Mourad Debbabi, Abdelouahid Derhab, and Djedjiga Mouheb. MalDozer: Automatic framework for android malware detection using deep learning. Digital Investigation, 2018.
  • [44] ElMouatez Billah Karbab, Mourad Debbabi, and Djedjiga Mouheb. Fingerprinting Android packaging: Generating DNAs for malware detection. Digit. Investig., 2016.
  • [45] Junhyoung Kim, Tae Guen Kim, and Eul Gyu Im. Structural information based malicious app similarity calculation and clustering. In Conf. Res. Adapt. Converg. Syst., 2015.
  • [46] Jon M. Kleinberg and Jon M. Authoritative sources in a hyperlinked environment. J. ACM, 1999.
  • [47] Ying-Dar Lin, Yuan-Cheng Lai, Chien-Hung Chen, and Hao-Chuan Tsai. Identifying android malicious repackaged applications by thread-grained system call sequences. Comput. Secur., 2013.
  • [48] Yacin Nadji, Manos Antonakakis, Roberto Perdisci, and Wenke Lee. Connected Colors: Unveiling the Structure of Criminal Networks. In Res. Attacks, Intrusions, Defenses 16th Int. Symp. Berlin, Heidelberg, 2013.
  • [49] Ritika Wason Nidhi Grover. Comparative Analysis Of Pagerank And HITS Algorithms. Int. J. Eng. Res. Technol., 2012.
  • [50] Susmit Panjwani, Stephanie Tan, Keith M. Jarrin, and Michel Cukier. An experimental evaluation to determine if port scans are precursors to an attack. In Proc. Int. Conf. Dependable Syst. Networks, 2005.
  • [51] Borja Sanz, Igor Santos, Xabier Ugarte-Pedrero, Carlos Laorden, Javier Nieves, and Pablo Garcia Bringas. Anomaly detection using string analysis for android malware detection. In Int. Jt. Conf. SOCO’13-CISIS’13-ICEUTE’13, 2014.
  • [52] Michael Spreitzenbarth, Felix C. Freiling, Florian Echtler, Thomas Schreck, and Johannes Hoffmann. Mobile-sandbox: having a deeper look into android applications. In Proc. 28th Annu. ACM Symp. Appl. Comput., 2013.
  • [53] Guillermo Suarez-Tangil, Juan E Tapiador, Pedro Peris-Lopez, and Jorge Blasco. Dendroid: A text mining approach to analyzing and classifying code structures in Android malware families. Expert Syst. Appl., 2014.
  • [54] Mingshen Sun, Mengmeng Li, and John C S Lui. DroidEagle: seamless detection of visually similar Android apps. In ACM Conf. Secur. Priv. Wirel. Mob. Networks, WiSec ’15, 2015.
  • [55] Timothy Vidas, Jiaqi Tan, Jay Nahata, Chaur Lih Tan, Nicolas Christin, and Patrick Tague. A5: Automated analysis of adversarial android applications. In ACM Work. Secur. Priv. Smartphones Mob. Devices, 2014.
  • [56] Te-En En Wei, Ching-Hao Hao Mao, Albert B. Jeng, Hahn-Ming Ming Lee, Horng-Tzer Tzer Wang, and Dong-Jie Jie Wu. Android malware detection via a latent network behavior analysis. In Trust. Secur. Priv. Comput. Commun., 2012.
  • [57] Florian Weimer. Passive DNS Replication. Technical report, 2005.
  • [58] Wenbo Yang, Juanru Li, Yuanyuan Zhang, Yong Li, Junliang Shu, and Dawu Gu. APKLancet: tumor payload diagnosis and purification for android applications. In ACM Symp. Information, Comput. Commun. Secur., ASIA CCS ’14, 2014.
  • [59] Zhenlong Yuan, Yongqiang Lu, Zhaoguo Wang, and Yibo Xue. Droid-Sec: deep learning in android malware detection. In ACM SIGCOMM Comput. Commun. Rev., 2014.
  • [60] Yuan Zhang, Min Yang, Bingquan Xu, Zhemin Yang, Guofei Gu, Peng Ning, X Sean Wang, and Binyu Zang. Vetting undesirable behaviors in android apps with permission use analysis. In ACM SIGSAC Conf. Comput. Commun. Secur., 2013.
  • [61] Yibing Zhongyang, Zhi Xin, Bing Mao, and Li Xie. DroidAlarm: An All-sided Static Analysis Tool for Android Privilege-escalation Malware. In ACM SIGSAC Symp. Information, Comput. Commun. Secur., ASIA CCS ’13, 2013.
  • [62] Wu Zhou, Yajin Zhou, Michael Grace, Xuxian Jiang, and Shihong Zou. Fast, scalable detection of piggybacked mobile applications. In ACM Conf. Data Appl. Secur. Priv., CODASPY ’13, 2013.
  • [63] Wu Zhou, Yajin Zhou, Xuxian Jiang, and Peng Ning. Detecting Repackaged Smartphone Applications in Third-party Android Marketplaces. In Proc. Second ACM Conf. Data Appl. Secur. Priv., 2012.
  • [64] Yajin Zhou, Zhi Wang, Wu Zhou, and Xuxian Jiang. Hey, You, Get Off of My Market: Detecting Malicious Apps in Official and Alternative Android Markets. In Symp. Netw. Distrib. Syst. Secur., 2012.