Was passiert, wenn die Werkzeuge, mit denen wir die nächste Generation intelligenter Software bauen wollen, selbst zum trojanischen Pferd werden? Wenn die vermeintlich produktivitätssteigernden Bibliotheken, die wir per simplen Befehl in unsere Projekte ziehen, plötzlich als Einfallstor für einen staatlich finanzierten Cyberangriff dienen? Der jüngste, massive Supply-Chain-Angriff auf die beliebten npm-Pakete des KI-Agenten-Frameworks Mastra ist keine theoretische Bedrohung mehr – er ist ein handfester Weckruf. Er zeigt in erschreckender Deutlichkeit, dass selbst hochkarätige Open-Source-Projekte mit Tausenden von Stars auf GitHub nicht vor der gezielten Infiltration durch Akteure wie die nordkoreanische Hackergruppe Sapphire Sleet gefeit sind.

Am 20. Juni 2026 berichtete BleepingComputer über eine der bislang umfangreichsten npm-Kompromittierungen des Jahres: Mehr als 140 Pakete im offiziellen @mastra-Scope wurden mit einer schädlichen Dependency verseucht. Microsoft Threat Intelligence, das die Details bereits am 17. Juni in einem Blogbeitrag offenlegte, ordnet den Angriff mit hoher Konfidenz der nordkoreanischen Gruppe Sapphire Sleet (auch bekannt als BlueNoroff) zu. Das Ziel war ein Cross-Platform-Infostealer, der sich auf Windows, Linux und macOS installierte und systematisch Credentials, API-Keys, Auth-Tokens und vor allem Krypto-Wallets aus über 160 Browser-Erweiterungen stahl.

Das Opfer: Mastra – Ein aufstrebender Stern im KI-Agenten-Himmel

Um die Tragweite des Angriffs zu verstehen, muss man das Ziel kennen. Mastra ist ein beliebtes Open-Source-Framework zum Bauen von KI-Agenten und -Workflows. Mit über 25.000 Stars auf GitHub (Stand 21.06.2026) positioniert es sich als eine der führenden Lösungen in einem schnell wachsenden Markt. Entwickler nutzen Mastra, um komplexe, multi-modale Agentensysteme zu erstellen, die Sprache, Code und Tools kombinieren können. Das Kernpaket `@mastra/core` wird unter der Apache-2.0-Lizenz veröffentlicht und erfreut sich großer Beliebtheit in der Community.

Warum Mastra ein lukratives Ziel ist

Die Attraktivität für Angreifer liegt auf mehreren Ebenen. Erstens handelt es sich um ein High-Profile-Projekt mit einer großen, aktiven Nutzerbasis – ideal, um eine breite Streuung der Malware zu erreichen. Zweitens arbeiten Entwickler, die mit KI-Agenten experimentieren oder produktive Systeme bauen, oft mit wertvollen Assets: Sie integrieren API-Keys für teure KI-Modelle (OpenAI, Anthropic, etc.), verwenden Cloud-Service-Credentials und verwalten nicht selten auch Test- oder sogar Produktionsumgebungen von einem Entwicklungsrechner aus. Drittens ist das Ökosystem rund um KI-Agenten noch relativ jung und die Sicherheitspraktiken sind oft nicht so etabliert wie in anderen Bereichen der Softwareentwicklung. Ein erfolgreicher Angriff auf ein Framework wie Mastra trifft somit eine gut betuchte und vielleicht noch etwas unvorsichtige Zielgruppe.

Der kompromittierte Maintainer-Account „ehindero“

Laut Microsoft gelang es den Angreifern, Zugriff auf den npm-Account des Maintainers mit dem Benutzernamen „ehindero“ zu erlangen. Wie genau dieser Zugriff erlangt wurde – ob durch Credential-Phishing, eine Kompromittierung des E-Mail-Accounts oder die Ausnutzung einer Schwachstelle – ist noch nicht vollständig öffentlich bekannt. Dieser Zugriff war der Schlüssel zum Königreich: Mit den Maintainer-Rechten konnten die Angreifer neue, bösartige Versionen der legitimen Mastra-Pakete publizieren, die von ahnungslosen Entwicklern dann via `npm install` oder durch automatische Update-Prozesse heruntergeladen wurden. Dieser Vorfall unterstreicht erneut die kritische Bedeutung der Sicherung von Maintainer-Accounts in Open-Source-Ökosystemen, ein Thema, das wir bereits im Kontext des Red Hat npm-Angriffs vertieft haben.

Die Angriffsmethodik: Typosquatting, Post-Install-Hooks und Cross-Platform-Malware

Der Angriff war handwerklich hochwertig und mehrschichtig aufgebaut. Er nutzte eine Kombination aus sozialem Engineering (Typosquatting), der Funktionsweise von Paketmanagern (Post-Install-Skripte) und komplexer, plattformübergreifender Malware.

Der Köder: „easy-day-js“ – Typosquatting von „dayjs“

Das Herzstück der schädlichen Payload war eine Dependency namens „easy-day-js“. Bei diesem Paket handelt es sich um ein klassisches Typosquatting: Es imitiert die äußerst populäre JavaScript-Bibliothek „dayjs“ zur Datumsmanipulation. Ein übermüdeter oder unaufmerksamer Entwickler, der „dayjs“ tippen möchte, könnte leicht „day-js“ oder ähnliches schreiben – und genau hier setzt der Angreifer an. Die kompromittierten Mastra-Pakete fügten „easy-day-js“ als Abhängigkeit ein. Bei der Installation wurde dieses Paket dann automatisch mitgeladen.

Der Auslöser: Der postinstall-Hook

Die eigentliche Malware-Aktivierung erfolgte über den `postinstall`-Hook in der `package.json` des schädlichen „easy-day-js“-Pakets. Post-Install-Skripte werden von npm automatisch ausgeführt, nachdem ein Paket installiert wurde. Dies ist ein legitimer Mechanismus, um z.B. Build-Schritte durchzuführen, wird hier aber missbraucht, um sofort nach der Installation einen schädlichen Payload herunterzuladen und auszuführen. Dieser Mechanismus umgeht geschickt einfache statische Code-Analysen, da die bösartige Logik erst beim Installationsvorgang vom Netzwerk geholt wird.

Die Payload: Ein plattformübergreifender Infostealer

Der heruntergeladene Payload war ein Infostealer, der speziell für Windows, Linux und macOS kompiliert wurde. Seine Hauptaufgabe: Die systematische Erbeutung von digitalen Werten. Die Malware durchsuchte das System nach:

• Browser-Daten: Cookies, Verlauf, gespeicherte Passwörter und Login-Daten.
• Krypto-Wallets: Ein besonderer Fokus lag auf Browser-Erweiterungen für Kryptowährungen. Insgesamt 166 Erweiterungen wurden gezielt angesprochen, darunter Schwergewichte wie MetaMask, Phantom, Coinbase Wallet, Binance Wallet und TronLink. Die Malware suchte nach Seed-Phrases, privaten Schlüsseln und Wallet-Dateien.
• Credentials & Tokens: Dateien wie `~/.aws/credentials`, `~/.ssh/id_rsa`, Environment-Variablen und Konfigurationsdateien, die API-Keys oder Zugangstokens enthalten könnten.
• Systeminformationen: Zur Profilerstellung und möglichen weiteren Angriffsplanung.

Technische Tiefenbohrung: Persistenz, Verschleierung und C2

Sapphire Sleet ging über einen einfachen Stealer hinaus und implementierte ausgefeilte Mechanismen für Persistenz und Verschleierung, die auf einen längerfristigen Zugriff und die Umgehung von Sicherheitssoftware hindeuten.

Plattformspezifische Persistenzmechanismen

Um einen Neustart des Systems zu überleben, etablierte die Malware je nach Betriebssystem unterschiedliche Autostart-Methoden:

Fortgeschrittene Verschleierungstaktiken

Die Angreifer zeigten ein tiefes Verständnis der Windows-Sicherheitslandschaft:

• PowerShell-Backdoor: Neben dem Hauptstealer wurde eine PowerShell-basierte Backdoor installiert, die eine flexible, skriptbasierte Fernsteuerung des kompromittierten Systems ermöglichte.
• Microsoft Defender-Ausschlüsse: Die Malware manipulierte proaktiv die Windows Defender-Einstellungen, um ihre eigenen Dateien und Prozesse von der Überwachung und Scans auszuschließen – eine Taktik, die Administratorrechte voraussetzt oder durch eine Schwachstelle erlangt.
• Bösartiger Windows-Dienst mit SYSTEM-Rechten: Auf einigen Systemen wurde ein Windows-Dienst installiert, der mit den höchsten verfügbaren SYSTEM-Rechten lief. Dies ermöglichte nicht nur tiefgreifenden Zugriff auf das System, sondern auch die Manipulation von Sicherheitssoftware und das Verstecken von Aktivitäten.
• C2-Kommunikation: Die gestohlenen Daten wurden an Command-and-Control-Server (C2) von Sapphire Sleet exfiltriert. Die Kommunikation war vermutlich verschleiert, um Netzwerküberwachung zu umgehen.

Der Täter: Sapphire Sleet – Nordkoreas digitales Finanzkommando

Die Zuordnung durch Microsoft zu Sapphire Sleet (auch bekannt als BlueNoroff, eine Untergruppe der berüchtigten Lazarus Group) ist hochsignifikant. Es handelt sich hier nicht um Cyberkriminelle, die aus finanzieller Gier handeln, sondern um einen staatlichen Akteur der Demokratischen Volksrepublik Korea (Nordkorea).

Das operative Profil: Finanzbeschaffung für das Regime

Sapphire Sleet ist spezialisiert auf die Beschaffung von Finanzmitteln durch Cyberangriffe. Ihre Taktiken sind vielfältig und ausgefeilt:

• Krypto-Diebstahl: Direkte Angriffe auf Kryptobörsen, Wallet-Anbieter und individuelle Wallet-Besitzer. Der Diebstahl von Kryptowährungen ist eine Hauptquelle für Devisenbeschaffung für das isolierte Regime.
• Fake-Job-Angebote: Die Gruppe stellt sich als Tech-Recruiter oder Arbeitgeber dar und lockt Opfer (oft Entwickler) in gefälschte Bewerbungsprozesse, bei denen sie schädliche Code-Proben oder „Test-Tools“ ausführen sollen, die in Wirklichkeit Malware sind.
• Bösartige Browser-Extensions: Sapphire Sleet hat in der Vergangenheit gefälschte Browser-Erweiterungen verbreitet, die ebenfalls auf das Stehlen von Krypto-Wallet-Daten abzielten.
• Software Supply-Chain-Angriffe: Der Angriff auf Mastra reiht sich ein in eine Serie ähnlicher Aktionen. Microsoft erwähnt einen separaten npm-Angriff auf die beliebte HTTP-Client-Bibliothek Axios im April 2026. Dies zeigt eine klare Strategie: die Infiltration populärer Open-Source-Pakete, um Zugang zu einer großen Anzahl von Entwickler-Systemen zu erhalten.

Der Fokus auf Krypto-Wallets in diesem Angriff passt perfekt zu diesem Profil. Jedes kompromittierte Entwicklersystem mit einer verbundenen MetaMask-Erweiterung wurde zur potenziellen Geldquelle für das nordkoreanische Regime.

Lessons Learned und Schutzmaßnahmen für Entwickler und Unternehmen

Der Mastra-Angriff ist ein Lehrbuchbeispiel für moderne Supply-Chain-Bedrohungen. Er verdeutlicht, dass die Sicherheit unserer Software nicht erst im eigenen Code beginnt, sondern bei den hunderten Abhängigkeiten, die wir vertrauensvoll einbinden. Hier sind konkrete Schritte zur Risikominderung.

Für Entwickler: Praktische Hygiene im Paketmanagement

1. Scannen von Dependencies: Nutzen Sie Tools wie `npm audit`, `yarn audit` oder integrierte Scans in IDEs und CI/CD-Pipelines. Erwägen Sie erweiterte Sicherheitsscanner, die auch auf Typosquatting und verdächtige `postinstall`-Skripte prüfen.
2. Skeptisch gegenüber Post-Install-Skripten: Prüfen Sie die `package.json` von Abhängigkeiten, besonders von unbekannten Paketen. Ein `postinstall`-Skript, das Netzwerkkommunikation initiiert, ist ein riesiges Red Flag.
3. Lockfiles und Versions-Pinning: Verwenden Sie `package-lock.json` oder `yarn.lock` konsequent und pinnen Sie Dependency-Versionen mit exakten Versionsnummern (`~` oder `^` mit Vorsicht). Dies verhindert das automatische Einspielen neuer, potenziell kompromittierter Minor- oder Patch-Releases.
4. Multi-Faktor-Authentifizierung (MFA): Aktivieren Sie MFA für alle Konten, die mit Software-Entwicklung zu tun haben: npm, GitHub, GitLab, Cloud-Anbieter. Dies hätte den Kompromittierungsweg über gestohlene Credentials für „ehindero“ möglicherweise verhindert.

Für Unternehmen: Strukturelle Absicherung der Supply Chain

1. Software Bill of Materials (SBOM): Führen Sie eine detaillierte Inventarliste aller verwendeten Software-Komponenten und ihrer Abhängigkeiten. Im Falle eines Angriffs wie diesem wissen Sie sofort, ob und welche Mastra-Versionen Sie verwenden.
2. Private Package-Registries: Betreiben Sie ein firmeninternes npm-Registry (z.B. mit Verdaccio oder Azure Artifacts). Darin können Sie geprüfte, gescannte Versionen von öffentlichen Paketen spiegeln und die direkte Installation aus dem öffentlichen npm-Registry unterbinden.
3. CI/CD-Sicherheit: Integrieren Sie Sicherheitsscans (SAST, SCA) direkt in Ihre Build-Pipeline. Bauen und Testen Sie in isolierten, ephemeren Containern. Die Gefahr durch kompromittierte Build-Pipelines haben wir bereits im Artikel über den Red Hat npm-Angriff beleuchtet.
4. Least-Privilege-Prinzip auf Entwicklerworkstations: Entwickler sollten nicht mit administrativen Rechten auf ihren lokalen Maschinen arbeiten. Dies erschwert es Malware wie der in diesem Fall beschriebenen, persistente Windows-Dienste mit SYSTEM-Rechten zu installieren oder Defender-Ausschlüsse zu setzen.
5. Spezielle Vorsicht bei KI-Projekten: Teams, die mit Frameworks wie Mastra, LangChain oder anderen KI-Agenten-Tools arbeiten, sollten besonders sensibilisiert werden. Diese Projekte sind neu, populär und arbeiten mit hochwertigen Assets – ein perfektes Ziel. Die Sicherheitsherausforderungen von KI-Agenten gehen über Supply-Chain-Risiken hinaus, wie unser Deep-Dive zum Thema RCE in Autogen-Agenten zeigt.

Die größeren Implikationen: KI-Ökosysteme im Fadenkreuz

Der Angriff auf Mastra ist kein isolierter Vorfall, sondern signalisiert einen gefährlichen Trend. Staatliche Akteure haben das explosive Wachstum und das immense wirtschaftliche Potenzial der KI-Branche erkannt. Das Targeting von Frameworks und Tools in diesem Bereich wird zunehmen.

Supply Chain als Angriffsvektor der Wahl

Der direkte Angriff auf Anwendungen ist oft aufwändig und von begrenzter Reichweite. Die Infiltration einer einzigen, weit verbreiteten Open-Source-Bibliothek hingegen bietet ein enormes Hebelverhältnis. Ein erfolgreicher Commit in ein solches Projekt kann Tausende von Unternehmen und Hunderttausende von Entwicklern gleichzeitig treffen. Dieses Skalierungspotenzial macht Supply-Chain-Angriffe für Gruppen wie Sapphire Sleet so attraktiv.

Das Problem der Maintainer-Sicherheit

Der Fall „ehindero“ wirft ein grelles Licht auf die menschliche Schwachstelle in der Open-Source-Welt. Maintainer sind oft Einzelpersonen oder kleine Teams mit begrenzten Ressourcen. Sie werden zur kritischen Infrastruktur für Teile des globalen Internets, ohne zwangsläufig die Sicherheitsunterstützung oder das Training einer großen Firma zu haben. Phishing-Angriffe, wie sie häufig bei Credential-Stuffing-Angriffen eingesetzt werden, zielen genau auf diese Personen ab.

Die Zukunft: Sicherheit im Model Context Protocol (MCP) und Agenten-Ökosystem

Frameworks wie Mastra sind nur der Anfang. Die nächste Generation von KI-Systemen interagiert über Protokolle wie das Model Context Protocol (MCP) dynamisch mit Tools, Servern und Datenquellen. Jede dieser Schnittstellen ist ein potenzieller Angriffsvektor. Die Sicherheit von KI-Agenten wird nicht nur die Integrität ihres eigenen Codes, sondern auch die Sicherheit aller verbundenen Tools und die Vertrauenswürdigkeit der von ihnen verarbeiteten Daten umfassen müssen.

Fazit: Der Supply-Chain-Angriff auf Mastra ist eine makellose Demonstration moderner Cyberkriegsführung im digitalen Zeitalter. Ein staatlicher Akteur nutzt die Offenheit und das Vertrauen des Open-Source-Ökosystems, um über eine einzige kompromittierte Dependency Zugang zu wertvollen finanziellen Ressourcen auf Tausenden von Systemen weltweit zu erlangen. Für Entwickler und Unternehmen ist die Botschaft eindeutig: Naives Vertrauen in öffentliche Paketregistries ist ein nicht mehr zu verantwortendes Risiko. Eine rigorose Dependency-Überprüfung, die Einführung von Sicherheits-Governance in CI/CD-Pipelines und ein gesteigertes Bewusstsein für die Verwundbarkeit von Maintainer-Accounts sind keine optionalen Maßnahmen mehr – sie sind essentiell für die Überlebensfähigkeit in einer Landschaft, in der die nächste kritische Dependency bereits zum Ziel staatlicher Hacker geworden sein könnte.

Der Angriff zeigt zudem, dass KI-Frameworks längst keine Nischenprodukte mehr sind, sondern kritische Infrastruktur. Wer heute Agenten-Systeme baut, muss Supply-Chain-Sicherheit als elementaren Baustein der Architektur verstehen – nicht als nachträglichen Checklistenpunkt.