Golden SAML: How Attackers Forge ADFS Tokens and How to Detect and Harden Against It
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
ADFS is the federation bridge between on-premises Active Directory and cloud services like Microsoft 365. It issues SAML 2.0 tokens signed with a private key that service providers (Microsoft 365, Azure, third-party SaaS) trust completely. Whoever holds that signing private key can impersonate any user to any federated service -- permanently, silently, and without generating on-premises authentication events. This is why ADFS servers are Tier 0 infrastructure and why the SolarWinds attackers specifically targeted the ADFS token signing key during their campaign.
How the Attack Works
Step 1 (Initial access to ADFS server): the attacker must gain administrator access to an ADFS server -- typically via domain admin compromise, supply chain attack, or direct exploitation of the ADFS server. The SolarWinds attackers achieved this by deploying a backdoor via the SUNBURST-compromised Orion update, which provided access to systems including ADFS servers. Step 2 (Extract the token signing certificate): the ADFS token signing certificate's private key is stored in the ADFS configuration database (WID or SQL Server). With local admin or SYSTEM access to the ADFS server, extract using: the ADFSDump tool (a public tool for extracting ADFS secrets), or direct DKM (Distributed Key Manager) key extraction via the AD service account. The DKM key is stored in an AD container (typically CN=ADFS,CN=Microsoft,CN=Program Data,DC=domain,DC=com) and is accessible to the ADFS service account with AD access. Step 3 (Forge SAML assertions): using the extracted certificate, the attacker crafts a SAML Response XML document for any target user (e.g., GlobalAdmin@domain.com), signs it with the extracted private key, and presents it to the cloud service. The cloud service validates the signature against the trusted certificate thumbprint and issues a cloud-side session token. The attacker now has a valid Microsoft 365 or Azure session as the target user.
Protect the ADFS Token Signing Certificate
The token signing certificate is the highest-value credential on the ADFS farm. Protect it with hardware: configure ADFS to use a Hardware Security Module (HSM) for token signing key storage. With HSM-backed keys, the private key material cannot be exported from the HSM even by an attacker with admin access to the ADFS server. Verify current key storage: Get-AdfsSslCertificate and Get-AdfsCertificate -CertificateType Token-Signing -- check the StoreLocation and the StoreName. If the certificate is in the 'CurrentUser' or 'LocalMachine' Windows certificate store, the private key is exportable from the server. Configure DKM hardening: the AD container holding the DKM master key should have its ACL tightened to ADFS service account read access only -- remove any overly broad permissions. Audit the container: Get-ADObject -Filter {objectclass -eq 'container'} -SearchBase 'CN=Program Data,DC=domain,DC=com' and check the ACL with Get-Acl 'AD:\CN=ADFS,CN=Microsoft,...'. Certificate rotation: rotate the token signing certificate at least annually. Short-lived certificates limit the window during which a stolen certificate remains useful -- after rotation, the old certificate is no longer trusted by service providers.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Detect Golden SAML Usage
Golden SAML sign-ins are detectable in cloud-side logs. On-premises Windows events do not fire because the authentication happens in the ADFS server's token issuance path (ADFS audit events) and in the cloud service logs. ADFS audit events: enable verbose ADFS auditing. On the ADFS server: auditpol /set /subcategory:'Application Generated' /success:enable /failure:enable. ADFS writes audit events to the Security log (Event ID 4624 from ADFS when it issues a token). More specifically, ADFS generates Event ID 500 (token issued) and Event ID 1200 (token validation) in the ADFS Admin event log (Applications and Services Logs > AD FS > Admin). Alert on ADFS token issuance for high-privilege accounts (Global Admin, Exchange Admin) from unexpected IP addresses. In Microsoft 365 / Entra ID: Unified Audit Log sign-in events from federated users show the authentication method. A sign-in via SAML assertion that does not correspond to a normal ADFS server IP address is suspicious. Microsoft Sentinel: SecurityEvent and OfficeActivity and AADSignInEventsBeta all contain ADFS-related sign-in records -- correlate across all three. Defender for Identity has built-in Golden SAML detection (Forged SAML token used to access Active Directory resources alert).
Incident Response: ADFS Token Signing Certificate Compromise
If you suspect the ADFS token signing certificate has been extracted: Step 1 -- rotate the token signing certificate immediately. In the ADFS management console, Certificates > Token-signing > Add new certificate > Set as primary. This revokes trust for tokens signed with the old certificate. All active cloud sessions signed with the old certificate will be invalidated on the next token refresh. Step 2 -- revoke all active sessions for all users in the tenant. In Entra ID, use the Revoke All Tokens PowerShell command: Get-AzureADUser | Revoke-AzureADUserAllRefreshToken (or the Microsoft Graph equivalent). Step 3 -- update the federated domain's certificate metadata in Entra ID: Update-MsolFederatedDomain -DomainName yourdomain.com -SupportMultipleDomain. This forces Entra ID to fetch the new certificate from ADFS federation metadata. Step 4 -- audit all sign-in events from the suspected compromise window using the Unified Audit Log and Entra sign-in logs for any suspicious activity from Global Admin or other privileged accounts.
Long-Term: Migrate from ADFS to Entra ID Cloud Authentication
The most effective long-term mitigation for Golden SAML is eliminating ADFS entirely by migrating to Entra ID cloud authentication (password hash synchronization or pass-through authentication). With PHS or PTA, there is no ADFS server and no token signing certificate to steal. Entra ID issues tokens directly, signed with Microsoft-managed keys that are not accessible to any customer or attacker in the customer's environment. Microsoft completed this migration internally after the SolarWinds attack and recommends all customers do the same. Migration steps: in Entra Connect, enable Password Hash Synchronization as a backup authentication method alongside ADFS. Test seamless SSO with PHS for a pilot group. Convert the federated domain to managed authentication: Set-MsolDomainAuthentication -DomainName domain.com -Authentication Managed. After conversion, ADFS is no longer in the authentication path. Decommission the ADFS servers -- removing the infrastructure removes the attack surface entirely.
The bottom line
Golden SAML turns ADFS server compromise into permanent, stealthy impersonation of any user to any federated cloud service. The primary defense is treating ADFS servers as Tier 0 infrastructure with the same protections as domain controllers, storing token signing keys in an HSM, and enabling detailed ADFS and cloud-side audit logging. The strategic defense is migrating from ADFS to Entra ID cloud authentication, which eliminates the attack surface entirely.
Frequently asked questions
Does Golden SAML work against Okta or other identity providers?
Yes. Any SAML 2.0 identity provider that signs tokens with a private key is conceptually vulnerable to Golden SAML if the private key can be extracted. The specific extraction technique differs per IdP. Okta stores signing keys differently than ADFS. However, the principle is the same: extract the private key, forge SAML assertions. IdPs that store signing keys in cloud-managed HSMs (including modern Entra ID and Okta's cloud service) are harder to attack because the keys are not accessible to the attacker even with admin access to the management plane.
Is Golden SAML the same as a Pass-the-Cookie attack?
No. Pass-the-Cookie steals an existing browser session cookie to replay an authenticated session -- it requires the user to have an active session whose cookie can be extracted. Golden SAML forges a new SAML assertion from scratch using the signing key -- no existing session required, any user can be impersonated, and the attacker can generate new tokens indefinitely until the signing certificate is rotated. Pass-the-Cookie is constrained by session lifetime; Golden SAML is constrained only by certificate validity (typically 1-2 years).
Does enabling MFA prevent Golden SAML?
No. The forged SAML assertion can include any attributes, including MFA claims. The attacker can embed 'amr': ['mfa'] in the SAML assertion to satisfy MFA requirements at the cloud service. This is one of the reasons ADFS compromise is so severe -- normal Conditional Access MFA requirements can be bypassed by a forged token that claims MFA was completed. Phishing-resistant MFA (FIDO2, Windows Hello for Business, certificate-based auth) that uses hardware-bound attestation cannot be forged in a SAML assertion, but this protection only applies if the service provider verifies the authentication method claim against a cryptographic proof, not just the assertion attribute.
How do I check if my organization uses ADFS or cloud-only authentication?
In Entra Connect admin center or via PowerShell: Get-MsolDomain | Where-Object {$_.Authentication -eq 'Federated'} returns all federated domains (using ADFS or another IdP). Get-MsolDomain | Where-Object {$_.Authentication -eq 'Managed'} returns domains using Entra ID cloud authentication (PHS or PTA). If all domains are Managed, you do not have ADFS in your authentication path and Golden SAML does not apply. If any domain is Federated, identify the federation provider (Get-MsolFederationProperty -DomainName domain.com) to determine if ADFS is involved.
How do I detect that a Golden SAML attack has occurred?
Detection is difficult because forged SAML tokens are structurally valid -- they pass all signature verification. However, behavioral indicators exist: look for Entra ID sign-in log entries where the authentication method shows SAML from your ADFS provider for accounts that normally use PTA or PHS (inconsistent with their expected auth path), sign-ins for highly privileged accounts (Global Admins) occurring at unusual times or from unusual IPs, ADFS server audit logs showing token issuances to new relying parties or for accounts that have not signed in recently, and Windows Event ID 1202 or 1200 on ADFS servers showing federation service token issues. ADFS server audit logging (configured via Set-ADFSProperties -AuditLevel Verbose and enabling ADFS-specific event forwarding) is a prerequisite for any post-incident forensics.
What is the migration path from ADFS to Entra ID native authentication to eliminate Golden SAML as an attack surface?
Migrating from ADFS to Entra ID native authentication (Password Hash Sync or Pass-Through Authentication) eliminates the ADFS token signing certificate as an attack vector entirely, since authentication no longer routes through on-premises ADFS. The migration process: first inventory all relying party trusts in ADFS (Get-AdfsRelyingPartyTrust) to identify all applications that authenticate via ADFS. For Microsoft 365 and Azure applications, migration to Entra ID direct federation is straightforward using the ADFS migration report in Entra ID (Entra admin center > Identity > Hybrid management > ADFS migration). Third-party SAML applications need to be reconfigured to use Entra ID as the identity provider instead of ADFS. Run both ADFS and Entra ID in parallel during migration (hybrid mode) to avoid disruption. Microsoft's AD FS to Microsoft Entra migration guide covers the step-by-step process. After migration, decommission ADFS servers to remove the attack surface entirely -- maintaining ADFS for a subset of applications indefinitely preserves the Golden SAML risk for the accounts that use those applications.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.