On the Need of Precise Inter-App ICC Classification

for Detecting Android Malware Collusions*

Abstract—Malware collusion is a new threat against Android For example, a restaurant search app may send an Intent to
application security. It refers to the scenario where two or more Google Maps app, so that Google Maps displays a map with
applications interact with each other to perform malicious tasks. the chosen restaurant’s location. In this work, we investigate
Most existing solutions assume the attack model of a stand-
alone malicious application, and thus cannot detect collusion. the technical challenges associated with distinguishing benign
The objective of this position paper is to point out the need ICC flows from colluding ones. Inability to solve this problem
for practical solutions for detecting malware collusion. We show may result in a high number of false alerts, i.e., misclassifying
experimental evidence on the technical challenges associated benign ICCs as collusion.
with classifying benign Android inter-component communication Most of the existing static ICC-based program analyses are
(ICC) flows from colluding ones. We statically construct ICC
Maps to capture pairwise communicating ICC channels of for detecting vulnerable-yet-benign apps. For example, Com-
2,644 real benign apps. We find that existing permission-based Droid [11] and Epicc [12] identify application communication-
collusion-detection policies trigger a large number of false alerts based vulnerabilities. CHEX [13] identifies potentially vul-
in benign apps pairs. nerable component interfaces that are exposed to the public
without proper access restrictions in Android apps, using
I. I NTRODUCTION
data-flow-based reachability analysis. Amandroid [14] and
Malicious software (malware) has been constantly evolving DroidSafe [15] present a general information flow analysis
to evade detection. This evolution nature of malware was first framework for Android applications. All of the above solutions
shown in the seminal paper by Cohen [1] to cause endless focus on individual app analysis, and none of them provides
arms-races between defenders and attackers. In the realm a complete solution against malware collusion attack.
of smartphone application security, there exist a substantial XManDroid [9] provides a runtime monitoring of commu-
amount of solutions for detecting malicious apps (e.g., Elish nication links between apps. It develops communication clas-
et al. [2], TaintDroid [3], RiskRanker [4], AppContext [5], sification policies based on certain permissions combinations.
Apposcopy [6], Zhang et al. [7], and Alharbi et al. [8]). XManDroid has limitations in distinguishing benign ICC flows
Virtually all the existing solutions assume the attack model from colluding ones, giving a high number of false alerts
of a single malicious application. The detection techniques as demonstrated in our experiments. That solution is more
are focused on inspecting apps individually, through building appropriate for use to monitor a small number of apps already
behavioral models with features obtained from various static installed on a device, as opposed to screen a large number of
and dynamic program analysis. apps (e.g., in Google Play Market) for possible collusion.
The notion of malware collusion has been recently described Because of the wide usage of ICC calls in benign apps
in a few research papers [9], [10] as the next step that pairs, accurate classification is quite challenging. We argue that
malware writers’ may evolve into. Collusion refers to the practical solutions for detecting Android malware collusion
scenario where two or more applications – written by the needs to satisfy several requirements:
same malware writer – interact with each other to perform • To be able to characterize the context associated with
malicious tasks. The danger of malware collusion is that communication channels with fine granularity,
each colluding malware only needs to request a minimal • To define security policies for classification that minimize
set of privileges, which may make it appear benign under false alerts,
conventional screening mechanisms. Malware writers have • To be scalable to a large number of apps (e.g., tens of
strong incentives to write colluding malware. thousands of apps).
In the Android system, Intent and inter-component commu- The purpose of this position paper is to experimentally
nication (ICC) realize an encapsulated communication mech- demonstrate the difficulties and technical challenges associ-
anism for passing messages between two applications, or ated with applications collusion detection. We developed a
between two internal components of the same application. static analysis tool to model the Intent-based ICC of Android
Sending Intents through ICC channels is widely used in apps. applications. We constructed an ICC Map to capture pairwise
*This work has been supported by DARPA APAC award FA8750-15-2- communicating channels, and analyzed the ICC calls among
0076. 2,644 free popular applications from Google Play market.
These apps have passed multiple screening tools and are component. Colluding apps based on inter-app implicit In-
considered benign. 84.4% of these benign apps have external tents may not always succeed since there is a chance that
ICC calls. Furthermore, we apply a set of classification policies the implicit Intent will be wrongly delivered to a different
in the existing XManDroid [9] collusion detection solution component/app not the one intended by the attacker in her/his
to these communicating apps. Our results show that these collusion scenario. This depends on the other apps installed on
permission-based classification policies trigger a large number the mobile device and what are the actions they can handle.
of false alerts in benign apps pairs. Therefore, using inter-app explicit Intents make the collusion
To overcome the deficiencies in the existing work (namely, more successful than using inter-app implicit Intents.
reducing the number of false alerts), we argue that there is a
III. ICC C HANNEL C HARACTERIZATION
need for a more practical solution based on in-depth static flow
analysis. We sketch a promising approach and give specific The purpose of our analysis is to study the inter-app
examples to show how to discover the context associated with communication via ICC in Android and investigate whether
benign ICC flows, and to formulate more fine-grained policies. it is commonly used or not. To achieve this, we de-
fine ICC Map to identify the group of communicating
II. M ALWARE E VOLUTION AND ATTACK M ODEL apps by capturing the ICC channels between them. In
Malware collusion is a new malware generation attack that our ICC analysis, we focus on all Intent-based ICC APIs
is very challenging to detect under the existing conventional such as startActivity(Intent i), startService
screening techniques. A collusion attack occurs when ma- (Intent i), and sendBroadcast(Intent i).
licious applications, likely written by the same adversary,
A. ICC Map Construction
collaborate to gain a set of permissions to perform malicious
tasks. In malware collusion, each colluding malware only The objective of the ICC Map is to capture and identify all
needs to perform a certain functionality, which may make the intra- and inter-app ICCs of an application.
it appear benign to evade the conventional detection tools. Definition 1. ICC Map is a directed graph G(V, E) for app
Hence, malware writers have strong motivation to write col- A. Each node v ∈ V in G represents a component or action
luding malware to evade standard detection. Figure 1 depicts name, and each edge e ∈ E in G represents an ICC API.
the application collusion threat model through Intent-based There are two types of communication:
inter-component communication (ICC). Colluding applications • Internal communication: component X is communicating
may abuse system resources (e.g., sending spam SMS) or leak with component Y , where both X and Y are internal
sensitive data. Colluding applications also may communicate components in app A.
indirectly, e.g., through shared files, or through covert channels • External communication: component X is communicat-
as demonstrated in [10]. Detecting covert-channel based apps ing with component Y , where component X is in app A,
collusion remains an open problem. and component Y is in app B.
To determine if the app has an external communication,
Application X   Application Y  
we get the list of components and their actions defined in the
Data/Action
manifest of the app. Then, for each target component or action
ICC Exit ICC Entry
Component A Point Point Component C we find during our analysis, we match this target component
with this list. If this target component is not defined as one of
Data/Action  

ICC Entry ICC Exit the internal components, we label it as an external component
Component B Point Point Component D
and infer that this application has external ICC.
For each app, we store the ICC Map information
App X has set of App Y has set of
permissions not permissions not as a set S consisting of multiple four-item tuples
in App Y in App X {< ICCN amek , sourceComponentk , targetComponentk ,
typeOf Communicationk >}, where
Fig. 1. Application collusion threat model via ICC. • ICCN ame is the API name of ICCk , such as
startActivity() and startService()
In this paper, we focus our analysis on the Intent-based • sourceComponent is the name of the component which
ICC channels which are standard communication channels initiates the ICCk (exit point). It is a subclass of
in the Android. Colluding applications can use explicit or Activity, Service, BroadcastReceiver
implicit Intents for inter-app communications. The explicit • targetComponent is the name of the component which
Intent specifies the target component/app, while the implicit receives the ICCk (entry point). It is a subclass of
Intent specifies the action string and will be delivered to any Activity, Service, BroadcastReceiver
component that declares to handle this action. • typeOf Communication is the type of ICCk communi-
In order for the attacker to make her/his apps collusion cation, internal or external.
always succeed, she/he should use inter-app explicit Intents Our goal is to find all Intents used in the ICC APIs
to guarantee that the Intent will be delivered to the correct to identify the source and target components linked by the
 abc.ssd.TrafficInfoCheck.TrafficInfoActivity abc.ssd.TrafficInfoCheck.Widget.AppWidgetEx

startActivityForResult () startService ()
startActivityForResult ()
stopService()
startActivity ()

abc.ssd.TrafficInfoCheck.TrafficInfoSiteActivity abc.ssd.TrafficInfoCheck.SettingActivity abc.ssd.TrafficInfoCheck.Widget.WidgetRepeatReceiver

abc.ssd.TrafficInfoCheck.Widget.AppWidgetService
android.intent.action.VIEW (External ICC)
(Internal ICC)

Fig. 2. Partial ICC map for abc.ssd.TrafficInfoCheck application.

Intents. We utilize the data-flow analysis in Soot framework1 Android apps from Google Play market. These apps covering
to find the Intent object used in the ICC API. Specifically, we various application categories and different levels of popularity
use data-flow analysis to construct the data dependence graph as determined by the user rating scale. We checked these apps
(DDG) of intra- and inter-procedural dependences to track the using different tools such as VirusTotal2 and Elish et al. [2].
dependences between the definition and use of Intents in a All these tools indicate that these apps are benign.
given app. The DDG is a common program analysis structure
A. ICC Analysis on Benign Apps
which represents inter-procedural flows of data through a
program [16]. The ICC Map graph is constructed based on For each app, we construct the ICC Map to capture all types
the ICCMap information set S. of communication that the app performs. In particular, we need
to find whether the app is interacting with other apps or not.
B. Example of ICC Map We found that 2,230 apps (84.4%) out of 2,644 apps perform
Figure 2 shows an example of partial ICC Map for external ICC with other third party or built-in apps by either
abc.ssd.TrafficInfoCheck app. It is an app to using implicit or explicit Intent. Table I summarizes our ICC
display information about the Japanese railway service. analysis on 2,644 free popular apps.
In this example, there are five ICC APIs. This map For the apps with the external ICC (84.4%), 298 apps
is constructed based on the ICCMap information set (11.3%) use explicit Intent ICC. In particular, these apps
which has five tuples for this example. For instance, send external ICC to other third party apps by specifying
<startActivity(), abc.ssd.TrafficInfoCheck.TrafficInfoActivity, explicitly the name of the target component. On the other hand,
android.intent.action.VIEW, external> is one tuple in the ICC 1,932 apps (73.1%) use implicit Intent ICC (not specifying
Map information set S. This tuple can be interpreted as there the target component) for communicating with other third
is an ICC call startActivity() from the source com- party or built-in apps.
ponent (abc.ssd.TrafficInfoCheck.TrafficInfo B. Collusion Detection Using XManDroid
Activity) to a target component which declares to handle
XManDroid [9] is a runtime monitoring of communication
this action android.intent.action.VIEW. This target
links between apps, and it defines communication classifi-
component is an external component since none of the internal
cation policies based on certain permissions combinations.
components in this app can handle this action. Only other
XManDroid suffers from high false positives as it is acknowl-
components in other apps, which are declared to handle this
edged by its authors. We confirmed this property by evaluating
action, will receive the request. Hence, we infer that this app
a set of XManDroid’s policies on randomly selected 20 benign
is communicating with another app through this action.
apps pairs. We found these 20 benign apps pairs using our
IV. E XPERIMENTAL E VALUATION ICC Map analysis. Each pair uses direct explicit Intent ICC
channels for the communication between the apps. We found
The purpose of this experiment is to show the difficulties
that 11 out of 20 benign pairs of apps are misclassified as
and challenges in classifying benign Android ICCs from
collusion according to XManDroid’s policies, a very high
colluding ones. In particular, the objective of this experiment
false positive rate (55%). Figure 3 shows the number of the 20
is to answer the following questions:
benign apps pairs that trigger alerts per XManDroid’s policy.
1) How often do benign apps perform inter-app communi- The empirical results indicate that many Android apps are
cations with other apps? interacting with other third party or built-in apps through
2) How effective is the existing collusion detection solution ICC channels. This ICC-based communication provides a
(namely XManDroid) in terms of false positive rate? potential opportunity for the attackers to develop malicious
We implemented a static analysis tool in Java to construct colluding apps by utilizing the ICC APIs in a similar way as
the ICC Map for a given Android app. We performed our in the communication between the benign apps. Therefore,
ICC characterization study on 2,644 free popular real-world it is challenging to develop a detection technique that can
1 http://www.sable.mcgill.ca/soot 2 https://www.virustotal.com
 TABLE I
S UMMARY OF ICC ANALYSIS ON 2,644 BENIGN APPS . I MPLICIT AND V. C OLLUSION D ETECTION WITH C ROSS -A PP DATA -F LOW
EXPLICIT I NTENT ICC ARE USED FOR COMMUNICATION BETWEEN APPS . A NALYSIS
The above experiments show the challenges in distinguish-
Action Used in External Implicit Intent ICC # of Apps (%)
ing benign inter-app ICCs from colluding inter-app ICCs in
android.intent.action.VIEW 1870 (70.7%) practice, since most of the apps perform external commu-
android.intent.action.SEND 943 (35.7%) nications. In this paper, we proposed ICC Map to statically
android.intent.action.DIAL 399 (15.1%) characterize the inter-app ICC channels among the Android
android.intent.action.GET CONTENT 275 (10.4%) apps. This ICC Map does not provide a solution for apps
android.media.action.IMAGE CAPTURE 231 (8.7%) collusion detection but it helps to identify pair or group of
android.intent.action.CALL 158 (6.0%)
communicating apps. Thus, one can utilize this ICC Map to
android.intent.action.PICK 139 (5.3%)
android.intent.action.SENDTO 122 (4.6%)
first identify the communicating apps. Then, a set of security
android.media.action.VIDEO CAPTURE 62 (2.3%) policies can be defined and applied to differentiate between
android.intent.action.DELETE 53 (2.0%) benign communicating apps and colluding ones.
android.intent.action.EDIT 48 (1.8%) There may be multiple ICC calls between two apps. The
android.speech.action.RECOGNIZE SPEECH 45 (1.7%) sensitivity of each ICC call may differ substantially and needs
android.intent.action.MEDIA MOUNTED 42 (1.6%) to be analyzed case-by-case. Permission-based policies cannot
android.intent.action.INSERT 33 (1.2%) achieve this granularity. Inferring the ICC sensitivity requires
android.intent.action.SEARCH 20 (0.8%) in-depth data-flow analysis in both apps, detailing how the
android.intent.action.RINGTONE PICKER 19 (0.7%) data is created, modified, and consumed. Policies based on
android.intent.action.WEB SEARCH 12 (0.5%) such an analysis will be more fine-grained than permission-
android.intent.action.SYNC 3 (0.1%)
based policies, reducing false alerts on benign ICCs.
android.intent.action.ANSWER 2 (0.1%)
We argue the need for in-depth static flow analysis (e.g.,
# of apps with external implicit Intent ICC 1932 (73.1%) definition-use relations) in both source and destination apps
# of apps with external explicit Intent ICC 298 (11.3%) for collusion detection. The key is the discovery of the context
associated with benign ICC flows. The discovery requires new
Total # of apps with external ICC 2230 (84.4%)
static program analysis algorithms and data structures. Static
Total # of apps with Internal ICC 414 (15.6%) analysis-based solution provides complete analysis coverage,
and scalable to analyze large number of apps. Admittedly,
static analysis-based solution in general is affected by ob-
fuscated code and can not handle dynamic code loading.
differentiate well between non-malicious ICC and malicious However, we argue that any successful collusion detection
ICC. The reason is that most of the benign apps are interacting technique should be comprehensive, scalable, and not limited
with other apps according to our empirical results, which by the device’s resources constraints. Hence, we advocate the
makes it challenging to develop a detection mechanism. use of static analysis-based solution for collusion detection
because of the scalability and completeness provided by the
static analysis.
Existing work on single-app classification showed that
9 statically extracted features on user-trigger dependence, i.e.,
8 the degree of sensitive API calls having def-use dependence
7 relations on user inputs3 , is very effective [2], [17]. Benign
single apps have a high degree of user-trigger dependence,
# of Apps Pairs

6
whereas malware – often performing activities under stealth
5 mode – does not. Hence, it is conceivable to write similar
4 user-trigger dependence policies for collusion detection, i.e.,
how much the app actively involves the user in implicitly
3
authorizing inter-app ICC calls. Such a policy is under the
2 hypothesis that benign ICC flows are intended and initiated
1 by the users (at the source app), whereas colluding ones are
0 not. As a future work, we plan to design and implement such
Policy # 8 Policy # 9 Policy # 10 Policy # 11 policies to differentiate between benign inter-app ICC and
malicious inter-app ICC.
Fig. 3. Histogram showing the number of the 20 benign apps pairs that
Admittedly, all policies have their limitations and may be
trigger alerts per XManDroid’s policy [9]. Some apps pairs trigger alerts for bypassed by sophisticated malware writers. Yet, the advantages
more than one policy. XManDroid’s policy can be found in [9]. of fine-grained policies are twofold: making the tool more
3 User inputs may be onClick(), onItemClick(), etc.
usable by reducing false alerts, and creating bigger obstacles [12] D. Octeau, P. McDaniel, S. Jha, A. Bartel, E. Bodden, J. Klein, and Y. L.
for malware to bypass. Traon, “Effective inter-component communication mapping in Android
with Epicc: An essential step towards holistic security analysis,” in Proc.
of the 22nd USENIX Security Symposium, 2013.
VI. C ONCLUSIONS AND F UTURE W ORK [13] L. Lu, Z. Li, Z. Wu, W. Lee, and G. Jiang, “CHEX: statically vetting
In this position paper, we argue that it is very challenging Android apps for component hijacking vulnerabilities,” in Proc. of the
ACM Conference on Computer and Communications Security (CCS).
to detect malware collusion. We demonstrate the challenges ACM, 2012, pp. 229–240.
through experimental evidence. The experimental results in- [14] F. Wei, S. Roy, X. Ou, and Robby, “Amandroid: A precise and general
dicate that many Android apps communicate with other apps inter-component data flow analysis framework for security vetting of
Android apps,” in Proc. of the ACM Conference on Computer Commu-
through ICC channels, which makes it challenging to develop nications Security (CCS). ACM, 2014.
a detection mechanism without generating many false alerts [15] M. Gordon, D. Kim, J. Perkins, L. Gilhamy, N. Nguyen, and M. Rinard,
as in XManDroid [9]. None of the existing solutions provides “Information-flow analysis of Android applications in DroidSafe,” in
Proc. of the Network and Distributed System Security Symposium
a complete solution against app collusion attack. An effective (NDSS). The Internet Society, 2015.
solution should be scalable to a large number of apps, and [16] S. Horwitz, T. Reps, and D. Binkley, “Interprocedural slicing using
define policies for classification that minimize false alerts. dependence graphs,” ACM Transactions on Programming Languages
and Systems, vol. 12, pp. 26–60, 1990.
For future work, we plan to utilize our ICC Map for [17] B. Wolfe, K. Elish, and D. Yao, “Comprehensive behavior profiling for
application collusion detection and define security policies to proactive Android malware detection,” in Proc. of 17th International
differentiate between benign inter-app ICC and colluding inter- Information Security Conference (ISC), 2014.
app ICC. Our goal is to defend against the malware collusion
attack in the Android system.

ACKNOWLEDGEMENT
We thank our shepherd, William Enck and Adwait Nad-
karni, and the reviewers for their insightful comments.

R EFERENCES
[1] F. Cohen, “Computer viruses theory and experiments,” Computers and
Security, vol. 6, pp. 22 – 35, 1987.
[2] K. Elish, X. Shu, D. Yao, B. Ryder, and X. Jiang, “Profiling user-trigger
dependence for Android malware detection,” Computers & Security,
vol. 49, pp. 255–273, 2015.
[3] W. Enck, P. Gilbert, B. gon Chun, L. P. Cox, J. Jung, P. McDaniel, and
A. Sheth, “TaintDroid: An information-flow tracking system for realtime
privacy monitoring on smartphones,” in Proc. of the USENIX Symposium
on Operating Systems Design and Implementation, 2010, pp. 393–407.
[4] M. C. Grace, Y. Zhou, Q. Zhang, S. Zou, and X. Jiang, “RiskRanker:
scalable and accurate zero-day Android malware detection,” in Proc. of
the 10th International Conference on Mobile Systems, Applications, and
Services (MobiSys). ACM, 2012, pp. 281–294.
[5] W. Yang, X. Xiao, B. Andow, S. Li, T. Xie, and W. Enck, “Appcontext:
Differentiating malicious and benign mobile app behaviors using con-
text,” in Proc. of the International Conference on Software Engineering
(ICSE), 2015.
[6] Y. Feng, S. Anand, I. Dillig, and A. Aiken, “Apposcopy: Semantics-
based detection of Android malware through static analysis,” in Proc.
of the ACM SIGSOFT Symposium on the Foundations of Software
Engineering (FSE), 2014.
[7] H. Zhang, D. Yao, and N. Ramakrishnan, “Detection of stealthy malware
activities with traffic causality and scalable triggering relation discovery,”
in Proc. of the 9th ACM Symposium on Information, Computer and
Communications Security (ASIACCS). ACM, 2014.
[8] K. Alharbi, S. Blackshear, E. Kowalczyk, A. M. Memon, B.-Y. E. Chang,
and T. Yeh, “Android apps consistency scrutinized,” in Proc. of the
Extended Abstracts on Human Factors in Computing Systems. ACM,
2014.
[9] S. Bugiel, L. Davi, A. Dmitrienko, T. Fischer, A. Sadeghi, and B. Shas-
try, “Towards taming privilege-escalation attacks on Android,” in Proc.
of the 19th Annual Network and Distributed System Security Symposium,
2012.
[10] C. Marforio, H. Ritzdorf, A. Francillo, and S. Capkun, “Analysis of
the communication between colluding applications on modern smart-
phones,” in Proc. of the 28th Annual Computer Security Applications
Conference. ACM, 2012.
[11] E. Chin, A. P. Felt, K. Greenwood, and D. Wagner, “Analyzing inter-
application communication in Android,” in Proc. of the 9th Int’l Confer-
ence on Mobile Systems, Applications, and Services, 2011, pp. 239–252.