Fast 800 bösartige npm-Pakete verteilen RAT und Infostealer auf Windows, macOS und Linux

Kurzfassung

Im npm-Ökosystem tauchen fast 800 bösartige Pakete auf, die eine plattformübergreifende Schadsoftware nachladen. Betroffen sind Windows-, macOS- und Linux-Systeme gleichermaßen. Für Unternehmen mit JavaScript- oder Node.js-Abhängigkeiten ist das kein Randthema. Wer Pakete automatisiert aus öffentlichen Repositories zieht, muss die Supply-Chain jetzt enger kontrollieren.

Was ist passiert?

Die Angreifer haben eine große Zahl schädlicher npm-Pakete veröffentlicht. Laut Quelle nutzen sie dabei offenbar zufällig wirkende oder an echte Paketnamen angelehnte Typo-Squatting-Namen, um Entwickler und CI-Pipelines zum Installieren zu bringen. Nach der Installation liefern die Pakete eine Kombination aus Remote-Access-Trojaner und Infostealer aus.

Das Muster ist alt, die Größenordnung ist es nicht. Fast 800 Pakete auf einmal erhöhen die Chance, dass einzelne Treffer in internen Build-Umgebungen oder auf Entwicklerrechnern landen. Wer in DACH Software aus öffentlichen NPM-Quellen bezieht, sollte vor allem automatisierte Installationen und Lockfile-Änderungen prüfen.

Vorgehen und Werkzeuge

Die Kampagne setzt auf Paket-Täuschung statt auf einen klassischen Exploit. Der Köder liegt im Namen des Pakets. Nach dem Einspielen folgt die eigentliche Nutzlast: ein RAT für Fernzugriff und ein Infostealer zum Abgreifen von Zugangsdaten, Tokens oder anderen lokal gespeicherten Informationen.

Aus dem Auszug geht hervor, dass die Malware auf Windows, Mac und Linux ausgelegt ist. Welche konkreten Befehls- und Kontrollmechanismen, Persistenzmethoden oder Exfiltrationswege genutzt werden, nennt die Quelle nicht. Auch unklar bleibt, ob die Pakete noch aktiv im Registry-Ökosystem kursieren oder bereits entfernt wurden.

Wer ist betroffen?

Direkt betroffen sind Entwickler, DevOps-Teams und alle Organisationen, die npm-Pakete automatisiert in Build- oder Deployment-Prozesse einbinden. Im DACH-Raum trifft das vor allem Softwarehäuser, Agenturen, Start-ups und interne Plattformteams. Auch kleinere Teams geraten schnell in Reichweite, wenn sie Dependencies ohne Freigabeprüfung aktualisieren.

Privatanwender sind nur dann relevant betroffen, wenn sie selbst npm-basierte Werkzeuge installieren oder unsauber gepflegte Projekte auf dem Rechner ausführen. Der eigentliche Schadenshebel liegt aber klar in Unternehmensumgebungen: dort können gestohlene Tokens und Zugangsdaten direkt in Source-Repositories, Cloud-Konten oder Admin-Oberflächen führen.

Empfohlene Maßnahmen

Prüfen Sie zunächst die eigene Dependency-Kette. Ungeprüfte npm-Installationen gehören nicht auf Entwickler- oder Build-Systeme. Paketnamen mit kleinen Abweichungen zum Original sollten Sie konsequent als verdächtig behandeln.

Auf Admin-Seite hilft ein harter Blick auf die Supply Chain: nur freigegebene Registries verwenden, Lockfiles erzwingen, neue oder selten genutzte Pakete manuell reviewen und Build-Runner ohne dauerhafte Geheimnisse betreiben. Wer SSO-, Cloud- oder Git-Zugänge über Tokens absichert, sollte diese Tokens regelmäßig rotieren und auf Missbrauchssignale prüfen.

Zusätzlich sinnvoll: Egress-Filtering für Build-Umgebungen, zentrale Protokollierung von Paketinstallationen und ein schneller Abgleich mit IOC-Listen, sobald derartige Daten vorliegen. Fehlen solche Listen, bleibt nur die saubere Basishygiene. Das ist mühsam, aber wirksam.

Einschätzung von CyberSecurity-News.de

Der Fall zeigt erneut, wie leicht sich offene Paketökosysteme missbrauchen lassen. Fast 800 bösartige Pakete sind kein Zufallstreffer, sondern ein Massenangriff auf Vertrauen in die Lieferkette. Für Unternehmen mit JavaScript-Stack ist das praktisch relevant, für alle anderen eher ein Warnsignal als eine akute Bedrohung.

Die Informationslage ist allerdings noch dünn. Die Quelle nennt die Größenordnung und die Payload, lässt aber viele operative Details offen. Genau das ist das Problem: Ohne saubere Transparenz von Registry-Betreibern und Sicherheitsforschern bleibt die Reaktion vieler Teams zu spät und zu reaktiv.

Fazit

Wer npm produktiv nutzt, sollte diese Kampagne ernst nehmen. Nicht wegen eines spektakulären Exploits, sondern weil Angreifer hier direkt an der Software-Lieferkette ansetzen. Die beste Gegenwehr ist unspektakulär: Freigaben, Prüfungen, saubere Token-Hygiene und ein wacher Blick auf Paketnamen.