Cloud-to-Cloud Attack Paths: How Threats Traverse

📅 September 24, 2026  |  🏷 General  |  Cyber Security, Information Security, Threat Management

A threat actor compromised a mid-sized financial services firm last year without ever touching their on-premises network. The entry point was a forgotten OAuth token embedded in a CI/CD pipeline — one that granted write access to an Azure storage blob. From there, the attacker pivoted to a connected AWS S3 bucket via a misconfigured cross-account IAM role, exfiltrated 4.2 million customer records, and was gone before a single alert fired. The organization had invested heavily in endpoint detection and network segmentation. None of it mattered, because the entire attack lived inside the cloud control plane.

Cloud-to-cloud attack paths represent one of the most consequential and underexamined threat vectors in enterprise security today. Unlike traditional lateral movement, which security teams have spent decades hardening against, cloud-to-cloud traversal exploits the trust relationships that organizations deliberately build between SaaS platforms, IaaS environments, and cloud-native services. The attacker doesn’t need to compromise a host. They need to compromise an identity — and in a world of federated access, that identity may unlock dozens of interconnected systems simultaneously.

Understanding the Cloud-to-Cloud Attack Surface

The modern enterprise operates across an average of 4.2 distinct cloud providers, according to the 2026 Flexera State of the Cloud Report. Each connection between those providers — every API integration, OAuth grant, federated identity relationship, or shared data pipeline — represents a potential traversal point for a threat actor who has gained a foothold anywhere in the ecosystem.

The fundamental challenge is architectural. Cloud environments are designed for connectivity. SaaS applications integrate natively with identity providers; IaaS platforms expose APIs that federate with dozens of partner services; data warehouses pull from multiple cloud storage tiers across provider boundaries. Every one of these integrations is a design feature that becomes a security liability when trust is misconfigured, over-permissioned, or stolen.

The Trust Relationship Problem

Cloud-to-cloud attack paths almost always exploit legitimate trust relationships rather than exploiting software vulnerabilities. An attacker who steals a service account credential from a compromised Google Cloud workload may find that the same account is trusted by a connected Salesforce instance, which in turn has write access to an AWS data lake via an ETL pipeline. The blast radius of a single stolen credential can span three providers and multiple data classification tiers, all without triggering traditional network-based detection.

This is categorically different from traditional network lateral movement. When an attacker moves from one on-premises system to another, they generate network traffic that can be detected, segmented, and blocked. When they move from one cloud service to another via an API call, the traffic looks identical to legitimate service-to-service communication. The difference is purely contextual — and context-aware detection in multi-cloud environments remains a largely unsolved problem for most organizations.

OAuth and API Token Abuse

OAuth tokens and API keys are the currency of cloud-to-cloud connectivity, and they are systematically abused. A 2025 study by GitGuardian found that 12.8 million API secrets were exposed in public GitHub repositories that year alone — a figure that represents only detected exposure. Tokens embedded in container images, configuration files, CI/CD pipeline definitions, and Infrastructure-as-Code templates create a sprawling attack surface that most organizations cannot fully inventory, let alone monitor.

The specific danger of OAuth is that tokens often carry persistent, broad permissions long after their original use case has expired. A developer who authorized a third-party analytics tool six months ago may have granted it read access to the entire Google Workspace directory. If that tool is later compromised — or simply abandoned and its token never revoked — an attacker gains a legitimate-looking entry point into the organization’s identity infrastructure.

Anatomy of a Cloud-to-Cloud Attack Chain

Dissecting real-world cloud-to-cloud intrusions reveals a consistent pattern: initial access via credential theft or misconfiguration, followed by systematic enumeration of connected services, privilege escalation through over-permissioned roles, and lateral movement to higher-value targets across provider boundaries.

The 2025 Scattered Spider campaign — which targeted multiple telecommunications and hospitality organizations — demonstrated this pattern at scale. The threat group used social engineering to steal Okta session tokens, then used those tokens to authenticate to AWS management consoles, pivot into connected Azure Active Directory tenants through cross-tenant synchronization, and ultimately access cloud-hosted VoIP infrastructure. The entire kill chain spanned four distinct cloud platforms and was executed within 72 hours of initial credential theft.

Privilege Escalation Across Provider Boundaries

One of the most dangerous capabilities available to cloud-to-cloud attackers is the ability to escalate privileges across provider boundaries. A low-privilege service account in one cloud environment may have the ability to assume a high-privilege role in another through a cross-account trust policy. In AWS, for example, an attacker who compromises a workload with sts:AssumeRole permissions can potentially pivot to any AWS account that has established a trust relationship with that workload’s role — including accounts in entirely different organizational units.

Microsoft’s research team documented this specific technique in their 2026 Cloud Threat Intelligence Report, identifying “cross-tenant privilege escalation” as one of the top three cloud attack techniques observed across their customer base. Threat actors specifically search for Entra ID (formerly Azure AD) guest accounts that have been granted elevated permissions in target tenants — a configuration that is far more common than most security teams realize.

Data Exfiltration via Cloud-Native Services

Cloud-to-cloud attackers rarely need to exfiltrate data to external infrastructure. Instead, they abuse cloud-native data transfer services to move sensitive information to attacker-controlled cloud accounts — a technique that makes traditional network-based DLP controls completely ineffective. An attacker with AWS S3 access can simply replicate a bucket to a different AWS account using S3 Replication. A threat actor with Google BigQuery access can export datasets directly to a Google Cloud Storage bucket in a separate project. The traffic never leaves the cloud provider’s network, bypassing perimeter controls entirely.

Detection Challenges in Multi-Cloud Environments

The core detection problem in cloud-to-cloud attacks is log fragmentation. Each cloud provider generates its own audit logs in its own format, stored in its own logging service, with its own retention policies and access controls. Correlating CloudTrail events from AWS with Unified Audit Log entries from Microsoft 365, GCP Cloud Audit Logs, and Okta System Logs to reconstruct a multi-cloud attack chain requires either a highly mature SIEM implementation or a dedicated Cloud Detection and Response (CDR) platform — and even then, correlation logic must be purpose-built for cloud-to-cloud pivot patterns.

A 2026 survey by ESG Research found that only 31% of enterprise security teams reported “high confidence” in their ability to detect lateral movement between cloud providers. The remaining 69% either lacked visibility into cross-cloud activity entirely or could only detect such movement after-the-fact through manual log review.

The Identity Blind Spot

Traditional SIEM solutions were built around network-centric data models. They excel at correlating firewall logs, IDS alerts, and endpoint telemetry. They struggle fundamentally with identity-centric cloud telemetry, where the most meaningful signals are not packets but permission grants, role assumptions, and token issuances. Cloud-to-cloud attack paths generate rich identity telemetry — but extracting signal from that telemetry requires behavioral baselines for service-to-service communication that most organizations have never built.

The practical implication: an attacker assuming a cloud role from an unusual geographic location at an unusual time may generate a detectable anomaly if behavioral baselines exist. In most environments, they do not. The role assumption succeeds silently, the CloudTrail log is written, and no alert fires.

Defensive Architecture for Cloud-to-Cloud Threat Mitigation

Effective defense against cloud-to-cloud attack paths requires rethinking security architecture around identity rather than network perimeter. The specific controls that matter most are not traditional security tools — they are identity hygiene practices, cloud configuration standards, and behavioral detection capabilities that most organizations are only beginning to mature.

Cloud Infrastructure Entitlement Management (CIEM)

Cloud Infrastructure Entitlement Management platforms provide continuous visibility into identity permissions across multi-cloud environments, identifying over-permissioned accounts, unused permissions, and dangerous cross-account trust relationships. Gartner identified CIEM as a critical security capability in its 2025 Cloud Security Hype Cycle, projecting that 60% of enterprises would adopt dedicated CIEM tooling by 2027.

In practice, CIEM provides three critical capabilities for cloud-to-cloud threat mitigation: permission baseline analysis (identifying what permissions exist versus what permissions are actually used), entitlement graph visualization (mapping the full blast radius of any compromised identity across cloud providers), and policy remediation recommendations (generating least-privilege replacements for over-permissioned roles). Organizations that have deployed CIEM report reducing their effective cloud attack surface by 40–60% through permission right-sizing alone, according to Ermetic’s 2025 State of Cloud Security report.

Zero Trust for Service-to-Service Communication

Applying Zero Trust principles to cloud-to-cloud communication requires moving beyond perimeter-based trust models and implementing workload identity frameworks that authenticate and authorize every service-to-service API call contextually. SPIFFE (Secure Production Identity Framework for Everyone) and its implementation SPIRE provide cryptographic workload identity that travels with the workload regardless of where it runs — enabling context-aware authorization decisions that are not dependent on network location.

Practically, this means replacing long-lived API keys and service account passwords with short-lived, cryptographically verifiable workload credentials that expire within minutes. An attacker who steals a SPIFFE SVID (SPIFFE Verifiable Identity Document) has a credential with a maximum 15-minute validity window. The traditional OAuth token they might otherwise steal could remain valid for months. This asymmetry dramatically increases the cost of credential-based cloud-to-cloud attacks.

Regulatory and Compliance Implications

Cloud-to-cloud attack paths create specific compliance complications that extend beyond the direct security impact of a breach. When sensitive data traverses multiple cloud providers through automated pipelines and integrations, the question of data custody and breach notification becomes significantly more complex.

Under GDPR Article 33, organizations have 72 hours to notify supervisory authorities following discovery of a personal data breach. When a breach involves data that has been exfiltrated via cloud-to-cloud mechanisms — potentially without leaving any infrastructure the organization directly controls — accurately scoping the breach and identifying affected data subjects within that window becomes extraordinarily difficult. The Salesforce-to-AWS-to-attacker-controlled-GCS scenario is not hypothetical; it represents a growing class of breach that compliance teams are structurally unprepared to handle.

Shared Responsibility Gaps in Cross-Cloud Scenarios

Each major cloud provider operates under a shared responsibility model that clearly delineates provider responsibility versus customer responsibility. What the shared responsibility model does not address is the space between providers — the integration layer where SaaS applications connect to IaaS platforms, where federated identity relationships span provider boundaries, and where data flows across cloud service agreements. This inter-cloud responsibility gap is owned entirely by the customer, with no provider-level security controls, SLA commitments, or breach liability. Organizations that have not explicitly mapped this gap in their cloud security architecture are accepting undefined risk.

Key Takeaways

• Cloud-to-cloud attack paths exploit trust relationships, not software vulnerabilities. Attackers leverage legitimate OAuth tokens, API keys, and federated identity relationships to traverse cloud provider boundaries. Traditional vulnerability management does not address this threat surface.
• Log fragmentation is the primary detection barrier. Without purpose-built correlation logic across multi-cloud audit telemetry, cloud-to-cloud lateral movement is effectively invisible to conventional SIEM platforms.
• Over-permissioned identities are the root cause in the majority of cloud-to-cloud intrusions. CIEM tools that continuously right-size cloud permissions represent the highest-leverage preventive control available today.
• Short-lived credentials are a structural defense. Replacing long-lived API keys and OAuth tokens with cryptographically verifiable, short-lived workload identity credentials (SPIFFE/SPIRE or equivalent) dramatically reduces the value of credential theft to attackers.
• The inter-cloud responsibility gap is yours to own. Neither AWS, Azure, nor Google Cloud is responsible for securing the integration layer between their platforms. Explicit architectural ownership of cross-cloud data flows and trust relationships is a non-negotiable security requirement.

Conclusion: Building a Cloud-to-Cloud Security Program

Cloud-to-cloud attack paths will become increasingly prevalent as enterprise cloud adoption deepens and multi-cloud architectures become the operational norm. The threat is not theoretical — it is actively being exploited by sophisticated threat actors who understand that the control plane is now the network, and that identity is now the perimeter.

The organizations that will successfully defend against this threat class share three characteristics: they have complete visibility into their cross-cloud identity relationships and permission structures; they have deployed behavioral detection capabilities tuned specifically for cloud-to-cloud lateral movement patterns; and they have implemented least-privilege access models enforced by automated tooling rather than manual review.

Start with a cross-cloud entitlement audit. Map every service account, OAuth grant, API key, and federated trust relationship that crosses a cloud provider boundary in your environment. Score each relationship by blast radius — what is the maximum damage an attacker could cause if this specific identity were compromised? Prioritize remediation by blast radius, not by perceived likelihood of compromise. Then instrument your SIEM or CDR platform with detection logic specifically designed for the cloud-to-cloud pivot patterns documented in this post.

The attack path through your environment already exists. The question is whether you map it first, or whether a threat actor does.