Google scopre primo zero-day generato da AI per bypass 2FA
GTIG: zero-day in Python per bypass 2FA di tool open-source, con alta confidenza generato da AI. Ecco perché cambia il calendario di difesa.
Contenuto
Il Google Threat Intelligence Group ha reso noto l’11 maggio 2026 di aver identificato uno zero-day exploit implementato in uno script Python in grado di bypassare l’autenticazione a due fattori di un diffuso tool open-source di system administration. La valutazione, condotta con il supporto di Mandiant, attribuisce all’attività una provenienza cybercriminale e sostiene con alta confidenza che la vulnerabilità sia stata scoperta e weaponizzata usando un modello di intelligenza artificiale generico. L’episodio segna un passaggio operativo concreto: per la prima volta un exploit zero-day funzionale, pensato per uno sfruttamento di massa, presenta le impronte digitali strutturali di un output LLM.
- Il Google Threat Intelligence Group ha individuato uno zero-day in uno script Python che bypassa il 2FA su un popolare tool open-source web-based di amministrazione di sistema, richiedendo credenziali valide per l’accesso iniziale.
- Google esclude con alta confidenza l’uso di Gemini, ma ritiene probabile il ricorso a un modello AI generico per la discovery e la weaponizzazione della falla logica.
- Il codice presenta docstrings educative, un punteggio CVSS allucinato e una struttura Pythonic altamente caratteristica dei dati di training degli LLM, elementi ritenuti prova dell’origine artificiale.
- La campagna è stata attribuita a threat actors cybercriminali che stavano pianificando una mass vulnerability exploitation operation; il vendor interessato ha ricevuto disclosure responsabile e un fix proattivo, senza che il nome del software sia stato reso pubblico.
Il bypass del 2FA nasce da una trust assumption hard-coded
L’exploit sfrutta una semantic logic flaw derivante da una hard-coded trust assumption nel tool open-source web-based preso di mira. Secondo il report di GTIG, riportato da The Hacker News, lo script Python consente il bypass del 2FA una volta ottenute credenziali valide, aprendo la strada a uno sfruttamento di massa qualora le credenziali siano trafugate tramite phishing o infostealer. La natura della falla non risiede in un errore di implementazione crittografica, bensì in una debolezza logica del flusso di autenticazione che l’attore ha saputo individuare e incanalare in un payload funzionale.
Questa tipologia di vulnerabilità è particolarmente insidiosa perché sfugge ai test di sicurezza convenzionali: il codice può essere sintatticamente corretto e perfino ben documentato, ma racchiudere assunzioni di trust che il flusso 2FA non invalida in modo esplicito. Gli auditor umani tendono a concentrarsi su buffer overflow, injection o flaw crittografici, mentre una semantic logic flaw richiede la comprensione contestuale dello stato applicativo, un ambito in cui gli LLM stanno dimostrando profili di attenzione diversi e sistematici rispetto ai controlli manuali tradizionali.
Le impronte LLM nel codice Python
La valutazione di Google si fonda sulla struttura stessa del codice. Secondo quanto riportato da GTIG, lo script contiene un’abbondanza di docstrings educative, include un punteggio CVSS allucinato e adotta un formato Pythonic strutturato, con elementi come una classe ANSI color denominata _C, ritenuti altamente caratteristici dei dati di training degli LLM. Questi dettagli hanno permesso agli analisti di formulare un giudizio di alta confidenza sull’origine artificiale dell’exploit, pur senza identificare il modello specifico impiegato.
La presenza di un punteggio CVSS allucinato all’interno delle docstrings rappresenta uno degli elementi che GTIG ha evidenziato come artefatto tipico dell’output dei grandi modelli linguistici, generato con intento didattico ma privo di fondamento nel contesto reale della vulnerabilità. La classe _C per la colorazione ANSI, abbinata a una struttura codicistica pulita e didascalica, ha contribuito alla valutazione secondo cui il codice non sia stato prodotto manualmente da un exploit developer tradizionale, bensì generato o fortemente assistito da un sistema AI generico: Google esclude con alta confidenza il coinvolgimento 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, via SecurityWeek
Cybercriminali e la logica dello sfruttamento di massa
L’operazione è stata ricondotta a cybercrime threat actors che, secondo Google, stavano pianificando una mass vulnerability exploitation operation. Non è tuttavia chiaro se l’exploit sia stato effettivamente dispiegato in-the-wild o se la campagna sia stata intercettata in fase preparatoria, prima del fix proattivo coordinato con il vendor. Il nome del gruppo non è divulgato, né è stata resa pubblica l’identità del tool vulnerato, per contenere il rischio di replica fino all’adozione generalizzata della patch.
La scelta di non rivelare il nome del software riflette una strategia di contenimento volta a ridurre il rischio di replica, limitando la divulgazione agli ambienti già esposti o a chi disponga di credenziali valide per quel sistema specifico. La pianificazione di una mass vulnerability exploitation operation, tuttavia, indica che gli attori consideravano la falla adatta a una distribuzione su larga scala, presumibilmente attraverso l’uso combinato di accessi ottenuti tramite tecniche di credential harvesting precedenti all’exploit vero e proprio.
Il tempo compresso tra scoperta e weaponizzazione
L’angolo più disturbante dell’incidente non è la sola capacità di un modello AI di scrivere codice malevolo, ma la velocità con cui la fase di discovery si è trasformata in un payload operativo pronto per la distribuzione su larga scala contro infrastrutture reali. La falla logica, nascosta in una trust assumption hard-coded, è stata individuata e incapsulata in uno script funzionale senza passare attraverso i tempi tradizionali di reverse engineering manuale e prototipazione. Questo fenomeno costringe i vendor a ripensare i cicli di patch: le logiche di autenticazione 2FA basate su assunzioni statiche diventano bersagli prevedibili per sistemi automatizzati che analizzano il codice sorgente a scala con velocità non umana.
Ryan Dewhurst, watchTowr Head of Threat Intelligence, ha osservato a The Hacker News che "AI is already accelerating vulnerability discovery, reducing the effort needed to identify, validate, and weaponize flaws. This is today's reality: discovery, weaponization, and exploitation are faster. We're not heading toward compressed timelines; we've been watching the timelines compress for years." Il suo commento colloca l’episodio GTIG in una curva già in corso, dove la generazione automatizzata di exploit non è una prospettiva futura, ma una condizione che richiede ricalibrazione immediata delle difese.
Cosa fare adesso
La risposta difensiva non può limitarsi a ricercare fix per singole vulnerabilità, perché il vettore d’attacco rivelato da GTIG è trasversale: una trust assumption logica individuata da un modello AI e weaponizzata in tempi compressi. Le misure prioritarie devono intervenire sia sul codice sia sulla supervisione operativa.
- Auditare le trust assumption hard-coded: verificare nei tool di system administration open-source e proprietari che le logiche di 2FA non possano essere aggirate tramite manipolazione semantica dei flussi di autenticazione, trattando le vulnerabilità logiche con pari priorità rispetto ai flaw tecnici.
- Comprimere i cicli di remediation per flaw logici: rivedere le procedure di risposta alle segnalazioni su autenticazione e trust boundary, perché gli LLM accelerano la discovery di queste superfici di attacco e ne abbreviano la weaponizzazione.
- Deployare detection behavioral sui tool di amministrazione: implementare monitoraggi per identificare accessi con credenziali valide ma comportamento anomalo successivo al bypass formale del 2FA, integrando controlli di coerenza comportamentale post-autenticazione.
- Addestrare i team a riconoscere output LLM: aggiornare le procedure di code review e threat hunting per identificare pattern tipici degli script generati da modelli AI, come docstrings eccessive, score di severità allucinati e classi decorative standardizzate, per velocizzare il triage di codice sospetto in ambienti enterprise e open-source.
Il messaggio più netto che emerge dal report GTIG è che la superficie di attacco non si è semplicemente allargata, ma è diventata più veloce da percorrere. Le logiche di autenticazione costruite su assunzioni statiche di trust, spesso trascurate dagli auditor umani perché “ovvie”, risultano visibili e vulnerabili alla scansione sistematica di modelli AI. Riconoscere questo shift non significa demonizzare gli LLM, ma ridefinire i tempi e le priorità della difesa: il calendario del patch management deve finalmente allinearsi alla velocità reale della weaponizzazione.
Domande frequenti
- Qual è il tool open-source compromesso?
- Google non ha reso pubblico il nome del software, limitandosi a confermare la collaborazione con il vendor per una disclosure responsabile e un fix proattivo prima che la campagna potesse dispiegarsi su larga scala.
- L’exploit permette l’accesso remoto senza credenziali?
- No. Lo script richiede credenziali valide come prerequisito; il suo obiettivo è aggirare il secondo fattore di autenticazione una volta che l’attore disponga già della prima.
- È stato confermato quale modello AI ha generato il codice?
- GTIG ha escluso con alta confidenza l’uso di Gemini, ma non ha identificato il modello specifico. La valutazione si basa interamente sulle caratteristiche strutturali del codice e non su indicatori di infrastruttura.
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.