Die Kampagne, die technische Tests in Hintertüren verwandelt und Code in Erinnerung in Entwicklungsumgebungen führt

Entwickler sind ein strategisches Ziel für schädliche Schauspieler geworden, die nicht nur versuchen, Anmeldeinformationen zu stehlen, sondern hartnäckigen Zugriff auf Maschinen mit sensiblen Informationen zu pflanzen. Ein neuer Microsoft-Bericht beschreibt eine koordinierte Kampagne, die Projekte oder falsche technische Tests ausnutzt - vor allem als Next.js-Projekte oder Interview-Übungen -, um Entwickler zu induzieren, um Code auszuführen, die dann von Angreifern gesteuerte Skripte laden und ausführen. Das letzte Ziel ist sehr klar: die Fernausführung des Codes im Speicher zu erhalten und von dort aus die Kontrolle zu erweitern, ohne Spuren auf der Festplatte zu hinterlassen. Sie können die Microsoft-Analyse hier lesen: Microsoft Defender Security Research.

Die Bedrohung basiert auf dem Vertrauen, dass Entwicklungsteams in alltägliche Werkzeuge und Strömungen setzen. Von den Forschern wurden drei Arten der Hinrichtung beschrieben, die in ihrem Aktivator unterschiedlich, aber in seinem Ergebnis konvergent sind. Im ersten Schritt nutzt eine Visual Studio Code-Konfigurationsdatei die Workspace-Automatisierung, um Aufgaben beim Öffnen des Projektordners einzufordern; die Konfiguration verwendet einen Trigger, der Remote-Befehle durch Anvertrauen des Projekts ausführt, so dass Sie einen angemeldeten Ladegerät auf öffentlichen Plattformen herunterladen und heiß ausführen können.

Der zweite Vektor ist derjenige, der während der Entwicklung passiert: Starten Sie einfach den Server mit dem klassischen Entwicklungsbefehl - zum Beispiel npm run dev- um den versteckten Code in modifizierten JavaScript-Bibliotheken zu aktivieren, die als harmlose Abhängigkeiten erscheinen, wie z.B. eine minifizierte Datei von jQuery. Dieser schädliche Code lädt einen Loader aus einer Staging-Domain (oft Vercel) herunter, die dann Anweisungen direkt in der Node.js. Prozess führt.

Die dritte Methode wird ausgelöst, wenn Sie den Applikations-Backend starten: scheinbar legitime Module oder Routen können Logik enthalten, die beim Start die Prozessumgebung (z.B. Umgebungsvariablen) an einen externen Server sendet und die JavaScript-Antwort im Speicher ausführt. In allen Fällen macht die gleiche JavaScript-Payload ein Maschinenprofil und kontaktiert regelmäßig einen Endpunkt der Registrierung, um eine eindeutige Kennung ("instanceId") zu erhalten, die zur Korrelation und Verwaltung der Sitzung dient.

Die technische Bedeutung des laufenden Codes im Speicher ist, dass es den forensischen Druck auf der Festplatte reduziert und die Lieferung einer zweiten Stufe erleichtert, die als Controller fungiert: eine "Stufe 2", die in der Lage ist, Aufgaben auf Anfrage auszuführen, Vermögenswerte in der Umgebung zu entdecken und Informationen auszufiltern. Microsoft betont, dass der Controller Fehler-Telemetrie, Retry-Logik und Fähigkeit, Kinderprozesse zu verwalten - das heißt, es verhält sich als gut gestaltetes Remote Access Tool. Weitere Details in Microsofts Originalbericht: Technischer Bericht.

Es ist nicht nur Vercel: Angreifer haben auch mit alternativen Stadienservern begonnen, um spätere Stadien aufzunehmen. Abstrakte Sicherheit hat eine Änderung der Taktik gegenüber der Verwendung von GitHub Gists und URL kürzer dokumentiert, um den wahren Ursprung der Nutzlasten zu verbergen. Sie identifizierten auch ein schädliches npm-Paket namens "slint-validator", das eine outspoken Nutzlast von Google Drive erholt: dass Nutzlast entspricht einer JavaScript Malware-Familie bekannt als BeaverTail.

In Windows wurden noch aufwendigere Infektionsketten beobachtet: Eine VS-Code-Task kann ein Batch-Skript starten, das Node.js herunterlädt, wenn es nicht vorhanden ist, native Dienstprogramme als Certutil verwendet, um eingebettete Codeblöcke zu decodieren und mit der Node Laufzeit eine Malware in Python mit PyArmor geschützt entfaltet. Andere Analysen zeigen auf kreative Techniken der Widerstandsfähigkeit: Code in NFT-Kontrakte in Blockchains wie Polygon für die Nutzlast, von dort zurückzugewinnen, so dass es schwierig, seine Verfügbarkeit zu widerrufen und zu erhöhen.

Unabhängige Forscher Asgard Network haben diese Aktivität verfolgt und sie mit Taktiken verknüpft, die in früheren Kampagnen verwendet werden, die für ihre Raffinesse bekannt sind. Während Microsoft die Kampagne nicht einem bestimmten Schauspieler zuzuschreiben vermeidet, passen die Muster zu einer Gruppe von Operationen, die in der Vergangenheit mit nordkoreanischen Gruppen unter dem Label "Contagious Interview" in einigen öffentlichen Berichten in Zusammenhang stehen.

Kooperationsplattformen und öffentliche Repositorien waren nicht immun: GitLab berichtete über die Beseitigung von mehr als 100 Konten, die für die Verteilung von schädlichen Projekten verantwortlich sind, die mit dieser Kampagne verbunden sind. Sein Intelligence-Team fand auch interne Beweise, die auf eine organisierte Struktur hinter diesen Operationen, mit Finanzprotokollen und Ausrüstungsleistungskontrolle, deutete auf eine nachhaltige und wirtschaftliche nutzorientierte Tätigkeit. Mehr Kontext in GitLabs Analyse: GitLab Threat Intelligence.

Für diejenigen, die in der Entwicklung arbeiten, sollte dies den Alarm klingen: "technische Test" Repositories oder Interview Vorlagen sind ideale Vektoren, weil sie täglich Aufgaben passen. Führen Sie einen lokalen Server, öffnen Sie einen Workspace oder Vertrauen ein Standardprojekt kann ausreichen, um eine schädliche Ausführungskette auszulösen. Legitimierte Tools und Dienste, die externe Inhalte (Vercel, Render, Railway, JSON Keeper, u.a. npoint.io) hosten, wurden von Angreifern wiederverwendet, um Payloads zu speichern und zu bedienen.

Die praktischen Empfehlungen sind nicht radikal, aber sie erfordern Disziplin: die Privilegien der Entwicklungskonten zu begrenzen, Gebäude und CI / CD-Umgebungen vom Entwicklungsteam zu segregaten, starke Authentifizierung und bedingten Zugang zu anzuwenden und die in den Projekten enthaltenen Aufgaben und Automatisierungen zu filtern oder zu überprüfen, bevor sie umgesetzt werden. Es ist auch angebracht, Abhängigkeiten zu scannen, Skripte von Drittanbietern ohne Überarbeitung zu vermeiden und sich nicht automatisch auf die Vertrauensaufforderungen des VS-Codes oder auf Aufgaben mit Ausführung verlassen Auf konfiguriert, um Ordner zu öffnen.

Darüber hinaus sollten Unternehmen und Sicherheitsbeamte die Erkennung von Node.js-Prozessen implementieren, die JavaScript im Speicher herunterladen und bewerten, ausgehende Verbindungen zu öffentlichen Hosting-Diensten überwachen und wo möglich weiße Listen verwenden. Repository und Plattform-Anbieter nehmen bereits Maßnahmen ein: Die Kontoabhebung und Koordination zwischen Sicherheitsteams ist Teil der Antwort. Um die menschliche Dimension des Problems zu verstehen und wie "Beschäftigung" als Köder ausgenutzt wird, bietet Oktas Bericht eine interessante Perspektive, wie einige falsche Kandidaten Kontrollen passieren und in diesen Systemen verwendet werden: Okta Analyse.

Die Botschaft für die technische Gemeinschaft ist einfach und dringend: senken Sie Ihre Wache nicht. Die Kombination von Social Engineering mit der Automatisierung von Entwicklung fließt eine scheinbar harmlose Git Projekt in eine effektive Hintertür. Überprüfen Sie die Aufgaben.json, Audit-Abhängigkeiten und behandeln Sie mit Verdacht jedes Projekt, das automatische Befehle beim Öffnen ausführen fordert, sind Maßnahmen, die diese Ketten stoppen können, bevor sie ihre erste Nutzlast im Speicher ausführen.

Diese Kampagne erinnert daran, dass die Entwicklungssicherheit spezifische Kontrollen für die täglichen Ströme und Werkzeuge beinhalten sollte. Es geht nicht nur darum, Server in der Produktion zu schützen: Der "Client" - das Entwicklerteam - ist genauso kritisch, wenn dieser Client Schlüssel, Token und Zugang zu Infrastruktur enthält, die in Sekunden geschwenkt werden können. Eine gute Praxis bei der Hygiene von Anmeldeinformationen, Segmentierung und Code-Review ist jetzt eine wesentliche Verteidigung.