What you might be missing about the “SolarWinds breach”
Author: Steve Jones
Like many cybersecurity professionals, we at Signal Hill have been following the developments of the SolarWinds breach closely and perhaps struggling to quantify the implications of this uniquely destructive campaign. Yes, the attackers were exceptionally skilled. Yes, the scope of the attack was brazen, and yes, the insidiousness of a malicious contamination in a major software vendor’s supply chain is forcing organizations to recognize new regions of their threat landscape. But to characterize this in the context of SolarWinds, and to limit one’s focus to the supply chain threat may distract from other aspects of this incident that aren’t as widely reported and therefore maybe not well understood by the government agencies and commercial organizations that may be affected. Consider this:
The attackers are known to have compromised many organizations’ networks via the backdoor that was delivered by the tainted SolarWinds patch. SolarWinds customers have been right to focus on determining whether this has happened to them. But organizations that don’t use SolarWinds, or even those that do but haven’t seen indications of further compromise.. can’t yet conclude that they haven’t been breached by this espionage campaign.
Organizations that use Microsoft Office 365 and Azure may have been compromised by the SolarWinds attackers, irrespective of the affected SolarWinds software. The attackers have compromised Microsoft cloud customers through a third party reseller. This attack didn’t exploit any vulnerability within Microsoft’s cloud platform, rather it exploited the very nature of the cloud that allows and encourages sharing of resources and administrative responsibilities with external entities. We are used to thinking about how attackers infiltrate an organization by stealing credentials, escalating privileges, and moving laterally across the organization’s network, but we are not as used to thinking about an attacker breaching an organization and then moving laterally through that organization’s customers, partners, vendors, etc. Here is an example of how this can happen; the victim inadvertently grants consent to a third party, allowing access to their cloud tenant.
These “illicit consent” attacks can be difficult to detect; there is no malware involved, and the malicious activity may not be raising any alarms within the compromised cloud tenants. Worse, the victims of the attack may be under no obligation to notify affected parties. While DHS/CISA is doing a great job working with government agencies and FedRAMP-governed CSPs to alert organizations affected by the SolarWinds breach, not all CSPs are beholden to FedRAMP notification requirements, and commercial third party service providers aren’t required to report intrusions to DHS/CISA. Since most (all?) agencies procure cloud services through a reseller, this presents a significantly large blind spot:
Imagine “Acme”, a hypothetical organization that buys Azure/O365 services or applications through a third party vendor. The vendor was breached via SolarWinds back in March. The attacker stole high-level credentials including credentials that allow the vendor access to Acme’s Azure cloud. The vendor may have recently remediated the SolarWinds backdoor and otherwise cleaned up without disclosing to anyone and without realizing that the attacker has direct access to Acme’s Azure cloud and doesn’t need the SolarWinds back door to read Acme’s email, extract data, etc.
So even though Acme doesn’t use SolarWinds, has no Sunburst IOCs in their environment, hasn’t been notified by anyone of a compromise, and believes they don’t have to worry about this “SolarWinds breach”, the attacker has free reign of Acme’s cloud (and even Acme’s on-prem Active Directory as well, depending on their authentication controls).
The only way for Acme (and you) to have confidence is to mine audit logs for signs of authentication abuse and unauthorized access to Azure/M365 resources. CISA and CrowdStrike have both published tools to make this task easier… but that doesn’t mean it’s an easy task; depending on the number of users, applications, and service principals provisioned in your Azure Active Directory, it can be very difficult to know whether any activity complies with your organization’s definition of what’s “authorized”. If you’re responsible for performing this work at your organization, you’ll want to refer to Microsoft’s recent description of the attacker’s methods to elevate privileges, and this documentation about illicit consent attacks in Office 365.
The “SolarWinds breach” has highlighted a feature of cloud multi-tenancy that isn’t new, but will hopefully get a lot more attention now. Security professionals have long described the “shared responsibility” aspect of the cloud, where some security responsibilities are yours while others belong to the cloud providers. Now we are seeing the “shared liability” of the cloud as well; features and flaws inherent in the cloud platforms which carry security risk need to be recognized and mitigated by the consumers of cloud services. After the SolarWinds malware has been completely ferreted out and remediated, these risks inherent to cloud multi-tenancy will remain.
