AboutDFIR.com – The Definitive Compendium Project
Digital Forensics & Incident Response

Table of Contents

How to Use MFTECmd – Command Line

To run MFTECmd, open a command prompt in the folder where MFTECmd.exe resides and type the following command:


It will then output the following:

Here is an illustration of what this looks like. Notice how my command prompt is set in the folder where my MFTECmd executable resides.

If we want to run MFTECmd against the $MFT in our Lone Wolf 2018 image, our command will look something like this:

MFTECmd.exe -f "M:\Forensics\Lone Wolf 2018\KAPE\tout\D\$MFT" --csv C:\Temp --csvf LoneWolfMFT.csv --debug --trace

This command points to the $MFT file that I extracted with KAPE. This will output a CSV that Timeline Explorer will ingest very nicely. Notice, I like to use the debug and trace switches because I like to see what’s going on while the tool is parsing. These switches are completely optional!

Examining MFTECmd Output (CSV)

CSV output is the preferred format to analyze in Timeline Explorer. Alternatively, you can use Excel if that’s more comfortable for you.

Understanding the Artifacts

As always, Tools & Artifacts – Windows is at your disposal for Windows-based artifacts, both system and third-party. The SANS Windows Forensic Analysis (FOR500) and Hunt Evil (FOR508) posters are great resources, as well.

Anti-Forensics Artifacts

MFTECmd combined with Timeline Explorer will provide some very useful pointers to potential anti-forensics artifacts such as timestomping. Zone Identifier artifacts are also made readily available in the MFTECmd output.

For instance, here’s an example from a MFT entry record of a file I changed the timestamp of on my personal machine using Change Timestamp, a GUI program that allows you to modify a file’s timestamps.

MFTECmd.exe -f "M:\Forensics\KAPETest\1252020\tout\C\$MFT" --de 723095

The output is as follows:

Entry-seq #: 0xB0897-0x2, Offset: 0x2C225C00, Flags: InUse, Log Sequence #: 0x146E19B7D7, Mft Record To Base Record: Entry/seq: 0x0-0x0
Reference Count: 0x2, Fixup Data: Expected: 3B-00 Fixup Actual: 00-00|00-00 (Fixup OK: True)

Type: StandardInformation, Attribute #: 0x0, Size: 0x60, Content size: 0x48, Name size: 0x0, Content offset: 0x18, Resident: True

Flags: Archive, Max Version: 0x0, Flags 2: None, Class Id: 0x0, Owner Id: 0x0, Security Id: 0xAFD, Quota Charged: 0x0
Update Sequence #: 0x3616E8000

Created On: 2018-12-03 05:00:00.0000000
Content Modified On: 2018-12-03 05:00:00.0000000
Record Modified On: 2020-12-03 14:15:21.2752325
Last Accessed On: 2020-12-03 14:24:16.8589849

**** FILE NAME ****
Type: FileName, Attribute #: 0x2, Size: 0x70, Content size: 0x58, Name size: 0x0, Content offset: 0x18, Resident: True

File name: Result.html (Length: 0xB)
Flags: Archive, Name Type: Windows, Reparse Value: 0x0, Physical Size: 0x0, Logical Size: 0x0
Parent Mft Record: Entry/seq: 0x7140C-0x11

Created On: 2020-11-07 12:39:07.7605723
Content Modified On: 2020-11-07 12:39:08.0635726
Record Modified On: 2020-11-07 12:39:08.0635726
Last Accessed On: 2020-11-07 12:39:08.0635726

**** FILE NAME ****
Type: FileName, Attribute #: 0x3, Size: 0x78, Content size: 0x5A, Name size: 0x0, Content offset: 0x18, Resident: True

File name: RESULT~1.HTM (Length: 0xC)
Flags: Archive, Name Type: Dos, Reparse Value: 0x0, Physical Size: 0x0, Logical Size: 0x0
Parent Mft Record: Entry/seq: 0x7140C-0x11

Created On: 2020-11-07 12:39:07.7605723
Content Modified On: 2020-11-07 12:39:08.0635726
Record Modified On: 2020-11-07 12:39:08.0635726
Last Accessed On: 2020-11-07 12:39:08.0635726

**** DATA ****
Type: Data, Attribute #: 0x4, Size: 0x48, Content size: 0x0, Name size: 0x0, Content offset: 0x0, Resident: False

Non Resident Data

Starting Virtual Cluster #: 0x0, Ending Virtual Cluster #: 0x1F, Allocated Size: 0x20000, Actual Size: 0x1F97E, Initialized Size: 0x1F97E

DataRuns Entries
Cluster offset: 0x8DA8D8, # clusters: 0x20

I’ve bolded some important parts of this output. The bolded and underlined timestamps in the Standard_Information (x10) attribute were modified by me with Change Timestamp. Notice that the File_Name (x30) attribute does not get modified. This is due to the fact that applications like Change Timestamp are not able to modify the File_Name (x30) timestamp. This is great for forensic examiners because it allows us to do a comparison to pick up on potential timestomping artifacts.

So what can MFTECmd do for us to help us spot timestomping easier? Glad you asked!

In Timeline Explorer when you have a MFTECmd_$MFT_Output.csv file opened, you can scroll to the far right columns and notice the following two columns. This screenshot displays the output for this particular Result.html file. The first column, “SI<FN”, points out the the File_Name (x30) attribute’s timestamp is greater than the Standard_Information (x10) attribute’s timestamp. Now, this doesn’t mean 100% of the time it will be timestomping, but it should be clue enough to make you want to look into it further. The reason for it not being 100% is you will likely see many false positives if you look at these columns when you run MFTECmd on your own system. At least, that was my experience.

Additionally, we see the second column, “u Sec Zeros”, which is pointing our attention to the fact that one of the timestamps has the subseconds zeroed out, or HH:MM:SS.0000000. This should be a telltale sign for time manipulation, however, it appears other artifacts I saw on my own system appeared to be artifacts from various file syncing services like Dropbox, Box, etc, that did not appear to record subseconds at all. This resulted in a lot of false positives on my output, but it doesn’t take very long to find the anomaly Result.html amongst the rest of this noise. As with everything in forensics, trust but verify!

Also, please note there is a second File_Name (x30) attribute due to the filename being longer than 8 characters. You can also see the file is non-resident, meaning it’s larger than what the 1024 byte entry can store. For the curious, this HTML file is the output of a 3-way folder compare with UltraCompare. Something like that will be non-resident 99.9% of the time given the inherent file size.

One last thing to consider is that not all timestomped files will have zeroed out subseconds. A timestomped file can its timestamps inherited from another file, so as long as that file isn’t doesn’t have zeroed out subseconds, then the timestomped file won’t either, naturally.

To tie all of this in together for a timestomped file with zeroed out subseconds, let’s watch a GIF of how this looks in Timeline Explorer with the $MFT CSV output of my own system loaded to find this Result.html file.

$J Parsing

The USN Journal provides the examiner with a play by play as to what happened on the NTFS volume in terms of file creation, file rename, file deletes, and much more.

One limitation with the $J is that you will not get the full path of the file, so you’ll have to correlate the Entry Number and Sequence Number to make sure they match up. That way, you’ll know you’re looking at the same number.

Let’s find the file called “The Cloudy Manifesto.docx” in the $J and tie in the records found in both the $MFT and $J.

We can see this is  a file named “The Cloudy Manifesto.docx” that resides in the user jcloudy’s Dropbox folder.

Now, notice there are many different files named “The Cloudy Manifesto.docx” but some of them have different entry numbers. Without looking at the $MFT and cross-referencing those Entry Numbers, we wouldn’t know what that means. As you can see, that file resides in multiple different locations, so it makes sense why each would have their own entry number. Let’s watch this in action below.

One thing to consider with the $J is that you may experience data rollover in that you aren’t able to find artifacts from a long time ago. That being said, I’ve also seen it where the $MFT output is 1/4th the size of the $J output. I am not aware of any documentation explaining these two examples that are on opposite sides of the spectrum from each other, but just something to be aware of.