Google: scoperto primo zero-day AI in-the-wild, bypassa 2FA
Google conferma: zero-day AI in-the-wild aggira 2FA su tool open-source. Il report GTIG rivoluziona il threat model per difensori.
Contenuto
Il Google Threat Intelligence Group ha rivelato l'11 maggio di aver individuato uno zero-day exploit in-the-wild, scritto in Python e in grado di bypassare la 2FA su uno strumento open-source web-based. L'analisi rileva con alta confidenza l'impiego di un modello AI/LLM nella sua creazione, segnalando il primo caso noto e confermato pubblicamente da un vendor di una vulnerabilità weaponizzata con impronte digitali artificiali. La notizia accorcia la distanza tra scoperta logica e exploit funzionante, obbligando difensori e vendor a ripensare il threat model legato agli LLM usati offensivamente.
- L'exploit sfrutta una falla logica semantica legata a un'assunzione di fiducia hard-coded nel tool open-source, richiedendo credenziali utente valide per l'attivazione.
- Gli analisti di Google hanno identificato indicatori stilistici AI nel codice Python, tra cui docstring didascaliche, un punteggio CVSS allucinato e una struttura Pythonic standardizzata tipica dei dati di training degli LLM.
- Google ha collaborato con il vendor colpito per una disclosure responsabile e il rilascio della patch, omittendo però di divulgare il nome del software e dell'attore responsabile.
- L'operazione rientra in una campagna di mass vulnerability exploitation coordinata da cybercriminali, che segna un punto di svolta nella weaponizzazione automatica delle vulnerabilità zero-day.
Uno zero-day Python che aggira la 2FA dopo il furto di credenziali
Secondo il report diffuso dall'11 maggio, l'exploit messo in luce da Google sfrutta una semantic logic flaw contenuta in uno strumento di amministrazione web-based open-source. La vulnerabilità nasce da un'assunzione di fiducia hard-coded che consente a un utente munito di credenziali valide di saltare il flusso di verifica della 2FA. Non si tratta di un brute-force contro i token o di un bypass universale, ma di un percorso logico interno che neutralizza il secondo fattore una volta superata la prima barriera.
La natura in-the-wild dell'arsenale conferma che il codice non era un proof-of-concept accademico, ma uno strumento attivamente impiegato in operazioni cybercriminali. Google ha definito la campagna come una mass vulnerability exploitation operation, sottolineando la capacità degli attori di coordinare lo sfruttamento su larga scala. L'assenza di dettagli sul vendor e sul gruppo responsabile, scelta per tutelare gli utenti in attesa di aggiornamenti, lascia tuttavia aperta la questione della superficie di attacco reale già compromessa.
Docstring educative e CVSS allucinato: i segni dell'IA nel codice
Gli investigatori di Google non hanno basato la loro valutazione su intuizioni, ma su artefatti stilistici ricorrenti all'interno dello script. Il codice presenta docstring didascaliche eccessivamente dettagliate, un punteggio CVSS allucinato inserito direttamente nei commenti e una formattazione Pythonic rigida, con menu di aiuto strutturati e una classe ANSI per i colori scritta in modo pulito e standardizzato. Elementi che, presi singolarmente, potrebbero sembrare pedanteria del programmatore, ma che nel loro insieme compongono un profilo stilometrico compatibile con l'output di un modello linguistico addestrato su corpus tecnici.
"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 (GTIG), via SecurityWeek
L'identificazione di un CVSS inventato all'interno del codice è particolarmente significativa: il modello ha generato un valore di gravità plausibile a prima vista, ma non ancorato a una valutazione reale della vulnerabilità. Questo tipo di allucinazione, tipica degli LLM generativi, costituisce per Google un'impronta digitale quasi forense, che separa il lavoro di un analista umano esperto da quello di una pipeline automatizzata di weaponizzazione.
Google esclude Gemini ma conferma l'uso di un LLM da parte degli attaccanti
Nella pubblicazione dell'11 maggio, Google Threat Intelligence Group ha esplicitamente escluso l'impiego di Gemini per la creazione dello zero-day, pur confermando l'alta confidenza nell'uso di un modello AI da parte degli attori malintenzionati. La distinzione è rilevante: non si tratta di un autogol del proprio ecosistema, ma della conferma che strumenti linguistici di terze parti o open-source sono già stati integrati nella catena di attacco cybercriminale. Google non ha però specificato quale LLM sia stato coinvolto, lasciando il campo apertamente classificato o, quanto meno, non attribuito.
La dichiarazione di Google, riportata da SecurityWeek, pone un paletto normativo e tecnico: per la prima volta un vendor di threat intelligence mainstream attribuisce con alta confidenza uno zero-day in-the-wild a un processo di authoring AI. L'implicazione è che la curva di apprendimento necessaria per identificare e sfruttare flaw logici complessi si è appiattita, permettendo a gruppi cybercriminali di scalare la fase di weaponizzazione senza competenze di reverse engineering tradizionali.
Cosa fare adesso
La conferma di uno zero-day AI-generated in circolazione attiva impone alle organizzazioni un ripensamento immediato delle strategie di autenticazione e monitoraggio. Ecco quattro priorità operative.
- Auditare i flussi di autenticazione dei tool open-source web-based interni, verificando l'assenza di assunzioni di fiducia hard-coded che potrebbero essere aggirate dopo la compromissione di credenziali.
- Rinforzare l'autenticazione con fattori aggiuntivi indipendenti dal flusso applicativo principale, privilegiando l'adaptive authentication basata su comportamento e contesto piuttosto che flussi 2FA sequenziali rigidamente accoppiati.
- Introdurre nella code review e nel SAST la ricerca di pattern stilistici tipici dei LLM, come docstring eccessivamente didascaliche o punteggi CVSS inline, per individuare codice potenzialmente generato artificialmente inserito nelle repository.
- Mappare le dipendenze da tool di amministrazione web-based open-source con accesso privilegiato, assicurando che la compromissione delle credenziali utente non consenta il salto di fase dell'autenticazione a due fattori senza allarmi in tempo reale.
Il confine tra proof-of-concept teorico e arma in-the-wild si è appena assottigliato in modo misurabile. Non serve più immaginare uno scenario distopico: l'evidenza pubblicata da Google dimostra che attori cybercriminali hanno già integrato gli LLM nella catena di weaponizzazione, riducendo la curva di apprendimento umana per scovare e sfruttare flaw logici.
Per chi difende reti e applicazioni, questo significa che la velocità di adattamento offensiva ha superato quella delle patch tradizionali. La prossima generazione di autenticazione non può più prescindere da un modello di minaccia che consideri l'intelligenza artificiale come strumento di attacco già operativo.
Lo zero-day permette l'accesso senza alcuna credenziale?
No, secondo Google l'exploit richiede credenziali utente valide per attivare il bypass della 2FA. Non si tratta di un accesso indiscriminato, ma di un salto di fase dopo la compromissione iniziale.
È stato utilizzato Gemini per generare l'exploit?
No. Google Threat Intelligence Group ha esplicitamente escluso l'impiego di Gemini, pur mantenendo alta confidenza che un altro modello AI/LLM sia stato coinvolto nella fase di discovery e weaponization.
Perché non viene rivelato il nome del tool vulnerabile?
Google ha coordinato la disclosure responsabile con il vendor interessato, preferendo non divulgare pubblicamente il nome del software e dell'attore per disruzione proattiva e tutela degli utenti non ancora aggiornati.
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.