Remote-Access-Trojaner in npm Paket.

Remote-Access-Trojaner in npm-Paket entdeckt: Hintergründe, Schutz und Lehren

tiny-tool.de

Im Mai 2025 wurde bekannt, dass das beliebte npm-Paket rand-user-agent mit einem gefährlichen Schadcode infiziert war. Die Nachricht traf die Entwickler-Community hart: 45.000 wöchentliche Downloads zählte das Paket zum Zeitpunkt der Entdeckung. Doch was ist genau passiert? Was bedeutet das für andere Paketmanager – und wie kann man sich schützen?

Was sind Paketmanager?

Paketmanager sind Werkzeuge, die in der Softwareentwicklung den Alltag erleichtern: Sie helfen dabei, externe Bibliotheken und Tools bequem in ein Projekt einzubinden – ohne manuelles Herunterladen oder Konfigurieren. Beispiele gefällig?

npm für JavaScript und Node.js – mit über zwei Millionen Paketen.
pip für Python – unverzichtbar für Data Science und Machine Learning.
RubyGems für Ruby – perfekt für Rails-Projekte.
APT für Debian/Ubuntu – zum Installieren von Systemsoftware.
Homebrew für macOS – für Tools und kleine Programme.

Die zentrale Rolle von Paketmanagern macht sie leider auch zum beliebten Angriffsziel – wie der aktuelle Fall eindrücklich zeigt. BleepingComputer

npm: Das Herzstück des JavaScript-Ökosystems

npm ist der Standard-Paketmanager für Node.js. In Projekten wird er über die Datei package.json gesteuert – ein npm install genügt, um alle Abhängigkeiten zu installieren. Genau diese Einfachheit macht npm auch verwundbar: Jeder kann Pakete veröffentlichen – inklusive Angreifer. Besonders beliebte Pakete wie rand-user-agent mit zehntausenden wöchentlichen Downloads sind attraktive Ziele. SecurityWeek

Was ist bei `rand-user-agent` passiert?

Das Paket rand-user-agent wird häufig im Web-Scraping verwendet und erzeugt zufällige User-Agent-Strings. Obwohl offiziell als „veraltet“ markiert, blieb es weiterhin beliebt. Am 5. Mai 2025 entdeckte Aikido Security in den Versionen 1.0.110, 2.0.83 und 2.0.84 schadhaften Code – clever versteckt und obfuskiert.

Der Code baute eine versteckte Verbindung zu einem fremden Server auf, ermöglichte den Fernzugriff auf das System, das Ausführen von Shell-Befehlen und das Exfiltrieren von Systeminformationen und Dateien. Besonders perfide: Die Malware installierte zusätzliche Abhängigkeiten im Hintergrund und tarnte sich auf Windows-Systemen als scheinbar legitimer Python-Ordner.

Ermöglicht wurde das Ganze durch einen kompromittierten Zugangsschlüssel eines Entwicklers – ohne Zwei-Faktor-Authentifizierung. Der Angreifer konnte damit direkt neue Paketversionen bei npm veröffentlichen, ohne dass Änderungen im Quellcode auf GitHub erkennbar waren.

Warum ist das so gefährlich?

Solche Supply-Chain-Angriffe brauchen keine aktive Aktion des Opfers. Ein einfacher npm install reicht – z. B. in einer CI/CD-Pipeline – und schon ist das System kompromittiert.

Hinzu kommt: rand-user-agent wurde von rund 30 weiteren npm-Paketen verwendet. Entwickler, die davon nichts ahnten, könnten automatisch die infizierte Version eingebunden haben. Cybernews

Auch die Art der Tarnung war bemerkenswert: Code, der nur durch horizontales Scrollen sichtbar war, sowie unscheinbare Dateinamen – kaum erkennbar für das menschliche Auge.

Kein Einzelfall: Weitere bekannte Angriffe

Solche Vorfälle gab es bereits mehrfach in der Open-Source-Welt:

EventStream (2018): Eine Backdoor wurde nach einem Maintainer-Wechsel eingebaut. Ziel: Bitcoin-Wallets. SecurityWeek
UA-Parser-JS (2021): Enthielt einen Kryptominer, der heimlich Ressourcen verbrauchte. BleepingComputer
Typosquatting bei PyPI (2022): Tippfehler wie discordpydebug lockten Entwickler in die Falle. The Hacker News
xrpl.js (2025): Die offizielle XRP-Library wurde kompromittiert, um private Schlüssel zu stehlen. Cybernews

Die Gemeinsamkeit: Angreifer setzen auf beliebte, aber schlecht gepflegte Pakete, um möglichst viele Systeme zu erreichen.

Wie kann man sich schützen?

Ein paar einfache, aber effektive Maßnahmen:

Nur gepflegte Pakete nutzen: Achte auf regelmäßige Updates, aktive Maintainer und gute Bewertungen.
Automatische Scans: Nutze Tools wie npm audit, yarn audit oder Plattformen wie Snyk.
2FA aktivieren: Pflicht für alle, die Pakete veröffentlichen. npm Docs
Versionssicherheit: Mit package-lock.json kannst du unerwartete Updates vermeiden.
Weniger ist mehr: Reduziere unnötige Abhängigkeiten – jede davon ist ein potenzielles Risiko.
Verdächtige Ordner prüfen: Etwa versteckte .node_modules-Verzeichnisse oder verdächtige Ordner im AppData-Bereich.
SBOM nutzen: Eine Software-Stückliste hilft bei der schnellen Analyse im Ernstfall.
Monitoring-Tools einsetzen: Plattformen wie Vorlon erkennen verdächtige Aktivitäten frühzeitig.

Was lernen wir daraus?

Der Fall rand-user-agent zeigt: Sicherheit darf im Open-Source-Bereich kein Nachgedanke sein. Vorschläge für eine bessere Zukunft:

2FA verpflichtend für Maintainer – nicht nur empfohlen.
Automatische Checks vor Veröffentlichung – etwa durch Vergleich mit dem GitHub-Quellcode.
Bessere Kennzeichnung veralteter Pakete – mit Warnhinweisen direkt beim Installieren.
Mehr Community-Augen – durch Reviews und Vertrauensmodelle.

Organisationen wie die Open Source Security Foundation arbeiten bereits an Lösungen wie der „OpenSSF Scorecard“, um Schwachstellen früh zu erkennen.

Fazit

Open Source ist das Rückgrat moderner Softwareentwicklung – doch mit der Freiheit kommt Verantwortung. Wer auf offene Komponenten setzt, muss auch für deren Sicherheit sorgen.

Für Maintainer:

Aktiviere konsequent Zwei-Faktor-Authentifizierung (2FA) für deine Paketmanager-Accounts.
Veröffentliche neue Versionen nur, wenn sie mit dem Quellcode im Repository übereinstimmen.
Reagiere zügig auf Sicherheitsmeldungen und halte Pakete aktuell – oder gib sie offiziell auf.
Dokumentiere deine Projekte transparent, damit andere Risiken besser einschätzen können.

Für Anwender*innen:

Wähle Abhängigkeiten gezielt aus: Achte auf Wartung, Updates und Community-Aktivität.
Nutze Werkzeuge wie npm audit oder Snyk für automatisierte Sicherheitsprüfungen.
Vermeide veraltete oder selten gepflegte Pakete – auch wenn sie populär sind.
Setze auf package-lock.json oder yarn.lock, um dein Projekt gegen plötzliche Änderungen abzusichern.

Vertrauen ist gut, Kontrolle ist besser – denn die nächste Paketfalle könnte schon beim nächsten npm install zuschnappen.

Quellen

🔎

Transparenzhinweis: Die Inhalte dieser Website werden mit größtmöglicher Sorgfalt recherchiert und aufbereitet. Quellen werden transparent benannt und regelmäßig geprüft. Dennoch kann keine Garantie für die Richtigkeit, Vollständigkeit oder Aktualität sämtlicher Informationen übernommen werden. Auch bei der Verwendung von künstlicher Intelligenz (z. B. zur Bild- oder Texterstellung) achten wir auf eine sachliche und nachvollziehbare Darstellung – Irrtümer sind jedoch nicht ausgeschlossen.