A Study of the Effectiveness Abs Reliability of Android Free Anti-Mobile Malware Apps
J. Walls*; K.-K.R. Choo*,† * University of South Australia, Adelaide, SA, Australia
† University of Texas at San Antonio, San Antonio, TX, United States
Abstract
With the increasing popularity of Android devices and the number of malware apps targeting them, ensuring the security and privacy of user data and preventing the device from being compromised are of paramount importance. In this chapter, we survey Android-related security risks and vulnerabilities, as well as conduct a systematic evaluation of 15 popular free antimalware apps using 11 known malware samples collected between Feb. 27, 2014 and Aug. 3, 2014 from the Contagio Mobile Malware Mini Dump database. By conducting a manual experiment to replicate potential day-to-day threats to users unknowingly installing malicious apps (i.e., malware samples), the evaluation produced results that varied significantly across all three Android operating systems and hardware test devices. We hope the findings will contribute to a better understanding of the effectiveness and reliability of such apps for Android devices, as well as improved antimalware apps and detection rates.
Keywords
Android apps; Android antimalware apps; Malicious app detection; Mobile malware apps; Mobile threats
1 Introduction
Smartphones are popular for both personal and corporate use, and they are becoming the new personal computer due to their portability, ease of use, and functionality (e.g., video conferencing, Internet browsing, email correspondence, persistent wireless and data connectivity, worldwide map location services, and countless mobile apps). It is, therefore, not surprising that the number of smartphone devices reached 336 million units worldwide, which was an increase of 19.3% in the first quarter of 2015. Continued growth is expected throughout 2015 and 2016, particularly for devices running Android operating system (OS). The latter's worldwide market share is 78.9% at the end of the first quarter 2015. With a majority of the smartphone market share worldwide, the Android OS also surpassed a billion shipments of devices in 2014 (Rivera and Goasduff, 2015; Rivera and van der Meulen, 2015).
Given the flexibility and ease of operation that mobile OS permits, hardware manufacturers are able to develop faster and more powerful devices that incorporate a wide range of functionalities for everyday use; for example, larger display screens, integrated browsing, media support for video, audio and images, a gyroscope and other real-world sensors, access to Global System for Mobile Communications (GSM), Enhanced Data for GSM Evolution (EDGE), 3G, 4G Long-Term Evolution (LTE) data, Bluetooth, Wi-Fi, a built-in digital camera, and Global Positioning System (GPS) components.
Vulnerabilities in hardware and software functionalities can, however, be exploited by criminals. Examples include “phishing” attacks facilitated by mobile apps, such as instant messaging apps (see Chu et al., 2013). Apps can be designed to provide access to sensitive user data (e.g., contact lists and geolocation information) should the permissions be granted by the user. Unfortunately, with the openness and widespread adoption of the Android OS, the platform is the most targeted of the four popular mobile platforms by malware authors (Symantec Corporation, et al., 2014; APWG, 2013). Another recent study of mobile malware, for example, reported that “Android devices are currently the most targeted, accounting for 60% of the infections observed in the mobile network” (Alcatel-Lucent, 2013, p. 7), and examples of mobile malware targeting Android devices including Android.Ackposts, a malicious mobile app (also known as “Battery Long”) designed to steal personal data from a compromised device and upload details to a remote server, were detected (Symantec Intelligence, 2012). Other malware includes short message service (SMS) Trojan viruses, false advertising modules that contain malware, and sophisticated web-based malware that use various exploits in order to gain root access.
In this chapter, we investigate the effectiveness and reliability of 15 popular free antimobile malware apps in detecting malware on three Android devices running three different Android flavors, namely KitKat (4.4.x), Jelly Bean (4.1.x), and Ice Cream Sandwich (4.0.x). Two newer Android flavors were also taken into consideration, specifically Lollipop (5.x), which was released in late 2014, and Marshmallow (6.0), which was released in late 2015. However, the relative number of devices running Lollipop (23.5% distribution) and Marshmallow (distribution not currently available) were considerably lower than that of earlier versions, such as KitKat, where distribution is 38.9% (Dashboards as of Oct. 11, 2015, Android Developers Dashboards, 2015). Along with higher distribution across multiple devices, KitKat, Jelly Bean, and Ice Cream Sandwich demonstrate enough history and stability for this study, whereas Lollipop and Marshmallow would have too much flux and unknown variables; thus they were not included within this study and are subject to further analysis. This is, to the best of our knowledge, the first academic systematic study that has been conducted through a manual experiment process of 15 popular free antimalware apps for Android devices. Our findings will contribute to a better understanding of the effectiveness and reliability of such apps for Android devices, and it potentially serves as a guide for future antimalware app developers.
The chapter is organized as follows: In Section 2, we present an overview of Android OS and app security and describe the malware threats and existing countermeasures. Our experiment setup and findings are presented in Sections 3 and 4, respectively. Section 3 outlines the experiment process in detail, in which 15 popular free antimalware apps are measured against a suit of 15 known malware samples. Each test will be performed manually to replicate a day-to-day user who unknowingly installs a malicious app. The results will hopefully demonstrate the effectiveness and reliability of how well the antimalware app performed. After the experiment process, Section 4 outlines the findings of all the test results against their respective metric values, which allow for possible analysis of particular performance issues and their improvements. The last section concludes this chapter and discusses future research topics.
2 An Overview of Android
2.1 The Android OS
2.1.1 System Framework and Architecture
A major advantage of the Android OS is that it is part of the Open Handset Alliance (OHA) consortium, which provides flexibility for device manufacturers and software and app developers, as the environment has fewer restrictions and compatibility issues across multiple hardware devices. The core building blocks of the Android software platform, which is based on the open-source Linux OS and uses the Linux Kernel, have been modified specifically for smartphones (Nimodia and Deshmukh, 2012).
The Android OS system architecture comprises five main architecture layers, each with its own functionality and benefits for interoperability across different devices (Fig. 1). The Linux Kernel is the first layer, residing at the bottom of the architecture. It is considered to be the core layer, as it includes all physical-level operations, such as hardware device drivers. The remaining layers build on the Linux Kernel and perform their own functions. The second layer is Libraries, where native libraries are developed in C/C++ to ensure smooth OS functionality when accessing multiple apps at once. Additional features facilitate Internet-related functions and data storage, such as web browsing (Nimodia and Deshmukh, 2012).
The third layer is the Android Runtime (ART). This layer uses Java programming and operates its own virtual environment, Dalvik Virtual Machine (DVM), for developing Android apps. Application Framework is the fourth layer and comprises several individual components that manage various application frameworks, such as built-in default apps, including email and a web browser (e.g., open-source WebKit browser or Chrome in later versions). Due to the many components and its functionality, this is one of the main layers within the Android system framework (Nimodia and Deshmukh, 2012).
Finally, Applications is the fifth layer. This represents the top of the architecture, and it is where app downloads and installs are located (Nimodia and Deshmukh, 2012). These five layers make up the overall Kernel, and assist with the operation and functionality of the Android OS architecture as a whole.
Although these five underlying layers give Android OS immense development capabilities and allow developers to produce a variety of features and variables in their apps, security measures must be considered in order to help protect hardware devices, network resources, and software design, such as ensuring the security and privacy of user data and avoiding the exploitation of app privileges.
2.1.2 Security Architecture
Within the Linux Kernel, there are a number of security features in place throughout each of the five layers that have their own functions but work together by layering on top of each other to provide a security model. This enables the Android OS to become more secure and restrict access to core file system activities and storage locations, such as root system files. Some of these features include the following:
Linux Kernel—The fundamental purpose of the Kernel is a user-based permission model. Key security features include device encryption to prevent unauthorized access, independently isolating processes, the ability to remove unsecured or unnecessary sections of the kernel, and allow integration between the additional system layers. The Linux Kernel also refers to file system permissions, which isolate resources from one another; for example, preventing User A from altering User B's files. The Linux Kernel also provides an application sandbox environment within the libraries and ART layer (Vargas et al., 2012).
Libraries and ART—A primary security feature of the Android OS is the application sandbox environment, where the Linux Kernel enforces security between apps and the system so they are unable to interact with each other. This effectively isolates resources and data files from other apps by assigning each installed app a unique user ID (UID) and a group ID (GID). As in the example above, User A will not have the level of permission to alter User B's files (Vargas et al., 2012).
Application communication—As the security between apps and resources is isolated by default, interapp communication is possible by way of the application communication feature that uses an Inter-Process Communication (IPC) mechanism. Although there are additional functionalities with how IPC interacts, the basic principle is to gather the two main sections of information, one from the receiving end and one from where data shall be passed, which allows purposeful interaction (Ongtang et al., 2012).
Application permissions: Any installed app must have a digital signature, or security certificate, that validates the legitimacy of an app and confirms the app developer's details. As the user can verify the details of an app and review permissions, this minimizes the security risk of downloading and installing fake apps. Essential information about the permissions of an app can be found in the AndroidManifest.xml file, which is located in the root directory. This is an important security consideration because when an app is downloaded and the user accepts the permissions shown on the screen, a check can be made to verify these permissions through the AndroidManifest.xml file (Vargas et al., 2012; Pieterse and Olivier, 2012).
Although the Linux Kernel has different security features for each layer, these features have not been used in all version releases of the Android OS. New versions are becoming more frequent as development continues, contributing to the software improvements outlined in Table 1. For example, earlier Android versions, such as 2.3 (Gingerbread), have a less advanced security model compared with that of newer versions, such as 4.3 (Jelly Bean). Unfortunately, earlier OS versions on older hardware devices will not receive any software updates, as a hardware upgrade is required. This is mainly due to improved hardware and OS capabilities, where added software and security features have been introduced to support changes (Vargas et al., 2012). By not upgrading the hardware, users are unable to upgrade their Android OS and therefore become more susceptible to malicious attacks.
Table 1
Android Version History as of Oct. 11, 2015 (Amadeo, 2014; Android Developers Dashboards, 2015)
| OS Name | Version | Release Dates | Application Programming Interface (API) | Distribution | Key Features and Improvements |
| n.a. | 1.0 | Sep. 2008 | – | – | Initial release of Android with full handset functionality and features such as Android Market, Google Maps/Calendar/Contacts, Short Message Service (SMS)/Multimedia Messaging Service (MMS), telephony, web browser, email, video, camera, Wi-Fi, and Bluetooth capability |
| n.a. | 1.1 | Feb. 2009 | – | – | Maintenance release to 1.0 and device hardware |
| Cupcake | 1.5 | Apr. 2009 | – | – | Uses Linux Kernel 2.6.27; additions include screen rotation, various widget support, enhanced animation, predictive text and soft keyboard, browser update, Picasa introduction, and YouTube video uploads |
| Donut | 1.6 | Sep. 2009 | – | – | Uses Kernel 2.6.29; faster searching, picture and video gallery, battery indicator, text-to-speech, and new API framework |
| Eclair | 2.x | Oct. 2006–Jan. 2010 | – | – | Uses Kernel 2.6.29; introduces the use of multiple accounts, Google Maps navigation, calendar and contacts sync with Gmail/Exchange, HTML5 support, live wallpaper, additional APIs introduced, and optimized hardware |
| Froyo | 2.2.x | May 2010–Nov. 2011 | 8 | 0.7% | Uses Kernel 2.6.32; improved performance, Java process improvement in DVM, Chrome, tethering, wireless access point (WAP), Adobe Flash, cloud-to-device messaging (C2DM), data access control, and additional user interface frameworks |
| Gingerbread | 2.3.x | Dec. 2010–Sep. 2011 | 10 | 13.5% | Uses Kernel 2.6.35; introduces near field communication (NFC), control battery usage for apps, front and rear camera, SIP telephony, native development environment, Google Talk video chat, overall enhanced performance for screen, video, and audio |
| Jelly Bean | 4.3.x | Jul. 2012–Jul. 2013 | 18 | 9.0% | Based on Kernel 3.0.31; introduces Google Now, keymaps, multiple user and onscreen support, Google Cloud Messaging (GCM), OpenGL ES 3.0 support for game graphics, filesystem write performance, security and performance enhancements, developer logging, and analysis |
| 4.2.x | 17 | 19.7% | |||
| 4.1.x | 16 | 27.8% | |||
| KitKat | 4.4.x | Oct. 2013–Jun. 2014 | 19 | 17.9% | Uses Kernel 3.4.0; various user interface changes, wireless printing, a new storage access framework, more synchronization between accounts and Google +, further security enhancements, bug fixes, and the new runtime virtual machine called ART which, although not enabled by default, will eventually replace DVM for increased performance and battery life |
| Lollipop | 5.0 | Oct. 2014 | 21 | 15.6% | The Dalvik DVM has been replaced with a newer ART virtual machine, with ahead-of-time (AOT) compilation and 64-bit processor support. Lock screen no longer support widgets but provides application and notification support, guest and multiple user accounts, Tap and Go quick data transfers and migration to new devices, device protection improved for lost or stolen—device stays locked until Google account sign in, even if device has been factory reset |
| 5.1 | Feb. 2015 | 22 | 7.9% | ||
| Marshmallow | 6.0 | Oct. 2016 | 23 | n.a | Key features include fingerprint authentication, confirm credential (time out app protection and password authentication based on use), App Linking (associate an app with a web domain), Auto Backup for Apps (full backups and app restores), Direct Share (share data with other users through apps, such as social media, more intuitively), Voice Interactions with apps, Android for Work (silent app installs, enterprise owned devices, and further control over device such as security certificate control) |
Android version history, distribution, and key features and improvements throughout the various release dates are represented in Table 1 (Android, Developers Guide, 2014; Android Dashboards, 2015).
In addition to the Linux Kernel security architecture, we need to consider environmental and physical factors when it comes to the security of an Android OS smartphone. These factors include the Memory Management Unit (MMU), which is a hardware prerequisite component that handles the memory and cache of a smartphone. This means the device needs sufficient internal memory to carry out processes. The MMU is important to the Linux Kernel, as it assists in the separation of processes and reduces access privileges. Type Safety is a second factor to consider. It is a programming language that prevents discrepancies between programming variables and enforces a standard code format, therefore preventing conspicuous code from being executed. A final factor to consider is the Mobile Carrier/Network Operator, where authentication of the Subscriber Identity Module (SIM) and associated protocols adhere to the mobile network's basic security principles. This helps to avoid intrusion, which can target user identification, voice and data charges, and monitoring (Shabtai et al., 2010). For example, in Sep. 2014, fake mobile phone towers were reportedly discovered in the United States that could give those who were in control of the towers “the ability to attack mobile phones through eavesdropping and installing spyware” (Sky News, 2014).
2.1.3 Vulnerabilities
Having an open-source OS encourages rapid development because multiple developers can identify vulnerabilities in the OS and prepare patches to fix the identified vulnerabilities to avoid widespread exploitation of such vulnerable devices.
The core layers for potential vulnerabilities were discussed above (Linux Kernel platform, the open-source OS, and third-party apps), thus emphasizing that understanding the Android OS security architecture will assist in mitigating vulnerabilities in core apps and services. However, hardware resources may also be affected and include a number of additional vulnerabilities. Hardware resources at risk may include battery power, memory and central processing unit (CPU) resources, removable storage media, and cameras. For example, the contents of a secure digital (SD) card have no security measure in place, thus allowing private content to be exploited (Shabtai et al., 2009).
Although the impact of vulnerabilities depends upon the type of threat, a standard (nonmodified and nonrooted) Android OS is typically well protected because the core components of the Linux Kernel cannot be replaced. However, source code, such as framework, DVM, and the native libraries, can be modified, thus increasing the risks of vulnerabilities. For example, previous studies have highlighted a number of poorly designed and insecure mobile apps that request excessive and unnecessary permissions and, consequently, increase the security risk (Shabtai et al., 2009). In a more recent work, Choo and D’Orazio (2015) identified vulnerabilities and design weaknesses in the Australian Government Medicare Express Plus app for iOS devices, which allows an attacker to expose the device user's sensitive data and personally identifiable information (PII) stored on the device. Due to the time lag between the discovery of a vulnerability and the availability of an update or patch, users of affected devices are vulnerable to attacks (Husted et al., 2011).
2.1.4 Rooted Android Devices
Rooting an Android device is a process that allows a user to obtain root privileges, allowing them to easily interact with the OS and make changes to the device. Such changes include interface customizations, unlocking hidden features, installing the latest OS releases, and removing software preinstalled by hardware manufacturers. Rooted devices also allow third-party app installations that offer additional features not supported by nonrooted Android smartphones, such as apps that tweak the battery life, speed, and performance of a smartphone (Liebergeld and Lange, 2013).
While the rooting process removes existing restriction and allows more flexibility, it may result in additional security risks, as malicious apps may be able to bypass the device's built-in security measures. For example, third-party apps having root access to the device would be able to interact directly with the device and system files and therefore be able to access information on the device that includes private and sensitive data. Third-party apps that have root access may also modify files and/or disable the device, rendering it unusable (Liebergeld and Lange, 2013).
2.2 Android Application Security
2.2.1 App Permissions
Android is a popular app development platform and offers open-source flexibility in an unrestricted marketplace. This has contributed to the growing availability of Android OS and also allows for an extensive API, which defines how the app interacts with most areas of the hardware functionality, such as user data and phone settings, wireless connectivity, GPS system, and built-in digital camera.
The security of app permissions is managed through the Linux Kernel, specifically the Libraries and ART layers, and is based on isolating activities and permissions in terms of what the app is able to perform and access on the device. As each app has its own process and is managed in its own sandbox environment, apps are unable to “talk” to each other, which means less information can be shared. App permissions need to be declared in the AndroidManifest.xml file, as mentioned earlier in the Security Architecture. If such permissions are not listed within this file, then the Kernel will carry out its task of restricting, known as a “runtime exception,” preventing any malicious activity from running (Vidas et al., 2011).
According to Vidas et al. (2011), there are close to 130 app-level permissions incorporated within the Android framework that are declared before an installation occurs. The user initiates installation and needs to accept such permissions before the installation can occur. This allows some control over what permissions are being executed by an app. However, the majority of users are not aware of how permissions work and what they are intended for. Thus, apps may comprise privileged permissions that are not required for the purpose of the app, such as location access and network access, which may have an impact on the privacy, security, and vulnerability of the device (Vidas et al., 2011).
The development of an Android app is based on four protection levels. The app developer can select the appropriate protection level in conjunction with Component Type permissions. The four protection levels are Normal, where minimal permissions are needed; Dangerous, where a substantial risk is present and therefore more permissions are requested, but only on a user's confirmation; Signature, which allows apps with the same signature permissions to talk to each other; and, finally, SignatureOrSystem, which is a signature permission that has access to the image file system. As app permission requests are granted, the protection layers declare the app's permissions to the user for approval and grant access to the smartphone. In the event of permissions being declined, the app will not install (Ongtang et al., 2012).
2.2.2 Component Permissions
To assist in the selection of app permissions and protection levels, predetermined component types need to be identified in relation to an app's purpose. There are four component types defined by Android to securely identify an app's purpose and what areas of the system it will access. The first component type is Activity, which relates to onscreen user functionality. For example, onscreen app activity generally displays only one or two options per screen due to the screen size of smartphone devices. Having too many app activities on one screen will be hard to read and thus affect option selection by users. The second component type is Service, where an app will continue to perform a particular process in the background, even if the app has been temporarily closed from onscreen display; for example, downloading a music file and returning to the home screen (Enck et al., 2009).
The third component type is Content Provider, which enables the sharing and storing of data through a relational database that can describe the content it contains. Finally, the fourth component type is Broadcast Receiver, which can be defined as a mailbox for receiving messages from other internal apps only and with no external interference so that the message can then be broadcasted to its intended destination (Enck et al., 2009).
2.2.3 Signing Apps
Before an app can be added to the Android marketplace, the app must be digitally signed with a certificate to identify the author. This ensures that both the app code and noncode resources are authenticated. If the app does not have a valid certificate, it will not be packaged as an Android application package (APK) file format for distribution. An app can also be self-signed by the developer and not necessarily through a Certificate Authority (CA), a commercial entity that issues digitally signed certificates. The APK is the driving force for app installation on an Android device. Therefore if the APK file is not digitally signed, it will be deemed as an invalid or unauthenticated file and will not be published. A digital signed app is verified as being from a legitimate/trusted source (developer) (Android, Developers Guide, 2013).
2.2.4 Privacy
Apps can be installed quickly and easily without having many options to configure, unlike traditional computer system software installations. Although app permissions are presented to the user, they are often simply accepted for immediate use without much consideration. In a survey of 250 university students and academic staff members, for example, it was found that device users would allow app permissions that appeared unnecessary on their mobile devices (Imgraben et al., 2014). Once the app has been installed, all included permissions will have been given access to parts of the smartphone, and the user will be unable to change, modify, or select certain permissions after the installation.
As a result, there may be leaking of personal and sensitive data to third parties (e.g., advertisement companies) and sending of SMS/MMS messages, and as well as calls made without the user's knowledge. It may be impossible for users to know what information is being captured and how data is gathered and used (Feth and Pretschner, 2012). A developer may have legitimate reasons for gathering data, such as user interaction feedback and usage statistics, although data transmitted to a third party without the user's knowledge can infringe on the user's privacy (Dietz et al., 2011). For example, mobile advertising is usually present in free apps, where app developers are financially compensated through a referral system when a user generates impressions (clicks) on specific advertisements (Leontiadis et al., 2012). Additionally, malicious apps can masquerade as legitimate apps that may inadvertently be installed by the user and read their personal data without the user even knowing (La et al., 2013).
As the number of mobile apps continue to increase, so will the need for privacy-enhancing and monitoring components. One example is the “permissions request” monitoring system that allows a user to actively manage and monitor what tasks/data the apps are conducting/collecting with their approved permissions. A “permissions request” monitoring system would also check permission requests at runtime and not at deployment time. For example, permitting an app to access the Internet every so often allows control over the runtime of the app, rather than accepting all permissions and allowing the app to access the Internet all the time without user consent (Feth and Pretschner, 2012).
“Permissions request” monitoring gives the user flexibility and a degree of control over app permissions, thus assisting with the protection of personal and sensitive data. If the user is uncomfortable with available options after finding out what the permissions are, apps can be easily uninstalled by the user's request without question in order to protect data privacy.
2.3 Android Malware Threats and Countermeasures
As smartphones are mostly always on and connected to the Internet through either mobile data or wireless home connections, possible attack vectors will make use of such available connectivity. Given that a user can allow elevated permissions unknowingly, this generates a number of avenues for an attack. By browsing untrusted websites on an Android smartphone, the user leaves the door open for drive-by exploitation, which is a common vector that spreads malware by identifying and exploiting mobile web browsers. Phishing is another common vector by which information is gathered under false pretences via emails or websites that masquerade as official or legitimate. Other than technical attacks, there are also human factors to consider such as social engineering, which is an attack vector that targets a user by manipulation, coercing them into making a particular decision that will actually help the attacker perform its relevant functions.
Threats of this nature make an everyday smartphone a potential target for attacks that can compromise private information, steal data, make use of hardware resources, and leave the device partially or fully unusable. Not only will this have a huge impact on an individual smartphone, potential threats, such as phishing, have the capability to spread and infect other smartphones through contacts stored on the device. For example, SMS/MMS messages may be distributed unknowingly to stored contacts, which may result in unwanted charges. This can also extend to email accounts, social media networks, and cloud-based services.
With the Android OS, there are several security measures in place in the underlying core framework and Linux Kernel. Although these areas are protected, it is possible to manipulate the hardware in order to uncover vulnerabilities in the framework, thus allowing root access. Therefore rooted devices will be more susceptible to security threats, such as SMS Trojan horses (Shabtai et al., 2009). The Android OS also uses various components, such as Java, which can also render a smartphone vulnerable to exploitation. As malicious code needs to be inserted into Android binaries.dex files, Java code is generally unable to infect class file formats to make this adjustment, and the Java code does not have write privileges to any APK files (Shabtai et al., 2009).
Malware is a “classic” threat to Android OS. It presents additional concerns as the Android OS platform becomes more versatile and the storage of personal data increases, making it an ideal target for malware apps. Malware can be designed to capture personal data and control a smartphone without the consent of the user by impersonating a useful or legitimate functionality, such as a Trojan or a botnet (La et al., 2013).
Since Android is an open-source platform and the system framework and architecture use a sandbox environment, there is an onus on users as they make the choice to download apps from the Google Play store or alternative sources, some of which can be untrustworthy.
However, even trusted sources, such as the Google Play store, have had malicious apps, as there is no initial review of an app's code before the app is posted. For example, a user may see an app they would like to download from a social media network but when they click on the link to download the app, they are redirected to an untrusted Android app download website and not the Google Play store. The user downloads, accepts, and installs the app, giving elevated permissions to the Android platform and allowing a potential malicious attack, such as phishing, to take place (Delac et al., 2011).
One example of a malware app was Trojan-SMS.AndroidOS.FakePlayer.b, which surfaced in 2010 and targeted Android phones by masquerading as a fake music player that users had to manually install. This example relates to the app permissions mentioned above. If users are not aware of the permissions being granted, they may render their smartphones vulnerable to security threats by unknowingly authorizing access. The purpose of this malware was to send SMS messages to premium-rate telephone numbers without the user's consent or knowledge. In this particular example, the malware app was able to take control of software resources, but it is also had further capability to access and manipulate hardware resources, such as by changing or deleting memory card data (La et al., 2013). Therefore, having antimalware protection in place will help mitigate a potential security threat in order to protect personal data and corporate data, particularly as bring your own device (BYOD) policies are becoming acceptable in the workplace environment (Wang et al., 2012).
To counteract malware within the Google Play store, Google introduced an automatic system named Bouncer in early 2012 that was designed to automatically sweep apps for malicious code. Although Bouncer was responsible for a 40% reduction in malware apps in the Google Play store, malware is evolving at such a speed that it will always find new vulnerabilities that make automatic systems, such as Bouncer, struggle to keep up to date. Therefore being personally aware of what apps are being downloaded and their permissions is a vital security measure to prevent any security threat (Hou, 2012).
There is a vast range of apps to download, and malicious apps may leverage this to their advantage by conducting an IPC between one another. Apps for the Android platform are comprised of four main components that share information and data from the receiving components that need to be passed through each one, as introduced in Section 2.2. As each component has its own purpose, the interaction between them may cause a possible threat to occur and initiate IPC between two apps that are of a malicious nature. Therefore if one component of an app is configured by a developer to attempt contact with a different or same component of another app, then personal data could be leaked and shared with external sources for later use.
Apps, mobile web browsers, email clients, hardware capability, and access to a wide network of social elements all present different avenues for security threats. Smartphones, with increasing connectivity options and data storage, are a consistent source of valuable information, making them ideal targets for strategic attack. There are a number of different strategic attack actors, which include attempts to capture information over a period of time to explore and gain resourcefulness in sensitive information for the purpose of exposing data. Possible reasons behind such attack actors may include financial gain, information gathering, or an exposure of truth. For example, a politically motivated threat may relate to wanting deception exposed for political gain.
Each attack vector has a method and logic to it. Thus the choice of malware, phishing, social engineering, or botnet attacks may depend on the intended outcome. For example, malware may exploit a smartphone to become a botnet (zombie) without the user even knowing. This causes the device to perform automated tasks across the Internet without the knowledge of the user and with the aim of targeting and compromising confidentiality, integrity, and availability of services (Pieterse and Olivier, 2012).
There are a number of countermeasures to such threats, which have been introduced by security providers. The countermeasures include virus, malware and spyware protection, and the ability to wipe the smartphone remotely if it is lost or stolen. However, antivirus/malware signature repositories need to be constantly updated with the latest definitions in order to remain effective as security threats continue to rise (Shabtai et al., 2009).
The various attack vector and actor methods are outlined in Table 2.
Table 2
Example of Android Attack Vectors/Actors and Possible Mitigation Strategies
| Potential Attack Vector/Actors | Description | Examples | Mitigation Strategies |
| Mobile network services | SMS/MMS, voice calls, emails | Messages presented to the user that appear to be from a legitimate source, where the user may be sent to external untrusted website. Various unknown phone calls claiming to be authorized agencies with the intention to obtain information verbally, or a user is asked to call a number that charges a nominal fee, where the user is unaware. | Delete unknown messages, user awareness, do not reply or call back, mark unwanted emails as spam/block sender, hang up phone call, awareness of sharing personal information over phone, identification and verification of source, call-block features |
| Mobile Internet access | 3G/4G services, Wi-Fi | Always on and connected, exposing mobile device to threats, easy connectivity to public Wi-Fi hotspots, as well as untrusted and open wireless networks | Turn off GPS and location options, do not access sensitive uniform resource locator (URL) links (e.g., banking websites) over public Wi-Fi, turn off other connectivity tools if not used (also saves battery), be aware of apps constantly using data/internet services, install antivirus/malware defenses |
| Social engineering | Deception, vulnerability aimed at the user and social surroundings | Includes fake webpages impersonating as trusted sources, fraud, scams, hoaxes, tricking the user into doing something they should not be doing | Password and change management, two-factor authentication, physical device security, classifying the sensitivity of information (what is important to keep safe and not share), educating users on identifying legitimacy and authenticity, Android apps, Google Play store, antivirus/malware defenses |
| Drive-by and WebView vulnerability | Exploits vulnerability in WebView interface, malware automatically downloads without user's knowledge or consent | Information gathering, malicious website gains remote shell system access | Affects any device running an Android version earlier than 4.2, restricted software patches due to carrier, upgrade hardware/new smartphone to mitigate risk |
| Phishing | Gathers sensitive data, such as login credentials and personal data | Impersonates an official or legitimate source, such as a banking website, fake emails, hoaxes, and web links to untrusted websites; this also expands on social engineering | Use antivirus/malware defenses to scan device, email, and web access regularly; monitor attempts to change/access system at the Kernel level; user education and awareness is vital; encryption of information |
| Webpages | Trusted or untrusted webpages | Pop-up windows, shortened URL links that do not clearly show the website URL, users can be taken to an unknown website with malicious content that tricks users into downloading and installing various items | Similar mitigation strategies to phishing, monitor webpage port access, runtime analysis, clearing browser cache, do not auto save or store usernames and passwords for critical websites, be aware of clicking on URL links, do not allow suspicious installation prompts |
| Bluetooth | Spreading malicious content | Paired devices may share and spread malware and steal data if user is unaware and accepts transfer requests | Do not pair with unknown devices; make sure to disconnect/cancel previously connected devices as a safety measure; turn off/disable Bluetooth; be aware of apps wanting to use Bluetooth channel, which can disconnect one channel and connect to another; employ a notification system to prompt user of unintentional connections to a device |
| Physical attack/USB/other peripherals | USB connectivity and syncing with external sources | Smartphones have a large storage capacity in which malicious content can be stored and used to spread across multiple devices; data theft involving removable SD cards and using them in other devices; a more advanced example would involve activating the Android Debug Bridge (ADB) feature, configuring the device to allow apps to be installed without permissions to accept prompts | Activate PIN code to prevent unauthorized access, do not leave phone unattended, be aware of surroundings, do not plug phone into unknown devices, use secondary password prompt for installing apps, only the owner can install/update, manufacturer firmware and security patches |
| Google Play store | Malware-infected apps, such as games | Limited verification process, lack of app code review | Bouncer, knowing what access is required and what permissions the app needs to function and why it needs certain access, individual permission acceptance, not just accept all |
| User admin permissions | Authorized to accept and grant permission to device | Allows malicious apps to install and access Android system, connects to unprotected networks due to admin privileges | User education, second prompt to challenge user and awareness of what access is being granted |
| App permissions | New/already installed apps request permission to install, update, or make a change; malicious app injections; third-party apps | IPC; data capture and loss through unencrypted transmission; notification pop-ups that are accepted but may not be what they seem; unusual permission requests, such as a weather app asking for camera access (not needed and potential threat); apps may have been repackaged as a free version that may contain malicious content (Pieterse and Olivier, 2012) | Know what apps are being/have been installed and their use, selective app permission acceptance, using Google Play instead of random untrusted app stores/websites, antivirus/malware defenses for prevention, introduction of a notification and alert system when IPC occurs |
| Remote app install | Various services are now available that allow apps to be installed remotely onto a device from an external website, such as Google Market (not official Google Play store) | No app permission acceptance or confirmation; an app could be installed directly onto a device without user intervention from a website offering the service, resulting in malicious code being installed alongside the app, although updated in v.2.3, older devices running lower Android versions are still at risk | Users of older Android devices should use the official Google Play store, practice due diligence on reputable remote app install websites, antivirus/malware defenses, upgrade and start using the latest Android OS release/version (update of physical handset device required) |
| Gateway to third-party workstation | Virtual Private Network (VPN) solutions, connecting to home or corporate networks, provided by third-party apps such as TeamViewer | Additional line into other sensitive networks, malicious content can spread | Enterprise Mobile Device Management (MDM) solutions, antivirus/malware defenses, close connections properly, encryption, latest patches and security updates, also relates to mobile internet access and physical attack mitigation strategies |
| Internet Relay Chat (IRC), instant messages apps, P2P file sharing networks | Third-party installed software | Connect to other devices and services, more vulnerable and open to further exploits | Avoid installing bundled unauthorized apps, device and port activity monitoring, antivirus/malware defenses, also relates to webpage mitigation strategies |
| Privacy | Manufacturers and apps gathering user data | Data being gathered includes GPS locations, system logs, account information and user interaction with the device, which can be used not for financial gain but for mass consumer production and research development | Turn off GPS through the physical device and in-app options, sign out of accounts (such as Gmail), create a dedicated and limited profile account just for Android use that has less private and confidential data exposure |
| Rooted device | Opens additional services and functionalities, can install apps currently forbidden by phone manufacturer and/or carrier, will allow full system access to Android OS | Malicious content can exploit a rooted device and gain core system access and control; view all personal information; gain access to gateways (e.g., VPNs); install Kernel modules, such as rootkits, and render them unusable; untrusted device (e.g., DroidKungFu threat (Spreitzenbarth, Forensic Blog, 2014)) | Do not root device if unsure of consequences, analyze app permissions more closely, install antivirus/malware defenses |
2.3.1 Antimalware
Malware apps have the ability to compromise the integrity of personal data to take advantage of software and hardware functionality. According to the Fortinet Threat Landscape Report (2014), for example, a record number of malware families specifically targeting the Android OS were detected in 2013, and the Android OS was the most targeted platform OS for the majority of attacks. Over 50,000 malware samples were collected per day in the first quarter of 2013, and by the end of the fourth quarter, a staggering 450,000 malware samples were collected on a daily basis. It was then that the first ransomware malware sample targeting the Android OS was discovered, called Locker/SLocker Ransomware (Spreitzenbarth, Forensic Blog, 2014), though ransomware is not a new threat to computer-based systems.
Android devices continue to be one of the most targeted mobile devices in the first quarter of 2014, with a notable focus on Trojans, which are repackaged apps designed to facilitate social engineering and the sending of messages to a premium-rate number without the user's knowledge (F-Secure Mobile Threat Report, 2014). It is, therefore, not surprising that Android Jelly Bean (v. 4.2) added an option for the user to allow or block suspicious SMS messages sent from apps. The report also highlighted the rise of Windows Trojan hops, Tor network threats, and Bootkit, targeting older versions of the Android OS, as well as Cryptominer and Dendroid toolkits, designed to repackage apps and take advantage of remote access facilities. In addition, a recent report estimated “[w]ith an overall infection rate 0.65 percent [between 2013 and the first half of 2014], around 15 million mobile devices are infected worldwide at any time” (Alcatel-Lucent, 2014, p. 4).
Throughout the past couple of years, potentially unwanted programs (PUP), such as malware, have had a significant impact on the Android OS, with a worldwide market share of 78.9%, Android continues to be a top target for malicious threats. According to G DATA (2015), for example, in the first quarter of 2015, there were 440,267 brand new malware samples identified, compared to the fourth quarter of 2014, where 413,871 malware samples were identified, which is an increase of 6.4%. In relation to the first quarter of 2014, there were 363,153 malware samples identified, which is an increase of 21% in the first quarter of 2015.
As users are frequently using Android devices for everyday usage, such as taking advantage of Internet banking and online shopping on the move, there is a tendency for more PII information to be shared with various apps. Thus the malware efforts of cybercriminals are financially motivated and are targeting such interactions. For example, known Android malware identified in the first quarter of 2015 accounted for 50.3% being financially motivated, such as banking Trojans (i.e., Svpeng Trojan, which masquerades as Flash Player and includes a malicious combination of financial malware and ransomware) and SMS Trojans, where 49.7% were other malware attack vectors (see Table 2; G DATA, 2015).
As malicious apps aim to abuse the possible vulnerabilities in the Android platform, apps, and various services, a countermeasure would be to install antimalware software. Antimalware configuration is kept up to date by using signature repositories that include known malware threats and definitions, which allow antimalware to react quickly when a threat is discovered. Thus the speed with which antimalware reacts to the detection of malware will be based on how up to date the definitions are in the repository, which is similar to how antivirus definitions work. Antimalware is designed to scan files, emails, attachments, SMS messages, and websites to help protect against Trojans, viruses, worms, and rootkits (Shabtai et al., 2009).
Although traditional workstation environments have seen a significant evolution in malware detection systems, smartphone devices present a number of unique challenges, and traditional detection systems are not easily deployed in a mobile device environment. Smartphones are likely to store more sensitive data and PII (e.g., SMS messages, photos, and videos taken using the device's camera, as well as geolocation information stored by various apps) and therefore pose a greater security and privacy risk to users. The effectiveness of antimobile malware signature repositories is unclear, as such an approach may offer resource-constrained mobile devices limited protection against newer mobile threats, such as polymorphic and metamorphic code (Suarez-Tangil et al., 2014).
A study by AV-Test (2014) evaluated 36 Android security apps over a period of 6 months with a restricted dataset of approximately 2300 malware samples. Throughout the study, eight security apps achieved plausible and optimistic detection results. The security apps with positive results included Ahnlab, Avira, BitDefender, Cheetah Mobile (three versions), G data, Kaspersky, McAfee, Qihoo, Symantec, TrendMicro, and TrustGo. The findings provide an indication of how antimobile malware apps for Android are improving in performance and detection rates.
Having antimalware apps perform regular scans and signature updates will have an adverse impact on power consumption and the performance of the device. One promising approach is to have cloud-based signature repositories, where the heavy lifting is undertaken in the cloud rather than the lightweight client app. There are, however, privacy and confidentiality concerns about using cloud-based solutions (Suarez-Tangil et al., 2014). For example, will cloud-based antimalware providers be able to track the device users?
Awareness of app privileges and the number of permissions requests needed are becoming a primary focus point for reasonable protection against malware. For example, if the required antimalware app permissions requests are not fully accepted, the app will not be used to the best of its ability, thus leaving the smartphone unprotected. If all requested permissions are accepted, it would be difficult to fully understand what the permissions are doing or mean. The various protection methods available from an antimalware app may include a number of different detection and analysis methods, such as type of monitoring, granularity, and identification, all of which require various permissions granted by the user. This leads to further concerns related to privacy and confidentiality (Suarez-Tangil et al., 2014).
Thus new privacy apps for the general user are becoming popular, allowing control over permissions that an app is using, such as Privacy App by SnoopWall. Further development in regard to app permission control, security, and privacy measures may also include enterprise-wide solutions, such as GlobalProtect by Palo Alto Networks, where mobile users benefit from enterprise security features by connecting through a VPN connection.
With the increase in the popularity of Android devices and the subsequent growth of mobile malware, we have seen an increase in the number of antimalware apps in recent times. Major security companies, such as Intel Security (McAfee Mobile Security), AVG Mobile, AVAST, Symantec, and Kaspersky are offering free or paid (in-app purchase) antimalware apps. The Google Play install statistics identify that the two most popular downloaded antimalware apps are AVG Mobile and AVAST, each reaching between the region of 100,000,000 and 500,000,000 installs (as of Jul. 20, 2014). There are also new players catering for the Android market. For example, CM Security (Cheetah Mobile), and Lookout Security & Antivirus (Lookout Mobile Security) reportedly have between 50,000,000 and 100,000,000 downloads as of Jul. 20, 2014, and 360 Security (Qihu) and Antivirus Free (Creative Apps) have between 10,000,000 and 50,000,000 downloads respectively as of Jul. 20, 2014 (Google Play, 2014).
There are, however, challenges faced by Android and other mobile antimalware app designers due to the inherent differences between a mobile device and the “traditional” client device, such as a desktop and laptop. For example, mobile devices are typically resource constrained due to manufacturer restrictions. Thus timely core OS version and patch updates may not be released for older hardware devices. This leaves the devices vulnerable and more open to potential security threats and exploits (Husted et al., 2011). Another difference is how a user will inherently have higher permissions on a device, where they can unintentionally install any number of apps from untrusted sources. Therefore giving the user control over accepting all app permission requests that may be a potential risk to both the user and the device (Shabtai et al., 2009; Feth and Pretschner, 2012). This raises concerns about the potential security risks and threats related to interapp and resource communication such as IPC interactions (Ongtang et al., 2012). Any newly installed app may contain malicious app injections that will try to communicate with and affect other apps on the device.
Despite the increased attention to the threat of mobile malware and security companies offering both free and paid antimalware apps, the number of downloads is low in comparison to other apps such as games. Research conducted by TrendMicro shows that only 20% of Android-based devices have security apps installed despite the increase in mobile malware (TrendMicro, 2012). Similarly, a survey of 250 university students and staff at a South Australian university found that the majority of the participants did not install an anti-malware app (Imgraben et al., 2014). The findings and those of a study by Zhou and Jiang (2012, p. 96), which found that mobile malware is “rapidly evolving and existing antimalware solutions are seriously lagging behind,” suggested that more needs to be done to protect mobile device users.
The lack of adoption of antimalware apps is, perhaps, due to a lack of user awareness (as highlighted by Imgraben et al. (2014)) and the perception that antimalware apps will slow device performance and increase battery consumption. In comparison to existing antivirus solutions, there is a wider range of anti-malware apps to choose from, which may further confuse users. By conducting an evaluation of the top 15 most downloaded free antimalware apps, this research will facilitate users to making an informed decision.
2.3.2 Firewall
If configured in the correct manner, firewalls can be an essential part of protecting Android smartphone data. With the ability to control and keep a log of all inbound and outbound traffic through various connections, firewalls can guard against untrusted network resources and attacks to vital services of the OS and core framework. Once the firewall has been configured to monitor and manage communications within a set of access list rules, it will be able to detect whether an app is trying to send private and confidential data and block this communication (Shabtai et al., 2010).
Although firewalls are an effective solution, they are unable to block all communications such as SMS messages and attacks via the Internet browser, emails, and Bluetooth. Nevertheless, having the ability to manage app permissions and define what access they do and do not have is an important part of protecting data and private information (Shabtai et al., 2010).
2.3.3 Intrusion Detection System
An Intrusion Detection System (IDS) is a well-established security mechanism that has been implemented through information technology (IT) infrastructure and computer systems. Providing several security features, such as monitoring network and port activity, file protection and, notably, identification of suspicious activity, IDS capabilities have also been designed for smartphone security protection and monitoring. For IDS to be effective, a number of approaches are used to complement each other, which include Prevention-, Detection-, Anomaly-, and Signature-based approaches (La et al., 2013).
Each approach has a unique function for detecting malicious software or activities that is able to learn system behavior and alert the user if a suspicious anomaly is found. This is an effective measure if definitions are kept up to date and can identify unknown threats (Shabtai et al., 2010).
2.3.4 App Certification
App certification is specifically designed to counteract malware apps, as legitimate apps go through stringent testing and review before they are packaged in order to ensure appropriate functionality and determine their purpose. CA verifies a trust association, which is checked before an app is installed on a smartphone. Therefore, any malicious app that attempts an installation without a certification will be detected and removed (Shabtai et al., 2009). However, certifications can be a costly exercise for an app developer.
As Android is an open-source platform, there are several third-party app stores available where users can freely download any number of apps. This is an additional security threat, as apps may have a higher risk of containing malware that can bypass any CA authentication (Shabtai et al., 2009).
2.3.5 Selective Access Control
Given that installed apps have been granted certain permissions by the user, it is likely that these apps use the granted permissions as and when it suits their purpose. To prevent unnecessary granted permissions, it is entirely possible for the package installer to be modified so that advanced features can be installed to allow control over permissions. In this way, the user is fully aware of a request and has the ability to allow or deny the request without any interference to the usability of the smartphone or performance. By adding control of app permissions, malicious software is prevented from using unknowingly granted permissions and data as a whole is protected (Shabtai et al., 2010).
Limiting unnecessary app permissions will harden an Android device and will give the user the responsibility of becoming more aware of the functionalities of the device, thus allowing the user more control over what permissions are granted. Selective access control can be seen in corporate environments, where BYOD initiatives are managed and enforced by certain policy restrictions, ultimately protecting the corporate infrastructure, user, and personal data (Shabtai et al., 2009).
2.3.6 Context-Aware Security
There are a number of activities a smartphone can carry out in any moment. These include contextual activities, such as adjustments in local time, or wireless connections to other devices. Depending on the contextual circumstances, context-aware security is able to restrict or allow access based on predefined configurations that learn from the interaction and surroundings of its day-to-day operations based on user activity (Shabtai et al., 2010).
For example, if context awareness detects that a device has changed locations and is in a different time zone or country, it may be configured to lock down the smartphone, make it inaccessible, and encrypt its data. Although this is not an instant security measure and takes time to configure and set up, it does present an interesting method for protecting malicious access to resources and services based on predefined settings that help protect confidential content (Shabtai et al., 2010).
2.3.7 Data Encryption
Although the prevention of malicious software attacks is important, consideration must also be given to personal data protection because smartphones may be lost or stolen. As the amount of data being stored on a smartphone increases, data encryption has become a highly regarded factor for any event because the user is in control of managing access.
Throughout all Androids platforms, data encryption can include several techniques, such as a hardware access passcode, file-level password-based encryption, and a SIM personal identification number (PIN). Additional measures can include limiting the number of password attempts and locking the smartphone or file when the maximum attempts have been reached (Shabtai et al., 2010). Not only is this a reliable internal security measure, but such a measure can also be implemented with removable storage, such as an SD card. There are also additional features defined within apps themselves; for example, SMS and MMS apps may also include a separate passcode that can be set for further protection. With a variety of options, implementing data encryption can help prevent the exposure of sensitive and personal data (Wang et al., 2012).
However, newer releases of Android, namely Lollipop and Marshmallow, include a number of security enhancements to ensure data encryption to protect users. For example, full disk encryption was included, allowing the user to encrypt their device if they so choose. Smart Lock features, such as Trusted Face, was a feature released in earlier Android versions (Ice Cream Sandwich and above) and has since been updated to include Trusted Places and Trusted Devices. Lollipop also introduced multiuser, guest, and restricted profiles, allowing more control over the protection and encryption to keep data safe. Additional features within Marshmallow include fingerprint authentication and credentials authentication, which uses timeout variants based on when the device was last unlocked and used. Such security additions help to protect and encrypt data where required (Android Security Enhancements, 2015; Android Developers Guide, 2015).
Further data encryption and security features include the adaptation of remote device wiping and data backup and restore services through additional cloud anti-malware apps. Users are able to backup their data to personal cloud storage services and restore their data to another device when convenient. Remote device wiping is beneficial when a device is either lost or stolen to protect users (Walls and Choo, 2015; Di Leom et al., 2015). Additional data encryption and security features ensure data encryption to prevent data leakage.
3 Experiment Setup
To determine the effectiveness and reliability of the 15 most popular (by number of installs) free antimalware apps available on Google Play store (Table 3).
Table 3
Antimobile Malware Apps for Android Devices (Information Correct as of Dec. 16, 2014)
| Manufacturer | Antimalware App | Initial App Release Date | Current Version | License | Developer Website Source | Number of Installs (Google Play) |
| AVG Mobile | Antivirus Security | 2011 | v4.2.212757 | Free | http://www.avg.com/au-en/for-mobile#android-tab | 100,000,000–500,000,000 |
| AVAST Software | Mobile Security and Antivirus | Dec. 2011 | 4.0.7871 | Free | http://www.avast.com/en-au/free-mobile-security | 100,000,000–500,000,000 |
| Cheetah Mobile | CM Security and Find My Phone | Late 2012 | v2.2.5.1040 | Free | http://www.cmcm.com/en-us/cm-security | 50,000,000–100,000,000 |
| Lookout Mobile Security | Lookout Security and Antivirus | Nov. 2009 | v9.9.1 | Free | https://www.lookout.com/android | 50,000,000–100,000,000 |
| Doctor Web Ltd | Dr. Web v.9 Anti-virus | Dec. 2013 | v9.02.1(2) | Free [14-day demo only] | http://download.drweb.com/android | 10,000,000–50,000,000 |
| Qihu | 360 Security—Antivirus Free | Jun. 2013 | v2.1.0.1032 | Free | http://360safe.com/mobile-security.html | 10,000,000–50,000,000 |
| Creative Apps | Antivirus Free | 2011 | 7.3.02.02 | Free | http://en.nq.com/mobilesecurity | 10,000,000–50,000,000 |
| Norton Mobile | Norton Security and Antivirus | Jun. 2013 | 3.8.6.1653 | Free [28-day demo only] | http://community.norton.com/t5/Norton-Mobile-Security/bd-p/NMS | 10,000,000–50,000,000 |
| TrustGo Inc. | Antivirus and Mobile Security | Feb. 2013 | 1.3.15 | Free | http://www.trustgo.com/features | 5,000,000–10,000,000 |
| McAfee Mobile Security/Intel Security | McAfee Free Antivirus and Security | Oct. 2011 | 4.3.0.448 | Free | https://www.mcafeemobilesecurity.com | 5,000,000–10,000,000 |
| Kaspersky Lab | Kaspersky Internet Security | Jun. 2011 | 11.6.4.1190 | Free | http://www.kaspersky.com/android-security | 5,000,000–10,000,000 |
| BitDefender | Mobile Security and Antivirus | Apr. 2013 | 2.30.625 | Free [14-day demo only] | http://www.bitdefender.com.au/solutions/mobile-security-android.html | 1,000,000–5,000,000 |
| MalwareBytes | MalwareBytes Antimalware Mobile | Oct. 2013 | 1.05.0.9000 | Free | http://www.malwarebytes.org/mobile | 1,000,000–5,000,000 |
| Sophos Limited | Free Antivirus and Security | Jul. 2012 | 4.0.1433 (12) | Free | http://www.sophos.com/en-us/products/mobile-control.aspx | 100,000–500,000 |
| Pablo Software | Virus Scan | Jun. 2014 | 1.5.9 | Free | https://play.google.com/store/apps/details?id=com.pablosoftware.virusscan | 100,000–500,000 |
To ensure the usefulness of this study, we obtained 15 popular Android malware samples for analysis by the antimalware apps. The malware samples were collected between Feb. 27 and Dec. 4, 2014 from the Contagio Mobile (2014) Malware Mini Dump database (Table 4). The malware sample SMS Sender (Xxshenqi-A.apk and com.android.Trogoogle.apk) includes two datasets from the same malware family, but most malware samples are from different malware families.
Table 4
Experiment Malware Samples
| Malware Sample Date | Malware Sample Name | File Name | Description |
| Dec. 4, 2014 | Deathring: preloaded malware | com.android.Materialflow.apk | DeathRing is a preloaded malware on brand new smartphones popular in Asia and African countries. DeathRing is a Trojan masquerading as a ringtone app that uses SMS and Wireless Access Point (WAP) vectors for malicious means. For example, SMS content may be used to phish PII data (The Register and Leyden, 2014) |
| Nov. 20, 2014 | Notcompatible.C | Com.security.patch.apk | NotCompatible.C is a sophisticated botnet that used encryption and peer-to-peer communication, which has evolved from the earlier NotCompatible.A malware threat. NotCompatible.C has a botnet-like nature and is primarily aimed at network security, using Android as the attack vector to gain access. The malware can compromise vulnerable hosts and exploit exposed data inside the network. With such sophistication, NotCompatible.C is an example of how mobile malware has significantly matured (Lookout, 2014) |
| Oct. 30, 2014 | Android SMS worm Selfmite | selfmite.apk | The Android Selftmite vulnerability previously surfaced early Jun. 2014 and was called Andr/Slfmite-A. The same vulnerability resurfaced in Oct. 2014, named Andr/Slfmite-B, and masquerades as a Google Plus app. The vulnerability uses a fake Google Plus icon as a botnet-style malware, which collects PII data and decides what to do with it. The fake app also installs with device administrator rights, making it difficult to uninstall and take over critical aspects of the smartphone, such as SMS and phone. The aim for this malware is to make money through affiliate revenue and pay-per-click icons (Sophos, 2014) |
| Oct. 8, 2014 | Xsser mRAT (Android sample) | code4hk.apk | The code4hk malware is an app that exploits PII data from Android and iOS devices. The malware uses a fake mobile remote access tool (mRAT) app that claimed to coordinate the Occupy Central pro-democratic movement in Hong Kong. The app initiates through a link that is sent through a messaging service called Whatsapp, which then activates the malicious app if clicked. Activation leads to exploitation and extraction of data (Lacoon Security and Bobrov, 2014) |
| Aug. 3, 2014 | SMS Sender | Xxshenqi-A.apk | The fake SMS Sender malware app is a combination of a worm plus a Trojan. The Trojan is effectively packaged within the worm and activated when the APK file has been installed, therefore two versions are from the same malware family. Shenqi-A malware targets all SMS messages made and received (McAfee Labs et al., 2014) |
| Aug. 3, 2014 | SMS Sender | com.android.Trogoogle.apk [Torgle-A] | |
| Jun. 23, 2014 | Google Cloud Messaging Trojan | smsgoogle.apk 05android (Google Cloud Messaging)/Android.Mobilespy/Agent-DBM | The Google Cloud Messaging Trojan prevents an affected user from uninstalling the malicious app and exploits PII and hardware informational data, such as IMEI serial and device ID. The data is sent to premium numbers via SMS, therefore charging the user and capturing data at the same time (F-Secure, 2014) |
| May 10, 2014 | Android Monitor Spyware | com.exp.tele.apk (HGSpy.A/QlySpy.a) | Android Monitor Spyware comes in various forms of malware, such as HGSpy.A and QlySpy.a. The malicious app gains permission for a number of core processes and system preferences. Elevated permissions include location, Internet, Wi-Fi control, phone, messaging, and phone reboot control (Contagio Mobile, 2014) |
| May 6, 2014 | Android SMS Trojan | Google-fake-installer.apk FakeInst (RuSMS-AH, Google.Services.Framework) | Android SMS Trojan, known as FakeInst, masquerades as an installer for other applications. However, this is a malware that sends SMS messages to premium-rate numbers or services without knowledge (Contagio Mobile, 2014) |
| May 6, 2014 | Fake AV Se-cure MobieAV | Fake-av.apk Se-cure.Mobieav | FakeAV malware predominantly use visual payloads, enticing users to take action and pay a fee to protect their device. Known FakeAV apps do not have the same functionality as legitimate AV apps and do not offer the same protection (Contagio Mobile, 2014; Spreitzenbarth, Forensic Blog, 2014) |
| May 6, 2014 | Android Samsapo.A | android.samsapo.apk (com.android.tools. system) | Android Samsapo.A is a worm that tries to hide within the Android system utilities. The malware is designed to spread through various means, such as email attachments and across a network. Permissions are escalated to exploit SMS, phone calls, and alarm settings and act as a downloader for other malware apps from different URLs (Contagio Mobile, 2014; Spreitzenbarth, Forensic Blog, 2014) |
| May 6, 2014 | Android Fake Banker | fake-banker.apk (Sparkasse/Banker-Y) | Android Fake Banker malware is a fake mobile online banking app, which aims to exploit PII data. This specific malware sample masquerades as a well-known EU bank (Contagio Mobile, 2014) |
| Mar. 6, 2014 | Dendroid.AndroidSpyware | com.parental.control.v4.apk | Dendroid is a well-known Android malware that targets a device's camera and audio, as well as access GooglePlay. The malware uses a remote-access Trojan to control the device and exploit data (Contagio Mobile, 2014) |
| Feb. 28, 2014 | iBanking Android | iBanking.ing.apk (Security Space) | iBanking Mobile Bot malware masquerades as legitimate banking apps. Once the user accepts the permissions, the malicious app is able to capture incoming/outgoing calls, redirect numbers, capture audio, and send PII to a remote location. This specific malware sample masquerades as a well-known EU bank (Contagio Mobile, 2014) |
| Feb. 27, 2014 | Android Tor Trojan | tor.video.mp4.apk (com.BaseApp) | Android Tor Trojan targets the Tor network and builds upon the anonymity of its users through a fake app (Contagio Mobile, 2014) |
Source: Contagio Mobile, 2014. Mobile malware mini dump, viewed 08 August 2014. http://contagiominidump.blogspot.com.au.
Three mobile test devices were used, each with their own Android OS (Ice Cream Sandwich, Jelly Bean, and KitKat) (Table 5). Each of the 15 antimalware apps will be installed on every test device, which will be used to scan against the 15 malware samples and conducted in 675 individual tests. The experiment process is designed to accommodate a typical day-to-day user. Therefore each test was conducted manually, as if a user was unknowingly installing a malicious app, which will hopefully give an indication and validate the effectiveness and reliability of the apps under examination, as the experiment process has been designed to be repeatable. While each individual antimalware app provides various configuration options, our study used default configurations as would most users, particularly non-IT-literate users. Therefore the detection criterion will be based on antimalware app signature definition updates at the time of experiment (see Section 3.1), not based on behavioral factors. The antimalware apps were updated with the most recent signature repositories updates before any malware samples were tested and data recorded (see Table 3).
Table 5
Specifications of Test Devices
| Hardware/Manufacturer | Android OS Version | Kernel Version | Chipset/Processor | Memory | Internal Storage |
| Samsung Galaxy Music S6010 | Android 4.0.4 Ice Cream Sandwich (upgradable to 4.1.2 Jelly Bean) | 3.0.15-1150453 | 850 MHz Cortex-A9 | 512 MB | 4 GB |
| Samsung Galaxy Young NL 3G 850 | Android 4.1.2 Jelly Bean | 3.4.0-1140261 | Qualcomm MSM7227A Snapdragon with 1 GHz Cortex-A5 CPU | 768 MB | 4 GB |
| Motorola Moto G X1033 | Android 4.4 KitKat | 3.4.42 | Qualcomm Snapdragon 400 processor with 1.2 GHz quad-core CPU | 1 GB | 8 GB |
3.1 Experiment Process
To ensure both repeatability and reproducibility, which are key principles in scientific experiments, we outline the flow of our experiments below (Fig. 2):
1. The first step in the flow diagram is Start, which is where the experiment begins.
2. The next step is to create a new or use an existing Google test account and link this account to Android test device.
3. The next step in the process is to Sign in to Google Play store and install free antimobile malware app on the Android test device. Anti-malware apps will be installed based on their popularity (i.e., number of downloads) (see Table 3).
4. The next step is to Confirm antimobile malware app version for Android test device. This step is in place to confirm the actual version being tested on each Android test device, as some apps have a “varies with device” version release that is not defined in the Google Play store.
5. In order to have a consistent approach to testing individual antimalware apps using up-to-date signatures, the next step is to Update definitions and perform an initial scan of Android test device.
6. To prepare for the malwaresample.apk file transfer, the next step is Connect Android test device to personal computer via USB.
7. Using the Contagio Mobile (2014) Malware Mini Dump database, the next step is to proceed to Download known malwaresample.apk file to desired location on test personal computer.
8. The next step, Decision on how to upload file, is to upload the sample file that is based on user preference, which may be:
a. Manual upload: Manually upload sample file to the Downloads folder of the Android test device. Note: The plugged-in test device will behave similarly to that of an external hard drive.
b. Enable USB Debugging mode on Android device: On the Android test device, go to the home screen, select Menu > Applications > Development, and enable USB Debugging. Note: Android OS Jelly Bean and KitKat require “tapping” the About option a few times before the Development tab appears.
c. Establish Android Debug Bridge (ADB) connection: The Android ADB feature is another way of communicating between a personal computer and an Android test device. As Android is based on Linux, it allows a terminal-based interface; therefore files can be uploaded using command line instead of drag and drop.
9. Depending on the decision made in Step 8, the next step is Upload malwaresample.apk file to Download folder on test Android device for testing the antimalware apps.
10. Now that the sample file has been uploaded, the next step is to Browse to the Download folder on test Android device and install malwaresample.apk file. This will initiate the installation of the sample file onto the Android test device, where a digital timer watch will be used to record accurate detection time results.
11. Once this has been initiated, the next process is On successful install: Start Timer. Being extremely attentive and critical in this approach is necessary, as the timer must be started precisely upon confirmation that the install has finished. If there is any doubt in starting the timer upon a successful install, this step has to be repeated for accuracy.
12. This step is a defining factor in the overall detection rate and time, where the Malware sample auto detected is recorded.
a. No—Run manual antimobile malware scan—If the antimalware app did not detect the malwaresample.apk file, then a manual scan was run.
b. Yes—On detection: End Timer—If the malwaresample.apk was detected, the time will be recorded.
13. Following the detection process, the next step is Document results, which involves recording the detection type, detection time in seconds, and detection rate (see Section 3.2).
14. No malicious sample files can be left on the device, so the Ensure to factory reset device process has been added to keep all Android test devices in the same clean environment.
15. The process for additional sample files can be repeated in the process named Repeat process to test additional malwaresample.apk files.
16. Finally, the terminal End represents the end of the experiment.
3.2 Metrics
In our study, bar graphs and cumulative distribution function (CDF) will be used across the three following areas of malware sample detection principles, which collectively analyze the reliability and effectiveness of the antimalware apps used in our experiment.
Type of Scan (Auto [A] or Manual [M]): The type of scan used to identify a malware sample. Auto mode refers to the app being able to automatically detect a threat. If there is no automatic detection, a manual scan is conducted to thoroughly test the sample malware. A bar graph is used to represent the type of scan value. An effective antimalware app should perform a scan automatically for any new app installation, hence a higher percentage of the auto scan type will result in a higher scan value percentage. The latter is computed as (number of the type of scan, auto or manual)/(total number of test cases performed against the antimalware app).
Detection Time: The time it takes for the malware sample to be detected. For the purposes of reporting data, the detection time is recorded in milliseconds. Where a malware sample is not detected or an automatic scan does not take place, the detection time is recorded as n.a. CDF is used to cumulatively represent all detection time values and displays how the antimalware apps are distributed. For example, the detection time values for each app are sorted in ascending order (i.e., smallest value to largest value), which in most instances include 45 data points: 15 malware samples tested on each individual antimalware app across all three Android OS; 15 × 3 = 45. The data points in this example are representative of 1/45, which is 0.0222 (2.22%), up to 1.0 (100%). Each data point is representative of a percentage to determine the cumulative frequency of the detection time. While most apps have 45 data points, it is not true for all of the antimalware apps within this experiment. The apps that result in n.a. have fewer data points; however, they will still add up to 100%. Each data point on the graph show how results are distributed cumulatively for each antimalware app. Results with n.a. will not be included, as a figure is required to plot a result. Thus if any antimalware apps have n.a. across all 15 malware samples tested, they will not be shown, as they have no detection time due to their manual type of scan. Therefore antimalware apps that automatically detect a threat are considered more reliable and effective in detecting the malware samples used within this experiment.
Malware Sample Detected (Yes [Y] or No [N]): This identifies whether the tested malware sample was detected, as a percentage value. A bar graph is used to represent the malware sample detection value. A higher percentage means more malware samples were detected, resulting in a higher percentage. Malware sample detection percentage is computed as (number of malware sample detected)/(total number of test cases performed against the antimalware app).
4 Findings
First, we looked at the type of scan results (automatic or manual) to determine and compare antimalware apps (Fig. 3). The way in which the malware samples were detected played a vital role in the findings, as the aim of this analysis is to determine the effectiveness and reliability of free antimalware apps that are available from the Google Play store.
At the time of research, Android versions used within this experiment (i.e., KitKat, Jelly Bean, and Ice Cream Sandwich) are still popular versions throughout the consumer market. For example, KitKat currently holds the majority of distribution share across all Android platforms. In addition, it is likely no further updates or releases will be provided for KitKat, Jelly Bean, or Ice Cream Sandwich due to newer Android versions such as Lollipop and Marshmallow. Any new updates will relate to a new version release upgrade and device compatibility factors.
Our experiment conducted within this chapter is relevant, as its focus is on versions of Android that are no longer supported but are still widely used, hence the need to protect devices and ensure PII security. It is not uncommon for malware threats to target older Android versions, such as Ice Cream Sandwich, Gingerbread, and Froyo, thus learning attack methods and possibly adapting to newer Android versions. Furthermore, the experiment process is designed to facilitate a manual procedure that is both repeatable and transparent, which can be used to test the effectiveness and reliability of any antimalware app across new or old Android versions with a range of collected malware samples from various sources (see Section 3.1).
Although Lollipop and Marshmallow have recently been released, they still have a lower distribution and are somewhat less stable and more in flux than previous Android versions, as mentioned previously. Therefore, Lollipop and Marshmallow will be considered in future experiments.
The apps with a higher automatic detection of malware samples are more reliable and effective in protecting an Android device against malicious threats, thus protecting the user intuitively through prompt notification to remove a detected threat. Those with manual detection of malware samples require additional user intervention, which may lead to a malicious threat to perform the attack, as it was not detected and mitigated in a timely manner.
With this in mind, the apps that automatically and consistently detected a threat and would immediately prompt the user to uninstall received a higher percentage. The top eight antimobile malware apps examined were AVAST Software, Cheetah Mobile, Qihu (360 Security), Norton Mobile, McAfee Mobile Security/Intel Security, BitDefender, MalwareBytes, and Sophos Limited. All eight antimalware apps received 100% each for automatic detection and removal of the malware samples used within this experiment. The results show that all eight apps performed extremely well and show promising signs of Android automatic malware protection.
Following closely at 97.78% was AVG Mobile, where the majority of scans were automatic with one manual intervention. A manual scan was needed, as AVG did not detect one of the malware samples used within this experiment. The type of scan used correlates with the malware samples detected, as some malware samples were not detected at all. In this instance, a manual scan is used to verify possible detection of the installed malware sample to show transparency and accurate findings across all antimalware apps (see Fig. 7).
Lookout Mobile Security (A: 86.67%/M: 13.33%), Creative Apps (A: 33.33%/M: 66.67%), and TrustGo Inc. (A: 26.67%/M: 73.33%) required more prompts and more manual intervention. The three remaining apps did not provide automatic detection for the possible removal of malware samples used—Doctor Web Ltd (A: 0%/M: 100%), Kaspersky Lab (A: 0%/M: 100%), and Pablo Software (A: 0%/M: 100%). Although Doctor Web Ltd provided a free app, it was a 14-day trial and did not include automatic scanning. An in-app purchase to upgrade to the full version was required to benefit from automatic scanning. Kaspersky Lab and Pablo Software had no automatic notification of malicious threats being installed and required manual intervention on all malware samples installed. However, Doctor Web Ltd, Kaspersky Lab, and Pablo Software performed very differently in the malware samples detected, albeit manual intervention was needed, which makes these apps less reliable and effective in protecting an Android device.
Second, we looked at the cumulative frequency of detection time results across all three Android platforms and hardware test devices. During the experiments, we observed that the scanning mode (Fig. 3) had a considerable impact on the detection time across the different Android platforms and test devices. Antimalware apps that included automatic detection received a time value. Those that required a manual scan received no detection time value, which impacted the results distributed cumulatively for each tool.
Throughout the experiment, it becomes apparent the detection time for the 15 antimalware apps improved across newer Android OS's and hardware devices (Figs. 4–6). An observation was that some antimalware apps, such as AVAST, Cheetah, and TrustGo, started a scan of a malware sample during install, while other apps started a scan after install. Starting a scan during install showed significant improvement in detection time. However, the response in prompting for an automatic detection and removal of the malware samples was different across each malware sample.
At the time of experiment, Doctor Web scanned apps during install, which prompted a threat alert only with no automated process to remove the threat. Although this allowed for quicker detection time, the Doctor Web app did not autoprompt the user to uninstall or stop the malware sample from being installed; therefore the installed malware sample could be activated if opened. In order to remove the malware sample, a manual scan was needed within the app itself to activate the removal of the detected malware sample. Qiho also scanned apps during install and detected all 15 malware samples (Fig. 7). Such an example demonstrates how effective and reliable antimalware apps are if they include an automatic response.
Creative Apps varied between malware samples. Throughout some installations, Creative Apps started to check malware samples during installation while others were checked immediately after installation. Manual scans were much slower on older devices, where device specifications are lower than that of newer devices. Device specifications may have a direct relation to how quickly malicious apps are detected, meaning better detection time overall. Detection time varied considerably over the three difference devices and Android OS platforms for Norton, McAfee, and Sophos. The lower specification device had slower detection time overall; the detection time improved through later Android OS and hardware devices. Having a new and updated OS device proves to be a more reliable way in detecting malicious apps sooner rather than later. Lower detection times can be seen in Fig. 4, and a comparison in the improvement of detection time across all 15 anti-malware apps can be seen in Figs. 5 and 6.
Although TrustGo only detected four malware samples, the detection time was fairly responsive, as malware samples were scanned during installation. Once the malware sample was installed, a manual scan was run due to the low automatic malware sampled detection (Fig. 3). The manual scan adds to the experiment and analysis of the antimalware apps. If an automatic detection was missed, a manual scan, in theory, should detect any malicious activity. In this case, TrustGo did not detect 11 malware samples (Fig. 7).
Automatic scanning of a new app installation is not a feature of the free version of Kaspersky. App scanning during install is only available through the paid version, leaving vulnerabilities to the Android OS. Detection time was not taken into consideration, as the Kaspersky Lab app did not scan the malware samples on install. The malware samples could be installed and opened without any automated protection; therefore a manual scan was carried out on all malware samples and showed improved results (Fig. 7). Kaspersky did not have the option to change the default package installer, but if the option were available, detection time would increase significantly, as apps will be scanned before an installation begins.
BitDefender detected malware sample APK files on the first device scan, which is an added protection because no malware sample was installed. An antimalware app that scans and detects malicious APK files before an install has even started will have much higher detection time. However, this experiment process focuses on malicious threats that are installed. BitDefender did not prompt to change default package installer. Detection time improved over each test device. For example, older versions of Android and hardware performed slower than newer platforms. MalwareBytes detected all malware sample APK files when they were transferred to test devices. The detection time also improved over newer hardware devices and latest Android platforms (Figs. 4–6).
Pablo Software Virus scan did not have an automated malware scan for any malware samples installed. There were no scans before, during, or after the install of the malicious malware samples. The app prompted an installation of the newly installed app only and all 15 malware samples installed without any malware threat detection. A manual scan was conducted after each malware sample install; 10 were detected, leaving five malware samples undetected (Fig. 7).
The majority of detection time findings improved throughout newer models of hardware and Android OSs. The hardware may be a factor due to the improvement of hardware specification (Table 5). Android also introduces more app security within Android 4.4 (KitKat), such as restricting the installation of apps from other sources than Google Play and allowing or disallowing apps through verification (Table 1). However, the user can ignore such options and instead choose a suggested responsive antimalware tool.
In order for detection time to be effective and reliable, the app must also be able to remove the threat immediately. Our findings demonstrated that although particular apps were able to detect the malware samples, they were neither flagged as imminent threats nor removed upon detection. For example, the antimalware apps not included within the detection time results were Pablo Software, Kaspersky Lab, and Doctor Web. Due to a lack of automatic scan capability, no detection time could be recorded and the apps received a result of n.a (see Section 3.2). Nevertheless, the type of scan and malware sample detection results were taken into consideration.
Finally, we looked at the overall malware samples detected (Fig. 7), which include both automatic and manual detection across all Android platforms. Impressively, 10 out of the 15 antimalware apps used in this experiment achieved 100% detection of the malware samples used. The 10 top rated antimalware apps are AVAST, Cheetah, Doctor Web, Qihu, Norton, McAfee/Intel Security, Kaspersky, BitDefender, MalwareBytes, and Sophos.
With a large number of positive results, up-to-date malware definitions play a key role in detecting known malware. As mentioned earlier, malware samples were used from various malware families to test accuracy and transparency. Having up-to-date malware definitions are the sole responsibility of antimalware companies, which will depend on available infrastructure resources and technology (see Section 2.3.1). If a wide variety of malware families is known, then detection will undoubtedly improve. AVG performed very well and detected a very large number of malware samples, receiving 97.78%. Interestingly, the one malware sample recorded as not detected for AVG was the most recent sample and on Android 4.0 (Ice Cream Sandwich); AVG installed on newer Android platforms were able to detect all malware samples. Such a result demonstrates the vulnerability in older Android platforms and proves that upgrading to newer Android OSs and hardware devices is vital to ensure additional security measures (see Section 2.1.2).
Lookout Mobile Security received 86.67% and Pablo Security received 66.67%, which resulted in a large number of malware samples being detected. They showed promising results, and the detection would only improve if a wider range of malware families could be included in their definition updates. Of the remaining apps, Creative Apps detected 33.33% and TrustGo only detected 26.67%; both were unable to detect the majority of malware samples used in this experiment and therefore performed the at lowest levels.
A key observation throughout the experiment was how each antimalware app handled the detection of the malware sample APK files. As part of the experiment process, the malware samples (APK files) were manually transferred onto the smartphone devices in order to test each one. Antimalware apps such as AVAST, Lookout Security, BitDefender, and MalwareBytes were the only ones to actively detect that malicious APK files (malware samples) were being transferred onto the device. They also automatically prompted the removal of malicious APK files before any installation took place, which is a huge advantage in protecting any Android device. If the experiment process expanded the type of scans performed, such antimalware apps would have extremely good detection time over other antimalware apps in the Google Play market.
Initially, it seemed that hardware specification potentially had a role in improving detection times. As the experiment continued, however, this was not always the case, as Android 4.4 (KitKat) on the Motorola Moto G also presented slower detection times, as did older devices and Android platforms. Possible causes may relate to different Android versions and API's integrations.
The Motorola Moto G also has higher hardware specifications; there was a considerable difference to the time it took for the malware samples to complete installation. The malware samples were much quicker than older devices when installing malware sample APK files (Table 5); therefore this may contribute to the improved detection times of those antimalware apps used within this experiment. As the malware samples were installed more quickly, the detection of malicious activity would improve. However, this was not always true in all experiments. Older devices were able to detect some of the malware samples much more quickly. BitDefender and MalwareBytes were representative of this theory, as the detection time on newer Android platforms and hardware out-performed their predecessors.
After testing 15 anti-malware mobile apps, the major limitation in the majority of such apps tested is the inability to take control of the Google install manager system process. A unknowing user can begin the initial installation of a malicious app; once the malicious file has completed the installation, only then did the majority of antimalware mobile apps run a scan on the newly installed apps and only then were any malicious threats detected. Surprisingly, only three apps have an option that prompted to take control of the default Android package installer—AVAST, Lookout Mobile Security, and Norton Mobile. The Android package installer controls how APK files are installed. Having unknown APK files scanned would significantly increase the detection of any malicious threat, providing malware definitions are up to date. Within this experiment, the option was not selected because not all apps had the same option, so it would be an unfair advantage.
The aim of this experiment is to provide transparency between popular free antimalware apps by following an experiment process. Throughout this experiment, three vital observations were identified to significantly improve detection time, including the scanning of any APK files that are transferred to a smartphone, an option for changing the default installer package, and for a scan to immediately start during an app installation rather than after completion. If the antimalware apps used within this experiment have up-to-date malware definitions across a wide variety of malware families, all three observations will significantly improve malicious app detection times and detection rates.
5 Conclusion and Future Work
While Android and other mobile devices may be seen by some as an extension of existing threats to the security and privacy of user data, the mobile threat landscape is an extremely fast-moving environment (Choo, 2011; Quick et al., 2013). A 2014 study by 26 privacy enforcement authorities in 19 countries examining 1211 popular mobile apps for both Android and iOS platforms found that nearly 60% of these apps raised privacy concerns even before they were downloaded, and 85% of the apps were reportedly accessing personal data without providing adequate information to users (Leyden, 2014; Privacy Commissioner of Canada, 2014). It is essential that users undertake proactive measures such as those identified in this chapter; only a decade ago, several criminologists warned that “those who fail to anticipate the future are in for a rude shock when it arrives” (Grabosky et al., 2004, p. 156).
In this study, we manually examined the 15 most popular antimalware apps installed on devices running the three most recent versions of the Android OS. They were evaluated against 15 malware samples taken from various malware families from the Contagio Mobile Malware Mini Dump database. This is, to the best of our knowledge, the first academic study that provides a systematic and transparent evaluation of free antimalware apps for Android devices.
Our findings suggested that detection type is paramount in the responsiveness of detecting a malicious threat before, during, or upon immediate completion of a new app installation, which will prevent any consequent threat activation. Findings also suggested that there is a constant race between malware developers and security providers. For example, we identified that a number of free antimalware apps have outdated signature repositories and fewer options to change the default Android package installer. However, having an antimalware mobile app with automatic threat detection and removal installed is a significant advantage in protecting an Android device against potential malicious threats.
Future work includes:
1. Evaluate a wider range of devices in a live environment that would include both known and unknown (zero-day) malware samples. For example, users of the test devices would click on untrustworthy links and dubious advertisements and download attachments from phishing or spam email messages. Such experiment setting could potentially uncover additional malware families that have not been detected as part of signature repositories. The Android OS includes manual security features that allow or disallow the installation of nonmarket-based apps, which is a protective measure against manual app installations. For example, options such as “unknown sources and verify apps” are now included within Android KitKat and Lollipop, which prevent manual app installations taking place if selected. Therefore future work within a live environment will provide in-depth analysis into the relationship between malware and the Android OS.
2. Survey antimalware app users regarding their perceived effectiveness and reliability of the apps and evaluate the perceived effectiveness and reliability against the experiments either in a controlled environment (such as ours) or in a real-world deployment.
3. The above experiment (see Section 3.1) was conducted manually through a step-by-step process, where results were recorded manually on a per millisecond basis. The time involved was lengthy due to the precision of following each step of the experiment process, therefore limiting the malware sample dataset to 15 across 15 antimalware apps. Development of an automated process will enable the experiment to increase the malware dataset and include samples from different categories, as well as increase a broader range of antimalware apps, gaining further evaluation of their capabilities and limitations.
4. In addition, a list of prerequisites can be organized that will benchmark a number of different features that a user should expect from an antimalware tool. For example, does an antimalware app have options to change the default Android package installer? What about the ability to locate or lock a smart phone remotely or to notify the user of suspicious activity? Additional features would improve the overall effectiveness of an antimalware app.
Conflict of Interest Declaration
The authors are not affiliated with any security company or antimalware app provider. No personal recommendations or endorsement should be presumed from the apps selected in this study.