HomDroid: detecting Android covert malware by social-network homophily analysis

Abstract

Android has become the most popular mobile operating system. Correspondingly, an increasing number of Android malware has been developed and spread to steal users' private information. There exists one type of malware whose benign behaviors are developed to camouflage malicious behaviors. The malicious component occupies a small part of the entire code of the application (app for short), and the malicious part is strongly coupled with the benign part. In this case, the malware may cause false negatives when malware detectors extract features from the entire apps to conduct classification because the malicious features of these apps may be hidden among benign features. Moreover, some previous work aims to divide the entire app into several parts to discover the malicious part. However, the premise of these methods to commence app partition is that the connections between the normal part and the malicious part are weak (e.g., repackaged malware).In this paper, we call this type of malware as Android covert malware and generate the first dataset of covert malware. To detect covert malware samples, we first conduct static analysis to extract the function call graphs. Through the deep analysis on call graphs, we observe that although the correlations between the normal part and the malicious part in these graphs are high, the degree of these correlations has a unique range of distribution. Based on the

Enhancing Malware Detection for Android Apps: Detecting Fine-Granularity Malicious Components

“…There are many existing methods of AMDs based on machine learning, utilizing features like permission, Android API, Android component, Dalvik code, Call Graph and so on [8], [3], [60], [7], [11], [4], [5], [34], [61], [6], [40], [62], [19]. DREBIN [7] extracts features from AndroidManifest.xml files and Dalvik bytecode by static analysis for behavioral modeling to detect malware.…”

“…MalScan [5] leverages centralities of sensitive android APIs in CG as a feature vector for conducting classification. Similar related works also include [62] and [19]. Malicious Code Fragment Detection (MCFD).…”

“…From the software engineering perspective, each module should have high modularity [42], [43], [44]. A module in a program can be regarded as one function (feature) for users [33], [45], [46], [47], and malicious behaviors are distributed in these functions [19]. Therefore, it reduces the influence on the evolution direction and is easier to refine solutions.…”

“…III-C). The capture of time dependency is necessary since malicious components may be small parts of malware apps (e.g., 2%) [19] and distributed separately in JSTS.…”

“…However, most existing AMDs only extract single and simple information for behavioral modeling [12], [4], [5], [13] (e.g., API sequence, Android APIs, graph), which makes malware able to evade them [14], [15], [16]; • C2: Time Dependency: Time dependency represents the execution logic of code and contains semantic and structural information (i.e., control flow, data flow, and invocation relationship) [17], [3], [18]. Capturing time dependency is necessary since malicious components may be some small parts of malware apps (e.g., 2%) [19] and distributed separately in them [17]. Most existing AMDs [20], [7], [21], [22], [4], [5] neglect it or consider parts of it, allowing malware to evade detection with specific modifications [17], [16]; and • C3: Fine-granularity Malicious Component Detection: Existing few malicious code fragment detection systems [23], [24], [12] can locate malicious code at class or method level.…”