1 Introduction

Terrorism can be defined as “the use of violence by groups or individuals pursuing political objectives. Terrorists are frequently indiscriminate in their attacks and can deliberately target civilians and non-combatants, often seeking to inflict mass casualties” [1]. While smart mobile devices are increasingly popular with both individuals and businesses, their usage can be criminally exploited to facilitate terrorist activities, including financing of terrorism [2, 3].

A recent example of a mobile forensic challenge in terrorism investigations is the difficulty faced by the Federal Bureau of Investigation (FBI) in acquiring assistance from Apple Inc. to unlock an encrypted iPhone 5C [4]. It was alleged that this phone belonged to one of the key suspects, and the suspect had disabled iCloud backups several weeks prior to the incident. The challenges in this particular incident also demonstrate the potential role of mobile forensics in providing evidential data from mobile devices due to the use of the devices and their apps during terroristic activities, in particular, or other criminal activities in general.

Examining artefacts from mobile cloud services and mobile communication channels, including communication apps and emails, can provide useful information to reconstruct terrorist activities. This information is important for law enforcement in their investigation. Information such as chat logs, multimedia files, contact lists, and geo-tagged data can be used to determine the chain of events and identify terrorists and their associates.

Cloud storage apps are regularly used for file synchronisation and sharing activities. They are also commonly used to automatically backup a user’s device. For example, Android Backup Service uses Google Accounts (e.g. Google Drive, Google Photos) to back up a user’s data. As a result, this approach potentially leaves evidential data on both the cloud user’s device and the cloud provider’s storage area. Thus, new and/or refinements in mobile device digital evidence collection procedures are required. In this study, we demonstrate how our previously published integrated incident handling and digital forensics model can be used to guide a mobile forensic investigation [5]. The model consists of the following phases:

  1. (i)

    Preparation and forensic readiness: Getting prepared with strategies and tools.

  2. (ii)

    Identification: It commences after a suspicious event is detected and reported.

  3. (iii)

    Assessment, forensic collection and analysis: Initial assessment is conducted to decide the scale of forensic analysis and appropriate response actions.

  4. (iv)

    Act and monitoring: Involves containment and eradication activities of cybersecurity incidents.

  5. (v)

    Recovery: Involves restore system disruption to normal and in a secure state.

  6. (vi)

    Evaluation and forensic presentation: Delivering findings and recommendations.

2 An overview of terrorism activities and mobile forensics

As mobile devices continue to integrate into all aspects of society, it is conceivable that the importance attached to mobile device investigations will continue to escalate. The plausibility of this escalation coupled with increasing legal implications prompts the examination of information and communications technologies (ICT) and computing devices from the perspective of terrorist related activities. It also prompts an inspection of relevant research activities in mobile device forensics.

2.1 Terrorism

It is important to understand the common terrorist-related activities and how the emerging ICT, such as mobile computing infrastructure, affects them. Terrorist-related activities can be broadly classified into (1) information propagation, (2) information concealment, (3) fund raising, and (4) recruitment and training [6–8].

Information propagation concerns with the creation and dissemination of politically – or ideologically – motivated propaganda with the aims of influencing a particular segment of the community, radicalising potential supporters, and inciting “naïve” individuals to conduct terrorist and other criminal activities [7–9]. The dissemination use multimedia objects (e.g. videos, audios), usually via social media services such as social network sites, online forum, online games, video-sharing sites, and file-sharing sites.

Information concealment involves the misuse of (secure) communication platforms to disseminate information to circumvent law enforcement scrutiny and existing surveillance tools [10]. A method that can be used to conceal messages is steganography. A straightforward stenographic method modifies the least significant bit to hide messages within other forms of digital communication by embedding the true message within digital objects, such as text, image or audio [11]. The advancement of mobile device capabilities, coupled with the availability of freeware steganography, makes obscuring the true message from these devices very easy. Message obfuscation makes it difficult to identify and trace illegal communications regarding general activities and financial dealings.

Fundraising refers to the collection of funding to support terrorism and related operations. Source of funding includes donations from supporters, diverting funds raised by legitimate means (charity donations), and proceeds of crime [7, 12, 13]. The collection would come from a number of channels such as donations from supporters, money laundering approach from charitable institutions but diverted for terrorist intentions, and underground activities [8, 14]. Meanwhile, recruitment of terrorist members includes reaching out, communicating, influencing and radicalising like-minded individuals by utilizing ICT (e.g. social networking sites) [6].

The ease in which information is disseminated and hosted on devices coupled with the availability of tools to hide secret messages, plausibly, increases the effectiveness of terrorist fundraising and recruitment activities. Therefore in this paper, we focus on identifying artefacts that can be found in mobile devices after they were used in activities that are related to information propagation and concealment.

2.2 Mobile forensics

As defined by the National Institute of Standards and Technology (NIST), “[m] obile device forensic is the science of recovering digital evidence from a mobile device under forensically sound conditions using accepted methods” [15]. Data acquisition in mobile forensic activities involves physical, logical, and manual methods. Physical acquisition refers to recovering binary representations of the internal memory of mobile devices and dumping them into files, while logical acquisition interacts with a mobile device’s operating system to recover the logical objects stored in the file system [16]. Manual acquisition involves viewing the data content stored on a mobile device that requires manual manipulation of the buttons, keyboard or touchscreen and may be recorded using an external digital camera [15].

Existing mobile forensic research can be broadly classified into: (1) examining the capabilities of acquisition methods, (2) undertaking detailed forensic procedures, and (3) conducting in-depth forensic analysis of mobile apps or mobile operating systems.

In examining acquisition methods, Tassone et al. [17] demonstrated that mobile forensic tools have different capabilities in recovering artefacts from different mobile Operating Systems (OS). The authors indicate that the amount of artefacts recovered varies for different OSs and that specific tool support for physical acquisitions of certain phone models is not always present. This is consistent with Glisson et al.’s [18] study, which concluded that there is a considerable variation in recovery results between recovery methods and among toolkits. They acknowledge that this variance can be caused by vendors having different designs, overall software engineering requirements, and practical implementation decisions. The authors go on to highlight the fact that this variance makes it, potentially, difficult to validate artefacts recovered by different toolkits. One study on Windows Phone devices highlights a number of challenges in data acquisition on the three phones with this operating system, includes unrecovered deleted contacts and messages in the physical acquisition process, and impact of reset operation on the acquisition result [19].

The implementation of specific procedures and techniques in digital forensic investigations ensures that evidence can be acquired in a forensically sound manner. Using several cloud storage services such as Amazon S3, Dropbox, Evernote, and Google Docs as case studies, Chung et al. [20] utilised iPhone backup files and rooted Android devices to collect evidence of interest. Based on McKemmish’s framework [21], Martini et al. [22] proposed an evidence collection and analysis methodology for Android devices with detailed processes in the collection phase. Ariffin et al. [23] presented an operational technique to recover deleted image files by examining an iOS journaling file system. Leom et al. [24] demonstrated that the forensic collection and analysis of thumbnails in an Android Operating System (OS) would be significant for investigating steganography imagery.

Recent research by Berman et al. [25] and McMillan et al. [26] indicate that the introduction of GPS and mobile device artefact evidence is escalating and impacting court cases. Hence, the legal relevance, from an evidentiary value perspective, is, generally, based on the ability to locate and extract residual data in a forensically sound manner.

The relevance and admissibility of residual data is dependent on an in-depth forensic analysis of extracted artefacts. An analysis of mobile cloud apps by Martini et al. [22] on Android; and Grispos et al.’s [27] analysis on both iOS and Android identified various types of evidence artefacts along with their locations on the devices’ file system. Al Mutawa et al.’s [28] research showed different extraction results from social networking apps such as Facebook, Twitter, and MySpace found on Blackberry, Android, and iPhone. The authors observed that no traces of social networking activities could be recovered from Blackberry devices whereas, iPhone and Android phones stored significant amounts of evidentiary data. Farhood et al. [29] examined social network app artefacts left in Android’s internal memory and iOS’s internal storage that produced evidence of interest which include login, username, password, name, contact information, profile picture, work and education, location, friend list, posts, messages, comments, and IP addresses.

Focusing mainly on the in-depth forensic analysis of the artefacts left by WhatsApp messenger, Anglano [30] demonstrated how to interpret the data stored in the contacts and chat databases in order to reconstruct the list of contacts and the chronology of the messages that have been exchanged by the user. Another study emphasised an in-depth analysis to produce a taxonomy of artefacts. Azfar et al. [31] examined 40 popular Android mHealth apps and proposed forensic taxonomy that comprises databases, user credentials, personal details of users, user activities, user location, activity timestamps, and images.

Sgaras et al. [32] analysed WhatsApp, Viber, Skype, and Tango in Android and iOS that produced target artefacts such as installation data, traffic data, content data, user profile data, user authentication data, contact database, attachment or files exchanged, and location data. Most of the studies were highlighted to simulate common user activities to the particular applications and examine the evidentiary values of these artefacts. Glisson et al. [18] actually acquired devices from secondary markets to mimic situations faced by a forensic investigator when recovering data from an unknown device. Conducting common activities through social networking applications such as logging into apps, modifying personal information, uploading posts, uploading photos, posting comments, sending emails, and chatting promotes a real-world understanding of the artefacts that are generated from these activities [28, 29].

The literature clearly presents the extent to which acquired artefacts depend on acquisition techniques, types of mobile operating systems, and support features of forensic tools. This research indicates that file system architectures require particular techniques that pose challenges in mobile forensic investigations. It also indicates that the validation of extracted artefacts is not a trivial undertaking. Therefore, an in-depth understanding of acquisition techniques, a file system’s architecture, forensic tools features, an artefact’s taxonomy, and the users’ activities that trigger cybersecurity incidents are key points that need to be acknowledged and addressed in effective investigation practices. Understanding these points will aid in the development and re-construction of event scenarios.

3 Experimental environment

The benefits to these event scenarios were investigated through a series of exploratory controlled experiments as defined by Oates [33]. In these experiments, mobile devices were used to act as a sender and a receiver for both Android and Windows platforms. Details of the hardware and software utilized in these experiments are available in Table 1.

Table 1 Hardware and software specifications
Full size table

It should be noted that the Samsung devices were tested with the Android OS and the Nokia devices were tested with the Windows OS. Addition information pertinent to the experiment is that, for all of the experiments, the Samsung P3100 was always the sender and the Samsung 9300 was always the receiver.

Our experiments simulate three scenarios of common terrorism activities: (1) information propagation activities that use public cloud storage services, (2) information concealment activities that are associated with steganography apps, and (3) communication using available communication apps and emails. Data acquisitions were conducted at the end of each scenario to ensure that all residual data are acquired for a particular scenario.

In the first scenario, Sender (S) prepares files and saves them in a phone for further actions. The files are uploaded to particular cloud storage services. At Receiver (R) side, R runs two activities in accessing the files: (i) read files without download, and (ii) download files to a phone and read. After we conducted data acquisition on S devices, S started to clear his traces by uninstalling cloud storage apps and clearing browsing data; then we conducted data acquisition again on these devices.

For the second scenario, a steganography technique is used to hide secret messages. S prepares image files and they are processed using a steganography tool (i.e. Stegais). S send the image files with and without saving it to phone’s internal memory. Then the files are sent using cloud storage service (i.e. OneDrive), email (i.e. Gmail for Android device and Outlook for Windows Phone device) and messaging (i.e. WhatsApp) application. Similar to the information propagation scenario, R access the stego files with and without downloading the files.

These two scenarios, mainly, involve cloud storage apps and a pre-defined dataset containing 246 files which were created to be used in these scenarios. Information pertaining to the file types, file formats and the number of files for each file format is available in Table 2. The dataset used in both of these scenarios is Govdocs1 and is downloadable from the DigitalCorpora server (in http://digitalcorpora.org/corp/files/govdocs1/).

Table 2 Dataset
Full size table

During these scenarios, five files were downloaded for each format and the remaining files were read on the cloud storage. This translates into a total of 50 files being downloaded and 196 files being read on the receiver’s side.

The third scenario involves communication apps where common communication activities, such as adding a friend, conducting chat conversations and sharing media content were simulated. Network packets were captured on the receiver side after connecting the receiver’s phones to a hotspot.

The high-level mobile device acquisition process implemented in this experiment is illustrated in Fig. 1. The details of an initial inspection and manual acquisition procedures are presented in Figs. 7 and 8, Appendix A. Initial inspection refers to early examination of a device’s condition by collecting information such as manufacturer of device, model name and International Mobile Equipment Identification (IMEI) number.

Fig. 1
figure 1

Acquisition procedure

Full size image

The device’s power status was used to determine which acquisition technique to implement. If the device was powered on and functioning, a logical acquisition was conducted using XRY. The logical acquisition focused on the identification of missed calls and unread messages along with associated date/time stamp information. Once the logical acquisition had been conducted, a physical acquisition was attempted on the device using XRY. If XRY did not support a physical acquisition of the device then a manual acquisition of data on the device was conducted. Manual examinations were conducted through direct interaction with the device’s screen. To mitigate data alteration risks in powered on mobile devices, the flight mode was enabled and the GPS receiver on these devices was disabled. This acquisition utilized video recording and/or photography to capture important data which could become digital evidence.

For example, in our experiments, we identified that the Android sender’s device was not supported for physical acquisition. It should be noted that the device was rooted before the manual acquisition started. A rooting approach is applied to show that the sender’s account information is available and that there is a need to develop a proper method to acquire this information in a forensically sound manner. We are, however, aware that data alteration issues might occur when rooting a device.

If the device was powered off, a physical acquisition was attempted at the beginning. If XRY did not support a physical acquisition of the device, a manual acquisition of the data was conducted. In the real-world, manual acquisitions are optional if results from logical acquisition are limited and/or physical acquisition is not supported. However, for the purposes of this research, combinations of all three acquisition procedures (physical, logical and manual) were applied in this study; where manual acquisition was utilised to complete the result of logical acquisition, to confirm data validity of physical acquisition result.

4 Findings

The experimental finding are presented from the perspectives of information propagation, information concealment and information communication.

4.1 Information propagation

A description of the successful actions of upload, read and download files are presented in Fig. 2. The actions were executed using both mobile client apps and mobile web browsers. Observation for Google Drive on mobile web browsers is discarded as the interface does not display properly in both Android and Windows’ Phones. Additionally, a mobile client app for Google Drive is not available in the Microsoft Apps store.

Fig. 2
figure 2

Upload and download activities

Full size image

In Android devices, all file types and formats can be uploaded using both mobile client apps and a mobile web browser, while read and download actions present dissimilar results. The mobile client apps for Dropbox, Google Drive, and OneDrive allow R to read files without downloading for all file types and formats. It should be noted that opening files in .docx and .pdf format from OneDrive required the use of a Microsoft Office Mobile app.

Using a mobile web browser for Dropbox, read actions cannot be undertaken without download, but OneDrive interface allows the actions for all file types and formats (without required Microsoft Office Mobile).

In Windows devices, on the other hand, it was identified that only image files were successfully uploaded. This was due to a limitation of the attachment menu to handle other types of files. Read and download actions were, therefore, undertaken for image files. It was observed that 7 out of 13 image files could be downloaded using a mobile web browser for Dropbox.

4.1.1 Artefacts on android devices

Artefacts on Android devices were collected using a combination of physical, logical and manual acquisition methods. Logical and manual acquisitions were undertaken on the sender’s device whereas a physical acquisition was undertaken on the receiver’s device. It should be noted that XRY did not support physical acquisition of the sender’s device. Therefore, the dataset artefacts on the sender’s device were analysed from a logical acquisition perspective and its account information was mainly analysed using manual acquisition techniques after we rooted the device.

Sender and receiver accounts

The cloud storage service account ID that connected devices is key information for further investigations. Accounts.db is a local SQLite database that contains account ID metadata for its associated component apps and encrypted passwords (see Table 3). We noted that the only app that does not keep users’ passwords in the table is Dropbox.

Table 3 Account artefacts in Android devices
Full size table

Each of the cloud storage services has their own SQLite databases to preserve their account information. The information for Dropbox is stored in prefs.db; GoogleDrive information can be found from doclist.db, in table account168 (on the sender’s device) and account164 (on the receiver’s device); and OneDrive keeps the information in a metadata.db that can be located from table item.

Cloud storage activities

One database that gives general information about programs’ executions is launcher.db. It also gives information about the execution of the Dropbox, GoogleDrive and OneDrive. This information can be used to confirm that the apps have been executed on the device. Another important database in Android is /data/com.android.providers.media/databases/external.db. It consists of three relevant files which are (1) files – it presents all folders on the internal and external memory; (2) image thumbnails – it presents thumbnails of images; and (3) video thumbnails – it presents thumbnails of videos.

In detail, each of the apps store their activities’ log in their own records. Using these records, we can compare the metadata that is generated by uploading, sharing, reading and downloading files between the sender’s device and the receiver’s device. This comparison provides insight into overall relevance.

For the Dropbox app, an upload_log table in db.db provides key information in reference to the sender’s upload activity. This record contains a log of operations, relevant timestamps, the local file path, the file size and the upload status. To map the relevance between activities on the sender and receiver sides, Table 4 shows the examples of uploaded and downloaded files for the .mp3 file dataset. There is no information indicating the location of the uploaded file on the sender side. Conversely, on the receiver side, the file will be stored using the specified path in the field _data once the receiver execute download action and the timestamp is denoted in the modified field. Additional storage information of interest includes: the file name _display_name, the path is the folder path on the Dropbox, local_modified contains the time of the last access to the file and the field local_modified holds timestamp for actions conducted on the files once the files are in the cache folder.

Table 4 Dropbox’s log examples
Full size table

Although both GoogleDrive and One Drive do not have a specific upload log table, evidentiary metadata can be located from key database tables. In GoogleDrive, for instance, the Entry149 table contains file owner metadata that can be identified from the field labelled ‘owner’ while timestamps of upload, share, and recent access activities are represented in the creationTime, sharedWithMeTime and lastOpenedTime fields, respectively. This information is displayed in Table 5.

Table 5 An example of GoogleDrive logs
Full size table

Table 6 presents an example of the metadata generated by OneDrive when files are uploaded and downloaded from the table item. Metadata that link to the sender is ownerCid that comprises 16-digit of hexadecimal and ownerName denotes the registered name for the account. Creationdate and dateShared denotes the upload timestamp and shared timestamp respectively.

Table 6 OneDrive’s log examples
Full size table

Other tables of interest on sender’s device include the permission_scopes (see Table 7) and permission_entity (see Table 8) tables. These tables contain receiver metadata that is relevant to specific file transactions. In the permission scopes table, the PermissionScopeResourceName refers to the file name while permissiononEntityName denotes the file’s receiver user ID. This data indicates that a particular file was shared with particular user.

Table 7 Permission_scopes table
Full size table
Table 8 Permission_entity table
Full size table

We also noted that the cloud storage apps store the artefacts of cached files in a specific cache folder path. Cache files refer to files that have been accessed without being downloaded. In Dropbox, there are two important cache folder paths:

  • /storage/sdcard0/Android/data/com.dropbox.android/files/scratch/, and

  • /data/com.dropbox.android/files/log.txt.

The last path provides the location of the log file that keeps track of synchronised files.

In Google Drive, a log file located at the path /USERDATA/data/com.google.android.apps.docs/cache/ documents files that have been accessed and read. For OneDrive, cache folders are located at /USERDATA/data/com.microsoft.skydrive/no_backup/stream_cache/ia…a02@gmail.com/…/streams/. However, all OneDrive files and related formats can only be viewed by using a mobile web browser. In addition to the web browser restriction, associated OneDrive residual data was located using the path: /USERDATA/data/com.android.vending /databases.

Clearing traces

Clearing trace activities by the sender was simulated by uninstalling cloud storage apps and clearing browsing data. Data acquisition procedures were repeated and the same sources of evidence were observed. The system’s collection of cloud app databases are still in the phone’s memory but are generally lacking data in particular tables.

However, accounts.db retained the username IDs for both Dropbox and Google Drive accounts along with the encrypted password needed to access the Google Drive (see Table 9).

Table 9 Clearing traces artefacts
Full size table

Event reconstruction

An example of event reconstruction, for the information propagation activity, using Android devices is illustrated in Fig. 3. We present the upload details of an executable file from the sender’s side and report all artefacts on the receiver’s side.

Fig. 3
figure 3

Event reconstruction for information propagation activities on Android devices

Full size image

4.1.2 Artefacts on windows phone devices

Sender and receiver accounts

It should be noted that XRY version 6.15 did not support a physical acquisition of a Windows Phone when this study was conducted. Logical acquisitions obtained general information from sender and receiver devices such as device name, device manufacturer and model name.

Cloud storage activities

Logical acquisitions are conducted on both sender and receiver devices to collect the artefacts of upload/share – read/download activities. Media files such as documents, pictures, audios, videos, and archive files that were intact in the phone’s internal memory and/or located on the memory card were the primary artefacts that were acquired.

Artefacts from cloud storage accounts, cache files, and xml documents (related to installation and app usage) were not found. Manual acquisitions were conducted in an attempt to identify any artefacts of interest in reference to cloud storage app activities. Both of the sender and receiver phones were not protected with screen password, thus a complete list of installed apps, including cloud storage apps, was obtained. Examinations of archive folders (e.g. downloads) is recommended as the Windows Phone operating system allows users to side load an application. The archive folder is used to store .xap files of side load apps that might be useful in identifying current or attempted installations of apps. A file’s metadata such as name, type, size, created time and hash value were examined to reconstruct information propagation activities. Comparison of file metadata from senders and receivers suggested that cloud storage app integrity, for both uploaded and downloaded files, is maintained (i.e. same file names and hash values).

In these specific experiments, when a receiver only viewed uploaded picture files, no residual artefact of the viewed pictures was identified. This indicates that users who only view an uploaded picture, without downloading it first, may be more difficult to track in terms of viewing activities.

Clearing traces

We noted that there is no difference in logical acquisition results between, before and after uninstallation of cloud storage apps. Clearing browsing data activities did not appear to impact the extraction results.

Event reconstruction

Event reconstruction for information propagation activities on Windows Phone devices is shown in Fig. 4. From our findings, only image files were successfully uploaded and no artefacts were found, even if the user viewed the files.

Fig. 4
figure 4

Event reconstruction for information propagation activities on Windows Phone devices

Full size image

4.2 Information concealment

4.2.1 Artefacts on android devices

OneDrive and Gmail accounts were used to illustrate sending and receiving activities along with facilitating communication.

Hide/send – receive/unhide activities

Installation artefacts from the Stegais apps were collected from the path that was created by the Android operating system: /USERDATA/data/com.romancinkais. Stegais/files/. Generated steganography images can be located in the following path: /storage/ sdcard0/stegais/.

To illustrate sending and receiving activities, we used OneDrive to represent cloud storage services, Gmail for email services and WhatsApp apps to facilitate communication. Artefacts of shared steganography images on OneDrive are identified in the metadata.db in the table labelled item. Evidence of interest from WhatsApp was located in the chat_list table in message.db. No artefacts are found for activities using Gmail. Moreover, no artefact was found if the sender did not store the steganography image to the device’s internal memory before sending it.

We found downloading traces from OneDrive and Gmail in the /storage/sdcard0/Download path on the receiver’s device. WhatsApp generated its own folder in the path /storage/sdcard0/WhatsApp/Media /WhatsAppImages/ in order to store all downloaded image files.

Files integrity

File integrity is maintained during transmission activities via OneDrive and Gmail services as evidenced by the same file name and hash values. WhatsApp modified the file name and may apply compression to its transmitted data. We acknowledged that WhatsApp, most likely, does not compress small size file (e.g. 461,136 bytes) but probably does compress larger files (e.g. 2,926,316 bytes). As a result, it is probably that hidden messages, in stego images that use WhatApp, cannot be revealed due to the compression process.

Event reconstruction

An example of an event reconstruction for information concealment activities on Android devices is shown in Fig. 5. We confirmed that OneDrive and Gmail did not change the integrity of the sent files.

Fig. 5
figure 5

Event reconstruction for information concealment activities on Android devices

Full size image

4.2.2 Artefacts on windows phone devices

Logical acquisition results did not provide sufficient data to identify sender and receiver accounts for cloud storage services (i.e OneDrive), email (i.e. Outlook) and WhatsApp.

Hide/send – receive/unhide activities

Original images can be created by taking pictures using the phone’s camera and saving them in the Camera Roll folder in the phone’s memory. As expected, logical acquisitions successfully extracted images from the Camera Roll folder.

The use of the Stegais app was identified from artefacts in documents and unrecognised files that were extracted from the sender’s phones. README_FIRST.txt is an example of a Stegais app installation artefact that was extracted from Lumia c625/SDard/WPSystem/Apps/{D414A421-403A-4FC C-9069-7583604390BD}/Install, where {D414A4 21-403A-4FCC-9069-7583604390BD}is a code for Stegais app in the Windows Store. Another indication that Stegais was installed on the device was found in a collection of unrecognized files; Steganography.ni.exe was extracted from: Lumia 625/SDcard/WPSystem/AppRepository/29636 DharmendraMauryaRajp. Steganography_1.0.0.0_neutral__d0xnxt1pzcw50/NI. Meanwhile the use of WhatsApp was identified from the existence of messages.db that was saved in Lumia 625/SD card/WhatsApp/WinPhoneBackup/2015-12-09-0000.

Although the example files showed that a sender concealed information and delivered it, there is no artefact recovered from the hidden information that indicates the receivers’ identity. Furthermore, the logical acquisition could only extract steganography images if the sender saves the images before sending them to the receiver. Manual acquisition was undertaken to identify the Stegais and WhatsApp installations on the receiver’s device; however, from logical acquisition results, neither documents nor unrecognized files were extracted to identify the installation.

File integrity

We observed that cloud storage and email services do not modify the content of a sent steganography file. Uploaded and downloaded files have an identical hash value, but they have different file names. WhatsApp did compress the original files to enable light communication between their users. The compression made hidden messages unreadable.

Event reconstruction

Figure 6 presents an event reconstruction of information concealment activity on Windows Phone devices. The findings are similar to the findings generated in the Android scenario in the context of files integrity.

Fig. 6
figure 6

Event reconstruction for information concealment activities on Windows Phone devices

Full size image

4.3 Communication

Five mobile communication apps (i.e. Viber, Skype, WhatsApp, Telegram and Messenger) were chosen based on their current popularity as communication channels. Evidentiary values of digital objects on the communication apps were examined based on the simulation activities undertaken on Android devices. Those activities included sending and receiving text messages, documents, location, images, and making or accepting voice and video calls. In addition, two email apps (i.e. GMail and Microsoft Outlook) were studied. Sending and receiving emails and attachments activities were simulated.

To examine artefacts of user account, we first checked the accounts.db as it may contain account information (e.g. username and encrypted password) of installed apps. We found users’ email, they were identified from Skype and GMail (i.e. vic…g@gmail.com) and Microsoft Outlook (i.e. Vic…g07@yahoo.com.au:Yahoo) apps; and users’ encrypted password for Viber and GMail, 25b1…47 and oauth2rt_1/L-… I, respectively. We also found launcher.db that comprises installed apps, component name (e.g. org.telegram.messenger) provide clue that the apps have been launched.

Similar to cloud storage apps, initial survey on the accounts.db lead to additional metadata. Table 10 presents a snapshot of potential evidence sources for communication apps.

Table 10 A summary of potential evidence sources in communication apps
Full size table

To identify contacts, Skype uses the registered email or Skype name, Telegram and Messenger assign a unique user ID in integer format, while WhatsApp and Viber use the registered phone number. In terrorism investigations, for example, this metadata could lead to other terrorist actors, new members to be recruited, and/or probable targets.

Chat log artefacts present key information that may provide insight into terrorism perspectives, including target, motivation, attack tools, domain, method of action and perceived impacts. Accessing chat log tables allows investigators to identify metadata from communication activities, including actors (sender and recipient), message body, call logs from VoIP voice and video, logs of attachments (type, file location, size) and timestamp. Telegram, however, keeps chat log metadata in an encrypted format and BLOB objects format for attached media files. Examples of available artefacts are user ID, timestamp, and chat states (sent or received).

Group chat metadata was observed in WhatsApp and Telegram. Group chat is normally created for particular themes (e.g. organising events) or members (e.g. family, friends), thus the logs would give a greater overview of suspects’ motivation and for tracing connections between participants. WhatsApp provides detail information on group members including their phone number. Table of group_participants presents a list of group members [phone number – group id@g.us ]where group_participants_history denotes the latest activity (in integer value) of each participant in a particular group. A chat log of a group chat was found in the messages table by observing key_remote_jid, for example as 614…48–1,459,248,221@g.us. The acquired metadata for Telegram includes group id and group name. There did not appear to be a group administrator for Telegram.

The four communication apps, apart from Telegram, record logs of the media attachments during chat conversations in the chat log tables along with the media format. WhatsApp, Telegram and Viber create file paths in the internal memory directory to store the received and sent media. Messenger and Skype keep the shared media in their cache, but are limited to only a few media types such as images and audio messages for Messenger, and images and video for Skype. Traces of audio messages were found in Messenger and WhatsApp, while video messages were found on WhatsApp, Skype and Viber.

Besides shared media, the files of profile pictures were observed for WhatsApp, Viber, and Telegram. The naming convention for WhatsApp profile pictures is [phone number]@s.whatsapp.net.j. Telegram and Viber keep a history of timestamped profile pictures for users and their contacts; not just the most recent ones.

GPS data may play an important role in providing information such as location of target, suspects’ whereabouts during communication, and any shared location data during conversations. In communication apps, location data is recorded, if a user turns on the GPS menu and opts to share location or send their location data as an attachment during chat conversation. Whatsapp, Skype and Viber have specific columns for latitude and longitude data in their main chat logs tables, while data on Messenger can be observed from the embedded URL as attachments, for instance [{“name”:“Iaxx’s Location”,“caption”:null,”… markers = −34.81076900%2C138.62047000&language = en…. }].

Network analysis

Mobile forensics alone may not provide adequate digital evidence, although other forensic techniques, such as network forensics, could address this inadequacy by correlating evidence from different sources, for example network logs [34]. Let us consider on 29/03/2016 at 10:26:31 PM, a user shared one image file, file:///storage/sdcard0/viber/media/Viber%20Images/image-5…4aa-V.jpg. Table 11 presents an example of DNS responses between a client and a server that provide clues to file sharing activities using Viber on Android.

Table 11 Related network packets for Viber on 29/03/2016
Full size table

Since minimal significant artefacts were found on Windows devices, network-based evidences can, potentially, facilitate investigations. For instance, both the source and destination of IP addresses observed on network packets would have evidentiary value to trace the suspect (see Fig. 7).

Our findings have shown that network metadata supports the occurrence of mobile communication activities. The limitation, however, is that network monitoring is, normally, a practice that takes place at organisational levels. Hence, it, generally, requires a warrant to undertake this practice on personal devices.

5 Discussion

The increasing adoption of cloud and mobile technology infrastructures by organisations present plausible abuse opportunities for terrorist activities. Cooperative counter-terrorism at organisational and national levels is needed to increase overall understanding and mitigate infrastructure abuse.

In this paper, we demonstrated the intricacies associated with investigating terrorist activities on mobile devices. Our experiments interact with cloud storage services (i.e. Dropbox, Google Drive and OneDrive) and communication apps (Messenger, WhatsApp, Telegram, Skype and Viber, including email client services). The findings show that we can reconstruct more complete activities on Android devices as compared to Windows Phone devices.

On Android devices, we identified an account’s username, reconstructed a user’s activities and downloaded data. While on a Windows Phone only downloaded data; no database and XML files were extracted using logical acquisition. Similarly, while we can acquire viewed-only data in a cache folder for Android devices, only downloaded data is acquired on Windows Phone. The limited results derived from Windows Phone devices makes it necessary for a manual acquisition highly probable moreover when physical acquisition is not applicable. One study reported that more data was extracted including installed apps, databases and locations on Windows Phone device (i.e. Nokia Lumia 625) using physical acquisition method [19].

Focusing on communication apps, the extent of extracted data depends on the communication apps themselves. In other words, how individual apps store their data impacts extraction success, i.e., either in plaintext or encrypted. Telegram, which implements encryption, provides the fewest clues on users and metadata of events. In the future, similar encrypted data issues might be encountered for newer versions of WhatsApp.

6 Conclusion

This research highlighted the importance of mobile device forensics in investigations involving the use of cloud storage services and communication apps along with the necessity and potential utility of the integrated incident handling and digital forensics models to investigate and reconstruct terrorist incidents [5]. Key findings could inform future similar investigations.

Future research include extending the research to a wider range of mobile apps and app categories, as well as newer versions of mobile devices and operating systems.