Mandiant Discovers "Ghost" ADFS Certificate Issue That Enables Stealthy Golden SAML Attacks

Mandiant Reveals a New Golden SAML Attack Technique Targeting ADFS

Cybersecurity researchers at Mandiant have disclosed a sophisticated identity attack technique that could affect organizations still relying on Microsoft Active Directory Federation Services (ADFS) for authentication.

The research shows how manually rotating ADFS token-signing certificates while disabling AutoCertificateRollover can unintentionally expose the active signing key through Windows Machine DPAPI. This creates a condition Mandiant calls the "Ghost Certificate," where outdated certificate records remain in the ADFS configuration database while the operating system continues using a different active signing key.

More importantly, the technique enables attackers with SYSTEM-level access to recover the real signing key without interacting with LSASS or the running ADFS service. This may reduce visibility for security products that primarily monitor credential dumping or process memory access.

Golden SAML Continues to Be a Critical Identity Threat

The Golden SAML attack, first introduced by CyberArk researchers in 2017 and later expanded upon by Mandiant in 2021, remains one of the most powerful techniques for compromising Microsoft identity environments.

Instead of stealing passwords, attackers obtain the private key used by ADFS to sign Security Assertion Markup Language (SAML) tokens. With this cryptographic key, they can create legitimate authentication assertions for any user, including highly privileged administrators.

Because the tokens are cryptographically valid, they can bypass:

• Multi-Factor Authentication (MFA)

• Conditional Access policies

• Password verification

• Identity-based security controls

Once accepted, attackers gain trusted access to Microsoft 365, Microsoft Entra ID, and any other application that relies on ADFS federation.

Researchers Discover the "Ghost Certificate"

During a recent red team engagement, Mandiant analysts followed the traditional Golden SAML extraction process.

The team successfully extracted an encrypted signing certificate from the Windows Internal Database (WID) and decrypted it using Distributed Key Manager (DKM) material stored in Active Directory.

However, Microsoft Entra ID rejected every forged authentication token with AADSTS500172, indicating invalid signing material.

Further investigation revealed the cause.

The organization had manually rotated its ADFS signing certificate after disabling AutoCertificateRollover. Although Windows and the ADFS service correctly began using the new certificate, the WID configuration database still referenced the expired certificate.

The result was a "Ghost Certificate." The database entry remained fully decryptable but was no longer responsible for signing authentication tokens.

This mismatch between configuration and runtime state created a hidden attack surface that traditional Golden SAML extraction methods failed to identify.

Why Traditional Database Extraction Misses the Active Key

Traditional Golden SAML techniques assume the ADFS configuration database always reflects the certificate currently used for token signing.

Mandiant found that this assumption fails when configuration drift occurs.

If administrators manually replace certificates without updating ADFS using Set-AdfsCertificate, the WID database continues referencing obsolete certificate metadata.

As a result, attackers extracting certificates only from the database recover a signing key that Microsoft Entra ID no longer trusts.

Meanwhile, the active signing certificate remains stored inside Windows Machine DPAPI.

Machine DPAPI Holds the Active Signing Key

The research explains that ADFS stores its active RSA private key inside the Windows MachineKeys directory instead of protecting it with a user-specific DPAPI profile.

The protection model relies on:

• Machine DPAPI

• DPAPI_SYSTEM LSA secrets

• Machine master keys

• SYSTEM-level security context

Unlike User DPAPI, this architecture allows the signing key to remain available regardless of:

• Service account password changes

• Group Managed Service Account (gMSA) rotations

• Server reboots

• Service restarts

While this design improves operational resilience, it also means a process running with SYSTEM privileges may recover the private key directly from the operating system without interacting with LSASS.

A Design Choice With Security Consequences

According to Mandiant, machine-scoped storage introduces an important operational security consideration that is often overlooked in ADFS hardening guidance.

Because the private signing key is protected using Machine DPAPI rather than a user-bound profile, attackers who gain SYSTEM-level access may recover the key by accessing:

• DPAPI_SYSTEM secrets

• Machine master keys

• Machine-scoped cryptographic storage

This recovery process occurs independently of the original service account logon session.

As a result, organizations that rely mainly on LSASS monitoring or credential dumping detections may have limited visibility into this attack path.

From Machine DPAPI to Global Administrator Access

After recovering the active signing key from the Machine DPAPI store, Mandiant demonstrated the full attack scenario.

Researchers generated a forged SAML assertion that impersonated a Global Administrator account.

Microsoft Entra ID accepted the authentication request because it was signed with the organization's legitimate token-signing key.

The result was authenticated access to the federated Microsoft 365 tenant with Global Administrator privileges without requiring passwords or multi-factor authentication.

The demonstration confirms that once attackers recover the active signing certificate, they can impersonate virtually any user trusted by the federation.

Detection and Hunting Recommendations

Because the attack avoids many traditional credential theft techniques, defenders should monitor cryptographic operations alongside identity activity.

Monitor Machine DPAPI Storage

Configure Security Access Control Lists (SACLs) on:

C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys

C:\Windows\System32\Microsoft\Protect\S-1-5-18

Proper auditing generates Security Event ID 4663, providing visibility into unauthorized file access.

Monitor ADFS Token Issuance

Organizations should establish normal authentication baselines and investigate token issuance events that cannot be correlated with previous authentication activity.

Relevant ADFS events include:

• Event ID 299

• 1200-series audit logs

Correlate Microsoft Entra ID Sign-ins

Forged SAML assertions appear as legitimate federated logins inside Microsoft Entra ID.

Effective detection requires correlating:

• Entra ID sign-in logs

• ADFS token issuance logs

Security teams should prioritize anomalies involving:

• Privileged accounts

• Unexpected IP addresses

• Unusual user agents

• Abnormal claim sets

How Organizations Can Defend Against the Threat

Mandiant recommends treating every ADFS server as Tier 0 identity infrastructure, with the same level of protection as Domain Controllers.

The researchers recommend several defensive measures.

Deploy Hardware Security Modules (HSMs)

Moving token-signing certificates into an HSM prevents software-based extraction of private keys from Windows systems, eliminating the Machine DPAPI attack path.

Validate Certificate Rotations

Organizations that disable AutoCertificateRollover should ensure manual rotations include updating ADFS using Set-AdfsCertificate.

Administrators should verify consistency between:

• ADFS configuration

• LocalMachine\My certificate store

• Federation metadata

If Event ID 385 appears after certificate changes, it should be investigated as a possible sign of configuration drift.

Strengthen Tier 0 Administration

Protect ADFS servers using:

• Privileged Access Workstations (PAWs)

• Restricted administrative access

• Tier 0 segmentation

• Enhanced privileged monitoring

Use Group Managed Service Accounts

Running ADFS under gMSAs automates credential rotation and reduces operational errors that contribute to configuration inconsistencies.

Modernize Identity Federation

Organizations migrating from ADFS to native OpenID Connect (OIDC) federation eliminate this specific Machine DPAPI attack vector.

Why This Research Matters

Mandiant's findings demonstrate that identity security extends beyond passwords and authentication policies. Cryptographic key management, certificate lifecycle processes, and operating system storage mechanisms are equally important for protecting enterprise identity infrastructure.

The research also highlights how configuration drift during manual certificate management can create a hidden attack path capable of bypassing MFA, Conditional Access, and other identity protections. For organizations that continue to rely on ADFS, regular certificate validation, stronger Tier 0 protections, and monitoring of Windows cryptographic operations should become essential parts of their security strategy.