24 złośliwe pakiety npm wykorzystywały unpkg do hostowania fałszywych stron CAPTCHA Cloudflare

Wprowadzenie do problemu / definicja

Ekosystem npm pozostaje jednym z kluczowych elementów współczesnego łańcucha dostaw oprogramowania JavaScript, ale jednocześnie od lat jest atrakcyjnym celem dla cyberprzestępców. Najnowsza kampania pokazuje jednak istotną zmianę taktyki: zamiast uruchamiać złośliwy kod podczas instalacji pakietu, napastnicy wykorzystali publiczną infrastrukturę mirrorów npm do hostowania gotowych stron phishingowych.

W praktyce oznacza to, że złośliwy pakiet nie musi bezpośrednio infekować systemu dewelopera. Wystarczy, że zawiera odpowiednio przygotowany plik HTML, który po zmirrorowaniu przez usługę taką jak unpkg staje się publicznie dostępny pod wiarygodnie wyglądającym adresem i może służyć jako nośnik oszustwa.

W skrócie

Badacze opisali kampanię obejmującą 24 pakiety npm, które zawierały pojedyncze strony HTML imitujące weryfikację CAPTCHA Cloudflare. Kluczowym elementem operacji było nadużycie mirrorów i CDN-ów obsługujących pakiety npm, dzięki czemu fałszywe strony mogły być serwowane z legalnej i powszechnie rozpoznawalnej infrastruktury.

24 pakiety npm zawierały pliki HTML podszywające się pod Cloudflare CAPTCHA.
Pakiety nie musiały wykonywać złośliwego kodu podczas instalacji.
Mirrory takie jak unpkg pełniły rolę publicznego hostingu dla stron phishingowych.
Mechanizm przekierowania korzystał z zewnętrznej infrastruktury oraz publicznych usług pośredniczących.
Kampania wpisuje się w trend nadużywania zaufanej infrastruktury open source do operacji phishingowych.

Kontekst / historia

Ataki na npm są zwykle kojarzone z kradzieżą tokenów, złośliwymi skryptami instalacyjnymi albo przejęciami popularnych bibliotek. W omawianym przypadku model działania był jednak inny. Pakiety pełniły funkcję repozytorium statycznych treści phishingowych, które po publikacji stawały się dostępne przez zewnętrzne usługi mirrorujące zawartość rejestru.

To rozwinięcie trendu obserwowanego już wcześniej, gdy publiczny rejestr npm i powiązane z nim usługi były wykorzystywane do hostowania elementów kampanii wyłudzających dane. Obecna operacja pokazuje większą dojrzałość napastników: zamiast prostych przekierowań zastosowano wiarygodną wizualnie stronę weryfikacyjną oraz bardziej elastyczny model sterowania docelowym adresem.

Analiza techniczna

Wykryte pakiety zawierały głównie pojedynczy plik index.html. Samo ich pobranie lub instalacja nie oznaczały jeszcze bezpośredniej infekcji urządzenia. Istotą ataku było to, że po publikacji taki plik stawał się dostępny przez publiczny mirror i mógł być otwierany jak zwykła strona internetowa.

Po wejściu na spreparowany adres użytkownik widział stronę imitującą proces weryfikacji Cloudflare. Tego typu przynęta dobrze wpisuje się w scenariusze ClickFix, w których ofiara ma wykonać pozornie bezpieczną czynność potwierdzającą autentyczność sesji. Celem jest obniżenie czujności, wzbudzenie zaufania i przygotowanie użytkownika do kolejnego etapu oszustwa.

Osadzony w stronie kod JavaScript odpowiadał za pobieranie informacji o dalszym przekierowaniu. W analizowanych wariantach operatorzy kampanii korzystali nie tylko z własnej infrastruktury, ale także z publicznego magazynu typu key-value store, który działał jak pośredni punkt przechowujący docelowy adres. Taki mechanizm przypomina model dead drop resolver, w którym końcowy adres nie jest zapisany bezpośrednio w kodzie strony, lecz pobierany dynamicznie podczas jej działania.

Takie podejście daje napastnikom kilka korzyści operacyjnych. Utrudnia analizę statyczną, pozwala zmieniać finalny cel kampanii bez ponownej publikacji pakietu i rozprasza infrastrukturę ataku między legalne usługi o wysokiej reputacji. W efekcie tradycyjne mechanizmy filtrowania oparte wyłącznie na domenie mogą okazać się niewystarczające.

Konsekwencje / ryzyko

Największe zagrożenie dotyczy użytkowników końcowych i pracowników organizacji, którzy mogą kliknąć link prowadzący do takiej strony. Adres bazujący na znanej infrastrukturze może wyglądać wiarygodnie, szczególnie jeśli prezentuje znajomy mechanizm ochrony antybotowej.

Dla zespołów bezpieczeństwa problemem jest zacieranie granicy między legalnym hostingiem a infrastrukturą wykorzystywaną w ataku. Jeżeli szkodliwa treść jest serwowana przez renomowany mirror pakietów, wykrycie incydentu staje się trudniejsze zarówno dla narzędzi bezpieczeństwa, jak i dla samych użytkowników.

Wzrasta skuteczność phishingu opartego na zaufanej domenie pośredniczącej.
Detekcja oparta wyłącznie na reputacji domen staje się mniej efektywna.
Artefakty kampanii mogą pozostać dostępne w cache lub mirrorach nawet po usunięciu pakietu.
Organizacje muszą uwzględnić legalne usługi open source jako potencjalny etap łańcucha ataku.

Rekomendacje

Organizacje powinny rozszerzyć monitoring zagrożeń o nadużycia publicznej infrastruktury open source, w tym mirrorów npm i CDN-ów pakietów. Szczególną uwagę warto zwracać na ruch prowadzący bezpośrednio do plików HTML hostowanych w mirrorach, gdy nie jest on związany z normalnym pobieraniem zależności programistycznych.

Traktować adresy mirrorów npm jako potencjalny wektor phishingu, jeśli służą do renderowania treści webowych.
Monitorować odwiedziny nietypowych adresów prowadzących do statycznych plików HTML w ekosystemie pakietów.
Rozszerzyć kontrolę nad nowo publikowanymi lub nisko reputacyjnymi pakietami.
Analizować ruch do publicznych usług key-value store oraz podobnych serwisów pośredniczących.
Rozwijać reguły detekcji dla fałszywych stron CAPTCHA, Cloudflare i scenariuszy ClickFix.
Szkolić użytkowników, aby nie ufali komunikatom o weryfikacji poza oczekiwanym kontekstem biznesowym.

Dla zespołów AppSec i DevSecOps istotne jest również skanowanie rejestrów pakietów pod kątem artefaktów, które nie działają jak typowe biblioteki, lecz zawierają statyczne strony, przekierowania lub nietypowe odwołania do zewnętrznych usług. Nawet jeśli taki pakiet nie uruchamia złośliwego kodu lokalnie, może nadal stanowić ważny element infrastruktury oszustwa.

Podsumowanie

Kampania z wykorzystaniem 24 pakietów npm pokazuje, że zagrożenia w obszarze software supply chain ewoluują poza klasyczny model infekcji przez instalację biblioteki. Napastnicy coraz częściej wykorzystują legalne komponenty ekosystemu open source jako zaufaną platformę do hostowania przynęt phishingowych i pośredniego kierowania ofiar do dalszych etapów ataku.

Dla obrońców to wyraźny sygnał, że ocena ryzyka związanego z pakietami musi obejmować nie tylko wykonywany kod, ale również sposób, w jaki legalna infrastruktura może zostać przekształcona w element operacji phishingowej. Zaufana domena nie może być już traktowana jako wystarczający wskaźnik bezpieczeństwa.