New Bucket Hijacking Attack Can Redirect Cloud Data Streams to External Storage

A newly documented cloud attack technique called bucket hijacking can let attackers redirect active data streams, including logs, audit records, telemetry, and replicated files, into storage buckets they control.

The technique was detailed by Unit 42, which tested the issue across Google Cloud, Amazon Web Services, and Microsoft Azure. Researchers said they have not seen real-world attackers use the method yet, but warned that successful abuse could be difficult to detect.

The attack relies on a simple cloud design issue: many storage bucket names are globally unique within a provider. If an attacker can delete a target bucket and immediately recreate a bucket with the same name in another account, existing data streams may continue sending data to that name without realizing the owner changed.

How Bucket Hijacking Works

Bucket hijacking starts after an attacker already has access to a cloud environment with permission to delete a storage bucket. That permission is often broader than teams realize, especially in environments where storage administrator roles are widely assigned.

Once the attacker deletes the legitimate bucket, they race to create a new bucket with the same name under their own account or project. If the cloud service routes data by bucket name alone, the existing stream can continue writing to the recreated bucket.

This means the attacker may not need permission to edit the logging sink, replication rule, or diagnostic export. Deleting and recreating the destination can be enough to reroute the flow.

Attack Step	What Happens	Why It Matters
Initial access	Attacker compromises a cloud identity or role	The attacker needs permission to delete the target bucket
Bucket deletion	The legitimate destination bucket is removed	The bucket name may become available again
Name recreation	Attacker creates a bucket with the same name	The data stream may still point to that bucket name
Silent rerouting	Logs or data continue flowing to the new bucket	The configuration may still look valid to defenders

Why Global Bucket Names Create Risk

Cloud storage services often use bucket names as important routing identifiers. That design works well for scale and simplicity, but it can create risk when ownership changes after deletion.

Amazon’s S3 bucket naming rules explain that general purpose buckets normally exist in a shared global namespace, although AWS now also supports account-regional namespaces for new buckets.

The problem is not that public buckets are exposed. The problem is that a trusted internal process may continue sending data to a familiar bucket name even after a different account controls that name.

Which Cloud Services Were Tested

Unit 42 tested the technique against several automated data-streaming services. The affected scenarios involved services that write data into cloud storage based on bucket or storage-account destinations.

On Google Cloud, researchers tested Cloud Logging sinks, Pub/Sub subscriptions with Cloud Storage destinations, and Storage Transfer Service jobs. On AWS, they tested S3 replication and Amazon Data Firehose streams targeting S3.

On Azure, the technique was demonstrated through Azure Monitor diagnostic exports across subscriptions. Microsoft’s Azure Monitor diagnostic settings documentation explains that diagnostic settings can send platform logs and metrics to destinations such as storage accounts, event hubs, and Log Analytics workspaces.

• Google Cloud Logging sinks can export logs to Cloud Storage buckets.
• Google Cloud Pub/Sub can use Cloud Storage as a delivery destination.
• Storage Transfer Service jobs can move data between storage locations.
• AWS S3 replication can copy objects between buckets.
• Amazon Data Firehose can deliver streaming data to S3.
• Azure Monitor diagnostic settings can export logs to storage accounts.

Why the Attack Can Be Hard to Detect

Bucket hijacking can be hard to notice because the original stream configuration may still reference the same bucket name. A quick configuration review may not show a changed destination.

The visible problem is not always a broken pipeline. In a successful hijack, data keeps moving. The dangerous change is ownership of the destination, not necessarily the name displayed in the cloud console.

The Unit 42 research says the attack could reroute critical logs and sensitive data directly to an attacker’s environment. That makes monitoring bucket deletion events especially important.

Google Cloud Exposure and Defenses

In Google Cloud, the risk centers on destination buckets used by logging, Pub/Sub, and transfer workflows. If a compromised identity can delete the bucket, it may bypass the need to update the data-stream configuration directly.

Unit 42 highlighted the Storage Admin role as a risky example because it includes bucket deletion permissions. In some cases, that can create a path around more specific permissions, such as those needed to update a logging sink.

Google Cloud’s VPC Service Controls can help reduce data exfiltration risk by defining security perimeters around supported Google-managed services and blocking access from untrusted locations.

Cloud Platform	Tested Stream Type	Main Risk
Google Cloud	Cloud Logging, Pub/Sub, Storage Transfer Service	Data may flow to a recreated bucket controlled by another project
AWS	S3 replication and Amazon Data Firehose	Replicated or streamed data may be redirected to attacker-owned storage
Microsoft Azure	Azure Monitor diagnostic exports	Logs may be exported to a storage destination controlled outside the intended subscription

AWS Mitigation: Account-Regional S3 Namespaces

AWS has a direct mitigation for one major part of the problem. New general purpose buckets can be created in an account-regional namespace, which scopes the bucket name to a specific AWS account and Region.

The official AWS announcement says buckets in this namespace include the account ID and Region in the bucket name format. AWS says these names are tied to the account and cannot be recreated by another account.

This change reduces bucket name hijacking risk for new S3 designs. However, existing globally named buckets cannot simply be renamed into the new format, so organizations still need to review older buckets and migration plans.

Service Control Policies Can Reduce AWS Risk

AWS organizations can also use central guardrails to reduce exposure. AWS Service Control Policies let administrators define the maximum permissions available to IAM users and roles across accounts in an AWS Organization.

That matters because bucket deletion is the key step in this attack. An SCP can help prevent broad roles from deleting critical buckets or writing data to storage locations outside approved organizational boundaries.

Teams should test SCPs carefully before broad deployment because overly strict rules can break backups, replication, logging, deployment pipelines, and incident response workflows.

• Restrict s3:DeleteBucket on sensitive buckets.
• Require approved account-regional namespace buckets for new deployments.
• Block replication or delivery to unapproved external accounts.
• Alert on deletion attempts involving logging, telemetry, or backup buckets.
• Review IAM roles that combine storage administration and logging access.

Azure Risk Depends on Storage Account Ownership and Scope

Azure storage naming and service behavior differs from S3 and Cloud Storage, but the same general issue can appear when automated exports rely on named storage destinations.

Unit 42 described an Azure Monitor diagnostic export scenario that worked across subscriptions but stayed within the same tenant because of Azure platform controls and name reuse behavior.

Microsoft’s Log Analytics data export documentation shows how Azure Monitor can continuously export selected workspace tables to an Azure Storage Account or Event Hubs as data arrives in the pipeline.

Why Logs Are a High-Value Target

Cloud logs are not just operational records. They can reveal user activity, API calls, security events, resource names, internal architecture, source IPs, authentication patterns, and incident response activity.

If attackers redirect logs, they may gain intelligence while also weakening detection. A security team may believe audit data is still being preserved when it is actually flowing into attacker-controlled storage.

That makes bucket hijacking more dangerous than a normal storage misconfiguration. It can affect the visibility layer defenders depend on during an investigation.

Data Type	Why Attackers Want It
Audit logs	Reveal identity activity, API calls, and administrative behavior
Application telemetry	Shows service behavior, errors, internal names, and endpoints
Replication data	May include production objects, backups, or sensitive files
Security logs	Can show detection rules, response timelines, and investigation activity

What Cloud Teams Should Monitor

The most important signal is bucket deletion. A deletion event for a bucket used by logging, backups, replication, telemetry, or security analytics should trigger a high-priority alert.

Teams should also monitor bucket recreation with the same name, changes in bucket ownership, unusual stream delivery patterns, and write activity to storage outside the expected account, project, subscription, or tenant.

Because a hijacked stream may continue to work, failure alerts are not enough. Defenders need ownership validation and destination-account checks, not only delivery-success checks.

Least Privilege Is the First Defense

Bucket hijacking depends on permissions that allow deletion of important storage destinations. Organizations should remove bucket deletion permissions from routine administrator roles where possible.

Cloud teams should create break-glass workflows for destructive storage actions. Those workflows should require approval, logging, and alerts when deleting buckets tied to logs, backups, compliance evidence, or regulated data.

In Google Cloud, VPC Service Controls can help keep sensitive data inside approved perimeters. In AWS, SCPs can enforce organization-wide limits that normal IAM policies alone may not guarantee.

• Remove bucket deletion rights from broad storage administrator roles.
• Protect logging and audit buckets with separate administrative controls.
• Require approval for bucket deletion in production environments.
• Alert on destination bucket deletion, recreation, and ownership changes.
• Validate data-stream destinations by owner, not name alone.
• Use cloud perimeters and organization policies to block external writes.

AWS Users Should Review New Namespace Options

Organizations building new AWS storage workflows should consider S3 account-regional namespaces for buckets used by logs, replication, backups, and telemetry.

The S3 documentation says new buckets created in an account-regional namespace are unique to the account and cannot be recreated by another account. That directly addresses the name-reuse weakness behind many bucket hijacking and bucket squatting scenarios.

The AWS launch post also notes that existing global buckets cannot be renamed into account-regional names. Teams with older buckets should plan migrations carefully instead of assuming the new feature protects existing storage automatically.

Azure Teams Should Validate Diagnostic Destinations

Azure administrators should review diagnostic settings and Log Analytics exports that write to storage accounts, especially when those destinations sit outside the workload subscription.

The Azure diagnostic settings guide explains that diagnostic settings control where platform logs and metrics are sent. Those destinations should be reviewed for expected subscription, tenant, and storage-account ownership.

For Log Analytics, Microsoft’s data export documentation shows that export rules can continuously send selected tables as data arrives. This makes destination validation critical because the export can keep running after initial setup.

Why Multi-Cloud Teams Need One Policy

Bucket hijacking shows how a design pattern in one cloud can become a practical risk across several platforms. Multi-cloud teams should avoid treating each provider’s storage controls as a separate one-off problem.

The stronger approach is to define a shared policy: no critical data stream should rely only on a globally reusable storage name. Destination ownership, account boundary, deletion rights, and perimeter controls should all be verified.

Security teams should also include bucket hijacking in cloud threat modeling, incident response playbooks, and tabletop exercises. The attack affects logs and telemetry, which are exactly the data sources responders need during a breach.

FAQ