Wait, did you say ‘Cross-Cloud Provider Attacks’? Yes, this is actually a growing type of attack path: As organizations increasingly adopt multiple cloud platforms, their lack of security visibility across the clouds makes them a sitting target for these types of attacks.

Although lateral movement inside a cloud account is an attack path that security teams are well aware of and most probably already take steps to limit, a lesser known fact is that this lateral movement is actually also possible from account to account, and from one cloud provider to another, also called account or CSP (cloud service provider) ‘hopping’.

For instance, what if an AWS key is left on an asset in Google Cloud? Your AWS environment can be very secure, but if you are not aware of that AWS key on Google Cloud, it’s basically like leaving the door wide open. In the case of multi-account hopping, a user configured on one Azure account might also have permissions to other Azure accounts, allowing them to access and perform actions outside of their main account.

Attack path showing how an attacker can ‘hop’ from AWS to a bucket with PII on Google Cloud

In this blog post, we will dive deeper into the cross-account and cross-cloud provider attack paths that we encounter in the cloud environments scanned by the Orca Cloud Security Platform, their frequency, as well as the causes for these attack paths. Additionally, we will discuss effective detection and mitigation strategies for these threats.

Facts About Cross-Cloud and Cross-Account Hopping

Although not widely publicized (yet), attack paths involving multiple cloud accounts and multiple cloud providers are more common than you think. From our research of 8+ million attack paths discovered by the Orca Platform, we found that 9% of all organizations have at least one cross-cloud provider attack path, and 31% have at least one cross-account attack path.

The key here is that these cross-cloud provider attack paths can only be detected by cloud security solutions that support multiple cloud providers within a single solution. If organizations are using single cloud provider security tools, they may be dangerously unaware of these security weaknesses.

Cross-Account Attack Paths

The practice of using multiple accounts on the same cloud platform is pretty common. From analyzing cloud infrastructures on the Orca Platform, the  majority (63-65%) on AWS, Azure, and Google have more than one account.

There can be several reasons why organizations deploy multiple accounts on the same cloud platform, including:

  • Separate billing per unit: By having different accounts per business unit, it is much easier to assign expenses.
  • Separate environments to limit risk: Reduce the scope of damage that an attacker can cause since they gain access to only a small subset of the organization’s assets. 
  • Different owners and responsibilities: Apply boundaries for teams and professionals.

Although this makes sense in theory, the problem is that accounts on the same cloud provider platform are not actually entirely separate. As we mentioned above, cross-account attack paths certainly exist, exploiting IAM user roles or abusing keys. We found that 5% of all the attack paths detected by Orca are cross-account. Therefore it is important that organizations don’t get lulled into a false sense of security, but actively monitor for cross-account attack paths as well as in-account ones. 

Cross-Provider Attack Paths

Cross-cloud provider attacks occur when an attacker gains access to their target by first compromising one cloud service provider platform, and then finding an opportunity to move laterally to another cloud provider platform. These attack paths can be especially dangerous since many organizations are not even aware of this exposure.

For example, the security team may be feeling pretty confident about their security policies on AWS, only to find out that someone left an AWS key on a Google Cloud asset, leaving them with free range over AWS assets. Even though only a small amount (0.5%) of all attack paths detected by Orca are cross-cloud provider, this is still a significant number if organizations are blind to this risk.

A Proof of Concept of a Cross-Cloud Provider Attack

In the example below, we describe how an attacker is able to compromise sensitive data on AWS by exploiting a weakness in Google Cloud as the entry point:

  1. The attack begins with the adversary exploiting a Log4j Remote Code Execution Vulnerability (CVE-2021-45046) to gain access to an asset on Google Cloud. 
  2. The adversary then uses an Insecure Private Key on the asset to move laterally to another asset on Google Cloud and discovers sensitive AWS keys stored on the system that belong to the AWS user ‘Anika’. 
  3. By assuming the role of Anika, the adversary gains access to an S3 Bucket in the AWS environment, which contains personally identifiable information (PII), including email addresses.
The cross-cloud provider attack path described above as shown in the Orca platform

This proof of concept attack demonstrates the importance of proper security measures across multiple accounts and cloud platforms as well as the ability to understand and monitor cross-account and cross-provider cloud attack paths.

How to Prevent Cross-Account and Cross-Provider Attacks

By following the recommendations below, security teams can help prevent and minimize the impact of possible cloud breaches:

  • Multi-cloud security: Use a cloud security solution that supports multiple cloud providers and combines the data in one platform to correlate and analyze risks from all cloud platforms.
  • Limit permissions: Apply the least-privilege principle to reduce the risk of cross-account and cross-cloud provider attacks and improve cloud security posture in general.
  • Protect the crown jewels: Prioritize remediation of any risks that endanger your business critical assets, such as customer and employee data, intellectual property, and financial data.
  • Remediate strategically: Prioritize remediation of the most critical security risks and the risks with the largest blast radius, i.e. that affect the largest number of assets.
  • Manage secrets: Make sure you are using a security tool that can detect secrets and keys in cloud workloads to prevent cross-cloud provider attacks.
  • Utilize attack path analysis: Make sure teams can uncover and understand the attack paths an intruder could use to reach their end target.

Learn More About Orca Attack Path Analysis

Want to learn more about cross-account and cross-cloud provider attack paths and how Orca can help your security team stay one step ahead of attackers? Join our webinar Defending Against Multi-Cloud Attack Paths on April 13th, at 11 am PST or read our blog on the latest additions to Orca Attack Path Analysis capabilities.