sofiaboiko/sentinel-threat-detection

GitHub: sofiaboiko/sentinel-threat-detection

一个基于 Microsoft Sentinel 的网络杀伤链端到端检测工程项目,通过模拟完整攻击链验证自定义 KQL 分析规则的设计与调优。

Stars: 0 | Forks: 0

# 使用 Microsoft Sentinel 进行网络杀伤链检测 ![Python](https://img.shields.io/badge/Python-3.10%2B-3776AB?logo=python&logoColor=white) ![Flask](https://img.shields.io/badge/Flask-3.0-000000?logo=flask&logoColor=white) ![Azure](https://img.shields.io/badge/Azure-Monitor-0078D4?logo=microsoftazure&logoColor=white) ![Sentinel](https://img.shields.io/badge/Microsoft-Sentinel-0078D4?logo=microsoft&logoColor=white) ![Defender](https://img.shields.io/badge/Microsoft-Defender-0078D4?logo=microsoft&logoColor=white) ![KQL](https://img.shields.io/badge/KQL-Detection%20Engineering-F25022) ![Windows](https://img.shields.io/badge/Windows-11-0078D4?logo=windows&logoColor=white) 一个实践性的 SOC 作品集项目,展示了网络杀伤链全部六个阶段的端到端威胁检测——从侦察到数据外泄——使用故意留下漏洞的 Flask Web 应用程序作为目标,并以 Microsoft Sentinel 作为检测平台。 ## 概述 | | | |---|---| | **目标** | `flask-lab/` — Contoso 内部运营门户(故意留下漏洞的 Flask 应用) | | **攻击者工具** | `attack-simulation/scripts/` — payload、C2 监听器、持久化脚本 | | **检测平台** | Microsoft Sentinel + Log Analytics Workspace(`soc-lab-law`,西欧) | | **日志转发** | 在通过 Azure Arc 连接的 Windows 11 主机上运行的 Azure Monitor Agent (AMA) | | **分析规则** | 5 个计划的 KQL 规则,均已确认会生成事件 | | **MITRE ATT&CK 覆盖范围** | T1595.002, T1190, T1105, T1203, T1059.006, T1053.005, T1071.001, T1005, T1041 | ## 杀伤链覆盖范围 | # | 阶段 | 模拟的内容 | 检测 | |---|---|---|---| | 1 | **侦察** | 手动使用 curl 进行路径枚举(约 12 条路径,全为 404) | `recon_rule.kql` — 来自单一 IP 的 404 爆发 | | 2 | **漏洞利用 — 上传** | 将 `malicious_report.py` 及其伴随文件上传至 `/upload`(无扩展名验证) | `upload_rule.kql` — 在通用上传端点出现可执行扩展名 | | 3 | **漏洞利用 — 执行** | `POST /reports/generate` 触发了服务端的 `python.exe` → `whoami.exe`/`HOSTNAME.EXE` | `execution_rule.kql` — 将 `report_generated`(应用日志)与进程创建事件(Windows Event 表,EID 1)进行关联 | | 4 | **安装 / 持久化** | Windows 计划任务 `ContosoLabDemoBeacon`(每 10 分钟一次) | 无专用规则 — 任务创建属于操作系统级事件(EID 4698),在此实验中未被捕获。该任务的*输出*(周期性的 beacon 启动)由 `beacon_rule.kql` 检测。 | | 5 | **命令与控制** | `beacon.py` 以精确的 10 分钟间隔触发了 25 次以上 | `beacon_rule.kql` — 25 次启动的 StdevGapSeconds = 0 | | 6 | **目标达成** | `config.py` + `contoso_users.db` 被外泄至本地 C2 监听器 | `kill_chain_correlation.kql` — 所有阶段在同一个事件中关联至 `127.0.0.1` | 所有阶段均已通过 `attack-simulation/screenshots/` 和 `sentinel/screenshots/` 中的截图确认。 ## 仓库结构 ``` sentinel-threat-detection/ ├── flask-lab/ # Target application │ ├── app.py # Flask app with intentional vulnerabilities │ ├── config.py # Fake secrets (exfiltration target) │ ├── logging_config.py # JSON-per-line structured logging │ ├── requirements.txt │ ├── templates/ # Jinja2 HTML templates │ ├── static/css/ │ ├── logs/ # application-events.jsonl (ingested by AMA) │ └── storage/ │ ├── downloads/ # Pre-seeded demo documents │ ├── uploads/ # Files landed via /upload (attack artifacts) │ └── generated/ # Output of /reports/generate + fake user DB │ ├── attack-simulation/ │ ├── reconnaissance.md # Stage 1 — path enumeration commands │ ├── upload.md # Stage 2 — file upload exploitation │ ├── execution.md # Stage 3 — RCE via /reports/generate │ ├── persistence.md # Stage 4 — Scheduled Task installation │ ├── beaconing.md # Stage 5 — C2 check-in pattern │ ├── collection.md # Stage 6 — exfiltration via C2 │ ├── screenshots/ # Evidence screenshots per stage │ └── scripts/ │ ├── malicious_report.py # Main payload (upload → execute chain) │ ├── beacon.py # Periodic C2 check-in implant │ ├── c2_listener.py # Attacker-side HTTP listener │ ├── persistence_setup.ps1 # Windows Scheduled Task installer │ ├── persistence_setup.sh # Linux cron installer │ ├── cleanup.ps1 # Post-lab cleanup (Windows) │ └── cleanup.sh # Post-lab cleanup (Linux) │ ├── sentinel/ │ ├── analytics-rules/ # 5 scheduled KQL rules (paste into Sentinel) │ │ ├── recon_rule.kql │ │ ├── upload_rule.kql │ │ ├── execution_rule.kql │ │ ├── beacon_rule.kql │ │ └── kill_chain_correlation.kql │ └── screenshots/ # Sentinel incidents / rule results │ └── docs/ ├── lab_setup.md # How to run the lab end-to-end ├── azure_configuration.md # AMA, DCR, custom table setup ├── log_ingestion.md # ContosoAppLogs_CL schema reference ├── mitre_mapping.md # ATT&CK / CWE mapping table ├── detection_engineering.md # Rule design rationale + tuning notes ├── investigation.md # Sentinel incident investigation walkthrough ├── incident_report.md # Formal incident report └── lessons_learned.md # Real issues encountered and fixes ``` ## 实验环境 **此实验特意在本地 Windows 11 机器(而非隔离的 VM)上运行**, 通过 Azure Arc 连接到 Azure。所有网络流量仅限 `127.0.0.1` — 除了通过 AMA 转发到 Azure Log Analytics Workspace 的日志数据外,没有任何数据离开本机。 这是对 `docs/lab_setup.md` 中隔离 VM 建议的一种有意的、已记录的偏离, 是专门针对家庭实验环境而做出的审慎决定。 | 组件 | 值 | |---|---| | 宿主操作系统 | Windows 11 (build 26200) | | Azure 连接 | Azure Arc(非原生 Azure VM) | | 资源组 | `soc-lab-rg` | | Log Analytics Workspace | `soc-lab-law`(西欧) | | Sentinel 门户 | Microsoft Defender 门户 (`security.microsoft.com`) | | 自定义日志表 | `ContosoAppLogs_CL` | | 操作系统日志源 | Windows Event Log → Log Analytics 中的 `Event` 表(Sysmon 通道:`Microsoft-Windows-Sysmon/Operational`) | ## 快速开始(复现该实验) **前置条件:** Python 3.10+、pip、Windows(用于原样运行持久化脚本)或 Linux (使用 `persistence_setup.sh`),以及配置了 Sentinel + AMA 的 Azure 订阅。 ``` # 1. 启动目标应用 cd flask-lab pip install -r requirements.txt python app.py # listening on http://127.0.0.1:5000 # 2. 启动 C2 监听器(单独的终端) python attack-simulation/scripts/c2_listener.py # 3. 按顺序执行攻击阶段 # attack-simulation/reconnaissance.md → upload.md → execution.md # → persistence.md → beaconing.md → collection.md # 4. 运行后 — 清理 powershell -File attack-simulation/scripts/cleanup.ps1 # Windows # 或 bash attack-simulation/scripts/cleanup.sh # Linux ``` 完整设置说明:[`docs/lab_setup.md`](docs/lab_setup.md) Azure/Sentinel 配置对接:[`docs/azure_configuration.md`](docs/azure_configuration.md) ## 关键检测工程决策 - **为每个插桩的杀伤链阶段配备一个专用规则,外加一个关联规则。** 单个规则 本身被刻意设定为低置信度;关联规则(`kill_chain_correlation.kql`) 通过要求同一源 IP 在同一时间窗口内产生跨越 ≥2 个不同阶段的事件, 从而证明将其定为高严重性事件的合理性。 - **行为检测,而非基于 IOC 的检测。** 没有任何规则硬编码攻击者的 IP、 payload 文件名或 C2 端口。它们依据的是模式:404 的爆发、 通用上传端点上的可执行扩展名、Python 衍生出 shell 实用程序、均匀间隔的 进程启动。 - **经过实验调优的阈值,并已明确记录。** 侦察规则的阈值被降低 (20/15 → 10/8)以匹配手动 curl 扫描,而非自动化工具。关联 窗口在演示运行期间扩大到了 1 天。两者都在 KQL 注释中被标记为 “实验调优 —— 生产环境需收紧。” - **用于执行检测的对称关联窗口。** `execution_rule.kql` 的关联窗口为 ±1 分钟(不仅是向前),因为子进程 (`whoami.exe`)是在 Python 执行*期间*衍生出来的,并在 Flask 写入 `report_generated` 日志行之前完成 —— 这使得操作系统级的进程创建事件的时间戳略微 *早于* 应用日志的时间戳。 完整基本原理请参见 [`docs/detection_engineering.md`](docs/detection_engineering.md)。 ## 展示的漏洞(故意为之,仅供实验) | CWE | 位置 | 描述 | |---|---|---| | CWE-434 | `app.py` `/upload` | 无限制文件上传 — 无扩展名或 content-type 验证 | | CWE-94 | `app.py` `/reports/generate` | 代码注入 — 通过 `subprocess.run([sys.executable, ...])` 执行任何上传的文件 | | CWE-306 | 上述两个端点 | 缺失认证 — 两者无需会话即可访问 | | CWE-312 | `config.py` | (虚假)凭证的明文存储 — 故意设置的外泄目标 | ## 免责声明 本仓库是一个**网络安全作品集与教育项目**。 攻击模拟仅针对作者自己机器上本地运行的应用程序, 并使用了虚构数据。未攻击任何真实系统。本仓库的任何位置都 不存在真实的凭证。`attack-simulation/` 中的脚本仅供 受控的实验环境使用 — 有关条款请参阅 `LICENSE`。 ## 许可证 MIT — 请参阅 [`LICENSE`](LICENSE)
标签:AI合规, CISA项目, Go语言工具, HTTP工具, KQL, Microsoft Sentinel, 主机安全, 安全靶场, 攻击模拟, 网络信息收集, 网络安全, 逆向工具, 隐私保护, 驱动签名利用