Since I’m home and the baby is asleep I thought I’d spend some time on this weeks Sunday Funday challenge. I probably should sleep too, but that’s a problem for future me 🙂

The Challenge:

What does performing a copy and paste across two NTFS volumes do to timestamps of the file being copied and the file that is created due to the copy in Windows 7 and Windows 10.

More information on Windows timestamp rules can be found here: SANS “Evidence of” poster

The plan was to test the operation on both Windows 7 and Windows 10, but after writing out my testing plan, I figured I would just stick to Win10 (1803) and be a bit more comprehensive.

To get started I downloaded a Windows 10 VM and then created a VHD (created 2nd Nov 2018 at 10:16AM AEST) that I can attach. I made copies of the VM each time I did a test and then extracted out the $MFT. This volume contained an executable, a zip, a text file and a Word document (docx).

All the variations

I used a number of different methods of copying and pasting. Not every possible permutation though.

1. Keyboard copy and paste (ctrl c/v)
2. Right Mouse Click copy and paste
3. Ribbon copy and paste
4. Ribbon copy to location (there’s a series of locations, but I specified my own)
5. Right Mouse Click, send to Documents
6. Drag files off the external volume (which creates a copy)
7. Command line copy and paste

Findings

You can take a look at my spreadsheet here.

For the most part it looks like all of the methods of copying and pasting that I used had the same effect on changing timestamps.

Between the original and the copy

1. Created timestamp (SI/FN) was updated to reflect the time of the copy
2. Modified timestamp (SI) was unaffected
3. Modified (FN) was updated to reflect the time of the copy
4. Entry Modified (SI) was not changed between original and copy, but was updated (I think by my restarting the machine. But only for some filetypes, for ex: zip and exe were unaffected)
5. Entry Modified (FN) was updated to reflect the time of the copy
6. Access (SI) I think was messed up due to the way that I performed the testing, but interestingly each methods access timestamp was affected slightly differently. For example, the ZIP files original and copied Access time is exactly the same.

 

It looks like restarting the computer has affected the Access and Entry Modified timestamps a little bit. But that’s shown some interesting things; restarting the machine may modify these timestamps, but then if they’re copied/pasted that may or may not update the timestamp depending on the file type.

So what did we learn?

On Win10, it seems that the methods of copying and pasting are fairly consistent with our current understanding of copy operations, except that anomalies were identified in the way that Access timestamps are treated (which is expected). Sometimes the timestamps are updated quickly, sometimes there’s a longer delay. *shrug* Windows.

The modified (SI) timestamp is consistent across all operations and all file types.

The created (SI and FN) timestamp is updated to reflect the time of the copy across all operations and all file types.

---

As a side note, if someone wants to create an MFT monitor, that would be awesome. That way you can select a file and then get notified when its timestamps change. The main issue I had thinking through how I would run these tests is identifying if the operations had effects on the original files.

---

Addendum:

After I wrote this I figured I’d do a quick, less comprehensive, test on Win7 (32-bit). Just did a quick copy and paste using the mouse to the Desktop and recorded the results.

The only difference that I noticed between Win7 and Win10 was that the access timestamp on the original file wasn’t changed to the copy time in Win7. Otherwise, the $FT MACE and $SI ACE timestamps all reflected the time of the copy, and the  $SI Modified timestamp was preserved.