How the SolarWinds hackers are targeting cloud services in unprecedented cyberattack

GeekWire Illustration / Canva Image[Editor’s Note: Independent security consultant Christopher Budd worked previously in Microsoft’s Security Response Center for 10 years.]
Analysis: To understand where the SolarWinds attackers are going next, and how to defend against them, look to the clouds.
The SolarWinds supply chain attacks are unprecedented in many ways. The attacks are sophisticated in execution, broad in scope, and incredibly potent in their effectiveness. But perhaps most notable is the unprecedented manner in which the SolarWinds attackers seem to be seeking access to cloud-based services as one of their key objectives.
This is becoming clearer as new reports clarify information obfuscated by technical jargon in early incident reports last week.
On Monday, the New York Times reported that “[t]he Russian hackers who penetrated United States government agencies broke into the email system used by the Treasury Department’s most senior leadership.” This follows a report from Reuters on Dec. 13, saying “[h]ackers broke into the [National Telecommunications and Information Administration] NTIA’s office software, Microsoft’s Office 365. Staff emails at the agency were monitored by the hackers for months, sources said.”
Taking these reports and looking again at the technical details released by Microsoft and the National Security Agency (NSA) in the past week shows how the SolarWinds attackers have made targeting cloud-based services a key objective in their attacks. Specifically, if we decode the various reports and connect the dots we can see that the SolarWinds attackers have targeted authentication systems on the compromised networks so they can log in to cloud-based services like Microsoft Office 365 without raising alarms. Worse, the way they’re carrying this out can potentially be used to gain access to many if not all of an organization’s cloud-based services.
This tells us that attackers have adapted their attack methodology to match the hybrid on-premises/cloud environments many organizations now have. This means that responders to the SolarWinds attacks need to look not just at their systems and networks but also at their cloud-based services for evidence of compromise. This also means that defenders need to increase the security and monitoring of their cloud services authentication systems and infrastructure from now on.
We’ll explore the technical details below, but here are the key takeaways:

One of the key actions SolarWinds attackers take after establishing a foothold on networks is to target the systems that issue the proof of identity used by cloud-based services and steal the means to issue IDs.
Once they have this, they can use it to create fake IDs that enable attackers to impersonate legitimate users or create malicious accounts that seem legitimate, including accounts with administrative (ie total) access.
Because these IDs are used to give access to data and services by cloud-based services, the attackers are able to access data and email just like legitimate users, including those with total access, and they do so.

It is very likely that this is how the SolarWinds attackers gained access to Treasury and NTIA’s email systems: they leveraged the network compromise to get access to cloud-based services. In fact, one of the Microsoft postings about SolarWinds talks about “Protecting Microsoft 365 from on-premises attacks” which really means, “How to keep your network compromise from turning into a cloud-services compromise, as well.”
What is SAML and why does it matter?
To understand this aspect of the SolarWinds attacks, it’s important to know that SAML stands for “Security Assertion Markup Language.” It’s a method for authentication (i.e. logging on) used in cloud-based services. A “SAML token” is the actual “proof” to the service that you are who you say you are.
Anyone who’s an expert in cloud or authentication technologies won’t find the Treasury or NTIA developments surprising: Microsoft made this aspect clear in both its postings on Dec. 13: Customer Guidance on Recent Nation-State Cyber Attacks and Important steps for customers to protect themselves from recent nation-state cyberattacks. Both postings have the following, identical language:

The intruder uses “administrative permissions acquired through an on-premises compromise to gain access to an organization’s trusted SAML token- signing certificate. This enables them to forge SAML tokens that impersonate any of the organization’s existing users and accounts, including highly privileged accounts.”
“Anomalous logins using the SAML tokens created by the compromised token signing certificate can then be made against any on-premises resources (regardless of identity system or vendor) as well as to any cloud environment (regardless of vendor) because they have been configured to trust the certificate. Because the SAML tokens are signed with their own trusted certificate, the anomalies might be missed by the organization.”

Then Microsoft released a series of blog posts discussing the SolarWinds attacks, SAML and identity technologies (Dec. 15, Dec. 18, Dec. 21, and Dec. 21).
Meanwhile on Dec. 18, the NSA released a directive on “Detecting Abuse of Authentication Mechanisms.” While not in specific response to the SolarWinds attacks, it discusses SAML attacks and puts the SolarWinds attacks in the context of these attacks, which have been around since 2017.
Information is scattered across all of these postings but together they make clear that:

One of the key actions SolarWinds attackers are taking after they establish a foothold on networks is to “[steal] the certificate that signs SAML tokens from the federation server (ADFS) called a Token Signing Cert (TSC).” [Source]
Once they have this, it lets them “forge SAML tokens to impersonate any of the organization’s existing users and accounts, including highly privileged accounts.” [Source]
Because “[d]ata access has relied on leveraging minted SAML tokens to access user files/email or impersonating the Applications or Service Principals by authenticating and obtaining Access
Tokens using credentials that were added…[t]he actor periodically connects from a server at a VPS provider to access specific users’ emails using the permissions granted to the impersonated Application or Service Principal.” [Source]

What does this mean?
For security professionals, nothing here is new or surprising: total access to a network means you can do anything you want with it. Also, the NSA document notes these attacks have been seen since 2017. But this is the first major attack with this kind of broad visibility that targets cloud-based authentication mechanisms. That, combined with the technical jargon in these reports, means that many people haven’t yet connected these dots.
It doesn’t help that some of the discussion of this aspect has been unclear. Some reports have indicated that there’s a vulnerability affecting Microsoft’s products or services involved in the Treasury or NTIA email intrusions. I asked Microsoft if there were any vulnerabilities involved and they responded: “We have not identified any Microsoft product or cloud service vulnerabilities in these investigations. Once in a network, the intruder then uses the foothold to gain privilege and use that privilege to gain access.”
The NSA also speaks to this saying “[b]y abusing the federated authentication, the actors are not exploiting a vulnerability in [the Microsoft authentication technologies] ADFS, AD, or AAD, but rather abusing the trust established across the integrated components.” That is consistent with what I’ve outlined: attackers who own your network don’t need a vulnerability to gain access to your cloud-based services, they already have all they need to pull that off.
And while the discussion has focused on Microsoft’s cloud-based services, so far there is no information that indicates these attacks can only happen against their products or services. SAML is an open-standard that’s widely offered by vendors other than Microsoft and used by non-Microsoft cloud-based services. The SolarWinds attacks and these kinds of SAML-based attacks against cloud services in the future can involve non-Microsoft SAML-providers and cloud service providers.
Next Steps
Taking all of this into account, what next steps should people take?
First, if your organization has had the compromised SolarWinds files on your network, your incident response process needs to include checking your authentication systems for your cloud-based services for possible compromise. And if you cannot rule out that it’s been compromised, you’ll need to verify the integrity of those services.
Next, everyone using cloud-based services needs to take the NSA directives very seriously and prioritize increasing the security and monitoring of their cloud-based service authentication mechanism.
Finally, be ready to hear about more organizations’ cloud-based services being compromised as part of the SolarWinds attacks. This is the biggest, broadest attack we’ve seen. As a result, it’s a situation that’s going to take months, if not years, to fully untangle.