Google 旗下网络安全公司 Mandiant 披露了一种新方法，可从 Windows 主机的 Machine DPAPI 中恢复活跃的 Active Directory Federation Services（ADFS）签名密钥。该研究揭示，在部分 ADFS 部署中，证书记录与实际使用的签名材料存在严重脱节。

配置脱节导致密钥泄露风险

研究指出，当组织禁用自动证书轮换（AutoCertificateRollover）并手动轮换证书，却未完全更新配置时，漏洞便会显现。在此状态下，ADFS 服务仍使用存储在主机机器范围加密存储中的有效证书对令牌进行签名，而 Windows 内部数据库（WID）中却保留着关于旧证书的过时记录。

这一发现基于长期存在的 "Golden SAML" 攻击技术，其核心在于窃取 ADFS 令牌签名证书。此次突破在于，即使数据库仅指向不再用于签名的 " 幽灵 " 证书，攻击者仍能找回仍在使用的活跃密钥。一旦获取私钥，攻击者即可在联合环境中伪造任意用户的 SAML 断言，绕过多重身份验证（MFA）及其他身份控制措施，非法访问 Microsoft 365 和 Entra ID 等关联应用。

在红队演练中，分析师最初从 ADFS 数据库提取并使用分布式密钥管理器材料解密得到的证书已失效，生成的断言被 Entra ID 拒绝。进一步分析显示，活跃签名密钥受 Machine DPAPI 保护，留存于服务器的机器 RSA 密钥存储中。这意味着，拥有 SYSTEM 权限的特权进程无需直接与 LSASS 内存或 ADFS 服务进程交互，即可恢复该密钥。

架构弹性带来的安全弱点

这种脱节现象常见于管理员关闭自动轮换并执行手动证书更改的环境。尽管主机在操作系统层面绑定了新证书并正常运行，ADFS 数据库却可能未同步更新。Microsoft 事件 ID 385 可作为证书有效性警告的信号，但在手动管理环境中，这往往是脱节最明显的迹象。

Mandiant 指出，ADFS 将私钥材料存储于多种保护上下文中。虽然磁盘上可能存在用户 DPAPI 保护的密钥数据块，但团队未能通过测试恢复与 ADFS 服务帐户相关的可用主密钥。相反，活跃密钥位于 Windows 机器密钥存储路径下，与本地 SYSTEM 上下文可用的机器主密钥关联。这种设计旨在提高运营弹性，确保密钥在服务帐户密码更改、重启等期间保持可用，但也为具备足够特权的本地攻击者提供了可乘之机。

防御建议与缓解措施

演练中，研究人员利用恢复的密钥伪造了模拟全局管理员的 SAML 断言，成功获得联合 Microsoft 365 租户的全局管理员权限。为此，Mandiant 敦促防御者将监控重点转向操作系统加密操作和令牌颁发行为，而非仅依赖应用层存储。

具体建议包括：

对 MachineKeys 目录和机器 DPAPI 保护路径进行对象访问审计，关注安全事件 ID 4663，将其作为支持性证据。

将 ADFS 审计记录与 Entra ID 登录日志关联，识别缺乏清晰上游认证事件的异常联合登录。

针对特权身份，排查异常 IP 范围、声明偏差及不一致的用户代理。

Mandiant 强调，组织应将 ADFS 基础设施视为与域控制器同级的 Tier 0 身份基础设施。若攻击者在 ADFS 服务器上获取 SYSTEM 权限，应默认令牌签名密钥已泄露。

在缓解措施方面，推荐将令牌签名证书移入硬件安全模块（HSM），避免私钥以软件可访问形式存储于主机。同时，建议使用组托管服务帐户运行 ADFS，并在手动管理场景中，确保使用 Set-AdfsCertificate 命令更新配置，而非仅安装替换证书。此外，组织应定期检查 ADFS 配置、LocalMachine 证书存储和联合元数据的一致性，并调查事件 ID 385。鉴于受损密钥会影响所有 SAML 信任方，连接其他 SaaS 应用的组织也应审核相关关系，或考虑放弃基于 ADFS 的联合以彻底消除攻击路径。

【星途科讯 图文丨小林 首发于 ZAKER 科技，转载请注明出处】