Next.js-Malware in VS Code-Repos: So schützen sich Devs

Einführung: warum das wichtig ist

Entwickler-Workstations und Build-Umgebungen sind hochwertige Ziele, weil sie häufig Quellcode, Signiermaterial und Geheimnisse (API-Token, Cloud-Credentials) in Umgebungsvariablen enthalten. Microsoft Defender Experts berichtet über eine Kampagne, die bösartige Next.js-Repositories streut—oft verpackt als jobbezogene „Take-Home“-Assessments—und darauf ausgelegt ist, sich in normale Entwickler-Workflows einzufügen und zuverlässig Codeausführung auszulösen.

Was neu ist / zentrale Erkenntnisse

Microsoft beobachtete mehrere zusammenhängende Repositories mit gemeinsamen Namenskonventionen und wiederverwendeter Loader-Logik. Während der initiale Köder variiert, ist das Endergebnis konsistent: Laufzeit-Abruf und In-Memory-Ausführung von attacker-kontrolliertem JavaScript, gefolgt von gestaffeltem C2.

1) VS Code Workspace-Ausführung beim Öffnen des Ordners

Einige Repos enthalten .vscode/tasks.json, konfiguriert mit runOn: "folderOpen". Wenn ein Entwickler das Projekt öffnet (und ihm vertraut), wird automatisch ein Task ausgeführt und ein Node-Skript gestartet, das einen JavaScript-Loader abruft (beobachtet als Staging auf Vercel) und ihn ausführt.

2) Build-Time-Ausführung beim Starten der App

Andere Varianten werden ausgelöst, wenn ein Entwickler das Projekt startet (zum Beispiel npm run dev). Diese Repos betten bösartige Logik in scheinbar normale Assets ein (z. B. ein trojanisiertes jquery.min.js). Das Asset decodiert eine base64-URL, ruft den Loader ab (erneut häufig von Vercel) und führt ihn in memory aus.

3) Backend-Startup-Ausführung mit Env-Exfiltration + dynamischem RCE

Ein dritter Pfad wird während der Serverinitialisierung bzw. beim Module-Import aktiviert. Repos können einen .env-Wert wie AUTH_API=<base64> enthalten. Beim Start decodiert Backend-Code den Endpoint, postet process.env an den Angreifer und führt anschließend zurückgeliefertes JavaScript über dynamische Kompilierung aus (z. B. new Function("require", response.data)(require)). Das kann sensible Konfiguration leaken und ermöglicht operator-gesteuerte Folge-Payload-Auslieferung.

Stage-1-Registrierung → gestaffeltes Command-and-Control

Über alle Pfade hinweg läuft die Ausführung auf eine initiale „Registrar“-Stage zusammen, die den Host profiliert und einen Registration-Endpoint abfragt, wobei ein instanceId empfangen wird, um nachfolgende Aktivität zu korrelieren. Telemetrie stellte zudem persistente Callbacks zu attacker-kontrollierter Infrastruktur fest (einschließlich HTTP-Traffic auf Port 300) nach dem initialen Staging.

Auswirkungen für IT-Admins und Security-Teams

• Höheres Risiko auf Entwickler-Endpoints: Das Öffnen eines Repos kann ausreichen, um Code auszuführen, wenn Workspace-Tasks als vertrauenswürdig eingestuft werden.
• Credential-Exposure: Der Backend-Startup-Pfad kann Umgebungsvariablen exfiltrieren (Cloud-Keys, Datenbank-Credentials, CI-Token).
• Schwerer zu erkennen: In-Memory-Ausführung und gestaffelte Loader können offensichtliche On-Disk-Artefakte reduzieren.

Maßnahmen / nächste Schritte

• Developer Guidance: Behandeln Sie Take-Home-Assessments und unbekannte Repos als nicht vertrauenswürdig; vermeiden Sie in VS Code das Klicken auf „Trust“, bis eine Prüfung erfolgt ist.
• Repo-Inspektion: Markieren/prüfen Sie .vscode/tasks.json (insbesondere runOn: "folderOpen"), unerwartete Node-Skripte unter .vscode/ sowie minifizierte Libraries, die nicht mit bekannten Good-Hashes übereinstimmen.
• Secret Hygiene: Reduzieren Sie die Abhängigkeit von langlebigen Secrets in .env; nutzen Sie nach Möglichkeit Managed Identities/kurzlebige Tokens und rotieren Sie alle exponierten Credentials.
• Detection & Controls: Überwachen Sie Node.js-Prozesse auf ungewöhnliche ausgehende Verbindungen (z. B. Dev-Tools, die Staging-Domains aufrufen, gefolgt von unbekanntem C2), und erwägen Sie Egress-Restriktionen für Entwicklergeräte und Build-Agents.
• Hunting: Durchsuchen Sie Code-Hosting und interne Mirrors nach Namens-„Families“ und strukturellen Wiederverwendungsmustern, die Microsoft beschrieben hat (nahezu identische Repos, ähnliche Loader, wiederholte Staging-Endpoints).