SAML: federated authentication attacks & defense

SAML (Security Assertion Markup Language) is an XML-based open standard that enables federated authentication between an Identity Provider (IdP) and a Service Provider (SP). The IdP issues signed XML assertions that confirm a user's identity. The SP trusts these assertions without re-authenticating the user. SAML underpins most enterprise Single Sign-On deployments, including ADFS, Okta, and Azure AD. Each assertion contains authentication statements, attribute statements, and authorization decisions. The assertion is signed using asymmetric cryptography, typically RSA with SHA-256. The SP validates the signature against a pre-registered IdP certificate. If that trust relationship is compromised, an attacker can forge valid assertions for any identity in the federation. This is precisely why SAML is a high-value target in identity-focused attack chains. Understanding its XML structure, binding types (HTTP-POST, HTTP-Redirect, Artifact), and signature validation logic is prerequisite knowledge for both offensive and defensive practitioners working on federated identity systems.

Detecting SAML-based attacks requires visibility into IdP logs, SP-side authentication events, and network traffic carrying XML payloads. On ADFS, enable auditing at the verbose level: Event ID 411 (token validation failure), Event ID 412 (token issued), and Event ID 510 (extra claims) are critical. For Azure AD, monitor the Sign-in logs for 'unfamiliar sign-in properties' and correlate with the SAML token issuer field. Golden SAML attacks leave a distinctive trace: assertions are issued without a corresponding authentication event on the IdP side. Look for sign-ins to cloud services where no matching ADFS authentication occurred in the same time window. Network-level detection involves inspecting HTTP-POST bindings for malformed or duplicate XML signatures, which are characteristic of XML Signature Wrapping (XSW) attacks. A SIEM rule correlating successful SP logins with absent IdP session records is a strong detection primitive. Certificate usage anomalies, such as signing certificates accessed outside normal maintenance windows, should also trigger alerts. Tools like Splunk with the ADFS add-on or Elastic with custom ingest pipelines can parse SAML assertions from logs for structured analysis.

Red Team operators target SAML at two distinct layers: the protocol logic and the IdP infrastructure itself. XML Signature Wrapping (XSW) attacks manipulate the position of the signed element within the XML document. The signature remains valid, but the SP processes an unsigned, attacker-controlled element. There are eight documented XSW variants. Tools like SAMLRaider (Burp Suite extension) automate XSW payload generation and assertion tampering. The Golden SAML technique, documented against ADFS environments, requires prior compromise of the IdP token-signing private key, typically extracted from the ADFS DKM container in Active Directory or from the ADFS configuration database at 'C:/Windows/ADFS/'. With the private key, an attacker forges assertions offline for any user, including privileged accounts, with no interaction with the live IdP. ADFSDump and AADInternals are the primary tools for key extraction. Hardening measures include rotating token-signing certificates regularly, enabling ADFS Extranet Lockout, enforcing MFA at the SP level independently of the assertion content, and restricting access to the ADFS configuration database to dedicated service accounts only. Monitoring DPAPI-based decryption events on the ADFS server adds a detection layer for key theft attempts.