Jahny-Robles/Hybrid-Three-Pillar-SOC-Detection-Lab

# jahnylabs — 三支柱混合 SOC 检测实验室 **由 Jahny Robles 构建并编写文档** · 检测工程 · SIEM · EDR · 威胁检测 ## 摘要 (TL;DR) 我从零开始构建了一个完整的攻防实验室：一个在 pfSense 分段网络上的隔离 Active Directory 域、一台攻击者工作站，以及**同时在同一组 endpoint 上运行的三套检测栈**。我从 Kali 执行对手技术，然后在所有三个平台上对其进行追踪和检测——比较各自捕获了什么、遗漏了什么以及原因。 **旗舰练习 —— 场景 C（凭证访问）—— 已完成并经过端到端验证。** 其他场景正在滚动添加中（参见[状态](#status)）。 ## 三支柱架构 核心理念：同时从三种不同的检测理念监控同一组 endpoint，然后进行正面比较。 | 支柱 | 平台 | 检测理念 | 托管 | |---|---|---|---| | **1 — SIEM（自托管）** | Elastic Security | 通过 Elastic Agent 获取日志 + endpoint 遥测 | Oracle Cloud（自我管理） | | **2 — EDR** | Microsoft Defender for Endpoint P2 | 行为 endpoint 检测，自动事件关联 | Microsoft 365 租户 | | **3 — SIEM（云）** | Microsoft Sentinel | 基于 Windows Security 事件的 KQL 追踪 | Azure（通过 Arc + AMA + DCR） | 

拓扑的文本视图

``` ┌─────────────────────────────────────────────┐ │ DETECTION PLANE (3 pillars) │ │ │ │ Elastic SIEM MDE P2 (EDR) Sentinel │ │ (Oracle Cloud) (M365 tenant) (Azure) │ └───────▲──────────────▲──────────────▲────────┘ │ │ │ telemetry EDR sensor Security events │ │ (Arc+AMA+DCR) ┌──────────────────────┴──────────────┴──────────────┴─────────┐ │ ISOLATED LAB NETWORK (VMware, VMnet2, 192.168.10.0/24) │ │ │ │ pfSense GW ── Win Server 2022 DC ── Win10 victim ── Kali │ │ (firewall) (Active Directory) (monitored) (attacker)│ └──────────────────────────────────────────────────────────────┘ ```

对以下任何术语不熟悉？请参阅 [**术语表**](GLOSSARY.md)。 ## 实战检测工程 每次攻击都从 Kali 攻击机发起，随后在所有三个支柱中进行检测和记录。检测映射到 **MITRE ATT&CK**，并构建为一个可重复的循环： **攻击 → 检测（×3 平台） → 提取 artifact → 编写检测规则 → 重新测试 → 记录文档** ### 场景路线图 场景 C 已完成；其余场景是本仓库未来发展的计划构建内容。 | # | 场景 | 示例技术 | MITRE | 状态 | |---|---|---|---|---| | A | 侦察 (Reconnaissance) | 端口扫描、RDP 暴力破解、SMB 枚举 | T1595, T1110 | 计划中 | | B | 执行与持久化 (Execution & Persistence) | 编码的 PowerShell、计划任务、Run Keys | T1059, T1053, T1547 | 计划中 | | **C** | **凭证访问 (Credential Access)** | **LSASS 转储、Kerberoasting** | **T1003.001, T1558.003** | ✅ **已完成 + 已验证** | | D | 横向移动 (Lateral Movement) | Pass-the-Hash、DCSync、Golden Ticket | T1550, T1003.006, T1558.001 | 计划中 | | E | 数据外泄 (Exfiltration) | DNS 隧道、数据暂存 | T1048, T1560 | 计划中 | ### 检测工程亮点：AV vs. EDR vs. SIEM（场景 C） 这是一个分为两部分的凭证访问练习，展示了三类控制机制如何看待同一个攻击者。这两种技术都没有释放恶意文件，因此基于签名的 AV 对两者视而不见——真正的比较在于 EDR 与 SIEM 之间。 **第 2 部分 —— Kerberoasting (T1558.003)。** 从 Kali 为一个可被 Roast 的服务账户请求了 RC4 服务票据。攻击成功且 DC 记录了事件 4769 —— **但 Sentinel 什么也没看到。** 域控制器从未被接入 SIEM，因此遥测数据从未送达。我诊断了该缺口，将 DC 接入（Azure Arc + AMA + DCR），并**编写了一条用于检测 RC4 请求的 KQL 分析规则，并基于实时攻击遥测进行了端到端验证。** 这正是 EDR 失效的地方——没有 endpoint 行为可捕获——而 SIEM 证明了其价值，但前提是必须有正确的日志源在传输数据。 **核心要点：** 签名 AV 对两者都视而不见；EDR 掌控着 endpoint 上的攻击，却遗漏了 DC 端的攻击；SIEM 的情况则正好相反。纵深防御不是冗余——每一层都覆盖不同的攻击面。而且，检测的效果取决于为其提供的遥测数据：覆盖率缺口*本身就是*工作难点，而不是编写 KQL。 → 完整的说明、结果表格和检测规则：[`scenarios/scenario-c.md`](scenarios/scenario-c.md) → 经过验证的规则本身：[`detections/sentinel-kql/scenario-c-kerberoast.kql`](detections/sentinel-kql/scenario-c-kerberoast.kql) ## 我所构建的内容（展示的技能） **基础设施与网络** - 设计并隔离了一个由 pfSense 防火墙/网关分段的实验网络 - 搭建了一个 Windows Server 2022 **Active Directory** 域（DNS、NTP 权威服务器、加入域的 endpoint） - 部署了一台具有静态寻址和网络故障排除功能的 Kali 攻击者工作站 **云与 SIEM** - 在 Oracle Cloud 上自托管了 **Elastic Security**（Elasticsearch、Kibana、Fleet）——完整技术栈，而非托管层级 - 搭建了 **Microsoft Sentinel**，采用 Azure Arc 混合接入、Azure Monitor Agent 和 Data Collection Rules - 在独立的 M365 租户中接入了 **Microsoft Defender for Endpoint P2**；验证了传感器健康状况、高级追踪和事件关联 **检测与分析** - 在 Sentinel 中针对实时攻击遥测（Kerberoasting、4769 RC4）编写并**验证了 KQL 分析规则** - 诊断并修复了**检测覆盖率缺口**（DC 遥测数据无法到达 SIEM） - 确认了在 LSASS 凭证转储尝试中 **MDE 的行为阻止**和防篡改保护 (Tamper Protection) - 将检测映射到 **MITRE ATT&CK**，并生成了跨支柱检测比较（[场景 C 说明](scenarios/scenario-c.md)） **运营成熟度** - 解决了真实的故障：agent IPv6 连接、被静默丢弃的数据收集规则关联、跨租户集成限制 - 编写了一份包含决策树的故障排除 **runbook**，使问题能够被可重复地修复（[AMA/Arc 恢复](runbooks/ama-arc-snapshot-revert-recovery.md)） - 实施了冷快照基线 + 恢复后验证清单 ## 构建之旅（真实问题，真实修复） 这个实验室并非一帆风顺——而这正是关键所在。以下是我诊断并解决的一些生产级问题： - **Sentinel 摄取静默停止。** 遥测数据流动了几天，然后中断了。Agent 健康，网络正常，IPv6 也已处理过——但 Azure Data Collection Rule 静默丢失了其机器关联（很可能是在快照周期内发生的）。通过发现 DCR `Resources` 选项卡显示关联机器数为零诊断出该问题，重新进行关联，通过干净重启强制拉取 agent 配置，并确认摄取已恢复。将其记录为带有决策树的可重用 runbook，以将其与外观相似的 IPv6 故障模式区分开来。 - **Agent 连接故障 (IPv6)。** Endpoint agent 无法发送数据，因为它优先选择隔离网络无法提供服务的 IPv6 路由通往云端 endpoint。通过 agent 自带的诊断工具识别出问题，在适配器和注册表级别禁用了 IPv6，并验证了 IPv4 回退。 - **跨租户 EDR + SIEM。** MDE 和 Sentinel 最终位于不同的租户中。我没有强制使用脆弱且部分不受支持的跨租户数据桥，而是做出了深思熟虑的架构决策，将它们作为独立的支柱运行——这把一个限制变成了更强大的多平台比较案例。 - **检测覆盖率缺口（场景 C）。** 成功的 Kerberoast 对 Sentinel 是不可见的，因为域控制器从未被接入。接入 DC（Arc + AMA + DCR），编写检测规则，并针对实时攻击遥测进行了验证——这是实验室中最清晰的一课：*检测覆盖必须跟随遥测生成的位置。* ## SOC 技能 → 职位相关性 专门构建以映射到 Tier 1/2 SOC 分析师工作和 **SC-200（Microsoft Security Operations Analyst）** 考试领域： | SOC 能力 | 在本实验中的体现 | |---|---| | SIEM 操作与 KQL 追踪 | Sentinel 分析规则，编写 + 验证 | | EDR 告警分流与事件分析 | MDE 事件图 + 进程树（LSASS 阻止） | | 编写检测规则 | KQL 分析规则（场景 C），基于实时遥测验证 | | 威胁检测与 MITRE 映射 | T1003.001 + T1558.003，跨支柱比较 | | Active Directory 攻击意识 | Kerberoasting 检测（DCSync / Golden Ticket 已列入路线图） | | 日志源与遥测管理 | Arc/AMA/DCR pipeline，覆盖率缺口修复，Elastic Fleet | | 文档与 runbook | 本仓库 + AMA/Arc 恢复 runbook | ## 仓库内容 ``` Hybrid-Three-Pillar-SOC-Detection-Lab/ ├── README.md ← overview (you are here) ├── GLOSSARY.md ← IT/security terms reference ✅ ├── .gitignore ← secret-exclusion safety net ✅ ├── architecture/ │ └── lab-diagram.png ← 4-VM + 3-pillar diagram ✅ ├── scenarios/ │ └── scenario-c.md ← Credential Access (full writeup) ✅ ├── detections/ │ ├── sentinel-kql/ │ │ └── scenario-c-kerberoast.kql ← validated Kerberoast detection ✅ │ ├── elastic-eql/ ← EQL detections [roadmap] │ └── sigma/ ← portable Sigma rules [roadmap] ├── runbooks/ │ └── ama-arc-snapshot-revert-recovery.md ← AMA / Arc recovery ✅ └── soc-reports/ ← per-scenario analyst reports [roadmap] ``` ## 状态 🟢 **基础设施完成** — 所有三个支柱均已上线并正在摄取数据。 🟢 **场景 C（凭证访问）完成** — LSASS 转储 + Kerberoasting，已跨支柱检测并验证；说明和检测规则已发布。 🔨 **进行中** — 剩余场景（A、B、D、E）、各场景的 SOC 报告以及可移植的 Sigma/EQL 检测。 ## 联系方式 **Jahny Robles** — [LinkedIn](https://www.linkedin.com/in/jahny-robles-5a6851418/) 欢迎交流检测工程、SOC 分析和蓝队工作。 *实验室环境使用隔离的、不可路由的地址。出于操作安全的考虑，本公共仓库已刻意排除了所有凭证、租户标识符和基础设施机密。*

标签：Terraform 安全