Mandiant has documented a way to recover a live ADFS token-signing private key from the machine-scoped DPAPI store, and used it in a red team engagement to forge a SAML assertion that Entra ID accepted as Global Administrator.

What that key is worth:

By obtaining the private key of an ADFS token-signing certificate, an attacker can authenticate as any user to any SAML-federated application, bypassing multifactor authentication (MFA), conditional access, and all identity-based controls.

This is Golden SAML, first described by CyberArk in 2017. What is new is the extraction path.

The precondition, stated honestly

SYSTEM on the ADFS host. That is not a small ask, and anyone presenting this as a remote attack is misreading it.

But Mandiant's own framing of why it still matters is the right one: if SYSTEM is achieved on an ADFS host, the signing key must be considered compromised — and most organisations do not treat ADFS as though that were true.

The "ghost certificate"

The interesting failure is a configuration drift almost nobody audits for.

When AutoCertificateRollover is disabled and certificates are rotated by hand, administrators frequently install the new certificate without updating ADFS itself. The result:

the database often becomes a "ghost" — a record that still exists, still decrypts successfully, but references a certificate no longer used for token signing by the ADFS service.

So an investigator reading the configuration database sees a retired certificate and concludes nothing of value is there. The live key is somewhere else: in the machine key store at C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\, protected by the DPAPI_SYSTEM LSA secret and machine masterkeys under S-1-5-18.

Mandiant confirmed the active key material's location with SharpDPAPI /machine enumeration.

Why it evades the monitoring you have

The technique never touches the things security teams watch:

The technique avoids direct interaction with components such as LSASS and the live ADFS service process, which are often subject to enhanced monitoring in enterprise environments, and may therefore result in lower visibility depending on the organization's telemetry coverage.

No LSASS access. No interaction with the running service. No credential-dumping behaviour to alert on. Just file reads against a crypto directory and an LSA secret — both of which a SYSTEM process is entitled to do.

This is documented behaviour, not a bug

Worth being clear: Microsoft has not patched this and probably will not, because it is how the design works. Machine-scoped DPAPI protection is what lets ADFS keys survive service-account password changes, gMSA rotations and reboots. That resilience is the feature.

Mandiant's framing:

this design introduces an operational security implication that is not commonly emphasized in standard ADFS hardening guidance

Not a vulnerability. An implication of an architecture, plus a configuration habit that hides where the live key actually is.

Detection, in order of usefulness

1. Token issuance without preceding authentication. Compare primary authentication events against token issuance in the ADFS audit log — Event IDs 299 and the 1200-series, depending on version. A forged assertion produces the second without the first. This is the strongest signal available.

2. Configuration drift — ADFS Event ID 385. This is the observable symptom of the ghost condition. It self-resolves once AutoCertificateRollover is re-enabled and a rollover runs; if it persists in a manually-rotated environment, that is the drift.

3. SACL auditing on the crypto stores. Object access auditing on MachineKeys\ and the S-1-5-18 protect directory generates Event ID 4663. Mandiant is explicit that this is supporting evidence, not a standalone signal — legitimate processes read those paths.

4. Federated identity correlation. For privileged accounts, watch for unexpected IP ranges, claim-set deviations and user-agent inconsistencies, cross-correlating Entra ID sign-in logs with ADFS-side issuance. Neither source alone is sufficient.

What to fix

  • Treat ADFS as Tier 0. Same controls as a domain controller: restricted admin paths, dedicated privileged access workstations, separation from general server administration.
  • Validate that your rotations completed. With AutoCertificateRollover disabled, installing the certificate is not enough — you must run Set-AdfsCertificate, then verify with Get-AdfsCertificate. This single check finds the ghost condition.
  • Move token-signing keys to an HSM. That removes the extraction path entirely, because the key never exists in software-accessible storage.
  • Run ADFS under gMSA to cut the credential-rotation drift that causes this in the first place.
  • Audit every relying party trust, not just Microsoft ones. A compromised signing key affects every SAML application you federate — including the SaaS platforms nobody remembers configuring.
  • Consider migrating off ADFS to native OIDC federation, which removes this path along with several others.

What is not established

  • Not observed in the wild. This came out of a Mandiant red team engagement. Nothing here says an actual intrusion has used it.
  • No CVE and no patch, because the behaviour is by design.
  • No prevalence figure. Mandiant says the configuration is "commonly deployed"; nobody has counted.

The one thing to take away if you take nothing else: run Get-AdfsCertificate and check that what ADFS thinks it is signing with is what is actually on disk.