pranav-dagay/bots-v3-false-positive-triage

# SOC 调查：异常内部主机行为 — 误报分诊 ### Splunk BOTS v3 数据集 | Pranav Dagay ## 概述 | 字段 | 详细信息 | |---|---| | **数据集** | Splunk Boss of the SOC (BOTS) v3 | | **分析师** | Pranav Dagay | | **调查类型** | 误报分诊 | | **使用工具** | Splunk Enterprise, SPL | | **源类型** | `stream:http`, `stream:dns`, `WinEventLog:Security` | | **受调查主机** | `172.16.197.137` / `PCERF-L` | | **事件日期** | 2018-08-20 | | **严重程度** | 低 | | **处置结果** | 误报 — 无需升级 | 在对 BOTS v3 环境中的 HTTP 流量进行例行监控期间，发现多个外部目标 IP 针对敏感文件路径（包括 `/admin/` 和 `/store/catalog/payment` 端点）收到了异常的 404 响应。初步假设是某台内部主机可能正在探测外部服务器以寻找可访问的资源。 ## 调查步骤 **步骤 1 — 识别排名靠前的 HTTP 源 IP** ``` index=botsv3 earliest=0 sourcetype=stream:http | stats count by src_ip | sort -count | head 10 ``` 查询了按源 IP 分组的所有 HTTP 流量。发现 `172.16.197.137` 正在与 89 个唯一的外部目标进行通信 — 这对于标准工作站来说是异常的。 **步骤 2 — 分析可疑主机** ``` index=botsv3 earliest=0 sourcetype=stream:http src_ip=172.16.197.137 | table _time, src_ip, dest_ip, uri_path, status | sort _time ``` URI 路径包含大量编码字符串（`%2B`、`%3D`、`%2F`），并且 HTTP 206 响应表明存在来自 `/filestreamingservice/files/` 的分块文件下载。发现该主机是唯一一台与外部 IP `96.16.98.79` 通信的内部机器。 **步骤 3 — 识别唯一的外部目标** ``` index=botsv3 earliest=0 sourcetype=stream:http src_ip=172.16.197.137 | stats count by dest_ip | sort -count ``` 确认了 89 个唯一的外部目标 IP。正常的企业工作站通常会与 5-10 个外部 IP 进行通信。这个通信量是一个明显的危险信号。 **步骤 4 — 调查分块文件下载** ``` index=botsv3 earliest=0 sourcetype=stream:http src_ip=172.16.197.137 dest_ip=96.16.98.79 | table _time, uri_path, status | sort _time ``` 发现了 73 个针对 `/filestreamingservice/files/` 的 HTTP 206 部分内容响应，且包含重复的文件 GUID — 这与分块文件传输活动一致。 **步骤 5 — 提取主机的 DNS 查询** ``` index=botsv3 earliest=0 sourcetype=stream:dns src_ip=172.16.197.137 | mvexpand query{} | rename query{} as domain | stats count by domain, reply_code | sort -count | head 20 ``` DNS 查询解析为了合法的 Microsoft 服务域名，包括 `outlook.office365.com`、`login.microsoftonline.com`、`frothly-my.sharepoint.com` 和 `odc.officeapps.live.com`。 **步骤 6 — 审查端点进程创建日志** ``` index=botsv3 earliest=0 sourcetype=WinEventLog:Security host=PCERF-L EventCode=4688 | search NOT New_Process_Name="C:\\Windows\\System32\\*" | search NOT New_Process_Name="C:\\Windows\\SysWOW64\\*" | table _time, Account_Name, New_Process_Name, Process_Command_Line | sort _time ``` 主机 `PCERF-L` 上的进程创建日志仅显示了合法软件 — Google Chrome、Microsoft Office 365、Symantec Endpoint Protection、Cisco AnyConnect VPN 和 OneDrive。未发现可疑或未知的可执行文件。 ## 关键转折点 最初的 DNS 查询返回了空结果，因为 `query` 字段在 `stream:dns` 中被存储为多值字段，需要使用 `mvexpand query{}` 来提取域名。解决此问题后，DNS 证据表明该主机正在与合法的外部 Microsoft 服务域名通信 — 这将假设从可疑的出站活动转变为了合法的企业应用程序流量。 调查从纯 HTTP 分析转向了结合 `stream:http`、`stream:dns` 和 `WinEventLog:Security` 的跨源类型方法，以构建主机行为的完整图景。 ## 结论与处置 **结论：误报 — 已关闭，无需升级** 随着调查转向检查来自 `172.16.197.137` 的 DNS 流量，情况变得清晰起来：该主机正在执行常规的企业应用程序活动。DNS 证据确认该机器正在解析合法的 Microsoft 服务域名，并且主机 `PCERF-L` 上的进程创建日志 (Event ID 4688) 仅显示了合法的软件操作。 这 89 个外部目标 IP 和大量编码的 URI 路径与 **Office 365 和 Chrome 遥测流量** 一致，作为正常操作的一部分，它们自然会使用编码参数联系许多端点。在 HTTP、DNS 或端点遥测中均未发现恶意指标。 ## 分析师备注 孤立地查看 HTTP 流量使得情况看起来高度可疑 — 89 个外部目标、编码的 URI 以及分块文件下载，这些在单独出现时通常都与恶意行为有关。然而，与 DNS 流量和端点进程日志的交叉比对揭示了合法的企业应用程序行为，这证明了 **不应孤立地使用单一源类型来得出结论。** 在今后涉及异常出站 HTTP 流量的调查中，应将 DNS 关联分析和端点进程审查作为升级前的标准步骤。`stream:http` + `stream:dns` + `WinEventLog:Security` 的组合提供了仅靠 HTTP 无法呈现的完整图景。 ## 演示的关键 SPL 技术 | 技术 | 目的 | |---|---| | `stats count by src_ip \| sort -count` | 识别最活跃的通信方 | | `mvexpand query{}` | 展开多值 DNS 字段 | | `bucket _time span=1h \| stats count by _time` | 时间线分析 | | `search NOT New_Process_Name="C:\\Windows\\*"` | 过滤已知良好进程 | | `stats count by dest_ip` | 映射外部通信范围 | | 跨源类型追踪 | 关联 HTTP + DNS + 端点数据 | ## 工具与环境 - **Splunk Enterprise 10.2.1** (本地安装) - **数据集：** Splunk BOTS v3 (~2.08M 事件, 107 个源类型) - **使用的源类型：** `stream:http`, `stream:dns`, `WinEventLog:Security` - **调查时长：** ~60 分钟 *我的 SOC 作品集的一部分 — [github.com/pranav-dagay](https://github.com/pranav-dagay)*

标签：DNS日志分析, DNS 解析, False Positive Triage, HTTP日志分析, SOC调查, Splunk BOTS v3, Splunk Enterprise, SPL查询, Web流量监控, Windows终端日志, 事件研判, 子域名变形, 安全运营中心, 异常内部主机行为, 数据关联分析, 日志分析与取证, 网络安全, 网络映射, 误报判定, 跨数据源分析, 隐私保护