MFT forensics for alternate data streams and deleted files is still a challenging task for forensic investigators owing to little info available on practically using the tools to investigate the MFT records.
MFT is the master file table in NTFS disks which stores all metadata about the disks, files and even folders. So, for forensically investigating a file or folder, MFT can provide very useful information.
In this article, we are going to practically see how we can analyze MFT records, especially for the deleted files and the alternate data streams with winhex tool.
Table of Contents
MFT Forensics
MFT or Master file table keeps a record of all information about a disk, file or directory including the system files the OS uses. In the case of NTFS partitions, everything written to disk is considered as a file including a directory and each has its meta data stored in a separate MFT. In NTFS soon after the boot record MBR, we have the drive MFT with 15 records.
We can see that the first record is the $mft which is the disk MFT. There is another important record $bitmap which keeps track of all used and unused clusters on the disk. All files, folders and disks have the same size 1024 bytes MFT which can be extended if needed. There are different attributes in each MFT which store different meta data about the file. A file or folder information is stored in two ways in MFT.
1. Resident MFT
The data of a file less than 512 bytes is stored within MFT which is called a resident MFT.
2. Non-Resident MFT
Files larger than 512 bytes are stored outside the MFT. MFT record provides cluster addresses where the file is stored on the drive’s partition which are called data runs. Each MFT contains a flag identifying it as a resident or nonresident file.
MFT Attributes
The MFT attributes are further explained below:-
MFT Header Fields
–Offset 0x00—The MFT record identifier FILE is at offset 0.
–Offset 0x1C to 0x1F—Size of the MFT record; the default is 0x400 (1024) bytes, or two sectors.
–Offset 0x14—The length of the header indicates where the next attribute starts; typically 0x38 bytes.
–Offset 0x32 and 0x33—The update sequence array, stores two bytes of the first sector of the MFT record. It’s used only when MFT data exceeds 512 bytes. The update sequence array is used as a checksum for record integrity validation.
Attribute 0x10: Standard Information
•Offset 0x38 from the beginning of MFT record—the start of attribute 0x10.
•Offset 0x04 and 0x05 from beginning of attribute 0x10—Size of 0x10 attribute.
•Offset 0x18 to 0x1F—File’s create date and time; all dates and times are stored in Win32 File time format.
•Offset 0x20 to 0x27—Last modified date and time for the file.
•Offset 0x28 to 0x2F—Last access date and time.
•Offset 0x30 to 0x37—Record update date and time.
Attribute 0x30: File_Name
•Offset 0x04 and 0x05 from beginning of attribute 0x30—Size of attribute 0x30.
•Offset 0x5A from 0x30 attribute’s starting position—Short filename; in Unicode.
•Offset 0x20 to 0x27— File’s create date and time; in Win32 Filetime format.
•Offset 0x28 to 0x2F— Last modified date and time for file.
•Offset 0x30 to 0x37— Last access date and time.
•Offset 0x38 to 0x3F— Record update date and time.
Attribute 0x40: Object_ID
•Offset 0x04 and 0x05 from beginning of attribute 0x40—The size of attribute 0x40.
•Offset 0x14—Starting offset position for GUID data.
•Offset 0x18 to 0x27—Starting position for GUID Object_ID data.
Attribute 0x80: Data for a Resident File
•Offset 0x04 and 0x05 from the beginning of attribute 0x80—Size of the attribute.
•Offset 0x08—Resident/nonresident flag; for resident data, it’s set to 0x00
•Offset 0x40—Number of bytes in the data run.
•Offset 0x18—Start of the resident data run.
•Offset 0x1FE and 0x1FF from the beginning of MFT header— Sector checksum value, used to validate first 512 bytes of MFT record. The break between the first and second sectors is referred to as sector boundary. The 2 bytes at positions 0x32 and 0x33 of the MFT header in the update sequence array field are where the actual values for these bytes are stored.
•End of the MFT record is indicated by the hexadecimal values FF FF FF FF at the end of the record.
Attribute 0x80: Data for Nonresident File
•Offset 0x04 and 0x05 from the beginning of attribute 0x80—Size of the attribute.
•Offset 0x08—Resident/nonresident flag; for nonresident data, it’s set to 0x01.
•Offset 0x40—The start of the data run. The first run is the LCN; if the file is fragmented, additional data runs follow
•Following the last data run, the value 0x00 indicates the end of the Data attribute
Alternate Data Streams NTFS
The alternate data stream is a mechanism to attach a file to another file in the windows NTFS system. The alternate data stream can obscure valuable evidentiary data, intentionally or by coincidence. Such data streams are difficult to detect and can be only analysed through MFT.
Analyzing resident alternate data stream
Creating a resident alternate data stream file
The alternate data stream file can be easily created in the command prompt with the following commands.
D:\>echo This is just a normal file>ADS_ammar_asif_mainfile.txt (This will create sample.txt file in D)
D:\ > more< ADS_ammar_asif_mainfile.txt (This will display the contents of sample.txt)
This is just a normal file
D:\> echo ammar and asif >ADS_ammar_asif_mainfile.txt:hidden01.txt (creating an alternate data stream)
D:\> more< ADS_ammar_asif_mainfile.txt:hidden01.txt (This will display the contents of hidden file)
ammar and asif
MFT for resident alternate data stream file
The MFT for the resident alternate data stream file was opened with winhex tool which showed the following information.
File Create Date can be seen in the data interpreter. Similarly, other dates can be verified and checked.
The data “Ammar and Asif” which was appended in the alternate stream is clearly visible in the MFT Record. The alternate data stream has been clearly marked in the picture above within an enclosed box.
- There are two 0x80 attributes in the MFT
- The Filename of the alternate Data stream is starting at 0x18
- After the file name ended, the actual data is available at the next octet.
Analyzing non-resident alternate data stream
Similarly, a greater amount of text was appended to the same file to make it a non-resident alternate data stream.
MFT for non-resident alternate data stream file
Similarly, the MFT forensics was carried out for non-resident data stream which resulted in the following observations:-
- There are two 0x80 attributes in the MFT
- The Filename of the alternate Data stream is starting at 0x40
- After the file name ended, the cluster numbers are given in the next octet.
The starting cluster has been calculated to be 2004. The first digit “2” represents 2 bytes being used to give the cluster number and the second digit “1” tells that number of clusters is given in 1 byte.
We can also see the required data by opening cluster no 2004.
Analyzing $bitmap of NTFS Disk
Now we can see the Bitmap file to see that the required cluster is occupied. In the bitmap file, each cluster is represented by a single bit. Starting from the first bit. So, we need to check the 2004th bit. This means the 2004/8= 250th byte. Left-click in the Offset column to change the numbering to decimal and go to byte no 250. Location 1 in 1F is our required cluster which is turned as 1. We can see the value of 1F which is to be read from the least significant side to reach 2004 number cluster 0001 1111 to be read as 1111 1000 from which means the cluster number from 2000 to 2003(F) and 2004(1) are on.
MFT Forensics for Deleted files
There are two scenarios for forensics of deleted files.1st if the file was deleted to recycle bin and 2nd if it is permanently deleted through command prompt or shift+delete.
MFT analysis for deleted files (Recycle bin)
The same file was deleted to the recycle bin and its MFT was analysed. The following results were obtained.
- The Data Remains available for both the original and alternate stream attached file.
- The file name changes with $R and a random name.
- Following dates data about the file changes.
- 0x28-0x2F Last Access Date
- 0x30-0x37 Record Update time
- Following Dates Data for File Name changes
- 0x28-0x2F Last modified date
- 0x30-0x37 Last Access Date
- 0x38-0x3F Record Update time
Similarly, there is no change in $Bitmap file records.
MFT analysis for permanently deleted files (shift+del/cmd)
After deletion, there are a few changes to the MFT. MFT remains the same with an exception of the following:-
- 0x08 – the logfile sequence number has changed
- 0x10 – the record usage count increases by one
- 0x16 – the flags field changes to 00 from 01
The Flag 016 changes to 00 which indicates the file has been deleted
The name of the file does not change which was the case if file was deleted to recycle bin. The MFT record remains intact.
Data also remain available at the same location
However, in the $Bitmap file, the cluster number is freed and the flag is shifted to zero to indicate the operating system that any new data can be written at the cluster. The cluster no 2004 has been freed in bitmap bit no 2004, the 250th byte. This means new data can be stored at the location by OS.
FAQ
Why a file can be recovered even when it is permanently deleted?
Once a file is deleted, the operating system only changes the flags that disk space is empty. Till the time the sector or cluster is overwritten by new data, the old data remains available.
What is $Bitmap system file?
$Bitmap file keeps a record for all logical clusters on a disk. All clusters currently occupied are marked with “1” whereas free clusters are marked as “0”.
What is an MFT record?
MFT or master file table is a unique file for each folder, file or drive that keeps a record of all meta data for that particular file or folder.