Microsoft recently disclosed a set of complex techniques used by an advanced actor to execute attacks against several key customers. While we detected anomalies by analyzing requests from customer environments to the Microsoft 365 cloud, the attacks generalize to any Identity Provider or Service provider. For this reason, we want to detail what we know about these attacks from an Identity specific lens, so Identity vendors, IAAS, PAAS, and SAAS vendors (and organizations who use these products) can detect them, remediate them, and most importantly, prevent them. This document is broadly intended to support the security teams who are focused on protection, hunting, and remediation in Identity vendors in the interest of protecting our mutual customers. It generally assumes an advanced understanding of identity infrastructure and related components.
As part of our ongoing security processes, we leverage threat intelligence and monitor for new indicators that could signal attacker activity. There are two anomalies pertinent to this report, and discussed at https://aka.ms/solorigate:
Built-in security and monitoring capabilities provided by the Microsoft Cloud detected these anomalies, but such anomalies could present at any Identity Provider or Resource Provider, regardless of vendor. Any resource which trusts a customer’s compromised SAML token signing certificate should be considered at risk. The SAML attack is not specific to any particular identity system or identity vendor you use. It impacts any vendor’s on-premises or cloud identity system, and any resources that depend on industry-standard SAML identity federation. Likewise, while the specific mechanism for impersonating applications may vary from vendor to vendor, the pattern is vendor independent. We are not aware of any Microsoft software or cloud service vulnerability that has led to the exposure of customer SAML token signing certificates, the change in API usage, addition of credentials to service principals, or exposure of administrative credentials on premises or in the cloud. The traffic detected did not impact our production cloud environment
Elements of the activity we have detected and discuss in this blog suggest it was orchestrated by a sophisticated attacker. We believe over time this activity may be determined to be state-sponsored, but we do not have sufficient evidence to support that conclusion at this time.
It is important to emphasize – these attacks were criminal in nature, and so sophisticated that even top security companies fell victim to them. The fault lies with the criminal actor, not the victims. Further, these attacks leveraged broadly used patterns that impact many levels of the IT industry – focusing on any one technology type or vendor limits our ability to see systemic problems. By studying them and learning from these broad issues together, we can improve security throughout the industry.
We are sharing this information to help vendors who provide Identity Providers and Service Provider software and services, as well as their customers, hunt for activity and better defend against similar attacks. We will update this information as our investigations evolve.
Identity experts may skip this section, but it may help level set terminology and understanding of key components of the attack.
The following describes a typical environment. However, several caveats are worth mentioning:
For these reasons, it is important that you consider how elements of the attack pattern can impact your organization, even if your organization varies from the typical elements described below.
Components pertinent to this attack typically include:
If this is new to you, you can think of tokens as a ticket to a show, the SP as the ticket taker, and the IDP as the box office, and the signature as the little holograph on the ticket. If someone wants to go to the show, they go to the IDP, get a token, then present it to the SP who validates the holograph then lets them into the show.
In terms of a typical email interaction with Microsoft 365 with federated auth, think in terms of a user going to their on premises federation server to get a signed token, then presenting that token to Microsoft 365 (via Azure AD as a chained IDP) to get access after the signature is validated. If an application is trying to access that data, it will be pre-configured to know the IDP location, so it will always come to Azure AD first to get the token, but otherwise the OAUTH flows are similar.
For SAML federation relationships where Azure AD has been configured to trust a tenant-configured SAML token signing certificate from a customer-configured federation server, the federation server is the Identity Provider (IDP)and Azure AD is the Service Provider (SP).
Applications and Service Principals in Azure AD don’t use SAML or delegate trust to on premises federation servers; credentials must be managed directly in Azure AD.
OK, let’s lay all of this out in terms of the typical attack patterns, and how you might go about looking for them. The actions were targeted in nature and varied from target to target. Not all indicators of compromise or methodologies are present in all cases.
A rough overview of an indicative attack is as follows (see also https://aka.ms/solorigate). Each attack varied in details, but this pattern emerged repeatedly:
The details of each phase of the attack are described below.
The first significant pattern we have seen is evidence of forged SAML tokens. It is worth noting that we don’t retain logs for very long. We do this in accordance with our data retention and privacy policies. It varies by agreement, but is generally is 30 days, and we never log complete tokens, so we can’t see every aspect of a SAML token. Customers who want longer retention are encouraged to configure storage in Azure Monitor or other systems. What token anomalies we did detect were tokens which were anomalous in lifetime, usage location, or claims (particularly MFA claims). The anomalies were sufficient to convince us that the tokens were forged. We did not find this pattern in all cases.
In some cases, the SAML token forgeries described above correspond to configuration changes in the Service Provider. By impersonating a user with valid administrative credentials, the actor can change the configuration of the SAML Service Provider (in our case, Azure AD). In this case, the actor tells Azure AD to trust their certificate by, in effect, saying to the SP “There’s another SAML IDP you should trust, validate it with this public key.”
Once the attacker was able to impersonate a privileged Azure AD admin account, they added credentials to existing applications or service principals, usually with the permissions they wanted already associated and high traffic patterns (e.g. mail archival applications). There are some cases in which we see the attacker add permissions to existing applications or service principals. We also see cases in which a new application or service principal was set up for a short while and used to add the permissions to the existing applications or service principals, possibly to add a layer of indirection (e.g. using it to add a credential to another service principal, then deleting it).
With credentials added to an existing application or service principal, the actor proceeded to acquire an OAUTH access token for the application using the forged credentials, and call APIs with the permissions which had been assigned to that applications. Most of the API calls we detected were focused on email and document extraction, but in some cases API calls added users, or added permissions to other applications or service principals. Calls were generally very targeted, synchronizing then monitoring email for specific users.
This section relates other observations of attacker behavior.
Our optics into on premises behavior are limited, but here are the indicators we have as to how on premises access was gained. We recommend using on premises tools like Microsoft Defender for Identity (formerly Azure ATP) to detect other anomalies:
For administrative access to the Microsoft 365 cloud, we observed:
This graph summarizes the vectors and combinations tracked in this document.
The following guidance may assist customers in protecting their environments.
The Solarwinds attack is an ongoing investigation, and our teams continue to act as first responders to these attacks. As new information becomes available, we will make updates through our Microsoft Security Response Center (MSRC) blog at https://aka.ms/solorigate.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.