Unit 42 research shows how globally unique bucket names enable silent redirection of logs and messages across cloud accounts. Cross-CSP impact demonstrated.
Unit 42 at Palo Alto Networks has published research that dismantles a core assumption of cloud architecture: deleting a storage bucket does not guarantee its permanent demise. The researchers demonstrate that an attacker with delete permissions can recreate the bucket under the same name in their own account, silently intercepting active data flows without altering any source configuration. The technique, successfully tested against three Google Cloud services, exposes a structural cross-provider weakness that ties destination identity to the bucket name rather than to an immutable owner.
Key Takeaways
- Global uniqueness of bucket names creates a shared namespace where ownership is volatile, not permanent: whoever holds the name holds the flow
- The research documents successful simulations against Cloud Logging, Pub/Sub, and Storage Transfer Service, with actual exfiltration of logs and messages
- Two specific GCS permissions are required: storage.objects.delete to empty the bucket and storage.bucket.delete to delete it
- Unit 42 notified three CSPs — Google Cloud, AWS, and Microsoft Azure; no in-the-wild exploitation was detected at the time of publication
The Binding That Breaks: Global Name, Fluid Ownership
The architecture of major cloud providers assigns storage buckets globally unique names. This design, as the Palo Alto Networks researchers observe, "simplifies the establishment of data flows" between services: once the name is known, any component can direct data to it without further ownership verification. The destination's identity is the name itself, not a persistent account identifier. The research shows this architectural economy hides a structural flaw. When a bucket is deleted, its name returns to the global namespace. An attacker who has obtained the necessary permissions — storage.objects.delete to empty the contents and storage.bucket.delete for final deletion — can immediately recreate it under their own project. Source services, configured to write to that specific name, continue doing so unaware of the ownership change."Because a storage bucket name is globally unique, an attacker can simply delete the bucket and then recreate it under the attacker's own account using the same name. This therefore creates a global namespace risk." — Unit 42 researchers, Palo Alto Networks
Three Services, One Pattern: Logs, Messages, and Transfers
The researchers built working demonstrations against three representative Google Cloud services. In the first scenario, a Cloud Logging sink configured to write logs to a GCS bucket continues streaming data after the attacker deletes the original bucket and recreates the same name in their own project. The logs, potentially containing sensitive system and application information, land directly in the attacker's environment. The second scenario involves Pub/Sub: a subscription with a GCS destination, after the bucket is recreated under attacker control, routes entire messages to the new owner. The research documents a five-step simulation concluding with actual message exfiltration. The third case concerns Storage Transfer Service, where a GCS-to-GCS transfer job, once intercepted via a ghost bucket, can divert entire datasets to unauthorized accounts. Unit 42 emphasizes these three services constitute a "representative subset" of a broader attack surface: the pattern is systemic, not limited to isolated cases.Mitigation Steps
Organizations operating on Google Cloud can adopt immediate, specific measures to reduce the attack surface documented by Unit 42. Audit IAM permissions that include storage.objects.delete and storage.bucket.delete. These two specific permissions are the technical prerequisite for the attack; their over-allocation to roles, service accounts, or users that do not require bucket deletion capability constitutes the documented entry vector. Verify Cloud Logging, Pub/Sub, and Storage Transfer Service configurations that point to GCS buckets. The research demonstrated the vulnerability against these three services: every sink, subscription, or transfer job with a bucket destination should be inspected to confirm the destination bucket remains under the control of the organization that owns the data flow. Monitor bucket deletion and recreation events in your own project and connected projects. While the research does not document native automatic controls for name reuse, Google Cloud audit logs record bucket delete and create operations: temporal correlation of these events on identical names is the primary indicator available for detecting suspicious patterns.The Trust Chain That Doesn't Exist
The research highlights a gap in the cloud trust chain: between the service generating data and the bucket receiving it, no cryptographic or contractual verification of ownership occurs. Routing relies on a resource name, not an attested identity. This differs from other cloud attack patterns — such as DNS hijacking or subdomain takeover — where at least the attack surface maps to public registrations and known expiration timelines. In the ghost bucket case, the attack is instantaneous: no propagation interval, no TTL, no cache to poison. Recreation of the name is atomic relative to namespace availability. Unit 42 shared findings with Google Cloud, Amazon Web Services, and Microsoft Azure. The status of any countermeasures remains undocumented as of publication. The research does not report official vendor responses or intervention timelines."This could have led to the exfiltration of the target's data to the attacker's account." — Unit 42 researchers
What Remains Unclear
The dossier leaves relevant operational questions open. It does not specify whether provider audit logs record the delete-recreate sequence with sufficient detail to enable retrospective forensics, nor whether native APIs or tools exist to block reuse of a bucket name after deletion. It does not document whether the technique is replicable with buckets in different regions or with geographic locality requirements that would constrain recreation. The cross-CSP scope — asserted by the research as potential, given the shared global namespace pattern — has not been verified with equivalent simulations on AWS S3 or Azure Blob Storage. The researchers notified the three providers, but the brief does not report responses or confirmations of reproducibility."We have not yet identified a real-world threat actor using this attack technique. However, we recommend organizations take steps now to head off the potential impact, particularly since we anticipate that real-world attempts to use this attack technique would be difficult to detect." — Unit 42 researchersThe absence of documented exploitation does not mitigate the architectural risk: the barrier to entry is low — two over-allocated IAM permissions — and stealth is intrinsic to the design. For cloud organizations, the most disruptive insight from the research is not technical but conceptual: in operational logic, deletion marks an end; in the global bucket namespace, it can mark the beginning of a persistent compromise.
Information is based on the cited source and current as of publication.