"We recently identified a bucket hijacking technique impacting multiple services across major cloud service providers (CSPs)." — Palo Alto Networks Unit 42
How the bucket hijacking attack works
Unit 42 describes a simple but potent exploit built on a common architectural choice: storage bucket names that are globally unique within a cloud provider. Many cloud services route continuous data streams — telemetry, audit logs, replicated objects — into a destination identified only by that globally unique name. If an attacker can delete an organization’s bucket and immediately recreate a new bucket using the same name under the attacker’s account, the data stream can be redirected into the attacker-controlled bucket without changing the stream’s configuration.
The research shows this is not a hypothetical: after compromising an environment and acquiring deletion privileges, an attacker can empty and delete a bucket (requiring permissions such as storage.objects.delete and storage.bucket.delete in Google Cloud) and then recreate it under their control, allowing ongoing streams to flow into the attacker’s storage.
Services tested: Google Cloud Logging, Pub/Sub, Storage Transfer Service; AWS S3 replication and Firehose; Azure Monitor
Unit 42 ran controlled simulations across multiple services to demonstrate systemic applicability. In Google Cloud they used a logging sink routed to a Cloud Storage (GCS) bucket, deleted the bucket, recreated it in an attacker project and observed logs being delivered to the attacker bucket. The Pub/Sub test linked a subscription to a GCS bucket (with roles/storage.objectCreator and roles/storage.legacyBucketReader assigned to the service agent), published a message, deleted and re-created the bucket name in another project, and then saw subsequent messages delivered to the attacker bucket.
With Storage Transfer Service the team configured a transfer job between GCS buckets, granted the service agent Storage Object Viewer / Storage Legacy Bucket Reader on the source and Storage Object Admin on the destination, deleted the destination and re-created it elsewhere, and observed transferred objects appear in the attacker-controlled destination per the job schedule.
Unit 42 reproduced the pattern in AWS by exploiting S3 bucket replication and Amazon Data Firehose: they created a replication rule, deleted the destination bucket and immediately recreated it in an external account, then observed objects written to the source replicate into the attacker’s destination. In Azure the platform delays reuse of storage account names across tenants, but Unit 42 demonstrated a cross-subscription variation using Azure Monitor diagnostic settings: although the destination is stored as an ARM Resource ID, the pipeline resolves the account at runtime by DNS name ({{accountname}}.blob.core.windows.net), enabling an attacker who deleted and re-created a storage account with the same globally unique name in a different subscription to receive logs.
Why permissions and “configure-and-forget” routing matter
The report emphasizes that the attack bypasses the granular update permissions that typically control routers. For example, logging.sinks.update, pubsub.subscriptions.update and storagetransfer.jobs.update are the intended controls for modifying destinations, yet storage.buckets.delete and storage.objects.delete can be used to redirect data without ever updating the router. Unit 42 highlights two practical enabling scenarios: privilege escalation to acquire deletion rights, and dangling router resources left after a bucket is removed — both of which make silent exfiltration difficult to detect because the streaming configuration remains valid and continues to operate.
Mitigations Unit 42 recommends and provider responses
Prevention starts with principle-of-least-privilege controls: restrict deletion permissions such as storage.buckets.delete (Google Cloud), DeleteBucket (AWS) and Microsoft.Storage/storageAccounts/delete (Azure) to a minimal set of administrators and avoid assigning them to service accounts or applications without clear justification. Unit 42 also recommends perimeter controls: AWS service control policies (SCPs) and VPC endpoint policies can block writes to S3 buckets owned by external accounts; Google Cloud’s VPC Service Controls can block API calls to Cloud Storage buckets outside a defined perimeter. Unit 42 notes that AWS offers account regional namespaces for S3 buckets, which scope bucket names to an owning account and region to eliminate this hijacking vector.
For Azure, Unit 42 points out that soft-delete must be disabled for an attacker to promptly reclaim a name and that Microsoft recommended reviewing documentation and tooling on addressing dangling DNS for subdomain takeovers. Google has adjusted how router resources interact with target storage resources since Unit 42’s initial research.
Detection recommendations include high-priority alerts on storage deletion API calls, focusing monitoring and DSPM efforts on high-value assets, and using runtime analytics to detect writes to external buckets. Unit 42 highlights Palo Alto Networks’ own products — Cortex Cloud, Cortex Cloud Identity Security and Cortex XSIAM — as tools that can detect and alert on suspicious data movement and identity misuse, and offers Unit 42 incident response services for organizations that suspect compromise.
What this means for cloud security teams, enterprise IT, and Google Cloud, AWS and Microsoft Azure
- Cloud security teams: Prioritize alerts for bucket deletion API calls and apply DSPM prioritization to sensitive storage resources; treat storage deletion events as high-risk, especially for buckets used as sinks or long-term retention.
- Enterprise IT and procurement: Audit and tighten who holds deletion permissions (do not give storage.buckets.delete to service accounts by default), implement data-perimeter policies (SCPs, VPC Service Controls) and enable guardrails that prevent writes to external accounts.
- Google Cloud, AWS and Microsoft Azure: The architecture of global-name uniqueness contributed to the risk; AWS already offers an account regional namespace option, Google adjusted router interactions, and Microsoft advised reviewing dangling DNS mitigations — providers should continue hardening how routers resolve and validate destination ownership at runtime.
Unit 42’s work turns a seemingly small architectural choice — globally unique bucket names — into a cross-cloud exploitation methodology. The immediate next steps are concrete and technical: reduce deletion privileges, erect network and account perimeters that block external writes, and tune monitoring to treat bucket deletions as red‑flag events. The larger question the research leaves for cloud operators and customers alike is whether global, static resource names for critical storage sinks are an acceptable risk in configured-and-forgotten data pipelines.
Original report: https://unit42.paloaltonetworks.com/cloud-bucket-hijacking-risks/
