Google: primo zero-day AI in-the-wild, bypass 2FA rilevato
GTIG: primo zero-day AI in-the-wild, script Python bypassa 2FA su tool admin open-source. Marcatori LLM nel codice rivelano la genesi automatizzata e comprimono
Contenuto
Il 2026-05-11 il Google Threat Intelligence Group ha reso noto di aver identificato con alta confidenza il primo zero-day exploit in-the-wild il cui sviluppo è stato supportato da un modello AI. Lo script Python, scoperto nel corso di un'operazione di mass exploitation condotta da un gruppo cybercriminale, bypassa il meccanismo di autenticazione a due fattori su un diffuso tool open-source di amministrazione web-based. La novità non è solo il danno potenziale, ma il fatto che i marcatori stilistici degli LLM nel codice — docstring didattiche, un punteggio CVSS allucinato e formattazione iper-strutturata — costituiscono ora un nuovo indicatore di compromissione, rendendo la detection più complessa.
- Il Google Threat Intelligence Group attribuisce con "high confidence" a un modello AI il supporto nella scoperta e weaponizzazione della falla, pur escludendo l'uso di Gemini.
- L'exploit è uno script Python che sfrutta una semantic logic flaw, ovvero una hard-coded trust assumption, per aggirare il 2FA su un noto tool di system administration; il nome del software non è stato reso pubblico.
- Il codice presenta marcatori stilistici inequivocabili degli LLM: abbondanti docstring educative, un punteggio CVSS inventato e una formattazione Pythonica "da manuale" che tradiscono la sua origine automatizzata.
- Google ha coordinato la responsible disclosure con il vendor interessato, garantendo il rilascio della patch e interrompendo proattivamente la campagna di mass exploitation.
Come Google ha riconosciuto le impronte dell'IA nel codice
GTIG ha analizzato lo script Python recuperato durante l'operazione e ha isolato elementi altamente caratteristici dei dati di training degli LLM. Il codice contiene abbondanti docstring educative, un punteggio CVSS allucinato — ovverosia inventato dal modello generativo — e una formattazione Pythonica strutturata di tipo "textbook", oltre a classi ANSI per la colorazione del testo.
"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" — Google Threat Intelligence Group (GTIG)
"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", ha dichiarato il GTIG nel report. La firma digitale dell'intelligenza artificiale diventa così un nuovo artefatto forense, sfidando i tradizionali modelli di attribution basati esclusivamente su comportamenti runtime o infrastrutturali. I ricercatori sottolineano che la capacità di distinguere codice umano da codice AI-generated rappresenterà un tassello critico per i team di threat intelligence nei prossimi mesi.
La falla logica che bypassa il 2FA senza RCE
La vulnerabilità non è una classica buffer overflow o un errore di memory corruption, bensì una semantic logic flaw generata da una hard-coded trust assumption all'interno del tool di amministrazione open-source. Lo sfruttamento richiede credenziali valide: una volta in possesso di username e password, l'attaccante utilizza lo script per ingannare il flusso di autenticazione e neutralizzare il controllo del secondo fattore. Il risultato è un bypass 2FA, non un'esecuzione remota di codice.
Questa distinzione è rilevante perché dimostra come gli LLM possano individuare e sfruttare debolezze di design architetturale, non solo bug di implementazione, abbassando la soglia per attacchi sofisticati anche a operatori che non possiedono competenze tradizionali di reverse engineering. Il rischio concreto è l'espansione del numero di attori in grado di produrre zero-day funzionali a partire da semplici descrizioni semantiche di un flusso applicativo.
Operazione di mass exploitation e responsible disclosure
L'attività è stata classificata da Google come una "mass vulnerability exploitation operation" pianificata da cybercriminali collaborativi. L'obiettivo appariva la compromissione su larga scala di installazioni del tool open-source, sfruttando lo zero-day prima che il vendor potesse reagire e distribuire un aggiornamento. Google ha tuttavia collaborato strettamente con il produttore del software per una disclosure responsabile, assicurando il rilascio tempestivo della patch e interrompendo proattivamente la campagna in corso.
Il nome del tool e l'identità specifica del gruppo non sono stati divulgati, limitando la visibilità sull'entità geografica o settoriale della minaccia, ma confermando che il ciclo discovery-exploitation-patch si è compresso a un ritmo senza precedenti. Questa accelerazione impone ai vendor di ridefinire gli SLA interni di risposta alle vulnerabilità, considerando che il tempo di weaponizzazione potrebbe ora essere misurato in giorni anziché settimane.
Compressione dei tempi: quando l'exploit generation diventa commodità
Ryan Dewhurst, watchTowr Head of Threat Intelligence, ha commentato che l'intelligenza artificiale sta già accelerando la scoperta delle vulnerabilità, riducendo lo sforzo necessario per identificare, validare e weaponizzare le falle. "AI is already accelerating vulnerability discovery, reducing the effort needed to identify, validate, and weaponize flaws... We're not heading toward compressed timelines; we've been watching the timelines compress for years", ha affermato. L'incidente GTIG conferma questa tendenza: la generazione automatizzata di exploit funzionali a partire da logic flaw semantiche annulla il vantaggio temporale tradizionalmente goduto dai vendor tra segnalazione privata e abuso in-the-wild.
Se un modello AI può produrre uno script capace di bypassare meccanismi critici come il 2FA, la finestra di reazione si restringe drasticamente, obbligando i team di sicurezza a mantenere patch cycle sempre più aggressivi.
Cosa fare adesso
- Audit dei flussi 2FA nei tool open-source di amministrazione: verificare che l'autenticazione a due fattori non si basi su logiche di trust statiche o hard-coded assumption, ma su validazioni dinamiche indipendenti dal flusso principale di login. Ogni pannello admin web-based va ispezionato per assicurarsi che il secondo fattore non possa essere scavalcato manipolando parametri di sessione o header HTTP.
- Ridurre i tempi del vulnerability disclosure interno: la generazione AI-assisted di exploit comprime drasticamente l'intervallo tra la scoperta di una falla e il suo abuso in-the-wild. I programmi di bug bounty e i processi di triage devono essere ottimizzati per garantire patch in tempi molto più stretti rispetto agli SLA tradizionali.
- Addestrare la detection ai marcatori stilistici dell'AI: i team di threat intelligence devono integrare negli strumenti di code analysis e sandboxing l'identificazione di pattern LLM, come docstring eccessivamente didattiche, punteggi CVSS non verificati e formattazione Pythonica iper-standard, trattandoli come nuovi IoC (Indicator of Compromise).
- Segmentare e ridurre la superficie esposta dei pannelli amministrativi: limitare l'accesso ai tool di system administration a range IP aziendali noti, VPN gestite o bastion host hardened, eliminando l'esposizione pubblica diretta. Anche in presenza di un bypass 2FA, la segmentazione di rete può bloccare la catena di compromissione prima che l'attaccante raggiunga infrastrutture critiche.
Il caso GTIG non è un allarmismo sulle AI autonome, ma la conferma empirica che gli LLM stanno diventando strumenti standard nel kit degli attaccanti. La vera sfida per la difesa si sposta verso l'identificazione delle impronte stilistiche della generazione automatica, un dominio in cui il detection engineering deve ancora maturare rapidamente. Quando l'exploit generation diventa commodità accessibile anche a cybercriminali non-elite, la differenza tra sicurezza e compromissione si misura in finestre di reazione che il landscape tradizionale non è preparato a gestire.
FAQ
Lo zero-day identificato da Google permette l'accesso remoto senza alcuna credenziale?
No. Lo sfruttamento richiede credenziali valide per aggirare il flusso di autenticazione a due fattori tramite una semantic logic flaw. Non si tratta di una vulnerabilità di esecuzione remota di codice, ma di un bypass logico del 2FA.
Perché Google attribuisce l'exploit a un modello AI e non a un programmatore umano esperto?
Gli analisti di GTIG hanno rilevato marcatori stilistici altamente caratteristici dei training set degli LLM: docstring educative eccessive, un punteggio CVSS allucinato — ovvero inventato dal modello — e una formattazione Pythonica strutturata di tipo "textbook". Questi elementi, combinati, giustificano la valutazione di "high confidence" sull'uso di un AI model, sebbene non vi sia evidenza che si tratti specificatamente di Gemini.
Quali contromisure pratiche possono adottare le aziende se il nome del tool vulnerabile non è stato divulgato?
È necessario applicare rigidi principi di hardening su ogni pannello di amministrazione web-based: segmentazione di rete, autenticazione a due fattori su logiche dinamiche, monitoraggio continuo dei log di autenticazione e riduzione della superficie esposta. Queste misure riducono il rischio indipendentemente dal software specifico utilizzato.
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.