[unisog] Do Windows file access, file mod, file create timestamps lie?

[Paul FM]

Noticing that this could be a performance helper for all my machines I tested 
the registry key on NT SP6 and XP SP2 (speeds those machines up a little).

Guess what, none of the access times (files nor folders) are updated on NTFS 
file systems on those machines (NT SP6 nor XP SP2) with this registry key set 
(contrary to the below referenced documentation from Microsoft).

So, I suspect Microsoft added this a long time ago and documented it incorrectly.

By the way - I believe the granularity of the access time update is dependant 
on which version of NTFS you are using. On NT, it probably is an hour - but 
on a current machine with Windows XP SP2, I was seeing a much higher 
granularity of time (at least down to 5 minutes).

The big problem here is the lack of complete and accurate documentation from 
Microsoft.


John H. Sawyer wrote:
> On Sep 17, 2007, at 11:06 AM, Brian Eckman wrote:
> 
>> John H. Sawyer wrote:
>>> I hate to respond to my own messages, but thought I should provide
>>> links to backup my previous statements. The first is about how NTFS
>>> works and tells why the last access time may be up to an hour off.
>>> The second is a link to the registry that turns off last access times
>>> to speed up the filesystem because the action of reading a file would
>>> actually cause a write to the filesystem since it has to update the
>>> timestamp. In Vista, the key is present and set to 1 to turn off
>>> updates. If you've got any XP and Vista systems, compare them and
>>> you'll see.
>>>
>>> How NTFS Works
>>> http://technet2.microsoft.com/windowsserver/en/library/8cc5891d-
>>> bf8e-4164-862d-dac5418c59481033.mspx
>>>
>>> NtfsDisableLastAccessUpdate
>>> http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/
>>> regentry/46656.mspx
>>>
>>> I believe this is common knowledge amongst forensic people and may
>>> have just not filtered out to the rest of the security folks out
>>> there, but I'm not sure.
>>>
>>> -jhs
>> John,
>>
>> The URL you posted about the NtfsDisableLastAccessUpdate registry key
>> states that it "determines whether NTFS updates the last-access
>> timestamp on each directory when it lists the directories on an NTFS
>> volume". As a forensic investigator, this sounds to me like a desired
>> setting. In my opinion, viewing the contents of a directory is not
>> "accessing" a file, and therefore should not be updating that  
>> timestamp.
> 
> I agree. I just pasted the first link that I found that looked right  
> when googling the key name. The link you provided at the end explains  
> how it works in the real world.
> 
>> The article does not state that this registry setting prevents the  
>> Last
>> Accessed timestamp from being updated when the file is opened.  
>> However,
>> it appears, at least in Windows Vista (and likely Server 2003),  
>> that it
>> does prevent the timestamp from changing when the file is opened for
>> viewing.
> 
> MS supposedly added this key to Vista to speed up the filesystem  
> since they already knew Vista was a resource hog. System tweakers  
> looking to make their system as fast as possible have known about  
> this key for a while.
> 
> The key became part of conversations in the forensic community last  
> year when people were wondering what sort of curveballs Vista would  
> show up when doing forensics on the new OS.
> 
>> To verify this, I used my Windows Vista Enterprise system (with NTFS
>> filesystem on all volumes). I opened a text file, then closed it, and
>> checked the Last Accessed timestamp. It was sometime on July 9th. I
>> modified that registry key (set it to 0), then did the same. It was
>> still July 9th. I rebooted, and checked the Last Accessed timestamp
>> before opening the file - it was still July 9th. I then opened and
>> closed the file, and the timestamp was indeed updated to that  
>> second. I
>> then opened and closed it again, and the timestamp remained the  
>> same as
>> before - a few minutes earlier (which, as this thread has shown, is
>> expected, as it was well less than an hour later).
>>
>> Anyhow, I found a URL that more accurately explains the behavior of  
>> this
>> registry setting, at least on Windows Vista and Server 2003 computers
>> (and likely others). It's
>> http://technet2.microsoft.com/windowsserver/en/library/ 
>> 80dc5066-7f13-4ac3-8da8-48ebd60b44471033.mspx
> 
> -jhs
> 
>> Thanks,
>> Brian
>> -- 
>> Brian Eckman, Security Analyst
>> University of Minnesota
>> Office of Information Technology
>> Security & Assurance
> _______________________________________________
> unisog mailing list
> unisog at lists.dshield.org
> https://lists.sans.org/mailman/listinfo/unisog

-- 
---------------------------------------------------------------------
The views and opinions expressed above are strictly
those of the author(s).  The content of this message has
not been reviewed nor approved by any entity whatsoever.
---------------------------------------------------------------------
Paul Markfort   Info: http://www.menet.umn.edu/~paulfm
---------------------------------------------------------------------