j-dahl7/oauth-redirect-abuse-sentinel

# OAuth 重定向滥用检测实验室 这是一个部署 Microsoft Sentinel 检测内容以防范 OAuth 重定向滥用的实操实验室， 明确开启了可选的 Entra 强化功能——即 Microsoft 在其 [2026 年 3 月安全公告](https://www.microsoft.com/en-us/security/blog/2026/03/02/oauth-redirection-abuse-enables-phishing-malware-delivery/)中描述的技术。 **成本：** 使用现有的 Sentinel 工作区；数据接入、保留和 许可费用仍需照常支付。 **清理：** 删除实验室创建的 Sentinel 对象，并且仅在应用过强化的情况下， 恢复捕获的租户同意配置并删除指定的 CA 策略。 ## 验证范围 2026 年 7 月 25 日的强化修订版已通过离线 PowerShell 解析、 模拟安全测试以及 KQL/静态契约审查进行了检查。该版本未部署到任何 租户，未进行实时的 Graph 强化调用，也未针对此修订版验证任何实时的 Sentinel 查询或事件。规则输出取决于目标 工作区的 `SigninLogs`/`AuditLogs` schema、数据连接器、数据量以及 接入延迟。 ## 部署内容 | 资源 | 类型 | 详情 | |---|---|---| | 4 个分析规则 | Sentinel Scheduled | 高风险登录后的 OAuth 同意、可疑重定向 URI、OAuth 错误模式、批量同意 | | 1 个工作簿 | Azure Workbook | OAuth 安全仪表板（同意时间线、错误模式、URI 更改、热门应用） | | 可选的同意策略更改 | Entra ID | 租户授权策略更新；仅在指定 `-ApplyHardening` 时应用 | | 可选的 CA 策略 | Entra ID | 报告模式(Report-only)的逐步验证策略；仅在指定 `-ApplyHardening` 时创建/更新 | | 5 个搜寻查询 | KQL 文件 | 委托权限审计、非企业 IP、新增高权限应用、URI 清单、令牌重放 | | 1 个审计脚本 | PowerShell | 枚举所有 OAuth 应用的可疑重定向 URI 和过高权限 | ## 前置条件 - 具备现有 **Microsoft Sentinel** 工作区的 Azure 订阅 - 已配置 Azure CLI (`az login`) - PowerShell 7+ (`pwsh`) - 拥有工作区的 **Microsoft Sentinel Contributor** 或等效的规则/工作簿写入 权限 - 拥有默认只读 OAuth 审计所需的 **Application.Read.All** Graph 权限 （可通过 `-SkipAudit` 跳过审计） - 仅在明确使用 `-ApplyHardening` 时，才需要 **Conditional Access Administrator** 以及所需的 Graph 策略写入权限 - 在应用仅报告模式的 CA 策略前，需准备好通过 `-ExcludedUserIds` 传递的紧急访问账户的确切 Entra 对象 ID 现有的 Sentinel 工作区是一个共享目标。部署会在该工作区中创建或 更新规则和工作簿。Entra 强化功能默认**关闭**，因为 同意策略的更改是全租户范围的，且 CA 策略将应用于除你明确排除的对象 ID 之外的 所有用户。 ## 快速开始 ### 1. 克隆仓库 ``` git clone https://github.com/j-dahl7/oauth-redirect-abuse-sentinel.git cd oauth-redirect-abuse-sentinel ``` ### 2. 部署 首先进行预览： ``` ./scripts/Deploy-Lab.ps1 ` -ResourceGroup "rg-sentinel-lab" ` -WorkspaceName "law-sentinel-lab" ` -WhatIf ``` 默认部署会写入四个 Sentinel 规则和工作簿，然后 执行只读的 Graph 审计并在本地生成 `oauth-audit-report.csv`。它不会 应用租户强化： ``` ./scripts/Deploy-Lab.ps1 -ResourceGroup "rg-sentinel-lab" -WorkspaceName "law-sentinel-lab" ``` 如需跳过审计及其本地 CSV 文件： ``` ./scripts/Deploy-Lab.ps1 -ResourceGroup "rg-sentinel-lab" -WorkspaceName "law-sentinel-lab" -SkipAudit ``` 在捕获当前的同意策略集合、验证 租户、审查报告模式的影响，并确定紧急访问账户的 对象 ID 之后，方可选择启用强化： ``` ./scripts/Deploy-Lab.ps1 ` -ResourceGroup "rg-sentinel-lab" ` -WorkspaceName "law-sentinel-lab" ` -ApplyHardening ` -ExcludedUserIds @("","") ``` 该脚本会： 1. 验证 Sentinel 工作区是否存在以及是否启用了 Sentinel 2. 通过 Sentinel REST API 部署 4 个计划分析规则 3. 部署 OAuth 安全仪表板工作簿 4. 仅在存在 `-ApplyHardening` 时应用 OAuth 强化 5. 除非存在 `-SkipAudit`，否则运行 OAuth 应用审计并保存 CSV 报告 `-WhatIf` 会执行发现/读取调用，但会跳过受保护的云端写入、租户 强化、临时请求体文件以及审计/CSV。它不会验证 KQL 结果或 CA 影响。`-SkipHardening` 仅作为已弃用的 兼容性开关保留；未指定 `-ApplyHardening` 是常规的安全默认设置。 分析规则和工作簿使用确定性工作区范围内的 ID 以及 显式的所有权标记。如果遇到同名资源或标记不匹配的确定性 ID，部署将会安全终止，而不会进行覆盖。 当前的部署参数有 `-ResourceGroup`、`-WorkspaceName`、 `-ApplyHardening`、`-ExcludedUserIds`、`-SkipHardening`（已弃用）、 `-SkipAudit`、`-Destroy` 以及 PowerShell 通用的 `-WhatIf` 开关。 ### 3. 验证部署 打开 **Microsoft Defender portal** > **Microsoft Sentinel** > **Analytics**： - 你应该能看到 4 个以“LAB -”为前缀的新规则 - 所有规则都应显示为已启用且类型为 Scheduled 打开 **Workbooks**： - 在列表中找到“OAuth Security Dashboard” ## 分析规则 ### 规则 1：高风险登录后的 OAuth 同意 (高) 将 15 分钟时间窗口内的 `SigninLogs` 风险指标与 `AuditLogs` 同意事件进行关联。 **MITRE:** T1566.002 (Spearphishing Link) ### 规则 2：注册了可疑的 OAuth 重定向 URI (中) 监控应用注册中添加到隧道服务、免费托管、URL 缩短器或非 HTTPS 端点的重定向 URI。 **MITRE:** T1098 (Account Manipulation) ### 规则 3：基于 OAuth 错误的重定向模式 (高) 检测与重定向滥用最密切相关的 Entra 错误。最强的信号是 `AADSTS65001` 和 `AADSTS65004`；当其他 OAuth 失败集中在同一个应用和时间窗口周围时，它们会被包含在内作为辅助上下文。 **MITRE:** T1566.002 (Spearphishing Link), T1204.001 (User Execution: Malicious Link) ### 规则 4：对单个应用的大量 OAuth 同意 (高) 当 3 个或更多用户在 1 小时内同意同一个应用时触发。 **MITRE:** T1566.002 (Spearphishing Link) ## 搜寻查询 将 `detection/hunting-queries.kql` 中的查询导入到 Sentinel Hunting 中： | 搜寻 | 目的 | 回溯期 | |---|---|---| | 1. 枚举委托权限 | 对所有用户授予的权限进行基准审计 | 90 天 | | 2. 非企业 IP 登录 | 来自意外位置的 OAuth 应用身份验证 | 30 天 | | 3. 新的高权限应用 | 注册了敏感作用域的近期应用 | 14 天 | | 4. 重定向 URI 清单 | 重定向 URI 更改的完整审计跟踪 | 90 天 | | 5. 错误后的令牌重放 | 错误重定向后紧接着来自不同 IP 的成功验证 | 7 天 | **搜寻 2** 需要自定义——将 `CorporateNetworks` 变量替换为你组织的 IP 范围。 ## 强化策略 ### 用户同意限制 `Set-OAuthHardening.ps1` 脚本将用户同意限制为： - 仅限**低风险权限**（例如 `User.Read`、`openid`、`profile`） - 来自**经过验证的发布者**和受信任的租户自有工作流的应用 - 其他所有情况均需**管理员批准** - 更新策略时，现有的 `managePermissionGrantsForOwnedResource.*` 条目将被保留 这会更新租户的授权策略，而不是实验室范围内的资源。 在应用之前，请记录完整的原始 `permissionGrantPoliciesAssigned` 集合。 脚本之后无法推断所需的回滚状态。 ### 条件访问策略 创建一个报告模式的实验室 CA 策略，该策略在以下情况适用： - 登录风险为中或高 - 授予控制要求 **MFA** - 会话登录频率设置为**每次** 在强制执行之前，请对该策略进行为期 7 天的审查。 ### OAuth 应用审计 独立运行审计： ``` ./hardening/Audit-OAuthApps.ps1 -OutputPath "./oauth-audit-report.csv" ``` 该审计会检查每个应用注册的： - 可疑重定向 URI 域名（ngrok、herokuapp、workers.dev 等） - 非 HTTPS 重定向 URI（排除 localhost） - 高权限委托权限（Mail.Read、Files.ReadWrite.All 等） - 用户同意与管理员同意的权限 - 多租户应用注册 输出为按风险评分排序的 CSV。 ## 文件结构 ``` oauth-redirect-abuse-sentinel/ ├── README.md # This file ├── detection/ │ ├── analytics-rules.kql # 4 Sentinel analytics rules (full KQL) │ └── hunting-queries.kql # 5 proactive hunting queries ├── hardening/ │ ├── Set-OAuthHardening.ps1 # Consent restriction + CA policy │ └── Audit-OAuthApps.ps1 # OAuth app security audit └── scripts/ └── Deploy-Lab.ps1 # Main deployment orchestrator ``` ## 清理 ### 删除 Sentinel 资源 首先预览受保护资源的清理： ``` ./scripts/Deploy-Lab.ps1 ` -ResourceGroup "rg-sentinel-lab" ` -WorkspaceName "law-sentinel-lab" ` -Destroy ` -WhatIf ``` 然后删除此实验室拥有的四个分析规则和工作簿： ``` ./scripts/Deploy-Lab.ps1 ` -ResourceGroup "rg-sentinel-lab" ` -WorkspaceName "law-sentinel-lab" ` -Destroy ``` 在发出第一次删除请求之前，清理操作会验证每个确定性资源 ID 和所有权标记。 它会拒绝同标题的外部对象，以及不可变 ID、标题/显示名称或标记不匹配的 资源。旧版随机 ID 修订版中的遗留对象不会被强行接管或删除；请 仅在验证其不可变 ID 和内容后，手动审查并删除这些对象。 ### 删除强化（如果已应用） **还原同意策略：** 恢复在应用 实验室之前捕获的完整 `permissionGrantPoliciesAssigned` 集合。请勿使用猜测的单个值替换它，也不要丢弃现有的 `managePermissionGrantsForOwnedResource.*` 条目。 **删除 CA 策略：** ``` az rest --method DELETE ` --url 'https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies/' ``` 使用部署返回的不可变策略 ID，并首先验证其 显示名称、报告模式状态、条件、排除项和来源是否与 本实验室匹配。清理操作不会删除 `oauth-audit-report.csv`；请根据该 本地报告可能包含的敏感租户清单内容妥善处理。 ## 故障排除 ### 规则未触发 分析规则需要 `SigninLogs` 和 `AuditLogs` 中有匹配的数据。如果你的租户中没有 OAuth 同意事件或高风险登录， 规则将不会触发。请通过以下方式进行测试： 1. 注册一个包含 `webhook.site` 重定向 URI 的测试应用（触发规则 2） 2. 检查 `AuditLogs` 是否包含“Add application”事件 ### 工作簿不显示数据 确保工作区已启用 `AuditLogs` 和 `SigninLogs` 数据连接器。检查： ``` AuditLogs | take 1 SigninLogs | take 1 ``` ### 强化脚本失败 强化脚本需要 **Conditional Access Administrator** 角色和 **Policy.ReadWrite.ConditionalAccess** Graph 权限。使用 `-WhatIf` 运行以预览更改： ``` ./hardening/Set-OAuthHardening.ps1 -WhatIf ``` ## 资源 - [博客：使用 Microsoft Sentinel 和 Entra ID 检测 OAuth 重定向滥用](https://nineliveszerotrust.com/blog/oauth-redirect-abuse-sentinel/) - [Microsoft 安全博客：OAuth 重定向滥用（2026 年 3 月 2 日）](https://www.microsoft.com/en-us/security/blog/2026/03/02/oauth-redirection-abuse-enables-phishing-malware-delivery/) - [Microsoft 身份平台：授权码流程](https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-auth-code-flow) - [Microsoft：配置用户同意设置](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/configure-user-consent) - [Microsoft：针对高风险登录的条件访问](https://learn.microsoft.com/en-us/entra/id-protection/howto-identity-protection-configure-risk-policies) - [Azure Monitor 日志参考：SigninLogs](https://learn.microsoft.com/en-us/azure/azure-monitor/reference/tables/signinlogs) - [KQL 参考](https://learn.microsoft.com/en-us/kusto/query/)

标签：AI合规, AMSI绕过, Azure Sentinel, IPv6, KQL, Libemu, OAuth2, PowerShell, 威胁检测, 网络安全, 身份安全, 隐私保护