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

[Mike Lococo]

Brad,

> 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

Just a quick note to let you know that I'm reproducing the strange 
behavior on a Windows XP Pro system with an NTFS filesystem.  I don't 
have a complete explanation, but offer some notes that may or may not be 
illuminating:

  - I was using 'dir /TA' to list access times from the native windows 
shell, and crosschecking them against access times from a cygwin shell 
using 'ls -lu'.
  - ls (in cygwin) saw different results than dir (in a native shell) 
after running a command-line file copy (in a native shell).  ls saw an 
updated access time whereas dir didn't.  It may be worth checking your 
results against an offline check in Helix or some other bootable 
forensic environment to see if there's some weirdness going on in 
windows that disappears when the write-cache is flushed and the fs 
accessed through a sane api (for example, I know that NTFS will delay 
atime disk-writes for up to an hour... but I had thought it would still 
return correct times when queried, but who knows).
  - It's worth noting that access times are somewhat unreliable in any 
case.  They can be changed by a sophisticated attacker, and I've noticed 
weird cases in other OSes where they don't get updated as well.  I 
noticed recently that 'strings' on macosx doesn't update atimes, don't 
ask me how or why.

Thanks,
Mike Lococo