The (in)consistency of last access timestamps

Since the “Last Access” updates are almost back, let’s revise the consistency of last access timestamps present in NTFS file systems.

There are some misconceptions about how and when these timestamps are updated.

Let’s take a look at what Microsoft writes about last access timestamps.

FILETIME structure:

On NTFS, access time has a resolution of 1 hour.

Disabling Last Access Time in Windows Vista to improve NTFS performance:

Last Access Time has a loose granularity that only guarantees that the time is accurate to within one hour.

File Times:

The NTFS file system delays updates to the last access time for a file by up to 1 hour after the last access.

Fsutil behavior:

 

• File-based Last Access Time queries are accurate even if all on-disk values are not current. NTFS returns the correct value on queries because the accurate value is stored in memory.

• One hour is the maximum amount of time that NTFS defers updating Last Access Time on disk. If NTFS updates other file attributes such as Last Modify Time, and a Last Access Time update is pending, NTFS updates Last Access Time with the other updates without additional performance impact.

 

None of these quotes is absolutely correct, only the last one is very close to the truth.

On Windows XP SP2 (64-bit), Windows 7 SP1 (32-bit; the last access updates were explicitly enabled), and Windows 10 “Redstone 5” (also known as October 2018 Update; 64-bit; the last access updates were automatically enabled in the “System Managed” mode), it was observed that last access updates occur even when a previous value of a last access timestamp for a given file isn’t older than an hour. Thus, on NTFS, last access timestamps don’t have a resolution of one hour (at least in the versions of Windows mentioned and tested). So, the first two quotes above don’t contain accurate information.

However, these last access updates don’t always hit a drive immediately. Only a last access timestamp in memory is always updated immediately, but it could take some time for that updated timestamp to be written to a drive. This is very close to the last two quotes above.

But one hour isn’t always enough for a last access update to reach a drive.

In one of my tests with Windows XP SP2 (64-bit), an updated last access timestamp of a file in a desktop folder wasn’t written to a drive for 1.5 hours (and it was lost after I rebooted the operating system when trying to flush this timestamp to the drive, so even the reboot didn’t trigger the write).

In one of my tests with Windows 10 “Redstone 5” (64-bit), an updated last access timestamp of a file in a folder on a desktop wasn’t written to a drive for more than 12 hours! In fact, this timestamp appeared on the drive during the shutdown (when I decided to stop the test).

In similar tests, other updates to the $MFT data (like new file records) were written to a drive as expected, with no significant delay. Thus, this is not a global cache for write requests.

Thus, last access timestamps may be considered as a sort of volatile data during a forensic acquisition. However, I’m not aware of any tools to extract such timestamps from a memory image. So, examiners should consider collecting last access timestamps from a live machine using other means like running a tool which retrieves these timestamps using standard API calls.

---

And this is not the end!

During the tests, I found that a last access timestamp obtained from one source may be inconsistent with a last access timestamp for the same file obtained from another source. This was also documented by Hideaki Ihara here.

The reason is that there could be two different last access timestamps stored for a single file: one in a file record and another one in an index record ($I30). The first source, which is also overlaid with a last access timestamp in memory (as described above), is used by some API calls, while the second source is used by other API calls.

For example, the FindFirstFileExW() call uses index records to retrieve data about a file found. And this data may contain an “older” last access timestamp.

For some reason, last access timestamps from these sources aren’t always synchronized.

During the tests, such inconsistent last access timestamps were observed (at least once) in $MFT data and $I30 data (both located on a drive) from the following operating systems: Windows 7 SP1 (32-bit and 64-bit), Windows 10 “Redstone 5” (64-bit), Windows 10 “Insider Preview Build 18298” (64-bit).

Here is how it looks like in a HEX editor: