jelanidm/sentinel-range
GitHub: jelanidm/sentinel-range
一个基于 Microsoft Sentinel 和 Entra ID 审计日志的检测工程实验室，包含五条经真实事件验证的 KQL 分析规则。
Stars: 0 | Forks: 0
# SENTINL.RANGE
**一个云原生检测实验室，基于实时的 Microsoft Entra 审计遥测数据，构建于 Microsoft Sentinel 之中。**
本仓库是一个小型的检测工程作品集。我搭建了一个 Microsoft Sentinel 工作区，在一个隔离的测试租户中生成了我自己的管理员攻击遥测数据，编写了五条 KQL 分析规则来捕获它们，并在 Microsoft Defender 门户中将每条规则触发时的真实事件记录了下来。
这里的每一条规则都是由我编写的，并作为计划分析规则部署，而且（除了一个明确标注的例外情况）都进行了端到端的验证：执行攻击、引发事件、捕获证据。没有任何内容是自我评分的，全由平台进行评分。
## 为什么使用 Audit logs（而不是 sign-in logs）
最初的计划是使用 Entra 的 **sign-in** logs。将其导出到 Sentinel 需要付费的 Entra ID P1/P2 许可证，而这无法在个人账户租户上顺利激活。与其伪造数据，我不如将整个实验室的研究方向转向了 **Audit Logs**，它可以在任何租户上免费流入 Sentinel，且无需额外的许可证。
事实证明，这是更有趣的数据集。Audit logs 捕获了管理和身份管理活动、账户创建、角色授予、应用/服务主体注册、同意授权以及策略更改，这恰恰是持久化、权限提升和同意网络钓鱼经常出没的领域。这些正是 SOC 分析师在首次告警之后去调查的事件。
## 检测项
| # | 检测项 | MITRE 技术 | 规则 | 证据 |
|---|-----------|-----------------|------|----------|
| 1 | 创建了新用户或访客账户 | [T1136](https://attack.mitre.org/techniques/T1136/) Create Account | [KQL](detections/01-new-account-created.md) | 已触发（队列） |
| 2 | 分配了特权角色 | [T1098](https://attack.mitre.org/techniques/T1098/) Account Manipulation | [KQL](detections/02-privileged-role-assigned.md) | [事件 #66](screenshots/incident-privileged-role-detail.png) |
| 3 | 添加了服务主体 / 应用注册 | [T1098.001](https://attack.mitre.org/techniques/T1098/001/) Additional Cloud Credentials | [KQL](detections/03-service-principal-added.md) | [事件 #60-65](screenshots/incidents-queue.png) |
| 4 | 更改或禁用了 Conditional Access 策略 | [T1562](https://attack.mitre.org/techniques/T1562/) Impair Defenses | [KQL](detections/04-conditional-access-changed.md) | 规则已部署，未触发（需要 P2） |
| 5 | 单个执行者突发进行大量管理更改（关联） | TA0003 + TA0004（多重技术） | [KQL](detections/05-admin-change-burst.md) | 已触发（`ChangeCount: 4`） |
所有五条规则均已在 Sentinel Analytics 边栏选项卡中部署并启用：
在 Microsoft Defender 门户中引发的事件：
## 技术栈
- **SIEM：** Microsoft Sentinel（基于 Azure Log Analytics 工作区）
- **遥测数据：** Microsoft Entra ID Audit Logs
- **检测语言：** KQL (Kusto Query Language)
- **框架：** MITRE ATT&CK
- **事件呈现面：** Microsoft Defender 门户
## 构建过程
1. **搭建 SIEM**：配置 Log Analytics 工作区 + 启用 Microsoft Sentinel，安装 Entra ID 数据连接器并流入 Audit Logs。([工作区](screenshots/01-create-workspace.png) · [Sentinel](screenshots/03-sentinel-enabled.png) · [连接器](screenshots/04-entra-connector-auditlogs.png))
2. **生成攻击遥测数据**：在一个隔离的测试租户中，我执行了每条规则所针对的管理操作：创建测试用户、分配和移除特权角色、注册应用程序/服务主体。([示例](screenshots/05-create-test-user.png))
3. **编写并验证检测项**：使用 KQL 搜寻原始事件，将每个查询提升为计划分析规则，重新触发该操作，并确认了事件。([关联规则查询](screenshots/06-correlation-rule-query.png))
4. **捕获证据**：Defender 门户中的事件，Defender 自身的 MITRE 映射确认了该技术。([事件详情](screenshots/incident-privileged-role-detail.png))
## 关于调优的诚恳说明
本实验室触发了 **68 个事件**，其中大多数是重复的“添加了服务主体 / 应用注册”警报。这并不是需要隐瞒的错误，这恰恰是调优的核心意义所在。
在真实的 SOC 中，一条对每次应用注册都会发出警报的规则会让分析师疲于奔命。下面的每个检测文件都包含一条**调优说明**，准确描述了我将如何在生产环境中减少这种噪音（阈值、对已知自动化的排除、告警前的丰富化），同时又不丧失检测覆盖范围。 firsthand 亲身体验这些噪音是理解为什么警报保真度如此重要的最快方法，而通过调优减少误报正是我日常 SOC 工作的一部分。
## 仓库布局
```
sentinel-range/
README.md
detections/
01-new-account-created.md
02-privileged-role-assigned.md
03-service-principal-added.md
04-conditional-access-changed.md
05-admin-change-burst.md
screenshots/
(setup, query, deployed-rules, and incident evidence)
```
标签：Entra ID, KQL, Microsoft Sentinel, 安全运营, 扫描框架