Quando il malware si presenta con un volto familiare

Le versioni colpite sono rimaste disponibili per circa tre ore. Il Google Threat Intelligence Group ha registrato attività tra le 00:21 e le 03:20 UTC del 31 marzo, mentre altre ricostruzioni descrivono una finestra simile, compresa tra due e tre ore. Axios è una dipendenza ad alto impatto: le stime pubbliche parlano di circa 80 milioni fino a oltre 100 milioni di download settimanali su npm, con variazioni tra una fonte e l’altra.

Come è stato sfruttato l’account del maintainer

Le informazioni pubbliche più solide indicano una presa di controllo dell’account npm, non una vulnerabilità intrinseca nella libreria Axios. Una ricostruzione riferisce che gli aggressori avrebbero usato un token di accesso npm di lunga durata appartenente al maintainer principale; altre descrivono più genericamente un account o credenziali di pubblicazione compromessi.

La distinzione è importante. L’attacco ha oltrepassato il confine di fiducia tra l’autorità di pubblicazione del maintainer e la pipeline di rilascio di npm. Poiché i pacchetti erano stati pubblicati tramite un account legittimo, sviluppatori e sistemi automatizzati avevano meno motivi per considerarli sospetti.

Che cosa faceva la dipendenza malevola

plain-crypto-js@4.2.1 era presentata come una normale dipendenza, ma serviva a eseguire uno script postinstall. Lo script contattava un server di comando e controllo e recuperava un payload di seconda fase adattato al sistema operativo dell’host.

Gli sviluppatori, quindi, non dovevano scaricare un eseguibile palesemente sospetto. L’infezione poteva partire da un aggiornamento ordinario delle dipendenze, da una build CI o da un comando

npm install

È stato BlueNoroff?

L’attribuzione non è univoca nelle informazioni disponibili. Alcune analisi collegano l’operazione ad attori associati alla Corea del Nord, tra cui BlueNoroff o cluster affini; Microsoft ha invece attribuito la compromissione a Sapphire Sleet.

Queste valutazioni non dovrebbero essere presentate come un’unica conclusione confermata. Somiglianze nel codice, nelle infrastrutture o nelle modalità operative possono offrire una pista investigativa, ma non dimostrano da sole quale gruppo abbia condotto l’attacco. La conclusione più prudente è che la compromissione di Axios abbia coinvolto un account di maintainer dirottato, versioni avvelenate e un RAT multipiattaforma; l’identità dell’attore resta oggetto di valutazioni discordanti.

Come SilverFox ha usato le false applicazioni Claude

SilverFox ha seguito una strada diversa per entrare nelle organizzazioni: ha distribuito applicazioni Claude contraffatte per Windows, macOS e Linux. La campagna ha preso di mira organizzazioni dei settori industriale, consulenziale, commerciale e dei trasporti in India, Indonesia, Sudafrica e Russia.

Le applicazioni erano imitazioni del marchio Claude di Anthropic, non installer ufficiali. La loro efficacia dipendeva da uno scenario di lavoro credibile: un dipendente cerca uno strumento AI per aumentare la produttività, scarica quella che sembra un’applicazione familiare e installa invece un malware. Secondo Kaspersky, la campagna rientrava nelle attività di SilverFox osservate in più ondate dal dicembre 2025.

Dal phishing fiscale alle esche basate sull’AI

La campagna si inseriva in una serie di precedenti attività di phishing a tema fiscale. Tra gennaio e febbraio 2026, i ricercatori hanno registrato oltre 1.600 email malevole che si presentavano come comunicazioni ufficiali relative a controlli fiscali o sostenevano di contenere elenchi di violazioni tributarie.

È cambiato il veicolo, ma non il segnale di fiducia sfruttato. Una comunicazione fiscale crea urgenza e autorità; un assistente AI con un marchio noto comunica utilità e convenienza. Entrambi possono spingere l’utente ad aprire un allegato, scaricare un archivio o installare un programma prima di verificarne la provenienza.

SilverFox ha usato un modello di distribuzione a più fasi, con infrastrutture separate per i diversi momenti dell’intrusione. Questa segmentazione può rendere più difficile per i difensori bloccare o ricostruire l’intera catena d’attacco partendo da un singolo dominio o indicatore.

La lezione comune: la fiducia è parte della superficie d’attacco

Gli episodi Axios e SilverFox hanno preso di mira relazioni di fiducia differenti:

• Fiducia nel maintainer: le versioni di Axios sembravano provenire da un publisher npm autorizzato.
• Fiducia nelle dipendenze: il gestore dei pacchetti trattava la dipendenza malevola come parte di una normale procedura di installazione.
• Fiducia nel marchio: i falsi installer di Claude prendevano in prestito l’identità di un prodotto AI riconoscibile.
• Fiducia nei flussi di lavoro: sviluppatori e dipendenti seguivano azioni abituali, come aggiornare le dipendenze o installare software di produttività.

Il caso Axios dimostra perché una finestra di esposizione breve possa comunque essere pericolosa. Installazioni, build e processi CI/CD possono partire automaticamente: il numero di sistemi raggiunti non è quindi limitato alle persone che esaminano manualmente una release. Il caso SilverFox mostra lo stesso principio sul lato endpoint: categorie di software adottate rapidamente, come gli strumenti AI, offrono agli aggressori nuove esche credibili.

Che cosa dovrebbero fare ora le organizzazioni

Per l’incidente Axios, è necessario controllare lockfile, manifest dei pacchetti, log di build, cache e inventari delle dipendenze alla ricerca di axios@1.14.1, axios@0.30.4 e plain-crypto-js@4.2.1. Ogni macchina che ha installato una versione colpita durante la finestra di esposizione dovrebbe essere analizzata per individuare payload scaricati, meccanismi di persistenza non autorizzati e credenziali esposte. Gli avvisi raccomandano espressamente di considerare potenzialmente compromesse le installazioni interessate.

Per il software AI, le organizzazioni dovrebbero imporre il download delle applicazioni desktop solo da canali approvati, verificare editore e dominio di provenienza e bloccare o mettere in quarantena gli installer non autorizzati. Per la pubblicazione su npm, autenticazione multifattore resistente al phishing, credenziali a durata limitata o con privilegi strettamente definiti, attestazioni di provenienza delle release, lockfile e revisione delle modifiche alle dipendenze possono ridurre il rischio che un singolo account compromesso diventi un incidente di supply chain.

Il controllo più importante è verificare ogni passaggio in cui la fiducia cambia di mano. Un nome di pacchetto familiare non dimostra che ogni sua versione sia sicura; allo stesso modo, il nome di un prodotto noto non dimostra che ogni installer sia autentico.