analyzing-mft-for-deleted-file-recovery

analyzing-mft-for-deleted-file-recovery 技能概览

这个技能做什么

analyzing-mft-for-deleted-file-recovery 技能可帮助你分析 NTFS Master File Table（$MFT），以恢复已删除文件的元数据，并在可能的情况下，还原内容痕迹或路径历史。它面向 DFIR 场景，目标不只是“找到已删除文件”，而是重建文件曾经存在过什么、何时发生变化，以及时间戳或元数据是否被篡改。

适合谁安装

如果你要在 NTFS 卷上做事件响应、取证初筛或 Security Audit，并且需要一套结构化的已删除文件恢复流程，就应该安装 analyzing-mft-for-deleted-file-recovery 技能。它特别适合你已经有镜像、原始 $MFT 或 MFTECmd 输出文件，希望进行可重复分析，而不是只靠一个通用提示词。

为什么它有用

它的核心价值在于实用的工作流支持：重点围绕已删除记录、时间戳、$UsnJrnl、$LogFile 和 MFT slack space 展开。相比简单的“解析 MFT”提示，这种组合能带来更高的信息增益，因为它会推动交叉验证，而不是只做记录罗列。

如何使用 analyzing-mft-for-deleted-file-recovery 技能

安装并先检查关键文件

使用仓库说明里的安装命令：npx skills add mukul975/Anthropic-Cybersecurity-Skills --skill analyzing-mft-for-deleted-file-recovery。安装后，先读 SKILL.md，然后再看 references/workflows.md、references/api-reference.md 和 references/standards.md。如果你要验证输出质量或报告结构，建议尽早打开 assets/template.md，这样你的提示词可以直接贴合预期交付物。

提供适合实战的输入

analyzing-mft-for-deleted-file-recovery usage 最好在你一次性给出三类信息时使用：证据来源、问题目标和约束条件。例如：“分析这个来自 C:\Users\...\NTFS 的 MFTECmd CSV，识别已删除文件、可能的删除时间和 timestomping 指标；返回一份简洁的 Security Audit 摘要。”这比“帮我恢复已删除文件”更强，因为它明确告诉技能应优先输出什么。

按仓库工作流顺序来做

一套实用的 analyzing-mft-for-deleted-file-recovery guide 流程是：先提取或提供 $MFT，再用 MFTECmd 或 analyzeMFT 解析，筛选已删除记录（InUse = False），对比 $SI 和 $FN 时间戳，然后交叉参考 $UsnJrnl 和 $LogFile 以补全序列和删除上下文。如果你怀疑只能部分恢复，主解析之后还要检查 MFT slack space，避免漏掉残留的属性数据。

用输出约束提升提示质量

在发起分析时，明确你需要的输出格式：表格、时间线、初筛笔记，还是可直接交付审计的摘要。还要说明你只想看已删除记录、只看 timestomping 候选项，还是要完整合并时间线。对于 analyzing-mft-for-deleted-file-recovery for Security Audit，可以要求明确结论、置信度说明和任何证据缺口，这样结果才适合放进审查材料。

analyzing-mft-for-deleted-file-recovery 技能常见问题

这只用于已删除文件恢复吗？

不是。这个技能以已删除文件恢复为中心，但同样支持时间线重建和反取证审查。如果你的实际任务只是宽泛的 NTFS 初筛，而没有已删除文件相关问题，通用的文件系统取证提示词可能就够了。

使用它一定要有 MFTECmd 吗？

MFTECmd 是最自然的输入方式，但不是唯一方式。这个技能同样适配 analyzeMFT 和原始 MFT 审查。如果你手上只有磁盘镜像，没有解析后的输出，先提取 $MFT 或先生成 CSV，通常能得到更好的结果。

初学者适合用吗？

适合，只要用户能提供证据和清晰的问题。对初学者来说，这个技能比空白提示词更有价值，因为它会把注意力引向正确的工件和检查点。若用户连 NTFS 卷和普通文件列表都分不清，那就不太适合直接使用。

什么时候不该用它？

如果文件系统不是 NTFS，或者案件里没有删除、时间戳问题，又或者你需要的是完整内容 carving 而不是以元数据为主的恢复，就不要用 analyzing-mft-for-deleted-file-recovery。这些情况下，换一套取证流程会更快。

如何改进 analyzing-mft-for-deleted-file-recovery 技能

给它更强的证据，而不是只给目标

更好的输入会明确来源和范围：例如“来自一台工作站的 MFTECmd CSV，重点看 Downloads 目录里的已删除文档，包含父路径和删除指示”。这比“分析 MFT”更有效，因为技能可以优先处理相关行，而不是把全部内容都做成概述。

要求正确的取证对比

质量提升的关键在于比较 $SI、$FN、$UsnJrnl 和 $LogFile。如果你在意 analyzing-mft-for-deleted-file-recovery skill 的输出质量，就要让模型解释不一致之处，而不只是列出时间戳。这样更容易发现 timestomping、重命名历史，以及删除记录仍保留可用路径元数据的情况。

留意常见失败模式

最常见的问题，是把不完整元数据里的恢复确定性说得过头。一个已删除的 MFT 记录可能保留文件名和时间戳，但并不意味着文件内容还在。另一个常见问题是忽略重用风险：如果记录已被重新分配，恢复出的细节可能只是部分信息，甚至具有误导性。要让技能明确区分已确认事实和推断结论。

用更聚焦的第二轮提示迭代

拿到第一轮结果后，可以进一步收窄提示词：“只对 $SI 和 $FN 创建时间不一致的已删除记录重新分析；返回一个简短的发现表和一段 Security Audit 结论。”这样能迫使技能对证据进行排序，而不是重复陈述。