先说一个值得警惕的攻击场景——Golden SAML技术自2017年由CyberArk研究员首次披露，再到2021年Mandiant团队进一步细化，至今仍是微软生态系统中最高效的身份断言伪造手法之一。攻击者一旦拿到ADFS令牌签名证书的私钥，就能以任意用户身份登录任何支持SAML联合的应用，多因素认证、条件访问策略、基于身份的一切防护，统统绕开。
不过，在一次最近的红队演练中，Mandiant发现了一个容易被忽视的盲区：当ADFS证书被人为轮换时，配置漂移可能会悄悄把仍可用的签名密钥暴露在Machine DPAPI中。具体来说，在AutoCertificateRollover被禁用、证书由手工轮换的环境里，数据库中常常会残留一条“幽灵记录”——它看似正常，能解密，指向的证书却不被ADFS服务用于令牌签名。这个攻击向量的麻烦之处在于，它的底层配置在企业环境中相当普遍。而且，这套方法不需要触碰LSASS，也不涉及运行中的ADFS服务进程——这两个恰恰是企业监控的重点对象，因而很可能在遥测覆盖面不足的组织里悄无声息地溜过去。这篇文章就来拆解攻击者如何利用这种TTP伪造高权限SAML令牌，以及防御方该如何应对。
技术深析：遭遇“幽灵证书”
分析师按照标准DKM提取路径操作：从WID数据库中取出加密的Blob，再用存储在Active Directory中的DKM材料解密。提取过程很顺利，但恢复出来的证书已经不能用于令牌签名。拿它生成令牌提交给Entra ID，返回的是AADSTS500172错误——签名材料无效。这个工件结构上没错，但已经无法用于认证。真正有效的签名密钥存在于系统的机器级加密存储中，由Windows Machine DPAPI保护，通过操作系统的加密子系统管理。如果能拿到这个活跃密钥，攻击者就可以伪造任意用户的SAML断言，既不需要用户凭据，也绕过多因素认证，还能直接访问组织内包括Microsoft 365和Entra ID在内的所有SAML联合应用。
进一步分析发现，AutoCertificateRollover被禁用了，而且确实执行过手工轮换。通过Get-AdfsProperties直接确认，返回结果是AutoCertificateRollover: False——也就是说，证书生命周期管理交给了人工流程。ADFS服务当时用的是新有效密钥签名，但WID配置数据库从来没有更新过，只留下一条过期的“幽灵”记录作为唯一凭证。这种配置漂移状态可以通过Microsoft事件ID 385捕捉到，它标志着ADFS服务中的证书有效性警告。有意思的是，一旦重新启用AutoCertificateRollover并执行一次证书轮换，这个事件就会自动消失；但在禁用自动轮换且手工轮换未同步更新数据库的环境中，事件ID 385就是配置漂移的可见症状。
图1：ADFS证书枚举输出，清晰展示WID数据库与活跃主机证书之间的配置漂移
ADFS维护私钥的方式有两种保护上下文。位置1（User DPAPI）中，加密密钥Blob可能存在于磁盘上，但DPAPI保护与服务账户的SID及相关的DPAPI主密钥材料绑定。在本次评估环境中，域DPAPI备份密钥方法成功解密了交互式用户配置文件的主密钥材料，但未能返回与ADFS服务账户配置相关联的可解密材料。随后所有的离线解密尝试也都失败了，这与该环境中主密钥无法通过评估的磁盘恢复方法获取的情况一致——不过这仅限于本次评估环境，不代表所有ADFS部署的通用架构特性。
位置2（Machine RSA）则不同，它不依赖用户特定的登录会话。密钥材料由Machine DPAPI保护，利用DPAPI_SYSTEM LSA秘密以及机器主密钥——这些只有在拥有足够权限的SYSTEM级上下文中才能访问。
为什么WID路径拿不到这个密钥
在ADFS环境出现配置漂移时——通常发生在手工证书轮换且AutoCertificateRollover被禁用的情况下——ADFS服务主机能在操作系统层面成功绑定新分发的签名证书，保证服务正常运行。但WID配置数据库可能并没有更新当前签名证书的信息，导致证书元数据过期。配置与运行时状态之间的这种偏差，正是ADFS事件ID 385设计要标记的情况。后果就是，完全依赖WID数据库和DKM材料的提取技术，很可能返回一些不再用于签名操作的证书，最终导致下游联合场景中断。
Machine DPAPI存储是如何被填充的
要理解Machine DPAPI存储是如何被填充的，就得看看ADFS如何持久化它的令牌签名密钥材料。在初始部署、自动证书轮换或手工证书轮换过程中，ADFS会把RSA私钥材料持久化到机器范围的CAPI密钥存储中，路径是C:ProgramDataMicrosoftCryptoRSAMachineKeys，保护方式用的是机器DPAPI上下文，而不是绑定到某个用户的DPAPI上下文。在本次评估环境中，SharpDPAPI /machine枚举确认活跃的机器密钥材料就在这个路径下，而CNG CryptoKeys存储在本环境中未观察到使用。
整个保护链条依赖DPAPI_SYSTEM LSA秘密以及机器主密钥——这些主密钥与S-1-5-18安全上下文关联，存储在C:WindowsSystem32MicrosoftProtectS-1-5-18中，作为DPAPI保护的密钥材料。这两个组件只在主机上拥有高权限的SYSTEM级上下文中才能解析。对应的证书会被登记到LocalMachineMy证书存储中，ADFS在令牌签名操作时从那里提取关联的私钥。
从架构角度看，选择机器范围密钥存储是为了操作韧性。机器范围密钥在服务账户密码变更、gMSA轮换、系统重启和服务重启后仍然可用，不需要重新配置密钥或依赖特定的交互式登录会话。这种设计确保ADFS服务可以始终访问签名密钥，不管底层服务账户凭据如何变化。
但同一设计也带来了重要的安全后果。由于私钥由Machine DPAPI而非用户绑定的DPAPI上下文保护，一个拥有足够权限的本地进程如果能够访问机器密钥存储及相关DPAPI工件，就有可能独立于原始服务登录会话恢复密钥材料。这意味着，在某些条件下，恢复活跃的ADFS令牌签名私钥可以不用直接与LSASS内存或运行中的ADFS服务进程交互，从而可能降低在主要关注凭据转储或进程内存访问行为的安全控制措施下的可见性。
|
关键设计含义 ADFS将其令牌签名私钥材料持久化在机器范围的密钥存储中，由Machine DPAPI语义保护。这是文档化的行为，目的是确保机器范围的密钥持久性，能在服务账户变更、凭据轮换和服务重启后继续存在。 然而，这种设计引入了一个在标准ADFS加固指南中通常不被强调的操作安全含义：存储在机器密钥存储中的私钥受到这种保护模型的保护，并且可以通过在主机上本地可用的DPAPI_SYSTEM LSA秘密和机器主密钥，由拥有足够特权的SYSTEM级上下文恢复。 因此，恢复活跃的ADFS令牌签名私钥可能不需要直接与LSASS内存或运行中的ADFS服务进程交互，从而可能降低在主要关注凭据转储或进程内存访问行为的安全控制措施下的可见性。 |
攻击流程：从Machine DPAPI密钥恢复到SAML伪造
图2：Machine DPAPI提取流程——从SYSTEM执行到SAML断言的五步过程
图3：'SharpDPAPI /machine'输出，确认已从机器DPAPI存储成功恢复活跃的ADFS令牌签名私钥
恢复出来的密钥被用于伪造一个SAML断言，冒充全局管理员身份。Entra ID将其视为有效的认证断言并接受，最终在联合Microsoft 365租户内以全局管理员权限级别获得认证访问。
检测与狩猎
防御方应该优先关注操作系统级别的加密操作和身份颁发行为，而不是仅仅依赖应用层的配置存储。
SACL基于对象访问监控：通过SACL在
C:ProgramDataMicrosoftCryptoRSAMachineKeys和C:WindowsSystem32MicrosoftProtectS-1-5-18上配置对象访问审计。正确配置后，文件访问尝试会触发安全事件ID 4663。覆盖范围取决于SACL配置和访问路径；将其视为基于关联的检测中的辅助信号，而非独立信号。ADFS令牌颁发一致性：监控ADFS审计日志中主要认证事件与令牌颁发事件之间的不一致。相关事件包括令牌颁发和声明处理记录（事件ID 299，1200系列，具体取决于ADFS版本和审计配置）。目标是识别那些无法与明确的认证上下文关联的令牌颁发。最佳实践是先对每个信赖方信任的常规认证模式进行基线化。
Entra ID中的联合身份监控：Entra ID登录日志会将已接受的伪造断言记录为标准联合登录事件。检测需要将Entra ID登录记录与ADFS端颁发日志进行交叉关联——两者单独看都不够。对于特权账户，重点关注意外的IP范围、声明集偏差和用户袋里不一致。
缓解与修复
ADFS基础设施应被视为Tier 0身份基础设施，其重要性等同于域控制器。如果在ADFS主机上获得了SYSTEM级访问，签名密钥必须视为已泄露。
硬件-backed密钥保护：将令牌签名证书迁移到硬件安全模块（HSM）。HSM-backed密钥确保私钥材料不会以软件形式存在于主机上，彻底消除Machine DPAPI提取路径。
gMSA服务身份：使用组托管服务账户运行ADFS服务，自动进行凭据轮换，减少服务身份管理中的操作漂移。虽然这不直接解决机器范围密钥保护问题，但它消除了手工凭据管理作为配置漂移的一个促成因素。
Tier 0管理控制：用严格的Tier 0控制策略治理ADFS服务器：限制管理访问路径、使用独立特权访问工作站（PAW）、与通用服务器管理域隔离、加强特权访问监控。
证书轮换与配置验证：如果怀疑已遭入侵，请轮换令牌签名证书，并验证ADFS配置、
LocalMachineMy存储和联合metadata之间的一致性。不要依赖单一真相源。对于AutoCertificateRollover禁用的环境，手工轮换必须包含通过Set-AdfsCertificate更新ADFS——仅安装证书是不够的。轮换后使用Get-AdfsCertificate验证。如果之后出现事件ID 385，请调查配置不一致。多云范围意识：受损的ADFS令牌签名密钥影响所有SAML信赖方信任，而不仅是微软服务。使用ADFS进行跨其他SaaS平台身份联合的组织应将ADFS视为Tier 0基础设施，并审计所有信赖方信任。从ADFS-based联合迁移（例如，迁移到原生OIDC联合）可消除此特定攻击路径。