Ahmad-Obeid7/Microsoft-sentinel-soc-lab

# Microsoft Sentinel SOC 检测与分类实验室 ## 项目摘要 我部署了 Microsoft Sentinel，摄取了 292 个受控的 SSH 身份验证事件，并开发了九个 KQL 威胁狩猎和调查查询。 我将检测逻辑转换为计划分析规则，并调查了由此产生的三个事件： - 已确认的 SSH 账户入侵 - 密码喷射尝试 - 良性的自动备份失败 该项目证明，告警数量本身并不能决定严重程度：数量最高的来源是良性的，而数量较低的来源却成功入侵了一个账户。 ## 快速链接 - [查看 KQL 查询](queries/) - [阅读检测与响应报告](report/detection-and-response-report.md) - [查看调查证据](screenshots/) - [查看 Sentinel 工作簿](#sentinel-workbook) ## 主要成果 该检测识别出了三个可疑的源 IP 地址： | 源 IP | 活动 | 结论 | |---|---|---| | `203.0.113.77` | 多次失败后成功进行 SSH 登录并访问了 `/etc/shadow` | 真阳性 — 确认入侵 | | `198.51.100.23` | 一个外部源针对 11 个不同的账户 | 真阳性 — 密码喷射尝试 | | `10.20.14.9` | 内部备份服务每 60 秒重试一次过期的密码 | 良性阳性 — 配置错误的备份作业 | ## 工具与技能 **SIEM 与云** - Microsoft Sentinel - Azure Log Analytics - Azure Monitor Logs Ingestion API - Data Collection Endpoints 和 Data Collection Rules **检测与调查** - Kusto Query Language - 威胁狩猎 - 计划分析规则 - 实体映射和告警分组 - 事件分类和定级 - 检测调优 - MITRE ATT&CK 映射 **报告与可视化** - Microsoft Sentinel Workbooks - 基于证据的事件报告 - 补救建议 - Azure 资源清理 **辅助工具** - PowerShell - Azure Cloud Shell - Git 和 GitHub ## 架构与工作流 该项目遵循了完整的 SOC 生命周期： ``` flowchart LR A[SSH Authentication Logs] --> B[Azure Logs Ingestion API] B --> C[Data Collection Endpoint] C --> D[Data Collection Rule] D --> E[Log Analytics Workspace] E --> F[Microsoft Sentinel] F --> G[KQL Threat Hunting] G --> H[Scheduled Analytics Rule] H --> I[Sentinel Incidents] I --> J[Investigation and Triage] J --> K[Classification and Closure] K --> L[Workbook Dashboard and Report] ``` ### 工作流 1. **摄取** — 将受控的 SSH 数据集加载到自定义的 `MeridianLogs_CL` 表中。 2. **检查** — 审查了原始字段和最初的身份验证事件。 3. **狩猎** — 使用 KQL 提取源 IP 地址、用户名和身份验证结果。 4. **检测** — 为在 10 分钟时间窗口内产生五次以上 SSH 登录失败的源创建了计划规则。 5. **告警** — 将源 IP 映射为实体并生成独立的 Sentinel 事件。 6. **分类** — 调查每个事件，以确定身份验证是否成功以及随后发生了什么。 7. **定级** — 将两个事件作为真阳性关闭，一个作为良性阳性关闭。 8. **可视化** — 构建了一个 Sentinel 工作簿，显示了一段时间内的失败登录和顶级源 IP。 9. **报告** — 记录了证据、MITRE ATT&CK 映射、补救措施和检测局限性。 10. **清理** — 在保存项目证据后删除了 Azure 资源组。 ## 我构建的内容 - 连接到 Azure Log Analytics 工作区的 Microsoft Sentinel 部署 - 包含 SSH 身份验证活动的自定义 Log Analytics 表 - Data Collection Endpoint 和 Data Collection Rule - 九个记录在案的 KQL 威胁狩猎和调查查询 - 计划的暴力破解分析规则 - IP 实体映射和告警分组 - 三个经过全面调查的 Sentinel 事件 - 用于身份验证监控的工作簿仪表板 - 详细的检测和响应报告 - 用于作品集发布的已脱敏证据集 ## 数据摄取故障排除 最初的传统摄取脚本返回了成功的 HTTP 响应，但并未填充自定义表。 为了解决这个问题，我执行了以下操作： 1. 验证了工作区 ID 和目标表。 2. 确认自定义表已成功预配。 3. 测试了单个受控记录的摄取。 4. 将表从经典摄取迁移到基于 Data Collection Rule 的摄取。 5. 创建了 Data Collection Endpoint 和 Data Collection Rule。 6. 分配了所需的 Azure 角色。 7. 通过 Azure Monitor API 进行了身份验证。 8. 使用当前的 Logs Ingestion API 成功摄取了数据集。 此故障排除提供了有关 Azure 身份验证、权限、自定义表和现代日志摄取管道的实践经验。 ## 检测证据 ### 识别出的可疑源 第一个狩猎查询按源 IP 对失败的 SSH 身份验证尝试进行了分组。有三个源的活跃度显著高于正常的背景活动。  ### 计划分析规则 狩猎逻辑被转换为已启用的 Microsoft Sentinel 计划分析规则，严重程度为中级。  ### 生成的事件 该规则为三个可疑的源 IP 地址生成了独立的事件。  ### 确认的账户入侵 对 `203.0.113.77` 的调查显示，在多次身份验证尝试失败后，成功通过 SSH 登录到了 `opsadmin` 账户。  调查还发现了入侵后对 Linux 密码哈希文件的访问。  ### 密码喷射尝试 源 `198.51.100.23` 尝试针对 11 个不同的用户名进行身份验证，但没有成功登录。  ### 良性备份服务活动 内部源 `10.20.14.9` 针对凭据 `svc-backup` 产生了 30 次失败尝试，没有成功的身份验证，且尝试之间的时间间隔正好为 60 秒。  ### 已完成的事件队列 所有主要事件都经过了调查、分类、记录和关闭。  ### Sentinel 工作簿 创建了一个自定义工作簿，以可视化一段时间内的 SSH 失败登录，并对顶级源 IP 地址进行排名。  ## KQL 查询 项目中使用的完整 KQL 可在 [`queries`](queries/) 目录中找到。 | 文件 | 用途 | |---|---| | [`01-raw-log-inspection.kql`](queries/01-raw-log-inspection.kql) | 检查自定义表结构和示例原始事件 | | [`02-failed-logins-by-ip.kql`](queries/02-failed-logins-by-ip.kql) | 按源 IP 计算失败登录次数并进行排名 | | [`03-brute-force-detection.kql`](queries/03-brute-force-detection.kql) | 检测 10 分钟时间窗口内超过五次的失败 | | [`04-confirmed-compromise-investigation.kql`](queries/04-confirmed-compromise-investigation.kql) | 重构失败后接着成功身份验证的过程 | | [`05-post-compromise-shadow-access.kql`](queries/05-post-compromise-shadow-access.kql) | 识别对 `/etc/shadow` 的访问 | | [`06-password-spray-investigation.kql`](queries/06-password-spray-investigation.kql) | 提取密码喷射所针对的用户名 | | [`07-benign-backup-investigation.kql`](queries/07-benign-backup-investigation.kql) | 总结自动备份的重试模式 | | [`08-failed-logins-over-time.kql`](queries/08-failed-logins-over-time.kql) | 为工作簿身份验证时间线提供数据支持 | | [`09-top-source-ips.kql`](queries/09-top-source-ips.kql) | 为工作簿源 IP 排名提供数据支持 | ## 调查报告 完整的检测与响应报告包含事件证据、分析师决策、MITRE ATT&CK 映射、补救建议、检测局限性和经验教训。 [阅读完整的检测与响应报告](report/detection-and-response-report.md) ## MITRE ATT&CK 映射 | 技术 | 名称 | 项目证据 | |---|---|---| | `T1110` | 暴力破解 | 针对账户 `opsadmin` 的重复失败 SSH 登录 | | `T1110.003` | 密码喷射 | 一个外部 IP 尝试针对 11 个不同用户名进行身份验证 | | `T1078` | 有效账户 | 攻击者使用账户 `opsadmin` 成功进行了身份验证 | | `T1003.008` | 操作系统凭据转储：`/etc/passwd` 和 `/etc/shadow` | 被入侵的账户在身份验证后访问了 `/etc/shadow` | ## 检测局限性 计划分析规则在识别集中的登录失败活动方面非常有效，但它存在一些局限性： - 低速且慢速的攻击可能会保持在 10 分钟内失败五次以上的阈值之下。 - 基于 IP 的分组可能会漏掉轮换源地址的攻击者。 - 共享代理或 NAT 网关可能会导致多个系统显示在同一个源 IP 下。 - 该规则无法独立判断活动是恶意的还是良性的。 - 该规则不会将失败的尝试与随后的成功登录直接相关联。 - 该实验室使用的是静态导入的数据集，而不是持续的生产数据连接器。 - 对相同静态记录的重复评估会产生重复的事件。 - 可用的遥测数据仅限于一台虚构的 Linux 服务器。 生产环境的实施应将此规则与身份、端点、防火墙、网络和云审计日志相结合。 ## 我在生产环境中会做的改进 - 创建一个更高严重性的规则，针对重复失败后接着成功身份验证的情况。 - 基于一个源所针对的唯一账户数量添加密码喷射规则。 - 添加使用更长分析周期的低速且慢速攻击检测。 - 使用历史身份验证基线来调整阈值。 - 使用连续的数据连接器代替手动摄取日志。 - 添加告警抑制和去重。 - 将身份验证事件与进程执行和端点遥测相关联。 - 使用威胁情报信息丰富源 IP 实体。 - 仅在适当的验证后才自动执行遏制措施。 - 通过审查假阳性和假阴性来跟踪检测性能。 ## 仓库结构 ``` microsoft-sentinel-soc-lab/ ├── README.md ├── .gitignore ├── queries/ │ ├── 01-raw-log-inspection.kql │ ├── 02-failed-logins-by-ip.kql │ ├── 03-brute-force-detection.kql │ ├── 04-confirmed-compromise-investigation.kql │ ├── 05-post-compromise-shadow-access.kql │ ├── 06-password-spray-investigation.kql │ ├── 07-benign-backup-investigation.kql │ ├── 08-failed-logins-over-time.kql │ └── 09-top-source-ips.kql ├── report/ │ └── detection-and-response-report.md └── screenshots/ ├── 01-sentinel-enabled.png ├── 02-log-ingestion-confirmed.png ├── 03-raw-log-sample.png ├── 04-failed-logins-by-source-ip.png ├── 06-analytics-rule-enabled.png ├── 07-sentinel-incidents-generated.png ├── 08-incident-details-confirmed-compromise.png ├── 09-confirmed-compromise-success-login.png ├── 10-post-compromise-shadow-file-access.png ├── 11-confirmed-compromise-closed.png ├── 13-password-spray-evidence.png ├── 14-password-spray-closed.png ├── 15-incident-details-benign-backup.png ├── 16-benign-backup-job-evidence.png ├── 17-benign-backup-incident-closed.png ├── 18-incidents-triaged-and-closed.png ├── 19-sentinel-workbook-dashboard.png └── 20-resource-group-deleted.png ``` ## 负责任的使用与署名 该项目是在授权的实验室环境中完成的，使用了虚构的银行业务场景和受控的训练数据。 最初的场景和样本数据集是通过 MyFirstHack Mentorship Weekly Project 05 材料提供的。Azure 部署、摄取故障排除、KQL 分析、检测配置、事件调查、书面报告和脱敏截图均作为我自己实验工作的一部分完成。 本仓库不包含原始数据集、培训指南、摄取脚本、凭据和未经脱敏的证据。 ## 云清理 在保存了必要的项目证据后，删除了 Azure 资源组。  这删除了 Sentinel 部署、Log Analytics 工作区、自定义表、分析规则、事件、工作簿、Data Collection Endpoint 和 Data Collection Rule。 ## 核心要点 从这个项目中得到的最重要的教训是，告警数量并不等于严重性。 数量最高的来源是一个良性的备份过程，而数量较低的来源却成功入侵了一个账户并访问了敏感的凭据数据。因此，有效的 SOC 分析需要基于证据的调查、上下文推理和清晰的文档，而不是仅仅依赖于告警数量。

标签：AI合规, KQL, Microsoft Sentinel, 安全运营, 库, 应急响应, 扫描框架, 红队行动, 网络安全研究