Agenti AI: migliaia di credenziali rubate in meno di sei ore

Il tempo che separa "abbiamo trovato un modo per entrare" da "abbiamo migliaia delle tue credenziali" si misurava in giorni di lavoro manuale e paziente. L'8 settembre il Threat Intelligence Group di Google ha pubblicato un report che descrive un caso in cui quel tempo è sceso a meno di sei ore — e gran parte del lavoro in mezzo l'hanno fatto degli agenti AI, non delle persone. Non è un risultato da benchmark né una demo di red team: sono dati di incident response di Mandiant su un attore reale e finanziariamente motivato, e spostano la storia dell'"AI che attacca" dal proof-of-concept alla colonna operativa.

Cosa ha osservato davvero il GTIG di Google

Nel report From Prompting to Autonomy: The Evolution of Adversarial AI, il GTIG descrive un sospetto attore finanziariamente motivato che ha compromesso l'infrastruttura cloud di un'organizzazione e, da dentro quel perimetro, ha dispiegato un framework di attacco autonomo e multi-agente. Nelle parole del GTIG, questo "ha permesso all'attaccante di operare a una scala e a una velocità tipicamente associate a gruppi più grandi e con più risorse".

I meccanismi meritano una lettura ravvicinata, perché sono banali in un modo che li rende ripetibili:

• L'operatore è partito da un chatbot di coding AI, un prompt e un set di istruzioni per l'agente — di fatto un playbook in markdown — usandolo per pianificare, costruire ed eseguire la campagna.
• Le istruzioni consentivano all'AI di gestire in autonomia la pipeline di scansione delle vulnerabilità e di eseguire troubleshooting in tempo reale quando qualcosa si rompeva, senza un operatore che seguisse ogni passo.
• Il framework eseguiva la logica di rotazione degli IP senza intervento manuale e, poiché girava dentro il cloud della vittima, instradava il traffico d'attacco attraverso indirizzi IP legittimi già considerati affidabili dal bersaglio.
• Stato finale: migliaia di credenziali di terze parti compromesse, in meno di sei ore, dall'inizio alla fine.

Sia The Hacker News sia BleepingComputer hanno ripreso il report; il filo conduttore è sempre la stessa frase su cui il GTIG continua a tornare — la campagna ha "ridotto drasticamente la latenza dell'intervento umano nel loop".

Da prompting ad autonomia — l'arco che conta

Il titolo del report va letto come una linea temporale. Un anno fa, le prime analisi del GTIG sull'AI avversaria documentavano attori che usavano i modelli come tutti gli altri: scrivere un'esca di phishing, tradurre una nota di riscatto, chiedere uno snippet di PowerShell. Quello era prompting — un umano alla tastiera, che copia le risposte da una finestra di chat.

Il report di settembre documenta il gradino successivo: l'uso agentico, in cui al modello si consegnano un obiettivo e un loop e lo si lascia correre. La distinzione non è accademica. Quando guida un umano, l'operazione va a velocità umana e ogni biforcazione è una decisione che qualcuno deve prendere. Quando guida un agente, le biforcazioni sono codice, e l'operazione va alla velocità dell'API.

Il GTIG è prudente — più prudente di gran parte della copertura giornalistica — su quanto lontano sia arrivata questa evoluzione:

"Sebbene le recenti divulgazioni di incidenti di sicurezza sui modelli dimostrino che i modelli di frontiera possono identificare autonomamente zero-day ed eseguire intrusioni di rete, il GTIG non ha ancora osservato attori che dispieghino pipeline pienamente autonome contro bersagli reali."

Quel distinguo è il cuore onesto della storia. Ciò che il GTIG ha visto è una maturazione graduale: avversari che "sovrappongono capacità AI" a un mestiere che avevano già, usando modelli commerciali e open-weight per accelerare la conversione di disclosure pubbliche e ritardi nelle patch in codice d'exploit n-day funzionante, passando "dalla semplice generazione di script e identificazione di errori logici alla costruzione di catene d'exploit multi-stadio funzionanti". Nessuno ha ancora messo in campo una macchina fire-and-forget che sceglie i propri bersagli e li viola senza sorveglianza. Ma il caso del furto credenziali mostra quanto poco del loop richieda ancora un umano, e quanto in fretta gli umani rimasti possano muoversi una volta automatizzate le parti noiose.

Perché "sei ore" è il numero che dovrebbe spaventare

L'istinto è fissarsi sul conteggio delle credenziali. Il numero che davvero ridisegna il modello di minaccia è l'orologio. L'economia della difesa si è sempre appoggiata al fatto che gli attacchi richiedono tempo — tempo per allestire l'infrastruttura, per scansionare, per triare i risultati, per pivotare quando uno scanner lancia un errore alle 2 di notte e l'operatore dorme. Ognuno di quei ritardi è una finestra in cui chi difende può agire.

Un framework agentico riduce quelle finestre verso lo zero, e lo fa in modo disomogeneo lungo la kill chain:

Fase	Squadra umana tradizionale	Framework agentico (secondo GTIG)
Build di tooling e framework	giorni	un prompt, minuti
Gestione pipeline di scansione	manuale, limitata ai turni	autonoma, continua
Troubleshooting di uno step rotto	attende un operatore	in tempo reale, nel loop
Rotazione IP / evasione	scriptata, supervisionata	eseguita senza intervento
Credenziali su scala	variabile, manuale	migliaia in meno di 6h

La conseguenza operativa è che il budget di detection-to-containment che molti SOC assumono in silenzio — le ore tra quando una scansione compare nei log e quando un analista ci arriva — è ora più ampio dell'intero attacco. Se il vostro tempo medio per accorgervene si misura in giorni, una campagna agentica di furto credenziali è già finita, il bottino piazzato e il suo appiglio nel cloud riconvertito, prima che il primo ticket sia stato triato.

C'è un effetto di secondo ordine che il report nomina esplicitamente: l'attore ha operato dal cloud della vittima, attraverso IP legittimi. Il blocco basato su reputazione e geolocalizzazione — una fetta enorme di ciò che gli strumenti perimetrali fanno davvero — è cieco davanti al traffico che origina dentro un tenant fidato. L'evasione qui non è malware ingegnoso; è una rubrica di indirizzi che avete già messo in whitelist.

L'altra metà: malware che attacca l'AI nella vostra pipeline

La campagna di credenziali è il titolo, ma lo stesso report documenta il rovescio del mestiere agentico — malware costruito per sovvertire gli strumenti AI su cui difensori e sviluppatori ora si appoggiano. L'esemplare più netto è DUSTMAKER, un infostealer cross-platform tarato per gli ambienti CI/CD. Ciò che fa è un'anteprima di dove sta andando la supply chain:

• Legge i token OIDC direttamente dalla memoria del processo del runner di GitHub Actions, poi li usa per pubblicare pacchetti avvelenati che portano attestazioni di provenienza SLSA Build L3 valide — firmate, attestate e fidate da ogni consumatore a valle. Se pensate che un check di provenienza verde significhi artefatto pulito, ne abbiamo scritto mesi fa: firmato non vuol dire sicuro.
• Deposita payload in directory di configurazione nascoste degli agenti — .claude/, .cursor/, .vscode/ — e usa il prompt injection dentro quei file di config per istruire l'assistente AI dello sviluppatore a eseguire comandi arbitrari, trasformando l'agente di coding nell'esecutore del malware stesso.
• I suoi loader JavaScript incorporano prompt avversari mirati agli scanner di sicurezza basati su LLM, così lo step di revisione automatica che avrebbe dovuto intercettarlo viene convinto a non segnalarlo.

Ecco la parte su cui vale la pena fermarsi: l'attaccante non solo usa l'AI per muoversi più in fretta, ma prende di mira l'AI che avete dispiegato per difendervi. Uno scanner di sicurezza che legge testo controllato dall'attaccante e ci agisce sopra è un vicedelegato confuso con un modello linguistico attaccato. Il GTIG ha tracciato anche attori come UNC6780 (TeamPCP) che lo fanno a livello di ecosistema — ingannando assistenti di coding AI e scanner LLM per farsi passare compromissioni open-source nella supply chain.

Difendersi dalle campagne d'attacco agentiche

Non c'è una singola patch qui, perché non c'è un singolo CVE — è un cambio di mestiere, e le difese sono architetturali. Prime mosse concrete:

1. Trattate ogni credenziale come effimera. Tutto il valore della campagna erano le migliaia di segreti riutilizzabili raccolti. Restringete e ruotate le API key con aggressività, preferite la workload identity federation ai token a lunga vita, e imponete un TTL rigido a tutto ciò che un agente potrebbe raccogliere. Una credenziale che scade in un'ora vale poco per una campagna di sei ore.
2. Guardate l'egress dal vostro cloud, non solo l'ingress verso di esso. L'attore operava da dentro un tenant fidato. Il monitoraggio comportamentale dell'egress — un host che storicamente solo riceve dati e all'improvviso lancia scansioni a ventaglio, un workload che fa beaconing verso infrastruttura mai vista, richieste sostenute a forma di credenziale verso terze parti — è la superficie che intercetta tutto questo. Le liste di reputazione no.
3. Assumete che i vostri strumenti AI siano una superficie d'attacco. Isolate in sandbox ciò che gli agenti di coding possono eseguire, trattate i file di config dei repository (.claude/, .cursor/, .vscode/) come input non fidato, e non lasciate mai che uno scanner LLM compia un'azione basandosi solo sul testo letto dall'artefatto in revisione.
4. Non trattate la provenienza come un certificato di pulizia. Le attestazioni SLSA provano dove è stato eseguito un build, non che i suoi input fossero onesti. Affiancate alla provenienza l'analisi comportamentale di ciò che il pacchetto fa davvero in fase di installazione.
5. Comprimete il vostro loop di reazione. La verità scomoda del numero "sei ore" è che i pentest trimestrali e i digest SIEM del mattino dopo sono ormai più lenti dell'attacco. Se l'offesa gira in continuo, anche la difesa deve farlo.

La simmetria scomoda: testare un attaccante autonomo

L'ultimo punto è dove atterra la conclusione onesta, e non è comoda per il modello del pentest annuale. Non si può provare in modo significativo la difesa contro una macchina che costruisce una campagna in sei ore prenotando un consulente umano per due settimane il trimestre prossimo. Il ritmo deve corrispondere.

È il problema attorno a cui Zero Hunt è nata, perché la risposta a un attaccante autonomo e multi-agente è un validatore autonomo e multi-agente che gira sullo stesso orologio. Il motore di Zero Hunt è uno sciame di 10 agenti AI — Recon, Exploit, Web, Credential, Post-Exploit, Pivot, Tactic e Report sotto un AI Controller — che coordina come faceva il framework del GTIG, solo puntato sul vostro perimetro e con la vostra autorizzazione. Scrive codice d'exploit per-bersaglio con un LLM locale invece di rigiocare ExploitDB, e ogni nuova skill è validata in backtest nell'AI Gym (316/317 esercizi Vulhub, i corpus NYU CTF e Vulhub-Bench) prima di toccare un ingaggio in produzione. Soprattutto, le sue campagne change-triggered avviano una valutazione completa entro un'ora dalla comparsa di un nuovo asset sul perimetro — lo stesso collasso della finestra di reazione, ma che lavora per voi invece che contro di voi. E poiché gira 100% on-prem contro un modello locale, non state spedendo la vostra superficie d'attacco ai modelli di frontiera commerciali che il report mostra gli avversari interrogare per ottenere codice d'exploit.

Anche la metà del furto credenziali ha una risposta sul traffico. Il modello di AI Traffic Analysis di Zero Hunt — quattro teste di inferenza su miliardi di sequenze PCAP, a 2.7+ Gbit/s sulla GPU dell'appliance — legge il comportamento di una campagna di harvesting: il ventaglio delle scansioni, l'egress a forma di credenziale, la cadenza di rotazione degli IP, l'uscita improvvisa da un host che finora solo riceveva. Lo fa sul filo, mentre accade, che è l'unico posto dove il traffico instradato attraverso i vostri IP cloud fidati resta onesto. Il blocco per reputazione vede un indirizzo in whitelist; il modello vede un workload che fa qualcosa che non ha mai fatto.

Sei ore non è un numero che si batte con più personale. È un numero che si batte sul tempo, o si perde la corsa prima di sapere che è iniziata.