Researchers at Palo Alto Networks’ Unit 42 have confirmed a new cloud storage attack technique that can redirect an organisation’s active data streams, including security logs and audit telemetry, into storage controlled by an attacker. The attack works across Google Cloud, AWS and Microsoft Azure. All three providers have been notified through responsible disclosure.
The technique is called bucket hijacking. No real-world threat actor has been observed using it yet. Researchers warn that detection would be extremely difficult once it is deployed.
How The Attack Works
The attack exploits a fundamental design principle of cloud storage: bucket names are globally unique. No two users can register an identical bucket name within a provider’s namespace. The destination of any data stream is determined by that name alone, not by the account that owns it.
An attacker who gains bucket deletion permissions executes the attack in three steps. First, they delete the target organisation’s active storage bucket. Second, they immediately recreate a new bucket using the identical name inside their own attacker-controlled account. Third, the original data stream, whether a Google Cloud logging sink, an AWS S3 replication rule or an Azure Monitor diagnostic export, continues operating as normal and begins writing data directly into the attacker’s bucket.
The attack then runs indefinitely on its own. The legitimate sink or replication configuration continues to appear valid when inspected. It generates no error states. It triggers no native alerts. Logs, metrics and sensitive telemetry flow silently into the attacker’s environment for as long as the hijack remains in place.
Confirmed Across All Three Major Providers
Unit 42 successfully simulated bucket hijacking across multiple services on each major cloud platform.
On Google Cloud, researchers confirmed the attack on Cloud Logging sinks, Pub/Sub subscriptions with Cloud Storage destinations and Storage Transfer Service jobs. The required permissions were storage.buckets.delete and storage.objects.delete. The standard Storage Admin role grants both by default, which means a large number of enterprise cloud administrators already have the permissions needed to execute or be exploited through this attack.
On AWS, researchers confirmed the technique on S3 bucket replication and Amazon Data Firehose pipelines targeting S3 destinations.
On Azure, the attack was demonstrated as a cross-subscription attack via Azure Monitor diagnostic settings, though it is currently limited to same-tenant scope due to platform-enforced name reuse delays.
Researchers highlighted a particularly concerning permission gap in Google Cloud. The standard Storage Admin role grants storage.buckets.delete by default, bypassing the more restrictive logging.sinks.update permission that would be required to legitimately reconfigure a data stream. This allows attackers to reroute data streams without ever touching stream configurations directly.
Why This Is Dangerous
Security and audit logs are the primary tool organisations use to detect intrusions. An attacker who redirects those logs to their own storage before a breach is discovered can erase the evidence trail entirely. The incident response team opens the logging console. Everything looks normal. The logs appear to be flowing. The attacker has simply been reading them first.
For organisations in regulated industries — banking, healthcare, critical infrastructure — the implications extend beyond data theft. Audit log integrity is a compliance requirement. A hijacked log stream could compromise regulatory evidence, invalidate forensic investigations and expose organisations to liability well beyond the breach itself.
What Organisations Must Do
Unit 42 recommends two defensive priorities. First, restrict deletion permissions to the minimum required administrative roles. Permissions including storage.buckets.delete on Google Cloud, DeleteBucket on AWS and Microsoft.Storage/storageAccounts/delete on Azure should not be assigned as defaults to broad administrative roles.
Second, enforce data perimeter controls. AWS Service Control Policies and Google Cloud VPC Service Controls can block writes to buckets outside a trusted organisational perimeter. Enabling these controls ensures that even if a bucket is hijacked, the original data stream cannot write to an external destination.
Proactive monitoring for unexpected bucket deletions and rapid re-creations of identically named buckets should be added to cloud security playbooks immediately.
