Using MFT anomalies to spot suspicious files in forensic analysis

A typical NTFS filesystem contains hundreds of thousands of files.

Each file has its own $MFT entry, and all $MFT entries are given a sequential address starting from zero, zero being the $MFT entry itself.

Each MFT entry is addressed using an 6 byte number, additionally the preceding 2 bytes contains the MFT Sequence number, these two numbers combined are called the file reference number.

For example, if we take the entire 8 bytes of a File Reference Number(6 bytes for the MFT Number + 2 bytes for the sequence number) 0x060000000100 in little endian, we would need to split the 2 values as follows:

MFT Record number = [0x060000000000]
Sequence Number= [0100]

After converting from little endian we can determine that this refers to the MFT record number 6 and has a sequence number of 1.

The sequence number incremented each time an MFT File is reallocated, as NTFS attempts to reuse existing MFT records above creating new ones, it is possible for a file to be deleted and its MFT File to be reused for a new file.

If this happens, its sequence number would be incremented from 1 (Assuming the original file was the first to occupy that MFT) to 2.

Because of the way operating systems are installed, it’s normal to see files under entire directory structures written to disk with largely sequential MFT Record Number values.

As file systems are used over the years and new patches are applied causing files to be backed up and replaced, and because MFT entries are recycled fairly quickly, the ordering of these files by MFT Record Number values can break down.

However, usually this ordering remains sufficiently intact on many systems, even after years of use, that it can be used to spot files of interest.

For example, in a directory listing from a Windows NTFS partition’s %SystemRoot%\System32 directory sorted by date, the MFT Record Number values are largely sequential and, with some exceptions, tend to align with the file creation times.

In this image, extracted from a SANS Forensic poster, both creation date and MFT record number are out of place, and identify a possible malicious activity.

Probably the best tool to analyse those anomalies is analyzeMFT, written and developed by David Kovar:

[email protected]:~$ --help
Usage: [options]

  -h, --help            show this help message and exit
  -v, --version         report version and exit
  -f FILE, --file=FILE  read MFT from FILE
  -o FILE, --output=FILE
                        write results to FILE
  -a, --anomaly         turn on anomaly detection
  -e, --excel           print date/time in Excel friendly format
  -b FILE, --bodyfile=FILE
                        write MAC information to bodyfile
  --bodystd             Use STD_INFO timestamps for body file rather than FN
  --bodyfull            Use full path name + filename rather than just
  -c FILE, --csvtimefile=FILE
                        write CSV format timeline file
  -l, --localtz         report times using local timezone
  -d, --debug           turn on debugging output
  -s, --saveinmemory    Save a copy of the decoded MFT in memory. Do not use
                        for very large MFTs
  -p, --progress        Show systematic progress reports.
  -w, --windows-path    File paths should use the windows path separator
                        instead of linux

The installation is pretty simple, using PIP:

pip install analyzeMFT

Or directly cloning the repository:

git clone
cd analyzeMFT
python install

References and further readings


This site uses Akismet to reduce spam. Learn how your comment data is processed.