Mandiant Uncovers Technique to Steal Active ADFS Signing Keys via Machine DPAPI
Mandiant details a method for attackers to recover active Active Directory Federation Services (ADFS) signing keys using Machine DPAPI, enabling the forging of high-privilege SAML tokens.
Mandiant researchers have detailed a sophisticated technique that allows adversaries to recover active Active Directory Federation Services (ADFS) signing keys, a critical component for securing identity assertions within the Microsoft ecosystem. This method, discovered during a red team engagement, leverages the Machine Data Protection API (DPAPI) to access these keys, which can then be used to forge high-privilege SAML tokens. Such forged tokens enable attackers to impersonate any user, bypass multi-factor authentication (MFA), conditional access policies, and other identity-based security controls, granting them unauthorized access to SAML-federated applications, including Microsoft 365 and Entra ID.
The technique exploits a specific configuration drift scenario that can occur when ADFS certificates are manually rotated, and the AutoCertificateRollover feature is disabled. In these environments, the ADFS service might continue to use a new, valid signing key at the operating system level, while the underlying Windows Internal Database (WID) configuration database remains outdated, referencing an older, potentially expired certificate. This creates a 'ghost certificate'—a record that exists and can be decrypted but is no longer actively used for token signing by the ADFS service. While ADFS Event ID 385 may flag this certificate validity warning, it can self-resolve if AutoCertificateRollover is re-enabled, making its persistent presence an indicator of manual rotation without a corresponding database update.
Traditional extraction methods that rely on the WID database and Data Protection API (DPAPI) material stored in Active Directory might successfully retrieve the encrypted blob of the 'ghost' certificate. However, the resulting token would be rejected by downstream services like Entra ID due to invalid signing material. The critical insight Mandiant uncovered is that the *active* signing key resides in the machine-scoped cryptographic store, protected by Machine DPAPI. This store is managed by the operating system's cryptographic subsystem and is accessible to sufficiently privileged SYSTEM-level contexts, leveraging the DPAPI_SYSTEM LSA secret and machine masterkeys.
This attack vector is particularly concerning because the underlying configuration—manual certificate rotation with AutoCertificateRollover disabled—is common in enterprise environments. Furthermore, the technique avoids direct interaction with highly monitored components like LSASS (Local Security Authority Subsystem Service) or the live ADFS service process. This stealthier approach can potentially evade enhanced monitoring solutions that focus on these more traditional targets, leading to a lower detection probability depending on an organization's telemetry coverage.
The recovery process involves obtaining the encrypted key blob from the WID database and decrypting it using DKM material from Active Directory. However, the key difference lies in accessing the machine-scoped cryptographic store. Unlike user-specific DPAPI, which is tied to a service account's SID and masterkey, Machine DPAPI relies on system-level masterkeys. Mandiant's analysis in the assessed environment indicated that while domain DPAPI backup keys could decrypt masterkeys for interactive user profiles, they did not yield decryptable material for the ADFS service account profile, suggesting that offline decryption of the machine-scoped key might require specific system-level access or recovery methods.
By successfully obtaining the active signing key protected by Machine DPAPI, an attacker can forge valid SAML assertions for any user. This bypasses all identity-based security measures, including credentials and MFA, effectively granting them unfettered access to any SAML-federated application. The implications are severe, potentially allowing for widespread account compromise and data exfiltration within an organization's digital infrastructure.
Mandiant provides a blueprint for defense against this threat. Organizations are advised to ensure AutoCertificateRollover is enabled for ADFS to maintain automatic certificate lifecycle management and prevent configuration drift. Regular auditing of ADFS configurations, specifically checking for disabled AutoCertificateRollover and monitoring for Event ID 385, is crucial. Furthermore, implementing robust monitoring for unusual access patterns to the machine-scoped cryptographic store and ensuring comprehensive logging of ADFS service activities can help detect and prevent such attacks.