Mandiant finds way to recover active ADFS signing keys

Google-owned Mandiant has disclosed a way to recover active ADFS signing keys from Machine DPAPI on Windows hosts. The finding centres on some ADFS deployments where certificate records and live signing material have drifted apart.

The research outlines a path to abuse Active Directory Federation Services when organisations disable AutoCertificateRollover and rotate certificates manually without fully updating the configuration. In that state, the ADFS service can continue signing tokens with a valid certificate stored in the host's machine-scoped cryptographic store, while the Windows Internal Database still holds a stale record for an older certificate.

This gap matters because attackers who obtain the active private key can forge SAML assertions for any user in a federated environment. That can provide access to applications tied to ADFS, including Microsoft 365 and Entra ID, while bypassing multifactor authentication and other identity controls.

The issue builds on the long-known "Golden SAML" technique, which relies on theft of an ADFS token-signing certificate. What is new here is the method used to recover the live key when the database record points only to what the researchers described as a "ghost" certificate that is no longer used for signing.

During a red team engagement, analysts first followed the standard process of extracting an encrypted blob from the ADFS database and decrypting it with Distributed Key Manager material stored in Active Directory. That yielded a certificate, but it was no longer valid for token signing, and assertions created with it were rejected by Entra ID.

Further analysis showed that the active signing key remained on the server in the machine RSA key store and was protected by Machine DPAPI rather than a user-linked DPAPI context. In practice, that meant a sufficiently privileged process running as SYSTEM on the host could recover the key without directly interacting with LSASS memory or the live ADFS service process.

How drift appears

The condition appears in environments where administrators have turned off automatic certificate rollover and carried out a manual certificate change. According to the report, the host can bind to a newly provisioned signing certificate at the operating-system level and continue to function, but the ADFS database may never be updated to reflect the change.

In those cases, Microsoft Event ID 385 can indicate certificate validity warnings in the ADFS service. The event can clear after AutoCertificateRollover is re-enabled and another rollover occurs, but in manually managed environments it may remain the clearest sign of drift.

ADFS stores private key material in more than one protection context. The report said user DPAPI-protected key blobs may exist on disk, but in the environment examined the team could not recover usable master key material associated with the ADFS service account profile through the methods it tested. By contrast, the active machine key material was found under the Windows machine key store path and linked to machine master keys available to the local SYSTEM context.

Mandiant said this architecture is designed for operational resilience because machine-scoped keys remain available across service account password changes, Group Managed Service Account rotations, reboots and service restarts. The same design, it said, creates a security weakness because the key may be recoverable locally by a sufficiently privileged actor.

Privilege risk

The report said the recovered key was used to forge a SAML assertion impersonating a Global Administrator, which Entra ID accepted as valid. That resulted in authenticated access at Global Administrator level within the federated Microsoft 365 tenant used in the assessment.

The researchers urged defenders to focus monitoring on operating-system cryptographic operations and token issuance behaviour rather than relying only on application-layer stores. They recommended object access auditing on the MachineKeys directory and the machine DPAPI protection path, which can generate Security Event ID 4663 when files are accessed, though that signal should be treated as supporting evidence rather than a stand-alone alert.

They also called for correlation between ADFS audit records and Entra ID sign-in logs to identify accepted federated sign-ins that do not match a clear upstream authentication event. For privileged identities, the report recommended looking for unusual IP ranges, claim deviations and inconsistent user agents.

Mitigation steps

Mandiant said organisations should treat ADFS infrastructure as Tier 0 identity infrastructure, on par with domain controllers. If an attacker reaches SYSTEM level on an ADFS server, the token-signing key should be treated as compromised.

Among the recommended mitigations was moving token-signing certificates into a Hardware Security Module so private key material is not present in software-accessible storage on the host. The report also recommended running ADFS with Group Managed Service Accounts, although it noted that this does not remove the machine-scoped key issue itself.

For organisations that continue to manage ADFS manually, certificate rotation must include updating ADFS with Set-AdfsCertificate rather than simply installing a replacement certificate, the researchers said. They advised checking consistency across ADFS configuration, the LocalMachine certificate store and federation metadata, and investigating Event ID 385 after any rotation.

The warning extends beyond Microsoft services because a compromised ADFS signing key can affect every SAML relying party trust connected to that federation setup. The report said organisations using ADFS to connect other software-as-a-service applications should audit all of those relationships and consider moving away from ADFS-based federation to remove this attack path entirely.