Cloud Bucket Hijacking Technique Lets Attackers Reroute Logs and Sensitive Data

A critical cloud storage attack technique that exploits a fundamental architectural flaw shared across major cloud service providers (CSPs), including Google Cloud, Amazon Web Services (AWS), and Microsoft Azure.

The technique, dubbed bucket hijacking, enables attackers to silently redirect active data streams, including audit logs and sensitive telemetry, into attacker-controlled storage environments.

Palo Alto Networks’ Unit 42 researchers found that the attack capitalizes on a design characteristic common to all major cloud providers: globally unique bucket names.

Cloud Bucket Hijacking Technique

Because no two accounts can hold the same bucket name simultaneously, an attacker who gains permission to delete a target bucket can immediately recreate it under their own account using the identical name.

Any data streams, such as logging sinks, replication pipelines, or transfer jobs, that previously routed data to that bucket will continue to do so autonomously, now delivering sensitive data directly to the attacker.

This creates what Unit 42 researchers describe as a global namespace risk, where a storage destination’s identity is tied to its name alone rather than to an immutable account owner.

The attack begins when an adversary compromises a cloud environment and obtains the permissions required to delete a target bucket. Once the original bucket is deleted, the attacker immediately recreates a new bucket with the same name in their own account.

Because existing data stream configurations remain intact and continue routing autonomously, logs, audit events, and sensitive objects are silently and continuously delivered directly into the attacker’s environment.

A particularly dangerous aspect of this technique is its stealth. Because the data stream continues operating normally, the sink or replication configuration appears valid upon inspection, making the compromise extremely difficult to detect until significant data exfiltration has already occurred.

Unit 42 confirmed the attack across multiple services and providers:

• Google Cloud: Successfully simulated hijacking via Cloud Logging sinks, Pub/Sub subscriptions, and Storage Transfer Service jobs. Required permissions were limited to storage.buckets.delete and storage.objects.delete far less privileged than the granular logging.sinks.update permission typically associated with stream modification.
• AWS: Replicated the technique using S3 bucket replication and Amazon Data Firehose. Objects written to a source bucket were automatically replicated into the externally controlled destination bucket after name reclamation.
• Azure: Demonstrated a cross-subscription variant using Azure Monitor diagnostic settings. While Azure’s soft-delete policy delays immediate name reuse across tenants, attackers with cross-subscription access can reroute diagnostic pipelines to attacker-controlled storage accounts within the same tenant.

A core finding is that broad storage administrator roles commonly assigned in enterprise environments include default permissions for deleting buckets.

In Google Cloud, the standard Storage Admin role grants storage.buckets.delete without requiring targeted permissions like logging.sinks.update, meaning attackers can exploit the hijacking vector without ever needing explicit rights to modify streams.

Unit 42 recommends enforcing least privilege by restricting deletion permissions storage.buckets.delete (GCP), DeleteBucket (AWS), and Microsoft.Storage/storageAccounts/delete (Azure) minimal administrative roles only.

Organizations should deploy data perimeter controls, VPC Service Controls in Google Cloud, and SCP-based policies in AWS to block writes to buckets outside trusted boundaries.

AWS users should enable account-scoped regional namespaces for S3 to eliminate cross-account name reclamation entirely.

Security teams must also implement high-severity monitoring alerts on bucket deletion API calls, leveraging DSPM tools like Cortex XSIAM for prioritizing sensitive assets.

Unit 42 has not identified real-world threat actors exploiting this technique. However, given how difficult detection would be post-execution, the firm urges organizations to act proactively.

The research delivers a critical industry lesson: a design flaw discovered in one cloud provider can serve as a direct blueprint for exploiting another.

Follow us on Google News , LinkedIn and X to Get More Instant Updates. Set Cyberpress as a Preferred Source in Google.