Research  Question:    

Can  we  determine  if  an  application  is  malicious  based  on  the  network  traffic  from  the  mobile  device?  

INTRODUCTION  

It  is  important  to  protect  the  data  stored  on  our  mobile  devices  from  what  are  

known  as  malicious  applications.  Such  applications  are  capable  of  stealing  information  from  

our  smartphones  that  can  be  dangerous  in  the  hands  of  the  wrong  people.    The  purpose  of  

our  research  was  to  find  a  way  to  detect  malicious  activity  within  a  mobile  phone  

application.    We  began  by  downloading  malicious  applications  and  studying  how  they  

interacted  with  their  respective  host  servers.    Using  a  virtual  machine  we  observed  those  

interactions  so  we  could  better  understand  what  data  packets  are  being  sent  over  the  

network,  and  if  the  packets  could  potentially  be  malware.  As  a  team,  our  hope  was  to  find  

ways  to  secure  mobile  phones  from  malicious  applications  by  monitoring  the  device’s  

network  traffic.    The  research  question  we  focused  on  answering  was,  “Can  we  determine  if  

an  application  is  malicious  based  on  network  traffic  on  the  device?”  

As  the  popularity  of  mobile  phones  is  on  the  rise,  so  is  the  amount  of  malicious  

applications  being  downloaded.  It  is  important  to  understand  that  these  harmful  

applications  can  gather  all  the  data  from  your  mobile  device.    They  are  able  to  track  your  

keystrokes,  contacts,  Facebook  friends,  and  even  access  account  passwords.  As  a  society  we  

can  be  naïve  when  it  comes  to  storing  important  information  on  our  mobile  devices.  People  

need  to  be  mindful  of  how  they  use  their  devices  and  share  information  on  the  web  to  

protect  themselves  from  stolen  data.    Our  hope  for  this  project  was  to  be  able  to  enhance  

security  measures  for  users  who  are  especially  neglectful  of  security  standards  because  

individuals  might  not  care  if  someone  accesses  data  on  their  phone,  especially  if  it  isn’t  very  

sensitive  such  as  Facebook  pictures  or  contact  lists.  But  if  the  application  was  interacting  

with  something  more  personal  such  as  a  bank  login  then  we  would  want  to  deny  that  

application  network  accessibility  if  it  were  potentially  malicious.    

Our  goal  was  to  develop  an  application  to  detect  network  activity  on  other  

applications.  We  chose  to  go  this  direction  because  after  extensive  research  in  the  field  we  

found  that  although  the  Android  market  is  the  market  with  the  vast  majority  of  malicious  

activity  it  is  quite  adequate  at  detecting  malicious  application,  but  we  still  see  malicious  

apps  published  on  the  market.  We  decided  a  system  for  early  detection  may  be  out  of  our  

range  as  well  as  less  interesting  and  innovative  to  the  industry.  Changing  device  security  is  

another  way  to  go  that  we  decided  against  because  most  of  the  security  features  currently  

on  Android  devices  are  also  quite  adequate  security  features,  also  most  have  to  be  activated  

and  set  by  user  which  in  our  opinion  could  be  problematic  since  users  can  be  neglectful  of  

their  security  either  out  of  apathy  or  unfamiliarity.    

Background  

We  as  a  group  deemed  to  focus  only  on  android  applications  since  this  is  the  most  

used  smart  phone  in  the  United  States.  After  researching  the  field  we  found  that  Android  

security  is  a  high  focus  point  for  the  technology  industry,  with  many  entities  working  on  

improvements.  Why  is  the  industry  so  focused  on  Android  over  other  operating  systems?  

From  our  findings  we  believe  it  is  because  we  are  seeing  more  cases  of  malicious  activity  on  

Android  in  fact  the  market  has  seen  Android  go  from  having  47%  of  all  known  mobile  

malware  to  92%  in  just  one  year  [9  pg4].  A  review  done  in  2010  shows  that  the  Android  

Marketplace  and  Android  devices  have  many  countermeasures  already  in  place  to  combat  

these  security  risks,  [15  pg10]  most  all  deal  with  detection  before  publishing  on  to  the  

Android  Marketplace  [15  pg8].  

The  Android  Marketplace  still  has  numerous  applications  that  are  considered  

malicious  despite  the  efforts  of  today’s  security  professionals.  Android  has  the  “Google  

PlayStore”  marketplace  as  a  main  source  of  applications,  but  there  are  also  third-­‐party  

marketplaces  available  as  well.    These  third-­‐party  developers  are  contributing  heavily  to  the  

malware  problem  on  Android  as  we  can  see  from  the  graph  below[Figure  1]  [10  pg1].    

Android  has  over  500  third-­‐party  developer  marketplaces  that  are  known  to  contain  active  

malicious  applications  [9  pg4].    It  would  appear,  based  on  the  number  of  third-­‐party  

marketplaces  available  on  Android  compared  to  other  platforms,  Android  makes  their  

platform  more  accessible  to  third-­‐party  developers  to  develop  on  Android  over  other  

mobile  platforms  such  as  Apple’s  iOS  [3  pg3]  .  

 

     

We  began  our  research  by  looking  for  an  overview  of  what  a  malicious  application  is  

and  what  people  in  the  security  industry  are  doing  to  combat  them.  We  found  this  paper  

that  classifies  two  different  types  of  malicious  apps  as  “the  leak  of  sensitive  data”  and  

“unauthorized  access  to  system  resources”  [6  pg1].  This  means  that  the  malware  either  can  

extract  data  from  your  phone  and  send  it  to  unauthorized  personnel,  or  do  operations  on  

your  devices  without  your  knowledge  such  as  sending  premium  messages.  Our  findings  

showed  that  73%  of  malware  on  Android  exploits  messaging  systems  to  generate  premium  

SMS  messages  [9  pg4].    Using  their  work  we  were  able  to  better  understand  the  types  of  

malicious  apps  before  trying  to  come  up  with  our  own  solution  to  the  growing  malware  

issue.    

We  began  by  trying  to  devise  our  own  solution  for  detecting  malicious  activity  on  

mobile  devices.  By  looking  into  the  coding  of  a  normal  app  and  a  malicious  app  we  believed  

we  would  be  able  to  see  a  difference  and  that  difference  is  potentially  what  makes  the  app  

malicious.  Devising  a  system  to  detect  these  potentially  malicious  lines  of  code  within  an  

application  was  our  goal  at  this  time  and  we  found  these  individuals  who  were  claiming  to  

have  found  a  solution  [17  pg3].  If  we  could  detect  the  back-­‐end  code  that  makes  an  

application  malicious  we  could  alert  the  user  that  they  have  potentially  harmful  application  

on  their  phone.  This  solution  was  not  the  way  we  decided  to  go  however  because  after  

seeing  the  framework  of  Android’s  operating  system  we  decide  that  this  wouldn’t  be  the  

best  way  to  solve  the  malware  issue.    

Android’s  framework  doesn’t  allow  for  easy  communication  between  applications  

on  a  single  device.  Android  runs  a  “sandbox”  style  of  operating  applications,  meaning  each  

application  runs  in  its  own  “space”  on  the  phone  and  there  is  no  communication  between  

applications.  When  you  download  an  application  on  Android  “the  app  is  sandboxed  and  

restricted  to  the  permissions  granted  to  it  and  Android's  own  security  checks  again  

whenever  the  app  runs”  [8  pg2].    Each  application  uses  specific  memory  space  on  the  

device  that  is  unique  to  that  application  and  that  memory  isn’t  accessible  by  other  

applications  not  given  permission  to  that  memory  space.    

 If  we  can’t  access  the  memory  files  of  an  application  we  couldn’t  expect  to  be  able  to  

easily  create  an  app  that  could  access  another  app’s  coding.  Then  we  had  the  idea  to  look  at  

the  network  traffic  of  an  application  instead.    Our  research  brought  us  to  an  interesting  

product  that  currently  allows  a  user  to  deny  network  access  of  all  their  applications  on  their  

device.  This  product  is  known  as  Droid  Wall  and  it  is  available  on  the  Google  Play  Store  [1  

pg1].    After  doing  research  on  Droid  Wall  we  found  it  was    a  successful  application  that  

helped  end  users,  yet  we  figured  there  was  an  algorithm  we  could  build  that  would  help  

protect  the  user  even  more  by  analyzing  the  packets  and  their  IP’s  .    

We  wanted  to  do  something  innovative  and  constructive  to  enhance  the  current  

state  of  security  on  the  mobile  marketplace.  We  tried  to  differentiate  our  research  from  

current  research  and  products  that  where  currently  available.    One  can  see  that  our  current  

area  of  study  is  currently  being  researched  heavily  right  now  by  the  mobile  security  field  

since  we  are  seeing  the  popularity  of  smart  phones  rise  ,  experts  expect  that  over  1  Billion  

Android  phones  will  be  shipped  by  2017  [9  pg4];  but  where  our  work  strays  from  these  

other’s  is  that  we  are  trying  isolate  apps  based  on  their  network  activity  and  individually  

shut  down  applications  that  we  believe  are  malicious  where  these  individuals  [1]  have  just  

made  it  possible  to  shut  down  network  access  to  all  apps.    We  focused  our  attention  on  our  

detection  systems  on  the  network  activity  of  application  instead  of  looking  mainly  at  the  

coding  of  the  application  itself  and  attempting  to  detect  a  problem  either  in  the  Google  Play  

Store  or  before  publishing  to  the  Play  Store  or  even  on  the  end  users  phone.        

OUR  WORK  

As  we  researched  the  current  state  of  Android’s  mobile  security  we  considered  

many  different  avenues  in  which  to  use  our  research  to  raise  the  current  state  of  Android’s  

mobile  security.    We  decided  that  the  best  way  to  create  new  and  innovative  research  was  

to  look  at  the  network  activity  of  mobile  phones.  Our  research  centered  answering  the  

question  of  whether  or  not  we  could  decide  if  an  application  was  malicious  or  not  based  on  

the  network  traffic.  Our  group  used  network  traffic  capturing  tools  to  record  the  network  

activity  of  a  phone  while  running  different  applications,  some  known  to  be  malicious  others  

know  to  be  safe  applications.  Our  belief  was  that  we  would  see  irregular  network  activity  

when  running  an  application  we  knew  was  malicious.  

We  started  our  process  of  answering  this  question  by  first  creating  a  safe  

environment  in  which  to  test  for  malicious  applications.  We  didn’t  want  to  leak  our  own  

sensitive  data  while  conducting  our  research;  this  stopped  us  from  installing  malicious  

applications  onto  one  of  our  personal  phones.  We  tried  to  use  a  phone  that  was  at  still  at  

factory  settings  and  not  activated  to  a  mobile  service  plan  but  without  a  service  plan  

attached  to  the  phone  we  wouldn’t  be  able  to  access  and  download  applications  from  the  

mobile  marketplace.    We  decided  to  use  a  Virtual  Machine(VM)  [4]which  can  simulate  an  

Android  mobile  operating  system  on  a  desktop  or  laptop  computer.    

Next  we  had  to  find  a  database  of  malicious  application  that  we  could  download  

onto  our  VM.  This  process  proved  to  be  one  of  the  most  difficult  parts  of  our  research.  Due  

to  the  nature  of  malicious  applications  it  is  hard  for  individuals  such  as  ourselves  to  be  

allowed  access  to  them,  this  is  merely  a  security  measure  because  these  applications  can  be  

quite  dangerous  in  the  wrong  hands.  We  were  able  to  gain  access  to  a  blog  [11]  that  had  a  

collection  of  malicious  applications  that  had  been  discovered  by  the  Google  Play  Store  this  is  

where  our  test  set  of  malicious  applications  came  from.    

We  proceeded  to  install  both  malicious  and  creditable  applications,  such  as  

Facebook,  onto  the  VM  and  placed  data  that  wasn’t  sensitive  into  the  VM  and  creditable  

applications.  We  installed  both  types  so  that  when  we  captured  the  network  traffic  coming  

from  the  Virtual  Machine  we  could  compare  the  network  traffic  when  the  VM  was  running  

malicious  applications  against  when  its  running  creditable  applications.  Our  hypothesis  was  

that  when  we  look  at  the  network  traffic  coming  from  and  to  the  VM  there  would  be  

irregular  occurrences  in  the  network  traffic  when  running  malicious  applications  such  as  

sending  uncommonly  large  data  packets  or  sending  data  packets  to  servers  that  you  have  

never  previously  encountered  outside  of  running  this  malicious  application.  

We  used  network  traffic  capturing  programs  such  as  WireShark,  TCP  Dump,  Nettop  

and  packet  peeper  in  order  to  capture  the  network  traffic  being  generated  from  our  VM.  

WireShark  is  a  program  anyone  can  use  in  order  to  monitor  the  traffic  being  generated  on  a  

given  NIC.  Also,  you  can  use  TCP  Dump  to  monitor  the  TCP  traffic  on  the  network  This  

program  also  records  the  data  packet  size,  the  time  in  which  data  packets  are  either  being  

sent  or  received,  as  well  as  the  DNS  in  which  the  data  being  sent  to  or  received  from  [5].    

Our  Findings  

  After  working  with  many  solutions  to  try  and  trap  the  network  traffic  coming  from  

our  Android  Virtual  Machine  we  decided  to  stick  with  TCP-­‐dump,  Net-­‐top  and  Packet  

Peeper.    Using  these  applications,  we  worked  on  trying  to  find  abnormal  traffic  coming  from  

the  Android  OS  after  installing  different  malicious  applications.  After  looking  into  the  

different  types  of  malware  we  decided  to  stick  with  two  types  of  applications  that  could  

easily  be  confused  for  non-­‐malicious  applications.    The  two  apps  we  focused  on  were  Armor  

for  Android  and  Collage  Creator.  These  two  applications  were  determined  malicious  by  

multiple  security  companies  and  then  pulled  from  the  Google  Play  store.  After  these  

applications  were  pulled  many  independent  security  researchers  posted  these  applications  

to  their  blogs.  After  contacting  many  security  researchers,  we  were  able  to  get  access  to  a  

repository  that  we  would  use  for  testing.    

After  testing  many  of  the  pulled  applications  we  started  looking  at  the  traffic  

specifically  coming  from  Facebook,  which  was  our  normal  application,  and  then  Armor  for  

Android.  Armor  for  Android  tried  to  cover  itself  up  as  a  non-­‐malicious  application  by  

searching  your  phone  for  actual  malicious  applications  then  trying  to  remove  them.  When  

looking  at  the  traffic  and  after  analyzing  the  report  from  the  independent  security  

researcher  we  were  able  to  then  conclude  that  many  of  the  IP  addresses  that  did  not  DNS  

resolve  coming  from  Armor  for  Android  showing  it  was  possibly  trying  to  connect  to  a  

command  and  control  server.  After  trying  to  ping  that  command  and  control  server  we  

realized  that  it  was  no  longer  active.  We  then  made  the  connection  that  once  the  malicious  

app  is  removed  from  the  market  many  of  the  command  and  control  servers  must  be  taken  

offline.  The  only  issue  with  trying  to  prove  whether  or  not  an  app  is  malicious  just  based  on  

whether  or  not  the  DNS  resolves  is  faulty.    

   

We  then  proceeded  to  do  the  same  testing  with  Collage  Creator.  We  installed  this  

application  on  the  virtual  machine  then  proceeded  to  run  all  of  our  Network  tests  on  the  

application.  After  running  these  tests  we  came  to  the  same  conclusion  we  did  with  Armor  

for  Android.  Even  though  the  packets  were  encrypted  and  the  traffic  went  to  an  IP  address  

that  did  not  DNS  resolve  this  did  not  prove  that  the  application  was  malicious.  Security  

Firms  who  determined  these  applications  were  malicious  went  through  and  analyzed  the  

application  from  the  ground  up.  They  first  starting  by  analyzing  traffic  then  proceed  to  

decompiling  the  application  to  analyze  the  code.  We  tried  with  many  of  the  applications  

using  Dex2Jar  but  didn’t  have  any  luck  decompiling  the  applications.  

 

 

Conclusion  

  This  just  shows  that  unless  you  either  use  machine  learning  or  some  type  of  

advanced  algorithm  to  analyze  the  traffic  it  is  not  possible  to  tell  the  different  between  

Facebook  and  malicious  applications  traffic.  We  came  up  with  this  conclusion  because  small  

businesses  may  make  applications  that  connect  directly  to  a  IP  address  that  does  not  DNS  

resolve.  If  there  was  software  out  there  that  just  looked  at  the  Packet  and  whether  or  not  it  

DNS  resolved  it  would  possibly  be  stopping  non-­‐malicious  applications  from  accessing  the  

phones  network.    For  the  data  that  backs  up  our  conclusion  please  visit  the  website  where  

there  are  a  host  of  images  showing  our  data  based  on  each  application.  

Video:  

URL:  http://www.youtube.com/watch?v=N5rZSFNktXI  

Poster:  

 

 

 Bibliography    

[1]Ashraf.  "[Android,  Root  Required]  Block  Apps  from  Accessing  the  Internet  with  

DroidWall."  DotTech.  Dottech.org  -­‐,  1  Oct.  2011.  Web.  25  Oct.  2013.  

 [2]Bugiel,  Sven,  Lucas  Davi,  Alexandra  Dmitrienko,  Thomas  Fischer,  and  Ahmad-­‐Reza  

Sadeghi.  XManDroid:  A  New  Android  Evolution  to  Mitigate  Privilege  Escalation  

Attacks.  Technische  Universitat  Darmstadt:  Center  for  Advanced  Security  Research  

Darmstadt.  Information  Security  and  Cryptography  Group,  30  June  2011.  Web.  21  

Oct.  2013.  <http://www-­‐infsec.cs.uni-­‐

saarland.de/~bugiel/publications/pdfs/XManDroid-­‐tr-­‐2011-­‐04.pdf>.  

 

[3]Cooper,  James.  "The  Best  App  Store  Directory."  List  of  Mobile  App  Stores.  

Mobyaffiliates,  n.d.  Web.  1  Dec.  2013.  

[4]"Download  VirtualBox."  Downloads  –  Oracle  VM  VirtualBox.  Oracle,  n.d.  Web.  1  

Nov.  2013.  

[5]"Download."  Wireshark  ·  Go  Deep.  WireShark  Foundation,  n.d.  Web.  25  Nov.  2013  

http://www.wireshark.org/.  

 

 [6]Elish,  Karim  O.,  Danfeng  Yao,  Barbara  G.  Ryder,  and  Xuxian  Jiang.  A  Static  Assurance  

Analysis  of  Android  Applications.  Department  of  Computer  Science  -­‐  Virginia  Tech.  

Department  of  Computer  Science,  Virginia  Tech  &  North  Carolina  State  University,  

2013.  Web.  23  Sept.  2013.  

[7]Gheorghescu,  Marius,  and  Microsoft  Corp.  "An  Automated  Virus  Classification  System."An  

Automated  Virus  Classification  System  (2005).  

[8]Henry,  Alan.  "How  Secure  Is  Android,  Really?"  Lifehacker.  LifeHacker,  16  Oct.  

2013.  Web.  3  Nov.  2013.  

[9]  Juniper  Networks.  Juniper  Networks  Third  Annual  Mobile  Threats  Report.  Annual  

Report.  Juniper  Networks,  Mar.  2013.  Web.  19  Oct.  2013.  

<http://www.juniper.net/us/en/local/pdf/additional-­‐resources/jnpr-­‐2012-­‐

mobile-­‐threats-­‐report.pdf>.  

 

[10]Luo,  Symphony.  "1,730  Malicious  Apps  Still  Available  on  Popular  Android  App  

Providers."  Web  log  post.  Security  Intelligence  Blog.  TrendMicro.com,  20  Dec.  2012.  

Web.  1  Oct.  2013.  <http://blog.trendmicro.com/trendlabs-­‐security-­‐

intelligence/1730-­‐malicious-­‐apps-­‐still-­‐available-­‐on-­‐popular-­‐android-­‐app-­‐

providers/>.  

 

[11]Mila.  "Contagio:  Links  and  Resources  for  Malware  Samples."  Contagio:  Links  and  

Resources  for  Malware  Samples.  Blogger,  n.d.  Web.  9  Nov.  2013.  

 

[12]Nachenberg,  Carey.  "A  Window  Into  Mobile  Device  Security."  Examining  the  Security  

Approaches  Employed  in  Apple's  IOS  and  Google's  Android  (2011):  n.  

pag.Symantec.com.  Symantec,  2011.  Web.  5  Oct.  2013.  

<http://investor.symantec.com/files/doc_news/2012/symc_mobile_device_security

_june2011.pdf>.  

[13]Ronghua  Tian,  L.  Batten,  R.  Islam,  S.  Versteeg  “An  automated  classification  system  based  

on  the  strings  of  trojan  and  virus  families  In  Malicious  and  Unwanted  Software  

(MALWARE)”,  2009  4th  International  Conference  on  (2009),  pp.  23-­‐30,  

doi:10.1109/MALWARE.2009.5403021    

[14]Sanz,  Borja,  Carlos  Laorden,  Xabier  Ugarte-­‐Pedrero,  and  Garcia  Bringas.  "On  the  

Automatic  Categorization  of  Android  Applications."  (2011):  n.  pag.  Print.  

 

[15]Shabtai,  Asaf,  Yuval  Fledel,  Uri  Kanonov,  Yuval  Elovici,  Shlomi  Dolev,  and  Chanan  Glezer.  

"Google  Android:  A  Comprehensive  Security  Assessment."  IUB  Full  Text  Electronic  

Journal  List.  Ieeexplore.ieee.or,  Mar.-­‐Apr.  2010.  Web.  25  Oct.  2013.  

 

[16]Symantec  Corporation.  "Analysis  of  Mobile  Threats."  Symantec.com.  Symantec,  2012.  

Web.  5  Oct.  2013.  

<http://www.symantec.com/threatreport/topic.jsp?id=threat_activity_trends&aid=

analysis_of_mobile_threats>.  

 

 

 

 

 

[17]Yajin  Zhou,  Zhi  Wang,  Wu  Zhou,  Xuxian  Jiang,  "Hey,  You,  Get  off  of  My  Market:  

Detecting  Malicious  Apps  in  Official  and  Alternative  Android  

Markets,"  Proceedings  of  the  19th  Network  and  Distributed  System  Security  

Symposium  (NDSS  2012),  San  Diego,  CA,  February  2012  (17.8%).