欢迎来到2023！

去年我在这里发布的文章不够多。今天早上登录时发现只发布了两篇，哎呀。让我们通过一些关于INDX记录的验证研究来改变这种情况，特别是与INDX条目中存储的时间戳相关的内容。

我一直在为即将到来的Magnet Virtual Summit准备演讲，内容是关于从去年一起勒索软件调查中获得的加密VHDX文件中提取取证证据。在调查过程中，我不得不使用各种工具从部分加密的数据块中重建活动时间线，这是一个有趣的过程。

我使用的其中一个证据就是INDX记录，这让我尝试了许多不同的工具和处理方法。本文的重点与解析$I30条目时发现的时间戳有关。

由于Willi（幻灯片）和Brian已经做了更好的解释，我就不深入细节了；INDX记录存储在（或引用自）目录的MFT条目中，结合了INDX_Root和INDX_Allocation属性以及$Bitmap NTFS文件。像FTK Imager这样的工具会将此数据暴露为$I30文件，或显示$I30中存在但MFT中不存在的条目。在FTK Imager中选择一个项目甚至会显示该项目的INDX条目中记录的数据！

很酷的是，这些项目包含已知结构，因此我们可以使用Joachim Schicht的IndxCarver等工具检查加密卷，并在未分配空间中查找条目。需要注意的是，对于我的卷，这些不一定是未分配的条目——因为加密影响了VHDX文件的开头，磁盘头已经丢失，我认为没有简单的方法可以将其重新组合。相反，我依靠提取我知道可以提取的内容并重新组合！

以下是可用于提取和/或解析$I30条目的工具列表：

• MFTECMD
• Bulk_Extractor和Bulk_Extractor-rec
• INDXRipper
• INDXParse（版本1和2）
• dfir_ntfs
• IndxCarver和Indx2Csv

它们各有优缺点，操作方式略有不同。我尚未对它们的性能进行比较，但在勒索软件调查中或从未分配空间提取数据时，我会想使用IndxCarver或Bulk Extractor。据我所知，其他工具不会在那里搜索。INDXRipper是次佳选择，它可以在整个挂载点或映像上运行。我尚未测试DFIR NTFS，但Maxim是文件系统方面的知识宝库，我期待好的结果。

现在，进入本文的重点！

在阅读有关这些结构的资料以更好地理解时，我观察到人们经常写道INDX条目包含FILE_NAME记录。MFT条目中的FILE_NAME记录包含一系列时间戳，这些时间戳的更新方式与STANDARD_INFORMATION（0x10）属性略有不同。在复习SANS的FOR508高级事件响应、威胁狩猎和数字取证课程材料时，有一个注释说明，即使条目表明它应包含FILE_NAME（0x30）属性中的时间戳，它实际上包含的是STANDARD_INFORMATION属性中的时间戳。这很有趣——值得测试！

那么我如何测试： 我能想到的最简单的方法是获取一个测试映像并比较时间戳；为此我选择了Andrew Rathbun的Anti-Forensics VHDX和FTK Imager——因为它可以在一个地方显示文件系统和$I30时间戳。

我选择Anti-Forensics VHDX的原因是它更可能包含STANDARD_INFORMATION和FILE_NAME时间戳明显不同的条目。

从这里开始只是比较——0x10和0x30时间戳是什么？$I30时间戳是什么？

$STANDARD_INFORMATION

$FILE_NAME (MAC)

$I30->$FILE_NAME (MAC)

在这个例子中，我们可以看到$I30->FILE_NAME时间戳与STANDARD_INFORMATION时间戳一致，而不是与$FILE_NAME时间戳一致。

有趣的是，有一个恢复的$I30记录具有不同的时间戳，与FILE_NAME时间戳一致。

然而，我选择的其他项目显示STANDARD_INFORMATION属性与$I30中的时间戳相同。

这意味着虽然通常数据应匹配，但有时文件大小和“最后访问”时间戳在$I30时间戳中会不同。