The ‘Ghost’ in the Database: Recovering Active ADFS Signing Keys via Machine DPAPI

What Happened

Security researchers found a new way that attackers can steal the digital keys used by Microsoft's ADFS identity system to forge login tokens. When organizations manually rotate their security certificates instead of using automatic rotation, the system's database can become out of sync with the actual active certificate, leaving the real signing key stored in a less-monitored part of the Windows operating system. An attacker who already has deep access to an ADFS server can extract this key without touching the parts of the system that security tools typically watch most closely. With the stolen key, the attacker can create fake login tokens that impersonate any user, including top-level administrators, and gain access to email, cloud services, and other connected applications. Organizations should treat ADFS servers as critically sensitive infrastructure, enable automatic certificate rotation where possible, and consider moving signing keys to hardware security modules that prevent software-based extraction.

Key Takeaways

• When ADFS AutoCertificateRollover is disabled and certificates are manually rotated, the WID database retains stale 'ghost' certificate entries while the active signing key migrates to Machine DPAPI-protected storage, creating a configuration drift condition.
• The active ADFS token-signing private key can be recovered from the machine-scoped CAPI key store at C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\ using the DPAPI_SYSTEM LSA secret and machine masterkeys, without touching LSASS memory or the live ADFS service process.
• This technique significantly reduces detection visibility for organizations focused on LSASS access monitoring and ADFS process-level telemetry, as it operates entirely through OS cryptographic subsystem APIs.
• The recovered key was successfully used to forge a SAML assertion impersonating a Global Administrator, which Entra ID accepted as valid authentication.
• ADFS Event ID 385 is the observable symptom of this drift condition and should be treated as a high-priority investigative signal in environments with manual certificate rotation.

Affected Systems

• Microsoft ADFS servers with AutoCertificateRollover disabled
• Microsoft Entra ID (Azure AD) federated tenants using ADFS
• SAML-federated SaaS applications relying on ADFS identity assertions
• Windows Server environments hosting ADFS with manually rotated token-signing certificates

Vulnerabilities (CVEs)

None identified.

Attack Chain

1. Initial Access: Attacker obtains SYSTEM-level access on an ADFS server (Tier 0 identity infrastructure)
2. Discovery: Attacker confirms AutoCertificateRollover is disabled via Get-AdfsProperties, indicating manual certificate rotation and potential configuration drift
3. Credential Access: Attacker retrieves the DPAPI_SYSTEM LSA secret using LsaRetrievePrivateData API call
4. Credential Access: Attacker accesses machine masterkeys at C:\Windows\System32\Microsoft\Protect\S-1-5-18\ to decrypt machine-scoped DPAPI-protected material
5. Credential Access: Attacker uses SharpDPAPI /machine to recover the active ADFS token-signing private key from C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\ without touching LSASS or the ADFS service process
6. Defense Evasion: Attacker forges a SAML assertion impersonating a Global Administrator using the recovered key, which Entra ID accepts as valid federated authentication

Detection Availability

• YARA Rules: No
• Sigma Rules: No
• Snort/Suricata Rules: No
• KQL Queries: No
• Splunk SPL Queries: No
• EQL Queries: No
• Other Detection Logic: No

The article does not provide specific detection rule content but describes detection strategies including SACL-based object access auditing on MachineKeys and DPAPI paths (Event ID 4663), ADFS Event ID 385 for certificate drift, and cross-correlation of ADFS token issuance logs (Event IDs 299, 1200-series) with Entra ID sign-in logs.

Detection Engineering Assessment

Required Log Sources

• Windows Security Event Log (Event ID 4663 - object access with SACL configured on MachineKeys and DPAPI paths)
• ADFS Admin Event Log (Event ID 385 - certificate validity warnings)
• ADFS Audit Log (Event IDs 299, 1200-series - token issuance and claims processing)
• Entra ID Sign-in Logs (federated sign-in events)
• LSA secret access telemetry (if available via EDR or advanced auditing)

Hunting Hypotheses

Control Gaps

• EDR solutions focused on LSASS memory access detection will not catch this technique, which operates through legitimate OS cryptographic subsystem APIs.
• Standard ADFS configuration monitoring that only checks the WID database will miss the active signing key stored in Machine DPAPI.
• Entra ID sign-in logs alone cannot distinguish forged SAML assertions from legitimate federated authentication without ADFS-side correlation.
• Default Windows auditing does not include SACLs on MachineKeys or DPAPI masterkey paths, leaving file access to these critical locations unlogged.
• Organizations that do not treat ADFS servers as Tier 0 infrastructure may lack the enhanced monitoring and access controls needed to detect this attack.

Key Behavioral Indicators

• Process accessing C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\ that is not the ADFS service or Windows cryptographic services
• Process accessing C:\Windows\System32\Microsoft\Protect\S-1-5-18\ outside of normal DPAPI operations
• LsaRetrievePrivateData API call targeting DPAPI_SYSTEM secret
• SharpDPAPI.exe or similar DPAPI tool execution with /machine argument on ADFS servers
• ADFS Event ID 385 in environments with AutoCertificateRollover disabled
• Federated sign-in events in Entra ID for Global Administrator accounts from unexpected IP ranges or with inconsistent user-agent strings
• Token issuance events in ADFS audit logs (Event IDs 299, 1200-series) without corresponding primary authentication events

False Positive Assessment

Recommendations

Immediate Mitigation

Infrastructure Hardening

• Evaluate migrating ADFS token-signing certificates to a Hardware Security Module (HSM) to eliminate the Machine DPAPI extraction path entirely, as HSM-backed keys do not exist in software-accessible storage.
• Consider enabling AutoCertificateRollover in ADFS to prevent the configuration drift condition that creates the ghost certificate scenario.
• If manual certificate rotation is required, ensure the process includes updating ADFS via Set-AdfsCertificate and validating consistency across all configuration sources.
• Consider treating ADFS servers as Tier 0 identity infrastructure equivalent to Domain Controllers, with restricted administrative access, dedicated Privileged Access Workstations (PAWs), and enhanced monitoring.
• Evaluate migrating away from ADFS-based federation to native OIDC federation where feasible, which removes this specific attack path.
• Consider running ADFS services using Group Managed Service Accounts (gMSA) to reduce manual credential management as a contributing factor to configuration drift.

User Protection

• Consider configuring SACL-based object access auditing on C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\ and C:\Windows\System32\Microsoft\Protect\S-1-5-18\ to generate Event ID 4663 for unauthorized file access.
• If your SIEM supports cross-platform correlation, consider building detection rules that correlate Entra ID federated sign-in events with ADFS-side token issuance logs, particularly for privileged accounts.
• Consider baselining normal authentication patterns per relying party trust in ADFS to enable detection of anomalous token issuance events.

Security Awareness

• Consider incorporating ADFS certificate lifecycle management into existing security operations training, emphasizing that manual rotation without database updates creates exploitable drift conditions.
• If applicable, consider educating identity administrators on the risk that a compromised ADFS signing key affects all SAML relying party trusts, not just Microsoft 365 services.
• Consider documenting the Event ID 385 drift indicator in existing operational runbooks so administrators recognize it as a security-relevant signal rather than a benign warning.

MITRE ATT&CK Mapping

Additional IOCs

• File Paths:
  • C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\ - Machine-scoped CAPI key store where ADFS persists RSA private key material for token-signing, protected by Machine DPAPI. Targeted by attacker for active signing key extraction.
  • C:\Windows\System32\Microsoft\Protect\S-1-5-18\ - Machine masterkey storage for the SYSTEM (S-1-5-18) security context. Contains DPAPI-protected key material required to decrypt machine-scoped cryptographic secrets.
• Command Lines:
  • Purpose: Enumerate and decrypt machine DPAPI secrets including ADFS token-signing private keys | Tools: SharpDPAPI | Stage: Credential Access | SharpDPAPI /machine
  • Purpose: Check ADFS certificate rollover configuration status to identify drift condition | Tools: PowerShell, ADFS module | Stage: Discovery | Get-AdfsProperties
  • Purpose: Update ADFS configuration with new certificate after manual rotation to prevent WID database drift | Tools: PowerShell, ADFS module | Stage: Remediation | Set-AdfsCertificate
  • Purpose: Retrieve DPAPI_SYSTEM LSA secret for machine masterkey decryption | Tools: LSA API | Stage: Credential Access | LsaRetrievePrivateData
• Other:
  • DPAPI_SYSTEM - LSA secret name containing machine DPAPI masterkey material. Retrieved by attacker to decrypt machine-scoped cryptographic stores and recover ADFS signing key.