PoC Zealot: AI autonoma sferra attacco end-to-end su cloud GCP
Unit 42 dimostra con Zealot che sistemi multi-agente AI possono concatenare autonomamente SSRF, furto credenziali ed esfiltrazione BigQuery su cloud misconfigu…
Contenuto
Palo Alto Networks Unit 42 ha pubblicato il 23 aprile 2026 i risultati di Zealot, un proof of concept multi-agente che ha eseguito autonomamente una catena offensiva end-to-end contro una sandbox Google Cloud Platform. Il sistema non ha scoperto zero-day né creato nuove superfici di attacco: ha semplicemente concatenato a velocità macchina misconfigurazioni IAM e flaw di sicurezza già noti, dimostrando che la minaccia AI-autonoma sul cloud è passata dalla teoria alla pratica dimostrabile.
La posta in gioco non è l'emergenza di una nuova vulnerabilità, ma la velocità con cui agenti artificiali possono amplificare errori umani preesistenti. Per i team di sicurezza, questo sposta l'attenzione dal patching reattivo al controllo rigoroso delle configurazioni identitarie prima che vengano orchestrate da sistemi che non dormono, non sbagliano di distrazione e non lasciano tracce emotive.
- Zealot utilizza un'architettura supervisor-agent gerarchica in LangGraph con un supervisore centrale e tre agenti specialisti per orchestrare l'attacco autonomo.
- La catena dimostrata ha incluso SSRF, furto di credenziali dal metadata service GCP, impersonazione di service account ed esfiltrazione dati da BigQuery.
- L'architettura è dichiarata LLM-agnostic: nessun modello specifico è vincolante, il che allarga il campo di riproducibilità del PoC.
- I sistemi multi-agente puramente decentralizzati sono risultati instabili con azioni ridondanti o in conflitto; il supervisore ha risolto questi limiti riprioritizzando in tempo reale.
Come funziona l'architettura Zealot: il supervisore che orchestra specialisti
Il nucleo tecnico di Zealot è un'organizzazione gerarchica implementata in LangGraph, framework di orchestrazione per grafi di stato. Al vertice, un supervisore centrale gestisce lo stato condiviso dell'operazione e delega istruzioni dinamiche a tre agenti specialisti. Questa struttura rompe con i modelli multi-agente puramente decentralizzati, dove ogni nodo opera su obiettivi propri senza coordinamento superiore.
Gli autori di Unit 42 hanno testato entrambi gli approcci. I sistemi decentralizzati autonomi hanno generato comportamenti difficili da contenere: azioni ripetute senza progresso, conflitti tra agenti che tentavano operazioni contraddittorie, perdita di coerenza nello stato dell'attacco. Il supervisore centrale ha invece permesso di riassegnare priorità in tempo reale sulla base di nuove informazioni raccolte durante la fase di ricognizione.
L'Infrastructure Agent, il solo specialista descritto in dettaglio nel frammento disponibile, si occupa della mappatura delle risorse cloud e dell'identificazione delle misconfigurazioni esponibili. Le funzioni precise degli altri due agenti specialisti non sono specificate nel testo fornito, che risulta troncato in quel punto. L'articolo non entra nel dettaglio di quali modelli LLM siano stati effettivamente impiegati per ciascun nodo, limitandosi a sottolineare l'agnosticismo architetturale.
La catena di attacco dimostrata: da SSRF a esfiltrazione BigQuery
La dimostrazione empirica ha seguito una sequenza classica dell'attacco cloud avanzato, eseguita però senza intervento umano tra le fasi. Il punto di ingresso è stato il Server-Side Request Forgery (SSRF), una vulnerabilità consolidata che permette a un server di effettuare richieste verso endpoint interni o esterni controllati dall'attaccante. Zealot ha sfruttato questa condizione per raggiungere il metadata service di Google Cloud Platform.
Da lì, il sistema ha estratto credenziali esposte dal metadata service, meccanismo noto da anni ma ancora ricorrente in configurazioni non hardened. Con credenziali valide in mano, l'agente ha proceduto all'impersonazione di un service account, ottenendo così privilegi IAM sufficienti per interrogare risorse del target. La fase terminale è stata l'esfiltrazione di dati da BigQuery, servizio di data warehouse analytics di Google Cloud.
Ogni passaggio sfrutta tecniche documentate e mitigazioni note da tempo. La novità non sta nella catena in sé, ma nella sua esecuzione autonoma e nella velocità di concatenamento. Un attaccante umano esperto richiederebbe minuti o ore per verificare condizioni, adattarsi a risposte impreviste, correggere traiettorie. Zealot ha dimostrato che questo processo decisionale può essere compresso in cicli machine senza degradamento della precisione tattica.
"The findings from this PoC reveal that although AI does not necessarily create new attack surfaces, it serves as a force multiplier, rapidly accelerating the exploitation of well-known, existing misconfigurations." — Unit 42 (Palo Alto Networks)
Perché i sistemi decentralizzati puri hanno fallito
La scelta del modello supervisor-agent non è stata teorica ma empirica. Gli sperimentatori di Unit 42 hanno confrontato direttamente le due architetture e documentato i limiti dell'approccio decentralizzato. Quando più agenti autonomi operano senza coordinamento gerarchico, emergono competizioni su risorse comuni, ripetizione di ricognizioni già eseguite da altri nodi, decisioni contraddittorie che annullano progressi precedenti.
Il supervisore introduce un vincolo architetturale che alcuni ricercatori di AI avversaria considerano limitante: centralizza il controllo e introduce un single point of failure. Tuttavia, nel contesto offensivo cloud, questo trade-off ha pagato in affidabilità operativa. Il supervisore mantiene uno stato globale dell'operazione, valuta le intelligence provenienti dagli specialisti e riordina le priorità senza richiedere riconfigurazione manuale.
Questo risultato ha implicazioni oltre il red team automatizzato. Se il modello supervisor-agent si conferma superiore per operazioni complesse a più stadi, è probabile che anche sistemi difensivi multi-agente adotteranno gerarchie simili per la risposta a incidenti, creando una specie di convergenza architetturale tra attacco e difesa.
Cosa fare adesso
Il report Zealot non richiede panico per nuove vulnerabilità irrintracciabili, ma impone una riassegnazione prioritaria delle risorse difensive. Quattro azioni emergono con urgenza specifica:
Auditing sistematico delle IAM misconfigurations. La catena Zealot dipende da credenziali esposte e privilege escalation via service account. La revisione periodica dei binding IAM, della rotazione delle credenziali e della minimizzazione dei permessi metadata service deve passare da attività calendarizzata a processo continuo, con alert su ogni deviazione dalla baseline.
Monitoraggio comportamentale su credenziali valide. Poiché l'AI attua con credenziali legittime, la detection non può più affidarsi solo alla segnalatura di accessi anomali geografici o orari. È necessario profilare il comportamento tipico di ogni service account e generare alert su pattern di interrogazione BigQuery, frequenza di chiamate API o sequenze di azioni che deviano dal profilo stabilito.
Restrizione del metadata service e network segmentation. L'accesso al metadata service da posizioni non autorizzate deve essere bloccato a livello network, non solo di applicazione. L'impiego di Workload Identity o alternative che non espongono credenziali direttamente nel metadata endpoint riduce la superficie utile a SSRF chained attacks.
Valutazione del red team con agenti AI. I programmi di red team devono integrare test con sistemi agentic per verificare la resilienza contro attacchi che non seguono playbook umani prevedibili. Questo non sostituisce gli esercizi con operatori umani, ma ne completa la copertura su aspetti di velocità, persistenza e variazione tattica.
Il vero spostamento: da tool a operatore autonomo
Zealot si inserisce in un arco più amplo di sperimentazioni che testano il confine tra tool assistito e operatore indipendente. La differenza qualitativa è che un tool tradizionale esegue comandi dati; un sistema agentic formula sotto-obiettivi, valuta risultati intermedi, adatta la strategia. Unit 42 ha dimostrato che questo salto è già tecnicamente realizzabile in ambienti cloud standard con tecniche note.
La dichiarazione di LLM-agnosticità ha un corollario importante: la barriera all'ingresso non è il possesso di un modello proprietario costoso, ma la capacità di orchestrare architetture agentic con qualsiasi endpoint disponibile. Questo democratizza potenzialmente la riproducibilità del PoC, aumentando il pressure per difensori che non possono più contare sulla scarsità di strumenti avanzati come fattore di mitigazione implicita.
Restano zone d'ombra. Il testo troncato non permette di ricostruire le funzioni precise di tutti gli specialisti né di valutare se Zealot sia stato riprodotto su AWS, Azure o altri provider. Non sono disponibili metriche quantitative su tasso di successo, latenza di esecuzione o costo computazionale per catena completata. Questi limiti non attenuano la validità della dimostrazione, ma indicano dove la ricerca può e deve essere estesa.
FAQ
Zealot è una minaccia attiva nel cloud pubblico?
No. È un proof of concept eseguito in sandbox controllata da Unit 42 per dimostrare capacità tecniche, non un malware o un attacco osservato in the wild.
L'architettura LLM-agnostic significa che funziona con qualsiasi modello?
Gli autori dichiarano che qualsiasi modello può essere selezionato per ciascun agente, ma non specificano quali siano stati effettivamente testati né se performance e affidabilità siano equivalenti tra modelli diversi.
Perché il metadata service GCP resta un punto di ingresso dopo anni di avvisi?
Perché la sua esposizione dipende da configurazioni applicative e network che spesso non vengono riviste in ambienti dinamici o legacy. Zealot dimostra che questo gap di hardening non è accademico: è sfruttabile automaticamente.
Fonti
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.