Windows Hello for Business 密钥遭滥用:研究员揭示 Microsoft Entra ID 无密码认证绕过新路径

📅 2026/8/8 17:03:56
Windows Hello for Business 密钥遭滥用:研究员揭示 Microsoft Entra ID 无密码认证绕过新路径
企业级无密码认证方案的安全性正面临一次意料之外的考验。安全研究员 Dirk-jan Mollema 近期公开了一项技术细节展示了恶意程序如何在已沦陷的 Windows 终端上直接调用 Windows Hello for BusinessWHFB的加密密钥完成 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 的组织硬件级密钥保护解决了密钥被窃取的问题却没能完全堵住密钥被借用的通道。在端点安全与云身份治理之间仍然需要更紧密的联动与更精细的可见性才能真正守住那道看不见的边界