TopsTip2026 年 8 月 5 日，SpecterOps 研究员 Michael Grafnetter 在 Black Hat USA 2026 上演示了一个不需要破解任何加密算法的攻击。Windows 曾把 YubiKey 生成的历史签名以明文写进日志，一个已经通过认证的低权限远程用户就能读到这些记录。研究者称，把读到的签名与 Microsoft Entra ID 的验证行为串联起来，可以冒充高权限用户，并通过要求抗钓鱼 MFA 的策略（SpecterOps 把这一族攻击命名为 Pass-the-Passkey）。这条链重放的是已经生成的签名，没有导出硬件认证器里的私钥。对应的 Windows 日志信息泄露漏洞编号是 CVE-2026-34348，Microsoft 给出的 CVSS 3.1 基础分为 6.5，影响范围列了多个 Windows 10、Windows 11 和 Windows Server 版本，安全更新已经发布。CVE 覆盖的产品范围不等于完整攻击链在每个版本上都同样成立。
同一周还出现了另外两项研究：Palo Alto Networks 旗下 Unit 42 的 Pass-ta-key，以及独立研究者 Dirk-jan Mollema 对 Windows Hello for Business 密钥的调用实验。三者路径不同，共同点是都没有攻击公私钥签名本身，而是绕过它周围的日志、云同步和端点会话控制。对正在推进无密码迁移的团队来说，这个区别直接决定该替换什么、以及替换后还剩多少风险。Microsoft 向 The Hacker News 表示已对所报告的 relay assertions 问题实施缓解，但没有公开 Entra 侧的技术细节，外界因此无法核对缓解覆盖了哪些配置。
私钥确实能被取回，前提是恶意软件已经在机器里
Unit 42 的目标更靠前一层：Windows 上 Chrome 通过 Google Password Manager 同步的 Passkey。三条路径分别是静默获取有效认证断言、植入攻击者控制的用户验证密钥、以及恢复同步 Passkey 的私钥。三条都要求恶意软件已经以普通用户身份运行，不要求管理员提权。这个门槛比听上去低，日常见到的信息窃取木马正好停在这一层权限上。
其中影响最大的是 Golden Pass-ta-key，攻击对象是一个 32 字节的 Security Domain Secret。Unit 42 称拿到它就能解密受害者同步 Passkey 的私钥。Google 在收到报告后已从 Chrome 的设备日志中移除该秘密，但研究者称重新注册期间它仍会短暂出现在 Chrome 进程内存中，而且目前没有轮换或撤销这个秘密的机制。密码泄露后可以改密码，这个秘密眼下还没有对应的补救动作。
Unit 42 还在 eBay 上演示过一条即使网站请求 user verification 也依然可用的路径，披露后 eBay 调整了对 WebAuthn 用户验证标志的校验。一部分风险因此落在依赖方自己的校验实现上，不全在浏览器和操作系统。
Mollema 的方向几乎相反。他展示的是 TPM 保护、不可导出的 Windows Hello for Business 私钥：恶意软件只要运行在已登录的 Windows 用户会话中，就能调用系统密码学接口使用这把私钥，不必再触发 PIN 或生物识别。按他的技术记录，Entra 的 WebAuthn challenge 有效五分钟，且未绑定会话、用户或租户，攻击者可以在自己的系统请求 challenge，带到受害者机器上签名后再送回，所得登录同样满足抗钓鱼认证强度策略；他还描述了在缺少 device ID claim 的情况下，通过设备注册取得 Primary Refresh Token 的持久化路径。这部分目前只有研究者本人的记录，尚无厂商公开确认。
迁移窗口和这些缺口撞在了同一个季度
Microsoft 计划从 2026 年 9 月 1 日起为当前使用短信或语音认证的 Entra ID 用户自动启用 Passkey 并提示注册，并计划在 2027 年 2 月 1 日停止由自己提供短信和语音验证码。这个方向站得住：短信一次性验证码挡不住伪造域名的钓鱼页面，而 Passkey 的域名绑定和公钥机制让钓鱼站点与凭证填充都失去着力点。上面两项端点研究成立的前提，恰恰是受害者的 Windows 会话已经被恶意代码攻陷，那已经是另一类事故。
需要在迁移方案里写清的是同步与设备绑定的差别。同步 Passkey 换设备和账户恢复都更顺，代价是把信任边界扩展到同步服务和浏览器进程内存；设备绑定 Passkey 不把私钥交给云，但按 Mollema 的实验，活动会话里的恶意代码仍可能调用它。英国 NCSC 的凭证对比文件也把两者当作不同权衡，而不是优劣排序。
r/sysadmin 上关于这类披露的讨论反复回到同一个问题：既然攻击结果能满足抗钓鱼 MFA 策略，Passkey 还值不值得铺开。围绕本次三项研究的转帖互动量有限，中文和日文检索也没有形成可核验的集中讨论，这些帖子只说明运维侧的关注点，不构成行业共识。
几项事实仍是空白：公开研究都没有报告在野利用，Unit 42 三条路径的完整 Chrome 受影响版本与修复状态没有公布，Google 是否提供 Security Domain Secret 的轮换或撤销未见说明，SpecterOps 与 Mollema 各自观察到的 Entra 验证行为是否来自同一个底层缺陷也无法确定。其中最值得盯的是那个 32 字节秘密：只要它没有轮换机制，一次成功的端点感染就没有干净的收尾方式。
