New Bucket Hijacking Attack Allows Hackers to Reroute Cloud Data Streams to External Storage

A critical cloud storage attack technique dubbed “bucket hijacking” a method that enables threat actors to silently redirect an organization’s active cloud data streams, including audit logs and telemetry, into attacker-controlled external storage buckets across major cloud platforms.

The technique has been confirmed to affect Google Cloud, Amazon Web Services (AWS), and Microsoft Azure, with all three providers notified through responsible disclosure.

While no real-world threat actor has been observed exploiting this technique yet, researchers warn that detection would be extremely difficult once deployed.

The attack exploits a fundamental architectural flaw rooted in the global uniqueness of cloud storage bucket names. Because no two users can register an identical bucket name within a provider’s namespace, the identity of a destination storage bucket is tied to its name alone, not to a specific account owner.

An attacker who compromises a cloud environment and gains bucket deletion permissions can execute the attack in a straightforward sequence:

1. Delete the target organization’s active storage bucket.
2. Immediately recreate a new bucket using the identical name within an attacker-controlled account.
3. The original data stream, whether a Google Cloud logging sink, AWS S3 replication rule, or Azure Monitor diagnostic export, continues operating autonomously and begins writing data directly into the attacker’s bucket.

The attack is particularly dangerous because it is self-sustaining. Once the hijack is complete, the legitimate sink or replication configuration continues to appear valid upon inspection, generating no obvious error states and triggering no native alerts. Logs, metrics, and sensitive telemetry flow silently into the attacker’s environment indefinitely.

New Bucket Hijacking Attack

Unit 42 successfully simulated bucket hijacking across multiple services on each major provider:

• Google Cloud: Confirmed on Cloud Logging sinks, Pub/Sub subscriptions with Cloud Storage destinations, and Storage Transfer Service jobs. Required permissions: storage.buckets.delete and storage.objects.delete
• AWS: Confirmed on S3 bucket replication and Amazon Data Firehose pipelines targeting S3 destinations
• Azure: Demonstrated as a cross-subscription attack via Azure Monitor diagnostic settings; limited to same-tenant scope due to platform-enforced name reuse delays

Researchers highlighted that broad storage administration roles commonly assigned in enterprise environments dramatically increase exposure.

In Google Cloud, the standard Storage Admin role grants storage.buckets.delete by default, bypassing the more restrictive logging.sinks.update permission that would be required to legitimately reconfigure a data stream. This effectively allows attackers to reroute data streams without ever touching stream configurations directly.

Unit 42 recommends a two-pronged defense strategy combining least-privilege access controls and proactive monitoring:

• Restrict deletion permissions (storage.buckets.delete, DeleteBucket, Microsoft.Storage/storageAccounts/delete) to the minimum required administrative roles
• Enforce data perimeter controls — AWS Service Control Policies (SCPs) or Google Cloud VPC Service Controls — to block writes to buckets outside the trusted organizational boundary
• Enable AWS account-regional S3 namespaces to scope bucket names to specific accounts and regions, directly eliminating the hijacking vector
• Deploy high-priority monitoring alerts for storage bucket deletion API calls, particularly on buckets holding sensitive or regulated data

Unit 42 highlighted that this technique is not limited to the three providers tested. Any cloud platform relying on globally unique, statically named storage resources for data stream routing could be vulnerable to the same methodology.

The research reinforces that shared design philosophies across cloud providers mean a flaw discovered in one ecosystem can serve as a direct blueprint for exploiting another, a critical reminder for security teams managing multi-cloud environments.

🔒 CISO / Security Leader: Your Next Breach May Not Have a Face: Join the “Ghost in the Machine” LIVE webinar with ISC2