Meet Silver SAML

Key findings

• Golden SAML, an attack technique that exploits the SAML single sign-on protocol, was used as a post-breach exploit, compounding the devastating SolarWinds attack of 2020—one of the largest breaches of the 21st century.
• The supply chain SolarWinds attack affected thousands of organizations around the world, including the U.S. Government, by deploying malicious code into the company’s Orion IT management and monitoring software.
• In the wake of this attack, CISA and cybersecurity experts encouraged organizations with hybrid identity environments to move SAML authentication to a cloud identity system such as Entra ID.
• Semperis researchers Tomer Nahum and Eric Woodruff have discovered a new application of Golden SAML—one that can be exploited even in organizations that have followed previous security recommendations meant to defend against Golden SAML.
• The new attack technique, dubbed Silver SAML, enables the exploitation of SAML to launch attacks from an identity provider like Entra ID against applications configured to use it for authentication, such as Salesforce.
• To Semperis’ knowledge, no attacks using Silver SAML have been reported.
• Semperis researchers rate this vulnerability as a MODERATE risk to organizations. Depending on the compromised system, should Silver SAML be used to gain unauthorized access to business-critical applications and systems, the risk is SEVERE.

Golden SAML is a known attack technique discovered by CyberArk and published by Shaked Reiner. For years, Golden SAML has been known for its extraction of signing certificates from Active Directory Federation Services (AD FS) and its use of those certificates to forge SAML authentication responses. Today, we present a new application of Golden SAML—in Microsoft Entra ID and without the use of AD FS. Meet Silver SAML.

What is Silver SAML?

Today, many organizations use Entra ID as the identity provider (IdP) for software-as-a-service (SaaS) and line-of-business (LOB) applications. SAML is the primary means of authentication for these applications.

Within Entra ID, Microsoft provides a self-signed certificate for SAML response signing. Alternatively, organizations can choose to use an externally generated certificate. However, that option introduces a security risk.

Any attacker that obtains the private key of an externally generated certificate can forge any SAML response they want and sign that response with the same private key that Entra ID holds. With this type of forged SAML response, the attacker can then access the application—as any user.

The proof of concept discussed in this post focuses on Entra ID. But this attack can take advantage of any IdP that allows the import of externally generated SAML signing certificates.

For the sake of this proof of concept, Semperis built and published a new tool, called SilverSAMLForger, that can be used to forge signed SAML responses. You can find SilverSAMLForger on GitHub.

Background: SAML, Golden SAML, and the SolarWinds attack

SAML is a staple of modern authentication. For example, 63 percent of Entra ID Gallery applications rely on SAML for integration. Multi-cloud integrations with Amazon Web Services (AWS), Google Cloud Platform (GCP), and others rely on SAML. And many organizations continue to invest in SAML for SaaS and LOB applications because of the simplicity of its implementation.

Golden SAML and Solorigate

As part of the global supply chain attack on SolarWinds (aka Solorigate), Golden SAML was one of the attackers’ more innovative attack vectors.

The attackers gained initial access to SolarWinds by inserting malicious code into the company’s Orion Platform, used for infrastructure monitoring and IT management. Later, the attackers used this foothold to move laterally into the AD FS environment. From there, they stole the private key material used to sign SAML responses.

As a result of this post-breach Golden SAML attack, many organizations prioritized the move of applications to Entra ID for SAML authentication. This change removed the need to manage a complex Tier 0 infrastructure, and SAML signing keys cannot be exported from Entra ID. Even CISA recommends that organizations with hybrid identity environments move SAML authentication to cloud identity systems such as Entra ID.

The trouble with SAML and signing certificates

Unfortunately, many organizations mismanage signing certificates and weaken SAML security by using externally generated certificates. From our observations, enterprise organizations tend to:

• Generate self-signed signing certificates on a client system
• Generate signing certificates through an enterprise public key infrastructure (PKI), such as Active Directory Certificate Services (AD CS)
• Obtain and use signing certificates from an external certificate authority (CA)

Adding to the problem, we then see organizations that take these externally generated certificates and:

• Send certificate PFX files and passwords through insecure channels such as Teams or Slack
• Generate certificates on client machines, leaving the certificates available for export in the machines’ local certificate store
• Generate certificates on web servers, typically running Microsoft Internet Information Services (IIS), leaving the certificates available for export in the machines’ local certificate store

Even for organizations that use services such as Azure Key Vault—a more secure method for secret and certificate management—attack vectors can exist. (We will cover those vectors in the next section.)

Using an externally generated certificate for SAML response signing increases the attack surface of any IdP, including Entra ID. We have observed several common lessons in organizations that generate and manage SAML signing certificates externally, rather than directly within Entra ID.

• Lack of a chain of trust with self-signed certificates from Entra ID
• Inability to leverage certificate revocation with self-signed certificates
• Need to apply a defined corporate policy blindly to certificate management (usually based on one or both previous reasons)
• A subjective feeling that self-signed certificates are “less secure”

Additionally, some organizations want to maintain a SAML signing certificate lifetime longer than the Entra ID default. These organizations issue external certificates, not realizing that they can simply issue new certificates from Entra ID and configure those certificates to have a longer lifetime.

Many organizations do not understand the nuances of leveraging certificates for SAML signing; signing certificates are simply swept up into their broader certificate management directives and policies. Although common certificate lifecycle and management practices are important to many types of systems, they do not and should not apply to certificates that are used for SAML signing.

A chain of trust is not relevant in SAML. Most IdPs and Service Provider (SP) applications ignore any chain of trust. Unlike the server/client scenario you see with web browsers, an administrator is effectively an essential part of the chain of trust in SAML configurations. The administrator must configure and specify which signing certificate to trust, specifically in the application.

Nor is certificate revocation a relevant practice with SAML. If a signing certificate is compromised, an administrator must rotate (i.e., replace) that certificate in the SP and IdP. OASIS SAML 2.0 Metadata Interoperability Profile Version 1.0 specifically indicates to refrain from using revocation lists, Online Certificate Status Protocol (OCSP), or other mechanisms for key validation. Instead, you should have the IdP remove compromised keys from the SAML metadata.

Importing external certificates

As Figure 1 shows, you can configure self-signed certificates on an enterprise application (Okta, in this example) in the Entra admin center via the application’s Manage > Single sign-on > SAML > SAML Certificates settings.