Golden SAML Attacks: Why Your ADFS Is the Real Target

In post–SolarWinds analysis, Golden SAML stood out: adversaries who could forge SAML assertions could reach cloud apps as any user, often without repeating interactive sign-in—so MFA at the interactive login step does not save you if the identity provider signing key is gone.

If you still rely on Active Directory Federation Services (ADFS) for federation, this path belongs in both detection design and crisis exercises.

What is Golden SAML?

SAML is the XML-based protocol your IdP uses to assert identity to relying parties (e.g. Microsoft 365, SaaS). Users sign in; the IdP issues signed assertions downstream apps trust.

Golden SAML is industry shorthand for forged SAML assertions created with a stolen token-signing (or equivalent) private key—analogous in impact to a Kerberos Golden Ticket: the attacker does not guess passwords; they become the issuer of trust.

Naming varies by vendor stack; the risk pattern is the same: whoever holds the signing material controls trust.

Why This Matters More Than You Think

It bypasses MFA. The token is generated after authentication, so MFA never fires.

It's invisible to the target application. The forged token looks exactly like a legitimate one. Office 365 can't tell the difference between a real login and a Golden SAML attack.

It persists even after remediation. If you re-image compromised workstations but don't rotate the ADFS signing certificate, the attacker still has access. Many organizations missed this during SolarWinds remediation.

It gives access to everything. Any application that trusts your ADFS — email, cloud storage, SaaS apps, AWS/Azure console — is accessible with a forged token.

The Attack Path

Here's how it typically works:

1. Initial access — attacker compromises the network (phishing, supply chain, vulnerability exploitation)
2. Privilege escalation — attacker gains admin access to the domain
3. ADFS compromise — attacker accesses the ADFS server and extracts the token-signing certificate
4. Token forging — attacker generates SAML tokens for any user, accessing any federated service
5. Persistence — attacker maintains access even as other parts of the breach are remediated

The SolarWinds attackers followed this exact path. They used the compromised Orion update for initial access, escalated privileges, then targeted ADFS to forge tokens and access victims' cloud environments.

You can walk through a scenario based on this attack chain in our interactive SolarWinds demo — it covers the decision points a SOC team faces when detecting and responding to a supply chain compromise that leads to Golden SAML.

How to Detect It

This is the hard part. Golden SAML is designed to be stealthy.

Look for anomalies in SAML token usage:

• Tokens issued without corresponding authentication events in ADFS logs
• Users accessing services from unusual locations while ADFS shows them authenticating normally
• Token lifetimes or claims that don't match your configured policies

Monitor ADFS server integrity:

• Unexpected access to the ADFS configuration database
• Changes to token-signing certificates
• New DLLs loaded by the ADFS process

Use Azure AD (Entra ID) signals:

• Microsoft's "ADFS suspicious token" detection in Defender for Identity
• Sign-in logs showing token claims that don't match ADFS configuration

How to Defend Against It

Rotate your ADFS token-signing certificate regularly. This is the single most important control. If the certificate rotates, stolen copies become useless. Most organizations set this to auto-rotate and never check that it's actually happening.

Restrict access to the ADFS server aggressively. This server should be treated like a domain controller — tier 0 asset, minimal admin access, dedicated admin workstations, full audit logging.

Modernize identity architecture. Cloud-native authentication (e.g. Entra ID–centric patterns) changes attack surface and operational controls; migration is a program, not a checkbox—plan key custody, break-glass, and rollback.

Practice the scenario. Run a tabletop exercise where you detect a Golden SAML attack in progress. What do you do? How do you confirm it? How do you rotate the certificate without breaking all federated authentication?

Practice This Scenario

Golden SAML is exactly the kind of attack that tabletop exercises are made for. The detection is ambiguous, the response requires coordination between identity, security, and IT teams, and the business impact of getting it wrong (rotating ADFS certificates incorrectly) can be just as bad as the attack itself.

We built a supply chain compromise scenario that includes the Golden SAML phase. You can also build your own ADFS-focused scenario using our scenario builder, or browse our scenario library for related exercises.

For more context on supply chain attacks and other scenarios worth practicing, check out 10 scenarios every CISO should practice.

Related Reading

• Incident Response Tabletop Exercise: Complete Guide — how to structure the IR tabletop this attack slots into.
• Ransomware Tabletop Exercise Scenario: IR Walkthrough — the adjacent high-impact scenario most teams rehearse alongside Golden SAML.
• What Is a Tabletop Exercise? — quick refresher if this is your first scenario-based drill.

---

Summary: Protect token-signing material like tier-0 assets; rehearse certificate rotation and cross-team response before an adversary forces you to do it live. SolarWinds-style interactive flow · Library · Builder.