wittymastodon/ir-playbook-azure-lateral-movement

# 事件响应手册 — Azure/Entra ID 中的未经授权访问与横向移动   ## 目录 - [概述](#overview) - [项目背景](#why-this-project) - [开发时间线](#development-timeline) - [仓库结构](#repository-structure) - [内容详情](#whats-inside) - [图表](#diagrams) - [关键设计决策](#key-design-decisions) - [引用的工具与技术](#tools--technologies-referenced) - [如何使用本仓库](#how-to-use-this-repository) - [即将推出](#coming-soon) - [许可证](#license) ## 概述 一份针对云原生 Azure/Entra ID 环境（无本地 Active Directory）的完整事件响应手册， 涵盖了基于 NIST SP 800-61 的完整生命周期 — 准备、检测与分析、 遏制、根除、恢复和事件后活动 — 围绕一个特定且技术细节丰富的场景构建：源于身份凭据被盗用的未经授权访问和横向移动。 本仓库包含三个部分，它们旨在结合阅读， 而不是作为三个独立的部分看待： - **`playbook/`** — 可重用的框架。阅读此部分以了解流程。 - **`templates/`** — 手册流程生成的空白、按事件复制工件。阅读此部分以了解实际需要填写的内容。 - **`scenario/`** — 一个完整的示例案例（Case STRA-2026-0801-01），展示了针对一个连贯、真实的 incident 填写完整的每个模板，以及基于此构建的桌面推演。 ## 项目背景 有两个目标驱动了此项目，并且它们有意在方向上略有不同： 1. **展示现代云优先环境下的实用 IR 框架知识** — 之所以选择 Entra ID 横向移动而不是更常见的勒索软件场景， 正是因为它是一个较少模板化的领域，并迫使人们去应对以身份为中心的 攻击模式（token 窃取、service principal 滥用、Conditional Access），而不是经典的端点/域控制器技术。 2. **构建具有实际操作价值的内容**，而不仅仅是用于展示 — 调查工作表源于已在实际付费客户工作中使用的表单， 并且手册的遏制/根除逻辑在编写时就考虑了要经得起实际审查（证据监管链、 法律升级触发器、分级严重性监控窗口），而不仅仅是为了看起来完整。 ## 开发时间线 按阶段而非日历日期呈现 — 实际进度各不相同， 基于阶段的描述比按天数计算更真实、更实用地总结了这项工作。 | 阶段 | 发生了什么 | 原因 | |---|---|---| | **场景设定** | 选择 Entra ID 原生横向移动而非勒索软件；界定环境范围（完全远程、无本地 AD、中型组织） | 设定后续的每个技术决策 — 工具、遏制操作和严重性逻辑都必须与纯云身份模型相匹配 | | **框架构建（第 1–5 部分）** | 从准备到恢复逐节起草，每一节都与上一节交叉引用 | 每一部分的严重性/遏制/恢复逻辑都依赖于前一部分 — 线性构建保证了交叉引用的准确性 | | **检测工程** | 构建 Splunk SPL 查询并映射到 IOC 类别和 MITRE ATT&CK 技术 ID；添加了统计基线确立和邮件/SMTP 监控 | 一份只写“检查 SIEM”而没有展示实际查询的手册，并不能体现真正的专业能力 | | **取证与遏制深度** | 添加了实时分类工具包（TCPView、Process Explorer、Autoruns、Procmon）和特定于操作系统的取证镜像程序，并带有明确的监管链/证据 ID 约定 | 如果没有严格的证据保存纪律，遏制措施在案件需要经受审查时是站不住脚的 | | **恢复策略** | 定义了 CI/CD 恢复与重建策略，根据被盗用账户的访问级别和确认的影响进行严重性分级 | 现代事件经常触及构建/部署基础设施 — 一份停留在“从备份恢复”的手册会忽略真正的风险 | | **质量审查阶段** | 结构化的自我审查暴露了真实的缺陷：没有具体示例、没有 ATT&CK 映射、没有图表、缺少事件后活动部分、没有桌面推演 | 只构建而不检查自己的工作，正好会引发此阶段捕获到的那些盲点 | | **完整示例** | 构建了一个完整的虚构事件（Case STRA-2026-0801-01），并将其贯穿于每个模板 — 叙述、时间线、事件后报告、利益相关者沟通、保险/法律审查、经验教训 | 仅有模板并不能证明框架有效；填写完整的示例才能做到 | | **桌面推演与第 6 部分** | 基于完整示例构建了叙事驱动（而非基于幻灯片）的桌面推演；编写了之前缺失的事件后活动部分 | 完成了从“这是一个框架”到“团队将如何实际进行演练”的闭环 | | **图表与仓库结构** | 使用 Mermaid 构建了攻击路径、模板关系和响应流程图（可在 GitHub 上原生渲染）；仓库重组为 `playbook/` / `scenario/` / `templates/` | 结构和视觉效果才是让技术仓库真正易于浏览的关键，而不仅仅是内容完整 | ## 仓库结构 ``` ir-playbook-azure-lateral-movement/ ├── README.md ├── playbook/ │ ├── 01-preparation.md │ ├── 02-detection-analysis.md │ ├── 02a-detection-queries-splunk.md │ ├── 03-containment.md │ ├── 03a-live-triage-network-annex.md │ ├── 04-eradication.md │ ├── 05-recovery.md │ ├── 06-post-incident-activity.md │ └── diagram-response-flow.md ├── scenario/ │ ├── scenario-narrative.md │ ├── scenario-timeline-STRA-2026-0801-01.md │ ├── scenario-timeline-final-STRA-2026-0801-01.md │ ├── case-report-STRA-2026-0801-01.md │ ├── case-comms-STRA-2026-0801-01.md │ ├── case-insurance-legal-STRA-2026-0801-01.md │ ├── case-lessons-learned-STRA-2026-0801-01.md │ ├── diagram-attack-path-STRA-2026-0801-01.md │ ├── detection-alerts-savedsearches.conf.md │ └── tabletop-exercise.md └── templates/ ├── README.md ├── ir_billable_sheet.pdf ├── incident-timeline-template.md ├── incident-timeline-final.md ├── comms-templates.md ├── post-incident-report.md ├── cyber-insurance-legal-notification.md └── lessons-learned-smart-goals.md ``` ## 内容详情 **`playbook/`** — 框架本身，每个事件响应阶段对应一个文件。 每一部分都建立在前一部分的基础之上：准备阶段定义了角色和严重性标准，检测与分析阶段据此进行分配， 遏制阶段的决策树以此为核心依归，并以此类推，直到恢复和事件后活动。 **`templates/`** — 手册流程生成的每个可重用工件：一份调查/计费工作表、一份事件时间线、 一套五阶段的利益相关者沟通工具包、一份事件后报告、一份有条件触发的网络保险/法律通知包， 以及一份围绕 SMART 目标构建的经验教训文档。请参阅 `templates/README.md` 了解它们之间的 依赖关系 — 在填写任何模板之前值得一读，因为有几个模板有严格的一致性规则（例如，根本原因在三份独立的文档中必须逐字匹配）。 **`scenario/`** — Case STRA-2026-0801-01：通过钓鱼邮件投递的 信息窃取程序盗取了一名正在出差的员工的 session token，该 token 随后被重放，用于访问一个包含已暴露的 CI/CD 凭据的共享存储账户。 `templates/` 中的每个模板都是针对此事件填写的，此外还有基于相同场景构建的、供团队练习的桌面推演， 以及一个可部署的 Splunk 检测配置（`detection-alerts-savedsearches.conf.md`），它将该案例自身的经验教训建议之一实现为实际的“告警即代码”(alert-as-code)。 ## 图表 - **攻击路径** (`scenario/diagram-attack-path-STRA-2026-0801-01.md`) — Case STRA-2026-0801-01 的技术链条，从最初的钓鱼邮件投递到检测和遏制， 包括 MFA 未触发的特定时刻及其原因。 - **模板关系** (`templates/README.md`) — 七个可重用工件如何相互依赖，以及哪些数据必须在它们之间保持一致。 - **响应流程** (`playbook/diagram-response-flow.md`) — 贯穿所有六个手册阶段的高级流程， 包括三个真实的决策点（严重性分配、立即遏制还是持续观察、CI/CD 重建还是恢复），以及每个利益相关者通知和 指标边界（MTTD/MTTC/MTTR）在序列中的具体位置。 所有图表均使用 Mermaid 语法编写，GitHub 可以在浏览器中原生渲染 — 无需导出或安装插件。 ## 关键设计决策 有几个选择值得特别指出，因为它们是大部分实际思考过程发生的地方： - **分级严重性监控窗口**（SEV1：1 个季度，SEV2：1 个月，SEV3：1 周），其强度会**逐渐减弱**而不是保持不变 — 早期进行每日审查，逐渐减少到定期的检查点 — 这样可以使事件后监控成本保持适当比例，同时不会牺牲对延迟重新激活的覆盖。 - **CI/CD 恢复被视为其独立的严重性轴**，独立于事件整体的 Entra ID 严重性评级 — 一个标准用户账户被盗用，如果触及了一个有效的 service principal 凭据，仍然可能迫使进行完整的 CI/CD 链重建，无论是否曾经涉及任何特权目录角色。 - **一项提议的策略（在模式重复时周末自动禁用）在经验教训中被刻意留作未解决状态**，而不是直接采用，因为它与现有的遏制指导原则（在没有活跃使用证据的情况下不要禁用账户）相冲突，并且代表了一种真正的业务中断权衡，需要高管批准，而不是作为一种技术默认设置。 - **手册会自我修正。** 在开发过程中发现的两个真实缺陷 — 缺少针对特权身份被盗用的法律升级触发器，以及缺少针对 session token 窃取的 IOC 类别 — 都直接在相关章节中进行了修复，而不仅仅是单独记录下来，并且该过程现在作为预期模式记录在第 6.6 节中。 ## 引用的工具与技术 Microsoft Entra ID · Azure (Key Vault, Storage, NSGs/Firewall) · Microsoft Sentinel · Microsoft Defender for Cloud · Splunk (SPL) · EnCase · FTK Imager · Sysinternals (TCPView, Process Explorer, Autoruns, Process Monitor) · Wireshark · tcpdump · MITRE ATT&CK · 通用 CI/CD 平台 （与 Azure DevOps / GitHub Actions / Jenkins 无关） · Mermaid ## 如何使用本仓库 - **作为作品集参考：** 从 `scenario/scenario-narrative.md` 开始阅读了解故事， 然后查看 `playbook/` 了解其构建所依据的框架。 - **作为您自己环境的起点：** `playbook/` 部分和 `templates/` 的编写旨在被调整 — 替换环境假设（第 1.1 节）和工具引用以适应您自己的技术栈， 但保持结构逻辑（严重性标准驱动遏制决策，进而驱动恢复关卡）不变，因为那才是发挥真正作用的部分。 - **作为桌面推演：** `scenario/tabletop-exercise.md` 设计为可按原样运行一次，然后替换为新的场景，以便与同一团队进行重复演练。 ## 即将推出 这个仓库在功能上是完整的，但有一些项目仍在积极完善中，我们不会假装它们已经完成： | 项目 | 状态 | 目标 | |---|---|---| | Splunk SPL 查询针对实时实例的验证 | `playbook/02a-detection-queries-splunk.md` 中的查询和 `scenario/detection-alerts-savedsearches.conf.md` 中可部署的告警已经构建并且在内部是一致的，但字段名称尚未针对真实的 Splunk Add-on for Microsoft Cloud Services 部署进行验证 | 已计划 — 下个周末 | | `playbook/` 第 1–5 部分的文档修订跟踪 | 每个案件档案工件都有此功能；但手册各部分本身目前还没有 | 已计划 | | 跨事件指标日志（跟踪未来案件的 MTTD/MTTC/MTTR 趋势） | 目前不存在 — 已在第 6.3 节中标记 | 已计划 | | 添加到调查工作表 PDF 的案件结案清单 | 清单存在于第 6.7 节的文本中；尚未添加为 PDF 表单字段 | 已计划 | 为什么要明确指出这一点，而不是在发布前悄悄完成它：一个对正在进行的工作保持诚实的仓库， 比一个暗示一切都已永久确定的仓库更可信 — 特别是对于一个旨在展示真实 IR 流程成熟度的项目而言， “这是我们发现的仍需改进的地方”本身就是意义的一部分（参见第 6.5 节关于建议跟踪至闭环的内容）。 ## 许可证 本仓库的内容采用 [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/) 授权 — 可免费重用、改编，并为您自己组织的 IR 计划提供基础， 只需注明出处。（之所以选择它而不是 MIT 等代码许可证，是因为本仓库主要包含文档和模板，而不是软件 — CC BY 更适合此类内容。）

标签：Azure, Entra ID, 安全运营, 库, 应急响应, 扫描框架