Use Case: Identity
Golden SAML detection
A SAML assertion granted domain admin access to an account that doesn't exist in Active Directory. The signing certificate is cryptographically valid. ManySignal flagged the assertion mismatch in 2 minutes.
The technique that made SolarWinds possible
Golden SAML was the persistence mechanism that allowed SolarWinds Orion-compromised environments to maintain cloud access even after the initial backdoor was removed. By obtaining the ADFS token-signing certificate, the threat actor (Cozy Bear / APT29) could generate valid authentication tokens for any user, bypassing MFA and all other IdP controls. The technique is named after Golden Ticket — the Kerberos equivalent — and is similarly powerful as a persistence mechanism.
Detection requires asserting claims within SAML tokens against the actual directory state: if a SAML assertion claims group memberships, roles, or attributes that don't match the real user's directory record, that mismatch is the detection signal — regardless of whether the assertion's cryptographic signature is valid.
rule: golden_saml_assertion_anomaly
type: claim_validation + behavioral
sources:
- adfs_audit_log
- microsoft_entra_signin
- active_directory_ldap
trigger:
- event: saml.authentication.success
- condition: |
assertion.claims.groups NOT MATCH ldap_lookup(user.upn).groups
OR assertion.claims.upn NOT IN active_directory.users
OR assertion_source_ip NOT IN user_known_devices
enrichments:
- directory_validation: real-time ldap query
- cert_access_audit: adfs_certificate_export_events
- post_auth_activity: cloud_api_calls_15m
- solarwinds_ioc: known_apt_infrastructure
mitre: T1606.002 (SAML Tokens)MITRE ATT&CK mapping
Golden SAML FAQ
What is Golden SAML and why is it so dangerous?
Golden SAML is an attack technique discovered by CyberArk in 2017, later used in the SolarWinds breach. If an attacker obtains the ADFS token-signing certificate private key, they can forge SAML authentication responses for any user in the organization — including accounts that don't exist in Active Directory. The forged assertions bypass all IdP-level controls including MFA, because the assertion is cryptographically valid.
How does ManySignal detect Golden SAML since the forged assertions look valid?
Three signals flag Golden SAML: (1) authentication from an IP or device not associated with the claimed user, (2) claims in the SAML assertion (group memberships, roles) not matching the actual directory entry for that user, and (3) access to ADFS token-signing certificate material from an unusual process or account. ManySignal correlates all three.
Is Golden SAML still relevant with modern Entra ID environments?
Yes. Organizations running hybrid environments with ADFS in addition to Entra ID are still vulnerable. Additionally, analogous techniques apply to other SAML IdPs — any IdP where the signing certificate is accessible from a compromised server can be abused. The detection logic applies to all SAML assertion anomalies.
What's the remediation if Golden SAML is confirmed?
Remediation requires rotating the ADFS token-signing certificate, which invalidates all existing SAML sessions and forces re-authentication across the entire organization. This is a significant operational event. ManySignal's playbook includes pre-calculated rollout steps for minimizing user disruption during the certificate rotation.
Validate SAML assertions against your live directory
Real-time SAML claim validation against Active Directory — detect forged assertions regardless of cryptographic validity.