Mar 10, 2026 Redazione Approfondimenti, Attacchi, Attacchi, In evidenza, News, RSS 0

---

Torna il tema dell’affidabilità dei plug-in e servizi “indipendenti”. A cominciare dai primi casi eclatanti, ormai risalenti a quasi 30 anni fa, la situazione si fa sempre più pericolosa per chi usa plug-in per il browser. Di recente, infatti, alcune estensioni Google Chrome hanno cambiato mano e, dopo la vendita, hanno iniziato a iniettare codice remoto, raccogliere dati sensibili e installare malware sui sistemi delle vittime. Questo ci ricorda che i criminali sfruttano in maniera sistematico ogni possibilità di compromissione e violazione, senza trascurarne alcuna e puntando anche a iniziative che possono scalare fino a colpire milioni di utenti.

Estensioni legittime diventano malware dopo il cambio di proprietà

In questo caso, al centro dell’indagine ci sono due estensioni Chrome originariamente sviluppate da un autore identificato come akshayanuonline@gmail.com e successivamente trasferite ad altri sviluppatori: QuickLens – Search Screen with Google Lens, con circa 7.000 utenti attivi, e ShotBird – Scrolling Screenshots, Tweet Images & Editor, con circa 800 utenti.

QuickLens non è più disponibile nello store di Chrome, mentre ShotBird risulta ancora scaricabile. Entrambe le estensioni erano state inizialmente pubblicate come strumenti di produttività: QuickLens per catturare schermate e analizzarle con Google Lens, ShotBird per creare screenshot e contenuti grafici per social media.

Le anomalie sono iniziate dopo il passaggio di proprietà. Secondo le analisi condotte da monxresearch-sec, QuickLens sarebbe stato messo in vendita su marketplace dedicati alla compravendita di estensioni, per poi cambiare ufficialmente sviluppatore nel febbraio 2026. Poco dopo il trasferimento, è stata distribuita un aggiornamento che introduceva codice malevolo pur mantenendo le funzionalità originali.

Questo schema consente agli attaccanti di sfruttare la fiducia accumulata dall’estensione nel tempo, inclusi badge di qualità o recensioni positive nello store, per distribuire aggiornamenti compromessi a migliaia di utenti già installati.

Tecniche avanzate di esecuzione del payload nel browser

L’analisi tecnica ha rivelato un meccanismo di compromissione particolarmente sofisticato. L’estensione QuickLens modificata era in grado di rimuovere header di sicurezza HTTP come X-Frame-Options, aprendo la strada all’esecuzione di script malevoli che bypassano le protezioni di sicurezza del browser, inclusa la Content Security Policy (CSP).

Il codice introduceva inoltre funzioni di fingerprinting del sistema, raccogliendo informazioni sul Paese dell’utente, sul browser e sul sistema operativo. L’estensione contattava poi periodicamente un server di comando e controllo (C2), da cui riceveva codice JavaScript aggiuntivo.

Il payload non era presente nei file dell’estensione, ma veniva scaricato dinamicamente dal server remoto e salvato nello storage locale del browser, rendendo molto più difficile l’individuazione attraverso analisi statiche.

Per attivare il codice, gli sviluppatori malevoli utilizzavano una tecnica ingegnosa: un elemento <img> invisibile da un pixel veniva inserito nella pagina e il codice JavaScript veniva assegnato all’attributo onload. In questo modo il payload veniva eseguito automaticamente al caricamento della pagina, senza apparire direttamente nel codice dell’estensione.

Come si vede, la parte tecnica denota un buon livello di competenza, organizzazione e proceduralizzazione delle operazioni. Tutti segni che si tratta di un professionista sia dell’informatica, sia del crimine.

 Dal browser al sistema: la catena d’attacco ClickFix

La seconda estensione compromessa, ShotBird, implementava una variante differente della stessa strategia. In questo caso il codice malevolo mostrava un falso messaggio di aggiornamento di Google Chrome, inducendo l’utente a eseguire manualmente una serie di operazioni nel sistema operativo.

La vittima veniva reindirizzata a una pagina costruita secondo la tecnica nota come ClickFix. Qui l’utente riceveva istruzioni per aprire la finestra Run di Windows, lanciare cmd.exe e incollare un comando PowerShell.

Questo processo portava al download di un file eseguibile chiamato googleupdate.exe, che permetteva agli attaccanti di eseguire codice direttamente sul sistema compromesso.

Una volta installato, il malware era progettato per intercettare dati inseriti nei moduli web, tra cui credenziali, codici PIN, numeri di carta, token e identificativi personali. Il codice poteva inoltre accedere ai dati memorizzati nel browser, inclusi password salvate, cronologia di navigazione e informazioni sulle estensioni installate.

Un problema sistemico della supply chain delle estensioni

Le indagini indicano che lo stesso attore potrebbe essere responsabile della compromissione di entrambe le estensioni, data la presenza di infrastrutture di comando e controllo simili e tecniche operative identiche e il caso evidenzia un fenomeno, come anticipavamo, sempre più diffuso: la compravendita di estensioni browser come vettore di attacco supply chain.

Un’estensione popolare e verificata può cambiare proprietario e trasformarsi improvvisamente in uno strumento di sorveglianza o distribuzione malware. Inoltre, il problema non riguarda solo queste due estensioni: i ricercatori, infatti, hanno individuato altre campagne malevole nello store di Chrome.

Un esempio è lmΤoken Chromophore, un’estensione che si presenta come un semplice visualizzatore di colori ma che reindirizza automaticamente gli utenti verso un sito di phishing progettato per rubare le seed phrase dei wallet di criptovalute.

Altri casi includono estensioni che sfruttano tecniche di browser hijacking e affiliate hijacking, alterando la home page o il motore di ricerca del browser per generare traffico monetizzabile.

---

---

---

https://www.securityinfo.it/2026/03/10/plug-in-di-chrome-cambiano-proprieta-e-diventano-malware/?utm_source=rss&utm_medium=rss&utm_campaign=plug-in-di-chrome-cambiano-proprieta-e-diventano-malware

Mar 06, 2026 Redazione Approfondimenti, Attacchi, Attacchi, Attacco non convenzionale, In evidenza, Minacce, Minacce, Minacce, News, RSS 0

---

Nel mondo dello sviluppo software e delle infrastrutture IT, copiare e incollare comandi di installazione da documentazioni online è diventata una pratica quotidiana. Ma proprio questa abitudine, ormai radicata tra sviluppatori, amministratori di sistema e professionisti DevOps, sta diventando il punto di ingresso per una nuova tecnica di social engineering. I ricercatori della società di sicurezza Push Security hanno infatti individuato una nuova variante degli attacchi ClickFix, ribattezzata InstallFix, che sfrutta false guide di installazione per indurre le vittime a eseguire comandi malevoli direttamente dal terminale.

Il principio è semplice quanto efficace: convincere l’utente a eseguire manualmente un comando che, apparentemente, serve a installare uno strumento legittimo. In realtà, quel comando scarica e avvia malware progettati per sottrarre dati sensibili dal sistema. L’elemento che rende questa tecnica particolarmente insidiosa è il fatto che l’utente stesso avvia l’operazione, riducendo drasticamente i segnali di anomalia che potrebbero essere intercettati dagli strumenti di sicurezza tradizionali.

Pagine clonate e istruzioni manipolate

Uno degli esempi più recenti riguarda la clonazione della pagina di installazione di Claude Code, l’assistente di programmazione via riga di comando sviluppato da Anthropic. Gli attaccanti hanno creato una replica quasi perfetta della documentazione ufficiale, riproducendo fedelmente layout grafico, branding e persino la struttura della sidebar con i link alla documentazione.

La pagina fraudolenta è praticamente indistinguibile da quella originale. Tutti i collegamenti presenti rimandano al sito autentico di Anthropic, aumentando ulteriormente la credibilità del contenuto. L’unico elemento alterato riguarda le istruzioni di installazione per macOS e Windows. I comandi suggeriti all’utente, anziché scaricare il software legittimo, eseguono codice che recupera malware da server controllati dagli attaccanti.

Questa strategia consente alla vittima di continuare a navigare il sito ufficiale anche dopo aver eseguito il comando malevolo, senza accorgersi che l’infezione è già avvenuta.

Il ruolo del malvertising nei motori di ricerca

La distribuzione di queste pagine fraudolente avviene attraverso campagne di malvertising sui motori di ricerca. Gli aggressori acquistano annunci sponsorizzati su piattaforme pubblicitarie, facendo apparire i link malevoli tra i primi risultati per ricerche come “Claude Code install” o “Claude Code CLI”.

Gli utenti che cliccano sugli annunci vengono reindirizzati verso domini apparentemente legittimi ospitati su piattaforme affidabili come Cloudflare Pages, Squarespace o Tencent EdgeOne.

Alla base dell’efficacia della tecnica InstallFix c’è una pratica diffusa nella comunità degli sviluppatori: l’utilizzo dei cosiddetti comandi “curl-to-bash”. Questo approccio consente di installare software scaricando ed eseguendo automaticamente uno script remoto con una singola riga di comando.

In molti casi, lo script viene eseguito senza che l’utente ne verifichi il contenuto, basandosi esclusivamente sulla reputazione del dominio da cui viene scaricato. Secondo i ricercatori, il modello di sicurezza implicito in queste operazioni si riduce spesso a una logica estremamente fragile: se il dominio sembra legittimo, allora il comando viene considerato sicuro.

Con l’espansione degli strumenti CLI e degli assistenti di programmazione basati su intelligenza artificiale, sempre più utenti non strettamente tecnici stanno adottando strumenti che richiedono l’esecuzione di comandi di installazione complessi. Questo ampliamento della platea rende le campagne InstallFix particolarmente promettenti per i cybercriminali.

Amatera Stealer, il malware distribuito

Il payload utilizzato nelle campagne osservate è Amatera Stealer, una famiglia relativamente recente di malware progettata per il furto di informazioni sensibili. Gli analisti ritengono che il malware sia derivato da ACR Stealer e venga distribuito attraverso un modello Malware-as-a-Service, che consente a diversi gruppi criminali di utilizzarlo tramite abbonamento.

Una volta eseguito sul sistema della vittima, Amatera è in grado di sottrarre credenziali salvate nei browser, cookie e token di sessione, oltre a raccogliere informazioni dettagliate sul sistema compromesso. Il malware può inoltre individuare e sottrarre dati relativi a portafogli di criptovalute, aumentando il valore economico delle informazioni esfiltrate.

La famiglia Amatera include anche tecniche di evasione progettate per evitare il rilevamento da parte degli strumenti di sicurezza e prolungare la permanenza del malware nel sistema compromesso.

Tecniche di esecuzione diverse per Windows e macOS

Gli attacchi InstallFix utilizzano approcci leggermente differenti a seconda del sistema operativo della vittima. Nel caso dei sistemi macOS, i comandi malevoli contengono istruzioni codificate in base64 che scaricano e avviano un binario remoto da domini controllati dagli attaccanti.

Nei sistemi Windows, invece, l’attacco sfrutta l’utility di sistema mshta.exe per recuperare il malware remoto. L’esecuzione del payload coinvolge anche processi di sistema come conhost.exe, utilizzati per supportare l’avvio del codice malevolo.

L’utilizzo di strumenti legittimi già presenti nel sistema operativo consente agli aggressori di ridurre i segnali di anomalia e aumentare le probabilità di successo dell’infezione.

Una nuova superficie di attacco per l’ecosistema DevOps

Le campagne InstallFix evidenziano una debolezza strutturale nell’ecosistema degli strumenti per sviluppatori. La fiducia implicita nei comandi pubblicati online, unita alla diffusione di piattaforme di distribuzione automatica del software, crea una superficie d’attacco ampia e difficile da controllare.

La combinazione di siti clonati, risultati sponsorizzati nei motori di ricerca e comandi di installazione automatica rende questi attacchi particolarmente credibili anche per utenti esperti. Il fatto che l’infezione avvenga tramite un comando eseguito manualmente dall’utente complica ulteriormente l’individuazione dell’attacco.

Per questo motivo, i ricercatori raccomandano di ottenere le istruzioni di installazione esclusivamente dai siti ufficiali dei produttori software, evitando i risultati sponsorizzzati dei motori di ricerca e verificando sempre il contenuto degli script prima di eseguirli. Salvare tra i preferiti i portali di download ufficiali degli strumenti utilizzati più frequentemente può rappresentare una misura semplice ma efficace per ridurre il rischio.

---

---

---

https://www.securityinfo.it/2026/03/06/installfix-false-guide-di-installazione-cli-per-installare-infostealer/?utm_source=rss&utm_medium=rss&utm_campaign=installfix-false-guide-di-installazione-cli-per-installare-infostealer

Mar 05, 2026 Giancarlo Calzetta Approfondimenti, In evidenza, News, RSS, Scenario, Scenario 0

---

L’adozione crescente dell’intelligenza artificiale generativa nel cybercrime sta modificando in profondità il modo in cui vengono progettati e analizzati gli attacchi informatici. Secondo Kaspersky, uno degli effetti più rilevanti riguarda l’attribuzione delle operazioni malevole: l’AI tende a cancellare le “impronte digitali” degli attaccanti, rendendo molto più difficile collegare un attacco a uno specifico gruppo criminale.

Gli esperti del Global Research and Analysis Team (GReAT) segnalano che gli aggressori stanno utilizzando sempre più spesso modelli generativi per produrre codice, email di phishing e altri contenuti operativi. Questa evoluzione modifica uno dei pilastri tradizionali della threat intelligence, basato sull’analisi di pattern linguistici, errori ricorrenti o stili di programmazione che permettevano di identificare l’autore di un attacco.

L’AI elimina le “impronte digitali” degli attaccanti

Una delle tecniche usate dagli analisti per ricostruire l’identità o almeno l’origine di un attacco informatico consisteva nell’analizzare una serie di indicatori relativamente affidabili. Errori grammaticali, peculiarità linguistiche, stili di scrittura del codice o abitudini operative rappresentavano elementi utili per collegare campagne diverse allo stesso gruppo.

L’utilizzo dell’intelligenza artificiale cambia radicalmente questo scenario. I contenuti generati dai modelli AI tendono a essere neutri e privi di tratti distintivi, rendendo molto più complesso individuare le caratteristiche di uno specifico attore malevolo.

Secondo i ricercatori di Kaspersky, questa trasformazione costringerà gli analisti della sicurezza a spostare il focus dell’attribuzione verso altri elementi, come l’infrastruttura utilizzata, le sovrapposizioni tra strumenti impiegati e gli indicatori comportamentali delle operazioni.

Malware generato con AI: dai moduli ai framework completi

L’intelligenza artificiale non si limita a migliorare la qualità delle campagne di phishing. Sempre più spesso viene impiegata anche nello sviluppo del malware.

I modelli linguistici di grandi dimensioni sono infatti in grado di generare porzioni significative di codice malevolo, contribuendo alla creazione della struttura iniziale dei programmi e dei moduli funzionali. Questo approccio consente agli attaccanti di ridurre drasticamente i tempi di sviluppo e di adattare rapidamente i propri strumenti.

Secondo Kaspersky, forme di sviluppo assistito dall’AI sono già state osservate in campagne attribuite al gruppo FunkSec, che ha distribuito malware scritto in Rust in grado di sottrarre dati, cifrare informazioni e manipolare processi di sistema.

Un altro esempio è rappresentato dalla campagna RevengeHotels, osservata nel 2025, in cui i threat actor hanno utilizzato modelli linguistici per generare parti del codice di infezione e dei downloader utilizzati nella catena di attacco.

“Prevediamo che l’intelligenza artificiale rimarrà uno dei fattori chiave nel plasmare il panorama delle minacce nel 2026” – ha dichiarato Georgy Kucherin, Senior Security Researcher del GReAT di Kaspersky. Secondo il ricercatore, riducendo tempi e costi necessari per sviluppare strumenti malevoli, l’AI consente agli attaccanti di ampliare il numero e la portata delle proprie operazioni.

---

• agenti AI sicurezza, AI cybercrime, attribuzione attacchi informatici, cyber threat landscape 2026, esfiltrazione dati cloud, FunkSec malware Rust, Kaspersky GReAT, malware generato da AI, phishing AI generated, ransomware mirato, RevengeHotels campaign, threat intelligence AI

---

---

https://www.securityinfo.it/2026/03/05/cybercrime-e-ai-lattribuzione-degli-attacchi-diventa-sempre-piu-difficile/?utm_source=rss&utm_medium=rss&utm_campaign=cybercrime-e-ai-lattribuzione-degli-attacchi-diventa-sempre-piu-difficile

Mar 04, 2026 Giancarlo Calzetta Attacchi, In evidenza, News, RSS 0

---

Nuove campagne di phishing stanno sfruttando in modo strumentale il protocollo OAuth per distribuire malware e compromettere endpoint aziendali, con un focus particolare su organizzazioni governative e del settore pubblico. A diffondere la notizia è stata Microsoft stessa che ha rilevato un abuso sistematico dei meccanismi di redirect legittimi previsti dallo standard di autorizzazione.

Secondo quanto comunicato dal team di sicurezza di Redmond, alcune applicazioni OAuth malevole sono già state disabilitate su Microsoft Entra ID, ma attività correlate risultano ancora in corso e richiedono monitoraggio continuo. Non sono stati resi noti dettagli su scala e impatto delle campagne.

OAuth come vettore: quando il redirect diventa arma

OAuth (Open Authorization) è lo standard utilizzato per consentire l’accesso a servizi online tramite credenziali di terze parti, come Google, Facebook o Apple, attraverso l’uso di access token. Una delle funzionalità previste dallo standard permette agli identity provider di reindirizzare l’utente verso una landing page in caso di errore durante il processo di autenticazione. E proprio questa caratteristica viene sfruttata dagli attaccanti.

I criminali creano URL OAuth apparentemente legittimi, utilizzando provider come Microsoft Entra ID o Google Workspace, ma manipolano specifici parametri per generare volutamente un errore nel processo di login. L’errore innesca un redirect verso una pagina sotto il controllo degli attaccanti, dalla quale viene scaricato il payload malevolo.

Un esempio di URL osservato nelle campagne contro Entra ID include parametri come scope non validi e prompt=none, combinati in modo tale da produrre un comportamento anomalo pur mantenendo un’apparenza coerente con una richiesta OAuth standard.

Come evidenziato dai ricercatori Microsoft, l’obiettivo non è il furto degli access token, poiché l’utente non concede alcun permesso all’applicazione. Lo scopo è invece forzare un errore che attivi il meccanismo di redirect, trasformando un flusso legittimo in un veicolo di distribuzione malware.

Dalla mail al C2: la catena di infezione

Le campagne iniziano con email di phishing che simulano richieste di firma elettronica, notifiche di registrazioni di riunioni Teams, reset password Microsoft 365 o contenuti a tema politico. I link malevoli vengono inseriti nel corpo del messaggio o, in alcuni casi, nascosti in allegati PDF.

Gli indicatori suggeriscono l’uso di strumenti di mass mailing preconfigurati, oltre a soluzioni custom sviluppate in Python e Node.js. Sono stati impiegati anche servizi cloud di posta elettronica e macchine virtuali ospitate nel cloud per la distribuzione delle email.

Una volta attivato il redirect OAuth, la vittima viene condotta su piattaforme di phishing-as-a-service come EvilProxy, in grado di intercettare credenziali e cookie di sessione.

In una delle campagne documentate, il redirect conduceva a un percorso /download/XXXX che avviava automaticamente il download di un archivio ZIP. Il contenuto includeva file LNK e loader basati su HTML smuggling.

L’apertura del file LNK innescava l’esecuzione di un comando PowerShell che avviava una fase di ricognizione del sistema. Successivamente veniva eseguito un file legittimo, steam_monitor.exe, utilizzato per effettuare side-loading di una DLL malevola denominata crashhandler.dll.

La DLL provvedeva a decrittare crashlog.dat ed eseguire il payload finale in memoria, stabilendo una connessione outbound verso un endpoint di command-and-control esterno.

Persistenza e rotazione dei domini: evasione dinamica

Un ulteriore elemento critico riguarda la flessibilità dell’infrastruttura attaccante. Ospitando il payload su URI di redirect controllati, gli attori malevoli possono ruotare rapidamente domini e destinazioni quando vengono bloccati dai filtri di sicurezza.

Questo approccio rende più complessa l’attività di detection basata su blacklist statiche e impone l’adozione di controlli comportamentali e analisi dei flussi OAuth anomali.

---

• crashhandler.dll, credential interception, DLL side-loading, EvilProxy, LNK malware, malware delivery, Microsoft Entra ID, OAuth phishing, OAuth redirect abuse, OAuth URL manipulation, phishing-as-a-service, PowerShell attack chain, sicurezza enti pubblici, steam_monitor.exe abuse

---

---

https://www.securityinfo.it/2026/03/04/phishing-via-oauth-campagne-contro-enti-pubblici-sfruttano-i-redirect-di-microsoft-entra-per-distribuire-malware/?utm_source=rss&utm_medium=rss&utm_campaign=phishing-via-oauth-campagne-contro-enti-pubblici-sfruttano-i-redirect-di-microsoft-entra-per-distribuire-malware

Mar 03, 2026 Giancarlo Calzetta In evidenza, News, RSS, Vulnerabilità 0

---

Google ha rilasciato gli aggiornamenti di sicurezza Android di marzo correggendo 129 vulnerabilità, tra cui una falla zero-day già sfruttata in attacchi mirati. La vulnerabilità, tracciata come CVE-2026-21385, interessa un componente grafico sviluppato da Qualcomm e, secondo quanto comunicato nel bollettino ufficiale, sarebbe oggetto di “limited, targeted exploitation”, ovvero di uno sfruttamento limitato, ma su bersagli precisi.

CVE-2026-21385: overflow nel sottocomponente Graphics

Secondo l’advisory pubblicato da Qualcomm il 3 febbraio, la vulnerabilità è un integer overflow (o wraparound) nel sottocomponente Graphics, sfruttabile da un attaccante locale per provocare corruzione della memoria.

L’azienda ha dichiarato di essere stato informato della vulnerabilità il 18 dicembre e di aver notificato i clienti il 2 febbraio. La falla, classificata come gravità elevata, coinvolgerebbe 235 chipset Qualcomm, ampliando significativamente la superficie potenzialmente esposta.

Dieci vulnerabilità critiche: RCE senza interazione utente

Oltre alla zero-day Qualcomm, il bollettino Android di marzo include la correzione di 10 vulnerabilità critiche nei componenti System, Framework e Kernel.

La più grave riguarda il componente System e potrebbe consentire remote code execution senza necessità di privilegi aggiuntivi né interazione da parte dell’utente. Una condizione che, se sfruttata in catene di exploit, potrebbe facilitare compromissioni silenziose su larga scala.

Le altre vulnerabilità critiche permettono escalation di privilegi o condizioni di denial-of-service, confermando come il livello di rischio nel layer basso del sistema operativo resti elevato, soprattutto in scenari dove gli aggiornamenti non vengono applicati tempestivamente.

Patch level 2026-03-01 e 2026-03-05: il nodo frammentazione

Google ha distribuito due livelli di patch: 2026-03-01 e 2026-03-05. Il secondo include tutte le correzioni del primo, oltre a fix relativi a componenti closed-source di terze parti e a sottocomponenti del kernel, che potrebbero non essere applicabili a tutti i dispositivi.

Come noto, i dispositivi Google Pixel ricevono gli aggiornamenti in modo immediato, mentre gli altri vendor devono integrare, testare e adattare le patch alle specifiche configurazioni hardware. Questo passaggio introduce ritardi variabili che, in presenza di una zero-day già sfruttata, possono tradursi in finestre di esposizione significative.

Per i team di sicurezza mobile e per i CISO, l’episodio conferma la necessità di monitorare costantemente i livelli di patch installati sui dispositivi aziendali, soprattutto in ambienti BYOD o in flotte eterogenee. La presenza di chipset Qualcomm in centinaia di modelli rende la gestione del rischio ancora più complessa.

---

• Android kernel vulnerability, Android marzo 2026 patch, Android security update, Android vulnerability, chipset Qualcomm exploit, CVE-2026-21385, integer overflow graphics, memory corruption Android, patch level 2026-03-05, Qualcomm zero-day, remote code execution Android, sicurezza mobile enterprise

---

---

https://www.securityinfo.it/2026/03/03/android-129-vulnerabilita-corrette-zero-day-qualcomm-gia-sfruttata/?utm_source=rss&utm_medium=rss&utm_campaign=android-129-vulnerabilita-corrette-zero-day-qualcomm-gia-sfruttata

Mar 02, 2026 Giancarlo Calzetta In evidenza, News, RSS, Vulnerabilità 0

---

Palo Alto, azienda specializzata in sicurezza informatica, ha scoperto una vulnerabilità nel browser Google Chrome avrebbe potuto trasformare l’assistente AI integrato in uno strumento di sorveglianza e furto dati. Il problema è stato segnalato a Google dopodiché è stata catalogata come CVE-2026-0628 e corretta a gennaio con il rilascio di Chrome 143.

Il problema riguardava Gemini Live, il pannello laterale AI di Chrome progettato per assistere l’utente nella navigazione tramite riassunti in tempo reale, esecuzione automatica di task e comprensione contestuale delle pagine web. Tutte funzioni molto utili, ma che che, come dimostra questo caso, ampliano in modo significativo la superficie d’attacco del browser.

L’AI nel browser: potere operativo e nuovi rischi

Gemini Live è concepito per “vedere” ciò che vede l’utente: il modello accede al contenuto della pagina attiva, ne interpreta il contesto e può eseguire azioni complesse direttamente dall’interfaccia del browser. Questo approccio consente operazioni multi-step che, fino a poco tempo fa, richiedevano estensioni dedicate o interventi manuali.

Secondo l’analisi di Palo Alto Networks, proprio questo accesso privilegiato all’ambiente di navigazione rappresenta il punto critico. L’AI non è una semplice estensione: è un componente nativo del browser con capacità avanzate, incluse interazioni con file locali, screenshot delle schede, accesso a microfono e videocamera.

In altre parole, l’assistente dispone di permessi che vanno oltre quelli normalmente concessi a un’estensione tradizionale e se un attore malevolo riesce a inserirsi in quel flusso, eredita lo stesso livello di privilegio.

Come funzionava l’attacco: estensioni malevole e declarativeNetRequests

La vulnerabilità CVE-2026-0628 avrebbe consentito a estensioni dannose di iniettare codice JavaScript all’interno del pannello Gemini Live. Per farlo, l’estensione doveva disporre di un set specifico di permessi attraverso l’API declarativeNetRequests che permette di intercettare e modificare richieste e risposte HTTPS.

Questa API nasce con finalità legittime, come il blocco di richieste intrusive o malevole, ma grazie alla possibilità di interagire con contenuti originati da Gemini e caricati nella scheda del sito sarebbe potuta diventare un vettore di compromissione.

In pratica, l’estensione avrebbe potuto intercettare il flusso tra il browser e il pannello AI, inserendo codice in grado di sfruttare le capacità operative dell’assistente. Tra gli scenari ipotizzati: attivazione silenziosa di microfono e videocamera, accesso ai file locali, cattura di screenshot delle schede aperte e persino l’orchestrazione di campagne phishing sfruttando l’interfaccia di Gemini.

Il punto più delicato è che il pannello Gemini è parte integrante del browser. Non si tratta di un plugin isolato, ma di un componente con accesso diretto alle risorse di sistema. Il dirottamento dell’assistente avrebbe quindi permesso a un’estensione di aggirare i normali limiti di sicurezza, ottenendo privilegi superiori rispetto a quelli previsti dal modello di sicurezza standard di Chrome.

Patch e implicazioni per la sicurezza dei browser AI-native

Palo Alto Networks ha segnalato la vulnerabilità a Google lo scorso ottobre. La correzione è stata distribuita con le versioni 143.0.7499.192 e 143.0.7499.193 per Windows e macOS, e con la 143.0.7499.192 per Linux.

L’episodio evidenzia un tema destinato a diventare centrale nel dibattito sulla sicurezza applicativa: l’integrazione nativa di modelli AI nei browser modifica radicalmente il perimetro di fiducia. Se l’assistente dispone di accesso privilegiato per eseguire operazioni legittime, qualsiasi vulnerabilità nel suo canale di comunicazione diventa un moltiplicatore di rischio.

Per i professionisti della sicurezza IT, il caso CVE-2026-0628 rappresenta un campanello d’allarme che sentiamo ormai suonare sempre più spesso. L’evoluzione verso browser AI-native richiede una revisione delle strategie di hardening, monitoraggio delle estensioni e controllo dei permessi concessi. Non è più sufficiente valutare il rischio delle estensioni in modo isolato: occorre considerare anche l’interazione con componenti intelligenti ad alto privilegio

---

• AI assistant, browser security, Chrome 143 patch, CVE-2026-0628, declarativeNetRequests API, esfiltrazione dati, estensioni malevole, Gemini Live, Google Chrome, hijacking browser, Palo Alto Networks, phishing via browser, sicurezza AI, vulnerabilità Chrome

---

---

https://www.securityinfo.it/2026/03/02/una-falla-in-chrome-sfrutta-gemini-live-per-scopi-malevoli/?utm_source=rss&utm_medium=rss&utm_campaign=una-falla-in-chrome-sfrutta-gemini-live-per-scopi-malevoli

Feb 27, 2026 Giancarlo Calzetta Approfondimenti, Attacchi, Attacchi, In evidenza, News, RSS, Scenario, Scenario 0

---

Il ransomware continua a evolvere come una delle minacce più pervasive per organizzazioni pubbliche e private e i dati emersi dal Crypto Crime Report 2026 di Chainalysis fotografano un fenomeno apparentemente contraddittorio. Nel 2025 i pagamenti legati al ransomware sono diminuiti per il secondo anno consecutivo, ma allo stesso tempo il numero di attacchi e di vittime rivendicate ha raggiunto livelli record, segnando un nuovo punto di svolta nell’economia dell’estorsione digitale.

Secondo il report, i gruppi ransomware hanno incassato circa 820 milioni di dollari nel 2025, con un calo dell’8% rispetto all’anno precedente. La quota di vittime disposte a pagare è scesa al minimo storico del 28%, segnale di una maggiore resilienza organizzativa, di politiche di risposta più mature e di una crescente pressione normativa e assicurativa contro il pagamento dei riscatti. Tuttavia, questa apparente buona notizia è controbilanciata da un incremento significativo delle richieste economiche: il riscatto mediano è passato da 12.738 dollari nel 2024 a 59.556 dollari nel 2025, evidenziando una strategia criminale orientata a massimizzare il valore di ogni singolo attacco.

Volume record e frammentazione dell’ecosistema criminale

Il vero elemento distintivo del 2025 non è stato il valore complessivo dei riscatti, bensì il volume degli attacchi. I dati eCrime.ch indicano un aumento del 50% anno su anno delle vittime, rendendo il 2025 l’anno più attivo mai registrato per il ransomware. Questa crescita riflette una trasformazione strutturale del panorama delle minacce, dove la pressione estorsiva non è più dominata esclusivamente dai grandi brand criminali.

Il panorama dei gruppi ransomware appare infatti sempre più frammentato. Le operazioni delle forze dell’ordine, le sanzioni internazionali e gli arresti hanno colpito nomi storici come LockBit e BlackCat, ma il vuoto è stato rapidamente riempito da spin-off, affiliati opportunisti e nuovi attori meno strutturati. Questi gruppi minori contribuiscono a un numero crescente di tentativi di estorsione, molti dei quali non si traducono in pagamenti tracciabili, rendendo più complessa la valutazione economica reale del fenomeno.

Gli eventi di maggiore impatto mediatico hanno comunque contribuito a definire il 2025 come un anno critico. Il caso Jaguar Land Rover è stato descritto come l’incidente cyber più costoso nella storia del Regno Unito, mentre Marks & Spencer ha subito una prolungata interruzione operativa dopo una violazione attribuita a un gruppo legato a Scattered Spider, con conseguenze rilevanti sul valore di mercato. Tuttavia, il report sottolinea che la vera storia non è quella dei mega-breach, ma la crescita costante del volume complessivo degli attacchi, spesso rivolti a organizzazioni di dimensioni medie o a supply chain complesse.

Leak site e pressione reputazionale come leva strategica

I dati di Emsisoft rafforzano questa lettura, indicando che oltre 8.000 organizzazioni sono state pubblicamente nominate sui leak site nel 2025, un incremento significativo rispetto agli anni precedenti. L’esposizione pubblica continua a rappresentare uno degli strumenti più efficaci per forzare le vittime alla negoziazione, soprattutto in contesti regolamentati o ad alta visibilità.

Le economie avanzate restano nel mirino privilegiato degli attaccanti. Gli Stati Uniti guidano la classifica delle vittime, seguiti da Canada, Germania, Regno Unito e dal resto dell’Europa occidentale. I settori più colpiti includono manifatturiero, finanziario e servizi professionali, mentre in Canada e Germania emerge un interesse particolare verso supply chain, logistica e infrastrutture critiche. Negli Stati Uniti, invece, l’aumento delle vittime ha interessato trasversalmente tutti i comparti, compresi governo e infrastrutture essenziali.

Questa distribuzione geografica e settoriale evidenzia come il ransomware sia ormai una minaccia sistemica, capace di colpire ecosistemi economici complessi e di generare impatti a cascata su partner, fornitori e clienti. L’effetto reputazionale e operativo derivante dalla pubblicazione sui leak site si conferma quindi un elemento centrale della strategia estorsiva moderna.

Il ransomware come supply chain criminale

Uno degli insight più rilevanti del report Chainalysis riguarda l’evoluzione del ransomware verso un modello simile a una supply chain criminale. In questo contesto, gli Initial Access Broker (IAB) svolgono un ruolo sempre più determinante, fungendo da intermediari che vendono accessi compromessi alle reti aziendali già pronti all’uso. Nel 2025, gli IAB hanno ricevuto almeno 14 milioni di dollari in pagamenti on-chain, una cifra modesta rispetto al totale ransomware ma strategicamente significativa.

L’analisi di Chainalysis evidenzia infatti una correlazione temporale tra l’aumento dei pagamenti agli IAB e la successiva crescita degli attacchi ransomware: i picchi nelle transazioni verso questi intermediari precedono di circa 30 giorni l’aumento dei pagamenti ransomware e delle pubblicazioni sui leak site. Questo pattern suggerisce una filiera operativa strutturata, in cui l’accesso iniziale viene acquistato, monetizzato e trasformato in campagne estorsive con tempistiche relativamente prevedibili.

Il report conclude che il ransomware non sta diminuendo, ma si sta trasformando. Meno organizzazioni pagano, ma più organizzazioni vengono colpite, le richieste economiche aumentano e il mercato degli accessi compromessi continua a prosperare, preparando il terreno per nuove ondate di disclosure e campagne di estorsione. Ma questo significa anche che la promozione della resilienza aziendale ha funzionato, iniziando a minare il terreno che ha portato alla crescita del ransomware: la sua redditività.

---

---

---

https://www.securityinfo.it/2026/02/27/paradosso-ransomware-pagamenti-in-calo-ma-attacchi-ai-massimi-storici/?utm_source=rss&utm_medium=rss&utm_campaign=paradosso-ransomware-pagamenti-in-calo-ma-attacchi-ai-massimi-storici

Feb 27, 2026 Redazione Approfondimenti, In evidenza, Minacce, Minacce, News, RSS, Tecnologia, Tecnologia, Vulnerabilità 0

---

L’introduzione di funzionalità di intelligenza artificiale generativa nelle piattaforme cloud sta ridefinendo il perimetro di sicurezza delle credenziali applicative. Un caso emblematico è stato scoperto dai ricercatori di Truffle Security Co. e riguarda l’ecosistema Google Cloud dove le tradizionali API key — storicamente considerate semplici identificatori di progetto — hanno acquisito nuovi privilegi con l’arrivo di Gemini. Il risultato è una superficie d’attacco inattesa, in cui migliaia di chiavi pubbliche possono essere sfruttate per accedere a dati privati, consumare risorse e generare costi anche elevati.

Un cambio di paradigma nella gestione delle API key

Per oltre un decennio Google ha comunicato in modo esplicito che le API key non erano né andavano trattate come segreti. La documentazione di servizi come Google Maps e Firebase invitava infatti gli sviluppatori a inserirle direttamente nel codice client o nelle pagine HTML, poiché il loro scopo principale era identificare il progetto ai fini di fatturazione e monitoraggio. Eventuali restrizioni, come l’allow-listing dei referer HTTP, venivano considerate controlli accessori e non meccanismi di autenticazione.

L’arrivo della Generative Language API, che abilita l’accesso a Gemini, ha però modificato radicalmente questa premessa. Quando l’API viene attivata in un progetto Google Cloud, tutte le API key esistenti associate a quel progetto possono ottenere automaticamente accesso agli endpoint sensibili di Gemini, senza notifiche, conferme o cambiamenti visibili nell’interfaccia di gestione. In altri termini, una chiave creata anni prima per un widget di Maps può trasformarsi silenziosamente in una credenziale capace di interrogare modelli generativi a nome di qualcun altro e accedere ai dati del progetto.

Questa dinamica introduce una forma di espansione retroattiva dei privilegi, in cui la sequenza temporale degli eventi diventa determinante. La chiave nasce come identificatore pubblico, l’API Gemini viene attivata successivamente e, senza alcun intervento dell’utente, la stessa chiave assume un ruolo autentico e sensibile. Il problema non è dunque una configurazione errata, ma un difetto architetturale legato a default permissivi e alla mancanza di separazione tra chiavi pubbliche e segrete.

Default insicuri e rischio di privilege escalation

Alla base della vulnerabilità vi è il fatto che Google utilizza un formato unico di API key (prefisso AIza…) per scenari con requisiti di sicurezza profondamente diversi. Quando una nuova chiave viene generata, la configurazione predefinita è “unrestricted”, rendendola valida per tutte le API abilitate nel progetto, incluse quelle generative. L’interfaccia segnala genericamente il rischio di uso non autorizzato, ma l’impostazione di default resta permissiva.

Questo scenario si allinea a due debolezze note: posture di sicurezza con default insicuri e assegnazione impropria dei privilegi. L’assenza di separazione tra chiavi pubbliche e segrete favorisce confusione operativa e compromissioni, mentre l’upgrade implicito dei privilegi applicato a chiavi già esposte in ambienti pubblici rappresenta una forma di trust escalation difficilmente individuabile dagli sviluppatori.

Lo scenario di attacco: scraping e accesso ai dati Gemini

Dal punto di vista operativo, l’exploit è estremamente semplice. Un attaccante può visitare un sito web, recuperare dal codice sorgente una API key utilizzata per servizi come Maps e inviarla a un endpoint Gemini. In diversi casi analizzati, la richiesta non restituisce un errore ma una risposta valida, segno che la chiave è accettata per operazioni sensibili.

Una volta ottenuto l’accesso, il threat actor può interrogare endpoint che contengono file caricati, dataset, documenti e contenuti cache del progetto. Oltre alla compromissione della riservatezza dei dati, emerge il rischio economico: l’uso massivo delle API generative può generare costi elevati e saturare le quote disponibili, causando interruzioni ai servizi legittimi. L’attaccante non deve compromettere infrastrutture o credenziali interne, ma semplicemente sfruttare una chiave pubblica già esposta.

L’impatto reale: migliaia di chiavi vulnerabili online

Un’analisi condotta sul dataset Common Crawl di novembre 2025 ha individuato 2.863 API key Google attive potenzialmente sfruttabili attraverso questo vettore. Tra le organizzazioni coinvolte figurano istituzioni finanziarie, aziende di sicurezza e realtà globali del recruiting, a dimostrazione di quanto il problema non sia limitato a progetti marginali.

Particolarmente significativo è il fatto che anche Google stessa presentasse chiavi pubbliche esposte su siti di prodotto che, una volta testate, risultavano valide per interrogare endpoint Gemini. Durante un test, una chiave pubblicata da anni per finalità innocue ha restituito una risposta positiva alla richiesta di elenco modelli generativi disponibili, confermando la trasformazione silenziosa dei privilegi.

La disclosure e la risposta di Google

La vulnerabilità è stata segnalata a Google nel novembre 2025 attraverso il Vulnerability Disclosure Program. In una prima fase il comportamento è stato classificato come previsto, ma l’evidenza fornita — inclusi esempi interni a Google — ha portato a una riclassificazione come bug e a un aumento della severità. L’azienda ha quindi avviato un piano di mitigazione che include la rilevazione automatica delle chiavi esposte e la limitazione del loro accesso a Gemini.

A gennaio 2026 il problema è stato formalmente catalogato come privilege escalation limitata a un singolo servizio, mentre a febbraio risultava ancora in fase di remediation strutturale. Nonostante le difficoltà iniziali nel triage, Google ha riconosciuto il rischio e ha ampliato i meccanismi di protezione per i clienti potenzialmente esposti. Ad oggi, però, la soluzione completa è ancora mancante.  Google ha indicato alcune direttrici di miglioramento, tra cui default più restrittivi per le nuove chiavi generate tramite AI Studio, blocco automatico delle chiavi individuate come compromesse e notifiche proattive ai proprietari dei progetti.

---

---

---

https://www.securityinfo.it/2026/02/27/google-api-keys-le-chiavi-pubbliche-diventano-credenziali-sensibili/?utm_source=rss&utm_medium=rss&utm_campaign=google-api-keys-le-chiavi-pubbliche-diventano-credenziali-sensibili

Feb 25, 2026 Giancarlo Calzetta In evidenza, Mercato, News, RSS, Tecnologia 0

---

Venerdì scorso Anthropic ha presentato Claude Code Security, una nuova funzione che analizza intere codebase alla ricerca di vulnerabilità e propone patch correttive. Il rilascio, per ora, è in modalità research preview limitata per clienti enterprise e team, mentre i maintainer open source possono chiedere accesso gratuito accelerato. L’effetto immediato, però, non si è visto nei bug tracker: si è visto in Borsa, con una reazione nervosa su diversi titoli cyber e un dibattito istantaneo sul “fine dei vendor di sicurezza”.

La “tempesta perfetta”: hype sull’AI, paura di disintermediazione e un mercato già nervoso

Il sell-off è stato alimentato da un’idea semplice, quasi cinematografica: se un LLM può scansionare codice e suggerire fix, allora una fetta del lavoro di sicurezza potrebbe essere automatizzata e “commoditizzata”. In realtà, analisti e osservatori hanno rapidamente raffreddato la lettura apocalittica: l’AI sta entrando in modo sempre più profondo nella sicurezza, ma non elimina i bisogni strutturali di detection, risposta, threat intel, governance e controllo del rischio. La reazione del mercato viene descritta come un’overreaction, più legata al timing e al sentiment che a un impatto immediato sui modelli di business.

Per drammatizzare, George Kurtz (CEO di CrowdStrike) ha chiesto a Claude se il nuovo strumento potesse rimpiazzare ciò che fa la sua azienda. La risposta del modello è stata sostanzialmente un “no” e il punto non è l’aneddoto in sé, ma ciò che riflette: l’AI può essere molto brava su compiti delimitati, ma la sicurezza reale è un sistema socio-tecnico fatto di contesto, priorità, trade-off e responsabilità.

“500 vulnerabilità high-severity”: un claim potente, ma il diavolo è nei dettagli

Il lancio di Claude Code Security arriva dopo che Anthropic aveva dichiarato che Claude Opus 4.6 avrebbe individuato e validato più di 500 vulnerabilità “ad alta pericolosità” in progetti open source. È un numero che colpisce l’immaginazione, perché sposta l’immagine dalla semplice individuazione di pattern alla capacità di proporre un percorso di validazione e remediation. Ma nel mondo della sicurezza contano almeno due domande: qual è il tasso di falsi positivi e qual è il costo (in risorse e in tempo) per ottenere quei risultati. Su questo, chi lavora quotidianamente su strumenti per developer security chiede più trasparenza e metriche pubbliche.

Anthropic posiziona Claude Code Security come uno strumento context-aware, capace di “ragionare” sul codice in modo simile a un ricercatore umano: “comprende” interazioni tra componenti, “segue” il movimento dei dati e intercetta bug complessi che sfuggono a regole statiche. Se la promessa regge alla prova dei fatti, l’impatto pratico potrebbe essere notevole per team che gestiscono codebase ampie e stratificate, dove la vulnerabilità non è un pattern banale ma nasce da logica di business, integrazioni e condizioni limite. Resta però un punto chiave: Anthropic dice che nessuna modifica viene applicata senza approvazione umana.

Non è un unicum: Amazon, Microsoft e Google stanno correndo nella stessa direzione

Claude Code Security è la novità “più chiacchierata”, ma non è la prima tessera del mosaico. In parallelo, praticamente tutti i grandi player stanno usando agenti AI per scoprire vulnerabilità e accelerare il ciclo di patching. Google aveva già parlato di Big Sleep come strumento LLM-based per caccia ai bug e più di recente DeepMind ha presentato CodeMender come agente per automatizzare la creazione di patch, individuare la root cause e generare una correzione verificabile. L’AI sta diventando un moltiplicatore di produttività nella sicurezza del software e questo non è un segreto per nessuno, si applica a tutti i campi, ma non è una bacchetta magica che sostituisce processi e responsabilità.

Inoltre, il vero banco di prova non è “se trova qualche bug”, ma se regge a scala industriale senza esplodere in falsi positivi, rumore e patch discutibili. Isaac Evans (Semgrep) ha centrato una questione che nella narrazione mainstream viene spesso messa in secondo piano: senza statistiche pubbliche su precision/recall, falsi positivi e costi, il rischio è che parte della comunicazione sia per lo più marketing. Anche ammesso che l’AI migliori sensibilmente la discovery, rimane il processo: triage, priorità, compatibilità, regressioni e governance del cambiamento in ambienti di produzione.

Perché “umani nel loop” non è una clausola di stile, ma un requisito di sicurezza

Il punto non è la sfiducia verso gli LLM: è la responsabilità. Una patch proposta da un modello può essere tecnicamente corretta e allo stesso tempo funzionalmente pericolosa, perché sposta un controllo, rompe un’integrazione o introduce un comportamento inatteso. Inoltre, gli stessi modelli che aiutano a trovare vulnerabilità possono anche produrre codice fragile o aprire nuovi vettori, soprattutto quando diventano parte del toolchain quotidiano. L’adozione sensata passa quindi da controlli: code review, test, policy di merge, e soprattutto ownership chiara su ciò che entra in produzione.

La traiettoria più credibile è che Claude Code Security e strumenti analoghi diventino una difesa aggiuntiva: un livello che anticipa problemi, accelera remediation e riduce il backlog di vulnerabilità note, soprattutto quelle ripetitive e pattern-based. È la posizione espressa anche da chi lavora sulla supply chain: qualsiasi tecnologia che aiuti a scrivere codice più sicuro è positiva, ma resta solo un elemento dentro una strategia più ampia fatta di controlli, processi, telemetria e risposta agli incidenti

---

• agentic AI, AI security, Anthropic, Big Sleep, Claude Code Security, Claude Opus 4.6, code scanning, CodeMender, context aware analysis, CrowdStrike, cybersecurity stocks, DevSecOps, false positives, Google DeepMind, patch suggestion, remediation, secure coding, secure SDLC, Semgrep, static analysis, supply chain security, vulnerability discovery

---

---

https://www.securityinfo.it/2026/02/25/claude-code-security-crea-il-panico-ma-non-uccide-la-cyber/?utm_source=rss&utm_medium=rss&utm_campaign=claude-code-security-crea-il-panico-ma-non-uccide-la-cyber

Feb 24, 2026 Redazione Attacchi, In evidenza, News, Scenari, Tecnologia 0

---

Un attacco che riprende la logica Shai-Hulud, ma sposta l’asticella sul toolchain moderno

Una recente analisi dei  ricercatori di Socket, un’azienda specializzata in sicurezza informatica, ha svelato una nuova campagna d’attacco alla supply chain dello sviluppo software colpendo NPM, l’ecosistema dove risiedono migliaia di librerie Javascript largamente usate dai programmatori di tutto il mondo. L’attacco è stato descritto come Sandworm_Mode con capacità di propagazione “worm-like”, costruita per scalare velocemente sfruttando la fiducia dell’ecosistema JavaScript e le abitudini quotidiane degli sviluppatori. L’operazione è stata attribuita a un cluster di almeno 19 pacchetti malevoli pubblicati tramite due alias e progettati per ingannare tramite typosquatting, cioè con nomi “quasi identici” a utility note, tool crypto e perfino strumenti legati al coding assistito dall’AI.

Typosquatting su utility, crypto e AI coding: l’innesco che porta il malware in pipeline

Il meccanismo d’ingresso è semplice e pericolosamente efficace: pacchetti che si presentano come dipendenze plausibili per attività comuni (sviluppo, parsing, compatibilità, tool “di supporto”) e che, una volta installati o richiamati, avviano una catena di esecuzione malevola. Le fonti convergono sul fatto che i pacchetti sono stati rimossi dal registry, ma il rischio resta per chi li abbia già introdotti nelle build locali o CI (continuous Integration)/CD (Contiuous Delivery), dove l’automazione moltiplica l’impatto.

Il salto di qualità rispetto al classico malware da pacchetto è nella propagazione: Sandworm_Mode abusa di credenziali NPM e GitHub sottratte per muoversi lateralmente e affianca questo canale a una GitHub Action manipolata che punta a raccogliere ed esfiltrare segreti di CI. Il modello, descritto come affine alla precedente ondata “Shai-Hulud”, consente non solo di colpire la singola workstation dello sviluppatore, ma di trasformare repository e pipeline in moltiplicatori di compromissione.

Un dettaglio particolarmente insidioso è la possibilità di usare pacchetti “vettore” per innescare workflow via GitHub Actions: basta aggiungere una dipendenza che attiva un percorso di pull request e workflow per arrivare ai segreti del repository e provare a iniettare ulteriori dipendenze o automatismi. È una dinamica che rende più difficile distinguere l’attacco da attività legittime, soprattutto in progetti molto attivi e con automazioni estese.

L’AI come nuova superficie d’attacco: iniezione di un server MCP “rogue” e prompt injection

La parte più attuale della campagna è l’aggancio agli assistenti di coding. Le analisi riportano che il malware installa un server MCP locale malevolo e lo registra nelle configurazioni di più strumenti, puntando a piattaforme come Claude Code, Cursor, Continue e Windsurf. L’idea è avvelenare l’interfaccia “fidata” tra sviluppatore e AI: tramite prompt injection, l’assistente viene indotto a leggere e consegnare informazioni sensibili (chiavi SSH, credenziali cloud, token NPM e segreti vari) verso il canale controllato dall’attaccante.

Non si parla solo di credenziali “classiche”. Sandworm_Mode mira esplicitamente anche alle API key dei provider LLM, oltre a environment variables e file .env, con logiche di validazione per capire cosa valga la pena monetizzare o riutilizzare. In parallelo, viene descritto un harvesting più profondo che include anche dati provenienti da password manager, a conferma della volontà di massimizzare l’accesso persistente agli ambienti di sviluppo.

Offuscamento assistito da Ollama: quando la “difesa” diventa mimetismo del payload

Un altro elemento interessante è l’uso di tooling locale per rendere il codice meno leggibile: il malware invoca un’istanza locale di Ollama per riscrivere porzioni del codice, cambiare nomi di variabili, alterare flussi di controllo, inserire delle esche e codificare stringhe. Non è “AI magica”, ma è un modo pragmatico per aumentare l’attrito per chi analizza e per le difese basate su firme, sfruttando risorse già presenti su molte workstation moderne.

Secondo Socket, la campagna adotta una strategia a due tempi: prima parte immediata e incondizionata dedicata alle operazioni più “profittevoli” (come il furto di chiavi legate al mondo crypto), seguita da attività più rumorose e “lunghe” come persistenza, propagazione e raccolta estesa di segreti. La razionalità è chiara: colpire subito, poi ridurre la probabilità di essere intercettati da sandbox o analisi “mordi e fuggi” tipiche delle prime ore.

Le analisi citano anche una capacità di dead switch configurabile ma inattiva, pensata per arrivare a una cancellazione della home directory nel caso in cui il malware perda accesso o non riesca più a operare con gli account compromessi. Anche se disabilitata nei campioni analizzati, la sola presenza del meccanismo segnala una postura offensiva pronta a passare dalla monetizzazione alla distruzione, se necessario.

Cosa fare ora: bonifica, rotazione credenziali e caccia ai workflow sospetti

La remediation non è “disinstallare e basta”. Chiunque sospetti l’installazione di uno dei pacchetti deve considerare compromessi token e segreti, perché l’attacco è costruito per muoversi tra macchina locale e CI. La linea operativa indicata dalle fonti è rimuovere i pacchetti malevoli eventualmente presenti, verificare modifiche recenti a file JSON e configurazioni, ruotare credenziali GitHub e NPM, ruotare i segreti di pipeline, e cercare workflow inattesi o recentemente introdotti nei repository. In parallelo, ha senso controllare configurazioni e integrazioni degli assistenti AI, perché il vettore MCP/prompt injection punta proprio a persistere nel toolchain.

---

• .env, AI coding assistant, AWS credentials, CI/CD Security, Claude Code, code obfuscation, Continue, credential theft, Cursor, developer security, DevSecOps, environment variables, git hooks, GitHub Actions, GitHub token, LLM API keys, MCP server, Model Context Protocol, npm, npm malware, NPM token, Ollama, persistence, prompt injection, Sandworm_Mode, secrets exfiltration, Shai-Hulud, SSH keys, supply chain attack, typosquatting, Windsurf, worm-like propagation

---

---

https://www.securityinfo.it/2026/02/24/sandworm_mode-il-worm-della-supply-chain-npm/?utm_source=rss&utm_medium=rss&utm_campaign=sandworm_mode-il-worm-della-supply-chain-npm