数据库中的“幽灵”：通过机器 DPAPI 恢复活动的 ADFS 签名密钥

Written by: Shebin Mathew

Introduction

“Golden SAML”技术最早由 CyberArk 研究人员 于 2017 年提出，随后由 Mandiant 研究人员于 2021 年进一步阐述，至今仍是威胁行为者伪造 Microsoft 生态系统中身份断言的最有效方法之一。通过获取 ADFS 令牌签名证书的私钥，攻击者可以以任意用户身份对任意 SAML 联合应用程序进行身份验证，从而绕过多因素身份验证（MFA）、条件访问以及所有基于身份的控制。

然而，在最近的一次红队演练中，Mandiant 发现当 ADFS 证书被手动轮换时，配置漂移可能会悄无声息地将活动签名密钥暴露在 Machine DPAPI 中。具体而言，Mandiant 发现 在禁用 AutoCertificateRollover 并手动轮换证书的环境中，数据库往往会变成“幽灵”——一条仍然存在、仍然能成功解密，但指向的证书已不再被 ADFS 服务用于令牌签名的记录。这一攻击向量值得关注，因为这种底层配置在企业环境中普遍存在。该技术避免了与 LSASS 和 ADFS 实时服务进程等组件的直接交互，而这些组件在企业环境中通常会受到增强的监控，因此在一定程度上可能降低可见性，具体取决于组织的遥测覆盖范围。本文将详细介绍对手如何利用此 TTP 伪造高权限 SAML 令牌，并提供针对该攻击的防御方案。

Technical Insight: Encountering the ‘Ghost Certificate’

分析人员遵循标准的 DKM 提取路径，从 WID 数据库中检索加密 blob，并使用存储在 Active Directory 中的 DKM 材料进行解密。提取成功，但恢复的证书已不再对令牌签名有效，Entra ID 以 AADSTS500172 拒绝了生成的令牌，原因是签名材料无效。虽然该产物在结构上正确，但无法用于身份验证，因为活动的签名密钥位于系统的机器作用域加密存储中，受 Windows Machine DPAPI 保护，并由操作系统的加密子系统管理。成功获取此活动密钥后，攻击者即可为任意用户伪造有效的 SAML 断言，从而绕过对用户凭据和多因素身份验证的需求，并获得对组织环境中任何 SAML 联合应用程序（包括 Microsoft 365 和 Entra ID）的未授权访问。

分析显示 AutoCertificateRollover 已被禁用，且已执行手动轮换。确认信息直接通过 Get-AdfsProperties 获得，该命令返回 AutoCertificateRollover: False，表明证书生命周期管理已委托给手动管理流程。虽然 ADFS 服务使用了新的有效密钥进行签名，但 WID 配置数据库从未更新以反映新证书——这使得一个已过期的“幽灵”条目成为唯一记录。此漂移状况会通过 Microsoft 事件 ID 385 显现，该事件表示 ADFS 服务中的证书有效性警告。值得注意的是，当 AutoCertificateRollover 重新启用并执行后续证书轮换时，该事件会自行解决；而在禁用该功能并执行手动轮换但未相应更新数据库的环境中，此事件是该漂移状况的可观测症状。

Figure 1: ADFS certificate enumeration output showing configuration drift between the WID database and the active host certificate

ADFS 在两种保护上下文中维护私钥。在 Location 1 (User DPAPI) 中，加密的密钥 blob 可能存在于磁盘上，但 DPAPI 保护与服务账户的 SID 及其关联的 DPAPI 主密钥材料绑定。在被评估的环境中，域 DPAPI 备份密钥方法成功解密了交互式用户配置文件的 MasterKey 材料，但未返回与 ADFS 服务账户配置文件关联的可解密材料。所有后续的离线解密尝试同样失败，这与通过该环境中评估的磁盘恢复方法无法恢复主密钥的观察结果一致——不过该观察结果仅限于被评估的环境，并不代表所有 ADFS 部署的通用架构特性。

Location 2 (Machine RSA) 不依赖于特定用户的登录会话。相反，密钥材料使用 Machine DPAPI 进行保护，利用 DPAPI_SYSTEM LSA 机密以及可供具有足够权限的 SYSTEM 级别上下文访问的机器主密钥。

Why the WID Path Misses This Key

在出现配置漂移的 ADFS 环境中——通常发生在禁用 AutoCertificateRollover 并执行手动证书轮换时——ADFS 服务主机可以在操作系统级别成功绑定到新配置的签名证书，从而确保服务继续运行。然而，WID 配置数据库可能无法反映当前的签名证书，从而导致过时的证书元数据。

配置与运行时状态之间的这种差异是 ADFS 事件 ID 385 设计用于标记的状况。因此，仅依赖 WID 数据库和 DKM 材料的提取技术可能会返回不再用于活动签名的证书，从而导致下游联合场景中的断言被拒绝。

Understanding How the Machine DPAPI Store Becomes Populated

要理解 Machine DPAPI 存储是如何填充的，需要研究 ADFS 如何持久保存其令牌签名密钥材料。在初始部署、自动证书轮换或手动证书轮换期间，ADFS 将其 RSA 私钥材料持久保存在机器作用域的 CAPI 密钥存储中，路径为 C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\，并使用机器 DPAPI 上下文而非用户绑定的 DPAPI 上下文进行保护。在被评估的环境中，SharpDPAPI /machine 枚举确认活动的机器密钥材料位于此路径下，而 CNG Crypto\Keys 存储在该环境中未被使用。

保护链依赖于 DPAPI_SYSTEM LSA 机密以及与 S-1-5-18 安全上下文关联的机器主密钥，这些主密钥以 DPAPI 保护的密钥材料形式存储在 C:\Windows\System32\Microsoft\Protect\S-1-5-18\ ——这两个组件最终仅能在主机上具有高度特权的 SYSTEM 级别上下文中解析。相应的证书已注册到 LocalMachine\My 证书存储中，ADFS 在令牌签名操作期间从该存储中检索关联的私钥。

机器作用域密钥存储的架构理由是操作弹性。机器作用域的密钥可在服务账户密码更改、gMSA 轮换、系统重启和服务重启期间保持可用，无需重新配置密钥或依赖特定的交互式登录会话。这种设计确保 ADFS 服务无论底层服务账户凭据如何变化，都能持续访问签名密钥。

然而，这一设计选择也带来了重要的安全影响。由于私钥使用 Machine DPAPI 而非用户绑定的 DPAPI 上下文进行保护，因此具有足够权限的本地进程（能够访问机器密钥存储和关联的 DPAPI 产物）可能能够在不依赖原始服务登录会话的情况下恢复密钥材料。因此，在某些条件下，恢复活动的 ADFS 令牌签名私钥可能无需直接与 LSASS 内存或实时 ADFS 服务进程交互，从而可能降低主要针对凭据转储或进程内存访问行为的防御措施的可见性。

KEY DESIGN IMPLICATION

ADFS 将其令牌签名私钥材料持久保存在机器作用域的密钥存储中，并使用 Machine DPAPI 语义进行保护。这是经过文档记录的行为，支持机器作用域的密钥持久性，使其在服务账户更改、凭据轮换和服务重启后仍能存续。

然而，这种设计引入了一个在标准 ADFS 加固指南中通常未被强调的操作安全影响：存储在机器密钥存储中的私钥受此保护模型保护，且可能被具有足够权限的 SYSTEM 级别上下文通过访问主机本地的 DPAPI_SYSTEM LSA 机密和机器主密钥进行恢复。

因此，恢复活动的 ADFS 令牌签名私钥可能无需直接与 LSASS 内存或实时 ADFS 服务进程交互，从而可能降低主要针对凭据转储或进程内存访问行为的安全控制的可见性。

Attack Flow: Machine DPAPI Key Recovery to SAML Forgery

Figure 2: Machine DPAPI extraction flow—five-step process from SYSTEM execution to SAML assertion

Figure 3: ‘SharpDPAPI /machine’ output confirming successful recovery of the active ADFS token-signing private key from the machine DPAPI store

恢复的密钥被用于伪造一个模拟全局管理员身份的 SAML 断言，Entra ID 将其接受为有效的身份验证断言，从而在联合 Microsoft 365 租户中获得 Global Administrator 权限级别的经过身份验证的访问。

Detection and Hunting

防御者应优先关注操作系统级加密操作和身份颁发行为的可见性，而非仅依赖应用层配置存储。

• SACL-Based Object Access Monitoring: 通过 SACL 在 C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\ 和 C:\Windows\System32\Microsoft\Protect\S-1-5-18\ 上配置对象访问审计。 当正确配置时，这将生成 Security Event ID 4663 以记录文件访问尝试。覆盖范围取决于 SACL 配置和访问路径；应将其作为基于关联的检测的支持证据，而非独立信号。

• ADFS Token Issuance Consistency: 监控 ADFS 审计日志中主要身份验证事件与令牌颁发事件之间的一致性。相关事件包括令牌颁发和声明处理记录（事件 ID 299、1200 系列，具体取决于 ADFS 版本和审计配置）。目标是识别无法明确关联到先前身份验证上下文的令牌颁发。当按依赖方信任对正常身份验证模式进行基线化时，此方法最为有效。

• Federated Identity Monitoring in Entra ID: Entra ID 登录日志会将接受的伪造断言记录为标准联合登录事件。检测需要将 Entra ID 登录记录与 ADFS 端的颁发日志进行交叉关联——任一来源单独使用都不充分。对于特权账户，应关注异常的 Internet 协议 (IP) 范围、声明集偏差以及用户代理不一致。

Mitigation and Remediation

ADFS 基础设施应被视为 Tier 0 身份基础设施，其关键性等同于域控制器。如果在 ADFS 主机上获得 SYSTEM 访问权限，则必须将签名密钥视为已泄露。

• Hardware-Backed Key Protection: 将令牌签名证书迁移到硬件安全模块 (HSM)。HSM 支持的密钥确保私钥材料不会存在于主机上的软件可访问存储中，从而完全消除 Machine DPAPI 提取路径。

• gMSA Service Identity: 使用组托管服务账户运行 ADFS 服务，以实现凭据自动轮换并减少服务身份管理中的操作漂移。虽然这并不能直接解决机器作用域密钥保护问题，但消除了手动凭据管理作为配置漂移促成因素。

• Tier 0 Administrative Controls: 使用严格的 Tier 0 控制治理 ADFS 服务器：受限的管理访问路径、专用特权访问工作站 (PAW)、与通用服务器管理域分离，以及增强的特权访问监控。

• Certificate Rotation and Configuration Validation: 如果怀疑已泄露，请轮换令牌签名证书，并验证 ADFS 配置、 LocalMachine\My 存储和联合元数据之间的一致性。不要依赖单一事实来源。对于禁用 AutoCertificateRollover 的环境，手动轮换必须包含通过 Set-AdfsCertificate 更新 ADFS——仅安装证书是不够的。轮换后使用 Get-AdfsCertificate 进行验证。如果之后出现事件 ID 385，请调查是否存在配置不一致。

• Multicloud Scope Awareness: 泄露的 ADFS 令牌签名密钥会影响所有 SAML 依赖方信任，而不仅仅是 Microsoft 服务。使用 ADFS 进行跨其他软件即服务 (SaaS) 平台身份联合的组织应将 ADFS 视为 Tier 0 基础设施，并审计所有依赖方信任。迁移出基于 ADFS 的联合（例如迁移到原生 OIDC 联合）可消除此特定攻击路径。

• Threat Intelligence