Google blocca il primo zero-day AI: bypass 2FA su tool admin
Google blocca il primo zero-day AI per bypassare la 2FA su tool open-source, interrompendo una mass exploitation operation pianificata prima del lancio.
Contenuto
L’11 maggio 2026 il Google Threat Intelligence Group ha identificato e interrotto uno zero-day exploit sviluppato con un modello di intelligenza artificiale per bypassare l’autenticazione a due fattori su un diffuso tool open-source di system administration. La scoperta segna la prima volta che un codice exploit generato da LLM viene intercettato prima di una mass exploitation operation pianificata da un gruppo cybercriminale. La posta in gioco è immediata: la weaponizzazione industriale dell’AI sta comprimendo i cicli tra scoperta e attacco contro strumenti che amministrano infrastrutture critiche.
- Un modello AI non meglio specificato — ma escluso Gemini — ha generato uno zero-day per bypassare la 2FA su un tool open-source, sfruttando una semantic logic flaw legata a una trust assumption hard-coded.
- Il Google Threat Intelligence Group ha interrotto l’operazione prima del lancio massiccio, coordinando la responsible disclosure direttamente con il vendor interessato.
- L’analisi del codice rivela hallmarks stilistici tipici dei dati di training degli LLM: docstrings didattiche, un punteggio CVSS allucinato e una struttura Pythonic da manuale con classi ANSI color.
- L’exploit richiede credenziali valide per funzionare, ma dimostra che l’intelligenza artificiale può individuare e weaponizzare logic flaws semantici oltre a simple syntax bugs.
Come funziona il bypass del 2FA generato da AI
Lo script Python sfrutta una semantic logic flaw legata a una trust assumption hard-coded all’interno del codice del tool open-source. Per essere attivato, l’attacco richiede comunque credenziali valide: non si tratta di una vulnerabilità pre-autenticazione, ma di un abuso semantico della logica applicativa che neutralizza il controllo del secondo fattore. Secondo il GTIG, questa capacità di individuare flaw logici e non semplici errori di sintesi rappresenta un salto qualitativo rispetto agli usi tradizionali dell’AI nel cybercrime.
La distinzione è rilevante perché gli strumenti di difesa tradizionali — WAF, IDS e scanner SAST/DAST — sono ottimizzati per rilevare pattern di attacco noti o deviazioni sintattiche, non per interrogare la semantica delle autorizzazioni. Un attacco che sfrutta una trust assumption hard-coded può quindi apparire del tutto legittimo nel traffico di rete, rendendo la detection significativamente più complessa.
Gli hallmarks che tradiscono il codice scritto da un LLM
L’analisi tecnica del Google Threat Intelligence Group ha rilevato nel codice tracce stilistiche altamente caratteristiche dei dataset di training degli LLM. Il file presenta abbondanti docstrings didattiche, include un punteggio CVSS allucinato e adotta una struttura Pythonic ordinata, con classi ANSI color e menu di aiuto dettagliati.
«For example, the script contains an abundance of educational docstrings, including a hallucinated CVSS score, and uses a structured, textbook Pythonic format highly characteristic of LLMs training data (e.g., detailed help menus and the clean _C ANSI color class)», si legge nel report ufficiale del GTIG. La valutazione di high confidence resta inferenziale: non esistono artefatti di provenienza assoluta, ma la firma stilistica è ritenuta inequivocabile dagli analisti.
L’operazione di mass exploitation interrotta
Il gruppo cybercriminale stava preparando una mass vulnerability exploitation operation che avrebbe colpito in modo diffuso il tool di amministrazione. Il Google Threat Intelligence Group ha interrotto l’infrastruttura offensiva prima del lancio, coordinando la responsible disclosure direttamente con il vendor interessato. Non è noto il nome del software vulnerabile né l’identità specifica degli attaccanti, elementi non divulgati per tutelare la catena di risposta e prevenire copie immediate dell’exploit.
La nuova frontiera: dai syntax bug ai logic flaw
Fino a oggi l’automazione offensiva si limitava a scannerizzare codici alla ricerca di syntax bug o configuration error noti. Lo zero-day intercettato dal GTIG dimostra invece che i modelli generativi possono scovare trust assumptions hard-coded, ovvero logic flaws semantici che dipendono dal contesto applicativo. Questa capacità abbassa drasticamente la soglia di accesso alla scoperta di vulnerabilità di design, un dominio che finora richiedeva intuizione umana e revisione manuale approfondita.
"Although we do not believe Gemini was used, based on the structure and content of these exploits, we have high confidence that the actor likely leveraged an AI model to support the discovery and weaponization of this vulnerability."
— Google Threat Intelligence Group (GTIG)
Cosa fare adesso
Verificare immediatamente se l’infrastruttura dipende dal tool open-source di system administration interessato e applicare con urgenza le patch che il vendor rilascerà a seguito della responsible disclosure coordinata da Google. Non è stato reso noto il nome del software, quindi le amministrazioni dovrebbero monitorare i canali ufficiali dei propri vendor per aggiornamenti inattesi critici.
Rafforzare il controllo dell’autenticazione a due fattori con meccanismi di session binding e verifica contestuale, senza considerare la mera presenza del 2FA come garanzia assoluta. Se la logica applicativa presenta trust assumptions hard-coded, un attore con credenziali valide può aggirare il secondo fattore a livello semantico, non tecnico.
Attivare logging avanzato e behavioral detection sui tool di amministrazione remota per identificare anomalie post-autenticazione. Un exploit che abusa di logic flaws semantiche può non lasciare tracce di buffer overflow o injection classiche, rendendo indispensabile il monitoraggio del comportamento dell’utente autenticato.
Valutare la migrazione verso standard FIDO2 e WebAuthn dove tecnicamente fattibile, riducendo la dipendenza da flussi 2FA basati su codici temporanei o push notification. Questi ultimi rimangono esposti a bypass logici quando la logica di business sottostante assume implicitamente che l’autenticazione iniziale sia sufficiente per tutte le operazioni successive.
Il messaggio per le aziende è che la linea di demarcazione tra proof-of-concept accademico e arma pronta all’uso si è spostata definitivamente verso il basso. Gli LLM non accelerano solo la scrittura di codice, ma iniziano a scalfire il dominio umano della ricerca vulnerability, individuando trust assumptions che i revisori tradizionali spesso danno per scontate. Per il settore della difesa, questo significa costruire controlli che resistano a una logica di attacco generata automaticamente, non solo a payload noti.
Domande e risposte
Perché l’exploit richiede credenziali valide se è classificato come zero-day?Lo zero-day sfrutta una semantic logic flaw che si attiva dopo l’autenticazione iniziale, neutralizzando il controllo del secondo fattore. Non è una vulnerabilità pre-auth, ma un abuso della logica interna che presuppone trust hard-coded una volta ottenuto l’accesso.
Su quale base il GTIG attribuisce l’exploit a un modello AI?La valutazione si fonda su hallmarks stilistici riconducibili ai dati di training degli LLM, come docstrings didattiche, un CVSS score allucinato e una struttura Pythonic da manuale. Google specifica tuttavia che non esistono artefatti di provenienza assoluta e che la confidence, sebbene high, rimane inferenziale.
Verrà reso noto il nome del tool vulnerabile?Al momento il vendor e il software interessati non sono stati divulgati per tutelare la responsible disclosure e impedire la replica immediata dell’exploit da parte di altri attori. Le aziende dovrebbero monitorare i canali ufficiali dei propri fornitori per advisory critici.
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.