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

[Michael Bayne]

I checked the MSDN pages on the GetFileAttributesEx function and found 
this little tidbit on the page describing the file attribute data 
structure (http://msdn2.microsoft.com/en-us/library/aa365739.aspx):

"Not all file systems can record creation and last access time, and not 
all file systems record them in the same manner. For example, on the FAT 
file system, create time has a resolution of 10 milliseconds, write time 
has a resolution of 2 seconds, and access time has a resolution of 1 day 
(really, the access date). On the NTFS file system, access time has a 
resolution of 1 hour."

So your testing isn't coarse enough to show any changes in the access 
times, since they all occurred within an hour (or day, if he was testing 
a FAT file system).



marchany at vt.edu wrote:
> One of the guys in my group tried to post to the list but got a failure. 
> Apologies if this is a duplicate. It's a question that's bothering us and 
> we're trying to see how this impacts us in a forensic investigation.
> 
> --------------------------------From Brad Tilley-------------------
> 
> In an effort to monitor access to files that might contain sensitive
> data, we've been experimenting with Windows timestamps. We have found
> that timestamps do not change when the files are viewed, printed or
> copied (basic file reads). We wrote some scripts to monitor the
> timestamps while various read access was occurring. Below are the
> results... perhaps we're way off base here and there is a simple
> explanation for this, but if timestamps on Windows are really as
> indifferent as they seem to be to reads, we're wondering how or if we
> can rely on them. Any input or feedback is welcome... Brad
> 
> Please note the win32file.GetFileAttributesEx() function is four hours
> (19:00) ahead while the python os.stat() function has the correct
> (15:00) time.
> 

<snip>

> 
>   ------------------------------------------
> 
> Randy Marchany (for Brad Tilley)
> VA Tech IT Security Office.
> 
> 
> _______________________________________________
> unisog mailing list
> unisog at lists.dshield.org
> https://lists.sans.org/mailman/listinfo/unisog

-- 

Mike Bayne
Security Engineer
baynema at jmu.edu
1.540.568.1684
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3229 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.sans.org/pipermail/unisog/attachments/20070917/b90d9173/attachment.bin