Ondsindede Next.js-repositorier angriber udviklere

Introduktion: hvorfor dette er vigtigt

Udvikleres arbejdsstationer og build-miljøer er mål med høj værdi, fordi de ofte indeholder kildekode, signeringsmateriale og hemmeligheder (API-tokens, cloud-legitimationsoplysninger) i miljøvariabler. Microsoft Defender Experts rapporterer om en kampagne, der spreder ondsindede Next.js-repositorier—ofte pakket ind som jobrelaterede “take-home”-opgaver—designet til at gå i ét med normale udviklerarbejdsgange og pålideligt udløse kodeeksekvering.

Hvad er nyt / vigtigste fund

Microsoft observerede flere relaterede repositorier med fælles navngivningskonventioner og genbrugt loader-logik. Selvom det indledende lokkemiddel varierer, er sluttilstanden den samme: hentning ved runtime og in-memory-eksekvering af angriberkontrolleret JavaScript efterfulgt af trinvis C2.

1) VS Code-workspace-eksekvering ved åbning af mappe

Nogle repositorier inkluderer .vscode/tasks.json, konfigureret med runOn: "folderOpen". Hvis en udvikler åbner (og stoler på) projektet, kører en task automatisk og starter et Node-script, der henter en JavaScript-loader (observeret hostet på Vercel) og eksekverer den.

2) Build-time-eksekvering ved kørsel af appen

Andre varianter udløses, når en udvikler starter projektet (for eksempel npm run dev). Disse repositorier indlejrer ondsindet logik i tilsyneladende normale assets (f.eks. en trojaniseret jquery.min.js). Asseten afkoder en base64-URL, henter loaderen (igen ofte fra Vercel) og eksekverer den in-memory.

3) Backend-opstartseksekvering med eksfiltration af miljøvariabler + dynamisk RCE

En tredje vej aktiveres under serverinitialisering/modulimport. Repositorier kan indeholde en .env-værdi som AUTH_API=<base64>. Ved opstart afkoder backend-koden endpointet, sender process.env til angriberen og eksekverer derefter returneret JavaScript ved hjælp af dynamisk kompilering (f.eks. new Function("require", response.data)(require)). Dette kan lække følsom konfiguration og muliggør operatørstyret levering af efterfølgende payloads.

Fase 1-registrering → trinvis command-and-control

På tværs af alle veje konvergerer eksekveringen mod en indledende “registrar”-fase, der profilerer værten og spørger en registreringsendpoint periodisk, hvor den modtager et instanceId til at korrelere efterfølgende aktivitet. Telemetri noterede også vedvarende callbacks til angriberkontrolleret infrastruktur (herunder HTTP-trafik på port 300) efter den indledende staging.

Konsekvenser for IT-administratorer og sikkerhedsteams

• Højere risiko på udviklerendpoints: Det kan være nok at åbne et repositorium til at eksekvere kode, hvis workspace-tasks er markeret som trusted.
• Eksponering af legitimationsoplysninger: Backend-opstartsvejen kan eksfiltrere miljøvariabler (cloud-nøgler, databaselegitimationsoplysninger, CI-tokens).
• Sværere detektion: In-memory-eksekvering og trinvise loaders kan reducere tydelige artefakter på disken.

Handlinger / næste skridt

• Vejledning til udviklere: Behandl take-home-opgaver og ukendte repositorier som utroværdige; undgå at klikke på “Trust” i VS Code, før de er gennemgået.
• Inspektion af repositorier: Markér/undersøg .vscode/tasks.json (især runOn: "folderOpen"), uventede Node-scripts under .vscode/ og minificerede biblioteker, der ikke matcher kendte gode hashværdier.
• Secret hygiene: Reducer afhængigheden af langlivede hemmeligheder i .env; brug managed identities/kortlivede tokens, hvor det er muligt, og roter alle eksponerede legitimationsoplysninger.
• Detektion og kontroller: Overvåg Node.js-processer for usædvanlige udgående forbindelser (f.eks. udviklerværktøjer, der kalder staging-domæner efterfulgt af ukendt C2), og overvej egress-begrænsninger fra udviklerenheder og build-agenter.
• Threat hunting: Søg i kodehosting og interne spejle efter navngivnings-“familier” og mønstre for strukturel genbrug, som Microsoft beskriver (næsten identiske repositorier, lignende loaders, gentagne staging-endpoints).