Cloud Bucket Hijacking — Global Namespace Risk: Silent Data-Stream Redirection via Statically-Named Storage Buckets (AWS / Google Cloud / Azure)
Cloud Bucket Hijacking (TL-2026-0952), also tracked as Global Namespace Risk, is a critical-severity cloud security threat, first published 2026-06-27. It has no confirmed attribution, affects Amazon Web Services Amazon S3 (Bucket Replication, Amazon Data, maps to 15 MITRE ATT&CK techniques (T1020, T1078, T1119), and is covered by 9 detection rules and 20 indicators of compromise.
Key facts for TL-2026-0952
- Threat ID
- TL-2026-0952
- Also known as
- Global Namespace Risk, Universal Bucket Hijacking, Cloud Bucket Hijacking, Data-Stream Redirection
- Severity
- CRITICAL
- Status
- TRACKING
- Category
- CLOUD
- First published
- 2026-06-27
- Last reviewed
- 2026-06-27
- Attribution confidence
- NONE
- Motivation
- UNKNOWN
- Target sectors
- financial, government, healthcare, technology, cloud-service-providers, enterprise, saas
- Target regions
- Global, North America, Europe, Asia-Pacific
- Detection rules
- 9
- Indicators of compromise
- 20
Malware and tooling in Cloud Bucket Hijacking
Malware and tooling: Attacker-controlled AWS account / GCP project / Azure subscription hosting a recreated same-named bucket
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.
How Cloud Bucket Hijacking works
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 techniques used in TL-2026-0952
Exfiltration
T1020 Automated Exfiltration; T1537 Transfer Data to Cloud Account
Initial Access
T1078 Valid Accounts; T1199 Trusted Relationship
Persistence
Privilege Escalation
Collection
T1119 Automated Collection; T1530 Data from Cloud Storage
Impact
Discovery
T1526 Cloud Service Discovery; T1538 Cloud Service Dashboard; T1580 Cloud Infrastructure Discovery; T1619 Cloud Storage Object Discovery
Credential Access
defense-impairment
T1578 Modify Cloud Compute Infrastructure; T1685 Disable or Modify Tools
Resource Development
Affected products and versions in Cloud Bucket Hijacking
- Amazon Web Services — Amazon S3 (Bucket Replication, Amazon Data Firehose)
Vulnerable versions: Global bucket namespace (pre-account-regional namespaces)
Fixed in: Account-regional namespaces (GA March 2026) - Google Cloud — Cloud Logging sinks, Pub/Sub (GCS destination subscriptions), Storage Transfer Service, Cloud Storage
Vulnerable versions: Global GCS bucket namespace; Storage Admin grants storage.buckets.delete by default
Fixed in: Provider adjusted router-to-target-storage interaction; VPC Service Controls mitigation - Microsoft Azure — Azure Monitor diagnostic settings, Azure Storage accounts
Vulnerable versions: Cross-subscription, same-tenant scope; storage account with soft-delete disabled
Fixed in: Guidance: cross-subscription validation, DNS record auditing, soft-delete enabled
Remediation for Cloud Bucket Hijacking
Patches
- AWS: account-regional S3 namespaces (GA March 2026) eliminate the global-namespace hijack vector
- Google Cloud: provider adjusted how router (sink) resources interact with target storage resources
- Azure: provider recommends cross-subscription validation and DNS record auditing (no software patch — design guidance)
Immediate actions
- Restrict bucket/storage-account deletion permissions (s3:DeleteBucket, storage.buckets.delete + storage.objects.delete, Microsoft.Storage/storageAccounts/delete) to the minimum set of highly-trusted admin roles via least privilege
- Audit and remove dangling router resources (Cloud Logging sinks, S3 replication rules, Firehose delivery streams, Pub/Sub GCS subscriptions, Storage Transfer jobs, Azure Monitor diagnostic settings) whose destination bucket no longer exists
- Deploy high-priority monitoring alerts on storage bucket / storage-account deletion API calls (CloudTrail DeleteBucket, GCP storage.buckets.delete audit logs, Azure Activity Log storageAccounts/delete)
Workarounds
- AWS: enforce SCPs and VPC endpoint policies restricting S3 writes to organization-owned accounts (data perimeter)
- Google Cloud: enforce VPC Service Controls perimeters to block Cloud Storage API calls targeting buckets outside the perimeter
- Use non-predictable, account-scoped bucket naming and avoid statically/predictably named buckets for sensitive sinks
Longer-term hardening
- Adopt AWS S3 account-regional namespaces (x-amz-bucket-namespace: account-regional) so bucket names are scoped to the owning account and region instead of a single global namespace
- Disable cross-account/cross-tenant write paths and validate that audit-log and telemetry sinks resolve only to organization-owned destinations
- Use Data Security Posture Management (DSPM) to inventory sensitive sink destinations and prioritize monitoring of high-value retention/backup buckets
- Enable Azure storage-account soft-delete and audit storage-account DNS records to detect/slow cross-subscription name reclamation
Weaknesses (CWE) in Cloud Bucket Hijacking
CWE-284, CWE-269, CWE-639, CWE-732, CWE-668
Timeline of Cloud Bucket Hijacking
- Amazon S3 launches enforcing globally-unique bucket names across all accounts and regions — the design characteristic later abused by bucket hijacking.
- Aqua Security presents 'Bucket Monopoly' at Black Hat USA 2024, demonstrating predictable/static bucket name squatting risks across AWS services.
- AWS introduces account-regional S3 namespaces (GA), scoping bucket names to the owning account and region and structurally ending global bucket-name squatting/hijacking on AWS.
- Unit 42 documents Azure platform limitations — a deleted storage-account name is not immediately reusable cross-tenant (multi-day delay) and only released if soft-delete is disabled — bounding the viable Azure variant to cross-subscription, same-tenant scope and rating it less severe than AWS/GCP.
- Google Cloud adjusts how router (sink) resources interact with target storage resources; Azure recommends cross-subscription validation and DNS record auditing.
- Palo Alto Networks Unit 42 (Yahav Festinger) publishes 'The Global Namespace Risk: Universal Bucket Hijacking Technique for Cloud Data Exfiltration', demonstrating the technique across AWS, Google Cloud and Azure services.
- OffSeq Threat Radar indexes 'The Global Namespace Risk: Universal Bucket Hijacking Technique' for tracking and triage.
- Threadlinqs Intelligence ingests TL-2026-0952 and builds detection coverage for storage bucket deletion + recreation and data-stream redirection.
- Cyber Security News, Cyberpress and others report the technique to a broad defender audience; no in-the-wild exploitation observed.
Sources cited for Cloud Bucket Hijacking
- The Global Namespace Risk: Universal Bucket Hijacking Technique for Cloud Data Exfiltration
- New Bucket Hijacking Attack Allows Hackers to Reroute Cloud Data Streams to External Storage
- Cloud Bucket Hijacking Technique Lets Attackers Reroute Logs and Sensitive Data
- The Global Namespace Risk: Universal Bucket Hijacking Technique for Cloud Data Exfiltration (Threat Radar)
- AWS S3 Introduces Account-Regional Namespaces, Ending 18 Years of Global Bucket Name Collisions
- What is S3 Bucket Namesquatting, and How Do You Prevent It?
- S3 Bucket Namesquatting (glossary)
- Bucketsquatting is (Finally) Dead
- New Bucket Hijacking Attack Allows Hackers to Reroute Cloud Data Streams to External Storage (Cryptika)
Threats related to Cloud Bucket Hijacking
- Global Namespace Bucket Hijacking: Universal Cloud Data Exfiltration via Storage Bucket Name Reclamation (AWS S3 / GCP Cloud Storage / Azure Blob)
- ShutterGap: Ephemeral Public Exposure of AWS RDS/DocumentDB Snapshots, AMIs & SSM Documents Evades CSPM/CNAPP Scan Cycles
- Azure Blob Storage Ransomware: Four Storage-Encryption Abuse Methods (BlackCat/ALPHV, STORM-0501)
- Pickle in the Middle: Vertex AI Model Upload Hijacking via GCS Bucket Squatting Enables Cross-Tenant RCE (google-cloud-aiplatform v1.139.0/v1.140.0)
- Lone Attacker Uses AI-Assisted Workflows to Breach Large AWS Cloud Environment in 72 Hours (Sygnia Investigation)
- AWS Bedrock AgentCore Sandbox Escape via DNS Tunneling and Metadata Service Exploitation
Detection coverage for TL-2026-0952
As of 2026-06-27, Threadlinqs Intelligence publishes 9 detection rule(s) for TL-2026-0952 across Splunk SPL, Microsoft KQL and Sigma, covering 20 indicator(s) of compromise. The whole corpus is readable without an account; a free account unlocks full detection query text in Splunk SPL, Microsoft KQL and Sigma; paid tiers add raw indicator values, correlation and the MCP server. Threadlinqs MCP server · View plans.