{
	"id": "8180e0b0-eaf9-4282-93ca-f8ee7d3b2f1b",
	"created_at": "2026-04-06T00:10:20.728214Z",
	"updated_at": "2026-04-10T13:12:24.009883Z",
	"deleted_at": null,
	"sha1_hash": "be2aef2c6a000173de2b1ac72717eac0af2acc5a",
	"title": "Dissecting Android Malware: Characterization and Evolution",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 126269,
	"plain_text": "Dissecting Android Malware: Characterization and Evolution\r\nBy Authors\r\nArchived: 2026-04-05 14:25:50 UTC\r\nDownload References\r\nRequest Permissions\r\nSave to\r\nAlerts\r\nAbstract:\r\nThe popularity and adoption of smart phones has greatly stimulated the spread of mobile malware, especially on\r\nthe popular platforms such as Android. In light of their ra...Show More\r\nMetadata\r\nAbstract:\r\nThe popularity and adoption of smart phones has greatly stimulated the spread of mobile malware, especially on\r\nthe popular platforms such as Android. In light of their rapid growth, there is a pressing need to develop effective\r\nsolutions. However, our defense capability is largely constrained by the limited understanding of these emerging\r\nmobile malware and the lack of timely access to related samples. In this paper, we focus on the Android platform\r\nand aim to systematize or characterize existing Android malware. Particularly, with more than one year effort, we\r\nhave managed to collect more than 1,200 malware samples that cover the majority of existing Android malware\r\nfamilies, ranging from their debut in August 2010 to recent ones in October 2011. In addition, we systematically\r\ncharacterize them from various aspects, including their installation methods, activation mechanisms as well as the\r\nnature of carried malicious payloads. The characterization and a subsequent evolution-based study of\r\nrepresentative families reveal that they are evolving rapidly to circumvent the detection from existing mobile anti-virus software. Based on the evaluation with four representative mobile security software, our experiments show\r\nthat the best case detects 79.6% of them while the worst case detects only 20.2% in our dataset. These results\r\nclearly call for the need to better develop next-generation anti-mobile-malware solutions.\r\nDate of Conference: 20-23 May 2012\r\nDate Added to IEEE Xplore: 09 July 2012\r\nISSN Information:\r\nConference Location: San Francisco, CA, USA\r\nhttp://ieeexplore.ieee.org/document/6234407\r\nPage 1 of 18\n\nIn recent years, there is an explosive growth in smartphone sales and adoption. According to CNN [1], smartphone\r\nshipments have tripled in the past three years (from 40 million to about 120 million). Unfortunately, the increasing\r\nadoption of smartphones comes with the growing prevalence of mobile malware. As the most popular mobile\r\nplatform, Google's Android overtook others (e.g., Symbian) to become the top mobile malware platform. It has\r\nbeen highlighted [2] that “among all mobile malware, the share of Android-based malware is higher than 46% and\r\nstill growing rapidly.” Another recent report also alerts that there is “400 percent increase in Android-based\r\nmalware since summer 2010” [3].\r\nGiven the rampant growth of Android malware, there is a pressing need to effectively mitigate or defend against\r\nthem. However, without an insightful understanding of them, it is hard to imagine that an effective mitigation\r\nsolution can be practically developed. To make matters worse, the research community at large is still constrained\r\nby the lack of a comprehensive mobile malware dataset to start with.\r\nThe goals and contributions of this paper are three-fold. First, we fulfil the need by presenting the first large\r\ncollection of 1260 Android malware samples in 49 different malware families, which covers the majority of\r\nexisting Android malware, ranging from their debut in August 2010 to recent ones in October 2011. The dataset is\r\naccumulated from more than one year effort in collecting related malware samples, including manual or\r\nautomated crawling from a variety of Android Markets. To better mitigate mobile malware threats, we will release\r\nthe entire dataset to the research community at http://malgenomeproject.org/.2\r\nSecond, based on the collected malware samples, we perform a timeline analysis of their discovery and\r\nthoroughly characterize them based on their detailed behavior breakdown, including the installation, activation,\r\nand payloads. The timeline analysis is instrumental to revealing major outbreaks of certain Android malware in\r\nthe wild while the detailed breakdown and characterization of existing Android malware is helpful to better\r\nunderstand them and shed light on possible defenses.\r\nSpecifically, in our 1260 malware samples, we find that 1083 of them (or 86.0%) are repackaged versions of\r\nlegitimate applications with malicious payloads, which indicates the policing need of detecting repackaged\r\napplications in the current Android Markets. Also, we observe that more recent Android malware families are\r\nadopting update attacks and drive-by downloads to infect users, which are more stealthy and difficult to detect.\r\nFurther, when analyzing the carried payloads, we notice a number of alarming statistics: (1) Around one third\r\n(36.7%) of the collected malware samples leverage root-level exploits to fully compromise the Android security,\r\nposing the highest level of threats to users' security and privacy; (2) More than 90% turn the compromised phones\r\ninto a botnet controlled through network or short messages. (3) Among the 49 malware families, 28 of them (with\r\n571 or 45.3% samples) have the built-in support of sending out background short messages (to premium-rate\r\nnumbers) or making phone calls without user awareness. (4) Last but not least, 27 malware families (with 644 or\r\n51.1% samples) are harvesting user's information, including user accounts and short messages stored on the\r\nphones.\r\nThird, we perform an evolution-based study of representative Android malware, which shows that they are rapidly\r\nevolving and existing anti-malware solutions are seriously lagging behind. For example, it is not uncommon for\r\nAndroid malware to have encrypted root exploits or obfuscated command and control (C\u0026C) servers. The\r\nadoption of various sophisticated techniques greatly raises the bar for their detection. In fact, to evaluate the\r\neffectiveness of existing mobile antivirus software, we tested our dataset with four representative ones, i.e., AVG\r\nhttp://ieeexplore.ieee.org/document/6234407\r\nPage 2 of 18\n\nAntivirus Free, Lookout Security \u0026 Antivirus, Norton Mobile Security Lite, and Trend Micro Mobile Security\r\nPersonal Edition, all downloaded from the official Android Market (in the first week of November, 2011). Sadly,\r\nwile the best case was able to detect 1,003 (or 79.6%) samples in our dataset, the worst case can only detect 254\r\n(20.2%) samples. Furthermore, our analysis shows that malware authors are quickly learning from each other to\r\ncreate hybrid threats. For example, one recent Android malware, i.e., AnserverBot [4] (reported in September\r\n2011), is clearly inspired from Plankton [5] (reported in June 2011) to have the dynamic capability of fetching and\r\nexecuting payload at runtime, posing significant challenges for the development of next-generation anti-mobile-malware solutions.\r\nThe rest of this paper is organized as follows: Section II presents a timeline analysis of existing Android malware.\r\nSection III characterizes our samples and shows a detailed breakdown of their infection behavior. After that,\r\nSection IV presents an evolution study of representative Android malware and Section V shows the detection\r\nresults with four representative mobile antivirus software. Section VI discusses possible ways for future\r\nimprovement, followed by a survey of related work in Section VII. Lastly, we summarize our paper in Section\r\nVIII.\r\nSECTION II.\r\nMalware Timeline\r\nIn Table I, we show the list of 49 Android malware families in our dataset along with the time when each\r\nparticular malware family is discovered. We obtain the list by carefully examining the related security\r\nannouncements, threat reports, and blog contents from existing mobile antivirus companies and active researchers\r\n[6] [7] [8] [9] [10] [11] [12] as exhaustively as possible and diligently requesting malware samples from them or\r\nactively crawling from existing official and alternative Android Markets. As of this writing, our collection is\r\nbelieved to reflect the state of the art of Android malware. Specifically, if we take a look at the Android malware\r\nhistory [13] from the very first Android malware FakePlayer in August 2010 to recent ones in the end of October\r\n2011, it spans slightly more than one year with around 52 Android malware families reported. Our dataset has\r\n1260 samples in 49 different malware families, indicating a very decent coverage of existing Android malware.\r\nTable I The Timeline of 49 Android Malware In Our Collection (O† Offical Android Market; A‡: Alternative\r\nAndroid Markets)\r\nTable I- The Timeline of 49 Android Malware In Our Collection (O† Offical Android Market; A‡: Alternative\r\nAndroid Markets)\r\nFor each malware family, we also report in the table the number of samples in our collection and differentiate the\r\nsources where the malware was discovered, i.e., from either the official or alternative Android Markets. To\r\neliminate possible false positive in our dataset, we run our collection through existing mobile antivirus software\r\nfor confirmation (Section V). If there is any miss from existing mobile antivirus security software, we will\r\nmanually verify the sample and confirm it is indeed a malware.\r\nTo better illustrate the malware growth, we show in Figures 1(a) and 1(b) the monthly breakdown of new Android\r\nmalware families and the cumulative monthly growth of malware samples in our dataset. Consistent with others\r\n[2] [3], starting summer 2011, the Android malware has indeed increased dramatically, reflected in the rapid\r\nhttp://ieeexplore.ieee.org/document/6234407\r\nPage 3 of 18\n\nemergence of new malware families as well as different variants of the same type. In fact, the number of new\r\nAndroid malware in July 2011 alone already exceeds the total number in the whole year of 2010. Figure 1(b)\r\nfurther reveals two major Android malware outbreaks, including DroidKungFu (starting June, 2011) and\r\nAnserverBot (starting September, 2011). Among these 1260 samples in our collection, 37.5% of them are related\r\nto DroidKungFu [14] and its variants; 14.8% are AnserverBot [4]. Both of them are still actively evolving to\r\nevade the detection from existing antivirus software - a subject we will dive into in Section IV.\r\nFigure 1. - The Android Malware Growth in 2010–2011\r\nFigure 1.\r\nThe Android Malware Growth in 2010–2011\r\nIn this section, we present a systematic characterization of existing Android malware, ranging from their\r\ninstallation, activation, to the carried malicious payloads.\r\nA. Malware Installation\r\nBy manually analyzing malware samples in our collection, we categorize existing ways Android malware use to\r\ninstall onto user phones and generalize them into three main social engineering-based techniques, i.e.,\r\nrepackaging, update attack, and drive-by download. These techniques are not mutually exclusive as different\r\nvariants of the same type may use different techniques to entice users for downloading.\r\n1) Repackaging\r\nRepackaging is one of the most common techniques malware authors use to piggyback malicious payloads into\r\npopular applications (or simply apps). In essence, malware authors may locate and download popular apps,\r\ndisassemble them, enclose malicious payloads, and then re-assemble and submit the new apps to official and/or\r\nalternative Android Markets. Users could be vulnerable by being enticed to download and install these infected\r\napps.\r\nTo quantify the use of repackaging technique among our collection, we take the following approach: if a sample\r\nshares the same package name with an app in the official Android Market, we then download the official app (if\r\nfree) and manually compare the difference, which typically contains the malicious payload added by malware\r\nauthors. If the original app is not available, we choose to disassemble the malware sample and manually determine\r\nwhether the malicious payload is a natural part of the main functionality of the host app. If not, it is considered as\r\nrepackaged app.\r\nIn total, among the 1260 malware samples, 1083 of them (or 86.0%) are repackaged. By further classifying them\r\nbased on each individual family (Table II), we find that within the total 49 families in our collection, 25 of them\r\ninfect users by these repackaged apps while 25 of them are standalone apps where most of them are designed to be\r\nspyware in the first place. One malware family, i.e., GoldDream, utilizes both for its infection.\r\nTable II An Overview of Existing Android Malware (Part I: Installation and Activation)\r\nTable II- An Overview of Existing Android Malware (Part I: Installation and Activation)\r\nhttp://ieeexplore.ieee.org/document/6234407\r\nPage 4 of 18\n\nAmong the 1083 repackaged apps, we find that malware authors have chosen a variety of apps for repackaging,\r\nincluding paid apps, popular game apps, powerful utility apps (including security updates), as well as porn-related\r\napps. For instance, one AnserverBot malware sample (SHA1: ef140ablad04bdge52c8c5f2fb6440f3agebe8ea)\r\nrepackaged a paid app com. camelgames.mxmotor available on the official Android Market. Another BgServ [15]\r\nmalware sample (SHA1: bc2dedad0507a916604f86167a9fa30693ge2080) repackaged the security tool released\r\nby Google to remove DroidDream from infected phones.\r\nAlso, possibly due to the attempt to hide piggy-backed malicious payloads, malware authors tend to use the class-file names which look legitimate and benign. For example, AnserverBot malware uses a package name\r\ncom.sec.android.provider.drm for its payload, which looks like a module that provides legitimate DRM\r\nfunctionality. The first version of DroidKungFu chooses to use com. google .ssearch to disguise as the Google\r\nsearch module and its follow-up versions use com.google.update to pretend to be an official Google update.\r\nIt is interesting to note that one malware family - jSMSHider- uses a publicly available private key (serial number:\r\nb3998086d056cffa) that is distributed in the Android Open Source Project (AOSP). The current Android security\r\nmodel allows the apps signed with the same platform key of the phone firmware to request the permissions which\r\nare otherwise not available to normal third-party apps. One such permission includes the installation of additional\r\napps without user intervention. Unfortunately, a few (earlier) popular custom firmware images were signed by the\r\ndefault key distributed in AOSP. As a result, the jSMSHider-infected apps may obtain privileged permissions to\r\nperform dangerous operations without user's awareness.\r\n2) Update Attack\r\nThe first technique typically piggy- backs the entire malicious payloads into host apps, which could potentially\r\nexpose their presence. The second technique makes it difficult for detection. Specifically, it may still repackage\r\npopular apps. But instead of enclosing the payload as a whole, it only includes an update component that will\r\nfetch or download the malicious payloads at runtime. As a result, a static scanning of host apps may fail to capture\r\nthe malicious payloads. In our dataset, there are four malware families, i.e., BaseBridge, DroidKungFuUpdate,\r\nAnserverBot, and Plankton, that adopt this attack (Table II).\r\nThe BaseBridge malware has a number of variants. While some embed root exploits that allow for silent\r\ninstallation of additional apps without user intervention, we here focus on other variants that use the update\r\nattacks without root exploits. Specifically, when a BaseBridge-infected app runs, it will check whether an update\r\ndialogue needs to be displayed. If yes, by essentially saying that a new version is available, the user will be\r\noffered to install the updated version (Figure 2(a)). (The new version is actually stored in the host app as a\r\nresource or asset file.) If the user accepts, an “updated” version with the malicious payload will then be installed\r\n(Figure 2(b)). Because the malicious payload is in the “updated” app, not the original app itself, it is more stealthy\r\nthan the first technique that directly includes the entire malicious payload in the first place.\r\nFigure 2. - An Update Attack from BaseBridge\r\nFigure 2.\r\nAn Update Attack from BaseBridge\r\nhttp://ieeexplore.ieee.org/document/6234407\r\nPage 5 of 18\n\nThe DroidKungFuUpdate malware is similar to BaseBridge. But instead of carrying or enclosing the “updated”\r\nversion inside the original app, it chooses to remotely download a new version from network. Moreover, it takes a\r\nstealthy route by notifying the users through a third-party library [16] that provides the (legitimate) notification\r\nfunctionality. (Note the functionality is similar to the automatic notification from the Google's Cloud to Device\r\nMessaging framework.) In Figure 3, we show the captured network traffic initiated from the original host app to\r\nupdate itself. Once downloaded, the “updated” version turns out to be the DroidKungFu3 malware. As pointed out\r\nin Table I, the DroidKungFuUpdate malware was available on both official and alternative Android Markets.\r\nFigure 3. - An Update Attack from DroidKungFuUpdate\r\nFigure 3.\r\nAn Update Attack from DroidKungFuUpdate\r\nThe previous two update attacks require user approval to download and install new versions. The next two\r\nmalware, i.e., AnserverBot and Plankton, advance the update attack by stealthily upgrading certain components in\r\nthe host apps not the entire app. As a result, it does not require user approval. In particular, Plankton directly\r\nfetches and runs a jar file maintained in a remote server while AnserverBot retrieves a public (encrypted) blog\r\nentry, which contains the actual payloads for update! In Figure 4, we show the actual network traffic to download\r\nAnserverBot payload from the remote command and control (C\u0026C) server. Apparently, the stealthy nature of\r\nthese update attacks poses significant challenges for their detection (Table VII-Section V).\r\nFigure 4. - An Update Attack from AnserverBot\r\nFigure 4.\r\nAn Update Attack from AnserverBot\r\n3) Drive-by Download\r\nThe third technique applies the traditional drive-by download attacks to mobile space. Though they are not\r\ndirectly exploiting mobile browser vulnerabilities, they are essentially enticing users to download “interesting” or\r\n“feature-rich” apps. In our collection, we have four such malware families, i.e., GGTracker [17], Jifake [18],\r\nSpitmo [19] and ZitMo [20]. The last two are designed to steal user's sensitive banking information.\r\nThe GGTracker malware starts from its in-app advertisements. In particular, when a user clicks a special\r\nadvertisement link, it will redirect the user to a malicious website, which claims to be analyzing the battery usage\r\nof user's phone and will redirect the user to one fake Android Market to download an app claimed to improve\r\nbattery efficiency. Unfortunately, the downloaded app is not one that focuses on improving the efficiency of\r\nbattery, but a malware that will subscribe to a premium-rate service without user's knowledge.\r\nSimilarly, the Jifake malware is downloaded when users are redirected to the malicious website. However, it is not\r\nusing in-app advertisements to attract and redirect users. Instead, it uses a malicious QR code [21], which when\r\nscanned will redirect the user to another URL containing the Jifake malware. This malware itself is the repackaged\r\nmobile ICQ client, which sends several SMS messages to a premium-rate number. While QR code-based malware\r\npropagation has been warned earlier [22], this is the first time that this attack actually occurred in the wild.\r\nhttp://ieeexplore.ieee.org/document/6234407\r\nPage 6 of 18\n\nThe last two Spitmo and ZitMo are ported versions of nefarious PC malware, i.e., SpyEye and Zeus. They work in\r\na similar manner: when a user is doing online banking with a comprised PC, the user will be redirected to\r\ndownload a particular smartphone app, which is claimed to better protect online banking activities. However, the\r\ndownloaded app is actually a malware, which can collect and send mTANs or SMS messages to a remote server.\r\nThese two malware families rely on the comprised desktop browsers to launch the attack. Though it may seem\r\nhard to infect real users, the fact that they can steal sensitive bank information raises serious alerts to users.\r\n4) Others\r\nWe have so far presented three main social engineering-based techniques that have been used in existing Android\r\nmalware. Next, we examine the rest samples that do not fall in the above three categories. In particular, our dataset\r\nhas 1083 repackaged apps, which leaves 177 standalone apps. We therefore look into those standalone apps and\r\norganize them into the following four groups.\r\nThe first group is considered spyware as claimed by themselves - they intend to be installed to victim's phones on\r\npurpose. That probably explains why attackers have no motivations or the need to lure victim for installation.\r\nGPSSMSSpy is an example that listens to SMS-based commands to record and upload the victim's current\r\nlocation.\r\nThe second group includes those fake apps that masquerade as the legitimate apps but stealthily perform malicious\r\nactions, such as stealing users' credentials or sending background SMS messages. FakeNetflix is an example that\r\nsteals a user's Netflix account and password. Note that it is not a repackaged version of Netflix app but instead\r\ndisguises to be the Netflix app with the same user interface. FakePlayer is another example that masquerades as a\r\nmovie player but does not provide the advertised functionality at all. All it does is to send SMS messages to\r\npremium-rate numbers without user awareness.\r\nThe third group contains apps that also intentionally include malicious functionality (e.g., sending unauthorized\r\nSMS messages or subscribing to some value-added service automatically). But the difference from the second\r\ngroup is that they are not fake ones. Instead, they can provide the functionality they claimed. But unknown to\r\nusers, they also include certain malicious functionality. For example, one RogueSPPush sample is an astrology\r\napp. But it will automatically subscribe to premium-rate services by intentionally hiding confirmation SMS\r\nmessages.\r\nThe last group includes those apps that rely on the root privilege to function well. However, without asking the\r\nuser to grant the root privilege to these apps, they leverage known root exploits to escape from the built-in security\r\nsandbox. Though these apps may not clearly demonstrate malicious intents, the fact of using root exploits without\r\nuser permission seems cross the line. Examples in this group include Asroot and DroidDeluxe.\r\nB. Activation\r\nNext, we examine the system-wide Android events of interest to existing Android malware. By registering for the\r\nrelated system-wide events, an Android malware can rely on the built-in support of automated event notification\r\nand callbacks on Android to flexibly trigger or launch its payloads. For simplicity, we abbreviate some frequently-used Android events in Table III. For each malware family in our dataset, we also report related events in Table II.\r\nhttp://ieeexplore.ieee.org/document/6234407\r\nPage 7 of 18\n\nTable III The (Abbreviated) Android Events/Actions of Interest to Existing Malware\r\nTable III- The (Abbreviated) Android Events/Actions of Interest to Existing Malware\r\nAmong all available system events, BOOT_COMPLETED is the most interested one to existing Android\r\nmalware. This is not surprising as this particular event will be triggered when the system finishes its booting\r\nprocess - a perfect timing for malware to kick off its background services. In our dataset, 29 (with 83.3% of the\r\nsamples) malware families listen to this event. For instance, Geinimi (SHA1:\r\n179e1c69ceaf2a98fdca1817a3f3f1fa28236b13) listens to this event to bootstrap the background service -\r\ncom.geinimi. AdService.\r\nThe SMS_RECEIVED comes second with 21 malware families interested in it. This is also reasonable as many\r\nmalware will be keen in intercepting or responding incoming SMS messages. As an example, zSone listens to this\r\nSMS_RECEIVED event and intercepts or removes all SMS message from particular originating numbers such as\r\n“10086” and “10010.”\r\nDuring our analysis, we also find that certain malware registers for a variety of events. For example, AnserverBot\r\nregisters for callbacks from 10 different events while BaseBridge is interested in 9 different events. The\r\nregistration of a large number of events is expected to allow the malware to reliably or quickly launch the carried\r\npayloads.\r\nIn addition, we also observe some malware samples directly hijack the entry activity of the host apps, which will\r\nbe triggered when the user clicks the app icon on the home screen or an intent with action ACTION_MAIN is\r\nreceived by the app. The hijacking of the entry activity allows the malware to immediately bootstrap its service\r\nbefore starting the host app's primary activity. For example, DroidDream (SHA1 :\r\nfdf6509b4911485b3f4783a72fde5c27aa9548c7) replaces the original entry activity with its own\r\ncom.android.root.main so that it can gain control even before the original activity\r\ncom.codingcaveman.SoloTrial.SplashActivity is launched. Some malware may also hijack certain UI interaction\r\nevents (e.g., button clicking). An example is the zSone malware (SHA1:\r\n00d6e661f90663eeffc10f64441b17079ea6f819) that invokes its own SMS sending code inside the onClick()\r\nfunction of the host app.\r\nC. Malicious Payloads\r\nAs existing Android malware can be largely characterized by their carried payloads, we also survey our dataset\r\nand partition the payload functionalities into four different categories: privilege escalation, remote control,\r\nfinancial charges, and personal information stealing.\r\n1) Privilege Escalation\r\nThe Android platform is a complicated system that consists of not only the Linux kernel, but also the entire\r\nAndroid framework with more than 90 open-source libraries included, such as WebKit, SQLite, and OpenSSL.\r\nThe complexity naturally introduces software vulnerabilities that can be potentially exploited for privilege\r\nescalation. In Table IV, we show the list of known Android platform-level vulnerabilities that can be exploited for\r\nhttp://ieeexplore.ieee.org/document/6234407\r\nPage 8 of 18\n\nprivilege exploitations. Inside the table, we also show the list of Android malware that actively exploit these\r\nvulnerabilities to facilitate the execution of their payloads.\r\nTable IV The List of Platform-Level Root Exploits and Their Uses in Existing android Malware\r\nTable IV- The List of Platform-Level Root Exploits and Their Uses in Existing android Malware\r\nOverall, there are a small number of platform-level vulnerabilities that are being actively exploited in the wild.\r\nThe top three exploits are exploid, RATC (or RageAgainstTheCage), and Zimperlich. We point out that if the\r\nRATC exploit is launched within a running app, it is effectively exploiting the bug in the zygote daemon, not the\r\nintended adbd daemon, thus behavoring as the Zimperlich exploit. Considering the similar nature of these two\r\nvulnerabilities, we use RATC to represent both of them.\r\nFrom our analysis, one alarming result is that among 1260 samples in our dataset, 463 of them (36.7%) embed at\r\nleast one root exploit (Table V). In terms of the popularity of each individual exploit, there are 389, 440, 4, and 8\r\nsamples that contain exploid, RATC, GingerBreak, and asroot, respectively. Also, it is not uncommon for a\r\nmalware to have two or more root exploits to maximize its chances for successful exploitations on multiple\r\nplatform versions. (In our dataset, there are 378 samples with more than one root exploit.)\r\nTable V An Overview of Existing Android Malware (Part II: Malicious Payloads)\r\nTable V- An Overview of Existing Android Malware (Part II: Malicious Payloads)\r\nA further investigation on how these exploits are actually used shows that many earlier malware simply copy\r\nverbatim the publicly available root exploits without any modification, even without removing the original debug\r\noutput strings or changing the file names of associated root exploits. For example, DroidDream contains the\r\nexploid file name exactly the same as the publicly available one. However, things have been changed recently. For\r\nexample, DroidKungFu does not directly embed these root exploits. Instead it first encrypts these root exploits\r\nand then stores them as a resource or asset file. At runtime, it dynamically uncovers these encrypted root exploits\r\nand then executes them properly, which makes their detection very challenging. In fact, when the first version of\r\nDroidKungFu was discovered, it has been reported that no single existing mobile antivirus software at that time\r\nwas able to detect it, which demonstrated the “effectiveness” of this approach. Moreover, other recent malware\r\nsuch as DroidCoupon and GingerMaster apparently obfuscate the file names of the associated root exploits (e.g.,\r\nby pretending as picture files with png suffix). We believe these changes reflect the evolving nature of malware\r\ndevelopment and the ongoing arms race for malware defense (Section IV).\r\n2) Remote Control\r\nDuring our analysis to examine the remote control functionality among the malware payloads, we are surprised to\r\nnote that 1, 172 samples (93.0%) turn the infected phones into bots for remote control. Specifically, there are 1,\r\n171 samples that use the HTTP-based web traffic to receive bot commands from their C\u0026C servers.\r\nWe also observe that some malware families attempt to be stealthy by encrypting the URLs of remote C\u0026C\r\nservers as well as their communication with C\u0026C servers. For example, Pjapps uses its own encoding scheme to\r\nencrypt the C\u0026C server addresses. One of its samples (SH1: 663e8eb52c7b4a14e2873b1551748587018661b3)\r\nencodes its C\u0026C server mobilemeego91.com into 2maodb3ialke8mdeme3gkos9g1icaofm. DroidKungFu3\r\nhttp://ieeexplore.ieee.org/document/6234407\r\nPage 9 of 18\n\nemploys the standard AES encryption scheme and uses the key Fuck_sExy-aL1!Pw to hide its C\u0026C servers.\r\nGeinimi similarly applies DES encryption scheme (with the key 0x0102030405060708) to encrypt its\r\ncommunication to the remote C\u0026C server.\r\nDuring our study, we also find that most C\u0026C servers are registered in domains controlled by attackers\r\nthemselves. However, we also identify cases where the C\u0026C servers are hosted in public clouds. For instance, the\r\nPlankton spyware dynamically fetches and runs its payload from a server hosted on the Amazon cloud. Most\r\nrecently, attackers are even turning to public blog servers as their C\u0026C servers. AnserverBot is one example that\r\nuses two popular public blog services, i.e., Sina and Baidu, as its C\u0026C servers to retrieve the latest payloads and\r\nnew C\u0026C URLs (Section IV).\r\n3) Financial Charge\r\nBeside privilege escalation and remote control, we also look into the motivations behind malware infection. In\r\nparticular, we study whether malware will intentionally cause financial charges to infected users.\r\nOne profitable way for attackers is to surreptitiously subscribe to (attacker-controlled) premium-rate services, such\r\nas by sending SMS messages. On Android, there is a permission-guarded function sendTextMessage that allows\r\nfor sending an SMS message in the background without user's awareness. We are able to confirm this type of\r\nattacks targeting users in Russia, United States, and China. The very first Android malware FakePlayer sends SMS\r\nmessage “798657” to multiple premium-rate numbers in Russia. GGTracker automatically signs up the infected\r\nuser to premium services in US without user's knowledge. zSone sends SMS messages to premium-rate numbers\r\nin China without user's consent. In total, there are 55 samples (4.4%) falling in 7 different families (tagged with ‡\r\nin Table V) that send SMS messages to the premium-rate numbers hardcoded in the infected apps.\r\nMoreover, some malware choose not to hard-code premium-rate numbers. Instead, they leverage the flexible\r\nremote control to push down the numbers at runtime. In our dataset, there are 13 such malware families (tagged\r\nwith t in Table V). Apparently, these malware families are more stealthy than earlier ones because the destination\r\nnumber will not be known by simply analyzing the infected apps.\r\nIn our analysis, we also observe that by automatically subscribing to premium-rate services, these malware\r\nfamilies need to reply to certain SMS messages. This may due to the second-confirmation policy required in some\r\ncountries such as China. Specifically, to sign up a premium-rate service, the user must reply to a confirming SMS\r\nmessage sent from the service provider to finalize or activate the service subscription. To avoid users from being\r\nnotified, they will take care of replying to these confirming messages by themselves. As an example,\r\nRogueSPPush will automatically reply “Y” to such incoming messages in the background; GGTracker will reply\r\n“YES” to one premium number, 99735, to active the subscribed service. Similarly, to prevent users from knowing\r\nsubsequent billing-related messages, they choose to filter these SMS messages as well. This behavior is present in\r\na number of malware, including zSone, RogueSPPush, and GGTracker.\r\nBesides these premium-rate numbers, some malware also leverage the same functionality by sending SMS\r\nmessages to other phone numbers. Though less serious than previous ones, they still result in certain financial\r\ncharges especially when the user does not have an unlimited messaging plan. For example, DogWars sends SMS\r\nmessages to all the contacts in the phone without user's awareness. Other malware may also make background\r\nhttp://ieeexplore.ieee.org/document/6234407\r\nPage 10 of 18\n\nphone calls. With the same remote control capability, the destination number can be provided from a remote C\u0026C\r\nserver, as shown in Geinimi.\r\n4) Information Collection\r\nIn addition to the above payloads, we also find that malware are actively harvesting various information on the\r\ninfected phones, including SMS messages, phone numbers as well as user accounts. In particular, there are 13\r\nmalware families (138 samples) in our dataset that collect SMS messages, 15 families (563 samples) gather phone\r\nnumbers, and 3 families (43 samples) obtain and upload the information about user accounts. For example,\r\nSndApps collects users' email addresses and sends them to a remote server. FakeNetflix gathers users' Netflix\r\naccounts and passwords by providing a fake but seeming identical Netflix UI.\r\nWe consider the collection of users' SMS messages is a highly suspicious behavior. The user credential may be\r\nincluded in SMS messages. For example, both Zitmo (the Zeus version on Android) and Spitmo (the SpyEpy\r\nversion on Android) attempt to intercept SMS verification messages and then upload them to a remote server. If\r\nsuccessful, the attacker may use them to generate fraudulent transactions on behalf of infected users.\r\nD. Permission Uses\r\nFor Android apps without root exploits, their capabilities are strictly constrained by the permissions users grant to\r\nthem. Therefore, it will be interesting to compare top permissions requested by these malicious apps in the dataset\r\nwith top permissions requested by benign ones. To this end, we have randomly chosen 1260 top free apps\r\ndownloaded from the official Android Market in the first week of October, 2011. The results are shown in Figure\r\n5.\r\nFigure 5. - The Comparison of Top 20 Requested Permissions by Malicious and Benign Apps\r\nFigure 5.\r\nThe Comparison of Top 20 Requested Permissions by Malicious and Benign Apps\r\nBased on the comparison, INTERNET, READ_PHONE_STATE, ACCESS_NETWORK_STATE, and\r\nWRITE_EXTERNAL_STORAGE permissions are widely requested in both malicious and benign apps. The first\r\ntwo are typically needed to allow for the embedded ad libraries to function properly. But malicious apps clearly\r\ntend to request more frequently on the SMS-related permissions, such as READ_SMS, WRITE_SMS,\r\nRECEIVE_SMS, and SEND_SMS. Specifically, there are 790 samples (62.7%) in our dataset that request the\r\nREAD_SMS permission, while less than 33 benign apps (or 2.6%) request this permission. These results are\r\nconsistent with the fact that 28 malware families in our dataset (or 45.3% of the samples) that have the SMS-related malicious functionality.\r\nAlso, we observe 688 malware samples request the RECEIVE_BOOT_COMPLETED permission. This number is\r\nfive times of that in benign apps (137 samples). This could be due to the fact that malware is more likely to run\r\nbackground services without user's intervention. Note that there are 398 malware samples requesting\r\nCHANGE_WIFI_STATE permission, which is an order of magnitude higher than that in benign apps (34\r\nhttp://ieeexplore.ieee.org/document/6234407\r\nPage 11 of 18\n\nsamples). That is mainly because the Exploid root exploit requires certain hot plug events such as changing the\r\nWIFI state, which is related to this permission.\r\nFinally, we notice that malicious apps tend to request more permissions than benign ones. In our dataset, the\r\naverage number of permissions requested by malicious apps is 11 while the average number requested by benign\r\napps is 4. Among the top 20 permissions, 9 of them are requested by malicious apps on average while 3 of them\r\non average are requested by benign apps.\r\nSECTION IV.\r\nMalware Evolution\r\nAs mentioned earlier, since summer of 2011, we have observed rapid growth of Android malware. In this section,\r\nwe dive into representative samples and present a more indepth analysis of their evolution. Specifically, we choose\r\nDroidKungFu (including its variants) and AnserverBot for illustration as they reflect the current trend of Android\r\nmalware growth.\r\nA. DroidKungFu\r\nThe first version of DroidKungFu (or DroidKungFu1) malware was detected by our research team [30] in June\r\n2011. It was considered one of the most sophisticated Android malware at that time. Later on, we further detected\r\nthe second version DroidKungFu2 and the third version DroidKungFu3 in July and August, respectively. The\r\nfourth version DroidKungFu4 was detected by other researchers in October 2011 [31]. Shortly after that, we also\r\ncame across the fifth version DroidKungFuSapp, which is still a new variant not being detected yet by existing\r\nmobile antivirus software (Section V). In the meantime, there is another variant called DroidKungFuUpdate [32]\r\nthat utilizes the update attack (Section III). In Table VI, we summarize these six DroidKungFu variants. In total\r\nthere are 473 DroidKungFu malware samples in our dataset.\r\nTable VI The Overview of Six DroidKungFu Malware Families\r\nTable VI- The Overview of Six DroidKungFu Malware Families\r\nThe emergence of these DroidKungFu variants clearly demonstrates the current rapid development of Android\r\nmalware. In the following, we zoom in various aspects of DroidKungFu malware.\r\n1) Root Exploits\r\nAmong these six variants, four of them contain encrypted root exploits. Some of these encrypted files are located\r\nunder the directory “assets”, which look like normal data files. To the best of our knowledge, DroidKungFu is the\r\nfirst time we have observed in Android malware to include encrypted root exploits.\r\nThe use of encryption is helpful for DroidKungFu to evade detection. And different variants tend to use different\r\nencryption keys to better protect themselves. For example, the key used in DroidKungFu1 is Fuck_sExy-aL1!Pw,\r\nwhich has been changed to Stak_yExy-eLt!Pw in DroidKungFu4.\r\nhttp://ieeexplore.ieee.org/document/6234407\r\nPage 12 of 18\n\nIt is interesting to notice that in DroidKungFu1, the file name with the encrypted root exploit is “rate” - the\r\nacronym of RageAgainstTheCage. In DroidKungFu2 and DroidKungFu3, this file name with the same root\r\nexploit has been changed to “myicon”, pretending to be an icon file.\r\n2) C\u0026C Servers\r\nAll DroidKungFu variants have a payload that communicates with remote C\u0026C servers and receives the\r\ncommands from them. Our investigation shows that the malware keeps changing the ways to store the C\u0026C server\r\naddresses. For example, in DroidKungFu1, the C\u0026C server is saved in plain-text in a Java class file. In\r\nDroidKungFu2, this C\u0026C server address is moved to a native program in plaintext. Also, remote C\u0026C servers\r\nhave been increased from 1 to 3. In DroidKungFu3, it encrypts the C\u0026C server addresses in a Java class file. In\r\nDroidKungFu4, it moves the C\u0026C address back to a native program as DroidKungFu2 but in cipertext. In\r\nDroidKungFuSapp, we observe using a new C\u0026C server and a different home-made encryption scheme.\r\n3) Shadow Payloads\r\nDroidKungFu also carries with itself an embedded app, which will be stealthily installed once the root exploit is\r\nsuccessfully launched. As a result, the embedded app will be installed without user's awareness. An examination\r\nof this embedded app code shows that it is almost identical to the malicious payload DroidKungFu adds to the\r\nrepackaged app. The installation of this embedded app will ensure that even the repackaged app has been\r\nremoved, it can continue to be functional. Moreover, in DroidKungFu1, the embedded app will show a fake\r\nGoogle Search icon while in DroidKungFu2, the embedded app is encrypted and will not display any icon on the\r\nphone.\r\n4) Obfuscation, JNI, and Others\r\nAs briefly mentioned earlier, DroidKungFu heavily makes use of encryption to hide its existence. Geinimi is an\r\nearlier malware that encrypts the constant strings to make it hard to analyze. DroidKungFu instead encrypts not\r\nonly those constant strings and C\u0026C servers, but also those native payloads and the embedded app file. Moreover,\r\nit rapidly changes different keys for the encryption, aggressively obfuscates the class name in the malicious\r\npayload, and exploits JNI interfaces to increase the difficulty for analysis and detection. For example, both\r\nDroidKungFu2 and DroidKungFu4 uses a native program (through JNI) to communicate with and fetch bot\r\ncommands from remote servers.\r\nThe latest version, i.e., DroidKungFuUpdate, employs the update attack. With its stealthiness, it managed into the\r\nofficial Android Market for users to download, reflecting the evolution trend of Android malware to be more\r\nstealthy in their design and infection.\r\nB. AnserverBot\r\nAnserverBot was discovered in September 2011. This malware piggybacks on legitimate apps and is being\r\nactively distributed among a few third-party Android Markets in China. The malware is considered one of the\r\nmost sophisticated Android malware as it aggressively exploits several sophisticated techniques to evade detection\r\nand analysis, which has not been seen before. Our full investigation of this malware took more than one week to\r\nhttp://ieeexplore.ieee.org/document/6234407\r\nPage 13 of 18\n\ncomplete. After the detailed analysis [33], we believe this malware evolves from earlier BaseBridge malware. In\r\nthe following, we will highlight key techniques employed by AnserverBot. Our current dataset has 187\r\nAnserverBot samples.\r\n1) Anti-Analysis\r\nThough AnserverBot repackages existing apps for infection, it aims to protect itself by actively detecting whether\r\nthe repackaged app has been tampered with or not. More specifically, when it runs, it will check the signature or\r\nthe integrity of the current (repackaged) app before unfolding its payloads. This mechanism is in place to thwart\r\npossible reverse engineering efforts.\r\nMoreover, AnserverBot aggressively obfuscates its inter-nal classes, methods, and fields to make them humanly\r\nunreadable. Also, it intentionally partitions the main payload into three related apps: one is the host app and the\r\nother twos are embedded apps. The two embedded apps share the same name com.sec.android.touchScreen.server\r\nbut with different functionality. One such app will be installed through the update attack while the other will be\r\ndynamically loaded without being actually installed (similar to Plankton). The functionality partitioning and\r\ncoordination, as well as aggressive obfuscation, make its analysis very challenging.\r\nWe have the reason to believe that AnserverBot is inspired by the dynamic loading mechanism from Plankton. In\r\nparticular, the dynamic mechanisms to retrieve and load remote code is not available in earlier BaseBridge\r\nmalware. In other words, it exploits the class loading feature in Dalvik virtual machine to load and execute the\r\nmalicious payload at run time. By employing this dynamic loading behavior, AnserverBot can greatly protect itself\r\nfrom being detected by existing antivirus software (Section V). Moreover, with such dynamic capability in place,\r\nmalware authors can instantly upgrade the payloads while still taking advantage of current infection base.\r\n2) Security Software Detection\r\nAnother related self- protection feature used in AnserverBot is that it can de- tect the presence of certain mobile\r\nantivirus software. In particular, it contains the encrypted names of three mobile antivirus software, i.e.,\r\ncom.qihoo360.mobilesafe, com.tencent.qqpimsecure and com.lbe.security, and attempts to match them with those\r\ninstalled apps on the phone. If any of the three antivirus software is detected, AnserverBot will attempt to stop it\r\nby calling the restartPackage method and displaying a dialog window informing the user that the particular app is\r\nstopped unexpectedly.\r\n3) C\u0026C Servers\r\nOne interesting aspect of AnserverBot is its C\u0026C servers. In particular, it supports two types of C\u0026C servers. The\r\nfirst one is similar to traditional C\u0026C servers from which to receive the command. The second one instead is used\r\nto upgrade its payload and/or the new address of the first type C\u0026C server. Surprisingly, the second type is based\r\non (encrypted) blog contents, which are maintained by popular blog service providers (i.e., Sina and Baidu). In\r\nother words, AnserverBot connects to the public blog site to fetch the (encrypted) current C\u0026C server and the new\r\n(encrypted) payload. This functionality can ensure that even if the first type C\u0026C server is offline, the new C\u0026C\r\nserver can still be pushed to the malware through this public blog, which is still active as of this writing.\r\nhttp://ieeexplore.ieee.org/document/6234407\r\nPage 14 of 18\n\nSECTION V.\r\nMalware Detection\r\nThe rapid growth and evolution of recent Android malware pose significant challenges for their detection. In this\r\nsection, we attempt to measure the effectiveness of existing mobile antivirus software. To this end, we choose four\r\nrepresentative mobile antivirus software, i.e., AVG Antivirus Free v2.9 (or AVG), Lookout Security \u0026 Antivirus\r\nv6.9 (or Lookout), Norton Mobile Security Lite v2.5.0.379 (Norton), and TrendMicro Mobile Security Personal\r\nEdition v2.0.0.1294 (TrendMicro) and download them from the official Android Market in the first week of\r\nNovember 2011.\r\nWe install each of them on a separate Nexus One phone running Android version 2.3.7. Before running the\r\nsecurity app, we always update it with the latest virus database. In the test, we apply the default setting and enable\r\nthe real-time protection. After that, we create a script that iterates each app in our dataset and then installs it on the\r\nphone. We will wait for 30 seconds for the detection result before trying the next app. If detected, these antivirus\r\nsoftware will pop up an alert window, which will be recorded by our script. After the first iteration, we further\r\nenable the second-round scanning of those samples that are not detected in the first round. In the second round, we\r\nwill wait for 60 seconds to make sure that there is enough time for these security software to scan the malware.\r\nThe scanning results are shown in Table VII. In the table, the first two columns list the malware family and the\r\nnumber of the samples in this malware family. The rest columns show the number of samples as well as the\r\npercentage being detected by the corresponding security software. At the end of the table, we show the number of\r\ndetected samples for each antivirus software and its corresponding detection rate. The results are not encouraging:\r\nLookout detected 1003 malware samples in 39 families; TrendMicro detected 966 samples in 42 families; AVG\r\ndetected 689 samples in 32 families; and Norton detected the least samples (254) in 36 families.\r\nTable VII Detection Results From Four Representative Mobile Anti-Virus Software\r\nTable VII- Detection Results From Four Representative Mobile Anti-Virus Software\r\nApparently, these security software take different approaches in their design and implementation, which lead to\r\ndifferent detection ratio even for the same malware family. For example, AVG detects all ADRD samples in our\r\ndataset, while Lookout detects 59.0% of them. Also, Lookout detects most of DroidKungFu3 samples and all\r\nDroidKungFu4 samples while AVG can detect none of them (0.0%) or few of them (4.1%).\r\nThere are some malware families that completely fail these four mobile security software. Examples are BeanBot,\r\nCoinPirate, DroidCoupon, DroidKungFuSapp, NickyBot and RogueLemon. One reason is that they are relatively\r\nnew (discovered from August to October 2011). Therefore, existing mobile antivirus companies may not get a\r\nchance to obtain a copy of these samples or extract their signatures. From another perspective, this does imply that\r\nthey are still taking traditional approaches to have a signature database that represents known malware samples.\r\nAs a result, if the sample is not available, it is very likely that it will not be detected.\r\nOur characterization of existing Android malware and an evolution-based study of representative ones clearly\r\nreveal a serious threat we are facing today. Unfortunately, existing popular mobile security software still lag\r\nbehind and it becomes imperative to explore possible solutions to make a difference.\r\nhttp://ieeexplore.ieee.org/document/6234407\r\nPage 15 of 18\n\nFirst, our characterization shows that most existing Android malware (86.0%) repackage other legitimate\r\n(popular) apps, which indicates that we might be able to effectively mitigate the threat by policing existing\r\nAndroid Markets for repackaging detection. However, the challenges lie in the large volume of new apps created\r\non a daily basis as well as the accuracy needed for repackaging detection. In addition, the popularity of alternative\r\nAndroid Markets will also add significant challenges. Though there is no clear solution in sight, we do argue for a\r\njoint effort involving all parties in the ecosystem to spot and discourage repackaged apps.\r\nSecond, our characterization also indicates that more than one third (36.7%) of Android malware enclose\r\nplatform-level exploits to escalate their privilege. Unfortunately, the open Android platform has the well-known\r\n“fragmentation” problem, which leads to a long vulnerable time window of current mobile devices before a patch\r\ncan be actually deployed. Worse, the current platform still lacks many desirable security features. ASLR was not\r\nadded until very recently in Android 4.0. Other security features such as TrustZone and eXecute-Never need to be\r\ngradually rolled out to raise the bar for exploitation. Moreover, our analysis reveals that the dynamic loading\r\nability of both native code and Dalvik code are being actively abused by existing malware (e.g., DroidKungFu and\r\nAnserverBot). There is a need to develop effective solutions to prevent them from being abused while still\r\nallowing legitimate uses to proceed.\r\nThird, our characterization shows that existing malware (45.3%) tend to subscribe to premium-rate services with\r\nbackground SMS messages. Related to that, most existing malware intercept incoming SMS messages (e.g., to\r\nblock billing information or sidestep the second-confirmation requirement). This problem might be rooted in the\r\nlack of fine-grain control of related APIs (e.g., sendTextMessage). Specifically, the coarse-grained Android\r\npermission model can be possibly expanded to include additional context information to better facilitate users to\r\nmake sound and informed decisions.\r\nFourth, the detection results of existing mobile security software are rather disappointing, which does raise a\r\nchallenging question on the best model for mobile malware detection. Specifically, the unique runtime\r\nenvironments with limited resources and battery could preclude the deployment of sophisticated detection\r\ntechniques. Also, the traditional content-signature-based approaches have been demonstrated not promising at all.\r\nFrom another perspective, the presence of centralized marketplaces (including alternative ones) does provide\r\nunique advantages in blocking mobile malware from entering the marketplaces in the first place.\r\nLast but not least, during the process of collecting malware samples into our current dataset, we felt confusions\r\nfrom disorganized or confusing naming schemes. For example, BaseBridge has another name AdSMS (by\r\ndifferent antivirus companies); ADRD is the alias of Hongtoutou; and LeNa is actually a DroidKungFu variant.\r\nOne possible solution may follow the common naming conventions used in desktop space, which calls for the\r\ncooperation from different mobile security software vendors.\r\nSmartphone security and privacy has recently become a major concern. TaintDroid [34] and PiOS [35] are two\r\nsystems that expose possible privacy leaks on Android and iOS, respectively. Comdroid [36] [37] and Woodpecker\r\n[38] expose the confused deputy problem [39] on Android. Accordingly, researches have proposed several\r\npossible solutions [37] [40] [41] to this issue. Stowaway [42] exposes the over-privilege problem (where an app\r\nrequests more permissions than it uses) in existing apps. Schrittwieser et al. [43] reports that certain security flaws\r\nexist in recent network-facing messaging apps. Traynor et al. [44] characterizes the impact of mobile botnet on the\r\nmobile network. AdRisk [45] systematically identifies potential risks from in-app advertisement libraries. Our\r\nhttp://ieeexplore.ieee.org/document/6234407\r\nPage 16 of 18\n\nwork is different from them with a unique focus on systematically characterizing existing Android malware in the\r\nwild.\r\nTo improve the smartphone security and privacy, a number of platform-level extensions have been proposed.\r\nSpecifically, Apex [46], MockDroid [47], TISSA [48] and AppFence [49] extend the current Android framework\r\nto provide find-grained controls of system resources accessed by untrusted third-party apps. Saint [50] protects the\r\nexposed interfaces of an app to others by allowing the app developers to define related security policies for\r\nruntime enforcement. Kirin [51] blocks the installation of suspicious apps by examining the existence of certain\r\ndangerous permission combination. L4Android [52] and Cells [53] run multiply OSes on a single smartphone for\r\nimproved isolation and security. Note that none of them characterizes (or studies the evolution of) existing\r\nAndroid malware, which is the main focus of this work.\r\nAmong the most related, Felt et al. [54] surveys 46 malware samples on three different mobile platforms, i.e.,\r\niOS, Android and Symbian, analyzes their incentives, and discusses possible defenses. In contrast, we examine a\r\nmuch larger dataset (with 1,260 malware samples in 49 different families) on one single popular platform -\r\nAndroid. The size of our dataset is instrumental to systematically characterizing malware infection behavior and\r\nunderstanding their evolution. Moreover, the subsequent test of existing mobile security software further\r\nnecessitates a change for effective anti-mobile-malware solutions.\r\nFrom another perspective, Becher et al. [55] provides a survey of mobile network security, from the hardware\r\nlayer to the user-centric attacks. DroidRanger [56] detects malicious apps in existing official and alternative\r\nAndroid Markets. DroidMOSS [57] uses the fuzzy hashing to detect the repackaged apps (potential malware) in\r\nthird-party android markets. Enck et al. [58] studies 1,100 top free (benign) Android apps to better understand the\r\nsecurity characteristics of these apps. Our work differs from them by focusing on 1, 260 malicious apps\r\n(accumulated from more than one year effort) and presenting a systematic study of their installation, activation,\r\nand payloads.\r\nIn this paper, we present a systematic characterization of existing Android malware. The characterization is made\r\npossible with our more than one-year effort in collecting 1260 Android malware samples in 49 different families,\r\nwhich covers the majority of existing Android malware, ranging from its debut in August 2010 to recent ones in\r\nOctober 2011. By characterizing these malware samples from various aspects, our results show that (1) 86.0% of\r\nthem repackage legitimate apps to include malicious payloads; (2) 36.7% contain platform-level exploits to\r\nescalate privilege; (3) 93.0% exhibit the bot-like capability. A further indepth evolution analysis of representative\r\nAndroid malware shows the rapid development and increased sophistication, posing significant challenges for\r\ntheir detection. Sadly, the evaluation with four existing mobile antivirus software shows that the best case detects\r\n79.6% of them while the worst case detects only 20.2%. These results call for the need to better develop next-generation anti-mobile-malware solutions.\r\nACKNOWLEDGMENT\r\nWe would like to thank our shepherd, Patrick Traynor, and the anonymous reviewers for their comments that\r\ngreatly helped improve the presentation of this paper. We also want to thank Michael Grace, Zhi Wang, Wu Zhou,\r\nDeepa Srinivasan, Minh Q. Tran, and Lei Wu for the helpful discussion. This work was supported in part by the\r\nUS National Science Foundation (NSF) under Grants 0855297, 0855036, 0910767, and 0952640. Any opinions,\r\nhttp://ieeexplore.ieee.org/document/6234407\r\nPage 17 of 18\n\nfindings, and conclusions or recommendations expressed in this material are those of the authors and do not\r\nnecessarily reflect the views of the NSF.\r\nSource: http://ieeexplore.ieee.org/document/6234407\r\nhttp://ieeexplore.ieee.org/document/6234407\r\nPage 18 of 18",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"origins": [
		"web"
	],
	"references": [
		"http://ieeexplore.ieee.org/document/6234407"
	],
	"report_names": [
		"6234407"
	],
	"threat_actors": [],
	"ts_created_at": 1775434220,
	"ts_updated_at": 1775826744,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/be2aef2c6a000173de2b1ac72717eac0af2acc5a.pdf",
		"text": "https://archive.orkl.eu/be2aef2c6a000173de2b1ac72717eac0af2acc5a.txt",
		"img": "https://archive.orkl.eu/be2aef2c6a000173de2b1ac72717eac0af2acc5a.jpg"
	}
}