Erkennung von Sicherheitsverletzungen nach dem Supply Chain von Axios.

Die Kompromittierung des NPM-Pakets „axios“ im Upstream-Bereich dient als entscheidendes Fallbeispiel für die Instrumentalisierung der Lieferkette. Diese Vorfälle verdeutlichen, dass sich das „Dependency Poisoning“ von einem theoretischen Sonderfall zu einem äußerst wirksamen Vektor für den ersten Zugriff entwickelt hat, der es versierten Angreifern ermöglicht, in abgesicherten Unternehmensumgebungen eine Remote-Code-Ausführung (RCE) zu erreichen.

Technische Untersuchungen deuten darauf hin, dass die kompromittierten Axios-Versionen (v1.14.1 und v0.30.4) mit einem Trojaner versehen wurden, um die schädliche Payload „plain-crypto-js@4.2.1“ einzuschleusen. Dieser Vorfall stellt eine entscheidende Abweichung vom herkömmlichen Software-Risiko dar; es handelte sich nicht um die Ausnutzung einer Schwachstelle auf Code-Ebene, sondern um eine gezielte Manipulation der Paketveröffentlichungs-Pipeline.

Die meisten Sicherheitskonzepte basieren darauf, anfällige Funktionen mittels statischer Analyse zu identifizieren, doch nur wenige sind darauf vorbereitet, mit einem Szenario umzugehen, in dem der Paketmanager selbst als Überträger für verschleierte malware dient. Sobald diese schädliche Abhängigkeit zur Laufzeit ausgeführt wird, ändert sich der Umfang des Vorfalls schlagartig. Es geht nicht mehr um die Sauberkeit der Abhängigkeiten, sondern um die Erkennung nach der Ausnutzung, wobei der Schwerpunkt auf dem Verständnis des Verhaltens nach der Ausführung liegt.

Wie der Kompromiss zustande kommt

Mithilfe forensischer Telemetrie und Verhaltensanalysen konnte die Axios-Kompromittierung erfolgreich auf die Übernahme eines Betreuerkontos (ATO) zurückgeführt werden, wodurch die manuelle Einfügung einer bösartigen transitiven Abhängigkeit unter Umgehung herkömmlicher CI/CD-Sicherheitsvorkehrungen ermöglicht wurde. Aktuelle Erkenntnisse weisen diese Kampagne mit hoher Sicherheit BlueNoroff zu, einem hochentwickelten Bedrohungscluster innerhalb der Lazarus-Gruppe (mit Verbindungen zur DVRK), der für aggressive Exfiltration von Finanzdaten und geistigem Eigentum bekannt ist.

Auch wenn die Zuordnung von Angriffen nach wie vor ein dynamisches Forschungsgebiet ist, ist die taktische Priorität für die Sicherheitsteams klar: Eine vertrauenswürdige Abhängigkeit wurde zum Vektor für den Erstzugang. Dieser Vorfall unterstreicht den Zusammenbruch des impliziten Vertrauens im Open-Source-Ökosystem. Für Unternehmen, die CI/CD-Infrastrukturen oder cloud Build-Umgebungen verwalten, bedeutet dies eine entscheidende Veränderung der Angriffsfläche – standardmäßige Entwickler-Workflows sind nicht mehr „vorab authentifizierte“ Sicherheitszonen, sondern hochkarätige Ziele für den Einsatz staatlich geförderter Remote-Access-Trojaner (RAT).

: Wie sich die Ermittlungsarbeit ändern muss

Herkömmliche Sicherheitsmodelle basieren größtenteils auf CVE-zentrierten Risikobewertungen, bei denen der Schwerpunkt auf der Identifizierung latenter Schwachstellen im Code liegt. Diese Modelle berücksichtigen jedoch nicht die Instrumentalisierung des Verteilungskanals, bei der sich der Paketmanager von einem vertrauenswürdigen Verwaltungsdienstprogramm zu einem primären malware wandelt.

Zum Zeitpunkt der Laufzeitausführung wandelt sich der Vorfall von einem Mangel an Abhängigkeitshygiene zu einem aktiven Eingriff in den Betrieb. Wenn eine Entwickler-Workstation, ein Build-Runner oder eine Release-Pipeline eine mit einem Trojaner infizierte Version von Axios aufgenommen hat, muss der Umfang der Untersuchung unverzüglich über eine einfache Entfernung hinausgehen. Eine wirksame Bedrohungssuche nach der Ausführung muss folgende Aspekte berücksichtigen:

• Ungewöhnliche Prozessausführung: Hat der npm- oder Node-Prozess unerwartete Shell-Aktivitäten oder die Ausführung von Binärdateien (z. B. cmd.exe, /bin/sh) ausgelöst?

• C2-Beaconing: Gibt es Telemetriedaten, die auf ausgehende Verbindungen zu nicht standardmäßiger oder verdächtiger externer Infrastruktur hindeuten?

• Feststellung der Persistenz: Gab es unbefugte Änderungen an Systemstartskripten, Cron-Jobs oder Registrierungsschlüsseln?

• Heimliches Auslesen: Gab es Versuche, auf Umgebungsvariablen, Anmeldedaten oder lokale Schlüsselbunddaten zuzugreifen?

• Seitliche Bewegung: Gibt es Anzeichen für interne Erkundungsaktivitäten oder die Nutzung von Anmeldedaten, die von dem betroffenen Build-Runner ausgehen?

‍

‍

Dies ist der entscheidende Schwachpunkt moderner Erkennungssysteme: Die Kompromittierung der Lieferkette wird als isoliertes „Paketproblem“ betrachtet und nicht als etablierter Brückenkopf. Um raffinierte Angreifer abzuschrecken, müssen Verteidiger im Rahmen einer Zero Trust agieren, die jede bösartige Abhängigkeit als vollwertigen Netzwerkangriff behandelt.

‍

Wenn du immer noch nicht zuhörst

Sobald die Ausführung gelungen ist, ist der Angreifer nicht mehr auf das Paket angewiesen, sondern auf die Zugriffsmöglichkeiten innerhalb der Umgebung.

Und sollte sich die Zuschreibung an BlueNoroff bestätigen, ist die anfängliche Exfiltration von CI/CD-Geheimnissen, cloud schlüsseln und Quellcode-Repositorys lediglich der Auftakt zu einer operativen Umorientierung mit weitreichenden Folgen.

Die Kompromittierung von Anmeldedaten auf Entwicklerebene ermöglicht praktisch eine logische Umgehung der Air-Gap-Sicherheitsbarriere in der Produktionsumgebung und verwandelt eine Infektion einer lokalen Workstation in einen Angriff auf cloud . In den Händen eines staatlich geförderten Akteurs führt diese Datenexfiltration unmittelbar zu:

• Die Nutzung gestohlener Geheimnisse: Die rasche Umwandlung erbeuteter Cloud und Kubernetes-Geheimnisse in Angriffsmittel, um eine dauerhafte Präsenz mit weitreichenden Zugriffsrechten innerhalb der Infrastruktur zu etablieren.

• Sekundäre Supply Chain : Durch die Nutzung gestohlener Zertifikate zur Codesignierung oder Schreibzugriff auf Repositorys wird weiterer Schadcode in die kundenorientierten Produkte des Unternehmens eingeschleust, wodurch sich der Schaden auf die gesamte Nutzerbasis ausweitet.

• Anmeldedatenbasierte laterale Ausbreitung: Ausweitung vom Entwickler-Ökosystem auf hochsensible Produktionsdatenbanken oder Finanzsysteme. Da der Angreifer legitime, gestohlene Anmeldedaten verwendet, kann er herkömmliche signaturbasierte Sicherheitsmaßnahmen umgehen, sodass Verhaltensanalysen die einzige praktikable Methode zur Erkennung des Eindringens darstellen.

‍

So sieht der Axios-Kompromiss im Netzwerk aus

Bei einem Angriff auf die Lieferkette, wie beispielsweise dem Hackerangriff auf Axios, werden Protokolle auf Host-Ebene häufig durch „vertrauenswürdige“ Binärdateien bereinigt oder umgangen. Die „Network Truth“ bleibt die einzige unveränderliche Aufzeichnung der taktischen Absichten des Angreifers.

Die folgenden Verhaltensweisen „in Echtzeit“ entlarven den Angriff, während er sich von einer einfachen Paketinstallation zu einem schwerwiegenden Eindringen entwickelt:

• C2-Herzschlag- und Protokollanomalien: Erkennt den „Low-and-Slow“-Rhythmus von Command & Control C2), der in HTTPS verborgen ist.  

• Böswillige Staging-Phase (Outbound-Egress): Markiert den genauen Zeitpunkt, zu dem der Installationsprozess eine Payload der zweiten Stufe abruft.

• Interne Erkundung (Ost-West-Datenverkehr): Erfasst das „Rauschen“ des Angreifers, der Ihre Umgebung über das Netzwerk kartografiert, lange bevor dieser seinen ersten internen Angriff startet.

• Anomalien bei privilegierten Zugriffen: Erkennt identitätsbasierte Angriffe während der Datenübertragung. Das System deckt anomale Anfragen oder erstmalige Authentifizierungen bei Produktionssystemen auf, bei denen gestohlene Entwicklerzugangsdaten verwendet werden.

• Datenschmuggel und Tunneling: Überwacht die Exfiltration in Echtzeit. Das System erkennt das „Chunking“ von Daten innerhalb verschlüsselter Tunnel oder ungewöhnliche DNS-Abfragen, die dazu dienen, Umgebungsgeheimnisse und cloud aus dem Netzwerk zu schmuggeln.

‍

Das ist kein Problem mehr, das sich auf den Randbereich beschränkt

Der Axios-Vorfall ist mehr als nur ein Versagen der Lieferkette; er ist ein Weckruf hinsichtlich des Zusammenbruchs der traditionellen Perimeter-Sicherheit. Viel zu lange galt die Entwicklerinfrastruktur als „Sicherheitsblindfleck“ – isoliert von zentralen Erkennungsstrategien und zugleich ein leichtes Ziel für raffinierte Angreifer wie BlueNoroff.

Um staatlich geförderten Angriffsclustern einen Schritt voraus zu sein, müssen Sicherheitsverantwortliche die „Norm“ der ausschließlichen Konzentration auf die Produktionsumgebung aufgeben und eine Denkweise annehmen, die den gesamten Software-Lebenszyklus als einheitliche Angriffsfläche betrachtet.  

Die Frage lautet nicht mehr: „Ist ein schädliches Paket in unsere Umgebung gelangt?“ Die Frage lautet vielmehr: „Reicht unsere Transparenz tief genug in unser Entwickler-Ökosystem hinein, um den Eindringling abzufangen, bevor er sich unseren wertvollsten Produktionsressourcen zuwendet?“ Durch diese Umstellung der Denkweise wird eine systemische Schwachstelle in einen kontrollierten Verteidigungsvorteil verwandelt, der sicherstellt, dass kein Teil der Infrastruktur außerhalb des Schutzschirms der Netzwerkerkennung und -reaktion liegt

Wenn Ihr Team darüber nachdenkt, wie sich das Verhalten von Angreifern über das Scannen von Paketen und präventive Maßnahmen hinaus erkennen lässt, ist dies genau der richtige Ort für Vectra AI dabei helfen kann, verdächtige Aktivitäten nach einem Sicherheitsverstoß in cloud, Identitäts- und Netzwerkumgebungen aufzudecken.

‍