shank078/Splunk-SOC-Detection-Lab

# 🔎 Splunk SOC 检测实验室 — 暴力破解攻击关联 ### *摄入 28,963 条事件。4 个攻击者 IP 分布在 3 个国家。一个账户被锁定。执行了完整的 IR。*

## ⚡ TL;DR — 关键指标 | 指标 | 结果 | |--------|--------| | **摄入事件数** | 28,963+ Windows 安全事件 | | **隔离的攻击者 IP** | 分布在 3 个国家的 4 个独立 IP | | **构建的攻击关联** | EventID 4625 (登录失败) → 4740 (账户锁定) | | **事件响应 (IR)** | 通过 Azure RunCommand 紧急解锁账户 | | **MITRE 技术** | T1110 暴力破解 · T1078 有效账户 | | **平台** | Splunk Enterprise — 自托管于 Azure (Windows Server 2022) | ## 📖 项目简介 本实验室模拟了真实的 SOC 分析师工作流程 — 从在 Azure 上部署独立的 Splunk Enterprise 基础设施，到检测并关联针对暴露在互联网上的 Windows Server 2022 主机的活跃暴力破解攻击。 与托管的 SIEM 部署不同，本实验室需要动手进行基础设施管理：在 Windows Server 上原生安装 Splunk、配置本地日志摄入、从头编写 SPL 检测查询，以及在攻击者成功锁定管理员账户时执行实时事件响应。 ## 🏗️ 架构 ``` graph TD A["🌍 Real Attackers\nIndia · Panama · Europe · France"] -->|RDP Brute Force\nPort 3389| B["SPLUNK-SRV-01\nWindows Server 2022\nAzure — Australia East"] B -->|WinEventLog:Security\nEventID 4625 + 4740| C["Splunk Enterprise\nlocalhost:8000\nindex=main"] C -->|SPL Detection Queries| D["🔍 SOC Analysis\nAttacker Profiling\nCorrelation Timeline"] D -->|Account Locked Out| E["🚨 Incident Response\nAzure RunCommand\nOut-of-Band Recovery"] ``` ## 🛠️ 技术栈 | 组件 | 技术 | 详情 | |-----------|-----------|--------| | **SIEM** | Splunk Enterprise v10.4.0 | 自托管于 Windows Server 2022 | | **云平台** | Microsoft Azure | 澳大利亚东部区域 | | **日志源** | WinEventLog:Security | 原生 Windows 安全事件日志 | | **关键 Event ID** | 4625, 4740, 4688 | 登录失败、锁定、进程创建 | | **查询语言** | SPL (Splunk Processing Language) | 自定义检测查询 | | **IR 工具** | Azure RunCommand | 带外 PowerShell 执行 | | **MITRE ATT&CK** | T1110, T1078 | 暴力破解、有效账户 | ## 🚀 构建阶段 ### 阶段 1 — 基础设施部署 在 **Azure 澳大利亚东部**部署 Windows Server 2022 VM 作为实验环境。建立了到 `SPLUNK-SRV-01` 的 RDP 访问，以便进行手动配置。   ### 阶段 2 — Splunk Enterprise 设置 下载 Splunk Enterprise v10.4.0 并将其原生安装在 Windows Server 上 — 而非云托管实例。拥有完整的基础设施控制权：安装、服务配置、端口管理以及在 `localhost:8000` 上的 Web UI 访问。   ### 阶段 3 — 数据摄入 配置 Splunk 使用原生 `WinEventLog:Security` 源类型实时摄入**本地 Windows 安全事件日志**。在将 VM 暴露于 RDP 流量后，在观察窗口内摄入了 **28,963+ 条事件**。 ``` [WinEventLog://Security] index = main disabled = false ```   ### 阶段 4 — 检测工程 #### 基准验证 (攻击前) 初始检测查询返回**零结果** — 证实了在暴露 RDP 之前没有任何暴力破解活动。此基准至关重要：它证明了检测是基于真实活动触发的，而非噪声。  #### 检测 1 — 按源 IP 进行暴力破解 `MITRE: T1110.001` ``` index=main sourcetype="WinEventLog:Security" EventCode=4625 | stats count by Source_Network_Address, Account_Name, ComputerName | sort - count | rename count as "Failed_Login_Attempts" ``` **结果：** 在 3 个国家/地区识别出 4 个独立的攻击者 IP。 | 源 IP | 国家/地区 | 失败尝试次数 | 目标账户 | |-----------|---------|-----------------|-------------------| | `163.47.70.77` | 🇮🇳 印度 | 16 | SPLUNKVM, admin email | | `190.2.155.233` | 🇵🇦 巴拿马 | 12 | SPLUNKVM | | `195.242.214.36` | 🇪🇺 欧洲 | 4 | SPLUNKVM | | `86.254.114.246` | 🇫🇷 法国 | 2 | Test |  #### 检测 2 — 暴力破解 → 账户锁定生命周期 `MITRE: T1110 → T1078` 将 EventID 4625 (登录失败) 与 EventID 4740 (账户被锁定) 进行关联，重构了完整的攻击链 — 从首次尝试到成功锁定。 ``` index=main sourcetype="WinEventLog:Security" (EventCode=4625 OR EventCode=4740) | eval Status=if(EventCode==4625, "Failed Login", "Account Locked") | table _time, Status, Account_Name, Source_Network_Address, ComputerName | sort - _time ``` **结果：** 18 条关联事件。`SPLUNK-SRV-01$` 被锁定的准确时刻在时间线中清晰可见 — 攻击成功了。  ### 阶段 5 — 实时事件响应 攻击不仅仅是触发了警报 — 它成功了。管理员账户被锁定，阻止了对机器的合法访问。 **问题：** 标准的密码重置需要登录。而攻击者的锁定破坏了这一途径。 **解决方案：** Azure **RunCommand** — 一个完全绕过 OS 登录界面的带外 PowerShell 执行通道，在 Azure 架构层运行。 ``` net user SPLUNKVM [REDACTED_NEW_PASSWORD] ```  ## 🧠 关键发现与经验教训 ### 1. 攻击成功了 — 而这正是关键所在 大多数实验室展示的都是在模拟数据上触发检测，实际上并没有破坏任何东西。在本实验中，攻击者锁定了管理员账户。这种失败使得 IR 阶段变得真实 — 带外恢复在这里不是理论概念，而是真实记录的执行过程。 ### 2. 跨平台字段映射 — SPL vs KQL Windows 安全事件字段在 Splunk 和 Microsoft Sentinel 中使用不同的名称。在两个平台上编写检测需要精确了解这些映射 — 这是一项真正的工程技能，而不是简单的复制粘贴操作。 | 字段概念 | Splunk SPL | Microsoft Sentinel KQL | |--------------|-----------|----------------------| | 源 IP 地址 | `Source_Network_Address` | `IpAddress` | | 目标账户名称 | `Account_Name` | `TargetUserName` | | 事件代码 | `EventCode` | `EventID` | | 时间戳 | `_time` | `TimeGenerated` | | 计算机名称 | `ComputerName` | `Computer` | ### 3. 自托管 SIEM = 真正的基础设施所有权 与 Sentinel (完全托管的 SaaS) 不同，Splunk Enterprise 需要：VM 配置、Splunk 安装、服务配置、端口管理、index 创建以及日常维护。这更接近于运行本地或混合 Splunk 部署的企业 SOC 团队实际管理的内容。 ## 🔮 后续计划 - [ ] 通过 Splunk lookups 集成 **AbuseIPDB / VirusTotal** 威胁情报源 — 使用已知的恶意信誉评分丰富攻击者 IP 表 - [ ] 构建**实时 SOC 仪表板** — 在地理位置上映射攻击者 IP，按 EventCode 跟踪事件速度 - [ ] 配置 **Splunk Alert Actions** — 在突破阈值时自动将恶意 IP 推送到 Azure NSG 拒绝列表 - [ ] 在所有摄入的 EventID 中添加完整的 **MITRE ATT&CK 映射** - [ ] **🤖 试点 AI 驱动的分类** — 使用 **IBM watsonx Orchestrate** 自主分类警报严重性，并在路由到 SOC 队列之前丰富攻击者档案 ## 📁 仓库结构 ``` splunk-soc-detection-lab/ ├── spl-queries/ │ ├── 01-brute-force-by-source-ip.spl │ └── 02-attack-lifecycle-correlation.spl ├── configs/ │ └── inputs.conf ├── docs/ │ └── lessons-learned.md ├── screenshots/ │ ├── 01_azure_vm_deployment_success.png │ ├── 02_rdp_server_manager_access.png │ ├── 03_splunk_enterprise_installation.png │ ├── 04_splunk_web_dashboard_login.png │ ├── 05_winventlog_data_input_configured.png │ ├── 06_winventlog_ingestion_verification.png │ ├── 07_baseline_detection_no_attacks.png │ ├── 08_bruteforce_detection_top_attackers.png │ ├── 09_attack_lifecycle_correlation_timeline.png │ └── 10_incident_response_account_unlock.png └── README.md ``` ## 🔗 相关项目 | 项目 | 描述 | |---------|-------------| | [双 SIEM 检测实验室](https://github.com/shank078/Dual-SIEM-Detection-Lab) | 在 KQL 和 SPL 中重建相同的检测 — 在实时流量上实现跨平台一致性 | | [Azure Sentinel 蜜罐 SIEM](https://github.com/shank078/azure-sentinel-honeypot-siem) | 捕获并全球映射了 1,400+ 次真实的暴力破解尝试 | | [SOAR Pipeline — Sentinel 到 Jira](https://github.com/shank078/azure-sentinel-jira-soar-pipeline) | 零接触的自动化事件工单生成 | ## 👤 关于作者 **Shankar Baral** — 初级网络安全分析师与 IT 支持专家 信息技术硕士 (网络安全) · GPA 4.92 · 澳大利亚永久居民 · 堪培拉, ACT [](https://linkedin.com/in/shankarbaral1) [](https://github.com/shank078) [](mailto:shankarbaral1@gmail.com) *寻求澳大利亚的初级 SOC 分析师和安全工程师机会。*

标签：FOFA, Splunk SPL, Windows Server, 安全运营中心, 库, 应急响应, 红队行动, 网络映射