Daily Blog #233: Sunday Funday 2/9/14 Winner Redux

Hello Reader,
           You might have guessed this but most Sunday Funday's are made after my favorite cases over the years. This weeks' challenge was different as it focused on a specific tool letting the tools author get involved as well While Willi wasn't eligible for a prize I did get his permission to share his answer so you can see what the author sees. So read on to see whats possible.

The Challenge:

You have an MFT extracted from a live system that you've taken back to your analysis system. You've used Willi Ballenthin's fuse-mft to mount the MFT and begin your inspection.Answer the following questions:

1. What functions do you expect to work against the fused mounted MFT.

2. What functions will not work against the fused mounted MFT.

3. What information, retrievable from the live system, is missing in this method that you could recover if you parsed the MFT with the rest of the image accessible.

Willi's Answer

1. What functions do you expect to work against the fused mounted MFT

File and directory structure. Standard information and filename information attribute metadata, which includes filenames, a bunch of timestamps, a glimpse at the file size, and some hints as to which file system driver modified the volume. Small file content may be available if they are resident in the MFT.

2. What functions will not work against the fused mounted MFT

Mainly, larger file content. Also, efficient access, as either the directory structure must be precomputed (what fuse-mft does), or the directly indices (usually non-resident) must be available. For huge files, there's some chance that very few attributes will be available, as most can be evicted. Finally, it can be difficult to reconstruct old activity, which is better illuminated by the NTFS UsnJrnl and LogFile.

3. What information, retrievable from the live system, is missing in this method that you could recover if you parsed the MFT with the rest of the image accessible

The biggest issue I've struggled with is ownership information. Its a surprisingly complex task to resolve the security IDs associated with a file, and requires the data attributes (specifically, indices) off the $SECURE file to make any headway. 

Then, you get to guess what the human-readable account name is (which I think is best done by inspecting the Registry. I'd love to hear about the most correct approach). Of course, everything in #2 becomes reasonable to implement.

Also Read: Daily Blog #232