Mandiant "Ghost in the Database": recovering an active ADFS token-signing key from Machine DPAPI when the WID/DKM Golden SAML path fails
Background. Golden SAML — forging SAML assertions by stealing an identity provider's token-signing key — has been public tradecraft since CyberArk's 2017 disclosure (CyberArk, 2017), and Mandiant previously documented network-based extraction of ADFS secrets during the UNC2452/SolarWinds intrusions (Mandiant). The standard extraction path pulls the encrypted signing key from the ADFS Windows Internal Database (WID) and decrypts it with Distributed Key Manager (DKM) material stored in Active Directory. This new Mandiant write-up documents a variant that defeats that assumption when ADFS configuration has drifted.
During a red-team engagement, Mandiant found that ADFS deployments with AutoCertificateRollover disabled (Get-AdfsProperties → AutoCertificateRollover: False) and certificates rotated manually can leave the WID configuration database holding only a stale "ghost" certificate record, while the ADFS service actually signs tokens with a newer certificate whose private key lives in the machine CAPI store (Mandiant, 2026-07-07). In that state the classic path still "works" mechanically — the WID blob decrypts via DKM — but Entra ID rejects the resulting token with AADSTS500172 because the key is no longer the one in use.
The key's real location and protection. The active private key sits under C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\, with the certificate enrolled in the LocalMachine\My store. It is protected by Machine DPAPI (not user-bound DPAPI): the DPAPI_SYSTEM LSA secret plus machine masterkeys under the S-1-5-18 (SYSTEM) context at C:\Windows\System32\Microsoft\Protect\S-1-5-18\. Machine-scoping is deliberate — it keeps the key usable across service-account password changes, gMSA rotations and reboots — but it also means a SYSTEM-level actor can recover the key entirely from the host. Mandiant confirmed recovery with SharpDPAPI /machine, which enumerated the active key material under that path (the CNG Crypto\Keys store was not in use in the assessed environment) — no interaction with the live ADFS process or LSASS is required, reducing visibility for defenses that watch only credential-dumping/process-memory access (Mandiant, 2026-07-07).
Kill chain (ATT&CK). SYSTEM-level foothold on the ADFS host → recover Machine-DPAPI-protected masterkeys and the CAPI signing key (T1552 Unsecured Credentials, via SharpDPAPI /machine) → forge a SAML assertion impersonating a Global Administrator (T1606.002 Forge Web Credentials: SAML Tokens) → Entra ID accepts it as a valid federated authentication assertion, yielding Global Administrator access to the Microsoft 365 tenant with MFA and conditional access fully bypassed (T1078.004 Valid Accounts: Cloud Accounts). Because the forged assertion is honoured for all SAML relying-party trusts, the blast radius extends to every SaaS platform federated through the same ADFS, not just Microsoft services.
Hunt and detection. The drift condition itself is observable: ADFS Event ID 385 fires when the WID record and the actively-used signing certificate diverge, and self-resolves only once AutoCertificateRollover is re-enabled and a rollover runs. For key-theft detection, Mandiant recommends SACL-based object-access auditing (Security Event ID 4663) on C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\ and C:\Windows\System32\Microsoft\Protect\S-1-5-18\, treated as correlation evidence rather than a standalone signal. The strongest analytic is cross-source: correlate ADFS token-issuance/claims events (Event IDs 299 and the 1200-series, version-dependent) against Entra ID sign-in logs to surface federated sign-ins with no matching upstream authentication context, baselining claim sets, IP ranges and user-agents per relying-party trust for privileged accounts — neither log source alone is sufficient (Mandiant, 2026-07-07).
Hardening. Migrate token-signing certificates to an HSM to eliminate the software-accessible key and thus the Machine DPAPI extraction path entirely; run ADFS under gMSA to reduce manual-rotation drift; govern ADFS servers as Tier 0 (restricted admin paths, dedicated PAWs, separation from general server administration). When AutoCertificateRollover is disabled, a manual rotation must include Set-AdfsCertificate — installing the certificate alone is insufficient — and be validated with Get-AdfsCertificate; a subsequent Event ID 385 signals lingering inconsistency. Organisations migrating to native OIDC federation remove this attack path altogether (Mandiant, 2026-07-07). ADFS remains widely deployed for on-prem/hybrid identity across Swiss and EU public-sector estates mid-migration to Entra ID, making this a direct Tier 0 hardening item for the constituency.
Successfully obtaining this active key allows an attacker to forge valid SAML assertions for any user, bypassing the need for user credentials and multi-factor authentication
The recovered key was used to forge a SAML assertion impersonating a Global Administrator identity, which Entra ID accepted as a valid authentication assertion
Configure object access auditing via SACLs on C:\\ProgramData\\Microsoft\\Crypto\\RSA\\MachineKeys\\ and C:\\Windows\\System32\\Microsoft\\Protect\\S-1-5-18\\. When configured correctly, this generates Security Event ID 4663 for file access attempts.
Defender actions
- Inventory ADFS: run Get-AdfsProperties for AutoCertificateRollover:False and Get-AdfsCertificate to confirm the WID record matches the active token-signing certificate; any Event ID 385 is a drift indicator to investigate.
- Migrate ADFS token-signing certificates to an HSM (removes the Machine DPAPI extraction path entirely), run ADFS under gMSA, and govern ADFS hosts as Tier 0 with PAWs; when rotating manually, always run Set-AdfsCertificate, not certificate install alone.
- Deploy SACLs (Event ID 4663) on C:\\ProgramData\\Microsoft\\Crypto\\RSA\\MachineKeys\\ and C:\\Windows\\System32\\Microsoft\\Protect\\S-1-5-18\\, and correlate Entra ID federated sign-ins against ADFS issuance events (299 / 1200-series) to find tokens with no matching upstream authentication.
ATT&CK mapping
3 techniques mapped from the cited reporting · MITRE ATT&CK v19.2
Initial Access TA0001
T1078.004Valid Accounts: Cloud Accounts
Valid accounts in cloud environments may allow adversaries to perform actions to achieve Initial Access, Persistence, Privilege Escalation, or Defense Evasion. Cloud accounts are those created and configured by an organization for use by users, remote support, services, or for administration of resources within a cloud service provider or SaaS application. Cloud Accounts can exist solely in the cloud; alternatively, they may be hybrid-joined between on-premises systems and the cloud through syncing or federation with other identity sources such as Windows Active Directory.
Persistence TA0003
T1078.004Valid Accounts: Cloud Accounts
Valid accounts in cloud environments may allow adversaries to perform actions to achieve Initial Access, Persistence, Privilege Escalation, or Defense Evasion. Cloud accounts are those created and configured by an organization for use by users, remote support, services, or for administration of resources within a cloud service provider or SaaS application. Cloud Accounts can exist solely in the cloud; alternatively, they may be hybrid-joined between on-premises systems and the cloud through syncing or federation with other identity sources such as Windows Active Directory.
Privilege Escalation TA0004
T1078.004Valid Accounts: Cloud Accounts
Valid accounts in cloud environments may allow adversaries to perform actions to achieve Initial Access, Persistence, Privilege Escalation, or Defense Evasion. Cloud accounts are those created and configured by an organization for use by users, remote support, services, or for administration of resources within a cloud service provider or SaaS application. Cloud Accounts can exist solely in the cloud; alternatively, they may be hybrid-joined between on-premises systems and the cloud through syncing or federation with other identity sources such as Windows Active Directory.
Stealth TA0005
T1078.004Valid Accounts: Cloud Accounts
Valid accounts in cloud environments may allow adversaries to perform actions to achieve Initial Access, Persistence, Privilege Escalation, or Defense Evasion. Cloud accounts are those created and configured by an organization for use by users, remote support, services, or for administration of resources within a cloud service provider or SaaS application. Cloud Accounts can exist solely in the cloud; alternatively, they may be hybrid-joined between on-premises systems and the cloud through syncing or federation with other identity sources such as Windows Active Directory.
Credential Access TA0006
T1552Unsecured Credentials
Adversaries may search compromised systems to find and obtain insecurely stored credentials. These credentials can be stored and/or misplaced in many locations on a system, including plaintext files (e.g. Shell History), operating system or application-specific repositories (e.g. Credentials in Registry), or other specialized files/artifacts (e.g. Private Keys).
T1606.002Forge Web Credentials: SAML Tokens
An adversary may forge SAML tokens with any permissions claims and lifetimes if they possess a valid SAML token-signing certificate. The default lifetime of a SAML token is one hour, but the validity period can be specified in the <code>NotOnOrAfter</code> value of the <code>conditions ...</code> element in a token. This value can be changed using the <code>AccessTokenLifetime</code> in a <code>LifetimeTokenPolicy</code>. Forged SAML tokens enable adversaries to authenticate across services that use SAML 2.0 as an SSO (single sign-on) mechanism.
AI-generated · no human review · this permalink is the shareable record for the finding · verify operationally critical claims against the linked primary source.