Forschende von Koi Security haben eine langlaufende Kampagne namens PhantomRaven offengelegt: Seit August 2024 wurden im npm-Ökosystem 126 bösartige Pakete mit insgesamt über 86.000 Downloads publiziert; zum Zeitpunkt der Veröffentlichung waren rund 80 noch aktiv. Kern der Operation ist die Technik der Remote Dynamic Dependencies (RDD), die klassische Prüfmechanismen und statische Analysen zielgerichtet umgeht.
Remote Dynamic Dependencies (RDD): Was sich hinter der Methode verbirgt
In legitimen npm-Workflows sind Abhängigkeiten im package.json deklariert und werden über die vertrauenswürdige npm-Infrastruktur bezogen. RDD verändert dieses Bedrohungsmodell: Ein Paket lädt bei der Installation Code von externen URLs nach – teils sogar über unverschlüsseltes HTTP – und führt ihn sofort aus. Formal kann der Manifest-Eintrag weiterhin „0 Dependencies“ zeigen, wodurch Entwicklerinnen und Entwickler sowie Scanner in die Irre geführt werden.
Startet ein Team npm install, stößt das Schadpaket verdeckte Downloads vom Angreifer-Server an und führt die Nutzlast unmittelbar aus. Keine Benutzerinteraktion erforderlich; die tatsächliche Abhängigkeit erscheint weder im Lockfile noch durchläuft sie den npm-Registry-Pfad. Damit bleibt sie für statische Analysen weitgehend unsichtbar.
Taktiken: zielgerichtete Auslieferung und schwer replizierbare Artefakte
Nach Erkenntnissen von Koi Security wird die Payload bei jeder Installation neu bezogen und nicht gecacht. So können die Betreiber Antworten kontextabhängig variieren: IP-basierte Filter, „saubere“ Antworten für Sicherheitsforschende oder alternative Nutzlasten für Unternehmensnetze und Cloud-Umgebungen. Diese Nerrepilizierbarkeit erschwert Forensik und Bedrohungsjagd erheblich.
Im Anschluss sammelt die Malware Telemetrie und entwendet sensible Daten wie Access Tokens. Solche Token öffnen den Weg zu Supply-Chain-Angriffen, etwa durch Manipulation legitimer Repositories oder CI/CD-Pipelines. Die Exfiltration erfolgt redundant über HTTP GET (Daten in der URL), HTTP POST (JSON) und WebSocket-Verbindungen.
Social Engineering im Entwickleralltag: Slopsquatting und Marken-Imitation
Mehrere Pakete gaben sich als Tools aus dem Umfeld von GitLab und Apache aus, um Vertrauen und Installationsraten zu erhöhen. Zusätzlich kommt Slopsquatting zum Einsatz: Angreifer nutzen Halluzinationen von LLM-Assistenzsystemen aus, die mitunter plausibel klingende, aber nicht existente Paketnamen empfehlen. Diese Namen werden prompt in npm registriert und als Malware-Kanal missbraucht.
Auswirkungen auf DevOps und Software-Lieferketten
RDD unterläuft bewährte Dependency-Kontrollen: Lockfiles und viele statische Scanner spiegeln nicht wider, welche Fremdkomponenten zur Build-Zeit „on the fly“ geladen werden. Das erhöht das Risiko für Build-Agenten, Secrets und Artefakte und passt in das MITRE ATT&CK-Muster T1195 Supply Chain Compromise. Frühere Vorfälle im npm-Ökosystem (z. B. event-stream 2018 oder ua-parser-js 2021) belegen den potenziellen Impact solcher Eingriffe.
Abwehrmaßnahmen für npm, CI/CD und Netzwerke
Installationsrisiken minimieren
Setzen Sie in CI/CD npm ci mit –ignore-scripts bzw. npm_config_ignore_scripts=true ein und kapseln Sie Builds in Umgebungen mit begrenztem Internetzugang (Allowlist nur HTTPS-Domains der Registry). Offizielle Hinweise finden sich in der npm-Dokumentation.
Netzwerk- und Proxy-Kontrollen
Blockieren Sie ausgehendes HTTP, unterbinden Sie Code-Downloads von nicht verifizierten externen URLs zur Build-Zeit und erzwingen Sie Egress-Filter, TLS-Inspection und DNS-Logging. Alarmieren Sie auf Netzwerkverbindungen während npm install, die nicht zur Registry gehören.
Transparente Abhängigkeitsverwaltung
Validieren Sie neue Pakete (Herkunft, Maintainer-Reputation, Changelogs, Source-Repo) und überwachen Sie typosquatting/slopsquatting. Nutzen Sie interne Spiegel oder Caches vertrauenswürdiger Artefakte und ergänzen Sie Repos mit OpenSSF Scorecard-Signalen.
Schutz von Secrets und Token
Implementieren Sie Least Privilege, kurzlebige Token und regelmäßige Rotation; führen Sie Secret-Scanning ein und trennen Sie Build- von Produktionsumgebungen. Wo möglich, bevorzugen Sie kurzlebige, signierte Workload-Identitäten (z. B. OIDC) statt Langzeitschlüssel. Orientierung bieten NIST SSDF und SLSA.
Schulung und Prozesse
Verlassen Sie sich nicht blind auf LLM-Empfehlungen zu Paketnamen. Verankern Sie manuelle Prüfungen, definieren Sie Policies für Netzwerkzugriffe während Builds und erfassen Sie Installationslogs revisionssicher.
PhantomRaven zeigt, wie effizient Angreifer Architekturmerkmale von npm und Entwicklergewohnheiten ausnutzen. Wer jetzt Build-Skripte einschränkt, Egress konsequent kontrolliert und eine unabhängige Paketprüfung etablierte, reduziert das Risiko signifikant. Prüfen Sie Ihre Pipelines heute: Skripte deaktivieren, externe Verbindungen auf das Minimum begrenzen und neue Abhängigkeiten zweistufig verifizieren – bevor der nächste Vorfall die Lieferkette trifft.
