Introduction

In 2022, a significant phishing campaign known as “0ktapus” targeted Okta users, successfully bypassing their one-time code-based multi-factor authentication (MFA). Attackers sent SMS messages containing links to phishing sites that closely resembled the victims’ organizational Okta login pages. Unsuspecting employees entered their corporate credentials and 2FA codes into these fraudulent sites, which were then captured by the attackers. Many enterprises that integrated Okta with cloud service providers such as AWS, Azure, and Google Cloud Platform (GCP) for authentication and security were affected. The complexity of cloud-native architectures, shared responsibility models, and the dynamic nature of cloud environments further amplify these challenges.

Twilio Hackers Scarf 10K Okta Credentials in Sprawling Supply Chain Attack

Cloud supply chain attacks are becoming increasingly frequent and sophisticated, posing significant risks to organizations. As businesses rely more on cloud services for digital transformation, securing cloud supply chains has become a critical challenge. Unlike traditional IT environments, cloud supply chains involve multiple interconnected vendors, third-party software providers, and dependencies, each introducing security vulnerabilities. A single compromised component, such as a vulnerable third-party API, misconfigured software update, or exploited identity federation, can serve as an entry point for widespread breaches, leading to data theft, service disruptions, and regulatory non-compliance.

In our previous blog, “Understanding Supply Chain Attacks in the Cloud: An Introduction to the Silent Threat”, we explored the differences between traditional supply chain attacks and modern cloud-centric supply chain attacks. In this blog, we will examine techniques and real-world examples of how threat actors exploit cloud supply chains across the three major cloud service providers: AWS, Azure, and GCP.

Understanding Cloud Supply Chain Attacks

A blog post by Dark Reading reported that “Next-Gen” supply chain attacks have surged by 430% in recent years, highlighting the increasing frequency and sophistication of supply chain attacks. Cloud supply chain attacks are no exception, as organizations increasingly rely on cloud services for their operations. The shared responsibility model in cloud computing, where security responsibilities are divided between cloud service providers (CSPs) such as AWS, Azure, and Google Cloud, and their customers, adds complexity to cloud security and amplifies these risks. Businesses integrate third-party vendors, software dependencies, and external services into their cloud environments, expanding the attack surface and introducing increasing potential entry points for attackers.

Security weaknesses within this interconnected cloud ecosystem can be exploited through misconfigurations, vulnerabilities in third-party software, insecure software dependencies, open-source components, or insider threats. A single compromised component associated with cloud can give attackers unauthorized access, allowing them to steal data, introduce malicious code, or disrupt operations, resulting in a successful cloud supply chain attack.

Why Cloud Service Providers (CSPs) Are Prime Targets

One of the most well-known quotes about cloud computing today is, “Because it’s in the cloud doesn’t mean it’s secure.” Many organizations assume that migrating to the cloud automatically ensures security, but this is a misconception. In a blog post by iShareInfo titled “Cloud Service Providers Risk Landscape,” the author explored various incidents that have impacted Cloud Service Providers (CSPs) such as AWS, Azure, and Google Cloud (GCP) over the years.

These Major cloud service providers offer extensive cloud-native security services to help customers defend against evolving cyber threats. However, their reliance on third-party integrations and automation frameworks introduces vulnerabilities that attackers can exploit. Weaknesses in third-party software, insecure APIs, or misconfigured automation tools create potential entry points for cyberattacks, exposing cloud environments to security risks. Given their vast, interconnected ecosystems of third-party services and dependencies, AWS, Azure, and GCP have become prime targets for cybercriminals. According to Dark Reading, the rapid expansion of cloud computing has increased the complexity of cyber threats facing cloud service providers (CSPs). As cloud adoption and interconnectivity continue to grow, attackers are increasingly exploiting these vulnerabilities, creating systemic risks that extend beyond individual companies to entire industries.

A single compromise within a CSP’s ecosystem can have a ripple effect, impacting thousands or even millions of customers. Attackers often target widely used third-party services (e.g., identity management tools, security software, or database management solutions) to gain indirect access to multiple cloud environments. For example, an attacker exploiting a vulnerability in an API used for cloud automation can potentially escalate privileges, exfiltrate sensitive data, or deploy malicious workloads across multiple customer accounts. This cascading impact makes CSP-focused supply chain attacks a high-value target for cybercriminals, as breaching one critical component can affect an entire network of interconnected businesses.

Techniques Used by Attackers to Exploit Cloud Supply Chains

Adversaries employ various sophisticated means to exploit supply chain vulnerabilities within major Cloud Service Providers (CSPs) such as AWS, Azure, and Google Cloud Platform (GCP). The following are prominent techniques, tools and procedures (TTPs) discovered in the wild by infamous Advanced Persistent Threads (APTs):

Supply Chain Attacks via Managed Service Providers (MSPs)

Attackers increasingly target Managed Service Providers (MSPs) to infiltrate multiple client environments through a single breach point. MSPs offer services like networking, maintenance, and cloud solutions, often possessing deep access to their clients’ systems. This extensive access makes them attractive targets for cybercriminals aiming to maximize the impact of their attacks.

The SolarWinds supply chain attack, disclosed in December 2020, stands as a significant example of how compromising a Managed Service Provider (MSP) can have extensive repercussions across both public and private sectors. Attackers infiltrated SolarWinds’ Orion software build system, embedding malicious code into updates between March and June 2020. This breach affected approximately 18,000 customers who downloaded the compromised updates, including U.S. government agencies and numerous private enterprises.

SolarWinds Breach 2020 – Image Source: https://www.informationweek.com/

More specifically, the threat actor followed a pattern of the following action:

Unauthorized modifications to system tasks
Repeated cycle of directory creation, execution, and deletion
Presence of newly created or unrecognized local user accounts
Evidence of Adfind.exe usage or existence
Instances of cmd.exe or rundll32.exe being executed from solarwinds.businesslayerhost.exe
Unusual or overly permissive email forwarding and deletion rules on the email gateway

Exploiting Third-Party Software Dependencies

According to Orca Cloud Security Platform, nearly half (49%) of organizations are vulnerable to a Dependency Confusion attack, which exploits the way package managers retrieve software dependencies. Attackers create malicious packages with the same names as legitimate private ones and publish them to public repositories. If a package manager prioritizes public sources over private ones, it may mistakenly download and integrate the malicious package. This can lead to code execution, system compromise, and security breaches across cloud environments, including AWS, Azure, and Google Cloud Platform (GCP).

In September 2024, Tenable Research identified a critical remote code execution (RCE) vulnerability in Google Cloud Platform (GCP), termed CloudImposer. This flaw resided in Google Cloud Composer, a managed orchestration service built upon Apache Airflow. The vulnerability allowed attackers to execute arbitrary code on GCP servers by exploiting the dependency installation process. When the attacker uploads a malicious package to the Python Package Index (PyPI) with the same name as an internal dependency, they could have it pre-installed on all Composer instances with elevated permissions. This breach could lead to unauthorized code execution, data exfiltration, and lateral movement within GCP services. Tenable reported the issue to Google, which acknowledged and rectified the vulnerability by April 22, 2024. Additionally, Google updated its documentation to guide users in securely managing Python dependencies, mitigating similar risks in the future.

Compromising Continuous Integration/Continuous Deployment (CI/CD) Pipelines

In December 2020, attackers identified as the Russian SVR hacking group known as Cozy Bear, infiltrated SolarWinds’ CI/CD pipeline, injecting malicious code into the Orion software updates. This supply chain attack affected thousands of organizations, including U.S. government agencies and major corporations. The breach underscored the potential impact of compromised CI/CD pipelines on a global scale.

CI/CD pipelines are integral to the automated software deployment process, enabling rapid development and delivery. However, they also present attractive targets for threat actors. Attackers exploit vulnerabilities within these pipelines to insert malicious code during the build process, potentially compromising the entire software supply chain.

CI/CD Compromise in a typical Cloud Attack Chain Breach

Common Attack Vectors with CI/CD compromise:

Exploitation of Third-Party Services: CI/CD systems often rely on multiple third-party services and plugins to perform tasks like code scanning and linting. While these integrations can be incredibly useful, they also present a significant risk as they often grant a high level of permissions for resources in the CI/CD system to third-party services. If a third-party service or plugin is compromised, having overly permissive access can lead to attackers pushing malicious code and compromising the CI/CD or even the production environment.
Unauthorized Code Alterations: Attackers who gain access to CI/CD systems can make unauthorized changes to the codebase. For example, they might backdoor the code in the exploited repository to attack anyone who uses the code associated with the compromised repository.
Security Misconfigurations: CI/CD environments are intricate, involving multiple interconnected systems. That means there are more opportunities for misconfiguration whether in CI/CD tools or deployment settings. Common issues include open ports, weak permissions, and insecure defaults, which attackers can leverage to compromise pipeline security

Exploiting Misconfigured Cloud Storage

In October 2017, data analytics firm Alteryx experienced a significant data breach, exposing sensitive information on approximately 123 million U.S. households. The breach was discovered by cybersecurity firm UpGuard, which found that an Amazon Web Services (AWS) S3 storage bucket owned by Alteryx was left unsecured, allowing anyone with an AWS account to access its contents. The exposed data, sourced from Experian and the U.S. Census Bureau, included 248 data fields per household, such as addresses, phone numbers, estimated income, and mortgage information.

Misconfigured cloud storage, such as AWS S3 buckets, Azure Blob Storage, or Google Cloud Storage, is a common entry point for attackers. If improperly configured, these storage services can expose sensitive data, credentials, or even allow remote code execution. Here’s how attackers typically exploit these misconfigurations:

Publicly Accessible Storage Buckets

Misconfiguration: Buckets are set to “public” access, allowing anyone on the internet to list, read, or write data.
Exploitation:
- Attackers scan for open buckets using tools like AWSBucketDump or GrayhatWarfare.
- Extract sensitive data like credentials, API keys, or personal information.
- Inject malicious files (e.g., JavaScript for drive-by downloads).

Improper IAM Permissions

Misconfiguration: Weak IAM policies allowing excessive permissions to users or roles.
Exploitation:
- Privilege escalation via excessive permissions (e.g., s3:PutBucketPolicy).
- Creating new policies or modifying existing ones to gain broader access.
- Using stolen IAM credentials to manipulate cloud storage.

Lack of Encryption & Data Leakage

Misconfiguration: Data stored without encryption or encryption keys exposed in public repositories.
Exploitation:
- Attackers access unencrypted sensitive data.
- Use leaked encryption keys (often found in GitHub repositories or exposed logs)

Versioning & Deleted Files Exposure

Misconfiguration: Storage bucket versioning enabled but not properly secured.
Exploitation:
- Attackers recover previous versions of deleted files.
- Extract credentials or old backups containing sensitive data.

Abusing Default Configurations and Credentials

Many cloud services are deployed with default configurations and credentials to simplify initial setup. However, if these defaults are not modified, they can pose significant security risks. Attackers often exploit these unaltered settings to gain unauthorized access to systems and data.

In a Trend Micro research publication titled ‘Supply Chain Attacks in the Age of Cloud Computing: Risks, Mitigations, and the Importance of Securing Back Ends‘, a detailed explanation is provided on how default configurations in Jenkins, Docker, and Kubernetes are exploited by threat actors.

Default configurations in widely-used services like Jenkins, Docker, and Kubernetes pose significant security risks if not properly secured. Attackers often exploit these default settings to gain unauthorized access or execute malicious code within an organization’s infrastructure.

Jenkins, a popular open-source automation server, can be vulnerable when default configurations are left unchanged. By default, Jenkins allows build jobs to execute on the primary server, which can be exploited by less-privileged users to overtake the Jenkins instance, leading to potential leakage of secrets, job configurations, and source code.

Docker containers rely on configuration files, such as Dockerfiles, to define application environments. If these files are exposed or contain insecure default settings, they can reveal sensitive information, including environment variables with API keys or database credentials. Attackers can exploit this information to compromise the containerized applications or the host system.

Kubernetes, a leading container orchestration platform, can be susceptible to attacks if default configurations are not properly secured. For instance, exposed Kubernetes dashboards without authentication can provide attackers with administrative access to the cluster. Additionally, default settings may allow for excessive permissions, enabling unauthorized users to deploy malicious containers or access sensitive data.

Conclusion

Cloud supply chain attacks present a significant and growing threat in the digital landscape. These attacks exploit vulnerabilities within the interconnected ecosystem of cloud services, third-party vendors, software dependencies, and infrastructure components. The techniques explored in this blog target weak links in the supply chain, compromising the security, integrity, and availability of cloud-based systems, often with far-reaching consequences.

In Part 3, we will explore detection and mitigation strategies that organizations can adopt to protect against cloud supply chain attacks.

Breaking The Chain: How Threat Actors Exploit Supply Chains in Major CSPs