PLS help: odd timestapm information through ENCASE

Hi mate, these timestamps aren't that odd, and pretty trivial to test.

Question 1 check what happens when you copy a file to a new location. The file system last modified will remain the same (i.e. earlier), and the file created will reflect when the file was copied (i.e. later).

Question 2 Last accessed gets triggered by all sorts of things - e.g. if a virus scan runs through a directory, last accessed will get updated (i.e. later), but file created/ file modified remains the same (i.e. earlier).

Question 3 Dunno. Probably something I should google or test some day…

If you're able to, start running some tests to see what happens to various time stamps as you do different actions. If you can test on exactly the same WinXP build then great, but I'd assume that Windows generally exhibits the same behaviour if you just want to do a few quick tests.

how can Last Accessed be later than Entry Modified, especially File Status is "File Deleted"?

A different theory for last access being a few seconds behind can be that the file is open in i.e. word, user saves, then 20 seconds later word closes down and the file handle is closed, triggering the last access.

As for deletion, i have no clue. Could be that the software is reporting the events in wrong sequence.

I think the following chart explains everything.

https://blogs.sans.org/computer-forensics/files/2010/04/Windows-Time-STDINFO.jpg
https://blogs.sans.org/computer-forensics/files/2010/04/Windows-Time-FILENAME2.jpg
Both jpg taken from https://digital-forensics.sans.org/blog/2010/04/12/windows-7-mft-entry-timestamp-properties

Things to be pointed out here, EnCase only reports the MACE time of a file from the Standard information attribute of MFT record. Whenever we want to compare all the MACE Time including those in the Filename attribute, you need some enscripts or do it manually.

Second, deletion of file will not alter any MACE time. There is absolutely no clue of time of deletion of file from the MFT. You can go for the $Logfile or $usnjrl.$J and bet you luck there.

Third, EnCase is just a tool, if you doubt about the result, please verify with other tools.

I think the following chart explains everything.

Not quite. It doesn't explain what research and tests the chart is based on, nor where it was published or if it has been criticized.

Or, expressed differently, how is that chart different from rumours, hearsay or folklore?

It's got to be, doesn't it? The term 'forensic science' got to mean something, doesn't it?

Does anyone know if there is any SANS course that teaches scientific methodology or source criticism suitable for computer forensics?

how can Last Written be earlier than File Created?

The NTFS BASIC_INFO timestamps are not immutable they can be changed by system calls.

Some Windows software does so Windows Shell is know to change 'real' file time stamps to be more user-friendly. Some install software restores original time stamps to installed files. File archivers may also do it on unpack/restore.

If that explains this particular case is another problem. The mechanism exists, and may be used by any user who has file access.

There are other mechanisms as well.

how can Last Accessed be later than Entry Modified, especially File Status is "File Deleted"?

Entry Modified is not well researched, as far as I know, so I won't make any definite statement about when it is set and when not. In general, however, it seems to be set when some file information outside the main data stream changes, but I have seen cases where that doesn't seem to hold true. So … research needed, I think. (Again, Windows Shell just may be interfering.)

But what about the following sequence of actions

1. Some change of file metadata changes a currently open file. That (probably) changes Entry Modified.

2. The file is closed some time later, setting the Last Access. Or perhaps … system is shut down, overriding running programs, and last Last Access found in timestamp cache is flushed to disk.

3. Still later, the file is deleted.

But, as before, the windows system call SetFileInformationByHandle() and FILE_BASIC_INFO data can do just about anything you want, including preventing individual file time stamps from being updated by later calls.

the deletion date of this file is actually 01/03/2015 102648AM, right?

What evidence that file deletion changes file stamps are you relying on here? Is there any?

As far as I know, there isn't.

Personally - and with all due respect to Encase - I would get a "second opinion" using Joakims' nice little $MFT and USNJrnl related tools

https://github.com/jschicht

The issue may be here which (out of the 6, 8 or 12 date/times [1] + GUID data if available) data Encase uses and represents (and how it represents them), JFYI
https://www.forensicfocus.com/Forums/viewtopic/t=15034/

Once established the validity of the data (ALL data, not only the selected one Encase displays), then (and this may depend on a number of factors, including the specific OS, the specific file type, the application/program used to access it, etc., etc.) there could be (or there could be not) an explanation.

jaclaz

[1] of course in most cases the two (or three) sets of 4 timestamps are the same, but you never know…