Echoes of SolarWinds in New ‘Silver SAML’ Attack Technique – Source: www.darkreading.com

Source: shaneinsweden via Shutterstock

After the threat actor behind the SolarWinds attack compromised the company’s Orion network management product and leveraged it to break into target enterprise networks, the group often used a technique dubbed “Golden SAML” to maintain persistent access to different applications and services in that environment.

The technique involved stealing the victim organization’s Active Directory Federation Services (ADFS) token-signing certificate and using it to forge SAML response tokens. The tokens allowed the threat actor to authenticate — without a password or two-factor authentication — to any federated service they wanted on the victim’s network with self-assigned administrator and super-admin privileges.

A Twist on the Golden SAML Technique

This week, researchers at Semperis released details of a new version of the technique that they discovered and have dubbed “Silver SAML.” Like the original, Silver SAML involves SAML response forgery but doesn’t require the attacker to have access to ADFS. It also works in Microsoft Entra ID (formerly Azure AD) and any other identity provider environment that permits the import of externally generated SAML signing certifications, Semperis said.

“The main difference is where the attack is implemented,” says Eric Woodruff, researcher at Semperis. “Golden SAML historically has been used to move into Entra ID and then optionally other applications. Silver SAML only allows you to move into applications; you won’t breach Entra ID itself.”

Many organizations use a SAML token-based architecture for enabling single sign-on (SSO) for users within enterprise settings and across multiple SaaS and cloud services such as Azure, AWS, and Google Cloud. For SaaS or muticloud SSO via SAML, when a user first requests access to a service or app, the service sends a SAML request to an identify provider such as Entra ID. The identity provider authenticates the user and generates a signed SAML token confirming the user’s identity information and other details such as username, groups, and other attributes. The service provider receives the token via a SAML response or XML document, which is often digitally signed as well.

In a Golden SAML attack — which CyberArk first described in 2017 — an adversary steals the ADFS token-signing certificate and then uses it to forge SAML tokens granting themselves access to any federated service and app, and with any level of privileges they choose.

Externally Generated Signing Certificates  

Silver SAML is an approach that works when an identity provider, such as Entra ID, gives organizations the option of using self-signed or externally generally certificates — such as those via a trusted certificate authority — to sign SAML responses. Often organizations opt to use externally generated signing certificates for SAML responses in the belief they are somehow stronger or because a broader enterprisewide policy might mandate the use of external certificates, Woodruff says. However, certificate management and life-cycle practices that might be applicable in other contexts can be dangerous when applied to SAML, he says.

“Silver SAML is only possible when the signing certificate was generated externally from Entra ID — it does not matter if the certificate is from an external signing authority or externally self-signed,” Woodruff notes. “If the certificate is generated within Entra ID, the private key cannot be exported, and SAML response forging is impossible without it.”

When an organization permits the use of an external signing certificate, an attacker that manages to steal it can then use the certificate to forge any Entra ID SAML response, Woodruff says. Obtaining these certificates can often be easier than perceived because of the insecure ways in which organizations sometime manage them. For instance, some organizations generate and store self-signed certificates on insecure client systems or on Web servers and leave them available for export in the machines’ local certificate store, Semperis said in its report. In other instances, an organization might send a signing certificate as an attachment in email, Slack, or Teams, and the password for it is sent along with it.

“For organizations that still had or have ADFS, there has been a surge of migrations to Entra ID, and organizations can have hundreds upon hundreds of applications to migrate,” Woodruff says. “In many of these instances they are likely to work with consultants, and out of expediency will take the path of least resistance with certificate management.” Even when an organization might store an externally generated signing certificate in a secure app like Azure Key Vault, there are ways an attacker can access and use it to sign a SAML response, he says.

The SilverSAMLForger Proof of Concept

To demonstrate how a Silver SAML attack might play out, the researchers at Semperis built a “SilverSAMLForger” proof-of-concept tool that generates a SAML response spoofing an Entra ID response and signed with an externally generated certificate. The research highlights why organizations that use externally generated certificates should take care to manage them securely and ensure they are protected as a Tier 0 — or critical — resource, he says.

Despite the potential damage an attacker could do via Silver SAML, Woodruff assesses it as a moderate severity threat for organizations. That’s because it works only in situations where an organization uses externally generated certificates and does not manage them securely. “Further, it’s difficult to assess the severity of the attack because it’s going to vary for each organization,” he says. “It depends on what type of applications they have federated to Entra.”