SAML-Floy through the eyes of an attacker
For the SAML pencilator, there is a trust chain between three participants: User's browser (User Agent), Service Provider (SP) and Identity Provider (IdP).
1. The user comes to SP, SP generates AuthnRequest and sends a redirect to IdP
2. IdP authenticates the user (login, password, MFA)
3. IdP forms SAMLResponse - XML-document with Assertion, signed by the IdP private key - and through the browser sends it back to the SP
4. SP validates the signature, extracts attributes from Assertion (NameID, roles, groups) and provides access
The critical point is step 4. The SP must ensure that the signature belongs to the trusted IdP, that it is the Assertion that is processed and that the data is not modified. According to OWASP A07:2021 - Identification and Authentication Failures, errors in the authentication are among the ten most critical risks of web applications. Attacks on SAML hit the gap between what the validator of the signature is checked and what business logic processes.
XML Signature Wrapping - Assertion Substitution for Valid Signature
Mechanics XSW-attacks
XML Signature Wrapping (XSW) is an attack class that exploits the difference between two phases of SAML processing: signature validation and data extraction. According to IBM, the attacker inserts fake elements into an XML document without breaking the validity of the digital signature. The validator checks one part of the document, the application processes another.
Technically, it works like this: the signed Assertion refers to the ID element through an attribute URI="#_id1234" in the Reference block. The attacker moves the signed Assertion to another part of the DOM tree, and puts a fake with an arbitrary NameID in its place. If SP is looking for Assertion according to XPath (e.g. //saml:Assertion) and takes the first one found - he will process a fake, although the validator of the signature correctly checked the original.
Predictions. Works if:
1. There is at least one legitimate SAMLResponse from IdP (interception through Burp or own accounting on SP).
2. SP uses vulnerable signature verification.
Does not work if:
1. SP tyms assertion to a specific session and strictly checks InResponseTo.
2. SP verifies that the machined element is the one that the Reference URI points to.
Applicability: external pentest (SP is available via the Internet, uses SAML SSO), internal pentest (access to the corporate SSO portal). Category MITRE ATT&CK: T1212 (Explotication for Credential Access) at initial access or T1550.001 (Application Access Token) at the lateral movement to other SP.
XSW Options and Practice with SAML Raider
According to HackTricks and Juraj Somorov’s “On Breaking SML,” eight XSW variants have been documented. In practice, three work more often than others:
View attachment 5515
On the pentest, I usually start with XSW #1 and #3 - they work on the largest number of implementations. If you do not roll, I go to #7 (Extensions), then to #4-#6.
Adjustments to the environment to work with SAML Raider:
• OS: any (Burp Suite cross-platform)
• Burp Suite Professional or Community Edition (retrieved 2024.x and 2025.x)
• SAML Raider - installation via BApp Store in Burp
• Browser tuned to proxy through Burp
• Intercepted SAMLResponse from target IdP (own accounting or interception)
Procedure: intercept the POST request from SAMLResponse to the ACS endpoint SP via Intercept, in SAML Raider Tab press "Parse SAML" - the extension decodes Base64 and show the XML structure. Select the XSW option from the list, specify the target NameID, click "Apply XSW" and forward request. The extension itself restructures the DOM tree, moving the signed Assertion and inserting a fake one.
Restrictions. SAML Raider covers standard XSW #1-#8. Advanced equipment - namespace confusion, Void Canonicalization (described in the PortSwigger study of December 2025) - require manual modification of XML. The researchers showed that instead of finding a signed SAML Assertion, it is possible to reuse any XML document signed with a private IdP key, and this is a completely different attack surface.
Parser differentials: why libraries break down again and again
PortSwigger’s research revealed the fundamental reason for the survivability of XSW-uldigense: many SAML libraries use two different XML parsers – one to validate the signature, the other to retrieve data. In Ruby-SAML, for example, one parser (REXML) extracts DigestValue and SignatureValue, and the other (Nokogiri, wrapper libxml2) performs canonicalization and hashing. Differences in framespace processing, comments and DTD between parsers create exploited discrepancies.
In Ruby-SAML, both parsers were looking for Signature by XPath //ds:Signature, returning the first entry. Additional logic on REXML checked that the parent element Signature is Assertion. But if the attacker placed a fake Assertion with a Signature nested so that both parsers "saw" different elements - the validation took place, and the application processed fake data. Two parsers in one application are like two locks on one door, each of which opens with its own key.
Golden SAML - forgery of tokens through IdP signature key
Operating Chain
If XSW cheats SP through the structure of XML, then Golden SAML is a complete compromising trust. The attacker, possessing the private key Token Signing Certificate from IdP, generates cryptographic valid SAML Assertion for any user, to any SP, with any attributes. In the terminology of MITRE ATT&CK - T1606.002 (Forge Web Credentials: SAML Tokens)
Microsoft characterizes Golden SAML as a rare but highly effective post-exploitation technique. Rareness is compensated by the scale: one stolen key compromises all the entity’s accounts. Organizations connect dozens of applications to one SSO, and one forged token potentially opens access to everyone.
Predictions. Works if:
1. The Domain Admin privileges or local administrators are obtained on the ADFS host.
2. Extracted Token Signing Certificate (closed key).
3. Specify identifiers of target SP (Issuer URI, Audience).
Does not work:
1. No pre-compromising on-prem of infrastructure. Golden SAML is not initial access, it is an extra movement after a deep penetration.
Kill chain:
1. Compromise of ADFS-server - compulsory escalation to Domain Admin or local administrator on ADFS-host (T1556.007, Modify Authentication Process: Hybrid Identity)
2. Extracting a private key from Windows Internal Database (WID) or SQL Server, where APDS stores the configuration (T1552.004, Unsecureed Credentials: Private Keys). Tool: ADFSDumpfor exporting configurations and keys
3. Generation of fake Assertion with arbitrary attributes - NameID, roles, bands. Tool: shimit(Python) to create SAML Response with the specified key and target SP parameters
4. Token delivery - substitute the generated SAMLResponse in POST request for ACS endpoint via browser
The SolarWinds (2020) attack showed Golden SAML in full growth: after compromising through supply chain, the attackers pulled SAML certificate signals from on-prem ADFS servers and forged tokens to access Microsoft 365, Azure AD and other cloud applications without a single access to the IdP.
Silver SAML - a lightweight option for Entra ID
Semperis has uncovered the Silver SAML technique, which works with Microsoft Entra ID (formerly Azure AD) without compromising ADFS. If an entity uses an externally import-induced signature sign in Entra ID (and not an Entra-signed certificate), an attacker with access to this certificate may generate fake SAML Response. Semperis has posted a PoC tool SilverSAMLForger. Microsoft qualified the problem as not meeting the criteria for an immediate solution, but recommended using only self-signed Entra ID certificates. A typical position is “not a bug, it’s a feature” (but the certificate is better to change).
CVE in SAML libraries: what is being used right now
Many SAML authentication trips do not hit the protocol architecture, but in the bugs of specific libraries. Three fresh CVE - all with CWE-347 (Impropper Verification of Cryptographic Signature) Show the scale of the problem.
CVE-2024-45409: Ruby-SAML - CVSS 10.0 (Critical)
Applicability: external pentest if the target SP runs on the Rails stand with ruby-saml (GitLab CE/EE, applications on OmniAut). Fingerprinting: Rails session in cookies, characteristic HTTP headlines. Corrected: versions of 1.17.0 and 1.12.3.
CVE-2025-47949: samlify - CVSS 9.9 (Critical)
Vulnerable version: samlafi < 2.10.0 (Node.js). Classic Signature Wrapping: An attacker, having any IdP XML document, counterfeits SAML Response and authenticated as an arbitrary user. Vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N Maximum availability. According to Obsidian Security, applications on vulnerable versions took unsigned or incorrectly signed Assertion as valid. Corrected: Version 2.10.0. Fingerprinting: Express session in cookies, Node.js-stack.
CVE-2025-23369: GitHub Enterprise Server - CVSS 7.6 (High)
Vulnerable versions: GHES < 3.12.14, < 3.13.10, < 3.14.7, < 3.15.2, < 3.16.0. Improper verification of cryptographic signature, allowing spoofing signatures for internal users. Operation requires: GHES uses SAML SSO, the attacker is already an existing user (PR:L). Vector: CVSS:4.0 with AC:H and ATP - high complexity, additional preconditions. Severity - High (7.6), not Critical. This is a privilege escalation for an authenticated user, not complete bypass. It was discovered through GitHub Bug Bounty. According to PortSwigger, the vulnerability is associated with the peculiarities of the namespaces processing in libxml2 - again parser differential between the validation components.
Historical Series: XML Comment Injection (2017-2018)
Early mass vector - insert XML-comments in NameID for pruning strings:
Vector Selection: Decision tree for attacks on SAML authentication
View attachment 5516
What the Defense Sees and Where Blind SIEM areas in SAML-attacks
XSW and CVE Exploitation
SP-side: if the SP logs to raw SAML Assertion (many SPs do not do this in the default configuration - write only NameID and the result), anomalies in the XML structure are theoretically detectable. In practice, with a successful XSW, the log looks like a legitimate input of the target user.
IdP-side: XSW does not affect IdP. In IdP magazines there will be legitimate authentication of the user-attack (from whose name the original SAMLResponse is received). The anomaly can be caught by correlation: one user is authenticated to IdP, and the entrance of another is fixed to the SP. But this requires the integration of the logs of both systems - and this is rare in practice.
Golden SAML
According to Microsoft, Golden SAML creates zero authentication events in IdP. IdP is not involved in the attack at all. Monitoring failed logins, impossible travel, MFA failure - useless. Standard SIEM correlations miss the attack completely.
Detection is possible through: post-authentication behavioral analysis (atypical SP, time, volumes); monitoring of changes of ADFS-configuration - Event ID 307 (Token Signing Certificate) in ADFS Audit Log; monitoring of changes PreferredTokenSigningKeyThumbprint In Entra Appability Management magazines; Microsoft Defender for Identity (contains Golden SAML).
The main blind spot: if the ADFS Audit Log is not integrated into SIEM (and this is a common situation - organizations do not touch the settings of ADFS for years), the disprocket of the signature key will remain invisible until behavioral analytics catches abnormal access patterns. Or maybe he won't.
Checklist for blue team
1. Integrate ADFS Audit Log into SIEM
2. Configure the Altrate to Event ID 307 (Change Signal Certificate) in ADFS
3. Monitor PreferredTokenSigningKeyThumbprintthe Entra ID Audit
4. Use only self-signed certificates Entra ID (Silver SAML mitigation)
5. Correlation SP and IdP: NameDID in SP must comply with the authenticated user in IdP
6. Update SAML-libraries: ruby-saml >=1.1.0, samlify >= 2.10.0, GHES to current versions
7. To check that SP binds the Reference URI to a specific processed element - not to the first Assertion found by XPath
I have been working with SAML infrastructures on pentests for several years and I see a stable pattern: SAML is broken not through cryptography, but through parsers. Each year there is a CVE with CVSS 9+ in the next library - and each time the root is one: two different parsers in one application, one for validating the signature, the other to extract data.
The problem is deeper than individual CVE. SAML 2.0 is the 2005 standard built on XML. The XML signature specification allows dozens of ways to place a signature on signed data: enveloped, enveloping, detached. Each library interprets permissible placements in its own way, each interpretation is a potential XSW vector. Researchers continue to find new classes of attacks on the canonicalization of XML, and the end is not visible.
Golden SAML is another story. Here the problem is not in the code, but in the architecture: organizations have been pulling ADFS for years as a bridge between on-prem AD and cloud, and this bridge becomes a single compromise point of the incident. Microsoft explicitly recommends the transition to purely cloud identification, but for many it is a project for years.
My prediction: in the coming year we will see a few more critical CVE in SAML libraries - the study of parser differentials is gaining momentum. For a penesster, this means one thing: fingerprinting SAML-stester SP is not an optional step, but the first. Know what kind of library, what version, what are the parsers under the hood - the difference between "decomes DA in an hour" and "spent a day on a blind brute force of XSW-variants."
For the SAML pencilator, there is a trust chain between three participants: User's browser (User Agent), Service Provider (SP) and Identity Provider (IdP).
1. The user comes to SP, SP generates AuthnRequest and sends a redirect to IdP
2. IdP authenticates the user (login, password, MFA)
3. IdP forms SAMLResponse - XML-document with Assertion, signed by the IdP private key - and through the browser sends it back to the SP
4. SP validates the signature, extracts attributes from Assertion (NameID, roles, groups) and provides access
The critical point is step 4. The SP must ensure that the signature belongs to the trusted IdP, that it is the Assertion that is processed and that the data is not modified. According to OWASP A07:2021 - Identification and Authentication Failures, errors in the authentication are among the ten most critical risks of web applications. Attacks on SAML hit the gap between what the validator of the signature is checked and what business logic processes.
XML Signature Wrapping - Assertion Substitution for Valid Signature
Mechanics XSW-attacks
XML Signature Wrapping (XSW) is an attack class that exploits the difference between two phases of SAML processing: signature validation and data extraction. According to IBM, the attacker inserts fake elements into an XML document without breaking the validity of the digital signature. The validator checks one part of the document, the application processes another.
Technically, it works like this: the signed Assertion refers to the ID element through an attribute URI="#_id1234" in the Reference block. The attacker moves the signed Assertion to another part of the DOM tree, and puts a fake with an arbitrary NameID in its place. If SP is looking for Assertion according to XPath (e.g. //saml:Assertion) and takes the first one found - he will process a fake, although the validator of the signature correctly checked the original.
Predictions. Works if:
1. There is at least one legitimate SAMLResponse from IdP (interception through Burp or own accounting on SP).
2. SP uses vulnerable signature verification.
Does not work if:
1. SP tyms assertion to a specific session and strictly checks InResponseTo.
2. SP verifies that the machined element is the one that the Reference URI points to.
Applicability: external pentest (SP is available via the Internet, uses SAML SSO), internal pentest (access to the corporate SSO portal). Category MITRE ATT&CK: T1212 (Explotication for Credential Access) at initial access or T1550.001 (Application Access Token) at the lateral movement to other SP.
XSW Options and Practice with SAML Raider
According to HackTricks and Juraj Somorov’s “On Breaking SML,” eight XSW variants have been documented. In practice, three work more often than others:
View attachment 5515
On the pentest, I usually start with XSW #1 and #3 - they work on the largest number of implementations. If you do not roll, I go to #7 (Extensions), then to #4-#6.
Adjustments to the environment to work with SAML Raider:
• OS: any (Burp Suite cross-platform)
• Burp Suite Professional or Community Edition (retrieved 2024.x and 2025.x)
• SAML Raider - installation via BApp Store in Burp
• Browser tuned to proxy through Burp
• Intercepted SAMLResponse from target IdP (own accounting or interception)
Procedure: intercept the POST request from SAMLResponse to the ACS endpoint SP via Intercept, in SAML Raider Tab press "Parse SAML" - the extension decodes Base64 and show the XML structure. Select the XSW option from the list, specify the target NameID, click "Apply XSW" and forward request. The extension itself restructures the DOM tree, moving the signed Assertion and inserting a fake one.
Restrictions. SAML Raider covers standard XSW #1-#8. Advanced equipment - namespace confusion, Void Canonicalization (described in the PortSwigger study of December 2025) - require manual modification of XML. The researchers showed that instead of finding a signed SAML Assertion, it is possible to reuse any XML document signed with a private IdP key, and this is a completely different attack surface.
Parser differentials: why libraries break down again and again
PortSwigger’s research revealed the fundamental reason for the survivability of XSW-uldigense: many SAML libraries use two different XML parsers – one to validate the signature, the other to retrieve data. In Ruby-SAML, for example, one parser (REXML) extracts DigestValue and SignatureValue, and the other (Nokogiri, wrapper libxml2) performs canonicalization and hashing. Differences in framespace processing, comments and DTD between parsers create exploited discrepancies.
In Ruby-SAML, both parsers were looking for Signature by XPath //ds:Signature, returning the first entry. Additional logic on REXML checked that the parent element Signature is Assertion. But if the attacker placed a fake Assertion with a Signature nested so that both parsers "saw" different elements - the validation took place, and the application processed fake data. Two parsers in one application are like two locks on one door, each of which opens with its own key.
Golden SAML - forgery of tokens through IdP signature key
Operating Chain
If XSW cheats SP through the structure of XML, then Golden SAML is a complete compromising trust. The attacker, possessing the private key Token Signing Certificate from IdP, generates cryptographic valid SAML Assertion for any user, to any SP, with any attributes. In the terminology of MITRE ATT&CK - T1606.002 (Forge Web Credentials: SAML Tokens)
Microsoft characterizes Golden SAML as a rare but highly effective post-exploitation technique. Rareness is compensated by the scale: one stolen key compromises all the entity’s accounts. Organizations connect dozens of applications to one SSO, and one forged token potentially opens access to everyone.
Predictions. Works if:
1. The Domain Admin privileges or local administrators are obtained on the ADFS host.
2. Extracted Token Signing Certificate (closed key).
3. Specify identifiers of target SP (Issuer URI, Audience).
Does not work:
1. No pre-compromising on-prem of infrastructure. Golden SAML is not initial access, it is an extra movement after a deep penetration.
Kill chain:
1. Compromise of ADFS-server - compulsory escalation to Domain Admin or local administrator on ADFS-host (T1556.007, Modify Authentication Process: Hybrid Identity)
2. Extracting a private key from Windows Internal Database (WID) or SQL Server, where APDS stores the configuration (T1552.004, Unsecureed Credentials: Private Keys). Tool: ADFSDumpfor exporting configurations and keys
3. Generation of fake Assertion with arbitrary attributes - NameID, roles, bands. Tool: shimit(Python) to create SAML Response with the specified key and target SP parameters
4. Token delivery - substitute the generated SAMLResponse in POST request for ACS endpoint via browser
The SolarWinds (2020) attack showed Golden SAML in full growth: after compromising through supply chain, the attackers pulled SAML certificate signals from on-prem ADFS servers and forged tokens to access Microsoft 365, Azure AD and other cloud applications without a single access to the IdP.
Silver SAML - a lightweight option for Entra ID
Semperis has uncovered the Silver SAML technique, which works with Microsoft Entra ID (formerly Azure AD) without compromising ADFS. If an entity uses an externally import-induced signature sign in Entra ID (and not an Entra-signed certificate), an attacker with access to this certificate may generate fake SAML Response. Semperis has posted a PoC tool SilverSAMLForger. Microsoft qualified the problem as not meeting the criteria for an immediate solution, but recommended using only self-signed Entra ID certificates. A typical position is “not a bug, it’s a feature” (but the certificate is better to change).
CVE in SAML libraries: what is being used right now
Many SAML authentication trips do not hit the protocol architecture, but in the bugs of specific libraries. Three fresh CVE - all with CWE-347 (Impropper Verification of Cryptographic Signature) Show the scale of the problem.
CVE-2024-45409: Ruby-SAML - CVSS 10.0 (Critical)
Applicability: external pentest if the target SP runs on the Rails stand with ruby-saml (GitLab CE/EE, applications on OmniAut). Fingerprinting: Rails session in cookies, characteristic HTTP headlines. Corrected: versions of 1.17.0 and 1.12.3.
CVE-2025-47949: samlify - CVSS 9.9 (Critical)
Vulnerable version: samlafi < 2.10.0 (Node.js). Classic Signature Wrapping: An attacker, having any IdP XML document, counterfeits SAML Response and authenticated as an arbitrary user. Vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N Maximum availability. According to Obsidian Security, applications on vulnerable versions took unsigned or incorrectly signed Assertion as valid. Corrected: Version 2.10.0. Fingerprinting: Express session in cookies, Node.js-stack.
CVE-2025-23369: GitHub Enterprise Server - CVSS 7.6 (High)
Vulnerable versions: GHES < 3.12.14, < 3.13.10, < 3.14.7, < 3.15.2, < 3.16.0. Improper verification of cryptographic signature, allowing spoofing signatures for internal users. Operation requires: GHES uses SAML SSO, the attacker is already an existing user (PR:L). Vector: CVSS:4.0 with AC:H and ATP - high complexity, additional preconditions. Severity - High (7.6), not Critical. This is a privilege escalation for an authenticated user, not complete bypass. It was discovered through GitHub Bug Bounty. According to PortSwigger, the vulnerability is associated with the peculiarities of the namespaces processing in libxml2 - again parser differential between the validation components.
Historical Series: XML Comment Injection (2017-2018)
Early mass vector - insert XML-comments in NameID for pruning strings:
XML-parser returned [email protected] Instead of a complete line [email protected]. Affected By: OneLogin PythonSAML (CVE-2017-11427), Ruby-SAML (CVE-2017-11428), Clever saml2-js (CVE-2017-11429), OmniAuth-SAML (CVE-2017-11430) - all CWE-287 (Improper Authentication); Shibboleth (CVE-2018-0489, CWE-347); Duo Network Gateway (CVE-2018-7340, CVSS 7.5 High, CWE-287/CWE-347). The current versions of libraries are patched, but on the legacy infrastructure, the vector is still alive.
Vector Selection: Decision tree for attacks on SAML authentication
View attachment 5516
What the Defense Sees and Where Blind SIEM areas in SAML-attacks
XSW and CVE Exploitation
SP-side: if the SP logs to raw SAML Assertion (many SPs do not do this in the default configuration - write only NameID and the result), anomalies in the XML structure are theoretically detectable. In practice, with a successful XSW, the log looks like a legitimate input of the target user.
IdP-side: XSW does not affect IdP. In IdP magazines there will be legitimate authentication of the user-attack (from whose name the original SAMLResponse is received). The anomaly can be caught by correlation: one user is authenticated to IdP, and the entrance of another is fixed to the SP. But this requires the integration of the logs of both systems - and this is rare in practice.
Golden SAML
According to Microsoft, Golden SAML creates zero authentication events in IdP. IdP is not involved in the attack at all. Monitoring failed logins, impossible travel, MFA failure - useless. Standard SIEM correlations miss the attack completely.
Detection is possible through: post-authentication behavioral analysis (atypical SP, time, volumes); monitoring of changes of ADFS-configuration - Event ID 307 (Token Signing Certificate) in ADFS Audit Log; monitoring of changes PreferredTokenSigningKeyThumbprint In Entra Appability Management magazines; Microsoft Defender for Identity (contains Golden SAML).
The main blind spot: if the ADFS Audit Log is not integrated into SIEM (and this is a common situation - organizations do not touch the settings of ADFS for years), the disprocket of the signature key will remain invisible until behavioral analytics catches abnormal access patterns. Or maybe he won't.
Checklist for blue team
1. Integrate ADFS Audit Log into SIEM
2. Configure the Altrate to Event ID 307 (Change Signal Certificate) in ADFS
3. Monitor PreferredTokenSigningKeyThumbprintthe Entra ID Audit
4. Use only self-signed certificates Entra ID (Silver SAML mitigation)
5. Correlation SP and IdP: NameDID in SP must comply with the authenticated user in IdP
6. Update SAML-libraries: ruby-saml >=1.1.0, samlify >= 2.10.0, GHES to current versions
7. To check that SP binds the Reference URI to a specific processed element - not to the first Assertion found by XPath
I have been working with SAML infrastructures on pentests for several years and I see a stable pattern: SAML is broken not through cryptography, but through parsers. Each year there is a CVE with CVSS 9+ in the next library - and each time the root is one: two different parsers in one application, one for validating the signature, the other to extract data.
The problem is deeper than individual CVE. SAML 2.0 is the 2005 standard built on XML. The XML signature specification allows dozens of ways to place a signature on signed data: enveloped, enveloping, detached. Each library interprets permissible placements in its own way, each interpretation is a potential XSW vector. Researchers continue to find new classes of attacks on the canonicalization of XML, and the end is not visible.
Golden SAML is another story. Here the problem is not in the code, but in the architecture: organizations have been pulling ADFS for years as a bridge between on-prem AD and cloud, and this bridge becomes a single compromise point of the incident. Microsoft explicitly recommends the transition to purely cloud identification, but for many it is a project for years.
My prediction: in the coming year we will see a few more critical CVE in SAML libraries - the study of parser differentials is gaining momentum. For a penesster, this means one thing: fingerprinting SAML-stester SP is not an optional step, but the first. Know what kind of library, what version, what are the parsers under the hood - the difference between "decomes DA in an hour" and "spent a day on a blind brute force of XSW-variants."
