Over the past several years, multiple tools have been released to enable API-based collection of cloud storage data. While this is an important capability, it has the often fatal liability that API-based collections require valid user credentials (and multi-factor authentication). An often overlooked area of cloud forensics is data and metadata stored on the local device. Unsurprisingly, endpoints which have synchronized to a cloud storage service may contain a wealth of information relevant to an investigation. Devices regularly record metadata on locally synchronized files in addition to files only present in the cloud. Deleted items may still be recoverable, and files may be present in cloud storage cache folders even when they were not selected for local synchronization. In short, cloud storage data can be more accessible on the local device and can contain files and metadata distinctly different than the current cloud repository. In the case of encryption technologies designed to keep data encrypted while in the cloud, the local archive may be the best available copy (even if incomplete). However, endpoint collection includes its own set of challenges.
On-demand Cloud Synchronization
The first generation of cloud drive applications were largely designed to synchronize local folders to backup copies in a cloud instance. Applications using this model are easy to investigate and collect evidence on since the files present in the local folder store are often identical to what can be found in the cloud. Recently a new model has emerged, allowing users to see and interact with all files present in the cloud drive, even when they are not present locally. Box Drive was one of the first to implement this feature, quickly followed by OneDrive and Dropbox Smart Sync. Implementing this feature has required application developers to use certain tricks to integrate cloud contents into the local view of the filesystem. As an example, the image below shows files from a OneDrive instance. OneDrive includes a new “Status” column and populates it with icons to indicate files only in the cloud (blue cloud icon) versus files available locally (green checkmark).
Over the past several years, multiple tools have been released to enable API-based collection of cloud storage data. While this is an important capability, it has the often fatal liability that API-based collections require valid user credentials (and multi-factor authentication). An often overlooked area of cloud forensics is data and metadata stored on the local device. Unsurprisingly, endpoints which have synchronized to a cloud storage service may contain a wealth of information relevant to an investigation. Devices regularly record metadata on locally synchronized files in addition to files only present in the cloud. Deleted items may still be recoverable, and files may be present in cloud storage cache folders even when they were not selected for local synchronization. In short, cloud storage data can be more accessible on the local device and can contain files and metadata distinctly different than the current cloud repository. In the case of encryption technologies designed to keep data encrypted while in the cloud, the local archive may be the best available copy (even if incomplete). However, endpoint collection includes its own set of challenges.
On-demand Cloud Synchronization
The first generation of cloud drive applications were largely designed to synchronize local folders to backup copies in a cloud instance. Applications using this model are easy to investigate and collect evidence on since the files present in the local folder store are often identical to what can be found in the cloud. Recently a new model has emerged, allowing users to see and interact with all files present in the cloud drive, even when they are not present locally. Box Drive was one of the first to implement this feature, quickly followed by OneDrive and Dropbox Smart Sync. Implementing this feature has required application developers to use certain tricks to integrate cloud contents into the local view of the filesystem. As an example, the image below shows files from a OneDrive instance. OneDrive includes a new “Status” column and populates it with icons to indicate files only in the cloud (blue cloud icon) versus files available locally (green checkmark).
ΩDescription: Microsoft OneDrive Storage Files and Metadata Author: Chad Tilbury Version: 1 Id: f3c680ca-0646-48cc-a471-5f484e22b1cf RecreateDirectories: true Targets: - Name: OneDrive User Files Category: Apps Path: C:\Users\*\OneDrive*\ IsDirectory: True Recursive: True FollowReparsePoint: True FollowSymbolicLinks: True Comment: "" - Name: OneDrive Metadata Logs Category: Apps Path: C:\Users\*\AppData\Local\Microsoft\OneDrive\logs\ IsDirectory: True Recursive: True Comment: "" - Name: OneDrive Metadata Settings Category: Apps Path: C:\Users\*\AppData\Local\Microsoft\OneDrive\settings\ IsDirectory: True Recursive: True Comment: "
Figure 2: KAPE Target File for OneDrive
The target file represented in Figure 2 demonstrates how easy it is to create (and modify) acquisition targets. In collaboration with Eric Zimmerman, two new collection options were added to KAPE to support cloud storage application collection. Recall that some “on-demand” cloud applications use reparse points and other symbolic link redirection to show files and folders to users that really exist in a different location (including only in the cloud). The options FollowReparsePoint and FollowSymbolicLinks will follow the redirection implemented by these NTFS features to collect the cached files in the redirected locations. They are particularly useful for the collection of Box and OneDrive files, but I suspect the community will find many other cloud applications requiring these options for collection. Of the most popular cloud storage applications, only Google File Stream cannot be collected with KAPE. This is due to the FAT32 volume it creates. In this case, FTK imager is a good backup as it will successfully image a Google File Stream volume (using the “Contents of a Folder” image option).
The KAPE Github repository includes target files for Box, Dropbox, Google Drive, and OneDrive. The meta-target file “CloudStorage.tkape” references these individual targets, facilitating collection using all the individual cloud app targets at once (and in the future will include any new cloud application targets added). It is important to note that the current KAPE target files only collect cloud storage files from default locations. If a user has renamed or moved their cloud storage folder, it will be missed by these target files (notice that the example in Figure 2 expects the “OneDrive” folder to be at C:\Users\<username>\OneDrive). Target files can be easily modified to collect any non-standard folder locations once they have been identified by the investigator. Thus, a review of the subject file system is recommended before you perform your final triage collection.
Danger!
A word of caution: when requesting files via reparse points, the cloud application may download files from the cloud as part of the collection process. To further emphasize, collecting files via the reparse points of some cloud applications may collect files from the cloud that do not currently exist on the device. This could cause storage space and scope of authority issues, and there is no way to only specify “local” files in these folders. Note that a logical image accomplished with a tool like FTK Imager will exhibit the same behavior. If this is a problem for your investigation, an excellent mitigation (and good best practice) is to isolate the subject system from the network. Alternatively, the examiner can take screenshots and manually copy the local files from the live system. This is a great example of knowing and understanding your tools before using them in a real investigation. In this brave new world for investigators, detailed planning before performing an acquisition will pay dividends.
Speaking of knowing your tools, the SANS Institute FOR498 and FOR500 digital forensics classes now cover KAPE and cloud collection and analysis in depth!
________________________________________________________________________________
Check out our webcast from December 3 conducted by Chad Tilbury here.
________________________________________________________________________________
Chad Tilbury, GCFA, has spent over twenty years conducting computer crime investigations ranging from hacking to espionage to multi-million dollar fraud cases. He is a senior instructor and co-author of FOR500 Windows Forensic Analysis and FOR508 Advanced Incident Response, Threat Hunting, and Digital Forensics at the SANS Institute. Find him on Twitter @chadtilbury.
.PNG "DFIR_ICON_(1).PNG"){kind=icon}
