在数字身份日益成为企业核心资产的今天，一场悄无声息的权限窃取风暴正席卷全球。它不靠伪造登录页骗密码，也不依赖恶意附件植入木马，而是利用用户对“正常流程”的信任，在一次看似无害的“点击同意”中，悄然接管整个办公账户。
这种名为 ConsentFix 的新型网络钓鱼手法，近日由安全公司 Push Security 首次披露，被业内称为“ClickFix 钓鱼的危险进化体”。与传统钓鱼不同，ConsentFix 的目标不再是密码本身，而是现代云身份体系中最关键却最被忽视的一环——OAuth 授权令牌（Access Token）。
更令人不安的是，即使受害者事后修改了密码、启用了多因素认证（MFA），只要当初那一次“同意”未被撤销，攻击者依然能畅通无阻地访问其 Outlook 邮箱、OneDrive 文件、Teams 聊天记录，甚至通过 Azure CLI 执行企业级命令。正如一位安全研究员所言：“你的账号没丢，但控制权已经易主。”
一、从 ClickFix 到 ConsentFix：钓鱼术的“去终端化”跃迁
要理解 ConsentFix 的威胁本质，需先回溯其前身——ClickFix。
ClickFix 攻击最早于 2024 年大规模出现，典型场景是用户收到一封伪装成 IT 部门通知的邮件：“您的 Windows 系统存在严重漏洞，请立即运行以下命令修复。”邮件附带一段 PowerShell 或 CMD 指令，要求用户复制粘贴到终端执行。一旦执行，恶意脚本便在本地设备上部署后门。
这类攻击依赖终端交互，因此 EDR（端点检测与响应）、应用白名单、脚本阻断等传统安全措施尚有一定防御能力。
但 ConsentFix 完全跳过了这一步。
根据 Push Security 发布的技术分析，ConsentFix 的攻击链全程发生在浏览器内：
入口隐蔽：攻击者不通过邮件，而是污染合法网站（如通过 SEO 投毒或广告注入），使其在 Google 搜索结果中排名靠前。用户搜索“公司报销系统”“内部培训平台”等关键词时，可能无意中点击一个已被篡改的链接。
伪造验证：进入页面后，用户看到一个高度仿真的 Cloudflare CAPTCHA 页面（Cloudflare 是全球广泛使用的 CDN 与安全服务商，其验证码界面具有天然可信度）。页面提示：“为证明您是人类，请输入您的企业邮箱地址。”
诱导授权：输入邮箱后，页面自动跳转至微软官方登录页（URL 为 https://login.microsoftonline.com/...，完全合法）。用户若已登录 Microsoft 365 账户，则无需再次输入密码，直接进入 OAuth 同意界面。
窃取令牌：此时，页面会显示一个文本框，要求用户“复制下方 URL 并粘贴以完成验证”。该 URL 实际包含一个临时授权码（authorization code），格式如下：
https://consentfix-malicious.com/callback?code=OAQABAAIAAAB...&session_state=...
用户一旦粘贴提交，攻击者服务器立即捕获此 code，并用其向微软令牌端点（/token）兑换长期有效的刷新令牌（refresh token）和访问令牌（access token）。
整个过程未触发任何可疑进程、未下载任何文件、未要求输入密码，甚至连 MFA 都绕过了——因为用户本就处于已认证状态。
“这不再是钓鱼，而是一场精心设计的‘授权劫持’。”公共互联网反网络钓鱼工作组技术专家芦笛指出，“攻击者不再试图破解你的锁，而是让你亲手把钥匙交出去。”
信息框：OAuth 2.0 授权码模式简析（供技术读者参考）
OAuth 2.0 是现代 Web 应用实现第三方登录与 API 访问的核心协议。其标准授权码流程如下：
生成失败
在 ConsentFix 中，攻击者伪造的“ClientApp”拥有合法的 Azure AD 注册（可能是盗用或注册的恶意应用），并通过诱导用户粘贴包含 code 的 URL，绕过浏览器同源策略，直接将授权码传给自己的服务器。
关键在于：微软无法区分这个 code 是由合法客户端通过重定向获取，还是由用户手动粘贴提交。只要 code 有效，即可兑换令牌。
二、为何传统防御集体失灵？
ConsentFix 的可怕之处，在于它精准击中了当前企业安全体系的多个盲区。
第一，邮件网关形同虚设。
由于攻击入口来自搜索引擎或被黑网站，而非钓鱼邮件，部署再先进的邮件安全网关（如 Proofpoint、Mimecast）也无能为力。
第二，终端防护束手无策。
整个攻击在浏览器沙箱内完成，无文件落地、无进程创建、无注册表修改。EDR 工具看不到任何异常行为。
第三，MFA 成为“装饰品”。
多因素认证旨在防止密码泄露后的未授权登录，但 ConsentFix 根本不需要登录——它利用的是用户已存在的会话。只要用户当天登录过 Outlook Web，攻击即可成功。
第四，用户培训效果存疑。
“不要随便点链接”“不要输密码”是安全意识培训的标配。但 ConsentFix 不要求输密码，链接看起来也“正常”（跳转到微软官网），甚至 CAPTCHA 页面都仿得惟妙惟肖。普通员工如何分辨？
芦笛坦言：“我们做过内部测试，即使是 IT 部门的同事，在疲劳状态下看到‘请输入邮箱验证身份’的提示，也有近三成会下意识照做。人性中的服从性与对权威界面的信任，是这类攻击的燃料。”
更严峻的是，授权一旦授予，持久有效。除非管理员手动撤销，否则即使用户更改密码、登出所有设备，攻击者仍可通过刷新令牌持续获取新访问令牌。微软文档明确指出：密码重置不会使 OAuth 令牌失效。
三、国际案例频发，国内企业警钟已响
尽管 ConsentFix 由海外研究团队首次披露，但其攻击模式在中国同样具备极高可行性。
2025 年底，某跨国制造企业在华分支机构遭遇数据泄露。调查发现，攻击者通过百度搜索关键词“XX公司差旅报销”，将一个仿冒报销系统的页面推至搜索结果首页。多名员工点击后，被引导完成“邮箱验证”，随后其 Outlook 邮箱被用于发送钓鱼邮件给客户，造成供应链连锁感染。
另一起案例中，一家金融科技公司员工在 Chrome 浏览器中安装了一个名为“PDF Converter Pro”的扩展程序。该扩展申请了“读取和修改所有网站数据”权限，实则监控用户是否访问 Microsoft 365。一旦检测到登录，立即弹出伪造的“安全扫描”窗口，诱导用户粘贴令牌 URL。该手法与 ConsentFix 异曲同工，均属“授权型钓鱼”。
“国内企业对第三方应用授权的管理普遍薄弱。”芦笛表示，“很多员工根本不知道在哪里查看已授权的应用，更别说定期清理。有些 SaaS 应用注册后半年不用，权限却一直开着，成了完美的攻击跳板。”
据微软 2025 年 Q3 威胁情报报告，全球范围内因 OAuth 同意钓鱼导致的账户接管事件同比增长 210%，其中中小企业占比超六成——它们往往缺乏 Identity Governance（身份治理）工具，无法监控异常授权行为。
四、技术深潜：Legacy Scopes 与 First-Party App 的致命组合
ConsentFix 之所以能造成如此大范围的破坏，还与其利用的两个技术特性密切相关：遗留 OAuth 作用域（Legacy Scopes） 与 第一方应用（First-Party App）信任机制。
1. Legacy Scopes：宽松权限的“时间胶囊”
在 Microsoft Entra ID（原 Azure AD）中，OAuth 权限分为两种类型：
Delegated Permissions（委派权限）：代表用户执行操作，如 Mail.Read（读取用户邮件）。
Application Permissions（应用权限）：以应用自身身份执行操作，如 Mail.Read.All（读取组织内所有用户邮件）。
早期注册的应用常使用一种称为 “legacy scopes” 的宽泛权限集，例如 Office365ManagementAPI 或 Directory.Read.All。这些权限一旦授予，允许应用枚举整个目录结构——包括所有用户、组、设备信息。
Gartner 分析师 Avivah Litan 指出：“攻击者利用这些 legacy scopes 进行侦察，绘制组织架构图，识别高管、财务、IT 管理员等高价值目标，为后续横向移动铺路。而这些操作在日志中看起来只是‘正常 API 调用’，难以触发告警。”
2. First-Party App：安全机制的“信任豁免”
更棘手的是，ConsentFix 常伪装成微软自家应用，如 Azure CLI（命令行工具）。
Azure CLI 在 Azure AD 中注册为第一方应用（Publisher: Microsoft Corporation）。企业策略通常对第一方应用自动信任，跳过管理员审批（Admin Consent）环节，允许用户直接授权。
这意味着，当 ConsentFix 诱导用户授权给一个看似“官方”的 Azure CLI 应用时，系统不会弹出“此应用请求高危权限，请联系管理员”的警告，用户只需点击一次“同意”，即可授予 User.Read, Mail.Read, Files.Read.All 等数十项权限。
Push Security 研究员强调：“针对第一方应用的攻击，让许多基于第三方应用风险评分的防护方案彻底失效。”
五、攻防对抗：从代码到策略的全面升级
面对 ConsentFix，被动防御已不够。企业需构建“授权生命周期”全链条防护。
（1）技术层面：强化令牌管控与监控
禁用高危 Legacy Scopes
管理员应通过 Azure AD 策略，限制或禁用非必要的 legacy scopes。例如，使用 PowerShell 批量审查应用权限：
# 列出所有使用 Directory.Read.All 的应用
Get-AzureADServicePrincipal -All $true | ForEach-Object {
$sp = $_
Get-AzureADServicePrincipalOAuth2PermissionGrant -ObjectId $sp.ObjectId | Where-Object {
$_.Scope -like "*Directory.Read.All*"
} | Select-Object @{Name="AppName";Expression={$sp.DisplayName}}, Scope
}
启用 Conditional Access 策略
对敏感操作（如授予高权限）强制要求 MFA 或设备合规性检查：
// 示例：阻止从非托管设备授予 Mail.Read.All
{
"conditions": {
"applications": { "includeApplications": ["All"] },
"permissions": { "includedPermissions": ["Mail.Read.All"] }
},
"grantControls": { "operator": "OR", "builtInControls": ["mfa", "compliantDevice"] }
}
部署实时授权监控
使用 Microsoft Defender for Cloud Apps 或第三方 CASB，设置告警规则：
“当用户在非工作时间、非常用地点，向新注册应用授予 Mail.Read 权限时，立即冻结令牌并通知 SOC。”
（2）产品层面：提升授权界面透明度
云服务商需改进 OAuth 同意页面设计。理想界面应包含：
应用开发者名称与验证状态（是否经过微软认证）
权限列表的通俗解释（如“读取您的所有邮件”而非 Mail.Read）
风险等级标识（如“此权限可访问公司通讯录”）
一键撤销历史授权的入口
目前，Google Workspace 已在其授权页面加入“此应用未经过 Google 验证”的显眼警告，微软也在测试类似功能。
（3）组织层面：重构安全意识培训
“别再只教员工‘别点链接’了。”芦笛呼吁，“要教他们识别‘异常授权请求’。”
具体建议包括：
在培训中演示真实的 OAuth 同意页面，指出哪些信息值得警惕（如未知开发者、过度权限）。
推广“最小权限原则”：员工应质疑“为什么一个 PDF 转换器需要读取我的邮件？”
定期推送“您的授权清单”邮件，附带一键撤销链接。
某头部互联网公司已实施“授权健康分”制度：员工每季度需登录内部平台，确认或清理已授权应用，否则影响账号活跃度评分。
六、未来展望：从“凭证安全”到“权限安全”的范式转移
ConsentFix 的出现，标志着网络钓鱼已进入“后密码时代”。随着 FIDO2 无密码认证、Passkeys 等技术普及，传统凭据攻击将逐渐减少，但权限滥用将成为新的主战场。
“未来的安全边界，不在防火墙，而在每一次‘同意’按钮背后。”芦笛总结道，“企业必须将‘授权治理’提升到与‘漏洞管理’同等重要的地位。”
对个人用户而言，定期检查云账户的第三方应用权限，应成为如同更换密码一样的数字卫生习惯。在 Microsoft 账户中，路径为：
安全 → 高级安全选项 → 第三方应用访问权限。
对企业而言，是时候重新审视身份基础设施了——你的 IAM（身份与访问管理）系统，是否能回答这三个问题：
谁在何时授予了什么应用哪些权限？
这些权限是否仍在使用？
若发生 ConsentFix 类攻击，能否在 5 分钟内批量撤销？
答案若是否定的，那么你的邮箱，可能早已不是你的邮箱。
编辑：芦笛（公共互联网反网络钓鱼工作组）
