先记结论：自称 IT 的电话让你「立刻更新通行密钥」时，危险不在 Passkey 私钥被拷走，而在你把一次有效登录交给了对方。中间人截的是会话；设备码流程里，登录页甚至可以是微软真域名。改密码只覆盖口令这一层，挡不住已经登记的陌生验证器。能当场核对的是：来电路由、地址栏主机名、安全信息页有没有多出设备，而不是「我已经用了 Passkey」。
一句话先回答搜索意图
通行密钥（Passkey）按 WebAuthn 设计，私钥留在本机或同步钥匙串，并绑定依赖方的来源站点。假登录页拿不到这块私钥，这是「抗钓鱼」这句话能成立的范围。它不能成立的范围是：你被催着走完一次登录，会话令牌落到对方手里；或者你在真域名上输入别人给你的设备码，把令牌签发给对方控制的应用。
这篇文章给已经开了通行密钥、仍会被电话或短信催「更新」的人，以及要给同事解释「为什么 Passkey 不是免责金牌」的开发者和运维。它不代替微软的事故通报，也不写成「怎么关掉通行密钥」。你要带走的是：话术覆盖哪一层、会话和设备码各偷哪一层、改密码为什么不够，以及挂掉电话之后能在本机核对什么。
微软这次披露拆开了哪几层
2026 年 9 月 9 日，微软安全研究发布英文通报。他们跟踪的是一组仍在进行的云身份入侵：异常登录之后，出现对方添加的验证方法、大量 Microsoft Graph 访问、SharePoint 与 OneDrive 下载，以及通过 REST API 收集邮件。通报写明，这类活动从 2026 年 5 月起被观察到。
开头不是一封精致的钓鱼邮件，而是打到个人手机号的电话或短信。来电自称公司 IT 服务台，制造紧迫感：通行密钥、多重验证或单点登录必须马上更新，否则账号会中断。链接常常另用短信发到同一部个人手机。微软写得很干脆：尽管话术围着 Passkey 转，登记通行密钥常常不是真正目标。借口的作用是把人带进两条技术路径——中间人（AiTM）钓鱼，或设备码授权。
中间人路径截的是凭据和会话令牌。设备码路径里，受害人被说服在微软自己的认证页输入一串码，令牌发给对方控制的客户端，不必再偷浏览器 Cookie。两条路都可能让后续访问不再碰一次 MFA。若链接开在未纳入 Defender 的个人手机上，终端侧可能几乎没有痕迹；调查时，当事人对电话或短信的回忆，常常是解释「入侵从哪开始」的最早、有时也是唯一的证据。
基础设施也按「看起来眼熟」来搭。通报列出的主题域名包括 passkeyhelpdesk.com、setupmypasskey.com、add-passkey.com、secure-passkey.com，以及把公司名嵌进子域的形态，例如 contoso.add-passkey.com。同一家公司名还可以出现在 integratedsso.com 这类 SSO 主题域下。域名注册后数小时就能用，给拦截窗口很短。部分案例里，对方还会用已经沦陷的同事账号，在 Teams 里发同一套「更新通行密钥」消息，把内部信任叠到电话之外。
微软把初始访问活动关联到包括 Storm-3121、Storm-3032 在内的多组操作方。Storm-3121 的后续常接到 ShinyHunters 与 Falcon 勒索；Storm-3032 被描述为从 BlackFile 分裂、现在打 Helix 旗号的一拨人。这只说明生态，不证明你接到的每一通「IT 电话」都来自同一团伙。能写进交接说明的，是话术加两条技术路径，不是某个团伙名字。
通行密钥挡得住假站，挡不住交出去的会话
把「抗钓鱼」读成「再也不会被骗」，是把凭据层和会话层焊成了一句。通行密钥在登记时绑定站点来源。假域即使做成和微软登录页一样，通常也拿不到你为 login.microsoftonline.com 存下的私钥。这是 Passkey 相对密码复用的真实优势，不必否定。
微软调查里的一条时间线，把「优势停在哪」写清楚了。T+0 分，未托管环境访问 OfficeHome，返回错误 50074，要求二次验证；T+1 分，MFA 完成（通报写明是中间人加上非抗钓鱼 MFA），随后 50140 打断「保持登录」；同一分钟认证成功，会话建立。接下来大约一小时内，同一会话打开 My Apps、个人资料、审批管理、安全信息，再经 Graph 枚举 SharePoint 与 Outlook。会话在，对方就不必再碰你的通行密钥。
所以「我已经用了 Passkey」只能支持很窄的结论：假站很难直接导出这块私钥。它不能支持：你不会被催着在仿冒页上再走一遍密码或短信码；中间人拿不到这次登录换来的令牌；安全信息页不会多出对方的验证器。后几句要另找证据：看你点开的主机名是不是官方登录域，以及登录之后安全信息有没有陌生设备。
不要用真实工作账号去「试探」来电里的链接或设备码。准备一句可丢弃的说法就够：挂断，改走公司书面公布的 IT 渠道回拨。核对的是来电路由和地址栏，不是把一次有效登录再送给对方。
设备码为什么能在真域名上得手
中间人至少还要搭一张像登录页的站。设备码把这层也拆掉了。官方流程本来就是：一个客户端显示短码，你在浏览器打开微软的设备登录页，输入这串码，等于批准「那个客户端」代表你访问资源。页是真的，证书是真的，地址栏也经得起「是不是微软」。被骗的点换成了：这串码是谁生成的、批准会落到谁的应用。
通报里的第二条攻击序列就是这样：通行密钥话术之后走设备码，受害人在合法认证页输入对方提供的码，令牌发给对方控制的客户端。之后对方重放这枚令牌，枚举目录和文件，不再需要再偷 Cookie，也不再需要再过一次 MFA。对习惯检查「锁和域名」的人，这比假站更难当场拆穿——你检查的那一层是绿的。
因此，「地址栏是微软」只能支持：你没有把口令打进 add-passkey.com 这种仿冒主机。它不能支持：这个码属于你自己的笔记本；批准之后令牌只会留在你的浏览器。别人电话、短信或即时消息里念给你的码，默认要按「对方的客户端」处理，而不是按「官方页面所以安全」处理。
改密码为什么盖不住已经登记的验证器
得手之后，对方第一件事往往不是继续翻文件，而是把自己的验证方法写进你的身份。通报写的是：新手机号、验证器应用，或软件一次性口令。2026 年 9 月 4 日的一条真实审计示例里，新增记录的设备名是 NO_DEVICE，设备标记是 SoftwareTokenActivated，哈希函数字段为 hmacsha1。这不是「又设了一个密码」，而是以后的二次验证可以由对方完成。
微软给确认沦陷账号的处置顺序是连在一起的：撤销活动会话和刷新令牌、重置凭据、删除对方登记的验证方法、去掉对方加的邮箱规则，并要求用抗钓鱼方式重新登记。只改密码、不看安全信息页，等于留下一把对方已经配好的钥匙。第三条调查序列还显示，对方可以隔几天再用早先登记的 PhoneAppOTP 登录，然后用 Node.js 自动化走 Graph——口令对了、二次验证也「过了」，过的是他们自己的因素。
本地 密码检测 对照的是公开高频弱口令名单，待测密码不上传，也不是全网撞库。它能告诉你这串口令是不是太常见，不能告诉你安全信息页有没有多出 NO_DEVICE，也不能证明刚才那通电话是假的。弱口令和会话劫持不是同一列数据，不要互相代替。
| 你看见的说法 | 能支持的结论 | 不能支持的结论 |
|---|---|---|
| 我已经登记了通行密钥 | 假站很难直接导出这块私钥 | 再也不会被催着交出一次有效登录 |
| 地址栏是微软官方域名 | 你没有把口令打进仿冒主机 | 设备码批准的一定是你自己的客户端 |
| 电话自称本公司 IT，还报得出部门名 | 对方做了公开信息侦察 | 来电走的是公司核实过的回拨渠道 |
| 我改掉了密码 | 口令这一层已轮换 | 陌生验证器和未撤销的会话都失效了 |
| 短信链接开在个人手机，电脑没中毒 | 这台工作电脑的终端日志可能是空的 | 云身份没有建立过对方的会话 |
| 同事在 Teams 里也催我更新 Passkey | 消息来自一个已登录的内部账号 | 这个账号此刻一定仍由本人控制 |
挂掉电话之后，当场能核对哪几层
口号不能当证据。下面只核对应由你控制的事：来电是不是走既有渠道、将要点开的主机名、安全信息页有没有多出设备。不要用生产账号去打开来电里的链接做实验。
- 挂断。用公司书面公布的 IT 工单、内部门户或回拨号码联系，不要回拨刚才那通来电，也不要点短信里的链接。微软建议给员工一条核实过的渠道，用来上报主动找上门的认证请求。
- 若你已经点开链接：只看地址栏主机名。公司名出现在子域、后缀却是
add-passkey.com、setupmypasskey.com或secure-passkey.com，这不是微软登录域。不要在这一页输入口令、短信码或通行密钥确认。 - 若有人要你「在官网输入一串码」：先问这串码是哪个应用、哪台设备生成的。别人念给你的码，按对方客户端处理。官方设备码页是真的，批准对象仍可能是对方的应用。
- 登录公司账号后，打开安全信息 / My Sign-Ins，逐条看验证方法。多出来的手机号、验证器、软件令牌，尤其是设备名不像你自己的手机的，按管理员流程撤销会话并删除，不要只改密码。
- 必须把一次性短秘密交给已经核实过的同事时，改走密文通道。打开 阅后即焚，写入一句可丢弃的金丝雀，例如
canary-fp-20260921-passkey-lure。打开开发者工具的 Network，勾选 Preserve log。生成后搜这句金丝雀：POST /secrets的请求体里应只有密文、过期时间和阅读次数，不应出现原文，也不应出现井号后的密钥。链接形态是s.html?id={id}#{key}；RFC 9110 规定请求目标 URI 不含 fragment。
前四步处理的是身份被接管的通道。第五步处理的是另一件常见误操作：把「IT 要的码」或临时口令截图发进聊天。图床和相册会留下像素和可能的 OCR，上一篇已经写过。焚链只上传密文，密钥留在 # 后面。两条通道不要混用——不要先截进聊天，再把完整焚链 URL 贴回同一张图。
完整链接和密文不要走同一条渠道。电话里报出来的设备码、聊天里的截图、焚链的 s.html?id=…#… 整串，是三种不同的泄露面。把钥匙和锁写在同一条消息里，井号后的保护对「能看见这条消息的人」已经没了。
三种把「我有 Passkey」读过头的情况
第一，把抗钓鱼当成抗社会工程。通行密钥绑定来源站点，针对的是假登录页直接拿走私钥。电话、短信、内部聊天可以绕开这一层，把你带到中间人或设备码。微软自己的缓解清单里，和「强制抗钓鱼 MFA」并列的，是针对语音与邮件钓鱼做培训，以及拦截不必要的设备码流。
第二，把「页面是官方的」当成「批准对象是我的」。设备码页可以是真域名。你检查锁图标，检查不到令牌签发给谁。判断依据是码的来源：自己设备弹出的，和电话里念的，不是同一件事。
第三，把改密码当成收尾。口令、会话、对方登记的验证器、邮箱转发规则，分属不同开关。通报要求它们一起处理。本地生成一组新口令，只能覆盖「还在用密码的服务」这一层：打开 密码生成器 即可，长度 6–128 位、默认 16 位，低于 8 位会提示安全性较低，计算在浏览器完成，不上传。它代替不了撤销会话，也代替不了删掉陌生验证方法。
常见问题
我已经登记了通行密钥，还会被这通电话骗到吗？
会，而且常常不是因为 Passkey 被偷走。话术用通行密钥当借口，真正要的是中间人截到的会话，或你在微软真域名上为对方应用输入的设备码。通行密钥绑定来源站点，挡得住假登录页直接拿走私钥，挡不住你主动授权对方的客户端。
地址栏看起来像微软官网，是不是就可以输入设备码？
设备码流程的登录页本来就可以是官方域名。危险不在「是不是假站」，而在「这个码是谁发给你的、授权会落到谁的应用」。别人电话或短信里念给你的码，授权的是对方控制的客户端，不是你自己的浏览器会话。
改掉密码之后，这次通话还算结束了吗？
不够。微软写明对方会在得手后登记自己的手机号、验证器或软件令牌。只改密码、不撤销会话、不删陌生验证方法，对方仍可能通过自己登记的第二因素再进来。安全信息页上多出来的设备，要按官方处置步骤拿掉。
同事在聊天里要一次性口令，能不能截图发过去？
不要把活口令或设备码截进聊天相册。短文本应在当前标签页用 AES-256-GCM 加密后走 阅后即焚，密钥放在链接的 # 后面，形态是 s.html?id={id}#{key}。创建和阅读都打开即用，无需账号。先确认对方身份走的是你们公司既有的核实渠道，而不是刚才那通自称 IT 的来电。超过 32 KB 的材料改走 文件加密盒，单文件不超过 5 GB，输出 .lock / .enc。
把短秘密改走打开即用的通道
若你希望用一个把计算边界写清楚的页面来练习「还口令、不截图」，打开 FastPwd 的 阅后即焚 即可，无需注册。写入上面那句金丝雀，阅读次数留 1，生成后按第五节对照 Network：请求体里应只有密文，不应出现原文或井号后的密钥。必须把短口令交给已经核实过的同事时，才走这条通道，不要先截图，更不要把设备码回给陌生来电。
聊天记录或工单正文里如果还叠着手机号、证件号，先在 隐私清洗 里做规则脱敏，再决定要不要发出。清洗在本机完成，原文不作为业务数据上传，也不写入 analytics。还在用口令的站点，用密码生成器本地生成唯一口令，不要复用被电话催过的那一串。密码检测只回答「是不是公开高频弱口令」，不回答「刚才那通电话是不是假的」。
下次再接到「马上更新通行密钥」的电话，记住三件事。第一，话术里的 Passkey 常常只是借口，对方要的是会话或设备码授权。第二，真域名挡不住你把令牌签发给别人的应用。第三，收尾看安全信息页和会话撤销，不是只改密码。能写进交接说明的，只能是这三句，不能是「我开了通行密钥，所以不用管来电」。
延伸阅读
把口令截进图床之后，登录哈希挡不住 OCR 明文和 Image ID，见 把密码截进图床之后，OCR 明文和 Image ID 为什么比哈希更危险。阅后即焚烧掉的是服务器上的密文，证明不了接收方没截图，见 阅后即焚能证明服务器删了密文，为什么证明不了对方没截图。URL 井号后面为什么不进 HTTP，见 URL 的井号后面为什么适合放密钥，以及什么时候会失效。