Doppio cyber-attacco mondiale: l’intelligenza artificiale buca gli antivirus

Una doppia minaccia informatica di altissimo livello sta scuotendo il mondo degli sviluppatori e degli utenti comuni. Da una parte, la potenza dell’intelligenza artificiale ha permesso di scovare clamorosi “buchi” di sicurezza (Zero-Day) in software storici come Vim ed Emacs, permettendo agli hacker di prendere il controllo di un computer semplicemente facendoti aprire un file di testo. Dall’altra, Microsoft lancia l’allarme rosso su una sofisticata campagna criminale che corre su WhatsApp: gli attaccanti inviano messaggi contenenti microscopici script in grado di eludere i controlli di sicurezza di Windows e installare virus invisibili senza che l’utente se ne accorga. Due fronti di attacco diversi che dimostrano un fatto inquietante: gli strumenti di tutti i giorni sono diventati le nuove armi di distruzione digitale. Tra fine marzo e inizio aprile 2026 emergono due storie molto diverse ma accomunate dallo stesso messaggio: anche gli strumenti più ordinari possono diventare vettori d’attacco ad alto impatto. Da una parte Microsoft documenta una campagna attiva che distribuisce script VBS malevoli via WhatsApp e costruisce una catena di infezione stealth su Windows usando utility native rinominate, payload ospitati su cloud affidabili e tecniche di bypass di User Account Control. Dall’altra, il ricercatore Hung Nguyen di Calif mostra come l’assistente Claude AI possa accelerare la scoperta di vulnerabilità critiche in due editor di testo diffusissimi come Vim ed Emacs, entrambi in grado di arrivare all’esecuzione di comandi semplicemente aprendo file o directory appositamente preparati. Per sviluppatori, sysadmin e team SOC il segnale è molto chiaro: la superficie d’attacco del 2026 passa tanto dalle chat quanto dagli strumenti di sviluppo quotidiani.

La campagna via WhatsApp usa file VBS e living-off-the-land su Windows

Secondo Microsoft Defender Security Research Team, la campagna parte da messaggi WhatsApp che consegnano file Visual Basic Script dannosi. Una volta eseguiti, questi script avviano una catena multi-stage progettata per ottenere persistenza e accesso remoto. L’elemento più interessante è che gli attaccanti non si affidano subito a binari palesemente malevoli, ma preferiscono una strategia living-off-the-land: creano cartelle nascoste in C:\ProgramData, copiano utility Windows legittime, le rinominano e le usano per scaricare i componenti successivi. In particolare, curl.exe viene mascherato come netapi.dll e bitsadmin.exe come sc.exe, così l’attività si confonde più facilmente con normali operazioni di sistema. I payload vengono poi recuperati da servizi cloud molto diffusi come AWS, Tencent Cloud e Backblaze B2, dettaglio che aiuta gli attaccanti a mescolarsi nel traffico legittimo e a ridurre la visibilità delle comunicazioni sospette.

Il malware tenta il bypass UAC e installa MSI malevoli persistenti

La fase successiva della catena punta all’elevazione dei privilegi. Microsoft osserva che il malware tenta ripetutamente di avviare cmd.exe con privilegi elevati e manipola le impostazioni di UAC tramite il registro, fino a riuscire a sopprimere il prompt di conferma o comunque ad aggirare le difese del sistema. Una volta ottenuto un contesto amministrativo, la campagna distribuisce pacchetti MSI malevoli come Setup.msi, WinRAR.msi, LinkPoint.msi e AnyDesk.msi, tutti non firmati e usati per stabilire accesso remoto persistente. Questo passaggio è importante perché mostra una progressione molto ordinata: iniziale social engineering via chat, esecuzione di uno script fidato dal sistema operativo, abuso di tool nativi, indebolimento delle difese e infine deploy di componenti remoti durevoli. Per i defender il problema non è solo il file VBS iniziale, ma l’intera catena che si innesta su strumenti legittimi e quindi produce indicatori meno evidenti rispetto a un malware tradizionale.

Microsoft evidenzia utility rinominate e cloud trusted come fattori di evasione

Uno degli aspetti più insidiosi della campagna è il modo in cui sfrutta la reputazione degli strumenti esistenti. Le utility rinominate mantengono il proprio PE metadata, incluso il campo OriginalFileName, e questo diventa uno dei pochi segnali utili alla difesa: il nome del file sul disco non corrisponde più al binario originario. È un indicatore relativamente sottile ma molto utile per il threat hunting. Allo stesso tempo, il caricamento dei payload da infrastrutture cloud note rende più difficile per molte organizzazioni bloccare le connessioni senza introdurre falsi positivi pesanti. Microsoft consiglia quindi di rafforzare le policy contro esecuzione di script offuscati, bloccare il lancio di file scaricati da script VBScript e attivare protezioni comportamentali capaci di intercettare anche gli abusi di binari legittimi. Il dato che conta è che il vettore iniziale è estremamente semplice: un messaggio ricevuto in chat e un file aperto con troppa fiducia.

Claude AI accelera la ricerca vulnerabilità in Vim ed Emacs

Sul fronte degli editor di testo, la storia è altrettanto significativa perché mostra il ruolo crescente dell’AI nella scoperta di bug reali. Hung Nguyen racconta di aver chiesto a Claude di individuare una vulnerabilità zero-day in un editor di testo attivabile semplicemente con l’apertura di un file. Il risultato è stato sorprendente: l’assistente ha aiutato a individuare catene di esecuzione in Vim e GNU Emacs, poi raffinate dal ricercatore fino alla costruzione di proof of concept funzionanti. Il caso è interessante non tanto perché l’AI abbia “trovato da sola” il bug, ma perché ha accelerato il processo di revisione del codice, individuazione del percorso esecutivo e formulazione di ipotesi sfruttabili. In altre parole, l’AI non sostituisce ancora il ricercatore, ma ne aumenta in modo tangibile la velocità operativa, soprattutto su codebase mature e molto ampie.

In Vim la catena parte dalle modeline e finisce in esecuzione comandi

La vulnerabilità pubblicata per Vim è tracciata come GHSA-2gmj-rpqf-pxvh e colpisce le versioni dalla 9.1.1391 fino a prima della 9.2.0272. Secondo l’analisi pubblicata da Calif, il problema è una catena a due bug. Il primo è che l’opzione tabpanel non è marcata correttamente con il flag P_MLE, il che permette a una modeline di iniettare espressioni %{...} anche quando modelineexpr non è abilitato. Il secondo è che autocmd_add() non verifica in modo adeguato il contesto sicuro con check_secure(), consentendo di registrare un autocomando nel sandbox che poi verrà eseguito più tardi, fuori dal sandbox stesso. Il risultato è una forma di command execution con i privilegi dell’utente che sta eseguendo Vim.

È una dinamica particolarmente interessante perché sfrutta una combinazione di funzionalità storiche dell’editor, non un classico buffer overflow: proprio per questo dimostra quanto il rischio nei tool legacy possa annidarsi in meccanismi apparentemente innocui e profondamente integrati nel prodotto.

Il team Vim reagisce rapidamente e rilascia la patch 9.2.0272

A differenza di molti casi simili, qui la reazione dei maintainer di Vim è stata piuttosto rapida. Il problema è stato corretto nella versione 9.2.0272, che blocca la catena descritta e chiude la possibilità di usare tabpanel in questo modo. L’impatto non va minimizzato: Vim è presente su un numero enorme di server Linux, sistemi embedded, ambienti DevOps e workstation tecniche. Anche se la finestra di esposizione riguarda soprattutto le release recenti, il rischio è reale perché basta aprire un file crafted per innescare il payload. Il fatto che la PoC scriva in /tmp/calif-vim-rce-poc rende molto chiara la semplicità concettuale dell’attacco: non serve una lunga interazione, basta il normale gesto di aprire un file con un editor ritenuto affidabile.

In Emacs il trigger passa da Git e dal parametro core.fsmonitor

Il caso Emacs è ancora più delicato perché, almeno al momento della disclosure, non risulta corretto a livello dell’editor. La catena individuata da Nguyen non sfrutta una funzione interna di editing puro, ma l’integrazione di Emacs con il controllo versione tramite vc-git. Quando l’utente apre un file, vc-refresh-state viene eseguito dal find-file-hook e richiama comandi git per capire se il file si trova in una directory versionata. A questo punto entra in gioco il vero problema: Git legge il file .git/config e può eseguire un programma definito in core.fsmonitor. Un attaccante può quindi preparare un archivio che contiene una directory .git nascosta, un file di configurazione malevolo e uno script eseguibile. La vittima estrae l’archivio, apre un innocuo file di testo in Emacs e lo script viene eseguito nel contesto dell’utente. Qui la parte notevole è che il file aperto può essere perfettamente pulito: tutto l’attacco vive nella directory nascosta del repository.

I maintainer di Emacs scaricano la responsabilità su Git

La disclosure resa pubblica da Calif indica che i maintainer di GNU Emacs hanno ritenuto il problema principalmente di competenza di Git, perché l’editor non farebbe altro che invocare il tool di versionamento previsto dal workflow. Dal punto di vista strettamente tecnico la posizione è comprensibile, ma dal punto di vista della sicurezza pratica lascia aperta una superficie d’attacco molto concreta. Se aprire un file in Emacs in una directory con una .git preparata ad hoc provoca l’esecuzione di uno script, l’utente subisce comunque un effetto finale di RCE attraverso il proprio editor. Nguyen propone come mitigazione di far sì che Emacs invochi Git con override espliciti, ad esempio disabilitando core.fsmonitor, ma al momento il problema evidenzia soprattutto una zona grigia sempre più comune: la sicurezza dei tool moderni non dipende solo dal codice principale, ma anche dalle integrazioni automatiche con componenti esterni fidati.

Sviluppatori e sysadmin restano il bersaglio ideale di queste catene

La combinazione tra la campagna WhatsApp e le vulnerabilità in Vim ed Emacs racconta un punto fondamentale: molti attacchi moderni non puntano su software “esotici”, ma sugli strumenti quotidiani usati da sviluppatori, sysadmin e knowledge worker. Un file ricevuto via chat, un archivio estratto in fretta, un file aperto in editor da terminale o in workstation di sviluppo: tutto questo fa parte del lavoro normale. Proprio per questo questi vettori sono così efficaci. Nel caso WhatsApp, il rischio cresce in ambienti aziendali dove il confine tra uso personale e professionale dei dispositivi è sempre più debole. Nel caso di Vim ed Emacs, il rischio cresce perché gli editor vengono spesso eseguiti su server, bastion host, jump box e ambienti tecnici dove un payload riuscito può esporre credenziali, repository, token e segreti di produzione.

Il 2026 mostra come l’AI stia accelerando sia difesa sia scoperta offensiva

La lezione più ampia è che il 2026 sta rendendo più rapido l’intero ciclo della sicurezza offensiva e difensiva. Claude AI ha dimostrato di poter aiutare concretamente nella ricerca di vulnerabilità su software maturo, riducendo il tempo necessario per individuare percorsi sfruttabili. Allo stesso tempo, la campagna documentata da Microsoft mostra che gli attaccanti continuano a perfezionare catene low-noise che sfruttano strumenti legittimi, cloud affidabili e vettori social semplicissimi come le chat. Per le organizzazioni la risposta resta tripla: aggiornare subito Vim alle versioni corrette, trattare con estrema cautela file e archivi aperti in Emacs finché non arriveranno mitigazioni strutturali e rafforzare le policy su esecuzione di VBS, MSI non firmati, modifiche al registro UAC e uso di strumenti LOLBAS. La parte più scomoda è che nessuna di queste minacce richiede exploit fantascientifici: bastano fiducia implicita, automazione e un file aperto al momento sbagliato.