勒索软件在每台主机、每一次基本都做同一件事：枚举文件、读每个文件、写一份加密副本、删除原件。每一步都会落到 $MFT 上。只要你知道它的形态，往往无需找到样本或读勒索信，在拿到 MFT 之后几分钟内就能确认事件是一次勒索软件运行。
下面是这种模式、我见过的变种，以及如何把勒索软件与表面相似的其他大规模文件活动区分开。
三个信号
扩展名大规模变化。 新文件出现，与现有文件共享同一个父目录和基础文件名，但扩展名不同。report.docx 变成 report.docx.locked、report.encrypted、report.crypted_{guid} 或 report.docx.[victim_id].lockbit。在短时间窗口内统计这类配对出现了多少，是 $MFT 中勒索软件最清晰的指标之一。单个用户配置文件或共享上一分钟内出现数百条，就是签名特征。
几秒之内集中出现的一波 $STANDARD_INFORMATION created 时间戳。 正常用户活动是一次创建一两个文件的小爆发。勒索软件是按千创建。把可疑窗口内的 SI created 时间戳画成直方图，加密运行会以一根盖过基线的垂直尖峰出现。尖峰的宽度告诉你勒索软件跑得多快（现代多线程变种不到一分钟就能拿下一个用户配置文件；较老的单线程版本耗时更长，尖峰也更宽）。
与加密副本对应的、已被删除的原件。 每一个 report.docx.locked，通常都有一个对应的 report.docx，其 IN_USE 标志现在被清掉了。被删除记录会留在 $MFT 里直到槽位被复用。你可以直接从这条已删除槽位里恢复原件的名称、大小与时间戳。再把同窗口内的 $UsnJrnl FILE_DELETE 原因码与之配上，操作顺序就毫不含糊了。
值得了解的变种
并非每个家族都遵循同一模式。我看到的变种：
- 原地加密。 一些家族（较老的 Sodinokibi 变种、某些 Conti 构建版本）会打开原文件、把加密后的字节写回同一文件、再重命名。不存在单独的"加密副本"文件；已删除原件的模式消失了。但一分钟内对数千个文件的
$UsnJrnlDATA_OVERWRITE仍然非常吵，而且重命名会留下RENAME_OLD_NAME/RENAME_NEW_NAME这一对。 - 间歇式加密。 BlackCat 与近期几个家族只加密文件的部分块（比如每隔一个 100 KB 块加一段），以加速运行。文件大小几乎不变，修改时间会更新，但
$DATA簇基本完好。在$MFT上看起来轻，但 USN journal 仍会显示这些写入。 - 仅重命名。 一小撮"假勒索软件"擦写器只重命名文件、不加密。MFT 模式与真正的勒索软件运行无异；只能靠文件内容分析来区分。
- 对网络盘的影响。 许多家族会枚举映射的网络盘并跨网加密。本地 MFT 显示的变化会比实际事件少；文件服务器的 MFT 承担了大部分变化。
勒索信
大多数家族会在每个受影响目录里丢下一份勒索信，名字像 HOW_TO_DECRYPT.txt、README_FOR_DECRYPT.html、restore-files.txt，或品牌特定的变体。它们内容相同、大小相同，创建时间集中在与加密相同的时间窗口里。在 MFT 中扫描分布在许多父目录、内容大小一致的文本或 HTML 文件，往往比按名称模式查找更先发现它们。
勒索信在取证上还能作为基线之用。它们的创建时间本质上是"勒索软件在该目录中活动的最早时刻"。如果一个目录里有一份时间为 02:14 的勒索信，但同一目录内有时间为 02:09 的加密文件，那么勒索软件先做了枚举与加密，然后才落下勒索信。这能让你对该家族的流程多了解一些。
$MFT 不会告诉你的事
MFT 确认 做了什么 与 什么时候。它不告诉你是哪个进程在写、运营者从哪里进来、勒索软件如何抵达这台主机。要回答这些：
- Prefetch、Amcache 与 Shimcache 提供哪种可执行文件在该时间窗口运行过的证据。
- Sysmon Event ID 1 提供带命令行、父进程与哈希的进程创建。
- 若命令行审计已开启，则 Security Event 4688 提供进程创建记录。
- USN journal
$J提供文件打开/读/写/重命名/删除操作的精确顺序。 - 如果机器仍在线且加密进程仍驻留，则 内存转储。有时能在内存里拿到加密密钥。
- 浏览器历史 与邮件工件，用于推断初始访问向量。
仅 MFT 就能回答最紧迫的运营问题：运行何时开始、影响范围多大、哪些文件被触碰。这些足以做出处置决策。归因是另一个练习，把 MFT 作为输入之一。
VSS 删除作为信号
大多数勒索家族会在开始加密前尝试删除 Volume Shadow Copy，因为 VSS 快照会让受害者不付款就能还原。常见命令是 vssadmin delete shadows /all /quiet。它留下：
- 一条 Windows 系统事件日志条目（VSS 服务消息的
Event ID 8224）。 - 若部署了 Sysmon，会有一条对
vssadmin.exe调用的 Sysmon Event ID 1。 - 主机上一份新创建但内容为空的 VSS 状态。
vssadmin list shadows不返回任何快照，或只返回事件后的快照。
如果你看到一台主机没有 VSS 快照，且 \$Extend\$UsnJrnl 的 MFT 记录序列号显示最近被重新创建过，那么即使加密运行尚未明显展开，你也已经看到勒索软件的准备阶段。关于你仍可能恢复的东西，见 VSS 与 $MFT。
我遵循的取证流程
- 从可疑主机（或者如果 VSS 还有事件发生前的快照，那就从快照）拉出
$MFT与$UsnJrnl:$J。 - 用 MFTECmd 或
mft_dump解析 MFT。按 SI created 降序排。看顶部 1,000 条。 - 如果顶部条目集中在几分钟的窗口里，且其中很多带有不寻常的扩展名，那你看到的就是勒索软件痕迹。
- 拉出对应的已删除记录。它们的
$FILE_NAME属性给你原始文件名。这样你就知道什么被加密了。 - 与 USN journal 交叉比对。加密文件的
FILE_CREATE与原件同时刻的FILE_DELETE共同确认该模式。 - 找勒索信：同时出现在多个目录里、有不寻常名称（HOW_TO_DECRYPT、RECOVERY、README_RESTORE）的小文件。它的内容会标明家族。
- 由家族名称转向已知 IOC：文件哈希、C2 域名、注册表持久化，以及其他日志里已知的 kill chain 工件。
这一流程在一台主机上通常少于三十分钟即可走完，并能给你足够的信息来决定遏制与开始恢复规划。
延伸阅读
- DFIR Report 的 勒索软件案例研究。每篇 writeup 把 MFT 与 journal 证据和 kill chain 的其余部分配对呈现。
- The Record 与 Microsoft Security Blog 上的 LockBit、BlackCat、Cl0p 技术分析。各家族在 MFT 上的具体痕迹细节有别。
- MITRE ATT&CK，T1486 Data Encrypted for Impact。关于勒索软件做了什么以及每种行为留下哪些工件的技术目录。