Supply Chain unter Beschuss: 36 fake Strapi-Plugins und die Systematik des Vertrauens

Die kompromisslose Bequemlichkeit moderner Entwicklungsumgebungen – ein kurzes npm install und das Problem ist gelöst – ist gleichzeitig ihre größte Schwachstelle. Aktuell demonstriert eine Welle von Supply-Chain-Angriffen eindrucksvoll, wie Angreifer dieses Vertrauensparadigma systematisch aushebeln. Ein besonders ausgeklügeltes Beispiel haben Forscher von SafeDep aufgedeckt: 36 malicious npm Packages, die sich als Strapi-CMS-Plugins tarnen, zeigen die taktische Evolution eines Angreifers von der breit angelegten RCE bis zum gezielten Krypto-Diebstahl.

Die Anatomie eines getarnten Angriffs

Die entdeckten Pakete folgen einem einfachen, aber effektiven Muster: Sie nutzen das Naming-Convention-Prinzip. Alle starten mit strapi-plugin-, gefolgt von branchenüblichen Begriffen wie cron, database oder server. Offizielle Strapi-Plugins nutzen jedoch den Scoped-Package-Namen @strapi/. Ein Detail, das im Entwickleralltag schnell übersehen wird. Hinzu kommt ein weiterer psychologischer Trick: Die Pakete tragen die Versionsnummer 3.6.8, um den Anschein eines gereiften, etablierten Community-Plugins für Strapi v3 zu erwecken. Beschreibungen, Repositories oder Homepages fehlen komplett – ein rotes Tuch für geübte Augen, aber oft übersehen in der Eile des Projektalltags.

Hochgeladen von vier Sock-Puppet-Accounts innerhalb von nur 13 Stunden, entfaltet sich die eigentliche Malware über den postinstall-Hook. Dieser Mechanismus wird bei der Installation automatisch mit den Rechten des ausführenden Nutzers ausgeführt. In CI/CD-Pipelines oder Docker-Containern bedeutet das oft: direkter Root-Zugriff.

Die Lernkurve des Angreifers

Das Faszinierendste an diesem Campaign ist die dokumentierte Evolution der Payloads. SafeDep identifizierte acht verschiedene Stufen, die einen klaren Erkenntnisgewinn des Angreifers widerspiegeln:

1. Der laute Einstieg: Zunächst wurde versucht, lokale Redis-Instanzen für Remote Code Execution (RCE) zu missbrauchen und über Crontab eine Reverse Shell sowie eine PHP-Webshell zu laden. Gleichzeitig wurde versucht, Docker-Container zu escapen.
2. Der Pivot zur Reconnaissance: Als die lauten Angriffe nicht den gewünschten Erfolg brachten, wechselte der Angreifer die Taktik. Das System wurde nach Environment-Variablen, PostgreSQL-Connection-Strings und Krypto-Wallet-Seeds gescannt.
3. Gezielte Datenextraktion: Mit hartcodierten Credentials griff der Angreifer direkt auf PostgreSQL-Datenbanken zu, suchte nach Strapi-Konfigurationen und dumpte gezielt Tabellen mit Referenzen zu Krypto-Transaktionen. Besonders brisant: Der Code versuchte, sich mit sechs spezifischen Guardarian-Datenbanken zu verbinden. Das deutet darauf hin, dass der Angreifer bereits im Vorfeld Informationen über das Ziel besaß.
4. Persistenz: Die Endstufe war ein gezielter Implant, der Remote-Zugriff auf den Hostnamen prod-strapi sicherstellte, kombiniert mit hartcodierten Pfaden für Credential-Scans.

Die Narrative ist eindeutig: Ein gezielter Angriff auf eine Krypto-Plattform, der sich von breit angelegten RCE-Versuchen zu präziser Datenextraktion und Persistenz entwickelte. Wer diese Pakete installiert hat, muss von einer vollständigen Kompromittierung ausgehen und alle Credentials rotieren.

Das Ökosystem brennt

Dieser Vorfall ist leider kein Einzelfall, sondern Teil eines industrialisierten Trends. Die Grenzen zwischen einzelnen Angriffsvektoren verschwimmen zunehmend:

• Account-Takeovers & CI/CD-Manipulation: Ein kompromittierter GitHub-Account (ezmtebo) flutete Open-Source-Repos mit Pull Requests, die CI/CD-Secrets über Logs und temporäre Workflows exfiltrierten. Ähnlich erging es der xygeni-action GitHub Action, wo gestohlene Maintainer-Zugangsdaten einen Reverse-Shell-Backdoor pflanzten. Sogar das Emacs-Package kubernetes-el wurde via Pwn-Request-Lücke (pull_request_target) gekapert, um Repos zu löschen und CI/CD-Secrets zu stehlen.
• Typosquatting im Krypto-Umfeld: Die gekaperte dev-protocol Organisation verteilte Malware über typosquatted Dependencies wie ts-bign, die Private Keys stahlen und SSH-Backdoors öffneten. Auf PyPI tarnte sich pyronut als beliebtes pyrogram-Framework und installierte eine unsichtbare Backdoor, die es Angreifern ermöglichte, über Telegram-Befehle beliebigen Code auf dem Host auszuführen. Auch bittensor-wallet wurde kompromittiert, um Wallet-Keys über DNS-Tunneling und Domain Generation Algorithms (DGA) zu exfiltrieren.
• Der Feind im IDE-Plugin: Besonders heimtückisch sind schlafende VS-Code-Extensions. Drei scheinbar tote solidity-Extensions von IoliteLabs wurden nach acht Jahren (März 2026) plötzlich mit einem Multi-Stage-Backdoor-Update versehen. Die Extension fast-draft geht noch weiter: Hier wechseln sich laut Aikido cleane und malicious Releases ab – ein Hinweis auf zwei konkurrierende Akteure, die sich eine Publisher-Identität teilen.

Die Systematik des Vertrauens

Group-IB stellte bereits im Februar 2026 fest: Supply-Chain-Angriffe sind zur dominierenden Kraft in der Cybedrohlandschaft geworden. Die Logik der Angreifer ist so einfach wie fatal: Anstatt hartnäckig die Firewall eines Unternehmens anzugreifen, kapert man das Vertrauen in etablierte Open-Source-Pakete und erbt so automatisch den Zugriff auf Hunderte Downstream-Organisationen. Paketmanager wie npm und PyPI sind zu perfekten Verteilungsnetzen für Malware mutiert.

Die Konsequenz für Entwickler und DevOps-Teams ist unangenehm: Blindes Vertrauen ist kein Option mehr. npm install ist ein privilegierter Vorgang, der Security-Gates durchlaufen muss. Das Fehlen von Metadaten, das Vorhandensein von postinstall-Scripts und die Namenskonventionen von Paketen müssen automatisiert geprüft werden. Zudem ist das Prinzip der minimalen Rechte – etwa das Vermeiden von Root-Rechten in Docker-Containern bei der Installation – nicht nur Best Practice, sondern überlebensnotwendig. Die Angreifer haben die Lernkurve absolviert; jetzt sind wir an der Reihe.

Quelle: The Hacker News