This morning, in my Enfuse talk (MAC Times, Mac Times, and more) I made a blanket statement. I usually avoid these but, in this case, I made a deliberate blanket statement. I provided the example from the SANS Windows Forensic Poster and showed, from the poster, that MAC times are not updated when a file is deleted. I also bemoaned the fact that there are many forensic investigators that still believe that MAC times are updated at the time of deletion. Today I’m on a quest to change their minds.
SANS has published this poster for several years and it is maintained by some of the smartest people I know. In addition to that I’ve also done my own testing and seen things from my own investigations. I have never seen a MAC time updated for the deletion of a file on a Windows computer. Never. Not in over 10 years of working in this field, not in the around 500 investigations I’ve conducted.
Let’s talk about what I mean by deleted. What does it mean?
- Soft delete – This is where a file is moved to the Recycle Bin. In this instance the name of the file is changed to something like $R101ABA. When the file name is changed it triggers an update to the “Modified” or “Metadata Changed” field.
- Hard delete – This is when a) the Recycle Bin is emptied, or b) a file is deleted through bypassing the Recycle Bin. It is when the file is rendered to unallocated space. None of the standard information attributes or filename attributes are updated.
- Third-party delete – This is when software such as CCleaner is used. CCleaner wipes/erases files from the drive but not before changing its name to something like ZZZZZZZ.ZZZ. In instances like this, where the file name is being changed, the “Modified” or “Metadata Changed” field is updated to reflect the file change. The eradication of this file happens almost instantaneously so the deletion appears to have been the cause, but it is not. It was the file name change, prior to deletion, that caused the update.
Let’s take a look at an example. I have a file as follows:
- Name: me.jpg
- Created: 02/11/2014 14:07:10
- Last Written: 02/03/2014 09:42:17
- Accessed: 02/11/2014 14:07:10
- Entry Modified: 02/11/2014 14:07:10
If I put this file in the recycle bin at 11/5/2014 the record updates to something like this:
- Name: $R01ROJ78.jpg
- Created: 02/11/2014 14:07:10
- Last Written: 02/03/2014 09:42:17
- Accessed: 02/11/2014 14:07:10
- Entry Modified: 11/05/2014 11:27:08
Note that the modified time changes because of the file-name change, not necessarily because it was placed in the recycle bin. When the recycle bin is emptied, none of the dates and times in the $MFT are updated.
What about if I use CCleaner to erase the file?
- Name: ZZZZZZZ.ZZZ
- Created: 02/11/2014 14:07:10
- Last Written: 02/03/2014 09:42:17
- Accessed: 02/11/2014 14:07:10
- Entry Modified: 11/05/2014 11:27:08
Once again, the modified time is updated because of the file rename only. Yes, the deletion time will likely follow very quickly, but the removal of the file does not trigger an update to that field, only the renaming of the file.
And when the file is deleted by bypassing the recycle bin (shift-delete)?
- Name: me.jpg
- Created: 02/11/2014 14:07:10
- Last Written: 02/03/2014 09:42:17
- Accessed: 02/11/2014 14:07:10
- Entry Modified: 02/11/2014 14:07:10
Nothing. Nothing is changed at all.
Let’s look at another scenario. You receive a computer on 08/18/2017 for analysis. When you review the contents of the computer you note that a deleted file has the following properties:
- Name: secret-plan.doc
- Created: 08/12/2017 16:15:12
- Last Written: 08/17/2017 19:01:33
- Accessed: 08/17/2017 19:01:33
- Entry Modified: 08/17/2017 19:01:33
You may be tempted to say, “The file looks like it was deleted at 08/17/2017 at 19:01:33.” But you’d be incorrect. What we have here is a window in which the file was deleted. We know that the file was deleted sometime between 08/17/2017 at 19:01:33 and the time that the computer arrived on your desk. This may be a window of only a few hours, as in this example, but it could be a windows of days, weeks, or even months. In instances such as these it would be well worth your time carving out $USNJRNL records using something like TriForce from GC Partners in order to determine the file deletion times.
Definitive blanket statements are not often made in this field. As such, when these statements are made, they are not made lightly. Yes there will be instances where metadata may change immediately before the deletion took place, especially when using third-party tools, but the MAC times are not updated on file deletion, period.
9 responses to “Deleted vs “Deleted””
nice! But, what about a shift+deletion using Windows Xp or in a modern Windows system in which the owner changed the registry key: NtfsDisableLastAccessUpdate from 0 to 1 value?
AFAIK if you select the file or only open the directory containing the file the access timestamp changes. What do you think?
Hi Nanni,
I have tested it. Same thing. Last accessed is not updated at the time of deletion.
But if you have a file with last access timestamp at 11/11/2011 and you access it now, the last time access will be 05/27/2017 (in old windows xp or new systems with that registry key changed) when you’ll want delete it, you should open the folder in which the file is and select it for deleting, so in this scenario if you have the NtfsDisableLastAccessUpdate changed or you are using an old Windows XP, the last access timestamp is changed before you delete it…because the action of selecting or seeing the file is changing that timestamp. Can you explain me your test in this scenario? Thanks 😉
Nanni, yes, if you access the file you will change the access time but only if access times are enabled. But, if someone just straight deletes the file, there is no access. What you’re proposing is that someone opens the file and then deletes it. Once again, the only time that would be updated would be the access time IF access times are enabled. Given that Windows XP has an ever shrinking market share, and that I’ve never seen anyone use the NtfsDisableLastAccessUpdate registry value, it all seems rather moot. The fact remains, deletion does not cause timestamp updates.
Yes Lee, I was just describing that scenario, if you are not using XP or you did not change the NtfsDisableLastAccessUpdate, I agree with you and your article 😉
Thanks
Just to be clear, even if you have last accessed times enabled (on XP or any other Windows OS) the accessed time is not updated at the time of deletion. None of the MAC times stored in the MFT for a file or folder are updated at the time of deletion. Deletion being the rendering of the content of the file to unallocated space.
If the file is deleted, the timestamp is not changed. However, if the folder is deleted, MFT Record Update Time of the parent folder may be changed depending on the configuration of the child item.
See blow,
http://forensic-proof.com/archives/6463
Completely agree. This, however, is indirect evidence as the parent folder could also have been changed due to other activity. So, while helpful, it is not the first thing I would check when looking at potential deletion times.
EnCase “Entry Modified” is the “metadata changed” field of the $MFT.
In what circumstance you will have the file’s “File Created” timestamp is -LATER- than the “Entry Modified”, even when the “Is Deleted” is showing -YES-. I can’t quiet explain that, a file is marked as deleted from the $MFT, the but file’s creation timestamp is -LATER- than the metadata changed field.