# Cloud Bucket Hijacking — Global Namespace Risk: Silent Data-Stream Redirection via Statically-Named Storage Buckets (AWS / Google Cloud / Azure)

> A cross-cloud data-exfiltration technique (Unit 42, June 2026) in which an attacker holding bucket-deletion permissions deletes a target organization's statically-named storage bucket and immediately recreates it under an attacker-controlled account using the identical name. Active data streams — Cloud Logging sinks, S3 replication, Data Firehose, Pub/Sub-to-GCS, Storage Transfer Service jobs and Azure Monitor diagnostic settings — continue writing autonomously into the attacker's bucket, silently exfiltrating logs and telemetry with no native alerts. No in-the-wild exploitation has been observed.

- **Published:** 2026-06-27T00:00:00Z
- **Last reviewed:** 2026-06-27T00:00:00Z
- **Canonical:** https://intel.threadlinqs.com/threat/TL-2026-0952
- **ID:** TL-2026-0952
- **Severity:** CRITICAL
- **Category:** CLOUD
- **Status:** TRACKING
- **Detections:** 9 · **IOCs:** 20 (full data via the Threadlinqs MCP server — Purple tier)

## Description

Unit 42 researcher Yahav Festinger disclosed (June 22, 2026) a universal cloud-storage abuse technique rooted in a design characteristic shared by all major cloud providers: globally unique bucket namespaces. Because no two accounts can simultaneously hold the same bucket name, an attacker who obtains permission to delete a target bucket can immediately recreate it under their own account with the identical name and inherit any data stream that was configured to write to that name.

The attack is dangerous precisely because it is self-sustaining and stealthy. Once the hijack completes, the original sink, replication rule or diagnostic export continues to appear valid upon inspection — the resource configuration itself never changes, so it generates no obvious error states and triggers no native alerts. Logs, metrics and sensitive telemetry flow silently into the attacker's environment indefinitely. Unit 42 notes detection becomes "extremely difficult once deployed."

On AWS, the technique targets S3 Bucket Replication and Amazon Data Firehose. The attacker (1) abuses or exploits a replication/delivery configuration pointing at a destination bucket, (2) deletes that destination bucket (s3:DeleteBucket), (3) recreates it with the identical name in an attacker-controlled account (s3:CreateBucket), and (4) observes objects replicating/streaming into the attacker bucket. CloudTrail records DeleteBucket and CreateBucket events.

On Google Cloud, the technique targets Cloud Logging sinks (a sink routing logs to a GCS bucket), Pub/Sub subscriptions with a Cloud Storage destination, and Storage Transfer Service jobs. The attacker deletes the destination bucket (requires storage.buckets.delete plus storage.objects.delete) and recreates it with the same name in an external project. A critical authorization gap drives the risk: the standard Storage Admin role grants storage.buckets.delete by default, so an attacker can reroute the data stream WITHOUT ever holding the more granular control-plane permissions (logging.sinks.update, pubsub.subscriptions.update, storagetransfer.jobs.update) that would normally be required to repoint a stream. The sink configuration still resolves and appears valid, so the hijack and exfiltration remain largely undetected.

On Azure the impact is lower. Azure Monitor diagnostic settings export resource logs to a storage account; the internal pipeline resolves the destination at runtime via the storage account DNS name ({accountname}.blob.core.windows.net). Platform limitations prevent immediate cross-tenant reuse of a storage account name for several days after deletion, and the account must have soft-delete disabled for the name to be released and reclaimed. The viable variant is therefore cross-subscription (same-tenant): an attacker deletes the storage account (Microsoft.Storage/storageAccounts/delete) and recreates it in a different subscription within the same tenant. Unit 42 rates this less severe than AWS/GCP because it is bounded to a cross-subscription rather than cross-tenant scope.

Two enabling scenarios are described: (1) privilege misuse — a compromised identity that already holds bucket-deletion permission redirects data streams; and (2) dangling router resources — an operator deletes a bucket but fails to remove the associated sink/replication/transfer 'router' resource, leaving a danger that an external attacker recreates the bucket and silently captures the stream. Because destination resources used for long-term retention or backup are infrequently inspected, deletion may not trigger immediate operational alerts, widening the detection gap. AWS's March 2026 account-regional S3 namespaces (scoping bucket names to the owning account+region) structurally eliminate the AWS vector; Google Cloud adjusted how router resources interact with target storage resources; Azure recommends cross-subscription validation and DNS record auditing. No CVE has been assigned; the issue is a design-level namespace risk rather than a software flaw.

## MITRE ATT&CK

- T1583 Acquire Infrastructure
- T1078 Valid Accounts
- T1199 Trusted Relationship
- T1078 Valid Accounts
- T1078 Valid Accounts
- T1685 Disable or Modify Tools
- T1578 Modify Cloud Compute Infrastructure
- T1552 Unsecured Credentials
- T1580 Cloud Infrastructure Discovery
- T1526 Cloud Service Discovery
- T1619 Cloud Storage Object Discovery
- T1538 Cloud Service Dashboard
- T1119 Automated Collection
- T1530 Data from Cloud Storage
- T1537 Transfer Data to Cloud Account
- T1020 Automated Exfiltration
- T1485 Data Destruction

## Sources

- [The Global Namespace Risk: Universal Bucket Hijacking Technique for Cloud Data Exfiltration](https://unit42.paloaltonetworks.com/cloud-bucket-hijacking-risks/)
- [New Bucket Hijacking Attack Allows Hackers to Reroute Cloud Data Streams to External Storage](https://cybersecuritynews.com/bucket-hijacking-attack/)
- [Cloud Bucket Hijacking Technique Lets Attackers Reroute Logs and Sensitive Data](https://cyberpress.org/cloud-bucket-hijacking-technique/)
- [The Global Namespace Risk: Universal Bucket Hijacking Technique for Cloud Data Exfiltration (Threat Radar)](https://radar.offseq.com/threat/the-global-namespace-risk-universal-bucket-hijacki-b3f460e94625a49f)
- [AWS S3 Introduces Account-Regional Namespaces, Ending 18 Years of Global Bucket Name Collisions](https://www.infoq.com/news/2026/03/s3-account-regional-namespaces/)
- [What is S3 Bucket Namesquatting, and How Do You Prevent It?](https://www.varonis.com/blog/preventing-s3-bucket-namesquatting)
- [S3 Bucket Namesquatting (glossary)](https://www.threatngsecurity.com/glossary/s3-bucket-namesquatting)
- [Bucketsquatting is (Finally) Dead](https://onecloudplease.com/blog/bucketsquatting-is-finally-dead)
- [New Bucket Hijacking Attack Allows Hackers to Reroute Cloud Data Streams to External Storage (Cryptika)](https://www.cryptika.com/new-bucket-hijacking-attack-allows-hackers-to-reroute-cloud-data-streams-to-external-storage/)

## Full data

Detection queries (Splunk SPL / Microsoft KQL / Sigma) and IOC values require the Threadlinqs MCP server (Purple tier): https://intel.threadlinqs.com/mcp

Canonical: https://intel.threadlinqs.com/threat/TL-2026-0952