Kwaadaardige Next.js repo's misbruiken VS Code-taken

Introductie: waarom dit belangrijk is

Werkstations van ontwikkelaars en build-omgevingen zijn doelwitten met hoge waarde, omdat ze vaak broncode, signing-materiaal en secrets (API-tokens, cloud-credentials) in omgevingsvariabelen bevatten. Microsoft Defender Experts rapporteert een campagne die kwaadaardige Next.js-repositories verspreidt—vaak verpakt als jobgerelateerde “take-home”-assessments—die zijn ontworpen om op te gaan in normale developer-workflows en betrouwbaar code-executie te triggeren.

Wat is er nieuw / belangrijkste bevindingen

Microsoft observeerde meerdere gerelateerde repositories met gedeelde naamgevingsconventies en hergebruikte loader-logica. Hoewel de initiële lokmiddelen variëren, is de eindtoestand consistent: runtime ophalen en in-memory uitvoeren van door aanvallers beheerde JavaScript, gevolgd door gefaseerde C2.

1) VS Code-workspace-executie bij het openen van een map

Sommige repo’s bevatten .vscode/tasks.json die is geconfigureerd met runOn: "folderOpen". Als een ontwikkelaar het project opent (en vertrouwt), wordt automatisch een taak uitgevoerd die een Node-script start dat een JavaScript-loader ophaalt (waargenomen in stages op Vercel) en deze uitvoert.

2) Build-time executie bij het draaien van de app

Andere varianten worden geactiveerd wanneer een ontwikkelaar het project start (bijvoorbeeld npm run dev). Deze repo’s verbergen kwaadaardige logica in ogenschijnlijk normale assets (bijv. een getrojaniseerde jquery.min.js). De asset decodeert een base64-URL, haalt de loader op (opnieuw vaak vanaf Vercel) en voert deze in memory uit.

3) Backend-opstartexecutie met env-exfiltratie + dynamische RCE

Een derde route activeert tijdens server-initialisatie/module-import. Repo’s kunnen een .env-waarde bevatten zoals AUTH_API=<base64>. Bij het opstarten decodeert backend-code het endpoint, post process.env naar de aanvaller en voert vervolgens geretourneerde JavaScript uit via dynamische compilatie (bijv. new Function("require", response.data)(require)). Dit kan gevoelige configuratie lekken en maakt operator-gestuurde follow-on payload delivery mogelijk.

Stage 1-registratie → gefaseerde command-and-control

Over alle routes heen komt de uitvoering samen in een initiële “registrar”-fase die de host profileert en een registratie-endpoint pollt, waarna een instanceId wordt ontvangen om daaropvolgende activiteit te correleren. Telemetrie noteerde ook persistente callbacks naar door aanvallers beheerde infrastructuur (inclusief HTTP-verkeer op poort 300) na de initiële staging.

Impact voor IT-admins en securityteams

• Hoger risico op developer-endpoints: Het openen van een repo kan al voldoende zijn om code uit te voeren als workspace-taken worden vertrouwd.
• Credential exposure: De backend-opstartroute kan omgevingsvariabelen exfiltreren (cloud keys, database-credentials, CI-tokens).
• Moeilijkere detectie: In-memory uitvoering en gefaseerde loaders kunnen zichtbare on-disk artefacts verminderen.

Actiepunten / volgende stappen

• Richtlijnen voor ontwikkelaars: Behandel take-home-assessments en onbekende repo’s als niet-vertrouwd; klik niet op “Trust” in VS Code voordat er is beoordeeld.
• Repo-inspectie: Flag/inspecteer .vscode/tasks.json (met name runOn: "folderOpen"), onverwachte Node-scripts onder .vscode/, en geminificeerde libraries die niet overeenkomen met bekende hashes.
• Secret hygiene: Verminder afhankelijkheid van long-lived secrets in .env; gebruik waar mogelijk managed identities/short-lived tokens en roteer eventuele blootgestelde credentials.
• Detectie & controls: Monitor Node.js-processen op ongebruikelijke outbound-verbindingen (bijv. dev tools die staging-domeinen aanroepen gevolgd door onbekende C2), en overweeg egress-restricties vanaf developer-devices en build agents.
• Hunting: Doorzoek code hosting en interne mirrors op naamgevings- “families” en patronen van structureel hergebruik zoals beschreven door Microsoft (near-duplicate repo’s, vergelijkbare loaders, herhaalde staging-endpoints).