The Key That Never Leaves
On July 7, 2026, Mandiant published research demonstrating a technique to recover active ADFS token-signing private keys from Machine DPAPI stores — without interacting with LSASS memory or the live ADFS service process. The recovered key was used to forge a SAML assertion that impersonated a Global Administrator. Microsoft Entra ID accepted it as a valid authentication. The attacker gained full administrative access to a federated Microsoft 365 tenant.
How It Works
ADFS stores token-signing private keys in the Machine RSA key store at C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\, protected by Machine DPAPI using the DPAPI_SYSTEM LSA secret. The master keys sit at C:\Windows\System32\Microsoft\Protect\S-1-5-18\. An attacker with SYSTEM-level access on the ADFS host can decrypt the signing key using SharpDPAPI, extract the private key, and forge SAML assertions for any user in any federated application.
The critical detail: this key material persists through service account password changes, gMSA rotations, system reboots, and service restarts. No user-bound logon session is required. The key is always there, protected only by SYSTEM-level access to the host. And because the technique never touches LSASS memory or the ADFS service process, it evades every detection mechanism designed to catch credential dumping.
The Ghost Certificate
The attack becomes worse in environments where AutoCertificateRollover is disabled and administrators perform manual certificate rotation — a common enterprise configuration. When an administrator provisions a new signing certificate at the OS level but does not update ADFS via Set-AdfsCertificate, a configuration drift occurs. The ADFS internal database (WID) retains metadata for the old certificate. The service binds to the new certificate. The old certificate becomes a ghost — invisible to administrative queries, but still present in the Machine DPAPI store.
Mandiant found that extracting the key from the WID database path yields this ghost certificate, which Entra ID rejects with error AADSTS500172. The correct path is the Machine RSA store, where the active signing key lives undetected. Event ID 385 in ADFS logs — a certificate validity warning — is the observable indicator of this configuration drift, but most organizations treat it as routine noise.
Not a Vulnerability. A Design Decision.
There is no CVE for this technique. ADFS persists token-signing private keys in machine-scoped storage protected by Machine DPAPI — this is documented, intended behavior. Microsoft designed it this way. The security implication is that any attacker who achieves SYSTEM access on an ADFS server automatically possesses the material to impersonate any user across every SAML-federated application in the organization. Not just Microsoft 365. Every relying party trust.
The original Golden SAML technique was described by CyberArk in 2017 and used by Mandiant in incident response investigations as early as 2021. This new variant extends the attack by avoiding the paths that defenders have learned to monitor — LSASS access, ADFS service process interaction, credential dump behaviors. The technique operates entirely within the machine DPAPI context, a layer that standard EDR, SIEM, and XDR deployments do not monitor for identity-material extraction.
Detection Is Cross-Correlation or Nothing
Mandiant identified four detection approaches, none sufficient alone. SACL-based monitoring on the MachineKeys directory generates Event ID 4663 on access — but only as a supporting signal. ADFS audit events 299 and 1200-series can reveal token issuance without preceding authentication context. Entra ID sign-in logs record forged assertions as standard federated sign-ins, indistinguishable from legitimate ones without cross-referencing ADFS-side issuance logs. Event ID 385 flags the certificate drift condition.
The detection problem is structural: no single log source reveals the attack. Only correlation across ADFS server file-access logs, ADFS audit events, and Entra ID sign-in logs can surface the anomaly. Most security operations centers monitor Entra ID or ADFS, not both with cross-correlation. The gap between what exists in logs and what is operationally monitored is where this technique lives.
The Fix Is Replacement
Mandiant's primary remediation is hardware-backed key protection — migrate token-signing certificates to a Hardware Security Module so private key material never exists in software-accessible storage. The secondary recommendation is more fundamental: replace ADFS-based federation with native OIDC federation. Eliminate the SAML signing key entirely.
Both recommendations amount to the same conclusion: the fix for ADFS is to stop using ADFS. This is the pattern that runs through every legacy infrastructure analysis — the cost of continued operation is not the licensing fee or the maintenance window. It is the accumulation of design decisions made in a different threat era, now exploitable by techniques their architects never anticipated. ADFS was designed when SYSTEM access on a domain-joined server was the end of the attack chain, not the beginning.
