Blockchain jako element infrastruktury cyberprzestępczej. Analiza kampanii ClickFix wykorzystującej sieć Polygon.

Przez wiele lat infrastruktura kampanii malware opierała się na klasycznym modelu wykorzystującym domeny oraz serwery C2 kontrolowane bezpośrednio przez operatorów. Rozwój technik detekcji, automatyzacji sinkholingu oraz szybkiego blokowania domen sprawił jednak, że utrzymanie stabilnej infrastruktury stało się coraz trudniejsze. W odpowiedzi grupy cyberprzestępcze zaczęły poszukiwać nowych metod ukrywania elementów swojej infrastruktury. Jednym z obserwowanych trendów jest wykorzystanie technologii blockchain nie jako mechanizmu finansowego, lecz jako odpornego na zakłócenia źródła konfiguracji kampanii.

W analizowanej operacji blockchain sieci Polygon został wykorzystany jako rozproszony magazyn informacji, umożliwiający dynamiczne wskazywanie aktualnych adresów infrastruktury kontrolowanej przez atakujących. Rozwiązanie to pozwala na zmianę backendu kampanii bez konieczności modyfikowania kodu osadzonego na zainfekowanych stronach internetowych.

Niniejszy artykuł przedstawia pełny łańcuch infekcji – od kompromitacji legalnych witryn, przez wykorzystanie techniki ClickFix, aż po pozyskanie konfiguracji z wykorzystaniem smart contractu działającego w sieci Polygon.

Kompromitacja stron internetowych jako punkt wejścia

Łańcuch infekcji rozpoczyna się od przejęcia legalnych stron internetowych (najczęściej przy użyciu podatności w systemach CMS). Uzyskany dostęp nie był wykorzystywany do klasycznego defacementu lub bezpośredniego hostowania malware. Zamiast tego atakujący wstrzykiwali do publikowanych artykułów fragment kodu JavaScript odpowiedzialny za inicjalizację kolejnych etapów infekcji. Takie podejście zapewnia wysoką skuteczność kampanii. Użytkownik odwiedza bowiem legalną, zaufaną stronę internetową, której reputacja nie budzi podejrzeń ani po stronie ofiary, ani po stronie rozwiązań ochronnych.

W jednym z przypadków zwróciliśmy uwagę na fakt zaatakowania jednej strony przez dwóch różnych operatorów, z których każdy umieścił w jej kodzie niemal ten sam skrypt. Jedyną różnicą była subtelna zmiana w konfiguracji loadera, którą opiszemy w dalszej części. Kod umieszczony na stronach został celowo ukryty przed analizą poprzez zastosowanie kilku warstw obfuskacji. Pierwsza warstwa wykorzystuje kodowanie Base64, natomiast druga realizuje dodatkowe szyfrowanie danych przy użyciu operacji XOR.

Już na tym etapie można zauważyć charakterystyczne podejście autorów kampanii. Obfuskacja nie ma na celu zapewnienia wysokiego poziomu ochrony kryptograficznej. Jej zadaniem jest raczej utrudnienie masowej analizy, ograniczenie skuteczności sygnatur oraz ukrycie najbardziej interesujących elementów infrastruktury.

Dopiero po odszyfrowaniu ukazuje się właściwy loader odpowiedzialny za komunikację z dalszymi komponentami kampanii.

Dostarczenie loadera JavaScript

Loader został zaprojektowany jako niewielki moduł inicjalizacyjny, którego głównym zadaniem jest dynamiczne pobranie właściwego komponentu z infrastruktury operatora. Nie zawiera on docelowego payloadu, pełniąc jedynie rolę pośrednika między zainfekowaną przeglądarką a serwerem sterującym.

Pierwszym etapem działania jest zabezpieczenie przed wielokrotnym uruchomieniem poprzez ustawienie globalnej zmiennej __BW_SCRIPT_INITIALIZED__. Dzięki temu skrypt nie zostanie wykonany ponownie, nawet w przypadku wielokrotnego załadowania na tej samej stronie.

Istotnym elementem jest wykorzystanie blockchaina Polygon jako zdecentralizowanego mechanizmu przechowywania konfiguracji. Loader wysyła zapytanie eth_call do jednego z kilkunastu publicznych węzłów RPC Polygon i odczytuje wynik funkcji wskazanej przez selektor b68d1809. Zwrócona wartość zawiera nazwę domeny lub adres serwera panelu kontrolnego. Takie rozwiązanie utrudnia przejęcie infrastruktury przez obrońców, ponieważ adres C2 nie jest zapisany bezpośrednio w kodzie.

Rys. 1. Konfiguracja loadera.

Po uzyskaniu adresu panelu loader buduje zestaw endpointów API odpowiedzialnych za pobieranie konfiguracji (cfg), inicjalizację sesji (init), pobieranie modułów (js) oraz raportowanie zdarzeń (evt). Komunikacja z tym API jest dodatkowo ukrywana za pomocą własnego mechanizmu szyfrowania.

Kod implementuje kilka funkcji kryptograficznych. Zawiera obsługę RC4, SHA-256 oraz AES-GCM. Dane przesyłane do serwera są pakowane do parametrów URL w postaci zaszyfrowanych blobów Base64URL. Odpowiedzi API mogą być odszyfrowywane zarówno przy użyciu starszego mechanizmu oznaczonego jako q2, jak i nowszego wariantu gcm1 wykorzystującego AES-GCM.

Po pobraniu konfiguracji loader dynamicznie wybiera jeden z wielu trybów działania. Zdefiniowane są między innymi moduły browser, font, recaptcha, cloudflare, cf_update, mac_recaptcha oraz mac_cloudflare. Oznacza to, że faktyczna funkcjonalność jest dostarczana dopiero na późniejszym etapie i może być dostosowywana do systemu operacyjnego, przeglądarki lub rodzaju kampanii.

Następnie wykonywana jest funkcja loadModeScript(), która pobiera kolejny skrypt JavaScript z endpointu API. Loader nie zawiera tego kodu lokalnie – jest on dostarczany na żądanie z infrastruktury operatora. Takie podejście pozwala na szybką wymianę payloadów bez konieczności modyfikowania samego loadera.

Kod posiada również mechanizm telemetryczny. Funkcja logEvent() wysyła do serwera informacje o zdarzeniach związanych z wykonaniem kampanii. Pozwala to operatorom monitorować skuteczność infekcji, błędy oraz aktywność ofiar.

Analizowany kod to typowy stager/loader JavaScript. Jego główne cechy to: wykorzystanie blockchaina do przechowywania konfiguracji C2, szyfrowana komunikacja z API, dynamiczne pobieranie kolejnych modułów oraz możliwość szybkiej rotacji infrastruktury poprzez zmianę smart contractu i kluczy kryptograficznych. Jedyna funkcjonalna różnica pomiędzy analizowanymi próbkami wskazuje na wykorzystanie dwóch różnych kampanii lub dwóch niezależnych instancji tej samej infrastruktury.

Porównując różne wersje loadera, można zauważyć dwie istotne różnice.

Pierwsza to adresy smart contractów:

CONTRACT_ADDRESS:'0x994Cb8274721E5d6dAA4fE3FeBf80CF9237A9ae8'
CONTRACT_ADDRESS:'0x9130ec7e8B20646ad30E1386d1b45Cd26EB0e07b'

Loader wykorzystuje blockchain Polygon jako mechanizm przechowywania aktualnego adresu serwera C2/panelu administracyjnego. Zmiana adresu kontraktu pozwala operatorom przenieść infrastrukturę bez konieczności modyfikowania samego loadera.

Drugą różnicą jest klucz API_Q2_KEY_HEX:

49f1213251b35c468ae5699c3715b4f16bde9910c9e17b7b33ffd23e02c9fc05
26acb2471fd8f8bbde422096c50e439a5542fe4725f06158c57bd8367aae040e

Jest to 256-bitowy klucz wykorzystywany do szyfrowania i odszyfrowywania komunikacji z API. Zmiana tego klucza powoduje, że każdy loader komunikuje się z własnym zestawem danych konfiguracyjnych oraz może obsługiwać odrębne kampanie.

Blockchain jako mechanizm odnajdywania infrastruktury

Najciekawszym elementem analizowanego przypadku jest sposób pozyskiwania adresu serwera wykorzystywanego przez operatorów.

Loader zawiera jedynie adres smart contractu działającego w sieci Polygon oraz identyfikator funkcji, która ma zostać wywołana. Następnie wykonywane jest zapytanie do kontraktu za pośrednictwem jednego z czternastu publicznych węzłów RPC. W rezultacie przeglądarka ofiary nie komunikuje się początkowo z serwerem kontrolowanym przez przestępców. Zamiast tego odczytuje informacje zapisane w blockchainie. Dopiero odpowiedź zwrócona przez smart contract zawiera aktualny adres infrastruktury wykorzystywanej przez operatorów kampanii. Oznacza to, że blockchain pełni funkcję zdecentralizowanego systemu rozgłaszania konfiguracji.

Paradoksalnie wykorzystanie blockchaina zwiększa również możliwości analityczne obrońców, ponieważ historia zmian konfiguracji pozostaje publicznie dostępna i może być korelowana pomiędzy kampaniami.

Rys. 2. Domeny C2 zapisane w kontrakcie.

Zalety wykorzystania blockchaina z perspektywy atakujących

Takie rozwiązanie przynosi operatorom szereg korzyści.

Przede wszystkim adres serwera C2 nie jest zapisany bezpośrednio w kodzie JavaScript umieszczonym na zainfekowanych stronach. Analiza pojedynczej próbki nie pozwala więc natychmiast zidentyfikować aktywnej infrastruktury.

Dodatkowo zmiana backendu kampanii wymaga jedynie aktualizacji danych zapisanych w kontrakcie. Nie jest konieczna ponowna kompromitacja stron internetowych ani aktualizacja loadera.

Atakujący zyskują również dodatkową odporność na działania obronne. Nawet jeśli część domen zostanie zablokowana lub przejęta, wszystkie aktywne implanty nadal mogą odnaleźć nową infrastrukturę przez odczyt danych z blockchaina. Potwierdzeniem tej funkcjonalności jest analiza zapisów w blockchainie (rys. 2). Dokładnie widać kolejne domeny wykorzystywane przez tego operatora. 

Analiza obu kontraktów wykazała, że są one powiązane z tym samym podmiotem identyfikowanym w platformie analitycznej blockchain. W połączeniu z niemal identycznym kodem loadera, sposobem komunikacji z backendem oraz analogiczną logiką działania dowodzi to, że obie kampanie były obsługiwane przez tego samego operatora lub tę samą infrastrukturę operacyjną. Dzięki temu możliwe było rozszerzenie analizy o inne kontrakty i transakcje powiązane z tym samym podmiotem, co pozwoliło na identyfikację dodatkowych elementów infrastruktury wykorzystywanej w kampaniach, w tym konfiguracji powiązanych z kolejnymi operacjami.

Rys. 3. Aktywność „kontraktowa” threat actora.

W efekcie smart contract pełni funkcję zdecentralizowanego mechanizmu dystrybucji konfiguracji, który pod względem operacyjnym realizuje część celów osiąganych tradycyjnie przez DGA i fast-flux.

Od blockchaina poprzez ClickFix do malware typu infostealer

Po uzyskaniu aktualnej konfiguracji z blockchaina loader pobiera dalsze komponenty, w tym konfigurację oraz zakodowany skrypt PowerShell (rys. 4).

W analizowanych kampaniach widoczny jest parametr bc (Blocked Countries), który jest używany przez moduł v3.js (recaptcha) do geofiltrowania ofiar. Oznacza to, że użytkownicy z tych krajów (Rosja, Białoruś, Ukraina, Kazachstan, Azerbejdżan, Gruzja, Armenia) nie są obejmowani kampanią i mogą otrzymywać alternatywną lub nieszkodliwą zawartość. Takie wykluczenie jest powszechnie spotykane u cyberprzestępców działających z Rosji, operatorów MaaS (Malware-as-a-Service), grup ransomware oraz operatorów infostealerów (Lumma, StealC, Rhadamanthys, Vidar itp.).

W dalszej części, po spełnieniu warunków, ofierze prezentowana jest Fake CAPTCHA. Atak wykorzystuje technikę ClickFix, która w ostatnim czasie stała się jednym z najpopularniejszych mechanizmów dostarczania malware. Jej skuteczność wynika z faktu, że użytkownik sam wykonuje działania prowadzące do uruchomienia złośliwego kodu.

Rys. 4. Skrypt wraz z konfiguracją (pobrany z serwera C2).

Rys. 5. Zdekodowany skrypt pobrany z serwera C2.

Ofiara otrzymuje komunikat przypominający mechanizmy weryfikacyjne Cloudflare lub CAPTCHA. Następnie proszona jest o wykonanie kilku prostych kroków prowadzących do nieświadomego uruchomienia polecenia systemowego (rys. 6).

Rys. 6. Fałszywa CAPTCHA wraz z prezentowanym poleceniem systemowym.

W przeciwieństwie do klasycznych exploitów atak nie wykorzystuje podatności w systemie operacyjnym. Zamiast tego wykorzystuje zaufanie użytkownika oraz jego aktywny udział w procesie infekcji.

Analizowana linia polecenia uruchamia interpreter cmd.exe, który za pomocą narzędzia curl pobiera plik wykonywalny z adresu hxxps://framesavecloudjs[.]beer/api/index.php?a=ex&i=36ec115d30a81048634ec26be52da8d7aedab9624adecd23673e37c2c6f9c0ce i zapisuje go w katalogu tymczasowym systemu Windows pod nazwą vxs.exe. Następnie pobrany plik jest uruchamiany w tle przy użyciu polecenia start /b, co minimalizuje widoczność procesu dla użytkownika. Parametr i zawiera unikalny identyfikator kampanii lub sesji wykorzystywany przez serwer do zwrócenia odpowiedniego ładunku, natomiast znak ^ przed & służy do poprawnej interpretacji polecenia przez interpreter CMD oraz może utrudniać wykrywanie przez proste mechanizmy detekcji. Końcowa część rem Verification code: B9B94A20DBF5 jest wyłącznie komentarzem i nie wpływa na wykonanie kodu – pełni rolę socjotechniczną, imitując kod weryfikacyjny prezentowany użytkownikowi w fałszywym oknie CAPTCHA lub komunikacie bezpieczeństwa. W efekcie jedynym celem skryptu jest pobranie zdalnego pliku wykonywalnego i jego uruchomienie na systemie ofiary.

Finalnym etapem analizowanego łańcucha infekcji jest instalacja na komputerze ofiary malware typu infostealer. Jest to popularne złośliwe oprogramowanie specjalizujące się w kradzieży danych uwierzytelniających, zapisanych haseł, plików cookie, tokenów sesyjnych, danych kart płatniczych oraz informacji z portfeli kryptowalut.

Taka architektura wskazuje na wykorzystanie modelu Malware-as-a-Service (MaaS), w którym początkowy łańcuch infekcji jest oddzielony od końcowego ładunku. Dzięki temu operatorzy mogą dynamicznie zmieniać dostarczane złośliwe oprogramowanie bez konieczności modyfikowania infrastruktury wykorzystywanej do dystrybucji, dostosowując kampanię do bieżących celów i potrzeb.

Wnioski

Analizowana kampania pokazuje ewolucję współczesnych operacji cyberprzestępczych w kierunku coraz większej modularności infrastruktury. Blockchain nie jest tutaj wykorzystywany jako kanał komunikacji z malware ani mechanizm finansowania działalności. Jego rola sprowadza się do funkcji odpornego na zakłócenia repozytorium konfiguracji, umożliwiającego dystrybucję aktualnych adresów infrastruktury operacyjnej. Analizowana kampania pokazuje, że technologie blockchain coraz częściej pełnią rolę elementów infrastruktury operacyjnej, a nie wyłącznie środka transferu wartości.

Takie podejście znacząco utrudnia działania obronne, ponieważ eliminacja pojedynczej domeny lub serwera nie prowadzi do unieszkodliwienia całego łańcucha infekcji. Jednocześnie wykorzystanie publicznej infrastruktury blockchain powoduje, że ruch generowany przez malware częściowo miesza się z legalnym ruchem sieciowym. Jest to przykład rosnącego trendu polegającego na wykorzystywaniu technologii zdecentralizowanych jako elementów infrastruktury cyberprzestępczej, a nie wyłącznie jako mechanizmów finansowych. To właśnie ten aspekt należy uznać za najbardziej interesujący element techniczny całej kampanii.

Piotr Chęciński
Bartłomiej Zieliński
Ireneusz Tarnowski