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.

Indeed. This is why I said they were "apparently" redundant.

I think that the Microsoft developer told me that he thought the timestamps in $FILE_NAME were a left over from an early optimization that was dropped before NTFS was first publicly released. The same structure is, of course, present in the directory indexes which is possibly why they remain to this day. My original experiment didn't address this. I haven't tried it yet but I expect the index timestamps are updated in sync with the $STANDARD_INFORMATION.

Jim

www.binarymarkup.com

I haven't tried it yet but I expect the index timestamps are updated in sync with the $STANDARD_INFORMATION.

There are many real-world situations when these timestamps are out-of-sync (and I saw one with a keylogger's journal having different timestamps in these two sources). Even the official documentation states that they can be out-of sync:

Note  In rare cases or on a heavily loaded system, file attribute information on NTFS file systems may not be current at the time this function is called. To be assured of getting the current NTFS file system file attributes, call the GetFileInformationByHandle function.

the timestamps in $FILE_NAME were a left over from an early optimization that was dropped before NTFS was first publicly released

There are many real-world situations when these timestamps are out-of-sync (and I saw one with a keylogger's journal having different timestamps in these two sources). Even the official documentation states that they can be out-of sync:

Note  In rare cases or on a heavily loaded system, file attribute information on NTFS file systems may not be current at the time this function is called. To be assured of getting the current NTFS file system file attributes, call the GetFileInformationByHandle function.

I think you should have included exactly where that caveat appears.  I find it in the documentation of FindNextFile(), which seems likely to be used by software that enumerates files in directories, such as software for creating live images or file archives. 

Microsoft documentation also says somewhere that the only situation in which on-disk file time stamps are guaranteed to be 'correct' is when the file has been closed for access (this flushes all in-core data related to that file/file handle to disk). That is, a live image (done through the use of FindNextFile() and related calls) cannot be guaranteed to be 'true', and must be interpreted with this in mind, unless additional precautions are taken.  The same will obviously be true for unclean file systems, where normal closing and dismounting has not been done, perhaps due to a crash or a hard power failure.

Additionally, there is (or was) a documented limit to such out-of-sync-ness: at most one hour before an in-core time stamp was synced with on-disk structures.  This is almost certainly a worst-case situation: in most situation it happens must faster. But in situations where a file has been opened for processing, and processing stalls for any reason (bug, lack of input data, etc.), the latest time stamps (typically last access, if enabled, and probably also the modification timestamps) might remain un-flushed until some internal NTFS book-keeping flushing done on a one-hour basis is performed. 

This means that any NTFS time stamp taken from a live image might, in the worst case, be out of sync by at most one hour. If proper precautions are taken by the imaging software, that may be reduced to minimal amounts. Whether or not proper precautions are taken for closed-source software needs the support of the manufacturer of that software to clarify, or some serious testing on heavily loaded systems.

I think you should have included exactly where that caveat appears.

See my blog post (linked above) for at least one related condition.

Microsoft documentation also says somewhere that the only situation in which on-disk file time stamps are guaranteed to be 'correct' is when the file has been closed for access (this flushes all in-core data related to that file/file handle to disk).

Not really. The NTFS driver attempts to provide consistent & up-to-date metadata when an application tries to read from a logical volume (e.g., \\.\C:) directly. Thus, simply reading from a logical drive (e.g., using FTK Imager Lite) can change many timestamps ("older" timestamps will be replaced by "newer" ones).

Additionally, there is (or was) a documented limit to such out-of-sync-ness: at most one hour before an in-core time stamp was synced with on-disk structures.

[...]

This means that any NTFS time stamp taken from a live image might, in the worst case, be out of sync by at most one hour. If proper precautions are taken by the imaging software, that may be reduced to minimal amounts.

Not true. There was a documented limit for the last access timestamp updates, but it wasn't enforced (in fact, the documentation is slightly wrong). I have seen last access timestamps not being updated for more than 12 hours (no shutdown/sleep/hibernation involved). Again, this was documented long time ago.

Also, how about 22 hours for the file modification timestamp? I have seen that on a real system. (Other examples in the blog post linked before.)

@jimc

These links may be relevant to the OP's needs, and to your interests:

http://www.kazamiya.net/en/NTFS_Timestamps

https://www.sciencedirect.com/science/article/pii/S1742287619300234