Chrome e npm sotto attacco tra VPN false e slopsquatting AI

🛡️ Executive Summary

• Socket collega 737 estensioni VPN e proxy Chrome a una campagna che impersona 66 marchi e concentra il traffico su una stessa infrastruttura SOCKS5.
• OpenSourceMalware osserva oltre 700 pacchetti npm malevoli pubblicati in 48 ore con nomi compatibili con slopsquatting e typosquatting automatizzato.
• Il downloader npm colpisce Windows, Linux e macOS, usa Cloudflare Workers e ricostruisce il payload anche attraverso record DNS TXT.

Browser e package manager stanno diventando due versioni dello stesso problema: software apparentemente utile o plausibile che acquisisce fiducia prima di spostare il traffico o eseguire codice ostile. Socket ha ricostruito una campagna composta da 737 estensioni VPN e proxy nel Chrome Web Store, oltre un terzo delle quali impersona marchi reali del settore privacy. Molte dirigono l’intera navigazione dell’utente attraverso una stessa infrastruttura SOCKS5 e alcune utilizzano DNS-over-HTTPS per rendere meno evidente la risoluzione dei domini controllati dagli operatori. In parallelo OpenSourceMalware segue una campagna npm che ha pubblicato centinaia di pacchetti malevoli in poche ore, con nomi apparentemente generati in massa e compatibili con il fenomeno dello slopsquatting AI. L’import del falso SDK è sufficiente ad avviare un downloader multipiattaforma.

Socket trova 737 estensioni VPN collegate

La ricerca di Socket sulle estensioni VPN Chrome identifica 737 estensioni gratuite VPN e proxy pubblicate attraverso almeno 40 account sviluppatore. Di queste, 274 impersonano 66 servizi VPN o privacy esistenti, mentre l’intera campagna ha accumulato almeno 75.486 installazioni sulla base dei contatori a fasce mostrati dal Chrome Web Store. Socket è riuscita a recuperare e analizzare il codice di 525 componenti; 212 erano già stati rimossi prima della raccolta e sono quindi conosciuti soltanto attraverso le relative schede. Tra i pacchetti analizzati a livello di codice, 520 su 522 configurano effettivamente un proxy, quasi sempre verso la stessa infrastruttura. Il targeting è prevalentemente russofono: la maggior parte delle descrizioni è in russo e numerose estensioni promettono accesso a servizi bloccati nel Paese, tra cui YouTube, Instagram e ChatGPT. La dimensione della campagna mostra quanto il marketplace delle estensioni possa diventare un canale di distribuzione parallelo alla più tradizionale supply chain dei browser già esposta da incidenti come quello di Hola.

Il proxy riceve praticamente tutta la navigazione del browser

Il comportamento più significativo è l’uso di chrome.proxy.settings. Secondo Socket, 520 delle 522 estensioni recuperate impostano un server SOCKS5 sulla porta 1082 e utilizzano una bypass list limitata essenzialmente agli indirizzi loopback. In pratica, la normale navigazione del browser viene indirizzata verso l’infrastruttura gestita dallo stesso provider.

Questo pone il soggetto che controlla il proxy in una posizione di adversary-in-the-middle rispetto al traffico del browser, pur senza dimostrare automaticamente che il contenuto HTTPS venga decifrato o che le informazioni transitanti vengano effettivamente registrate. Socket è molto chiara su questo punto: la ricerca ha osservato il comportamento client e non afferma che i server conservino o esfiltrino tutto il traffico. Ciò che viene dimostrato è invece l’instradamento non trasparente, l’impersonificazione dei brand e la concentrazione delle connessioni su una stessa infrastruttura. Il rischio deriva quindi prima di tutto dal livello di fiducia concesso a un’estensione che l’utente ritiene appartenere a un servizio diverso.

Cloudflare e Google DoH aiutano a nascondere il dominio del proxy

Una parte delle estensioni introduce anche un livello dedicato all’evasione dei controlli di rete. 104 componenti richiedono permessi verso endpoint DNS-over-HTTPS di Cloudflare e Google e utilizzano questi resolver per ottenere direttamente l’indirizzo IP del proxy. Chrome riceve quindi un IP già risolto e la macchina della vittima non deve effettuare la normale query DNS in chiaro verso il dominio controllato dagli operatori. Questo comportamento può ridurre la visibilità per i sistemi che dipendono dai log DNS aziendali per individuare domini sospetti, anche se non rende naturalmente invisibile la successiva connessione IP. Socket descrive questa scelta come una forma di blocklist evasion e la collega alla gestione remota dell’infrastruttura, che permette di sostituire destinazioni e domini mantenendo operative le estensioni già installate. L’abuso delle estensioni come punto di controllo del traffico ricorda la crescente attenzione verso marketplace e componenti aggiuntivi già emersa con 77 estensioni Open VSX contraffatte che profilavano sviluppatori e repository.

Il Chrome Web Store contiene copie di marchi VPN reali

L’impersonificazione non riguarda soltanto nomi generici come “Free VPN”. Socket ha trovato copie di Cloudflare 1.1.1.1 e numerosi altri servizi conosciuti, con nomi, loghi e presentazioni progettati per apparire credibili nel Chrome Web Store. Il report documenta 274 estensioni che imitano 66 brand. In alcuni casi il codice o i materiali inclusi mostrano inoltre una consapevolezza esplicita delle regole del marketplace: dieci pacchetti contenevano un file PRIVACY_JUSTIFICATIONS.md, e nove copie erano byte-identiche pur provenendo da nove publisher differenti.

I documenti dichiaravano ai revisori assenza di raccolta dati, assenza di trasmissione verso server esterni, nessun tracking e nessun remote code. Socket riporta inoltre casi di modifiche del codice dopo l’approvazione iniziale e schemi coordinati di recensioni, elementi che rafforzano l’ipotesi di un’attività organizzata anziché di semplici sviluppatori indipendenti che condividono accidentalmente la stessa infrastruttura.

Il modello a pagamento promette server che non esistono

La stessa rete offre anche un servizio premium. Le estensioni promuovono server localizzati in Giappone, Singapore, Canada, Australia e Turchia, ma Socket ha verificato che nessuno dei 200 hostname associati alle località pubblicizzate risultava risolvibile durante l’analisi. Il report interpreta questa componente come subscription fraud, distinta dal problema del proxying.

L’attività non viene descritta come un gruppo APT o come una classica operazione malware; Socket collega invece l’infrastruttura a un vero business VPN registrato in Russia e considera le estensioni un funnel per acquisire clienti. Proprio questa sovrapposizione tra servizio apparentemente commerciale e comportamenti nascosti rende il caso meno lineare di una normale estensione infostealer: alcune funzionalità sono quelle attese da una VPN, ma l’identità presentata, il routing reale e le affermazioni fornite ai revisori non corrispondono.

Le rimozioni non hanno fermato la campagna

Google ha già rimosso una parte consistente delle estensioni, ma al momento della raccolta Socket ne trovava ancora 516 attive, con 58.318 installazioni complessive visualizzate nello store. In totale, 221 delle 737 risultavano già rimosse. Il dato più interessante riguarda però gli account publisher: secondo Socket, 28 dei 29 account core che avevano subito almeno una rimozione hanno continuato a pubblicare, mentre 29 dei 30 account interessati da un intervento conservavano comunque altre estensioni ancora attive. Il costo di ingresso contribuisce alla resilienza: un account Chrome Web Store richiede pochi dollari e può produrre molte estensioni prima che l’intero profilo venga eventualmente neutralizzato. La campagna evidenzia quindi un limite dei takedown basati sul singolo pacchetto, lo stesso problema che compare nella supply chain open source quando rimuovere una versione non elimina automaticamente publisher, credenziali o infrastruttura utilizzati per creare quella successiva.

Oltre 700 pacchetti npm compaiono in appena 48 ore

Il secondo caso sposta il problema dal browser al codice degli sviluppatori. La ricerca di OpenSourceMalware sulla campagna WEL1DROPPER documenta la pubblicazione di oltre 700 pacchetti npm malevoli in circa 48 ore; il conteggio aggiornato mantenuto dal team è successivamente salito a 788 package. I nomi sembrano prodotti attraverso combinazioni casuali di termini plausibili, molti dei quali ricordano SDK mobile, checkout, analytics, autenticazione o servizi applicativi. OpenSourceMalware parla di AI slop squatting o typosquatting generato casualmente, ma la qualificazione “AI” deve essere letta con precisione: il report osserva una produzione massiva di nomi compatibili con output automatizzato, non dimostra attraverso telemetria diretta quale modello sia stato utilizzato dall’attore. Il fenomeno resta comunque importante perché sfrutta un nuovo rischio degli ecosistemi generativi: nomi di pacchetti plausibili ma inesistenti possono essere suggeriti, copiati e successivamente registrati dagli aggressori.

L’import del pacchetto basta ad avviare l’infezione

La campagna evita una delle difese più comuni contro il malware npm. I pacchetti analizzati non hanno bisogno di script preinstall o postinstall. Nel caso esaminato in dettaglio, [email protected], il README invita semplicemente lo sviluppatore a importare il modulo tramite require(). All’interno di index.js, subito dopo l’export dell’API apparentemente legittima, viene caricato _helpers.js; il file esegue immediatamente la propria funzione run() e avvia la catena malevola. In questo modo controlli che vietano gli install script possono essere superati senza sfruttare alcuna vulnerabilità: il codice ostile parte quando l’applicazione utilizza la dipendenza, durante sviluppo, test o avvio in produzione. È una distinzione cruciale rispetto alle campagne basate esclusivamente sull’installazione ed estende il problema già osservato nelle compromissioni npm come AsyncAPI, dove pipeline GitHub legittime avevano pubblicato pacchetti Miasma infetti.

Windows, Linux e macOS ricevono payload differenti

Una volta eseguito, il downloader determina sistema operativo e architettura e sceglie il payload appropriato. Sono supportati Linux x64, Linux ARM64, macOS sia Intel sia Apple Silicon e Windows x86/x64. Il primo tentativo di download utilizza tre host Cloudflare Workers controllati dagli aggressori. Il codice accetta una risposta se il server restituisce HTTP 200 e almeno 1.001 byte, quindi salva il contenuto in una posizione temporanea ed esegue il file in background. Su sistemi Unix vengono creati nomi come /var/tmp/.cache_<id>, mentre su Windows il payload assume una forma simile a %TEMP%\dotnet_diag_<id>.exe. Il downloader non verifica firma, hash atteso o pinning del certificato applicativo: qualunque binario sufficientemente grande ricevuto dal server viene considerato valido ed eseguito. La campagna dimostra così quanto la supply chain npm possa diventare un ponte diretto dal JavaScript al malware nativo multipiattaforma.

Se Cloudflare viene bloccato il malware arriva attraverso DNS TXT

La caratteristica tecnica più originale è il secondo canale di delivery. Se tutti e tre i server HTTPS falliscono, il package interroga domini sotto wel1.ru utilizzando record DNS TXT. Una prima richiesta a c.<dominio> restituisce il numero di frammenti da recuperare; il downloader interroga quindi record numerati come 0.<dominio>, 1.<dominio> e così via, concatena le stringhe e le decodifica da Base64 ricostruendo il payload binario. Il meccanismo supporta fino a 2.000 chunk. OpenSourceMalware sottolinea che non si tratta di semplice service discovery: il DNS diventa un vero canale alternativo per consegnare l’eseguibile. Bloccare i domini Cloudflare Workers non è quindi sufficiente se il resolver aziendale continua a permettere le query TXT verso l’infrastruttura fallback. La resilienza del delivery richiama il più ampio spostamento verso infrastrutture distribuite già osservato nella crescita degli attacchi supply chain open source e dei meccanismi anti-takedown.

macOS aggiunge persistenza e un ulteriore beacon

L’analisi del secondo stadio macOS mostra una catena più lunga. Il binario universale supporta Intel e Apple Silicon, verifica la presenza di debugger, Frida, Wireshark e VMware, controlla la quantità di memoria della macchina e può scaricare un ulteriore componente beacon_mac.bin. La persistenza viene creata sotto ~/.local/share/runtime, mentre un LaunchAgent chiamato com.apple.windowserver.helper.plist avvia il payload al login e lo riavvia dopo le terminazioni inattese. Il naming cerca deliberatamente di imitare componenti Apple, ma i percorsi utilizzati non corrispondono a servizi legittimi del sistema operativo. Il malware conserva inoltre lo stesso principio di ridondanza visto nel primo stadio: Cloudflare Workers come percorso primario e DNS TXT come fallback. Questo comportamento rende il falso package npm non un semplice infostealer JavaScript, ma un loader capace di introdurre una catena nativa persistente nell’endpoint dello sviluppatore.

L’attribuzione russa resta indicativa e non definitiva

OpenSourceMalware collega la campagna a un possibile contesto russo attraverso il dominio wel1.ru, riferimenti a servizi finanziari russi e somiglianze con una precedente ondata denominata Moika, che aveva pubblicato oltre 250 package npm nei mesi precedenti. Tra i punti comuni vengono citati la stringa oob nell’infrastruttura, l’attenzione verso pagamenti e servizi russi, il finto codice di telemetria utilizzato come copertura e kill switch costruiti con logiche simili. Sono elementi di clustering utili, ma non costituiscono prova sufficiente dell’identità o della nazionalità dell’operatore. Il report stesso usa formule probabilistiche. Il dominio .ru e la presenza di nomi di banche russe all’interno dei binari potrebbero rappresentare infrastruttura, targeting, decoy o altri artefatti operativi. La distinzione è importante soprattutto quando una campagna viene descritta attraverso termini sintetici come “Russian AI slopsquatting”: la componente tecnica è documentata molto meglio dell’attribuzione umana.

Slopsquatting e impersonificazione sfruttano lo stesso difetto cognitivo

Le due campagne non risultano collegate tra loro, ma operano sullo stesso meccanismo di fiducia. Le estensioni Chrome sfruttano nomi, loghi e reputazione di VPN esistenti per convincere l’utente che il software installato appartenga a un marchio conosciuto. I package npm utilizzano invece nomi tecnicamente plausibili per entrare in un flusso nel quale uno sviluppatore si aspetta che il componente esista e faccia ciò che il nome suggerisce. Nel primo caso è brand impersonation; nel secondo è slopsquatting o package-name confusion. Entrambi funzionano prima ancora che inizi la parte malevola perché la vittima delega fiducia al marketplace o al registry. La crescita di campagne come ChainDrop e le estensioni Open VSX contraffatte conferma che store e package manager non possono più essere considerati un filtro sufficiente di autenticità.

L’AI aumenta il numero di nomi che un attaccante può occupare

Lo slopsquatting aggiunge una conseguenza specifica dell’uso crescente degli assistenti generativi nello sviluppo. Un modello può suggerire per errore una libreria dal nome credibile che non esiste realmente; se il namespace è libero, un attaccante può registrarlo e aspettare che qualcuno segua quel suggerimento. Le campagne massive rendono possibile un approccio ancora più aggressivo: occupare centinaia di nomi semanticamente plausibili prima ancora di sapere quali verranno suggeriti o digitati dagli sviluppatori. OpenSourceMalware considera l’insieme dei package osservati compatibile con questa produzione automatizzata. Non è necessario che ogni infezione derivi direttamente da un’allucinazione di un LLM: è sufficiente che la generazione AI aumenti enormemente lo spazio dei nomi credibili e che gli aggressori riescano a popolarlo a basso costo. È una delle conseguenze operative dell’aumento del 1.444% dei pacchetti malevoli open source già evidenziato nell’analisi sulle nuove difese di Google per repository e dipendenze.

Store e registry devono essere trattati come origini non sufficientemente fidate

Per gli utenti Chrome, Socket raccomanda di verificare l’identità reale del publisher, confrontare l’estensione con il sito ufficiale del servizio VPN e considerare con attenzione componenti che richiedono controllo completo del proxy. Per gli ambienti enterprise, allowlist delle estensioni e gestione centralizzata del browser riducono notevolmente il rischio di installazioni arbitrarie. Nel caso npm, le misure devono comprendere lockfile, verifica dei maintainer, analisi delle nuove dipendenze, quarantena temporale delle release, controllo del codice eseguito all’import e monitoraggio DNS, senza limitarsi al blocco degli install script. Il modello della quarantena è già diventato concreto con le difese temporali introdotte da GitHub e PyPI contro le nuove release. Le due ricerche mostrano infine perché l’etichetta “presente nello store” o “pubblicato su npm” debba essere interpretata soltanto come disponibilità attraverso un canale noto, non come certificazione della sicurezza del codice.

La supply chain ora inizia dal nome del software

La trasformazione più significativa riguarda quindi il momento in cui comincia l’attacco. Tradizionalmente la supply chain veniva associata alla compromissione di un maintainer, di una pipeline o di una release autentica. Queste campagne mostrano un percorso precedente: creare direttamente il prodotto falso che l’utente o lo sviluppatore pensa di stare cercando. Socket documenta centinaia di estensioni che ereditano visivamente l’identità di servizi VPN reali; OpenSourceMalware documenta centinaia di package che occupano nomi apparentemente plausibili e trasformano un semplice require() in esecuzione nativa su Windows, Linux e macOS. Con l’AI che moltiplica nomi, dipendenze suggerite e codice generato, il problema non è più soltanto verificare se una versione sia stata manipolata: diventa necessario verificare se il software che si sta installando sia mai stato quello corretto fin dall’inizio.