[Microsoft-Sentinel-Complete-README.md](https://github.com/user-attachments/files/27020290/Microsoft-Sentinel-Complete-README.md)
# Microsoft Sentinel SOC 实验室作品集项目
## 项目概述
本仓库是一个实操性的 **Microsoft Sentinel SOC 项目**，旨在以招聘人员和招聘经理能够快速理解的方式，展示实际的安全运营知识。
本项目的目标是展示我能够在 SIEM 环境中完成真实分析师所遵循的完整工作流程：
- 部署并了解 Sentinel 环境，
- 连接相关的数据源，
- 验证遥测数据的引入，
- 编写和调优 KQL 检测规则，
- 调查事件，
- 使用 Watchlist 充实检测结果，
- 思考威胁情报的用例，
- 并使用 Playbook 设计自动化。
该项目的灵感来源于一次 Microsoft Sentinel 实践练习实验室，随后被扩展为一个完整的作品集案例研究，使其读起来像真实的 SOC 工作记录，而不是一份简短的教程笔记。
## 为什么这个项目很重要
许多初级网络安全候选人声称他们了解 Microsoft Sentinel，但很少有人能真正展示他们在其中做了什么。
这个项目有助于证明我了解：
- Sentinel 如何融入 SOC，
- 数据接入与检测工程之间的区别，
- 事件是如何被调查的，
- 如何使用 KQL 进行威胁狩猎，
- Watchlist 如何提高检测质量，
- 以及自动化如何支持响应。
与其仅仅说 **“我看过 Sentinel 的视频”**，不如说这个仓库展示了一个包含技术细节的结构化 SOC 工作流项目。
## 展示的核心技能
| 领域 | 展示的能力 |
|---|---|
| SIEM 工程 | Workspace 设置，Microsoft Sentinel 接入，可见性验证 |
| 数据引入 | 连接日志源并检查遥测数据的健康状况 |
| 检测工程 | 构建和调优基于 KQL 的分析逻辑 |
| 威胁狩猎 | 跨日志数据调查可疑行为 |
| 事件响应 | 分流、证据审查、所有权分配、分类、文档记录 |
| 数据充实 | Watchlist 和威胁情报概念 |
| SOAR | 使用 Logic Apps 进行 Playbook 设计 |
| 安全报告 | 仪表板，Workbook，运营可见性 |
| 沟通 | GitHub 文档，案例摘要，面向招聘人员的报告 |
## 工具和技术
- **Microsoft Sentinel**
- **Azure Log Analytics Workspace**
- **Kusto Query Language (KQL)**
- **Azure Activity Logs**
- **SigninLogs / AuditLogs / SecurityEvent**
- **Watchlists**
- **Threat Intelligence**
- **Analytics Rules**
- **Incidents**
- **Workbooks**
- **Azure Logic Apps / Playbooks**
## 项目目标
构建本项目旨在展示以下内容：
1. 启用 Microsoft Sentinel 实验室环境。
2. 连接日志源并确认遥测数据引入。
3. 创建并测试有用的 KQL 检测规则。
4. 了解 Analytics Rules 如何生成事件。
5. 练习告警分流和调查工作流。
6. 使用 Watchlist 支持调优和数据充实。
7. 将威胁狩猎逻辑应用于可疑事件。
8. 记录真实的自动化 / 遏制工作流。
9. 以对招聘人员友好的 GitHub 格式展示项目。
## 架构概述
```
graph TD
A[Azure Subscription] --> B[Log Analytics Workspace]
B --> C[Microsoft Sentinel]
D[Azure Activity Logs] --> C
E[Security Events / Sign-In Logs / Audit Logs] --> C
F[Threat Intelligence] --> C
G[Watchlists] --> C
C --> H[Analytics Rules]
H --> I[Incidents]
I --> J[Investigation & Triage]
C --> K[Hunting Queries]
C --> L[Workbooks]
C --> M[Automation Rules]
M --> N[Logic App Playbooks]
N --> O[Notification / Approval / User Disable / IP Block]
```
## 截图
### Microsoft Sentinel 概览仪表板
### 事件队列 / 分流视图
### Workbook / 报告视图
### Logic App Playbook 流程
## 端到端实验室演练
## 阶段 1：Workspace 设置和 Sentinel 启用
实验室的第一步是创建或选择一个 **Log Analytics workspace**，并在其上启用 **Microsoft Sentinel**。
这很重要，因为 Sentinel 依赖于该 Workspace 进行：
- 日志存储，
- 查询执行，
- Analytics Rules，
- 调查，
- 以及 Workbook。
### 我在这个阶段学到了什么
- Microsoft Sentinel 不仅仅是一个仪表板。它依赖于 Azure 资源和正确的设置。
- Workspace 是检测和调查背后的核心数据层。
- 在构建检测之前，环境本身必须正常工作。
### 我在实时实验室中会收集的证据
- 资源组创建，
- Workspace 部署，
- Sentinel 接入状态，
- 使用的订阅和区域，
- 已启用环境的门户截图。
## 阶段 2：数据连接器和遥测数据引入
启用 Sentinel 后，下一个重要步骤是连接数据源。
SIEM 的 usefulness 仅取决于其接收到的遥测数据的质量和相关性。
### 数据源思维模式
当我连接一个数据源时，我会考虑：
- 它填充了什么表，
- 它启用了什么检测，
- 需要什么权限或先决条件，
- 它将产生多少信号与噪音，
- 以及该数据对于安全调查是否真的有用。
### 探索的示例连接器类型
- Azure Activity
- 登录和身份日志
- 审计日志
- 安全事件
- Microsoft security alerts
- 威胁情报源
### 接入数据后我验证的内容
- 连接器显示为已连接或健康状态，
- 日志到达预期的表中，
- 时间戳是最近的，
- 并且我可以成功查询数据。
### 这向招聘人员展示了什么
它展示了我理解数据引入先于检测工程，并且连接器的质量直接影响 SOC 的可见性。
## 阶段 3：Analytics Rules 和检测工程
这是 Sentinel 变得可操作的地方。原始日志变成了可操作的检测。
### 我的检测工作流
1. 识别可疑行为。
2. 选择正确的表。
3. 编写 KQL 查询。
4. 在 Logs 中测试查询。
5. 将其转换为计划的 Analytics Rule。
6. 设置严重性、频率和分组。
7. 调优以消除已知噪音。
### 本项目涵盖的检测思路
- 来自单一 IP 的重复失败登录，
- 禁用账户的登录尝试，
- 创建新用户后紧跟着进行角色分配，
- 与受信任的允许列表不匹配的事件。
### 为什么这很重要
这表明我可以像一名初级检测工程师那样思考，而不仅仅是点击使用内置内容。
## 阶段 4：事件分流和调查
一旦告警变成事件，工作就转移到了案例处理上。
### 我在分流期间会问的问题
- 是什么规则创建了这个事件？
- 严重性是否合适？
- 涉及了哪些用户、IP 或主机？
- 证据是否表明存在真实的恶意活动？
- 该案例是孤立的、重复的，还是更广泛模式的一部分？
### 在 Sentinel 中典型的分析师操作
- 分配所有权，
- 更新状态，
- 添加评论，
- 添加标签，
- 审查证据和实体，
- 对事件进行分类，
- 升级或附带说明后关闭。
### 为什么事件文档记录很重要
清晰的笔记是真实 SOC 工作的一部分。另一位分析师应该能够理解案例被升级、遏制或关闭的原因。
## 阶段 5：使用 KQL 进行威胁狩猎
威胁狩猎超越了等待告警的范畴。它涉及主动搜索可疑行为。
### 本项目中使用的狩猎思维
- 从事件中发现的实体进行 Pivot（支点分析），
- 扩大时间窗口以寻找相关活动，
- 比较不同用户和主机之间的行为，
- 寻找可能尚未产生告警的模式，
- 并验证某个告警是否属于更广泛的入侵的一部分。
### 狩猎假设示例
- 单个源 IP 可能在执行密码喷洒，
- 禁用的账户可能仍然是自动化工具或攻击者的目标，
- 新创建的账户可能升级过快，
- 受信任的来源应当与可疑的来源区分开。
## 阶段 6：用于充实和调优的 Watchlist
Watchlist 为检测和调查添加了上下文。
### Watchlist 用例示例
- 特权用户，
- 敏感系统，
- 受信任的扫描器 IP，
- 已批准的 VPN 出口 IP，
- 已知的可疑指标。
### 为什么 Watchlist 很重要
一个优秀的 SOC 需要在不失去可见性的前提下减少误报。Watchlist 有助于区分正常的业务活动和高风险活动。
## 阶段 7：威胁情报概念
威胁情报可用于充实日志并对可疑事件进行优先级排序。
### 我如何看待 Sentinel 中的 TI
- 将观察到的 IP 或域与已知指标相关联，
- 使用 TI 匹配来提高分析师的优先级，
- 将 TI 与调查上下文相结合，
- 并避免将所有指标匹配都自动视为恶意。
## 阶段 8：自动化和 Playbook
最后一个阶段是响应的成熟度。
### Playbook 设计思考
一个优秀的 Playbook 应该：
- 在有意义的条件下触发，
- 通知合适的人员，
- 留下审计跟踪，
- 为高风险操作提供审批支持，
- 并且仅在安全的情况下自动执行遏制操作。
### 示例响应流程
- 创建 Sentinel 事件，
- 通知分析师或 SOC 频道，
- 请求审批，
- 禁用用户或封锁 IP，
- 附带响应说明更新事件。
这展示了对 **SIEM + SOAR** 的理解，而不仅仅是查看告警。
## 本项目包含的 KQL 查询
## 1) 按源 IP 统计的失败登录
```
// Failed logons by source IP
// Useful for spotting brute force or password spray behavior.
SecurityEvent
| where TimeGenerated > ago(24h)
| where EventID == 4625
| extend SourceIp = tostring(IpAddress)
| extend Account = tostring(TargetUserName)
| summarize FailedAttempts=count(),
FirstSeen=min(TimeGenerated),
LastSeen=max(TimeGenerated),
TargetedAccounts=make_set(Account, 20),
Hosts=make_set(Computer, 20)
by SourceIp
| where FailedAttempts >= 10
| where isnotempty(SourceIp)
| order by FailedAttempts desc
```
### 为什么包含此查询
此查询有助于检测来自单一源的密码喷洒、暴力破解尝试或重复的身份验证失败。
## 2) 创建新用户后紧跟着进行角色分配
```
// New user followed by role assignment within 24 hours
// Useful for spotting suspicious privilege escalation after account creation.
AuditLogs
| where TimeGenerated > ago(7d)
| where OperationName == "Add user"
| project AddedTime = TimeGenerated,
UserPrincipalName = tostring(TargetResources[0].userPrincipalName)
| join kind=inner (
AzureActivity
| where TimeGenerated > ago(7d)
| where OperationNameValue =~ "MICROSOFT.AUTHORIZATION/ROLEASSIGNMENTS/WRITE"
or OperationName =~ "Create role assignment"
| project RoleAssignmentTime = TimeGenerated,
Caller,
OperationName,
ResourceGroup,
SubscriptionId
) on $left.UserPrincipalName == $right.Caller
| where RoleAssignmentTime between (AddedTime .. AddedTime + 1d)
| project AddedTime, RoleAssignmentTime, UserPrincipalName, OperationName, ResourceGroup, SubscriptionId
| order by RoleAssignmentTime desc
```
### 为什么包含此查询
这有助于识别可疑的身份配置或账户创建后快速的权限提升。
## 3) 已禁用账户仍收到登录尝试
```
// Sign-in attempts against disabled accounts
// Useful for investigating stale credentials, attacker re-use, or noisy automation.
SigninLogs
| where TimeGenerated > ago(7d)
| where ResultDescription has_any ("account is disabled", "disabled")
or Status has_any ("account is disabled", "disabled")
| summarize Attempts=count(),
FirstSeen=min(TimeGenerated),
LastSeen=max(TimeGenerated),
Applications=make_set(AppDisplayName, 20),
Locations=make_set(Location, 20)
by IPAddress, UserPrincipalName
| order by Attempts desc
```
### 为什么包含此查询
禁用的账户通常不应成为活跃的身份验证目标。这可以揭示攻击者对旧凭证的重用，或者是内部自动化出现故障。
## 4) Watchlist 允许列表示例
```
// Watchlist allow-list example
// Replace 'trusted-ip-allowlist' with your actual watchlist alias.
let AllowedIPs =
_GetWatchlist('trusted-ip-allowlist')
| project SearchKey;
SigninLogs
| where TimeGenerated > ago(24h)
| where isnotempty(IPAddress)
| join kind=leftanti AllowedIPs on $left.IPAddress == $right.SearchKey
| summarize FailedOrRiskyEvents=count() by IPAddress, UserPrincipalName, AppDisplayName
| order by FailedOrRiskyEvents desc
```
### 为什么包含此查询
这展示了如何使用 Watchlist 来减少告警疲劳，同时保留对不受信任来源的可见性。
## 示例 Watchlist
## 高风险 IP Watchlist
```
SearchKey,Description,Owner,Priority
185.220.101.1,Tor exit node sample,ThreatIntel,High
45.95.147.34,Suspicious authentication source sample,SOC,High
103.86.99.12,Unapproved external address sample,SOC,Medium
```
## 特权用户 Watchlist
```
SearchKey,DisplayName,Department,Criticality
admin01@contoso.com,Domain Admin Account,Infrastructure,High
secops.lead@contoso.com,Security Operations Lead,Security,High
azure.owner@contoso.com,Azure Subscription Owner,Cloud,High
```
## 示例事件摘要
```
# 样本 Incident 摘要
## Incident 标题
Suspicious Sign-In Attempts Against Disabled Accounts
## Severity
Medium
## 摘要
Multiple authentication attempts were observed against one or more disabled accounts. The pattern may indicate stale credential use, attacker knowledge of historic identities, or noisy automated processes attempting to authenticate with invalid account states.
## 已审查的初始 Evidence
- sign-in failure descriptions
- source IP addresses
- affected user accounts
- time window and repetition pattern
- related applications involved in the sign-in attempts
## Analyst 评估
The activity is suspicious because disabled accounts should not be valid authentication targets during normal operations. Repeated attempts warrant validation of the source system or user behavior behind the traffic.
## 建议的后续 Action
1. Validate whether the source IP belongs to a trusted internal process.
2. Review whether the affected accounts are tied to decommissioned services.
3. Check for additional sign-in or enumeration activity from the same source.
4. Escalate if the source is external, repeated, or associated with other authentication anomalies.
## Containment 注意事项
- block or monitor the source IP if malicious intent is confirmed,
- notify identity administrators if an internal process is misconfigured,
- tune the detection only after root cause is understood.
## Closing Note 示例
Incident reviewed and documented. Further validation required to determine whether the source is malicious or a legacy internal process using stale credentials.
```
## 检测理念
我将这个项目既当作一个 **Microsoft Sentinel 学习实验室**，也当作一个 **SOC 作品集项目**。
目标不是生成大量嘈杂的检测。目标是证明我能够：
- 将可疑行为转化为查询，
- 思考该行为为何重要，
- 理解误报，
- 调查输出结果，
- 并记录下一步应该发生什么。
## 事件处理思维
当我审查一个事件时，我重点关注：
1. 是什么触发了它，
2. 它看起来有多严重，
3. 哪个实体最重要，
4. 证据是否支持升级，
5. 以及应该考虑采取什么遏制行动。
这反映了 SOC 分析师在真实环境中使用 Microsoft Sentinel 的基本工作流。
## MITRE ATT&CK 思维
我试图从攻击者行为的角度进行思考，而不仅仅是原始事件。
与本项目相关的 ATT&CK 风格推理示例包括：
- 通过重复的失败登录进行 **凭证访问**，
- 通过在创建用户后快速分配角色进行 **权限提升**，
- 通过可疑的账户配置进行 **持久性** 维持，
- 通过可疑的登录行为和重复探测进行 **发现**，
- 在必须将受信任的来源与可疑来源区分开来时的 **防御规避**。
## 招聘人员价值
这个项目有助于证明我能够：
- 解释 Microsoft Sentinel 是什么，
- 接入并验证数据源，
- 编写和调优 KQL，
- 创建有用的检测逻辑，
- 以分析师的思维调查事件，
- 清晰地记录案例笔记，
- 并理解 SIEM 和 SOAR 之间的联系。
这使得该项目比仅仅声明“我曾用过一次 Sentinel”的基本笔记更有说服力。
## 简历要点
- 构建并记录了一个实操性的 Microsoft Sentinel SOC 实验室，涵盖了 Workspace 接入、数据连接器、KQL 检测、威胁狩猎、事件分流、Watchlist、威胁情报、Workbook 和 Playbook 设计。
- 创建了 KQL 查询，以检测 Microsoft Sentinel 中的可疑身份验证活动、禁用账户登录以及从身份到权限的升级模式。
- 通过审查严重性、证据、实体、所有权、分类和案例文档，练习了 Microsoft Sentinel 的事件处理。
- 使用 Watchlist 和调优概念将受信任的活动与可疑活动区分开，并减少了告警噪音。
- 使用 Azure Logic Apps 设计了 Microsoft Sentinel SOAR 工作流，用于分析师通知、基于审批的遏制、禁用用户和封锁 IP。
## 面试谈论要点
### 你在 Microsoft Sentinel 中实际做了什么？
我设置了实验室环境，查看了数据连接器，使用 KQL检测和狩猎，调查了 Sentinel 可以生成的事件类型，并记录了基于 Playbook 的响应将如何工作。
### 哪一部分最有价值？
编写和理解 KQL 是最有价值的部分，因为它迫使我思考攻击者的行为、告警质量和减少误报。
### 你是如何展示事件处理的？
我记录了所有权、严重性审查、证据分析、分类，以及为升级或关闭而留下的备注类型。
### 为什么要包含 Playbook 和 Workbook？
因为安全运营不仅仅是查看告警。它还包括报告、可见性、沟通和可重复的响应过程。
## 我将如何进一步改进这个项目
为了使这个项目随着时间的推移变得更加强大，我会：
1. 用我自己 Azure 租户的图像替换初始截图，
2. 从实验室中导出真实的自定义 Analytics Rules，
3. 添加更多的 KQL 狩猎和调优示例，
4. 记录一个真实的误报以及我是如何调优它的，
5. 添加一段简短的屏幕录制，展示规则触发和事件打开的过程，
6. 随着 Microsoft 继续推进 Sentinel 的过渡，构建一个 Defender 门户版本。
## 仓库结构
```
microsoft-sentinel-portfolio-project/
├── README.md
├── assets/
│ └── images/
│ ├── dashboard.png
│ ├── incident-grid.png
│ ├── incidents.png
│ ├── logic-app.png
│ └── workbook-graph.png
├── docs/
│ ├── 01_lab_walkthrough.md
│ ├── 02_detection_and_hunting.md
│ ├── 03_incident_response_and_playbooks.md
│ ├── 04_recruiter_notes.md
│ └── 05_image_attribution.md
├── kql/
│ ├── 01_failed_logons_by_ip.kql
│ ├── 02_new_user_followed_by_role_assignment.kql
│ ├── 03_disabled_accounts_signins.kql
│ └── 04_watchlist_allowlist_example.kql
├── reports/
│ └── sample-incident-summary.md
└── watchlists/
├── high-risk-ip-addresses.csv
└── privileged-users.csv
```
## 参考文献
- 视频灵感：`https://www.youtube.com/watch?v=NJlaqBaqahc`
- Microsoft Sentinel 官方文档：`https://learn.microsoft.com/en-us/azure/sentinel/`
- Microsoft Sentinel 培训实验室内容：`https://github.com/Azure/Azure-Sentinel/tree/master/Solutions/Training/Azure-Sentinel-Training-Lab`
- 图片归属说明：`docs/05_image_attribution.md`