WiLL75G/soc-sigma-powershell-network-connection

# SOC 检测验证：PowerShell 发起的网络连接（Sigma 规则 1f21ec3f） 一条语法完美的 Sigma 规则却无法触发，因为它所依赖的唯一一种事件类型在终端上被静默禁用了。本次验证首先通过建立基线发现了这个可见性盲区，随后将其修复，验证了该规则在真实的下载触发器（download cradle）上成功触发，并识别出一种误报情况，完成了端到端的完整检测验证闭环。 ## 概览 | 字段 | 详情 | | --- | --- | | 工作类型 | 检测工程验证，上游贡献 | | 受测规则 | `net_connection_win_powershell_network_connection.yml` (ID 1f21ec3f) | | 主机 | JAMES-VM, Windows 11, 192.168.64.17 | | 遥测数据 | Sysmon Event ID 3 (Network Connection) | | 主要发现 | Sysmon EID 3 在基线状态下被禁用，规则无法触发 | | 次要发现 | `filter_main_msrange` 之外的合法 Azure 流量触发了误报 (FP) | | ATT&CK | T1059.001 | | 上游 | 作为 SigmaHQ issue #6056 提交 | ## 简介 这是一次检测工程验证，而非真实的应急响应事件。目的是针对真实的终端遥测数据，验证公开的 SigmaHQ 规则 `net_connection_win_powershell_network_connection.yml`（规则 ID `1f21ec3f-810d-4b0e-8045-322202e22b4b`）是否会在其声称要检测的行为上触发：由 `powershell.exe` 或 `pwsh.exe` 发起连接到远程主机的网络行为（MITRE ATT&CK T1059.001）。 在验证过程中，基线评估显示 Sysmon 的网络连接日志记录（Event ID 3）被禁用了，这意味着该规则根本不可能触发。我们修复了这个盲区，验证了传感器，随后确认该规则在良性的 PowerShell 下载触发器上成功触发。此外还发现了一个次要问题：一条合法的管理员连接也触发了该规则，因为其目标 IP 落在了规则的 `filter_main_msrange` 排除块之外。 这是上游贡献作品集中的一部分。JAMES-VM 终端及其 Sysmon 遥测数据是 `detection-engineering-labs` 和 `sentinel-soc-lab-setup` 工作背后的同一个家庭实验室主干；在这里，该实验室被用来测试 SigmaHQ 规则集本身，并作为 issue #6056 提交。 ## 执行摘要 一旦终端可见性被正确配置，该 Sigma 规则便被确认可以按设计正常运行。此次验证揭示了两个具有分析价值的发现。 首先，终端上的一个可见性盲区（网络日志记录被禁用）将会在生产环境中悄无声息地阻止检测，这进一步印证了检测规则的可靠性完全取决于底层的遥测数据。其次，该规则的 Microsoft IP 排除列表在设计上范围较窄，在列出范围之外的合法 Azure 托管流量会产生误报。规则作者明确将此记录为预期的调优工作（“需要额外的过滤器。请根据您的环境进行调整。”）。本次演练中使用的所有测试流量都是良性的；没有发生任何恶意活动。 ## 受影响系统 受测系统是一个独立的实验室终端。未涉及任何生产系统。 | 属性 | 值 | | --- | --- | | 主机名 | JAMES-VM | | 角色 | 受测实验室终端 (UTM 虚拟机) | | 操作系统 | Windows 11 | | 内网 IP | 192.168.64.17 | | 遥测来源 | Sysmon (Microsoft-Windows-Sysmon/Operational) | | 检测平台 | 针对 Sysmon Event ID 3 评估的 Sigma 规则 | ## 调查方法论 ### 步骤 1：Sysmon Event ID 3 的基线检查 首要任务是确认终端正在生成该规则所依赖的遥测数据。该规则专门依赖于 Sysmon Event ID 3 (Network Connection)，该事件会填充 `Image`、`Initiated`、`DestinationIp` 和 `User` 字段。 ``` Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" -MaxEvents 5 -FilterXPath "*[System[EventID=3]]" ``` 查询未返回任何事件。  **SOC 观察：** 缺少任何 Event ID 3 记录表明，无论发生什么活动，该规则都无法在此终端上触发。这是一个可见性盲区，在任何更改之前作为基线状态被捕获，这也是整个发现的缩影：传感器如果从未记录，规则就无法检测。 ### 步骤 2：确认 Sysmon 正在运行且日志通道存在 为了区分传感器失效和配置漏洞，我们在去掉了 Event ID 过滤器的情况下再次运行了相同的查询。 ``` Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" -MaxEvents 5 ``` 查询返回了五个事件，全部为 Event ID 4（Sysmon 服务状态更改）。  **SOC 观察：** Sysmon 正在运行且日志通道存在，但仅存在服务状态更改事件。这排除了传感器失效的可能性，并指向了配置层面的原因，这一区分决定了您是需要重新安装还是重新配置。 ### 步骤 3：检查激活的 Sysmon 配置 打印了正在运行的配置（只读，未做任何更改）以确定根本原因。 ``` sysmon -c ``` 输出确认了 `Network connection: disabled`。激活的配置文件为 `C:\Windows\System32\sysmonconfig.xml`，配置哈希为 `SHA256=DC84AB61C8AB22CF8C1038FA054D89A865C07726F9D4ADF321A1463E7171C404`。  **SOC 观察：** 根本原因已确认。全局网络连接捕获开关被禁用，覆盖了配置中存在的任何 NetworkConnect 规则。Sysmon 默认不记录 Event ID 3，因此这是一种常见的现实世界错误配置，而非实验室人为造成的问题。 ### 步骤 4：下载已知良好的社区配置 下载了 SwiftOnSecurity sysmon-config 并保存为一个新文件名，以便在验证替换成功之前保留现有配置。 ``` Invoke-WebRequest -Uri "https://raw.githubusercontent.com/SwiftOnSecurity/sysmon-config/master/sysmonconfig-export.xml" -OutFile "C:\Windows\System32\sysmonconfig-swift.xml" ```  **SOC 观察：** 刻意保留了原始配置完好无损。只有在验证了新状态之后才替换已知状态，这是标准的变更管理实践，这意味着失败的替换仍会留下一个可用的后备方案。 ### 步骤 5：验证下载的配置 在加载之前，检查了文件大小并在配置中搜索了 NetworkConnect 部分。 ``` Get-Item "C:\Windows\System32\sysmonconfig-swift.xml" | Select-Object Name, Length Select-String -Path "C:\Windows\System32\sysmonconfig-swift.xml" -Pattern "NetworkConnect" ``` 文件大小为 123,257 字节，并同时包含 include 和 exclude 的 NetworkConnect 块。  **SOC 观察：** 正常的文件大小确认了下载是完整的，而不是将错误页面另存为 XML。同时存在 include 和 exclude 的 NetworkConnect 块，确认了该配置启用了带有噪声过滤的网络日志记录。 ### 步骤 6：加载已验证的配置 新配置被应用到正在运行的 Sysmon 中。这是一次实时的热交换；无需重新安装或重启。 ``` sysmon -c "C:\Windows\System32\sysmonconfig-swift.xml" ``` 输出确认配置已成功验证并更新。  **SOC 观察：** Schema 版本通知（配置声明为 4.50，二进制文件为 4.91）是预期的向后兼容行为，并未阻止更新。 ### 步骤 7：确认盲区已修复 重新运行了步骤 3 中相同的 `sysmon -c` 命令，以确认更改已生效。 ``` sysmon -c ``` 输出现在显示 `Network connection: enabled`，并且配置哈希已更改为 `SHA256=055FEBC600E6D7448CDF3812307275912927A62B1F94D0D933B64B294BC87162`。  **SOC 观察：** 在相同命令上的前后对比，以及更改后的配置哈希，提供了配置确已被替换而非仅仅是声明的密码学确认。成功消息的截图可以伪造；但更改后的 SHA256 则不能。 ### 步骤 8：生成良性测试连接 生成了一个无害的出站连接，以确认现在将会产生 Event ID 3。 ``` Test-NetConnection -ComputerName "github.com" -Port 443 ``` 连接成功（`TcpTestSucceeded : True`）连接到了远程地址 20.87.245.0。  **SOC 观察：** 此连接由 powershell.exe 发起，它本身将成为下文次要发现的相关证据。 ### 步骤 9：确认 Event ID 3 正在记录 重新运行了步骤 1 中最初的基线查询。 ``` Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" -MaxEvents 5 -FilterXPath "*[System[EventID=3]]" ``` 查询现在返回了 Event ID 3 记录。  **SOC 观察：** 在基线时失败的相同查询现在返回了数据。重新运行完全相同的基线查询（而非一个新查询），正是这成为了盲区已修复的确凿证据。 ### 步骤 10：确认已填充所有规则必需的字段 展开了最近的 Event ID 3，以确认该规则依赖的四个字段都存在。 ``` Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" -MaxEvents 1 -FilterXPath "*[System[EventID=3]]" | Format-List ``` 事件显示 `Image` 以 `powershell.exe` 结尾，`Initiated: true`，已填充的 `DestinationIp`，以及 `User: JAMES-VM\william`。  **SOC 观察：** Sigma 规则评估的全部四个字段都已填充，确认了传感器产生的遥测数据与规则逻辑兼容。仅仅启用事件是不够的；该事件必须携带规则需要读取的字段。 ### 步骤 11：引爆 PowerShell 下载触发器 执行了一个良性的 PowerShell 下载触发器。该技术与恶意的 T1059.001 模式完全相同；只是其载荷（一个公开的 README）是无害的。 ``` (New-Object System.Net.WebClient).DownloadString("https://raw.githubusercontent.com/SwiftOnSecurity/sysmon-config/master/README.md") ``` README 内容被下载到内存中并打印到了控制台。   **SOC 观察：** 该触发器使用了 System.Net.WebClient，这是真实下载触发器所使用的同一个 .NET 类，生成了一个供规则评估的 powershell.exe 出站连接。使用真实的技术类别而不是近似值进行测试，正是让真阳性结果具有意义的原因。 ### 步骤 12：确认规则在触发器连接上触发 检索了由触发器生成的 Event ID 3，并逐字段地将其与规则逻辑进行了比对。 ``` Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" -MaxEvents 3 -FilterXPath "*[System[EventID=3]]" | Format-List ``` 触发器连接发自用户 `JAMES-VM\william`，发往 `185.199.109.133`（GitHub Pages CDN，公共地址）。  **SOC 观察：** 此事件满足了规则中的 selection，并且通过了所有排除过滤器的校验，确认了一次真阳性检测（完整分析见下文）。 ## 指示器（良性测试制品） 本次演练期间未发生任何恶意活动。以下是为了保证完整性而记录的良性测试指示器，并已明确标注。 | 指示器 | 类型 | 分类 | | --- | --- | --- | | `(New-Object System.Net.WebClient).DownloadString(...)` | PowerShell 命令 | 良性测试触发器（仅用于技术演示） | | 185.199.109.133 | 目标 IP | GitHub Pages CDN（良性；真阳性触发器） | | 20.87.245.0 | 目标 IP | Azure 托管的 GitHub endpoint（良性；误报触发器） | | powershell.exe | 进程 | 用于测试的合法 Windows 二进制文件 | ## MITRE ATT&CK 映射 | 战术 | 技术 | ID | 相关性 | | --- | --- | --- | --- | | 执行 | 命令和脚本解释器：PowerShell | T1059.001 | Sigma 规则检测的行为类别；通过良性的下载触发器复现 | ## 发现 此次验证产生了两个发现。 **发现 1，主要发现。** 该 Sigma 规则运行正确。由非 SYSTEM 用户向公共的非 Microsoft 目标发起的 PowerShell 连接满足了规则的 `selection`（`Image|endswith` powershell.exe, `Initiated: 'true'`），并且通过了所有 `filter_main_*` 排除项的校验，因此条件 `selection and not 1 of filter_main_*` 的评估结果为真，规则成功触发。发往 185.199.109.133 的触发器连接是一个被确认的真阳性值得注意的是：诸如 185.199.108.0/22 之类的 GitHub CDN 空间不应被加入白名单，因为已知攻击者会滥用 GitHub 来托管载荷。 **发现 2，次要发现。** 发往 20.87.245.0 的良性管理连接也触发了该规则。此地址由 Azure 托管，属于毗邻 Microsoft 的空间，但位于规则的 `filter_main_msrange` 块 `20.184.0.0/13`（涵盖 20.184.0.0 至 20.191.255.255）之外。该规则的 `falsepositives` 部分明确预期到了这一点，指出需要额外的过滤器，并且必须根据环境进行调整。Microsoft 通过每周的 Azure IP Ranges 和 Service Tags 文件发布权威范围，但这些范围轮换频繁，使得任何静态硬编码的列表在一段时间后都会变得脆弱。 ## 响应 由于未发生恶意活动，因此不需要进行遏制或根除。操作响应是通过启用 Sysmon 网络连接日志记录来修复终端可见性盲区，随后验证检测规则是否按预期触发。 关于 Microsoft 范围过滤器的次要发现已被记录下来，准备作为一个带有证据的问题升级给规则维护者，而不是进行单方面的更改，这考虑到了规则作者声明的设计意图。将其作为一个问题提出，体现了对成熟规则中较窄的过滤器可能是刻意为之的尊重；维护者而不是验证者，才能决定修复方案。 ## SOC 视角 这里最重要的教训是，一个检测规则只有在其底层的遥测数据可靠时才值得信赖。 该规则在语法上始终有效且逻辑合理，然而它却无法触发，因为终端悄悄地未能生成该规则所依赖的那唯一一种事件类型。在生产环境的 SOC 中，这是最危险的故障模式：一种存在于纸面上的检测，在控制台中报告为绿色，而在实践中却产生了零覆盖。没有人会收到提示说“您的警报已失效”。 首先建立基线正是能够捕捉到它的方法。针对实时遥测数据验证检测，而不是因为规则写得很好就假设它们能起作用，这正是假设覆盖与已验证覆盖之间的全部区别，也是整个验证作品集所建立的准则。 ## 学习成果 - Sysmon 默认不记录网络连接（Event ID 3）；必须启用全局网络捕获开关，否则规则无法触发。 - 基线优先的方法论在进行任何更改之前发现了可见性盲区，使得修复效果可以通过前后的配置哈希来衡量。 - 通过将捕获的每个事件字段与规则的 selection 和 filter 块进行映射比对，可以手动验证 Sigma 规则逻辑。 - 检测规则中的排除过滤器是有意设计得比较狭窄的，需要针对特定环境进行调优；在列出范围之外的合法云流量会产生误报。 - 在一个成熟的开源项目上提出检测逻辑问题的正确方式，是提出一个尊重作者设计意图且带有证据的 issue，而不是一个未经请求的逻辑更改 pull request。 ## 仓库结构 ``` soc-sigma-powershell-network-connection/ ├── README.md └── screenshots/ ├── 01_baseline_eventid3_missing.png ├── 02_baseline_only_eventid4.png ├── 03_baseline_networkconnect_disabled.png ├── 04_download_swift_config.png ├── 05_verify_swift_config_networkconnect.png ├── 06_load_swift_config.png ├── 07_verify_networkconnect_enabled.png ├── 08_generate_test_connection.png ├── 09_confirm_eventid3_logging.png ├── 10_eventid3_full_fields.png ├── 11a_detonate_download_cradle.png ├── 11b_detonate_download_cradle_output.png └── 12_eventid3_cradle_connection.png ``` ## 结论 针对实时的 Sysmon 遥测数据，端到端地验证了用于检测 PowerShell 发起的网络连接的 SigmaHQ 规则。发现并修复了一个预先存在的终端可见性盲区，经过了验证，随后确认了该规则在良性的下载触发器上能够产生真阳性检测。识别出了一个次要的误报情况，并已记录在案，准备作为带有证据的升级问题提交给维护者。本次演练演示了一个完整的检测验证工作流，该工作流建立在基线优先方法论和字段级规则分析的基础上，并进一步强调了：要证明覆盖能力，需要针对真实的遥测数据验证检测，而不是想当然地认为规则会按照编写的那样运行。

标签：AI合规, AMSI绕过, OpenCanary, Sigma规则, Sysmon, 威胁检测, 安全运营, 扫描框架, 目标导入