When identity provider (IdP) infrastructure is breached, exposed SAML signing keys compromise every federated application relying on that trust relationship. Threat actors with access to these private keys can forge valid assertions for arbitrary users—commonly targeting administrative accounts to skirt multifactor authentication across all connected services. Because this results in a full authentication bypass without generating standard IdP authentication logs, detecting the intrusion is exceptionally difficult until the unauthorized access causes noticeable disruption.DKM and signing key access is the highest-confidence pre-compromise signal in ADFS environments. Monitor Active Directory for reads of the DKM container (Event 4662 with appropriate object GUID filtering). Also monitor for ADFS configuration database access and signing certificate export operations. Microsoft Defender for Identity generates alerts for these behaviors and is the most practical way to catch this access in real time.InResponseTo and unsolicited assertion anomalies can surface injection attempts. If your SP logs include InResponseTo values, correlate them against authentication requests you issued. Assertions lacking an InResponseTo that aren't part of an expected IdP-initiated flow are worth investigating.Timing anomalies provide a weak supplementary signal—attackers set assertion timestamps themselves, so this catches errors rather than deliberate attacks. If you monitor timing, use consistent thresholds: flag assertions where NotBefore is more than 5 minutes before the received timestamp, or where the validity window exceeds 1 hour.Note on certificate validation failures: XSW attacks succeed precisely because signature validation passes against the original signed element—they do not produce certificate errors. Golden SAML uses the legitimate certificate and also produces no validation failure. Certificate validation failures indicate a different problem (misconfiguration or an attacker using the wrong key) and should not be relied upon as an XSW or Golden SAML indicator.
- [ ] Verify that ADFS success auditing is enabled and events (including Event 1200) are forwarded to your SIEM
- [ ] Enable alerts for AD Event 4662 on the DKM container and for ADFS signing certificate export operations
- [ ] Confirm Microsoft Defender for Identity (or equivalent) is deployed and generating alerts for credential access on ADFS and AD
- [ ] Verify that service providers reject assertions signed by certificates not in the configured trust storeShort-term hardening (complete within 1 week):
- [ ] Audit all SP-initiated flow configurations—ensure InResponseTo is validated and unsolicited (IdP-initiated) assertions are rejected where not required by business process
- [ ] Implement assertion timing validation: reject assertions with NotBefore offsets greater than 5 minutes or validity windows longer than 1 hour
- [ ] Audit ADFS signing key storage—evaluate HSM if currently stored in software, and document the operational model for how signing occurs
- [ ] Verify SAML library versions in applications you build or operate; check for CVE-2024-45409, CVE-2025-25291, and CVE-2025-25292
- [ ] Establish correlation monitoring between ADFS Event 1200 issuance logs and SP authentication success events, joining on assertion IDOngoing 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 and a tested process for updating relying party trust stores
- [ ] Develop and test an incident response runbook for SAML forgery that includes session revocation at SPs, two-pass certificate rotation, and follow-on persistence hunting
- [ ] Contact SaaS vendors for key applications to confirm their SAML library currency and assertion validation practices
Attack surfaces and threat vectors
SAML assertion forgery exploits two primary attack surfaces: compromised IdP signing infrastructure and XML signature validation weaknesses in service providers.Golden SAML attacks target the IdP's SAML signing certificate and private key. In Active Directory Federation Services (ADFS) environments specifically, the token signing key is stored 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 access can retrieve both remotely and reconstruct the signing key without touching the ADFS server directly. Cloud identity providers such as Microsoft Entra ID and Okta do not store signing keys on domain controllers, so this extraction path is specific to ADFS. ADFS should be treated as tier 0 infrastructure—equivalent to domain controllers—because compromising it is equivalent to compromising every application that trusts it. Where feasible, organizations should evaluate migrating from ADFS to cloud-based authentication to reduce this attack surface. With the signing key in hand, attackers generate cryptographically valid SAML assertions for any identity. In practice, most service providers require the subject identifier to match a real account, so attackers typically impersonate existing administrators rather than inventing users. The forged assertions pass signature validation because they use the legitimate signing key.Hardware security modules raise the bar for key extraction—an HSM prevents the private key material from being exported—but an attacker who has already compromised the IdP server can still instruct the HSM to sign arbitrary assertions on their behalf. HSMs are a meaningful control, not a complete one.XML Signature Wrapping (XSW) attacks exploit how service providers validate SAML assertion signatures. Rather than stealing a signing key, these attacks exploit parser logic: the attacker typically starts with a legitimately signed assertion—such as one issued to their own account—and manipulates the XML structure so that signature validation passes against the original signed element while the application processes a different, attacker-controlled element containing elevated privileges or a different identity. Service providers that validate signatures without checking element positioning accept these manipulated assertions.Real-world XSW vulnerabilities remain active. In 2024, CVE-2024-45409 was disclosed in the ruby-saml library; two related issues (CVE-2025-25291 and CVE-2025-25292) followed in early 2025. A 2018 comment-injection vulnerability affected multiple SAML libraries. These are not theoretical weaknesses.Assertion replay and injection bypasses normal SAML flows by submitting previously issued or forged assertions directly to service provider endpoints. Without a signing key, this succeeds only when the SP has broken or absent signature validation—in which case audience and timing restrictions provide little real protection. When a signing key is available, the attacker can initiate a legitimate SP-initiated login flow and forge a matching response, making this indistinguishable from normal authentication. The primary defense is requiring SP-initiated flows with InResponseTo validation, which prevents replayed or injected assertions that don't correspond to an active authentication request.Note: A meaningful portion of SAML service providers are SaaS applications where customers cannot modify XML parser configuration or assertion logging behavior. SP-side technical controls in this article apply to applications you build or operate directly. For third-party SaaS, the practical controls are vendor vetting and keeping SAML libraries patched.Business impact
SAML assertion forgery creates complete authentication bypass across integrated applications, exposing sensitive data and critical systems to unauthorized access. Attackers gain legitimate user sessions without triggering authentication logs at the identity provider, making detection difficult through normal monitoring.The most significant documented example is UNC2452 (the SolarWinds campaign), in which 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 followed initial access with additional persistence mechanisms including 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 implications arise when unauthorized access touches regulated data systems. Organizations may face audit findings when SAML forgery enables access to systems covered by SOX, HIPAA, or PCI DSS requirements. The scope and duration of unauthorized access are material to 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 extends when organizations must rotate signing certificates and reconfigure trust relationships across multiple service providers—a significant operational burden that should be planned for in advance.Detection guidance
SAML assertion forgery produces limited direct signals—most attacks are designed to look like legitimate authentication. Detection relies on correlating events across the IdP and service providers, and on monitoring for the infrastructure access that precedes key extraction.Important prerequisite: ADFS success auditing is not enabled by default at the level needed for effective detection. Enable ADFS auditing at the "Success audits" level and ensure events are forwarded to your SIEM. Event 1200 (token issuance) and event 1202 are the relevant ADFS signals.Primary detection control: Correlate service provider authentication events against IdP assertion issuance events—ideally joining on assertion ID where both sides log it. Users with an existing SSO session can receive assertions without generating a new login event, so joining on authentication events alone produces false negatives. The goal is identifying SP sessions that have no corresponding ADFS issuance event (Event 1200).// Logic pattern / pseudocode — validate for your platform
// Detect SP authentications without corresponding IdP assertion issuance events
// Prefer joining on assertion ID where both sides log it
SELECT sp_auth.user_id, sp_auth.assertion_id, sp_auth.timestamp, sp_auth.source_ip
FROM service_provider_auth_events sp_auth
LEFT JOIN idp_assertion_issuance_events idp_issuance
ON sp_auth.assertion_id = idp_issuance.assertion_id
WHERE idp_issuance.assertion_id IS NULL
AND sp_auth.auth_method = 'SAML'
AND sp_auth.timestamp > (current_time - interval '1 hour')
// Logic pattern / pseudocode — validate for your platform
// Supplementary: detect assertions with anomalous timing
SELECT assertion_id, user_id, not_before, not_on_or_after, received_timestamp
FROM saml_assertion_logs
WHERE (not_before < (received_timestamp - interval '5 minutes'))
OR ((not_on_or_after - not_before) > interval '1 hour')
OR (received_timestamp > not_on_or_after)
Mitigation strategies
Protect ADFS as tier 0 infrastructure. Domain administrator access is sufficient to extract ADFS signing keys remotely. Apply the same access controls, monitoring, and privileged access workstation requirements to ADFS servers as to domain controllers. Where feasible, evaluate migrating to cloud-based authentication (Entra ID with Entra-native federation) to eliminate the ADFS key extraction path entirely.Implement strict XML signature validation at service providers you control. Validate that signed elements haven't been repositioned within the XML structure—the element being processed for authentication decisions must be the element the signature covers. This prevents XSW attacks. For SaaS applications, verify with vendors that their SAML libraries are current and unaffected by known CVEs, including CVE-2024-45409 and CVE-2025-25291/25292.Use HSM storage for ADFS signing keys. An HSM prevents the private key from being exported, raising the bar for key theft. Recognize the limitation: an attacker with control of the IdP server can still use the HSM to sign assertions. HSMs reduce one extraction path; they don't eliminate Golden SAML risk.Require SP-initiated flows with InResponseTo validation. Configure service providers to reject SAML assertions that don't correspond to an outstanding authentication request. This blocks replay and injection of stolen assertions but does not prevent Golden SAML—an attacker with the signing key can initiate a legitimate SP flow and forge the response. The terms here matter: "unsolicited assertions" are IdP-initiated flows, and blocking them means requiring SP-initiated authentication with InResponseTo checking, not the reverse.Apply assertion timing constraints. Configure service providers to reject assertions where the received time falls outside the NotBefore/NotOnOrAfter window, and reject assertions with validity windows longer than 1 hour. Use a consistent maximum age of 5 minutes for the NotBefore offset. Timing constraints limit replay windows for stolen assertions but are not a primary Golden SAML control.Enable ADFS audit logging and forward to SIEM. Log all token issuance events (Event 1200) with user identity, target relying party, assertion ID, and timestamp. This is the authoritative record needed to detect orphaned SP sessions.Certificate rotation after confirmed compromise. After a key compromise, rotate the ADFS token signing certificate twice—once to replace the compromised key, and again to invalidate any trust relationships that may have been established against the first replacement. A routine 90-day rotation cycle has operational value but is insufficient if the attacker retains access to the IdP; distributing certificate updates to many SaaS relying parties on a 90-day cycle creates significant operational burden that should be planned before the policy is enforced.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 each affected service provider—certificate rotation alone does not invalidate sessions established with the old key
- Audit all service providers for follow-on persistence: new OAuth application credentials, added federation trust relationships, or new privileged accounts created during the access window (this was a hallmark of the SolarWinds campaign)
- Review ADFS and AD audit logs for DKM container access prior to the detection date to establish the compromise window
Getting started checklist
Immediate actions (complete within 24 hours):- [ ] Verify that ADFS success auditing is enabled and events (including Event 1200) are forwarded to your SIEM
- [ ] Enable alerts for AD Event 4662 on the DKM container and for ADFS signing certificate export operations
- [ ] Confirm Microsoft Defender for Identity (or equivalent) is deployed and generating alerts for credential access on ADFS and AD
- [ ] Verify that service providers reject assertions signed by certificates not in the configured trust storeShort-term hardening (complete within 1 week):
- [ ] Audit all SP-initiated flow configurations—ensure InResponseTo is validated and unsolicited (IdP-initiated) assertions are rejected where not required by business process
- [ ] Implement assertion timing validation: reject assertions with NotBefore offsets greater than 5 minutes or validity windows longer than 1 hour
- [ ] Audit ADFS signing key storage—evaluate HSM if currently stored in software, and document the operational model for how signing occurs
- [ ] Verify SAML library versions in applications you build or operate; check for CVE-2024-45409, CVE-2025-25291, and CVE-2025-25292
- [ ] Establish correlation monitoring between ADFS Event 1200 issuance logs and SP authentication success events, joining on assertion IDOngoing 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 and a tested process for updating relying party trust stores
- [ ] Develop and test an incident response runbook for SAML forgery that includes session revocation at SPs, two-pass certificate rotation, and follow-on persistence hunting
- [ ] Contact SaaS vendors for key applications to confirm their SAML library currency and assertion validation practices
Sources
- MITRE ATT&CK T1606.002 – Forge Web Credentials: SAML Tokens
- MITRE ATT&CK T1552.004 – Unsecured Credentials: Private Keys
- OWASP SAML Security Cheat Sheet
- NIST IR 8587 (ipd)
- NIST SP 800-63B
- CVE-2024-45409 – ruby-saml signature validation bypass
- CVE-2025-25291 / CVE-2025-25292 – ruby-saml
- Semperis – Silver SAML (2024)
- Microsoft – Detecting and Mitigating ADFS Key Compromise