Repo Next.js dannosi: malware VS Code e furto dati
Riepilogo
Microsoft segnala una campagna che distribuisce repository Next.js malevoli, spesso camuffati da test tecnici per assunzioni, per colpire sviluppatori e ambienti di build ad alto valore. I progetti possono eseguire codice automaticamente all’apertura della cartella in VS Code o durante l’avvio dell’app, scaricando payload in memoria e avviando comunicazioni di comando e controllo: un rischio rilevante perché può portare al furto di codice sorgente, token API e credenziali cloud.
Introduzione: perché è importante
Le workstation degli sviluppatori e gli ambienti di build sono obiettivi ad alto valore perché spesso contengono codice sorgente, materiale per la firma e segreti (token API, credenziali cloud) nelle variabili d’ambiente. Microsoft Defender Experts segnala una campagna che semina repository Next.js malevoli—spesso confezionati come “take-home” assessment legati a offerte di lavoro—progettati per confondersi nei normali flussi di lavoro degli sviluppatori e attivare in modo affidabile l’esecuzione di codice.
Novità / risultati principali
Microsoft ha osservato più repository correlate con convenzioni di naming condivise e logica di loader riutilizzata. Anche se l’esca iniziale varia, l’esito finale è coerente: recupero a runtime ed esecuzione in memoria di JavaScript controllato dall’attaccante, seguiti da C2 a fasi.
1) Esecuzione del workspace VS Code all’apertura della cartella
Alcuni repo includono .vscode/tasks.json configurato con runOn: "folderOpen". Se uno sviluppatore apre (e considera attendibile) il progetto, un’attività viene eseguita automaticamente e avvia uno script Node che recupera un loader JavaScript (osservato in staging su Vercel) e lo esegue.
2) Esecuzione in fase di build all’avvio dell’app
Altre varianti si attivano quando uno sviluppatore avvia il progetto (ad esempio, npm run dev). Questi repo incorporano logica malevola in asset apparentemente normali (ad esempio, un jquery.min.js trojanizzato). L’asset decodifica un URL base64, recupera il loader (anche qui, spesso da Vercel) e lo esegue in memoria.
3) Esecuzione all’avvio del backend con esfiltrazione env + RCE dinamica
Un terzo percorso si attiva durante l’inizializzazione del server/import del modulo. I repo possono contenere un valore .env come AUTH_API=<base64>. All’avvio, il codice backend decodifica l’endpoint, invia process.env all’attaccante, quindi esegue il JavaScript restituito usando compilazione dinamica (ad esempio, new Function("require", response.data)(require)). Questo può far trapelare configurazioni sensibili e consente la distribuzione di payload successivi guidata dall’operatore.
Registrazione Stage 1 → command-and-control a fasi
In tutti i percorsi, l’esecuzione converge su uno stage iniziale di “registrar” che profila l’host ed esegue polling di un endpoint di registrazione, ricevendo un instanceId per correlare l’attività successiva. La telemetria ha inoltre rilevato callback persistenti verso infrastruttura controllata dall’attaccante (incluso traffico HTTP sulla porta 300) dopo lo staging iniziale.
Impatto per gli amministratori IT e i team di sicurezza
- Rischio più elevato sugli endpoint degli sviluppatori: Aprire un repo può bastare per eseguire codice se le attività del workspace vengono considerate attendibili.
- Esposizione delle credenziali: Il percorso di avvio backend può esfiltrare variabili d’ambiente (chiavi cloud, credenziali database, token CI).
- Rilevamento più difficile: L’esecuzione in memoria e i loader a fasi possono ridurre gli artefatti evidenti su disco.
Azioni / prossimi passi
- Linee guida per gli sviluppatori: Trattare take-home assessment e repo non familiari come non attendibili; evitare di fare clic su “Trust” in VS Code finché non vengono revisionati.
- Ispezione dei repo: Segnalare/ispezionare
.vscode/tasks.json(in particolarerunOn: "folderOpen"), script Node inattesi sotto.vscode/e librerie minificate che non corrispondono a hash noti e affidabili. - Igiene dei segreti: Ridurre la dipendenza da segreti a lunga durata in
.env; usare managed identities/token a breve durata dove possibile e ruotare eventuali credenziali esposte. - Rilevamento e controlli: Monitorare i processi Node.js per connessioni in uscita insolite (ad esempio, tool di sviluppo che chiamano domini di staging seguiti da C2 sconosciuti) e valutare restrizioni di egress da dispositivi degli sviluppatori e build agent.
- Hunting: Cercare su piattaforme di hosting del codice e mirror interni “famiglie” di naming e pattern di riuso strutturale descritti da Microsoft (repo quasi duplicati, loader simili, endpoint di staging ripetuti).
Hai bisogno di aiuto con Security?
I nostri esperti possono aiutarti a implementare e ottimizzare le tue soluzioni Microsoft.
Parla con un espertoResta aggiornato sulle tecnologie Microsoft