ronscorner/ai-powered-purple-team-detection-platform

# AI 驱动的紫队检测平台 一个基于 Elastic 和 KQL 的平台，用于运行受控的 MITRE ATT&CK 验证、收集遥测数据，并通过 AI 辅助生成可解释的检测规则。 本代码仓库包含了 [frontend/](frontend/) 中的完整应用程序代码库以及 [docs/](docs/) 中的支持文档。 ## 项目概述 该项目将紫队攻击执行与 Elastic 遥测分析以及 AI 辅助检测工程连接在一起。当前的实现以经过授权的 Windows 实验室环境为中心，在其中通过 Kali 控制节点执行 Red Canary Atomic Red Team 测试，将遥测数据发送到 Elasticsearch 并在 Kibana 中进行审查，然后应用程序根据产生的证据生成符合 ECS 标准的 KQL。 当前支持： - 通过 Evil-WinRM 使用 Red Canary Atomic Red Team 执行 Windows 目标攻击 - Elastic 和 Kibana 遥测数据审查 - 符合 MITRE ATT&CK 标准的 KQL 生成 - AI 辅助的日志解释和检测指导 ## 功能列表 - 通过 Web UI 进行 MITRE ATT&CK 技术和 Red Canary Atomic Red Team 测试选择 - 通过 Kali 控制 VM 路由的远程执行工作流 - 通过 PowerShell 和 `Invoke-AtomicTest` 执行 Windows 攻击 - 从 Elasticsearch 获取 Elastic 遥测数据 - 使用 ECS 风格字段生成对 Kibana 友好的 KQL - AI 辅助的分析师解释和验证指导 - 为可重复的紫队操作设计的检测工作流 ## 架构图 ``` flowchart LR A["User UI"] --> B["Backend API"] B --> C["Kali Control VM"] C --> D["Evil-WinRM"] D --> E["Windows Target"] E --> F["Red Canary Atomic Red Team / Invoke-AtomicTest"] F --> G["Windows Telemetry"] G --> H["Winlogbeat"] H --> I["Elasticsearch"] I --> J["Kibana"] I --> K["Log Analysis in UI"] B --> L["AI-Assisted Detection Generation"] K --> L L --> M["Elastic KQL Output"] ``` ## 后端工作流 后端工作流旨在将执行、遥测数据收集和 AI 推理分离开来但又相互连接： 1. 用户在 UI 中选择一项 MITRE ATT&CK 技术和一个 Red Canary Atomic Red Team 测试。 2. 应用程序在 Next.js 服务器层中调用后端 API 路由。 3. 后端通过 SSH 连接到 Kali 控制 VM。 4. Kali 启动 `evil-winrm` 以连接到 Windows 目标。 5. Windows 目标通过 `Invoke-AtomicTest` 运行针对所选技术的 Red Canary Atomic Red Team 测试。 6. Windows 遥测数据由原生日志和可选的 Sysmon 生成。 7. Winlogbeat 将遥测数据发送到 Elasticsearch。 8. 应用程序查询 Elasticsearch 以获取与执行相关的遥测数据。 9. AI 辅助检测层基于 MITRE 上下文和检索到的信号生成并解释 KQL。 10. UI 展示遥测数据、分析师指导和可重用的 KQL。 ## 后端架构 核心后端职责： - `GET /api/atomic-tests` - 发现或缓存可通过已配置的远程执行路径使用的 Red Canary Atomic Red Team 测试 - `POST /api/run-attack` - 通过 Kali 到 Windows 的工作流启动选定的 Red Canary Atomic Red Team 测试 - `GET /api/logs` - 从 Elasticsearch 检索与执行相关的遥测数据 - `POST /api/detection` - 使用 MITRE 上下文、观察到的遥测数据和确定性验证构建 Elastic KQL - `POST /api/assistant` - 用对分析师友好的语言解释遥测数据、检测和攻击行为 详细的架构说明位于 [docs/backend-architecture.md](docs/backend-architecture.md)。 ## MITRE 攻击执行概述 当前的攻击执行模型为： ``` User selects MITRE ATT&CK technique -> User selects Red Canary Atomic Red Team test -> Backend API launches execution -> SSH to Kali control VM -> Kali runs evil-winrm -> Windows PowerShell session starts -> Invoke-AtomicTest executes -> Windows telemetry is generated -> Winlogbeat ships telemetry to Elasticsearch -> UI queries Elastic and generates KQL ``` 这使得执行模型对于紫队验证而言明确且可重现。 ## Kali 控制 VM Kali 控制 VM 充当应用程序后端和 Windows 目标之间的操作桥梁。 主要职责： - 接收来自后端的 SSH 命令 - 运行 `evil-winrm` - 运行诸如 `curl` 和 `nmap` 等验证工具 - 托管辅助脚本或用于受控执行的编排包装器 Kali 节点还可以与通用的 AI 控制的 SSH 工作流集成，包括 Agent 风格的执行模式和基于 MCP 的 SSH 控制。 ## Evil-WinRM 工作流 当前的 Windows 执行路径依赖于 Evil-WinRM： ``` Backend API -> SSH to Kali -> evil-winrm -> Windows PowerShell -> Invoke-AtomicTest ``` 这允许项目将 Kali 视为操作控制机，同时将攻击执行保留在目标系统上。 ## Atomic Red Team 执行 Red Canary Atomic Red Team 提供用于 ATT&CK 验证的技术级测试内容。 在当前的实现中： - 用户选择一项技术和测试 - 后端触发 `Invoke-AtomicTest` - Windows 目标运行相关的 PowerShell 驱动的测试 - 生成的遥测数据成为 Elastic 审查和 KQL 生成的基础 ## Elasticsearch 和 Kibana 遥测数据流 遥测数据流： ``` Windows logs / Sysmon -> Winlogbeat -> Elasticsearch -> Kibana for manual validation -> Application log retrieval and analysis ``` Elasticsearch 是用于遥测数据检索的核心记录系统。Kibana 是配套的分析师交互界面，用于手动验证、字段检查和查询测试。 ## AI 辅助检测生成 检测层使用 AI 将 ATT&CK 上下文和观察到的遥测数据转化为可重用的 Elastic 检测。 AI 生成的目标是产生： - KQL，而非特定于供应商的 pipeline 语法 - 符合 ECS 标准的字段用法，例如 `process.name`、`process.command_line`、`host.name`、`source.ip` 和 `destination.ip` - 简明的面向分析师的解释，说明查询要查找的内容 ## 为什么 AI 助手很重要 该助手旨在帮助分析师更快地从 ATT&CK 技术选择过渡到有用的检测内容，而无需取代分析师的判断。 实际好处： - 用清晰且面向分析师的语言解释可疑行为 - 突出显示与所选技术或测试最相关的遥测数据 - 帮助将执行证据与符合 ECS 标准的字段联系起来 - 将观察到的行为转化为可供审查和完善的 KQL 草稿 - 支持迭代式的检测工程，而非一次性的查询生成 其目标是在攻击验证、遥测审查和可用检测逻辑之间缩短时间，同时保持分析师对最终查询的控制权。 ## AI 验证 Pipeline AI 辅助验证 pipeline 旨在优化相关性，而不是取代分析师的审查： 1. 应用程序从 Elasticsearch 检索遥测数据。 2. 信号被标准化，以便用于下游推理。 3. AI 帮助识别与所选 ATT&CK 行为最相关的日志。 4. 检测层根据这些信号生成或改进 KQL。 5. UI 展示遥测上下文和生成的 KQL，供分析师审查。 ## 截图 仪表板概览：  MITRE ATT&CK 矩阵和 Atomic Red Team 覆盖范围视图：  计划未来添加的内容： - 远程执行控制台截图 - Elastic 遥测数据审查截图 - 生成的 KQL 和助手指导截图 ## 设置概述 高级设置流程： 1. 准备一个 Kali 控制 VM、一个 Windows 目标 VM 和一个 Elastic/Kibana VM。 2. 将所有系统置于同一个隔离的实验室网络中。 3. 配置到 Kali 的 SSH 访问。 4. 在 Windows 上启用 WinRM。 5. 在 Windows 上安装 Red Canary Atomic Red Team、Winlogbeat 和可选的 Sysmon。 6. 将 Winlogbeat 指向 Elasticsearch。 7. 配置应用程序环境变量。 8. 从 `frontend/` 启动应用程序。 实验室设置的详细信息位于 [docs/lab-setup.md](docs/lab-setup.md)。 ## 路线图 - 扩展文档和截图以供公共 GitHub 使用 - 提高实验室部署的可重复性 - 添加更丰富的 Kibana 验证示例 - 添加检测内容导出和共享工作流 - 扩展对更多 ATT&CK 执行路径的支持 ## Linux 支持路线图 当前版本尚未实现 Linux 执行。 未来的工作应添加： - `LINUX_TARGET_IP` - `LINUX_TARGET_USER` - `LINUX_TARGET_SSH_KEY` 或基于密码的身份验证 - 用于 Linux 执行的后端路由 - 一个攻击路由器，用于选择： - Windows 技术 -> Evil-WinRM - Linux 技术 -> SSH - Linux 遥测数据收集，通过： - `auditd` - Sysmon for Linux - Elastic Agent 或 Filebeat ## 环境变量 常见的公共配置变量： - `KALI_SSH_HOST` - `KALI_SSH_USER` - `KALI_SSH_KEY_PATH` - `WINDOWS_TARGET_IP` - `WINDOWS_TARGET_USER` - `WINDOWS_TARGET_PASSWORD` - `ELASTICSEARCH_URL` - `ELASTICSEARCH_USERNAME` - `ELASTICSEARCH_PASSWORD` - `ELASTICSEARCH_API_KEY` - `KIBANA_URL` - `OPENAI_API_KEY` 当前应用程序还支持面向桥接的名称，例如： - `EXECUTION_BRIDGE_HOST` - `EXECUTION_BRIDGE_USER` - `WINRM_TARGET_HOST` - `WINRM_TARGET_USER` - `WINRM_TARGET_PASSWORD` - `ATOMIC_RED_TEAM_MODULE_PATH` 有关初始模板，请参见 [.env.example](.env.example)。 ## 贡献 欢迎做出贡献，尤其是在以下领域： - 文档改进 - Elastic/KQL 检测内容 - 实验室自动化和设置的可重复性 - 遥测数据丰富和验证 - Linux 支持的规划和实现 在做出贡献时： 1. 开启一个 Issue 或讨论以描述更改。 2. 保持执行逻辑更改的范围清晰并进行记录。 3. 优先使用环境驱动的配置，而不是硬编码的基础设施细节。 4. 保留项目以 Elastic 和 KQL 为核心的方向。 ## 安全免责声明 本项目仅适用于已授权的实验室环境、紫队验证和检测工程研究。请勿对您不拥有或未获得明确测试权限的系统运行攻击模拟。

标签：AI合规, Atomic Red Team, Cloudflare, Conpot, ECS, Elasticsearch, Evil-WinRM, IPv6, IP 地址批量处理, KQL, MITM代理, MITRE ATT&CK, OpenCanary, Petitpotam, PowerShell, Terraform, TGT, Windows安全, Winlogbeat, 人工智能, 内存分配, 子域名变形, 安全检测工程, 安全运营, 扫描框架, 攻防演练, 数据泄露检测, 无线安全, 检测规则生成, 用户模式Hook绕过, 紫队, 网络安全, 网络安全审计, 自动化攻击, 越狱测试, 远程执行, 隐私保护