Ademolacode/Microsoft-SOC-Analyst-Portfolio

GitHub: Ademolacode/Microsoft-SOC-Analyst-Portfolio

一个基于 Microsoft 365 E5 实验室的 SOC 分析师实战作品集,展示威胁检测、事件调查和跨域关联的完整方法论与可复用 KQL 规则。

Stars: 0 | Forks: 0

# Microsoft SOC Analyst 作品集 ### 跨 Microsoft 安全体系的检测、调查与事件报告 *通过使用真实 Microsoft 365 E5 工具进行的 30 天 SOC 实战模拟构建。* [![Microsoft Sentinel](https://img.shields.io/badge/Microsoft%20Sentinel-0078D4?style=for-the-badge&logo=microsoftazure&logoColor=white)](https://azure.microsoft.com/products/microsoft-sentinel/) [![Defender for Endpoint](https://img.shields.io/badge/Defender%20for%20Endpoint-5E5E5E?style=for-the-badge&logo=microsoft&logoColor=white)](https://learn.microsoft.com/microsoft-365/security/defender-endpoint/) [![Defender for Office 365](https://img.shields.io/badge/Defender%20for%20Office%20365-5E5E5E?style=for-the-badge&logo=microsoft&logoColor=white)](https://learn.microsoft.com/microsoft-365/security/office-365-security/) [![Microsoft Entra](https://img.shields.io/badge/Microsoft%20Entra-008272?style=for-the-badge&logo=microsoft&logoColor=white)](https://learn.microsoft.com/entra/) [![KQL](https://img.shields.io/badge/KQL-000000?style=for-the-badge&logo=microsoft&logoColor=white)](https://learn.microsoft.com/azure/data-explorer/kusto/query/) [![MITRE ATT&CK](https://img.shields.io/badge/MITRE%20ATT%26CK-FF0000?style=for-the-badge&logo=mitre&logoColor=white)](https://attack.mitre.org/) ## 目的 本仓库记录了在自建 Microsoft 365 E5 云实验室中完成的一项结构化 SOC 调查计划。这并非工具配置的演练——全篇重点在于**调查质量**:如何验证遥测数据、跨领域关联、测试假设,并生成对其他分析师真正有用的文档。 这里的工作也具有研究目的。每次调查都揭示了一个一致的模式:只有当来自电子邮件、身份和端点的数据结合时,最重大的威胁才可见。这一观察是一项关于基于 ML 的跨领域检测的独立研究计划的基础——请参阅下方的[相关工作](#related-work)。 ## 实验室架构 ![Lab Architecture](https://static.pigsec.cn/wp-content/uploads/repos/2026/03/5e1d63ba6f002849.png) ## 目录 - [环境概述](#environment-overview) - [调查方法](#investigation-approach) - [迷你项目 1 — SOC 基础](#mini-project-1--soc-foundation-and-visibility) - [迷你项目 2 — 电子邮件安全与网络钓鱼](#mini-project-2--email-security-and-phishing-investigation) - [迷你项目 3 — 端点检测](#mini-project-3--endpoint-detection-and-response) - [迷你项目 4 — 跨领域调查(顶点项目)](#mini-project-4--cross-domain-incident-investigation) - [KQL 查询库](#kql-query-library) - [关键发现](#key-findings) - [相关工作](#related-work) ## 环境概述 | 领域 | 实现 | |---|---| | **SIEM** | Microsoft Sentinel,包含经过验证的日志引入和自定义分析规则 | | **端点** | Defender for Endpoint — Windows 11 VM,已加入并全面监控 | | **电子邮件** | Defender for Office 365 — 已配置并测试 Safe Links 和 Anti-Phishing 策略 | | **身份** | Entra ID 登录日志、身份风险遥测、Conditional Access | | **设备管理** | Intune — ASR 策略部署与强制执行验证 | | **威胁模拟** | Atomic Red Team — MITRE ATT&CK 映射的技术执行 | | **框架** | 全程使用 MITRE ATT&CK 进行技术映射和调查上下文构建 | ## 调查方法 本实验室的每次调查都遵循相同的五步法。采用一致方法的意义在于,它能发现临时性调查所遗漏的内容——特别是在得出恶意活动结论之前测试替代假设的步骤。 1. **验证警报** — 在得出任何结论之前,确认时间戳、引入健康状况和受影响实体 2. **确定活动范围** — 识别用户、设备、时间窗口,以及活动是否可能已扩散 3. **关联遥测数据** — 在适用的情况下跨电子邮件、身份和端点进行透视;切勿止步于单一领域 4. **测试假设** — 在认定恶意解释之前,先考虑良性解释 5. **清晰记录** — 生成调查结果、时间线和建议,以便其他分析师可以直接采取行动而无需提问 ## 迷你项目 1 — SOC 基础与可见性 📂 [`mini-projects/01-soc-foundation/`](mini-projects/01-soc-foundation/) **重点:** SIEM 部署、连接器验证和基准 KQL。 ![Sentinel Workspace](https://static.pigsec.cn/wp-content/uploads/repos/2026/03/951cc12404002906.png) 2 个数据连接器处于活动状态,2/2 健康。13 条活跃的安全建议。此阶段未配置自动化规则——我想在自动化任何响应之前先理解我所看到的内容。 **我实际学到的:** 可见性需要刻意的配置。默认的 Sentinel 设置虽然会引入数据,但这并不意味着它已准备好用于调查。我花了比预期更多的时间来验证事件时间是否对齐且结构是否一致——这项基础工作对之后运行的每个查询都至关重要。 第一个有意义的信号立即出现:**EventID 4625(登录失败)每天生成数千个事件**,源自测试 VM。这成为了贯穿整个实验室的主线。 ![EventID Summary](https://static.pigsec.cn/wp-content/uploads/repos/2026/03/6bb24f0a6c002910.png) ``` // Understanding what's in the data before writing detections SecurityEvent_CL | summarize RandomCount = count() by EventID_s ``` EventID 4625 在 24 小时窗口内出现了 18,163 次。这是针对测试 VM 的模拟暴力破解活动——但对于暴露在互联网上的默认配置 Windows 机器来说,这些数字也是现实的。默认的本地管理员帐户名是自动扫描器首先尝试的目标。 ## 迷你项目 2 — 电子邮件安全与网络钓鱼调查 📂 [`mini-projects/02-email-security/`](mini-projects/02-email-security/) **重点:** 电子邮件威胁检测、策略验证、网络钓鱼模拟和调查工作流。 ### 已配置的策略 ![Safe Links Policy](https://raw.githubusercontent.com/Ademolacode/Microsoft-SOC-Analyst-Portfolio/main/screenshots/06-safelinks-policy.png) ![Anti-Phishing Policy](https://static.pigsec.cn/wp-content/uploads/repos/2026/03/f0ea052a81002947.png) **最重要的 Safe Links 设置:** 点击时(而不仅仅是投递时)进行实时 URL 扫描,以及“扫描后再投递”——这可以防止 URL 在投递时是干净的,但在用户点击前变成恶意的这种竞争条件。跟踪用户点击也已开启,这正是生成用于跨领域调查的 UrlClickEvents 数据的原因。 **在 Anti-Phishing 中发现的缺口:** 域名冒充保护已关闭。这很重要,因为本次模拟中的网络钓鱼电子邮件使用了 `officence[.]com`——如果保护 `office.com` 的冒充规则启用,就会捕获这个域名。我将其标记为一项整改项。 ### 网络钓鱼模拟 **攻击时间线:** ![Phishing Timeline](https://static.pigsec.cn/wp-content/uploads/repos/2026/03/65f7e0c46c002950.png) **模拟电子邮件:** ![Phishing Email](https://static.pigsec.cn/wp-content/uploads/repos/2026/03/ecfc359866003003.png) 电子邮件来自 `user@officence[.]com`——一个 `office.com` 的仿冒域名。Outlook 部分阻止了内容(发件人不受信任),但将邮件投递到了收件箱。这是真实的 MDO 默认行为:投递并附带警告,而不是直接隔离。 **用户点击:** ![David Clicked](https://static.pigsec.cn/wp-content/uploads/repos/2026/03/c7a2671b5c003009.png) David Book 点击了链接。Safe Links 拦截了它并重定向到一个培训页面。这就是真实攻击与模拟的分叉点:如果没有 Safe Links,用户将落在凭据收集页面上,调查将立即转移到身份领域,以寻找来自异常 IP 的成功登录。 **仅凭电子邮件域能告诉我的:** 一个可疑 URL 被点击了。仅此而已。如果不关联到身份领域,就无法确认凭据是否被盗。 📄 [完整网络钓鱼调查报告](mini-projects/02-email-security/investigation-report.md) ## 迷你项目 3 — 端点检测与响应 📂 [`mini-projects/03-endpoint-detection/`](mini-projects/03-endpoint-detection/) **重点:** 端点遥测、ASR 规则验证、对手模拟、警报调查。 ### VM 已加入 ![VM Onboarded](https://static.pigsec.cn/wp-content/uploads/repos/2026/03/4916e9998e003014.png) `mydfir` 已成功加入。风险等级返回为 Medium——2 个活动警报,1 个事件——这是预期的,因为在完整的 MDE 配置完成之前,该设备已用于生成攻击模拟遥测。我首先检查了设备时间线,以了解 MDE 已经看到了什么。 ### ASR 规则 ![ASR Policy](https://static.pigsec.cn/wp-content/uploads/repos/2026/03/648a2b1f82003020.png) 通过 Intune 部署了配置了 ASR 规则的 `MyDFIR-Cyber-Policy`。截图时,设备分配仍处于待定状态。我在此注意到了一点:**ASR 规则应通过遥测进行验证,而非假设其有效**。在 Intune 中显示为已创建的策略与实际上在设备上强制执行的策略是两回事。我通过在重启后观察 MDE 门户中的阻止事件确认了强制执行。 **端点阶段的关键洞察:** 编码的 PowerShell 命令与实际恶意意图之间的关系。命令本身(Get-LocalUser、Get-ChildItem、Compress-Archive)单独来看并不恶意——管理员会例行运行它们。只有当你拥有来自身份领域的身份验证上下文时,恶意上下文才会变得清晰。这就是最简单形式的“靠土地维生”(Living-off-the-land)检测问题。 📄 [完整端点调查报告](mini-projects/03-endpoint-detection/investigation-report.md) ## 迷你项目 4 — 跨领域事件调查 📂 [`mini-projects/04-cross-domain-investigation/`](mini-projects/04-cross-domain-investigation/) **重点:** 跨电子邮件、身份和端点的端到端攻击重建。这是顶点项目。 ### 事件 24 — 人工键盘攻击 ![Incident 24](https://static.pigsec.cn/wp-content/uploads/repos/2026/03/0312b73aac003022.png) ![User Contained](https://static.pigsec.cn/wp-content/uploads/repos/2026/03/2c1c7ad60b003026.png) Defender XDR 将 58 个单独的警报关联为一个 HIGH 严重性事件:勒索软件行为、横向移动、人工键盘攻击分类。David Book 用户卡片上的 `CONTAINED` 徽章显示自动攻击中断已被触发——会话被撤销,访问受限。 ### 根本原因 **David Book 的 MFA 被禁用了。** 这不是一个微妙的发现。这意味着从网络钓鱼模拟中收集凭据的那一刻起,攻击者就拥有了无争议的访问权限。攻击的每个后续阶段——风险登录、PowerShell 执行、持久化尝试、横向移动——完全取决于这一单一控制的缺失。 Conditional Access 最终阻止了进一步访问(错误 53003): ![CA Policy Log](https://static.pigsec.cn/wp-content/uploads/repos/2026/03/f7ee5fc4a4003031.png) 但这发生在*破坏造成之后*。Conditional Access 是一个有用的层,但它不能替代 MFA——它是 MFA 的补充。 **这对检测研究为何重要:** 如果没有跨领域关联,事件 24 看起来就像是三个独立的中等严重性警报。电子邮件域中的网络钓鱼点击。身份域中的风险登录。端点域中的可疑进程执行。单独来看都不紧急。合在一起,它们就是确认的人工键盘攻击。关联性使威胁变得可见——而这正是我的研究计划旨在使用基于 ML 的方法形式化的具体问题。 📄 [完整跨领域调查报告](mini-projects/04-cross-domain-investigation/investigation-report.md) ## KQL 查询库 📂 [`kql/`](kql/) 本次挑战中使用的所有查询,均附带了每个查询正在测试的假设说明。 ``` -- Failed logon volume triage SecurityEvent_CL | summarize Count = count() by EventID_s ``` ``` -- Top targeted accounts (brute force identification) SecurityEvent_CL | where EventID_s == "4625" | summarize Count = count() by Account_s | sort by Count desc | take 10 ``` ``` -- Cross-domain: phishing click to authentication anomaly -- Joins UrlClickEvents (email) to SignInLogs (identity) on shared UPN -- Full query: kql/cross-domain-phishing-to-auth.kql ``` ``` -- Cross-domain: password spray to confirmed compromise -- Three-stage chain: spray pattern → successful auth from spray IP → endpoint activity -- Full query: kql/cross-domain-spray-chain.kql ``` ``` -- Cross-domain: LOLBAS commands with authentication risk context -- Joins DeviceProcessEvents to SignInLogs — only surfaces commands by accounts -- with anomalous recent authentication (the precondition for LOLBAS detection) -- Full query: kql/cross-domain-lolbas-context.kql ``` ## 关键发现 | 发现 | 证据 | 意义 | |---|---|---| | 单领域检测存在结构性限制 | 电子邮件、身份和端点各自只看到了同一攻击的片段 | 关联不是锦上添花——它是使某些威胁可见的机制 | | MFA 缺失是关键故障 | 事件 24 的发展完全归因于 David Book 帐户上的 MFA 被禁用 | MFA 是影响最大的单一身份控制;其他一切都是在它之上的层级 | | CA 策略生效了——但太晚了 | 攻击发展后记录了错误 53003 | Conditional Access 补充了 MFA;它不能替代 MFA | | 仅从端点无法检测 LOLBAS 命令 | 事件 24 中使用的 PowerShell 与管理员活动无法区分 | 来自身份领域的身份验证上下文是检测的前提条件,而非改进 | | Anti-Phishing 中的域名冒充缺口 | 如果启用了域名冒充保护,`officence[.]com` 本会被捕获 | 策略覆盖范围需要验证,而非假设 | ### 我会做得不同的地方 1. **在任何其他实验室配置之前启用 MFA。** 它应该是任何环境中的第一个控制措施,而不是事后补救。 2. **从第一天起就启用域名冒充保护。** 网络钓鱼模拟部分成功是因为这被关闭了。 3. **在运行攻击模拟之前构建跨领域 KQL 规则。** 先运行模拟然后编写检测规则意味着规则从未针对未知数据进行测试——这是一种较弱的验证。 ## 相关工作 本实验室与基于同一环境构建的另外两个仓库相关联: **[Microsoft-SOC-Analyst-Portfolio](https://github.com/Ademolacode/Microsoft-SOC-Analyst-Portfolio)** — 源于本次挑战的跨领域检测研究工作。包含具有文档化假设的正式 KQL 检测规则、配对的单领域与跨领域比较,以及为研究背景构建的完整调查报告。 **[AI-SOC-Automation](https://github.com/Ademolacode/AI-SOC-Automation)** — Splunk SIEM 集成,包含自动检测工作流和 Atomic Red Team 验证。 本次挑战中持续观察到的模式——个别信号单独看是模棱两可的,但综合来看则是确定性的——是关于网络系统中基于 ML 的行为威胁检测的博士研究计划的操作动机。研究计划可应要求提供。 仓库结构 ``` microsoft-soc-analyst-portfolio/ ├── README.md ├── screenshots/ ← Annotated evidence + generated diagrams │ ├── diagram-lab-architecture.png │ ├── diagram-phishing-timeline.png │ ├── diagram-brute-force.png │ ├── diagram-incident24.png │ └── [annotated screenshots 01–16] ├── kql/ ← All queries with hypotheses │ ├── cross-domain-phishing-to-auth.kql │ ├── cross-domain-spray-chain.kql │ └── cross-domain-lolbas-context.kql └── mini-projects/ ├── 01-soc-foundation/ ├── 02-email-security/ ├── 03-endpoint-detection/ └── 04-cross-domain-investigation/ ``` *MyDFIR 30 天 Microsoft SOC Analyst 挑战 · 2025 年 1 月至 2 月完成* *Ademola Oniyinde · 安全运营分析师 · demola.adeayo@gmail.com*
标签:AMSI绕过, Azure AD, Cloudflare, Defender for Endpoint, Defender for Office 365, KQL, Kusto 查询语言, Microsoft 365 E5, Microsoft Entra, Microsoft Sentinel, MITRE ATT&CK, 作品集, 威胁检测, 安全实验室, 安全运营中心, 库, 应急响应, 端点安全, 网络安全, 网络映射, 补丁管理, 调查报告, 身份安全, 速率限制, 邮件安全, 隐私保护