Die meisten Sicherheitsteams haken die EDR-Anforderung ab, haken die Proxy-Anforderung ab und gehen zum nächsten Punkt über. Gegen Supply-Chain-Malware bietet beides keinen ausreichenden Schutz, da sie für ein anderes Problem entwickelt wurden.
Traditionelle Malware schleicht sich auf eine Maschine, während Lieferketten-Malware eingeladen wird. Die Entwickelnde führt aus npm install, und der bösartige Code landet mit voller Ausführungsberechtigung. Diese Umkehrung sprengt beide Tools auf Designebene.
Warum EDR Malware übersieht
EDR überwacht Prozesse auf verdächtiges Verhalten: ungewöhnliche Systemaufrufe, unerwartete Eltern-Kind-Beziehungen, bekannte bösartige Signaturen. Es fragt: „Verhält sich dieser Prozess wie Malware?“
Das Problem ist, dass Lieferketten-Malware in vertrauenswürdigen Laufzeitumgebungen ausgeführt wird und dabei Dinge tut, die diese Laufzeitumgebungen den ganzen Tag tun. Ein Postinstall-Skript, das `.env`-Dateien liest und deren Inhalte an einen Angreifer POSTet, sieht identisch aus wie ein Build-Tool, das Anmeldeinformationen zum Bereitstellen von Code abruft. Beide sind node oder python Dateien lesen und HTTP-Aufrufe tätigen. Die Systemaufrufe und die Netzwerkaufrufe sind dieselben. EDR hat keinen Kontext, dass das eine legitim und das andere nicht ist.
Im März 2026 kaperten Angreifer das npm-Konto des Hauptentwicklers von axios, einem Paket mit ~100 Millionen wöchentlichen Downloads. Sie rührten den Quellcode nicht an. Sie fügten eine neue Abhängigkeit hinzu, deren einzige Aufgabe ein Postinstall-Skript war, das einen plattformübergreifenden RAT herunterlud und sich selbst löschte. Für einen Prozessmonitor war dies nicht von einem npm install zu unterscheiden, das seine Arbeit verrichtet. Es löst eine Abhängigkeit auf, führt einen Hook aus und tätigt eine HTTP-Anfrage.
Zwei Monate später, drei Versionen von durabletask, einem Python-Paket im Azure-Ökosystem von Microsoft, wurden mit einer Backdoor versehen. Die Injektion umfasste etwa zehn Zeilen in __init__.py. Der Code ruft eine Datei ab und führt sie in einem Subprozess aus, wobei Ausnahmen verschluckt werden. Die zweite Stufe sammelte Anmeldeinformationen von AWS, Azure, GCP, Kubernetes und Vault und verbreitete sich dann über SSM auf andere Instanzen und über kubectl execauf andere Pods, unter Verwendung der eigenen Anmeldeinformationen des Opfers und Zugriff auf die eigenen Cloud-APIs des Opfers. Auf Hosts mit israelischen oder iranischen Gebietsschema-Einstellungen führte ein Sechstel der Fälle `rm -rf \*` aus. Keine fremde Binärdatei, kein anomales Ziel. EDR hat kein Modell für den Fall, dass das Paket selbst die Bedrohung darstellt.
Lieferkettenangriffe auf dieser Ebene sind so gefährlich, weil die bösartige Nutzlast normales Verhalten ist. Es gibt keine Anomalie zu erkennen, denn der ganze Sinn besteht darin, sich in das Rauschen einzufügen oder in diesem Fall das Rauschen selbst zu sein.
Warum Proxys es übersehen
Ein Proxy im Traffic-Pfad kann Paket-Downloads abfangen und sie auf bekannte bösartige Pakete überprüfen. Das funktioniert theoretisch. Das Problem ist der Teil „im Traffic-Pfad“.
Remote- und Unternehmens-Proxys sind Opt-in-Kontrollen auf Maschinen, die Entwickelnde besitzen. Entwickelnde arbeiten von zu Hause, aus Cafés, vom Hotel-WLAN. Sie installieren Tools, die System-Proxy-Einstellungen umgehen. VS Code verwaltet seine eigenen Erweiterungs-Downloads. npm, pip und cargo haben ihre eigenen HTTP-Clients. Viele CLI-Tools und Sprachlaufzeitumgebungen ignorieren HTTP_PROXY vollständig, es sei denn, sie sind explizit konfiguriert. Und wenn ein Tool wegen des Proxys nicht funktioniert, deaktivieren Entwickelnde den Proxy, beheben das Problem und vergessen, ihn wieder zu aktivieren.
Solche Fälle passieren jeden Tag. Eine Entwickelnde installiert um 23 Uhr eine kompromittierte VS Code-Erweiterung von ihrer persönlichen Maschine. Ein CI-Runner zieht eine vergiftete Abhängigkeit außerhalb des Unternehmensnetzwerk-Perimeters. Keiner dieser Installationen läuft über den Proxy. Der Scan läuft nie. Die Überprüfung, die es hätte erkennen sollen, war einfach nicht vorhanden.
Was wirklich funktioniert
Sowohl EDR als auch Proxys lösen reale Probleme für die Bedrohungen, für die sie entwickelt wurden, und sind immer noch wertvoll. Sie decken jedoch nicht die entwickelndenspezifische Angriffsfläche der Lieferkette ab.
Diese Oberfläche benötigt etwas, das auf der Maschine selbst lebt, versteht, was Pakete zum Installationszeitpunkt tun, und immer vorhanden ist, unabhängig von der Netzwerkkonfiguration. Wir haben Aikido Device Protection entwickelt, um genau das zu tun. Erfahren Sie in diesem Blog, wie eine Reihe von Organisationen Device Protection zum Schutz von Entwickelnden-Maschinen einsetzen.
Wenn Sie ein vollständigeres Bild davon erhalten möchten, was traditionelle Endpoint-Tools auf Entwickelnden-Maschinen übersehen, wird die MDM-Version dieses Problems in diesem Artikel behandelt.
