Android Malware Familial Classification

Android Malware Familial Classification

The rapid increase in the number of Androidmalware poses great challenges to anti-malware systems becausethe sheer number of malware samples overwhelms malwareanalysis systems. The classification of malware samples intofamilies, such that the common features shared by malwaresamples in the same family can be exploited in malware detectionand inspection, is a promising approach for accelerating malwareanalysis. Furthermore, the selection of representative malwaresamples in each family can drastically decrease the number ofmalware to be analyzed. However, existing classification solutionsare limited because of following reasons: First, the legitimatepart of the malware may misguide the classification algorithmsbecause the majority of Android malware are constructed byinserting malicious components into popular apps. Second, thepolymorphic variants of Android malware can evade detectionby employing transformation attacks. In this work, we propose anovel approach that constructs frequent subgraphs (fregraphs) torepresent the common behaviors of malware samples that belongto the same family. Moreover, we propose and develop FalDroid,a novel system that automatically classifies Android malwareand selects representative malware samples in accordance withfregraphs. We apply it to 8,407 malware samples from 36families. Experimental results show that FalDroid can correctlyclassify 94.2% of malware samples into their families usingapproximately 4.6 sec per app. FalDroid can also dramaticallyreduce the cost of malware investigation, by selecting only 8.5%to 22% representative samples that exhibit the most commonmalicious behavior among all samples into their families usingapproximately 4.6 sec per app. FalDroid can also dramaticallyreduce the cost of malware investigation, by selecting only 8.5%to 22% representative samples that exhibit the most commonmalicious behavior among all samplesn the third quarter of 2016, Android, the most popularmobile operating system, accounted for 86.8% of the marketshare of smartphones [1]. Meanwhile, it has become the majortarget of 97% of mobile malware [2]. A recent security reportshows that on average, 38,000 new mobile malware sampleswere captured per day during the third quarter of 2016 [3].The analysis of each malware sample requires ample time [4]–[6]. Hence, the sheer number of malware samples overwhelmsmalware analysis systems.The majority of new malware samples are polymorphicvariants of known malware [7], [8]. Thus, to acceleratemalware analysis, we can classify malware samples intovarious families and then select representative samples fromeach family. However, the familial classification of Androidmalware is challenging because of two reasonsirst, the accurate separation of malicious components Code Shoppy
 

https://codeshoppy.com/android-app-ideas-for-students-college-project.html
the legitimate part from the majority of Android malware,which are repackaged popular apps, is nontrivial [9]–[12].Zhou and Jiang [7] found that 86% of Android malwaresamples are repackaged apps produced by injecting maliciouscomponents into legitimate apps. The injected maliciouscomponents are hidden within the functionalities of popularapps and usually constitute only a small portion of therepackaged apps. Differentiating between the legitimate partand malicious components of malware is difficult for existingfeatures, such as system calls [13] and sensitive path [14].Second, polymorphic variants of Android malware thatbelong to the same family perform the same maliciousactivities with different implementations. Therefore, suchmalware can easily evade existing classification solutions [15],[16] that seek an exact match of a given specification. Forexample, Listing 1 illustrates different implementations ofthe same functionality (i.e., obtain device id, phone number,and voice mail number) in two malware samples. The twomalware samples belong to the same family,geinimi. Thesebot-like malware samples steal personal information and sendit to a remote server. Three major differences (highlightedin red) are observed in the two implementations. First, thestructures of class names are different. Second, the argumentsof the two functions are different. One takes a service(Lcom/geinimi/Adservice), one of the four basic componentsof Android apps, as an argument. By contrast, the other usesan object of the classrally/eas an argument. Third, theformer function contains two more statements (including oneinvocation) than the latter