“`html
A significant cloud storage assault technique known as “bucket hijacking” is a method that allows malicious actors to covertly redirect an organization’s active cloud data streams, including audit logs and telemetry, into storage buckets controlled by the attacker on major cloud platforms.
This method has been verified to impact Google Cloud, Amazon Web Services (AWS), and Microsoft Azure, with all three providers being alerted through responsible disclosure.
Although no actual malicious entity has been detected utilizing this method thus far, experts caution that detection would prove exceedingly challenging once it is implemented.
The assault capitalizes on a foundational architectural vulnerability stemming from the global uniqueness of cloud storage bucket names. Since no two users can secure an identical bucket name within a provider’s namespace, the identity of a target storage bucket is linked solely to its name, rather than a particular account owner.
A malicious actor who breaches a cloud environment and obtains bucket deletion rights can execute the assault in a straightforward series of steps:
- Remove the target organization’s active storage bucket.
- Instantaneously recreate a new bucket using the same name within an attacker-controlled account.
- The original data stream, whether a Google Cloud logging sink, AWS S3 replication rule, or Azure Monitor diagnostic export, continues functioning independently and starts writing data directly into the attacker’s bucket.
This attack is especially perilous because it is self-sustaining. Once the hijacking is finalized, the legitimate sink or replication configuration remains appearing valid upon examination, producing no apparent error states and eliciting no inherent alerts. Logs, metrics, and sensitive telemetry flow quietly into the attacker’s environment indefinitely.
New Bucket Hijacking Assault
Unit 42 successfully replicated bucket hijacking across various services on each leading provider:
- Google Cloud: Verified on Cloud Logging sinks, Pub/Sub subscriptions with Cloud Storage destinations, and Storage Transfer Service tasks. Necessary permissions:
storage.buckets.deleteandstorage.objects.delete - AWS: Verified on S3 bucket replication and Amazon Data Firehose channels targeting S3 destinations
- Azure: Demonstrated as a cross-subscription attack via Azure Monitor diagnostic settings; restricted to same-tenant scope due to platform-enforced name reuse delays
Researchers emphasized that extensive storage administrative roles typically assigned in enterprise settings significantly heighten vulnerability.
In Google Cloud, the standard Storage Admin role grants storage.buckets.delete by default, circumventing the more restrictive logging.sinks.update permission that would be needed to legitimately reconfigure a data stream. This effectively permits attackers to reroute data streams without directly altering stream configurations.
Unit 42 suggests a dual-faceted defense approach that combines least-privilege access controls and proactive monitoring:
- Limit deletion permissions (
storage.buckets.delete,DeleteBucket,Microsoft.Storage/storageAccounts/delete) to the bare minimum necessary administrative roles - Implement data perimeter controls — AWS Service Control Policies (SCPs) or Google Cloud VPC Service Controls — to prevent writes to buckets beyond the trusted organizational boundary
- Enable AWS account-regional S3 namespaces to confine bucket names to specific accounts and regions, effectively eradicating the hijacking vector
- Activate high-priority monitoring alerts for storage bucket deletion API calls, particularly on buckets containing sensitive or regulated data
Unit 42 pointed out that this method is not confined to the three providers tested. Any cloud platform reliant on globally unique, statically named storage resources for data stream routing could be susceptible to the same tactics.
The research underscores that shared design philosophies among cloud providers imply a vulnerability discovered in one ecosystem can serve as a direct template for exploiting another, a crucial reminder for security teams overseeing multi-cloud settings.
“`