Allarme Microsoft: i finti progetti Next.js che rubano i segreti degli sviluppatori direttamente in memoria

Microsoft ha rivelato una campagna coordinata che prende di mira gli sviluppatori attraverso repository maliziosi camuffati da progetti Next.js legittimi e materiali per assessment tecnici. L’obiettivo non è l’utente finale, ma il sistema di sviluppo, dove risiedono codice sorgente, chiavi cloud, token API e accessi a pipeline CI/CD. La minaccia si integra nei workflow quotidiani, sfrutta la fiducia negli strumenti di sviluppo e punta a ottenere esecuzione di codice remoto in memoria con un’architettura di comando e controllo in due fasi. La telemetria raccolta da Microsoft Defender indica che l’attività si allinea a un cluster più ampio che utilizza esche legate al recruiting per mimetizzarsi nelle routine degli sviluppatori. Un “progetto interview” diventa così un vettore di compromissione affidabile.

Dalla telemetria al pivot: come sono stati scoperti i repository

L’indagine parte da connessioni outbound sospette verso infrastrutture C2 controllate dall’attaccante. Microsoft Defender evidenzia processi Node.js che comunicano ripetutamente con IP correlati a staging e comando. Tracciando a ritroso l’esecuzione, gli analisti identificano repository ospitati su piattaforme pubbliche, presentati come assessment tecnici a tema recruiting. Un primo repository, camuffato da progetto legittimo, funge da meccanismo di consegna iniziale. Successivamente emergono repository correlati che condividono convenzioni di naming come “Cryptan-Platform-MVP1”, insieme a varianti con suffissi quali v1, demo, master, platform, server. Il pivot si basa su segnali chiave: naming ricorrente, riuso strutturale dei file e logica loader identica.

L’analisi dei pattern consente di identificare ulteriori repository non direttamente visibili nei log iniziali, ma funzionalmente correlati. Il riuso della struttura e del meccanismo di staging conferma un’operazione coordinata di seeding.

Tre percorsi di esecuzione verso lo stesso backdoor

L’analisi tecnica rivela tre percorsi di esecuzione distinti che convergono su un medesimo esito: il recupero runtime di JavaScript controllato dall’attaccante e la sua esecuzione in memoria. Il primo percorso sfrutta l’automazione di workspace in Visual Studio Code. Un file .vscode/tasks.json con runOn: "folderOpen" innesca l’esecuzione immediata al momento dell’apertura del progetto. In alcune varianti, uno script offuscato funge da fallback durante l’inizializzazione del workspace. Il loader viene recuperato da un endpoint ospitato su Vercel e lanciato tramite Node.js, avviando il beacon verso l’infrastruttura C2. Il secondo percorso si attiva quando lo sviluppatore esegue manualmente l’applicazione, ad esempio con npm run dev. Asset apparentemente legittimi come jquery.min.js risultano trojanizzati e contengono codice offuscato che decodifica un URL base64-encoded, recupera un loader JavaScript e lo esegue in memoria. Anche in questo caso il traffico outbound verso endpoint staging precede la comunicazione persistente con server C2 su HTTP porta 300. Il terzo percorso coinvolge il backend. Un valore .env come AUTH_API=<base64> viene decodificato al startup. Un modulo, ad esempio server/routes/api/auth.js, trasmette process.env a un endpoint controllato dall’attaccante e riceve codice JavaScript eseguito dinamicamente tramite new Function("require", response.data)(require). Questo espone configurazioni sensibili come chiavi cloud e credenziali database, abilitando esfiltrazione e tasking successivo.

Fase 1: beacon e registrazione leggera

Indipendentemente dal vettore iniziale, tutti i percorsi conducono a un payload di Fase 1 che funge da registrar leggero. Il client profila l’host, effettua polling a intervalli regolari verso un endpoint di registrazione e riceve un identificatore persistente instanceId. In base alle risposte del server, può eseguire codice bootstrap in memoria senza scrivere artefatti su disco.

L’uso di new Function() per compilare JavaScript runtime riduce il footprint e aumenta la stealthiness. La Fase 1 stabilisce l’identità dell’host e prepara la transizione verso un controller separato.

Fase 2: controller persistente e tasking operator-driven

La Fase 2 trasforma il foothold iniziale in un client di tasking persistente. Il payload, spesso eseguito come script inline tramite node -e, mantiene un loop di controllo a lungo termine. Comunica con endpoint come /api/handleErrors e /api/reportErrors, riceve array messages[] contenenti task JavaScript e li esegue in memoria tramite interprete Node separato.

Il controller gestisce stato di sessione, ruota identificatori, implementa logica retry e supporta kill-switch remoto. Le operazioni osservate includono enumerazione directory tramite endpoint paired /api/hsocketNext e /api/hsocketResult, oltre a workflow di upload staged attraverso /upload, /uploadsecond e /uploadend. Questo design modulare consente scoperta guidata dall’operatore, consegna di payload follow-on e esfiltrazione di dati sensibili. L’architettura in due fasi massimizza controllo e resilienza.

Perché i developer sono un bersaglio ad alto valore

I sistemi developer contengono asset strategici: repository privati, chiavi di accesso a cloud provider, token CI/CD, credenziali database. Quando un assessment non fidato viene eseguito su un endpoint corporate, il compromesso può espandersi oltre la singola macchina. La campagna dimostra come il workflow di sviluppo sia diventato una superficie d’attacco primaria. L’apertura di un repository, l’avvio di un server di sviluppo o l’import di un modulo backend sono azioni normali che qui diventano trigger di esecuzione remota.

Mitigazioni: confini di fiducia e controllo delle identità

Microsoft raccomanda containment immediato e scoping in caso di sospetto. La telemetria endpoint deve essere analizzata per individuare polling ripetuto verso endpoint sospetti e process tree anomali. È necessario effettuare pivot sull’intera flotta utilizzando tabelle come DeviceNetworkEvents e DeviceProcessEvents. Poiché la campagna include furto di credenziali e sessioni, la risposta deve integrare triage dell’identità e remediation delle sessioni. Microsoft Entra ID Protection fornisce un framework per investigare sign-in rischiosi e utenti compromessi. In caso di sospetto furto di token, controlli come Conditional Access app control in Microsoft Defender for Cloud Apps possono limitare movimenti dati durante l’indagine. Sul fronte endpoint, è cruciale rafforzare i confini di fiducia nei workflow developer. Workspace Trust e Restricted Mode in Visual Studio Code impediscono l’esecuzione automatica di codice in cartelle non fidate fino a esplicita approvazione. Le organizzazioni dovrebbero adottare questa impostazione come default per repository provenienti da fonti sconosciute. Ulteriori controlli includono regole di riduzione superficie d’attacco in Microsoft Defender for Endpoint, protezione cloud-based in Defender Antivirus e SmartScreen per mitigare download e staging malevoli. La centralizzazione del monitoring in Microsoft Sentinel consente la creazione di query di hunting focalizzate su esecuzioni Node insolite, polling HTTP ripetuti e pattern di upload staged.

Una lezione per la supply chain del codice

Questa campagna evidenzia un punto chiave: la supply chain del software non si limita a dipendenze e pacchetti pubblici. Anche un semplice “progetto interview” può diventare un vettore di compromissione. Il confine tra attività lavorativa e superficie d’attacco si assottiglia. I difensori devono trattare l’ambiente di sviluppo come infrastruttura critica, applicando visibilità, segmentazione e controlli di identità allo stesso livello dei sistemi di produzione. Perché oggi, prima ancora del deploy, è nel codice in fase di sviluppo che si gioca la prima linea della sicurezza.