Google Cloud/Mandiant published a sharp reminder that federation infrastructure is not “just another server.” In ADFS environments, the token-signing private key is the trust anchor that lets users authenticate into Microsoft 365, Entra ID, and other SAML-connected SaaS applications. If an attacker can recover that key, they may be able to forge valid SAML assertions — the classic “Golden SAML” problem — and bypass many of the controls defenders normally count on, including MFA and conditional access.
The latest research highlights a specific operational risk: ADFS environments that manually rotate certificates with AutoCertificateRollover disabled can drift out of alignment. The Windows Internal Database may still hold stale certificate metadata while the active signing key lives in the machine-scoped Windows cryptographic store. That matters because a sufficiently privileged attacker on the ADFS host may not need to dump LSASS or interact directly with the live ADFS service process to recover signing material. The risk moves from “credential theft” into “identity infrastructure compromise.”
Source: Google Cloud / Mandiant — Recovering Active ADFS Signing Keys via Machine DPAPI
What happened
Mandiant describes a red-team finding where the expected ADFS database/DKM extraction path recovered a certificate, but that certificate was no longer the active signing key. The environment had manually rotated certificates and disabled automatic rollover. ADFS continued operating because the active key was available through the local machine certificate store, while the database record had become a stale “ghost” entry.
The practical consequence is ugly: SYSTEM-level compromise of an ADFS server can become compromise of the federation signing key. Once the signing key is exposed, an attacker may be able to mint trusted SAML assertions for privileged identities and access relying-party applications as though authentication legitimately occurred.
Why this matters for SMBs and government contractors
Many smaller enterprises and contractors still run ADFS because it was deployed years ago for Microsoft 365 federation, legacy SSO, VPN portals, business applications, or partner access. Those servers often sit quietly in the background until something breaks. That is the danger.
For a government contractor, federation servers should be treated as Tier 0 identity infrastructure, in the same class as domain controllers, certificate authorities, privileged access systems, and cloud identity administrators. If an attacker compromises ADFS signing material, the blast radius can extend across email, SharePoint, Teams, finance systems, customer portals, and any third-party SaaS relying on the same trust.
Defensive takeaways
- Inventory ADFS and all relying-party trusts. Know exactly which SaaS and internal apps trust ADFS-issued assertions.
- Validate certificate state, not just certificate dates. Compare ADFS configuration, the LocalMachine certificate store, and federation metadata. If manual rotation is used, confirm the configuration was updated with the proper ADFS tooling.
- Investigate ADFS Event ID 385. Treat certificate validity or drift warnings as identity-risk indicators, not routine noise.
- Harden ADFS like a domain controller. Restrict admin paths, require privileged access workstations, remove broad server-admin access, and monitor privileged logons to federation hosts.
- Audit machine key access. Where feasible, configure object access auditing on machine key and SYSTEM DPAPI paths and correlate that telemetry with privileged process activity.
- Correlate Entra ID sign-ins with ADFS issuance logs. A forged assertion can look like a normal federated sign-in in cloud logs. The signal often appears when cloud sign-in records do not line up with expected ADFS-side authentication and issuance events.
- Plan migration or key protection. If ADFS must remain, consider HSM-backed signing keys. If it does not need to remain, migration toward modern cloud-native federation/OIDC patterns can remove this specific attack path.
Bulwark Black assessment
This is not a mass-exploitation story. It is more important than that. It is a reminder that identity trust anchors are the crown jewels, and they often fail through drift, manual process, and incomplete monitoring rather than a flashy zero-day.
The key question for defenders is simple: if someone gets SYSTEM on your ADFS server today, do you have the telemetry, isolation, and recovery plan to treat every federated application as potentially compromised? If the answer is unclear, ADFS belongs in the next identity-security review, not the next annual audit.
