LerinOG/ir-tabletop-exercise

# 事件响应桌面演练 — 账户被攻陷后的升级 ## 概述 这是一次模拟响应不断升级的被攻陷事件的桌面演练，作为 [AD + SIEM Detection Lab](https://github.com/LerinOG/ad-siem-detection-lab) 项目的直接延续。该场景从该项目的检测结束之处开始：密码喷洒攻击成功，并且 `test.user1` 现已被攻陷。本次演练记录了所遵循的事件响应剧本，并逐步讲解了 SOC 分析师在事件展开时所面临的决策点。 ## 场景背景 在 Detection Lab 项目中检测到密码喷洒攻击的三天后，被攻陷的 `test.user1` 账户再次被使用——这一次不是在一台外部主机上快速失败并成功，而是正常登录，混入合法流量中。攻击者利用此访问权限进行横向移动、建立持久性，并试图访问敏感文件共享。 ## 事件响应剧本 本剧本遵循 NIST SP 800-61 事件响应生命周期。 ### 1. 准备 - **已部署检测工具：** 在加入域的 endpoint 上配置了带有 Sysmon 的 Wazuh SIEM（来自 Detection Lab 项目） - **已知良好的基线：** 提前记录了正常的登录模式、已知的 service account 以及预期的计划任务 - **上报联系人：** IT 安全负责人、系统管理员（在真实组织中：如果怀疑数据泄露，则需联系法务/合规部门） - **隔离能力：** 能够禁用 AD 账户并将主机从网络中隔离（防火墙规则 / 禁用交换机端口） ### 2. 识别 **注入 1：** Wazuh 生成警报：`test.user1` 在其正常工作模式之外（当地时间凌晨 2:47 的一个星期六），从一个以前未与该账户关联的内部 IP 登录到 SRV01。 **分析师操作：** - 提取整个环境（不仅仅是 SRV01）中 `test.user1` 最近的全部活动——检查 DC01 以及任何其他加入域的系统 - 检查此 IP 是否对应于已知设备（工作站清单）或无法识别 - 交叉比对：此账户是否是之前密码喷洒事件中被标记为被攻陷的三个账户之一？（是的——`test.user1` 是被确认攻陷的三个账户之一） **决策点：** 由于该账户有记录在案的先前攻陷记录，因此应将此登录视为疑似攻击者持续活动，而不是误报，即使登录本身是正常成功的（这次没有失败的尝试——攻击者已经拥有有效的凭证）。 ### 3. 遏制 **注入 2：** 登录 40 分钟后，Wazuh/Sysmon 日志显示在 SRV01 上创建了一个新的计划任务（Sysmon Event ID 1 — 通过 `schtasks.exe` 创建进程），配置为在每次系统启动时运行脚本——这是一种经典的持久性机制。 **分析师操作（短期遏制）：** - 立即禁用 `test.user1` AD 账户，以切断对被攻陷凭证的进一步使用 - 将 SRV01 从网络中隔离（或限制为仅限安全团队访问），以阻止来自该主机的任何进一步横向移动或数据外发 - **不要**立即删除计划任务或重启机器——首先保留它以进行取证审查 **决策点：** 权衡业务影响（SRV01 承载着业务使用的 IIS 和文件共享）与持续被攻陷的风险。在本场景中，鉴于已确认存在恶意的持久性——这是意图的明确指标，而不仅仅是异常的登录行为——隔离是合理的。 ### 4. 根除 **注入 3：** 调查确认，计划任务被配置为运行一个 PowerShell 脚本，该脚本试图访问文件共享（`\\SRV01\Finance$`）并将文件存放在临时目录中——这与勒索软件攻击前/数据外发前的暂存行为一致，尽管在遏制之前并未发生实际的加密或外发。 **分析师操作：** - 删除恶意计划任务和任何已暂存的文件 - （再次）重置 `test.user1` 密码，并审查该账户是应永久禁用并重新配置，而不是被重用 - 检查 SRV01 以及 `test.user1` 访问过的任何系统上是否存在任何其他持久性机制（额外的计划任务、新服务、注册表 Run 键） - 审查攻击者是否创建了任何新账户或修改了组成员身份（权限提升检查） ### 5. 恢复 - 仅在确认没有剩余的持久性机制后，才将 SRV01 恢复为完全网络访问状态 - 在事件发生后密切监控 `test.user1`（或其替代账户）和 SRV01 1-2 周，查看是否有任何复发 - 确认 Finance 共享的文件完整性——根据可用日志，没有文件被修改或外发，但这应该明确验证，而不是假设 ### 6. 经验教训 - **奏效之处：** 之前的密码喷洒检测意味着 `test.user1` 已经是一个已知的风险账户——这缩短了将新登录正确归类为可疑而非良性所需的时间，尽管它具有有效的凭证和看似正常的成功登录。 - **发现的差距：** 使用有效的、先前被攻陷的凭证进行成功登录本身不会产生高严重性警报，除非与先前的事件历史进行交叉比对。**建议：** 维护一个涉及先前事件的账户“监控名单”，并配置 Wazuh 在初始攻陷后的规定监控期（例如 30 天）内，以更高的严重性级别标记来自这些账户的任何活动。 - **发现的差距：** 仅靠密码重置（针对原始事件）是不够的——攻击者在几天后仍保留访问权限，这意味着要么重置没有完全使现有的会话/token 失效，要么凭证被再次重用/猜测到。**建议：** 在任何确认的账户被攻陷事件后，强制使所有会话失效并要求重新注册 MFA，而不仅仅是重置密码。 - **奏效之处：** Sysmon 的进程创建日志（Event ID 1）近乎实时地捕获了计划任务的创建，在攻击者采取下一步行动之前为遏制工作赢得了先机。 ## 文件 - `README.md` — 本文档（剧本 + 演练过程） ## 展示的技能 事件响应规划（NIST SP 800-61）、桌面演练引导、遏制/根除/恢复决策制定、持久性机制分析、事件后经验教训文档编写，以及将检测工程与响应流程相连接。

标签：Active Directory, Plaso, Terraform 安全, 子域枚举, 安全运营, 库, 应急响应, 扫描框架