一、什么是MFT

MFT，全称Master File Table，即主文件表，它是NTFS文件系统的核心。它是包含了NTFS卷中所有文件信息的数据库，在$MFT 中每个文件（包括MFT本身）至少有一个MFT，记录着该文件的各种信息。这些信息被称为属性。

NTFS使用MFT条目定义它们对应的文件，有关文件的所有信息，比如大小、时间、权限等都存在MFT条目中，或者由MFT条目描述存储在MFT外部的空间中。

MFT由一个个MFT项（也称为文件记录(File Record)）组成，每个MFT项占用1024字节的空间。这个概念相当于Linux中的inode，File Record在$MFT文件中物理上是连续的，且从0开始编号，每个MFT项的前部几十个字节有着固定的头结构，用来描述本MFT项的相关信息。后面的字节存放着“属性”。(-via 百度百科)

二、MFT与数据恢复

在正常情况下，MTF条目会随着文件添加到NTFS卷中而增加，因此MFT的大小也会增加，当文件从NTFS卷中删除时，其MFT条目会被标记为free（空闲），以准备被重复使用，此条目会继续存在，直到它被新文件覆盖。但MFT所占空间大小不会因为删除文件而缩小。

例子：假如现在有100个MFT条目和一个文件X，现在删除文件X并立即创建500个以上文件，那么文件X的MFT条目将会被覆盖。虽然文件的内容可能存在与硬盘上，但包含名称、元数据等的MFT条目将被覆盖。

例子2：现在MFT有10000个条目，删除1000个文件和立即添加2个新文件。此时，可以恢复998个条目。不过文件的数据是否可以恢复得看它们是否已被覆盖。

这种文件数据和MFT条目分开的方式，会导致在删除操作后存在以下几种可能性：

1、文件被删除，但MFT条目和文件数据是100%可恢复的，则删除的文件可以100%被恢复。

2、文件被删除，MFT条目可恢复，但部分文件数据被覆盖，则该文件部分可被恢复。

3、文件被删除，MFT条目可恢复，但是文件数据被100%覆盖，则该文件不可恢复，但该文件相关属性信息（名称、日期、大小等信息）可被恢复。

4、文件被删除，MFT条目和文件数据100%可恢复，但文件已100%丢失，这种情况下。取证调查可以揭示该文件的大量信息，但不是通过MFT，而是使用其他证物。

5、文件被删除且MFT100%被覆盖，但文件数据未100%被覆盖。剩余的文件可以从磁盘上未分配的空间恢复。但雕刻数据的结果取决于碎片、可恢复数据的数量（可能是100%）和文件的性质。

当然，MFT被覆盖时，存在非100%被覆盖的情况，这种情况被称为MFT文件松弛，标准上来说，MFT条目被分配1024字节的固定空间。如果MFT条目小于1024字节。比如1000字节，则剩下为额外松弛空间。比如一个只有200字节长的密码文件，其文件数据也会被放置在MFT内，这种文件数据称为常驻数据。而文件名称、日期等元数据只占用大约500字节左右，如果删除了文件并在其位置创建了新的MFT条目，且不包括常驻数据。这意味着即使这个文件被删除，如果仔细检查也能恢复。

三、$MFT文件在取证中的应用

题目来源：Cynet应急响应挑战赛

题目描述：GOT公司的CTO在自己的笔记本上发现了可疑的活动。他说桌面上某些文件突然被移动了位置，而且其他文件似乎还在不合逻辑的日期被修改。他希望我们找出桌面上文件异常的相关证据。通过 一些技术检查，我们发现他是对的。桌面文件有明显的异常痕迹。请根据提供的$MFT文件找到与文件更改/修改相关的异常痕迹。

提示：1、找出受攻击者影响的文件名称及其原始创建时间。2、该文件位于桌面上。3、时间格式：DD-MM-YYYY HH:MM:SS ，文件名格式：filename.ext（ext是文件扩展名）

下载题目提供的文件

用Winhex打开可以查看其组成结构

我们可以通过$MFT解析软件把MFT条目导出来

Mft2Csvhttps://github.com/jschicht/Mft2Csv

下载打开软件，选择$MFT文件，然后导出到csv文件

导出的条目会以csv文件的形式存放在软件目录下

打开导出的csv文件，就可以看到文件的名称，日期，权限等各种信息

我们找到桌面上的相关文件

通过筛选，我们把要找的文件锁定在19个相关文件内容中

通过观察比较，发现其中一个文件时间有异常

0x0567DC00|GOOD|OK||88567|13|1|86832|1|Mod-File.txt|:\Users\DFIR\Desktop\Mod-File.txt|FILE|ALLOCATED|1|archive|archive|DOS+WIN32|0|2019-01-01 01:01:01.0000000|2019-01-01 01:01:01.0000000|2020-01-19 12:19:30.3933817|2019-01-01 01:01:01.0000000|0|2020-01-19 11:51:19.3290999|2020-01-19 11:51:25.8535572|2020-01-19 11:51:25.8539659|2020-01-19 11:51:25.8520885|1|0|0|0|20993824|||1|0||00||146907926|352|1024|0|0|0x0006|||||0|0|0|0|1368|0||||||||||||{817E2E08-3A9F-11EA-9223-000C2909356D}|NOT PRESENT|NOT PRESENT|NOT PRESENT|||||||||||||||||||||||||||||||||||||||1|0|1|1|0|0|0|1|0|0|0|0|0|0|0|0

上述项目对应的含义如下：

RecordOffset|Signature|IntegrityCheck|Style|HEADER_MFTREcordNumber|HEADER_SequenceNo|Header_HardLinkCount|FN_ParentReferenceNo|FN_ParentSequenceNo|FN_FileName|FilePath|HEADER_Flags|RecordActive|FileSizeBytes|SI_FilePermission|FN_Flags|FN_NameType|ADS|SI_CTime|SI_ATime|SI_MTime|SI_RTime|MSecTest|FN_CTime|FN_ATime|FN_MTime|FN_RTime|CTimeTest|FN_AllocSize|FN_RealSize|FN_EaSize|SI_USN|DATA_Name|DATA_Flags|DATA_LengthOfAttribute|DATA_IndexedFlag|DATA_VCNs|DATA_NonResidentFlag|DATA_CompressionUnitSize|HEADER_LSN|HEADER_RecordRealSize|HEADER_RecordAllocSize|HEADER_BaseRecord|HEADER_BaseRecSeqNo|HEADER_NextAttribID|DATA_AllocatedSize|DATA_RealSize|DATA_InitializedStreamSize|SI_HEADER_Flags|SI_MaxVersions|SI_VersionNumber|SI_ClassID|SI_OwnerID|SI_SecurityID|SI_Quota|FN_CTime_2|FN_ATime_2|FN_MTime_2|FN_RTime_2|FN_AllocSize_2|FN_RealSize_2|FN_EaSize_2|FN_Flags_2|FN_NameLength_2|FN_NameType_2|FN_FileName_2|GUID_ObjectID|GUID_BirthVolumeID|GUID_BirthObjectID|GUID_DomainID|VOLUME_NAME_NAME|VOL_INFO_NTFS_VERSION|VOL_INFO_FLAGS|FN_CTime_3|FN_ATime_3|FN_MTime_3|FN_RTime_3|FN_AllocSize_3|FN_RealSize_3|FN_EaSize_3|FN_Flags_3|FN_NameLength_3|FN_NameType_3|FN_FileName_3|DATA_Name_2|DATA_NonResidentFlag_2|DATA_Flags_2|DATA_LengthOfAttribute_2|DATA_IndexedFlag_2|DATA_StartVCN_2|DATA_LastVCN_2|DATA_VCNs_2|DATA_CompressionUnitSize_2|DATA_AllocatedSize_2|DATA_RealSize_2|DATA_InitializedStreamSize_2|DATA_Name_3|DATA_NonResidentFlag_3|DATA_Flags_3|DATA_LengthOfAttribute_3|DATA_IndexedFlag_3|DATA_StartVCN_3|DATA_LastVCN_3|DATA_VCNs_3|DATA_CompressionUnitSize_3|DATA_AllocatedSize_3|DATA_RealSize_3|DATA_InitializedStreamSize_3|STANDARD_INFORMATION_ON|ATTRIBUTE_LIST_ON|FILE_NAME_ON|OBJECT_ID_ON|SECURITY_DESCRIPTOR_ON|VOLUME_NAME_ON|VOLUME_INFORMATION_ON|DATA_ON|INDEX_ROOT_ON|INDEX_ALLOCATION_ON|BITMAP_ON|REPARSE_POINT_ON|EA_INFORMATION_ON|EA_ON|PROPERTY_SET_ON|LOGGED_UTILITY_STREAM_ON

在其文件日期修改日期和访问日期上都很不正常，都是2019-01-01 01:01:01.0000000，通过比较FN Info Creation date(FN_CTime)和Std Info Creation date(SI_CTime)发现两种时间不一致。(注：FN (FILE_NAME) ，SI (STANDARD_INFORMATION) )；而$FN只能由内核级进程修改，攻击者想修改非常困难。

至此我们找出了被修改的文件是Mod-File.txt，文件的原始创建时间是19-01-2020 11:51:19

四、总结

攻击者利用的是Timestomp技术。Timestomp 是一种修改文件时间戳（修改，访问，创建和更改时间）的技术，通常用于模拟同一文件夹中的文件。该技术可以用在攻击者修改或创建的文件上，使得它们在取证调查人员或文件分析工具面前更加隐蔽。Timestomp 可以与文件名伪装（Masquerading）结合使用来隐藏恶意软件和工具。（
https://attack.mitre.org/techniques/T1070/006/）

本文涉及相关实验：Linux系统取证
https://www.hetianlab.com/expc.do?ec=
ECID9d6c0ca797abec2016100813263000001&pk_campaign=toutiao-wemedia（本实验主要介绍 Linux 环境下的磁盘取证和内存取证工具的使用包括 Ftkimage、xmount、Volatility等。）