Im offiziellen npm-Registry sind 36 malizioese Pakete entdeckt worden, die sich gezielt als Plugins für die Headless-CMS-Plattform Strapi ausgeben. Die Pakete wurden genutzt, um Redis- und PostgreSQL-Instanzen auszunutzen, eine reverse shell zu etablieren, Zugangsdaten zu stehlen und einen persistenten Implantat-Zugang in kompromittierten Systemen zu verankern. Der Vorfall unterstreicht erneut, wie Software-Supply-Chain-Angriffe Entwicklungsumgebungen in Verteilkanäle für Schadcode verwandeln.
Malizioese npm-Pakete tarnen sich als Strapi-Plugins
Nach Erkenntnissen von SafeDep folgten sämtliche Pakete einem nahezu identischen Aufbau: Sie bestanden lediglich aus package.json, index.js und postinstall.js. Es fehlten aussagekräftige Beschreibungen, Repository-Links oder Projekt-Webseiten, während die Version konsequent auf 3.6.8 gesetzt war – mutmaßlich, um einen etablierten Community-Plugin-Status für Strapi v3 zu simulieren.
Die Namen der Pakete begannen stets mit „strapi-plugin-„, gefolgt von generischen Begriffen wie „cron“, „database“ oder „server“. Dieses Namensschema soll den Eindruck regulärer Strapi-Erweiterungen erwecken und Entwickler täuschen, die solche Benennungen aus dem Ökosystem kennen. Entscheidend ist: offizielle Strapi-Plugins werden ausschließlich im Namespace @strapi/ veröffentlicht – ein wichtiges Unterscheidungsmerkmal gegenüber inoffiziellen und potenziell schädlichen Paketen.
Innerhalb eines Fensters von rund 13 Stunden wurden die 36 Pakete unter Verwendung von vier neu angelegten npm-Konten veröffentlicht. Diese Konten – darunter etwa „umarbek1233“ und „kekylf12“ – deuten auf Wegwerf-Accounts hin, wie sie typischerweise in kurzlebigen Kampagnen genutzt werden, die möglichst viele Systeme erreichen sollen, bevor Schutzmechanismen greifen.
Technische Analyse: postinstall-Skripte, Datenbankzugriffe und Implantate
Missbrauch von npm-Lifecycle-Skripten zur verdeckten Codeausfuehrung
Die zentrale Schadlogik war im postinstall-Skript verankert, das automatisch beim Ausführen von „npm install“ gestartet wird. Solche Skripte laufen ohne weiteres Zutun des Nutzers und mit denselben Rechten wie der aufrufende Account. In CI/CD-Pipelines, Docker-Containern oder Installationen mit Root-Rechten eröffnet dies Angreifern weitreichende Privilegien bis hin zur vollständigen Systemübernahme.
Diese Technik verdeutlicht ein strukturelles Risiko des npm-Ökosystems: Jedes Paket mit Lifecycle-Skripten kann zur Ausführung beliebigen Codes bei der Installation verwendet werden. In der Praxis wird damit die Software-Lieferkette selbst zum Angriffsvektor – ein Muster, das sich in den vergangenen Jahren in zahlreichen Supply-Chain-Vorfällen beobachten lässt.
Mehrstufige Angriffstaktik: von RCE bis zu persistenter Kompromittierung
SafeDep beschreibt insgesamt acht Varianten der eingesetzten Payloads, die eine klare Weiterentwicklung der Taktik erkennen lassen. In der Anfangsphase standen aggressive Exploits im Vordergrund, insbesondere Remote Code Execution (RCE) über Redis sowie Versuche, mithilfe von Docker-Escape-Techniken vom Container auf den Host zu springen.
Als sich diese direkten Angriffsversuche offenbar als begrenzt wirksam erwiesen, verlagerte der Akteur den Fokus auf Aufklärung und Umgebungsanalyse. Der Schadcode inventarisierte Systemeigenschaften, Konfigurationsdateien und Netzwerkumgebungen, um lohnende Ziele und Angriffswege zu identifizieren.
In einem weiteren Schritt nutzte der Angreifer hart codierte Zugangsdaten und Hostnamen für PostgreSQL, um Datenbanken direkt anzusprechen – vorbei an der eigentlichen Anwendungsschicht. Dies ermöglichte unter anderem den Zugriff auf sensible Geschäftsdaten und potenziell auch auf kryptografische Schlüssel oder Wallet-Informationen.
Die finalen Payload-Varianten konzentrierten sich auf Persistenz und Datendiebstahl. Dazu gehörten die Installation eines permanenten Implantats, das Nachladen zusätzlichen Schadcodes sowie das Einrichten einer reverse shell zur interaktiven Fernsteuerung des Systems. Der gezielte Fokus auf Datenbanken, digitale Assets und Zugangsdaten legt nahe, dass sich die Kampagne wahrscheinlich gegen eine Kryptoplattform oder einen FinTech-Dienst richtete.
Supply-Chain-Angriffe auf Open Source als strategischer Trend
Der Missbrauch vermeintlicher Strapi-Plugins reiht sich ein in eine Serie zunehmender Supply-Chain-Angriffe auf Open-Source-Ökosysteme. Laut einem aktuellen Bericht von Group-IB haben Angriffe auf die Software-Lieferkette sich zu einer dominierenden Bedrohung entwickelt, weil Angreifer so vererbten Zugriff auf zahlreiche Organisationen über deren vertrauenswürdige Dienstleister und Abhängigkeiten erlangen.
Öffentliche Paket-Repositorien wie npm und PyPI stehen dabei im Fokus. Angreifer nutzen gestohlene Maintainer-Zugänge, automatisierte Tools für Massenkompromittierungen und gezielte Code-Injektionen in Build-Prozesse. Kompromittierte CI/CD-Pipelines fungieren anschließend als leistungsfähige Distributionskanäle für Schadsoftware, die sich über ganze Infrastrukturen und Kundenlandschaften ausbreiten kann.
Empfehlungen: So schuetzen Unternehmen ihre Software-Lieferkette
Organisationen, die eines der identifizierten Pakete installiert haben, sollten zunächst von einer vollständigen Kompromittierung des betroffenen Systems ausgehen. Unmittelbare Maßnahmen umfassen das Zurücksetzen sämtlicher Zugangsdaten (inklusive Datenbank-Accounts, API-Schlüssel, CI/CD-Secrets), die detaillierte Auswertung von Logdaten auf verdächtige Aktivitäten sowie die Neuinstallation kritischer Services aus verifizierten, vertrauenswürdigen Images.
Zur nachhaltigen Reduzierung des Risikos von Supply-Chain-Angriffen sind mehrere technische und organisatorische Kontrollen ratsam. Dazu zählt eine strikte Validierung von Abhängigkeiten: Für Strapi sollten ausschließlich Pakete im Namespace @strapi/ eingesetzt werden; daneben sind Reputation (Downloads, Sterne), changelog, Quellcode-Transparenz und aktives Maintainer-Ökosystem wesentliche Prüfkriterien. Pakete ohne klare Herkunft oder Dokumentation sollten gemieden werden.
Ebenso wichtig ist der kontrollierte Umgang mit Lifecycle-Skripten. In sensiblen Build- oder Produktionsumgebungen empfiehlt es sich, Installationsskripte standardmäßig zu blockieren, etwa mit „npm install –ignore-scripts“, und nur sorgfältig geprüften Paketen die Ausführung zu gestatten. Ergänzend sollten Unternehmen Software Composition Analysis (SCA)-Werkzeuge, interne Spiegel-Repositorien und Allow-/Deny-Listen für kritische Bibliotheken nutzen.
Ein weiterer Schwerpunkt liegt auf der Härtung von CI/CD- und Container-Umgebungen. Dazu gehören der Verzicht auf Root-Rechte in Containern, eine strikte Segmentierung von Zugriffsrechten in Pipelines, die regelmäßige Rotation von Secrets in Orchestrierungsplattformen sowie kontinuierliche Überwachung auf Anomalien im Build-Prozess.
Die aktuelle Kampagne gegen Strapi-Entwicklungsumgebungen macht deutlich, dass jeder Schritt in der Software-Entwicklung – von der Abhängigkeitsauswahl bis zum Deployment – als potenzielle Angriffsfläche betrachtet werden muss. Wer npm und andere Open-Source-Ökosysteme einsetzt, sollte die Auswahl und Überwachung von Dependencies mit derselben Konsequenz betreiben wie den Schutz produktiver Systeme. Unternehmen, die jetzt in transparente Prozesse, automatisierte Sicherheitsprüfungen und eine robuste Software-Lieferkettensicherheit investieren, reduzieren nicht nur ihr unmittelbares Risiko, sondern stärken langfristig die Resilienz ihrer gesamten digitalen Infrastruktur.
