SAML Hacking: Bypassing Enterprise Single Sign-On Protocols for Unauthorized Access

Before diving into exploitation techniques, it is essential to understand the architectural flow and the underlying components of a SAML transaction.

The Key Players in SAML

A standard SAML authentication flow involves three primary entities:

1. The Principal (The User): The human (or sometimes machine) attempting to access a resource.
2. The Identity Provider (IdP): The centralized system that manages user identities and performs the actual authentication (e.g., Okta, Microsoft Entra ID, Ping Identity, Active Directory Federation Services).
3. The Service Provider (SP): The application the user wants to access (e.g., Salesforce, Slack, AWS Console). The SP delegates the authentication process to the IdP.

The SAML Authentication Flow

The most common implementation is the SP-Initiated Flow, which generally proceeds as follows:

1. Access Request: The user navigates to the Service Provider (e.g., https://crm.example.com).
2. SAML Request (AuthnRequest): The SP recognizes that the user is not authenticated. It generates an XML document called an AuthnRequest and redirects the user's browser to the Identity Provider, passing the request along.
3. Authentication: The IdP receives the request, challenges the user to authenticate (e.g., via username/password and MFA), and verifies their identity.
4. SAML Response (The Assertion): Once authenticated, the IdP generates a SAML Response. This is a complex XML document containing one or more "Assertions." These assertions make statements about the user—their username, email, department, role, and the fact that they successfully authenticated at a specific time. Crucially, the IdP mathematically signs this XML document using its private cryptographic key.
5. Assertion Consumption: The IdP redirects the user's browser back to the Service Provider's Assertion Consumer Service (ACS) URL, carrying the signed SAML Response (usually encoded in Base64 via an HTTP POST parameter).
6. Validation and Access: The SP receives the SAML Response. It uses the IdP's previously shared public key to cryptographically verify the signature, ensuring the assertion was genuinely issued by the trusted IdP and hasn't been tampered with. If valid, the SP extracts the user's identity from the assertion, establishes a local session, and grants access.

SAML hacking rarely involves exploiting the underlying cryptography (unless the keys are exceptionally weak). Instead, vulnerabilities almost exclusively stem from how the Service Provider parses, validates, and processes the complex XML assertions. XML processing is notoriously difficult to secure, leading to several devastating attack vectors.

1. XML Signature Wrapping (XSW)

XML Signature Wrapping is arguably the most famous and complex class of SAML vulnerabilities. It exploits the disconnect between the XML element that the SP verifies cryptographically and the XML element it actually uses to log the user in.

A standard SAML Response contains a <Signature> element that signs a specific part of the document, usually the <Assertion> element (which contains the user's identity, like <NameID>[email protected]</NameID>).

In an XSW attack, the attacker (who has legitimate access to a low-privileged account, e.g., [email protected]) intercepts their own valid, signed SAML Response. The attacker then manipulates the XML structure. They keep the original, valid <Signature> and the original, valid <Assertion> (which the signature points to). However, they inject a second, malicious <Assertion> into a different part of the XML document, changing the identity to a target user (e.g., <NameID>[email protected]</NameID>).

If the Service Provider's SAML library is poorly implemented, it might verify the signature against the original (attacker's) assertion, confirming the math checks out. But when the application logic proceeds to extract the username to log the user in, it might traverse the XML tree incorrectly and extract the <NameID> from the newly injected, unverified, malicious assertion. The attacker successfully logs in as the administrator. There are up to eight known structural variations of XSW attacks, targeting different flaws in XML parsing logic.

2. Golden SAML (Forging the Signature)

Golden SAML is an attack technique popularized during the massive SolarWinds supply chain compromise. It is not an exploit of a parser vulnerability; rather, it represents the ultimate catastrophic failure of the SAML trust model: the compromise of the IdP's private signing key.

If an advanced threat actor compromises the on-premises Identity Provider (such as extracting the token-signing private key from an Active Directory Federation Services (ADFS) server), they essentially hold the master key to the enterprise. With this private key, the attacker can act as the Identity Provider.

They can forge perfectly valid, mathematically correct SAML Responses for any user, granting themselves administrative access to any federated Service Provider (like Microsoft 365 or AWS) connected to that IdP. Because the forged tokens are signed with the legitimate, trusted private key, the Service Providers accept them unconditionally. This attack bypasses MFA, password resets, and traditional conditional access policies, as the authentication process happens entirely offline in the attacker's environment before the forged token is presented to the SP.

3. XML External Entity (XXE) Injection

Because SAML relies entirely on XML, Service Providers must employ an XML parser to read the incoming responses. If the SP's XML parser is not configured securely, it may be vulnerable to XML External Entity (XXE) injection.

The SAML specification allows for the inclusion of Document Type Definitions (DTDs), which can define custom entities. In an XXE attack, the attacker modifies the intercepted SAML Response to include a malicious DTD that defines an external entity pointing to a local file on the SP's server (e.g., <!ENTITY xxe SYSTEM "file:///etc/passwd">).

When the vulnerable SP parses the SAML Response, it resolves the external entity, reading the contents of the /etc/passwd file and potentially embedding it within the XML document or returning it in an error message. Advanced XXE can also lead to Server-Side Request Forgery (SSRF), allowing the attacker to scan internal networks or interact with internal APIs from the perspective of the SP server.

4. Signature Stripping and Downgrade Attacks

Some poorly implemented Service Providers rely on the presence of the <Signature> element to trigger the validation logic. If an attacker intercepts their own valid SAML Response and simply deletes the entire <Signature> block, a vulnerable SP might process the assertion without performing any cryptographic validation whatsoever.

In this scenario, the attacker can simply strip the signature, alter the <NameID> to the administrator's email, and submit the modified response. The SP, seeing no signature, assumes it doesn't need to validate it, and trusts the contents blindly.

Similarly, if the IdP and SP support multiple signature algorithms, an attacker might attempt a downgrade attack, altering the XML to specify a weaker, breakable hashing algorithm (like MD5) or even a "none" algorithm, hoping the SP's validation library will accept the downgraded, easily spoofed signature.

5. Comment Injection (The XML Comment Bug)

A seemingly innocuous feature of XML—the ability to add comments <!-- like this -->—can lead to severe authentication bypasses, as demonstrated by a famous vulnerability discovered in several enterprise SAML libraries (like python3-saml).

Consider an SP that uses an email address as the primary identifier. If the SP's backend system validates a user's domain (e.g., only allowing @example.com users) but uses a flawed string manipulation function before validating the XML, an attack is possible.

An attacker registers an account with a malicious domain they control, designed to look like the target domain with a comment inserted: [email protected].<!-- -->attacker.com. When the Identity Provider signs the assertion, it signs this literal string. However, when the Service Provider's XML parser reads the document, it might interpret the comment as part of the XML structure rather than the text value, effectively stripping it out during normalization.

The resulting string evaluated by the SP becomes [email protected] which might bypass poor regex checks, or conversely, if the truncation happens differently, it might resolve to just [email protected], allowing the attacker to log in as the administrator using an account they fully control on the IdP side.

The implications of a successful SAML bypass are devastating because SSO systems govern access to an organization's most critical assets.

Consider a scenario involving a cloud-based financial management Service Provider used by a Fortune 500 company. An attacker identifies that the SP is vulnerable to XML Signature Wrapping (XSW). The attacker compromises a low-level employee's account (perhaps through a standard phishing attack) to gain legitimate access to the IdP and generate a valid SAML Response for that low-level user.

Using a proxy tool like Burp Suite with a SAML extension (e.g., SAML Raider), the attacker intercepts the response on its way back to the financial SP. They execute an XSW attack, wrapping the legitimate assertion in a malicious wrapper that changes the <NameID> to the Chief Financial Officer (CFO). Because the SP's parser is flawed, it validates the signature but logs the attacker in using the CFO's identity. The attacker now has full administrative control over the company's financial records, able to authorize massive wire transfers or exfiltrate highly sensitive quarterly earnings data before it is made public.

In the case of Golden SAML (as seen in the SolarWinds incident), the attackers didn't need to find a flaw in the SP's parser. By stealing the ADFS token-signing certificate, they silently forged tokens granting them "Global Administrator" access to the victim organization's Microsoft 365 environment, allowing them to read the emails of top executives and exfiltrate data without triggering any traditional brute-force or impossible-travel alerts.

Defending against SAML vulnerabilities requires stringent configuration, secure coding practices on the SP side, and robust monitoring of the IdP infrastructure.

1. Secure Service Provider Implementation

The vast majority of SAML vulnerabilities reside within the Service Provider's parsing and validation logic.

• Use Audited Libraries: Developers should never attempt to write their own SAML parsing or cryptographic validation routines. Always utilize established, heavily audited, and actively maintained SAML libraries (e.g., Shibboleth, spring-security-saml).
• Enforce Strict Validation: The SP must be configured to strictly require signed assertions. It must reject any SAML Response that lacks a valid signature, preventing signature stripping attacks.
• Validate the Recipient and Audience: The SP must verify that the SAML Response is specifically intended for it. It should check the Destination attribute in the root element and the <AudienceRestriction> to ensure the token hasn't been stolen from another application and replayed.
• Disable DTD Processing: To prevent XXE attacks, the XML parser used by the SAML library must be explicitly configured to disable the processing of external entities and DTDs.

2. Protect the Identity Provider Keys

The private signing key of the Identity Provider is the crown jewel of the enterprise network. If it is compromised, the entire SSO trust model collapses (Golden SAML).

• Use Hardware Security Modules (HSMs): Wherever possible, the IdP's private signing keys should be generated and stored within a Hardware Security Module (HSM). An HSM prevents the private key from ever being extracted to disk or memory, making it immune to theft even if the server operating system is compromised.
• Regular Key Rotation: Implement a policy to regularly rotate the IdP signing certificates. This limits the window of opportunity if a key is ever compromised and forces attackers to continuously attempt to steal the new keys.

3. Implement Defense in Depth

While SAML relies heavily on the IdP for authentication, Service Providers should not trust assertions blindly without secondary checks.

• Just-In-Time (JIT) Provisioning Limits: If an SP uses JIT provisioning (creating an account on the fly when a user logs in via SAML for the first time), ensure strict role assignment policies are in place so that a forged token for a non-existent admin doesn't automatically create an admin account.
• Session Monitoring: Monitor for anomalous behavior post-authentication. Even if an attacker bypasses SAML to gain access, their subsequent actions (e.g., downloading massive amounts of data or accessing systems outside their normal working hours) should trigger UEBA (User and Entity Behavior Analytics) alerts.