Ghost in the Database: Recovering Active ADFS Signing Keys

Imagine paddling through a swamp, thinking you’ve found the perfect deep pool, only to realize it’s a ghost—a dry bed that looks right but won’t hold water. That’s exactly what Mandiant researchers encountered when they tried to extract ADFS signing keys from the WID database. The keys were there, but they were expired, useless for forging SAML tokens. The real treasure? It was hiding in a different spot: the Machine DPAPI store.

The Ghost Certificate Problem

When AutoCertificateRollover is disabled and certificates are manually rotated, the ADFS service happily uses a new signing key, but the WID database never gets the memo. It still holds the old, expired certificate—a ‘ghost’ entry. Attackers who only look in the database end up with tokens that Entra ID rejects with AADSTS500172. But the active key is still on the host, protected by Machine DPAPI.

Where the Real Key Lives

ADFS stores its token-signing private key in the machine-scoped CAPI key store at C:ProgramDataMicrosoftCryptoRSAMachineKeys, protected by Machine DPAPI. This design ensures the key survives service account changes and reboots, but it also means a sufficiently privileged process (SYSTEM-level) can recover it without touching LSASS or the ADFS service process—potentially flying under the radar of defenses focused on credential dumping.

Attack Flow: From Machine DPAPI to SAML Forgery

1. Obtain SYSTEM-level access on the ADFS host.
2. Use SharpDPAPI with the /machine flag to enumerate and decrypt the machine key store.
3. Extract the active token-signing private key.
4. Forge a SAML assertion impersonating any user (e.g., Global Administrator).
5. Authenticate to any SAML-federated app (Microsoft 365, etc.) bypassing MFA.

Mandiant demonstrated this successfully, forging a Global Administrator token that Entra ID accepted.

Detection and Hunting

• SACL Auditing: Monitor access to MachineKeys and ProtectS-1-5-18 via Security Event ID 4663.
• Token Issuance Consistency: Look for ADFS token issuance (Event IDs 299, 1200-series) without a corresponding primary authentication event.
• Entra ID Sign-in Logs: Cross-correlate federated sign-ins with ADFS logs; watch for unusual IPs, claims, or user-agents for privileged accounts.

Mitigation and Remediation

• Use an HSM: Hardware-backed keys never exist in software-accessible storage, eliminating the Machine DPAPI path.
• gMSA for ADFS: Group Managed Service Accounts reduce credential drift.
• Tier 0 Controls: Treat ADFS servers like Domain Controllers—restrict admin access, use PAWs, and monitor heavily.
• Validate Certificate Rotation: After manual rotation, run Set-AdfsCertificate and verify with Get-AdfsCertificate. If Event ID 385 appears, investigate.
• Consider Migration: Moving from ADFS to native OIDC federation removes this attack surface entirely.

For more on securing your identity infrastructure, check out our reviews of Cloudflare Workers and Neon Database—both offer modern, secure alternatives to legacy federation.

Original announcement published on Google Cloud.