随着人们逐渐意识到许多多因素身份验证（MFA）方式仍然容易被钓鱼攻击（即不具备抗钓鱼能力），无密码、基于 FIDO2 的身份验证方式（也称为“通行密钥”，如 YubiKeys、Okta FastPass 和 Windows Hello）正受到越来越多的推崇。

这本是一件好事。因为像短信验证码、推送通知、基于应用的动态密码（OTP）等常见的 MFA 手段，早已被攻击者轻松绕过。其中最常见的方式就是“中间人攻击（AitM）”钓鱼工具包——这是当前钓鱼攻击的主流选择。它的攻击原理是：当受害者输入密码并完成 MFA 验证后，攻击者截获生成的认证会话。这类钓鱼网站会将用户与真实网站之间的消息传递中继，从而完成“中间人攻击”。

但通行密钥登录方式就不会被钓鱼。因为通行密钥是绑定到特定域名的，比如你无法在 phishing.com 上使用为 microsoft.com 生成的通行密钥，即使中继了信息也无法生成正确的认证凭据。

然而，攻击者并没有就此放弃。随着通行密钥逐渐普及，我们已经观察到一些专门针对这类抗钓鱼认证流程的攻击手段，这些手段试图“降级”或绕过认证，以实现钓鱼攻击。

下面是目前已知攻击者用来绕过通行密钥的方法。

降级攻击（Downgrade Attacks）

降级攻击是攻击者绕过抗钓鱼 MFA 的首选方式。许多犯罪型 AitM 工具包中都包含了 MFA 降级功能，即便是一些开源工具如 Evilginx 也能做到。

攻击者在实施 AitM 攻击时，并不需要中继所有内容。他们可以修改某些交互内容。例如，应用原本提示：“你需要 MFA 验证——选择使用通行密钥或备用验证码？”而钓鱼网站则会将页面修改为：“你需要 MFA 验证——请输入备用验证码。”从而人为剥夺你选择更安全通行密钥的机会，强迫使用不安全的备选方式。即使账户默认使用 SSO 登录，攻击者也可以强制降级为用户名+密码登录，从而继续实施钓鱼攻击。

比如通过 Evilginx 的定制模块（phishlet），攻击者可以对微软账户进行降级攻击，绕过 Windows Hello 的安全认证。

换句话说，哪怕有安全的认证方式存在，只要账户同时支持不安全的备用方式，攻击者就仍有可乘之机。

设备码钓鱼（Device Code Phishing）

另一种绕过通行密钥的方式是利用“设备码登录”流程——这是为不支持浏览器或输入能力受限的设备设计的备用登录机制。

这种登录方式通常要求用户在另一设备上访问登录网站并输入一段代码，从而授权目标设备。攻击者可以诱导受害者在合法的身份验证网站上输入攻击者提供的设备码，从而让攻击者获取账户访问权限。

这种攻击方式的特点是：

· 用户访问的是完全合法的网址

· 没有任何权限弹窗提示

· 验证后的访问权限可直接落到攻击者手中

这种攻击方式已被用于多个攻击活动中，尤其是在 Microsoft 365 针对性攻击中频繁出现。

权限钓鱼（Consent Phishing）

权限钓鱼是 SaaS 攻击矩阵中最早被收录的攻击方式之一，但近年来活跃度又有明显上升。

攻击者会诱导用户授权恶意 OAuth 应用访问其数据。例如，发送一个钓鱼链接，请求访问敏感权限。如果用户同意，攻击者就能绕过 MFA，获得持久访问权限，即便之后用户修改密码也无效。

这种攻击常见于Microsoft Azure 和 Google Workspace，但如今也已扩展到 GitHub 等实现自有 OAuth 接口的 SaaS 平台。攻击者一旦获取权限，便可控制代码仓库传播恶意软件、破坏服务集成、窃取数据等。

GitHub 恶意 OAuth 应用

验证钓鱼（Verification Phishing）

注册新账号时，平台通常会通过邮件验证链接或验证码来确认身份。攻击者则通过钓鱼或社工手段，让用户点击恶意链接或提供验证码，借此绕过验证机制。

例如通过跨身份提供商（IdP）冒充方式，攻击者可以注册一个与受害者公司域名一致的身份，并通过某些应用的默认 SSO 机制直接登录，无需进一步校验。

研究发现，超过三分之二的应用允许此类冒充行为。攻击者可以借助未受管理的“社交 IdP”接入系统，而这些身份验证过程未必会由组织统一管理，从而形成漏洞。

应用专用密码钓鱼（App-Specific Password Phishing）

这是攻击者引导用户为“旧版应用”生成一组不支持 MFA 的专用密码，然后诱导用户将该密码提供给自己。攻击者通常冒充技术支持或服务人员，指导用户创建密码并通过表单或聊天工具提交。由于这类密码是为不支持现代认证机制设计的，一旦获取，攻击者就能在后台悄无声息地访问受害者数据（邮箱、联系人、文件等），且不会触发 MFA 机制。

一次定向攻击中使用的极具迷惑性的 ASP 钓鱼诱饵

额外手段：绕过不支持通行密钥的本地账户

最简单的绕过方式就是直接攻击那些根本不支持通行密钥的应用。通行密钥常与 SSO 联合使用，而很多应用并未支持通行密钥登录。

例如：Slack、Mailchimp、Postman、GitHub 等常用工具就被频繁单独攻击，绕开像 Microsoft、Google、Okta 等 IdP 的认证机制。

而且很多账户同时注册了“幽灵登录方式”（如本地用户名+密码），这些方式甚至没有启用 MFA，极易被攻击者利用。这也解释了如去年 Snowflake 攻击事件、今年 Jira 攻击中，攻击者如何利用凭证泄露成功入侵。最终，企业就暴露出一个庞大且脆弱的身份攻击面。

千用户组织有逾 1.5 万个账户，配置各异且存相关漏洞。

结语

多数情况下，攻击者无需专门破解通行密钥本身。只需使用常见钓鱼工具，目标账户若仍绑定不安全的 MFA 或本地登录方式，照样可以被入侵。唯一真正安全的账户是那些只启用通行密钥，且完全禁用了其他认证方式或通过策略限制了非通行密钥登录的账户。

但即便如此，也不能掉以轻心。比如近期曝光的案例中，微软提供的部分条件访问模板会错误地将“高风险登录”标记为误报，导致攻击照常发生。在应用和身份遍布各类系统的现实下，要全面掌握认证状态、管理权限设置，绝非易事。