Acquiring Google Drive Attachments of Emails

Forensic Email Collector can acquire Google Drive attachments and their revisions during Gmail / G Suite acquisitions. You will be presented with three options in the Gmail API settings page:

1. Fetch Drive Attachments

When this option is selected, FEC will detect Drive attachments in acquired emails and attempt to acquire them.

2. Fetch Revisions of Drive Attachments

When this option is selected, FEC will also request revision information for each Drive attachment from Drive API. If the item has revisions, they will be acquired along with the parent Drive attachment.

Note 1: Each Drive attachment can potentially have hundreds of revisions. Acquisition of Drive attachment revisions can cause the acquisition to take significantly longer and increase the probability of throttling.

Note 2: Accessing the revisions of a Drive file requires different permissions than accessing the parent Drive file. You may encounter cases where the Drive attachment can be acquired but its revisions cannot due to lack of permissions.

3. Fetch Only the Latest Revision Before Parent was Sent

A Drive attachment that was referenced in an email can continue to be modified after the email was sent. When this option is selected, FEC will limit Google Drive revision acquisition to the latest Drive revision before the sent date of the email.

For example, let's look at the following timeline:

1. A file was created on Google Drive on January 1, 2019

2. The file was revised on March 1, 2019

3. The file was revised again on March 15, 2019

4. The file was attached to an email as a Drive attachment and sent on April 1, 2019

5. The file was revised again on May 1, 2019

When the "Fetch Only the Latest Revision Before Parent was Sent" option is selected, the current version of the Drive attachment (as of May 1, 2019) and the latest Drive revision before the email was sent (as of March 15, 2019) would be acquired.

How Are the Drive Attachments and Revisions Stored?

You can find the acquired Drive attachments and their revisions inside your output folder under "Items\!-- Drive Attachments --!\" in a folder structure that looks as follows:

Items\
   !-- Drive Attachments --!\
      <Parent Message ID>
         <Drive Attachment No>
              Revision_<revision date>_<revision ID>

Additionally, four log files named "Downloaded_Drive_Attachments", "Remaining_Drive_Attachments", "Downloaded_Drive_Attachment_Revisions", and "Remaining_Drive_Attachment_Revisions" will be created inside the "Logs" folder in your output directory. These logs will contain a list of Drive items as well as their metadata acquired from Google Drive.

Finally, the creation and last modification file system timestamps of the acquired Drive attachments and their revisions will be set to reflect the file metadata acquired from Google Drive.

Quick Tip: Google Drive provides hash values for external files (e.g., PDF, ZIP, etc.) that are stored in Drive and FEC captures this information during acquisition. The hashes that Drive provides are calculated using the MD5 algorithm. If you set your output hashing setting in FEC to MD5, you can easily compare the hashes that Drive reports to the hashes that FEC calculates for each file side by side.

What is A Permanent Error?

When acquiring Google Drive attachments, FEC pays attention to the status messages from Google Drive. If Drive API indicates that a Drive item is no longer available (i.e., it was deleted, moved, its permissions were changed, etc.), then FEC records that as a permanent error and does not attempt to retry the item multiple times. Such issues would be listed as "Drive Attachments with Permanent Errors" in the Acquisition Summary section of the Acquisition Log.

Packaging Drive Attachments and Revisions with Their Parent Messages

FEC provides the option to package Drive attachments and revisions with their parent messages in individual ZIP archives. This is possible for MIME and MSG output and the packaged files are saved at the following locations:

<project root>\Items\!-- Drive Attachments --!\!Packaged_MIME and 
<project root>\Items\!-- Drive Attachments --!\!Packaged_MSG

Drive attachment/revision packaging can be accomplished in two different ways:

1. During Project Configuration

When setting up the output options for a project, you have the option to choose Drive attachment/revision packaging options as in the screenshot below. These options are only available if the "Fetch Drive Attachments" option was selected.

If the packaging options are selected, FEC checks the acquisition status at the conclusion of the acquisition session. If all Drive items without permanent errors have been acquired, then it proceeds with packaging the Drive attachments and revisions. Otherwise, it holds off on the packaging as there are more items that have the potential to be acquired through additional retries. You can trigger the packaging manually via a post-acquisition action as described below.

2. As A Post-Acquisition Action

It is also possible to trigger the packaging of Drive attachments/revisions with their parents via a post-acquisition action. You can accomplish this by opening an existing project, and then clicking the " Package Drive Attachments Now..." hyperlink as in the screenshot below:

Note that the post-acquisition action is available even if the "Package w/Drive Attachments" output options were not selected during project setup. Clicking on the hyperlink will cause FEC to do the following:

  • Check the output folder to see if Drive attachments/revisions were packaged previously. If so, a new, unique set of folders will be created to house the new set of packaged files.
  • Package the Drive attachments/revisions for all applicable output types. That is, both MIME and MSG output options if they had been selected during project setup.

What Are the Conditions for Drive Attachments to be Packaged?

At the end of an acqusition, you may notice that you have more subfolders under the "!-- Drive Attachments --!" folder than you have ZIPs inside the "!Packaged_MIME" or "!Packaged_MSG" folders. This is because a parent message must have at least one successfully acquired Drive attachment or revision for the ZIP package to be created. If the Drive attachment or revision acquisition is unsuccessful (e.g., the file is no longer available), you might have a folder for the attachment but no package ZIP as there is no Drive attachment or revision to include in the package.

Did this answer your question? Thanks for the feedback There was a problem submitting your feedback. Please try again later.