PhantomRavens Kampagne von Remote-Abhängigkeiten, die in Scheck npm

In den letzten Monaten hat die JavaScript-Community wieder eine unangenehme Erinnerung erhalten: Software-Lieferketten bleiben einer der Lieblingsvektoren für Angreifer. Eine Kampagne namens "PhantomRaven", die ursprünglich Ende 2025 entdeckt und durch die anschließende Forschung erweitert wurde, publiziert bösartige Pakete in der npm-Registrierung mit der Absicht, sensible Daten von Entwicklern und kontinuierlichen Integrationsumgebungen zu stehlen.

Die technische Besonderheit von PhantomRaven ist die Verwendung von entfernten dynamischen Abhängigkeiten (Remote Dynamic Dependencies, RDD), eine einfache, aber effektive Taktik: Statt den schädlichen Code in das veröffentlichte Paket einzubetten, weisen Angreifer aus dem Paket. json-Datei zu einer in einer externen URL gehosteten Einheit. Wenn Sie npm installieren, wird diese Einheit vom Server des Angreifers heruntergeladen und ausgeführt, in vielen Fällen vermeiden Sie automatisierte statische Überprüfungen, die den Paketinhalt im Register analysieren. Sie sehen eine technische Erklärung, wie npm Paket spielt. json in der offiziellen npm Dokumentation: https: / / docs.npmjs.com / cli / v9 / conforming-npm / Paket-json.

Die öffentliche Forschung über PhantomRaven, einschließlich der von Endor Labs, beschreibt mehrere Wellen der Veröffentlichung: Nach der ersten Entdeckung wurden zwischen November 2025 und Februar 2026 neue Runden entdeckt, in denen die Angreifer Dutzende von Paketen aus Einweg-Konten gestartet. Endor Labs dokumentiert detailliert die Beharrlichkeit der Kampagne, die Konsistenz der Nutzlast und die damit verbundene Infrastruktur; Ihr Bericht ist hier verfügbar: https: / / www.endorlabs.com / lernen / zurück / von-phantomraven. Nach diesen Analysen sind noch viele der Proben im npm-Datensatz zugänglich.

Ein weiteres wiederkehrendes Feature der Kampagne ist die Verwendung von "slopsquatting" oder Typosquatting-Techniken: bösartige Pakete versuchen, wie sehr gebrauchte legitime Projekte - zum Beispiel Babel oder GraphQL Codegen - zu suchen, indem sie Namen veröffentlichen, die mit denen von automatischen Assistenten verwechselt werden könnten oder von denen sie schnell eine Empfehlung kopieren und einfügen. Die Kombination aus überzeugenden Namen und Fernabhängigkeit reduziert die Erkennungswahrscheinlichkeit und erhöht die Wahrscheinlichkeit eines Entwicklers, der das Paket per Fehler installiert.

Sobald der schädliche Code die Maschine erreicht, ist sein Ziel klar und gefährlich: Informationen zu sammeln, die dem Angreifer erlaubt, seitlich oder exfilter Geheimnisse zu bewegen. Endor Labs stellt fest, dass die Proben nach lokalen Dateien und Konfigurationen wie .gitconfig und .npmrc, Umgebungsvariablen und Token von CI / CD Pipelines - GitHub, GitLab, Jenkins, CircleCI - suchen; sie sammeln auch Systemdrucke (IP, Hostname, Node Version) um das Opfer zu formen. Das Senden von Daten an den Steuer- und Befehlsserver (C2) erfolgt in der Regel durch HTTP GET, obwohl die Autoren auch POST und WebSocket verwendet, um Redundanz zu gewährleisten.

Die von PhantomRaven verwendete Infrastruktur zeigte wiederholte Muster: Domains, die das Wort "artifact", Server auf Amazon EC2, die oft nicht TLS-Zertifikat, und eine Nutzlast, deren die meisten Code blieb unverändert zwischen Wellen. Allerdings haben die Betreiber npm- und Postkonten gedreht, Metadaten angepasst und PHP-Endpunkte geändert, um mit minimalen Änderungen funktionsfähig zu bleiben.

Dies lässt mehrere praktische Lektionen für jeden Entwickler oder Sicherheitsteam. Erstens gibt es keine Abkürzung: die Herkunft eines Pakets zu überprüfen und seine Veröffentlichung ist wichtiger denn je. Es ist nicht genug, die von einem Chatbot oder Paste vorgeschlagene zu kopieren, ohne einen Namen zu betrachten, der "gut" schallt. Inspecting package.json, die Überprüfung des Autors und des Rufes der Öffentlichkeit, und die Überprüfung der Existenz eines angemessenen Quell-Repository sind einfache Schritte, die viele unangenehme Überraschungen vermeiden können. Für diejenigen, die Pipelines und Repositories verwalten, ist es empfehlenswert, die in den Workflow integrierten Tools für die Einheits-Scannen und Geheimerkennung zu ermöglichen; GitHub bietet geheime Scan- und Dependabot-Funktionen für Sicherheitsupdates, die das Risiko reduzieren helfen: https: / / docs.github.com / en / code-security / secret-scanning.

Es ist auch angebracht, Sicherheitskontrollen auf Token und Anmeldeinformationen anzuwenden: Beschränken Sie den Umfang der Token CI / CD, drehen Sie sie regelmäßig und nicht in Dateien, die von Drittprozessen gelesen werden können. Auf organisatorischer Ebene reduziert die Praxis des Baus von Artefakten in isolierten Umgebungen und unter Verwendung zuverlässiger Paketzulassungslisten (anstatt Pakete aus öffentlichen Daten ohne Überwachung zu installieren) die Angriffsfläche. Ressourcen wie OWASP und Supply Chain Analyse bieten nützliche Anleitungen für die Gerätehygiene und Früherkennung: https: / / owasp.org / www-project-dependency-check /.

Es gibt auch kommerzielle und gemeinschaftliche Lösungen, die helfen können, Risiken zu mindern: Einheit Sicherheitsscanner, private Paketspiegel und strengere Verlagsrichtlinien in internen Repositories. Plattformen wie Snyk haben Anleitungen und Analysen veröffentlicht, wie Lieferketten kritische Vektoren bleiben; siehe z.B. ihre Abdeckung von Lieferkettenangriffen: https: / / snyk.io / blog / Supply-chain-attacks /.

Obwohl PhantomRavens Technik aus der kryptographischen oder obfuskationischen Sicht des Codes nicht ausgefeilt ist - die Nutzlast, die zwischen den Proben kaum verändert wird - liegt ihre Wirksamkeit in der betrieblichen Einfachheit und in der Ausbeutung menschlicher Gewohnheiten: auf Namen, nach unifizierten Beispielen und laufenden Einrichtungen in privilegierten Umgebungen. Eine kleine Änderung der Entwicklungsgewohnheiten und die Annahme grundlegender Sicherheitskontrollen können die Exposition deutlich reduzieren.

Wenn Sie ein Entwickler sind, überprüfen Sie Ihre Projekte und Pipelines: suchen Sie nach Einheiten, die auf externe URLs im Paket zeigen. json, bestätigen Sie, dass es keine unbekannten Pakete in Ihren Lockfiles und betrachten Sie Scannen von Entwicklungsmaschinen und CI-Läufern mit Werkzeugen, die anormale Kommunikation zu verdächtigen Domänen erkennen. Wenn Sie eine Organisation betreiben, fördert sie Null-Konfidenz-Richtlinien für Drittanbieter-Pakete und bietet Teams einen Katalog von zugelassenen und aktualisierten Einheiten.

Die Branche hatte bereits ähnliche Episoden und Lösungen sind weitgehend bekannt. Die Lektion ist, dass die Überwachung kontinuierlich sein muss: Die Angreifer wiederholen Muster, die arbeiten und drehen das Minimum, das erforderlich ist, um vorwärts zu bewegen. Bleiben Sie informiert, wenden Sie technische Kontrollen an und vor allem überprüfen Sie zweimal vor der Installation, sind Schritte, die jetzt Teil der grundlegenden Sicherheit jedes npm-basierten Projekts sind.