Add content from: The Global Namespace Risk: Universal Bucket Hijacking Techni...

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 <source-bucket>
+aws firehose describe-delivery-stream --delivery-stream-name <stream-name>
+
+# Azure: diagnostic settings pointing to storage accounts
+az monitor diagnostic-settings list --resource <resource-id>
+```
+
+**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}}