The “Golden SAML” technique has long been recognized as a high-impact method for bypassing authentication in the Microsoft ecosystem. By obtaining the private key of an Active Directory Federation Services (ADFS) token-signing certificate, an adversary can forge identity assertions for any user, effectively neutralizing multifactor authentication (MFA). New research from Mandiant researchers indicates that traditional extraction methods may fail in environments with specific configuration drift, but active keys remain exposed through Windows Machine DPAPI.
The ‘Ghost’ Database and Configuration Drift
In many enterprise environments, administrators disable the AutoCertificateRollover feature to maintain tighter control over the certificate lifecycle. When certificates are manually rotated, a discrepancy often arises between the Windows Internal Database (WID) and the actual certificate used by the ADFS service. This condition leads to a “ghost” entry in the database—a record that technically exists and can be decrypted but no longer represents the active signing material used for authentication.
According to the Mandiant analysis, extracting keys solely from the WID database and Distributed Key Management (DKM) material may yield expired or invalid certificates. These artifacts result in AADSTS500172 errors when presented to Entra ID. However, the active signing key continues to reside in the system’s machine-scoped cryptographic store, making the process of recovering active ADFS signing keys via Machine DPAPI a viable and stealthier path for attackers. This TTP allows for the recovery of the active key without interacting with LSASS memory or the live ADFS service process, which are frequently monitored by EDR solutions.
Technical Analysis: Machine RSA vs. User DPAPI
ADFS persists private keys in two distinct protection contexts. The first, User DPAPI, is tied to the service account’s SID and masterkey material. In many forensic scenarios, this material is not easily recoverable if the service account profile is not interactive. The second context, Machine RSA, utilizes Machine DPAPI. This model leverages the DPAPI_SYSTEM LSA secret and machine masterkeys available to SYSTEM-level contexts at S-1-5-18.
When ADFS performs a manual rotation, the RSA private key is stored in the machine-scoped CAPI key store at C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\. Because the key is protected by Machine DPAPI rather than a user-bound context, any process with SYSTEM privileges can resolve the protection chain. This design ensures service resilience across account changes and reboots but facilitates Privilege Escalation to a Global Administrator level if the host is compromised.
How to Detect ADFS Signing Key Recovery Attempts
Defenders must shift focus from application-layer stores to operating system-level cryptographic operations. To effectively monitor for this activity, organizations should implement System Access Control Lists (SACLs) on the following paths:
C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\C:\Windows\System32\Microsoft\Protect\S-1-5-18\
Successful monitoring of these paths will generate Security Event ID 4663. While this provides supporting evidence, it must be correlated with ADFS audit logs. Specifically, analysts should look for Event ID 299 or the 1200-series events to identify token issuance that does not correlate with a preceding primary authentication event. This is a critical step to detect ADFS signing key recovery in high-security environments where MITRE ATT&CK techniques like T1555 (Credentials from Password Stores) are utilized.
Mitigation and Tier 0 Hardening
To mitigate the risk of Golden SAML via DPAPI, ADFS infrastructure must be governed as Tier 0 assets, equivalent to Domain Controllers. The following steps are recommended:
- Hardware-Backed Protection: The most effective defense is migrating token-signing certificates to a Hardware Security Module (HSM). This ensures the private key never touches the host’s software-accessible storage.
- gMSA Implementation: Use Group Managed Service Accounts (gMSA) to automate credential management, reducing the likelihood of administrative errors during rotation.
- Strict Administrative Access: Limit access to ADFS servers to dedicated Privileged Access Workstations (PAWs) and enforce Zero Trust principles for all administrative sessions.
- Verification of Rotation: When performing manual rotations, use
Set-AdfsCertificateto ensure the WID database is updated. Validation viaGet-AdfsCertificateis essential to identify configuration drift before it becomes a security liability.