The ‘Ghost’ in the Database: Recovering Active ADFS Signing Keys via Machine DPAPI

The ‘Ghost’ in the Database: Recovering Active ADFS Signing Keys via Machine DPAPI
Mandiant showed that in ADFS environments with AutoCertificateRollover disabled and manual certificate rotation, a “ghost” certificate entry can leave the active token-signing key recoverable from Machine DPAPI. If that key is obtained, attackers can forge SAML assertions to impersonate users, bypass MFA, and gain access to federated services such as Microsoft 365 and Entra ID. #ADFS #EntraID #Microsoft365 #GoldenSAML

Keypoints

  • Golden SAML remains a powerful technique for forging identity assertions in Microsoft federated environments.
  • Mandiant found that manual ADFS certificate rotation can create configuration drift between the active signing key and the WID database.
  • When AutoCertificateRollover is disabled, the WID database may retain a stale “ghost” certificate record that still decrypts but is no longer used for signing.
  • The active ADFS token-signing private key may reside in Machine DPAPI-protected storage under the machine key store, not only in the DKM/WID path.
  • Recovering the active key can allow attackers to forge valid SAML assertions and impersonate privileged users, including Global Administrator accounts.
  • Defenders should monitor ADFS Event ID 385, file access to MachineKeys and ProtectS-1-5-18, and inconsistencies between ADFS and Entra ID logs.
  • Recommended mitigations include HSM-backed keys, gMSA usage, Tier 0 controls, and careful certificate rotation validation with Set-AdfsCertificate and Get-AdfsCertificate.

MITRE Techniques

  • [T1003.001 ] OS Credential Dumping: LSASS Memory – The article notes attackers may avoid direct interaction with LSASS, implying this common credential-dumping path is not required for the key-recovery approach (‘without direct interaction with LSASS memory or the live ADFS service process itself’).
  • [T1552.004 ] Unsecured Credentials: Private Keys – Adversaries recover the ADFS token-signing private key from machine-scoped storage and use it to forge SAML assertions (‘recover the key material’, ‘forge valid SAML assertions’).
  • [T1558.002 ] Steal or Forge Kerberos Tickets: Silver Ticket – The article’s Golden SAML abuse is analogous to forging authentication artifacts to impersonate users (‘forge identity assertions’, ‘impersonating a Global Administrator identity’).
  • [T1550.001 ] Use Alternate Authentication Material: Application Access Token – Attackers use forged SAML assertions as alternate authentication material to access federated applications (‘authenticate as any user to any SAML-federated application’).
  • [T1484.002 ] Domain or Tenant Policy Modification – The attack abuses federation trust and identity issuance controls in a Microsoft identity environment (‘bypass multifactor authentication, conditional access, and all identity-based controls’).
  • [T1112 ] Modify Registry – The article does not explicitly mention registry modification, so no item listed.

Indicators of Compromise

  • [File paths ] ADFS machine key and DPAPI-protected material locations used during key storage and access checks – C:ProgramDataMicrosoftCryptoRSAMachineKeys, C:WindowsSystem32MicrosoftProtectS-1-5-18
  • [Windows Event IDs ] ADFS drift and access telemetry – Event ID 385, Event ID 4663
  • [ADFS / Entra ID error and audit indicators ] certificate/sign-in validation and federation activity – AADSTS500172, Event IDs 299 and 1200-series
  • [PowerShell / tooling output ] certificate and machine-key enumeration references – Get-AdfsProperties, Get-AdfsCertificate, Set-AdfsCertificate, SharpDPAPI /machine
  • [Certificate / identity stores ] locations referenced for signing certificate validation – LocalMachineMy, WID database, DKM material in Active Directory


Read more: https://cloud.google.com/blog/topics/threat-intelligence/recovering-active-adfs-signing-keys-machine-dpapi/