You write to a logical drive when you read from it

Many unexpected things happen under the hood when you do live forensics. Tools used to acquire data from running Windows systems often utilize direct access to logical drives to copy locked files and extract NTFS metadata. But did you know that NTFS metadata is updated when you read a logical drive directly?

When something is directly reading from a logical drive (e.g., “\\.\C:”), the NTFS driver tries to ensure that a reader gets consistent volume data. To do so, the NTFS driver is flushing an opened volume during an early read request (which is not necessary the first one).

In my tests, the system volume (of a Windows 10 machine) is flushed when reading after the first 8192 bytes of volume data. The system volume isn’t always flushed when reading within the first 8192 bytes of volume data. (The exact condition is unknown.)

The same effect isn’t observed when a physical drive is opened instead of a logical drive.

During a flush, metadata in an $MFT file and nonresident $I30 records is updated. To demonstrate the scope of these modifications, the following experiment was conducted:

1. A virtual machine with a Windows 10 installation was set up.
2. “User files” were created on the desktop and in the documents folder. Some “user files” are empty, while others contain data.
3. The virtual machine was rebooted.
4. After the boot, several “user files” were opened and then closed (this was repeated multiple times for some of them).
5. The virtual machine was left running for more than 30 minutes.
6. A USB Flash drive was attached to the virtual machine.
7. An acquisition tool (FTK Imager Lite) was launched from that drive.
8. A snapshot was taken (the “before” state), then:
   • A logical drive (“C:”) was added as evidence. No further actions performed.
   • Another snapshot was taken after several seconds (the “after” state).
   • The first snapshot (the “before” state) was restored (the system clock didn’t jump to the current time).
   • A main window of the acquisition tool was closed (so the program got terminated).
   • Another snapshot was taken after several seconds (the “alternative after” state).

Then, I compared the “after” and “alternative after” states against the “before” state.

• 97% of entries located in the $MFT file (file records and resident $I30 entries, including those recovered from the slack space) taken from the “before” state are found unchanged in the “after” state.
• 99% of entries located in the $MFT file taken from the “before” state are found unchanged in the “alternative after” state.
• 99% of entries located in nonresident $I30 data taken from the “before” state are found unchanged in the “after” state as well as in the “alternative after” state (a total number of unchanged entries is slightly different between these two states).

So, $MFT data received more updates in the “after” state than in the “alternative after” state! Finally, I compared metadata entries for “user files”:

• No “user files” received metadata updates between the “before” state and the “alternative after” state.
• No “user files” received metadata updates in $I30 data (both resident and nonresident) between the “before” state and the “after” state.
• The following metadata fields for multiple “user files” received updates in file records (in the $MFT file) between the “before” state and the “after” state:
  • “Log file sequence number”,
  • “Last access timestamp” (in $STANDARD_INFORMATION attributes only).
• Both fields mentioned above were set to a greater value (for example, one last access timestamp was changed from “2020-02-16 22:38:18.623632” to “2020-02-16 22:53:59.169294”; the latter timestamp corresponds to step #4 in the list above).

Be careful when reading an NTFS volume on a live system! Especially if you want to preserve last access timestamps.