Residual Cloud Forensics
CloudMe and 360Yunpan as Case Studies
A. Dehghantanha*; T. Dargahi† * University of Salford, Salford, United Kingdom
† Islamic Azad University, Tehran, Iran
Abstract
Recently, cloud storage has emerged as a challenge for digital forensics investigators, as there are numerous types of cloud storage services freely available with the potential of being used for criminal activity. Several research studies focused on forensic acquisition of data from various cloud services to find out the forensic validity of data and metadata from cloud storage. This chapter analyzes CloudMe and 360Yunpan to detect residual artifacts with forensics value of user activities. We performed the experiments in three separate platforms, which are Windows 8.1 (x86) Professional (client- and browser-based), Android KitKat 4.4.2, and Apple iOS 8.0. We found several digital forensic artifacts, such as the sync and file management metadata, registry data, RAM artifacts, and network data. Supported by our investigation, we provide several general guidelines and recommendations for future cloud-based forensic analysis.
Keywords
Cloud computing; Cloud storage forensics; Digital forensics; CloudMe; 360Yunpan
1 Introduction
The use of cloud computing in the information and communications technologies (ICT) sector has become a main trend in recent years. Cloud services come in three models, software as a service (SaaS), platform as a service (PaaS), and infrastructure as a service (IaaS) [1, 2]: SaaS is often presented as a subscription-based model and has a multitenant environment, where various clients (such as web browser, desktop clients, mobile devices) can access its applications through the Internet. PaaS is provided as a platform that allows users to develop and deploy customized applications. IaaS is a self-service model where clients are allowed to set up an infrastructure and run any software they prefer [3].
The ever increasing interest in using cloud storage services raises several security and privacy issues [4–8]. Therefore there is an exponential growth in demand for a forensic investigative study of the existing cloud platforms [9] in order to discover data remnants of forensic value on client devices [10–15]. However, since processing of digital data in cloud computing systems varies from one provider to another, the acquisition and analysis of digital evidence is different within different platforms and cloud storage providers [14]. As mentioned by Taylor et al. [3], the dynamic nature of data processed in the cloud raises the issue of having a proper method for data seizure in order to conduct an accurate investigation.
Most of the cloud forensics relevant academic publications focus on the issues and challenges faced by digital forensics practitioners and the digital forensic framework for conducting forensic investigations in the cloud environment, with only a few publications that emphasize the technical side of cloud forensics. Cloud forensic academic literature that studies the technical perspective often focuses on the forensic analysis on the server-side. The reason for the lack of technical-focused papers might be the highly restrictive access permissions to conduct server analysis in the datacenters of cloud service providers. It is only during recent years that more papers are beginning to adopt cloud forensics framework, which was used to conduct a forensic identification, preservation, and extraction of data in various cloud services on the client-side. Among them are ownCloud [16, 17], Microsoft SkyDrive [8, 18, 19], Google Drive [8, 18, 20–23], Dropbox [8, 17, 18, 20, 23–25], SugarSync [24, 26], to name a few. In Table 1, we present a summary of the investigated cloud platforms in the literature, categorized by the type of cloud services, ie, SaaS, and IaaS, that are forensically investigated.
Table 1
A Brief Overview of the Existing Cloud Storage Forensics Research Studies
| Cloud Services | SaaS | IaaS | |||||||||||||||||||||
| Amazon | Amazon Cloud | Amazon | Amazon | ||||||||||||||||||||
| Dropbox | Drive | SkyDrive | Box | S3 | Drive | AWS | OneDrive | ownCloud | Flicker | PicasaWeb | iCloud | UbuntuOne | hubiC | Mega | Evernote | SugarSync | Hadoop | vCloud | XtreemFS | Eucalyptus | EC2 | ||
| References | Daryabar et al. [23] | ✓ | ✓ | – | ✓ | – | – | – | ✓ | - | - | - | - | - | - | - | - | - | - | - | - | - | - |
| Shariati et al. [26] | – | – | – | – | – | – | – | – | – | – | – | – | – | – | – | – | ✓ | – | – | – | – | – | |
| Daryabar et al. [29] | – | – | – | – | – | – | – | – | – | – | – | – | – | – | ✓ | – | – | – | – | – | – | – | |
| Quick et al. [19] | – | – | ✓ | – | – | – | – | – | – | – | – | – | – | – | – | – | – | – | – | – | – | – | |
| Chung et al. [20] | ✓ | ✓ | – | – | ✓ | – | – | – | – | – | – | – | – | – | – | ✓ | – | – | – | – | – | – | |
| Federici et al. [18] | ✓ | ✓ | ✓ | – | – | – | – | – | – | – | – | – | – | – | – | – | – | – | – | – | – | – | |
| Grispos et al. [24] | ✓ | – | – | ✓ | – | – | – | – | – | – | – | – | – | – | – | – | ✓ | – | – | – | – | – | |
| Martini et al. [17] | ✓ | – | – | – | – | – | – | ✓ | ✓ | – | – | – | – | – | – | – | ✓ | – | – | – | – | – | |
| Marturana et al. [21] | – | ✓ | – | – | – | – | – | – | – | ✓ | ✓ | – | – | – | – | – | ✓ | – | – | – | – | – | |
| Quick et al. [25] | ✓ | – | – | – | – | – | – | – | – | – | – | – | – | – | – | – | – | – | – | – | – | – | |
| Quick et al. [8] | ✓ | ✓ | ✓ | – | – | – | – | – | – | – | – | – | – | – | – | – | – | – | – | – | – | – | |
| Quick et al. [22] | – | ✓ | – | – | – | – | – | – | – | – | – | – | – | – | – | – | – | – | – | – | – | – | |
| Hale et al. [30] | – | – | – | – | – | ✓ | – | – | – | – | – | – | – | – | – | – | – | – | – | – | – | – | |
| Oestreicher [31] | – | – | – | – | – | – | – | – | – | – | – | ✓ | – | – | – | – | – | – | – | – | – | – | |
| Martini et al. [32] | – | – | – | – | – | – | – | – | – | – | – | – | – | – | – | – | – | – | ✓ | – | – | – | |
| Martini et al. [33] | – | – | – | – | – | – | – | – | – | – | – | – | – | – | – | – | – | – | – | ✓ | – | – | |
| Marty [34] | – | – | – | – | – | – | ✓ | – | – | – | – | – | – | – | – | – | – | – | – | – | – | – | |
| Dykstra et al.[35] | – | – | – | – | – | – | – | – | – | – | – | – | – | – | – | – | – | – | – | – | – | ✓ | |
| Cho et al.[36] | – | – | – | – | – | – | – | – | – | – | – | – | – | – | – | – | – | ✓ | – | – | – | – | |
| Blakeley et al.[37] | – | – | – | – | – | – | – | – | – | – | – | – | – | ✓ | – | – | – | – | – | – | – | – | |
| Anwar et al.[38] | – | – | – | – | – | – | – | – | – | – | – | – | – | – | – | – | – | – | – | – | ✓ | – | |
| Shariati et al.[39] | – | – | – | – | – | – | – | – | – | – | – | – | ✓ | – | – | – | – | – | – | – | ✓ | – | |
(✓), analyzed; (–) not analyzed.
In this research study we carry out a forensic investigation on two cloud storage platforms, ie, CloudMe [27], and 360Yunpan [28], considering several file operations, such as upload, access, and download. CloudMe [27] is a European cloud service, which is owned by CloudMe AB company, founded in 2012. It offers secured cloud storage, file synchronization, and client software for managing cloud data across various client devices, including GoogleTV and Samsung Smart TV.
360Yunpan [28] is a China-based cloud service. A distinguishing feature of 360Yunpan is its huge storage capacity, ie, 36 TB free of charge space for its users. The free huge storage space of the cloud could be a good motivation for performing criminal activities.
1.1 Contribution
Considering CloudMe and 360Yunpan as case studies, we answer the following research questions:
1. What kind of data could be recovered after using CloudMe and 360Yunpan on Windows 8.1, Android KitKat 4.4.2, and Apple iOS 8.0?
2. What kind of data could be recovered after accessing CloudMe and 360Yunpan through web-browsers: Internet Explorer (IE), Google Chrome (GC), and Mozilla Firefox (MF)?
3. What forensic artifacts could be recovered after analyzing the network traffic and capturing the live memory?
4. What data remains on Windows 8.1, Android KitKat 4.4.2, and Apple iOS 8.0 after using inbuilt apps?
5. Are the MD5 of the files downloaded during the acquisition process identical to original files? If no, what are the changes?
6. Is the timestamp information remaining the same during the process of upload, storage, and download from cloud storage?
We believe that our experimental results will help the forensic investigators to better understand the potential artifacts that could be found on the client side of the aforementioned two cloud services.
2 Research Methodology
In order to conduct our experiments, we adopted the cloud forensics framework proposed by Martini and Choo [40] (Fig. 1), which is based on NIST [41] and McKemmish [42] frameworks. In this section we explain the adoption of the framework in this research: the steps of the framework, as well as the process used to conduct the research.
The first step of the framework is Commence (scope), in which we outline the scope of the experiments. The focus of this study is to identify the data remnants that are locatable after performing the following actions: upload, access, download, and delete by using the cloud service through web browser or the client software. We carried out our experiments using three different web browsers: Microsoft Internet Explorer, Google Chrome, and Mozilla Firefox. Moreover, we targeted the following data remnants: username, password, file names, date and time, or the presence of client software, as well as the indication of cloud services. Furthermore, we captured and analyzed memory as an important source of evidence, as well as network traffic.
The second step of the framework is Prepare, in which we set up the virtual environments to answer the research questions, which are explained in Section 1.1. We took advantage of virtual environments due to the lack of physical hardware devices. Besides, in terms of memory capturing, adopting virtual environment is easier, as we can perform memory capture by copying the files in “VMEM” format when the VM is running. Moreover, in terms of network traffic capturing, the use of a virtual environment is more convenient, as it can be done by running “Wireshark” on the host machine to monitor and capture the network traffic on the virtual machine.
The third step of the framework is Identify and Collect, in which we recognize the files that contain the required information to conduct the analysis. We consider the following files: virtual hard drives (VMDK) of each VM folder, the memory instances (VMEM files), and network capture file (PCAP) as well.
The fourth step is Preserve (forensic copy). In digital forensic acquisition and analysis, the potential digital evidences should be obtained in a forensically sound manner. Therefore a forensic copy of each of the required files should be acquired using a forensically sound tool, such as “HashCalc” to calculate the hash values in MD5 to ensure the integrity of the data.
The next step of the framework is Analyze, in which the analysis of the obtained data is carried out. We performed this step utilizing a set of forensic analysis tools, including (but not limited to) “Process Monitor 3.05,” “Regshot 1.9.0,” “Nirsoft Web Browser PassView 1.4.3,” and “Hex Workshop 6.8” (detailed information about the adopted tools are explained in Section 2.1).
The sixth step is Present, in which we have to present the evidential data. Generally, the reporting should consist of the information on all processes carried out, the tools and applications used in the investigation and restrictions, if any, to avoid false conclusions.
In the next step, ie, Feedback, the important information discovered in the experiments should be shared with the IT community to allow the forensics practitioners to locate the required information and to find out the security issues. Besides, it is also important to report the issues and improvements faced during the examinations, in order to provide a guideline for future examinations.
Finally, the last step of the framework is Complete, which concludes the investigation results.
2.1 Experimental Setup
We carried out our experiments considering four settings on different operating systems (OS): (a) Windows browser-based, (b) Windows app-based, (c) Android app-based, and (d) iOS app-based. Table 2 provides detailed information of the considered cloud services and operating systems.
Table 2
List of Considered Cloud Services and Operating Systems
| Cloud Service | Operating System | Version |
| CloudMe (3 GB) | Windows 8.1 | 1.8.8 |
| Android KitKat 4.4.2 | 1.7.2 | |
| Apple iOS 8.0 | 1.8.4 | |
| YunPan (36 TB) | Windows 8.1 | 6.0.1.1090 |
| Android KitKat 4.4.2 | 6.0.11 | |
| Apple iOS 8.0 | 4.1.0 |
We carried out our experiments using the Enron Email Dataset1 (the August 21, 2009 Version, which we downloaded on the 17th November 2014) and performed four operations on each of the platforms: upload, download, open, and delete. We carried out the operations using the following files:
– arora_savedmail.docx,
– arora_savedmail.txt,
– arora_savedmail.rtf,
– arora_savedmail.jpg.
We applied MD5 algorithm on the files of the dataset, using “Hash Calc version 2.02” in order to track down the originality of the files before and after the operations. Moreover, we used VMware Workstation 10.0, in order to build the virtual machines (VMs) needed for the experiments. We created a VMs for Windows 8.1 64 bit, which we used in both Windows-based experiments, having the following specification: one CPU, 1-GB RAM, and 20-GB virtual hard disk. Table 3 depicts the software configuration for Windows-based experiments.
Table 3
Initial Environment Configuration for Windows-Based Experiments
| Setting | Tools | Version |
| Windows browser-based | Nirsoft web browser PassView | 1.4.3 |
| Nirsoft IE cache viewer | 1.5.3 | |
| Nirsoft Mozilla cache viewer | 1.66 | |
| Nirsoft Chrome cache viewer | 1.61 | |
| Internet Explorer | 11 | |
| Mozilla Firefox | 33.0 | |
| Google Chrome | 39.0.2171.65 | |
| Windows app-based | Regshot | 1.9.0 |
| Process Monitor | 3.05 |
In order to conduct the experiments on Android, we installed a ported version of Android KitKat 4.4.2 ISO image on VMware Workstation 10 with the following configuration: one CPU, 1-GB internal memory, and 15-GB internal storage.
For the experiments of iOS platform, we utilized an iPad Mini 2 version 8.0. The adopted tools are: “iPhone Backup Browser version 1.2.0.6”, and “Hex Workshop version 6.8”. The credentials set up for the experiments are listed in Table 4.
Table 4
Credentials Used During the Experiments
| Credentials | Descriptions |
| Virtual Machine | Full name: AliceName AliceFamily |
| User name: Alice | |
| Password: A@12345 | |
| Cloud Service | |
| CloudMe | User name: Bob25775 |
| Password: B@12345 | |
| 360YunPan | User name: [email protected] |
| Password: B@12345 | |
2.1.1 Windows 8.1 Client Application Based
We installed Windows 8.1 in a VMware workstation, without any extra applications. We carried out three operations on the could services: upload, download, and delete. We did not perform open operation, because the dataset is available offline for the user. Besides, we performed installation and uninstallation of the client app. The set up for the experiments are as shown in Fig. 2.
2.2 Windows 8.1 Browser Based
We installed the three most popular web browsers, ie, Microsoft Internet Explorer (IE), Google Chrome (GC), and Mozilla Firefox (MF) on the VMs. The operations carried out in the VMs for browser-based cloud usage are upload, open, download, and delete as shown in Fig. 3.
The browser remnant files are considered as one of the sources of evidence that could be identified easily when a user is accessing the cloud services via online interface. Therefore, we investigated the browser cache. The tools that can be utilized for extracting the browser caches are “Nirsoft Cache Viewer” for IE, GC, and MF. Besides that, in order to recover the username and password used for the cloud services, we used “Nirsoft Web Browser Passview” [43].
2.3 Android KitKat 4.4.2 Client Application Based
We adopted a virtual machine VMware Workstation 10 with an Android KitKat 4.4.2 operating system installed, to conduct our experiments on Android. The ported Android operating system is rooted by default; therefore we could directly conduct the experiments. The main focus of the evidence source was the internal memory and network traffic, as it was not possible for us to use the VMDK file for analysis. The experiments stages are shown in Fig. 4.
2.4 Apple iOS 8.0 Client Application Based
We used an iPad Mini 2 running iOS 8.0, to conduct the iOS experiments. We downloaded the cloud services app used in the experiments from Apple Store: “CloudMe”, and “360 YunPan HD” apps. We carried out upload, open, download, and delete operations as shown in Fig. 5. During the experiments, we also installed and uninstalled the applications to identify if there is any additional sources of evidential data. In order to identify the sources of evidence in iOS, we used iTunes to back up the device. We used a forensically sound tool for iOS forensic, named “iPhone Backup Browser,” to investigate the backup files. Moreover, iOS does not support uploading files, other than photos, directly using the device. Therefore, the upload operation for CloudMe is done with the help of Dropbox, while the upload for 360Yunpan is done using the web browser, as there is no upload option available.
3 Results and Discussion
This section presents the evidence identification and preservation methods used in the experiments. Moreover, we provide the findings of the experiment, which are the residual forensic artifacts that were generated and left in the client devices during the installation and uninstallation of client-side application. We performed three file operations (upload, download, delete) in four different settings (Windows 8.1 client application-based, Windows 8.1 browser-based, Android KitKat 4.4.2, and Apple iOS 8.0). The collected findings will then be followed with an analysis and a presentation of the summary of findings.
3.1 Evidence Source Identification and Preservation
Before utilizing the datasets in the experiment, we applied hash algorithm using “HashCalc 2.02” on all the five dataset files. This is to ensure that the integrity of the datasets can later be verified after the experiment and to check if the original content of the datasets were altered during the file operations.
We analyzed the evidences separately for each experiment setup using a range of forensic tools. For Windows 8.1 client application- and browser-based experiments, we took snapshots of the virtual machine. We could analyze the .vmem (virtual live memory) and .vmdk (virtual hard disk) files using “AccessData FTK Imager 5.5” and “Hex Workshop 6.8.0.5419”, respectively. The analysis of the live memory is conducted in “Hex Workshop” by using search keywords, such as the cloud storage provider name (CloudMe, or 360Yunpan), user credentials (Bob25775, B@12345), and dataset filenames (arora_savedmail). This also applies to the experiments running on Android KitKat 4.4.2 virtual machine.
During the installation, uninstallation, and file operations, we captured the network traffic using “Wireshark 1.12.1” running on the host machine. We analyzed the captured .pcap files, using “Wireshark” adopting custom filters and keyword searches.
Other forensic tools that we used are: “Process Monitor version 3.1” for monitoring registry changes in the Windows 8.1 client-application experiment; “SQLite DB Browser 3.4.0” for viewing .db files; “RegRipper 2.8” for analyzing registry files extracted from the Windows 8.1 . vmdk files; “PList Explorer version 1.0” for viewing and analyzing Apple iOS 8.0 backup files. We recorded the timestamps of each of the datasets before proceeding with the upload to the cloud storage, which will later be verified with the timestamps recorded after sync and download. It should be noted that the modified time usually remains the same before upload, after upload, and after download unless there is a difference in the device’s local time. The MAC timestamps for the datasets used in the file operations of each cloud service running on different platforms recorded and presented in Section 3.3.
3.2 Evidence Collection
Evidence collections for research experiments that are running on virtual machine such as Windows 8.1 app-based, Windows 8.1 browser-based, and Android KitKat 4.4.2 app-based have similar evidence collection methods. For every operation conducted on the virtual machine, the running virtual machine is taken as a snapshot in VMware Workstation 10 to preserve the data in virtual live memory and the virtual hard disk. At the same time, the network traffic is captured using “Wireshark 1.12.1” for analysis. All the collected evidences then hashed using “HashCalc 2.02” to generate their MD5 file hashes as a precaution to verify if there were alterations made on the evidence after analysis. These evidences are analyzed in the host machine using the forensic tools that are mentioned in Section 3.1.
For the Apple iOS 8.0 app-based research experiment, there was a limitation in the collection of evidence. Due to the newness of the operating system (at the time of experiments), there were no jailbreaking solution for it. Therefore it was impossible for us to achieve root and gather more evidence. The alternative solution was to utilize the in-built backup feature that comes with Apple devices. Using iTunes as backup solution, we were able to create something similar to a snapshot, which can be accessed online and analyzed later.
3.3 Examination and Analysis
In this section we present the findings of our analysis on CloudMe, and 360Yunpan running on Windows 8.1 (client application-based and web browser-based), Android KitKat 4.4.2, and Apple iOS 8.0.
3.3.1 Cloud Service: CloudMe
In this section we report our findings on CloudMe in several sections based on the underlying platforms.
Windows 8.1—Client Application Based
CloudMe 1.8.8 is a SaaS cloud storage service, for which the client application could be located on the user’s hard disk. Users are given the option to selectively sync files instead of CloudMe synching all the files in the local folder. Therefore the experiments for CloudMe includes an extra operation for sync. The installation of CloudMe 1.8.8 client application for Windows creates directories in several locations:
• ProgramFiles (x86)CloudMeCloudMe which is executable file for starting CloudMe
• \% USERPROFILE % DocumentsCloudme which is the local CloudMe folder
• \% LOCALAPPDATA % CloudMe which stores user-specific sync and file management metadata
CloudMe stores user-specific sync and file management data such as sync logs, cache database, and other user details and configurations. Analysis on the CloudMe folder in local app data found a text log 2014-11-23.txt containing login information of the user as shown in Fig. 6.
Other files such as cache.db contains more forensically valuable data as it includes the multiple SQL tables including “user_ table” that stores user details as shown in Fig. 7, as well as “syncfolder_ document_ table” that indexes files synched and stored in the users CloudMe storage. The “user_ table” stores the unique userID, username, and device name including the time of creation of the CloudMe client application.
Examination of the Windows 8.1 live memory shows CloudMe leaves traces of user information such as user ID, username, user first name and last name, and last login time as shown in Fig. 8. Other useful forensic artifacts include traces of file synchronization, which is found during the upload of sample dataset into CloudMe cloud storage. CloudMe also leaves traces in the live memory during download operation when users log into their CloudMe account on a new client device. The files from the CloudMe account are synched into the local CloudMe folder as shown in Fig. 9.
The network traffic between the local client application and CloudMe cloud storage was also captured when the file operations were conducted in CloudMe. CloudMe uses TLSv1.2 [Transport Level Security version 2] to encrypt the connection between the client-app and remote cloud service. Hence, we were not able to read the data from the network streams. However, we could find out the SSL certificate used by CloudMe; which is StartCom Class 3 issued by StartCom Ltd as shown in Fig. 10. Uninstallation of the client application removes the local root folder, but leaves the configuration files containing sync log which has no valuable data, and cache.db which only contains user CloudMe account details.
Table 5 shows the timestamps for DOCX and JPG captured before uploading (first row) and upon downloading (second row), and sync (third row). The MAC timestamps for upload and sync matches, whereas the timestamps for download varies for some of the file types. We suspect that CloudMe may be sensitive to file types during the file operations.
Table 5
Timestamp and MD5 of Original, Sync, and Downloaded Files
| MD5 | Created | Modified | Accessed | |
| docx | 4d16f5b7e1d5f8ea195bd87a600c6815 | 11/30/2014 (01:44:45) | 11/17/2014 (14:15:45) | 11/30/2014 (01:44:45) |
| 4d16f5b7e1d5f8ea195bd87a600c6815 | 11/30/2014 (01:44:45) | 11/17/2014 (14:15:44) | 11/30/2014 (01:44:45) | |
| 4d16f5b7e1d5f8ea195bd87a600c6815 | 11/30/2014 (01:35:32) | 11/30/2014 (01:35:32) | 11/30/2014 (02:31:04) | |
| jpg | 7f5ce91bb949b29c8d2deefaeb999d0f | 11/30/2014 (01:44:48) | 11/17/2014 (00:24:40) | 11/30/2014 (01:44:48) |
| 7f5ce91bb949b29c8d2deefaeb999d0f | 11/30/2014 (01:44:48) | 11/17/2014 (00:24:40) | 11/30/2014 (01:44:48) | |
| 7f5ce91bb949b29c8d2deefaeb999d0f | 11/30/2014 (01:36:41) | 11/30/2014 (01:36:43) | 11/30/2014 (02:32:52) | |
| rar | f90f08cb35307de7b5b44e1c3ffd1445 | 11/30/2014 (01:44:50) | 11/17/2014 (14:33:20) | 11/30/2014 (01:44:50) |
| f90f08cb35307de7b5b44e1c3ffd1445 | 11/30/2014 (01:44:50) | 11/17/2014 (14:33:20) | 11/30/2014 (01:44:50) | |
| f90f08cb35307de7b5b44e1c3ffd1445 | 11/30/2014 (01:41:44) | 11/30/2014 (01:41:44) | 11/30/2014 (02:32:58) | |
| rtf | 7f5ce91bb949b29c8d2deefaeb999d0f | 11/30/2014 (01:44:50) | 11/17/2014 (14:19:54) | 11/30/2014 (01:44:50) |
| 7f5ce91bb949b29c8d2deefaeb999d0f | 11/30/2014 (01:44:48) | 11/17/2014 (00:24:40) | 11/30/2014 (01:44:48) | |
| 7f5ce91bb949b29c8d2deefaeb999d0f | 11/30/2014 (01:59:49) | 11/30/2014 (01:59:49) | 11/30/2014 (02:33:07) | |
| txt | 83d78201914c892021290de6185f375c | 11/30/2014 (01:44:51) | 11/17/2014 (14:12:42) | 11/30/2014 (01:44:51) |
| 83d78201914c892021290de6185f375c | 11/30/2014 (01:44:51) | 11/17/2014 (14:12:42) | 11/30/2014 (01:44:51) | |
| 83d78201914c892021290de6185f375c | 11/30/2014 (01:44:51) | 11/30/2014 (02:12:42) | 11/30/2014 (02:33:09) |
Windows 8.1—Web Browser Based
In what follows we demonstrate our findings separated by the performed actions.
Upload—Live Memory/Browser Cache
We could discover the action of uploading files (“syncUpload”) in the memory as shown in Fig. 11. The only critical information found in the browsers caches is the URL address of “www.cloudme.com” located with “bob25775,” which we believe to be the username of the cloud service (Fig. 12).
Open/View—Live Memory
We could recover the filename along with the cloud service URL address identified from the memory of the machine. We found “exportwriter.zoho.com” in the memory, which we believe has been used to preview the document.
Download—Live Memory/Browser Cache
We were not able to find out any obvious evidence showing the download action for CloudMe. However, there were records of the filename discovered as part of the URL address in the memory as shown in Fig. 13. Analyzing the browsers’ cache, we discovered files along with the file size, the last accessed time, as well as the URL address showing the cloud service CloudMe as part of it (Fig. 14).
Delete—Live Memory
The deletion of files in CloudMe cloud service is identified by the action “action= emoveEntry” followed by the filename as displayed in Fig. 15.
Android KitKat 4.4.2—Client Application Based
We downloaded CloudMe 1.7.2 for Android from Google Play. The installation of CloudMe creates a directory to store user configuration files: /storage/emulated/0/Android/data.com.xcerion.android. CloudMe leaves traces of user credentials of both client device and cloud service account on the client device internal memory as shown in Fig. 16.
Searching the internal memory by dataset filenames shows that the internal memory contains traces of upload, download, and delete activity in CloudMe. Fig. 17 shows the files that are stored in the local CloudMe cache folder on the client device. We could not find evidence of the actual download activity in the internal memory. However, the downloaded files are found in the default Android download folder. As for file deletion activity, the keyword search “delete” shows a chunk of data in the internal memory that indicates the presence of file being deleted as shown in Fig. 18.
During the experiments, we captured the network traffic using “Wireshark 1.12.1” during the file operations. Analysis of pcap files show that CloudMe uses the same SSL encryption as the PC-app version for Android mobile version, which is StartCom. Further analysis using keyword search only returned results with traces of CloudMe account username and device type but no other user account data (Fig. 19).
The downloading of dataset files from CloudMe storage into the client device did not leave any traces of activity as no filename or metadata are found. However, some of the file contents are recoverable from the network streams such as the RTF and TXT files (Fig. 20). Uninstallation of CloudMe mobile client application did not leave traces in the internal memory and network.
Apple iOS 8.0—Client Application Based
We could identify the appdata of CloudMe as “com.xcerion.icloud.iphone” in the backup files. The evidences for the installation activity of the application are discoverable from the files, namely “Manifest.mdbd”, “Manifest.plist”, and “Info.plist” (Fig. 21). Whereas we found the login activity evidence from “xcerion.icloud.iphone.plist” (Fig. 22), where the username and first login name are revealed to be “bob25775”.
The upload option in CloudMe of iOS version only allowed the upload of photo. Thus we uploaded the dataset with JPG format. The datasets with file formats RTF and DOCX were the only supported files that could be uploaded to CloudMe by accessing the files using Dropbox and “open with” CloudMe.
We performed the open operation on three of the files. The files that we could discover in the backup being downloaded are: “arora_ savedmail.rtf” and “arora_ savedmail.docx”. However, there is no record of the downloaded file with JPG format. The directory of the downloaded files is “Documents/Inbox/[filename]”. As for download and delete operations, there is not such options available for CloudMe in iOS platform. We could not discover any appdata for CloudMe after the uninstallation of the application.
Table 6 shows the timestamp of the DOCX and RTF files, as well as JPG file format, which are being uploaded and downloaded during the experiments. When the files are uploaded, the date modified changed to the date and time being uploaded. Meanwhile, both date created and date modified changed to the downloaded date when the files are being downloaded.
Table 6
Timestamps of Original and Downloaded Files
| Created | Modified | Accessed | |
| docx | 11/16/2014 (12:05:35) | 11/17/2014 (14:15:43) | 11/16/2014 (12:05:35) |
| 11/16/2014 (17:37:49) | 11/16/2014 (17:37:49) | ||
| rtf | 11/16/2014 (12:05:35) | 11/17/2014 (14:19:52) | 11/16/2014 (12:05:35) |
| 11/16/2014 (17:38:13) | 11/16/2014 (17:38:13) | ||
| jpg | 11/16/2014 (12:05:35) | 11/17/2014 (14:24:40) | 11/16/2014 (12:05:35) |
| 11/16/2014 (17:58:47) | 11/16/2014 (17:58:47) |
3.3.2 Cloud Service: 360Yunpan
In this section we report our findings on 360Yunpan in several sections, based on the underlying platforms.
Windows 8.1—Client Application Based
360Yunpan client application provides users with 36 TB of online storage and it synchronizes all the folders on the user client application without the need to store the files on the users local machine. The installation of 360Yunpan 6.0.1.1090 client application creates a virtual drive on the computer, which allows users to see all their folders and directly manage their content stored on the cloud from any device. However, the virtual drive can only be opened and accessed when the application is running and the user is logged in. The installation of the app also creates a folder named 360CloudUI and 360Login which stores log files, application specific configuration files, and other related files for Yunpan client application. The list of files created during the installation is as follows:
• ProgramFiles(x86)360360WangPan360WangPan.exe
• \% USERPROFILE% AppDataRoaming360CloudUI
• \% SERPROFILE% AppDataRoaming360Login
Yunpan client sync metadata information is stored in “% appdata% 360CloudUI” directory, which stores a number of files containing sync information in the “log” file format, as well as user and application specific data in the files with “ini” file format. The configuration file shows traces of user specific data. The “LastAccount” directive shows the unique user ID generated by Yunpan during sign up and “CacheRootPath” shows the current directory of configuration files as shown in Fig. 23. In Fig. 24,“http” shows the IP address of the service provider of Yunpan; “cip” is the ip address of local machine; “pwd” directive only shows the encrypted password of the user cloud service credentials when the checkbox is ticked for the client to remember the password during sign in.
360Yunpan also generates sync and file metadata during file operations and stores them in the 360CloudUI folder under different configuration files. The sync.log file contains history of the file operations that users have carried out including login as shown in Fig. 25, uploading, and delete (Fig. 26) operations. The logs for downloading were not recorded.
Analysis on the live memory shows traces of username, userID, and a possible password as shown in Fig. 27. The password string is then analyzed using “Hash Identifier v1.1” to identify the type of hash being used on the password, but the results shows that the hash is unidentifiable. Regardless, there is still potential for further investigation.
The installation of 360Yunpan also made changes to the registry in Windows 8.1. Based on the registry data extracted, 360Yunpan starts up when the system boots and creates traces when user runs the program as shown in Fig. 28.
Analysis of the network traffic while performing operations on the files shows that 360Yunpan does not use any secure encryption or issued any certificate from any certificate authority for interactions between the client application and 360Yunpan cloud storage. The only information that could be found about the server-side is that 360Yunpan uses its own server—360server. As such, there were more data remnants gathered during the network traffic capture. Since the connection is not encrypted, using keyword searches, such as userid, username, and dataset filename, returns positive results for sync activity (as shown in Fig. 29). Similar results are obtained for upload, delete, and uninstallation. The upload activity that was captured in the network shows file metadata such as the filename, file size, MD5 hash, creation time, and modification time.
The timestamps for each of the datasets are recorded before uploading and upon downloading in 360Yunpan. The timestamps for each of the dataset before upload and download are the same. This is due to the virtual nature of the 360Yunpan hard drive, which does not store the files on the local machine and instead directly uploads them into the cloud as shown in Table 7.
Table 7
Timestamps and MD5 of Original Files and Downloaded Files
| MD5 | Created | Modified | Accessed | |
| docx | 4d16f5b7e1d5f8ea195bd87a600c6815 | 11/17/2014 (14:35:25) | 11/17/2014 (14:15:45) | 11/17/2014 (14:35:25) |
| 4d16f5b7e1d5f8ea195bd87a600c6815 | 11/17/2014 (14:35:25) | 11/17/2014 (14:15:45) | 11/17/2014 (14:35:25) | |
| jpg | 7f5ce91bb949b29c8d2deefaeb999d0f | 11/17/2014 (14:35:25) | 11/17/2014 (12:24:40) | 11/17/2014 (14:35:25) |
| 7f5ce91bb949b29c8d2deefaeb999d0f | 11/17/2014 (14:35:25) | 11/17/2014 (12:24:40) | 11/17/2014 (14:35:25) | |
| rar | f90f08cb35307de7b5b44e1c3ffd1445 | 11/17/2014 (14:35:25) | 11/17/2014 (14:33:20) | 11/17/2014 (14:35:25) |
| f90f08cb35307de7b5b44e1c3ffd1445 | 11/17/2014 (14:35:25) | 11/17/2014 (14:33:20) | 11/17/2014 (14:35:25) | |
| rtf | 97ae2ca81f0a88bb78eacceb22e2964b | 11/17/2014 (14:35:25) | 11/17/2014 (14:19:54) | 11/17/2014 (14:35:25) |
| 97ae2ca81f0a88bb78eacceb22e2964b | 11/17/2014 (14:35:25) | 11/17/2014 (14:19:54) | 11/17/2014 (14:35:25) | |
| txt | 83d78201914c892021290de6185f375c | 11/17/2014 (14:35:25) | 11/17/2014 (14:12:42) | 11/17/2014 (14:35:25) |
| 83d78201914c892021290de6185f375c | 11/17/2014 (14:35:25) | 11/17/2014 (14:12:42) | 11/17/2014 (14:35:25) |
Windows 8.1—Web Browser Based
We adopted “Web Browser PassView” during the analysis of Yunpan cloud service. However, we could only identify the username for Internet Explorer (Fig. 30). In what follows we demonstrate our findings while performing several operations, ie, upload, open/view, download, delete.
Upload—Live Memory/Browser Cache
We could find the LoginName in the memory as shown in Fig. 31. We used the keyword “name=“files[]”; filename=” to identify the files uploaded. As it can be seen in Fig. 32, we could discover the filename along with the method name “upload,” meaning that a file with the filename has been uploaded to the cloud service. Moreover, we found out that the files with names as highlighted in Fig. 33 have been uploaded to yunpan.360.cn using Chrome version 39.0.2171.65. We found the same evidence for the action of uploading files using Firefox version 33.0 under user “bob25775%2540gmail.com.”
Investigating the browsers cache, we could locate the username and encrypted password for Yunpan for all the three browsers in the URL part of the cached address as showed in Fig. 34.
Upload—Network Traffic
Analyzing the network traffic we could identify that the user with login name “bob25775%40gmail.com” has uploaded a file named “arora_ savedmail.docx” to yunpan.360.com at 27 Nov 2014 10:27:19 GMT (refer to Fig. 35). Moreover, we could recover the content of the uploaded file in TXT format using Chrome by analyzing the network traffic (as shown in Fig. 36), as well as RTF format. The rest of the file formats, such as DOCX (Fig. 37), and JPG were encrypted, while we could discover several files names in the file of RAR format (Fig. 38), and we believe that they are the archived files. We found same evidences using the browser Firefox.
Open/View—Live Memory/Browser Cache
We could discover the preview of the files in Yunpan easily from the method “method=preview” followed by the filename as shown in Fig. 39. Moreover, the version of web browsers that are used to access yunpan.360.cn to preview the file using “docviewer” is recoverable. Similar to the evidence discovered in memory, the cache of the three of the browsers has captured the URL address with “method=preview” and filename.
Open/View—Network Traffic
Analyzing the network traffic, we could capture the same data as memory and cache analysis: “method=preview” is identified as well as the cloud service Yunpan.360.cn and the filename being previewed (Fig. 40). Moreover, the filename in TXT format and the content of the file is recoverable.
Download—Live Memory
During the analysis of the live memory, we discovered that there were files being downloaded from Yunpan using Internet Explorer, Chrome, and Mozilla Firefox. Fig. 41 shows a part of the memory where the file, “arora_ savedmail.jpg.jpg”, has been downloaded (“method=download”) using Chrome 29.0.2171.65. The memory also captured the content of the file named “arora_ savedmail.txt” which was not encrypted.
Download—Network Traffic
The network traffic captured the action of files downloading from YunPan. As shown in Fig. 42, the user with “loginName=bob25775% 40gmail.com” has used the “method=download” to download the files from yunpan.360.cn. There were also same evidences for different files format, being downloaded using three browsers, Internet Explore, Chrome, and Mozilla Firefox.
Delete—Live Memory
There is no obvious evidences showing the deletion of files in Yunpan, however we have discovered the “buttonid= delete” has been selected as shown in Fig. 43.
Delete—Network Traffic
From the network traffic, we were able to identify the deletion of file from “POST /file/recycle” followed by the filename and date highlighted in the Fig. 44. There were also similar evidences discovered for all the three considered browsers, along with different file types.
As for the timestamp of the dataset, we discovered that when the files are being uploaded, the date modified will be altered to be the date and time when the files are uploaded. However, when the files are downloaded, the date modified will changed to the date and time of the downloading.
Android KitKat 4.4.2—Client Application Based
360Yunpan for Android platforms was not available in Google Playstore (at the time of experiments). The .apk file had to be downloaded from its official website. Upon installation, 360Yunpan creates a directory for storing user configuration files in “data/data/com.qihoo.yunpan” as shown in Fig. 45.
Analysis on the internal memory of Android 4.4.2 captured during the installation of 360Yunpan application shows traces of navigation to the 360Yunpan official website, and the downloaded apk file in the memory as shown in Fig. 46. 360Yunpan leaves traces of user account data such as user email and 360Yunpan unique user ID in the internal memory as shown in Fig. 47, as well as username and password of the mobile client application (Fig. 48).
Further analysis of the internal phone memory found that 360Yunpan leaves traces of file activity in the client device such as file download. However, we could not find any data remnants for file upload, delete and uninstallation. We captured the downloading of files into a new client device after logging into the test user account. Fig. 49 shows the files synching onto the client device from the cloud storage after logging in, including filename, date, and time.
During the file operations, we captured the network traffic using Wireshark 1.12.1 on the host machine. Analysis of pcap files shows that 360Yunpan uses SSL encryption for mobile version of the client application, which is issued by WoSign (Fig. 50). However, it is still possible to recover some data remnants showing file activities conducted between the mobile client application and 360Yunpan cloud storage. The activities found are login, upload, and download. Other information includes the device type and 360Yunpan user ID. Fig. 51 shows the network activity of uploading the datasets, where the filename and metadata are recognizable.
During the downloading of dataset files into the client device no filename or metadata are found. However, some of the file contents can be seen in the network streams such as the .rtf and .txt files (Fig. 52). Uninstallation of 360Yunpan mobile client application did not leave traces in the internal memory and network.
The results of analyzing timestamps for each of the datasets before uploading and upon downloading in 360Yunpan is similar to what we found for the Windows 8.1 client-based experiment. The timestamps for each of dataset before upload and download are the same. This may be due to the virtual nature of the 360Yunpan hard drive, which does not store the files on the local machine and instead direct uploads them into the cloud.
Apple iOS 8.0—Client Application Based
The application of Yunpan for iPad device is known as “360 YunPan HD” in Apple Store. The appdata for this cloud service in iOS platform is identified as “com.360.yunpanhd”. We could discover traces of installing the application from “info.plist”, “manifest.mdbd”, and “Manifest.plist” (Fig. 53). However, we could not find any login information.
There is no upload option available for iOS version of Yunpan thus the datasets have been uploaded to the cloud service via web browser in order to carry out the experiments. We were able to load all the five file types, however preview was only available for files with format JPG, DOCX, and TXT. After loading the files, they were downloaded and saved the directory Documents/c3eb49937bff58e03d20886e174d2f12/yunpan/ios/[filename]. We were able to discover the file names from the memory analysis (Fig. 54).
We performed the download operation by saving JPG file to gallery, downloading of RAR file, and there is no download option for files format with DOCX, RTF, and TXT. However the files have been downloaded by themselves when loaded for preview. The filename of the five datasets have been discovered from the file directory Documents/c3eb49937bff58e03d20886e174d2f12.db. After the deletion of the files, we could not find any traces of filename. Moreover, there was no traces on the appdata, after uninstallation of the application.
4 Reporting and Presentation
In this section we report our findings on each of the cloud platforms in Tables 8 to 13. The presented tables are subjected to change depending on applicability. (Y) shows the experimented section, while (N) depicts not-experimented section, and (NF) means there is no finding in a particular source of evidence.
Table 8
CloudMe Investigation—Windows 8.1 Client Browser Application
| Installation of client software (ie, what can be found in the stored files (ie, within Program Files, AppData, etc.), registry, and network traffic?). Other than setup and configuration data, we are particularly interested in looking for user-specific cloud service and authentication data (password file and the encryption method) | Y | |||
| Upload | Download | Delete | Sync | |
| Accessing web-based cloud app (What data remnants can be found in browser history, cache, cookies, etc. after a user has accessed web-based cloud app?) | Y | Y | Y | Y |
| Prefetch files | N | N | N | N |
| Link files | N | N | N | N |
| Pagefile.sys (can be extracted from FTK, similar to RAM analysis) | N | N | N | N |
| Thumbcache files | N | N | N | N |
| Event log files (event viewer) | N | N | N | N |
| Registry files | NF | NF | NF | NF |
| Unallocated space (can be extracted from FTK, similar to RAM analysis) | NF | NF | NF | NF |
| & recycle bin (FTK) | NF | NF | Y | NF |
| Network analysis (ie, server ip addresses/range, timestamps (do they correlate with the time you started up cloud service?), certificate used, keywords that could be used to filter only traffic of relevance) | Y | Y | Y | N |
| System volume information | N | N | N | N |
| RAM | Y | |||
| Compare the MD5 and creation, last added, last accessed, last modified times of files before and after file transfers (uploaded/downloaded/synced) | Y | Y | Y | Y |
| Uninstallation of client software (ie, what data remnants left in the stored files, registry, network traffic?) | Y | |||
Table 9
CloudMe Investigation—Android 4.4.2 Mobile Client Application
| Upload | Download | Delete | Sync | |
| Cloud app (if any) related artifacts (installation directory, credentials, timestamps of relevance from the plist (ios)/sqlite files) | N | N | N | N |
| Internal Memory | Y | Y | Y | Y |
| Compare the MD5 and creation, last added, last accessed, last modified times of files before and after file transfers (uploaded/ downloaded/synced) | Y | Y | Y | Y |
| Network analysis | Y | Y | Y | Y |
| Uninstallation | Y | |||
Table 10
CloudMe Investigation—Apple iOS 8.0 Mobile Client Application
| Upload | Access/ Open | Download | Delete | Sync | |
| Web-based cloud app artifacts (ie, what can be found in browser history, cache, cookies, etc. after a user has accessed web-based cloud app using a browser?) | N | N | N | N | N |
| Cloud app (if any) related artifacts (installation directory, credentials, timestamps of relevance from the plist (ios)/sqlite files) | Y | Y | N | N | N |
| Optional: RAM | N | N | N | N | N |
| Optional: Compare the MD5 and creation, last added, last accessed, last modified times of files before and after file transfers (uploaded/downloaded/synced) | N | N | N | N | N |
| Optional: Network analysis | N | N | N | N | N |
| Uninstallation | No evidence discovered. | ||||
Table 11
360Yunpan Investigation—Windows 8.1 Client Application
| Installation of client software (ie, what can be found in the stored files (ie, within Program Files, AppData, etc.), registry, and network traffic?). Other than setup and configuration data, we are particularly interested in looking for user-specific cloud service and authentication data (password file and the encryption method) | Y | ||
| Upload | Download | Delete | |
| Accessing web-based cloud app (what data remnants can be found in browser history, cache, cookies, etc. after a user has accessed web-based cloud app?) | Y | Y | Y |
| Directory listings: determining the sync/file management metadata, and files/folders added/removed during each cloud usage circumstance, ie, folders containing sync metadata information | Y | Y | Y |
| Prefetch files | N | N | N |
| Link files | N | N | N |
| Pagefile.sys (can be extracted from FTK, similar to RAM analysis) | N | N | N |
| Thumbcache files | N | N | N |
| Event log files (event viewer) | N | N | N |
| Registry files | Y | Y | Y |
| Unallocated space (can be extracted from FTK, similar to RAM analysis) | NF | NF | NF |
| & Recycle bin (FTK) | NF | NF | Y |
| Network analysis: server ip addresses/range, timestamps (do they correlate with the time that cloud service started up?), used certificate, keywords that could be used to filter only traffic of relevance | Y | Y | Y |
| System volume information | N | N | N |
| RAM | Y | Y | Y |
| Compare the MD5 and creation, last added, last accessed, last modified times of files before and after file transfers (uploaded/downloaded/synced) | Y | Y | Y |
| Uninstallation of client software: what data remnants left in the stored files, registry, network traffic? | Y | ||
Table 12
360Yunpan Investigation—Android 4.4.2 Mobile Client Application
| Upload | Download | Delete | |
| Cloud app (if any) related artifacts: installation directory, credentials, timestamps of relevance from the plist/ sqlite files) | N | N | N |
| Internal Memory | Y | Y | Y |
| Compare the MD5, creation, last added, last accessed, last modified times of files before and after file transfers (uploaded/ downloaded/ synced) | Y | Y | Y |
| Network analysis | Y | Y | Y |
| Uninstallation | Y | ||
Table 13
360Yunpan Investigation—Apple iOS 8.0 Mobile Client Application
| Upload | Access/ Open | Download | Delete | Sync | |
| Web-based cloud app artifacts: what can be found in browser history, cache, cookies, etc. after a user has accessed web-based cloud app using a browser? | N | N | N | N | N |
| Cloud app (if any) related artifacts: installation directory, credentials, timestamps of relevance from the plist (ios)/ sqlite files | Y | Y | Y | Y | N |
| Optional: RAM | N | N | N | N | N |
| Optional: Compare the MD5, creation, last added, last accessed, last modified times of files before and after file transfers (uploaded/ downloaded/ synced) | N | N | N | N | N |
| Optional: Network analysis | N | N | N | N | N |
| Uninstallation | No evidence discovered. | ||||
4.1 Cloud Service: CloudMe
In this section we provide reports of our findings while investigating CloudMe on Windows 8.1 web browser-based application in Table 8, Android 4.4.2 mobile client application in Table 9, and Apple iOS 8.0 mobile client application in Table 10.
4.2 Cloud Service: 360Yunpan
In this section we provide reports of our investigative study on 360Yunpan, considering Windows 8.1 client application (Table 11), Android 4.4.2 mobile client application (Table 12), and Apple iOS 8.0 mobile client application (Table 13).
5 Conclusion
In this chapter we conducted a forensics investigative study on two cloud storage services, ie, CloudMe, and 360Yunpan. In conclusion, we could find valuable forensic evidence related to CloudMe and 360Yunpan cloud storage accounts from various platforms. Data remnants such as user credentials, device names, filenames, and proof of activity can be found through various sources of evidences such as hard drives, live memory, internal phone memory and backup files, network traffic, and more. The gathered data further proves that each of the two cloud services leave digital footprints when file operations are carried out, as well as installation and uninstallation of the client application. This will help forensic investigators in rearranging and timelining the sequence of events for presentation as forensic evidence.
Some of the things to be highlighted are the implementation of encryption for each of the cloud storage services and the registry footprints. Although 360Yunpan offers the largest storage capacity free of charge, the security of the files during the transfer is weak compared to CloudMe. Due to the transparency of the data during file transfer, it was easy to sniff the traffic and gather much needed forensic evidence. In contrast, CloudMe leaves less digital footprints compared to 360Yunpan. The uninstallation of CloudMe, although leaves configuration files, it does not change any registry keys in addition to the use of encryption during the transfer of files. Therefore CloudMe is much more privacy preserving. As explained throughout the paper, it is easy to recover user credentials from the internal memory on Android platforms. Therefore there is a need for forensic investigators to reach a better understanding of the challenges in this regard.