设备码流程未禁用：攻击者绕过 MFA 读邮箱

问题背景

公司用的是 Microsoft 365，全员强制 MFA，邮件网关、EDR、DLP 都按基线配了。安全团队一直认为“有 MFA 兜底，账号被盗的风险可控”。财务部一位同事在月初反馈：连续几天收不到供应商发票邮件，让 IT 帮忙查一下。

IT 先看邮件流，邮件确实到了她的邮箱，但被一条收件箱规则自动移到了一个不显眼的子文件夹。再查登录日志，发现前一天凌晨有一个来自境外 IP 的登录，认证方式是“设备代码”（deviceCode），应用显示为命令行工具，登录成功了。用户说那天下午点过一个“账号验证”的链接，按页面提示输入了一串代码，还在手机上点了 MFA 确认。

故障现象

用户邮箱里出现了一条自动规则：把主题含“发票”“对账”的邮件移到某个子文件夹，并标记为已读。
登录日志里有一条成功登录，IP 在境外，认证协议是 deviceCode，客户端应用是命令行工具，资源是 Exchange Online。
用户没有改过密码，也没有收到异常登录提醒；MFA 记录显示她本人确实在手机上批准过一次登录。
同一时段，她的账号还向内部几个同事发过一封“共享文档”的钓鱼邮件。
邮件网关、EDR 都没有告警；只有身份侧的登录日志留下了痕迹。
进一步排查发现，租户层面允许所有用户使用设备码流程，条件访问里也没有针对它的限制。

排查过程

第一步看登录日志。在 Entra ID 的 Sign-in logs 里按用户筛选，找到那条境外登录：Authentication Protocol 字段是 deviceCode，Application 是一个常见的命令行客户端，Resource 是 Office 365 Exchange Online，结果 Success。设备码登录不会出现在用户常用的 Outlook/Teams 登录记录里，很容易被忽略。

第二步问清楚用户操作。她回忆收到一封“您的账号需要重新验证”的邮件，点进去是一个看起来很像微软的页面，提示“在设备上输入以下代码”。她按提示在微软官方页面输入了代码，并用手机批准了 MFA。整个过程中，她没有输入密码，也没有把密码告诉任何人——这正是设备码钓鱼的典型话术。

第三步解释攻击链。OAuth 2.0 的设备授权流程（RFC 8628）原本是给输入受限设备用的：客户端先向身份平台申请一个设备码和用户码，用户在其他设备上打开验证页面输入用户码并完成认证，客户端再轮询令牌端点换取访问令牌。攻击者把自己伪装成“客户端”，把用户码发给受害者；受害者是在微软官方页面完成认证的，MFA 也是真的，但最终令牌发给了攻击者的客户端。MFA 保护了“谁在认证”，却没有保护“令牌发给谁”。

第四步查影响面。用 Get-InboxRule 查该用户的收件箱规则，确认了那条转移发票邮件的规则；查发件箱和已发送，发现钓鱼邮件；查 OAuth 授权，确认攻击者拿到的令牌有 Exchange Online 的邮件读写权限。再看其他用户，没有发现类似的 deviceCode 登录，说明目前只成功了一次。

第五步确认租户配置。Entra ID 的条件访问里没有任何策略针对“身份验证流”，设备码流程对所有用户开放；也没有“要求合规设备”的策略。也就是说，只要用户被骗着输入一次代码，攻击者就能拿到令牌，和密码、MFA 方式都无关。

第六步处置与验证。吊销该用户的所有刷新令牌、重置密码、删除恶意收件箱规则、撤销可疑 OAuth 授权；然后在条件访问里新增策略，阻止设备码流，并要求办公场景使用合规设备。观察一周，登录日志里没有再出现 deviceCode，用户邮件流恢复正常。

解决方案

先止血：吊销用户全部登录会话与刷新令牌，重置密码；删除恶意收件箱规则、转发规则和签名；检查并撤销异常的 OAuth 授权；排查已发送邮件，通知可能受影响的同事。
封堵设备码流：在条件访问里针对“身份验证流”配置策略，阻止设备码流；对必须使用设备码的合法场景（如会议室设备、部分命令行工具）用单独的用户组做例外，并配合合规设备要求。
收紧条件访问基线：办公场景要求合规/已加入域的设备，敏感应用要求防钓鱼 MFA（FIDO2/Windows Hello），禁止旧版认证；对高风险登录启用“仅允许受信任位置”或额外验证。
监控认证协议：在 SIEM 里对 AuthenticationProtocol = deviceCode 的登录单独告警，尤其是境外 IP、非常用应用、非工作时间；同时对“新建收件箱规则/转发规则”做审计告警。
用户沟通：发一次针对设备码钓鱼的提示——任何让你“在页面上输入代码”的邮件都要警惕，微软不会通过邮件要求你输入设备码；收到可疑邮件走举报通道。
验证：策略上线后确认正常办公不受影响，合法设备码场景仍可用；模拟一次设备码登录，确认被条件访问拦截并产生告警。

根因分析

直接根因是租户允许 OAuth 设备码流程且条件访问没有限制，攻击者利用该流程诱导用户在官方页面完成认证，令牌被签发到攻击者客户端，MFA 被“合法”地绕过，邮箱随后被读取和利用。

更深一层，是把 MFA 当成了账号安全的全部。MFA 解决的是“认证时是不是本人”，但 OAuth 体系里还有“令牌发给哪个客户端、这个客户端能访问什么”的问题；设备码流程、应用 consented 权限、刷新令牌，都是密码和 MFA 之外的身份入口。只盯着登录框，就会漏掉这些“侧门”。

还有一层是监控盲区。设备码登录在用户视角里没有明显感知，在网关和 EDR 里也没有流量特征；如果没人按认证协议去筛登录日志，这类事件就只能等用户发现邮件丢了才曝光。身份侧的日志不是“出了事再查”，而应该成为日常告警源。

预防措施

条件访问基线明确覆盖“身份验证流”：默认阻止设备码流，合法场景按组例外；每季度复核例外清单。
敏感应用要求防钓鱼 MFA 和合规设备，逐步淘汰可被诱导的推送/短信验证方式。
SIEM 对 deviceCode 登录、异常 OAuth 授权、收件箱规则变更设置告警，按用户和 IP 聚合。
建立令牌被盗的应急手册：吊销会话、重置密码、清理规则与授权、检查发件与转发、通知相关方，按顺序执行。
用户培训聚焦“设备码”话术：不把任何代码输入到别人发来的页面，不在非官方入口完成认证。

总结

MFA 挡得住“猜密码的人”，挡不住“把令牌领走的人”。设备码流程本来是为输入受限设备设计的便利通道，租户默认全开、又没有条件访问约束时，它就变成了一条绕过 MFA 的侧门：用户认证是真的，MFA 是真的，只有令牌落到了 attacker 手里。把不用的认证流关掉、把令牌签发纳入监控、把“输入代码”列为钓鱼话术，身份安全才不只停留在登录框上。