Il 22 giugno 2026 l'Unit 42 di Palo Alto Networks ha pubblicato l'analisi di una tecnica di bucket hijacking che sfrutta un'assenza di controlli nell'architettura dei cloud provider maggiori: l'identità di un bucket di storage è legata al suo nome, non a un identificatore di proprietà immutabile. Il risultato è un attacco cross-provider in cui un attore malevolo può reindirizzare silenziosamente flussi di dati attivi verso un ambiente sotto il proprio controllo, senza mai toccare il servizio sorgente.
- I nomi dei bucket di storage sono globalmente unici all'interno di ogni cloud provider, ma non ancorati a un proprietario immutabile: la cancellazione e ricreazione con lo stesso nome in un altro account trasferisce l'identità del destinatario
- Unit 42 ha dimostrato l'attacco su 3 servizi Google Cloud: Logging, Pub/Sub e Storage Transfer Service, con esfiltrazione effettiva dei dati in tutti i casi testati
- L'attacco richiede 2 permessi specifici su Google Cloud:
storage.objects.deleteper svuotare il bucket estorage.bucket.deleteper eliminarlo - La ricerca è stata condivisa con 3 CSP — Google Cloud, AWS e Microsoft Azure — ma 0 threat actor sono stati identificati che utilizzino questa tecnica nel mondo reale; il rilevamento in scenari reali è descritto come particolarmente difficile
Il meccanismo: nome come identità, non come indirizzo
La vulnerabilità non risiede in un bug di implementazione, ma in una scelta architetturale. Come documenta Unit 42, i cloud provider trattano il nome del bucket come identificatore globale del destinatario di un flusso dati. Quando un amministratore configura Google Cloud Logging per riversare i log in un bucket, o quando Pub/Sub archivia messaggi in GCS, il sistema risolve la destinazione interrogando il namespace globale: il nome è la destinazione.
Questo significa che se il bucket viene eliminato e immediatamente ricreato con identico nome in un altro progetto, account o addirittura organizzazione, i flussi automatici continuano a funzionare. Non c'è interruzione del servizio, nessun errore visibile, nessuna notifica di fallimento. I dati semplicemente cambiano destinazione senza che il mittente ne sia informato.
La fonte descrive questa caratteristica come la "foundational logic" dell'attacco. La citazione chiave dell'analisi: "Because a storage bucket name is globally unique, an attacker can simply delete the bucket and then recreate it under the attacker's own account using the same name. This therefore creates a global namespace risk". Il passaggio da proprietà legale a proprietà nominale è istantaneo.
Le simulazioni: 3 servizi, 3 esfiltrazioni confermate
Unit 42 ha costruito proof-of-concept su 3 servizi Google Cloud, dimostrando che la tecnica non dipende da una specifica implementazione ma dal modello di namespace condiviso. Nel caso di Google Cloud Logging, i ricercatori hanno configurato un sink verso un bucket GCS, eliminato il bucket, ricreato in un progetto controllato e verificato l'arrivo dei log. Il flusso non si è interrotto.
La stessa procedura ha funzionato su Pub/Sub, dove i messaggi destinati a un bucket di archiviazione sono stati dirottati, e su Storage Transfer Service, configurato per trasferimenti automatici tra bucket. In tutti e 3 i casi, l'esfiltrazione è avvenuta senza alterazione della configurazione lato sorgente. Non è stata necessaria alcuna compromissione del servizio emittente.
I permessi richiesti sono circoscritti: storage.objects.delete per svuotare il contenuto e storage.bucket.delete per l'eliminazione finale. Non servono privilegi di amministratore progetto né accesso ai sistemi che generano i dati. L'attaccante colpisce il punto terminale, non il percorso.
"real-world attempts to use this attack technique would be difficult to detect"
La dimensione cross-provider: S3 e Azure nel perimetro di rischio
L'analisi non si limita a Google Cloud. Unit 42 menziona esplicitamente i bucket S3 di AWS e il corrispondente servizio Azure Blob Storage nel campo di applicazione teorico della tecnica, e ha notificato i 3 provider prima della pubblicazione. Tuttavia, il dossier contiene prove dettagliate solo per l'ecosistema Google. Per AWS e Azure, la fonte non documenta simulazioni pubblicate né elenca permessi specifici equivalenti a quelli testati su GCS.
La disclosure coordinata con 3 CSP majori suggerisce che la logica del namespace globale non sia un'eccezione di Google ma una caratteristica condivisa, almeno nella struttura nominale. Il testo menziona che la ricerca è stata condivisa "before any mitigations were provided", senza chiarire se mitigazioni siano state successivamente rilasciate.
Le organizzazioni che operano su cloud multipli non possono assumere che la protezione esista su un provider semplicemente perché un altro è stato studiato più approfonditamente.
Cosa fare adesso
Per le organizzazioni che utilizzano Google Cloud, la priorità immediata è verificare chi detenga i 2 permessi critici identificati da Unit 42: storage.objects.delete e storage.bucket.delete sui bucket che ricevono flussi automatici da Logging, Pub/Sub o Storage Transfer Service. La rimozione di questi permessi da ruoli non strettamente necessari riduce la superficie di attacco documentata.
Per i bucket che fungono da destinazione di pipeline dati automatizzate, è necessario controllare che non esistano configurazioni con dipendenze implicite sul nome del bucket senza verifica del proprietario. Questo vale in particolare per i sink di logging centralizzati e i job di trasferimento schedulati.
Su ambienti multi-cloud, il passaggio operativo è la mappatura dei bucket attivi come punti terminali di flussi dati, non solo come storage statico. La cancellazione di un bucket va trattata come evento di rischio persistente: il nome rimane disponibile nel namespace globale e può essere reclamato.
Il monitoraggio dei log di accesso ai bucket è l'unico controllo documentato con potenziale efficacia contro questa tecnica, dato che l'attacco non genera errori di servizio. La visibilità sul cambio di proprietà effettivo — non solo sulla configurazione — resta il punto debole segnalato dalla ricerca.
Perché è importante
La fonte non quantifica il numero di bucket potenzialmente esposti né stima la superficie di attacco sui 3 provider. La lista dei servizi vulnerabili è descritta come "representative subset", il che implica che altri servizi con flussi automatici verso bucket potrebbero presentare le stesse caratteristiche.
Il dato più rilevante per la valutazione del rischio resta la difficoltà di rilevamento. Poiché l'attacco non genera errori né interrompe il servizio, la sua efficacia in scenari reali dipende interamente dalla capacità di monitoraggio dei log di accesso ai bucket.
L'assenza di threat actor identificati non mitiga la rilevanza della tecnica. Al contrario, la combinazione di bassa visibilità, requisiti di accesso circoscritti e impatto silenzioso ne fa un vettore ideale per operazioni di spionaggio a lungo termine, dove la priorità è la persistenza piuttosto che l'immediatezza.
Per le aziende con pipeline dati automatizzate su cloud, il punto critico è la consapevolezza che la cancellazione di una risorsa non equivale alla sua scomparsa dal perimetro di rischio. Il nome sopravvive come indirizzo attivo finché qualcun altro non lo reclama.
Le informazioni sono basate sulla fonte citata e aggiornate al momento della pubblicazione.