maintaining-engagement-state

维护项目状态

一项评估项目会持续数周，而一次会话不会。这两件事之间的差距， 正是工作被重复、发现失去证据、凭据无法追溯来源，以及由于无人记录 而导致制品遗留在生产环境中的地方。

这不是附加在实际工作上的行政负担。**来源记录能让发现具备可报告性， 而制品登记簿能让清理成为可能。**事后无法从终端滚动记录中重建这两者。

假设所有未写入记录的内容都会丢失：不仅仅是被遗忘，而是被悄无声息地 丢失，以至于下一次会话会自信地重复操作，或与之前的操作相矛盾。

适用场景

• 任何持续时间超过一次工作时段的评估项目或调查
• 休息后恢复工作，或接手他人的工作
• 即将遇到上下文边界，但仍有未记录的状态
• 在分析人员、班次或团队之间交接工作
• 运行任何会向目标写入内容的操作之前
• 无法回答“这个凭据来自哪台主机？”时

不适用场景

• 撰写面向客户的交付物——使用 reporting-security-findings； 此技能产出的原始材料会供该技能使用
• 判断某项发现是否属实——应使用相关的测试或分析技能； 无论结果如何，都应在此处记录
• 可能提交法庭的证据的保管链——法律证据保管有超出此处范围的正式要求； 使用 responding-to-incidents 并遵循组织法律顾问的意见
• 一次工作时段内完成，且没有任何内容留在目标上的独立任务

六项记录

将以下内容保存在同一个文件中，放在代码库或案件文件夹内，并在工作过程中 持续更新——不要等到最后才重建。

1. 范围与授权

范围内的目标和明确排除项、测试时段、指定联系人，以及授权函的存放位置。 逐字复制排除项；改述范围正是人们测试错误资产的原因。

还要记录一个字段，因为“在范围内”和“可访问”是两个不同的问题。 出站模式说明此评估项目允许与哪些对象通信：

模式	允许	拒绝
offline	静态分析、本地样本、仿真	任何出站数据包
lab_only	你控制的实验室和 VM 网段	生产环境，以及任何可路由的对象
authorized_target_only	范围内列出的资产	列表之外的所有对象
unrestricted_lab	书面授权的隔离实验室网络	公共互联网

在运行第一条命令之前就指定模式，而不是等某些操作触及超出预期的范围后再指定。 这个字段能避免两种典型错误：进行“仅静态分析”的恶意软件分诊时解析了 C2 域名， 以及范围受限的 Web 测试中扫描器跟随重定向访问了范围外的资产。当此代码库中的 某项技能要求使用隔离实验室时，指的是 lab_only 或限制更严格的模式。

授权是一道门槛，不是备注。如果授权尚待批准或尚未取得，可以阅读文档和制定计划； 但不能扫描、挂钩或利用漏洞。

2. 凭据来源

对于每个凭据、哈希、令牌或密钥：它是什么、来自哪里、如何获取，以及曾用于 访问哪些目标。

cred-04  | svc_backup NTLM hash
         | source: SAM dump, WS-014 (10.2.3.14), local admin via CVE-2021-XXXX
         | obtained: 2026-07-27 14:02
         | used on: FS-02 (success), DC-01 (failed, no local admin)
         | provenance: CONFIRMED

来源记录不是记账。它能回答你将被问到的三个问题：

• 它是真的吗？ 来源不明的凭据可能是诱饵——参见 recognizing-deception。如果你说不清它从何而来，就无法排除这种可能。
• 它在范围内吗？ 从范围外主机收集的凭据会污染使用它访问到的一切对象。
• 影响范围有多大？ 客户的修复措施是“轮换这些特定密钥”，而这需要完整清单。

将任何无法追溯的内容标记为 provenance: UNKNOWN，并将其视为可疑项， 而不是悄悄拿来使用。

3. 访问清单

每项已获得的访问权限：主机、账户、权限级别、方式，以及是否仍然有效。访问权限会失效——会话会过期、密码会轮换、主机会重启。你曾经拥有的权限清单，并不等于你当前拥有的权限清单。

4. 操作记录——清理清单

每次对目标进行写入时，都要立即记录。 写入的文件、创建的服务或任务、新增的账户、注册表项、共享、 防火墙规则、云资源、配置编辑。

art-07 | WS-014 | C:\Windows\Temp\c2.exe        | dropped 14:02 | REMOVED 18:40
art-08 | DC-01  | scheduled task "WinUpdateSvc" | created 15:10 | PENDING
art-09 | AWS    | IAM user "svc-audit-tmp"      | created 16:22 | PENDING

事后凭记忆编写的清单总是不完整，而遗漏的内容会留在客户的生产环境中。两个独立的相关方都需要这份清单：你需要它来清理；客户的蓝队需要它来区分你的操作痕迹与真实入侵——无论是在交付期间还是之后。

在事件调查中，同一份记录也涵盖你在证据系统上做过的操作，从而能将你的活动与攻击者的活动区分开来。

5. 带证据的发现

每项发现：内容、位置、复现步骤、采集的证据，以及所证实的影响。发现时就采集证据——能证明问题存在的状态，经修复、重启或凭据轮换后便不复存在。

6. 未果尝试

这类记录最常被跳过，却最能在不同会话间发挥作用：尝试了什么、针对什么，以及失败的原因。

dead-03 | Kerberoast svc_sql | hash cracked? NO after 6h, 14M candidates
dead-04 | SMB signing DC-02  | enforced -- relay not viable
dead-05 | /admin on portal   | 403 from all tested source ranges

如果没有这份记录，下一次会话就会重新进行那场耗时 6 小时的破解。记录失败结果，也能让最终报告准确区分“我们在那里什么都没发现”和“我们没有检查那里”。

会话边界纪律

在会话结束前——无论是否按计划结束——记录必须回答：

1. 我目前持有哪些访问权限？它们是否仍然有效？
2. 我在目标上留下了哪些尚未清理的内容？
3. 我刚才正在做什么？
4. 我排除了哪些可能性，以免有人重复尝试？

在工作过程中就记下这些内容，而不是等到最后。意外结束的会话，恰恰是其状态从未被记录的会话；一次任务可能毫无预警地丢失上下文。

交接

交接内容是在同一份记录上再补充三项：当前进展、紧接着要做的操作，以及任何有时效性的事项（正在运行的破解任务、即将过期的令牌、计划于 02:00 触发的任务）。如果接手的分析师还得问“你刚才在做什么？”，那这次交接就失败了。

跨次任务

每次任务结束后，这六条记录都会重置。有两件事值得在任务之间延续，但两者都会以同样的方式出错——凭记忆重建，就会失真。

机器实际能做什么。 技能调用工具前，工具必须已存在于已知路径，且其版本的参数标志与技能的预期一致。猜测 /usr/bin/ghidra 或 jadx 的位置，然后把故障当作目标的问题来排查，是白白浪费一小时的常见方式。维护一份本地且针对特定机器的清单——工具、实际路径、版本，以及任何通过套接字通信的组件（MCP 服务、辅助守护进程）是否不仅已安装，而且已注册并能响应。已就绪和可用是两种不同状态：磁盘上有 MCP 二进制文件，却没有运行中的服务，并不代表具备相应能力。这份清单属于特定机器，不应放入共享仓库；把它当作 ~/.ssh/config 一样对待——归你所有、加入 Git 忽略规则，发布的任何内容都不应依赖它。

以往案例带来的经验。 每个已完成案例都记一篇简短的去标识化日志，记录场景、奏效的技术、走不通的路及其耗费的时间，以及工具方面的意外情况——这样，下次遇到类似案例时就能查阅，而不必从头开始。按场景、技术和目标特征为日志编制索引，并在开始新工作前先查阅索引，而不是直接阅读日志；索引的成本很低。先准备几个经过实践验证的参考案例，这样从第一天起它就有用，而不是等到第十次任务后才派上用场。

要安全地保存日志，需要遵守两项原则。写入时就去标识化，而不是等到分享前才处理——真实域名、IP、令牌和个人身份信息（PII）在写入时就替换为占位符，这样即使日志原本无意外传，也不会在意外泄露时暴露信息。还要默认保留在本地：将经验提交到共享或公开位置，会把任务细节交给第三方；“模型已经匿名化处理”并不是一种你能向客户辩护的保护措施。如果要分享日志，必须针对每条日志有意识地审查并作出决定，而不能把分享当作工作流中的默认步骤。

应当摒弃的自我安慰

• “我会记得它是从哪里来的。” 你不会，下一个会话也不会。无法追溯来源的凭据无法在报告中使用，也无法与植入的凭据区分。
• “终端历史里都有。” 历史记录不包含推理过程、可信的时间戳、失败情况，也不记录你的结论。而且会话结束后，历史记录也常常会丢失。
• “最后我会列出清理清单。” 最后的时刻恰恰是记忆最差、清单最长的时候。凭记忆记录的资产总是不完整，遗漏的东西会留在生产环境中。
• “没人需要知道我走过的弯路。” 这些内容能区分有据可查的否定结果与未经审查的空白，也能避免下一个会话花六小时重新破解同一个哈希。
• “我会边做边清理，不需要登记清单。” 那么登记清单只会让你每件资产多写一行，并证明这一点。没有清单，你就无法证明环境已恢复到原先状态。
• “客户只想知道发现了什么。” 直到下个月警报响起，他们需要确认你创建的账户是不是你的。无人认领的资产会被当作入侵事件调查。
• “记录失败会让任务显得不专业。” 没有记录否定结果的任务，显得不够严谨，而不是成功。覆盖情况本身就是一项发现。

参考资料

• reporting-security-findings — 使用此记录来生成交付物
• recognizing-deception — 说明无法追溯来源的凭据为何危险，而不只是杂乱
• responding-to-incidents — 调查方面的对应内容，包括正式的证据处理流程