Windows Hello for Business 密钥遭滥用：研究员揭示 Microsoft Entra ID 无密码认证绕过新路径
企业级无密码认证方案的安全性正面临一次意料之外的考验。安全研究员 Dirk-jan Mollema 近期公开了一项技术细节，展示了恶意程序如何在已沦陷的 Windows 终端上，直接调用 Windows Hello for Business（WHFB）的加密密钥完成 Microsoft Entra ID 身份验证。整个过程中，攻击者既不需要窃取用户的明文密码，也无需获取 PIN 码或生物识别数据，就能在云端建立持久化访问通道。
当 TPM 成为"沉默的帮凶"
Windows Hello for Business 的设计初衷是消除传统密码带来的安全风险。这套系统通常将用户的私钥封装在设备内置的可信平台模块（TPM）中，借助硬件级隔离让密钥几乎无法被导出。用户每次登录时，只需通过 PIN、指纹或面部识别完成本地验证，TPM 才会释放密钥的使用权限。
从架构层面看，这套逻辑无懈可击。TPM 的物理防篡改特性决定了攻击者很难直接读取私钥内容。然而 Mollema 的研究揭示了一个被长期忽视的盲区：密钥虽然"出不来"，但在特定条件下，它的"签名能力"可以被会话内的进程直接调用。
当用户完成一次正常的 Windows Hello 登录后，系统会在后台维护一组缓存的认证上下文。这意味着在会话保持活跃期间，已经通过身份验证的进程可以通过 Windows 密码接口（Crypto API）请求使用受 TPM 保护的密钥执行加密签名，而系统不会再次弹出 PIN 或生物识别提示。对于普通用户而言，这种设计提升了使用体验；但对于已经植入恶意软件的沦陷终端，这恰好构成了一条隐蔽的认证隧道。
从本地签名到云端身份：两条渗透路径
Mollema 在研究中梳理了两条利用 WHFB 密钥突破云边界的具体路径。第一条路径瞄准的是 Microsoft Entra ID 体系中的核心凭证——主刷新令牌（PRT）。
PRT 在整个微软生态中扮演着"万能通行证"的角色。一旦获取有效的 PRT，攻击者不仅能够在 Outlook、Teams、Azure Portal 等微软服务之间自由穿梭，还能在令牌过期前通过续期机制维持长期访问。过去，攻击者若想通过 WHFB 密钥申请 PRT，通常需要额外控制一台已经加入或注册到 Entra ID 的设备作为跳板。而新的研究表明，这条限制正在被逐步瓦解。
第二条路径则更具隐蔽性。研究人员发现，WHFB 密钥可以被伪装成一枚标准的 FIDO2 通行密钥，通过 WebAuthn 协议向 Microsoft Entra ID 发起认证请求。WebAuthn 作为当前主流的无密码和抗钓鱼登录标准，在企业环境中被广泛信任。当攻击者利用沦陷会话生成有效的 WebAuthn 断言后，即可从任意一台远程机器完成 Entra ID 登录。
这里存在一个值得安全团队高度警惕的细节：由于这种登录并非来自受害者的原始注册设备，Entra ID 颁发的访问令牌中往往不会携带正常的设备标识符。表面上看，这似乎是一个缺陷；但对攻击者而言，缺失的设备绑定信息反而成了一扇方便之门。他们可以凭借这枚"干净"的令牌，在 Entra ID 中注册一台全新的、由攻击者控制的设备。一旦新设备完成注册，后续的 PRT 获取、持久化后门部署、甚至添加额外的认证方式（如新的通行密钥）都将变得顺理成章。
条件访问策略的"信任盲区"
这项研究对企业中广泛部署的条件访问（Conditional Access）策略提出了直接挑战。在大多数组织的配置中，Windows Hello 和 FIDO2 被归类为"抗钓鱼认证方法"，满足强多因素认证（MFA）策略的要求。当攻击者通过沦陷会话伪造认证流程时，系统日志中记录的是一次合规的、高信任等级的登录事件，而非传统的凭证泄露告警。
当然，如果企业启用了"要求合规设备"或"要求受管理设备"的策略，攻击者在初始阶段仍会受到一定阻碍。但问题在于，一旦攻击者通过上述路径获得了云端的第一个有效令牌，他们就可以尝试绕过设备层面的限制。例如，利用新注册的攻击者控制设备逐步满足合规性检查，或者通过令牌续期在设备状态变更窗口期内维持访问。
更棘手的是，这种攻击方式在日志层面的表现极其暧昧。它不像暴力破解那样会产生大量失败记录，也不像传统的票据传递攻击那样会触发明显的 Kerberos 异常。一次成功的 WHFB 密钥滥用，在审计日志中可能仅仅表现为一次来自已知用户、使用强认证方法的正常登录。
防御视角：在日志中寻找"幽灵设备"
面对这种新型威胁，被动等待告警显然不够。安全运营团队需要将监测重心转向那些"看起来正常、实则异常"的认证事件。
一个关键的检测指标是 Entra ID 登录日志中设备 ID 字段为空或缺失的 Windows Hello for Business 认证记录。诚然，在某些特定场景下——例如用户通过私密浏览模式或不支持 SSO 的第三方浏览器登录——设备 ID 为空属于正常现象。但在标准化部署的企业环境中，大多数 WHFB 登录都应该携带明确的设备标识。如果突然发现大量来自内部用户的 WHFB 登录缺少设备绑定信息，就需要立即展开排查。
除了关注设备 ID 的缺失，安全团队还应建立对以下行为的持续监控：
异常设备注册活动是另一个不容忽视的信号。当攻击者成功获取无设备绑定的令牌后，他们往往会尝试在 Entra ID 中注册新设备。任何未经预期的新设备加入记录，尤其是与敏感账户关联的注册事件，都应触发人工复核流程。
认证方式的突变同样值得警惕。如果某个长期仅使用 Windows Hello 登录的账户，突然在短时间新增了 FIDO2 通行密钥或其他备用认证方法，这很可能意味着攻击者正在为持久化访问铺设后路。
令牌生命周期中的异常模式也能提供线索。例如，PRT 的频繁续期请求、来自异常地理位置的令牌使用、或者同一账户在短时间内通过不同设备类型生成多个有效会话，都可能暗示着凭证被滥用的风险。
回归端点：会话安全仍是根基
需要明确的是，这项研究并不意味着 TPM 保护机制本身存在可被远程利用的漏洞。攻击的起点始终是终端上已经运行的恶意代码。没有沦陷的活跃会话作为前提，攻击者无法凭空调用 WHFB 密钥完成签名操作。
这也再次印证了端点检测与响应（EDR）体系在整个安全架构中的基础性地位。无论云端的身份验证模型多么先进，一旦终端失守，所有的认证凭证都可能成为攻击者的工具。对于企业而言，强化终端防护、及时修补系统漏洞、限制不必要的本地管理员权限、以及部署行为分析能力来识别异常的进程注入和 API 调用，仍然是阻断此类攻击最有效的前置手段。
此外，考虑到攻击者可能利用 WebAuthn 断言从远程机器发起认证，企业还应当评估是否有必要在条件访问策略中增加对设备注册状态和已知设备指纹的校验权重。单纯依赖认证方法的"强度标签"来判定信任等级，在面临会话劫持与密钥滥用场景时，显然已经显得单薄。
无密码认证的大方向不会因为个别攻击技术而逆转，但这项研究提醒所有采用 Windows Hello for Business 的组织：硬件级密钥保护解决了"密钥被窃取"的问题，却没能完全堵住"密钥被借用"的通道。在端点安全与云身份治理之间，仍然需要更紧密的联动与更精细的可见性，才能真正守住那道看不见的边界