设备码钓鱼揭秘：EvilTokens如何绕过密码攻破1.2万邮箱

微软近期查封了一个名为 EvilTokens 的钓鱼服务，这个服务在没有窃取任何一个密码的情况下，成功入侵了约 1.2 万个邮箱。它利用的不是传统的密码泄露或暴力破解，而是 OAuth 设备码流程（Device Code Flow）这一本应为合法场景设计的认证机制。这起事件暴露出一个长期被忽视的攻击面：当认证设计优先考虑便利性时，攻击者同样会利用这份便利。

设备码登录是什么，为什么会被盯上

OAuth 设备码流程最初是为那些输入体验糟糕的设备设计的——智能电视、游戏主机、命令行工具、物联网终端。这类设备往往没有键盘或浏览器，让用户直接在上面输入复杂密码既不现实也不安全。

设备码流程的做法是：设备显示一个短码，用户在另一台有浏览器的设备（手机或电脑）上访问指定网址，输入这个短码并完成登录授权，设备端随即拿到访问令牌（token）。整个过程中，密码从未在那台“瘦设备”上出现过，这正是它的安全卖点。

问题在于，这套流程的信任假设是“输入短码的人和操作设备的人是同一个人”。一旦这个假设被打破，便利就变成了漏洞。攻击者无需知道受害者的密码，只需诱导对方替自己完成那一步授权。

从 OAuth 2.0 协议规范角度看，设备码流程（RFC 8628）定义了两个独立的轮询循环：设备端以固定间隔向令牌端点轮询，直到用户在授权端点完成操作，令牌才被下发。这个设计的关键安全假设是"带外信道（out-of-band channel）安全"——设备通过屏幕或语音把短码传递给用户，这条信道本身不经过网络，因此被视为可信。当攻击者通过钓鱼邮件把短码传递给受害者，他们实际上是劫持了这条带外信道：短码从"设备告知用户"变成了"攻击者告知受害者"，但认证服务器对此毫无感知。设备码默认有效期通常为 15 分钟，留给攻击者足够的时间完成社会工程学操作。

EvilTokens 的攻击链条如何运作

EvilTokens 把设备码流程的信任缺口变成了一条规模化的攻击流水线。其核心逻辑可以拆解为几个关键环节。

攻击者先发起登录

攻击者以受害者组织的身份，向微软的认证端点发起一次设备码登录请求，拿到一个合法的、由微软真实签发的设备码。注意，这个短码本身是真实有效的，不是伪造的，这让后续的欺骗极具迷惑性。

把真实短码伪装成日常提示

攻击者随后向目标发送钓鱼邮件或消息，内容通常伪装成 IT 部门的例行操作，比如“请完成多因素认证设置”“验证你的设备”之类，并附上刚拿到的真实短码和官方登录链接。由于链接指向的是微软官方页面，任何检查域名的常规防范手段都会失效。

受害者替攻击者完成授权

一旦受害者在官方页面输入短码并通过自己的凭据（包括多因素认证）完成登录，令牌就会被发放给攻击者控制的那台“设备”。这里最棘手的一点是：多因素认证在这种场景下不但没能拦截攻击，反而成了帮凶——受害者亲手用 MFA 为攻击者的会话背书。

攻击者拿到的是访问令牌和刷新令牌，可以在相当长的时间内持续访问邮箱，而全程没有触碰过密码，因此传统的“异常登录地点”“密码泄露告警”往往难以察觉。

为什么传统防护在这里失灵

这起事件值得安全团队深思的地方，在于它几乎绕过了组织通常引以为傲的几道防线。

密码策略在此毫无用武之地，因为根本没有密码被盗。多因素认证同样被规避，因为它是受害者在合法流程中主动完成的。反钓鱼培训里反复强调的“检查网址域名”也不管用，因为用户访问的确实是官方域名。

换句话说，EvilTokens 攻击的是认证流程的逻辑设计，而非技术实现的漏洞。这类针对协议信任假设的攻击，往往比利用具体 bug 的攻击更难防御，因为修补它意味着要在便利性和安全性之间重新权衡。

这类攻击在安全研究领域通常被归类为"同意钓鱼"（Consent Phishing）或"令牌劫持"攻击的变体。与之相近的还有 AiTM（Adversary-in-The-Middle）攻击——攻击者在用户和真实认证服务器之间充当透明代理，实时转发认证流量并截获令牌。设备码攻击更为隐蔽，因为它不需要任何中间人基础设施，完全借用微软自身的合法端点完成整个流程，连 TLS 证书校验、HSTS 等网络层防护也完全无效。这类针对"协议意图"而非"协议实现"的攻击，学界称之为"语义攻击"（Semantic Attack），它要求防御者从协议设计逻辑而非技术漏洞的角度重新审视安全边界。

团队应该如何应对

对于确实需要为用户提供设备码登录的团队，完全禁用并不总是现实选项，但可以通过一系列措施大幅收窄攻击面。

限制设备码流程的使用范围是最直接的手段。如果组织内并不使用智能电视、命令行工具等需要设备码的场景，应当在身份平台层面直接禁用该流程。微软 Entra ID 等平台支持通过条件访问策略限制设备码登录。

按需放行而非默认开放。即便部分场景需要，也应将设备码登录限定在特定用户组、特定应用或可信网络范围内，而不是对全员开放。

加强令牌层面的监控。由于攻击不留下密码泄露痕迹，监控重点应转向异常的令牌发放和使用行为，例如从陌生地理位置或异常客户端发起的设备码登录请求。

对认证流程本身做用户教育。培训内容需要更新——不能只教用户“看域名”，还要让他们理解：收到含有登录短码的消息时，如果自己并没有主动在某台设备上发起登录，就绝不应该输入这个短码。这是打破攻击信任假设的关键一环。

结语：便利与安全的永恒拉锯

EvilTokens 的案例是一次很好的提醒：安全威胁正在从“偷密码”向“偷信任”转移。当认证机制为了照顾体验而放松某些假设时，攻击者会精准地利用那个缺口。对于设计和运营身份认证的团队而言，设备码流程不是必须一刀切禁用的功能，但它需要被当作一个明确的风险点来管理——默认关闭、按需开放、持续监控，才是更稳妥的姿态。

背景补充

访问令牌（Access Token）通常有效期较短（如 1 小时），但刷新令牌（Refresh Token）的有效期可长达数天乃至数月，允许持有者在无需用户再次介入的情况下持续换取新的访问令牌。在微软 365 场景中，刷新令牌的默认最长存续时间可达 90 天。这意味着受害者即便事后修改密码，只要刷新令牌未被主动吊销，攻击者依然能维持访问权限。这也是为什么事件响应时必须明确吊销所有相关令牌，而不能仅凭密码重置来终止入侵。