SAML Assertion Forgery Exploit: How It Works and How to Prevent It

Post Views: 8

SAML assertion forgery exploits compromised identity provider signing keys to bypass authentication and access sensitive systems.

Attack surfaces and threat vectors

SAML assertion forgery exploits two main vulnerabilities: compromised IdP signing infrastructure and XML signature validation flaws in service providers. Golden SAML attacks specifically target the IdP’s SAML signing certificate and private key. In Active Directory Federation Services (ADFS) environments, the token signing key is encrypted in the ADFS configuration database. The key used to decrypt it—the Distributed Key Manager (DKM) key—is stored in Active Directory. An attacker with domain administrator privileges can remotely retrieve both components to reconstruct the signing key without interacting with the ADFS server directly. Cloud-based identity providers like Microsoft Entra ID and Okta do not store signing keys on domain controllers, making this extraction method unique to ADFS. ADFS must be treated as critical infrastructure equivalent to domain controllers since its compromise affects all trusting applications. Organizations should consider migrating to cloud-based authentication to reduce this risk.

Golden SAML attacks

With the signing key, attackers generate cryptographically valid SAML assertions for any identity. Most service providers require the subject identifier to match an existing account, so attackers typically impersonate administrators rather than creating new users. The forged assertions pass validation because they use the legitimate signing key. Hardware security modules (HSMs) complicate key extraction, but XML Signature Wrapping (XSW) attacks exploit service provider validation logic. Attackers manipulate the XML structure of a legitimate assertion—such as one issued to their own account—to make signature validation pass against the original signed element while the application processes a different, attacker-controlled element containing elevated privileges or a different identity. Service providers that do not check element positioning accept these manipulated assertions.

Real-world XSW vulnerabilities

In 2024, CVE-2024-45409 was disclosed in the ruby-saml library, followed by two related issues (CVE-2025-25291 and CVE-2025-25292) in early 2025. A 2018 comment-injection vulnerability affected multiple SAML libraries. These are not theoretical flaws.

Assertion replay and injection

Assertion replay and injection bypass standard SAML flows by submitting previously issued or forged assertions directly to service provider endpoints. Without a signing key, this works only if the service provider lacks proper signature validation, in which case audience and timing restrictions offer minimal protection. With a signing key, attackers can initiate a legitimate SP-initiated login flow and forge a matching response, making the attack indistinguishable from normal authentication. The primary defense is requiring SP-initiated flows with InResponseTo validation, which ensures assertions correspond to active authentication requests. Note that many SAML service providers are SaaS applications where customers cannot modify XML parser configurations or assertion logging behavior. Technical controls discussed here apply to applications built or operated directly by the organization. For third-party SaaS, practical measures include vendor evaluation and keeping SAML libraries updated.

Business impact

SAML assertion forgery enables complete authentication bypass across integrated applications, exposing sensitive data and critical systems to unauthorized access. Attackers gain legitimate user sessions without triggering IdP authentication logs, complicating detection through standard monitoring. The most documented example is UNC2452 (the SolarWinds campaign), where attackers forged SAML tokens after compromising ADFS infrastructure to move laterally into cloud environments. Semperis documented a related technique in 2024—Silver SAML—targeting Entra ID environments. In both cases, attackers used initial access to establish persistence through new application credentials and federation trust changes. Data exposure occurs immediately when forged assertions grant access to applications containing customer records, financial data, or intellectual property. The scope depends on the privileges encoded in the forged assertion and the identity being impersonated. Compliance risks arise when unauthorized access touches regulated data systems, potentially leading to audit findings under SOX, HIPAA, or PCI DSS requirements. The duration and extent of unauthorized access influence how regulators and auditors assess the incident. Operational disruption follows when incident response teams must invalidate all active SAML sessions to contain the breach. Recovery involves rotating signing certificates and reconfiguring trust relationships across multiple service providers, a significant operational burden requiring advance planning.

Detection guidance

SAML assertion forgery produces limited direct signals, as attacks are designed to mimic legitimate authentication. Detection relies on correlating data from multiple sources. ADFS success auditing is not enabled by default at the required level, so organizations must enable it and ensure it is configured for effective monitoring. Primary detection control: Correlate service provider authentication events with IdP assertion issuance. For example, detect SP authentications without corresponding IdP assertion issuance by joining on assertion IDs. Supplementary: Monitor for anomalies in assertion timing. Attackers set timestamps themselves, so this detects errors rather than deliberate attacks. Flag assertions where NotBefore is more than five minutes before the received timestamp or where the validity window exceeds one hour. Note that certificate validation failures do not indicate XSW or Golden SAML attacks, as these methods use legitimate certificates. Certificate errors suggest misconfigurations or attackers using incorrect keys and should not be relied upon as indicators.

Mitigation strategies

Protect ADFS as tier 0 infrastructure. Domain administrator access allows remote extraction of ADFS signing keys, so apply the same access controls, monitoring, and privileged access workstation requirements to ADFS servers as to domain controllers. Consider migrating to cloud-based authentication (Entra ID with native federation) to eliminate the ADFS key extraction path. Implement strict XML signature validation for service providers under direct control. Ensure signed elements are not repositioned within the XML structure, as the element processed for authentication decisions must match the one covered by the signature. Use HSMs to store ADFS signing keys, as this raises the bar for key extraction. Require SP-initiated flows with InResponseTo validation, configuring service providers to reject assertions without corresponding authentication requests. This blocks replay and injection of stolen assertions but does not prevent Golden SAML attacks. Apply assertion timing constraints, rejecting assertions where the received time falls outside the NotBefore/NotOnOrAfter window or where the validity window exceeds one hour. Use a consistent maximum NotBefore offset of five minutes. Timing constraints limit replay windows but are not primary controls for Golden SAML. Enable ADFS audit logging and forward events to a SIEM. Log all token issuance events. Rotate certificates after confirmed compromise, replacing the compromised key and then rotating again to invalidate trust relationships. A 90-day rotation cycle has operational value but is insufficient if the attacker retains IdP access, creating significant burdens for SaaS relying parties.

Incident response considerations

A confirmed SAML forgery incident requires more than certificate rotation. Rotate the ADFS token signing certificate twice before restoring normal operations. Revoke active sessions and refresh tokens at affected service providers, as certificate rotation alone does not invalidate sessions established with the old key. Audit all service providers for follow-on persistence mechanisms, such as new OAuth application credentials, added federation trust relationships, or new privileged accounts created during the access window. Review ADFS and AD audit logs for DKM container access prior to detection to establish the compromise window.

Getting started checklist

Immediate actions (complete within 24 hours)

Verify ADFS success auditing is enabled and configured.
Enable alerts for Active Directory reads of the DKM container.
Confirm Microsoft Defender for Identity (or equivalent) is deployed and generating alerts for credential access on ADFS and AD.
Verify service providers reject assertions signed by certificates not in the configured trust store.

Short-term hardening (complete within one week)

Audit SP-initiated flow configurations to ensure InResponseTo validation and reject unsolicited (IdP-initiated) assertions.
Implement assertion timing validation to reject NotBefore offsets exceeding five minutes or validity windows longer than one hour.
Audit ADFS signing key storage, evaluating HSM use and documenting signing processes.
Verify SAML library versions in applications, checking for CVE-2024-45409, CVE-2025-25291, and CVE-2025-25292.
Establish correlation monitoring between ADFS and service provider logs.

Ongoing protection (implement within 30 days)

Apply tier 0 access controls and privileged access workstation requirements to all ADFS servers.
Evaluate migration from ADFS to cloud-native authentication as a long-term risk reduction measure.
Establish and document certificate rotation procedures, including the two-rotation post-compromise requirement.
Develop and test an incident response runbook for SAML forgery, including session revocation, two-pass certificate rotation, and persistence hunting.
Contact SaaS vendors for key applications to confirm SAML library currency and assertion validation practices.