当前位置: 首页 > 技术干货 > Windows 取证之$MFT

Windows 取证之$MFT

发表于:2021-06-18 17:25 作者: W汐 阅读数(135人)

一、什么是MFT

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

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

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

二、MFT与数据恢复

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

例子:假如现在有100个MFT条目和一个文件X,现在删除文件X并立即创建500个以上文件,那么文件XMFT条目将会被覆盖。虽然文件的内容可能存在与硬盘上,但包含名称、元数据等的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系统取证 (本实验主要介绍 Linux 环境下的磁盘取证和内存取证工具的使用包括 Ftkimage、xmount、Volatility等。)

大家都在学

Tomcat漏洞利用实践

XXE漏洞分析与实践

点对点非对称加密的消息发送系统-Bitmessage软件使用实验