khaledmedz/SOC-Alerts-Triage-Portfolio

# 案例研究 01：访问被防火墙拦截的黑名单外部 URL ## 执行摘要 - **事件定性：** 真阳性 - 良性用户活动 - **威胁等级：** 低（已完全缓解） - **Log Analytics Workspace 范围：** `SNTL-RG` / `WS1` - **摘要：** 一台内部主机（`10.20.2.17`）因尝试访问被列入黑名单的恶意短链接（`http://bit.ly/3sHkX3da12340`）而触发了高危的 Microsoft Sentinel 警报。威胁情报已验证该 URL 为恶意链接。在 Log Analytics Workspace 中的调查显示，用户在点击该链接之前，曾合法地在 Google 上搜索过“小型企业薪资设置”。该出站尝试已被防火墙成功拦截。在 Sentinel 原生表中进行的有针对性搜寻确认不存在横向移动或活跃的主机被入侵情况。 ## 工具、技术与 KQL 表 - **SIEM 平台：** Microsoft Sentinel - **日志摄取引擎：** Azure Log Analytics Workspace - **调查的表：** - `tbl061237451_CL`（摄取专有防火墙日志的自定义日志表） - `SecurityAlert`（Sentinel 警报存储表） - **KQL 操作：** 自定义日志发现、schema 审计（`getschema`）、时区偏移对齐 ## 分类与调查工作流 ### 1. Microsoft Sentinel 警报识别 本次调查是在 Microsoft Sentinel 事件队列中出现高危分析规则匹配后启动的。 - **事件 ID：** 8816 - **分析规则：** 访问被防火墙拦截的黑名单外部 URL - **源 IP：** `10.20.2.17` - **目标 IP：** `67.199.248.11`（端口 80） - **目标 URL：** `http://bit.ly/3sHkX3da12340`  ### 2. 威胁情报验证 在查询内部 Sentinel 日志之前，我使用开源威胁情报（OSINT）分析了可疑的 `bit.ly` URL。入侵指标证实该短链接已被明确标记为恶意链接。  ### 3. 日志源发现与故障排除 为了确认防火墙确实拦截了该连接，我尝试查询 Sentinel 标准的 `CommonSecurityLog` 表。由于查询界面中出现解析器/语法错误，此初始步骤失败。  为解决此问题并定位防火墙日志在 Log Analytics Workspace 中的实际摄取位置，我执行了广泛的元数据发现查询： ``` search * | where TimeGenerated > ago(24h) | summarize count() by $table ``` 查询显示，防火墙数据被定向到了一个名为 `tbl061237451_CL` 的自定义表。  为了针对此自定义表编写准确的 KQL 查询，我对其 schema 进行了审计以映射字段名称： ``` tbl061237451_CL | getschema | project ColumnName, ColumnType ```  ### 4. 遥测验证与日志关联 使用审计过的 schema 字段，我在自定义表中查询了目标主机 `10.20.2.17`。 ``` tbl061237451_CL | where SourceIP == "10.20.2.17" | project TimeGenerated, Action_s, URL_s, DestinationIP_s ``` Sentinel 查询确认： 1. 防火墙成功对恶意的出站 `bit.ly` 请求执行了 **"blocked"**（拦截）操作。 2. 就在此前片刻，对一个 Google 搜索域名发生了一次 **"allowed"**（允许）的连接。  ### 5. 时间线与上下文分析 为了解用户的意图和上下文，我检索了之前被允许的流量。 ``` tbl061237451_CL | where SourceIP == "10.20.2.17" | project TimeGenerated, Action_s, URL_s, DestinationIP_s, Rule_s ``` 遥测数据揭示了以下按时间顺序排列的事件序列： - **15:29:19（本地）：** 用户在 Google 上搜索 `how to set up payroll system for small business`。 - **15:31:41（本地）：** 两分钟后，用户点击了搜索结果中托管的恶意短链接。防火墙成功拦截并阻止了该出站流量。  ### 6. 时区校准（UTC 日志元数据与本地传感器 Payload） 在日志关联期间，我发现并解决了本地化防火墙日志 payload 与 Log Analytics 元数据后端之间的时区偏移差异。 为了证明这种偏移，我查询了原始的 `timestamp_s` 字符串（由防火墙传感器在本地记录），并将其与 Sentinel 原生的 `TimeGenerated` 日期时间字段（已标准化为 UTC）进行了比较。 ``` tbl061237451_CL | where SourceIP == "10.20.2.17" | where Action_s == "blocked" | project TimeGenerated, timestamp_s, URL_s ``` 查询返回了以下值： - **`TimeGenerated`（UTC 元数据）：** `6/12/2026, 2:29:58.031 PM` - **`timestamp_s`（本地 Payload）：** `06/12/2026 15:31:41.403` 这验证了大约 1 小时的明显时区偏移（代表本地夏令时或区域时差）。识别这一差值对于成功调整基于时间的搜寻窗口以及确保准确的跨日志时间关联至关重要。  ### 7. 范围威胁搜寻与主机历史记录 为了排除主机被入侵或横向移动的可能性，我在整个工作区内进行了有针对性的威胁搜寻。 **查询此主机上的其他短链接点击活动：** ``` tbl061237451_CL | where TimeGenerated > ago(24h) | where SourceIP == "10.20.2.17" | where URL_s contains "bit.ly" | project TimeGenerated, Action_s, URL_s ```  **查询 Sentinel 的 `SecurityAlert` 表，检查其他安全提供商（MDE、Entra ID）是否标记过此主机：** ``` SecurityAlert | where TimeGenerated > ago(7d) | where ExtendedProperties has "10.20.2.17" | project TimeGenerated, AlertName ``` 历史搜索返回了零结果，确认该主机上没有其他活跃的警报。  ## 事件定性与结案报告 - **状态：** 已关闭 - **分类：** 真阳性 - 良性用户活动 - **根本原因：** 员工的合理失误。用户在研究薪资系统时点击了恶意的搜索结果链接。 - **缓解措施：** 无需进一步缓解。企业防火墙已按设计预期拦截了该连接。未下载任何恶意 payload，且主机未显示任何被活跃入侵的迹象。

标签：Go语言工具, IP 地址批量处理, KQL, Microsoft Sentinel, Web报告查看器, 子域枚举, 安全分析与取证, 安全运营, 扫描框架