Utilizing the Cloud to Store Hijacked Camera Images

Abstract Data Corporation (IDC), Android and iOS together

Mobile devices implementing Android operating account for, roughly, 96% of the operating systems
systems inherently encourage opportunities to create shipped on units [3]. The IDC report indicates that
and implement malicious software. This opportunity Android has the overall lead year-to-date on OS
increases as dissemination of the Android OS to market penetration.
standalone devices, such as cameras, increases. The Complicating matters, mobile devices are
problem intensifies when these devices utilize cloud increasingly being used for a range of personal and
storage service capabilities. Previous security and business related activities like checking emails, social
forensics research is focused on Android malware media interaction and banking transactions that,
detection, data leakage and operating system potentially, utilize third party applications. In 2012, a
modifications. In this research, malware was study by Bit9 states that 25% of the sampled apps,
developed and implemented on a camera running an more than 100,000 apps, have permissions that make
Android Operating System. The execution of this them suspicious from a security perspective [4]. A
malware successfully transferred images to a Juniper Networks press release states that the total
secondary cloud location without notifying the user amount of malware in their sample study increased
about the data transfer or raising noticeable by 614% from March of 2012 to March of 2013 [5].
indicators with an industry accepted mobile device This information raises more concerns when
analysis toolkit. The research contribution is an considered in conjunction with a 2014 McAfee study
initial empirical analysis of the viability of software that indicates that 70% of adult participants between
to divert an image and store it in a secondary cloud the ages of eighteen and twenty-one shared sexually
storage environment without alerting digital suggestive content through unsecured mobile devices
forensics software about the malicious nature of the [6]. Merging this information with escalating data
malware. capture capabilities in mobile devices and increased
research into anti-forensics activities fosters an
environment that is conducive to malware
development [7].
1. Introduction The problem is intensified by recent research
indicating that digital evidence, obtained from mobile
The proliferation and assimilation of mobile devices, is increasingly being utilized in legal context
devices continues to escalate in communication [8, 9]. When this information is considered on a
oriented societies. According to eMarketer, nine global context, the potential impact is enormous. A
countries will exceed fifty-percent smartphone security company reports that they discovered
saturation and just under one-quarter of the total spyware targeting Occupy Central protesters in Hong
population of the world will use a smartphone in Kong [10]. The report claims that software bears
2014 [1]. In support of this escalation trend, Gartner resemblance to existing android spyware, indicating
states that smart phone sales topped one billion units that there is the potential to develop code capable of a
worldwide in 2014 [2]. cross platform attack.
There are a large number of mobile device Due to trends in mobile device growth,
operating systems in the market that include, but are technology evolution, operating system migration
not limited to, Android, Symbian, iOS, BlackBerry and legislative reliance on device data, altering a
and Windows Mobile. According to the International device’s native functionality creates security risk for

1530-1605/16 $31.00 © 2016 IEEE 5497

5496
DOI 10.1109/HICSS.2016.679
individuals, corporations and digital forensics detection through Manifest and API calls [19] along
investigations. This concept prompted research into with a general characterization of malware [20].
the hypothesis that malicious software can be Grace et al [16] developed a solution to identify
developed to copy camera generated images from a zero-day Android application attacks. They achieved
Samsung camera with 4G capability running an this by developing a prototype application that
Android Operating System (OS) to a Dropbox cloud processed apps acquired from Android markets. They
service. It also stimulated a secondary hypothesis that processed 104,874 distinct apps and flagged 3,281
residual data from the malicious software is not distinct apps as high and medium risk apps. The
easily detectable by an industry accepted, mobile authors defined high risk apps as exploited platform-
device forensic toolkit. In order to address both of level vulnerabilities in software. Medium risk apps
these hypotheses, subsidiary research questions were contribute to financial loss or sensitive information
identified: disclosure. Low risk apps expose personal and device
 What components of the Android operating specific information. They considered low risk apps
system need to be utilized to capture image data milder than medium risk apps. Their research
and transfer data to an alternative cloud service? examines apps available from a global market
 What security restrictions need to be identified perspective. While this is important, it does not take
and circumvented to ensure appropriate access to into consideration issues from the point of view of
necessary functionality? apps that are installed on a device and the potential
 Is residual data created by the malware on the impact this has on capturing residual data.
camera and, if so, is that data detectable by an Huang et al [18] attempted to detect malware by
industry accepted mobile device forensic toolkit? examining the differences between the user interface
The research contribution is an initial empirical and the behavior of the application. They found in
analysis of the viability of software to divert an many cases that there was no discernable mismatch
image and store it in a secondary cloud storage between the Application Programming Interface
environment without alerting digital forensics (API) intent and the User Interfaced (UI). To improve
software. The paper is structured as follows: Section their results, they also examined program
two discusses relevant approaches to developing and dependencies among APIs. In their design section,
implementing mobile device malware. Section three they defined six intents that they were interested in
presents the methodology and the experimental examining that included install, phone calls, SMS
design. Section four discusses the implementation sending, HTTP Access, SMS Notification and UI
and results. Section five draws research conclusions operations. They also note that the detection of
and section six presents future work. implicit calls is possible through the implementation
of pre-defined patterns. As the authors noted, the
reliance on rules could allow incompatible intents to
2. Literature review be missed if they do not breach one of the existing
rules. The authors also noted that the current
As Android OS proliferation increases, it stands implementation relies on textual keywords and does
to reason that the attacks will escalate. A string of not address apps that use images.
Android related vulnerabilities have been exposed Wu et al [19] proposed a static analysis solution
over the past few years by other researchers [11]. for detecting malware on Android devices. The static
Femerling [12] catalogues a number of general information that is considered includes permission,
vulnerabilities to which smartphones, such as component deployment, API calls, and intent
Android, are susceptible. These vulnerabilities messages. Their application collects data from
include privacy risks, enabled debug code in the application manifest files, application API calls and
Dalvik debug monitor, and XSS. The ongoing quest then attempts to model malware capabilities by
to discover Android vulnerabilities continues to fuel applying K-means algorithms. Then it classifies the
research into Android browser apps vulnerabilities application as malicious or benign using a k Nearest
[13], attacks on the Android clipboard [14], and Neighbors (kNN) algorithm.
attacks against Android Smartphone USB Research by Zhou and Jiang [20] characterized
connections [15]. Android malware based on the installation, the
These vulnerabilities motivate research into activation mechanism and the payload. They
detecting leaks and zero-day attacks in Android identified three social engineering techniques that
malware [16, 17], to detect surreptitious behavior in hackers use to entice people to install infected
Android applications [18], and Android malware applications on devices. The techniques they
identified include repackaging, update attacks and

5498
5497
driven-by-download. They also identified malicious Schmidt et al [22] produced a detailed description
payload functionalities that include financial charges, of techniques that can be used to develop Android
privilege escalation, remote control and personal malware. These techniques take advantage of Linux
information stealing. Within the personal information applications and native operating functionality. They
collection functionality, they discussed capturing also point out the requirements needed to program a
phone numbers, SMS messages, and user account malicious application such as a hosting application
information to upload to remote servers. They did not and a trigger mechanism after installation. The
specifically discuss the capturing of images from a introduction of malware that utilizes cloud storage
mobile phone or a camera running an Android OS or further complicates investigations in an environment
storing that data in a cloud storage service. where researchers have already argued that these
To investigate malware detection, Zhou and Jiang situations are intrinsically difficult [23-25].
[20] installed Norton’s Mobile Security, Lookout These articles validate the interest in detecting
Security and Antivirus, and Trend Micro’s Mobile capability leaks, surreptitious behavior and malware
Security Personal Edition along with over 1,260 activity in mobile devices. However, there is minimal
malware samples on a Nexus One. It is interesting research or vulnerability discussion investigating the
that they determined that 1,083 of the samples were viability of implementing malware on a camera
legitimate applications that had been re-packaged to running an Android operating system that capitalizes
contain malware. Their experiment consisted of two on cloud storage service capabilities. In addition,
scanning rounds. For the first round they wait for there is no indication as to how this malware impacts
thirty seconds and then move to the next application. a mobile device investigation.
If the applications are detected to be infected by
malware the antivirus will produce an alert box 3. Methodology and experimental design
saying that there was something found. With the
completion of the first round, a second round is
This research aims to investigate the plausibility
conducted increasing the time to sixty seconds and
of developing malware for an Android Operating
only using the applications in which the malware was
System (OS) installed on a camera and utilizes the
not detected. The results show that each company
cloud for storage capture. The approach used in this
follows a different design and implementation
research utilizes a first complete pass at an iterative
process for their security software and, as a result,
implementation of a design science methodology that
produce different detection ratios. The results
follows the general activities as defined by Peffers et
indicate that some malware software is not detectable
al [26]. The high-level problem statement focuses on
by antiviruses. As the authors point out, it is plausible
the utilization of the cloud to store hijacked data.
that the malware that is not detectable is new and that
Refinement of this problem statement led to a
software companies have not yet identified a malware
more detailed design solution that focuses on the
signature in order to add it to the antivirus detection
development of malware that is designed to divert
system. They also indicate that malware is rapidly
images to a secondary cloud location without
evolving and that solutions are lagging.
notifying the user of the data transfer. The camera
Davi et al [21] discusses conceptual issues with
used in this experiment was a Samsung Galaxy
the Android OS security model. They point out that
GC100 Digital Camera running a 4.1 Jelly Bean
the Android OS security model is based on
distribution of the Android OS. The research also
application-oriented mandatory control and
uses an industry accepted toolkit to examine the
sandboxing which allow the user and developer,
camera for residual data that may alert an examiner
alike, to limit the execution rights given to an
that there is a potential issue with the software on the
application upon installation. They conducted an
device. Any tool could have been chosen for the
experiment with a specific software configuration
examination of the residual data. As a matter of
that demonstrates the possibility of implementing an
convenience, XRY (Version: 6.10.1) was used in this
escalation privileged attack. In addition, their
experiment.
configuration points out that the permissions given to
The refinement of the objectives included
an application can be increased by a malicious
investigating the OS installed on the device to
application or runtime exploitation of a legitimate
understand the basic functionality that is natively
app. The results they obtained indicate that the
available and to begin to identify potential issues that
security model can be compromised by a privileged
would hinder application development. This was
escalation attack and that sophisticated runtime
achieved by acquiring a Samsung Digital camera;
attacks present issues for this particular sandbox
inspecting the device and the documentation that
model.

5499
5498
accompanied the camera. Identifying the version of network to obtain access to the Internet. A separate
the device’s Android OS focused review efforts on computer was used to create and configure the
relevant online Android development documentation. hacker’s Dropbox cloud storage service.
The investigation into the documentation indicated The Dropbox Developer’s website was accessed
that the easiest way to hijack the image, which is to create the hacker’s application in the App Console.
being generated by the camera, is to capture and The application’s Key and Secret were then added to
dissect the intent that is created when a picture is the malware in order to start the authentication
taken. process once it starts-up on the device. The malware
The refinement stage involved validating XRY was loaded onto the camera using Eclipse JUNO. The
compatibility. In doing so, the device was reset to project (CamSurv) runs on the device as an Android
factory settings to wipe any preliminary data that application. After the automatic start-up, the hacker’s
might have been residing on the device. The set-up authentication information and Dropbox password
settings were completed, i.e., date, time and location. were inserted once the authentication page was
The developer option was selected in order to displayed.
activate the USB debugging option. The camera was The evaluation activity implemented a device and
connected to the device using the ‘Camera’ data manipulations along with examining the camera
connection in the USB connection options. This using an industry accepted forensic toolkit. Initially,
option allows for the transfer of photos using camera the malware was implemented and pictures were
software, as well as, the transfer of any files onto the taken to verify that the software was functioning
PC. Three photos were taken within the forensic properly. The device then underwent a number of
Laboratory at the University of (Removed for manipulations to test the impact of these activities on
Review). XRY was previously installed on a lab PC. the malware. For this experiment, the following states
XRY was then used to extract data from the camera. were defined and associated activities were
The preliminary examination revealed that the implemented:
camera was functioning correctly and that XRY was  Active power state – In this state, the device is
able to extract data from the camera. not powered down and the application cache is
The design and development consisted of two not cleared. Multiple pictures were rapidly taken
phases. The first phase focused on the owner of the with the camera in an active power state.
camera. The camera is reset to factory settings in  Standby state - The device is put into standby
order to minimize residual data that was left on the mode for two minutes. It is then taken out of
device from previous activities. The cloud storage standby mode and a picture is taken.
location was created and configured for the owner of  Powered off state - The device is powered off
the account. The camera was then configured to and then powered back up again. Then pictures
connect to the University’s wireless network to gain are taken with the device.
access to the Internet. After the connection was tested  Battery removal state- The battery is removed
by navigating to a Google search page, the camera and re-inserted into the device. The device is
was configured to connect to the owner’s account and powered-up and a photo is taken.
account synchronization was enabled. A number of The pictures also underwent manipulations to test
sample pictures were taken in order to test the native the impact of these activities on the malware
functionality of the camera. The pictures were functionality. In doing so, pictures were renamed and
verified by accessing the owner’s Dropbox account pictures were deleted. The photos on the device were
from a separate computer. The photos were then verified with the photos on the owners cloud and
downloaded from the Dropbox account onto a the hijacked cloud by generating and comparing hash
computer and copied from the camera using a USB values. In the event that normal hash values were
connection to the same computer. They were different, a fuzzy hashing could be used to determine
imported into FTK, hash values were generated for the percentage of the match between them.
all of the files and the results were compared. Once these manipulations had been completed, a
The second phase concentrated on the hijacking forensic analysis of the camera was conducted. The
of the camera. The solution for capturing the images camera was connected to the XRY toolkit using a lab
was developed in this phase. The camera is, again, computer. A logical extraction of the data on the
reset to factory settings in order to minimize residual camera was conducted using XRY. After the
data that was left on the device from previous extraction is completed the results are examined in
activities. The owner’s Dropbox account information detail in order to determine if the XRY can detect the
was added back to the device. The camera was malware application and the hacker’s Dropbox
reconfigured to connect to the University’s wireless account. A physical extraction of the camera was

5500
5499
conducted using XRY. After the physical extraction internet in order to upload the data to the alternative
was completed, the results were compared with the cloud. Figure 2, Manifest permissions, presents the
results from the logical extraction. permissions declared in the malware program.
It should be noted that this research is a proof of The INTERNET permission was used to gain
concept intended to investigate the development of access to the Internet in order to upload the picture to
hijacking software for a camera running Android Dropbox. The CAMERA permissions and the
version 4.1. Hence, other versions of the Android hardware camera feature were established so that the
Operating System (OS) along with other OS’s were broadcast receiver could catch the picture intent when
considered out of scope for this experiment. This it was broadcasted by the system. A quick inspection
experiment focuses on the capturing of images and of the Android manifest permission revealed that there
the data transfer of those images; not the loading of is not an obvious entry for reading internal storage
the software onto the device. [27]. Hence, the READ_EXTERNAL_STORAGE
Hence, for the purposes of this research, it is was used to detect the photo in the internal storage
assumed that the attacker will have physical access to and convert the Uniform Resource Identifier (URI) to
the camera for a few minutes to install the malicious the corresponding system path detailing the photos
software. The overall flow is presented in Figure 1, saved location.
Attack flow. For matters of convenience, Wi-Fi
connections were used for testing. The Dropbox is
the default cloud service for the device. For
simplicity, this service was utilized for the original
owner and a separate Dropbox account was set-up for
the hacker. It is presumed that seeing an additional
Dropbox account on a device will not raise
suspicions as quickly as discovering other accounts.
All other device interactions and various other cloud
storage application solutions are considered out of
scope for this experiment.

Figure 2. Manifest permissions

The introduction of the manifest permission for

RECEIVED_BOOT_COMPLETED was added after
a problem with the malware was detected in reference
to powering the device down and back up again. The
Figure 1. Attack flow permissions for ACCESS_FINE_LOCATION and
ACCESS_LOCATION_EXTRA_COMMANDS,
were added in anticipation of examining possibilities
4. Implementation and results to capture Global Positioning System information.
The permission to WRITE_EXTERNAL_STORAGE
The software was developed as a standalone was added to ensure that the program could write to
application. It was specifically developed for the cloud service storage area.
Application Programming Interface (API) 16 which
implements Android 4.1, also known as Jelly Bean.
4.2. Broadcast receiver
The application was developed with a custom
launcher icon and an empty activity. These options
were a necessity in order for the application to be In order to copy the image, the intent associated
installed and run on a camera and the Android Virtual with the image needed to be captured. The broadcast
Device (AVD). The following sections present receiver was used to achieve this by declaring intent
essential parts of the code in detail. filters in the manifest. Intent filters stipulate the intent
types to which a service, activity or broadcast receiver
can respond [28]. Figure 3, Broadcast receiver Intent
4.1. Permissions
Filter, presents the intents that were necessary for the
program to function.
A number of permissions were declared in the The Broadcast Receiver works by initially
manifest of the malware in order for it to function catching the intent and then extracting the Uri
properly, copy the image taken and gain access to the

5501
5500
information from the received intent. Initially, the Figure 6 presents the code that was implemented to
broadcast receiver was not able to catch the intent. upload the image to the hacker’s Dropbox.
This was solved by adding a line of code that The Dropbox authentication process is executed
referenced the android priority. Android’s order of when the malware is installed on the device. A new
execution for synchronous messages to broadcast intent is created in the MainActivity class and the
receivers is determined by propriety values [28]. Authentication class is called by starting a new
Those with the higher values are executed first. In this activity. The Main activity path is shown in Figure 7,
case, android:priority=”999” was added in the Main activity class.
declaration of the intent filter.

Figure 5. Path method

The classes associated with the Uploading of the

Figure 3. Broadcast receiver intent filter image and Authentication of the application were
derived from the Dropbox SDK examples which are
It then creates a new intent and adds the Uri provided as guidance in the corresponding Dropbox
information as extra data and sends it to the Intent SDK folder.
Service class which uploads the image to Dropbox.
Figure 4, Broadcast receiver class, presents the code
utilized in the Broadcast Receiver class.

Figure 6. Image upload method

In order for the authentication process to occur,

Figure 4. Broadcast receiver class Dropbox authentication information is required inside
the manifest. In addition, the Authentication class
needs to be declared in the manifest with the
4.3. UpServ class – intent service corresponding actions. The code that is needed for the
manifest is displayed in Fig 8 Dropbox authentication.
This class is where the upload of the image
happens. The class is fired up as soon as the intent is
received from the Broadcast receiver. The Uri
information is extracted from the intent and is
converted to the corresponding path on the device
using the getPath method.
After this process is completed, a new file
containing the image is created and then uploaded to Figure 7. Main activity class
the alternative Dropbox account using the upload
Upon code development completion, the
class. Figure 5, Path method, presents the code that
experimental design was executed as described in
was implemented to acquire the storage location.
section three. To validate the native functionality of

5502
5501
the camera, three photos were taken to test the amount of data that it received in a very short period
owner’s configuration. Once this was completed, the of time.
malware was loaded onto the camera and ten photos
were taken to test the malware’s functionality.
The photos located on the camera are displayed
YYYYMMDD_HHMMSS.jpg and those located on
Dropbox are displayed YYYY-MM-DD
HH.MM.SS.jpg. A visual inspection of the phone’s
images, the images stored in the owner’s cloud and
the images stored in the hacker’s cloud indicated that
they were the same images. The only discernable
difference between the images on the device and the
images in the cloud is the way their names are
displayed. Although there is a difference in the names
of the photos, a hash value comparison of the images
using FTK version 5.0 confirmed that they were the
same files. The images taken by the camera and
transferred to both the owner’s account and the
hacker’s account are displayed in Figure 9, Owner’s
Dropbox, and Figure 10, Hacker’s Dropbox.
Figure 9. Owner’s Dropbox

The powered off and battery removal states did

present a problem for the malware. The reboot of the
device did prompt the user of the camera to re-
authenticate to the drop box as displayed in Figure 11,
Dropbox camsurv authentication.

Figure 8. Dropbox authentication

The third step in the methodology focused mainly

on code development. The fourth step tested the
functionality of the malware that was being developed
from the perspectives of device and data
manipulations. If the pictures were taken in slow
intervals, the malware performed as expected in an
active power state.
The malware functioned properly when the device
was put into standby mode and then returned to an
active power state. In other words, in both Active
Power and Standby states, the pictures were transfer
successfully to both the owner’s and the hacker’s Figure 10. Hacker’s Dropbox
accounts without visually notifying the operator. During malware testing it was discovered that
It should be noted that if the images were taken in when the camera was not plugged into the power
rapid succession manually, this created a problem adaptor the camera, by default, uses a setting called
with data transfer over the Internet connection. The "Fast power-on". It is located in the Settings > Power
pictures were transferred but it took notably longer for > Power On option. This option appears to use a
the upload to take place. If the option in the device speedy start-up process for up to 24-hours and does
settings was set to take multiple photos, the not look as if it sends a BOOT_COMPLETED when
application crashed. It did not successfully handle the the device is started.

5503
5502
 Limited information regarding how the fast related URL, as well as where it was stored. The tool
power-on works or how to programmatically disable it identified that all of the applications were installed on
is available in the Android development environment. the Device. An external SD card was not used in this
With insufficient information in reference to its experiment.
functionality, it was manually disabled for the There was no indication from the tool that there
purposes of this experiment. The manual disabling was a potential issue with the software residing on the
was done during the set-up of the camera for each device. The logical extraction did find the application
phase. but there was nothing to indicate that it was
potentially malicious. The physical extraction
detected the application as well as the owner’s
account. It did not, however, report the hackers
account. It did report the permissions that were given
to the application when it was installed as displayed in
Figure 12, Physical - installed apps permissions.
It is also interesting that the physical extraction
detected the owner’s account information but did not
display any information associated with the hacker’s
Dropbox account. The information detected for the
owner’s account is displayed in Figure 13, Physical –
owner’s Dropbox account.
Figure 11. Dropbox camsurv authentication
The image manipulations did not affect any of the
Dropbox accounts. When the picture was renamed on
the device neither cloud account was affected by this
change. The same occurred with the deletion of the
picture on the camera. The manipulations that were
conducted on the pictures only affected the images on
the device because the photos had already been
transferred to both Dropbox accounts. There was no
auto-update software functionality implemented in the
default Dropbox camera software. Hence, any Figure 12. Physical - installed apps
manipulation that occurred later had no effect on permissions
either account. From an investigation perspective, it is An examination of the Web related findings did
interesting to note that there can be differences not readily reveal references to the malware camera
between the names of the artifacts on the device and application. Eleven cookies were identified that
the data stored in the owner’s cloud storage account. related to the Dropbox application and one to Google.
More importantly, the results indicate that data hastily However, there were no cookies that specifically
deleted from the device and/or, possibly, overwritten referred to the malware application. A detailed
could still be resident in the cloud storage account due analysis did reveal that the modified time on the
to the native functionality of the software. cookies was very close to the modified times of the
The last stage examined the camera from a digital photos in the hackers account.
forensic perspective. Both physical and logical data
extractions were conducted on the camera using XRY.
XRY, in total, recovered 194 Device/Installed
applications. The Device applications category
includes the system application such as the System
UI, the Android System itself, the certification
installer, the input devices, the key chain and much
more.
The applications that were actually installed on the
device included the web browser, Google Play Books,
Dropbox and the malicious application. It is worth Figure 13. Physical – owner’s Dropbox
mentioning here that the forensic tool retrieved the accounts
Package name for each application along with the

5504
5503
5. Conclusions Residual data is created by the malware on the
camera simply by installing the software on the
The impact of malware on individuals, device. However, the preliminary examination of the
corporations, governments and digital investigations device by an industry accepted mobile device forensic
is an increasingly challenging and multifaceted topic. toolkit indicates that there is minimal detection of the
Environmental complexity coupled with technical software or the connections established by the
opportunities to compromise applicants potentially malicious software. The initial results do indicate that
puts individuals and employees at risk while permission information and software installs could,
simultaneously inhibiting forensics investigations. potentially, be used as an indicator to the investigator
The results from this research demonstrates that it that there is something suspicious in reference to the
is possible to develop an Android application that software installed on the device. At the moment, the
hijacks an image produced by a 4G enabled Samsung tool provides minimal additional information to
camera. It also demonstrates that it is possible to support further conjecture.
utilize cloud storage services as a storage location for
this activity. More importantly, it raises the question 6. Future work
of the appropriateness of current forensic tool
functionality. Future research will examine the implementation
The forensic tool used in this experiment of the malware on multiple devices to attempt to
performed both a logical and a physical extraction of identify indicators that can be used by practitioners to
the camera. Neither extraction technique highlighted alert them to a potential issue with the software
to the examiner that the applicants on the device could installed on the device. Future work will build off of
be potentially malicious. Even if the analyst suspected the development of this application and focus on the
that there was something malicious on the device, use of the cloud to propagate the malware to other
they would be forced to investigate the device mobile devices. This involves the investigation of
manually or use additional tools to search for specific effectively embedding the malware into a file that is
code or applications. If it was discovered at all, this uploaded to the owner’s cloud storage service. When
would also require a manual interpretation of the code the file is downloaded by the owner for use on a
or application which increases the overall cost and the smartphone, tablet or other devices utilizing an
time commitment involved in the investigation. Android Operating system so that it will automatically
Without automated forensics tool detection, manual install and connect to a hacker’s storage service. This
discovery is tied to the ability of the analyst, which is will include investigating effective triggers for
highly variable. installation. This includes investigating the viability of
The research demonstrates that it is possible to cross-platform malware development.
develop an application that resides in the background Future work in this area forces the idea that
and transmits copies of images to a cloud storage research should focus on investigating ways to
service without visually notifying the user of the implement effective and intelligent digital forensics
device. The components of the Android operating analysis. Intelligent digital forensics needs to
system that need to be utilized to capture image data investigate the integration of improved policies,
and transfer data to an alternative cloud service standards and procedures regarding investigation
include the intents associated with the camera button, processes from the individual, the business, and the
cloud service set-up, cloud service authentication and cloud service provider perspectives. It also needs to
the image itself. More specifically, the permission investigate the amalgamation of artificial intelligence
needs to be defined in the manifest, a broadcast algorithms.
receiver needs to be instantiated, authentication to the
hacker’s Dropbox account is necessary and up-load
methods must be established.
7. References
The security restrictions that need to be identified
and circumvented to ensure appropriate access to [1] eMarketer. Worldwide Smartphone Usage to Grow 25%
in 2014. 2014; www.emarketer.com/Article/Worldwide-
necessary functionality are detailed in the manifest.
Smartphone-Usage-Grow-25-2014/1010920.
The application needs access to the camera so that it
can be notified when a picture has been taken. The [2] Gartner. Gartner Says Smartphone Sales Surpassed One
application needs access to the Internet to connect to Billion Units in 2014. 2015; www.gartner.com/newsroom.
the hacker's cloud and it needs the ability to write to
external storage.

5505
5504
[3] International Data Corporation. Press Release: Android [16] Grace, M., et al., RiskRanker: scalable and accurate
and iOS Squeeze the Competition, Swelling to 96.3% of the zero-day android malware detection, in Proceedings of the
Smartphone Operating System Market for Both 4Q14 and 10th international conference on Mobile systems,
CY14, According to IDC 2015; www.idc.com/. applications, and services. 2012, ACM: Low Wood Bay,
Lake District, UK. p. 281-294.
[4] Bit9, Pausing Google Play: More Than 100,000
Android Apps May Pose Security Risks. 2012. p. 14. [17] Grace, M., et al. Systematic Detection of Capability
Leaks in Stock {Android} Smartphones. in Proceedings of
[5] Juniper Networks Inc. Juniper Networks Mobile Threat the 19th Network and Distributed System Security
Center Third Annual Mobile Threats Report: March 2012 Symposium (NDSS). 2012. San Diego, CA, USA.
through March 2013. 2013; www.juniper.net.
[18] Huang, J., et al., AsDroid: detecting stealthy behaviors
[6] McAfee. Study Reveals Majority of Adults Share in Android applications by user interface and program
Intimate Details Via Unsecured Digital Devices. 2014; behavior contradiction, in Proceedings of the 36th
http://www.mcafee.com/us/about/news/2014/q1/20140204- International Conference on Software Engineering. 2014,
01.aspx. ACM: Hyderabad, India. p. 1036-1046.

[7] Karlsson, K.-J. and W.B. Glisson, Android Anti- [19] Dong-Jie, W., et al. DroidMat: Android Malware
forensics: Modifying CyanogenMod, in Hawaii Detection through Manifest and API Calls Tracing. in
International Conference on System Sciences (HICSS-47). Information Security (Asia JCIS), 2012 Seventh Asia Joint
2014, IEEE: Waikoloa, Hawaii Conference on. 2012.

[8] McMillan, J., W.B. Glisson, and M. Bromby, [20] Zhou, Y. and X. Jiang. Dissecting Android Malware:
Investigating the Increase in Mobile Phone Evidence in Characterization and Evolution. in Security and Privacy
Criminal Activities, in Hawaii International Conference on (SP), 2012 IEEE Symposium on. 2012.
System Sciences (HICSS-46). 2013, IEEE: Wailea, Hawaii.
[21] Davi, L., et al., Privilege Escalation Attacks on
[9] Berman, K., W.B. Glisson, and L.M. Glisson, Android, in Information Security, M. Burmester, et al.,
Investigating the Impact of Global Positioning System Editors. 2011, Springer Berlin Heidelberg. p. 346-360.
(GPS) Evidence in Court Cases, in Hawaii International
Conference on System Sciences (HICSS-48). 2015, IEEE [22] Schmidt, A.D., et al., Smartphone malware evolution
Kauai, Hawaii revisited: Android next target?, in Malicious and Unwanted
Software (MALWARE), 2009 4th International Conference
[10] Borrov, O. Lacoon Discovers Xsser mRAT, the First on. 2009. p. 1-7.
Advanced Chinese iOS Trojan. 2014;
www.lacoon.com/lacoon-discovers-xsser-mrat-first- [23] Biggs, S. and S. Vidalis. Cloud Computing: The
advanced-ios-trojan/. impact on digital forensic investigations. in Internet
Technology and Secured Transactions, 2009. ICITST 2009.
[11] National Institute of Standards and Technology. International Conference for. 2009.
National Cyber Awareness System: Vulnerability Summary
for CVE-2014-1939. http://web.nvd.nist.gov/. [24] Grispos, G., T. Storer, and W.B. Glisson, Calm Before
the Storm: The Challenges of Cloud Computing in Digital
[12] Femerling, S.R., Smartphone Apps Are Not That Forensics. 2012, IGI Global. p. 28-48.
Smart: Insecure Development Practices. 2012, Vulnex.
[25] Taylor, M., et al., Digital evidence in cloud computing
[13] Wu, D. and R.K.C. Chang, Analyzing Android systems. Computer Law & Security Review, 2010. 26(3): p.
Browser Apps for file:// Vulnerabilities, in Information 304-308.
Security Conference. 2014, SpringerLink: Hong Kong.
[26] Peffers, K., et al., A Design Science Research
[14] Zhang, X. and W. Du, Attacks on Android Clipboard, Methodology for Information Systems Research. J. Manage.
in Detection of Intrusions and Malware, and Vulnerability Inf. Syst., 2007. 24(3): p. 45-77.
Assessment, S. Dietrich, Editor. 2014, Springer
International Publishing. p. 72-91. [27] Android Developer. Manifest.permission.
http://developer.android.com/reference/android/Manifest.pe
[15] Pereira, A., M. Correia, and P. Brandão, USB rmission.html.
Connection Vulnerabilities on Android Smartphones:
Default and Vendors’ Customizations, in Communications [28] Android Developer. <intent-filter>.
and Multimedia Security, B. De Decker and A. Zúquete, http://developer.android.com/guide/topics/manifest/intent-
Editors. 2014, Springer Berlin Heidelberg. p. 19-32. filter-element.html.

5506
5505