Palo Alto Networks’ Unit 42 has published “The Global Namespace Risk,” a technique that lets an attacker with limited permissions on a target cloud account silently redirect live, ongoing data streams — audit logs, telemetry, and replicated objects — into a bucket they control, on any of AWS, Google Cloud Platform, or Microsoft Azure. There’s no CVE, because it isn’t a bug in any one product; it’s a structural consequence of how object storage naming works everywhere.

What Happened

Bucket (or storage-account container) names are globally unique per provider: once a name is taken, no other account — not even the original owner, once they’ve released it — can claim a different bucket with that exact name at the same time. Ownership of a storage destination is therefore tied to a name string, not to an immutable account ID. Sinks, replication rules, and delivery pipelines that write to storage almost universally reference that destination by name, not by an account-bound resource identifier.

Unit 42’s attack chain is simple: an adversary who has (or obtains) permission to delete a target bucket — through a misconfigured IAM policy, an over-permissioned service account, or a compromised credential — deletes it, then immediately re-creates a bucket with the identical name inside their own, attacker-controlled account. Any pipeline still configured to write to that name keeps writing, now straight into the attacker’s storage. Because the sink or replication configuration on the victim side never changes, it continues to look completely valid during routine audits.

Researchers demonstrated working reclamation-and-redirect chains against production services on all three providers:

  • AWS: S3 bucket replication rules and Amazon Data Firehose delivery streams.
  • Google Cloud: Cloud Logging sinks, Pub/Sub subscriptions with a Cloud Storage push destination, and Storage Transfer Service jobs.
  • Azure: Azure Monitor diagnostic settings writing to a storage account.

In each case, the victim’s own logging or transfer infrastructure becomes the exfiltration channel — no phishing, no malware, and critically, no IAM event or access-denied signal that would normally trip an alert, since the attacker is writing to a bucket they legitimately own.

Impact

The prerequisite is real but not exotic: storage.buckets.delete in GCP, s3:DeleteBucket in AWS, or Microsoft.Storage/storageAccounts/delete in Azure, scoped to the target bucket. That permission shows up more often than it should in service accounts, CI/CD roles, and “cleanup” automation that was never meant to touch production logging destinations. Once the swap happens, everything downstream — CloudTrail history, security telemetry, replicated backups, cross-account transfer jobs — can flow to the attacker for as long as the redirect goes unnoticed, which Unit 42 notes could be indefinitely, since the pipeline reports healthy the entire time. All three cloud vendors were notified before publication; Unit 42 says it has not observed the technique used in the wild yet, but stresses the design flaw is universal, not vendor-specific.

Mitigation

  • Lock down deletion permissions. Restrict storage.buckets.delete (GCP), s3:DeleteBucket (AWS), and Microsoft.Storage/storageAccounts/delete (Azure) to a minimal, tightly audited set of administrative identities — never grant it to CI/CD, automation, or general developer roles.
  • Enforce data perimeters. Use VPC Service Controls in GCP or Service Control Policies in AWS to block writes to storage resources outside your organization’s trusted boundary, regardless of whether the destination name matches.
  • Adopt account-scoped bucket namespaces where available. AWS now supports account-regional S3 bucket namespaces, which eliminate cross-account name reclamation entirely — enable it for any new logging or replication destinations.
  • Alert on bucket-deletion API calls. Treat DeleteBucket/storage.buckets.delete events on any bucket that serves as a logging, replication, or transfer destination as a high-priority signal, not routine noise.
  • Periodically verify destination ownership, not just pipeline health — a healthy-looking sink is exactly what this technique is designed to produce.

Sources: Unit 42, “The Global Namespace Risk”, Cloud Security Alliance write-up, GBHackers coverage, CyberPress coverage.