OFICIAL Google Cloud Threat Intelligence

Recovering Active ADFS Signing Keys via Machine DPAPI

What happened
Based on Google Cloud Threat Intelligence · Jul 07, 2026

Researchers found that misconfigured ADFS certificate rotations can expose active signing keys via Machine DPAPI, enabling adversaries to forge SAML tokens and bypass MFA in Microsoft environments.

Recovering Active ADFS Signing Keys via Machine DPAPI
Google Cloud Threat Intelligence — Google
Key points
·
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.
·
However, during a recent red team engagement, Mandiant discovered that when ADFS certificates are manually rotated, configuration drift can silently leave active signing keys exposed in Machine DPAPI.
·
This attack vector warrants attention because the underlying configuration is commonly deployed in enterprise environments.
·
This post details how adversaries may exploit this TTP to forge high-privilege SAML tokens and provides the blueprint to defend against it.

In a recent red team assessment, Mandiant discovered that manually rotated ADFS certificates can leave active signing keys exposed in Machine DPAPI when AutoCertificateRollover is disabled. This configuration drift creates 'ghost' entries in the WID database that reference outdated certificates, allowing attackers to extract and misuse the keys without interacting with monitored processes like LSASS.

The exposed keys are stored in the machine-scoped cryptographic store, protected by Windows Machine DPAPI and accessible only via SYSTEM-level contexts. Successfully recovering these keys enables adversaries to forge valid SAML assertions, bypassing MFA and granting unauthorized access to SAML-federated applications, including Microsoft 365 and Entra ID, at high privilege levels.

The attack exploits a documented ADFS behavior where token-signing private keys persist in the machine key store, surviving service account changes and credential rotations. This design choice, intended for operational resilience, inadvertently introduces a security risk by allowing key recovery through access to DPAPI_SYSTEM LSA secrets and machine masterkeys on the host.

Defenders are advised to implement SACL-based object access monitoring on critical cryptographic directories, track inconsistencies in ADFS token issuance logs, and cross-correlate Entra ID sign-in records with ADFS-side issuance events. ADFS infrastructure should be treated as Tier 0 identity infrastructure, with SYSTEM access on ADFS hosts treated as a potential key compromise.

Original source → Deals on Clipraptor.com →