Google scopre primo zero-day AI: bypass 2FA in tool admin open

Google Threat Intelligence: identificato il primo zero-day AI in-the-wild, bypass 2FA su tool admin open-source e prevenuto il mass exploitation criminale.

Contenuto

Google scopre primo zero-day AI: bypass 2FA in tool admin open
Google scopre primo zero-day AI: bypass 2FA in tool admin open

Il Google Threat Intelligence Group ha pubblicato l'11 maggio 2026 la prima analisi di uno zero-day exploit in-the-wild con evidenza convincente di assistenza da parte di un modello generativo di intelligenza artificiale. Lo script Python, intercettato prima del lancio di una campagna di mass exploitation pianificata da un gruppo cybercriminale, consente di bypassare l'autenticazione a due fattori su uno strumento open-source di amministrazione web-based molto diffuso. L'episodio conferma che gli LLM stanno abbassando la soglia tecnica per scoprire e armiare vulnerabilità logiche sottili, riducendo l'intervallo tra ricerca e weaponization.

Punti chiave
  • L'exploit si presenta come uno script Python che sfrutta una semantic logic flaw derivante da un'hard-coded trust assumption, anche se richiede credenziali valide per l'accesso iniziale.
  • Google esclude con high confidence l'uso di Gemini, ma riconosce indicatori stilistici inequivocabili di generazione o assistenza AI, come docstring educativi, un punteggio CVSS allucinato e una formattazione textbook Pythonic.
  • Un gruppo cybercriminale di rilievo aveva pianificato un'operazione di mass exploitation, interrotta dalla responsible disclosure di GTIG e dal rilascio tempestivo della patch da parte del vendor.
  • L'attacco non è un RCE pre-autenticazione: la minaccia risiede nella capacità di un modello AI di accelerare la discovery e la weaponization di flaw logiche complesse, comprimendo i tempi di reazione dei difensori.

Un bypass 2FA in Python con l'impronta dell'AI

L'analisi di GTIG si concentra su uno zero-day implementato in uno script Python che permette di eludere il secondo fattore di autenticazione su un tool di system administration web-based. Secondo il report ufficiale, la compromissione non avviene per forza bruta o furto di credenziali, ma sfruttando una falla logica semantica radicata in un'hard-coded trust assumption all'interno del flusso di verifica.

L'attaccante deve già disporre di credenziali valide, ma l'exploit annulla il controllo aggiuntivo del 2FA, trasformando un accesso legitimo in un punto di ingresso totale. Si tratta di una modalità subdola: non è un bug di memoria o un overflow, bensì un errore di progettazione logica che un modello AI ha apparentemente aiutato a individuare e incapsulare in codice funzionante.

La semantic logic flaw che aggira l'autenticazione

La vulnerabilità non risiede in una libreria vulnerabile o in un parsing errato, ma in una relazione di fiducia codificata in modo rigido tra i componenti del tool. Google descrive la falla come una semantic logic flaw: il sistema presuppone implicitamente che un determinato stato o ruolo sia sufficiente per saltare il secondo step di verifica, senza rivalidare la richiesta.

Questo genere di difetti è storicamente più difficile da individuare con gli strumenti automatici tradizionali, perché non genera crash né presenta pattern di corruzione di memoria. L'exploit Python traduce invece questa assunzione in una sequenza precisa di chiamate che ingannano il flusso di autenticazione, dimostrando una comprensione non banale dell'architettura target.

Indicatori stilistici: quando il codice tradisce il modello che l'ha scritto

La certezza di Google non si fonda su metadati o watermark, ma su un profilo stilistico altamente caratteristico degli output dei large language model. Gli analisti hanno rilevato docstring educativi e didascalici di tipo textbook, help menu dettagliati con classe ANSI color e, soprattutto, un punteggio CVSS allucinato non coerente con la reale severità della falla.

Questi elementi, pur non compromettendo la funzionalità maligna, costituiscono una firma comportamentale: il codice è tecnicamente valido, ma strutturato come se dovesse illustrare un concetto didattico piuttosto che operare in uno scenario offensivo. Per questo GTIG afferma con high confidence che un modello AI ha supportato la scoperta e la weaponization, pur escludendo che si tratti di Gemini.

"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

Mass exploitation prevenuta: la disclosure che ha fermato la campagna

La scoperta di GTIG ha interrotto un piano ben più ampio. Fonti di sicurezza identificano gli attori come un prominent cybercrime group che stava coordinando l'acquisizione massiva di accessi amministrativi attraverso lo sfruttamento sistematico dello zero-day. Grazie alla responsible disclosure condotta con il vendor, la patch è stata rilasciata prima che la campagna raggiungesse la fase di mass exploitation.

Non sono state rese note né l'identità esatta del gruppo, né il numero di partner criminali coinvolti nella pianificazione, né il nome del tool open-source interessato, omesso per tutela dei sistemi ancora in fase di aggiornamento.

Cosa fare adesso

Per le organizzazioni che impiegano strumenti di amministrazione web-based, l'incidente impone priorità immediate su più fronti.

  • Verificare che tutte le istanze di tool open-source per la system administration siano aggiornate alla patch più recente rilasciata dal vendor in seguito alla segnalazione di GTIG.
  • Rivedere le logiche di autenticazione degli strumenti critici, eliminando trust assumptions hard-coded che possano permettere il bypass di un fattore di verifica indipendente.
  • Attivare il monitoraggio comportamentale sui log di accesso amministrativo, ricercando anomalie nella sequenza di autenticazione anche quando le credenziali presentate sono formalmente valide.
  • Adattare i cicli di vulnerability assessment per includere la revisione manuale o semiautomatica delle logiche semantiche, oltre ai test di sicurezza tradizionali focalizzati su bug di memoria.

Perché questo zero-day cambia la percezione del rischio AI

L'angolo più disturbante dell'incidente non è la potenza dell'arma, ma la democratizzazione del processo che l'ha costruita. Non si tratta di un RCE su kernel o di un worm pre-autenticazione: è un bypass 2FA su flaw logica, un attacco raffinato ma non apocalittico. L'accelerazione avviene nella fase di ricerca e weaponization, dove un LLM sembra aver compresso drasticamente i tempi necessari a passare dalla comprensione dell'architettura all'exploit funzionante.

Ryan Dewhurst, head of threat intelligence di watchTowr, osserva che l'intelligenza artificiale sta già accelerando la discovery, riducendo lo sforzo per identificare, validare e armiare le flaw, e che i tempi di compressione tra scoperta e exploitation non sono una prospettiva futura, ma una realtà osservata da anni.

Il messaggio non è che un algoritmo abbia inventato una vulnerabilità dal nulla, ma che abbia permesso a un gruppo criminale di individuare e sfruttare una falla logica in tempi molto più rapidi. La barriera tecnica cade, il ciclo di weaponization si accorcia e la differenza tra vulnerabilità teoretica e exploit in-the-wild rischia di diventare una questione di giorni. Per i team difensivi, l'orizzonte si restringe: il patching reattivo potrebbe non bastare più.

Domande frequenti

Lo sfruttamento richiede credenziali rubate?
Sì, l'attacco presuppone che l'attore disponga già di credenziali valide per il primo step di accesso; l'exploit aggira esclusivamente il controllo del secondo fattore, non sostituisce l'autenticazione iniziale.
Perché Google esclude l'uso di Gemini?
Nel report ufficiale GTIG specifica di non ritenere che Gemini sia stato impiegato, basandosi sull'analisi strutturale e stilistica del codice; la high confidence sull'uso di un modello AI si riferisce invece a un generico sistema LLM, non identificato nel dettaglio.
È noto il nome del tool vulnerabile?
No. Il vendor e il nome dello strumento open-source sono stati omessi per responsible disclosure, al fine di permettere agli utenti di applicare le patch prima che i dettagli tecnici alimentino attacchi mirati.

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti

Link utili

Apri l'articolo su DeafNews