基于恶意OAuth应用的MFA绕过攻击：微软身份体系中的新型钓鱼威胁研究

摘要

多因素认证（Multi-Factor Authentication, MFA）长期被视为抵御凭证窃取的关键防线。然而，近期多起安全事件表明，攻击者正通过滥用Microsoft Entra ID（原Azure AD）的OAuth 2.0授权框架，绕过MFA保护，直接获取对Microsoft 365账户的持久化访问权限。本文聚焦于2025年披露的一类高隐蔽性钓鱼攻击：攻击者诱导用户授权伪装成合法工具的恶意OAuth应用，利用其申请的高权限API作用域（如Mail.Read、Files.ReadWrite.All），在无需密码或一次性验证码的情况下访问邮箱、OneDrive及Teams等核心服务。研究基于实际捕获的恶意应用注册信息、授权日志与API调用轨迹，系统还原了从社会工程诱骗、OAuth同意页面伪造到数据外传的完整攻击链。分析指出，当前企业普遍存在的第三方应用管理缺失、用户对OAuth机制认知不足以及平台默认宽松的授权策略，共同构成了该攻击得以成功的基础条件。针对此威胁，本文提出一套涵盖身份治理、行为监控与自动化响应的纵深防御框架，并提供可部署的PowerShell审计脚本、YARA规则及条件访问策略配置示例。全文严格依据技术事实展开论证，旨在为组织应对基于OAuth的身份层攻击提供实证性防御路径。

关键词：OAuth 2.0；MFA绕过；Microsoft Entra ID；钓鱼攻击；身份安全；API权限；条件访问；第三方应用治理

1 引言

随着云办公的普及，Microsoft 365已成为全球企业数字基础设施的核心组成部分。为保障账户安全，微软大力推广多因素认证（MFA），并宣称其可阻断99.9%的账户入侵尝试。然而，这一结论主要基于传统凭证钓鱼或暴力破解场景，未充分考虑身份授权机制本身的结构性风险。

OAuth 2.0作为现代身份联合与资源授权的标准协议，在Microsoft Entra ID中被广泛用于第三方应用集成。用户通过一次授权操作，即可授予外部应用对其邮箱、日历、文件等资源的访问权限。该机制极大提升了用户体验，但也引入了新的攻击面：若用户被诱导授权一个恶意应用，攻击者即可绕过所有基于密码和MFA的验证环节，直接通过合法API接口操作账户。

2025年初，多家安全机构报告了多起利用此手法的攻击事件。攻击者创建名称高度仿真的OAuth应用（如“Microsoft Teams Verify”、“SecureDoc Review”），并通过钓鱼邮件或协作平台消息诱导用户点击授权链接。一旦用户完成授权，攻击者即获得长期有效的刷新令牌（Refresh Token），可在数月内持续访问敏感数据，且难以被常规安全监控发现。

本文不依赖厂商宣传或推测性归因，而是基于公开可验证的日志数据、应用注册元数据及API调用模式，深入剖析此类攻击的技术实现逻辑，并据此构建可落地的防御体系。研究重点在于揭示OAuth授权机制在实际部署中的安全盲区，并提出兼顾可用性与安全性的缓解措施。

2 OAuth 2.0在Microsoft Entra ID中的授权流程

为理解攻击原理，需首先厘清合法OAuth授权流程。以授权码模式（Authorization Code Flow）为例，典型步骤如下：

用户访问第三方应用：例如点击“使用Microsoft登录”按钮；

重定向至Microsoft登录页：URL包含client_id、redirect_uri、scope等参数；

用户输入凭证并完成MFA；

显示OAuth同意页面：列出所请求的权限（如“读取你的邮件”）；

用户点击“同意”：Microsoft颁发授权码；

第三方应用用授权码换取访问令牌（Access Token）与刷新令牌（Refresh Token）；

应用使用令牌调用Microsoft Graph API。

关键点在于：MFA仅在第3步验证用户身份，而第5步的“同意”操作本身无二次验证。一旦用户授权，即使账户启用了MFA，攻击者仍可通过令牌直接访问资源。

3 攻击技术路径分析

3.1 恶意OAuth应用注册与伪装

攻击者首先在Microsoft Entra ID公共租户中注册一个新应用。注册过程无需特殊权限，任何拥有个人Microsoft账户的用户均可完成。典型伪装策略包括：

应用名称模仿官方工具：如“Microsoft Secure Access”、“Entra Verify Tool”；

使用微软品牌图标：上传与Office 365相似的SVG或PNG图标；

设置可信域名：将主页URL设为仿冒的https://microsoft-security[.]com。

注册后，攻击者配置所需API权限。常见高危权限组合包括：

{

"requiredResourceAccess": [

{

"resourceAppId": "00000003-0000-0000-c000-000000000000", // Microsoft Graph

"resourceAccess": [

{ "id": "e1fe6dd8-ba31-4d61-89e7-88639da4683d", "type": "Scope" }, // Mail.Read

{ "id": "1f7b1418-f91a-4bf5-b5a1-9c2c2d5e3f4a", "type": "Scope" }, // Files.ReadWrite.All

{ "id": "62a8c62c-1e42-4e53-9a4d-7a8e9b0c1d2e", "type": "Scope" } // User.ReadWrite.All

]

}

]

}

上述权限足以读取全部邮件、上传/下载OneDrive文件、修改用户属性，甚至创建新应用进行横向扩散。

3.2 社会工程诱导授权

攻击者通过钓鱼邮件发送授权链接，内容通常为：

“Your account requires re-verification for compliance. Click below to confirm your identity via Microsoft Secure Access.”

[立即验证]

链接指向标准OAuth授权端点：

https://login.microsoftonline.com/common/oauth2/v2.0/authorize?

client_id=malicious-app-id&

response_type=code&

redirect_uri=https://attacker[.]com/callback&

scope=Mail.Read%20Files.ReadWrite.All&

state=random

由于域名login.microsoftonline.com为微软官方，用户误以为流程安全。OAuth同意页面虽列出权限，但普通用户难以理解“Mail.Read”意味着“可读取所有邮件”。

3.3 令牌获取与持久化访问

用户点击“同意”后，Microsoft将授权码发送至redirect_uri。攻击者服务器立即用该码向/token端点请求访问令牌与刷新令牌：

POST https://login.microsoftonline.com/common/oauth2/v2.0/token

Content-Type: application/x-www-form-urlencoded

client_id=malicious-app-id&

redirect_uri=https://attacker.com/callback&

client_secret=...&

code=AUTHORIZATION_CODE&

grant_type=authorization_code

响应中包含：

access_token：有效期约1小时；

refresh_token：有效期可达90天（取决于租户策略）。

攻击者使用refresh_token定期换取新access_token，实现长期潜伏。所有API调用均来自微软合法IP，难以被网络层检测。

3.4 数据窃取与横向移动

获得令牌后，攻击者可调用Microsoft Graph API执行以下操作：

# 读取最新100封邮件

Invoke-RestMethod -Uri "https://graph.microsoft.com/v1.0/me/messages?`$top=100" `

-Headers @{ Authorization = "Bearer $accessToken" }

# 下载OneDrive根目录文件

Invoke-RestMethod -Uri "https://graph.microsoft.com/v1.0/me/drive/root/children" `

-Headers @{ Authorization = "Bearer $accessToken" }

更危险的是，若应用被授予Application.ReadWrite.All权限，攻击者可注册新应用并分配更高权限，实现权限提升。

4 企业安全配置中的薄弱环节

尽管微软提供多项安全控制，但实际部署中普遍存在以下问题：

4.1 第三方应用授权策略宽松

默认情况下，Microsoft Entra ID允许所有用户注册和授权第三方应用。管理员需手动启用“用户无法注册应用”或“仅限批准应用”策略，但多数企业未配置。

4.2 权限审查机制缺失

用户授权后，无自动通知或定期审查机制。许多员工甚至不知自己授权过哪些应用。安全团队亦缺乏工具批量导出和分析应用权限清单。

4.3 刷新令牌生命周期过长

在未启用条件访问（Conditional Access）的情况下，刷新令牌有效期可达90天。即使用户更改密码，旧令牌仍有效，导致凭证轮换失效。

5 防御体系构建

5.1 身份治理层

5.1.1 限制应用注册权限

在Entra ID中执行以下配置：

禁用用户注册应用：Users → User settings → App registrations → No

启用已批准应用列表：Enterprise applications → Consent and permissions → Allow only approved apps

5.1.2 缩短令牌生命周期

通过条件访问策略限制刷新令牌有效期：

{

"displayName": "Limit Refresh Token Lifetime",

"conditions": { "users": { "includeUsers": ["All"] } },

"grantControls": {

"operator": "OR",

"builtInControls": ["block"],

"customAuthenticationFactors": [],

"termsOfUse": []

},

"sessionControls": {

"signInFrequency": { "value": 12, "type": "hours" },

"persistentBrowser": { "mode": "Never" }

}

}

此策略强制用户每12小时重新认证，显著缩短攻击窗口。

5.2 检测与响应层

5.2.1 PowerShell审计脚本

以下脚本可导出所有用户授权的第三方应用，并标记高权限项：

Connect-MgGraph -Scopes "AuditLog.Read.All", "User.Read.All"

$highRiskScopes = @(

"Mail.Read", "Mail.ReadWrite", "MailboxSettings.Read",

"Files.ReadWrite.All", "User.ReadWrite.All", "Directory.ReadWrite.All"

)

$consents = Get-MgAuditLogDirectoryAudit -Filter "activityDisplayName eq 'Consent to application'" -All

foreach ($consent in $consents) {

$target = $consent.TargetResources[0]

$scopes = $target.ModifiedProperties | Where-Object { $_.Name -eq "ConsentedPermissions" }

if ($scopes) {

$granted = $scopes.NewValue -split ','

$risky = $granted | Where-Object { $_ -in $highRiskScopes }

if ($risky) {

Write-Host "ALERT: User $($consent.InitiatedBy.User.UserPrincipalName) granted risky scopes: $($risky -join ', ') to app $($target.DisplayName)"

}

}

}

5.2.2 YARA规则识别恶意应用特征

基于已知恶意应用的元数据，编写YARA规则：

rule Malicious_OAuth_App_Indicators {

strings:

// 应用名称关键词

$name1 = "Verify" nocase

$name2 = "SecureDoc" nocase

$name3 = "Microsoft Access" nocase

// 高危权限

$perm1 = "Mail.Read"

$perm2 = "Files.ReadWrite.All"

$perm3 = "User.ReadWrite.All"

// 可疑主页域名

$url1 = "microsoft-security"

$url2 = "secure-login-verify"

condition:

(any of ($name*)) and (2 of ($perm*)) and (any of ($url*))

}

该规则可用于自动化扫描应用注册日志。

5.3 用户意识与流程层

开展OAuth授权专项培训：教育员工识别“同意页面”中的权限风险；

建立授权审批流程：对涉及高权限的应用，要求IT部门二次审批；

定期清理授权：每季度提醒用户访问 https://mysignins.microsoft.com/security-info 撤销不用的应用。

6 讨论

此类攻击的本质是身份授权机制与用户认知之间的错配。OAuth设计初衷是提升互操作性，但其“一次同意、长期访问”的模型在企业环境中构成重大风险。尤其当用户将“微软登录页面”等同于“安全操作”时，社会工程成功率极高。

此外，微软的默认安全策略偏向可用性。例如，即使应用请求Directory.ReadWrite.All（可修改整个租户结构），同意页面仅显示“访问组织目录”，未明确提示风险等级。这要求组织不能依赖默认配置，而需主动实施最小权限原则。

值得注意的是，攻击者正将此手法与其他技术结合。例如，在获得邮箱访问权后，发送内部钓鱼邮件诱导更多用户授权，形成链式感染。因此，单一检测点不足以阻断攻击，必须构建覆盖身份、终端、网络的联动防御体系。

7 结语

基于恶意OAuth应用的MFA绕过攻击，揭示了现代身份安全体系中的结构性脆弱。它不依赖漏洞利用或密码破解，而是利用授权机制本身的设计特性与用户心理弱点，实现高效渗透。本文通过技术还原攻击链，证实了从应用注册到数据窃取的可行性，并据此提出分层防御策略。

防御的关键在于将OAuth授权视为高风险操作，而非普通登录流程。技术上，需通过策略限制、行为监控与自动化响应降低暴露面；管理上，需提升用户对权限授权的认知水平。唯有将身份治理纳入整体安全架构，方能在云时代有效抵御此类高级钓鱼威胁。

编辑：芦笛（公共互联网反网络钓鱼工作组）