shank078/azure-identity-security-lab

# 🔐 Azure 身份安全与事件响应实验室 ### *一场完整的红队入侵与蓝队恢复——由一人完成构建、破坏与修复。*    ## 这个项目是什么（以及我为什么构建它） 大多数云安全内容教你如何*配置*东西。这个项目是关于当仅靠配置不够时会发生什么。 我设计这个实验室是为了模拟一个真实的企业 Microsoft Entra ID 环境，然后使用一种绕过大多数组织认为坚不可摧的控制措施的技术来故意攻击它：**MFA**。目标是在技术和操作层面上，准确理解攻击者如何利用*启用*安全控制和*强制执行*安全控制之间的漏洞。 这不是一个 CTF 演练。每一个决定都反映了一个现实世界的场景：预算限制、身份架构权衡、事件响应的紧迫性，以及经得起审查的审计追踪的重要性。 ## 技术栈 | 层级 | 技术 | |---|---| | 云服务提供商 | Microsoft Azure | | 身份平台 | Microsoft Entra ID (原 Azure AD) | | 安全控制 | 多因素身份验证 (MFA)，安全组，RBAC | | 监控 | Entra ID 登录日志，审计日志，Identity Protection | | 攻击工具 | VPN (地理欺骗)，私有会话劫持 | ## 完整故事：为期 15 天的安全冲刺 这个实验室分为五个阶段运行。每个阶段都直接建立在上一个阶段之上。 ### 🏗️ 阶段 1 — 环境设置 每个安全环境都始于坚实的身份基础。我配置了一个专用的实验室目录，并从第一天起就确立了两个不同的用户角色： - **管理员账户** — 拥有提升的权限，仅用于管理任务 - **标准用户** — 作为攻击目标的最小权限员工账户 我还为策略目标配置了一个专用的**安全组**，从一开始就保持任何更改的爆炸半径受控且可审计。 **我立刻遇到的真实世界限制：** Azure 的免费层不提供 Conditional Access。那是 Premium P2 的功能。我没有搁置这个项目，而是记录了这个障碍并进行了转向——这正是工程师在生产环境中当预算与安全路线图不匹配时会做的事情。 **创建管理员和标准用户账户**  **设置用于策略目标的安全组**  **租户创建障碍——被记录下来，而非被隐藏**  ### 🔒 阶段 2 — 身份加固 环境配置完成后，我转向了加固。这就是免费层限制迫使做出真实工程决策的地方。 **“免费层”转向：** Conditional Access——强制执行 MFA 策略的黄金标准——被挡在了 P2 许可证墙之后。因此，我改为实施**按用户 MFA 强制执行**。这不是理想的企业解决方案，但却是一个仅使用可用工具实现的合法、有效的控制。在受限的环境中，优秀的工程师会利用他们手头的一切。 **验证：** 在进入攻击阶段之前，我确认了加固是有效的。尝试在未完成 MFA 注册的情况下登录会返回强制性的“需要更多信息”阻止。外围防线守住了——目前来说。 **Conditional Access 被锁定在 P2 之后——许可证墙**  **激活按用户 MFA 作为免费层的替代方案**  **验证“需要更多信息”阻止是否处于活动状态**  ### 💀 阶段 3 — 泄露（红队） 这是大多数组织忽略的地方：**MFA *已启用* 与 MFA *已强制执行* 是两码事。** 当用户启用了 MFA 但尚未完成注册时，就会存在一个窗口。一个很小的窗口——但最先采取行动的攻击者会获胜。 我扮演一个掌握被盗凭证的内部威胁，并准确利用了那个漏洞： **步骤 1 — MFA 劫持** 在合法用户注册自己的设备*之前*登录了目标账户。将我的身份验证器注册为主要 MFA 方法。该账户现在信任我的设备，而不是他们的。 **步骤 2 — 建立持久性** 从账户内部执行了管理员密码重置。合法用户现在被完全锁定——他们无法登录，也无法通过 MFA 恢复，因为攻击者也控制了它。 **步骤 3 — 完全账户接管 (ATO)** 完成。受害者在没有管理员干预的情况下没有任何途径可以返回。这是一种有记录的现实世界技术，用于针对 Microsoft 365 环境的商业电子邮件泄露 (BEC) 攻击活动中。 **发起劫持——攻击者视角的 MFA 设置界面**  **攻击者的设备已成功链接为受信任的 MFA 方法**  **攻击者重置密码以锁定合法用户**  ### 🔍 阶段 4 — 检测与分析（蓝队） 转换角色。我现在是刚刚收到工单的 SOC 分析师：一个用户被锁在他们的账户之外，而且不知道为什么。 **使其更加真实：** 攻击是通过位于 **Washington州西雅图** 的 VPN 出口进行的。我的合法管理员会话是从 **澳大利亚** 运行的。这种地理差距是有意为之的——这正是 Entra ID 登录日志捕获到的信号，也是训练有素的分析师知道要追踪的信号。 **调查过程：** 1. 提取了**登录日志**并针对被盗用账户进行了过滤 2. 识别出了一个**不可能的旅行**场景——同一个账户在彼此相隔几分钟的时间内从澳大利亚和西雅图进行了身份验证。如果不使用 VPN 或极快的飞机，这在物理上是不可能的。 3. 确定了准确的**攻击者 IP 地址**和恶意 MFA 注册的精确时间戳 4. 交叉比对了**审计日志**——发现了 MFA 设备的添加以及随后的密码重置 登录日志告诉我*是谁*和*在哪里*。审计日志告诉我*做了什么*。两者结合在一起，重建了整个攻击时间线。 **确凿的证据——显示从澳大利亚账户在西雅图登录的登录日志**  **在身份验证元数据中确认恶意的 MFA 注册**  ### 🛡️ 阶段 5 — 事件响应与恢复 如果没有文档化、可重复的响应，检测就毫无意义。我遵循了标准的 IR 工作流：**遏制 → 根除 → 恢复 → 文档化。** **遏制 — 全局会话撤销** 立即终止了被盗用账户上的所有活动会话。攻击者被同时踢出所有活动的门户会话——会话中途，没有警告，没有优雅的退出。 **根除 — 恶意 MFA 方法删除** 从账户的身份验证方法中移除了攻击者的设备。后门被清除了。 **恢复 — 身份恢复** 执行了最后的管理员密码重置，以使用干净的凭证将控制权交还给合法用户。 **文档化 — 审计追踪验证** 确认每项修复操作都带有准确的时间戳正确地显示在审计日志中。在真实的事件中，这就是你交给你的 CISO、法律顾问或监管机构的东西。如果它没有出现在日志中，那就等于没发生过。 **管理员撤销所有活动会话——攻击者被驱逐**  **从受信任的身份验证方法中移除攻击者的手机**  **执行最终的管理员密码重置**  **密码重置成功——账户已恢复**  **显示事件期间采取的所有管理员操作的审计日志**  ## 主要发现与经验教训 ### 1. MFA 漏洞是真实存在的——并且被广泛低估 那些启用了 MFA 就认为工作已经完成的组织留下了一扇敞开的窗户。阶段 3 中的攻击不需要任何恶意软件、任何漏洞利用和任何技术复杂性。只需时机和被盗的凭证。 **修复方法：** 在创建账户后立即强制执行**注册活动**，以便用户在攻击者之前被推动完成注册。或者使用**带有受信任位置的 Conditional Access** (P2) 来完全阻止来自未识别区域的身份验证。 ### 2. 两个日志来源。一个完整的图景。 大多数分析师提取一个日志就停在那里了。 - **登录日志** → 行为异常。不可能的旅行、不熟悉的位置、反复的失败、新的设备指纹。 - **审计日志** → 管理员操作。MFA 方法更改、密码重置、角色分配、组成员身份更改。 你需要两者来重建完整的攻击时间线。仅靠其中任何一个都会留下优秀的攻击者可以隐藏的漏洞。 ### 3. 受限的环境并不是无防御的环境 高级许可证解锁了强大的自动化功能。但是按用户 MFA、登录日志和审计日志在每一个层级都存在。这里的工具不需要任何成本。它们需要的是一个知道如何使用它们的分析师。 ## 下一步计划 这个实验室故意以手动狩猎和手动响应结束。自然的下一次迭代是自动化： - **集成 Microsoft Sentinel** — 用自动化的分析规则取代手动日志审查，这些规则会在发生不可能的旅行和 MFA 注册异常时触发 - **构建 KQL 监视列表** — 自动标记高风险 IP 范围和已知的 VPN 出口节点 - **通过 Playbook 自动化遏制** — 在检测到异常的那一刻触发全局会话撤销，将攻击者的停留时间从几小时缩短到几秒 *(这方面的基础已经上线——见我的 [Azure Sentinel Honeypot & SIEM project](https://github.com/shank078/azure-sentinel-honeypot-siem))* ## 仓库结构 ``` azure-identity-security-lab/ ├── images/ │ ├── 01_entra_user_provisioning.png │ ├── 02_security_group_configuration.png │ ├── 03_licensing_constraint_documentation.png │ ├── 04_premium_feature_restriction.png │ ├── 05_manual_mfa_enforcement.png │ ├── 06_mfa_login_verification.png │ ├── 07_attacker_mfa_registration.png │ ├── 08_unauthorized_mfa_method_added.png │ ├── 09_persistence_via_password_reset.png │ ├── 10_impossible_travel_vpn_log.png │ ├── 11_authentication_metadata_analysis.png │ ├── 12_global_session_revocation.png │ ├── 13_rogue_mfa_method_deletion.png │ ├── 14_administrative_identity_recovery.png │ ├── 15_remediation_success_confirmation.png │ └── 16_final_audit_trail_verification.png ├── documentation/ │ └── incident-response-log.md └── README.md ``` ## 如何阅读本项目 **如果您是招聘经理：** 上面的阶段结构讲述了完整的故事。如果您想直接跳到最有趣的部分，请从阶段 3（攻击）开始——每一步都有截图记录。 **如果您是安全领域的同行：** 克隆该仓库，阅读文档文件夹以了解详细的技术步骤，如果您想讨论方法论，请随时开启一个 issue。 **如果您正在构建自己的实验室：** 阶段 1 和 2 的设置在免费的 Azure 租户上是特意设计为可复现的。唯一的代价是阶段 3 中用于地理欺骗的 VPN。 ## 联系我 **LinkedIn:** [linkedin.com/in/shankarbaral1](https://linkedin.com/in/shankarbaral1) **GitHub:** [github.com/shank078](https://github.com/shank078) *对澳大利亚的初级 SOC 分析师和高级 IT 基础架构职位持开放态度。*

标签：Azure AD, Entra ID, GitHub Advanced Security, IAM, MFA绕过, RBAC, TGT, 云基础设施, 会话劫持, 多因素认证劫持, 安全加固, 安全实验, 安全靶场, 微软Azure, 攻防演练, 数据展示, 红队, 网络安全, 身份与访问管理, 身份安全, 隐私保护