24 pakiety npm wykorzystano jako infrastrukturę phishingową ClickFix

Firma OX Security ujawniła kampanię, w której 24 pakiety npm zawierały identyczny, złośliwy plik HTML — fałszywą stronę CAPTCHA stylizowaną na weryfikację Cloudflare. Pakiety nie służyły przede wszystkim do infekowania programistów podczas instalacji. Napastnicy wykorzystywali rejestr npm oraz automatycznie synchronizowane mirrory, takie jak unpkg, jako wiarygodnie wyglądające miejsce do hostowania treści phishingowych i rozpowszechniania prowadzących do nich linków. 217

npm jako zaplecze hostingu phishingu

Kampania wykorzystywała zaufanie do ekosystemu npm w nietypowy sposób. Ładunkiem nie był typowy skrypt uruchamiany podczas instalacji pakietu, lecz pojedyncza strona HTML. Osoba, która otworzyła odpowiedni plik za pośrednictwem npm lub jego mirrora, mogła zobaczyć ekran weryfikacji przypominający usługę Cloudflare, wyświetlany pod domeną znanego serwisu. 217

To ważne rozróżnienie: samo pobranie pakietu npm nie musiało oznaczać infekcji. Celem atakujących było nakłonienie użytkowników do otwarcia linków rozpowszechnianych innymi kanałami. Rejestr npm i jego mirrory zapewniały im stabilny, zaufanie budzący kanał dostarczania strony phishingowej. 17

Zmienny łańcuch przekierowań

Fałszywa CAPTCHA była dopiero początkiem łańcucha przekierowań. Według OX Security wcześniejsze wersje kampanii łączyły się z domeną podszywającą się pod witrynę Microsoftu. W kolejnych etapach badacze odnotowali zmieniające się adresy i elementy infrastruktury, między innymi microcloud[.]homes oraz login[.]microsofte[.]live. 218

Napastnicy korzystali także z KeyVal — publicznego magazynu danych typu key-value — jako mechanizmu rozstrzygania adresu docelowego, określanego również jako „dead drop”. Dzięki temu mogli zmieniać miejsce, do którego trafiały ofiary, bez konieczności publikowania tego samego pliku HTML ponownie we wszystkich pakietach. 21

Taka konstrukcja utrudnia skuteczne usunięcie kampanii. Skasowanie pakietu z npm nie unieważnia automatycznie każdego adresu prowadzącego do wcześniej zsynchronizowanej kopii w mirrorze. W opisach kampanii wskazywano, że po usunięciu części pakietów z rejestru niektóre pliki i strony hostowane w mirrorach nadal pozostawały dostępne. 1718

CAPTCHA była przynętą dla ataku ClickFix

Strona nie przeprowadzała prawdziwej kontroli bezpieczeństwa. Zamiast tego instruowała odwiedzających, aby skopiowali, wkleili i uruchomili polecenie na własnym komputerze. To charakterystyczny schemat ClickFix: atakujący nie musi wykorzystywać luki w oprogramowaniu, ponieważ przekonuje ofiarę do samodzielnego wykonania złośliwego polecenia z jej własnymi uprawnieniami. 2025

Fałszywe strony weryfikacyjne są skuteczne, bo wykorzystują znajome elementy identyfikacji wizualnej przeglądarek i usług bezpieczeństwa. W podobnych kampaniach przycisk weryfikacji lub instrukcja na stronie potajemnie umieszcza polecenie w schowku, a następnie prowadzi użytkownika przez skróty klawiszowe albo okno systemowe. 2628

Praktyczna zasada jest prosta: CAPTCHA nigdy nie powinna wymagać otwarcia powłoki systemowej, PowerShella, Terminala ani okna „Uruchom” i wykonania wklejonego tekstu.

Jaki zasięg miały pakiety?

Według OX Security każdy z pakietów uzyskiwał przed usunięciem zwykle około 50–300 pobrań tygodniowo. 2 Liczby te opisują aktywność w rejestrze, a nie całkowitą liczbę osób, które mogły zetknąć się ze stronami phishingowymi za pośrednictwem bezpośrednich linków lub adresów mirrorów.

Z tego powodu standardowe statystyki pobrań pakietów nie pokazują pełnego zamierzonego zasięgu operacji. Pakiety działały jak sieć stron docelowych, a linki do nich mogły być rozpowszechniane w wiadomościach phishingowych, za pośrednictwem przejętych witryn lub innymi kanałami. 217

Element szerszego trendu ClickFix

Kampanię npm najlepiej traktować jako wariant infrastrukturalny szerszego modelu ClickFix. W opisywanych operacjach napastnicy łączą znajomą przynętę — na przykład CAPTCHA, błąd przeglądarki, fałszywą aktualizację lub narzędzie programistyczne — z instrukcjami nakłaniającymi ofiarę do samodzielnego uruchomienia polecenia. Proofpoint określił tę technikę jako coraz popularniejszy sposób dostarczania złośliwego oprogramowania, a Microsoft dokumentował jej kolejne odmiany, w których zakłócenia i inżynieria społeczna zwiększają prawdopodobieństwo wykonania polecenia. 222527

Wspomniane w kontekście trendu kampanie związane z PavinLoader, EtherHiding, Amatera Stealer, fałszywymi stronami OpenAI Codex wymierzonymi w programistów korzystających z komputerów Mac oraz ACR Stealer pokazują podobieństwo technik: różne przynęty i ładunki prowadzą do wykonania działania przez użytkownika. Dostępne materiały nie dowodzą jednak, że kampania obejmująca 24 pakiety npm była prowadzona przez tego samego operatora.

Nie ma również wystarczających dowodów, aby potwierdzić operacyjny związek z rzekomą wcześniejszą kampanią Beamglea, która miała wykorzystywać 175 pakietów npm. Tego twierdzenia nie należy przedstawiać jako ustalonego faktu w odniesieniu do kampanii opisanej przez OX Security.

Najważniejszy wniosek dla bezpieczeństwa

Ten przypadek poszerza definicję zagrożenia w łańcuchu dostaw npm. Pakiet nie musi uruchamiać złośliwego kodu podczas instalacji, aby stać się użyteczny dla atakującego. Zwykły, statyczny plik HTML hostowany przez zaufany rejestr i jego mirrory może pełnić funkcję wejścia do operacji phishingowej.

Programiści i zespoły bezpieczeństwa powinni sprawdzać nieoczekiwane adresy npm oraz CDN, traktować instrukcje fałszywej weryfikacji jako próbę manipulacji, monitorować przeglądarki i punkty końcowe pod kątem podejrzanego uruchamiania poleceń oraz nie wykonywać tekstu skopiowanego ze stron internetowych. Najważniejszym sygnałem ostrzegawczym nie jest sama CAPTCHA, lecz prośba o obejście normalnych zabezpieczeń przez wklejenie i uruchomienie polecenia.