Skadliga Next.js-repon stjäl data via VS Code Tasks

Introduktion: varför detta spelar roll

Utvecklares arbetsstationer och byggmiljöer är högvärdiga mål eftersom de ofta innehåller källkod, signeringsmaterial och hemligheter (API-tokens, molnuppgifter) i miljövariabler. Microsoft Defender Experts rapporterar om en kampanj som planterar skadliga Next.js-repon—ofta paketerade som jobbrelevanta “take-home”-uppgifter—utformade för att smälta in i normala utvecklarflöden och pålitligt trigga kodexekvering.

Nytt / viktigaste fynden

Microsoft observerade flera relaterade repon med delade namngivningskonventioner och återanvänd loader-logik. Även om den initiala luringen varierar är slutläget konsekvent: hämtning vid körning och exekvering i minnet av attacker-kontrollerad JavaScript, följt av stegvis C2.

1) VS Code workspace-exekvering när en mapp öppnas

Vissa repon inkluderar .vscode/tasks.json konfigurerad med runOn: "folderOpen". Om en utvecklare öppnar projektet (och litar på det) körs en uppgift automatiskt och startar ett Node-skript som hämtar en JavaScript-loader (observerad i steg på Vercel) och exekverar den.

2) Exekvering vid byggtid när appen körs

Andra varianter triggas när en utvecklare startar projektet (till exempel npm run dev). Dessa repon bäddar in skadlig logik i till synes normala tillgångar (t.ex. en trojaniserad jquery.min.js). Tillgången avkodar en base64-URL, hämtar loadern (återigen, ofta från Vercel) och exekverar den i minnet.

3) Exekvering vid backend-uppstart med env-exfiltration + dynamisk RCE

En tredje väg aktiveras under serverinitialisering/modulimport. Repon kan innehålla ett .env-värde som AUTH_API=<base64>. Vid uppstart avkodar backend-koden endpointen, postar process.env till angriparen och exekverar sedan returnerad JavaScript med dynamisk kompilering (t.ex. new Function("require", response.data)(require)). Detta kan läcka känslig konfiguration och möjliggör operatörsstyrd leverans av efterföljande payloads.

Steg 1-registrering → stegvis command-and-control

Över alla vägar konvergerar exekveringen mot ett initialt “registrar”-steg som profilerar värden och pollar en registreringsendpoint, och tar emot ett instanceId för att korrelera efterföljande aktivitet. Telemetri noterade även beständiga callbacks till angriparstyrd infrastruktur (inklusive HTTP-trafik på port 300) efter den initiala iscensättningen.

Påverkan för IT-administratörer och säkerhetsteam

• Högre risk på utvecklarendpoints: Att öppna ett repo kan räcka för att exekvera kod om workspace tasks är betrodda.
• Exponering av autentiseringsuppgifter: Backend-uppstartsvägen kan exfiltrera miljövariabler (molnnycklar, databasuppgifter, CI-tokens).
• Svårare att upptäcka: Exekvering i minnet och stegvisa loaders kan minska uppenbara artefakter på disk.

Åtgärder / nästa steg

• Vägledning för utvecklare: Behandla take-home-uppgifter och okända repon som opålitliga; undvik att klicka “Trust” i VS Code innan granskning.
• Repo-granskning: Flagga/granska .vscode/tasks.json (särskilt runOn: "folderOpen"), oväntade Node-skript under .vscode/, och minifierade bibliotek som inte matchar kända bra hashar.
• Secret-hygien: Minska beroendet av långlivade hemligheter i .env; använd managed identities/kortlivade tokens där det är möjligt och rotera eventuella exponerade autentiseringsuppgifter.
• Detektion och kontroller: Övervaka Node.js-processer för ovanliga utgående anslutningar (t.ex. utvecklarverktyg som anropar staging-domäner följt av okänd C2), och överväg egress-begränsningar från utvecklarenheter och build agents.
• Hunting: Sök i kodhosting och interna speglar efter namngivnings-“familjer” och mönster av strukturell återanvändning som Microsoft beskriver (nästan identiska repon, liknande loaders, upprepade staging-endpoints).