重点文件时间线检查结果与攻击者操作节律分析

重点文件时间线检查结果与攻击者操作节律分析

0x02电子取证/重点文件目录检查 给出了 stat、find、forfiles 等文件时间查询命令。到了 0x03取证分析，已有文章 重点目录异常文件与落地载荷关联分析 聚焦的是"文件为什么落在这个目录"和"落地载荷的语义分类"。本文换一个角度：不讨论文件落在哪，而是讨论文件的时间戳能告诉我们什么。

文件时间线分析要回答的核心问题是：

• 攻击者在什么时间窗口内做了什么
• 操作之间的先后顺序和因果关系
• 时间戳本身是否可信、是否被篡改
• 如何从散乱的文件时间中还原出攻击者的操作节律

0x01 MACE 时间的基本语义

Windows NTFS 的四个时间戳

NTFS 文件系统为每个文件维护四个时间戳，统称 MACE：

这四个时间戳分别存储在 MFT 的两个属性中：

• $STANDARD_INFORMATION（$SI）：用户可见、可修改
• $FILE_NAME（$FN）：索引用、通常不可被普通工具修改

两者的时间差异是检测 timestomp 的关键依据。

Linux ext4 的三个时间戳

Linux ext4 文件系统维护三个主要时间戳：

关键区别：touch 命令可以修改 mtime 和 atime，但不能修改 ctime 和 crtime。这意味着 ctime 是检测 timestomp 的天然锚点。

0x02 0x02 取证结果如何转化为时间线输入

1. stat 结果的时间语义

0x02 中给出的 stat 命令输出示例：

File: "/"
Size: 1024         Allocated Blocks: 2            Filetype: Directory
Access: Wed Jan  8 12:40:16 1986
Modify: Wed Dec 18 09:32:09 1985
Change: Wed Dec 18 09:32:09 1985

分析时应关注：

• Modify 和 Change 是否一致？ 如果 mtime 被人为回拨但 ctime 未变，说明存在 timestomp
• Access 时间是否合理？ 现代系统 atime 更新策略不一致，不宜作为强证据
• 时间戳和文件内容/上下文是否匹配？ 系统二进制文件的 mtime 不应晚于系统安装日期

2. find 时间搜索结果的聚类

0x02 中给出的 find 时间搜索命令：

find / -ctime 0 -name "*" -ls
find /tmp -mtime -1 -type f
find /var/www -name "*.php" -newermt '2019-08-08' ! -newermt '2019-11-23'

这些命令的输出不是孤立文件清单，而是时间窗内的文件集合。分析时应做：

• 时间窗聚类：把同一时间窗内创建/修改的文件归为一组
• 路径关联：同组文件是否分布在相关目录（如 /tmp + /var/www + ~/.ssh）
• 类型关联：同组文件是否包含脚本、二进制、配置文件等不同类型

当多个文件在同一时间窗内出现在多个关键目录时，更可能是攻击者的批量操作，而非巧合。

3. forfiles 时间搜索结果的定向分析

0x02 中给出的 forfiles 命令：

forfiles /m *.jsp /D +2021/5/1 /s /p c:\ /c "cmd /c echo @path @fdate @ftime"
forfiles /S /M *.exe /D +2026/6/15 /C "cmd /c echo @path @fdate @ftime"

这些命令适合在已知入侵时间窗后，定向搜索该时段内新增的特定类型文件。分析要点：

• 搜索结果中的文件是否都有合理的创建来源
• 文件时间是否和入侵时间窗吻合
• 是否存在时间戳明显异常的文件（如 mtime 远早于系统安装日期）

0x03 从文件时间到攻击者操作节律

1. 操作节律的含义

攻击者在入侵过程中通常遵循一定的操作模式：

• 初始访问 -> 投放载荷（下载目录、Temp）
• 执行 -> 运行载荷（Prefetch、Amcache、4688）
• 持久化 -> 安装服务/任务/注册表（System 7045、Security 4698）
• 横向移动 -> 在内网扩散（4624 Type 3、SMB/RDP 日志）
• 目标达成 -> 数据窃取、加密、清理

每个阶段都会留下文件时间戳。如果把这些时间戳按时间排列，可以看到攻击者的操作节律——他们多久完成一个阶段、在哪些目录留下痕迹、是否有意压缩操作时间。

2. 时间窗聚类的实战方法

假设通过 find 和 stat 得到以下文件时间：

01:14:22  C:\Windows\Temp\adobe_update.exe    Created
01:14:23  C:\Windows\Temp\config.xml          Created
01:14:45  C:\ProgramData\svchost.exe          Created
01:15:02  C:\ProgramData\update.dll           Created
01:15:30  C:\Users\admin\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\update.lnk  Created
01:16:10  C:\Windows\Prefetch\ADOBE_UPDATE.EXE-3A4F21B2.pf  Created
01:18:00  C:\Windows\Temp\adobe_update.exe    Deleted

时间窗聚类分析：

• 01:14:22-01:14:23：Temp 目录出现两个文件，间隔 1 秒，说明是同一投放动作
• 01:14:45-01:15:02：ProgramData 出现两个文件，间隔 17 秒，说明投放后立即部署持久化组件
• 01:15:30：启动目录出现 LNK，说明持久化链已建立
• 01:16:10：Prefetch 记录执行，说明载荷已被运行
• 01:18:00：Temp 文件被删除，说明攻击者开始清理中间产物

整个操作节律：从投放到清理，约 4 分钟。这是一个非常紧凑的攻击时间窗。

3. Linux 侧的操作节律

类似地，Linux 侧通过 find + stat 可以得到：

02:13:50  /tmp/update.sh          mtime
02:13:51  /tmp/fscan              mtime
02:14:01  /var/spool/cron/root    mtime (计划任务被修改)
02:14:15  /home/app/.ssh/authorized_keys  mtime
02:15:00  /tmp/update.sh          Deleted
02:15:01  /tmp/fscan              Deleted

操作节律：

• 02:13:50-02:13:51：工具投放（脚本 + 二进制）
• 02:14:01：计划任务被修改（持久化）
• 02:14:15：SSH 密钥被写入（备用入口）
• 02:15:00-02:15:01：临时工具被删除（清理）

整个操作节律：从投放到清理，约 1 分钟。比 Windows 侧更紧凑，说明攻击者对 Linux 操作更熟练或使用了自动化脚本。

0x04 时间戳可信度判断

1. Timestomp 检测的基本方法

攻击者经常使用 timestomp 技术修改文件时间戳，使恶意文件看起来像系统原有文件。MITRE ATT&CK 将其编为 T1070.006。

检测方法：

Windows 侧：

• 比较 $SI 和 $FN 的 MACE 时间：如果 $SI.C 远早于 $FN.C，或 $SI.M 被回拨但 $FN.M 未变，说明存在 timestomp
• 检查纳秒精度：通过 PowerShell 修改的时间戳，纳秒部分通常为 0
• 比较同目录文件时间：如果某个文件的创建时间和同目录其他文件差异巨大，值得怀疑

$si = (Get-Item "C:\ProgramData\svchost.exe").CreationTime
$fn = # 需要通过 MFT 解析工具获取 $FN 时间
# 如果 $si 和 $fn 差异显著，说明存在 timestomp

Linux 侧：

• 比较 mtime 和 ctime：touch -t 可以修改 mtime 和 atime，但不能修改 ctime
• 如果 mtime 早于 ctime，且差异不合理，说明 mtime 被篡改
• 在 ext4 上通过 debugfs 查看 crtime：如果 mtime 早于 crtime，说明存在 timestomp

stat suspicious_file
# 如果 mtime = 2020-01-01 但 ctime = 2026-06-15，说明 mtime 被回拨

debugfs -R 'stat <inode_number>' /dev/sda1 | grep crtime
# 如果 mtime 早于 crtime，说明存在 timestomp

2. 时间戳不可信时的替代方案

当时间戳被篡改或不可信时，可以转向以下替代证据：

• Prefetch / Amcache：记录执行时间和次数，不受文件 timestomp 影响
• USN Journal（$UsnJrnl）：记录文件系统变更，时间戳独立于文件 MACE
• 事件日志：4688、7045、4698 等事件的时间戳由系统维护，攻击者难以修改
• Sysmon Event 1/2/3：进程创建、文件创建时间、网络连接时间，独立于文件时间戳
• 审计日志（auditd）：Linux 侧的文件访问和修改记录

3. 文件操作对时间戳的影响

不同文件操作对时间戳的影响不同，理解这些规则对时间线分析至关重要：

Windows 侧：

Linux 侧：

这些规则帮助分析人员判断：一个文件是原始创建、复制落地、还是被移动过。

0x05 操作节律在报告中的表达

1. 时间线表格

攻击者操作节律建议整理为如下格式：

2. 节律总结

在时间线表格之后，应给出节律总结：

• 总操作时间窗：从首次投放到最后清理，约 4 分钟
• 操作阶段：投放 -> 部署 -> 持久化 -> 执行 -> 清理
• 操作特征：时间紧凑、步骤完整，说明攻击者有预谋且操作熟练
• 工具特征：文件名伪装为 Adobe 更新器，但路径不符合正常安装习惯

0x06 三个最容易误判的边界

1. 文件时间不等于攻击时间

文件的 mtime 可能被 timestomp 修改，atime 在现代系统上不可靠，ctime 虽然更难篡改但也不是绝对可信。文件时间只能作为时间线的参考，不能单独作为攻击时间的定论。

2. 时间相近不等于因果关系

两个文件在同一时间窗内被创建，不等于它们是同一攻击者的操作。需要结合路径、类型、后续行为等综合判断。

3. 文件被删不等于时间线断裂

即使文件已被删除，Prefetch、Amcache、USN Journal、事件日志中的时间记录仍然存在。文件删除不等于证据消失，只是证据来源从文件系统转移到了旁证系统。

0x07 公开资料与分析借鉴

1. Security Scientist: 12 Questions About Timestomp (T1070.006)

Vincent van Dijk 在 Security Scientist 上发布的 Timestomp 深度文章，系统说明了：

• NTFS MACE 四个时间戳的含义和存储位置（$SI vs $FN）
• Cobalt Strike、Metasploit、PowerShell 的 timestomp 方法
• APT28、APT29、APT32 等国家级攻击者的 timestomp 实战案例
• 检测方法：$SI vs $FN 时间差异、纳秒精度为 0、USN Journal 交叉验证

最值得借鉴的一点是：大多数 timestomp 工具只修改 $STANDARD_INFORMATION 属性，不修改 $FILE_NAME 属性。比较两者时间差异是最可靠的检测方法。

公开来源：

• Security Scientist: 12 Questions and Answers About Timestomp (T1070.006)

2. Intramweb: stat Command for Linux Security

Intramweb 在 2026 年发布的 Linux stat 命令安全指南，清楚说明了：

• mtime、ctime、atime 的安全语义差异
• ctime 不能被 touch 修改，是检测 timestomp 的天然锚点
• 通过 inode 号变化判断文件是否被替换（而非原地修改）
• 系统二进制文件的 mtime 不应晚于系统安装日期

最值得借鉴的一点是：ctime 变化但 mtime 不变，说明元数据被修改（权限、所有者变更），这是 timestomp 尝试的经典指标。

公开来源：

• Intramweb: stat Command: Inspect Linux File Metadata and Detect Binary Tampering

3. Qazeer DFIR Notes: Linux Timestomping

Qazeer 的 DFIR 笔记中关于 Linux timestomp 的章节，提供了实用的检测方法：

• ext4 上的 crtime 不能被 touch 修改
• 如果 mtime 或 ctime 早于 crtime，说明存在 timestomp
• 通过 debugfs -R 'stat <inode>' <device> 查看 crtime

最值得借鉴的一点是：crtime 是 Linux ext4 上最不可篡改的时间戳，是验证其他时间戳可信度的锚点。

公开来源：

• Qazeer DFIR Notes: Timestomping

4. Palmbach & Breitinger: Artifacts for Detecting Timestamp Manipulation

David Palmbach 和 Frank Breitinger 在 2020 年发表的学术论文，系统研究了 NTFS 时间戳篡改检测的可靠性：

• $USNJrnl 和 $LogFile 是检测 timestomp 的两个关键 Artifact
• $USNJrnl 保留 30-40 小时的日志数据，远多于 $LogFile 的 2-3 小时
• 基于机器学习的检测方法可以有效识别 timestomp 文件并减少误报

最值得借鉴的一点是：文件时间戳不是唯一的证据来源，$USNJrnl、Prefetch、LNK、事件日志等都包含独立的时间信息，可以用于交叉验证。

公开来源：

• Palmbach & Breitinger: Artifacts for Detecting Timestamp Manipulation in NTFS on Windows and Their Reliability

5. Forensic Focus: Linux Timestamps, Oh boy!

Forensic Focus 上的 Linux 时间戳实验文章，详细记录了不同文件操作对时间戳的影响：

• wget 下载保留源文件 mtime，ctime 更新为下载完成时间
• curl 下载不保留源文件 mtime，mtime 和 ctime 都更新
• scp 下载/上传后 mtime、ctime 都更新为操作完成时间
• cp 复制后 mtime 更新为复制时间
• mv 移动后 mtime 不变，ctime 更新

最值得借鉴的一点是：不同工具对时间戳的影响不同，理解这些差异可以帮助判断文件是通过什么方式落地的。

公开来源：

• Forensic Focus: Linux Timestamps, Oh boy!

0x08 和其他分析篇怎样联动

本文最适合和以下专题联动：

• 重点目录异常文件与落地载荷关联分析：提供文件落点语义分析，本文补充时间维度
• 时间偏移与时钟篡改对事件时间线分析的影响：提供系统时钟可信度分析
• 日志清理与反取证痕迹识别：提供文件删除后的旁证恢复方法
• 系统日志检查结果证据强度分层与事件链构建分析：提供日志时间线和文件时间线的交叉验证

本文的定位是聚焦 0x02 重点文件检查中"时间戳"这一维度，而不是覆盖整个文件取证领域。

0x09 建议的交付结构

文件时间线分析结果建议整理为如下表格：

0x0A 总结

文件时间线分析的关键，不是"列出文件的时间戳"，而是：

• 从 MACE 时间中读出攻击者的操作顺序
• 从时间窗聚类中读出操作节律
• 从时间戳差异中读出 timestomp 痕迹
• 从文件操作对时间戳的影响中读出落地方式

当你能把 stat、find、forfiles 的输出从"文件清单"升级为"攻击者操作节律图"时，0x02 里的"重点文件目录检查"才真正在时间维度上升级为 0x03 的"文件时间线分析与操作节律还原"。