Technical Report RHUL–MA–2015–11 4 March 2015

Cross-Platform Malware Contamination Nicholas Aquilina

Information Security Group Royal Holloway University of London Egham, Surrey, TW20 0EX United Kingdom

www.ma.rhul.ac.uk/tech

Cross‐Platform Malware Contamination

Nicholas Aquilina

SRN: 090397493

2014

Project submitted as part of the requirements for the award of the

M. Sc. in Information Security of the University of London.

Project Submission Form

University of London M. Sc. Information Security

Student Project Supervisor

Nicholas Aquilina Dr Konstantinos Markantonakis SRN: 090397493

Miclor, Flat 2, Triq l‐Ghasir, Zebbug ZBG1501, Malta [email protected]

Anti‐Plagiarism Declaration

You are reminded that all work submitted as part of the requirements for any examination of the University of London must be expressed in your own words and incorporate your own ideas and judgements. Using another person’s thoughts or words as though they were your own work is considered to be copying or plagiarism. This is not allowed. You must clearly identify direct quotations from the published or unpublished work of another person by placing those quotes inside quotation marks, and also provide a full reference to their source. Whether you use a series of short quotations from several different sources or a single long quotation from a single source, they must all be identified clearly. Equally, if you summarise another person’s ideas or judgements, you must refer to that person in your text, and include the work referred to in your bibliography. Failure to observe these rules may result in an allegation of cheating.

I declare that this assignment is all my own work, and that I have acknowledged all quotations from the published or unpublished works of other people.

I declare that I have also read the statement on plagiarism in the General Regulations for Awards at Graduate and Masters Levels for the MSc in Information Security (Section 9) and in accordance with it I submit this project report as my own work.

Please sign here to show that you have read the above:

Nicholas Aquilina Date

To my wife

and son

Table of Contents

Acknowledgements ...... v List of Figures ...... vi List of Tables ...... vi List of Screenshots ...... vi Executive Summary ...... viii 1 – Introduction ...... 1 1.1 Background ...... 1 1.2 Aims and Objectives of the Project ...... 1 1.3 Research Approach ...... 2 1.3.1 Qualitative research approach ...... 2 1.3.2 Quantitative research approach ...... 2 1.4 Project Structure ...... 3 2 – Malware History and Cross‐Platform Contamination ...... 4 2.1 What is Malware? ...... 4 2.2 A Brief History of Malware ...... 5 2.3 How Malware Evolved from the Traditional Computer Platform to the Mobile Platform .... 6 2.4 Review of Various Malware Threat Models ...... 10 2.5 Review of Various Malware Infection Vectors ...... 13 2.6 Revenue Channels Exploited by Malware ...... 19 2.6.1 Billed events ...... 19 2.6.2 Payment systems ...... 20 2.7 Cross‐Platform Contamination ...... 20 2.8 Concluding Remarks ...... 23 3 – Malware Concealment Strategies ...... 24 3.1 Introduction to Malware Concealment Strategies ...... 24 3.2 Overview of Obfuscation Theory ...... 25 3.3 Passive Strategies to Evade Detection ...... 26 3.3.1 Code obfuscation ...... 26 3.3.2 Entry point obfuscation ...... 28 3.3.3 Encryption ...... 28 3.3.4 Packing ...... 29

3.3.5 Oligomorphism ...... 30 3.3.6 Polymorphism ...... 30 3.3.7 Metamorphism ...... 31 3.4 Active Strategies to Evade Detection ...... 33 3.4.1 Anti‐emulation ...... 33 3.4.2 Anti‐debugging ...... 33 3.4.3 Anti‐disassembling ...... 34 3.5 Concluding Remarks ...... 34 4 – Malware Detection Strategies ...... 36 4.1 Introduction to Malware Detection Strategies ...... 36 4.2 Malware Detection Using Static Techniques ...... 37 4.2.1 Introduction to static malware analysis ...... 37 4.2.2 Signature analysis and hashing ...... 37 4.2.3 Extract system calls ...... 38 4.2.4 Static taint analysis ...... 38 4.3 Malware Detection Using Dynamic Techniques ...... 40 4.3.1 Introduction to dynamic malware analysis ...... 40 4.3.2 Dynamic taint analysis ...... 41 4.3.3 Behavioural analysis ...... 43 4.4 Malware Detection Using Heuristics ...... 44 4.4.1 Introduction to heuristic malware analysis ...... 44 4.4.2 Monitoring API and system calls ...... 45 4.4.3 OpCode analysis ...... 45 4.4.4 Using N‐Grams for detection ...... 46 4.4.5 Representing malware through control flow graphs ...... 46 4.5 Malware Detection Using Hybrid Techniques ...... 48 4.6 Concluding Remarks ...... 50 5 – Improving Cross‐Platform Malware Detection ...... 51 5.1 Implementation and Analysis of Cross‐Platform Infection ...... 51 5.2 Framework Proposal to Limit Malware Propagation ...... 56 5.3 Challenges for Implementation ...... 59 5.3.1 Access to hardware drivers ...... 60 5.3.2 Power management ...... 60

iii

5.3.3 Functionality ...... 60 5.3.4 Security review ...... 61 5.4 Concluding Remarks ...... 61 6 – Conclusions and Proposals for Future Research ...... 62 6.1 Significance of Our Research ...... 62 6.2 Future Research ...... 62 Appendix 1 – Infecting and Controlling an Android Device ...... 64 Appendix 2 – Infecting and Controlling a Windows Computer ...... 69 Appendix 3 – Analysis of Mobile to Desktop Infection ...... 74 Bibliography ...... 85

Acknowledgements

The author of this dissertation would like to thank his project supervisor, Dr Konstantinos Markantonakis Ph.D., M.Sc., MBA, B.Sc., for his overall guidance on the concept of cross‐platform malware, and his useful direction on the write‐up of this project.

Heartfelt gratitude goes to Mr Stefan Bühlmann, CEO of Joe Security LLC for providing me with access to their ‘Joe Sandbox Cloud’, an extensive cloud‐based malware analysis system.

The author further thanks Dr Phyllis Aquilina B.A., LL.M. (Lond.), LL.D. for her proofreading and overall input in the linguistic aspects and presentation of this research study.

List of Figures

Figure 1 ‐ Aggregate total of mobile malware between 2011 and 2013 ...... 6 Figure 2 ‐ Overview of threats leading to exploits on mobile devices ...... 8 Figure 3 ‐ Client‐side attack of drive‐by downloads ...... 17 Figure 4 ‐ Malware lifecycle stages ...... 24 Figure 5 ‐ Flow of normal programme through obfuscation transformation ...... 25 Figure 6 ‐ Original code on the left hand side with dead code inserted on right hand side ...... 26 Figure 7 ‐ Code transposition based on unconditional branches ...... 27 Figure 8 ‐ Code transposition based on independent instructions ...... 27 Figure 9 ‐ An extract from the Cascade virus code ...... 28 Figure 10 ‐ Implementation of polymorphic engine ...... 31 Figure 11 ‐ Five separate stages of metamorphic malware ...... 32 Figure 12 ‐ Information flow to Object Y derived from Object X ...... 39 Figure 13 ‐ Object X is tainted through user input ...... 39 Figure 14 ‐ Static vs dynamic analysis ...... 41 Figure 15 ‐ Taint tracking of non‐validated input X ...... 42 Figure 16 ‐ An example of Control Flow Graph ...... 47 Figure 17 ‐ Reduction of original CFG to condensed CFG...... 48 Figure 18 ‐ Simple flow diagram of malware analysis using hybrid techniques ...... 49 Figure 19 ‐ Overview of our setup for cross‐platform malware contamination ...... 52 Figure 20 ‐ Common architecture for Windows and Android devices ...... 57 Figure 21 ‐ Proposed architectural layout with the hypervisor ...... 58 Figure 22 ‐ Flowchart of behaviour analysis ...... 59

List of Tables

Table 1 ‐ Various types of malware and their properties ...... 13 Table 2 – A classification proposal of various infection vectors ...... 19

List of Screenshots

Screenshot 1 ‐ Creating the malicious Android application ...... 64 Screenshot 2 ‐ Launching our Metasploit Framework ...... 65 Screenshot 3 ‐ Configuring the various parameters for our listening service ...... 65 Screenshot 4 ‐ Browsing our test website using Android ...... 66 Screenshot 5 ‐ Application requesting various permissions ...... 67 Screenshot 6 ‐ Issuing a command to get system information ...... 68 Screenshot 7 ‐ Listing the various processes running ...... 68

Screenshot 8 ‐ Creating the malicious Windows application ...... 69 Screenshot 9 ‐ Launching our framework and configuring the various parameters ...... 70 Screenshot 10 ‐ Browsing our test website using Windows ...... 71 Screenshot 11 ‐ Installation of our malicious Windows application ...... 71 Screenshot 12 ‐ Getting access to the command line interface ...... 72 Screenshot 13 ‐ Launching an application on the remote computer ...... 72 Screenshot 14 ‐ Application launched on the desktop of the remote computer ...... 73 Screenshot 15 ‐ Confirming the validity of our malicious application ...... 74 Screenshot 16 ‐ Malicious application installed on our Android device ...... 75 Screenshot 17 ‐ DroidCleaner menu options ...... 76 Screenshot 18 ‐ Clean up process done ...... 76 Screenshot 19 ‐ Analysing captured packets ‐ part 1 ...... 77 Screenshot 20 ‐ Analysing captured packets ‐ part 2 ...... 77 Screenshot 21 ‐ Querying specific IP address information ...... 77 Screenshot 22 ‐ Anti‐virus programme detecting malicious executables ...... 78 Screenshot 23 ‐ Connecting our Android device to Windows XP ...... 79 Screenshot 24 ‐ Wire Shark packet capture on Windows XP ...... 79 Screenshot 25 ‐ Further analysis of captured IP address ...... 80 Screenshot 26 ‐ Further analysis of svchosts.exe ...... 81 Screenshot 27 ‐ Details of attacker's server ...... 82 Screenshot 28 – Anti‐debugging features when run against a virtual machine ...... 83 Screenshot 29 – Anti‐debugging features when run against a physical machine ...... 83 Screenshot 30 ‐ List of commands available to the attacker ...... 84

vii

Executive Summary

The use of mobile devices in our everyday lives has become widespread. In recent years, the number of smartphones sold globally surpassed the number of desktop computers sold. Malware authors have followed this and developed sophisticated malware addressed both at the mobile device platforms as well as desktop platforms. Particular interest is being shown in the areas of Microsoft Windows operating system for desktop computers and the Android operating system for mobile environments, such as smartphones and tablets. At the same time, vendors of security solutions, such as anti‐virus and anti‐malware developers, face challenges from the limited and restricting security architecture of mobile platforms when compared to their desktop counterpart.

This project seeks to understand and analyse current malware strategies from both the attacker's perspective as well as the defendant's position. We analyse in detail various malware infection vectors and discuss new revenue channels which malware authors are exploiting. We review various malware concealment strategies, focusing on both passive and active strategies. We further review in detail a range of malware detection strategies focusing on behavioural analysis and hybrid malware detection techniques. In our research, we note that such detection techniques usually reside at a high level within the operating system stack. Attackers are well aware of this fact and have implemented various active and passive concealment strategies. This makes them as much vulnerable as any other application running on the device, whether it is a desktop computer running Microsoft Windows or a smartphone running Android.

With this theoretical framework in mind, we then concentrate on cross‐platform malware contamination between Windows computers and Android mobile devices. A practical demonstration of how a specific Android malware infects a Windows based computer through USB connection follows, giving our own views on how to limit cross‐platform malware contamination. In conclusion, we put forward for discussion a suggestion for the creation and implementation of a hypervisor at a layer below the operating system utilising a behavioural analysis framework. This project finishes off with a constructive criticism of our own proposal, bringing forth various challenges and barriers for its practical implementation.

viii

1 – Introduction

1.1 Background

It is generally acknowledged that malware contamination has increased at an alarming rate during these past few years. Malware is reportedly increasingly designed using sophisticated techniques, clearly to overcome many security architectures currently in use. At the same time, the past few years witnessed a sharp increase in the use of mobile devices. This increased, in turn, the threat of malware cross‐platform contamination.

Cross‐platform contamination may occur between a desktop computer infecting a mobile device, and vice‐versa. This study will analyse the various methods of malware propagation and infection vectors with particular focus on the way in which cross‐platform malware occurs. We will consider in detail the various malware detection strategies currently in use. On a practical level, this study will also present the reader a practical demonstration of cross‐platform malware contamination between an infected Android tablet and a Windows XP virtual machine connected through USB.

The point of departure in this study, drawn on relevant academic literature, is that protection mechanisms currently in use are devised to reside within the guest operating system. Our aim is to present an innovative architecture to increase the efficiency of existing malware detection methods. This innovative architecture involves the use of a hypervisor level residing between the hardware layer and the operating system and kernel layers.

1.2 Aims and Objectives of the Project

In execution of the said outline, this project takes a theoretical perspective. On the basis of the various academic literature and published journal reports, we review the various malware concealment and detection strategies in use, commenting their respective strengths and deficiencies and, on this basis, selecting the most efficient mechanisms.

Following this review, we will propose an efficient and practical way in which cross‐ contamination across platforms can be restricted through the use of a behavioural analysis framework.

Particular attention will be given to the two most common platforms in use, namely the standard Windows desktop PC (personal computer) and smartphones running the Android mobile operating system.

1.3 Research Approach

At the outset of this project, we had to select the most fitting research approach out of the two mainstream approaches, namely:

i. qualitative research ii. quantitative research

According to Denscombe [1], the main distinction between the two methods is that qualitative research tends to pick specific words and use them as the main factor for the analysis, whilst quantitative research tends to rely more on figures. Silverman [2] comments that many people seem to think that quantitative research may produce better outcomes than qualitative research.

This is surely not the case. In fact Gummesson [3] argues that the important thing is not to choose the most acceptable method of research, but to choose the right method to adopt in the light of the specific purpose of the research.

1.3.1 Qualitative research approach

Denzin and Lincoln [4] define qualitative research as ‘a situated activity that locates the observer in the world’. It is submitted that the qualitative method is helpful for identifying the aim of the research. Neill [5] argues that the main features of a qualitative research study are:

 A complete and detailed description;  Better placed for the earlier phases of research projects;  The design emerges as the study unfolds;  The researcher is the data‐gathering instrument;  Data is in the form of words, pictures or objects;  Subjective orientation such that individuals’ interpretation of events is important (e.g. in‐ depth interviews);  Qualitative data is more ‘rich’, time consuming and less able to be generalised;  Researcher tends to become subjectively immersed in the subject matter.

1.3.2 Quantitative research approach

Quantitative research is concerned with numbers and measurement, rather than words, in the collection and analysis of data [6]. Joppe [7] argues that the most common quantitative research techniques include:

 Observation;  Experimentation; and

 Surveys.

For the purposes of this project, we chose a qualitative approach, making use of the following literature sources:

 Published books on Information Security  Published books on malware  Published journals related to Information Security  Conference proceedings  Published reports by information security companies  Websites of various companies involved in operating systems, security and anti‐virus applications

1.4 Project Structure

Following this introductory chapter, this project report is structured as follows:

Chapter 2 – Malware History and Cross‐Platform Contamination

This chapter presents the reader with a brief overview of what is malware, its various threat models and infection vectors, and how it evolved from the traditional desktop computer to the mobile platform.

Chapter 3 – Malware Concealment Strategies

In this chapter, we provide the reader with an overview of various passive and active strategies which malware creators use to evade detection.

Chapter 4 – Malware Detection Strategies

This chapter sets off from the previous chapter. Here we present the reader with various malware detection strategies in use. We classify these various strategies in four sections, namely static, dynamic, heuristic and hybrid analysis.

Chapter 5 – Improving Cross‐Platform Malware Detection

In this chapter, we present a practical implementation of a cross‐platform attack. We demonstrate how a malicious application, downloaded onto an Android device, can infect our Windows‐based computer through a USB connection We then set off to propose a new framework with the intention of limiting such cross‐platform malware contamination.

Chapter 6 – Conclusions and Proposals for Future Research

This concluding chapter wraps up the various objectives that were attained during this project, putting forward various proposals on which future research may be carried out.

2 – Malware History and Cross‐Platform Contamination

2.1 What is Malware?

Malware is a general term used to refer to any software that is installed on a machine and performs unwanted tasks. A malware is a programme that has malicious intent [8]. Malware can range from a simple nuisance such as pop‐up advertising [9], to an intrusion [10] causing severe damage such as stealing passwords and data or infecting other machines on a network. As already noted, the purpose behind malware is malicious, hence the term malware (malicious software), utilising connected systems in order to propagate.

Eschelbeck [11] classifies malware into different generations based upon the payload, enabling of vulnerabilities and propagation mechanisms. The first generation includes malware sharing the same properties of a computer virus. It requires human intervention, or a system event, to trigger replication and spreading. Some examples of this malware include Melissa [12], LoveLetter [13] and SoBig [14]. The second generation includes malware that shares the properties of computer worms. It does not require any human intervention to replicate and propagates through the Internet by automatically scanning victims for known vulnerabilities. Examples of this type of malware include Slapper [15] and Blaster [16]. The third generation evolved into exploits and unknown vulnerabilities. These employ multiple attack vectors in order to replicate. Eschelbeck notes that by pre‐compiling and cataloguing vulnerable targets in advance, third generation malware strikes faster, preventing timely intervention by security administrators. It is also acknowledged that third generation malware employs various polymorphic techniques to conceal and encrypt its presence, in an attempt to delay discovery. An example of this generation of malware is the SQL Slammer worm [17].

Malware became known to many computer users and organisations through widespread infections of the Melissa virus [18] in 1999 and the LoveLetter worm [19] in 2000. Both were based on email attachments as their primary infection vector. On opening the attachment, the malware overwrote a variety of different types of files that existed on the user’s PC and emailed a copy of itself to the recipients stored in the user’s email address book. Despite the damage that Melissa and LoveLetter made, Microsoft [20] argued that these contributed to three positive effects:

1. They caused computer malware to receive increased scrutiny from the security community 2. They increased social awareness about computer malware through peer pressure 3. They increased the importance of backups

2.2 A Brief History of Malware

The first reported incident relating to mobile malware dates back to the turn of the third millennium. It was during that year (2000) that a worm, written in VBScript began spreading to mobile devices configured to receive emails [21]. This worm, called Timofonica, marks an important point in the history of computing where the mobile platform experienced its first notable security incident. It is to be noted though, that Timofonica did not spread on mobile devices, rather it spammed these devices using the traditional desktop PC.

The year 2004 saw the release of the first malicious software aimed at smartphones. Security researchers received copies of this first mobile malware, Cabir [22], a worm which infected the Symbian OS. Written by members of an international group of virus writers, calling themselves ‘29A’, it was mainly a proof‐of‐concept virus written in C++. The worm spread amongst Bluetooth‐enabled devices in discoverable mode and exploited the limited resources of mobile devices, at that time, battery life.

One of the best known epidemics of Cabir took place in Helsinki in August 2005, during the 10th World Athletics Championship [23]. Whilst this worm was more of an inconvenience than a threat at the time, today’s mobile malware is much stealthier and has more severe effects. In July 2004, we find reports of the first Windows CE virus. This virus, called Duts [24], infected all the files in the device’s root folder using Windows mobile, appending itself after displaying the message: ‘Dear user, am I allowed to spread?’.

From the year 2010 onwards, the mobile market saw some significant changes. First, Android began to position itself as the most popular mobile operating system in the market. That same year saw the release of the first malware targeted at this platform, FakePlayer [25]. Another notable change was the increased complexity of this malware. At the second quarter of 2013, Kaspersky Labs reported an aggregate total of 100,386 mobile malware modifications to its systems [26], which can be considered as a dramatic increase when compared to just over 46,000 modifications reported at the end of 2012. The following graph, taken from the same report, shows the aggregate total of mobile malware which Kaspersky Labs detected during the years 2011 and 2013:

Figure 1 ‐ Aggregate total of mobile malware between 2011 and 2013

(H1 refers to first half, H2 refers to second half)

The second quarter of 2013 saw the release of one of the most sophisticated Android Trojans so far. Named Obad [27], this malware can send SMS messages to premium numbers, download and install other malware on infected devices, send a list of installed applications to the server, send the user’s contact data to the server and replicate itself via Bluetooth. The console of the malicious author can also issue remote commands. It uses the AndroidManifest.xml file, used to define an application's structure and parameters in Android, to obscure its behaviour should security researchers try to analyse it. In addition, it exploits an error in DEX2JAR which makes it harder for researchers to convert APK (Android application package) files into JAR (Java Archive) format, making it extremely difficult to detect, analyse and remove.

2.3 How Malware Evolved from the Traditional Computer Platform to the Mobile Platform

The traditional desktop and mobile environments are not the same. There are various differences and these have been commented in detail by many security experts. Some of these differences discussed by key authors [28], include:

1. A mobile device typically has only limited processing power, storage capacity and battery power. Mobile devices’ CPU speeds/architecture and memory capacity have been increasing rapidly in the past years. However, these specifications in the mobile environment are still less than their desktop counterparts. On account of these limitations, many complex anti‐ malware solutions existing on the desktop platform cannot be implemented fully on the

mobile platform. The overhead for executing such complex solutions would incur excessive use of CPU and memory resulting in lower battery life.

2. Mobile malware can spread without the reliance of the network infrastructure, such as Bluetooth interfaces. As opposed to the desktop platform, mobile devices are not limited to the traditional network interface connection (namely through cable Ethernet or wireless). Therefore, when a new malware signature is available, the mobile device may not be able to obtain it in a timely manner, unless the mobile device is configured to use mobile data communications (3G/UMTS).

3. The mobility of a mobile device makes it more difficult to quarantine the malware in a local area. Traditional desktop platforms normally operate through network connections within a specific area, even though the advance of laptops/notebooks has dramatically reduced this ‘fixed’ connectivity.

4. The user interface within a mobile device is different from a desktop computer interface. To start with, the screen size and resolution are much higher on the desktop platform than on the mobile platform, including tablets. Security mechanisms applied to the desktop computer such as visual indicators in URLs and CAPTCHAs, may not be applicable to the mobile counterpart. A CAPTCHA is a programme that protects websites against bots by generating and grading tests that humans can pass but current computer programmes cannot [29]. A recent study, carried out in 2011 by Felt and Wagner [30], shows that constraints in the mobile user interface make it easier for attackers to conduct phishing attacks than on the desktop browsers.

In the following diagram, we show the differences between desktop and mobile devices categorised in four sections. When applied to mobile devices, malicious attackers can exploit each of these sections which will, in turn, cause damage to the victims. Malicious attackers exploit these differences to the prejudice of users. We can consider the above mentioned differences in the figure below showing how these differences can be exploited to create malware targeted specifically for the mobile platform.

Mobile Device

Different Limited Network User Interface

Attack Vectors Resources Environment Limitations

Malware exploits

Costs for the Victim

Figure 2 ‐ Overview of threats leading to exploits on mobile devices

The mobile platform is seen as an appealing platform for many specialists working in different sectors, particularly e‐commerce and online streaming applications. Mobile communication systems, supporting voice and data services, have become ubiquitous. People are now finding these devices indispensable in their lives. One could foresee that this increased popularity would make them more attractive target for attackers. Many of these applications involve the transfer of large sums of money. Their security is therefore paramount.

Various authors have described different types of attacks with the aim of overriding the inbuilt security for desktop and mobile platforms alike. Alfalayleh and Brankovic [31] refer to the following types of attacks:

 Unauthorised access. Malicious users try to access the services and the resources of a platform without permission. This type of attack is usually the precursor to any of the following attacks.

 Masquerading. The attacker assumes the identity of a trusted entity in order to gain access to the platform’s services and resources.

 Denial of Service. Attackers cause denial of service to platforms by either consuming resources such as CPU clock cycles, memory or disk space, altering or deleting system files or else launching a denial of service against another platform.

 Annoyance attack. Although annoyance attacks may not necessarily be a very serious problem, they can still cause damage when used as a decoy by Trojans or Rootkits [32].

 Eavesdropping. During an eavesdropping attack, the malware will monitor the behaviour of the PC or mobile device and extract sensitive information from it [33]. Examples of sensitive information may be PIN numbers used for online payment systems or confidential documents that may be transmitted via Internet in an encrypted form. DroidCleaner [34], an Android application, claimed to free up the memory of smartphone devices when in fact, it deceived the user in installing an application to infect the PC connected to it.

Applying the Confidentiality, Integrity, Availability model [35] to the computer and mobile platforms with regards to malware, we are faced with the following issues:

1. Confidentiality

Confidentiality is an important concept in Information Security requiring that information is carried between, and stored, on platforms that are only accessible to authorised parties. This includes information transmitted over communications media such as the Internet; as well as information stored on devices such as the internal storage memory of a mobile device. The Information Security community is constantly analysing the ever‐evolving encryption techniques. We are experiencing various attacks related to confidentiality of data and information. Recent malware attacks used both on desktop PCs and Android devices, such as CryptoLocker [36], are using encryption to encrypt the most important files on a victim’s device, demanding payment to release the decryption key.

2. Integrity

The data communicated or stored must also be protected from any unauthorised modifications. This requires implementation of security policies that detect, and ideally prevent, any such unauthorised modifications.

3. Availability

Desktop and mobile devices nowadays are used for various services. The issue of availability is becoming critical as increasingly more users depend on these services. Denial of service attacks are a frequent occurrence nowadays. The occurrence of such attacks is becoming more prominent as a means of extortion or blackmail.

In the next two sections (2.4 and 2.5), we will be reviewing the commonest malware threat models and their attack vectors, including the attacks mentioned above.

2.4 Review of Various Malware Threat Models

The ultimate goal for a malware author is to damage or disrupt a computer system, whether on a desktop PC or mobile device. Delac et al [37] include in their definition of malware such hostile software as viruses, worms, Trojans, spyware, backdoors, rootkits and botnets across different platforms. The following is an overview of these different types of hostile software:

2.4.1 Viruses

Viruses have been around since the early 1980s [38]. Various definitions exist of what a virus is. Generally speaking, a virus is a type of malware that enters a computer system via the hardware or software without the user’s knowledge and then attaches itself to a programme file [39]. The virus then starts to replicate and commits the various malicious tasks that it is programmed to do. The severity of the damage that viruses can bring along varies. Such damage may include loss of integrity on data, software corruption and denial‐of‐service (DoS).

A virus cannot exist on its own and needs a carrier in order to propagate itself.

2.4.2 Worms

Worms are a type of malware that slips into computer systems without the owner’s permission, and operate without the owner’s knowledge. Whilst a virus is dependent upon a host file or the boot sector of a device and the actual transfer of files between machines to spread, a worm can run completely independently and spread itself through network connections. Worms can replicate themselves and send out thousands of copies from each infected system. This is done using the contact details stored within the system. Worms have a devastating impact on Internet traffic, various web sites and the infected system itself.

An example of a worm which had a devastating effect on the World Wide Web was the infamous Blaster worm, discovered in August 2003 [40]. According to Symantec Corporation [41], “Blaster is an example of an increasingly dangerous type of computer virus known as a 'blended threat.' Blended threats combine the characteristics of viruses, worms, Trojan horses, and other malicious code, taking advantage of vulnerabilities in operating systems and applications to initiate, transmit, and spread an attack. By combining multiple vectors and techniques, blended threats can spread rapidly and cause widespread damage".

2.4.3 Trojans

Trojans are a type of malware named after the wooden horse the Greeks used to infiltrate Troy [42]. A Trojan is a harmful piece of software that appears legitimate to the user receiving it. The user is tricked into loading and executing the software with the idea that the software will perform a required function. After activation, the Trojan can attack the host itself through different processes, such as changing desktop background, damaging or deleting files, stealing data, activating and spreading other malware. In addition, Trojans are widely known to create backdoors on the infected system, providing remote access to malicious users. A Trojan is a type of masquerading attack, activated by the user and does not replicate. An example of a Trojan on the Android mobile platform is Soundminer [43]. This Trojan monitors phone calls and records data. This infiltration can occur, for instance, when a person communicates his credit card number or enters it on the phone's keypad. Using various analysis techniques [44], Soundminer trims the extraneous recorded information down to the most essential, such as the credit card number itself, and sends this specific targeted information back to the attacker over the network.

2.4.4 Spyware

A function of spyware is collecting information for advertising purposes. The presence of spyware on a device is normally hidden from users and hard to detect. Spyware has the capability of capturing credit card details, passwords and email addresses, to name a few. In addition, it can also monitor the user’s web activity or change the default page of the web browser. Spyware is usually infiltrated when the unsuspecting user installs free software of his choice. Upon installation, the spyware will piggyback on the installation and start collecting data from the user’s activities. The user can also be tricked into installing the spyware through a Trojan horse, such as pretending to be a free piece of security software [45].

2.4.5 Backdoors

A backdoor [46] is a remote administration utility. Once these remote administration utilities are installed on a device, they allow access to the malicious user, enabling him to control the host over a network or over the Internet. Undocumented processes may exist within the device’s system code, enabling the backdoor to exploit it and gain control of the target device. A typical backdoor consists of two components ‐ the client and its server or servers. An attacker will use a client application to communicate with the server components, which are installed on the victim's device. The components that form the server, installed on the device, can be delivered to the victim's system in various ways such as part of a worm or Trojan payload, as an e‐mail attachment or as a tantalizingly‐named file on peer‐to‐peer networks. Backdoors may be considered as legitimate when installed by authorised administrators for legitimate reasons.

2.4.6 Rootkits

Rootkits [47] can be considered as a special type of malware that hide their presence, their files and processes and any network links that are established on the target device. In order to do this, rootkits load special drivers within the lower layers of the operating system such as API function redirection or using an undocumented OS function [48]. This feature makes them almost undetectable by common anti‐malware software. Rootkits may be included in a larger software package, or may be installed by an attacker who has been able to take advantage of vulnerabilities in the target device.

2.4.7 Botnets

Botnets are a type of malware that allows an attacker to control a compromised set of remote devices. Some of the attacks often used by attackers through the use of botnets include large scale network attacks such as distributed denial of service attacks (DDoS), spam or collection of private information. A modern definition of a 'bot' [49] is advanced malicious software that incorporates usually one or more aspects of the aforementioned techniques introduced by viruses, worms, Trojan horses and rootkits for propagation and hostile integration into a foreign system, providing the functionality of the compromised system to the attacker.

A simple botnet configuration is where the bots are connected to a single central server. This configuration, however, does not scale much and closing the single central server will effectively neutralise the botnet. Another configuration is possible, whereby through the use of a hierarchical structure, the bot master connects to hundreds of bots which in turn are connected to many other bots. This type of configuration scales much better than the single central server one. Ahmed et al [50] argue that while PC‐based botnets have become one of the most serious threats to the Internet, mobile botnets targeted for smartphones are not as popular as their counterparts for a variety of reasons including resource issues, limited battery power, and Internet access constraints.

The differences between the various types of malware as described above are listed in table 1 from Peng et al [51] (ibid, p. 4):

Type Virus Worm Trojan Backdoor Spyware Rootkit Botnet Form Parasitic Independent Disguised Disguised Disguised Disguised Disguised Propagation Depends on Self Deception Deception Deception Deception Deception the host file replication Target Local file Network Local system Local system Local system Local system Local system hosts Human Yes No Yes Yes Yes Yes Yes intervention Major risks System Network loss Information Information Information Information Information damage leakage leakage leakage leakage leakage and system damage Infection Fast Very fast Slow Not Slow Fast Very fast speed applicable Detection Simple Very complex Complex Complex Complex Complex Complex

Table 1 ‐ Various types of malware and their properties

2.5 Review of Various Malware Infection Vectors

Infection vectors for malware have changed over the years, moving from the traditional desktop platform over to mobile devices. Viruses initially spread through the use of infected floppy discs. When the use of floppy discs declined, Internet connectivity became more ubiquitous and malware managed to spread utilising techniques, such as mass email lists or web vulnerabilities. Infection vectors which malware uses for mobile devices also had a similar effect, moving from simple SMS or MMS infection vectors to Bluetooth, email and web vulnerabilities. The following are the most common infection vectors utilised by malware for infection and propagation which, in our view, apply to both the traditional PC and mobile devices:

2.5.1 SMS/MMS

Cellular services, such as the short message service (SMS) and the multimedia messaging service (MMS) can be considered as primary attack vectors for the mobile platform. Text messaging is often used to interact with various automated systems, for example ordering products or services, or participating in contests such as voting. Though short messages are limited to 140 bytes [52], longer messages can still be sent by segmenting the message and sending it in multiple parts. The end recipient is responsible for reassembling the complete (multipart) message. Short messages can also be used to send binary content [53] such as ringtones and logos. While SMS is mainly limited to text, MMS is more advanced, allowing also the transmission of multimedia objects, such as video and audio. The ComWar worm was the first worm for mobile phones which was able to propagate via MMS [54]. It infected mobile phones running under OS Symbian Series 60. The worm increased its chances of propagating across mobile phones by targeting other phone owners listed in the victim’s address book. By masking itself as originating from a trusted source, an incoming message is more likely to be accepted and read by the recipient.

2.5.2 Bluetooth

Bluetooth [55] is a short‐range radio communication protocol allowing Bluetooth‐enabled devices (whether mobile or stationary) within 10‐100 metres to communicate with each other. It is possible to have up to eight devices that can communicate with each other through the use of a ‘piconet’ [56], where one device works as a ‘master’ and the other devices act as ‘slaves’. The master will take turns to communicate with each slave in a round‐robin fashion. Any device can search for other nearby devices, and any devices configured to respond back will give out their name, class, list of services and other technical details such as the manufacturer. Devices that are compromised will try to pair with other devices using default Bluetooth passwords. If a connection is made, the compromised device will send out its malicious content to the other device [57]. The Cabir (ibid) worm was the first worm to use Bluetooth as an attack vector. It used a file named caribe.sis that contained the worm's main executable caribe.app, system recognizer flo.mdl and resource file caribe.rsc. The caribe.sis file did not arrive automatically to the target device, so the user needed to answer ‘yes' to the transfer question while the infected device was still in range. The question was repeated to the user who selected ‘no’. The SIS file contained autostart settings that automatically executed caribe.app after the SIS file was installed. The worm was then activated and started looking for new devices to infect via Bluetooth.

2.5.3 Internet access

In a recent survey carried out by Palo Alto Networks and published on Info Security Magazine [58], it transpired that 90% of fully undetected malware was delivered via web‐browsing. Since the early days of the Internet, email was the vector of choice for malicious attackers delivering malware to a target. This report highlights the fact that this trend is rapidly changing. The report further claims that, while emails certainly continues to be a major source of malware, attackers are increasingly turning to real‐time, web‐enabled applications to deliver malware that is undetectable by traditional anti‐virus and anti‐malware solutions. Mobile devices can access the web using Wi‐Fi or 3G connectivity, allowing users to make use of common Internet applications such as web surfing, instant messaging, social networking and email. Apart from the convenience of such services they expose mobile devices to the same threats as the desktop platform. Moreover, mobile phones are constantly switched on, thus increasing the chances of a successful attack, especially where a constant Internet connection is maintained.

We refer the reader to Appendices 1 and 2 for a practical demonstration of how we managed to create malicious applications for Android devices and Windows computers. Once the user downloads these applications and installs them on his device, a backdoor is created to the attacker’s command‐and‐control server. We demonstrate how the attacker can perform illicit tasks on the victim’s device, such as taking a photo using the mobile camera or launching a remote application on the Windows computer.

2.5.4 Social engineering

Even though one may correctly deduce that social engineering attacks are a form of attack vector related to Internet access, we feel that a detailed explanation of this attack vector is required. The proliferation of social network websites has brought about various attacks listed throughout the literature which involve identity theft. The United States Computer Emergency Readiness Team (US‐CERT) states that social engineering is one of the most common methods of spreading malware on the Internet [59]. Such malicious activity is often successful since users are deceived into believing it is coming from legitimate sources. The authors of this technical paper classify social engineering attacks into three types:

1. Phishing. This is the act of attempting to manipulate a victim into providing sensitive information by masquerading as a trustworthy person or entity. The victim would not divulge such information were it not for this masquerading attack.

2. Vishing. This social engineering attack utilises voice communication, combined with other forms of social engineering, to entice a victim to call a certain telephone number and communicate sensitive information. Though in theory this may seem impractical, this type of attack becomes more feasible through the use of Voice over Internet Protocol (VoIP) and other Internet broadcasting services.

3. Smsishing. Smsishing [60] is another form of social engineering attack that exploits SMS. Short text messages may contain hyperlinks to webpages, email addresses or phone numbers that, when clicked, will automatically open a browser window or email message or dial a number. Several websites provide the capability to significantly shorten a URL [61]. This capability is often integrated in social networking applications to happen automatically [62]. Shortened URLs are invaluable in this case because they allow a URL with 137 characters to be shortened to 17 characters. Malicious attackers take advantage of this feature to hide a malicious URL within the condensed URL [63]. Since the original URL is completely replaced, a user cannot know the destination of the shortened link without having first clicked on the link. Legitimate URLs are indistinguishable from malicious ones, providing attackers with an effective cover. This tactic could lure a victim into unwittingly downloading malware or visiting a fraudulent site.

2.5.5 Synchronisation/USB

USB is currently employed as a means of charging, communicating, and synchronizing the contents of the phone with computers and other phones. Unlike the network and Bluetooth communications for mobile devices that have some predefined set of defence mechanisms in place, USB traffic is not authenticated, filtered, or vetted [64]. For example, to establish Bluetooth connectivity, the user is required to enter a passcode in order to establish connection between unpaired devices. On the other hand, USB connections are overlooked both by the

15 users and by the defences, and are assumed as a trusted communication channel. This inherent trust is rooted in the belief that physical proximity implies trust. Later on (see sections 5.1.2 and 5.1.3), we shall be seeing how the use of synchronisation between mobile device and desktop PC leads to cross‐platform malware contamination. This contamination may be transmitted from the personal computer to the mobile device, as well as vice‐versa.

In addition to the above listed attack vectors commonly outlined in literature, we feel that the following attack vectors also pose a real security threat, and can be easily exploited by malicious attackers.

2.5.6 WiFi

The ever‐increasing use of WiFi networks coupled with security loopholes make WiFi connections an ideal distribution medium for malicious programmes. Hu et al [65] proved that in densely populated urban areas, WiFi routers form a tightly interconnected proximity network that can be exploited as a substrate of malware to launch massive fraudulent attacks. These authors highlight the fact that wireless networks are weakened because of general security, including keeping the default router password and leaving the WiFi router open with no authentication/encryption, thus making the networks behind these routers more vulnerable to malware attacks. Their report however claims that such a large scale attack requires meeting certain conditions; the key among those conditions is installing unprotected routers. A recent article published by the Internet Crime Complaint Centre [66] confirms that there have been instances of travellers’ laptops being infected with malicious software while using hotel Internet connections. This is a real concern that must be taken into consideration both when users set up WiFi networks within their home or business environments, as well as outside their trusted zones.

2.5.7 Jailbreak for iOS and Root for Android

The terms ‘jailbreak’ for Apple products, and ‘rooting’ for devices running Android, are nowadays a common reference [67] to the gaining of access to areas of the mobile or tablet device that normal users are not supposed to have access to. When the device is in this state, the user is able to make modifications, such as using alternative application stores or having direct access to the device’s file system. Malicious users may take advantage of this state to implant their malicious software which can access the whole file system without any system restrictions.

2.5.8 Peripheral memory cards

Removable storage and memory cards have been used by malware authors to infect devices on traditional as well as mobile platforms. Using these media, malware can potentially infect not only mobile devices but also any other device that is equipped to read such memory cards. This infection vector opens the possibility of creating malware that will run on more than one platform. Cardtrap was the first cross‐platform mobile malware that used memory cards to propagate [68]. This worm was designed for mobile devices running Windows CE, J2ME, Symbian, iOS, Blackberry OS and Android. Its main aim was to spread and infect as many mobile devices as possible. The worm created an autorun file on the memory card. This file attempted to install another malware once the memory card was inserted into a card reader. This method of propagation was seen as a novel approach at that time. In a quite recent incident, Vodafone discovered traces of the now defunct Mariposa botnet malware on memory cards shipped to some 3000 mobile devices [69] [70].

2.5.9 Drive‐by downloads

Drive‐by download attacks are considered amongst the commonest methods for spreading malware today [71]. Drive‐by download malware first pushes, and then executes, malicious code on a target system without the user’s consent. These attacks target the uppermost layer of the OSI 7‐layer model, the application layer. A common attack would be to exploit memory corruption vulnerabilities within web browsers and their plug‐ins, executing shell code and gaining control of a target system. In figure 3, Narvaez et al [72] illustrate this infection process in a simple way. In step 1, the browser sends a request to a remote web server. In step 2, the server responds back by returning a web page, containing the specific attack code which exploits the browser vulnerability.

Figure 3 ‐ Client‐side attack of drive‐by downloads

We understand that drive‐by downloads can be used as a means to attack various platforms. Malicious attackers may craft a specific code that targets a particular vulnerability. Despite the possibility of infecting various web browsers on the desktop computer, attackers can also target smartphones. It is a known fact that, nowadays, smartphones are considered as a miniature computing platform open to attack on the same basis as the desktop computer. Various web browsers are available for download across the Android Play store. These browsers can still exhibit various vulnerabilities which may not be known to the user, especially if these are not regularly updated. A Trojan discovered in 2012 targeted Android devices. This appears to be the first time that compromised websites have been used to distribute malware targeting specifically the Android platform. The distribution of this Trojan, called NotCompatible [73] depends on the compromised website. If a user visits a compromised website that has a hidden iframe at the bottom of the page, the mobile web browser will automatically download the Trojan application. An Android device infected with this Trojan could potentially be used to gain access to normally protected information systems or used in a DDoS attack.

2.5.10 Mobile application markets for Android devices (Google Play)

Mobile users generally make use of an online market store to download, and keep updated, various applications for their mobile devices. The official market store for Android users is Google Play. Throughout the past two or three years, various cases were reported of malicious applications being uploaded onto Google Play, concealed as legitimate applications.

To counteract this threat, Google introduced Bouncer [74]. Bouncer examines applications submitted to Google Play automatically by execution inside a virtual Android environment, thereby reducing the amount of malicious applications available. Android users have the added possibility of downloading applications from other sources which may not be secure and may be controlled by malicious users.

Through a process known as repackaging [75], a malware author can repackage a legitimate application with malware and either distribute the application on Google Play or distribute the pirated application through other online markets. Any user that downloads this repackaged application will get infected and the relevant payload installed on their device.

Having reviewed the various malware infection vectors, we propose a classification of the various infection vectors in table 2, based on the similarity and differences between platforms:

Infection Vector Computer Mobile device

SMS/MMS No Yes Bluetooth Yes Yes Internet access Yes Yes Social engineering Yes Yes Synchronisation Yes Yes WiFi Yes Yes Jailbreak or Root No Yes Peripheral memory cards Yes Yes Drive‐by downloads Yes Yes Application markets No Yes

Table 2 – A classification proposal of various infection vectors

We note that the vast arsenal of infection vectors available to malicious attackers may be further utilised for cross‐platform malware contamination.

2.6 Revenue Channels Exploited by Malware

As already mentioned earlier (section 2.3), the primary idea behind the creation of malware is the generation of costs for the user. This will, in turn, generate revenue for the attacker. Many of the documented malware attacks use traditional means of deceiving their victims such as stealing financial information and other personal information, click fraud, extortion and espionage.

Mobile devices have a specific bundle of attack vectors. Some of these attack vectors are new to both individuals as well as organisations. Becher et al [76] state that the generation of costs can be divided in two events: those events that generate costs to the user by the mobile network operators and events that generate costs to the user arising from payment systems. A brief overview of their work is given below:

2.6.1 Billed events

The problems related to the costs issued by the mobile network operators existed when desktop platforms were in common use. Specific malware, called diallers, dialled premium‐rate numbers through landlines using modems or ISDN lines. These premium‐rate numbers were controlled and operated by malware authors. The increased use of always‐on connections, such as broadband connections, slowed down the propagation of these events. However, with the ever increasing use of mobile devices, these events are likely to remain in the foreseeable future. A recently published attack [77] demonstrated how malicious users can force mobile devices to send premium‐rate SMS messages. It also demonstrated how to prevent them from receiving

19 messages for long periods of time using special applications called SIM Toolkits. SIM Toolkits [78] receive commands via specially formatted and digitally signed SMS messages. These messages are processed without appearing in the user’s inbox. The attack demonstrated how an attacker might use an SMS spoofing service to force the dispatch of an error message to a premium‐rate number. As a result, fraudulent charges are debited to the account of the owner of the targeted device.

2.6.2 Payment systems

Payment systems for mobile devices can be compromised through the messaging functionality or through physical proximity. Using the messaging functionality of a mobile phone as a trustworthy channel, malware can forward messages such as online banking transaction numbers or online payment services [79]. Mobile devices are nowadays being used as physical payment devices. Proximity payments based on Near Field Communication (NFC) has opened up new possibilities for malicious attackers. Although at the time of writing, no specific malware has yet been devised, various organisations have brought to light possible vulnerabilities. One such example is to proxy a URL stored in NFC tags which, when parsed with a mobile supporting NFC, will launch the malware instead of the Browser. McAfee has also warned that Near Field Communications (NFC) could allow mobile devices to become infected by touching other phones infected with malware [80].

2.7 Cross‐Platform Contamination

Cross‐platform malware has been around for quite some time. The first worm considered to be also the first cross‐platform malware, was released in 1988 [81]. In less than twenty four hours, it caused the greatest damage that was witnessed by malware at that time. The Morris worm slowed thousands of systems by creating different processes and temporary files and folders, while at the same time spreading copies of itself. It exploited vulnerabilities on the VAX and Sun Microsystems platforms, as well as vulnerabilities in the Sendmail UNIX email delivery software. Hence it was deemed to be the first malware programme to utilise cross‐platform contamination.

Peter Ferrie [82] notes that following the Morris worm, other multi‐platform malware emerged. This included the W32/W97M Coke in 1999 and the W32/HLP Dream and Pluma in 2000. In 2001, we saw the release of W32/Linux infector called Peelf and more recently, in 2005, three new multi‐platform scripting viruses were released. Although a proof‐of‐concept, Peelf had the ability to infect various Microsoft Windows systems as well as Linux.

It is well known that USB is commonly used as a means to charge, communicate and synchronise the contents of mobile devices with computers as well as with other phones. It is therefore of no surprise that malware exploits this communication medium as a means to propagate itself. This threat vector creates potential for malware installed on a PC to take over a mobile device when

20 the device is connected via USB interface to the infected PC. This threat vector can also work in the opposite direction: the mobile device can infect the PC when connected using the same interface. During the 26th Annual Computer Security Applications Conference in 2010, Wang and Stavrou (ibid) demonstrated how a PC can abuse the USB connection to unlock and flash the software of a mobile device, bypassing all software and hardware defences. According to researchers, when a USB cable is connected to a computer or a smartphone, a message pops up indicating that the computer has detected a connection. However, the message is only visible for less than a second, and the user may not even notice it. Researchers note that, to make matters worse, both the computer and smartphone are completely unaware of the type of device that is connected to the USB port. As a result, very little, if any, user interaction is necessary for the USB device to take over the system. In addition, by posing as a Human Interface Device (HID) such as a keyboard or mouse, an infected mobile device can take over a computer.

Another example of how cross‐platform malware may contaminate both mobile devices and PCs lies in the form of malware that is available in third‐party application stores or official application stores. A team of researchers from Georgia Tech [83] demonstrated how hackers can upload malicious applications on the official ‘Apple App Store’. The team created a malicious application, called Jekyll, posing as a benign news reader. Hidden within the code, however, was a proof‐of‐concept code that was activated only after Apple vetted, and approved, this application. The malicious payload was able to send tweets [84], email and text messages without the user's knowledge. It could also steal the iPhone's unique device ID, turn on the camera and take video, forward voice calls to other phones and connect to local Bluetooth devices.

In another instance, Symantec Corporation discovered 14 applications that were published on Google’s Play store [85] which were all developed by the same malicious developer. The malicious payload that runs in the background as an Android service communicated with a number of command‐and‐control servers that waited for the developer instructions. Such applications may be the perfect means to spread other malware both to other mobile devices as well as to PCs. The use of propagation means already covered, such as SMS, Bluetooth or WiFi could be implemented and exploited.

Even though cross‐platform malware is not considered to be as common as other forms of malware targeting specific platforms, the recent interest in online banking systems has spurred an increase in malware authors’ interest. Many commercial banks and other financial institutions are now trying to maximise the amount of online services that are available to their clients. One of the most popular security features of online banking services is the use of TAN codes (Transaction Authentication Number) with digital signatures [86]. In some cases, banks send TAN codes via a text message (mTANs, or mobile transaction authentication numbers).

In December 2012, Dmitrienko at al [87] demonstrated through a proof‐of‐concept attack how cross‐platform contamination could be used to break mTan‐based online banking authentication [88]. The normal authentication procedure for mTAN‐based authentication is as follows:

1. As a first step, the user authenticates with the bank using a set of credentials.

2. When the user is successfully logged in, he can browse the details of his relevant accounts. However, transactions involving sensitive operations, such as money transactions, are not allowed. These have to be authenticated by mTANs. 3. To perform such a transaction, the user will have to fill in an online form displayed on his terminal. 4. Once the form is filled in, a transaction request is sent to the bank. The bank will generate a random mTAN which is sent to the user’s mobile via SMS. 5. The user will then input this transaction number in the form displayed on his terminal. The transaction authentication code is sent to the bank which is then validated. 6. If the received mTAN is the same as that transmitted, then the transaction is authenticated.

The attack scenario that was demonstrated by Dmitrienko et al was divided into three phases. In the first phase, malware installed on the terminal steals the user’s credentials (namely login and password) and forwards them to the attacker’s server. In order to steal the user’s credentials, the user’s terminal waits until the user logs into the online banking site. During the login procedure, it may either eavesdrop on the user’s input or else reads out the information entered into the Internet browser through the login and password form fields. These credentials are then passed on to the remote malicious server.

The second phase involves the cross‐platform infection, where the malicious terminal infects the user’s mobile device. In order to perform this cross‐platform infection, the user’s terminal will launch a man‐in‐the‐middle attack on the user’s mobile device. This will allow the attacker to manipulate the Internet traffic that is routed to and from the mobile device. A possible infection vector could be a malicious URL that is sent to the mobile such that when the user taps on this link, an exploit is downloaded and executed without the user’s knowledge. This exploit will perform privilege escalation in order to gain SMS interception. A possible way to carry this out is to rename the device that is associated with the GSM modem and create another pseudo‐ terminal. The user will not receive notifications from the default GSM modem but from this pseudo‐terminal controlled by the exploit package.

During the third phase, the malicious server performs the transaction with the user’s bank, mimicking itself as the user. The mTAN transaction requests are filled‐in by the malicious server itself whilst the infected mobile intercepts the mTANs sent by the bank, forwarding them to the malicious server which completes the transaction. The malicious server will send the login credentials to the bank. It will then fill in the relevant transaction forms and sends these out to the bank. The bank will reply back with an SMS containing the random mTAN. The mobile device will hide this SMS from the user and will forward the message to the malicious server. This will in turn send the mTAN and the other transaction details to the bank.

2.8 Concluding Remarks

In this chapter, we presented an overview of how malware evolved and started targeting mobile devices in addition to traditional desktop computers. When comparing and contrasting the differences that exist between these two environments, we appreciate why the mobile environment is becoming appealing for malware creators. We believe that malware authors are targeting specific users with the intent of achieving immediate profits through the use of multiple infection vectors, commonly referred to as ‘blended threats’.

The use of various online banking and authentication services using mobile devices is increasing. Attackers are well aware of this fact and are now devising highly specialised attacks targeting the unaware user on both fixed and mobile devices. Through the use of social engineering techniques, clients of these online services are becoming a vulnerable target. Even though it is considered as a proof‐of‐concept, the above example confirms the high level of complexity that malware authors achieved throughout these past few years.

With this appreciation in mind, we now propose to embark on a detailed study of cross‐platform malware contamination, with particular focus on select malware concealment strategies.

3 – Malware Concealment Strategies

3.1 Introduction to Malware Concealment Strategies

Malware concealment strategies serve one purpose, namely survival of the code. The longer malware can protect itself from detection, the more time it has available for replication and infection. The malware lifecycle, as shown in figure 4 below, can be seen as being made up of four phases:

Phase 1 Phase 2 Infect Detect

Phase 4 Phase 3 Eradicate Analyse

Figure 4 ‐ Malware lifecycle stages

Concealment strategies aim to increase the span of time between infection and detection phases. In addition, these strategies aim to make the analysis part of malware difficult for the anti‐ malware developers. Through various concealment strategies which we will be looking at in the sections below (sections 3.3 and 3.4), malware authors aim to spread and prosper, hiding their code from plain sight. The first malware known to use concealment strategies to obfuscate its existence was the Brain virus [89], released in January 1986. The virus creators, the Farooq Alvi brothers, replaced the boot sector of a floppy disk with a copy of the virus. The real boot sector was moved to a different sector, marked as a bad sector. The technique used is often referred to as ‘garden pathing’, based on the general idea that a path in a garden is something very pleasant to walk in, whilst at the same time, deceiving the user about the dangers. This was the precursor to modern and more complex concealment strategies. A more recent example of a virus implementing concealment strategies is Zmist [90]. This specific malware knits itself to the code of its target programme by first decompiling it into manageable objects. It then seamlessly integrates itself between these programme objects and reassembles all the code into a new programme generation.

Nowadays, there are many different types of malware concealment strategies. These strategies can be classified in two groups. On one hand, we have malware which implements a set of techniques to hide itself from detection, such as bypassing anti‐virus or anti‐malware signature detection. Such method of detection is implemented in both the traditional desktop platform as well as on mobile devices. On the other hand, we find other kinds of malware that, apart from concealing their presence, they actively try to hinder the detection and analysis of the code. This classification can help us understand better the degree of damage that malware can cause. The first group uses passive strategies to evade detection, so that the malware will not attempt to defend itself from the concealment strategies already implemented within the application code (refer to section 3.3). We can view this kind of malware as having a sort of protection shell which, once detected and removed, will reveal the source code behind.

The second group uses active strategies to evade detection. In addition to passive concealment strategies, this type of malware will implement aggressive coding techniques for self‐protection. Common examples found across the various literature (refer to section 3.4) include hindering the detection of a virus using signature‐based methods and hindering the analysis of the code by using anti‐emulation, anti‐debugging techniques and anti‐disassembling techniques.

We will further analyse these three types of techniques in section 3.4 below.

3.2 Overview of Obfuscation Theory

Obfuscation is a technique used by code developers to enforce a security policy aiming to protect the code from being analysed and understood. Barak et al [91] provide us with a detailed definition of obfuscation. They state that an obfuscator O is an (efficient, probabilistic) “compiler” that takes as input a programme P and produces a new programme P' satisfying the following two conditions:

Functionality: P' computes the same function as P.

“Virtual black box” property: Anything that can be efficiently computed from P' can be efficiently computed given oracle access to P.

We can summarise this definition using figure 5 below. The original programme P is passed through an obfuscation transformation O which produces a new programme P’.

Obfuscation Programme (P) Transformation Programme (P’) (O)

Figure 5 ‐ Flow of normal programme through obfuscation transformation

3.3 Passive Strategies to Evade Detection

3.3.1 Code obfuscation

Code obfuscation is a technique in virtue of which, the code is deliberately modified with the intent of making it difficult for humans to understand or for anti‐malware engines to detect. Dead code insertion, code transposition and register reassignment are three simple techniques which malware creators commonly use in order to conceal their malicious activities and, thus, evade detection.

Dead code [92] is a block of code which is correct in terms of syntax but is irrelevant to the programme being executed. The end result is that the code changes its appearance but not its behaviour. The most common operation used for dead code insertion is the NOP command. The NOP command stands for ‘no operation’. When the processor executes the code, the NOP instructions are skipped. Another type of dead code is the CLC instruction (Compare Logical Characters) and is used to compare two fields that are both in storage. An example of dead code insertion using NOP in machine language code is given in the figure below:

0040100F POP DWORD PTR 0040100F POP DWORD PTR DS:[40F974] DS:[40F974] 00401016 RCR EBX,CL 00401016 NOP 00401018 BSWAP EBX 00401017 RCR EBX,CL 0040101A PUSH Test.00401056 00401018 BSWAP EBX 0040101F POP EBX 00401019 NOP 0040101A PUSH Test.00401056 0040101B NOP 0040101C NOP 0040101F POP EBX Original code Code with dead code inserted (within box)

Figure 6 ‐ Original code on the left hand side with dead code inserted on right hand side

Code transposition [93] [94] is another technique that reorders the sequence of the instructions in a piece of code without affecting its behaviour. Commentators outline two methods for this technique.

The first method randomly shuffles the instructions and then recovers the original code execution order through the insertion of unconditional branches. The second method creates new generations of the code by choosing, and then reordering, the independent instructions that have no effect on each other. Although the second method is a complex way of performing code transposition, it can be argued that the detection will not be as straightforward as it might be when using the first method.

Examples of these two methods, taken from the published paper by You and Yim (op. cit., p. 299) are shown in the following two figures:

Figure 7 ‐ Code transposition based on unconditional branches

Figure 8 ‐ Code transposition based on independent instructions

Register reassignment (op. cit, p. 298) is a relatively simple technique that switches the registers from generation to generation. The programme code and its behaviour are kept the same. Registers used in code, such as EAX, EBX and EDX are reassigned to EBX, EDX and EAX respectively. This technique is used extensively by metamorphic viruses.

3.3.2 Entry point obfuscation

Entry point obfuscation is the technique which viruses hidden inside executable files use to call their malicious code. When a virus infects a file, it must find a way to take control of the file and inject its malicious code. A virus changes the entry point of the infected application, making it point to its own native code. Such malware hides its payload by using unusual places inside the executable file and trying to dissuade the anti‐virus or anti‐malware engine from investigating the file. Entry point obfuscation is viewed as an anti‐heuristic method, often deemed hard to detect, disinfect and remove.

3.3.3 Encryption

The first virus utilising encryption to scramble its contents was the Cascade virus [95], released in the late 1986. The virus had a piece of encryption/decryption routine, referred to as a decryptor, followed by the actual body of the code which was encrypted. An extract from the virus code is shown in the figure below (ibid, p. 253):

lea si, Start ; position to decrypt (dynamically set) mov sp, 0682 ; length of encrypted body (1666 bytes)

Decrypt: xor [si],si ; decryption key/counter 1 xor [si],sp ; decryption key/counter 2 inc si ; increment one counter dec sp ; decrement the other jnz Decrypt ; loop until all bytes are decrypted

Start: ; Encrypted/Decrypted Virus Body

Figure 9 ‐ An extract from the Cascade virus code

It can be clearly seen that this decryptor has anti‐debugging features since the stack pointer, referred to in the code as ‘sp’, is used as one of the decryption keys. Using simple symmetrical XOR ciphering, the code was very practical for viruses. The key used for ‘sp’ was simply the size of the file in bytes, converted to hexadecimal notation (166610 decimal is 068216 in hexadecimal). At that time, it was very difficult for anti‐virus vendors to perform this type of detection. The situation changed very quickly and anti‐virus vendors started showing detection capabilities of encrypted malware, matching the most common decryptor patterns with a growing database of decryptor signatures stored within their databases.

3.3.4 Packing

In the early days, storage space and bandwidth limitations prevailed. System memory and disk space availability were smaller in the 1980s and beginning of the 1990s. At that time, it was difficult for software developers to send out files and executables over the Internet without any form of compression. The introduction and use of packers enabled developers and software companies to minimize memory and bandwidth usage during storage and transfer over communications media [96]. These packing tools enabled the use of compression and encryption to be used on these files. Nowadays, despite the abundance of storage space and bandwidth transfer speeds, software developers still make use of these packers. However, a small change to the source file (for example, changing a variable name) will result in a totally different compressed file. This effect is very similar to that of a hash, where a change in one letter will result in a completely different cryptographic hash file.

There are many packing tools available used to compress, encrypt and armour executables and files. Such packing tools are available to both corporate vendors as well as malware creators. A brief overview of two packing tools that created a stir in the information security community is given below:

3.3.4.1 Polypack Initially the work of Jon Oberheide, a PhD student at that time, Polypack [97] is a web‐based automated file packing service. It employs ten of the most common packers found and ten popular anti‐malware engines. The service evaluates the effectiveness of anti‐malware and anti‐ virus scanners when detecting packed malware. A binary file submitted to the service is packed by each of these ten packers and then analysed by each of the ten anti‐malware engines. The results are then displayed to the user submitting the file. At the time it was published, it caused quite an interesting debate between anti‐malware and anti‐virus vendors, and the security community in general. The issue revolved around whether it was ethical to publish such research demonstrating the limitations of current anti‐malware engines. Malware creators can easily make use of this model for concealment of their malicious software.

3.3.4.1 Themida Themida [98] is a commercially available package. The target market of this software is aimed at commercial software companies and vendors looking to protect their intellectual property from reverse engineering. Protection features used by Themida include anti‐debugger techniques, anti‐memory dumpers, different encryption algorithms, advanced entry‐point protection and dynamic encryption. In Oberheide’s experiments with Polypack, Themida outperformed its competitors and evaded most of the anti‐malware scanners. However, just like any other good security tool, malicious authors could use Themida to create and protect their malware. In fact, it could be argued that the security community viewed both Themida and Polypack as threats, when these tools are used by malware creators.

3.3.5 Oligomorphism

Oligomorphism comes from the Greek words oligo meaning few and morphe meaning shape or form. Encrypted viruses used the same decryptor. The main idea behind oligomorphic malware is that of constantly changing the decryptor that is used to encrypt and decrypt the malware body. The most simple technique for achieving oligomorphism within malware is that of having a set of decryptors instead of a single one. The code will then select which decryptor to use in a random way from the predefined set of alternatives. The first known malware to use this technique was the Whale virus [99], detected in the late 1990. It used a few dozen decryptors and would randomly chose one to encrypt itself as it spread to new files. Other oligomorphic viruses were able to generate decryptors dynamically, making it harder for anti‐virus vendors to extract comprehensive signatures for their databases. W95/Memorial [100] had the ability to build 96 different decryptor patterns. Thus the detection of the virus based on the decryptor's code was an impractical solution. Most products at that time tried to deal with the virus employing dynamic decryption of the encrypted code.

3.3.6 Polymorphism

Polymorphism is a method of encryption that mutates the static binary code to evade anti‐ malware scanning engines. It originates from the Greek words polys meaning many and morphe meaning shape or form. The use of this technique radically changes how the malware hides itself, whilst at the same time, keeping the same functionality. This type of encryption method assists malware in avoiding detection since no single signature sequence will match other sequences. In their research, O’Kane et al (op. cit., pp. 43‐44) provide a simple implementation of a polymorphic engine. The following is an overview of this engine:

a) The host application will start first, followed by the execution of the polymorphic engine at some time. When the engine is run, it gains control of the CPU. b) The polymorphic engine then deciphers the mutated malware code in the infected host – this will convert the encrypted code into native code using the key stored within the infected file itself. c) The engine will then write the native code into memory, ready for execution. d) The malicious code runs, carrying out the various activities it was programmed to do such as creating a backdoor for a bot, changing system or registry parameters or stealing confidential data. e) In order for the polymorphic engine to generate a mutated version, a new key must be generated. This is carried out by the engine, storing the key within the newly created version of the malware. f) The malware engine will then transform the native code back into encrypted code using an inverse function.

This is further illustrated in figure 8 (op. cit., p. 44):

Figure 10 ‐ Implementation of polymorphic engine

It is submitted that polymorphic code is still susceptible to anti‐virus detection. The polymorphic engine does not change the native code significantly. Therefore, it is still possible for an up‐to‐ date anti‐virus programme to detect the signature once the malware is loaded into memory during runtime.

In 1992, the first ever polymorphic toolkit was released in the wild. This mutation engine named MtE [101] started a new way of virus writing, allowing virus writers to link their code to an MtE generated object. This turned a normal non‐concealed virus into a polymorphic one. Even though nowadays all anti‐virus engines can detect MtE concealed viruses, it is still considered as a source of inspiration for those malicious individuals that aspire to write polymorphic engines. Other examples of such toolkits exist such as DAME (Dark Avenger’s Mutation Engine) and TPE (Trident Polymorphic Engine) [102].

3.3.7 Metamorphism

It was not until late 1998 that the first instances of viruses that used metamorphic techniques appeared. One of these first viruses that appeared in the wild was called Win95/Regswap [103]. It used a technique that switched the CPU registers from one generation to another. The malware was able to re‐programme itself as it evolved across different generations. This prevented conventional and known signature and pattern matching from working.

The technique of swapping registers became known as the basic form of metamorphism. The term comes from the Greek words meta meaning about and morphe meaning shape or form.

Metamorphic malware is categorised into two main groups. The first group defines the communication capability of the malware, whether the malware is capable of open‐world communication (downloading further plugins) or closed‐world communication with no communication capability.

An example of an open‐world metamorphic malware is the Conficker worm [104]. This worm appeared in 2008 and quickly spread across the Internet, compromising many computers as it replicated. Being capable of open‐world communication, the worm was able to update itself with new features. One such feature is dynamic code obfuscation where the mutation code can dynamically generate new versions of itself each time it runs.

The second group defines the transformation capability of the malware. Schiffman [105] further divides this group into binary transformer and alternate representation. Metamorphic malware capable of binary transformation mutates the binary executable of itself during evolution. Alternate representation transformation refers to the pseudo‐code representation of itself and performs the mutation based on that representation.

Metamorphic malware is believed to be more complex than any other malware. We try to simplify this process by splitting it up in five separate stages shown in the following figure:

Disassemble

Shrink

Permute

Expand

Assemble

Figure 11 ‐ Five separate stages of metamorphic malware

Basically, in the first step, the disassembler decodes the native code. In the next step, a shrinker compresses the disassembled code to keep it within a reasonable size. Failure to use a shrinker will see the malware increasing in size, and hence the host file will grow as well. Then, a permutation engine reorders the code by randomising it, connecting the various blocks with ‘jmp’ operands and implementing register reassignment. An expander will then recode the single operational instructions into several instructions, inserting benign codes such as ‘nop’ or ‘clc’.

Finally, an assembler will recode the expanded code, calculating the new ‘jmp’ vectors and reassigned registers.

A good example of malware that implemented obfuscation methods as described above was the Rustock.B [106]. This Trojan, which installed a backdoor on the infected computer, made use of useless and confusing instructions within the code, and further concealed it using register reassignment and code transposition.

3.4 Active Strategies to Evade Detection

3.4.1 Anti‐emulation

Emulation and the use of virtual machines are an important aspect of malware analysis across all platforms. Through the use of emulation, a safe and accurate environment is created for analysing and evaluating real life behaviour of malware and its impact on the targeted system. Malware such as Zeus [107], and related families such as Dromedan [108] and Yakes [109] have deployed anti‐emulation techniques. Many security researchers have observed that the use of emulation systems can be detected by simple queries directed to the machine. Malware creators have responded to such emulation techniques implementing anti‐emulation techniques to counter analysis and evade detection.

Multiple memory registers within a running system, such as the stack, are allocated and reserved so that a programme uses them during execution. Each emulation environment will have its own unique pattern of using these memory regions and of the variables which it stores. For example, VMware populates CPU register EAX with 0x564D5868 and register EDX with the hypervisor port 0x5658. Performing an ‘IN’ instruction on this port using the aforementioned register and passing command identifier 0x0A will modify the value of register EBX from the initial 0xFFFFFFFF to 0x564D5868. The code to perform such checks is available online through the VMware Knowledge Base [110]. In addition, it is to be noted that these values will be different from when a system is running in a non‐emulated environment. By checking the state and contents of these memory registers, malware can be aware of whether or not it is being executed and analysed within an emulated environment. Through this analysis phase, malware may execute differently from when the malware is run on native hardware.

3.4.2 Anti‐debugging

Anti‐debugging techniques are used to trick debuggers, making the job of anti‐malware analysis much more difficult. A common technique used is code obfuscation which has already been covered in section 3.3.1. Other techniques which are also available deal directly with how the host operating system handles debugging. Taking the Windows operating system as an example,

33 there are specific API functions that can reveal whether the malware code is being debugged. One of the oldest techniques, considered to be the most common, is the IsDebuggerPresent API call. When a binary file is being analysed, Windows sets a flag in the PEB [111], or Process Environment Block, representing this fact. The PEB contains information that the running process needs, such as the number of processors in the system and a specific flag that shows whether the current process is being debugged or not. Querying this API returns a TRUE value if the current application is being debugged or FALSE if otherwise. Timing is another technique commonly used to detect debugging of application code. The idea behind this kind of technique is that instructions take longer to execute when they are being debugged than if they running natively. If a set of instructions takes longer than a fixed set of time, the malware concludes that it is running within a debugged environment and responds accordingly.

3.4.3 Anti‐disassembling

Anti‐disassembly techniques employ special code within a file that trick the disassembly and analysis tools into producing incorrect programme listings [112]. These techniques provide an additional layer to the extensive array of armour available for malware creators. A common technique that is seen in the wild is the use of two back‐to‐back conditional jump instructions that point to the same target. For example, if a jump on zero (JZ) instruction is followed by a jump on non‐zero (JNZ) instruction, the disassembler does not recognise this, since it is configured to disassemble instructions one line at a time.

Common goals which malware authors strive to achieve when implementing anti‐disassembling techniques in their code are that the function should not be easy to automate and that the source code should not be available until the code runs. The most common examples found in the literature relate to having the code generated only when the virus or malware runs (much like a Just‐In‐Time procedure) and keeping the code in encrypted form, decoding only those parts that are needed [113].

3.5 Concluding Remarks

This detailed review of select concealment strategies elucidates the determination of malware authors to make the analysis part of malware difficult for anti‐malware developers. We analysed how concealment techniques are becoming increasingly complex, ranging from simple code obfuscation techniques to polymorphism and metamorphism. It is believed that the level of complexity of the metamorphic code makes it the most complex type of malware available.

Yet again, these concealment strategies are passive. This means that their aim is to hide their presence as much as possible. On the other hand, concealment strategies using active techniques implement aggressive coding techniques to self‐protect the code. One of the most common forms is the use of anti‐emulation techniques. In our practical part (chapter 5), we shall

34 demonstrate how malware behaves in a different manner when a virtual environment is detected. It is clear that the ultimate aim of any malware creator is to increase the span of time between the infection phase and detection phase. The longer malware stays hidden, the more it can spread and infect vulnerable targets. We shall now review various malware detection techniques commonly in use by anti‐malware developers.

4 – Malware Detection Strategies

4.1 Introduction to Malware Detection Strategies

Malware authors are becoming more aware of the security methods devised, and used, in commercial as well as domestic realms. They have become more skilled in hiding their malicious programmes and operate quietly, thus avoiding detection. Once they manage to infiltrate a device, they will use their concealment strategies to hide their presence, making it part of their botnet, stealing data and infecting other devices to which it may be connected. These attacks have become so advanced that sometimes they can go undetected for weeks, or even months, as in the case of StuxNet [114]. In January 2012, the Wall Street Journal reported that hackers working from China had accessed Nortel’s networks, breaching the telecommunication company’s networks as far back as 2000 [115]. In such cases, cross‐platform malware could take the form of cross‐platform viruses, worms or even botnets. An example of this could be an infected mobile device being introduced within company premises. It then connects to the company’s network via Bluetooth, USB or WiFi and infects other devices.

Various malware detection strategies are currently in use. Detection involves a process of analysing and identifying whether a code is genuinely benign or malicious. Robust malware detection strategies depend on how efficiently obfuscated malware is detected. Simple strategies, such as trusting and installing only digitally signed applications, are one way of limiting malware infection. Various authors acknowledge that given the vast amount of applications that are available on the Internet, especially through the use of peer‐to‐peer sites, one cannot expect all applications to be digitally signed [116]. Moreover, the fact that an application is signed does not mean it is benign. Self‐signed applications cannot be trusted, and even applications signed by a trusted Certificate Authority may have malicious intent.

An additional layer of protection is introduced through the use of focused detection strategies. Static malware analysis is a well‐known group of techniques for detecting and handling malware. They rely on static file signatures or static code to analyse and determine whether an application code is malicious. An alternative to static malware analysis is the use of dynamic malware analysis techniques. These techniques, together with heuristics‐based analysis, will be reviewed in sections 4.2, 4.3 and 4.4. Although these techniques accomplish the same goal of understanding and explaining how malware works, the tools used and skills required are quite different. Following this analysis, we will analyse their advantages and limitations for securing a mobile platform, when compared to the desktop platform, and propose practical alternatives.

Various authors [117] [118] have come up with different classifications of these techniques. Through this work, we do not intend to devise any new detection techniques, but suggest and argue an easier classification of the various malware detection strategies.

4.2 Malware Detection Using Static Techniques

4.2.1 Introduction to static malware analysis

Static analysis is a process of extracting static information from a file without actually executing the file. The information thus extracted is used to create a profile of the file using different techniques such as calculating file hashes, scanning through different anti‐virus and anti‐malware engines and extracting file information. Analysis of the code is one of the tasks carried out. While code analysis is being done, the anti‐malware engine will search for known strings. A string in an application is a sequence of characters such as the words ‘send’ or ‘open’. By searching through strings within an application, the researcher can get an idea of what the application does. Reverse engineering will also be carried out using programmes such as disassemblers, decompilers and debuggers. Static analysis can be divided into the following three main components:

4.2.2 Signature analysis and hashing

Signature‐based malware analysis has been in use on the desktop platform since the introduction of anti‐virus software. The operation of this method is to scan files for malicious content through the use of known signatures, and we argue it is one of the best‐known malware detection techniques. When analysing an application, it is suggested to first run it through multiple anti‐ virus engines. To identify whether an application is malicious or not, the anti‐virus software will compare the contents of the application with a dictionary of known malware signatures. We understand that such a technique is in fact difficult to implement on such platforms, particularly on account of the limited mobile platform resources such as battery life, processing power and memory availability. In addition, signature analysis techniques are not considered useful in detecting polymorphic malware (covered in section 3.3.6), as a small change within the malware code will result in a different signature. As a result, this renders the malicious code undetectable using signature analysis. Apart from the limited hardware resources that mobile devices have, signature‐based techniques require constant dictionary updates for each and every variant of malware in the wild.

Another common method, very similar to signature analysis, is hashing. Hash functions [119] are primarily used to generate fixed‐length output data that acts as a shortened reference to the original data. The targeted application is run through a hashing programme which in turn produces a unique hash, identifying the malware. Two unique properties of hashing functions should be noted. One such property is that hash functions are non reversible. This means that it is not possible to reconstruct the original input from the hash generated. The other property is that when a hash function is invoked twice on the same application code, the same hash value is produced. Popular hashing functions that were commonly used include Message‐Digest Algorithm 5 (MD5) and Secure Hash Algorithm 1 (SHA‐1). These hashing functions have been

37 proven broken and other hashing functions are now being used such as SHA3‐256, SHA3‐512 and Spherical Hashing [120]. Once a unique hash is generated for a given application, it can be used as a label, that is a means of sharing it with other malware researchers to help them identify the malware or to search for the hash online in order to determine if it has already been identified. We argue that malware authors can easily modify their code and, as a result, the application’s signature changes, thereby evading signature analysis. In addition, it is our understanding that many mobile users may disable data services (such as 3G) on their mobile devices to prevent their mobile network operators from imposing additional charges. When this is done, mobile users may not receive updated signatures for their anti‐malware engines. Further analysis of these challenges will be presented in section 4.6 below.

A recent implementation of malware protection on smartphones running Android is Drebin [121]. Drebin is a lightweight method for the detection of Android malware that enables the identification of malicious applications directly on the smartphone. We already discussed the issues concerning the limited resources on mobile platforms and how these can impede on the performance of monitoring applications. Drebin performs a broad static analysis, gathering the features of all applications installed on the smartphone. These features are then embedded into a joint vector space so that patterns indicative of malware can be automatically identified.

4.2.3 Extract system calls

Extracting system calls is a technique which Schmidt et al [122] presented in detail in 2009 for the Symbian OS. The researchers used IDA Pro, a disassembler which generates assembly language source code from machine‐executable code, to extract system calls. They then proceeded to classify the application as being either malicious or benign by using a lightweight algorithm called ‘centroid machine’. The centroid machine classifies the executable using clustering. Two main clusters are used. These are called cm for malicious classes and cb for benign classes. An executable is classified as being malicious if it is closer to cm, and benign if it is closer to cb. Unfortunately, at that time, there were just over three hundred known malware samples available for the Symbian OS. The researchers eliminated simple installers and ended up with a relatively small sample of just thirty three malicious applications and forty nine benign mobile applications. In statistic analysis, this is normally considered to be a very small sample in order to infer any conclusions on the effectiveness of this technique.

4.2.4 Static taint analysis

Taint analysis was originally proposed as a method to track the lifetime of data within a programme [123]. Static taint analysis is a technique which is used for detecting the information flow of a set of instructions that are influenced by the user’s input. Denning and Denning [124] define this flow of information as ‘Information flows from object x to object y, denoted x→y,

38 whenever information stored in x is transferred to, or used to derive information transferred to, object y’. This can be visualised in a simplified way in figure 10, which we adopted from their work:

Object X

Information flow

Operation

Value derived from object X

Object Y

Figure 12 ‐ Information flow to Object Y derived from Object X

The basic idea is to keep track of the values that are derived from the user’s input. The variables that have been flagged or ‘tainted’ with input controlled by the user are identified and labelled. Any operation that uses a value from a tainted object, say X, to derive another value for another object, say Y, will taint that object. We thus say that object X tainted object Y. In figure 10 below, we depict how object X is labelled (or tainted) following untrusted user input.

User input Taint Object X (untrusted)

Figure 13 ‐ Object X is tainted through user input

At this point, the system does not know whether the input came from a legitimate user or a malicious one. This labelling allows the researcher to track the influence of the tainted objects along the execution path of the programme, following all the tainted variables as well as their derivatives until the end of their lifetime. The functions within the programme code that are flagged as being possibly vulnerable are labelled as ‘sink’. If a tainted variable gets passed to a sink without being first checked, it is flagged as vulnerable. For example, if a ‘jump’ or ‘goto’ statements are inserted within the code, and these statements utilise in some way or another

39 user input, then those statements are marked as being vulnerable. Simple checks that are done on these variables could indicate possible attacks, such as cross‐site scripting, SQL injection and malicious script injection.

4.3 Malware Detection Using Dynamic Techniques

In this section, we will be looking at more advanced malware detection techniques. Rather than detecting malware through a known signature or a known hash, as seen in section 4.2.2, these techniques use dynamic analysis to detect malicious intent. The techniques covered within this section are dynamic taint analysis and behavioural analysis.

4.3.1 Introduction to dynamic malware analysis

Dynamic analysis, or behavioural analysis as is more commonly known, is the process of analysing, in the course of execution, the actions of a programme. The main idea of dynamic analysis is to execute a code sample within a controlled environment (such as a virtual machine), monitoring its behaviour and obtaining further information about its nature and purpose. At this stage, the code under investigation need not be malware. Through this analysis, the researcher will be able to assess better the threats, and create proper countermeasures. Using the Windows platform as an example, it is our opinion that the following checks can be easily implemented:

 What DLL files have been loaded into memory during application launch?  What files have been created, opened and modified during the execution of the application? Were any files deleted from protected locations, or was an attempt made to delete files from protected locations?  Has the registry been accessed? Simply reading and writing into the registry is not considered a malign action as applications continually use the registry during operation [125]. What is considered malign is the location, within the registry, where such changes have been made. For example, were any registry sections altered to refer to different DLL files which are not part of the standard Windows distribution?  Did the code have any effect on other processes? Were any existing processes closed or new ones created? Were these operations successful?  Was there any network activity? Were any files accessed over the network? Was there any attempt to perform a TCP scan of the whole network, perhaps using programmes such as nmap [126]?

It is our understanding that malicious activity on the mobile platform can be monitored using the following simple checks:

 Did the application try to activate the Bluetooth connection or 3G connectivity, even though they are disabled?

 Did the application try to send an SMS or MMS message even though there was no user activity, such as using the keypad to actually compose the message?  Is the application trying to access a specific file within a system folder or to create a new file in a protected area?  Is the application trying to erase files from the device, such as logs or critical system files?  Is there any impact on battery performance when compared to the default baseline?

We can classify the points listed above into three main tests derived from the categories reviewed in section 2.3, namely eavesdropping, device misuse and masquerading/fraud. In general, static malware analysis has the advantage of parsing through the whole application code, but code obfuscation techniques can be used to modify this code structure, reducing the effectiveness of this technique. On the other hand, since every code must be de‐obfuscated in order to run, obfuscation does not affect dynamic analysis. It is well‐known that in order to learn what an application is really doing, it is necessary to run the actual code and observe its actions. The figure below, taken from published work by Aycock [127], summarises the basic difference between static and dynamic analysis. In static analysis, the programme code is not running whilst in dynamic analysis, the programme code is running thereby creating a complete view of execution.

for i in 1…4: print (i)

for i in 1…4: print (i) print (i) print (i) print (i)

print (i)

Static view Dynamic view (code is not running) (code is running)

Figure 14 ‐ Static vs dynamic analysis

4.3.2 Dynamic taint analysis

Dynamic taint analysis is an extension of the static technique described in section 4.2.4 above. It was originally proposed by Newsome and Song in a paper published by Carnegie Mellon University in 2005 [128]. In dynamic taint analysis, data originating from, or arithmetically derived from, untrusted sources, such as the network, is labelled as tainted. The action of data tracking is done dynamically in real time, while the application is being executed. This technique

41 tracks how labelled data impacts other data in a way that might leak the original sensitive data. The type of tracking, as originally proposed, was performed at the instruction level. Finally, the impacted data is identified before leaving the system, usually at the network interface level.

Many modern programming languages already provide facilities to perform taint analysis. Developers make use of these facilities to identify programming errors. The figure below, taken from a technical report published by Sarwar et al during the 10th International Conference on Security and Cryptography [129], refers to input validation (ibid, p. 3):

Figure 15 ‐ Taint tracking of non‐validated input X

Over the course of programme execution flow, X evolves into Y and Z, through the use of functions F1 and F2. Taints are thus propagated to Y and Z as they are derived from an originally tainted source. When Z reaches an unsafe function F3, the taint tracking system can therefore raise the relevant alarm.

A well‐known implementation on the Android mobile platform is TaintDroid [130]. This system is designed to identify applications leaking sensitive information to external entities. It is considered as an extension to the Dalvik [131] virtual machine and can thus oversee all activity that runs above it. TaintDroid uses the concept of taint sources. Sensitive information, such as the IMEI number [132], text messages, contact details and GPS data, is tainted; and interfaces to the outside world, such as the mobile network interface, are labelled as taint sinks. The reason behind this methodology is that such data should never be sent to the outside world. There is no reason why contact details or the IMEI number should be transmitted over carrier lines. Whenever tainted data reaches a tainted sink, TaintDroid will issue a warning to the user.

4.3.3 Behavioural analysis

An alternative to the traditional signature‐based malware analysis approach is behavioural analysis. The intrusion of malware can be prevented through behavioural analysis. Behavioural‐ based malware analysis was originally proposed in 1996 [133]. Through this method, researchers not only perform surface scanning but also identify the malware’s actions. The proposed technique generates a database of malicious behaviour by studying a specific number of malware families on an operating system, in this case UNIX. Taking the Sendmail [134] programme as an example, the researchers used the following procedure (op. cit., p. 123) to build up the normal database:

i. Enumerate (list) potential sources of variations for normal Sendmail operation ii. Generate sample mail messages that cause the Sendmail programme to exhibit these variations iii. Build a normal database from the sequence of mail messages generated in the previous step iv. Continue generating normal mail messages, recording any mismatches and including them within the normal database.

In behavioural analysis, according to Elfattah et al (op. cit., p. 82), the runtime behaviour of an application is monitored and then compared and contrasted to a predefined set of malicious and normal behaviour profiles. These profiles can be specified either as a global rule that applies to all applications or as fine‐grained profiles for specific application rule sets. Since the code is not just statically analysed but executed, this technique is more efficient to detect polymorphic malware, or even malware that utilises various obfuscation techniques. Rather than just checking for static information such as the malware signature, behavioural analysis assesses the effects of an application when executed. Using the points referred to in section 4.3.1, we suggest that behaviour can, and should be, monitored both at the user‐level as well as the system‐level.

Monitoring at the user‐level depends on various factors, including user inactivity and total amount of SMS messages sent within a predefined period of time. User inactivity may be defined as the amount of time in which the mobile device is idle for example whether a keypad button was pressed (or screen used in case of modern smartphones) in a predefined amount of seconds. It can also be defined as the number of seconds during which the mouse on a desktop computer was not used, or the time in which the screensaver kicks in. The system may also be configured to monitor the total amount of SMS messages sent, especially whilst the user is inactive. This may be an indication of malware sending SMS messages without user authorisation, which will in turn create a cost for the user. Another indication of malware infection could be the transmission of an additional SMS message whenever the user sends an SMS message. Apart from being charged twice for each SMS message sent, the user may incur premium rate charges if the malware uses premium rate numbers.

Monitoring at the system‐level may involve various methods. One of these methods is monitoring for system calls. This could be the result of malware requesting the use of a system API with root privileges. It could also be a packet sniffer trying to install itself at the kernel level

43 to capture all packets which are inbound and outbound on the communications interface, be it the modem interface of a mobile device or the network interface of a desktop computer. Other factors that could be monitored include the tracing of read‐and‐write events on specific system files, CPU utilisation, adding new jobs to the scheduled tasks list, activating mobile phone or desktop camera and modifying the system registry with particular attention to start‐up scripts.

In their research, Suarez‐Tangil et al [135] stated that resource consumption increases drastically if a large number of events are collected directly over the platform being analysed. This clearly indicates that this type of monitoring can be potentially expensive for smartphones with their limited resources and capabilities.

4.4 Malware Detection Using Heuristics

4.4.1 Introduction to heuristic malware analysis

The term ‘heuristic’ refers to the act of finding out or discovering the solution to a problem. The Oxford English Dictionary defines the term as ‘problem solving techniques by trial and error methods which we use in everyday life’ [136]. Heuristics combines a few known facts with experience to make an assumption on the classification at large, and is regarded as forming part of artificial intelligence. These analyses and detection mechanisms employ data mining and machine learning techniques to review, trace and analyse the behaviour of the application code [137]. Through the use of these methods, heuristics look for pieces of programme code that seem to look like a virus rather than looking for specific virus signatures. In general, heuristic methods provide better detection capabilities against malware variants that are yet to be discovered, which static and dynamic malware analysis may not detect.

In their report, Harley and Lee [138] note that when heuristic analysis is used for the management of malware, it has a very restricted meaning. They note that heuristic analysis uses a rule‐based approach in diagnosing a potentially malicious application. As the anti‐malware analysis engine parses through the defined rules, it checks the application code against criteria that may indicate possible malicious intentions. A score is assigned to each possible match and if the score exceeds a threshold, then the application is flagged as suspicious. The relevance and strength of these scores get better as the system learns through further experience, augmenting its knowledge base as a result.

In 2001, Schultz et al [139] employed Naïve Bayes and Multi Naïve Bayes algorithms to classify applications into benign and malicious categories. The data‐mining framework that was proposed at that time automatically found patterns within the data set and used these patterns to detect a set of new malicious binaries which were previously unknown to the researchers. Only recently, researchers have used heuristic modelling to detect client side electronic banking frauds. The model that Timmermans and Kloosterman [140] proposed and implemented reaches an accuracy of around 90%, even though it is to be noted that a larger and more complete

44 dataset is required for more accurate results. In the following sections, we will be looking at four common techniques used in heuristic malware analysis and detection.

4.4.2 Monitoring API and system calls

Monitoring API and system calls is a technique used to extract critical information from known malicious programmes to determine their behaviour. This information is then used to construct a signature for the entire malware family rather than just for a single malware. Though in a sense, it may be similar to static analysis (covered in detail in chapter 4.2), it is actually not because the signature is not based on the actual code pattern but on the behaviour of the application. Therefore, common obfuscation techniques which may be present within the code will not affect detection. In addition, this technique is capable of identifying unknown malware variants within the same malware family, since the signature covers the whole malware family rather than just the specific malware.

Hofmeyr et al [141] were among the first researchers who considered monitoring API and system call sequences as a feature of malware. They introduced a malware detection method based on system call sequences based on the defences of natural immune systems. Normal behaviour profiles were made using short sequences of system calls. A divergence from this normal behaviour was flagged as an anomaly.

4.4.3 OpCode analysis

An OpCode (short for Operational Code) is the portion of a machine language instruction that specifies the operation to be performed [142]. A programme is defined as being made up of a series of ordered assembly instructions. An instruction, in this case, is made up of an operational code, and an operand or a list of operands. An operand is that part of an instruction which specifies the data to be operated, or manipulated. It also contains the data itself. In 2007, Bilar carried out one of the most important research studies on OpCodes [143]. In that study, Bilar showed the capability of single OpCodes being used as a feature in malware detection. He statistically analysed a random sample of known malware and non‐malicious software, extracting OpCodes using IDA Pro and a modified plugin. He reported that malware OpCode frequency distribution deviated significantly from non‐malicious software. This showed the capability of single OpCodes and demonstrated their high reliability for determining whether an application was malicious or not. Since traditional static approaches, such as signature analysis, tend to exhibit a failure in detecting metamorphic and polymorphic malware, the combination of using heuristics and signature analysis proved to be an ideal arrangement.

Another important contribution to this analysis strategy came from Shabtai at al [144]. In their work, they applied classification schemes based on OpCode patterns to detect unknown malicious instructions. They created a dataset of malicious and non‐malicious software under the

Windows operating system. After disassembly, a normalised term frequency (TF) and TF inverse document frequency (TFIDF) were calculated. The TF and TFIDF are well known measures in the text categorisation field [145]. These researchers reported that, on evaluating these frequencies, this methodology achieves a very high level of accuracy, roughly around 96%.

4.4.4 Using N‐Grams for detection

N‐Grams are defined as substrings of a larger string with a length of N [146]. Given a database of malicious code and a database of benign code, n‐gram analysis can be used to extract the most frequent n‐grams, thereby acting as a form of signature. When a new application code is analysed, the detection engine can classify it as benign or malicious, based on the most matching category. For example, the string ‘malware’ can be segmented into several 3‐grams such as ‘malw’, ‘alwa’, ‘lwar’ and so on.

It is interesting to note that, besides using heuristics, this method applies n‐gram based analysis to generate a file signature. Kolter et al [147] use n‐gram analysis and data mining approaches to detect malicious executables in the wild. They use n‐gram analysis to extract the features from 1,971 benign and 1,651 malicious Portable Executable (PE) files. The PE file format [148] refers to a format for executable files, various font files and Dynamic Link Library files for the Windows 32‐ bit and 64‐bit operating systems. The PE files were gathered from various devices running Windows 2000 and Windows XP operating systems. In a similar study, Stolfo et al [149] used n‐ gram analysis for file type identification and malware detection. Their research contributed to the analysis and detection of malware embedded in DOC and PDF files. The experimental results indicate a positive detection rate from their sample. It is worth mentioning that such proposed technique is specific to embedded malware, that is, malware hidden inside DOC and PDF files, rather than stand alone malware.

4.4.5 Representing malware through control flow graphs

Control flow graphs (CFG) use graphs to represent the paths that an application code might use during its execution. CFGs have been used in the analysis of software and have been studied for many years [150] [151]. CFG can be considered as a directed graph, where each node represents a statement of the programme and each edge represents control flow between the various statements. We can thus say that a control flow graph is made up of various linked nodes. Examples of these statements include copy statements, assignments and branches. The following figure, taken from Sharp [152], is an example of a generated CFG for the Chernobyl malware:

Figure 16 ‐ An example of Control Flow Graph

In 2011, Zhao [153] proposed a detection method based on the features of control flow graphs for PE files. Initially, he created a CFG for each executable file. Then, he used the features that were extracted from each graph as training data. Some of the features used by Zhao were information about nodes, edges and sub graphs. He used various data mining algorithms for classifying these PE files into benign or malicious categories.

Bonfante at al [154] propose a different scheme. They use CFG as a signature for malware detection, but reduce the resultant CFG to a condensed one. They abstract contiguous sequences of instructions in a node named ‘inst’ and subsequently, the end of the programme comes in a node which the researchers named ‘end’. These researchers defined six types of nodes: jmp, jcc, call, ret, inst and end, and devised control flow graphs as illustrated in figure 17 below:

Figure 17 ‐ Reduction of original CFG to condensed CFG

Afterwards, they proceeded to reduce these nodes as illustrated above. For any node of kind inst or jmp, they removed the node from the graph and linked all its predecessors to its unique successor. At the end of this reduction process, they used the resultant graph as a signature for each file.

4.5 Malware Detection Using Hybrid Techniques

Hybrid malware analysis is considered as a new technique combining in an intelligent way, both static code analysis as well as dynamic code analysis. In theory, this technique thus combines the benefits of static code analysis with virtual machine analysis. Using this technique should enhance the detection of malicious behaviour, compared to the outreach of the different individual methodologies.

An important aspect of hybrid malware analysis is linking dynamic runtime data with the respective disassembly code [155]. This reveals hidden API calls in full, and any input/output data. For example, static analysis might retrieve interesting event handlers from the Android Manifest file of an application prior execution. This is then passed to a Sandbox which in turn will generate simulation events to maximize code coverage and trigger as much payload as possible during runtime.

In figure 18, we illustrate the working of hybrid techniques in a simple way:

Suspect file arrives

File parsed using static analysis

Yes File flagged as being suspicious?

File parsed using Malicious file dynamic analysis

Yes File flagged as being a suspicious? No

Benign file

Figure 18 ‐ Simple flow diagram of malware analysis using hybrid techniques

When a suspect file arrives on the device, static techniques are used to analyse it. Signature analysis may be performed, possibly using more than one anti‐malware engine to increase the chances of detection. Through the use of static taint analysis, the detection process may check for any SQL injection attacks or possible buffer overflow attacks. Once all the static checks are done, the system checks whether the file was flagged as containing suspicious content. If so, the user may be prompted at this time to either carry out further manual analysis or else quarantine or delete the suspicious file.

If the file is not flagged as suspicious, it is then parsed using dynamic techniques involving also heuristics. This will provide an additional step of protection to the end device as now, apart from simply analysing the code in a static fashion, it will be executed in a sandbox or protected environment. The behaviour of the suspected file will then be analysed and parsed through various behavioural analysis techniques. If the file is not flagged as suspicious, it is marked as being benign and passed on to the relevant software application for processing. On the other hand, if the file is flagged as being suspicious, the user is alerted and further analysis may be requested.

Roundy and Miller [156] devised a technique that analyses the code prior to execution whilst, at the same time, selectively monitoring its execution. They achieved this through the use of hybrid

49 malware analysis – combining static and dynamic techniques to construct control and data flow analyses. In May 2013, Shar et al [157] proposed the use of dynamic attributes to complement static attributes in vulnerability prediction. They presented a prediction model based on classification and clustering in order to predict vulnerabilities. Their proposed hybrid prediction managed to achieve an overall detection rate of 90%.

4.6 Concluding Remarks

These highly advanced detection techniques demonstrate the intent of academic researchers to devise and implement new techniques to detect malware. In this chapter, we reviewed and assessed various malware detection techniques. We started with an analysis of basic static techniques such as signature analysis and extraction of system calls. We then reviewed static taint analysis, a method through which simple checks are done on specific variables that could indicate possible attacks. Moving from static detection techniques, we reviewed a number of dynamic detection techniques, the most common of which is behavioural analysis. Through the process of analysing the actions of a programme, we are in a better position to monitor and understand its behaviour. Execution of such programmes is done within a controlled environment. In addition to this, we also reviewed various heuristic detection techniques. Heuristics combines a few known facts with experience to make an assumption on the classification at large, and is regarded as forming part of artificial intelligence. Finally, we provided a brief overview of the emerging hybrid malware analysis techniques which combine in an intelligent way, both static code analysis as well as dynamic code analysis. In theory, this technique thus combines the benefits of static code analysis with those of virtual machine analysis.

It is our belief that all these malware detection techniques are highly vulnerable to malicious attackers. They usually reside at a high level within the operating system stack. Attackers are well aware of this fact and have acted in place various active and passive concealment strategies. This makes them as much vulnerable as any other application running on the device, being it a desktop computer running Microsoft Windows operating system or an Android smartphone or tablet. If malware manages to subvert the operating system, it will be able to replace various drivers from within the kernel, such as the modem driver. This could have serious repercussions on the user, who risks having to pay excessive fees for unwilled calls or messages. We feel that current academic literature needs to explore other lines of thought on this matter.

In the coming chapter, we propose a new way how to look at malware detection, departing from the traditional approach to detection strategies and opting for a hypervisor layer implementing a behavioural analysis framework.

5 – Improving Cross‐Platform Malware Detection

In the previous chapters, we provided a review of the various malware concealment strategies, categorised as passive or active strategies. We reviewed in detail the most common malware detection strategies currently in use. We now propose to analyse how cross‐platform malware infection occurs in practice through the use of a malicious application disguised as a registry cleaner for Android devices.

The ever increasing use of mobile devices makes it possible for malware to spread more easily to other devices. This can occur, for instance, when we connect a mobile device to a desktop PC for transferring photos or uploading music files. Cross‐platform malware contamination may also occur through drive‐by downloads, such as when we browse the Internet using PCs or mobiles running old or unpatched operating systems and applications.

Malware authors know that the majority of users may not use the very latest and patched operating systems and applications, and therefore devise attacks targeted for various versions of operating systems and web browsers.

5.1 Implementation and Analysis of Cross‐Platform Infection

In this section, we will analyse in more detail how malware infects desktop and mobile devices when they are connected through USB. For additional technical details regarding the practical implementation, we refer the reader to Appendix 3.

The setup was devised to contain as much as possible the infection, and avoid it from spreading. This was achieved through the use of VirtualBox [158]. VirtualBox is a virtualisation software package distributed by Oracle Corporation for both the x86 and x64/AMD64 based computers.

An overview of our set up can be seen in figure 19:

Apache 2 web server Disguised malicious running on Kali Linux application

Windows XP SP3 virtual Kali Linux virtual machine machine

VirtualBox running on Android tablet (Physical

the Host PC machine)

Host PC running Windows 7 64‐bit

Figure 19 ‐ Overview of our setup for cross‐platform malware contamination

We achieved our infection by having an Android tablet running Android Jelly Bean 4.1.1 download and install an infected application from a website, served from our virtualisation platform. The website was running standard Apache [159] software installed on Kali Linux [160] within a virtual machine. Kali Linux is a Debian‐derived Linux distribution designed for digital forensics and penetration testing. We used a malicious application called DroidCleaner which we downloaded through Contagio Mobile [161], a website providing mobile malware dumps for research purposes.

In the following section, we will see how we managed to infect our Windows XP virtual machine when it was connected to the Android tablet through USB. It is to be noted that we did not install any anti‐virus or anti‐malware engines on our Android tablet, nor on the Windows machine, to avoid possible interruptions from such sources. In addition, the settings of the Windows XP virtual machine were set at default so as to enable the autorun feature. All the latest available Windows updates were installed before carrying out this test. On the Android tablet, we installed two further applications prior to infection, namely ‘Shark for Root’ which allowed us to capture all the packets that are inbound and outbound on our wireless interface and to store them within a specially formatted file, and ‘Shark Reader’ which allowed us to read and analyse the files which ‘Shark for Root’ generated. These two applications are free for download from the Google Play store.

We proceeded to launch the application ‘Shark for Root’ and monitor the wireless network activity with the tablet in idle mode. No network traffic was detected. Then we launched the default stock browser and loaded the default website served by our web server. We downloaded the malicious application, DroidCleaner, on this default page. The application downloaded successfully on our device and once finished, we installed the application. We then launched the newly installed application and selected ‘Default cleanup’. The application showed us a progress bar indicator, with some information text being displayed on the current status and percentage

52 of completion. Various Android services were restarted. Once done, we closed the application and waited for one minute before stopping our network monitoring application. The application ‘Shark Reader’ was then launched in order to analyse the monitoring logs created.

Interestingly, we found network activity at the same time that the application was supposed to clean up our system. Two IP addresses were noticed, namely 54.235.185.74 and 173.194.70.95. When we carried out a reverse name lookup on the former IP, the results returned were of a host located within the Amazon Cloud cluster. A query on the latter IP reserved us some surprises. This specific IP seems to refer to a host which the malware application uses for downloading additional files. We drew this conclusion on the ground that the results returned by the website virustotal.com show a substantial activity of downloaded files from this IP which are tagged as malicious. In addition, the same website resolved this specific IP address to the domain name googleapis.com.

We then proceeded to check whether our malware would be able to propagate and infect our Windows XP virtual machine. From within VirtualBox, we configured a USB Device Filter for the USB port to which the tablet could be connected. The purpose behind this configuration was to ensure that devices connected to this USB port will be used only by the virtual machine, and not the host machine. The virtual machine was powered up, and two applications were launched, namely Process Hacker and Wire Shark. Process Hacker gives us a more detailed view of all the processes running on the machine than the standard Windows Task Manager. Wire Shark allows us to listen to, and monitor, inbound and outbound network traffic. Once these two applications were in place, we attached our infected Android tablet to the host computer. We need to remind the reader that, on this virtual machine, the autorun feature was left enabled to simulate a default installation of a user’s computer. It is probable that later versions of Windows software have this automatic run feature disabled.

Shortly after connecting the tablet to our host computer, the virtual machine installed the relevant USB drivers required for mass storage communication. Once completed, the autorun window was launched asking us for the following action. We selected the option to browse the newly created drive letter and shortly afterwards, we closed the same window. At the same time, we noticed that two new applications were running in our Process Hacker application. These were ‘pwd.exe’ and ‘Start.exe’. A few seconds later, a popup was displayed identifying an application error on the application ‘Start.exe’. We proceeded to terminate the relevant applications. Wire Shark was then stopped from logging any further network activity.

Analysing the generated activity log, we noticed that whilst we were checking our Process Hacker, the virtual machine was trying to communicate to an IP address using SSLv3. The IP address was 190.93.253.132 which, when queried using virustotal.com, was found to resolve to the domain www.minecraft.org. On further inspection of the connection to our Android tablet, we found out three additional files residing under the external memory card folder. These files were ‘svchost.exe’, ‘Kst.exe’ and ‘Controller.exe’. We parsed these three files to our anti‐virus software installed on the host machine. The anti‐virus software had no problems in identifying these three files as Trojans with the respective family names of ‘TR/MSIL.Agent.gtj’, ‘TR/Spy.Gen8’ and ‘TR/Rogue.KD.718296’.

Turning our attention to the actual malicious application, we used ‘apktool’ to extract the files contained within it. Apktool is a tool for reverse engineering Android application files. This particular tool was installed with our Kali Linux distribution. We note that among the numerous permissions requested by the application, there were some which do not make sense at all in a simple memory cleaner such as this one. Some of these permissions requested during installation include the ability to read and create SMS messages, make external calls from the mobile phone, kill background processes and read the contacts list.

The application then registered the device with the command‐and‐control server of the attacker. This location, found within the file ‘ConnectorService.smali’, pointed to ‘claco.kicks‐ass.net’. We hypothesise that the IP address 173.194.70.95 referred to above was, at some point in time, resolving to this domain name. The registration occured by having the device send the command string:

‘|NEW_HELLOW|’ followed by ‘ACCT + PORT’

All numeric values used within these files were written in hexadecimal notation. This seems to be a rather crude way of using obfuscation techniques. On successful registration, the programme carried out a download of three additional files. It is our understanding that these files relate to the USB autorun attack. Within the file ‘Tools.smali’, we could see an entry called ‘UsbAutoRunAttack’ and additional references to these three files as ‘app_data/autorun.inf’, ‘app_data/folder.ico’ and ‘app_data/svchosts.exe’. We believe that these actually point to the download location of these files from within the site ‘claco.kicks‐ass.net’. It also follows that once these files are downloaded, they are placed in the root directory of the memory card installed on the tablet. We came to this conclusion because, within this same file, we found various references to the path ‘/mnt/sdcard’. Therefore, if the Android device is connected to the PC in the USB drive emulation mode, the system will automatically execute the ‘svchosts.exe’ file. As described before, this is a Trojan file.

Unfortunately, we do not have the actual source code for the file ‘svchosts.exe’. We used OllyDbg to perform basic reverse engineering in order to inspect the assembly code. Interestingly, within the file, we found various references to a freely‐distributed library of NAudio [162]. NAudio is an open source audio library containing dozens of useful audio related classes and functions. We feel that a reference to this library can mean that our malware sample may perform monitoring of the default audio recording device. We then used ILSpy [163], an open source .NET assembly browser and decompiler. Our initial thoughts were confirmed when we opened the ‘svchosts.exe’ file. Within this file, there were various references to the NAudio library and various other configurations when recording was meant to start and finish. The aim of this application is to record audio data on the target computer when the microphone detects sound. These audio recordings will, in turn, be submitted to the attacker on his command‐and‐ control server. The details of this server were found within a special connector meant to be hidden. Within this code, we found references to the destination server ‘claco.kicks‐ass.net’ as well as the destination FTP port, FTP user name and FTP password.

Strangely enough, we did not notice any changes in our device information on our Windows virtual machine. The nature of our malware sample could be such that on detection of a virtual

54 environment, the application will either terminate or else run with limited functions. We used Joe Sandbox Cloud Analysis Report [164] to further analyse the file ‘svchosts.exe’. The results returned were quite fascinating. The executable file created guard pages which are used to protect against reverse engineering and debugging when it was run against a virtual machine running Windows XP with SP3. In simple terms, this means that if a debugger is being used to analyse the executable, such as OllyDbg in our case, an exception will be returned. This exception will be treated as a break within the programme execution and thus, the malicious payload will not be executed. Apart from this protection, there could be other built‐in protection mechanisms that prevented the application from installing the relevant audio devices. On the other hand, when the file was run against a native Windows XP machine with SP3, in addition to guard pages, we noticed that the programme checks for kernel debuggers. The report stated that the ‘SystemKernelDebuggerInformation’ was queried to determine system information further. We note that the ‘SystemKernelDebuggerInformation’ function can be used to determine if a kernel debugger is currently being attached to the system [165].

We can thus summarise our practical implementation of this cross‐platform malware contamination in the following steps:

Step 1: The unsuspecting user downloads a rogue application. This is thought to be an Android memory/registry cleaning application and for clearing up unused space or cache contents on the device, hopefully increasing the performance of the device.

Step 2: When the user launches the application, apart from seemingly cleaning up the Android device (in our case, it just restarted the processes already running), the application communicates to a remote command‐and‐control server. We hypothesise that additional applications are downloaded onto the Android device, stored on the external memory card.

Apart from this, we note that the application registers the Android device to this command‐and‐ control server allowing the remote attacker various functions. These range from sending SMS messages to rebooting the device and killing background processes.

Step 3: The user then proceeds to connect his Android device to the computer. Possible motives would include the transfer of pictures onto the computer, the upload of music files from the computer to the Android device or the charging of the Android device.

Step 4: On connection, the malware on the Android device propagates to the victim’s computer through the autorun feature which, in our tests, was left enabled. This in turn starts various rogue applications with the intention of performing malicious tasks without the user ever noticing. These include the installation of a microphone device driver which encodes any sound detected and sends it to the attacker’s command‐and‐control server.

It could be argued that having anti‐malware installed and disabling the autorun feature would have, at least, avoided cross‐platform contamination when our Android tablet was connected to our Windows XP virtual machine. This would have limited the contamination to just the Android tablet. Our main objective was to analyse the great lengths to which malware creators have come in order to infect various devices.

5.2 Framework Proposal to Limit Malware Propagation

Chapter 4 covered in detail various malware detection strategies which are currently available. These detection strategies are not considered to be native to a specific platform such as the Windows PCs or Android devices. However, it is our opinion that these detection strategies all share a common trait: analysis and detection through anti‐malware engines is carried out from within the operating system itself, running as a process.

It is our belief that malware creators are becoming craftier in their techniques for evading these anti‐malware engines. We gave a detailed overview of how malware can detect the presence of virtualisation platforms running on a Windows PC, such as VMWare in section 3.4.1. In the practical part (section 5.1), we commented how our malware, although created more than two years ago, still evidences built‐in anti‐debugging techniques. These techniques were demonstrated in practice when our malware failed to install the Trojan file upon detecting its presence on a virtual machine running Windows XP.

In this section, we wish to propose a new way how to look at malware detection, moving away from the traditional approach of existing detection strategies. To the best of our knowledge, no academic work has yet proposed or commented of our proposed security model. The primary aim of our model is to protect the device, be it Windows‐based or Android‐based, with a focused view on limiting malware propagation across these two platforms.

We propose that the addition of a new layer is introduced between the lowest layer, that is the hardware layer, and the next layer, which is the operating system kernel layer. This security layer, which we will denote as our hypervisor, can protect and monitor the whole system. This additional layer has to be lightweight in terms of consuming system resources, compatible across multiple platforms and non‐detectable by malware that adopts strategies to evade detection.

We must emphasise that we still need some sort of malware detection technique in order to detect the presence of malicious intentions during programme execution. For this reason, we propose the use of behavioural analysis. The reasons for choosing behavioural analysis are various. Having reviewed static malware analysis in section 4.2, we can deduce that malware using polymorphism or metamorphism techniques (refer to sections 3.3.6 and 3.3.7) will easily evade detection. In addition, such detection systems are largely based on signatures, that is, these systems are equipped with a database of known signatures or instructions that are considered malicious. Such a setup imposes a restriction on the frequency when this signature database is updated, such as when the computer is not connected to the Internet or the mobile device is out of (3G) data reception. Our proposals are based on the assumption that the operating system is running an anti‐virus or anti‐malware application.

When we look at the various components making up the Windows‐based PCs [166] and Android‐ based devices [167], we note various similarities in their frameworks. In figure 20 below, we collated these components, noting the similarities, and simplifying them in the following architecture:

User applications

Operating system

(Windows or Android)

Operating system kernel

Hardware components

(network, modem, camera, CPU, audio, power)

Figure 20 ‐ Common architecture for Windows and Android devices

We need to devise this additional layer in such a way that malicious behaviour can be monitored, intercepted and acted upon. We also need to be able to define what malicious behaviour is. Additionally, this layer must be able to intercept any hardware calls that may harm the operating system or cause distress for the user. This may include accessing the camera, increasing CPU utilisation thereby consuming battery use, accessing protected memory areas or enabling the computer or mobile microphone.

In the practical demonstration, we clearly showed how DroidCleaner attacked both the Android device as well as the Windows device. Through the registration of the Android device to the command‐and‐control server of the attacker, access to the various hardware components was made available. These included access to the camera, microphone or GPS tracking. On the Windows device, the intentions of the attacker were to install an open‐source audio library that tracked microphone input. The computer’s local storage was also accessed since the malware recorded any audio input, creating audio files and uploading them back to the attacker.

We also need to appreciate that the main contamination vector occurred through USB connection. In section 2.5.5, we commented on the known fact that USB traffic is neither authenticated, nor filtered. Although USB authentication may prove difficult to implement in practice, the reader must bear in mind that a similar idea based on quarantining ‘unknown status’ devices is already being implemented in various forms for computer and network security.

It is clear, through our above comments, that the deployment of this hypervisor layer must be transparent to the operating system. Our proposed architectural layout for this additional layer is as follows (see figure 21 below):

User applications

Protected operating system

(Windows or Android)

Hypervisor level

Camera Mic Network I/O CPU

Hardware components

Figure 21 ‐ Proposed architectural layout with the hypervisor

Within the hypervisor layer, we propose to configure two specification sets. One set, S1, will contain the hardware features that will be monitored. Some of the hardware items which we can include in this set are the GPS sensor, Bluetooth, WiFi, microphone, camera and accelerometer.

The other set, S2, will contain the permissions that will be requested for access to S1. Examples of permissions include a request to access the current roll/pitch of the accelerometer, take a picture using the camera, enable Bluetooth connectivity or access the location coordinates from the GPS. These sets will then be validated against user activity/inactivity parameters. Therefore, in our scenario, if the hypervisor detects a request to access the camera (selected from S1) requesting permission to take a snapshot (selected from S2), the request will be allowed if a previous user activity took place, such as using the touchpad or touchscreen. Such activity would be easy for the hypervisor to detect as this is the layer controlling access to the hardware. A graphical overview of this activity is given in the figure 22 below:

Start Device

Load Launch Datasets Hypervisor

Monitor Requests

No Request

Yes

Check User Activity

Update Yes No Timeout < Deny Access Dataset Limit?

Allow Update Access Dataset

Warn or Launch Alarm

Figure 22 ‐ Flowchart of behaviour analysis

5.3 Challenges for Implementation

We understand that creating a new layer will bring forth various challenges and barriers for its practical implementation. In the following sections, we attempt to level a constructive criticism at our proposal, noting what we deem to be the four major challenges to its implementation.

5.3.1 Access to hardware drivers

Having a hypervisor interact directly with the hardware layer brings about a major challenge: that of having access to the various hardware device drivers. Whilst on the Windows platform, the number of hardware manufacturers is well known, the same does not hold for the Android platform. It is known that Android is not controlled by a single company, as is the case for iOS installed on Apple devices. It will also be a challenge to get device driver source code directly from chip manufacturers. If we want our hypervisor to be implemented in practice, this barrier needs to be overcome. Possible solutions would call for a joint effort with a major player in this area, such as a CPU manufacturer or a major OEM.

5.3.2 Power management

Battery life is a critical factor on mobile devices. With the ever increasing performance in CPU speeds and memory access speeds, battery life is a limiting factor. We do not want our hypervisor to constantly check whether a request is forthcoming or not. Having such behaviour, constantly polling for requests, will hamper battery life, causing negative effects to our user experience. Google implemented ‘wakelocks’ in its Android operating system. Wakelocks are a kernel mechanism which Android uses for power management. When a process or thread holds a wakelock, the kernel will refrain from entering a low‐power state. If our hypervisor is not aware when a wakelock is active or not, it will remain in a constantly polling state, thereby contributing to battery consumption. Our hypervisor should possibly be aware of these wakelocks in the layers above.

5.3.3 Functionality

From a security perspective, functionality has always been a critical factor. Mobile and computer users have high expectations of their device’s functionality. They regard the added benefits of security as an extra burden, limiting what they can do with their devices. We feel that the addition of a hypervisor layer will affect functionality. There are various factors that need to be analysed in more detail, such as the processing when an incoming call takes place. What if malware manages to send an SMS message to a premium rate number and we receive a call back to confirm or accept this? If malware manages to subvert our operating system, it will be able to replace various drivers from within the kernel, such as the modem driver. Thus, any requests such as SMS messages or phone calls, could be filtered as required and hidden from the end user. On the other hand, having this additional hypervisor layer will create an additional step for attackers to subvert and control.

5.3.4 Security review

Security through obscurity is the belief that a system can be secure as long as nobody outside the group that implemented it is allowed to know anything about its internal mechanisms. In 1883, Auguste Kerckhoffs [168] extensively argued that any secure military system must not require secrecy and can be stolen by the enemy without causing trouble. In the academic security community Kerckhoffs’ Principle is widely supported. In the design of a system, security through obscurity is considered bad practice [169]. It is a philosophy which has been favoured by bureaucratic agencies and governments in the past. The usefulness of this philosophy has declined, giving favour to security through peer and community review. Our hypervisor layer cannot be software with an unknown internal structure (commonly referred to as black‐box). On the contrary, it has to be published in such a way that its internal structure and design are known and can be tested by the security community in general. It is important that such a proposal be scrutinised and reviewed in detail. Our argument is that opening the system to the security community allows independent assessment of its exposure to risk, makes patching bugs easier and forces software developers to spend more effort on the quality of the code. If this is not done, widespread acceptance of this proposal will not be possible.

5.4 Concluding Remarks

This chapter gave us with the opportunity to simulate, within a controlled environment, cross‐ platform malware contamination between an Android device and a Windows computer. We reported and analysed every step of the infection phase and propagation phase. The malware sample we used in our simulation, DroidCleaner, may only be considered a simple example. The code for it was written more than two years ago. We hypothesise that the attacker devising this malware intended to show that cross‐platform contamination is possible. It could be classified as a proof‐of‐concept malware, albeit a very dangerous one. We need to appreciate that cross‐ platform contamination was something relatively new at the time this malware was created. It is also a known fact that Windows XP had, indeed, a very large user installation base globally. Even if a very small percentage of those users left the operating system with default settings, cross‐ platform malware contamination through this specific malware could still occur extensively.

At this stage, after having reviewed various malware detection strategies commonly in use, we propose a different perspective of malware detection, suggesting the implementation of a hypervisor. The primary aim of our model is to protect the device, be it Windows‐based or Android‐based, with a focused view on limiting malware propagation across these two platforms. We propose a new layer, residing between the lowest layer, that is the hardware layer, and the next layer, which is the operating system kernel layer. We understand that the practical implementation of such a layer will give rise to various challenges and barriers. It is in this light that we raised and discussed four major challenges to its implementation, namely access to hardware drivers, issues relating to power management, functionality concerns and peer security review.

6 – Conclusions and Proposals for Future Research

The major outcome of the research performed in the course of this project has been the proposal and development of a new hypervisor layer which will assist current malware detection strategies to detect and contain cross‐platform malware contamination. In this final chapter we summarise the primary contributions of this research and provide suggestions for future work in this area.

6.1 Significance of Our Research

The purpose behind this work was to gain a better understanding of the way cross‐platform malware contamination occurs in practice, in an attempt to come up with possible frameworks which can assist us in limiting such contamination. We reviewed various malware threat models and malware infection vectors currently in use. We also provided the reader with, what we think, are the most common revenue channels exploited by creators of such malware. A review of the various passive and active malware concealment strategies was carried out.

We proceeded to give the reader a detailed analysis of malware detection strategies with an aim to simplify and consolidate as much as possible the various techniques. We proposed a simplified classification of detection strategies made up of static, dynamic, heuristic and hybrid techniques. As part of our research, we implemented and analysed in detail how cross‐platform malware contamination occurs. Using a controlled set up, we infected our Android device and, subsequently, our Windows XP virtual machine when these were connected through USB.

Following contamination, we started our detailed analysis of how this infection occurred, noting the various communications that were being done with the attacker’s command‐and‐control server. We utilised our knowledge of various analysis packages and techniques to demonstrate the great lengths to which malware creators have come in order to infect various devices.

Following our detailed analysis, we proposed that a hypervisor layer be introduced between the hardware layer and the operating system and kernel layers. It is our intention that such a proposal is used to further assist current malware detection strategies with the aim of stopping, or limiting as much as possible, cross‐platform malware contamination.

6.2 Future Research

The weaknesses affecting current malware detection strategies lie at the basis of our departure from the traditional view of how we can protect devices in favour of new methods designed to amplify the effectiveness of existing detection techniques.

Our proposal for the introduction of a hypervisor level is not yet tested in practice. Its prevailing benefits are in theory counterbalanced by multiple challenges which still need to be considered and addressed. The possible challenges to its practical implementation, as reviewed in section 5.3, include:

1. Access to the various hardware drivers with a view on the possible limited support by hardware manufacturers 2. Issues pertaining to limited battery autonomy, power management and power conservation 3. Functionality requirements from the users’ perspective as opposed to an additional step for attackers to subvert and control 4. Detailed security review and acceptance by the security community and device manufacturers

Despite these challenges, we still believe that this proposal brings forth a useful and efficient way to monitor and protect our system. Based on hardware virtualisation, it should provide security against various cross‐platform malware in existence. Any practical development of this proposal should be done with specific objectives in mind, namely a hypervisor whish is lightweight in operation, transparent to the operating system and provide for added capability enhancements.

Appendix 1 – Infecting and Controlling an Android Device

In this section, we demonstrate how easy it is for would‐be attackers to create a malicious Android application. This application can be easily installed on the unsuspecting victim’s device through various techniques, such as social engineering. We used Kali Linux and the Metasploit Framework [170] to create our malicious application. Metasploit is a security and penetration testing software distributed by Rapid7 and included within the Kali Linux distribution. We also use Genymotion [171] to create an Android virtual machine. Genymotion is an Android virtual machine open source project.

We launched our Kali Linux virtual machine on our host computer. Once the operating system was loaded, we logged in our desktop environment and started the Apache webserver. We then checked our network interface IP addresses. The IP address of the first network interface (eth0) was used to build our attack. We issued the command ‘mspayload’, specifying the reverse TCP attack, our eth0 IP address and the port number which we will be listening to. The resulting application was named as ‘gift.apk’. The details of this can be found in screenshot 1 below:

Screenshot 1 ‐ Creating the malicious Android application

Next, we started our Metasploit Framework command line interface. We configured our framework to use the same exploit we used in the creation of our malicious application. Then we proceeded to configure the various parameters needed to allow us to create a listening service,

64 such as the listening host IP address and listening port number. The details of these can be found in screenshots 2 and 3 below:

Screenshot 2 ‐ Launching our Metasploit Framework

Screenshot 3 ‐ Configuring the various parameters for our listening service

We then launched our Android virtual machine to browse our test website where the malicious application was residing. The user can be tricked into downloading such applications through various social engineering techniques which we discussed in section 2.5.4. In addition, in order for such an exploit to work, the device must be configured to allow installation of applications from unknown sources. The following screenshots show the user visiting our test website and application installation:

Screenshot 4 ‐ Browsing our test website using Android

Screenshot 5 ‐ Application requesting various permissions

Once the application was installed on the Android device, a backdoor connection was created to our server. We can see from the following screenshots that we could query the type of system we are connected to, as well as look at the various processes running on the victim’s device. Once we have this connection enabled, we can launch various other attacks, such as taking a snapshot using the camera on the device itself or recording conversations through the device’s microphone.

Screenshot 6 ‐ Issuing a command to get system information

Screenshot 7 ‐ Listing the various processes running

Appendix 2 – Infecting and Controlling a Windows Computer

In this section, we demonstrate how easy it is for would‐be attackers to create a malicious Windows application. This application can be easily installed on the unsuspecting victim’s device through various techniques such as social engineering. As in Appendix 1, we used Kali Linux and the Metasploit Framework to create the malicious application.

We proceeded to launch our Kali Linux virtual machine on our host computer. Once the operating system was loaded, we logged in our desktop environment and started the Apache webserver. We then checked our network interface IP addresses. The IP address of the eth0 network interface was used to build our attack. We issued the command ‘mspayload’, specifying the reverse TCP attack, our eth0 IP address and the port number which we listened to. The resulting application was named as ‘calc.exe’. The relative details of this can be found in screenshot 8 below:

Screenshot 8 ‐ Creating the malicious Windows application

We proceeded to launch our Metasploit Framework command line interface. We configured our framework to use the same exploit which we used in the creation of our malicious application. Then we proceeded to configure the various parameters as before. These parameters are required for the creation of the listening service, such as the listening host IP address and listening port number. The reader can find the details of these parameters in screenshot 9:

Screenshot 9 ‐ Launching our framework and configuring the various parameters

The user browsed our test website, selecting the ‘Calculator for Windows’, saving the application on his computer and launching the installation process. Instead of having the application available for download, the user may receive this application as an attachment in his email through a phishing attack as discussed in section 2.5.4.

Screenshot 10 ‐ Browsing our test website using Windows

Screenshot 11 ‐ Installation of our malicious Windows application

Once the application was installed on our Windows machine, a backdoor connection was created to our server. We can clearly see from the following screenshots that the attacker gets a command line interface directly on the victim’s computer. We then proceeded to change to the Windows directory, issuing a directory listing command and launching the Notepad application. The reader can refer to screenshots 12, 13 and 14 for further details. Such an attack is quite dangerous as the attacker may upload a malicious file which is launched every time the target computer is rebooted. This way, the backdoor connection to the attacker’s server is always maintained.

Screenshot 12 ‐ Getting access to the command line interface

Screenshot 13 ‐ Launching an application on the remote computer

Screenshot 14 ‐ Application launched on the desktop of the remote computer

Appendix 3 – Analysis of Mobile to Desktop Infection

In this section, we will analyse in more detail how malware can infect both Android‐based mobile devices and Windows‐based computers through a USB connection. The infection path in this case is from mobile to device.

The malicious application, DroidCleaner, was downloaded from the Contagio Mobile dump site. We used an online automated malware analysis site to confirm that it contains malware. The site detected the application as being malicious with MD5 checksum of C5A2D14BC52F109A06641C1F15E90985. A screenshot is being reproduced below for reference purposes:

Screenshot 15 ‐ Confirming the validity of our malicious application

We then proceeded to have this malicious application available for download. We used the same setup as per Appendices 1 and 2 with the only difference that in this scenario, the Android device is a physical device and not a virtual device. A physical device was chosen so that we could physical simulate the connection of said device to our target Windows machine using USB. The Apache webserver was launched on our Kali Linux distribution and the application was made available. The user then proceeds to download and install the malicious file on the Android tablet. Screenshot 16 shows the application DroidCleaner installed on our Android device:

Screenshot 16 ‐ Malicious application installed on our Android device

It is to be noted that our Android device came rooted as default. In addition, the applications ‘Shark for Root’ and ‘Shark Reader’ were installed. ‘Shark for Root’ was utilised to monitor for network activity when we launched the malicious application. The application is a traffic sniffer that works both on 3G and WiFi connections. Essentially, this application is the Android equivalent of Wire Shark. ‘Shark Reader’ was utilised to read the output of ‘Shark for Root’.

We launched ‘Shark for Root’ and left it running in the background. Next, we launched our malicious application, DroidCleaner. We selected the option ‘Default cleanup’ as shown in screenshot 17. Immediately upon tapping this option, we obtained a notification stating that the cleanup was done and that a restart of a number of applications was in course. Screenshot 18 shows the relevant messages that appeared on our device.

Upon completion, we were asked to perform a reboot of our Android device. This reboot was carried out as instructed.

Screenshot 17 ‐ DroidCleaner menu options Screenshot 18 ‐ Clean up process done

Shark Reader was then launched so that we could analyse whether any network connectivity was being made. Outbound traffic was noticed in two instances. The IP addresses which were being queried are:

54.235.185.74 (refer to screenshot 19)

173.194.70.95 (refer to screenshot 20)

We performed a reverse DNS lookup on these IP addresses. The results returned for IP address 54.235.185.74 were of a host located within the Amazon Cloud cluster.

A query on the IP address 173.194.70.95 reserved us some surprises. This IP refers to a host which our malware application uses for downloading additional files. We drew this conclusion on the grounds that the results which the website virustotal.com returned show a substantial activity of downloaded files from this IP address tagged as malicious. Further details on this analysis can be seen in screenshot 21.

Screenshot 19 ‐ Analysing captured packets ‐ part 1 Screenshot 20 ‐ Analysing captured packets ‐ part 2

Screenshot 21 ‐ Querying specific IP address information

Before connecting our Android tablet to our Windows machine, we checked the folder structure of our Android device. We noticed that within the mount point /mnt/sdcard, three new files were visible, namely:

svchost.exe

Kst.exe

Controller.exe

Later analysis of these files through our anti‐virus engine revealed that these files are Trojan files. The screenshot below shows our anti‐virus real‐time protection detecting the relevant Trojan families from these three files:

Screenshot 22 ‐ Anti‐virus programme detecting malicious executables

We then proceeded to connect our infected Android tablet to our virtual machine running Windows XP. The latest Windows XP updates were installed, but the default installation settings were kept. This, in turn, means that the autorun feature of Windows XP was kept enabled by default. Having autorun enabled was essential for our cross‐platform malware contamination.

We launched two applications on our machine, namely Process Hacker and Wire Shark. Following this, we proceeded to connect our tablet to the virtual machine using USB. Upon connection, Process Hacker displayed two unknown applications named ‘pwd.exe’ and ‘Start.exe’. Shortly afterwards, the application ‘Start.exe’ generated an application error as can be noted in the following screenshot:

Screenshot 23 ‐ Connecting our Android device to Windows XP

We then stopped Wire Shark from logging any further information. On inspecting the packets captured during the time when the Android device was connected, we found that our XP machine tried to connect to IP address 190.93.253.132 using SSLv3. The reader may refer to screenshot 24 for further details.

This IP address was checked using the website virustotal.com which reported that it resolves to the domain name www.minecraft.org (screenshot 25).

Screenshot 24 ‐ Wire Shark packet capture on Windows XP

Screenshot 25 ‐ Further analysis of captured IP address

When we analysed the code using ILSpy, the file ‘svchosts.exe’ contains the NAudio library which is launched upon programme execution. This confirmed our initial thoughts that the malware will record, and submit to the attacker, voice recordings whenever the microphone is activated.

Screenshot 26 ‐ Further analysis of svchosts.exe

To further our analysis and better understanding of this malware, we opened the ‘XControl’ reference in our file. Within this, we found references to the attacker’s server, the FTP user name and password to use for connection, and the destination port number to connect to.

Screenshot 27 ‐ Details of attacker's server

We then proceeded to upload the suspect file ‘svchosts.exe’ to Joe Sandbox Cloud Analysis Report for additional analysis. Particular attention was given to anti‐debugging techniques implemented within the application file. Through the online Sandbox Report, we chose to run this file on a virtual machine running Windows XP with SP3. The anti‐debugging feature found to be active in this state was the creation of guard pages, often used to prevent reverse engineering and debugging. In the following screenshot, we can clearly see this feature:

Screenshot 28 – Anti‐debugging features when run against a virtual machine

We then ran the same report against a physical machine running Windows XP with SP3. In addition to the anti‐debugging features noted in the previous scenario, during this analysis, we noticed the inclusion of another anti‐debugging feature. The application file checks for kernel debuggers by querying the ‘SystemKernelDebuggerInformation’ library. This is noted in the screenshot below:

Screenshot 29 – Anti‐debugging features when run against a physical machine

Within the Android application, we found references to various commands which the attacker can make use of. These range from sending SMS messages to making calls and enabling, or disabling, WiFi access. The list shown in the figure below was taken from the file ‘Tools.smali’:

Screenshot 30 ‐ List of commands available to the attacker

Bibliography

[1] M. Denscombe, The Good Research Guide: For Small‐Scale Social Research Projects, USA: 1st edition, Open University Press, Mc Graw Hill Education, 1998.

[2] D. Silverman, Doing Qualitative Research ‐ A Practical Handbook, USA: Sage Publications Ltd, 2000.

[3] E. Gummesson, Qualitative Methods in Management Research, USA: Revised edition, Sage Publications Ltd, 1991.

[4] N. K. Denzin and Y. S. Lincoln, Collecting and Interpreting Qualitative Materials, USA: 2nd edition, Sage Publications Ltd, 2003.

[5] J. Neill, "Qualititative versus Quantitative Research: Key Points in a Classic Debate," Febaruary 2007. [Online]. Available: http://wilderdom.com/research/QualitativeVersusQuantitativeResearch.html. [Accessed 17 October 2013].

[6] HSC StudentNet, "Study Skills Resources: Quantitative Research," University of the West of England, Bristol, UK, August 2009. [Online]. Available: http://hsc.uwe.ac.uk/net/student/Default.aspx?pageid=187. [Accessed 17 October 2013].

[7] M. Joppe, "The Research Process," Ontario Hostelry Institute, AMEX, Canada, June 2008. [Online]. Available: http://www.htm.uoguelph.ca/MJResearch/ResearchProcess/home.html. [Accessed 17 October 2013].

[8] M. Christodorescu, S. Jha, D. Maughan, D. Song and C. Wang, "Introduction to Malware Detection," in Malware Detection, New York, USA, Springer Science and Business Media, 2007, p. IX.

[9] Y. P. Chou, S. J. Horng, H. Y. Gu, C. L. Lee, Y. H. Chen and Y. Pan, "Detecting Pop‐up Advertisement Browser Windows Using Support Vector Machines," Journal of the Chinese Institute of Engineers, vol. 31, no. 7, pp. 1189‐1198, 2008.

[10] C. Willems, T. Holz and F. Freiling, "Toward Automated Dynamic Malware Analysis Using cwsandbox," Security & Privacy, IEEE, vol. 5, no. 7, pp. 32‐39, 2007.

[11] G. Eschelbeck, "Worm and Virus Defense: How Can We Protect the Nation’s Computers from these Threats?," A Report Submitted Before the Subcommittee on Technology, Information Policy, Intergovernmental Relations and the Census House Government Reform Committee, The Library of Congress, USA, 2003.

[12] Carnegie Mellon University, "CERT Advisory CA‐1999‐04 Melissa Macro Virus," March 1999. [Online]. Available: https://www.cert.org/advisories/CA‐1999‐04.html. [Accessed 14 November 2013].

[13] Carnegie Mellon University, "CERT Advisory CA‐2000‐04 Love Letter Worm," May 2000. [Online]. Available: https://www.cert.org/advisories/CA‐2000‐04.html. [Accessed 14 November 2013].

[14] T. Dübendorfer, A. Wagner, T. Hossmann and B. Plattner, "Flow‐level Traffic Analysis of the Blaster and SoBig Worm Outbreaks in an Internet Backbone," in Detection of Intrusions and Malware, and Vulnerability Assessment, Springer Berlin Heidelberg, 2005, pp. 103‐122.

[15] I. Arce and L. Elias, "An Analysis of the Slapper Worm," Security & Privacy, IEEE, vol. 1, no. 1, pp. 82‐87, July 2003.

[16] M. Bailey, E. Cooke, F. Jahanian, D. Watson and J. Nazario, "The Blaster Worm: Then and Now," Security & Privacy, IEEE, vol. 3, no. 4, pp. 26‐31, August 2005.

[17] C. Shannon and D. Moore, "The Spread of the Witty Worm," IEEE Security and Privacy, vol. 2, no. 4, pp. 46‐50, 2004.

[18] CERT Coordination Center, "CERT Advisory CA‐1999‐04 Melissa Macro Virus," March 1999. [Online]. Available: https://www.cert.org/advisories/CA‐1999‐04.html. [Accessed 20 October 2013].

[19] CERT, "CERT Advisory CA‐2000‐04 Love Letter Worm," May 2000. [Online]. Available: https://www.cert.org/advisories/CA‐2000‐04.html. [Accessed August 2013].

[20] Microsoft Corporation, "The Evolution of Malware and the Threat Landscape ‐ a 10 Year Review," Microsoft Corporation, Redmond, California, 2012.

[21] K. Dunham, S. Abu‐Nimeh, S. Fogie, B. Hernacki, J. A. Morales and C. Wright, Mobile Malware Attacks and Defense, Syngress Publishing Inc, 2009.

[22] N. Leavitt, "Mobile phones: the next frontier for hackers?," Computer Journal, vol. 38, no. 4, pp. 20‐23, 2005.

[23] M. Hypponen, "Viruses on the Stadium," F‐Secure, August 2005. [Online]. Available: http://www.f‐secure.com/weblog/archives/00000621.html. [Accessed 1 September 2013].

[24] Symantec Corporation, "WinCE.Duts.A," July 2004. [Online]. Available: https://www.symantec.com/security_response/writeup.jsp?docid=2004‐071710‐2120‐99. [Accessed 1 September 2013].

[25] G. Allen, "Alerting Users via Notifications," in Beginning Android 4, New York, USA, Apress

Media, 2012, pp. 437‐448.

[26] Kaspersky Labs, "Kaspersky Lab IT Threat Evolution: Q2 2013," August 2013. [Online]. Available: http://www.kaspersky.com/about/news/virus/2013/kaspersky_lab_it_threat_evolution_q 2_2013. [Accessed 3 September 2013].

[27] C. Smith, "Most advanced Android malware threat yet: Obad.a," June 2013. [Online]. Available: http://www.androidauthority.com/advanced‐android‐malware‐threat‐ backdoor‐androidos‐obad‐a‐223800/. [Accessed 6 September 2013].

[28] H.‐S. Chiang and W.‐J. Tsaur, "Mobile Malware Behavioral Analysis and Preventive Strategy Using Ontology," in IEEE Second International Conference on Social Computing, pp. 1080‐ 1085, Minneapolis, USA, 2010.

[29] Carnegie Mellon University, "CAPTCHA: Telling Humans and Computers Apart Automatically," 2010. [Online]. Available: http://www.captcha.net. [Accessed 7 September 2013].

[30] A. P. Felt and D. Wagner, "Phishing on Mobile Devices," in Web 2.0 Security and Privacy, Oakland, California, 2011.

[31] M. Alfalayleh and L. Brankovic, "An Overview of Security Issues and Techniques in Mobile Agents," Communications and Multimedia Security, vol. 175, pp. 59‐78, 2005.

[32] J. F. Levine, J. Grizzard and H. Owen, "Detecting and categorizing kernel‐level rootkits to aid future detection," Security & Privacy, IEEE, vol. 4, no. 1, pp. 24‐32, 2006.

[33] C. Thompson, "New Malware Attacks Smartphone, Computer to Eavesdrop," February 2013. [Online]. Available: http://finance.yahoo.com/news/malware‐attacks‐smartphone‐ computer‐eavesdrop‐172652055.html. [Accessed October 2013].

[34] T. Gaffney, "Following in the footsteps of Windows: how Android malware development is looking very familiar," Network Security, no. 8, pp. 7‐10, February 2013.

[35] H. Tipton and M. Krause, "What Is an Information Security Management System?," in Information Security Management Handbook, Auerbach Publications, 2008, p. 16.

[36] H. Nath and B. Mehtre, "Static Malware Analysis Using Machine Learning Methods," in Recent Trends in Computer Networks and Distributed Systems Security, Springer Berlin Heidelberg, 2014, pp. 440‐450.

[37] G. Delac, M. Silic and J. Krolo, "Emerging security threats for mobile platforms," in Proceedings of the 34th International Convention on Information and Communication Technology, Electronics and Microelectronics (MIPRO), IEEE, pp. 1468‐1473, Opatija,

Croatia, 2011.

[38] Antivirusware ‐ Independent Antivirus Reviews, June 2011. [Online]. Available: http://www.antivirusware.com/articles/history‐computer‐viruses.htm. [Accessed 20 September 2013].

[39] C. Nachenberg, "Computer virus‐coevolution," Communications of the Association for Computing Machinery, vol. 50, no. 1, pp. 46‐51, June 1997.

[40] Microsoft Corporation, "Virus alert about the Blaster worm and its variants," August 2003. [Online]. Available: http://support.microsoft.com/kb/826955. [Accessed 22 September 2013].

[41] Symantec Corporation, "W32.Blaster.Worm," August 2003. [Online]. Available: https://www.symantec.com/security_response/writeup.jsp?docid=2003‐081113‐0229‐99. [Accessed 22 September 2013].

[42] R. Ford, "Malware: Troy Revisited," Computers and Security, vol. 18, no. 2, pp. 105‐108, 1999.

[43] Computerworld Inc, "Soundminer Trojan horse steals Android phone data," January 2011. [Online]. Available: https://www.computerworld.com/s/article/9205627/Soundminer_Trojan_horse_steals_A ndroid_phone_data. [Accessed 20 September 2013].

[44] R. Schlegel, K. Zhang, X. Zhou, M. Intwala, A. Kapadia and X. Wang, "Soundminer: A Stealthy and Context‐Aware Sound Trojan for Smartphones," January 2011. [Online]. Available: https://www.cs.indiana.edu/~kapadia/papers/soundminer‐ndss11.pdf. [Accessed 25 September 2013].

[45] Y. Lee and K. Kozar, "Investigating factors affecting the adoption of anti‐spyware systems," Communications of the Association for Computing Machinery, vol. 48, no. 8, pp. 72‐77, July 2005.

[46] G. Wagener and A. Dulaunoy, "Malware behaviour analysis," Journal in Computer Virology, vol. 4, no. 4, pp. 279‐287, 2008.

[47] United States Computer Emergency Readiness Team, "Understanding Hidden Threats: Rootkits and Botnets," February 2013. [Online]. Available: https://www.us‐ cert.gov/ncas/tips/ST06‐001. [Accessed 26 September 2013].

[48] K. Chiang and L. Lloyd, "A case study of the rustock rootkit and spam bot," The First Workshop in Understanding Botnets, vol 20, 2007.

[49] D. Plohmann, E. Gerhards‐Padilla and F. Leder, "Botnets: Measurement, Detection,

Disinfection and Defence," March 2011. [Online]. Available: http://www.enisa.europa.eu/activities/Resilience‐and‐CIIP/critical‐ applications/botnets/botnets‐measurement‐detection‐disinfection‐and‐defence. [Accessed 26 September 2013].

[50] R. Ahmed and R. V. Dharaskar, "Study of Mobile Botnets: An Analysis from the Perspective of Efficient Generalized Forensics Framework for Mobile Devices," International Journal of Computer Applications, no. 15, pp. 5‐8, 2012.

[51] S. Peng, S. Yu and A. Yang, "Smartphone Malware and Its Propagation Modeling: A Survey," Communications Surveys & Tutorials, IEEE, vol. PP, no. 99, pp. 1‐17, 2013.

[52] B. Norwood, "What is the actual size for a sms?," July 2004. [Online]. Available: http://www.nowsms.com/discus/messages/1/5249.html. [Accessed 27 September 2013].

[53] 3GPP2, "Short Message Service ‐ TIA/EIA‐637‐A," [Online]. Available: http://www.3gpp2.org/public_html/specs/CS0015‐0.pdf. [Accessed 27 September 2013].

[54] S.‐K. Lee and W.‐J. Jae, "Design of effective anti‐malware system for mobile industrial devices based on windows CE," in 11th International Conference on Advanced Communication Technology, IEEE, vol. 3, pp. 1762‐1765, Gangwon‐Do, Korea (South), 2009.

[55] Nokia Corporation, "Bluetooth Overview," Nokia, October 2012. [Online]. Available: https://developer.nokia.com/Community/Wiki/Bluetooth_Overview. [Accessed 27 September 2013].

[56] F. Bennett, D. Clarke, J. Evans, A. Hopper, A. Jones and D. Leask, "Piconet: Embedded mobile networking," Personal Communications, IEEE, vol. 4, no. 5, pp. 8‐15, June 1997.

[57] J. Su, K. Chan, A. Miklas, K. Po, A. Akhavan, S. Saroiu, E. de Lara and A. Goel, "A Preliminary Investigation of Worm Infections in a Bluetooth Environment," WORM, vol. November, p. 8, 2006.

[58] Info Security Magazine, "90% of unknown malware is delivered via the web," March 2013. [Online]. Available: http://www.infosecurity‐magazine.com/view/31458/90‐of‐unknown‐ malware‐is‐delivered‐via‐the‐web/. [Accessed 27 September 2013].

[59] United States Computer Emergency Readiness Team, "Cyber Threats to Mobile Phones," April 2010. [Online]. Available: https://www.us‐cert.gov/security‐publications/cyber‐ threats‐mobile‐phones. [Accessed 16 August 2013].

[60] E. Chien, "Anatomy of a SMSishing Attack," Symantec Corporation, July 2009. [Online]. Available: http://www.symantec.com/connect/blogs/anatomy‐smsishing‐attack. [Accessed 27 September 2013].

[61] E. Ruiz, V. Hristidis, C. Castillo, A. Gionis and A. Jaimes, "Correlating financial time series with micro‐blogging activity," in Proceedings of the fifth ACM international conference on Web search and data mining, p. 515, Washington, USA, 2012.

[62] Symantec Corporation, "Malicious Shortened URLS on Social Networking Sites," April 2013. [Online]. Available: https://www.symantec.com/security_response/publications/threatreport.jsp. [Accessed 16 August 2013].

[63] M. Kassner, "URL shortening: Yet another security risk," March 2009. [Online]. Available: http://www.techrepublic.com/blog/it‐security/url‐shortening‐yet‐another‐security‐risk/. [Accessed 13 September 2013].

[64] Z. Wang and A. Stavrou, "Exploiting Smart‐Phone USB Connectivity for Fun and Profit," in Preceedings of the 26th Annual Computer Security Applications Conference (ACSAC), 6‐10 December pp. 357‐366, Austin, Texas, USA, 2010.

[65] H. Hu, S. Myers, V. Colizza and A. Vespignani, "WiFi networks and malware epidemiology," Proceedings of the National Academy of Sciences, vol. 10.1073/pnas.0811973106, 2009.

[66] Internet Crime Complaint Centre, "Malware installed on travellers' laptops through software updates on hotel Internet connections," May 2012. [Online]. Available: https://www.ic3.gov/media/2012/120508.aspx. [Accessed 1 October 2013].

[67] M. I. Husain and R. Sridhar, "iForensics: forensic analysis of instant messaging on smart phones," in Digital forensics and cyber crime, Berlin, Springer Berlin Heidelberg, 2010, pp. 9‐18.

[68] M. Alazab, A. Alazab and B. Lynn, "Smartphone malware based on synchronisation vulnerabilities, pp. 1‐6," in Proceedings of the 7th International Conference on Information Technology and Applications, Sydney, Australia, 2011.

[69] E. Mills, "Report: Memory card exposed 3,000 phones to virus," Cnet, March 2010. [Online]. Available: http://news.cnet.com/8301‐27080_3‐20000820‐245.html. [Accessed 29 September 2013].

[70] M. Ricknas, "Malware found on another HTC Magic smartphone," IT Worls, March 2010. [Online]. Available: http://www.itworld.com/personal‐tech/101253/malware‐found‐ another‐htc‐magic‐smartphone. [Accessed 15 September 2013].

[71] M. Egele, P. Wurzinger, C. Kruegel and E. Kirda, "Defending Browsers Against Drive‐by Downloads: Mitigating heap‐spraying code injection attacks," in Detection of Intrusions and Malware, and Vulnerability Assessment, Berlin, Springer Berlin Heidelberg, 2009, pp. 88‐ 106.

[72] J. Narvaez, B. Endicott‐Popovsky, C. Seifert, C. Aval and D. A. Frincke, "Drive‐by Downloads," in IEEE 43rd International Conference on System Sciences, pp. 1‐10, Hawaii, 2010.

[73] Lookout Inc, USA, "Hacked Websites Serve Suspicious Android Apps," May 2012. [Online]. Available: https://blog.lookout.com/blog/2012/05/02/security‐alert‐hacked‐websites‐ serve‐suspicious‐android‐apps‐noncompatible. [Accessed 12 December 2013].

[74] J. Oberheide and C. Miller, "Dissecting the android bouncer," in SummerCon, New York, 2012.

[75] R. Fedler, C. Banse, C. Krauss and V. Fusenig, "Android OS Security: Risks and Limitations ‐ A Technical Evaluation, pp. 9," May, Fraunhofer Research Institution for Applied and Integrated Security, AISEC, 2012.

[76] M. Becher, F. Freiling, J. Hoffman, T. Holz, S. Uellenbeck and C. Wolf, "Mobile Security Catching Up? Revealing the Nuts and Bolts of the Security of Mobile Devices," in Proceedings of the IEEE Computer Society 2011 Security and Privacy Symposium, Berkeley/Oakland, California, 2011.

[77] A. Bogdan, "SIM Toolkit Attack," November 2011. [Online]. Available: http://blog.m‐ sec.net/2011/sim‐toolkit‐attack/. [Accessed 15 September 2013].

[78] Gemalto, "SIM Toolkit," 2008. [Online]. Available: http://www.gemalto.com/techno/stk/. [Accessed 17 August 2013].

[79] D. Barroso, "ZeuS Mitmo: Man‐in‐the‐mobile," September 2010. [Online]. Available: http://securityblog.s21sec.com/2010/09/zeus‐mitmo‐man‐in‐mobile‐i.html. [Accessed 19 September 2013].

[80] R. Millman, "McAfee Warns of NFC Malware Risk," February 2013. [Online]. Available: http://www.itpro.co.uk/malware/19275/mcafee‐warns‐nfc‐malware‐risk. [Accessed 20 September 2013].

[81] H. Orman, "The Morris Worm: A Fifteen‐Year Perpective," Security & Privacy, IEEE, vol. 1, no. 5, pp. 35‐43, November 2003.

[82] P. Ferrie, "Something Smells Fishy," Virus Bulletin, vol. 11, p. 7, 2007.

[83] G. Keizer, "Researchers outwit Apple, plant malware in the App Store," Computerworld Inc, August 2013. [Online]. Available: https://www.computerworld.com/s/article/9241742/Researchers_outwit_Apple_plant_m alware_in_the_App_Store. [Accessed 12 November 2013].

[84] B. Jansen, M. Zhang, K. Sobel and A. Chowdury, "Twitter power: Tweets as electronic word

of mouth," Journal of the American Society for Information Science and Technology, vol. 60, no. 11, pp. 2169‐2188, 2009.

[85] Symantec Corporation, "Yet Another Bunch of Malicious Apps Found on Google Play," July 2013. [Online]. Available: http://www.symantec.com/connect/blogs/yet‐another‐bunch‐ malicious‐apps‐found‐google‐play. [Accessed 12 October 2013].

[86] D. Maslennikov, "ZeuS‐in‐the‐Mobile – Facts and Theories," Kaspersky Labs, October 2011. [Online]. Available: https://www.securelist.com/en/analysis/204792194/. [Accessed 22 October 2013].

[87] A. Dmitrienko, L. Davi, A.‐R. Sadeghi and C. Liebchen, "Over‐the‐Air Cross‐platform Infection for Breaking mTAN‐based Online Banking Authentication," in Black Hat 2012, Abu Dhabi, UAE, 2012.

[88] DSwiss Ltd, "2‐Factor Authentication for Mobile Applications," Institute of Applied Information Technology, Zurich University of Applied Sciences, Zurich, 2010.

[89] R. Malone and R. Levary, "Computer Viruses: Legal Aspects," University of Miami ‐ Business Law Journal, no. 2, pp. 125‐140, January 1994.

[90] M. Saleh, B. Mohamed and A. Nabi, "Eigenviruses for metamorphic virus recognition," IET Information Security, IEEE, vol. 5, no. 4, pp. 191‐198, 2011.

[91] B. Barak, O. Goldreich, R. Impagliazzo, S. Rudich, A. Sahai, S. Vadhan and K. Yang, "On the (Im)possibility of Obfuscating Programs," Journal of the ACM, vol. 59, no. 2, p. article 6, 2012.

[92] W. Wong and M. Stamp, "Hunting for Metamorphic Engines," Journal of Computer Virology, vol. 2, no. 3, pp. 211‐229, 2006.

[93] M. Christodorescu and S. Jha, "Static Analysis of Executables to Detect Malicious Patterns," in Proceedings of the 12th Conference on USENIX Security Symposium, Washington DC, USA, 2003.

[94] I. You and K. Yim, "Malware Obfuscation Techniques: A Brief Survey," in 2010 International Conference on Broadband, Wireless Computing, Communication and Applications, Fukuoka, Japan, 2010.

[95] P. Szor, The Art of Computer Virus Research and Defense, Boston, US: Addison‐Wesley Professional, 2005.

[96] P. O'Kane, S. Sezer and K. McLaughlin, "Obfuscation: The Hidden Malware," IEEE Security and Privacy, vol. 9, no. 5, p. 42, 2011.

[97] J. Oberheide, "PolyPack at USENIX WOOT ’09," August 2009. [Online]. Available: http://jon.oberheide.org/blog/2009/08/10/polypack‐at‐usenix‐woot‐09/. [Accessed 12 October 2013].

[98] Oreans Technologies, "Themida ‐ Advanced Windows Software Protection System," October 2013. [Online]. Available: http://www.oreans.com/themida.php. [Accessed 12 November 2013].

[99] E. Al Daoud, I. Jebril and B. Zaqaibeh, "Computer virus strategies and detection methods," International Journal of Open Problems in Computer Science, vol. 1, no. 2, pp. 12‐20, August 2008.

[100] McAfee Inc, "W95/Memorial," 01 August 2003. [Online]. Available: http://www.mcafee.com/threat‐intelligence/malware/default.aspx?id=111429. [Accessed 1 December 2013].

[101] VX Heaven, "The Mutation Engine," 1992. [Online]. Available: http://vxheaven.org/vx.php?id=em11. [Accessed 27 October 2013].

[102] T. Chen, "Trends in viruses and worms," The Internet Protocol Journal, vol. 6, no. 3, pp. 23‐ 33, 2003.

[103] P. Ször and P. Ferrie, "Hunting for metamorphic," in Virus Bulletin Conference 2001, 27‐28 September, Prague, Czech Republic, 2001.

[104] G. Lawton, "On the Trail of the Conficker Worm," Computer, IEEE, vol. 42, no. 6, pp. 19‐22, 2009.

[105] M. Schiffman, "A Brief History of Malware Obfuscation: Part 2 of 2," February 2010. [Online]. Available: http://blogs.cisco.com/security/a_brief_history_of_malware_obfuscation_part_2_of_2/. [Accessed 17 November 2013].

[106] D. Dittrich, "So you want to take over a botnet," in Proceedings of the 5th USENIX conference on Large‐Scale Exploits and Emergent Threats, USENIX Association, pp. 6‐6, California, USA, 2012.

[107] F. Howard, "Widespread site compromise leading to Zeus," Sophos Ltd, July 2011. [Online]. Available: http://nakedsecurity.sophos.com/2011/07/15/widespread‐site‐compromise‐ leading‐to‐zeus/. [Accessed 12 November 2013].

[108] A. Issa, "Anti‐virtual Machines and Emulations," Journal in Computer Virology, vol. 8, no. 4, pp. 141‐149, 2012.

[109] Z. Chen, L. Gao and K. Kwiat, "Modeling the Spread of Active Worms," in Twenty‐Second

Annual Joint Conference of the IEEE Computer and Communications, vol. 3, pp. 1890‐1900, San Francisco, California, USA, 2003.

[110] V. K. Base, "Mechanisms to determine if software is running in a VMware virtual machine," VMware, March 2011. [Online]. Available: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC &externalId=1009458. [Accessed 28 November 2013].

[111] D. Crow, "Navigating the PEB," May 2005. [Online]. Available: http://www.codeproject.com/Articles/10438/Navigating‐the‐PEB. [Accessed 22 November 2013].

[112] M. Sikorski and A. Honig, "Anti‐Disassembly," in Practical Malware Analysis, San Francisco, USA, No Starch Press, Inc, 2012, pp. 328‐350.

[113] J. Aycock, "Anti‐disassembly," in Computer Viruses and Malware, Philadelphia, USA, Springer Science and Business Media, LLC, 2006, pp. 103‐105.

[114] D. Kushner, "The Real Story of Stuxnet," February 2013. [Online]. Available: http://spectrum.ieee.org/telecom/security/the‐real‐story‐of‐stuxnet. [Accessed 1 December 2013].

[115] S. Gorman, "Chinese Hackers Suspected In Long‐Term Nortel Breach," The Wall Street Journal, February 2012. [Online]. Available: http://online.wsj.com/news/articles/SB10001424052970203363504577187502201577054 . [Accessed 29 November 2013].

[116] M. Elfattah, A. Youssif and E. S. Ahmed, "Handset Malwares Threats Feature Extraction Based on Behavior Analysis," Computer and Information Science, vol. 5, no. 2, p. 79, 2012.

[117] J. Vinod, R. Jaipur, V. Laxmi and M. Gaur, "Survey on Malware Detection Methods," in Proceedings of the 3rd Hackers’ Workshop on Computer and Internet Security, pp. 74‐79, Kanpur, India, 2009.

[118] N. Idika and A. P. Mathur, "A Survey of Malware Detection Techniques," Purdue University, West Lafayette, Indiana, USA, 2007.

[119] C. Shaffer, "Hashing Tutorial," Virginia Tech Algorithm Visualization Research Group, October 2011. [Online]. Available: http://research.cs.vt.edu/AVresearch/hashing/index.php. [Accessed 30 November 2013].

[120] J.‐P. Heo, Y. Lee, J. He, S.‐F. Chang and S.‐E. Yoon, "Spherical Hashing," in IEEE Conference on Computer Vision and Pattern Recognition pp. 2957‐2964, Rhode Island, USA, 2012.

[121] D. Arp, M. Spreitzenbarth, M. Hübner, H. Gascon and K. Rieck, "DREBIN: Effective and

Explainable Detection of Android Malware in Your Pocket," University of Göttingen, Germany, 2014.

[122] A.‐D. Schmidt, J. H. Clausen, A. Camtepe and S. Albayrak, "Detecting Symbian OS Malware through Static Function Call Analysis," in 4th International Conference on Malicious and Unwanted Software, Montreal, QC, 2009.

[123] J. Chow, B. Pfaff, T. Garfinkel, K. Christopher and M. Rosenblum, "Understanding Data Lifetime Via Whole System Simulation," in USENIX Security Symposium, pp. 321‐336, California, USA, 2004.

[124] D. E. Denning and P. J. Denning, "Certification of Programs for Secure Information Flow," Communications of the Association for Computing Machinery, vol. 20, no. 7, pp. 504‐513, 1977.

[125] Microsoft Corporation, "Windows Registry Information for Advanced Users," Microsoft Corporation, September 2012. [Online]. Available: https://support.microsoft.com/kb/256986. [Accessed 2 December 2013].

[126] G. Lyon, "Nmap Security Scanner," [Online]. Available: http://www.nmap.org. [Accessed 5 December 2013].

[127] J. Aycock, "Anti Virus Techniques," in Computer Viruses and Malware, New York, Springer Science & Business Media, LLC, 2006, p. 72.

[128] J. Newsome and D. Song, "Dynamic T aint Analysis for Automatic Detection, Analysis and Signature Generation of Exploits on Commodity Software," in Proceedings of the 12th Annual Network and Distributed System Security Symposium, California, USA, 2005.

[129] G. Sarwar, O. Mehani, R. Borely and M. A. Kaafar, "On the Effectiveness of Dynamic Taint Analysis for Protecting Against Private Information Leaks on Android‐based Devices," in SECRYPT 2013, 10th International Conference on Security and Cryptography, Reykjavik, Iceland, July 2013.

[130] W. Enck, P. Gilbert, B.‐G. Chun, L. P. Cox, J. Jung, P. McDaniel and A. Sheth, "TaintDroid: An Information‐Flow Tracking System for Realtime Privacy Monitoring on Smartphones," Operating Systems, Design and Implementation, vol. 10, pp. 255‐270, 2010.

[131] D. Bornstein, "Dalvik vm Internals," Google I/O Developer Conference, vol. 23, pp. pp. 17‐ 30, 2008.

[132] O. Benoit, N. Dabbous, L. Gauteron, P. Girard, H. Handschuh, D. Naccache, S. Socie and C. Whelan, "Mobile Terminal Security," International Association for Cryptologic Research ‐ ePrint Archive, vol. 158, pp. pp. 1‐24, 2004.

[133] S. Forrest, S. Hofmeyr, A. Somayaji and T. Longstaff, "A Sense of Self for Unix Processes," in Proceedings of the 1996 IEEE Symposium on Security and Privacy, Los Alamitos, CA, 1996.

[134] B. Costales, C. Assmann, G. Jansen and G. Shapiro, Sendmail, 4th Edition, Sebastopol, USA: O'Reilly Media, Inc, 2007.

[135] G. Suarez‐Tangil, J. Tapiador, P. Peris‐Lopez and A. Ribagorda, "Evolution, Detection and Analysis of Malware for Smart Devices," Communications Surveys & Tutorials, IEEE, vol. PP, no. 99, pp. 1‐17, 2013.

[136] Oxford University Press, "Oxford English Dictionary Online," 2013. [Online]. Available: http://www.oed.com/view/Entry/86554?redirectedFrom=heuristic. [Accessed 12 December 2013].

[137] Z. Bazrafshan, H. Hashemi, S. M. H. Fard and A. Hamzeh, "A Survey on Heuristic Malware Detection Techniques," in IEEE 5th Conference on Information and Knowledge Technology, Iran, 2013.

[138] D. Harley and A. Lee, "Heuristic Analysis – Detecting Unknown Viruses," March 2007. [Online]. Available: http://www.eset.com/us/resources/white‐ papers/Heuristic_Analysis.pdf. [Accessed 14 December 2013].

[139] M. Schultz, E. Eskin, E. Zadok and S. Stolfo, "Data mining methods for detection of new malicious executables," in IEEE Symposium on Security and Privacy, pages 38‐49, Oakland, California, 2001.

[140] T. Timmermans and J. Kloosterman, "Detecting Client‐Side e‐Banking Fraud Using a Heuristic Model," July 2013. [Online]. Available: http://www.delaat.net/rp/2012‐ 2013/p77/presentation.pdf . [Accessed 16 December 2013].

[141] S. A. Hofmeyr, S. Forrest and A. Somayaji, "Intrusion Detection Using Sequences of System Calls," Journal of Computer Security, vol. 6, no. 3, pp. 151‐180, 1998.

[142] R. Moskovitch, C. Feher, N. Tzachar, E. Berger, M. Gitelman, S. Dolev and Y. Elovici, in Intelligence and Security Informatics ‐ Lecture Notes in Computer Science, Springer Berlin Heidelberg, 2008, pp. 204‐215.

[143] D. Bilar, "Opcodes as predictor for malware," International Journal of Electronic Security and Digital Forensics, vol. 1, no. 2, pp. 156‐168, 2007.

[144] A. Shabtai, R. Moskovitch, C. Feher, S. Dolev and Y. Elovici, "Detecting unknown malicious code by applying classification techniques on OpCode patterns," Security Infomatics, vol. 1, no. 1, pp. 1‐22, 2012.

[145] E. Moyotl‐Hernandez and H. Jimenez‐Salazar, "An Analysis on Frequency of Terms for Text

Categorization," in Proceedings of the 20th Conference of Spanish Natural Language Processing Society, Valencia, Spain, 2004.

[146] T. Abou‐Assaleh, N. Cercone, V. Keselj and R. Sweidan, "N‐gram‐based Detection of New Malicious Code," Computer Software and Applications ‐ Conference Proceedings, vol. 2, pp. 41‐42, 2004.

[147] J. Z. Kolter and M. A. Maloof, "Learning to Detect Malicious Executables in the Wild," in Proceedings of the tenth ACM SIGKDD international conference on Knowledge discovery and data mining pp. 470‐478, Washington, USA, 2004.

[148] M. Pietrek, "msdn Magazine ‐ An In‐Depth Look into the Win32 Portable Executable File Format," February 2002. [Online]. Available: http://msdn.microsoft.com/en‐ us/magazine/cc301805.aspx. [Accessed 17 December 2013].

[149] S. J. Stolfo, W.‐J. Li, A. Stavrou, E. Androulaki and A. D. Keromytis, "A Study of Malcode‐ Bearing Documents," in Detection of Intrusions and Malware, and Vulnerability Assessment, Switzerland, Springer, 2007, pp. pp. 231‐250.

[150] P. Jalote, An Integrated Approach to Software Engineering, New York: Springer‐Verlag, 1997.

[151] T. J. McCabe, "A Complexity Measure," IEEE Transactions on Software Engineering, vol. 4, pp. pp. 308‐320, 1976.

[152] R. Sharp, "An Introduction to Malware ‐ Notes on Network Security," Spring 2009. [Online]. Available: http://www2.imm.dtu.dk/courses/02233/malware.pdf. [Accessed 12 December 2013].

[153] Z. Zhao, "A Virus Detection Scheme Based on Features of Control Flow Graph," in IEEE 2nd International Conference on Artificial Intelligence, Management Science and Electronic Commerce, pp. 943‐947, Zhengzhou, China, 2011.

[154] G. Bonfante, M. Kaczmarek and J.‐Y. Marion, "Control Flow Graphs as Malware Signatures," in Proceedings of the 2nd International Workshop on Theory of Computer Viruses, Nancy, France, 2007.

[155] J. Miller, "Hybrid Code Analysis versus State of the Art Android Backdoors," August 2013. [Online]. Available: http://www.joesecurity.org/articles/Hybrid%20Code%20Analysis%20versus%20State%20o f%20the%20Art%20Android%20Backdoors.pdf. [Accessed 19 December 2013].

[156] K. Roundy and B. Miller, "Hybrid Analysis and Control of Malware," in Recent Advances in Intrusion Detection, Springer Berlin Heidelberg, 2010, pp. 317‐338.

[157] L. K. Shar, H. B. K. Tan and L. C. Briand, "Mining SQL Injection and Cross Site Scripting Vulnerabilities Using Hybrid Program Analysis," in Proceedings of the IEEE 2013 International Conference on Software Engineering, pp. 642‐651, California, USA, 2013.

[158] Oracle Corporation, "VirtualBox," [Online]. Available: https://www.virtualbox.org. [Accessed 2 January 2014].

[159] The Apache Software Foundation, "Apache HTTP Server Project," [Online]. Available: https://httpd.apache.org/. [Accessed 2 January 2014].

[160] J. Muniz, Web Penetration Testing with Kali Linux, Birmingham, UK: Packt Publishing Ltd, 2013.

[161] Contagio Mobile, "Android/Windows Spy: Android DroidCleaner and Superclean," February 2013. [Online]. Available: http://contagiominidump.blogspot.com/2013/02/androidwindows‐spyandroidssucl.html. [Accessed 3 January 2014].

[162] CodePlex, "NAudio Overview," November 2013. [Online]. Available: https://naudio.codeplex.com. [Accessed 3 January 2014].

[163] G. Nolan, "Laying the Groundwork," in Decompiling Android, New York, USA, Apress Media LLC, 2012, pp. 1‐17.

[164] Joe Security LLC, "Joe Sandbox Cloud ‐ Advanced Threat Intelligence Service," 2013. [Online]. Available: http://www.joesecurity.org/joe‐sandbox‐cloud. [Accessed 20 December 2013].

[165] D. Lukan, "Anti‐Debugging: Detecting System Debugger," Infosec Institute ‐ IT Security Training and Resources, February 2013. [Online]. Available: http://resources.infosecinstitute.com/anti‐debugging‐detecting‐system‐debugger. [Accessed 31 January 2014].

[166] Microsoft Corporation, "User Mode and Kernel Mode ‐ Concepts For All Driver Developers," December 2013. [Online]. Available: http://msdn.microsoft.com/en‐ us/library/windows/hardware/ff554836%28v=vs.85%29.aspx. [Accessed 5 January 2014].

[167] Google Inc, "Android Security Overview," [Online]. Available: http://source.android.com/devices/tech/security/. [Accessed 2 January 2014].

[168] S. Mrdovic and B. Perunicic, "Kerckhoffs’ Principle for Intrusion Detection," in 13th International Telecommunications Network Strategy and Planning Symposium, pp. 1‐14, Budapest, Hungary, 2008.

[169] J.‐H. Hoepman and B. Jacobs, "Increased security through open source," Communications

of the Association for Computing Machinery, vol. 50, no. 1, pp. 79‐83, 2007.

[170] D. Maynor, Metasploit Toolkit for Penetration Testing, Exploit Development, and Vulnerability Research, California, USA: Elsevier, 2011.

[171] Genymotion Community, "Features of Genymotion," [Online]. Available: http://www.genymotion.com/features. [Accessed 6 January 2014].