Windows Instant Messaging App Forensics: Facebook and Skype as Case Studies
Conceived and designed the experiments: TYY AD KKRC. Performed the experiments: TYY. Analyzed the data: TYY. Contributed reagents/materials/analysis devices: TYY AD KKRC. Wrote the paper: TYY AD KKRC ZM.
Abstract
Instant messaging (IM) has switched the way people communicate with each other. However, the interactive and instant nature of these applications (apps) made them an attractive choice for malicious cyber activities such as phishing. The forensic examination of IM apps for modern Windows 8.1 (or later) has been largely unexplored, as the platform is relatively fresh. In this paper, we seek to determine the data remnants from the use of two popular Windows Store application software for instant messaging, namely Facebook and Skype on a Windows 8.1 client machine. This research contributes to an in-depth understanding of the types of terrestrial artefacts that are likely to remain after the use of instant messaging services and application software on a contemporary Windows operating system. Potential artefacts detected during the research include data relating to the installation or uninstallation of the instant messaging application software, log-in and log-off information, contact lists, conversations, and transferred files.
1. Introduction
Instant messaging (IM) is popular with both traditional computing device users (i.e., individual computers and laptops) and mobile device users by permitting them to exchange information with peers in real time using text messaging, voice messaging, and file sharing. According to the report of Radicati Group [1], the number of worldwide IM accounts (with the exception of mobile messaging) in two thousand fifteen amounted to over Three.Two billion which is expected to rise above Three.8 billion by the end of 2019.
Similar to other popular consumer technologies, IM services have also been exploited to commit frauds and scams [Two–Four], disseminate malware [Five], groom children online with the purpose of sexual exploitation [6–9] etc. The talk logs can provide a good deal of information of evidential value to investigators [Ten, 11], which may often comprise a suspect’s physical location, true identity, transactional information, incriminating conversations, and other person information i.e., email address and bank account number [12].
Due to the enlargened user privacy requirements [13] and requests for data redundancy, it is increasingly challenging to collect evidential data from the IM service provider (ISP). The data are often protected by proprietary protocols, encryption, etc., making forensic practitioners virtually unlikely to collect meaningful information from outward network [14]. Moreover, collecting data from a multi-tenancy environment may breach the data privacy policies of the ISPs [15]. Even if the artefacts could be identified, the challenges are compounded by cross-jurisdictional investigations that may prohibit cross-border transfer of information [16–Eighteen]. In the worst-case screenplay, the ISPs may not even log the incriminating conversations to reduce traffic to the messaging servers [Nineteen].
Depending on the IM application in use, the client device can often provide potential for alternative methods for recovery of the IM artefacts [20–22]. In addition to addressing the possible issues in relation to evidence acquisition from the ISPs, the terrestrial artefacts can be useful in establishing whether a suspect has a direct connection to a crime, as the suspect may claim he/she is a victim of identity theft otherwise. While a practitioner should be cognisant of technics of digital forensics, it is just as significant to maintain an up-to-date understanding of the potential artefacts that are recoverable from different types of IM products. Hence, in this paper, we seek to identify potential terrestrial artefacts that may remain after the use of the popular Facebook and Skype Windows Store application software (henceforth the Store app) on a Windows 8.1 client machine. Similar to the approaches of Quick and Choo [23–25], we attempt to reaction the following questions in this research:
Findings from this research will contribute to the forensic community’s understanding of the types of terrestrial artefacts that are likely to remain after the use of IM services and apps on devices running the newer Windows operating system.
The structure of this paper is as goes after. Section two discusses the background and related work. Section three outlines the research methodology and experiment environment and setup. In Sections four to 6, we present and discuss the findings from the IM apps. We then conclude the paper and outline potential future research areas in the last section.
Two. Literature Review
A Windows Store app (formerly known as Metro app) mimics the touch-screen-friendly mobile apps, while retaining the traditional mouse and keyboard inputs [26]. The installation is treated exclusively by the Windows Store, which bypasses the execution of executable files [27]. The Store apps are licensed to Microsoft account, providing the users the right to install a same app on up to eighty-one different Windows eight (or newer) desktop clients under the same login [28]. The concept also enables the users to wander the app credentials (stored within the Credential Locker) inbetween the corresponding devices [29].
The Store apps are predominantly built on Windows Runtime. In addition to suggesting the developers a multi-language programming environment, the architecture isolates the apps from the file system for security and stability [26]. The app itself is a package (.APPX file) that incorporates the app’s code, resources, libraries, and a manifest up to a combined limit of 8GB [26]. Each Store app is represented by a package ID, which is often denoted by the package name followed by its build version, the target platform, and the alphanumeric publisher identification (ID). The installation and application folders can be generally located in %Program Files%\WindowsApps\[Package ID] and %localappdata%\packages\[Package ID] respectively [30, 31].
The application data, correspond to the app states [26], are stored in three (Three) categories: local, wandering, and temp states; each of which creates a subfolder in the application folder. The ‘LocalState’ folder holds device-specific data typically loaded to support the app functionality, such as makeshift files and caches, recently viewed items, and other behavioural settings. The ‘RoamingState’ folder stores data collective inbetween the same app running on numerous Windows devices under the same login. The data may include account configurations, favourites, game scores and progress, significant URIs etc. Meantime, the ‘TempState’ folder houses data temporarily suspended or terminated from the memory for restoration purposes, such as page navigation history, unsaved form data etc. The application data persist across the lifetime of a Store app, with the exception of the temp data which may be subject to disk clean up [26].
The application cache/data can be stored using caching mechanisms like HTML5 local storage and IndexedDB (for Store apps written in HTML and JavaScript) as well as other third-party database options like SQLite [32]. In the absence of encryption mechanism, the data can aid in reconstruction of user events such as cloud storage [28], emails [30], web browsing history [33], conversations [34], and other user-specific events [35], depending on the Store app in use.
Instant messaging has been the subject of numerous digital forensic studies since the mid 2000’s. In a series of early works, Dickson identified that artefacts of the client-based American Online Messenger version Five.Five (AIM) [16], MSN Messenger version 7.Five [36], Yahoo Messenger version 7.0 [37], and Trillian version Three.1 [38] could be recovered from the registry, user settings, and other application-specific files on the hard drive of a Windows XP machine. By applying keyword search, the author was able to recover portion of the conversation history from unstructured datasets such as memory dumps, slack space, free space, and exchange files in plain text, even with the absence of talk logging. The findings were echoed by several others studies with respect to Digsby [39–41], Windows Live Messenger 8.0 [42], and Pidgin Two.0 [43]. However, Levendoski et al. [44] concluded that artefacts of the Yahoo Messenger client produced a different directory structure on Windows Vista/7. Kiley et al. [Nineteen] investigated web-based IM apps (i.e., AIM Express, Google Talk, Meebo, and E-Buddy) and found that artefacts of the contact lists, conversations, and approximate time of the last conversation could only be recovered from memory dump and hard disk’s free space, albeit reference to the URLs, last access times, and view count information could be recovered from the web browsing history.
Wong et al. [45] and Al Mutawa et al. [46] demonstrated that artefacts of the Facebook web-application could be recovered from memory dumps and web browsing cache in Javascript Object Notation (JSON) and Hypertext Markup Language (HTML) formats. Al Mutawa et al. [46] also described a methodology for investigating the Arabic string artefacts on a computer device. In another examine, Al Mutawa et al. [47] investigated artefacts of the Facebook and several other IM applications on iPhone Four, Blackberry Torch 9800, and Samsung GT-i9000 Galaxy S. The authors were able to extract records of the contact list and conversation from the logical pics, with the exception of the BlackBerry devices.
Said et al. [48] investigated Facebook and other IM applications for iPhone 3G and 3GS, Blackberry Bold seven thousand and 900, Samsung Omnia II i8000, Nokia E71, and Ericsson G900. Of all the mobile devices investigated, it was determined that only BlackBerry Bold nine thousand seven hundred and iPhone 3G/3GS provided evidence of Facebooking unencrypted. The investigate also exposed that artefacts of the Facebook applications were unique to the mobile devices investigated (i.e., iPhone 3GS and iphone 3G had the same version of Facebook v3.Four.Two but maintained different files in the application folders). Walnycky et al. [49] added that artefacts of the Facebook Messenger could vary depending on user settings, OS version, and manufacturer. Levinson et al. [50] demonstrated that records of the latest Facebook talks stored in the property list of the Facebook Messenger for iOS can assist forensic practitioners with timeline analysis.
Examining iTunes backups rather than disk pics, Norouzizadeh et al. [Ten] and Tso et al. [51] concluded that it is possible to extract users’ private data, messages, contact lists and posts Facebook app from the iTunes backup of iPhone four and iPhone 5s, respectively. Chu et al. [52] focused on live data acquisition from the desktop private computer (PC) and was able to identify distinct strings that will assist forensic practitioners with reconstruction of the previous Facebook sessions. Wongyai and Charoenwatana [53] determined that objects recovered from a network analysis of Facebook homepage can be broadly categorised into twenty four types based on properties such as file type, naming pattern, IP address, and location or section on the page.
Sgaras et al. [54] analysed Skype and several other VoIP applications for iOS and Android platforms. Albeit footprints of the installations, user profiles, conversations, contact lists, and network traffic could be located for all the VoIP applications investigated, it was concluded that the Android apps store far less artefacts than of the iOS apps. Simon and Slay [55] found that remnants of Skype communication, communication history, contacts, passwords, and encryption keys could be recovered from physical memory dump. However, Teng and Lin [56] demonstrated that using SQLite editor instruments, one could lightly modify Skype log files. Unsurprisingly, other studies have suggested that the network traffic behaviour varies among different versions [57, 58].
In the only article on Windows Store apps for instant messaging (at the time of this research), Lee and Chung [34] studied the third party Viber and Line apps and identified that the package identifications (IDs) could be discerned from ‘2414F_C7A.ViberFreePhoneCallsText_p61zvh252yqyr’ and ‘NA_VER.LINEwin8_8ptj331gd3tyt’ respectively. By analysing the app caches, the authors managed to locate records of account logins, contacts, talks, transferred file unencrypted. However, the explore is only limited to dead analysis of the hard disk. Hence, there is a need to develop a further understanding of the implications of the Windows Store apps for IM forensics–a gap that this paper aims to contribute to.
Trio. Research Methodology
The examination procedure in this research is adapted from the four-stage digital forensic framework of McKemmish [59], namely: identification of digital evidence, preservation of digital evidence, analysis, and presentation. The purpose is to enable acquisition of realistic data similar to that found in real world investigations. This paper mainly concentrates on the analysis stage, albeit we also shortly discuss the evidence source identification, preservation, and presentation to demonstrate how the framework could be applied in practice.
The very first step of the experiment involved the creation of eight (8) fictional accounts to play the role of suspects and victims in this research–see Table one . The IM accounts were assigned with a unique ‘display icon’ and username which was not used within the respective IM apps and Windows operating system. This eases identification of the user roles. Next was to create the test environments for the suspects and the victims, which consisted two (Two) control base VMware Workstations (VMs) version 9.0.0 build eight hundred twelve thousand three hundred eighty eight running Windows 8.1 Professional (Service Pack 1, sixty four bit, build 9600). As explained by Quick and Choo [23–25], using physical hardware to undertake setup, erasing, copying, and re-installing would have been an onerous exercise. Moreover, a virtual machine permits room for error by enabling the test environment to be reverted to a restore point should the results are unfavourable. The workstations were configured with the minimal space (2GB of physical memory and 20GB hard drive space) in order to reduce the time required to analyse the considerable amounts of snapshots in the latter stage.