Purple-Team-Automation

对 detection-as-code-repo 中构建的 Sigma 检测规则进行自动化紫队验证，使用 MITRE Caldera 对现有域实验环境执行一条链式 Active Directory 凭据访问攻击路径，并使用 ATT&CK Navigator 热力图可视化覆盖情况。

为什么选择 Caldera 而非 Atomic Red Team

本项目选择 Caldera 而非 Atomic Red Team，是因为它提供了完整的 C2 框架，包含 agent、对手配置文件以及链式多步操作，而非单一、孤立的技术执行。这更贴合本项目的目标：不仅仅是“这一项技术是否被检测到”，而是“一条真实的、有序的攻击链能否从头到尾在我们的现有检测栈下存活”。

仓库结构

Purple-Team-Automation/
├── abilities/                          自定义 Caldera ability YAML 文件
├── adversary-profiles/                 操作中使用的链式对手配置文件
├── validation/                         每项技术的 Kibana 证据 + LLMNR 已知缺口说明
├── attack-navigator-heatmap.json       ATT&CK Navigator 图层，在 mitre-attack.github.io/attack-navigator 加载
├── purple-team-automation-report.md    完整报告：范围、方法论、结果、缺口分析
└── README.md                           本文件

构建内容

基础设施

我通过 Docker Compose 在独立的 Ubuntu 虚拟机（caldera-server，192.168.18.205）上部署了专用的 Caldera 服务器，该虚拟机与现有 AD 域实验环境位于同一实验网络，同时与 ELK/SIEM 栈保持隔离。Caldera v5.0.0 启动后开箱即带有 2000 个内置 ability 和 29 个内置对手。

我在过程中定位到的构建问题：

• 我最初的构建看似完成，但实际上静默地没有生成任何镜像，因此我不得不进行干净重建。
• 容器因缺少预构建的 Vue 前端（plugins/magma/dist/assets/）而崩溃循环。我追踪到原因是 docker-compose.yml 中的整目录 Docker 卷挂载用未编译的主机源码覆盖了镜像中已编译的前端。通过移除整目录挂载修复。
• 我尝试在容器运行时重建前端，但失败了，因为 Dockerfile 在镜像构建后有意卸载了 npm/nodejs，以保持最终镜像精简。
• 在我终于让登录正常工作后，UI 仍然无法使用。编译后的前端将 localhost:8888 硬编码为其 API 基地址，这是在 Vue 构建时通过 plugins/magma/.env（VITE_CALDERA_URL）写入的，不受 conf/local.yml 运行时 app.frontend.api_base_url 设置控制。我通过编辑 .env 为虚拟机的真实 IP 并重建来修复。
• 我还遇到了另一个磁盘空间故障，追踪到原因是某个 LVM 逻辑卷只使用了虚拟机分配磁盘的一半。通过 lvextend -l +100%FREE + resize2fs 修复，并通过 docker system prune -a --volumes 回收构建缓存层。

自定义 ability

Stockpile 仅自带一个基于 LSASS/Mimikatz 的凭据转储原生 ability（T1003.001）。本项目所需的四项技术——Kerberoasting、AS-REP Roasting、Password Spraying 和 DCSync——都需要自定义 ability，我围绕 Impacket（GetUserSPNs.py、GetNPUsers.py、secretsdump.py）和 Kerbrute 构建了这些 ability，因为 Stockpile 现有的 Kerberoasting ability（Rubeus、WinPwn）仅适用于 Windows/.NET，与本实验环境中基于 Linux 的 Sandcat agent 不兼容。

在编写这些 ability 时，我遇到了两个构建问题：

• Caldera v5 的真实 ability schema 使用为每种工具专门构建的解析器模块（例如 plugins.stockpile.app.parsers.katz），带有 source/edge/target 字段，而不是我最初假设的通用正则 pattern 解析器。这导致加载时出现静默的 TypeError('ParserConfig.__init__()')。由于不存在用于原始 Impacket 输出的内置解析器，我从全部四个 ability 中完全移除了 parsers: 块。结果以原始输出/哈希文件形式捕获，并针对 Kibana 手动验证（见 /validation）。
• 我的两个 ability YAML 文件（password spray、DCSync）最初在 nano 粘贴静默失败后被保存为 0 字节文件。我在重启容器前通过用 cat/wc -l 对每个文件进行完整性检查发现了这一点。

Agent 部署

我在 Kali 虚拟机（192.168.18.70）上部署了一个 Sandcat agent（Linux，组 red），使用进程名 splunkd 进行 OPSEC 伪装，并确认其启动后处于存活且受信任状态，以 root 身份运行，使用 proc/sh 执行器。

对手配置文件与操作

我构建了 AD Credential Access Chain 对手配置文件，按照机会主义内部攻击者通常会尝试的顺序，将四个自定义 ability 串联起来：

    → Password Spray (Kerbrute)
    → Kerberoasting (GetUserSPNs.py)
    → AS-REP Roasting (GetNPUsers.py)
    → DCSync (secretsdump.py)

LLMNR/NBT-NS 投毒（T1557.001）被有意排除在 Caldera 配置文件之外。原因以及它为何仍作为已知缺口阴性对照纳入，请参见 validation/llmnr-known-gap.md。

结果

所有四项已执行的技术均确认被 detection-as-code-repo 的 Sigma 规则检测到，并直接在 Kibana 中交叉核对。LLMNR/NBT-NS 投毒仍是一个未解决的、已记录的缺口。

完整详情：validation/detection-results.md 完整报告：purple-team-automation-report.md 交互式热力图：attack-navigator-heatmap.json

后续步骤

1. 修复 Sysmon 配置（启用 Event ID 3 和 22）以关闭 LLMNR 缺口。
2. 为 LLMNR/NBT-NS 投毒编写并调优新的 Sigma 规则。
3. 重新运行此操作以确认修复并更新热力图。
4. 纳入更广泛的 SOC 项目路线图（Project D 及后续）。