Zum Inhalt springen
Software Supply Chain Security

npm-Mirror-Missbrauch: Fake CAPTCHA-Seiten statt echter Updates

npm-mirrors fake CAPTCHA

Cybersecurity-Teams warnen vor einem neuen Muster des npm-Mirror-Missbrauch: Statt Entwickler direkt zu infizieren, nutzen Angreifer eine Reihe von npm-Paketen als scheinbar legitime „Transport- und Speicherlösung“ für schädliche Inhalte. Besonders kritisch ist dabei der Einsatz von Mirror-Diensten wie unpkg, über die eine täuschend echte Fake-CAPTCHA-Seite ausgeliefert wird.

Nach Angaben von OX Security besteht die eigentliche Payload dabei aus einer einzigen HTML-Datei. Der Clou: Das Paket selbst soll beim Download nicht „aktiv“ schaden. Der Missbrauch zielt vielmehr darauf ab, die npm-Registry und ihre Spiegel als eine Art vertrauenswürdige Ablage zu verwenden – sodass die Seite live aus dem Browser heraus funktioniert.

Warum der Angriff nicht auf „Installation“ setzt

Viele Menschen denken bei npm-Paketen zuerst an die Gefahr, die von ausführbarem Code nach der Installation ausgeht. In diesem Fall liegt der Schwerpunkt jedoch auf etwas anderem: Der Angreifer verwendet die npm-Infrastruktur nicht, um Entwickler mit einem kompromittierten Build zu kompromittieren. Stattdessen dient die Plattform als „validiertes Storage“ für eine HTML-Payload.

Die Forscher beschreiben das so, dass das Schadstück zwar nur eine statische Seite enthält, aber durch den Kontext auf Mirror-Diensten voll gerendert und nutzbar wird. Wer also einen Link öffnet, der auf einem Mirror basiert, kann einer Interaktionsfalle zum Opfer fallen.

24 npm-Pakete als Phishing-Infrastruktur

Der Kampagnenbericht nennt mehrere npm-Paketnamen, die in der Angriffslogik eine Rolle spielen. Einige davon seien nach wie vor abrufbar. Dazu gehören unter anderem folgende Paket-Bezeichnungen: bgzxcuite2, prezdentkxheiw, egair0810, mn2adskhweox, mn3sadkoiewu, mbxcnsuwgs1, sowie weitere ähnlich zusammengesetzte Namen.

Wichtig ist dabei nicht die „Lesbarkeit“ der Namen, sondern ihr Zweck: Sie liefern jeweils eine HTML-Datei, die später als Fake-Verifikationsseite dient. Damit wird das npm-Ökosystem zu einer Art Katalog für Inhalte, die wie normale Mirror-Ressourcen wirken.

unpkg & Co.: Wenn ein vertrauenswürdiger Spiegel zur Falle wird

Die Kampagne richtet sich gezielt auf Mirror-Dienste wie unpkg. Sobald ein Paket auf so einem Dienst gespiegelt ist, wird die enthaltene index.html im Browser abrufbar – beispielsweise in der Form „unpkg[.]com/<package>@1.0.0/index.html“.

Diese Seite imitiert dabei eine Cloudflare CAPTCHA-Prüfung. Das Entscheidende: Sie wird auf einer Domain gehostet, der viele Nutzer grundsätzlich vertrauen, und sie wirkt im ersten Moment wie eine legitime Sicherheitsabfrage. Anschließend leitet sie jedoch zu ClickFix-nahen Phishing-Infrastrukturen weiter.

So funktioniert die Fake-CAPTCHA-Weiterleitung

Die HTML-Datei enthält die Logik für die Anzeige der erfundenen Verifikationsabfrage. Zusätzlich ist JavaScript eingebettet, das Anfragen an einen entfernten Server sendet. In frühen Iterationen soll die Kommunikation an eine typosquatted Domain gerichtet gewesen sein, die eine Microsoft Login-Seite nachahmt (angegeben als „login[.]microsofte[.]live“).

Nachdem diese Domain in der Google Chrome Safe Browsing-Blockliste auftauchte, wechselten die Angreifer laut den Forschern auf eine alternative Infrastruktur: KeyVal („api.keyval[.]org“). KeyVal ist ein frei zugänglicher Key-Value-Store mit REST-API, mit dem Entwickler Werte setzen oder abrufen können.

DDR statt Zufall: KeyVal als „Dead Drop Resolver“

In der beschriebenen Kampagne wird KeyVal zweckentfremdet. Die Forscher charakterisieren das Vorgehen so, dass der legitime Dienst zum sogenannten Dead Drop Resolver (DDR) umfunktioniert wird. Dadurch lassen sich Ziel-URLs indirekt „nachladen“ und auslesen.

Das Muster: Die Fake-Captcha-Seite ermittelt oder dekodiert aus dem Key-Value-Store die Adresse, zu der das Opfer letztlich geleitet wird. Somit kann der Angreifer die Weiterleitung flexibel steuern, ohne die ursprüngliche HTML-Payload jedes Mal neu ausrollen zu müssen.

Aktuell soll die entfernte Logik die Nutzer zwar zu einer legitimen ChatGPT-Webseite verschieben. Laut den Forschern ist dieses Setup aber grundsätzlich wiederverwendbar: Wenn der Angreifer die Konfiguration anpasst, könnte sie auch auf ClickFix oder andere Phishing-Domains umgeschaltet werden.

Was Nutzer und Teams daraus lernen sollten

Der Fall zeigt deutlich, dass Angreifer nicht nur nach „klassischem Malware-Code“ suchen, sondern gezielt Infrastruktur ausnutzen. npm und seine Spiegel werden dabei wie eine Speicherplattform behandelt, die auch dann noch verfügbar sein kann, wenn einzelne Pakete aus offiziellen Stores entfernt werden.

Für Verteidigung und Risikoanalyse bedeutet das: Selbst wenn eine Payload nur aus einer Seite besteht, kann sie durch den Hosting-Kontext wirken. Und weil Mirror-Dienste Inhalte oft sauber ausliefern, entsteht der Eindruck von Legitimität.

Kein Einzelfall: Infrastrukturmissbrauch bei npm ist bereits bekannt

Die Forscher betonen, dass dieses Vorgehen nicht neu ist. Schon zuvor gab es Berichte über Kampagnen, die npm-Pakete missbrauchten, um über unpkg-ähnliche CDNs Redirect-Skripte zu verteilen. In einem früheren Bericht wurden dabei 175 Pakete genannt, die im Rahmen einer Kampagne eingesetzt wurden, die auf das Abgreifen von Zugangsdaten abzielte.

Der gemeinsame Nenner bleibt: Angreifer nutzen vertrauenswürdige Plattformen als „Transportweg“ und „Datenablage“. Das kann Persistenz ermöglichen, weil Inhalte auf Mirrordiensten länger erreichbar sein können.

Praktische Gegenmaßnahmen gegen den npm-Mirror-Missbrauch

Auch wenn der konkrete Angriff über Links funktioniert, lassen sich viele Risiken senken. Ein guter Start sind die folgenden Schritte:

  • Links von npm-Mirror-Diensten kritisch prüfen: Wer eine vermeintliche Sicherheitsprüfung oder CAPTCHA sieht, sollte nicht ohne Weiteres interagieren.
  • Safe Browsing und Browser-Blocklisten nutzen: Das schnelle Blocken erkannter Ziele kann die Angriffswirkung reduzieren. Im Bericht führte diese Maßnahme sogar zu einem Wechsel der Infrastruktur.
  • Monitoring für verdächtige Paketnutzung: Achten Sie auf ungewöhnliche Referenzen in Logfiles, Downloads und im Webverkehr.
  • Security Awareness für Social-Engineering: Nutzer sollten darauf vorbereitet sein, dass „CAPTCHA“ nicht automatisch „legitim“ bedeutet.
  • Redundante Prüfmechanismen in der Lieferkette: Selbst wenn der Angriff keine Installation benötigt, kann ein kontrolliertes Prozessdesign das Risiko von Fehlentscheidungen senken.

Je besser Teams verstehen, dass nicht nur „Code in Paketen“, sondern auch Content-Hosting über Mirror-Dienste missbraucht werden kann, desto schneller reagieren sie im Ernstfall.

Fazit: npm-Mirror-Missbrauch gefährdet durch Vertrauen auf Spiegel-Domains

Der berichtete npm-Mirror-Missbrauch nutzt npm-Pakete nicht primär, um Entwickler zu infizieren, sondern um eine Fake-CAPTCHA-Seite über vertrauenswürdig wirkende Mirror-Dienste live auszuliefern. Über HTML-Logik und JavaScript wird der Nutzer schließlich zu externen Phishing-Zielen weitergeleitet, wobei eine umfunktionierte Key-Value-Infrastruktur die Zieladresse flexibel steuern kann.

Für die Praxis heißt das: Nicht nur Installationssicherheit zählt. Auch der Umgang mit Links, die Darstellung von vermeintlichen Sicherheitsprüfungen und das Monitoring rund um Mirror-Hosts sind entscheidend, um solche Phishing-Ketten rechtzeitig zu erkennen und zu stoppen.

Quelle: https://thehackernews.com/2026/08/24-npm-packages-abuse-unpkg-mirrors-to.html