This is something I have been noticing in Windows for a while but just had a chance to track it down. I wanted to share what I’ve found as most of you likely handle loose EML files from time to time.
The Problem
When navigating a folder of EML files on NTFS using Windows Explorer, merely clicking on a file or right-clicking it causes Windows to update the file’s file system last modification timestamp. The file itself is not modified. It is not even launched. Take a look at the video below for a quick demonstration:
What’s Happening?
Looking at the file system after the above exercise reveals the following:
Alternate data streams named OECustomProperty are created for the EML files with which I interacted. Each ADS contains metadata about the email such as sender, recipients, etc. Presumably, the ADS is created by the property system in Windows to help with indexing the file. More info on this here:
The Cure
In my testing, clearing the registry key at the following location and restarting Windows Explorer (or, rebooting the computer) took care of the issue.
If you decide to do that, do not forget to make a backup of the key first. Also, if you care about Windows’ indexing of EML files, I recommend doing further testing on how this affects indexing.
Consider storing your evidence in a read only container. My preference is to store email evidence in a vhdx, encrypt it with bitlocker to go, then mount read only
Absolutely! This is something I’ve encountered in test data during software development, not on email evidence. That said, in the context of evidence, one can run into this issue during preservation. In your example, the VHDX has to be writable at some point before you wrap it up and mount it read-only. While it is writable, if an EML file is accidentally clicked or right-clicked, you can experience the issue.
When connecting to raw evidence (not an image) the easiest solution is to use a hardware write blocker. I currently use Wiebetech ComboDock or CRU USB 3.1 WriteBlocker devices.
Thanks, @gmitchell. In the digital forensics context, once we get to the point where we can write protect the data, we have quite a few options. I, too prefer a hardware write blocker when I can
I hope this quick writeup will also help explain some unexpected file system timestamp changes a forensic examiner can encounter when analyzing endpoints. That is, you are examining files from a suspect’s devices and find that some of their file system last modification timestamps were changed. Was it because the suspect modified the contents of the file, or was it the Windows property system’s creating an ADS because the suspect merely clicked on the file? (this applies to more file types than just EML files).
The modification timestamp in the $STANDARD_INFORMATION Attribute is quite resilient, and a change there can be challenging to explain outside of the file’s contents having been changed.
Specifically, when I collect email with FEC, I collect into a read/write VHDX. After the collection is finished I hash the VHDX and store the hash next to it. I also zip the collection up and hash the zip. If anything changes, the hashes will tell me. From there, the VHDX is forever-on mounted read-only. On the same note, it could be copied to new media and attached to write-blockers, etc.
My workflow is very similar to yours One addition I have is that I have FEC apply trusted timestamping at the end of the acquisition. Adds only a few seconds, but provides an immutable timestamp that shows when the acquisition was completed.
BTW, would it be helpful if FEC managed the VHDX output for you (i.e., option to output inside a VHDX), or do you prefer to handle that yourself?
I would love if FEC would bundle up everything and hash it for me.
For instance, when I collect an iPhone, it has a huge directory structure. My forensic programs (magnet acquire) zip it up and then hash the zip.
I care less about disk space and more about forensic integrity. So if we could download everything, zip it, hash the pieces, and save it all next to each other that would be fantastic.
