La campagna graphalgo descrive un salto di qualità nel modo in cui gli attori sponsorizzati da uno Stato trasformano il reclutamento in un vettore di intrusione. In questo caso, l’operazione attribuita a Lazarus Group prende di mira sviluppatori JavaScript e Python che lavorano su prodotti e infrastrutture legate alle criptovalute, sfruttando piattaforme come LinkedIn, Reddit e Facebook per costruire l’illusione di un’opportunità professionale nel settore blockchain. Il cuore dell’attacco non è un allegato in email, ma un “compito di selezione” su GitHub: repository che sembrano innocui e che, una volta clonati e avviati, innescano l’installazione di dipendenze malevole da npm e PyPI, aprendo la strada a un RAT modulare con funzioni da downloader e un chiaro focus su MetaMask e asset crypto. Il dato che pesa, in termini operativi, è la durata: l’attività viene descritta come attiva dal maggio 2025, con un’evoluzione continua che non cambia la logica di fondo. Gli attaccanti separano con cura frontend e backend: possono aggiornare nome dell’azienda fittizia, dettagli della “posizione” e comunicazione con la vittima senza toccare l’infrastruttura malware. Questo rende più difficile inseguire la campagna con takedown puntuali e spiega perché alcune componenti, soprattutto nel ramo “big”, restino a lungo non pienamente attribuite a un singolo frontend pubblico.
La finta azienda Veltrix-capital e la catena sociale dell’inganno

L’operazione si regge su una costruzione narrativa: una finta azienda, Veltrix-capital, usata come facciata per annuncio, contatto e onboarding. I profili usati come “reclutatori” servono a ridurre l’attrito psicologico e a normalizzare l’azione più rischiosa: eseguire codice di terzi su una macchina di lavoro. La promessa è sempre la stessa, con varianti di contesto: ruoli blockchain, compensation competitiva, urgenza da selezione, e un test pratico che “dimostra” le competenze del candidato.

Qui la tecnica non è nuova, ma il modo in cui viene industrializzata lo è. L’interazione avviene spesso su canali pubblici e semi-pubblici, dove la vittima percepisce il contatto come plausibile. Reddit e Facebook diventano amplificatori perché gli annunci possono essere ripostati e discussi da utenti ignari, mentre LinkedIn consente un’azione più mirata, uno-a-uno, con messaggistica e profili che simulano reali esperienze HR.
Dal repository GitHub al malware: la supply chain travestita da “test tecnico”
Il passaggio decisivo avviene quando il candidato riceve un repository “di prova”. Il repository include elementi tipici di progetti reali, come package.json per JavaScript o requirements.txt per Python, e richiama librerie “coerenti” con un test su grafi, analytics o toolchain blockchain. L’installazione delle dipendenze fa il resto: pacchetti su npm e PyPI che sembrano utili, ma che contengono codice malevolo, spesso attivato in fase post-installazione.

È qui che la campagna usa due leve psicologiche forti. La prima è il contesto professionale: se stai facendo un colloquio, ti aspetti che il test sia “standard”. La seconda è la fiducia nell’ecosistema open source: il developer vede un nome di pacchetto e presume che il rischio sia limitato, soprattutto se il progetto compila e lancia output coerenti.

In questo schema, la “trappola” non richiede exploit: richiede abitudini. Un dev che fa npm install o pip install -r requirements.txt sta facendo esattamente quello che farebbe in un progetto lecito. Ed è questo che rende la campagna particolarmente pericolosa per l’industria crypto, dove molti sviluppatori lavorano su macchine personali, ambienti poco segmentati e con accesso a wallet, chiavi, repository privati e strumenti di deploy.
Due rami operativi: gruppo graph e gruppo big
La campagna viene descritta come articolata in due rami principali, graph e big, che condividono la logica ma diversificano pacchetti, tempistiche e copertura. Il ramo graph appare dal maggio 2025 e include pacchetti che richiamano direttamente l’etichetta graphalgo e varianti correlate. Nel tempo, vengono osservate versioni malevole in intervalli specifici, sia su npm sia su PyPI, con naming scelti per apparire come prerelease, build di test o release candidate. Questa scelta non è casuale: il developer è più disposto a installare una prerelease se pensa che il test di lavoro richieda “l’ultima funzionalità”. Il ramo big emerge in modo più evidente a dicembre 2025 con pacchetti come bigmathutils, che seguono una strategia particolarmente efficace: prima release innocue, poi inserimento della versione malevola quando la fiducia è consolidata. L’esempio più significativo è bigmathutils, che arriva a 10.000 download prima dell’introduzione della release compromessa 1.1.0, una dinamica che permette di colpire sia vittime “da colloquio” sia utenti reali che adottano il pacchetto in contesti legittimi.
La strategia della fiducia: pacchetti puliti prima, pacchetti infetti dopo
Uno dei tratti più importanti della campagna è la gestione del tempo. Pubblicare pacchetti legittimi all’inizio ha almeno tre vantaggi operativi: costruisce reputazione, genera metriche di download che rassicurano, e riduce l’attenzione dei controlli automatici che spesso si concentrano su pacchetti nuovi o chiaramente anomali. Quando la versione malevola arriva, spesso lo fa con un salto “compatibile” con la logica semantica delle release: patch o minor release che non insospettiscono. Nel caso citato, la transizione verso 1.1.0 diventa la finestra in cui l’attaccante capitalizza la fiducia accumulata. Questo modello è tipico delle operazioni supply chain moderne: il malware non entra come corpo estraneo, entra come aggiornamento.
RAT modulare: downloader, controllo remoto e focus su MetaMask
Il componente centrale è un RAT che opera come downloader iniziale. Non si limita a restare sul sistema: scarica payload secondari, espande capacità e mantiene flessibilità. Le funzioni descritte includono upload e download di file, esecuzione arbitraria di comandi, listing processi e raccolta di informazioni di sistema. È un profilo coerente con una piattaforma di accesso remoto pensata per adattarsi al target e all’ambiente della vittima.

Il segnale più chiaro sull’obiettivo finale è la presenza di controlli legati a MetaMask. Il malware verifica l’installazione dell’estensione e si prepara a rubare fondi o credenziali collegate ai wallet. In ambienti crypto, questa scelta è logica: un developer spesso gestisce testnet, mainnet, seed phrase, file di configurazione e credenziali cloud con privilegi elevati. L’accesso alla macchina del developer può diventare accesso al prodotto, al codice e agli asset. Il RAT è osservato in varianti multi-lingua, con componenti in Python, JavaScript e una componente VBS che compare come espansione più recente, indicando una campagna che non si limita a una singola piattaforma o stack, ma cerca versatilità e compatibilità, specialmente in ambienti Windows.
Infrastruttura C2 tokenizzata: codepool.cloud e aurevian.cloud
Sul piano di rete, l’operazione usa server di comando e controllo come codepool.cloud e aurevian.cloud, con una caratteristica rilevante: canali protetti da token. La tokenizzazione non è un dettaglio estetico. Serve a ridurre la possibilità che terzi “curiosi” enumerino o analizzino le rotte C2 in modo banale, e complica anche alcune tecniche di sinkholing o osservazione passiva. Questa architettura conferma un approccio maturo: non è un malware “che parla in chiaro”, ma un impianto che presume investigazione e prova ad alzare i costi di analisi.
Indicatori di compromissione: pacchetti, versioni e hash
La campagna include indicatori chiave che, in un contesto SOC, diventano fondamentali per hunting retrospettivo e prevenzione. Tra questi, i domini C2 e una lista ampia di pacchetti e versioni su npm e PyPI, oltre a hash specifici per i payload RAT. Nel materiale fornito emergono tre SHA1 associati alle componenti: 052c278f727292d779e9cf2465c9065a55b49546 per la variante Python, e5af589fcd2bfb7093dd10274161a3c0de42057f per la componente JavaScript, e dbb4031e9bb8f8821a5758a6c308932b88599f18 per il payload VBS. Sul piano supply chain, il set di pacchetti citati include intervalli precisi, tra cui graphalgo e varianti, l’impersonificazione tramite graphnetworkx e l’insieme “big” con bigmathutils e altri nomi adiacenti. La parte più critica, per un team di difesa, è non trattare questi indicatori come “lista da incollare”. Il valore sta nel modello: pacchetti con naming simile a librerie popolari, crescita “pulita” dei download, e inserimento del payload in release successive.
Attribuzione e contesto: perché Lazarus torna sempre sul crypto
L’attribuzione a Lazarus Group colloca l’operazione nel solco delle campagne nordcoreane orientate a monetizzazione e raccolta fondi. La combinazione tra social engineering, supply chain open source e focus esplicito su wallet rende la campagna coerente con un obiettivo finanziario, non solo di spionaggio industriale. L’uso di finte interviste, test tecnici e infrastrutture modulari ricalca tattiche già osservate in precedenti operazioni legate al mondo crypto, dove il rapporto tra velocità di sviluppo e controllo di sicurezza resta spesso sbilanciato. Qui l’impatto non si misura solo in fondi rubati. Si misura anche in compromissione di repository, esposizione di IP, accesso a chiavi di firma, pipeline CI/CD e, in casi estremi, contaminazione di prodotti downstream.
Iscriviti alla Newsletter
Non perdere le analisi settimanali: Entra nella Matrice Digitale.
Matrice Digitale partecipa al Programma Affiliazione Amazon EU. In qualità di Affiliato Amazon, ricevo un guadagno dagli acquisti idonei. Questo non influenza i prezzi per te.









