karcibald/azure-sentinel-soc-lab
GitHub: karcibald/azure-sentinel-soc-lab
该项目利用 Microsoft Sentinel 搭建云原生 SOC 实验环境，完整演示了从 Linux syslog 日志采集、暴力破解检测、OSINT 情报富化到威胁情报 Watchlist 部署的企业级安全运营流程。
Stars: 0 | Forks: 0
# azure-sentinel-soc-lab
云原生 SIEM 工程项目，利用 Microsoft Sentinel 采集 Linux syslog 遥测数据，映射持续暴力破解的基础设施，并部署主动威胁情报 watchlist。
# 云 SIEM 工程：Microsoft Sentinel 中的端到端威胁检测与基础设施映射
## 📑 执行摘要
本项目演示了利用 **Microsoft Sentinel (SIEM)** 部署企业级云安全运营中心 (SOC) 框架的过程。主要目标包括：暴露一个易受攻击的面向公众的 Linux 资产 (`vm1`)，通过 **Kusto Query Language (KQL)** 分析实时的恶意请求采集指标，利用开源威胁情报 (OSINT) 丰富本地化告警，通过全球 BGP 路由拓扑映射对手基础设施，以及构建自定义 watchlist 以最小化企业风险。
## 🏗️ 架构框架与技能栈
* **云基础设施：** Microsoft Azure（Virtual Machines、Network Security Groups、Log Analytics Workspaces）
* **SIEM 分析：** Microsoft Sentinel
* **查询与脚本语言：** Kusto Query Language (KQL)、PowerShell (Raw TCP Network Sockets)
* **核心领域：** 开源情报 (OSINT)、边界网关协议 (BGP) 拓扑、数字取证与事件响应 (DFIR)、防御性架构 (Whitelisting/Hardening)
## 🛠️ 分阶段技术演练
### 阶段 1：环境配置与日志采集流水线
* 配置了一台未经安全加固的 Linux 虚拟机 (`vm1`)，通过开放的 **SSH (Port 22)** 配置将其暴露于公共互联网，作为真实的蜜罐。
* 建立了 Azure Log Analytics Workspace (`soc-log-workspace`) 并接入了 **Microsoft Sentinel**。
* 配置了原生安全日志转发策略，将操作系统级别的身份验证和访问日志直接流式传输到集中的 SIEM 数据存储中。
*
### 阶段 2：威胁模拟（受控基线）
为了验证采集的运行健康状况并建立经过验证的基线，使用原始的 Windows PowerShell 网络套接字从管理工作站本地执行了一次对抗性模拟：
```
New-Object System.Net.Sockets.TcpClient("YOUR_VM_IP", 22)
This simulated attack bypassed application layer errors to guarantee that a transport-layer cryptographic handshake was successfully cataloged inside the sshd daemon logging tables.
### Phase 3: Live Incident Triage 与 KQL 分析
Within minutes of activation, automated global botnets initiated brute-force credential-stuffing campaigns against vm1. Custom KQL correlation analytics were built to parse and map the traffic spikes:
Code snippet
Syslog
| where ProcessName == "sshd"
| where SyslogMessage has "Failed password" or SyslogMessage has "invalid user"
| extend AttackingIP = extract(@"from ([0-9.]+)", 1, SyslogMessage)
| summarize AttemptCount = count() by AttackingIP, Computer
| top 10 by AttemptCount
High-Severity Incidents were automatically triggered within Sentinel as external nodes concurrently hammered system accounts (root, admin).
### Phase 4: OSINT 丰富与 BGP 路由深度剖析
Pivoting on a highly active attacking entity signature (195.178.110.217), external Open Source Intelligence (OSINT) tools were introduced to reconstruct the threat actor's profile:
AbuseIPDB Lookup: Confirmed a 100% Abuse Confidence Score with thousands of historical global abuse records, resolving to a hosting center in Amsterdam, Netherlands.
Hurricane Electric BGP Toolkit: Escalated the triage to network infrastructure routing layers. Discovered that the target IP lies within the 195.178.110.0/24 subnet managed under Autonomous System Number AS48090.
Operational Insight: While geolocated to Andorra by internal SIEM maps and Amsterdam by active proxies, the regional registry allocation (RIPE NCC) traced back to Bulgaria (BG) under a United Kingdom ASN registration. This layout highlights classic adversary proxy/VPS chaining used to obfuscate operational origins.
Phase 5: Operationalizing Threat Intelligence via Sentinel Watchlists
To optimize analytical detection over static, processing-heavy query logic, a custom threat intelligence Watchlist (KnownMaliciousHostingIPs) was engineered into the SIEM database.
By parsing incoming streams dynamically against the watchlist array using structured sub-second relational lookups, high-fidelity security alerts were achieved:
Code snippet
let MaliciousThreatIntel = _GetWatchlist('KnownMaliciousHostingIPs') | project IpAddress;
Syslog
| where ProcessName == "sshd"
| extend AttackingIP = extract(@"from ([0-9.]+)", 1, SyslogMessage)
| where AttackingIP in (MaliciousThreatIntel)
| project TimeGenerated, Computer, AttackingIP, SyslogMessage
Phase 6: Perimeter Containment & Remediation
Following data collection, incident response remediation protocols were deployed:
Navigated to the cloud fabric boundary at the Azure Network Security Group (NSG) level.
Reconfigured the perimeter rule for Port 22 from Any to IP Addresses, explicitly whitelisting only the administrator's trusted public workstation.
Effectively dropped all unauthorized global scanner probes at the cloud edge before reaching the internal OS platform layer.
📈 Analytical Conclusion & Strategic Takeaways
Automated Exploitation Scale: Threat actors programmatically harvest internet-facing subnets within minutes of creation; perimeter defense-in-depth is mandatory.
Telemetry Optimization: Leveraging native tools like Sentinel Watchlists cuts down CPU overhead during multi-gigabyte log cross-correlations.
The Analyst Mindset: True threat detection requires moving beyond a simple IP alert; pivoting to subnets, ASNs, and BGP peering networks reveals the true scale of adversarial operations.
---
### 🖼️ 推荐的 Image Mapping 顺序
To match the high quality of your write-up, upload your screenshots into an `images` directory in the repository and embed them into the Markdown text using the following format:
1. **Initial Shell Failures/Validation:** Reference `image_499d06.png` or your working PowerShell TCP handshake to demonstrate the initial validation phase.
2. **The Sentinel Incident Board:** Embed `image_4a09c6.png` or `image_f9c07e.png` to display active incident lists.
3. **The Investigation Panel:** Use `image_fa3823.png` to document the visual alert spike timeline.
4. **OSINT Verification:** Place `image_fa432a.png` (AbuseIPDB 100% rating) to highlight the threat classification phase.
5. **BGP/Network Topology:** Embed `image_faa583.png` or `image_faa8e2.png` to highlight structural network footprinting capabilities.
6. **Watchlist Validation:** Conclude with `image_fabbc9.png` to show the successful live KQL execution against your custom threat-intel matrix.
Name your files clearly (e.g., `sentinel-triage.png`, `bgp-routing.png`) so your repository looks
```
标签：AI合规, Azure, KQL, Microsoft Sentinel, PB级数据处理, PE 加载器, 威胁情报, 安全运维, 开发者工具