Adversaries that successfully execute attack can achieve persistent anytime, anywhere access to a victim network, security researchers say.

7 Min Read

The recently disclosed compromise at SolarWinds and the subsequent targeting of numerous other organizations have focused attention on a dangerous Active Directory Federation Services (ADFS) bypass technique dubbed "Golden SAML," which cybersecurity vendor CyberArk first warned about in 2017.

The attack gives threat actors a way to maintain persistent access to all of an enterprise's ADFS federated services. This includes hosted email services, file storage services such as SharePoint, and hosted business intelligence apps, time-card systems, and travel systems, according to a blog post from Israel-based Sygnia. The attention that the SolarWinds campaign has drawn to the attack technique significantly raises the likelihood of adversaries leveraging it in future attacks, Sygnia said. "It is therefore highly advised that organizations move swiftly in taking the necessary steps to protect their [single sign-on] infrastructure and establish effective monitoring to detect and respond to such attacks."

According to Sygnia, the Golden SAML technique involves the attackers first gaining administrative access to an organization's ADFS server and stealing the necessary private key and signing certificate.

When a user at the victim organization attempts to access a federated service such as AWS or Microsoft 365, the service redirects the request to ADFS for authentication. Normally, the user would authenticate with ADFS, and ADFS would return a signed SAML response or token to the app or federated service via the user system. The app or federated service would check the response and allows the user to log in.

In a Golden SAML attack, when the user attempts to access a service and when the service redirects the request to ADFS for authentication, the attacker would forge a SAML response using the stolen key to gain unauthorized access. The attack vector allows adversaries to gain access to critical and infrastructure without requiring any additional access on the victim environment. Importantly, attackers will continue to have that access until the ADFS private key is invalidated and replaced — a task that would require altering or terminating connectivity to all federated systems, according to Sygnia.

Arie Zilberstein, vice president of incident response at Sygnia, says ADFS servers are considered "tier-zero" infrastructure and are therefore usually well protected, requiring high privileges for access. "However, the threat actors in this case had a major advantage — the attack originated from SolarWinds," he says. "As SolarWinds Orion is an IT monitoring solution, it usually has access to high-privileged accounts and most servers in any environment, including ADFS."

Zilberstein says the threat actors used Golden SAML in the post-exploitation phase after compromising the internal network and getting access to the ADFS environment on target victim networks. The goal was to establish persistent access to critical resources such as Microsoft 365. Stealing the signing certificate and private key from the ADFS servers gave the attackers anytime, anywhere access to the victim network regardless of additional access to the environment, he says.

An advanced persistent threat (APT) group called Dark Halo (aka UNC2452), believed to be based in Russia, breached SolarWinds' software build system and injected a backdoor called Sunburst into updates of the company's Orion network management software. The updates were sent out to some 33,000 organizations worldwide, about 18,000 of which installed it on their systems. With a small subset of those organizations, the attackers used the Sunburst Trojan to download other malware for stealing data and conducting other forms of cyber espionage. A majority of the victims are believed to be technology companies, government organizations, contractors, and think tanks. Among the known victims are the US Treasury Department, Microsoft, and security vendor FireEye.

SolarWinds has said the attackers managed to poison Orion software updates that the company pushed out between March and June 2020. However, SecurityScorecard says its investigation shows evidence of a Trojanized backdoor in SolarWinds products as far back as October 2019, which means the breach was undetected for a significantly longer time than previously reported.

Initially, it was believed that SolarWinds' Orion platform was the only initial access vector. However, late last week, the US Department of Homeland Security's Cybersecurity & Infrastructure Security Agency (CISA) warned that it had evidence the APT group behind the SolarWinds attack had gained access to some networks using other methods than the tainted updates.

The CISA, National Security Agency, and Microsoft also warned about the attackers bypassing multifactor authentication (MFA) on victim networks by stealing private keys for single sign-on and forging SAML tokens. In a rare emergency directive, the CISA said one of the ways the adversary was gathering information from victim networks after it had gained initial was by gaining privileged access to Active Directory environments, compromising the SAML signing certificate, and then creating unauthorized authentication tokens for accessing federated services.

The CISA has instructed all federal civilian agencies to disconnect their SolarWinds instances and not install any of the patches the company has issued, until further notice. It has also warned all federal civilian agencies not to configure SolarWinds software to implement SAML-based authentication using ADFS. "This configuration is currently being exploited by the threat actor associated with this activity," the CISA noted in its advisory.

CyberArk, which in 2017 released a tool that demonstrates how the attack works, has described Golden SAML as an attack vector that gives adversaries a way to gain persistent access with any privileges they desire to any application that supports SAML authentication, including AWS and Azure.

The vendor has stressed that the attack vector does not rely on a security bug in SAML or with ADFS or any identity provider. Since it is an adversary with administrative access to the authentication environment that executes the attack, defenders can have a very difficult time spotting them, the security vendor has noted.

"I do think this tactic will become more commonly used," says Shaked Reiner, principal cyber researcher at CyberArk Labs. "With more and more services being ported to the cloud, SAML has become the de facto authentication standard to establish trust between the cloud and on-premises services."

Instead of settling on getting the domain's Kerberos local default account and forging any identity within that domain, attackers can steal the SAML token signing certificate and forge almost any identity across the entire organization. "After getting this certificate, it's a matter of signing a token for whatever identity the attackers desire, which is a rather easy process," Reiner says.

The attack vector is problematic for defenders because it makes the use of MFA obsolete. Since users get a valid SAML token only after they've authenticated using MFA, attackers using Golden SAML can simply bypass that stage entirely, he says. "It allows them to go straight to forging an identity using the stolen certificate, without having to know the user password or have other authentication factors." Attackers can grant themselves any identity and permission they desire, he says.

"No changes in users' credentials can help remediate this attack vector," Reiner notes. "Once attackers get a hold of the organization's SAML token signing certificate, this certificate must be changed in order to completely revoke the attackers' ability to use a Golden SAML."

In its blog post, Sygnia described some measures that organizations can take to detect a Golden SAML attack. The detection measures are targeted at organizations with an on-premises ADFS environment. They include correlating login events with corresponding ADFS authentication events and identifying events involving the export of signing certificate from the ADFS server.

About the Author(s)

Jai Vijayan, Contributing Writer

Jai Vijayan is a seasoned technology reporter with over 20 years of experience in IT trade journalism. He was most recently a Senior Editor at Computerworld, where he covered information security and data privacy issues for the publication. Over the course of his 20-year career at Computerworld, Jai also covered a variety of other technology topics, including big data, Hadoop, Internet of Things, e-voting, and data analytics. Prior to Computerworld, Jai covered technology issues for The Economic Times in Bangalore, India. Jai has a Master's degree in Statistics and lives in Naperville, Ill.

Keep up with the latest cybersecurity threats, newly discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

You May Also Like


More Insights