mattcaballero11/home-soc-lab

# 家庭 SOC 实验室：Microsoft Sentinel 中的实时检测流水线 我在工作中构建检测内容，但几乎所有内容都无法公开展示。它们属于客户。因此，我没有试图将一个真实项目脱敏到安全级别，而是选择在自己的 Azure 租户中从头开始重建了整个流程，并记录了整个过程。 这就是那个实验室。它使用一台 Windows 机器，将其日志发送到 Microsoft Sentinel，对其运行我自己的检测规则，触发真实的安全事件，然后将这些事件交给自动化的 playbook 进行丰富处理。上面还有一个仪表板将所有内容整合在一起。所有这些都运行在使用虚假攻击的临时 VM 上，因此这里没有任何客户数据。 简而言之：我独立完成了端到端的完整检测工程闭环，并记录了每一个出错的环节。这些记录实际上是此仓库中最有用的部分。 ## 运行效果 ``` flowchart LR A[Atomic Red Team + safe simulations
Windows VM] --> B[Sysmon Operational Log] B --> C[Azure Monitor Agent] C --> D[Data Collection Rule] D --> E[Log Analytics Workspace
Event table] E --> F[Microsoft Sentinel] F --> G[Scheduled KQL Analytics Rules] G --> H[Alerts + Incidents] H --> I[Automation Rule] I --> J[Logic Apps SOAR Playbook] J --> K[Incident Comment + SOAR-Enriched Label] H --> L[Sentinel Workbook Dashboard] ``` ## 技术栈 - Windows Server 2022 VM，生成日志的设备 - Sysmon，用于获取实际的遥测数据 - Azure Monitor Agent 加上 Data Collection Rule 来传输日志 - Log Analytics 作为存储 - Microsoft Sentinel 用于分析规则、事件和自动化 - Atomic Red Team 用于安全的、映射到 ATT&CK 的测试攻击 - Azure Logic Apps 作为 SOAR playbook - Sentinel Workbook 作为仪表板 ## 搭建 Azure 环境且避免意外账单 我要做的第一件事就是把所有资源放到一个资源组 `rg-home-soc-lab` 中，这样最后我就可以一次性删除所有内容。然后我为 Log Analytics 设置了较低的上限并设置了预算警报，因为 Sentinel 会根据你摄入的数据量收费，我不想用昂贵的代价去了解这一点。只要我不主动使用，VM 就会被停止并解除分配。  我始终坚持的一个规则很简单：证据是截图，而不是永远运行的实验室。捕获证明，然后将其关闭。 ## 获取 Windows 机器并从 Kali 登录 我选择 Windows Server 2022 是因为我需要 Sysmon、Windows 事件日志、PowerShell 和 Windows Atomic 测试。小型可突发性能 VM、标准 SSD、尽可能将 RDP 限制在我自己的 IP，并开启自动关闭。没什么花哨的。 我通过 RDP 从我的 Kali 机器连接： ``` xfreerdp3 /v::3389 /u:azureuser /d:. /cert:ignore /dynamic-resolution +clipboard ```  这部分让我折腾了一番。重启后公共 IP 发生了变化，所以我不得不再次去检查它。接着是 NSG 规则，然后是端口可达性，再然后是登录时的域名格式。有一次我干脆重置了 VM 密码以排除其干扰。这都不难，只是你第一次连接时通常会经历的“为什么连不上”检查清单。 ## 安装 Sysmon 并验证其是否正常工作 Sysmon 能将一台普通的 Windows 机器转变为值得监控的设备。我从 Sysinternals 获取了它并使用自定义配置进行了安装，然后在信任任何数据之前，确认服务已启动并且事件已在本地生成。 ``` Get-Service Sysmon64 Get-WinEvent -ListLog "Microsoft-Windows-Sysmon/Operational" ```  有一件让我吃亏并且值得一提的事：使用新配置运行 `Sysmon64.exe -c` 会**替换**当前的活动配置。有一次我开启了一个广泛的故障排除配置，应用它时悄悄地清除我的注册表和网络过滤器。所以教训是，每次更改后都要重新检查配置，因为 Sysmon 不会警告你刚刚关闭了一半的可见性。 ## 将日志导入 Sentinel 本地事件很好，但它们需要到达 Log Analytics 才能发挥作用。这就需要 Azure Monitor Agent 和 Data Collection Rule。我将 DCR 指向 Sysmon 操作日志，并选择了我真正关心的事件 ID： ``` Microsoft-Windows-Sysmon/Operational!*[System[(EventID=1 or EventID=3 or EventID=11 or EventID=12 or EventID=13 or EventID=14 or EventID=22)]] ``` 然后我等待心跳信号，确认代理健康，并看着 Sysmon 数据开始出现在 `Event` 表中。  Sysmon 字段包含在 `EventData` 中，因此此仓库中的每个查询都会解析它，并在需要时回退到 `RenderedDescription`。当某个字段第一次无法顺利解析时，这种回退机制不止一次拯救了我。 ## 使用 Atomic Red Team 进行安全攻击 要测试检测，你需要有东西可检测。我使用了 Atomic Red Team，它是一个小型测试库，每个测试都映射到一项 ATT&CK 技术。它可以生成逼真的、看似攻击的活动，而无需任何真实的恶意软件，这正是你在将要截图并发布的实验室中所需要的。 安装过程遇到了一些小磕碰。我找到的旧安装程序 URL 已失效（404），所以我不得不寻找当前的脚本。接着 Defender 阻止了 atomics 的解压，因此我添加了一个狭窄的文件夹排除项，而不是关闭 Defender，因为在安全实验室中关闭你的 AV 是一种糟糕的做法，也是个更坏的习惯。而且该模块只加载到当前的 PowerShell 会话中，所以重启后我必须重新加载它才能正常工作。 我重点关注的技术： - T1059.001, PowerShell - T1003.001, LSASS Memory - T1547.001, Registry Run Keys - T1053.005, Scheduled Task - T1047, WMI ## 编写检测规则 我在 Sentinel 中编写了五条计划分析规则，每项技术一条。它们都从 `Event` 表读取数据，解析出 Sysmon 字段，标记 ATT&CK 技术，并投射出清晰的字段，以便分析师能够真正看懂警报。 | 规则 | ATT&CK | 遥测数据 | |---|---|---| | LAB - Suspicious PowerShell Execution | T1059.001 / T1105 | Sysmon Event ID 1 | | LAB - LSASS Dump Attempt | T1003.001 | Sysmon Event ID 1 | | LAB - Registry Run Key Persistence | T1547.001 | Event IDs 12/13/14 | | LAB - Scheduled Task Creation | T1053.005 | Event ID 1 | | LAB - WMI Process Execution | T1047 | Event ID 1 | 规则文件位于 [`detections/sentinel/`](detections/sentinel/)。每条规则每 5 分钟运行一次，回溯 30 分钟，并在命中时创建事件。  在这里我要坦诚说明一个调优问题，因为它在稍后的仪表板中也会显现出来：以 5 分钟的频率对 30 分钟的数据进行回溯意味着同一活动会被反复匹配，因此一次测试攻击可能会引发多个警报和事件。对于证明流水线有效来说这没问题（这正是本实验室的目的），但在真实环境中，你会通过警报分组或抑制来修复它。我将其保留下来并记录在案，而不是将其隐藏。 ## 实战测试规则 这是我最关心的部分：看着攻击从一端输入，事件从另一端输出。以下是每一次的运行情况。 **PowerShell。** 我选择的 Atomic 测试（T1059.001，测试 16）需要一个不可用的辅助函数，因此它在框架内失败了。框架本身没问题，只是该测试缺少一个依赖项。我替换为了一个等效的安全模拟操作，它执行了与规则所查找内容相同的操作： ``` $payload = 'Write-Output "LAB-EncodedPowerShell-Test"' $encoded = [Convert]::ToBase64String([Text.Encoding]::Unicode.GetBytes($payload)) powershell.exe -NoProfile -EncodedCommand $encoded ``` 这产生了遥测数据、一次检测命中和一个事件。   **注册表 Run Key。** atomic 运行良好，但我的查询一开始返回为空。结果发现是两个问题叠加在一起：我在类似于路径的注册表值上使用了 `has_any`，而我本应该使用 `contains`；并且我当时的活动 Sysmon 配置可能根本没有捕获注册表事件。我切换到了 `contains`，同时解析了 `EventData` 和 `RenderedDescription`，在本地确认了事件，检查了 DCR 是否涵盖了 ID 12/13/14，并重新应用了 Sysmon 中的注册表过滤器。之后它就触发了。 **计划任务和 WMI。** 这两个表现正常。活动产生了进程遥测，并且每一个都在 Sentinel 中引发了事件。 **LSASS。** 这个需要明确的免责声明。我**没有**转储凭据。我运行了一个非破坏性的命令行模拟，它只是打印出真实转储会使用的那种命令，这样规则就有东西可以匹配，而无需触及实际的内存： ``` cmd.exe /c echo procdump64.exe -ma lsass.exe C:\Windows\Temp\lsass.dmp ``` 这是一个安全的回显，而不是内存转储，我希望这一点显而易见。规则仍然捕获到了该模式并引发了事件。  一旦全部五个测试运行完毕，我就可以在一个地方看到全套的 LAB 警报和事件。  ## 使用 SOAR playbook 自动化响应 检测只是工作的一半。在真实的 SOC 中，必须有东西对事件采取行动，因此我构建了一个名为 `pb-lab-incident-enrichment` 的 Logic App。一个自动化规则会监视标题以 `LAB -` 开头的事件，当一个事件出现时，它就会运行该 playbook。该 playbook 会向事件添加一个甄别评论，并用 `SOAR-Enriched` 标签对其进行标记。 这就是我遇到整个项目中最喜欢的 bug 的地方。评论操作一直失败并出现授权错误： ``` Microsoft.SecurityInsights/incidents/comments/write AuthorizationFailed / Forbidden ``` 我分配了 Sentinel Responder 角色，但我错误地在 VM 范围内分配了它。这无法授权在 Sentinel 工作区内进行写入操作。一旦我启用了系统分配的托管标识，在工作区/资源组范围分配了 Responder，并等待 RBAC 更改传播生效，它就通过了。   输出确认标签已应用： ``` { "labelName": "SOAR-Enriched", "labelType": "User" } ``` ## 仪表板 最后一块是一个名为 `Home SOC Lab - Detection Dashboard` 的 Sentinel Workbook，用于将所有内容整合在一起：随时间变化的 Sysmon 事件、事件 ID 细分、LAB 警报和事件、严重性和状态、按 ATT&CK 技术分组的警报、最近的可疑命令行以及经过 SOAR 丰富处理的事件。Workbook 查询位于 [`workbooks/`](workbooks/) 中。  关于这个仪表板上的数字，我要坦诚说明两点，因为它们很容易被误读： - 巨大的 Event ID 11 计数（在我的运行中约为 831）是**原始的文件创建遥测**，而不是攻击。Windows、PowerShell 和 Atomic 安装都会创建大量临时文件，而且我的历史配置捕获了 `\Temp\` 下的所有内容。它仅仅是日志量，仅此而已。 ``` SecurityIncident | where TimeGenerated > ago(7d) | where Title startswith "LAB -" | summarize arg_max(LastModifiedTime, *) by IncidentNumber | summarize UniqueIncidents=count() by Severity, Status ``` 我宁愿解释这些数字，也不愿让它们看起来比实际更令人印象深刻。 ## 我弄错的地方以及下一步会调优的内容 - Sysmon 配置更改会替换整个活动配置。每次更改后都要重新验证。 - 在匹配路径片段时，注册表值需要使用 `contains`，而不是 `has_any`。 - DCR 和 Sysmon 配置都必须涵盖你需要的事件 ID。在其中任何一个地方漏掉，数据就永远不会出现。 - 5 分钟 / 30 分钟的计划会产生重复的警报。下一版本将加入警报分组和抑制。 - 广泛的 `\Temp\` 文件创建捕获会产生大量噪音。在 [`sysmon/`](sysmon/) 中经过调优的配置只保留了重要的路径。 - 第一次就要在正确的范围内分配 RBAC。是工作区，而不是 VM。 ## 想自己构建吗 完整的分步说明位于 [`docs/setup-guide.md`](docs/setup-guide.md)，支持文档涵盖了[数据收集](docs/data-collection.md)、[分析规则](docs/sentinel-analytics-rules.md)、[测试方法](docs/detection-testing-methodology.md)和[成本控制](docs/cost-control.md)。你需要的一切都是免费的，或者可以在 Azure 试用版上运行，只要你保持设置每日上限并在完成后删除资源组即可。 ## 关于费用和清理的说明 该项目运行在一个带有每日上限和预算警报的一次性资源组上，并且只要我不使用它，VM 就会保持解除分配状态。在本地保存了所有截图、查询和配置之后，我删除了整个资源组，这样它就不再产生任何费用。清理清单位于 [`cleanup/delete-lab.md`](cleanup/delete-lab.md) 中。 ## 免责声明 本项目使用一次性的实验室 VM、我自己编写的检测内容、公开的 ATT&CK 映射、Atomic Red Team 测试以及安全模拟。它不包含任何客户数据、专有检测内容、生产遥测或机密工作产物。LSASS 测试是非破坏性的命令行模拟，而不是真实的内存转储。 ## 关于 由 **Matthew Caballero** 构建，他是一名从事检测工程和进攻性安全工作的网络安全顾问（拥有 PNPT，正在考取 CPTS 和 BSCP）。 在这里找到我：[LinkedIn](https://www.linkedin.com/in/matthewgcaballero/) · [验证我的证书](https://www.credly.com/users/matthew-caballero.9d29c5b1)

标签：AI合规, KQL, Microsoft Sentinel, SOAR, Sysmon, 安全运营中心, 网络映射