データベースの「幽霊」：Machine DPAPIによるADFSアクティブ署名キーの復元手法 The ‘Ghost’ in the Database: Recovering Active ADFS Signing Keys via Machine DPAPI

Active Directory Federation Services (ADFS) remains a cornerstone of enterprise single sign-on, so any weakness in how it protects its signing material carries outsized consequences. New threat intelligence research demonstrates that an ADFS server's active token-signing key can be recovered directly from its configuration database using the Windows Machine Data Protection API (DPAPI), giving an attacker who reaches the right host the ability to forge SAML tokens and impersonate any federated user.

The significance lies in what the token-signing key unlocks. ADFS issues SAML assertions that downstream services, including cloud platforms such as Microsoft 365, trust to authenticate users. Because those assertions are validated against the signing certificate rather than re-checked against a live directory, whoever controls the private key can mint tokens for arbitrary identities, populate arbitrary claims, and effectively bypass multi-factor authentication enforced at the identity provider. This class of attack is widely known as "Golden SAML," first documented by CyberArk researchers in 2017 and later observed in the 2020 SolarWinds intrusion, where actors abused forged tokens to move into cloud environments.

Historically, extracting that key was thought to require the Distributed Key Manager (DKM) master key, a secret stored in a protected Active Directory container and used to decrypt the signing material at runtime. Tooling such as ADFSDump and ADFSpoof was built around that workflow. The research reframes the problem: the signing key persists inside the ADFS configuration database, hosted in the Windows Internal Database or a dedicated SQL Server instance, and appears to be recoverable through Machine DPAPI on the ADFS server itself. The "ghost in the database" framing captures the idea that the live key sits as a decryptable artifact within storage that defenders may not treat as sensitive.

Machine DPAPI is the system-scoped variant of Windows' data protection service. Where user DPAPI ties encrypted secrets to a user's logon credentials, the machine variant binds material to the local computer, meaning code running with sufficient privilege on the box can request decryption without a specific user's password. In practice, that means an actor operating as SYSTEM or local administrator on an ADFS server, or able to execute within the ADFS service context, may be positioned to unwrap the signing key using the machine's own protection scope.

It is worth stressing the prerequisites. This is a post-compromise escalation technique rather than a remote, unauthenticated exploit. The attacker must already have privileged access to the ADFS host, so the finding is most relevant to lateral movement and persistence scenarios in which an intruder has established a foothold in the identity infrastructure. That framing reinforces long-standing guidance that ADFS servers should be treated as Tier 0 assets, on par with domain controllers, and isolated accordingly.

The technique also illustrates why federated identity systems are attractive targets. Compromising a single signing key is more durable than stealing individual credentials, because token forgery survives password resets and can persist until the certificate is rotated. Defenders can reduce exposure by tightly restricting who can log on to ADFS servers, monitoring for anomalous access to the configuration database and the DKM container, enforcing automatic certificate rollover, and rotating signing certificates twice to fully invalidate a suspected-stolen key. Detection products such as Microsoft Defender for Identity and SIEM rules that flag unusual token issuance patterns can help surface abuse after the fact.

The broader context is Microsoft's ongoing push to migrate customers away from on-premises ADFS toward cloud-based authentication in Entra ID, formerly Azure AD, using managed methods such as password hash synchronization or pass-through authentication. Cloud-hosted identity does not eliminate token-forgery risk, but it shifts key custody to the provider and narrows the on-premises attack surface that techniques like this one depend on. For organizations that must retain ADFS, the research is a reminder that protecting the signing key requires securing not only the DKM secret in Active Directory but also the configuration database and the DPAPI scope that guards it.

As with any offensive research, the practical impact will depend on how readily the method generalizes across ADFS versions and configurations, which further testing and vendor response are likely to clarify.