HomDroid: Detecting Android Covert Malware by Social-Network Homophily Analysis

To better illustrate the key insight of our approach, we present a simplified example at first. This example (i.e., com.cpssw) is an app that pushes notifications about the scores of users’ favorite teams. However, it collects private data such as International Mobile Equipment Identity (IMEI), writes them into files, and sends them to a remote server. The normal behavior of this malware is to bring notifications to users, thus it needs to connect to the Internet to complete this purpose. Meanwhile, the malicious activity is to send data to the Internet which can cause privacy leaks. In other words, the normal code and malicious code of this malware both need to connect to the Internet to achieve their corresponding goals.

Because Android apps use API calls to access operating system functionality and system resources, and malware samples always invoke sensitive API calls to perform malicious activities. Therefore, we can leverage sensitive API calls to characterize the malicious behaviors of an app. To obtain the sensitive API calls invoked by the malware example, we upload it to an Android apps analysis system (san, 2021) to analyze and generate a detailed behavioral report. Through the report, we find that this malware mainly invokes four sensitive API calls (i.e., FileOutputStream.write(), URL.openConnection(), TelephonyManager.getDeviceId(), and DefaultHttpClient.execute()) to complete its maliciousness. In other words, the malicious part of the malware can be characterized by these sensitive API calls and their correlative parent nodes.

Figure 1 shows the function call graph of the malware example where the total number of nodes and edges are 918 and 1,392, respectively. It consists of two parts, the left part is made up of normal nodes while the right part includes sensitive API calls and their correlative parent nodes. As shown in Figure 1, the number of nodes of the malicious part is 11 which accounts for about 1.2% of all nodes of the entire call graph. Moreover, the proportion of edges in the malicious part is also low, which is less than 1% of all edges of the whole app. In this case, we may cause a false negative when we extract features from the entire app to conduct classification since the malicious features may be hidden under normal behaviors. In practice, the cosine similarity of two feature vectors obtained from the normal part and the whole call graph by MaMaDroid (Mariconti et al., 2017) is more than 95%, and it is misclassified by MaMaDroid (Mariconti et al., 2017) in our experiments.

Some prior studies (Hu et al., 2014; Tian et al., 2017) intent to partition the entire app to discover the suspicious part to achieve a more accurate malware detection. However, these approaches are designed to detect repackaged Android malware and the connections between injected malicious code and legitimate part are expected to be weak. In this malware, the number of edges shared by the normal part and malicious part is 154 which is more than 12 times greater than the total number of edges in the malicious part. To obtain a more determinate result, we regard the call graph in Figure 1 as a social network and conduct social-network-analysis to research the homophily of the network. Homophily is the tendency of individuals to associate and bond with similar others, as in the proverb ‘birds of a feather flock together’ (Mcpherson and Lynn, 2001) (Details are in Section 3.3). Suppose that a network consists of two subnetworks, high homophily of the network means that the correlation between these two subnetworks is low. After analyzing Figure 1, we find that the homophily of Figure 1 is not distinct, in other words, the connections between the normal part and malicious part are strong, making it difficult to be handled by methods in prior studies (Hu et al., 2014; Tian et al., 2017).

In conclusion, when the malicious code accounts for a small part of an entire malicious app and the connection between normal code and malicious code is strong, prior approaches (Mariconti et al., 2017; Hu et al., 2014; Tian et al., 2017) may cause high false negatives since the malicious behaviors can be hidden under the normal codes. In this paper, we call this type of malware as Android covert malware and construct the first dataset of these malware samples.

To generate the dataset of Android covert malware, we first randomly download about 100,000 malicious apps from AndroZoo (Allix et al., 2016) which is a growing collection of Android apps collected from several sources, including the official Google Play app market and several third-party Android app markets (e.g., AppChina (App, 2021b)). After obtaining the samples, we perform static analysis to extract the function call graphs of these apps. As API calls are used by the Android apps to access operating system functionality and system resources, they can be used as representations of the behaviors of Android apps. Moreover, Android malware usually invokes some sensitive API calls to perform malicious activities. Therefore, we assume these sensitive API calls and their correlated parent nodes as the malicious part and the rest as the normal part. Particularly, we focus on the newest version of API calls set in PScout (Au et al., 2012), which is the largest collection of sensitive API calls (i.e., 21,986 API calls).

After dividing the graph into the normal part and malicious part, we build the covert malware dataset according to the following steps: 1) We first conduct statistical analysis to obtain the proportion of malicious nodes in all nodes; 2) We then perform homophily analysis to collect the correlation between the normal part and the malicious part; 3) Next, malware samples with low correlation between the normal part and the malicious part are be omitted; 4) As for the remaining malware, we divide them into six categories according to the proportion: [0-1%), [1%-2%), [2%-3%), [3%-4%), [4%- 5%), and greater than 5%; 5) To find which category may be more covert, we randomly select 100 samples from each category and upload them to VirusTotal (vir, 2021); 6) After analyzing the scanning results, we find that malware with a proportion of less than 2% is less likely to be detected as malware. Therefore, we pay more attention to these malware samples with a proportion of less than 2% (i.e., 4,321 samples); 7) To further verify whether these samples contain disguised behaviors or not, we conduct dynamic analysis to obtain accurate behaviors. Specifically, we use some state-of-the-art security tools (e.g., AppCritique (App, 2021a) and Sandroid (san, 2021)) to generate detailed behavior reports, and then manually analyze these reports to check whether sensitive API calls invoked by malicious behaviors are also used by normal behaviors. If there are many such cases, then we consider the malware to be covert. After in-depth manual analysis, we finally obtain 3,358 covert malware samples.

As shown in Figure 2, HomDroid consists of four main phases: Static Analysis, Graph Partition, Feature Extraction, and Classification.

• •

  Static Analysis: Given an app, we first conduct static analysis to obtain the function call graph where each node is a function that can be an API call or a user-defined function.

• •

  Graph Partition: After generating the call graph, we then divide it into certain subgraphs by community detection and discover the most suspicious part by homophily analysis. The output of this phase is the most suspicious subgraph.

• •

  Feature Extraction: Next, two types of feature sets are collected from the suspicious subgraph, including the appearance of sensitive API calls and the ratio of the number of sensitive triads to the total number of triads within the subgraph.

• •

  Classification: In our final phase, given a feature vector, we can accurately flag it as either benign or malicious by using a trained machine learning classifier.

To achieve high accuracy malware detection, we consider maintaining the program semantics of an APK file. In other words, we conduct light-weight static analysis to distill the semantics of an app into a graph representation. More specifically, we implement our static analysis to extract the function call graph of an app based on an Android reverse engineering tool, Androguard (Desnos et al., 2011).

In this phase, we pay attention to discover the most suspicious part of a function call graph. As shown in Figure 2, our Graph Partition phase is composed of two steps which are Community Detection and Homophily Analysis.

After obtaining the most suspicious subgraph of a call graph, we then extract features from the subgraph. More specifically, we collect two types of feature sets including the appearance of sensitive API calls and the ratio of the number of sensitive triads to the total number of triads within the subgraph.

Our first type of feature set focuses on the occurrence of sensitive API calls. As aforementioned, we select 426 most suspicious sensitive API calls (Gong et al., 2020) as our concerned objectives. Given the most suspicious subgraph, we check whether the nodes in the subgraph contain any sensitive API calls. If sensitive API calls appear in the subgraph, the value of the corresponding feature will be one, otherwise, it is zero. The dimension of our first type of feature vector is the total number of sensitive API calls, which is 426.

Furthermore, to maintain the graph semantics of the subgraph, we also consider the graph structure details to construct our second feature set. In social network analysis, there are 16 different types (Batagelj and Mrvar, 2001) of triads in a network. In practice, these triads can represent different network structure properties of a network. Therefore, we select a total of six types of triads from the 16 types (Batagelj and Mrvar, 2001) since sensitive API calls are always being invoked by other functions to perform malicious activities in Android malware.

In Figure 7, we present our selected six types of triads which can represent different graph structure details. For example, a sensitive triad of 021U shows that two normal functions invoke a same sensitive API call while 021C indicates that one normal function $f_{1}$ first invokes another normal function $f_{2}$ and then normal function $f_{2}$ invokes a sensitive API call. By extracting these sensitive triads from the suspicious subgraph, we are able to characterize malicious behaviors to achieve semantic Android malware detection. More specifically, we first extract all these six types of triads from a given suspicious subgraph. For each type of triad, we then collect sensitive triads by checking whether a triad contains any sensitive API call or not. After obtaining all sensitive triads and all triads, the ratio of the number of sensitive triads to the total number of triads for each sensitive API call will be calculated as the features.

To better describe the construction of the features of sensitive triads, we present an example in Figure 8. Assuming that a suspicious subgraph contains six nodes, and two of them are sensitive API calls. After collecting all the triads from the subgraph, we find that there are four sensitive triads including two sensitive triads of 021D, one sensitive triad of 021C, and one sensitive triad of 030T. In addition, the total number of six types (i.e., 021D, 021U, 021C, 111U, 030T, and 120U) of triads in the subgraph are two, zero, three, zero, one, and zero, respectively. For each sensitive API call, we compute the ratio of the number of corresponding sensitive triads to the total number of triads for each type of triad. For example, the number of triads of 021C of sensitive API call 5 is one and the total number of triads of 021C in the subgraph is three, then the feature of sensitive API call 5 for 021C will be calculated as 1/3. Moreover, if the subgraph does not contain sensitive triads of certain types, the corresponding features will be set zero directly. Finally, we can obtain a feature vector whose dimension is the number of sensitive API calls multiply by six (i.e., six types of sensitive triads). In HomDroid, the number of selected sensitive API calls is 426, then the dimension of the feature vector of sensitive triads is 426$*$6=2,556.

After extracting the mentioned two types of features, we concatenate them as our final feature vector whose dimension is 2,982.

Given extracted feature vectors, our final phase focuses on training a classifier first and then uses it to detect Android covert malware. More specifically, in order to check the ability of HomDroid on detecting covert malware with different classifiers, we implement six classification algorithms (i.e., 1-Nearest Neighbor, 3-Nearest Neighbor, Random Forest, Decision Tree, SVM, and Logistic Regression) by using a python library scikit-learn (skl, 2021). Parameters in these algorithms are default parameters in scikit-learn (skl, 2021), we leverage them to commence our evaluations and all the experimental results are presented in the following section.

As aforementioned, we obtain 3,358 Android covert malware by analyzing and filtering 100,000 malicious apps from AndroZoo (Allix et al., 2016). In order to evaluate the effectiveness of HomDroid on detecting Android covert malware, we also crawl benign apps from AndroZoo. Our final dataset consists of 4,840 benign apps and 3,358 covert malware, and the average sizes (in Table 1) of these benign apps and covert malware are 2.7 MB and 3.2 MB, respectively. We leverage this dataset to commence our evaluations and the experimental results are reported in the following subsections. Note that all experiments are conducted by performing 10-fold cross-validations, which means that the dataset is partitioned into 10 subsets, each time we pick one subset as our testing set and the rest nine subsets as training set. We repeat this 10 times and report the average as our final results.

In addition, we adopt several widely used metrics to measure the experimental results of HomDroid. These metrics are presented in Table 2, in which True Positive Rate (TPR) and False Negative Rate (FNR) present the effectiveness on detecting malicious samples while True Negative Rate (TNR) and False Positive Rate (FPR) show the ability on benign samples detection. In our experiments, we report both FNR and FPR to see how HomDroid performs on classifying both malicious and benign samples. Moreover, we also report F-measure and Accuracy for presenting the overall detection effectiveness of HomDroid.

In this phase, we conduct several experiments to examine the ability of HomDroid on Android covert malware detection by using the collected dataset in Table 1. Specifically, we evaluate the effectiveness of HomDroid from the following two aspects:

• •

  Different classification models: 1-Nearest Neighbor (1NN), 3-Nearest Neighbor (3NN), Random Forest (RF), Decision Tree (DT), Support Vector Machine (SVM), and Logistic Regression (LR).

• •

  Different thresholds of coupling: 1, 2, 3, 4, and 5.

In this phase, we perform comparative experiments of HomDroid with four state-of-the-art Android malware detection approaches: PerDroid²²2For more convenient discussion, we call the system in (Wang et al., 2014) as PerDroid since it is a permission-based method. (Wang et al., 2014), Drebin (Arp et al., 2014), MaMaDroid (Mariconti et al., 2017), and IntDroid (Zou et al., 2021)

In this phase, we pay attention to evaluate the runtime overhead of HomDroid. As aforementioned, HomDroid composes of four steps to analyze an app, which are Static Analysis, Graph Partition, Feature Extraction, and Classification. We introduce the corresponding overhead in Figure 11 according to the different steps involved in HomDroid. Our dataset consists of 4,840 benign apps and 3,385 covert malware, the average nodes and edges of our 8,198 apps are 5,615 and 12,131, respectively.

(1) Static Analysis: HomDroid is a semantics-based Android covert malware detection method, it distills the program semantics of an app into a function call graph by static analysis. The runtime overhead of function call graph extraction is given in Figure 11, it needs to take about 2.44 seconds to complete the static analysis on average. Moreover, more than 90% of apps in our dataset can be obtained the call graphs within 8 seconds.

(2) Graph Partition: After obtaining the call graph of an app, we then perform community detection and homophily analysis to dig out the most suspicious subgraph. This step is the most time-consuming phase among all the steps in HomDroid. As shown in Figure 11, the average runtime overhead to partition a call graph is 9.89 seconds, and more than 85% of call graphs are able to be discovered the corresponding most suspicious subgraph within 20 seconds.

(3) Feature Extraction: Given the most suspicious subgraph, we extract two types of feature sets from it including the presence of certain sensitive API calls and the ratio of the number of sensitive triads to the total number of triads within the subgraph. This step requires less time than the former two steps (i.e., static analysis and graph partition). Specifically, on average, it takes about 1.04 seconds for HomDroid to achieve the feature extraction from a suspicious subgraph.

(4) Classification: The final step of HomDroid is to perform classification by a classifier. The classifier is first trained by using feature vectors extracted from the feature extraction step. Figure 11 shows the runtime overhead of HomDroid when we select 1NN as our classifier. In practice, classification consumes the least runtime overhead, it only requires about 0.05 seconds to distinguish a feature vector as either benign or malicious.

We also compare the runtime overhead of HomDroid with PerDroid, Drebin, MaMaDroid, and IntDroid as shown in Table 5. It is obvious that PerDroid is the fastest system to detect malware among these compared four systems since PerDroid only extracts the requested permissions from the manifest file of an app. However, its detection effectiveness is the lowest due to the lack of consideration of semantics from app code. As for Drebin, it collects eight different types of feature sets from both manifest and app code, and these feature sets consist of several complex features (e.g., network address), thus making it time-consuming to complete the whole analysis of an app. As regards MaMaDroid, due to the complex static analysis and over many features (i.e., 115,600 features), the runtime overhead of MaMaDroid is more expensive than Drebin and HomDroid. As for IntDroid, it combines social network analysis with traditional graph analysis. Although the runtime overhead of social network analysis is small, the procedure of traditional graph analysis is more time-consuming. In other words, HomDroid achieves a more efficient malware detection than Drebin, MaMaDroid, and IntDroid.

(1) The use of homophily analysis. In our work, the generation of covert malware should meet that the normal parts and the malicious parts are highly correlated. In this generation phase, the use of homophily analysis is to check whether the normal parts and the malicious parts are highly correlated or not. Besides, in graph partition phase of HomDroid, the purpose of homophily analysis is to filter out the normal parts from sensitive subgraphs to generate an accurate suspicious subgraph. Although we choose to leverage homophily analysis in both phases, the correlation analysis in the two phases are independent. The use of same analysis technique will not incur bias in the final results.

(2) Why can HomDroid detect covert malware? Existing Android malware detection methods analyze the entire app to extract features, however, the malicious part of covert malware only occupies a small part of the entire app, thus the malicious features may be hidden under benign features. Moreover, some repackaged malware detection techniques first divide the entire app into several parts and then discover the most suspicious part. The premise of these methods to commence app partition is that the connections between the normal part and the malicious part are weak. However, covert malware samples do not fit the situation. HomDroid performs homophily analysis to discover the most suspicious parts, which has the ability to discover the suspicious parts from the entire graph although the connections between the normal part and the malicious part are strong.

(3) The application of HomDroid. The design of HomDroid is to detect Android covert malware, therefore, we can combine HomDroid with other state-of-the-art general malware detection techniques (e.g., IntDroid) to complete more comprehensive malware discovery. For example, IntDroid can be used as the first line of defense to filter most of malware (i.e., general malware), then HomDroid can be applied as the second line of defense to discover more malware (i.e., covert malware).

(4) Using different triads to detect covert malware. Since sensitive API calls are always being invoked by other functions to perform malicious activities, therefore, we only select six types of triads to commence our feature extraction. In reality, we also apply a feature ranking method (i.e., T-test) to research the ability of these six triads on covert malware detection. The results show that 021U triad ranks first. In our future work, we will construct different combinations of triads to find the most suitable combination to achieve better detection results.

Similar to any empirical approach, HomDroid suffers from several limitations, which are listed below.

(1) Call graph extraction. In this paper, our static analysis phase is implemented by leveraging Androguard (Desnos et al., 2011). In reality, function call graph extracted by Androguard (Desnos et al., 2011) is a context- and flow-insensitive call graph. We ignore these information for achieving high efficiency to detect covert malware. To mitigate the inaccuracies caused by our constructed call graph, we plan to use advanced program analysis to generate a suitable call graph to achieve the balance between the efficiency and effectiveness on detecting covert malware.

(2) Obfuscations. Since HomDroid is a graph-based method, it can resist some typical obfuscations (e.g., rename obfuscation), however, apps can use reflection (Rastogi et al., 2013) to call sensitive API calls, in this case, we may miss the call relationships between these methods. To be resilient to reflection, we can use an open-source tool, DroidRA (Li et al., 2016), to conduct reflection analysis to identify methods that use reflection for each app. Then the missing edges can be added into the call graph, where caller nodes are methods that use reflection and callee nodes are reflected methods. Moreover, since HomDroid is to perform static analysis to extract the call graph, it is vulnerable to dynamic loading and encryption (e.g., APK Protect (apk, 2021)). As for dynamic loading, it is the technique through which a computer program at runtime loads a library into memory. Thus all static-analysis-based methods suffer from this limitation. As for encryption, packers can protect apps by using encryption techniques to hide the actual Dex code. To address this limitation, we can use some unpacker systems such as PackerGrind (Xue et al., 2017) to recover the actual Dex files, then static analysis can be applied to extract call graph.

(3) Sensitive API calls. HomDroid mainly focuses on 426 sensitive API calls that are highly correlated with malicious operations (Gong et al., 2020). These sensitive API calls account for a small part of the whole sensitive API calls. We plan to conduct statistical analysis to select more valuable sensitive API calls to commence our experiments.

(4) The partition of our dataset. We perform 10-fold cross-validations to generate our evaluation results, which means that the dataset is partitioned into 10 subsets, each time we pick one subset as our testing set and the rest nine subsets as training set. We repeat this 10 times and report the average. In this partitioning phase, we do not distinguish the family labels of our covert malware. In practice, the result may overfit when samples from the same family are not used in both training and testing sets. We plan to label the family first by using Avclass (Sebastián et al., 2016), and then make sure that samples from the same family are used in both training and testing sets.