Google ha identificato un caso che segna un passaggio importante nella sicurezza informatica: un gruppo criminale ha utilizzato l’intelligenza artificiale per individuare e trasformare in exploit una vulnerabilità zero-day, con l’obiettivo di preparare un’operazione di sfruttamento su larga scala. Il caso è rilevante non perché dimostri che l’AI sia già in grado di condurre autonomamente ogni fase di un attacco complesso, ma perché mostra che i modelli generativi stanno diventando strumenti operativi concreti nel ciclo di scoperta, analisi e weaponization delle vulnerabilità software.
La vulnerabilità individuata riguardava uno strumento open source di amministrazione di sistema basato su interfaccia web, ampiamente utilizzato per la gestione remota di infrastrutture, server, applicazioni e configurazioni operative. Google non ha reso pubblico il nome del software coinvolto né quello del gruppo criminale, una scelta coerente con la necessità di evitare indicazioni utili ad altri attori malevoli. L’elemento tecnico più delicato è che la falla consentiva di aggirare il secondo fattore di autenticazione, pur richiedendo credenziali valide in partenza. Non si trattava quindi di un accesso completamente privo di autenticazione, ma di un difetto capace di neutralizzare una delle barriere più importanti nelle architetture di sicurezza aziendali.
Il punto centrale è la natura della vulnerabilità. Google ha spiegato che non si trattava di un bug classico come una corruzione di memoria, un buffer overflow o un errore di sanitizzazione dell’input, cioè categorie per le quali fuzzing, analisi statica e scanner automatici sono già molto usati. La falla era invece un problema logico di alto livello: una “trust assumption” codificata direttamente nel software, cioè una condizione di fiducia inserita dal programmatore che, in determinate circostanze, entrava in contraddizione con il meccanismo di enforcement della 2FA. Questo dettaglio è particolarmente importante perché mostra dove i modelli linguistici avanzati possono diventare pericolosi: non solo nel generare codice, ma nel leggere l’intenzione del codice e individuare anomalie semantiche che appaiono corrette agli strumenti tradizionali.
In altre parole, l’AI non avrebbe semplicemente scritto uno script offensivo su richiesta. Avrebbe contribuito a riconoscere una discrepanza tra ciò che il software sembrava voler garantire e ciò che realmente consentiva. È una differenza tecnica fondamentale. Molti sistemi di sicurezza sono costruiti su catene di condizioni, eccezioni, permessi, ruoli, callback, token di sessione e stati intermedi. Un errore in questa logica può non produrre crash, non violare sintassi, non attivare controlli statici evidenti e non apparire come vulnerabilità immediata. Tuttavia, se un modello è abbastanza capace di seguire il flusso semantico dell’applicazione, può iniziare a identificare esattamente questo tipo di fratture.
Google ha dichiarato di avere alta confidenza sul coinvolgimento di un modello AI nella scoperta e nella trasformazione della falla in exploit, sulla base della struttura e del contenuto del codice associato alla campagna. Tra gli elementi osservati figuravano docstring molto didattiche, un punteggio CVSS allucinato e una formattazione Python estremamente ordinata e “da manuale”, tutti segnali compatibili con output generati o assistiti da un modello linguistico. Google ha anche precisato di non ritenere che sia stato usato Gemini, mentre non ha identificato pubblicamente il modello effettivamente impiegato.
Questo aspetto va interpretato con attenzione. Non significa che ogni codice ben commentato o strutturato sia necessariamente AI-generated, né che l’attribuzione di un exploit a un modello sia sempre semplice. La cybersecurity lavora spesso su indizi, correlazioni, toolmark, comportamenti ripetuti e analisi forense del codice. In questo caso, però, Google considera il quadro sufficientemente solido per parlare di un primo caso concreto di exploit zero-day sviluppato con il supporto dell’AI e intercettato prima che venisse usato in una campagna di massa.
La parte più inquietante non è l’exploit in sé, ma il cambio di velocità che può introdurre. Lo sfruttamento di zero-day richiede normalmente competenze elevate, tempo, conoscenza del target, capacità di reverse engineering, sperimentazione e validazione. Se un modello AI riesce ad assistere queste fasi, anche senza sostituire completamente l’operatore umano, abbassa la soglia di accesso a capacità che in passato erano concentrate in gruppi altamente specializzati. Per i criminali informatici, l’AI diventa un moltiplicatore di produttività: riduce il tempo necessario per analizzare codice, testare ipotesi, produrre proof of concept, rifinire payload e adattare tecniche già note a nuovi bersagli.
È qui che emerge il concetto di hacking semi-autonomo. Non siamo ancora davanti a sistemi completamente indipendenti che scelgono obiettivi, conducono ricognizione, scoprono vulnerabilità, scrivono malware, esfiltrano dati e monetizzano l’attacco senza intervento umano. Tuttavia, il confine si sta spostando. Google osserva che gli attori malevoli stanno iniziando ad affidare all’AI parti sempre più operative della catena d’attacco, dalla ricerca di vulnerabilità alla generazione di codice, dall’offuscamento alla navigazione autonoma di ambienti compromessi.
Il rischio industriale è particolarmente alto perché la vulnerabilità colpiva uno strumento di amministrazione. Le piattaforme di gestione remota hanno spesso privilegi elevati e fungono da punto di controllo su server, utenti, configurazioni, applicazioni e ambienti distribuiti. Un bypass della 2FA su un sistema di questo tipo non equivale alla compromissione di una singola utenza periferica, ma può trasformarsi rapidamente in accesso infrastrutturale. Se l’attaccante dispone già di credenziali valide, ottenute tramite phishing, infostealer, credential stuffing o precedenti compromissioni, l’elusione del secondo fattore può aprire la strada a movimenti laterali, escalation dei privilegi e preparazione di campagne ransomware o di estorsione dati.
Il caso dimostra anche un limite strutturale della sicurezza basata esclusivamente su MFA. L’autenticazione a più fattori resta essenziale, ma non può essere considerata una protezione assoluta se la logica applicativa che la governa contiene eccezioni mal progettate. Una 2FA implementata correttamente deve essere applicata in modo coerente lungo tutto il ciclo di autenticazione, autorizzazione, cambio sessione, recupero credenziali, accesso API, delega amministrativa e operazioni privilegiate. Se una sola parte del sistema assume implicitamente che un utente sia già “fidato” senza rivalidare il contesto, la protezione può essere aggirata non rompendo la crittografia, ma sfruttando una contraddizione logica.
Questo è il motivo per cui i modelli generativi avanzati sono particolarmente adatti a una nuova classe di vulnerability discovery. Gli scanner tradizionali cercano pattern, sink pericolosi, chiamate insicure, input non filtrati, dipendenze vulnerabili o crash riproducibili. Un LLM, invece, può analizzare il codice come testo e come intenzione. Può confrontare nomi di funzioni, commenti, flussi condizionali, eccezioni, ruoli e messaggi di errore. Può notare che una funzione chiamata per imporre la verifica a due fattori viene aggirata in un ramo apparentemente legittimo. Può collegare una condizione hardcoded a una conseguenza di sicurezza non immediata. È proprio questa capacità di ragionamento contestuale che rende l’AI utile sia ai difensori sia agli attaccanti.
Il rapporto di Google colloca questo episodio dentro una tendenza più ampia: l’uso dell’AI non è più limitato alla scrittura di email di phishing più convincenti o alla traduzione di contenuti malevoli in più lingue. I gruppi avanzati stanno sperimentando prompt basati su false identità professionali, dataset specializzati di vulnerabilità, repository storici di bug reali e strumenti agentici usati in ambienti controllati per testare payload prima della distribuzione. Alcuni gruppi legati alla Cina e alla Corea del Nord hanno mostrato interesse specifico per la vulnerability research assistita dall’AI, mentre altri attori stanno usando modelli generativi per automatizzare analisi ripetitive su CVE e proof of concept.
Un dettaglio tecnico rilevante riguarda l’uso di basi dati specializzate. Google cita esperimenti con repository contenenti decine di migliaia di casi reali di vulnerabilità, usati per orientare il modello verso pattern di analisi più simili a quelli di un ricercatore esperto. Questo approccio è importante perché sposta l’AI da assistente generalista a sistema specializzato di supporto alla sicurezza offensiva. Quando un modello viene alimentato con esempi storici di bug, exploit, logiche di bypass e catene di attacco, può diventare più efficace nel riconoscere analogie e nel suggerire percorsi di analisi che un operatore meno esperto non avrebbe individuato.
La minaccia non riguarda solo la scoperta di vulnerabilità. Google descrive anche l’uso dell’AI per l’offuscamento, la generazione di codice esca e la modifica dinamica di malware. In alcuni casi, il codice malevolo viene riempito di logica inattiva o apparentemente amministrativa per confondere analisi statiche e revisori umani. In altri, l’AI viene usata per generare payload o variazioni del codice in modo da rendere più difficile la firma e la classificazione. Questo porta verso malware più adattivi, meno ripetitivi e potenzialmente più difficili da bloccare con controlli basati su pattern statici.
Ancora più significativo è il passaggio verso malware con componenti agentiche. Google cita PROMPTSPY, una backdoor Android che integra un modulo autonomo capace di interagire con l’interfaccia del dispositivo compromesso, interpretare la struttura visibile dello schermo e generare azioni come tocchi o swipe sulla base di obiettivi definiti dall’attaccante. In questo scenario, il modello non è più usato solo in fase di sviluppo, ma entra nel ciclo operativo del malware, aiutandolo a leggere lo stato del sistema e ad agire dinamicamente.
Questo tipo di evoluzione cambia il modello difensivo. I controlli tradizionali presuppongono spesso che il comportamento malevolo sia relativamente stabile: una famiglia di malware ha certe stringhe, certe chiamate, certe sequenze, certi indicatori di compromissione. Con componenti AI integrate, parte del comportamento può essere generato o adattato al contesto. Il malware può non limitarsi a eseguire una sequenza predefinita, ma decidere quale elemento dell’interfaccia manipolare, quale comando produrre o quale percorso seguire in base allo stato reale del dispositivo. Anche se queste capacità sono ancora iniziali, indicano una direzione molto chiara.
La superficie di rischio aumenta ulteriormente perché anche l’ecosistema AI diventa bersaglio. Secondo Google, gli attaccanti non stanno necessariamente superando le difese interne dei modelli frontier, ma stanno colpendo i livelli che li rendono utili: librerie wrapper, connettori API, skill agentiche, marketplace di componenti, pacchetti open source, file di configurazione e strumenti di orchestrazione. Questo è un punto cruciale per le aziende che stanno adottando agenti AI: il rischio non è solo che il modello risponda male, ma che l’ambiente attorno al modello venga compromesso.
In un’architettura enterprise, un agente AI può avere accesso a documenti interni, CRM, repository di codice, sistemi ticketing, strumenti DevOps, caselle email, database, API amministrative e servizi cloud. Se una skill, un connettore o una dipendenza viene manipolata, l’attaccante può trasformare l’agente in un punto di ingresso privilegiato. Google ha osservato casi di pacchetti malevoli mascherati da componenti per ecosistemi agentici e supply chain compromise legate anche a repository GitHub, GitHub Actions e pacchetti PyPI. Il problema quindi non è astratto: l’AI introduce nuove dipendenze software, e ogni dipendenza software può diventare vettore d’attacco.
Le conseguenze per la sicurezza aziendale sono profonde. Le organizzazioni non possono più limitarsi a usare l’AI come strumento difensivo aggiuntivo, né possono trattarla soltanto come rischio di data leakage o prompt injection. Devono considerare l’AI come parte dell’infrastruttura critica. Questo significa inventariare i modelli usati, controllare i connettori, verificare le autorizzazioni degli agenti, isolare gli ambienti di esecuzione, monitorare le chiamate API, applicare il principio del minimo privilegio e registrare in modo tracciabile le azioni automatizzate. Un agente AI con troppi permessi può diventare l’equivalente moderno di un account di servizio mal configurato, ma con capacità decisionali molto più flessibili.
Sul piano del secure software development, il caso del bypass 2FA mostra che la revisione del codice deve evolvere. Non basta più cercare vulnerabilità note o dipendenze obsolete. Serve una revisione semantica dei meccanismi di autorizzazione: quali assunzioni di fiducia sono codificate nel sistema, quali eccezioni esistono, quali percorsi saltano controlli critici, quali stati intermedi sono considerati validi e quali funzioni possono essere chiamate fuori sequenza. I team di sicurezza dovranno usare l’AI anche in difesa per simulare questo tipo di ragionamento, cercando non solo bug sintattici ma contraddizioni logiche tra requisito di sicurezza e implementazione.
La difesa dovrà diventare più simmetrica rispetto all’attacco. Se gli attori malevoli usano modelli per analizzare codice e trovare anomalie logiche, le aziende dovranno usare modelli analoghi per audit continui, code review assistita, threat modeling automatico, generazione di test negativi, verifica delle policy di autorizzazione e simulazione di percorsi di abuso. Google stessa sottolinea il ruolo difensivo di sistemi come Big Sleep, progettato da Google DeepMind e Project Zero per cercare vulnerabilità sconosciute, e CodeMender, un agente sperimentale pensato per correggere automaticamente vulnerabilità critiche nel codice.
La partita si sposta quindi su una competizione di velocità. Gli attaccanti possono usare l’AI per scoprire più bug in meno tempo, ma i difensori possono usarla per trovare e correggere vulnerabilità prima che vengano sfruttate. Il problema è la fase di transizione. Il mondo software contiene quantità enormi di codice legacy, applicazioni interne, strumenti open source, configurazioni storiche e sistemi non progettati per essere analizzati da modelli generativi avanzati. Se la capacità offensiva cresce più rapidamente della capacità di bonifica, il rischio complessivo può aumentare nel breve periodo.
Per le aziende, la risposta non può essere il blocco generico dell’AI, perché l’AI sarà anche uno strumento indispensabile di difesa. La risposta deve essere governance tecnica. Gli strumenti amministrativi esposti via web devono essere censiti, aggiornati e protetti con controlli compensativi. I meccanismi MFA devono essere testati non solo nella procedura standard, ma in tutti i percorsi alternativi di autenticazione e recupero sessione. Gli account privilegiati devono essere monitorati con criteri comportamentali, perché un attaccante che aggira il secondo fattore usando credenziali valide può apparire inizialmente come utente legittimo. I sistemi di detection devono concentrarsi su anomalie operative, cambiamenti di configurazione, uso insolito di strumenti amministrativi e tentativi di accesso coerenti dal punto di vista formale ma sospetti dal punto di vista del contesto.
È altrettanto importante rafforzare la supply chain dei componenti AI. Ogni libreria, plugin, skill, connettore e tool di orchestrazione deve essere trattato come codice ad alto impatto. Le aziende dovrebbero evitare agenti con accesso indiscriminato, preferire ambienti sandbox, usare credenziali temporanee, separare i permessi per funzione, applicare allowlist sugli strumenti richiamabili e registrare ogni azione automatizzata. Il principio di base è semplice: un agente AI non deve poter fare tutto ciò che un umano amministratore potrebbe fare, ma solo ciò che è strettamente necessario per il compito approvato.
Il caso intercettato da Google non chiude il dibattito sull’hacking autonomo, ma lo rende molto più concreto. Finora molte discussioni erano concentrate su scenari futuri, modelli troppo potenti da rilasciare o ipotesi di cyber-attacchi completamente automatici. Qui, invece, il punto è più pratico: un gruppo criminale ha già usato l’AI per supportare la scoperta e la costruzione di un exploit zero-day, e l’operazione è stata interrotta prima della distribuzione su larga scala. Questo basta a modificare la percezione del rischio.