One Architectural Sin, Two Clouds, and a Universal Attack Technique for Data Hijacking

One Architectural Sin, Two Clouds, and a Universal Attack Technique for Data Hijacking

Speakers: Yahav (Cloud Security Researcher, Palo Alto Networks)

Conference: fwd:cloudsec

YouTube: https://www.youtube.com/watch?v=PYjYK-0AqX4

Overview

In this fwd:cloudsec talk, Yahav Fessinger, a Cloud Security Researcher at Palo Alto Networks, unveiled a simple yet profoundly impactful attack technique capable of hijacking critical cloud data. Titled "One Architectural Sin, Two Clouds, and a Universal Attack Technique for Data Hijacking," the presentation delved into a fundamental architectural flaw common across major cloud providers: the global uniqueness of cloud storage bucket names coupled with the lack of robust ownership validation by services configured to route data to these buckets. The core premise is chillingly straightforward: an attacker with the ability to delete a victim's storage bucket can immediately recreate a new bucket with the exact same name in their own environment, thereby redirecting ongoing data streams – such as logs, messages, or replicated backups – to their control without any visible configuration change on the victim's side.

Yahav’s research demonstrates how this "architectural sin" is not isolated to a single service or cloud provider but represents a universal attack vector. He showcased successful simulations across Google Cloud Platform (GCP) services like Cloud Logging, Pub/Sub, and Storage Transfer Service, as well as Amazon Web Services (AWS) S3 bucket replication. The talk not only exposes this widespread vulnerability but also proposes a new cloud resource methodology rooted in understanding common architectural concepts across different cloud environments. For cloud defenders, this research highlights the critical importance of data perimeters and sophisticated detection strategies that move beyond simple event monitoring.

Background

▶ Watch: The core problem: data redirection attack (0:30)

The genesis of this research began with an investigation into attack techniques targeting cloud logging services, which are foundational components in any cloud environment. Each major cloud provider offers its own implementation: AWS has CloudTrail, GCP features Cloud Logging, and Azure provides Azure Monitor. These services are designed to collect comprehensive logs from a cloud environment, capturing every operation and event.

A key component within these logging services, particularly in GCP Cloud Logging, is the sync. A sync acts as a router, responsible for forwarding logs to various destinations. These destinations can include log buckets (optimized for real-time indexing), Pub/Sub topics (for asynchronous communication), BigQuery tables (for massive data storage and analysis), or crucially, GCS buckets (Google Cloud Storage buckets).

The critical characteristic underpinning this vulnerability lies in the design of cloud storage services themselves. AWS S3, GCP GCS, and Azure Storage Accounts all enforce a policy of global uniqueness for bucket/storage account names. This means that if a user creates a bucket named my-unique-log-storage, no other user, anywhere in the world, can create another bucket with that exact same name. This design decision, while seemingly innocuous and intended to simplify resource identification, becomes the "architectural sin" when combined with how certain cloud services reference these storage destinations. The problem arises because many routing services, such as a logging sync, rely solely on the bucket name to identify their destination, rather than a more robust identifier that incorporates resource ownership or a unique ID that persists beyond deletion. This reliance on a globally unique, yet recyclable, name creates a window of opportunity for attackers.

Key Findings

▶ Watch: Crucial concept: global uniqueness of bucket names (3:50)

The central discovery of Yahav's research is the universal data hijacking technique enabled by the combination of globally unique, recyclable bucket names and the lack of robust ownership validation by data routing services. The main findings can be summarized as follows:

1. Name-Based Resolution, Not Ownership: Cloud services configured to route data (e.g., logging sinks, Pub/Sub subscriptions, S3 replication rules) primarily resolve their target destinations based on the name of the storage bucket, not its underlying unique identifier or ownership. This means if a bucket with a specific name is deleted and then recreated with the same name in a different account, the routing service will seamlessly redirect data to the new, attacker-controlled bucket.
2. Bypassing Update Permissions: An attacker who gains sufficient permissions to delete a victim's bucket can effectively bypass the need for specific "update" permissions (e.g., logging.sinks.update, pubsub.subscriptions.update, storagetransfer.jobs.update) that would normally be required to modify the destination of a data stream. By deleting and re-creating the bucket, the attacker achieves the same outcome – redirecting data – using a different, potentially less monitored, permission. Yahav aptly described this as "one permission to rule them all."
3. Broad Impact Across Services and Clouds: The vulnerability is not confined to a single service or cloud provider. It was successfully demonstrated across multiple GCP services (Cloud Logging, Pub/Sub, Storage Transfer Service) and AWS (S3 bucket replication). This indicates a systemic architectural flaw rather than an isolated bug.
4. Stealthy Data Exfiltration: From the perspective of the legitimate routing service, no configuration change occurs. The sync, subscription, or replication rule still points to victim-log-storage, unaware that this name now maps to an attacker's resource. This makes the attack highly stealthy, as the victim's console or API calls would show no alteration to the service's configuration.
5. Azure's Nuance: While the architectural principle of globally unique storage account names exists in Azure, the practical feasibility of this specific attack is hindered by Azure's policy of delaying the re-availability of a deleted storage account name for several days. This makes immediate name squatting, a critical component of the attack, significantly more difficult or detectable.
6. A Universal Blueprint: The research proposes that this attack technique represents a blueprint for other attack vectors. The core components are a "resource with a globally unique ID" (like a bucket) and a "router resource" that references it, leading to an "impact" (like data exfiltration). By varying these components, new attack possibilities might emerge.

Technical Deep Dive

▶ Watch: The attack theory: hijacking logs via bucket deletion (4:15)

The technical foundation of this attack hinges on the inherent design of cloud storage and data routing services. Yahav systematically demonstrated this across various scenarios.

GCP Cloud Logging Hijack

The initial discovery and proof-of-concept centered on GCP Cloud Logging. As mentioned, Cloud Logging uses sinks to route logs to various destinations, including GCS buckets. The attack flow is as follows:

1. Initial Setup: A legitimate GCP project has a Cloud Logging sync configured to export critical logs to a GCS bucket, e.g., victim-log-storage, located within the victim's project.
2. Attacker Prerequisite: An attacker gains access to the victim's project with permissions to delete GCS buckets (e.g., storage.buckets.delete). This is the critical initial compromise.
3. Deletion: The attacker deletes the victim-log-storage bucket.
4. Name Squatting: Crucially, immediately after deletion, the attacker creates a new GCS bucket with the exact same name, victim-log-storage, but this time in their own attacker-controlled GCP project.
5. Data Redirection: The existing Cloud Logging sync, still configured to send logs to victim-log-storage, continues its operation. However, because GCS bucket names are globally unique and the original bucket no longer exists, the name victim-log-storage now resolves to the attacker's newly created bucket. The sync, unaware of the ownership change, begins streaming all subsequent logs directly to the attacker's environment.
6. Stealth: The Cloud Logging sync's configuration itself shows no change. It still points to victim-log-storage. There's no indication within the sync's settings that the underlying resource ownership has changed, making this a highly stealthy exfiltration channel. Yahav noted that this process must occur quickly to avoid the sync identifying a prolonged period of the bucket being absent, which could trigger alerts. Even if an alert is triggered, the sync would likely resume routing once the bucket reappears under the same name.

Expanding to Other GCP Services

Yahav extended the same technique to other GCP services that exhibit a similar "router" pattern referencing GCS buckets:

• Google Cloud Pub/Sub Subscriptions: Pub/Sub is a messaging service for asynchronous communication. A subscription can be configured to deliver messages to various endpoints, including a GCS bucket. By applying the same delete-and-recreate technique on a target GCS bucket for a Pub/Sub subscription, the attacker can hijack the stream of messages intended for the victim.
• Google Cloud Storage Transfer Service Jobs: This service is designed to manage and automate data transfers from external sources (other clouds, on-prem) to GCS buckets, often for archival or backup purposes. A transfer job defines the source and destination. If the destination GCS bucket is compromised via name squatting, the attacker gains access to all incoming backup or archival data. A particularly insidious aspect here is that backup destinations are often inspected less frequently, making this attack potentially long-lasting and undetected.

In all these GCP cases, the core vulnerability remained consistent: the service's reliance on the globally unique bucket name for resolution, without sufficient validation of the bucket's current ownership.

AWS S3 Bucket Replication

Recognizing that the "architectural sin" of globally unique names extends to AWS S3, Yahav simulated the attack using S3 bucket replication. This feature automatically replicates objects from a source S3 bucket to a destination S3 bucket.

1. Initial Setup: A legitimate S3 bucket in the victim's AWS account is configured with a replication rule to send objects to a destination S3 bucket, e.g., victim-replicated-storage, also within the victim's account.
2. Attacker Prerequisite: The attacker gains permissions to delete S3 buckets in the victim's account.
3. Deletion & Squatting: The attacker deletes victim-replicated-storage and immediately recreates an S3 bucket with the identical name, victim-replicated-storage, in their own AWS account.
4. Data Redirection: When new objects are uploaded to the source bucket in the victim's account, the replication rule, still pointing to victim-replicated-storage, will now replicate these objects to the attacker's bucket. Yahav confirmed this by uploading an object and observing its appearance in the external, attacker-controlled bucket.

This demonstration solidified the idea that the underlying flaw is cloud-agnostic, rooted in a common architectural pattern.

The Azure Exception

While Azure also enforces globally unique names for its Storage Accounts, Yahav noted a critical difference that impacts the practical feasibility of this specific name-squatting attack. Unlike AWS and GCP, Azure typically makes a deleted storage account name unavailable for re-use for several days. This delay prevents an attacker from immediately squatting on the name, making the attack less stealthy and more prone to detection or failure due to the target resource being genuinely absent for an extended period. Yahav also indicated some preliminary findings suggesting that in specific Azure services, the "router" resource might honor resource ownership rather than just the name, though this requires further investigation.

The Attack Blueprint

Yahav concluded the technical deep dive by generalizing the attack into a blueprint:

• Resource with Global Unique ID: An entity like a GCS bucket, S3 bucket, or Azure Storage Account, whose name is globally unique and can be recycled after deletion.
• Router Resource: A service component (e.g., Cloud Logging sync, Pub/Sub subscription, S3 replication rule, Storage Transfer Service job) that is configured to send data to the globally unique resource and relies primarily on its name for resolution.
• Impact: The consequence of the redirection, such as data exfiltration, service disruption, or data corruption.

This blueprint suggests that by identifying other services that fit this model, new attack vectors could be discovered, encouraging further research into this architectural pattern.

Demo / Proof of Concept

▶ Watch: Sync relies on name, not ownership; no configuration change (5:45)

The talk heavily relied on a series of simulated attacks to demonstrate the vulnerability across different cloud services and providers. While no live, real-time "demo" video was explicitly played for every scenario during the presentation (though Yahav mentioned a video for AWS was not shown but the results were observed), the methodology and observed outcomes constituted robust proofs of concept.

For GCP Cloud Logging, Yahav detailed the steps:

1. An existing Cloud Logging sync was configured to export logs to a GCS bucket within the victim's project.
2. The target GCS bucket was deleted.
3. Immediately after deletion, a new GCS bucket was created with the exact same name in an attacker-controlled project (outside the victim's organization).
4. After a short waiting period, logs were observed streaming to the external, attacker-controlled bucket, confirming the redirection.

Similar simulations were conducted for other GCP services:

• Google Cloud Pub/Sub: A subscription targeting a GCS bucket in the victim's project was set up. The target bucket was deleted and a new one with the same name recreated in the attacker's project. Data was then observed flowing to the attacker's bucket.
• Google Cloud Storage Transfer Service: A transfer job configured to send data to a GCS bucket was used. Following the same deletion and name-squatting procedure, data intended for the victim's archival bucket was redirected to the attacker's bucket.

For AWS S3 Replication, the process was also simulated:

1. A replication rule was preconfigured to replicate data from a source S3 bucket to a destination S3 bucket in the victim's AWS account.
2. The destination S3 bucket was deleted.
3. An S3 bucket with the identical name was immediately recreated in an external, attacker-controlled AWS account.
4. An object was uploaded to the source bucket, and after a short delay, it was observed to be replicated to the attacker's S3 bucket, demonstrating successful data hijacking.

In each proof-of-concept, the key observation was that the "router" resource (sync, subscription, job, replication rule) continued to function as if nothing had changed from its configuration perspective, yet the data was undeniably flowing to the attacker's environment. Yahav specifically noted that for the Cloud Logging scenario, the deletion and recreation had to be performed quickly to avoid the sync from identifying a prolonged absence of its target bucket, which could potentially trigger an alert. However, even in such cases, the sync would re-establish the connection to the new bucket once it reappeared under the same name.

Defensive Implications

▶ Watch: Expanding attack to other services like Pub/Sub (7:05)

Understanding this universal attack technique is crucial for cloud defenders. The implications demand a multi-layered defensive strategy focusing on both prevention and detection.

Prevention: Enforcing Data Perimeters

The most robust preventative measure against this type of attack is the implementation of data perimeters. These controls fundamentally restrict network access and resource interaction, ensuring that sensitive data and services cannot communicate with or be accessed from outside defined organizational boundaries.

• AWS Data Perimeter: AWS offers features and best practices to implement a data perimeter, primarily through a combination of Service Control Policies (SCPs), VPC Endpoints, and S3 Bucket Policies. SCPs can restrict actions that allow data exfiltration to external accounts. VPC Endpoints ensure that traffic to AWS services like S3 or CloudTrail stays within the AWS network and can be controlled by VPC security groups and network ACLs. By enforcing a data perimeter, even if an attacker manages to squat on a bucket name in their own account, the victim's routing services (e.g., S3 replication) would be prevented from writing to that external bucket because the perimeter controls would block cross-account access.
• GCP VPC Service Controls (VPC SC): GCP's answer to data perimeters is VPC Service Controls. This service allows organizations to define security perimeters around their cloud resources (like GCS buckets, Cloud Logging, Pub/Sub) and restrict data movement across these boundaries. If a VPC SC perimeter is in place, and a Cloud Logging sync attempts to write to a GCS bucket that, due to name squatting, is now located outside the defined perimeter (i.e., in an attacker's project), the request will be blocked. This prevents unauthorized data exfiltration, even if the name-based redirection occurs.

Yahav emphasized that while data perimeters are highly effective, they can be complex to implement, especially for large organizations with existing infrastructure, and may require careful planning to avoid disrupting legitimate workflows.

Detection: Correlating Anomalous Activities

For organizations where implementing a full data perimeter is challenging or as a complementary control, robust detection mechanisms are essential. The primary challenge with detecting this attack is that the core event – bucket deletion – is often noisy. Buckets are frequently deleted as part of normal operations, development, or cleanup. Alerting on every bucket deletion would generate an overwhelming number of false positives.

To overcome this, Yahav proposed a correlation-based detection strategy:

1. Base Event: Bucket Deletion: Start with the audit log event for storage.buckets.delete (GCP) or DeleteBucket (AWS S3). This is the initial trigger.
2. Contextual Insight: Data Sensitivity: Correlate the bucket deletion event with findings from a Data Security Posture Management (DSPM) solution. A DSPM tool can identify buckets containing sensitive data (e.g., PII, financial data, access keys). By focusing only on deletions of high-risk buckets, the noise can be significantly reduced, and alerts can be prioritized.
3. Identity Analytics: Anomalous Behavior: Further refine the detection by incorporating Identity Analytics. Look for anomalous activity related to the identity performing the bucket deletion. This could include:

• An identity that has never accessed or deleted this specific bucket before.
• An identity performing this action outside its usual operating hours or from an unusual geographic location.
• An identity with elevated privileges being used for an unexpected action.
• An identity that has not been active for a long period suddenly performing a bucket deletion.

By combining these three data points – a bucket deletion, targeting a sensitive bucket, performed by an anomalous identity – defenders can generate a high-priority, meaningful alert that indicates potential malicious activity, allowing security teams to investigate and respond effectively. This approach moves beyond simple rule-based alerting to leverage contextual and behavioral analytics.

Key Takeaways

• Universal Architectural Flaw: A single architectural decision – the global uniqueness and recyclability of cloud storage bucket names combined with services relying solely on these names for routing – creates a widespread vulnerability across multiple cloud services and providers.
• Cloud-Agnostic Mindset for Research: Different cloud providers, despite their unique branding, often share common architectural patterns and design decisions. A deep understanding of these common concepts enables researchers to identify and predict vulnerabilities across different cloud environments more effectively.
• "One Permission to Rule Them All": The ability to delete a storage bucket can be leveraged by attackers to bypass other, typically more privileged, permissions required to modify data routing configurations, effectively hijacking data streams.
• Proactive Prevention with Data Perimeters: Implementing strong data perimeters (e.g., AWS Data Perimeter, GCP VPC Service Controls) is the most effective preventative measure against this type of data exfiltration, as it restricts communication with external, attacker-controlled resources.
• Sophisticated Detection for Noisy Events: Detecting this attack requires moving beyond basic event monitoring. Correlating bucket deletion events with data sensitivity (via DSPM) and anomalous identity behavior (via identity analytics) is crucial for generating high-fidelity alerts.
• Blueprint for Future Attacks: The identified pattern of "Globally Unique ID Resource + Router Resource = Impact" serves as a blueprint for discovering other potential attack vectors within cloud environments.

About the Speaker(s)

Yahav Fessinger is a Cloud Security Researcher at Cortex Cloud, a division of Palo Alto Networks. With six years of dedicated experience in cloud security research, Yahav's work focuses on identifying novel attack vectors in real-time. He specializes in leveraging behavior analytics to pinpoint and understand malicious activities within cloud environments. His presentation at fwd:cloudsec exemplifies his commitment to uncovering fundamental security challenges that span across different cloud providers.