防御规避技术：Timestomping检测-NTFS取证

取证分析人员通常采用两种方式来验证文件时间戳是否被篡改：

• 对比 MFT（Master File Table，主文件表） 中 $STANDARD_INFORMATION 和 $FILE_NAME 的时间戳

• 寻找纳秒数为 0000000 的时间戳，因为这样的时间戳通常是通过自动化工具（如 Metasploit）生成的。

这两种验证方式会使调查陷入误区，因为它们基于两个错误的观点：

• $FILE_NAME 中的时间戳不会被篡改

• 黑客工具不能改变时间戳中的纳秒数

下文将阐明这两种方式会使调查陷入误区的原因以及验证文件时间戳是否被篡改正确的检测手段。

Timestomping是一种用修改文件时间戳来绕过系统防御的技术。攻击人员经常使用这种技术将恶意文件混入正常文件，这样，当分析人员进行信息检索时，关键的证据就会逃脱检测。

Timestomping 使用的工具通常有Cobalt Strike，Timestomp.exe 以及 Metasploit 等等，这些工具会导致 MFT 中的 $STANDARD_FILE 属性中的 MAC(B) 时间发生变化。这里的MAC(B) 时间代表的是：

• Modified - 修改时间

• Accessed - 访问时间

• Changed - 变更时间（MFT 变更）

• Birth（Creation time） - 创建时间

在MFT 中有两个位置可以记录时间 - $STANDARD_INFORMATION($SI)以及 $FILE_NAME($FN)。每个位置上都相应存储了文件的MAC(B)时间。对于长文件名，将有两个相应的 $FN MAC(B) 属性，也就是在现有的 $SI 的时间戳的基础上再多出 8 个时间戳。

修改 $SI 时间戳是一种很常见的 Timestomping的方式，因为它可以通过用户层面上的 API 进行修改。然而，修改 $FN 需要调用内核或滥用 $FN 时间戳的生成方式（重命名或移动文件）。

严格地说，有两种方式可以修改 $FN 时间戳：

• 方法1

在还没有引入 Patch Guard 的旧操作系统上，使用 Windows API 调用本地 API NtSetInformationFile 和 NtQueryInformationFile ，修改$FN。

• 方法2

在任何操作系统上通过 Timestomping 修改 $SI，然后移动或重命名文件，将修改后的 $SI 复制到 $FN 中 ，以修改 $FN。该技术在 Black Hat议题[1]中提到过。

这里只是为了向那些在调查当中未曾遇到过timestomping的人证明：攻击人员以及恶意软件经常使用这种技术。一些著名的事件中，攻击者使用了timestomping，包括但不限于：

• IRON TWILIGHT (APT28)

• IRON HEMLOCK (APT29) – 篡改了后门文件的时间戳

• TIN WOODLAWN (APT32) – 篡改了二进制XML计划任务文件的创建时间

• NICKEL GLADSTONE (APT38) – 篡改文件时间来混入系统其它文件中

• NICKEL ACADEMY (Lazarus) – 将 calc.exe 的时间戳复制到恶意投放的文件中（这是 Cobalt Strike 的入侵行为）

详细报告请阅读参考链接[2]。

如果攻击人员篡改了文件的 $SI 属性，然后移动或重命名该文件，那么 Windows 就会复制 $SI 中的时间戳到 $FN 中。老版本的 Windows 系统没有安装 Patch Guard ，那么攻击人员也可以使用 SetMace 命令来调用 API (NTSetInformationFile 以及 NTQueryInformationFile)，同样可以达到修改文件的 $FN 属性的目的。

第一步：篡改 $SI 属性中的微秒数

使用 nTimetools[3] 即可将文件的MAC(B)时间设置到任意纳秒，这就绕过了第一种检测方式（寻找纳秒数为 0000000 的时间戳）。

到MFT中观察发生的变化，可以发现该文件 $SI 和 $FN 属性的时间戳如下：

$STANDARD_INFORMATION:

Creation – 2020-05-19 12:34:56
Modification - 2020-05-19 12:34:56
MFT change – 2020-05-19 12:34:56
Last Access - 2020-05-19 12:34:56

Creation – 2022-04-21 02:45:38
Modification - 2022-04-21 02:45:38
MFT change - 2022-04-21 02:55:01
Last Access - 2022-04-21 02:45:38

第二步：移动文件位置

将上面的 file.txt 从桌面移动到一个临时的文件夹。

第三步：查看 $FI 以及 $SI 中的时间戳是否被修改

再次提取 MFT 并查看 C:tempfile.txt 的时间戳如下：

$STANDARD_INFORMATION Timestamps:
Creation – 2020-05-19 12:34:56
Modification - 2020-05-19 12:34:56
MFT change – 2020-04-21 02:55:01
Last Access - 2020-05-19 12:34:56

$FILENAME Timestamps:
Creation – 2020-05-19 12:34:56
Modification - 2020-05-19 12:34:56
MFT change - 2020-05-19 12:34:56
Last Access - 2020-05-19 12:34:56

此时 $FN 已经被篡改，攻击者只需要计算MFT的变化时间，就可以完美伪装恶意文件的时间戳。

其他方法

如果是在没有 Patch Guard 的旧版本的 windows 上，可以使用 SetMace 工具，依靠 API 篡改时间戳。笔者在 Windows 2003 服务器上进行了这个操作，得到了同样的结果：

首先在桌面上创建一个 test.txt 

然后继续运行 SetMace 修改 $FI 以及 $FN：

然后提取 $MFT 就可以看到 $FI 以及 $FN 被修改：

检测手段

在大多数的篡改时间戳的案例中，如果攻击者使用以下方法之一，那么采用比较$FI和$SI以及查看纳秒级精度的时间戳检测方法就足够了：

• Cobalt Strike

• Metasploit

• Timestomp.exe

• SetMace.exe

• 使用 API 修改时间戳

然而，如上所述，绕过这两种检测机制轻而易举，因此我们不得不考虑其他的检测方法。检测这些异常情况的最好方法是通过分析 USN Journal 文件和 $Logfile 文件。在繁忙的系统中，$Logfile 可能很快被覆盖，因此可以考虑从系统镜像中提取 $Logfile 。然而，仅仅 USN Journal 文件就会显示足够的信息来证明时间戳的真实性。

USN Journal 检测

通过解析 USN Journal 文件，我们可以发现如下的几种操作会被记录：

• FILE_CREATE

• RENAME_OLD_NAME

• RENAME_NEW_NAME

所有这些被记录的时间戳都在 2021年4月21日 2:45 左右。这些时间戳与存储在 MFT 中的时间戳大相径庭，MFT中的时间戳可追溯至2020年。通过检查 USN Joural文件并看到这种异常情况，就说明时间戳已经被篡改。

$LogFile 检测

这种方法在频繁操作文件的系统当中可能不太实用。这里在一台虚拟机上进行演示。

在 $Logfile 中需要寻找的是两个与以下内容有关的日志：

• Operation: CreateAttribute

• Filename: file.txt(或其他文件名)

• CurrentAttribute: $FILE_NAME

当篡改时间戳时，我们试图覆盖 $FN 属性，此时在 $Logfile 中有两条重要的日志记录：

• 在原来的 file.txt 创建时记录的本来的 $FILE_NAME 时间戳

• 文件的 $FI 属性被篡改时记录的新的 $FILE_NAME 时间戳

因此，在检测当中也应该在 $Logfile 中寻找这两行。这也是确定是否发生了 Timestomping 的另一个好方法，特别是当注意到 $LogFile 中的时间戳与 $MFT 中的不一致时。

两条矛盾的日志记录如下：