Active file and del...
 
Notifications
Clear all

Active file and deleted file with identical timestamps  

  RSS
MartyBoy
(@martyboy)
New Member

Hi All

I have a puzzling forensic case where image files with identical filenames have identical timestamps (Modified, Accessed Created) where one copy of the file was recovered with Metacarving from the identical file location (folder).

How can this be?

Even if the file was copied in the same folder location and one copy deleted I would expect some shift in the Timestamps and the copied file would normally have a sequential bracketed extension to the main filename.

This goes to court in three days so I would greatly appreciate some speedy input to allow me to supply an explanation to the court.

Thanks in supplication oops

P.S. The operating system is Windows Vista.

Quote
Posted : 01/08/2014 9:37 am
Passmark
(@passmark)
Active Member

At the risk of seeming daft. What is Metacarving? I know "meta" and I know "carving". But Metacarving? Surely this is a made up term.

If you are doing a normal file carve, via signature matching, then you won't get any valid dates, nor even a file name for that matter.
If you are recovering a file via deleted records in the MFT, then you will get a name and some dates, but I wouldn't describe this as a 'carve'.

Are you sure whatever tool you are using isn't just presenting active files along with the deleted files. So while you think you are looking at deleted files, you are in fact looking at all files (active and deleted).

ReplyQuote
Posted : 01/08/2014 9:51 am
MartyBoy
(@martyboy)
New Member

Hi Passmark

The term Metacarve is a Forensic Toolkit term for deleted records extracted from the Master File Table. A relevant case file extract suitably masked is shown below.

Case110110_1.1.E01/Partition 2/HP [NTFS]/[MetaCarve]/7744/folder name/folder name/filename

Sorry for the confusion, but my question still stands.

Thanks for your rapid response to my query.

ReplyQuote
Posted : 01/08/2014 10:49 am
mscotgrove
(@mscotgrove)
Senior Member

Have a look at both MFT entries. The date is actually stored several times. There may be a difference in a non displayed date field.

Also this way, you can double check the actual dates being reported.

Is the second MFT a valid MFT or just a duplicate that has been picked up.

Are the files stored in the same location, or a different physical location.

ReplyQuote
Posted : 01/08/2014 3:11 pm
athulin
(@athulin)
Community Legend

Even if the file was copied in the same folder location and one copy deleted I would expect some shift in the Timestamps and the copied file would normally have a sequential bracketed extension to the main filename.

That is assuming the 'basic' file operations. But why must it be a basic file operation?

A user (or a program) can prevent NTFS from modifying any of the (documented) timestamps of a file he/it operates on. And the same user/program can both read and set those timestamps. There's nothing technical impossible involved – it's not even technically challenging to do so.

Why do you only mention three timestamps (Modified, Accessed Created)? NTFS has four timestamps, and normal forensic tools will provide those. Could the fourth timestamp be different?

More interesting would be if the non-documented timestamp related to the filename attribute were exactly the same. You need special tools to extract those, unless you prefer to the job by hand. If they are different, you can at least order the two entries by time. AnalyzeMFT is one such tool – there are several other.

So … what programs on this particular computer are known to leave timestamps alone when they operate? Or set timestamps to predictable values? Backup/restore software? Antivirus? Archive programs? And what scenarions involving those programs could explain the results you see?

You only mention identical timestamps … but you don't say that anthing else (except filename) is identical. Is size identical? Other attributes such as sequence number.

Do you have the USNJournal? Does it contain anything relevant?

Simplest scenario is user extracted file X using something like WinZip or 7-Zip, which sets timestamps. (PKZIp does something similar – it can records and set each of the four standard NTFS timestamps.) Then, he deletes the file. And then repeats the extraction. That may cause the situation you're seeing.

Another possibility might be that the oldest of the two files was found to contain some malware, and the newest of them is the file with removed malware. There would be lots of other changes, as well as logs, indicating such activities, though. Have you found this particular file name logged anywhere?

And how about a file that was deleted by mistake, but restore by any of the possible backup solutions present in Vista?

(Added Are the timestamps identical to the last bit, or only identical in the textual version that your tools show you – i.e. within whatever rounding/truncation is taking place?)

ReplyQuote
Posted : 01/08/2014 6:20 pm
jaclaz
(@jaclaz)
Community Legend

At the risk of seeming daft. What is Metacarving? I know "meta" and I know "carving". But Metacarving? Surely this is a made up term.

JFYI wink
http//www.marriedtothesea.com/030807/dictionary.gif

D

jaclaz

ReplyQuote
Posted : 01/08/2014 7:28 pm
MartyBoy
(@martyboy)
New Member

Thanks for your responses, and I appreciate your willingness to assist me on this.

Here are a few items of new information based on what has been written in the responses.

Most of the issues raised in the responses have been assessed and discounted already because of facts surrounding the computer forensic case, such as opportunity, expertise and motivation. There was no A/Virus software installed, nor any other automated system management applications.

The number of files involved in this issue is substantial but the identical timestamp replication is only between the active file record (which comes from the MFT) and the deleted file record, which is also extracted from the MFT.

The timestamps are identical to one second, according to the forensic case file. I have no reason to distrust the software, although I haven't tried comparing UTC timecode records. I can't recall if there are any UTC timecodes in the MFT (more homework)

The compressed folder range of possible scenarios may fit the known facts, but I am still testing timestamp behavior with different archiving programs and formats over the weekend.

Because the time gaps between the timestamps of each different file name is differing by only a few seconds over the entire range of files which are (and were) all in the same folder, I am sure some type of automated process has been involved.

My guess at this stage is a compressed folder was downloaded and the files extracted to their single repository folder, the individual files were then deleted, and the files then extracted a second time and left in the same repository,

However I would have thought this would have changed one of the 3 MAC timestamps for the deleted version of each file. My expeerience is that the Last Accessed Date is usually changed to the timestamp when the deletion occurred, but I am aware that different versions of MS Windows treat the Last Accessed Date differently.

Anyway any other thoughts/ideas or explanations most welcome.

ReplyQuote
Posted : 01/08/2014 8:09 pm
PaulSanderson
(@paulsanderson)
Senior Member

I think I would want to know exactly what metacarving does - i.e. what the published description of the process is?

Try using a different tool to carve the data and see what it comes up with.

Have you also looked at the allocation for the two files? if it is the same then you are probably just looking at duplicated MFT entries. In this case it may be that one of the entries is in a shadowed MFT.

Try looking at the shadow files using Reconnoitre (http//sandersonforensics.com/forum/content.php?113-Software&tabid=38) and see if your "metacarved" file is actually in a shadow file.

ReplyQuote
Posted : 01/08/2014 8:41 pm
paul206
(@paul206)
Member

This is straight from the FTK 5.4 manual dated June 2, 2014 from the Evidence Processing Options section.

Data Carve carves data immediately after pre-processing. Click Carving Options, then select the file types to carve. Uses file signatures to identify deleted files contained in the evidence. All available file types are selected by default.

Meta Carve carves deleted directory entries and other metadata. The deleted directory entries often lead to data and file fragments that can prove useful to the case, that could not be found otherwise.

Data Carving can be customized and this is from that section

Data Carving is the process of looking for data on media that was deleted or lost from the file system. Often this is done by identifying file headers and/or footers, and then “carving out” the blocks between these two boundaries.

AccessData provides several specific pre-defined carvers that you can select when adding evidence to a case. In addition, Custom Carvers allow you to create specific carvers to meet your exact needs.

ReplyQuote
Posted : 28/08/2014 8:46 pm
PaulSanderson
(@paulsanderson)
Senior Member

Meta Carve Carves deleted directory entries and other metadata. The deleted directory entries often lead to data and file fragments that can prove useful to the case, that could not be found otherwise.

Sounds like this ties in with what I said above.

ReplyQuote
Posted : 28/08/2014 8:58 pm
pbobby
(@pbobby)
Active Member

It sounds to me like there are multiple artifacts all pointing to the same data. Say, an MFT record from the $MFT and an MFT record from the $Logfile. There aren't two separate files - it could simply be a display issue in FTK implying more than one file.

Per the FTK user manual quote above, it found a file that contained folder information, an $INDX structure, and parsed it for you.

ReplyQuote
Posted : 28/08/2014 11:31 pm
keydet89
(@keydet89)
Community Legend

I have a puzzling forensic case where image files with identical filenames have identical timestamps (Modified, Accessed Created) where one copy of the file was recovered with Metacarving from the identical file location (folder).

Let's see…NTFS on Vista.

So…the timestamps in which attributes are identical? $STANDARD_INFORMATION? $FILE_NAME? Both?

How about the record numbers? Are they also identical?

How can this be?

Did you create a timeline of system activity, using data sources such as file system metadata, Windows Event Logs, Registry metadata, Prefetch file metadata, etc? This might provide you with some context.

Even if the file was copied in the same folder location and one copy deleted I would expect some shift in the Timestamps…

Okay, but *which* time stamps? An MFT record with a $STANDARD_INFORMATION attribute and one $FILE_NAME attribute has 8 time stamps. Each additional $FILE_NAME attribute is another 4 time stamps.

The timestamps are identical to one second, according to the forensic case file. I have no reason to distrust the software…

Yeah, you do…depending upon which software it is.

You can always retrieve the records from the MFT itself and parse them by hand.

…although I haven't tried comparing UTC timecode records. I can't recall if there are any UTC timecodes in the MFT (more homework)

Can you elaborate on that last sentence a bit?

ReplyQuote
Posted : 28/08/2014 11:56 pm
UnallocatedClusters
(@unallocatedclusters)
Senior Member

I concur with keydet89 "Did you create a timeline of system activity, using data sources such as file system metadata, Windows Event Logs, Registry metadata, Prefetch file metadata, etc? This might provide you with some context."

Perhaps look at using FSPro Labs' Event Log Explorer (http//www.eventlogxp.com/) to analyze the event log files. You should find the event logs in C\Windows\System32\config or C\Windows\System32\winevt\Logs (not sure which for Vista). The event log files extensions are *.evt or *.evtx. Find and export the event log files from FTK and then import them into Event Log Explorer.

Within Event Log Explorer, one can filter the various event logs by "User" or SID to attribute activity to the correct Windows user account.

You should be able to find a record of Winzip being installed and then being run (executed) chronologically prior to the image files' metadata for example if you suspect that the image files were extracted from an archive file.

Basically, some other program and related user activity caused the image files to exist where you found them, so the event logs might give you this visibility.

ReplyQuote
Posted : 29/08/2014 7:01 am
Share: