Chi assume, chi cerca personale e chi lavora con sviluppatori o consulenti IT dovrebbe prestare attenzione a questa notizia: una campagna di attacco attribuita al gruppo iraniano Nimbus Manticore sta usando falsi processi di selezione per installare malware su computer Windows, Linux e macOS. Il punto importante per le aziende non è solo la tecnica usata, ma il fatto che l’attacco colpisce persone reali durante attività di lavoro credibili, come un colloquio o un test tecnico.
In pratica, il confine tra “file di lavoro” e “file malevolo” si sta assottigliando. Se in azienda collaborate con sviluppatori, freelance, candidati o fornitori che eseguono codice ricevuto via email, LinkedIn o piattaforme di recruiting, questo tipo di minaccia vi riguarda direttamente.
Cosa è successo
Il 1° settembre 2026 The Hacker News ha riportato un’analisi di Kaspersky su due famiglie di malware finora non documentate pubblicamente, chiamate NodeRabbit e PollCat. Secondo i ricercatori, sono collegate al gruppo Nimbus Manticore, un attore già noto per campagne di cyber spionaggio e per l’uso di esche legate al recruiting.
L’elemento nuovo è l’evoluzione tecnica: invece di limitarsi a strumenti tradizionali per Windows, il gruppo sta adottando RAT multipiattaforma scritte in Node.js e JavaScript, con la capacità di infettare anche Linux e Apple macOS. Per molte imprese questa è una differenza sostanziale, perché oggi gli ambienti IT sono spesso misti: notebook Windows in ufficio, Mac per ruoli creativi o tecnici, server Linux interni o in cloud.
Kaspersky indica che il primo campione di NodeRabbit è stato scoperto su un sistema in Afghanistan, con ulteriori rilevazioni su macchine in Egitto ed Etiopia. Anche se le vittime osservate non sono in Italia, la tecnica usata è replicabile ovunque e non richiede infrastrutture particolarmente visibili per raggiungere nuovi bersagli.
Come funziona l’inganno del “test tecnico”
La campagna si basa su un meccanismo semplice ma molto efficace: l’attaccante si presenta come recruiter o talent acquisition specialist di una grande azienda tecnologica, contatta un professionista su LinkedIn o su altre piattaforme di ricerca lavoro e propone una posizione tecnica.
A quel punto invia un archivio ZIP che sembra contenere un esercizio di valutazione. Nel caso analizzato, il file si chiamava “Front-Technical-Challenge.zip” ed era ospitato su AWS. All’interno era presente il codice sorgente di un presunto strumento di project management chiamato Taskflow, accompagnato da istruzioni che chiedevano al candidato di trovare e correggere bug del frontend entro tre ore, senza usare strumenti di intelligenza artificiale.
Il dettaglio decisivo è psicologico prima ancora che tecnico: il candidato viene esplicitamente invitato a non modificare il file server.js, perché dichiarato “privo di bug” e già funzionante. Proprio lì, invece, era nascosto il codice malevolo.
Questo schema è particolarmente insidioso perché sfrutta tre elementi molto comuni nelle aziende:
- la fiducia verso un contatto professionale credibile;
- l’urgenza tipica delle selezioni e delle prove pratiche;
- l’abitudine, soprattutto nei ruoli IT, a eseguire codice ricevuto per testarlo o correggerlo.
Perché questa campagna è più pericolosa del solito
Non si tratta del classico allegato sospetto scritto male o della finta fattura con macro. Qui l’attacco imita un flusso di lavoro perfettamente plausibile. Un tecnico, un consulente o un candidato può pensare di stare semplicemente aprendo un progetto da analizzare, quando in realtà avvia una catena di infezione.
Nel caso di NodeRabbit, il file server.js importava un pacchetto npm trojanizzato chiamato colorized_terminal, versione 2.1.0, incluso direttamente nella cartella node_modules dell’archivio. Questo è un altro aspetto importante: il pacchetto non veniva necessariamente pubblicato sul registro npm pubblico, ma veniva consegnato già incorporato nel materiale del test. In altre parole, i controlli standard sulla supply chain software potrebbero non bastare se il codice malevolo arriva “impacchettato” dentro un progetto condiviso privatamente.
Quando importato, il pacchetto avviava in background un impianto malevolo. Kaspersky riporta inoltre altre varianti di NodeRabbit che usano un diverso pacchetto trojanizzato, pretty-log versione 2.1.0.
Cosa può fare il malware una volta installato
NodeRabbit è classificabile come RAT, cioè un trojan di accesso remoto. In termini pratici, significa che dopo l’infezione l’attaccante può impartire comandi da remoto al sistema compromesso.
Secondo i dettagli pubblicati, il malware comunica con server di comando e controllo ospitati su Azure e può:
- raccogliere informazioni sul computer e sull’host;
- elencare i processi in esecuzione;
- eseguire comandi di shell arbitrari;
- esplorare directory e file;
- leggere file a blocchi ed esportarne i contenuti;
- scrivere dati su file esistenti;
- cancellare file o directory;
- creare nuove directory;
- raccogliere informazioni di rete come adattatori, MAC address, IP e DNS;
- modificare la frequenza con cui il malware “si fa vivo” verso l’infrastruttura degli attaccanti.
Una funzionalità particolarmente significativa è la possibilità di scrivere ed eseguire temporaneamente script Node.js aggiuntivi, per poi cancellarli. Dal punto di vista aziendale questo vuol dire che l’attaccante può estendere rapidamente le capacità del malware e, allo stesso tempo, rendere più difficile la ricostruzione dell’accaduto.
Un attacco pensato per ambienti misti
Uno dei dati più rilevanti è la persistenza multipiattaforma. Il malware si adatta al sistema operativo compromesso:
- su Windows usa una chiave Run del registro;
- su Linux crea una voce cron;
- su macOS usa un launch agent.
Kaspersky segnala anche che alcune varianti cercano di sembrare componenti legittimi, come un aggiornamento di Microsoft Edge o Intel Driver Support Assistant. Una terza variante considera persino il Windows Subsystem for Linux (WSL), creando un’attività pianificata giornaliera alle 10:00 che richiama script tramite wscript.exe e wsl.exe.
Per un’azienda questo è un campanello d’allarme chiaro: non basta più proteggere solo i PC Windows “classici”. Se in rete convivono workstation di sviluppo, notebook macOS e istanze Linux, l’approccio alla sicurezza deve essere uniforme.
Un’evoluzione coerente del gruppo Nimbus Manticore
Le fonti ricordano che Nimbus Manticore aveva storicamente usato malware in C, C++ e Go, spesso distribuiti tramite tecniche come il DLL search-order hijacking. Le nuove famiglie indicano una transizione verso strumenti più flessibili e portabili.
Nello stesso periodo, al gruppo sono stati attribuiti anche altri componenti, tra cui una backdoor Windows chiamata NightLedger, due tunnel WebSocket denominati BridgeHead e ArcBridge, uno strumento di reverse SSH tunneling e una backdoor con sovrapposizioni con TWOSTROKE.
Per i responsabili aziendali il dettaglio tecnico conta fino a un certo punto. Il messaggio operativo è più semplice: il gruppo sta ampliando il proprio arsenale e dimostra una capacità crescente di muoversi in ambienti diversi, mascherando l’attacco dentro processi professionali credibili.
Cosa significa per la tua azienda
Per una PMI italiana, questa notizia non riguarda solo il reparto IT o chi sviluppa software. Riguarda anche HR, acquisti, direzione e responsabili di funzione, perché l’ingresso dell’attaccante può avvenire tramite una persona che svolge un’attività legittima.
Ecco le misure più utili, in concreto.
1. Definite una regola chiara sui test tecnici e sul codice ricevuto dall’esterno.
Nessun file ricevuto via LinkedIn, email o chat dovrebbe essere eseguito su PC di produzione. Se gestite selezioni o collaborazioni tecniche, i test vanno aperti in ambienti isolati, meglio se temporanei.
2. Separate le postazioni operative dagli ambienti di prova.
Un notebook usato per amministrazione, accesso al gestionale, email e home banking aziendale non dovrebbe mai essere usato anche per eseguire repository, script o pacchetti ricevuti da terzi.
3. Estendete i controlli di sicurezza a macOS e Linux, non solo a Windows.
Molte aziende proteggono bene i PC d’ufficio ma lasciano più “libere” le macchine dei tecnici o i sistemi Linux. È un errore che campagne come questa sfruttano apertamente. Una gestione centralizzata delle postazioni e degli aggiornamenti, come nei servizi di desktop IT management, aiuta a ridurre molto il rischio operativo.
4. Formate HR e manager sui nuovi schemi di social engineering.
Un messaggio da un recruiter o un candidato non è automaticamente innocuo. Le persone che organizzano colloqui, prove pratiche e scambi di documentazione devono sapere che oggi anche un “coding challenge” può diventare un vettore di attacco.
5. Monitorate i segnali di persistenza e i comportamenti anomali.
Chiavi Run non previste, cron job sospetti, launch agent sconosciuti, processi Node.js eseguiti fuori contesto, traffico verso endpoint cloud apparentemente legittimi: sono tutti indicatori che vanno verificati rapidamente.
6. Preparatevi al peggio con backup e risposta all’incidente.
Un RAT non serve solo a spiare: può diventare il punto di partenza per furto dati, movimento laterale e ulteriori compromissioni. Backup verificati e separati sono una misura essenziale, non accessoria. Se non avete ancora una strategia robusta, conviene valutare soluzioni di remote backup.
7. Rivedete le misure di protezione dei dati personali.
Se un attacco raggiunge caselle email, file condivisi o sistemi HR, il rischio non è solo tecnico ma anche normativo. Una revisione periodica delle procedure legate al GDPR aiuta a capire prima dove sono i dati più esposti e come gestire correttamente un eventuale incidente.
Il punto chiave: l’attacco si nasconde dentro il lavoro normale
La lezione più importante di questo caso è che gli attaccanti non cercano più soltanto l’errore tecnico. Cercano il contesto giusto: un colloquio, una selezione, un esercizio, una collaborazione freelance, una prova su codice reale.
Per questo la difesa efficace non consiste solo nell’installare un antivirus. Serve una combinazione di regole operative, segmentazione delle postazioni, controllo delle esecuzioni, formazione mirata e capacità di reazione. Nelle PMI, dove spesso gli stessi strumenti vengono usati per tutto, dal commerciale all’IT, questa disciplina fa la differenza.
Domande frequenti
Questa minaccia riguarda solo sviluppatori e reparti IT?
No. Colpisce soprattutto chi esegue codice o apre progetti tecnici, ma può coinvolgere anche HR, manager e chi coordina selezioni o fornitori esterni.
Se usiamo solo Windows siamo al sicuro?
No. La campagna descritta punta anche a Linux e macOS, ma soprattutto dimostra che gli attaccanti usano tecniche credibili che possono compromettere qualunque ambiente mal gestito.
Cosa dovremmo fare subito in azienda?
Stabilire che test tecnici e codice ricevuto dall’esterno vengano aperti solo in ambienti isolati, verificare i sistemi di protezione su tutte le postazioni e controllare backup, logging e procedure di risposta agli incidenti.