Dynamic Malware Detection and Phylogeny Analysis using ... › sites › default › files › dynamic... · Dynamic Malware Detection and Phylogeny Analysis using Process Mining

Noname manuscript No.(will be inserted by the editor)

Dynamic Malware Detection and Phylogeny Analysis using ProcessMining

Mario Luca Bernardi · Marta Cimitile · Damiano Distante · Fabio Martinelli ·Francesco Mercaldo

Received: date / Accepted: date

Abstract In the last years, mobile phones have become es-sential communication and productivity tools used daily toaccess business services and exchange sensitive data. Con-sequently, they have also become the biggest target of mal-ware attacks. New malware is created everyday, most ofwhich is generated as variants of existing malware by re-using its malicious code. This paper proposes an approachfor malware detection and phylogeny studying based on dy-namic analysis using process mining. The approach exploitsprocess mining techniques to identify relationships and re-curring execution patterns in the system call traces gatheredfrom a mobile application in order to characterize its beha-vior.

The recovered characterization is expressed in terms of aset of declarative constraints between system calls and rep-resents a sort of run-time fingerprint of the application.

The comparison between the so defined fingerprint of agiven application with those of known malware is used to: i)verify if the application is malware or trusted, ii) in case ofmalware, which family it belongs to, and iii) how it differsfrom other known variants of the same malware family.

M. L. BernardiGiustino Fortunato University, Benevento ItalyE-mail: [email protected]

M. CimitileUnitelma Sapienza University, Rome, ItalyE-mail: [email protected]

D. DistanteUnitelma Sapienza University, Rome, ItalyE-mail: [email protected]

F. MartinelliInstitute for Informatics and Telematics, CNR Pisa, ItalyE-mail: [email protected]

F. MercaldoInstitute for Informatics and Telematics, CNR Pisa, ItalyE-mail: [email protected]

An empirical study conducted on a dataset of 1200 trus-ted and malicious applications across nine malware familieshas shown that the approach exhibits a very good discrim-ination ability that can be exploited for malware detectionand malware evolution studying. Moreover, the study hasalso shown that the approach is robust to code obfuscationtechniques increasingly being used by nowadays malware.

Keywords Malware Detection · Malware Evolution ·Malware Phylogeny · Security · Process Mining · LinearTemporal Logic · Declare

1 Introduction

Over the last years, the growth in the number of applica-tions for mobile phones has changed the way to communic-ate and to access information. Given their increasing capab-ilities, mobile phones are currently used to access sensitivedata, such as personal information and email, and to per-form a wide range of activities, like paying a bill and check-ing a bank account. As a consequence, they have becometarget of continuous attacks obtained through an increasingnumber of malicious software that becomes everyday moreaggressive and sophisticated [25]. This malicious code isusually generated from existing malicious software [25] us-ing some automatic tools that generate new malware fromlibraries and code borrowed from robust networks used formalware code exchange. In response to this phenomenon, awide range of antimalware programs have been developedthat can be used to perform malware detection and to studymalware phylogeny. Malware detection is meant to identifyand contain malware [11]. Malware phylogeny analysis ismeant to extract a model, inspired by biological research,that highlights similarities and relationships between a setof malware [21]. This model can then be used to support theidentification of malware evolution trends, the individuation

2 Mario Luca Bernardi et al.

of new strategies to dissect malware samples, and the dis-covery of software vulnerabilities (e.g., the vulnerabilitiespresent in an application may also reside in the applicationsderived from it) [25, 31].

In this paper, starting from the assumption that any ma-licious behavior is implemented by specific sequences ofsystem calls, we propose an approach for malware detec-tion and malware phylogeny analysis that adopts processmining techniques for the analysis of the system call tracesgenerated by an application. Process Mining (PM) is a pro-cess management technique for the analysis of business pro-cesses based on event logs [44]. In our approach we use PMto analyze the system call traces of a mobile application,assuming that similarities and derivations between systemcalls can be discovered and modeled in system call tracessimilarly to what applies for business process activities inbusiness process logs. According to this, in our approachwe use PM to derive a characterization of the behavior of a(trusted or malware) mobile application from a set of systemcall traces gathered from it in response to a set of operatingsystem events. Such characterization is expressed as a set ofdeclarative constraints between system calls using the De-clare process modeling language [36] and is named SystemCalls Execution Fingerprint (SEF). The extracted SEF mod-els can be used to characterize and discriminate malware andto trace the malware phylogeny.

Even if the proposed approach can be applied to all theexisting mobile platforms, in this work the focus is on theAndroid platform as, according to recent survey [4], it is thefavorite target for mobile threats. This is not surprising con-sidering that in 2014 Android holds more than 80% of thetotal market share in smartphones and tablets [5] and that thesales of smartphones worldwide totaled 349 million unitsin the first quarter of 2016 [3]. Moreover, current solutionsto protect Android users are still inadequate. For example,several antimalware adopt a signature-based malware detec-tion approach requiring antimalware vendors to be awareof new malware code in order to identify their signatures(in the form of fixed strings and regular expressions) and tosend out updates regularly. Furthermore, there are new tech-niques that evade signature-based detection approaches byincluding various types of source code transformation andsimple forms of polymorphic attacks [37]. Malware detec-tion in Android is also affected by another problem: differ-ently from antimalware software on desktop operating sys-tems, Android does not permit to monitor file system oper-ations. An Android application, indeed, can only access itsown disk space; as such, an Android antimalware cannot ac-cess and verify the malicious code eventually downloadedand run at run-time by another application installed in thedevice. This problem has been mitigated but not solved byGoogle with the introduction of Bouncer [34]. When a newapplication is submitted to the Google Play Store, Boun-

cer executes it in a sandbox for a fixed-time window be-fore making it available to users on the official store. Con-sequently, Bouncer can detect malware actions that happenin this time interval but cannot detect the other malwareactions that happen after this observation period. However,since signature-based detection techniques are evaded by at-tackers with new malware which are increasingly aggress-ive, new techniques that go beyond to detect malware soft-ware in Android devices are required.

With respect to existing approaches to malware detec-tion and phylogeny model extraction, our approach intro-duces the following novelties:

– the SEF model extracted to characterize a malware be-havior is obtained using a declarative constraint-basedlanguage that allows to exploit a much wider range ofproperties and relationships between system calls in sys-tem call traces;

– the same model can be effectively used as a malware fin-gerprint for both malware detection and phylogeny ana-lysis.

Finally, the approach is particularly suitable to be usedas an automatic verification step in the approval process per-formed by application stores to ensure the security of thepublished applications.

This paper is an extension of our earlier work presen-ted in [11] and [31]. With respect to these works, this paperpresents:

– an integrated approach for both phylogeny analysis andmalware detection;

– a wider experimentation involving a larger set of ap-plications belonging to an increased number of malwarefamilies;

– a robustness analysis aimed at assessing the impact ofbehavioral-preserving code transformations on the de-tection capability of our approach.

The rest of the paper is organized as follows. Section 2describes the background of our study. Section 3 presents theproposed approach. Section 4 evaluates the effectiveness ofthe approach by testing it on a dataset of 9 malware familiesand 1200 between trusted and malware applications. Section5 evaluates the robustness of the approach with regard to aset of well-known code transformation techniques. Section6 and 7 discuss threats to validity and related work, respect-ively. Finally Section 8 provides some conclusive remarksfor our work.

2 Background

2.1 Mobile Malware Families

Malicious programs are frequently related to previous pro-gram versions through evolutionary relationships. The know-

Dynamic Malware Detection and Phylogeny Analysis using Process Mining 3

ledge of these relationships can be useful for both construct-ing a phylogeny model and supporting malware detectionthrough the analysis of new malware basing on the similarit-ies with the known ones [28]. In particular, malware applica-tions can be grouped into families. Each family defines a setof behaviors and properties that, to a certain extent, are com-mon to all its members. Starting from the analysis of securityannouncements, threat reports, articles in researchers’ blogs,and data published by existing mobile antimalware com-panies, in [53] a list of 49 Android malware families, withtheir characteristics, is reported. The main properties for thetop 10 malware families (basing on the number of knownsamples) are reported in Table 4. For each malware familythe table shows: i) the name of the family (first column), ii)a brief description of the malware family (second column),iii) the installation type (third column), which refers to theway the malicious payload is installed (’r’ for repackaging,’s’ for standalone, and ’u’ for update attack), and iv) the ac-tivation mechanism (fourth column), i.e., the system eventsthat activate the malicious behaviour.

Table 2 shows a list of the most relevant system eventsthat an application can receive during its lifecycle and that,according to several studies [27, 53], are known to triggera malware payload most frequently. Looking at the table,the first row represents the BOOT event, the most used withinexisting Android malware. This is not surprising since thisevent will be triggered and sent to all the applications in-stalled in an Android device as the system finishes its boot-ing process, a perfect time for a malware to kick off its back-ground services. By listening to this event, a malware canstart itself without any intervention or interaction of the userwith the system.

Other events frequently used by malware writers are theACTION ANSWER and NEW OUTGOING CALL events (second rowin Table 2): these events will be sent in broadcast to thewhole system (and all the running applications) when a callis received or started.

Starting from existing malware, new variants are releasedby malware writers to get as much mileage as possible fromthe original code and to create new undetectable malware.Therefore, malware variants are new strains and slightly mod-ified versions of a malware belonging to the same malwarefamily. These malware variants include increasingly soph-isticated techniques for obfuscating malicious behavior inorder to elude detection strategies employed by current an-timalware products [53]. In particular, polymorphism andmetamorphism are obfuscating techniques rapidly spreadingamong malware targeting mobile applications [39].

For instance, the first version of DroidKungFu malwarewas detected in June 2011. Successively, security research-ers detected the second version DroidKungFu2 and the thirdversion DroidKungFu3 in July and August 2011, respect-ively. Finally, the fourth version DroidKungFu4 was detec-

ted in October 2011. Similarly to the the previous genera-tions of DroidKungFu, the latest version is able to install abackdoor that gives hackers full control of the mobile device.Therefore, while previous versions of DroidKungFu retrievedinstructions from a remote “command and control” serverand stored the URL for the server in plain text, DroidKungFu3and DroidKungFu4 encrypt the URL, making it harder toidentify and block them. Moreover, starting from this ver-sion, the vulnerable code is encrypted, making more dif-ficult to identify the malware [53]. Finally, starting fromDroidKungFu3, after installing the embedded payload, it ismasked as an official Google update, thus increasing its dif-fusion and reducing users’ diffidence.

2.2 Declare

In this work the ProM tool and the Declare language areused respectively to mine and represent the SEF model de-scribing the behavior of a malware family. The model is ex-tracted from a set of system call traces produced by mobileapplications in response to system events listed in Table 2.ProM 6.1 [45] is a tool supporting a wide variety of pro-cess mining techniques. Declare is a declarative constraintlanguage proposed by Pesic and van der Aalst and largelydiffused in the Process Mining domain [36]. While proced-ural approaches explicitly specify the interactions betweenprocess events, Declare represents a process as a set of rulesconstraining all the events to be executed in a given orderand implicitly describing all the possible workflows. In otherwords, while in procedural approaches all the activities thatare not explicitly specified are forbidden (the produced mod-els are “closed”), in declarative models all the workflowsthat do not violate the constraints are allowed (the producedmodels are “open”); for this reason, declarative approachesare suitable to represent complex processes with high flex-ibility [10]. Finally, another advantage of using Declare isthat it represents a process modeling language more under-standable for end-users and provided with an executable andverifiable formal semantics.

Declare constraints can be seen as concrete instantiationsof templates. A template is an abstract entity that definesparametrized classes of properties through an usable andsimple graphical representation connected to a formal se-mantics based on the adoption of Linear Temporal Logic(LTL) formulas.

LTL formulas can be traduced in non-deterministic Fi-nite State Automatons (FSA) that represent all the tracessatisfying the constraint. The temporal operators used to de-scribe the semantics of the Declare templates are reported inTable 3. In the table, LTL formulas are indicated by ϕ and ψ.◦ϕ is used to indicate that ϕ has to hold in the next positionin a trace.�ϕ means that ϕ is always in the subsequent posi-tions in a trace. ♦ϕ indicates that ϕ has to hold eventually in


Table 1: The top 10 malware families.

Family Description IT AEDroidKungFu 1-4 It installs a backdoor that allows attackers to access the smartphone when

they want and use it as they pleaser BOOT, BATT,

SYSOpfake It demands payment for the application content through premium text mes-

sagesr MAIN

GinMaster It contains a malicious service with the ability to root devices to escalateprivileges, steal confidential information and install applications

r BOOT

AnserverBot It repackages into the host app with two hidden apps r,u BOOT, NET,CALL

BaseBridge It sends information to a remote server running one or more malicious ser-vices in background

r,u BOOT, SMS,NET, BATT

Kmin It is similar to BaseBridge, but does not kill antimalware processes s BOOTPjapps It is a Trojan horse that has been embedded on third party applications and

opens a back door on the compromised devicer BOOT, SMS,

BATTGeinimi It has the potential to receive commands from a remote server that allows

the owner of that server to control the phoner MAIN

Adrd It is close to Geinimi but with less server side commands r BOOT, CALLDroidDream It gains root access to device to access unique identification information r MAIN

Table 2: System events used to activate the malicious payload.

# Event Description1 BOOT COMPLETED Able to catch the boot completed2 ACTION ANSWER,NEW OUTGOING CALL Incoming and Outgoing call3 ACTION POWER CONNECTED Battery status in charging4 ACTION POWER DISCONNECTED Battery status discharging5 BATTERY OKAY Battery full charged6 BATTERY LOW Battery status at 50%7 BATTERY EMPTY Battery status at 0%8 SMS RECEIVED Reception of SMS9 AIRPLANE MODE The user has switched the phone into or out of Airplane Mode10 BATTERY CHANGED Battery status changed11 CONFIGURATION CHANGED The current device Configuration (orientation, locale, etc) has changed12 DATA SMS RECEIVED A new data based SMS message has been received by the device13 DATE CHANGED Receives data changed events14 DEVICE STORAGE LOW Free storage on device is less than 10% of total space15 DEVICE STORAGE OK Free storage on device is adequate16 INPUT METHOD CHANGED An input method has been changed17 PROVIDER CHANGED Providers publish new events or items that the user may be especially interested in18 PROXY CHANGE Variation of proxy configuration19 SCAN RESULTS An access point scan has completed, and results are available from the supplicant20 SENDTO Send a message to someone specified by the data21 SIM FULL The SIM storage for SMS messages is full22 SMS SERVICE CDMA SMS has been received containing Service Category Program Data23 STATE CHANGED The state of Bluetooth adapter has been changed.24 WAP PUSH RECEIVED A new WAP PUSH message has been received by the device

the subsequent positions in a trace. ϕU ψ means that ϕ hasto hold at least until ψ holds in a trace. Moreover, ψ musthold in a future or in the current position. Finally, ϕW ψ

means that ϕ has to hold in the subsequent positions at leastuntil ψ holds. If ψ never holds, ϕ must hold everywhere.

Looking at the table, the response constraint�(a→♦b)indicates that if a occurs, b must eventually follow. Accord-ing to this, the response constraint is satisfied for traces suchas t1 = 〈a,a,b,c〉, t2 = 〈b,b,c,d〉 and t3 = 〈a,b,c,b〉, but notfor t4 = 〈a,b,a,c〉 because, in this case, the second instanceof a is not followed by a b. Some considerations apply to

t2, where the response constraint is satisfied only becausea never occurs. In this case, the constraint is called vacu-ously satisfied according to the notion introduced in [12].Moreover, according to [12], a constraint is non-vacuouslysatisfied in a trace when it is activated in that trace. Moreover,a constraint is activated in a trace when its occurrence im-poses some obligations. For example, for the response con-straint �(a → ♦b), a is an activation because the execu-tion of a forces b to be eventually executed. There are twokinds of constraint activation: the fulfillment and the viol-ation. Every constraint in a trace leads to a fulfillment if


Table 3: Graphical notation and LTL formalization of the Declare templates.

Template Formalization Notation

Init(A) Ainit

A

Existence(A) ♦A1..∗

A

Existence2(A) ♦(A∧◦(♦A))2..∗

A

Existence3(A) ♦(A∧◦(♦(A∧◦(♦A))))3..∗

A

Absence(A) ¬♦A0

A

Absence2(A) ¬♦(A∧◦(♦A))0..1

A

Absence3(A) ¬♦(A∧◦(♦(A∧◦(♦A))))0..2

A

Exactly1(A) ♦A∧¬♦(A∧◦(♦A))1

A

Exactly2(A) ♦(A∧◦(♦A))∧2

A

¬♦(A∧◦(♦(A∧◦(♦A))))

Choice(A,B) ♦A∨♦B A −− ♦−− B

Exclusive Choice(A,B) (♦A∨♦B)∧¬(♦A∧♦B) A −− �−− B

Responded Existence(A,B) ♦A→ ♦B A •−−−− B

Co-Existence(A,B) ♦A↔ ♦B A •−−−• B

Response(A,B) �(A→ ♦B) A •−−−I B

Precedence(A,B) ¬BW A A −−−I• B

Succession(A,B) �(A→ ♦B)∧ (¬BW A) A •−−I• B

Alternate Response(A,B) �(A→◦(¬AU B)) A •===I B

Alternate Precedence(A,B) (¬BW A)∧�(B→◦(¬BW A)) A ===I• B

Alternate Succession(A,B) (¬BW A)∧�(B→◦(¬BW A)) A •==I• B

∧ �(A→◦(¬AU B))

Chain Response(A,B) �(A→◦B) A •=−=−=−I B

Chain Precedence(A,B) �(◦B→ A) A =−=−=−I• B

Chain Succession(A,B) �(A→◦B)∧�(◦B→ A) A •=−=−I• B

Not Co-Existence(A,B) ♦A→¬♦B A •−−−•‖ B

Not Succession(A,B) �(A→¬♦B) A •−−I•‖ B

Not Chain Succession(A,B) �(A→¬◦B) A •=−=−I•‖ B

the trace is perfectly compliant with respect to a constraint.For example, the response constraint �(a→ ♦b) in tracet1 is activated and fulfilled twice, whereas, in trace t3, it isactivated and fulfilled only once. On the other hand, thereare both a fulfillment and a violation of an activation of aconstraint when a trace is not compliant with respect to thisconstraint (at least one activation leads to a violation).

For example, looking to the trace t4, the response con-straint�(a→♦b) is activated twice: the first activation leadsto a fulfillment (eventually b occurs) while the second activ-

ation leads to a violation (b does not occur subsequently).For clarity, we report in Figure 1 an example of a declarat-ive process. The process is inspired to the insurance claimprocess described in [35] and represents the set of activit-ies for the handling of health insurance claims. The processconsists of five events and the constraints between them. Forexample, the not co-existence rule between Notify by emailand Notify by phone indicates that only one between thesetwo events can occur in the some log.


The following Figure 2 shows an excerpt from an execu-tion trace for the process in Figure 1. For example, basingon the response constraint between Perform medical his-tory check and Contact hospital, the Perform medical his-tory check event occurs two times and is always followed byContact hospital.

Finally, in Figure 3 we report for completeness an FSAfor the constraint response(Perform medical history check,Contact hospital). The figure shows an automaton with thestates s0 and s1. State s0 has an incoming arrow without asource state, which means that it is an initial state. Moreover,it is represented with a double border meaning that it is alsoan accepting state. In the figure, there are also some events(e.g., (contact hospital, tc)) described with a couple contain-ing the event name and the event type. The event type givesinformation about the state of the event (e.g., suspended (ts)and completed (tc)). In the proposed example, activities arealways considered instantaneous and are labeled with theevent type tc. Moreover, transitions between states are repor-ted with labeled directed arrows. For example, the transition!(s0, (perform medical history check, tc), s0) means that ifthe automaton is in the state s0 and any event different from(perform medical history check, tc) occurs, then the auto-maton remains in state s0. Similarly, (s0, (contact hospital,tc), s1) means that if the automaton is in the state s0 and theevent (contact hospital, tc) occurs than the automaton statechanges in s1. Moreover, the transition (s1, (perform med-ical history check, tc), s0) means that from the state s1 wecan have a transition to the state s0. Similarly, the transition!(s1, (perform medical history check, tc), s1) means that ifthe automaton is in the state s1 and any event different from(perform medical history check, tc) occurs, then the auto-maton remains in state s1.

3 Approach

This section describes the proposed approach for Androidmalware detection and phylogeny tracking.

As mentioned in Section 1, the approach exploits pro-cess mining techniques to extract a characterization of a mal-ware or trusted application from its system call traces. Theproduced characterizations can be profitably used to (i) re-cognize a malicious behavior at run-time, (ii) identify mal-ware variants within the same family, and (iii) identify simil-arities across malware families. Moreover, the study of mal-ware behaviour can be used to support malware phylogenyby building “family trees” based on a similarity metric betweenmalware characterizations.

The approach is based on two assumptions: (a) systemcall traces (or logs) captured from the execution of a mobileapplication can be used to characterize the application, in-cluding its malware behavior, if present; (b) system eventsreported in Table 2 and associated to the Android operat-

ing system represent the activation mechanism for maliciouscode present in Android mobile malware.

Starting from the above assumptions, the proposed ap-proach mines system call traces produced by an applicationin response to system events listed in Table 2 with the aim tofind recurring execution patterns and relationships betweensystem calls characterizing the application or malware beha-vior. Such information, represented as a Declare model [36]is named SEF - Syscalls Execution Fingerprint. SEFs can becompared with each other for malware detection and phylo-geny analysis.

In the rest of the section we describe i) the formal defin-ition of SEF, ii the malware detection process, and iii) theprocess to build a phylogeny model for a family of malware.

3.1 Formal definition and notation for a SEF

We introduce here the formal definitions for the SEF asso-ciated to a mobile application and that associated to a mal-ware family, and specify the notation we use to representboth models.

Definition 1 (Declare model): Let be:

– T a set of system call traces.– Cuh = {SA,R} a unary constraint specifying a condition

R, contained in Table 3, that holds for the occurrences ofsystem call SA over traces in T .

– Cbk = {SA,SE ,R} a binary constraint specifying a rela-tionship R, contained in Table 3, that holds between theoccurrences of system calls SA and SE over traces in T .

The Declare model associated to traces in T is defined asfollows:

D = {Cu1 , . . . ,Cuh ,Cb1 , . . . ,Cbk} �

as a set of h unary and k binary constraints with {h,k} ≥ 0.

Definition 2 (SEF of an application A): Let be:

– E = {e1, . . . , en} the set of all the possible system eventsthat can be sent to an application;

– tAe jthe execution trace (system calls trace) generated by

the application A, in response to the event e j;– DAe j

the Declare model mined from the set of traces{tAe j1

, . . . , tAe jr} where r is the number of runs of the ap-

plication A.

The SEFA of the application A is defined as follows:

SEFA = {DAe1, . . . ,DAen} �

Definition 3 (SEF of a malware family Mh): Let be:

– A = {a1, . . . , am} the set of all the applications infectedwith the malware family Mh;


Figure 1: Declare model of an insurance claim process.

t0

Perform medicalhistory check

Contacthospital

Perform medicalhistory check

Skipresponse

Notify byphone

Contacthospital

Skipresponse

Figure 2: An example trace log of the insurance claim process in Figure 1.

Figure 3: The automaton obtained from the constraint re-sponse(Perform medical history check, Contact hospital) forthe insurance claim process.

– E = {e1, . . . , en} the set of all the possible system eventsthat can be sent to an application;

– taie j the execution trace generated by the application aiin response to the event e j;

– DM j = the Declare model mined from the set of traces{ta1e j , . . ., tame j}

We define:

SEFMh = {DMe1, . . . ,DMen} �

3.2 Distance among SEFs

In order to define a distance among SEFs, we need to in-troduce a distance definition for Declare models. Given twoDeclare models Di and D j, the distance d(Di,D j) is definedas follows:

d(Di,D j) =α(|

⋃(Di,D j)|−|

⋂(Di,D j)|)

α(|⋃(Di,D j)|−|

⋂(Di,D j)|)+(1−α)(|

⋂(Di,D j)|)

where α ∈ (0.5,1) is a parameter that allows to weigh dif-ferently constraints presence with respect to absence whenevaluating the distance. When α = 0.5 constraints presenceand absence is equally weighted.

Hence, given two SEFs, SEFA and SEFB, we can definethe distance as follows:

d(SEFA,SEFB) =∑

ni=1 d(DAei

,DBei)

n

where n = |E| is the cardinality of considered system eventsset.

To evaluate the distance between the SEF of a malwarefamily and the SEF of a single application, the Declare rulesthat should be taken into account must be restricted to theset of rules that are present in the SEF of the malware. Thisis important since the SEF of a single application, even ifinfected with a malware, includes the behaviour of the ori-ginal application in addition to that of the malicious codeof the malware. The restriction step filters out, during dis-tance evaluation, declare constraints for which the SA and


SE activities are not present in the SEF model of the mal-ware.

3.3 Malware detection

Figure 4 depicts how malware detection is accomplished. Atthe core of the approach is the definition of SEF reported inSection 3.1.

SEFs are used to characterize the behavior of an applica-tion to be checked. The matrix of distances between the SEFof the application and the SEFs of known malware familiesis calculated. This matrix is then provided as input to ourmalware classifier which, as a final result, indicates if theapplication is infected with a malware of a known family.

The malware classifier is based on the Weka data miningtoolkit1 and adopts different algorithms to classify the dis-tances between the SEF of an application and the SEFs ofknown malware families.

Several classification algorithms are available in the lit-erature that have proved to be effective in performing theproposed classification [22]. As we will discuss in Section4, in this work six classification algorithms are used for gen-eralizing and strengthening the internal validity of the ob-tained results.

In the rest of this subsection we describe i) the process tocompute the SEF characterizing an application, ii) the pro-cess to compute the SEF characterizing a family of malware,iii) the process to build our malware classifier used for de-tection.

3.3.1 Computing of the SEF of an application

As more formally defined in Section 3.1, the SEF of an ap-plicatin (or APK2), is a collection of Declare models eachof which characterizes the behavior of the application in re-sponse to one of the system events listed in Table 2. Such be-havior is mined from syscall traces captured from the applic-ation in response to the specific system event. The processto compute the SEF associated to an application is depictedin Figure 5. The main steps of the process are the following:

– Syscall Traces Extraction. In this step syscalls traces gen-erated by the APK in correspondence to the system eventslisted in Table 2 are captured and stored in a textualformat. The APK is first installed and run on an An-droid device emulator prepared for the purpose. Then,a system event from the list in Table 2 is generated andsent to the emulator and the sequence of system callsmade by the APK (syscall trace) in correspondence isgathered. We recall that system events listed in Table 2

1 http://www.cs.waikato.ac.nz/ml/weka/2 APK is the file format for an Android executable application. So,

in the paper we use the term APK as a synonym of Android application.

are assumed to be the mechanism for a malware pay-load eventually present in an APK to get activated. Eachevent of the list is sent more than once in order to have anumber of syscall traces from which to extract by factor-ization the behavior (in terms of syscalls) associated toit. Each time an event is sent the APK is first reinstalledand run in order to reduce as much as possible the influ-ence of the APK state in the generated syscall trace. Thestep ends when the list of system events in Table 2 hasbeen fully scanned. The step is handled by a set of shellscripts that perform the following actions:

– start the target Android device emulator;– install the APK of the application on the device emu-

lator;– wait until a stable state of the device is reached (i.e.,

when epoll wait is executed and the application waitsfor user input or a system event to occur);

– start the capture of syscall traces;– select one of the activation system events in Table 2– send the selected event to the application;– capture syscalls made by the application until a stable

state is reached;– stop the syscall capture and save the captured syscall

trace;– reinstall the APK and repeat the capturing for the

selected event a fixed number of times (ten times inour evaluation);

– select a new system event and repeat the steps aboveto capture syscall traces for this event;

– repeat the step above until all system events in Table2 have been considered.

– stop the Android device and revert its disk to a cleanbaseline snapshot.

– XES-based Event Stream Generation. In this step syscalltraces collected and saved in textual format in the previ-ous step are converted into an eXtensible Event Stream(XES)-compliant log format [44], an XML-based stand-ard for event logs3.Syscall traces extracted from the operating system arein a textual format that needs to be cleaned, filtered andconverted to an XES event stream. This is accomplishedby the Strace2XES converter, a tool implemented as anEclipse application. During this conversion, only usefulinformation available in the trace is kept. This includesattributes associated to the entire trace (e.g., the id ofthe application from which the trace has been generated)and attributes associated to a single system call occur-rence (e.g., the executed system call, its time-stamp, alist of arguments, if present, and the id of the process re-questing the call). This information is useful during thefollowing constraint mining step of the process to cor-

3 Visit http://www.xes-standard.org/.


Figure 4: The malware detection approach in brief.

Figure 5: The process for computing the SEF for an application.

relate events and extract a Declare model from syscalltraces.For example, consider the trace t0 =< A,A,B,B > andthe constraint response(A,B): it is impossible to determ-ine which instance of the activity (syscall) B should be

associated to the two instances of the activity A. Suchambiguity prevents a correct evaluation of constraints interms of satisfaction/violation. For data correlation weadopted a reference-based correlation approach similarto the one proposed in [19]: two events correlates if they


satisfy a correlation function that depends on a set of at-tributes of the first event (the identifier attributes) and onset of attributes of the second event (the reference attrib-utes). In our context, identifier and reference attributesare the process identifier (pid) and the event time-stamp,respectively, and they coincide. The correlation functionrequires that the pids of the two events are equal whereasthe time-stamp of the second event is greater than thetime-stamp of the first one. This allows the mining al-gorithm to keep the identification of constraints separatefor each process execution of a given application andavoids the detection of fake rules mined from the wrongcorrelation of system call events belonging to differentprocesses.

– Syscalls Execution Fingerprints (SEF) Computation. Inthis step the SEF associated to the application providedas input to the process is computed. For each systemevent in Table 2 the associated XES logs are selected.The logs of each set are first processed in order to filterout useless ones, e.g., those shorter than a given threshold.Such logs are mined using the Declare Miner4, a pluginfor the ProM Process Mining Toolkit, in order to obtaina Declare model from them. The collection of the so ob-tained Declare models represents the SEF of the APKand the characterization that the approach uses for mal-ware detection. Each of the Declare models consists ofa set of constraint rules expressed in the Declare declar-ative language [36] that describe relationships betweensystem calls that hold in all the traces from which themodel was mined.

3.3.2 Computing of the SEF of a family of malware

As formally defined in Section 3.1, the SEF of a family ofmalware is a set of Declare models, each of which character-izes the behavior of the malware family in correspondence toone of the system events in Table 2. Each of these models ismined from a dataset of syscall traces generated from differ-ent applications infected with a considered malware familywhen ’stimulated’ with one of the system events reported inTable 2. Since each model contains the constraints amongsystem calls that hold in all the considered traces (no mat-ter of the application they were captured from), it can beregarded as a representation of the malicious payload beha-vior in correspondence to a particular system event of thelist. Indeed, the behavior of the malicious payload is expec-ted to be the only shared behavior among the variety of in-fected applications used to compute the SEF of the malwarefamily.

It is worth noting that, while the SEF of a malware fam-ily describes only the behavior of the malicious payload, the

4 http://www.win.tue.nl/declare/declare-miner/

SEF computed for an infected application will include con-straints deriving from both the application behavior and themalicious payload.

Figure 6 shows the process for computing the SEF asso-ciated to a malware family. The process looks similar to thatfor computing the SEF for a single application.

In this case the mined Declare model is derived from aset of different applications infected with the same malwarefamily. Each application of the set has only one part in com-mon with the others: the malware payload. This means thatsyscall traces derived from such applications share only thepart of the behavior associated to such malware payload. Asa consequence, the mining process generates a model thatretains the behavior of the malware payload (for which theDeclare constraints support tends to be high) and discardsthe one that is specific to each applications (for which theDeclare constraints support is very low). 5

The main steps of the process are the following:

– Extraction of Syscall Traces for the Malware Family. Inthis step, a sycall trace is collected for each of the APKin the dataset of APKs provided as input for each of thesystem event in Table 2. All the APKs in the dataset mustbe verified in advance to be infected with a malware ofthe family Mh under analysis. In detail this step is ex-ecuted in a similar way to the step described in Section3.3.1 for collecting syscall traces for an application, ex-cept that (i) it is repeated for several APKs, and (ii) foreach APK and each system event in Table 2 only onetrace is collected.

– XES-based Event Stream Generation. Similarly to whathappens in the process for computing the SEF of an ap-plication, in this step, syscall traces collected and savedin textual format in the previous step are filtered and con-verted into an XES-compliant log format.

– Syscalls Execution Fingerprint (SEF) construction XESlogs produced from the previous step groups togethersyscall traces associated to a given system event. Eachgroup of XES logs is parsed using the Declare Miner.The so generated Declare model consists of a set of con-straints expressed in the Declare language that describethe relationships between system calls that hold in all theanalyzed traces. As such, the model describes the com-mon behavior between the set of applications, which isexpected to be the behavior of the malicious code asso-ciated to the malware. The collection of Declare models

5 There are two notions of support that can be defined upon Declarelanguage: one based on the percentage of constraints activations thatleads to a fulfillment (called event-based constraint support) and theother based on the percentage of traces in which the constraint is sat-isfied (trace-based support). In our context we considered trace-basedsupport since we are interested in mining the behavior that is sharedby all the traces (having assumed that, for different applications, suchbehavior models the malicious payload).


Figure 6: The process for computing the SEF for a malware family.

associated to the different system events in Table 2 aredefined to be the SEF of the malware family. This modelrepresents a characterization of the behavior of the mal-ware family and hence is exploitable for detection andphylogeny tracking tasks.

3.3.3 Building of the malware classifier

Our malware classification is performed using a Weka datamining toolkit. In particular, Figure 7 shows the process fortraining it. SEFs are computed for a dataset of training APKs,for the all known malware families, and for a test set ofAPKs. Then the training process is started and repeated withan increased number of training APKs until the best valuespossible for precision and recall are obtained using the clas-sifier over the testing APKs. The training is accomplished

calculating the matrices of distances between the SEFs ofthe known malware families and the SEFs of the trainingAPKs and the testing APKs. Several classification algorithmsare used over these matrices.

3.4 Phylogeny tracking approach

The proposed approach for malware phylogeny tracking isreported in Figure 8. The approach is based on the computa-tion of a malware phylogeny model according to the follow-ing main activities:

– Compute SEFs of a set of malware families. This activ-ity shares the SEF construction process already shownin Section 6. In this case the built SEFs are used to eval-


Figure 7: Building of the Malware Classifier.

Figure 8: Malware phylogeny process.


uate a dissimilarity matrix to be used in the subsequentclustering step.

– Dissimilarity matrix evaluation. This activity takes asinput the SEF models for the set of malware familiesand constructs a symmetric dissimilarity matrix in whicheach entry i, j reports the dissimilarity between the SEFmodel of family i and that of family j. It is based uponthe distance definition given in 3.2.

– Clustering. The final activity is aimed to recover a phylo-geny model by applying the Hierarchical AgglomerativeClustering (HAC) algorithm described in [24] over thedissimilarity matrix computed in the previous step. Thisalgorithm is commonly used in phylogeny model con-struction for both malware and biologic phylogeny clas-sification and, in our context, provides very good resultswith the best trade-off with respect to performances. Theresulting phylogeny model, however, is unable to repres-ent multiple inheritances. This means that

4 Evaluation

The effectiveness and efficiency of the proposed approachhave been evaluated using a dataset of 1200 malicious andtrusted applications belonging to nine malware families. Theevaluation starts from the collected syscall traces structuredin three sets (training, test and trusted sets) as specified inthe process described in Section 3.

Table 4: THE MALWARE FAMILIES OF THE DATASET.

Family IT #DS #ASAdrd r 91 78DroidDream r 81 81DroidKungFu1 r 34 34DroidKungFu2 r 30 30DroidKungFu3 r 304 67DroidKungFu4 r 97 66Fakeinstaller s 925 101Kmin s 147 112Opfake r 613 428Trusted r 200 200

4.1 Dataset Construction

The dataset used to empirically evaluate our approach in-cludes malware and trusted applications that were collectedas follows. Malware applications characterized by differentnature and malicious intents (wiretapping, selling user in-formation, advertisement, spam, stealing user credentials,ransom) have been downloaded from both Genoma [53] andDrebin [8] datasets. Trusted applications in the dataset arethe most downloaded from Google Play store from July 2012

to September 20146 for different categories (call, contacts,education, entertainment, travel, internet, lifestyle, news, pro-ductivity, utilities, business, communication, messaging, fun,health and personalization). The quality of the applicationscomposing the dataset was verified with the VirusTotal ser-vice [1]. This service allows the user to run 57 antimal-ware (e.g., F-Secure, AVG, Avira, Avast, Kaspersky, Bit-Defender) on all the applications of the entire dataset. Themalware applications that are not recognized as maliciousfrom at least five antimalware have been filtered. The qual-ity analysis also confirmed that the trusted applications inthe dataset did not contain any malicious code.

The training set was used to generate the SEF modelfor each malware family. These families were obtained bygrouping malware applications sharing common character-istics (i.e., payload installation, type of attack, and set of sys-tem events that trigger the malicious payload [53]). The listof the malware families considered in this study is reportedin Table 4.

The test set is used to verify that the malicious applica-tions’ behavior of a given malware family is correctly rep-resented by the SEF model obtained from the training set.In particular, the correctness is verified by analyzing the dis-tribution of the distances between SEFs of applications be-longing to the same malware family of the model itself.

Table 4 provides some descriptive statistics on our evalu-ation dataset specifying for each of the considered malwarefamily the installation type (IT) (repackaging (r) or standalone (s)), the number of downloaded samples (#DS), andthe number of analyzed samples (#AS) recognized as mal-ware during the quality analysis.

Following the process described in Section 3, the detec-tion process is based on the evaluation and analysis of thedistributions of intra-family distances whereas the phylo-geny model construction requires an inter-family similar-ity analysis by comparing malware family models with eachother.

4.2 Intra-family distances distributions analysis

The distribution of intra-family distances for the familiesDroidKungFu1-2 and Geinimi and for the three most dis-criminating events is shown in Figure 10. The results high-light how the SEF model can be used as a fingerprint of themalicious behavior, effectively.

Looking at the figure, we can observe that for the de-scribed three events (BOOT COMPLETED, BATTERY LOWand INPUT MEDIA CHANGED), the SEF for DroidKungFu1and DroidKungFu2 is quite discriminating. Moreover, theboxplots show that for these events the median values of thedistance distributions are well discerned: the value is 0.2 for

6 These applications have been also checked by Google Bouncer[34]


Figure 9: The distances distributions among SEFs models for three malware families

the infected applications and 0.7 for the trusted applications.Even if the results on test applications are less consistentthan on trusted distances, the medians value never overlap.Looking at the Geinimi family, the BOOT and SMS eventsare shown to be discriminating. This result is also confirmedby the first two boxplots of the third column of the mat-rix represented in Figure 9. In this figure, the last boxplotsshow that for the SYS event nothing can be claimed sinceboth medians overlap and the distance between the test andtrusted models is close to the maximum.

Finally, the results obtained for the other analyzed fam-ilies are consistent and comparable, showing that they arewell discriminated by at least one system event. This can beobserved from the boxplots in Figure 13. This figure high-lights how different events show a different discriminatingpower (the figure shows only the most discriminating eventacross the considered families).

4.3 Inter-family similarity: distances among family models

In Figure 11, the dissimilarity matrices for the set of con-sidered families and the three most discriminating systemevents are reported. Each discriminating system event is usedto relate similar families based on their behavior, that is ex-pressed by the constraints among system calls executed inresponse to that event. The malware lineage can be determ-ined by the validation of the cluster recovered from the SEFdistance matrices using the malware discovery dates. Theclusters of the dissimilarity matrices of the discriminatingevents are obtained using the following weights:

wi, j =#discriminative events

#total eventsif the event j is discriminating for the family i, while wi, j = 0if it is not.

The most discriminating event is the BATT event.It is also interesting to observe that in response to the

BOOT event, the system calls execution relationships showthat DroidKungFu4 is more similar to DroidKungFu1 thanto DroidKungFu3. For what concerns the other families, theSEFs show that they are quite different (the agglomerativeclustering step puts them together behind the cut).


Figure 10: The distance distributions among SEFs for the DroidKungFu3 malware over six events

Figure 11: The dissimilarity matrices associated to each of the events of the considered SEFs and the resulting weighteddissimilarity matrix.

Figure 12 shows the dendrogram derived from the clus-tering step applied to the weighted dissimilarity matrix inFigure 11. The dendrogram indicates that the three most

discriminating events (BOOT COMPLETED, BATTERY -LOW and INPUT MEDIA CHANGED events) provide ef-fective results by grouping together all the variants of Droid-


t

Figure 12: The resulting classification dendrogram associated to the weighted dissimilarity matrix in Figure 11.

KungFu. Moreover, looking at the dendrogram, we can ob-serve that GinMaster and DroidDream are more similar interms of system calls execution relationships with respect toGeinimi, even if the values are not discriminating.

4.4 Classification Results

The classification has been performed using the 6 classi-fication algorithms listed in the second column of Table 5.Two kinds of classification are executed: the first is based ona single binary classifier discriminating malware and trus-ted applications; the second uses a binary classifier for eachfamily and identifies the particular family of a malicious ap-plication. The results obtained for these two kinds of clas-sification are summarized in Table 5. The first column ofthe table reports the malware family (including a single ”Allfamilies” classifier trained with malware samples from allthe families included in the dataset). The second column liststhe adopted classification algorithms for each family, whilethe four remaining columns report the classification results.The quality of the classification is evaluated by calculatingprecision (column three) and recall (column four) based onthe following definitions.

Let be:

– TP: # of true positives (# of correctly classified occur-rences, i.e., applications classified as malware, being ac-tually malware),

– FP: # of false positives (# of incorrectly classified oc-currences, i.e., applications classified as malware, whilethey are trusted),

– FN : # of false negatives (# of not classified occurrences,i.e., applications classified as trusted, while they are mal-ware).

Precision is defined as the ratio of correctly classified occur-rences to all occurrences provided by the algorithms and isgiven by:

Precision = TPTP+FP

Recall is the ratio of correctly classified occurrences to allcorrect occurrences and is given by:

Recall = TPTP+FN

The Gold Standard (GS) used as reference is the set ofall correctly classified occurrences. Finally, the ROC Area(column five) is evaluated. It is the area under the ROCcurve (AUC) and is defined as the probability that a ran-domly chosen positive occurrence is ranked above a ran-domly chosen negative one.

Observing the first row of the table related to a ”catch-all” classifier for All families, Precision and Recall valuesare 0.903 and 0.938 (with the NBTree algorithm), respect-ively. The table also highlights that there is at least one clas-sification algorithm for each considered malware family giv-ing values of Precision and Recall greater than 0.85. Moreover,the ROC value shows that the probability of scoring malwareapplications higher than trusted ones is 0.9 (with the NBTreealgorithm) and for all the malware families there is at leastone classification algorithm resulting in a ROC value greaterthan 0.88.

The obtained results are very promising if compared tosimilar approaches available in the literature (we discusssome of them in Section 7). Moreover, our approach is bet-ter suited to perform malware family identification. This isdiscussed in Section 5.

5 Robustness Analysis

In order to demonstrate the effectiveness of our method inmalware identification, we applied a set of well-known code


Figure 13: The distance distributions among SEFs according to the most discriminating system event for each family.

transformations techniques [14,38,50] to the applications inour dataset. Such techniques are used by malware writers toevade the signature-based detection approaches adopted bycurrent antimalware.

In particular, in our experiment we used the followingcode transformation techniques:

1. Disassembling & Reassembling. The compiled DalvikBytecode in classes.dex of the application package maybe disassembled and reassembled through apktool. Thisallows various items in a .dex file to be represented inanother manner. In this way, signatures relying on theorder of different items in the .dex file are likely to beineffective with this transformation.

2. Repacking. Every Android application has a developersignature key that will be lost after disassembling andreassembling the application. Using the signapk7 tool,it is possible to embed a new default signature key inthe reassembled application in order to avoid detectionsignatures that match the developer keys.

3. Changing package name. Each application is identifiedby a unique package name. The aim of this transforma-tion is to rename the application package name in both

7 https://code.google.com/p/signapk/

the Android Manifest file and all the classes of the ap-plication.

4. Identifier renaming. This transformation renames eachpackage name and class name by using a random stringgenerator, in both the Android Manifest file and smaliclasses, handling renamed classes invocations.

5. Data Encoding. Strings could be used to create detec-tion signatures to identify malware. To elude such signa-tures, this transformation encodes strings with a Caesarcipher. The original string is restored during applicationexecution with a call to a smali method that knows theCaesar key.

6. Call indirections. Some detection signatures could ex-ploit the call graph of the application. To evade such sig-natures, a transformation is designed to mutate the ori-ginal call graph of the application by modifying everymethod invocation in the smali code with a call to a newmethod inserted by the transformation which simply in-vokes the original method.

7. Code Reordering. This transformation is aimed at modi-fying the instructions order in smali methods. A randomreordering of instructions has been accomplished by in-serting goto instructions with the aim of preserving theoriginal run-time execution trace.


% ROC Areadecrease in

Family Algorithm Precision Recall ROC Area transformed appsJ48 0.819 0.979 0.809 2.05HoeffdingTree 0.944 0,861 0.894 1.44

All families NBTree 0.903 0.938 0.9 1.01RandomForest 0.872 0.928 0.883 0.67RandomTree 0.915 0.89 0.867 1.23RepTree 0.832 0.966 0.854 1.27J48 0.902 0.648 0.762 2.47HoeffdingTree 0.899 0.873 0.887 0.78

Adrd NBTree 0.877 0.704 0.818 1.39RandomForest 0.955 0.296 0.824 2.84RandomTree 0.868 0.465 0.617 9.54RepTree 0.877 0.704 0.799 2.7J48 0.965 0.696 0.769 2.53HoeffdingTree 0.798 0.949 0.956 2.88

DroidDream NBTree 0.938 0.949 0.96 1.8RandomForest 1 0.38 0.869 2.61RandomTree 0.956 0.544 0.608 8.99RepTree 0.982 0.709 0.81 0.51J48 1 0.688 0.846 4.85HoeffdingTree 0.595 0.781 0.839 1.18

DroidKungFu1 NBTree 0.926 0.781 0.917 1.24RandomForest 0.919 0.990 0.871 3.1RandomTree 0.88 0.688 0.842 0.34RepTree 0.96 0.75 0.857 2.52J48 0.923 0.75 0.949 4.14HoeffdingTree 0.925 0.835 0.844 1.73




FakeInstaller NBTree 0.831 0.9 0.935 1.3RandomForest 0.93 0.667 0.93 1.97RandomTree 0.914 0.533 0.817 8.87RepTree 0.758 0.833 0.868 0.63J48 0.968 0.741 0.866 4.01HoeffdingTree 0.971 0.827 0.911 1.21

Kmin NBTree 0.946 0.864 0.913 1.74RandomForest 0.961 0.914 0.959 1.01RandomTree 0.938 0.926 0.966 2.93RepTree 0.955 0.79 0.893 1.05J48 0.797 0.953 0.861 3.44HoeffdingTree 0.909 0.943 0.882 1.95

Opfake NBTree 0.908 0.933 0.913 1.63RandomForest 0.834 0.966 0.917 1.83RandomTree 0.833 0.939 0.895 2.48RepTree 0.821 0.939 0.897 2.87

Table 5: Classification results: Precision, Recall and RocArea for classifying Malware samples and families computed withdifferent algorithms.


8. Defunct Methods. This transformation adds new meth-ods that perform defunct functions to smali code, whilenot changing the logic of the original source code.

9. Junk Code Insertion. These transformations introducethose code sequences that have no effect on the functionof the code. Detection algorithms relying on instructions(or opcodes) sequences may be defeated by this type oftransformations. This type of transformations providesthree different junk code insertions: (i) insertion of nopinstructions into each method, (ii) insertion of uncon-ditional jumps into each method, and (iii) allocation ofthree additional registers on which garbage operationsare performed.

10. Encrypting Payloads and Native Exploits. In Android,native code is usually made available as libraries ac-cessed via JNI. However, some malware, such as Droid-Dream, also pack native code exploits meant to run froma command line in non-standard locations in the applic-ation package. All such files may be stored encrypted inthe application package and be decrypted at run-time.Certain malware such as DroidDream also carry pay-load applications that are installed once the system hasbeen compromised. These payloads may also be storedencrypted. Payloads are categorized and encryption asDSA is exploited because signature based static detec-tion is still possible based on the main application’s byte-code. These are easily implemented and have been ob-served in practice as well (e.g., DroidKungFu malwareuses encrypted exploit).

11. Function Outlining and Inlining. In function outlining,a function is broken down into several smaller functions.Function inlining involves replacing a function call withthe entire function body. These are typical compiler op-timization techniques. However, outlining and inliningcan also be used for call graph obfuscation.

12. Reflection. This transformation converts any methodcall into a call to that method via reflection. This makesit difficult to statically analyze which method is beingcalled. A subsequent encryption of the method name canmake it impossible for any static analysis to recover thecall.

5.1 Dataset construction for robustness analysis

We apply the full transformation set to our samples with theDroidchameleon [38] and the ADAM [50] tools. Further-more, we use an obfuscation engine8 able to inject six differ-ent obfuscation techniques in Android applications. Table 6shows the obfuscation techniques implemented by the threetools.

8 https://github.com/faber03/AndroidMalwareEvaluatingTools

We combined together all the transformations providedby the three tools in order to generate a stronger obfusca-tion. From the test set used in Section 4 a transformed set isderived by applying the code transformations. A validationstep is executed also on the transformed set to assess theloss of quality of the resulting classifier. Figure 9 reports thedistances distributions among SEFs models, including thetransformed set. The comparisons between distances distri-butions of the test sets highlights a small deterioration inthe distribution parameters of the transformed ones. This issomething expected. However, the deterioration in almostall the cases consists of a small increase of the inter-quartilerange for transformed applications with respect to test ap-plications that never causes overlapping of median valueswith trusted applications. This means that the mined SEFmodels should maintain the same discriminative propertiesassessed with the test applications. Looking at the boxplotsfor the transformed set, we can see that in most cases thethird quartile is more stable than the first one across bothevents and families. This means that the transformed SEFmodels have distances, with respect to family models, thatare grater if compared to test models, but still lower thanthe first quartile of the trusted models. The transformed sethas been exploited to validate the classifier built with theoriginal training set and the detection quality has been eval-uated in order to assess the robustness of the approach withrespect to code transformations.

5.2 Discussion of Results

The results of the family classifiers reported in Table 5 in-clude in the last column the percentage decrease of the ROCArea (of each classifier) for the transformed applications.The decrease ranges between 0.34% to 11.5%, dependingon the malware family and the classification algorithm, buton average, it is equal to 2.6%. Classifying the ROC Area infour ranges:

– [0.5,0.7) as Poor– [0.7,0.8) as Fair– [0.8,0.9) as Good– [0.9,1.0) as Excellent

it is important to estimate how many classifiers change theirclass passing from test apps to transformed ones. The firstinteresting thing to observe is that the worst decreases relateto classifiers that were already performing poorly: they werealready Poor with test set and they remain Poor. This is con-firmed as a trend across all classifiers since decreases arehigher for classifiers that have worse performances (lowerROC Area). This can be seen looking at the Figure 14 thatshows a direct comparison between the ROC area for testand transformed applications (Plain and Transformed bars).As it can be easily observed from the bar graphic, most of


Table 6: Comparison between the transformation techniques implemented in the three tools.

Transformation Obfuscation engine DroidChamelon ADAMDissassembling X X XRepacking X X XChanging package name X XIdentifier renaming X XData Encoding X XCall indirections X XCode Reordering X XDefunct Methods. XJunk Code Insertion X XEncrypting Payloads XFunction Outlining XReflection X

Figure 14: Area under ROC curve variation between plain and transformed malware.

the decreases are in correspondence with the lowest ”Plain”values.

To summarize, our analysis shows that out of the total60 classifiers (9 malware families classifiers plus a single”catch-all” classifier multiplied by 6 learning algorithms)9 went from Excellent to Good and 3 from Good to Fair.The other classifiers (48) remain in the same class in whichthey belonged (27 Good, 15 Excellent, 4 Fair e 2 Poor).These are very good results confirming that the approach isquite insensitive to code transformation techniques since itis based on a fingerprint of the application and malware be-havior, which is left unchanged by behavior-preserving codetransformations. More investigation could be performed onthe individual learning algorithm sensitivity in order to re-veal why we obtained the worst results for two specific al-gorithms: J48 (3.4%) and RandomTree (6.6%).

6 Threats to validity

The construct validity analysis showed that the syscall tracesextraction could be imprecise in some circumstances. Thisis due to the trace capturing script that allows to starts thecapturing of the trace when an operating system events isoccurred (it is sent by the sandbox to the application) andstops to capture the trace every time a new stable state isreached. The source of imprecision lies in the trace auto-matic cut which does not take into account what happens tothe application during the capturing time. This entails thatsome incomplete traces could be captured and should be dis-carded from the set: for example, if an application is shutdown due to an illegal behavior, an incomplete trace is cap-tured. This issue was revealed performing outliers analysisand allowed to improve the approach introducing a trace val-idation step that is able to filter out incorrect traces from thedataset.


Another construct validity threat lies in the way the data-set, described in Section 3, is obtained. It is assumed thatthe considered applications are malicious basing on the re-sponse of some anti-virus software that do not provide anyassurance. To reduce mistakes, a combination of several anti-malware is adopted for the quality verification step and theapplication is considered as infected if the infection is re-cognized by at least five different anti-malware.

For what concerns the external validity threats and thegeneralization of our findings, our evaluation validates theapproach implementation on more than 2500 applicationsof 9 malware families. Even if this allows to obtain statistic-ally significant results, an extension of these results to moremalware families and to a larger set of applications is stilldesirable.

7 Related Work

7.1 Malware detection

Several studies about malware detection have been presen-ted in the last years. They differ from each other for thefeatures (or characterization) used to discriminate betweenmalware and non malware applications. These features canbe obtained with static or dynamic analysis techniques.

7.1.1 Static Methods

Static Methods capture suspicious patterns from the codeor artifacts related to code (i.e., meta information) and con-sist in analyzing malicious software without executing it.Some common patterns used in static analysis include stringsignature, byte-sequence n-grams, control flow graph, syn-tactic library call, operational code frequency distribution.An approach which considers control flow has been pro-posed in [41]. It is based on AndroGuard [2], a tool thatstarting from the extraction of mobile applications featuresallows to train a one-class Support Vector Machine and toextract permissions and control flow graphs from packagedAndroid applications. This method has been tested on a col-lection of 2081 trusted applications and 91 malicious ones.The results show a very low false negative rate but also anhigh false positive one. In [18], the control flow to detect ap-plication communication vulnerabilities is also considered.In this study, ComDroid, a tool to examine inter-applicationcommunication in Android, is proposed. The tool is appliedto analyze 20 applications founding 34 exploitable vulnerab-ilities (12 of the 20 analyzed applications have at least onevulnerability). The authors presented also several classes ofpotential attacks on mobile applications: outgoing commu-nication can put an application at risk of Broadcast theft(including eavesdropping and denial of service), data theft,

result modification, and Activity and Service hijacking. In-coming communication can put an application at risk of ma-licious Activity and Service launches and Broadcast injec-tion. Recently, the possibility of identifying the maliciouspayload in Android malware using a model checking basedapproach has been explored in [9,32,33]. Starting from pay-load behavior definition, the authors formulate logic rulesand then test them by using a real world dataset composedof Ransomware, DroidKungFu, Opfake families and updateattack samples. Several alternative techniques, consideringother features derived from static analysis, have been re-cently investigated. For example, in [51], a signature basedanalytic system for Android malware automatic management,collection, analysis and extraction, is proposed. The approachis supported by a tool, called DroidAnalytics, that works atopcode level. In the testing phase DroidAnalytics success-fully determines 2475 Android malware from 102 differentfamilies with 327 of them being zero-day malware samplesbelonging to six different families from a dataset of 150368Android applications. They also proposed a methodology todetect zero-day malware that allowed them to discover threenew malware families: AisRs (with 77 samples), AIProvider(with 51 samples) and G3app (with 81 samples). All familiesdiscovered are repackaged samples from legitimate applica-tions. Starting from the consideration that mobile malwareis usually employed to gather sensitive information fromdevice, authors in [20] propose a compiler to uncover usageof phone identifiers and locations. Here, a large set of An-droid applications collected from the market are analyzed toidentify a set of dataflow, structure, and semantic patterns.

DroidMOSS [52] adopts a fuzzy hashing technique toeffectively localize and detect possible changes from apprepackaging. The app similarity measurement system de-veloped by authors shows that a range from 5% to 13% ofapp hosted on several third-party marketplaces and the of-ficial Android Market are repackaged. In addiction to this200 samples from each third-party marketplace are analyzes.Moreover, authors detect whether the application are repack-aged from some official Android Market apps. From thestudy of the static approaches, we can conclude that theyusually transform the application binaries into uniquely selfcompressed unstructured binary files. Therefore, even trivialobfuscation techniques (for example, junk code insertion orcode reordering) can be used to evade the detection tech-niques of this type of antimalware. The limits of the staticapproaches are overcome by dynamic detection approaches,which are usually more robust with respect to the code ob-fuscation techniques currently employed by malware developers.

7.1.2 Dynamic Methods

Dynamic methods observe the behavior of a malicious ap-plication while it is being executed in a controlled environ-ment (virtual machine, emulator, sandbox etc.) or using a


real device. These methods are more effective respect to thestatic ones and do not require the executable to be disas-sembled. There are several studies proposing malware de-tection techniques based on dynamic analysis of mobile ap-plications and some of them are focused on the analysis ofsystem calls [13, 15, 23, 26, 40, 42, 43]. In [13], a method fordetecting mobile malware is proposed. The method is basedon three metrics respectively evaluating the i) occurrencesof a reduced subset of system calls; ii) the weighted sum ofa subset of permissions which the application requires andiii) the set of combinations of permissions. The experiment-ation considers a sample of 200 real world malicious appsand 200 real world trusted apps and produced a precision of74%. Another approach to the malware detection based onthe system calls analysis in proposed by CopperDroid [40].Authors customize the Android emulator to track syscalls.Similarly, in [47] the authors use an emulator to analyze sy-scalls. The method was validated on a set of 1600 maliciousapps, and was able to find the 60% of the malicious apps be-longing to one sample (the Genoma Project) and the 73% ofthe malicious apps included in the second sample (the Con-tagio dataset). Also in [26] system calls used to read/writeoperations on files are checked in order to detect maliciousbehavior. The authors used a customized kernel on a realdevice, and the sample included 2 malicious applications de-veloped by the authors.

In [43] the response of an application is characterizedbasing on a subset of system calls generated from bad activ-ities in background that are activated by user interfaces events.The experimentation is based on the use of an Android emu-lator and included 2 malicious samples of the DroidDreamfamily. An approach aiming at detecting anomalies in theAndroid system is also proposed in [42]. Here the authorsuse the view from Linux-kernel such as network traffic, sys-tem calls, and file system logs. In [23], a method based onthe analysis of an application log and of a set of system callsrelated to management of file, I/O and processes is intro-duced. The approach consists in the use of a physical device,with an Android 2.1 based modified ROM image. The evalu-ation phase considers 230 applications in greater part down-loaded from Google Play and the method detects 37 applic-ations which steal some kinds of personal sensitive data, 14applications which execute exploit code and 13 destructiveapplications.

DroidScope [49] uses a customized Android kernel toreconstruct semantic views with the aim to collect detailedapplications execution traces. The obtained detection rate isof 100%, but it is evaluated only on two Android maliciousapplications.

Authors in [48] propose an Android malware detectionmechanism which is based on feature-network, like incom-ing and outgoing information.

Arora et al. [7] analyze the network traffic features build-ing a rule-based classifier to detect Android malware. Theirexperimental results suggest that the approach is accurateand it detects more than 90% of the traffic samples. Thework is focused only on Android malware which is remotelycontrolled or leaks information to some remote server, for atotal of 27 different families.

In [16] a method for detecting Android malware is presen-ted. The method is based on the analysis of system calls se-quences and is tested obtaining an accuracy of 97% in mo-bile malware identification. They use machine learning toautomatically learn 1, 2 and 3-gram from syscall traces.

Looking at the dynamic malware detection methods (someof which have been summarized above), some weakness canbe highlighted. The first limitation is that dynamic analysisis time intensive and resource consuming, thus elevating thescalability issues. The virtual environment in which mobilemalware is executed is different from the real one and themalware may perform in different ways resulting in artificialbehavior rather than the exact one. In addition to this, mo-bile malware behavior is triggered only under certain con-ditions (i.e., on specific events in case of Android platform)and can’t be detected in virtual environment. Moreover allthe discussed methods (with the exception of the one in ref-erence [16]) require to recompile the kernel.

7.2 Malware phylogeny

Several studies are focused on the topic of malware phylo-geny. As an example, in [28] a method to realize phylogenymodels is introduced. In this method some features, calledn-perms, are used to match possibly permuted code and al-low to obtain a malware tree. Looking to the obtained mal-ware tree authors suppose that phylogeny models based onn-perms may support the identification of new malware vari-ants and the reconciling of inconsistencies in malware nam-ing. Compared with our proposed approach, this method isstatic and hence does not require malware execution. Moreover,with respect to the proposed approach, this method is lessrobust to code modifications that cannot be represented aspermutations.

Moreover, in [46] a framework defining malware evolu-tion relations in terms of path patterns on derivation graphsis proposed. The limitation of this approach is that the model’sdefinition of source code excludes machine generated code.This is very restrictive considering that usually maliciouscode is automatically generated from the existing maliciousapplications.

Another approach allowing to find similarities and dif-ferences between malware variants and strains is proposedin [17]. It uses some clustering algorithms to obtain a tax-onomy of the malware at hand. Unfortunately, in there isn’tany comment about the sufficiency of the adopted dataset


and a formal comparison to a reference phylogeny is missed.In [30], a data-centric approach based on packets inspectionsaiming to automatically identify and quantify the shellcodesimilarity, is proposed. This approach is used to create ashellcode phylogeny for a given vulnerability and differsfrom ours because it is mainly based on a behavior ana-lysis. Researchers in [29] collect logs derived from instruc-tions executed, memory and register modifications in orderto build the phylogenetic tree. In addition, they show thatnetwork resources were more useful for visualizing shortnop-equivalent code metamorphism than trees. They con-sider execution trace of alternating APIs and user proced-ures, while in our method we consider system calls trace,that are not affected by API version. In [6], a dynamic andstatic analysis approach based on a multiple kernel learn-ing to define a new malware classification is proposed. Thisframework places a similarity metric in some different viewadopting a kernel. Moreover, it employs the multiple kernellearning to discover a weighted combination of data sourcesachieving the best classification accuracy in a support vectormachine classifier. This approach cannot be directly com-pared to our one since it proposes a framework to improveclassification accuracy rather than a detection approach. How-ever, it can be effectively integrated with our approach inorder to obtain better results.

8 Conclusions

In this paper we proposed an approach for dynamic mal-ware detection and malware phylogeny tracking based onprocess mining techniques. It extracts a declarative model,named SEF, from system calls traces of malware and trustedapplications, which represents a fingerprint of their respect-ive dynamic behavior. Based on the distances between themined SEF models, similarities across malware families areidentified and several malware variants are characterized.

In terms of malware detection, the approach has beenevaluated on a dataset of more than 1200 infected applic-ations across 9 malware families. The obtained results areencouraging and show that the approach is effective in de-tecting malware, thanks to the capability of the SEF modelsto adequately represent malware behaviors.

In order to assess the effectiveness and the efficiencyof the approach in phylogeny tracking, we applied it to thesame dataset of applications. The results show the capabil-ity to effectively discriminate the 9 studied malware familiesand recognize variants of the same family of malware.

Finally, a robustness analysis against most common codeobfuscation techniques has been performed with the samedataset of applications. In this study, SEF models have shownto be quite insensitive to behavioral-preserving code trans-formations techniques. As a consequence, the proposed mal-ware detection and phylogeny tracking approach signific-

antly reduce false negatives in presence of obfuscated mal-ware and variants of malware families.

Acknowledgements

This work has been partially supported by H2020 EU-fundedprojects NeCS and C3ISP and EIT-Digital Project HII.

References

1. Virustotal. https://www.virustotal.com/, last visit 1 March2016.

2. Androguard. https://code.google.com/p/androguard/,,last visit 24 November 2014.

3. Gartner. http://www.gartner.com/newsroom/id/2944819,last visit 26 February 2016.

4. Mobile threat report. https://www.f-secure.com/documents/996508/1030743/Threat_Report_H1_2014.pdf,last visit 26 February 2016.

5. Smartphone os market share, q3 2014. http://www.idc.com/prodserv/smartphone-os-market-share.jsp, last visit26 February 2016.

6. Blake Anderson, Curtis Storlie, and Terran Lane. Improving mal-ware classification: Bridging the static/dynamic gap. In Proceed-ings of the 5th ACM Workshop on Security and Artificial Intelli-gence, AISec ’12, pages 3–14, New York, NY, USA, 2012. ACM.

7. A. Arora, S. Garg, and S. K. Peddoju. Malware detection us-ing network traffic analysis in android based mobile devices. InNext Generation Mobile Apps, Services and Technologies (NG-MAST), 2014 Eighth International Conference on, pages 66–71,Sept 2014.

8. Daniel Arp, Michael Spreitzenbarth, Malte Huebner, Hugo Gas-con, and Konrad Rieck. Drebin: Efficient and explainable de-tection of android malware in your pocket. In Proceedings of21th Annual Network and Distributed System Security Symposium(NDSS), 2014.

9. Pasquale Battista, Francesco Mercaldo, Vittoria Nardone, Anton-ella Santone, and CA Visaggio. Identification of android malwarefamilies with model checking. In International Conference on In-formation Systems Security and Privacy. SCITEPRESS, 2016.

10. M. L. Bernardi, M. Cimitile, G. A. Di Lucca, and F. M. Maggi.Using declarative workflow languages to develop process-centricweb applications. In 16th IEEE International Enterprise Dis-tributed Object Computing Conference Workshops, EDOC Work-shops, Beijing, China, September 10-14, 2012, pages 56–65, 2012.

11. M. L. Bernardi, Marta Cimitile, Francesco Mercaldo, and Dami-ano Distante. A constraint-driven approach for dynamic malwaredetection. In 14th IEEE Annual Conference on Privacy Securityand Trust, 2016.

12. Andrea Burattin, Marta Cimitile, Fabrizio Maria Maggi, andAlessandro Sperduti. Online discovery of declarative processmodels from event streams. IEEE T. Services Computing,8(6):833–846, 2015.

13. G. Canfora, F. Mercaldo, and C. A. Visaggio. A classifier of ma-licious android applications. In Availability, Reliability and Se-curity (ARES), 2013 Eighth International Conference on, pages607–614, Sept 2013.

14. Gerardo Canfora, Andrea Di Sorbo, Francesco Mercaldo, and Cor-rado Aaron Visaggio. Obfuscation techniques against signature-based detection: a case study. In 2015 Mobile Systems Technolo-gies Workshop (MST), pages 21–26. IEEE, 2015.

15. Gerardo Canfora, Eric Medvet, Francesco Mercaldo, and Cor-rado Aaron Visaggio. Availability, Reliability, and Security in In-formation Systems: IFIP WG 8.4, 8.9, TC 5 International Cross-Domain Conference, CD-ARES 2014 and 4th International Work-shop on Security and Cognitive Informatics for Homeland De-fense, SeCIHD 2014, Fribourg, Switzerland, September 8-12,


2014. Proceedings, chapter Detection of Malicious Web PagesUsing System Calls Sequences, pages 226–238. Springer Inter-national Publishing, Cham, 2014.

16. Gerardo Canfora, Eric Medvet, Francesco Mercaldo, and Cor-rado Aaron Visaggio. Detecting android malware using sequencesof system calls. In Proceedings of the 3rd International Workshopon Software Development Lifecycle for Mobile, DeMobile 2015,pages 13–20, New York, NY, USA, 2015. ACM.

17. Ero Carrera and Gergely Erdelyi. Digital genome mapping–advanced binary malware analysis. In Virus bulletin conference,volume 11, 2004.

18. Erika Chin, Adrienne Porter Felt, Kate Greenwood, and DavidWagner. Analyzing inter-application communication in android.In Proceedings of the 9th International Conference on Mobile Sys-tems, Applications, and Services, MobiSys ’11, pages 239–252,New York, NY, USA, 2011. ACM.

19. Florian Daniel, Jianmin Wang, and Barbara Weber, editors. Busi-ness Process Management: 11th International Conference, BPM2013, Beijing, China, August 26-30, 2013. Proceedings, Berlin,Heidelberg, 2013. Springer Berlin Heidelberg.

20. William Enck, Damien Octeau, Patrick McDaniel, and SwaratChaudhuri. A study of android application security. In Proceed-ings of the 20th USENIX Conference on Security, SEC’11, pages21–21, Berkeley, CA, USA, 2011. USENIX Association.

21. Matthew Hayes, Andrew Walenstein, and Arun Lakhotia. Evalu-ation of malware phylogeny modelling systems using automatedvariant generation. Journal in Computer Virology, 5(4):335–343,2008.

22. G. Holmes, A. Donkin, and I.H. Witten. Weka: A machine learn-ing workbench. In Proceedings of the Second Australia and NewZealand Conference on Intelligent Information Systems, pages357–361. Citeseer, 1994.

23. Takamasa Isohara, Keisuke Takemori, and Ayumu Kubota.Kernel-based behavior analysis for android malware detection.In Proceedings of the 2011 Seventh International Conference onComputational Intelligence and Security, CIS ’11, pages 1011–1015, Washington, DC, USA, 2011. IEEE Computer Society.

24. A. K. Jain, M. N. Murty, and P. J. Flynn. Data clustering: A review.ACM Comput. Surv., 31(3):264–323, September 1999.

25. Jiyong Jang, David Brumley, and Shobha Venkataraman. Bit-shred: Feature hashing malware for scalable triage and semanticanalysis. In Proceedings of the 18th ACM Conference on Com-puter and Communications Security, CCS ’11, pages 309–320,New York, NY, USA, 2011. ACM.

26. Youn-sik Jeong, Hwan-taek Lee, Seong-je Cho, Sangchul Han,and Minkyu Park. A kernel-based monitoring approach for ana-lyzing malicious behavior on android. In Proceedings of the 29thAnnual ACM Symposium on Applied Computing, SAC ’14, pages1737–1738, New York, NY, USA, 2014. ACM.

27. Xuxian Jiang and Yajin Zhou. Android Malware. Springer Pub-lishing Company, Incorporated, 2013.

28. Md Enamul Karim, Andrew Walenstein, Arun Lakhotia, andLaxmi Parida. Malware phylogeny generation using permutationsof code. Journal in Computer Virology, 1(1-2):13–23, 2005.

29. Wei Ming Khoo and Pietro Lio. Unity in diversity: Phylogenetic-inspired techniques for reverse engineering and detection of mal-ware families. In SysSec Workshop (SysSec), 2011 First, pages3–10. IEEE, 2011.

30. Justin Ma, John Dunagan, Helen J. Wang, Stefan Savage, andGeoffrey M. Voelker. Finding diversity in remote code injectionexploits. In Proceedings of the 6th ACM SIGCOMM Conferenceon Internet Measurement, IMC ’06, pages 53–64, New York, NY,USA, 2006. ACM.

31. Francesco Mercaldo Mario Luca Bernardi, Marta Cimitile. Pro-cess mining meets malware evolution: a study of the behavior ofmalicious code. In 2015 Fourth International Symposium on Com-puting and Networking (CANDAR), December 2016.

32. Francesco Mercaldo, Vittoria Nardone, Antonella Santone, andCorrado Aaron Visaggio. Download malware? No, thanks. Howformal methods can block update attacks. In Proceedings of the

4th FME Workshop on Formal Methods in Software Engineering,pages 22–28. ACM, 2016.

33. Francesco Mercaldo, Vittoria Nardone, Antonella Santone, andCorrado Aaron Visaggio. Ransomware steals your phone. formalmethods rescue it. In International Conference on Formal Tech-niques for Distributed Objects, Components, and Systems, pages212–221. Springer, 2016.

34. J. Oberheide and C. Mille. Dissecting the android bouncer. InSummerCon, 2012.

35. M. Pesic. Process mining in the large: preprocessing discovery,and diagnostics. PhD thesis, Ph.D thesis at Eindhoven Universityof Technology, 2012.

36. M. Pesic, H. Schonenberg, and W. M. P. van der Aalst. Declare:Full support for loosely-structured processes. In EDOC 2007,pages 287–300, 2007.

37. Vaibhav Rastogi, Yan Chen, and Xuxian Jiang. Droidchameleon:Evaluating android anti-malware against transformation attacks.In Proceedings of the 8th ACM SIGSAC Symposium on Inform-ation, Computer and Communications Security, ASIA CCS ’13,pages 329–334, New York, NY, USA, 2013. ACM.

38. Vaibhav Rastogi, Yan Chen, and Xuxian Jiang. Droidchameleon:evaluating android anti-malware against transformation attacks. InProceedings of the 8th ACM SIGSAC symposium on Information,computer and communications security, pages 329–334. ACM,2013.

39. Vaibhav Rastogi, Yan Chen, and Xuxian Jiang. Catch me if youcan: Evaluating android anti-malware against transformation at-tacks. IEEE Transactions on Information Forensics and Security,9(1):99–108, 2014.

40. A. Reina, A. Fattori, and L. Cavallaro. A system call-centric ana-lysis and stimulation technique to automatically reconstruct an-droid malware behaviors. In Proceedings of EuroSec, 2013.

41. J. Sahs and L. Khan. A machine learning approach to android mal-ware detection. proceedings of the european intelligence and se-curity informatics conference. In Proceedings of of the EuropeanIntelligence and Security Informatics Conference, 2012.

42. A.-D. Schmidt, H.-G. Schmidt, J. Clausen, K. A. Yuksel, O. Kiraz,A. Camtepe, and S. Albayrak. Enhancing security of linux-basedandroid devices. In Proceedings of 15th International Linux Kon-gress, 2008.

43. F. Tchakounte and P. Dayang. System calls analysis of malwareson android. In International Journal of Science and Tecnology(IJST) Volume, 2 No. 9, 2013.

44. W. van der Aalst. Process Mining: Discovery, Conformance andEnhancement of Business Processes. Springer Berlin Heidelberg,2011.

45. B. F. van Dongen, A. K. A. de Medeiros, H. M. W. Verbeek, A. J.M. M. Weijters, and W. M. P. van der Aalst. The prom frame-work: A new era in process mining tool support. In Proceedings ofthe 26th International Conference on Applications and Theory ofPetri Nets, ICATPN’05, pages 444–454, Berlin, Heidelberg, 2005.Springer-Verlag.

46. A. Walenstein and A. Lakhotia. A transformation-based model ofmalware derivation. In Malicious and Unwanted Software (MAL-WARE), 2012 7th International Conference on, pages 17–25, Oct2012.

47. Xinran Wang, Yoon-Chan Jhi, Sencun Zhu, and Peng Liu. Detect-ing software theft via system call based birthmarks. In Proceed-ings of the 2009 Annual Computer Security Applications Confer-ence, ACSAC ’09, pages 149–158, Washington, DC, USA, 2009.IEEE Computer Society.

48. Te-En Wei, Ching-Hao Mao, Albert B. Jeng, Hahn-Ming Lee,Horng-Tzer Wang, and Dong-Jie Wu. Android malware detectionvia a latent network behavior analysis. In Proceedings of the 2012IEEE 11th International Conference on Trust, Security and Pri-vacy in Computing and Communications, TRUSTCOM ’12, pages1251–1258, Washington, DC, USA, 2012. IEEE Computer Soci-ety.

49. Lok Kwong Yan and Heng Yin. Droidscope: Seamlessly recon-structing the os and dalvik semantic views for dynamic android


malware analysis. In Proceedings of the 21st USENIX Conferenceon Security Symposium, Security’12, pages 29–29, Berkeley, CA,USA, 2012. USENIX Association.

50. Min Zheng, Patrick PC Lee, and John CS Lui. Adam: an automaticand extensible platform to stress test android anti-virus systems. InInternational Conference on Detection of Intrusions and Malware,and Vulnerability Assessment, pages 82–101. Springer, 2012.

51. Min Zheng, Mingshen Sun, and John C. S. Lui. Droid analytics:A signature based analytic system to collect, extract, analyze andassociate android malware. In Proceedings of the 2013 12th IEEEInternational Conference on Trust, Security and Privacy in Com-puting and Communications, TRUSTCOM ’13, pages 163–171,Washington, DC, USA, 2013. IEEE Computer Society.

52. Wu Zhou, Yajin Zhou, Xuxian Jiang, and Peng Ning. Detect-ing repackaged smartphone applications in third-party androidmarketplaces. In Proceedings of the Second ACM Conferenceon Data and Application Security and Privacy, CODASPY ’12,pages 317–326, New York, NY, USA, 2012. ACM.

53. Yajin Zhou and Xuxian Jiang. Dissecting android malware: Char-acterization and evolution. In Proceedings of the 2012 IEEE Sym-posium on Security and Privacy, SP ’12, pages 95–109, Washing-ton, DC, USA, 2012. IEEE Computer Society.

Documents

Dynamic Malware Detection and Phylogeny Analysis using ... › sites › default › files › dynamic... · Dynamic Malware Detection and Phylogeny Analysis using Process Mining