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 百度百科)
在正常情况下,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、文件被删除且MFT
100%被覆盖,但文件数据未100%被覆盖。剩余的文件可以从磁盘上未分配的空间恢复。但雕刻数据的结果取决于碎片、可恢复数据的数量(可能是100%)和文件的性质。
当然,MFT
被覆盖时,存在非100%被覆盖的情况,这种情况被称为MFT
文件松弛,标准上来说,MFT
条目被分配1024字节的固定空间。如果MFT
条目小于1024字节。比如1000字节,则剩下为额外松弛空间。比如一个只有200字节长的密码文件,其文件数据也会被放置在MFT内,这种文件数据称为常驻数据。而文件名称、日期等元数据只占用大约500字节左右,如果删除了文件并在其位置创建了新的MFT条目,且不包括常驻数据。这意味着即使这个文件被删除,如果仔细检查也能恢复。
题目来源:Cynet应急响应挑战赛
题目描述:GOT公司的CTO在自己的笔记本上发现了可疑的活动。他说桌面上某些文件突然被移动了位置,而且其他文件似乎还在不合逻辑的日期被修改。他希望我们找出桌面上文件异常的相关证据。通过 一些技术检查,我们发现他是对的。桌面文件有明显的异常痕迹。请根据提供的$MFT
文件找到与文件更改/修改相关的异常痕迹。
提示:1、找出受攻击者影响的文件名称及其原始创建时间。2、该文件位于桌面上。3、时间格式:DD-MM-YYYY HH:MM:SS ,文件名格式:filename.ext(ext是文件扩展名)
下载题目提供的文件
用Winhex
打开可以查看其组成结构
我们可以通过$MFT
解析软件把MFT
条目导出来
Mft2Csv
https://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等。)