LONDON (IT BOLTWISE) – Eine Angriffsserie mit 148 npm-Paketen tarnte sich als „Student-Proxy“ und verwandelte Browser in ein DDoS-Botnetz. Laut Analyse von JFrog lief die Kampagne Anfang Mai rund zwei Wochen und nutzte dabei einen Proxy-Client als Zustellmechanismus. Im Kern wird nicht beim npm-Installieren zugeschlagen, sondern erst im geöffneten Tab: Remote-Code wird nachgeladen und anschließend werden entweder HTTP-Floods oder WebSocket-basierte Wisp-Lasten erzeugt. Unternehmen und Schulen können den Schaden begrenzen, indem sie Domains auf DNS-Ebene blockieren und betroffene Abhängigkeiten aus Lockfiles sauber neu aufsetzen.
Eine scheinbar harmlose npm-„Proxy“-Sammlung entpuppte sich als Lieferkette für Client-seitige Angriffe: Wie JFrog in einer neuen Auswertung beschreibt, haben 148 als Student-Webproxies getarnte Pakete in den ersten beiden Maiwochen für Angriffsverkehr gesorgt. Bemerkenswert ist dabei das Zielprofil: Die Pakete richteten sich nicht primär gegen Entwickler, die sie bauen, sondern gegen die Nutzer, die die zugehörigen Proxy-Seiten öffnen wollten. Auf der Oberfläche half das System tatsächlich beim Umgehen von Inhaltsfiltern. Dahinter wurden Browser jedoch so eingebunden, dass sie während einer Session DDoS-ähnliche Last erzeugen konnten, ohne dass beim Einbinden in ein Projekt offensiv „maliziöse“ Install- oder Build-Schritte auftreten.
Technisch verschiebt sich das Risiko damit vom klassischen „npm install“-Szenario in Richtung Web-Execution im Browser. JFrog stellt heraus, dass die betroffenen Pakete bei der Installation keine Lifecycle-Hooks und keine nativen Build-Skripte nutzten; sie seien auch nie dafür gedacht, in fremden Projekten importiert zu werden. Stattdessen ist der entscheidende Schritt das spätere Öffnen einer Seite, die der Proxy-Client ansteuert. Die Pakete starten dann einen Remote Loader, der den eigentlichen Payload-Inhalt austauschen kann. Dadurch lässt sich die Angriffsfähigkeit nachträglich „umschalten“, ohne dass Nutzer eine neue Paketversion installieren müssten.
Für die Markt- und Sicherheitslage ist das vor allem deshalb relevant, weil öffentliche Registries seit Jahren zugleich als günstige CDNs dienen. In der Analyse wird ein Modul namens G2 beschrieben, das JavaScript über jsDelivr aus einem GitHub-Repository bezieht und dabei bewusst auf eine mutable „main“-Branch statt auf einen festen, signierten Commit setzt. Hinzu kommen fehlende Subresource-Integrity-Checks sowie eine Ausführung mit Origin-Privilegien der Proxy-Seite. Das bedeutet: Der geladene Code kann Cookies, Local Storage und Same-Origin-Endpunkte auslesen bzw. missbrauchen. Mit einer „no-referrer“-Policy wird außerdem die Herkunft der Requests weniger sichtbar gemacht. Das ist weniger ein einmaliger „Payload-Upload“, sondern ein Mechanismus, der Änderungen im GitHub-Account sofort in jedem Browser replizieren kann.
Konkreter wird es beim zweiten Modul I2, das stärker in Richtung volumetrischer bzw. zustandsbasierter Lastangriffe zielt. Hier lädt der Browser eine Klartextdatei („websocket.txt“), um Ziel-URLs sowie eine Socket-Anzahl zwischen 1 und 1.024 zu bestimmen. Anschließend eröffnet die Komponente in einer gestaffelten Schleife mehrere WebSocket-Verbindungen zu einem Wisp-basierten Endpunkt. Wisp selbst ist ein Mercury-Workshop-Protokoll, das viele TCP- und UDP-Sockets über einen einzelnen WebSocket tunnelt, und es ist in Browser-Proxy-Implementationen als „plumbing“ bekannt. Doch im Angriffsszenario wird das Ziel durch korrekt formatierte Wisp-CONNECT-Frames und CLOSE-Frames getaktet, wodurch ein Control-Plane-Problem entsteht: Server müssen Verbindungen ständig allozieren und wieder auflösen, während Log-Ausgaben explodieren.
Jenseits der reinen Payload zeigt die Kampagnenanalyse, wie „operational“ das Ganze war. JFrog rekonstruiert die Timeline aus deobfuskierter App-Logik und archivierten Artefakten (u.a. über die Wayback Machine) und beschreibt einen Entwicklungsbogen: zunächst Adware, dann die Einbindung des Remote Loaders und des Wisp-Generators, anschließend eine Live-Phase mit dem Flood am Monatsende sowie ab dem 31. Mai eine Bereinigung der Pakete. Dennoch bleibt die Fähigkeit zur Wiederaktivierung erhalten, weil der Loader auf einen mutablen Branch verweist. Eine zweite Welle am 8. Juli brachte insgesamt 148 Pakete hervor, jedoch mit einem „cleaned-up“ adware-only Build—wobei Loader-Mechanismen weiterhin vorhanden blieben.
Auch wenn die Geschichte als „Student-Proxy“-Szenario klingt, ist die Abwehr klar technikgetrieben. Laut JFrog sollten Betreiber von Schul- und Unternehmensnetzwerken die Proxy-Kampagnen-Domains auf DNS-Ebene blockieren; besonders nennt die Analyse aktuell noch erreichbare Monetarisierungs- und Script-Hosts wie woofbeginner[.]com und c.vipersfutbol[.]com. Zusätzlich empfiehlt sich für Nutzer, die eine der Proxy-Seiten geöffnet haben, Browser-Cache, Local Storage zu leeren und Service Worker zu entfernen, falls eine Proxy- oder Tutoring-Domain einen registriert hat. Für IT-Teams mit betroffenen Abhängigkeiten gilt: Pakete aus den Manifests sowie Lockfiles entfernen, anschließend sauber neu aufbauen und die Build-Pipeline so absichern, dass solche Client-side Proxy-Artefakte nicht erneut durchrutschen.
Vergleicht man das mit früheren npm-Angriffsmustern, wird die strategische Verschiebung deutlich: Viele Tools für Dependency Scanning und Install-Time-Sandboxing sind darauf ausgelegt, Code zu erkennen, der während des npm-Installierens aktiv wird. Diese Kampagne umgeht genau diesen Trigger—der schädliche Effekt entsteht erst im Browser-Tab, nachdem eine Proxy-Seite geladen wurde. Aus der Sicherheitscommunity wird daher zunehmend betont, dass öffentliche Registries als „kostenlose CDNs“ nicht nur Komfort, sondern auch eine Angriffsfläche für mutable, serverseitig umschaltbare Client-Assets schaffen. Der Blick in konkurrierende Schadsoftware-Modelle (etwa Client-side Loader + WebSocket-Flooding) zeigt, dass Botnetze künftig stärker über legitime Web-Workflows gebaut werden. Für die Zukunft heißt das: Unternehmen sollten neben Supply-Chain-Checks auch Web-Content-Restriktionen, Policy-basierte Blockierung (DNS/Proxy) und striktes Lockfile-Management als Standard etablieren.
💳 Amazon-Kreditkarte mit 2.000 Euro Limit bestellen!
🔥 Heutige Hot Deals bei Amazon: Bis zu 80% Rabatte!
🎉 Amazon Haul-Store für absolute Schnäppchenjäger!
- ★ 23-stufiges KI-Go-Training – Für Spieler mit Grundkenntnissen der Regeln – Entwickelt als intelligenter Trainingspartner passt sich die KI Spielern von 18K bis 9D an. Ideal für alle, die die Grundregeln bereits beherrschen und ihr Spiel verbessern möchten.
- IHR EMOTIONALER AI-BEGLEITER: Eiliko ist mehr als nur ein Anhänger, es ist ein charismatischer KI-Freund. Mit einem dynamischen LED-Bildschirm, der eine Vielzahl von animierten Gesichtern und Ausdrucksformen anzeigt, reagiert er auf Ihre Interaktionen mit einzigartiger Persönlichkeit und Charme.
- NIEDLICHER BEGLEITER: Eilik ist der ideale Begleiter für Kinder und Erwachsene, die Haustiere, Spiele und intelligente Roboter lieben. Mit vielen Emotionen, Bewegungen und interaktiven Funktionen.
- 【XL-Größe für gedeihende Pflanzen】Geben Sie Ihren Pflanzen den Raum, den sie verdienen! Unser verbessertes, großes 13,7 cm großes Design bietet Platz für Pflanzen mit einem Durchmesser von bis zu 8,9 cm und damit deutlich mehr Platz für Wurzelwachstum und Pflanzengesundheit im Vergleich zu kleineren, veralteten Modellen. Die Produktabmessungen betragen 13,6 x 13,6 x 13,2 cm und das Gerät wiegt nur 355 g.
- V28 Update - JETZT MIT NEUEN FUNKTIONEN! Als Reaktion auf das Ladeproblem von Loona haben wir das automatische Aufladen 2.0 verbessert. Diese Optimierung hilft Loona, die Ladewege in verschiedenen Szenarien zu erkennen und anzupassen, um die Erfolgsquote beim automatischen Aufladen zu erhöhen. Mobile Hotspots können sich mit Loona verbinden und überwinden WLAN-Einschränkungen, sodass Sie jederzeit und überall mit Loona interagieren können.
- Die besten Bücher rund um KI & Robotik!
- Die besten KI-News kostenlos per eMail erhalten!
- Zur Startseite von IT BOLTWISE® für aktuelle KI-News!
- IT BOLTWISE® kostenlos auf Patreon unterstützen!
- Aktuelle KI-Jobs auf StepStone finden und bewerben!
- Künstliche Intelligenz: Dem Menschen überlegen – wie KI uns rettet und bedroht | Der Neurowissenschaftler, Psychiater und SPIEGEL-Bestsellerautor von »Digitale Demenz«
Du hast einen wertvollen Beitrag oder Kommentar zum Artikel "NPM: 148 „Student-Proxies“ wurden zu Browser-DDoS-Botnetzen" für unsere Leser?
#Sophos
#AmazonPrime
#Bestseller
Es werden alle Kommentare moderiert!
Für eine offene Diskussion behalten wir uns vor, jeden Kommentar zu löschen, der nicht direkt auf das Thema abzielt oder nur den Zweck hat, Leser oder Autoren herabzuwürdigen.
Wir möchten, dass respektvoll miteinander kommuniziert wird, so als ob die Diskussion mit real anwesenden Personen geführt wird. Dies machen wir für den Großteil unserer Leser, der sachlich und konstruktiv über ein Thema sprechen möchte.
Du willst nichts verpassen?
Du möchtest über ähnliche News und Beiträge wie "NPM: 148 „Student-Proxies“ wurden zu Browser-DDoS-Botnetzen" informiert werden? Neben der E-Mail-Benachrichtigung habt ihr auch die Möglichkeit, den Feed dieses Beitrags zu abonnieren. Wer natürlich alles lesen möchte, der sollte den RSS-Hauptfeed oder IT BOLTWISE® bei Google News wie auch bei Bing News abonnieren.
Nutze die Google-Suchmaschine für eine weitere Themenrecherche: »NPM: 148 „Student-Proxies“ wurden zu Browser-DDoS-Botnetzen« bei Google Deutschland suchen, bei Bing oder Google News!