Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Ekosystem npm od lat pozostaje jednym z najważniejszych elementów łańcucha dostaw oprogramowania, ale jednocześnie stanowi atrakcyjny cel dla cyberprzestępców. Najnowsza kampania pokazuje, że złośliwe pakiety nie muszą już infekować środowiska programistycznego podczas instalacji, aby wyrządzić realne szkody.
W opisywanym przypadku 148 pakietów npm podszywało się pod szkolne proxy i serwisy edukacyjne. Ich faktyczna rola polegała na uruchamianiu aplikacji webowych, które po otwarciu w przeglądarce mogły pobierać dodatkowy kod i wykorzystywać urządzenia użytkowników do generowania ruchu związanego z atakami DDoS.
W skrócie
- Badacze zidentyfikowali 148 pakietów npm udających szkolne proxy lub narzędzia edukacyjne.
- Pakiety nie zawierały klasycznego malware uruchamianego podczas instalacji.
- Złośliwa funkcjonalność aktywowała się po otwarciu aplikacji w przeglądarce.
- Mechanizm umożliwiał zdalne ładowanie kodu i dynamiczne uruchamianie funkcji ofensywnych.
- Przeglądarki użytkowników mogły być wykorzystywane do generowania ruchu HTTP i połączeń WebSocket wspierających ataki DDoS.
Kontekst / historia
Kampania była maskowana jako usługi służące do omijania szkolnych filtrów treści. Interfejsy publikowanych pakietów przedstawiano jako witryny korepetycyjne, edukacyjne lub proste web proxy, co miało zwiększyć wiarygodność i zachęcić użytkowników do ich uruchamiania.
Początkowo projekt nosił cechy adware i nadużycia infrastruktury rejestrowej. W kodzie pojawiały się elementy związane z reklamami typu pop-under, monetyzacją ruchu oraz śledzeniem aktywności użytkownika. Z czasem kampania ewoluowała i zaczęła wykorzystywać bardziej agresywne mechanizmy.
W połowie maja do kodu dodano zdalny loader oraz moduł generujący ruch oparty o WebSocket. Następnie aktywowano komponent odpowiedzialny za zalewanie wybranych celów ruchem HTTP. Po pojawieniu się analiz badaczy część najbardziej podejrzanych funkcji usunięto lub czasowo wyłączono, jednak kolejna fala publikacji z 8 lipca 2026 roku zwiększyła liczbę zidentyfikowanych pakietów do 148.
Analiza techniczna
Najbardziej niepokojący aspekt tej kampanii polegał na tym, że pakiety nie zawierały typowych wskaźników złośliwości związanych z procesem instalacji. Nie wykorzystywały standardowych hooków lifecycle ani charakterystycznych skryptów budowania, dlatego mogły pozostać niewidoczne dla części tradycyjnych narzędzi bezpieczeństwa analizujących zależności.
Ich zasadniczym celem było dostarczenie aplikacji webowej uruchamianej w przeglądarce. Po otwarciu takiej strony ładowany był zdalny kod JavaScript z zewnętrznego źródła. Ponieważ mechanizm wskazywał na zmienną gałąź zamiast przypiętego, niezmiennego zasobu, operatorzy mogli w dowolnym momencie podmienić ładunek bez publikowania nowej wersji pakietu.
Taki model oznaczał pełny dostęp do danych dostępnych w kontekście originu aplikacji, w tym do cookies, local storage oraz innych zasobów przeglądarkowych. Innymi słowy, złośliwa funkcja mogła zostać aktywowana już po wejściu użytkownika na stronę, bez potrzeby dalszej interakcji.
Jeden z odzyskanych wariantów wykorzystywał cykliczne żądania HTTP POST z dużym payloadem, wysyłane w trybie no-cors. Dodatkowo stosowano losowe parametry zapytań, aby ograniczyć skuteczność cache pośredniczących i zwiększyć obciążenie infrastruktury docelowej.
Drugim istotnym elementem był komponent WebSocket wykorzystujący protokół Wisp, stosowany w lekkich środowiskach proxy do tunelowania wielu połączeń przez pojedynczy kanał. Moduł pobierał konfigurację z pliku tekstowego, a następnie inicjował liczne sesje i cyklicznie wysyłał ramki sterujące. W praktyce oznaczało to obciążanie nie tylko warstwy transmisyjnej, lecz także logiki zarządzającej połączeniami po stronie serwera.
Skutek był poważny: nawet pojedyncza karta w przeglądarce mogła wymuszać znaczną liczbę operacji po stronie zdalnego serwera, prowadząc do degradacji wydajności, wyczerpania zasobów i zakłócenia dostępności usług.
Konsekwencje / ryzyko
Ta kampania zmienia klasyczne spojrzenie na ataki supply chain. Zamiast atakować bezpośrednio dewelopera lub pipeline CI/CD, przestępcy wykorzystali publiczny rejestr pakietów jako platformę do dystrybucji złośliwych aplikacji przeglądarkowych. Ofiarą stawał się użytkownik końcowy, którego przeglądarka była zamieniana w element rozproszonej infrastruktury atakującej.
Dla organizacji oznacza to kilka jednoczesnych problemów. Po pierwsze, standardowe skanery zależności mogą nie wykryć pełnego ryzyka, jeśli koncentrują się głównie na skryptach instalacyjnych. Po drugie, ruch pochodzi z legalnych przeglądarek użytkowników, co utrudnia detekcję, filtrowanie i atrybucję. Po trzecie, możliwość zdalnego przełączania ładunku oznacza, że kampania może szybko zmienić charakter z adware na DDoS, kradzież danych sesyjnych lub inne nadużycia po stronie klienta.
Szczególnie narażone są środowiska szkolne i korporacyjne, w których użytkownicy próbują obchodzić ograniczenia dostępu do treści. To właśnie tam tego typu usługi mogą zdobywać popularność i generować największą skalę nadużyć.
Rekomendacje
Organizacje powinny rozszerzyć ochronę łańcucha dostaw poza sam moment instalacji pakietów. Konieczne jest monitorowanie zależności, które zawierają kompletne aplikacje webowe, mechanizmy dynamicznego ładowania kodu, obfuskowany frontend lub funkcje proxy.
- Analizować pakiety npm pod kątem zdalnego pobierania wykonywalnego JavaScript.
- Blokować znane domeny i hosty powiązane z kampanią na poziomie DNS, proxy i secure web gateway.
- Monitorować ruch wychodzący z przeglądarek pod kątem nietypowej liczby połączeń WebSocket i powtarzalnych żądań POST.
- Weryfikować użycie narzędzi omijających polityki filtrowania treści w organizacji.
Jeżeli podejrzane pakiety były uruchamiane lub powiązane strony były odwiedzane, warto podjąć następujące działania:
- wyczyścić cache przeglądarki i local storage,
- usunąć service workery zarejestrowane przez podejrzane domeny,
- przeanalizować historię ruchu sieciowego oraz telemetrię EDR i NDR,
- usunąć pakiety z manifestów i lockfile,
- ponownie zbudować projekty wyłącznie z zaufanych źródeł.
Podsumowanie
Incydent z 148 pakietami npm pokazuje, że zagrożenia w ekosystemie open source coraz częściej wykraczają poza klasyczny model złośliwego kodu wykonywanego podczas instalacji. Wystarczy aplikacja przeglądarkowa z możliwością zdalnego ładowania ładunku, aby użytkownik końcowy został włączony do infrastruktury służącej do cyberataków.
Dla zespołów AppSec, SOC i administratorów sieci to wyraźny sygnał, że bezpieczeństwo supply chain musi obejmować nie tylko to, co instalujemy, ale także to, co później uruchamia się w przeglądarce użytkownika. Granica między bezpieczeństwem aplikacji, przeglądarki i sieci staje się coraz mniej wyraźna.
Źródła
- The Hacker News — https://thehackernews.com/2026/07/148-npm-packages-disguised-as-student.html
- JFrog Security Research — https://research.jfrog.com/npm_packages/lucide-proxy-botnet/
- SafeDep Advisory — https://safedep.io/packages/npm/lucide/
- Mercury Workshop Wisp Protocol — https://github.com/MercuryWorkshop/wisp-protocol
- Mercury Workshop wisp-server-node — https://github.com/MercuryWorkshop/wisp-server-node