Golden SAML: Everything Old is New Again
Threat actors have been exploiting a SAML implementation weakness that allowed malicious actors to forge SAML authentication credentials to log in to third-party services, effectively bypassing the Single Sign-On service as part of the SolarWinds attack. The attack dubbed Solorigate or SUNBURST, included the technique that allowed cyberspies to log in as any user and assume whatever role within the third-party service the actor was accessing. This method permitted cybercriminals to blend into regular user activity to help obfuscate their malicious actions. It also effectively bypassed multifactor authentication, which usually prevents account takeover attacks.
While this may seem like a revolutionary attack, it is based on an old technique called Golden SAML that Shaked Reiner first reported in 2017. The Golden SAML exploit itself is based in part on the Golden Ticket attack against Kerberos made accessible by the Mimikatz tool. Though the Golden SAML technique was known for quite some time, the SolarWinds breach and subsequent fallout have brought it into sharper focus. The technique is classified by MITRE ATT&CK as T1606.002 Credential Access: Forged Web Credentials: SAML Tokens.
How does Golden SAML Work?
Security Assertion Markup Language (SAML) is a protocol used to create trusted authentication environments, particularly with cloud resources. Its main advantage is allowing the creation of federated identities across multiple independent environments. It does this by allowing an environment, like a cloud service, to request identity validation from a trusted third-party, like Microsoft Azure AD. The third-party handles the authentication and then passes a token to the cloud service in order to authenticate and validated the identity to the service.
SAML can work in multiple different environments, as long as they are able to set up a trust relationship with the third-party identity provider. SAML works like this:
· A user tries to sign into a service, such as Amazon Web Service.
· AWS sends a SAMLRequest to an identity provider, such as Microsoft Azure AD, to authenticate the user.
· The user logs into the identity provider using their credentials for that provider.
· The provider passes along a SAMLResponse which verifies the identity to the service.
· The service allows the user to login as the identity they provided.
In a Golden SAML attack, the attack bypasses the identity provider by forging a SAMLResponse. Essentially, the attacker is able to forge a response and trick the service into believing a user has authenticated to the identity provider. This cuts the identity provider entirely out of the SAML steps listed above, allowing the attacker to skip directly to step 3 in the graph. What is worse is that any controls placed on authentication, such as MFA, are also skipped since those rely on the identity provider. To forge the response, the attacker needs access to the identity providers back end to find the private key used to sign responses that the identity provider would normally create after authentication.
Bypassing the identity provider entirely to access a cloud service make this attack exceedingly difficult to deal with. First, the attacker can forge any account they want since the same private key is used to sign responses regards of the user that is being authenticated. This makes it difficult to detect malicious activity because it can easily be lost in the background of normal authentication traffic. Second, once the attack is discovered, resetting MFA or account passwords will not stop the attacker. The attacker already has the private key which means the entire trust relationship must be reestablished and a new private key issued before any account password or MFA changes can be made. The flexibility in exploitation and the complexity in discovery and remediation make Golden SAML an extraordinarily strong tool for any attacker.
There are some mitigations to this attack:
· Rotating private keys to ensure that if one is compromised it can not be used for an extended period.
· Heighten awareness and monitoring around SAML authentication to detect when a Golden SAML attack might be in play.
· Additional privilege management and monitoring around Federated Identity accounts to ensure they are not exploited to allow access to the private key.
Unfortunately, there is no silver bullet for Golden SAML. The attack is not an exploit of a vulnerability but instead is exploiting the structure of how SAML is supposed to work. That said, heightened awareness and monitoring, especially around key federated services activity, and zero trust concepts can help to ensure you do not fall victim to this attack.
MITRE ATT&CK Codes
https://attack.mitre.org/techniques/T1606/002/
T1606.002 Credential Access: Forged Web Credentials: SAML Tokens
Sources
https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/
[1] Diagram courtesy of CyberARK article: Golden SAML: Newly Discovered Attack Technique Forges Authentication to Cloud Apps by Shaked Reiner 11/21/17 https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps
