NTSF MFT Entry Modified

1. Only accessing a file will change the MFT Entry Modified date? (same as last accessed date)

Don't think this is the case

1.1 Will this always happen?

See above

2. What types of system events can trigger changes at MFT Entry Modified date?

Any part of the entry is modified

If you want more useful answers, it may be better to give more information on what your actual problem is.

Posted by: @gforensic

Some doubts about MFT Entry Modified date:

1. Only accessing a file will change the MFT Entry Modified date? (same as last accessed date)

1.1 Will this always happen?

2. What types of system events can trigger changes at MFT Entry Modified date?

 

I don't know of any systematic research into the NTFS ChangeTime attribute, which is what I assume you are referring to.  If you can confirm that, you are basically reduced to 'I don't know' as soon as this time stamp is being discussed.

It is usually assumed that ChangeTime is updated when file metadata is changed directly.  That is, if a time stamp is set by SetFileTimeByHandle(), ChangeTime would change.  But if the time is set indirectly by opening or writing the file, it is not changed.  However, partial information is not necessarily of any particular forensic use unless you can describe exactly what it doesn't cover, and know whether those cases are present in your particular case.

However, the system call SetFileByHandle() allows time stamping to be turned off, selectively, so every test needs to be done both normally, and with disabled time stamping.  There may be other such areas where ChangeTime may be affected. (Remote file systems?)

In order to make sure, all Windows file-related system calls would need to be tested under all (or almost all conditions), and outcomes evaluated. And probably also on different releases of NTFS. I tried to do something like that many years ago, but ... it was simply a bigger job that I expected.  (A better way would be to inspect the source code ... but that is probably not practical for most practitioners.)

The best thing you can do, I think, is to find out where you got the idea that just accessing a file will change this timestamp, and post a reference to it. That way there's at least the opportunity for correction. It may be an unreliable source.  It may be a misinterpreted source.  And so on.

Posted by: @gforensic

1. Only accessing a file will change the MFT Entry Modified date? (same as last accessed date)

Incorrect.

1.1 Will this always happen?

Not relevant now that 1. is incorrect.

2. What types of system events can trigger changes at MFT Entry Modified date?

One example, renaming the file.

@athulin I read this part of FILE SYSTEM Forensic Analysis (Brian Carrier) and I got a little confused:

"The MFT modified time is set when any of the attributes are changed, and I also have
observed that it is set when an application opens a file but does not modify the content".

I decided to read more deeply on the subject because I came across a file that had the timestamp of the access date and mtf date changed exactly the same (the file modification and creation dates were earlier). Just for curiosity. So I didn't go into details.

But now, I looked in depth at the date/times attributes of the file, i checked that the attribute that caused the MFT modification date was the attribute related to 8.3 filename - INDX Entry Date Accessed. In fact the file has a long name, so it was created a entry in MFT for the short name. And now I wondering if if the simple access to the file in that condition may have triggered this time stamp updated, and will be always like this.

But thank u for the atention.

All references to the nonexisting calls SetFileTimeByHandle or SetFileByHandle should be to SetFileInformationByHandle.

@gforensic

Thanks for the reference.

I can't explain Carrier's statement -- and as it seems to contradict his own statements that a) the time that the metadata of the file was last modified, b) set when any of the attributes are changed, I would hesitate to interpret it.  (In both those cases, the file is opened -- so when does Windows decide that nothing was done with it? When it is closed? Or is the idea that opening the file changes access time, and that forces a MFT Modified time change?  Does it really happen that way? My impression is that it does not, but ... tests take priority to impressions.)

It is a pity Carrier did not describe the test that made him make that last observation: tests need to be performed several times, not impossibly on different systems, and with lots of services disabled to exclude that any Windows process affects the result.

For that reason, I would hesitate to base any argument on 'MFT Modified Time/ChangedTime changes when a file is just opened',  unless I had tested it very carefully. (The point you mention, short name generation, would mean testing on systems where auto-generation of short names was enabled, as well on systems where it was disabled.)

Changing a short file name is tantamount to change file metadata, so I would lean towards to assumption that that operation (changing the short name, or deleting it, or creating a short name for a file that doesn't have one already) would modify the MFT Modified Time = ChangeTime attribute.  (This would mean calling any of the SetFileShortName File Management Functions with legal parameters under normal conditions -- what happens if there's some kind of error during its execution is another matter. It might happen as a byproduct of some other call, say, SetFileInformationByHandle if that allows setting short names.)

@athulin

I did some tests to try to reproduce some scenarios, short names, long names, just opened files and closed them, turned off the machine, generated an image, but the truth is that I didn't identify any pattern. Some have changed the modified date of the MFT, others have not. Nothing can be said, you are allright.

I did some research into NTFS timestamp behaviour a few years ago. My main interest was the timestamps in the $FILE_NAME attribute. These duplicate those in the $STANDARD_INFORMATION attribute and are (apparently) redundant. I summarised the results in a number of state diagrams. These may be useful to others.

The main conclusions were:

1. $STANDARD_INFORMATION timestamps behave as expected. The Last Accessed timestamp is typically only updated when that feature is enabled in the OS. The Entry modified timestamp is updated to the current time whenever the $STANDARD_INFORMATION attribute is re-written.

2. The $FILE_NAME timestamps mirror those in $STANDARD_INFORMATION at the time the $FILE_NAME attribute was last re-written. In practice, this occurs when the file is first created, when it is renamed and when it is copied (which is strictly a new file). 

3. There are some subtle variations between OS releases that may be forensically useful.

Since I wrote the report, I have identified two areas where it could be improved:

a. It doesn't mention the SetFileInformationByHandle() API. This can be used to change all 4 timestamps in the $STANDARD_INFORMATION attribute. 

b. The $FILE_NAME attribute timestamps are potentially relavent when found in the $I30 indexes. 

As part of the research, I found several academic papers that discuss the issue and also managed to make contact with an engineer in the NTFS development team at Microsoft. This information and the technique used may be useful to others. I have put the report chapter that discusses this on my website www.binarymarkup.com

I hope this helps. It was some years ago that I did this work and it is possible that the situation has changed with more recent Windows releases. Please let me know if you spot any problems.

Jim

www.binarymarkup.com

These duplicate those in the $STANDARD_INFORMATION attribute and are (apparently) redundant.

No, they can be different.

The Last Accessed timestamp is typically only updated when that feature is enabled in the OS.

It's enabled by default (on older versions of Windows 10, it could be disabled, but the last access updates are always enabled for the OneDrive folder). However, since Windows Explorer shows you $FILE_NAME timestamps, you might not see an update immediately.