What happens to email attachment timestamps when a file is attached to an email message? As far as internal file metadata goes, nothing should change. Attaching the file does not change its contents, and internal metadata, such as the document’s author, title, creation and modification dates where applicable, should be preserved during transit.
How about file system metadata? Does plucking the file from the file system and attaching it to an email result in total loss of file system metadata? Not so, at least in an Exchange / Outlook environment. In fact, file system timestamps can survive the transit to the recipient’s mailbox, sometimes with 100-nanosecond precision!
How Outlook Stores Email Attachment Timestamps
Let’s take a look at how Outlook stores file system timestamps of a file that resided on an NTFS file system. As I mentioned in an earlier post about date forgery analysis and timestamp resolution, NTFS timestamps have 100-nanosecond resolution. We will first take a look at the attachment’s file system metadata before we attach it to an email.
I picked a plain-text log file as the subject matter, so internal document metadata is not applicable. Taking a look at the file system timestamps at full resolution shows that the file was created on 01/21/2017 at 03:07:54.3366204 (UTC), and last modified on 01/21/2017 at 03:09:31.7124446 (UTC). I will now attach this file to a new email using Outlook 2016, send it off to an Exchange user (on Exchange Server v15.1) and take a look at the metadata of the incoming message.
Here is the incoming email message with some of its MAPI properties visible via OutlookSpy. In Figure 3 below, you can see the MAPI Attachment Table, which contains information about all the attachment objects associated with the message.
Now let’s take a look at the IAttach interface for our specific attachment, “Download_Log_1_20_2017 7_07_54 PM.log”. We can see in Figure 4 that the PR_CREATION_TIME attribute is displayed as 1/21/2017 3:07 AM and the PR_LAST_MODIFICATION_TIME attribute is displayed as 1/21/2017 3:09 AM. These match the UTC file system timestamps of our original file. But, what happened to the full resolution?
We can open the individual properties to see the underlying data. As you can see in Figure 5 below, OutlookSpy interprets the underlying FILETIME structure for us, but it unfortunately goes up to millisecond precision. I will have to perform the conversion manually to get the full resolution.
Unfortunately, I have not been able to locate a forensic timestamp converter that displays FILETIME values in full resolution. So, I whipped something up quickly. As you can see in Figure 6 below, we have now recovered the file system timestamps of the attached file, with 100-nanosecond resolution.
Digital Forensics Implications
Being able to recover timestamps of a file on a file system before it was attached to an email can be very valuable in a digital forensics investigation. At a minimum, it provides additional metadata that can be used in conjunction with internal file metadata. In cases where internal file metadata is not present—as in this case where the attachment was a text file—having file system metadata can shed light on the history of the attachment.
Additionally, having access to timestamps with 100-nanosecond resolution is useful in date forgery analysis. For instance, if a suspect altered NTFS file system timestamps of a file with a utility that truncated the timestamps, reviewing the full resolution timestamps can reveal the forgery even after the file was transmitted via email.
It is important to note that finding a FILETIME value in the PR_CREATION_TIME and PR_LAST_MODIFICATION_TIME attributes is not a guarantee that the email attachment timestamps will reflect the attached file’s file system timestamps. For instance, I have reviewed emails sent via Outlook Web Access (OWA) and found that their MAPI properties did not reflect their file system timestamps.