Modifying timestamps of deleted files in the MFT

With a Hex based sector editor you can do anything.

The biggest skill is not to leave any signs behind. For instance (from memory) the date is stored in multiple records in the MFT block. All records should be updated. All time stamps at the end want to consistant. For instance, the creation time is normally the time the file was first copied to the hard drive, not the time the file was initially created.

Any logs may also need updating

Can you change file attributes in the MFT in order to update the timestamps of deleted items ?

Of course you can.

You can't change the timestanps you refer to by doing NTFS system calls. Once a file is deleted, NTFS has 'lost' it, and cannot retrieve it. That is, within the system that is NTFS, you cannot do it directly.

You can do it at a lower system levels, e.g. by opening the raw volume or the raw hard drive, locating the appropriate timestamp positions and modifying them. The easiest way to do it is probably to take the drive, connect it to a Unix system, and do the job there. Within Windows, it is probably possible to do it for other volumes than the system volume (at least on a quiescent system) – for the system volume, you probably need to do it as a task that is done on reboot, before the operating system has started.

Might even be possible to fire up a capable hex editor/sector editor and do it by hand.

I'm less into device drivers, but I suspect it is possible to do something clever in that area as well.

You could potentially do this using a hex editor on a bootable Linux distro.

If you were trying to do so on a live system, you have to remember that MFT records are re-used. You'd have to access the physical disk, locate the MFT, locate the record of interest, and change the time stamps (which attribute are you interested in, $STANDARD_INFORMATION? $FILE_NAME? Both?).

As Michael mentioned, doing this on a live system would leave indicators of the activity…attempting to remove those indicators would very likely also leave indicators.

I'd think, however, that if you're interested in misleading an investigator, there are much easier ways to go about it. In fact, you can find BlackHat presentations from 2005/2006 that discuss how to mislead an investigator trained to use a specific commercial tool.

Does anybody know of such a commercial tool ? Keep in mind that we are talking about deleted items, so indeed no longer 'visible' with the installed OS.
I'm asking this, because in the case we're investigating, the modification would have been performed on a large scale - a few hundred files. Can individual files be easily retraced within the MFT ? Are all the different inode's easily linked to each other ? And all timestamps would have to be adjusted….

Does anybody know of such a commercial tool ?

As you insist on commercial tool, how about WinHex? There are dozens of free tools, and anyone interested in doing these things would probably not have a problem creasting his own, or getting someone to do it for him.

However, you then add the problem of doing this over a few hundred files – which is an additional constraint. That would either require a scriptable disk editor, or a custom-programmed solution. But it doesn't seem to be a technically difficult matter, as long as you have the necessary system privileges.

I suspect you are still leaving important conditions and constraints out of your problem, though.

Can individual files be easily retraced within the MFT ?

Don''t understand. A file *is* an active MFT record. Once a file has been deleted, and the MFT record flagged as unused, it's not a file anymore. It's easy to look at each MFT record and decide if it is active or if it is 'free', and so probably contains remains of previously existing file attributes.

Are all the different inode's easily linked to each other ?

Again I don't understand – a given user-created MFT record (inode) is linked only to some other records, and then only through index entries in directories. Delete a file, and you delete the link. If traces of the links remain depends on the file system activity between the deletion and when the attempt to make the trace is being done. 'Easily' … according to whose perceptions?

Are you by any chance interested only in files that were located in a particular subset of directories? That may be trickier – perhaps needlessly so (see below).

And all timestamps would have to be adjusted….

Not all timestamps, only MFT time stamps. Right?

If I was interested in hiding file system activities during a specific time period, I would go over the MFT, collect all already existing time stamps of existing files outside that interval to get a source of legitimate time stamps, then go over the MFT again, and change *any* time stamp in a deleted MFT entry that was also within the specified period to one of the timestamps collected earlier, add a small random bias (at most +- 5 seconds or so) to avoid tell-tale duplicated time stamps, and I would take care to ensure that the time stamps were also consistent within the record (which is fairly easy, as they already have an assumed consistency that only needs to be replicated).

It would be discoverable, provided you have additional evidence about time stamps of files. Might even be provable, if those files are many enough and sufficiently unrelated.

Though I have probably forgotten something glaringly obvious …

Can you say which dates may have been changed. Is it the modify, create or access date?

Have the dates been made to look newer or older?

What is the pattern of files you think may have been changed - is it a single subdirectory/directory tree or files scattered all over the disk.

Some files, eg photos and certain documents have dates embedded in the file, so what type of file are you investigating?

Not a commercial tool, but "setmace" does write directly to physical disk and can modify timstamps inside $MFT. It does currently not support deleted files, but since the source is open, you could easily adapt it to support such. So it's not a particularly difficult task to do this. More sophisticated approaches on nt6.x would break into ring0 and execute code, and thereby circumvent the newer security measures. But it is ridiculously easy on nt5.x which is the case here…

Joakim,

I've looked at what's been written about setmace…how does the tool write directly to physical disk?

Thanks.

Joakim,

I've looked at what's been written about setmace…how does the tool write directly to physical disk?

Thanks.

A little $MFT parsing and some winapi like CreateFile, ReadFile and WriteFile (plus more of course). And then FSCTL_LOCK_VOLUME on nt6.x. You can have a look at the source; http//www.mediafire.com/?8iyy867qscfiugc (but many lines of code, likely way too much for the task)