L’uso dell’intelligenza artificiale nel contesto cyber non è un fenomeno nuovo. Da anni i modelli di machine learning vengono utilizzati lato difesa:

• per l’analisi di grandi moli di log,
• per il rilevamento di anomalie di rete o di comportamento degli endpoint,
• per il rilevamento di frodi,
• per la classificazione automatica di eventi.

Parallelamente, gli attaccanti hanno iniziato a utilizzare strumenti AI per accelerare alcune attività – dalla redazione di e-mail di phishing più credibili, alla generazione di codice di supporto, fino all’analisi preliminare di infrastrutture e bersagli.

Per lungo tempo, tuttavia, l’intelligenza artificiale è rimasta “esterna” al malware vero e proprio. Il codice malevolo era progettato, scritto e testato sfruttando eventualmente tool AI, ma il binario o lo script eseguibile restavano, in produzione, del tutto indipendenti da modelli di machine learning o da LLM.

Le nuove famiglie di malware AI-driven

Il rapporto pubblicato dal GTIG nel novembre 2025, dal titolo AI Threat Tracker: Advances in Threat Actor Usage of AI Tools, segna un cambio di fase: i ricercatori Google descrivono l’emersione di “novel AI-enabled malware in active operations”, strumenti nei quali l’AI viene richiamata in tempo reale dal malware durante l’esecuzione, per generare, riscrivere o offuscare il codice e per decidere, in parte, i passi successivi dell’attacco.

Le famiglie identificate – tra cui PromptFlux e PromptSteal, a cui si aggiungono FruitShell, PromptLock e QuietVault – sono considerate ancora sperimentali.

Non hanno un impatto devastante paragonabile alle grandi campagne di ransomware degli ultimi anni, e Google stessa sottolinea che, al momento, risultano rilevabili con relativa facilità dagli strumenti di sicurezza ben configurati. Ma gli elementi di novità sono significativi: l’integrazione di LLM in esecuzione, la capacità di generare script on demand, l’uso dei modelli per offuscare e mutare periodicamente il codice.

Per i CISO e per i responsabili IT, questo contesto impone una riflessione che vada oltre l’ennesimo “alert” di mercato.

La domanda non è se questi specifici ceppi di malware diventeranno la minaccia dominante nel breve periodo, ma se l’ecosistema di difesa sia pronto a confrontarsi con una classe di attacchi in cui l’intelligenza artificiale non è solo uno strumento di supporto, ma una componente attiva della catena d’attacco.

In questa prospettiva, l’analisi del report GTIG diventa un’occasione per anticipare scenari e adeguare fin da ora modelli di rischio, controlli e processi.

Dal supporto all’attacco: cosa si intende per malware AI-driven

Per delimitare il perimetro, è utile distinguere tra tre livelli di utilizzo dell’AI da parte degli attaccanti.

Nel primo livello, l’intelligenza artificiale viene impiegata per attività ausiliarie: generare testo per campagne di phishing, tradurre o localizzare contenuti, ridurre errori sintattici in script, costruire in maniera più efficiente spezzoni di codice da integrare in strumenti malevoli tradizionali.

In questo scenario, il malware distribuito sulle vittime non contiene riferimenti a modelli o API AI; beneficia del fatto che l’attaccante ha potuto svilupparlo più rapidamente o in modo più raffinato, ma la struttura del codice rimane statica.

Nel secondo livello, che potremmo definire di “tooling offensivo assistito da AI”, l’intelligenza artificiale viene integrata in strumenti a supporto del ciclo di attacco.

Si tratta, ad esempio, di piattaforme che aiutano a generare in modo semi-automatico varianti di payload, a costruire infrastrutture di comando e controllo, o a orchestrare campagne di attacco multifase.

Anche in questo caso, il malware eseguito sulle vittime resta tradizionale nel suo comportamento, pur essendo stato prodotto e gestito con l’aiuto di componenti AI.

Il terzo livello è quello documentato da GTIG nel 2025: l’AI entra nella “runtime chain” del malware. Il codice malevolo include logica per interrogare un modello generativo (sia esso un servizio cloud come Gemini, sia un modello open source esposto tramite API), ottenere in risposta codice o comandi da eseguire e integrare tali output nel proprio flusso di esecuzione.

In questo scenario, il comportamento del malware non è completamente determinato al momento della compilazione: una parte delle sue azioni viene definita dinamicamente, in funzione delle risposte del modello AI e del contesto in cui si trova.

È questo terzo livello che, in letteratura e nel dibattito tecnico, viene spesso indicato come malware “AI-driven” o “AI-enabled”.

L’aggettivo non va inteso in chiave sensazionalistica: i malware analizzati non sono “intelligenti” nel senso umano del termine, né autonomi nel delineare da soli obiettivi strategici. Restano strumenti al servizio di operatori umani.

Tuttavia, la capacità di generare o trasformare porzioni di codice on demand, di adattare i comandi da eseguire in funzione dell’ambiente e, potenzialmente, di apprendere pattern di risposta alle difese, rappresenta un’evoluzione importante rispetto alla logica statica del malware tradizionale.

Questa evoluzione modifica anche il terreno di confronto tra attacco e difesa. Se il codice può mutare ad ogni esecuzione, o addirittura più volte durante la stessa esecuzione, i meccanismi di rilevamento basati esclusivamente su firme o hash diventano meno efficaci.

La stessa analisi statica del file perde parte della sua capacità predittiva, a favore di un’osservazione più approfondita del comportamento in esecuzione, delle chiamate di rete, delle interazioni con l’ambiente e dell’uso delle API AI.

I più pericolosi malware AI-driven: PromptFlux e PromptSteal

Il report di Google e le successive analisi di stampa tecnica e generalista convergono su un punto: per la prima volta vengono descritte famiglie di malware che utilizzano LLM in esecuzione durante attacchi reali.

I casi più discussi sono PromptFlux e PromptSteal, a cui si affiancano FruitShell, PromptLock e QuietVault, ognuno con caratteristiche specifiche.

PromptFlux

È descritto come un malware sperimentale scritto in VBScript, individuato attraverso analisi di campioni caricati su VirusTotal.

La sua peculiarità è l’integrazione con l’API del modello Gemini: il codice contiene un modulo, definito dai ricercatori un “Thinking Robot”, che periodicamente interroga il modello per ottenere nuove varianti di codice offuscato da utilizzare al posto di quello corrente.

In pratica, PromptFlux rigenera di frequente parti del proprio sorgente VBScript, con l’obiettivo di mutare firma e struttura, rendendo più complesso il rilevamento da parte degli antivirus basati su pattern statici.

Il malware tenta di ottenere persistenza collocandosi, ad esempio, nella cartella di avvio di Windows e cercando di diffondersi tramite unità rimovibili e condivisioni di rete.

L’elemento innovativo non è tanto il vettore di diffusione, quanto il modo in cui il codice cerca di “sfuggire allo sguardo” degli strumenti di sicurezza, delegando a un LLM la generazione periodica di nuove versioni del proprio script. È un primo esempio, ancora grezzo, di metamorfismo guidato da AI.

PromptSteal

rappresenta un’altra declinazione di malware AI-enabled. In questo caso, GTIG lo definisce un data miner utilizzato da un attore sponsorizzato dallo Stato, identificato come APT28 (FROZENLAKE), in campagne contro obiettivi in Ucraina.

PromptSteal, secondo il report, interroga un modello open source (Qwen2.5-Coder-32B-Instruct) esposto tramite API sulla piattaforma Hugging Face per generare comandi da eseguire su sistemi Windows compromessi.

Il malware si presenta come un programma di generazione di immagini, che guida l’utente attraverso una serie di prompt; in realtà utilizza le risposte dell’LLM per costruire dinamicamente comandi orientati alla raccolta di file e dati di sistema da esfiltrare.

In questo caso, il modello AI non viene impiegato per riscrivere il corpo del malware, ma per decidere quali comandi lanciare sul sistema, in funzione del contesto.

Si tratta comunque di un uso operativo dell’AI all’interno del malware, che rende più flessibile la fase di discovery e raccolta dati rispetto a script statici predeterminati.

Gli altri malware AI-driven: FruitShell, PromptLock e QuietVault

Accanto a queste due famiglie principali, come dicevamo, Google e altre fonti riportano tre ulteriori strumenti sperimentali: FruitShell, PromptLock e QuietVault.

FruitShell

viene descritto come una reverse shell basata su PowerShell che utilizza un LLM per tentare di eludere sistemi di sicurezza anch’essi supportati da AI, cercando di generare comandi e pattern che appaiano meno sospetti.

PromptLock

Scritto in Go, sfrutta l’AI in fase di esecuzione per generare script a supporto di attività di cifratura e di esfiltrazione dati, con una logica potenzialmente riconducibile a un ransomware.

QuietVault

È associato a tecniche di data exfiltration stealth, con l’uso di AI per ottimizzare cosa, come e quando esfiltrare.

Minacce reali, ma ancora poco sofisticate

È importante sottolineare che, allo stato attuale, queste famiglie non risultano ancora ottimizzate né particolarmente sofisticate rispetto ad altre minacce ampiamente diffuse.

Lo stesso GTIG, così come diversi commentatori, le definisce strumenti “nascent” e “experimental”, con una capacità operativa limitata rispetto a malware consolidati.

Il loro vero significato, in chiave strategica, è quello di segnare l’ingresso in un nuovo paradigma, non di rappresentare già oggi la principale fonte di rischio per le organizzazioni.

Evoluzione delle tattiche: scenari a 12–24 mesi

L’emersione di malware AI-driven apre la strada a diversi scenari evolutivi, alcuni dei quali sono già oggetto di simulazioni e proof-of-concept in ambito accademico e industriale.

Tecniche di mutazione del codice

La traiettoria più immediata è l’affinamento delle tecniche di mutazione del codice.

Se oggi PromptFlux utilizza l’AI per riscrivere porzioni di VBScript con una logica relativamente semplice, in futuro si possono ipotizzare varianti capaci di modificare non solo la sintassi, ma anche le strutture di controllo, la sequenza delle chiamate di sistema e l’ordine delle operazioni, mantenendo invariata la semantica malevola ma aumentando drasticamente lo spazio delle possibili varianti.

L’adaptive payload

Un secondo scenario riguarda il cosiddetto “adaptive payload”.

Un malware che interroga un LLM o un modello specializzato potrebbe adattare la propria catena di attacco in funzione delle caratteristiche del sistema compromesso: versione del sistema operativo, presenza di determinati software, livello di patching, modalità di esecuzione (utente standard o privilegiato), indicatori di presenza di sandbox o strumenti di analisi.

La logica malevola non sarebbe più un flusso rigido di passi, ma un albero decisionale generato dinamicamente, con una combinazione di regole definite dall’attaccante e suggerimenti prodotti dal modello.

Il post-exploitation autonomo

Un terzo ambito di evoluzione è il post-exploitation autonomo. Modelli addestrati su grandi quantità di dati tecnici e di sicurezza potrebbero essere utilizzati per analizzare il contesto di una macchina compromessa e suggerire automaticamente all’operatore, o direttamente al malware, le azioni più efficaci per ottenere persistenza, movimento laterale o esfiltrazione dati.

In prospettiva, una parte delle attività attualmente svolte manualmente da operatori umani – spesso appartenenti a gruppi strutturati – potrebbe essere trasferita a “assistenti AI offensivi” integrati negli strumenti di attacco.

L’evoluzione delle tecniche di social engineering

Non va trascurata, infine, l’evoluzione delle tecniche di social engineering rese possibili dall’AI, con possibili integrazioni strette tra componenti di attacco “logiche” (malware) e componenti di attacco “relazionali” (deepfake vocali o video, conversazioni testuali credibili, interazioni in tempo reale gestite da agenti AI).

Il confine tra la fase di compromissione iniziale e il dispiegarsi delle attività del malware potrebbe diventare meno netto, con catene d’attacco in cui la persuasione dell’utente e l’esecuzione tecnica si intrecciano.

Per le organizzazioni, questi scenari non rappresentano un futuro remoto, ma una traiettoria credibile nel giro di pochi anni, se non di mesi, considerato il ritmo di innovazione nel campo dei modelli generativi e la rapidità con cui strumenti di sviluppo AI vengono adottati in ambito legittimo e illegittimo.

Impatto sui modelli di difesa: limiti della sicurezza “static-centric”

L’ingresso di malware AI-driven mette in luce i limiti di un modello di difesa ancora fortemente centrato su controlli statici. Gli antivirus basati prevalentemente su firme, le soluzioni che si affidano a black-list di hash, gli strumenti che operano soprattutto su analisi statiche del codice rappresentano ancora uno strato importante di protezione, ma rischiano di diventare progressivamente meno efficaci man mano che aumentano le capacità di mutazione e di offuscamento del malware.

Il problema non è soltanto la capacità di generare nuove varianti sintattiche del codice – una forma di metamorfismo già nota – ma la combinazione tra mutazione del codice e adattamento del comportamento in risposta alle difese.

Se un malware può interrogare un modello AI per identificare possibili indicatori di rilevamento (ad esempio la presenza di determinati processi di sicurezza, di agenti EDR, di pattern di rete riconducibili a sandbox) e modificare di conseguenza le proprie azioni, diventa più complesso definire pattern di rilevamento basati su pochi indicatori chiave.

Questo scenario rafforza la necessità, già evidenziata da tempo, di investire in modelli di rilevamento comportamentale e in capacità di osservabilità estesa.

Soluzioni EDR e XDR in grado di analizzare sequenze di eventi, correlare segnali provenienti da endpoint, rete, identità e applicazioni, e di apprendere pattern di comportamento nel tempo, risultano meglio attrezzate per individuare anomalie riconducibili a malware che cambiano forma.

Allo stesso tempo, la qualità e la profondità dei log raccolti diventano un fattore critico: senza dati adeguati, anche il migliore motore di analisi comportamentale resta inefficace.

Il SOC è chiamato a evolvere da struttura prevalentemente reattiva, centrata sulla gestione di alert, a funzione capace di sviluppare e mantenere nel tempo “detection use case” mirati, basati tanto su indicatori statici quanto su logiche di pattern e di scenario.

Nel contesto dei malware AI-driven, potrebbe essere più utile rilevare, ad esempio, combinazioni anomale di chiamate verso API AI pubbliche o verso endpoint di modelli open source, associate a comandi di sistema sospetti, che non cercare esclusivamente determinate stringhe all’interno di un file.

Infine, l’impatto riguarda anche il livello di governance della sicurezza. L’emersione di nuove classi di minacce che sfruttano l’AI rende evidente l’esigenza di aggiornare periodicamente i modelli di analisi del rischio, le policy e i piani di trattamento. Il rischio “malware AI-driven” non è solo un problema di tecnologia: è un rischio operativo e di business, che coinvolge continuità dei servizi, integrità dei dati e conformità normativa.

Integrazione nei framework di risk management e di governance

L’introduzione di una nuova categoria di minaccia non significa ripensare da zero i framework esistenti. Al contrario, l’esperienza dimostra che strumenti come il NIST Cybersecurity Framework, i CIS Controls, la ISO/IEC 27001:2022 e il COBIT 2019 sono sufficientemente flessibili da accogliere nuovi scenari all’interno di logiche consolidate di identificazione, protezione, rilevazione, risposta e recupero.

Nel dominio “Identify” del NIST CSF, ad esempio, il rischio associato a malware AI-driven può essere inquadrato come evoluzione della minaccia malware tradizionale, con l’aggiunta di caratteristiche specifiche: capacità di elusione avanzata, potenziale automazione delle fasi post-exploitation, maggiore velocità di adattamento alle difese.

Ciò richiede una revisione degli asset critici, dei processi e delle dipendenze esterne per valutare quali aree possano essere più esposte a questa classe di attacchi, in funzione anche dell’utilizzo interno di AI e di eventuali integrazioni con modelli esterni.

Sul versante dei controlli, i CIS Controls offrono già indicazioni utili per mitigare il rischio: inventario e controllo dei dispositivi e dei software, gestione delle vulnerabilità, controlli di logging e monitoring, protezione degli account privilegiati, segmentazione di rete.

L’emersione di malware AI-enabled non invalida questi principi, ma suggerisce di rafforzare alcuni aspetti: ad esempio, l’attenzione alle chiamate verso servizi AI esterni, la definizione di regole chiare per l’uso di modelli generativi in ambito aziendale, la protezione delle API e delle chiavi di accesso ai servizi AI.

La ISO/IEC 27001:2022, insieme alle linee guida della famiglia 27002, offre il quadro per tradurre questi principi in controlli organizzativi e tecnici.

L’adozione di politiche formali sull’uso dell’AI, la definizione di ruoli e responsabilità per la gestione dei rischi legati ai modelli generativi, l’integrazione di scenari AI-driven nella valutazione del rischio informativo e nei piani di trattamento diventano elementi coerenti con un sistema di gestione della sicurezza informativa maturo.

Infine, COBIT 2019 e il Risk IT Framework consentono di collegare il tema ai livelli più alti di governance aziendale.

Il rischio legato a malware AI-driven non è un dettaglio tecnico, ma un fattore che impatta sui processi di creazione del valore, sulla continuità dei servizi digitali, sulla reputazione e sulla conformità.

In questa logica, la definizione di obiettivi di controllo (control objectives) specifici, la misurazione di indicatori di performance e di rischio (KPI e KRI) e la rendicontazione periodica al board consentono di trattare il tema non come un fenomeno di moda, ma come una componente strutturale del rischio ICT.

Contromisure tecniche e organizzative

Alla luce del quadro descritto, la strategia di mitigazione non può esaurirsi nell’introduzione di un singolo prodotto o di una funzionalità “anti-AI-malware”. È necessario un approccio multilivello, che combini controlli tecnici avanzati con misure organizzative e processi di governance.

Rafforzare le capacità di rilevazione comportamentale

Sul piano tecnico, il primo asse riguarda il rafforzamento delle capacità di rilevazione comportamentale. Strumenti EDR e XDR che integrano analisi comportamentale e, a loro volta, modelli di machine learning, sono meglio posizionati per intercettare sequenze anomale di eventi riconducibili a malware che mutano forma.

È essenziale, però, che tali strumenti siano correttamente configurati, alimentati da log completi e inseriti in un processo SOC strutturato, in grado di investigare gli alert e di affinarne nel tempo le regole.

Osservabilità alle interazioni con servizi AI

Un secondo asse consiste nell’estendere l’osservabilità alle interazioni con servizi AI. In molte organizzazioni, l’uso di modelli generativi – interni o esterni – sta crescendo rapidamente.

Ciò implica la necessità di monitorare chiamate verso API di modelli pubblici, accessi a piattaforme di AI esterne, utilizzo di modelli interni esposti tramite API.

La comparsa, su endpoint non autorizzati, di chiamate verso servizi AI con parametri anomali o in contesti non previsti dovrebbe essere trattata come un potenziale indicatore di compromissione.

Gestione sicura dell’AI all’interno dell’organizzazione

Un terzo asse riguarda la gestione sicura dell’AI all’interno dell’organizzazione.

Policy chiare sull’uso dei modelli generativi, formazione degli utenti sui rischi associati all’inserimento di dati sensibili in prompt o in strumenti non autorizzati, controllo rigoroso delle chiavi di accesso alle API AI e dei sistemi che le memorizzano sono elementi chiave per evitare che lo stesso ecosistema AI dell’organizzazione diventi un vettore di attacco o uno strumento nelle mani di un attore malevolo.

Rivedere e aggiornare i processi di gestione del rischio

Sul piano organizzativo, è fondamentale integrare questi aspetti nei processi di gestione del rischio, di business continuity e di gestione degli incidenti.

I playbook di incident response dovrebbero prevedere scenari specifici legati ad attacchi che sfruttano AI, includendo, ad esempio, la necessità di disabilitare rapidamente chiavi API compromesse, di isolare componenti AI interne sospette e di coinvolgere, se necessario, i fornitori di servizi AI esterni.

Allo stesso tempo, i processi di business continuity dovrebbero considerare ipotesi in cui una parte degli strumenti di sicurezza basati su AI sia degradata o compromessa.

La centralità della componente umana

Infine, la componente umana resta centrale. La formazione continua dei team di sicurezza, l’aggiornamento dei profili di competenza del SOC e del team di incident response, la partecipazione a community di threat intelligence e di condivisione delle informazioni – inclusi i canali locali e nazionali, come i CSIRT e le strutture previste dalle normative – sono elementi indispensabili per mantenere il passo con un panorama di minacce in rapida evoluzione.

Oltre l’allarme, verso una difesa “ai-ready”

La scoperta di malware AI-driven in campagne reali segna l’inizio di una nuova fase, ma non l’arrivo improvviso di una minaccia ingestibile. Gli strumenti descritti dal GTIG e da altre fonti sono ancora sperimentali, con capacità limitate rispetto a molte minacce già in circolazione.

La loro importanza risiede nella direzione che indicano: un progressivo spostamento dell’intelligenza artificiale dalla fase di supporto allo sviluppo e alla pianificazione degli attacchi alla fase esecutiva del malware.

Per le organizzazioni, la risposta più efficace non è cedere a narrazioni allarmistiche, né minimizzare il fenomeno.

È, piuttosto, adottare una visione di medio periodo, che consideri i malware AI-driven come un ulteriore catalizzatore per evolvere i modelli di difesa da un paradigma statico a uno dinamico, capace di osservare, apprendere e adattarsi.

In quest’ottica, investire in capacità di detection comportamentale, rafforzare la governance dell’AI interna, integrare questi scenari nei processi di risk management e allineare le misure alle aspettative regolatorie diventa non solo una scelta tecnica, ma una decisione strategica.

Il messaggio di fondo del report GTIG è chiaro: l’uso malevolo dell’intelligenza artificiale sta entrando in una nuova fase operativa.

Il tempo per prepararsi non è esaurito, ma nemmeno infinito.

Le organizzazioni che sapranno interpretare correttamente questa evoluzione, aggiornando i propri modelli di sicurezza e di governance, saranno in una posizione migliore per affrontare non solo i primi ceppi di malware AI-driven, ma le generazioni successive che inevitabilmente seguiranno.