From d10beb188675f1ad63e99639da67e1b03bbc3d5a Mon Sep 17 00:00:00 2001 From: HackTricks News Bot Date: Tue, 23 Jun 2026 03:02:47 +0000 Subject: [PATCH] Add content from: The Global Namespace Risk: Universal Bucket Hijacking Techni... --- .../pentesting-cloud-methodology.md | 51 +++++++++++++++++++ 1 file changed, 51 insertions(+) diff --git a/src/pentesting-cloud/pentesting-cloud-methodology.md b/src/pentesting-cloud/pentesting-cloud-methodology.md index 9aa8f5ec6c..4b58b74f41 100644 --- a/src/pentesting-cloud/pentesting-cloud-methodology.md +++ b/src/pentesting-cloud/pentesting-cloud-methodology.md @@ -32,6 +32,50 @@ Each cloud has its own peculiarities but in general there are a few **common thi - For **integrations inside the cloud you are auditing** from external platforms, you should ask **who has access externally to (ab)use that integration** and check how is that data being used.\ For example, if a service is using a Docker image hosted in GCR, you should ask who has access to modify that and which sensitive info and access will get that image when executed inside an AWS cloud. +### Hunt autonomous data streams that write into globally-unique storage + +A recurring **cross-cloud post-exploitation primitive** is to find **long-lived routers / sinks / subscriptions / replication jobs** that keep writing into a storage destination identified mainly by a **globally unique name**. If an attacker can **empty + delete** that destination and then **recreate the same name** in an attacker-controlled project/account/subscription, the upstream service may continue delivering data to the replacement destination **without modifying the router resource itself**. + +This is interesting because it can **bypass the expected permission boundary**: the attacker might not have the permissions needed to update the router (for example `logging.sinks.update`, `pubsub.subscriptions.update` or similar), but a broad destructive storage permission such as `storage.buckets.delete`, `s3:DeleteBucket`, or `Microsoft.Storage/storageAccounts/delete` can still produce equivalent data redirection. + +**Generic attack flow:** + +1. Identify automated data streams that write to buckets / storage accounts and are expected to run unattended. +2. Verify whether the destination is referenced by **name** and whether that name is **reclaimable** after deletion. +3. Check if your current principal can delete the destination even if it cannot update the router resource. +4. Delete the destination, recreate the same globally-unique name under attacker control, and wait for the next log/message/object delivery cycle. + +**Good targets to review:** + +- **GCP**: Cloud Logging sinks to GCS, Pub/Sub Cloud Storage subscriptions, Storage Transfer Service jobs. +- **AWS**: S3 replication destinations, Firehose streams writing to S3, and any other service that continuously writes into an S3 bucket by name. +- **Azure**: Azure Monitor diagnostic settings writing to Storage Accounts, especially when deletion/recreation is possible inside the same tenant. + +**Quick hunting checklist:** + +```bash +# GCP: sinks, subscriptions and transfer jobs that may target GCS +gcloud logging sinks list +gcloud pubsub subscriptions list +gcloud transfer jobs list + +# AWS: replication and Firehose destinations +aws s3api get-bucket-replication --bucket +aws firehose describe-delivery-stream --delivery-stream-name + +# Azure: diagnostic settings pointing to storage accounts +az monitor diagnostic-settings list --resource +``` + +**What to report / detect:** + +- Principals that can **delete storage destinations** but cannot formally update the associated router resource. +- **Dangling router resources** still pointing to deleted buckets / storage accounts. +- Sensitive log/export pipelines that can write to **external accounts/projects/subscriptions**. +- High-severity alerts on deletion of buckets / storage accounts that are referenced by sinks, subscriptions, replication rules, transfer jobs, Firehose streams, or diagnostic settings. + +When a cloud environment heavily relies on autonomous exports for **logs, audit trails, backups, telemetry, or message archival**, this review should be part of the standard methodology because the impact is usually **silent long-term exfiltration** rather than immediate service breakage. + ## Multi-Cloud tools There are several tools that can be used to test different cloud environments. The installation steps and links are going to be indicated in this section. @@ -454,6 +498,13 @@ azure-security/ confidential-computing/luks2-header-malleability-null-cipher-abuse.md {{#endref}} +## References + +- [The Global Namespace Risk: Universal Bucket Hijacking Technique for Cloud Data Exfiltration](https://unit42.paloaltonetworks.com/cloud-bucket-hijacking-risks/) +- [Cloud Logging routing and sinks](https://docs.cloud.google.com/logging/docs/export/configure_export_v2) +- [Amazon S3 replication](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html) +- [Azure Monitor diagnostic settings](https://learn.microsoft.com/en-us/azure/azure-monitor/platform/diagnostic-settings) + {{#include ../banners/hacktricks-training.md}}