Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Nowa kampania malvertisingowa pokazuje wyraźną zmianę w sposobie dostarczania złośliwego oprogramowania. Zamiast pobierać gotowy plik wykonywalny z jednego źródła, atakujący dzielą ładunek na wiele elementów, a następnie wykorzystują funkcje przeglądarki do lokalnego złożenia finalnego pliku EXE na urządzeniu ofiary.
Taki model znacząco utrudnia wykrywanie oparte na sygnaturach, reputacji adresów URL oraz analizie pojedynczych próbek binarnych. Dla zespołów bezpieczeństwa oznacza to konieczność obserwowania całego łańcucha dostawy, a nie wyłącznie końcowego artefaktu.
W skrócie
Kampania określana jako SourTrade podszywa się pod znane platformy tradingowe i usługi związane z kryptowalutami. Jej celem jest nakłonienie użytkownika do pobrania rzekomo legalnej aplikacji, która w rzeczywistości powstaje lokalnie w przeglądarce z fragmentów dostarczanych podczas sesji.
- ładunek malware nie jest przesyłany jako pojedynczy plik EXE,
- do złożenia pliku wykorzystywane są mechanizmy Service Worker i Shared Worker,
- bazą dla finalnego pliku bywa legalny runtime Bun,
- każda sesja może prowadzić do wygenerowania innego hasha końcowego pliku,
- utrudnia to blokowanie oparte na statycznych IOC i reputacji plików.
Kontekst / historia
Operacja była obserwowana co najmniej od końca 2024 roku i była wymierzona głównie w inwestorów detalicznych oraz osoby zainteresowane aktywami cyfrowymi. Atakujący wykorzystywali reklamy prowadzące do stron imitujących legalne serwisy analityczne, giełdy, portfele kryptowalutowe i narzędzia inwestycyjne.
Kluczowym elementem kampanii było profilowanie odwiedzających. Strony docelowe analizowały środowisko użytkownika i potrafiły ukrywać właściwe działanie przed badaczami, botami oraz systemami automatycznej analizy. Tego rodzaju cloaking i selektywne dostarczanie ładunku ograniczają widoczność kampanii i wydłużają czas potrzebny na jej pełne rozpoznanie.
Badacze wskazywali, że podobne klastry zagrożeń były wcześniej łączone z kradzieżą danych, przechwytywaniem ruchu, keyloggingiem oraz zdalnym dostępem. W tym przypadku szczególną uwagę zwrócono jednak na sam mechanizm dostawy i lokalnego konstruowania pliku wykonywalnego.
Analiza techniczna
Łańcuch ataku rozpoczyna się na stronie phishingowo-reklamowej, która jeszcze przed aktywną interakcją użytkownika przygotowuje infrastrukturę potrzebną do wygenerowania pliku. Najpierw rejestrowany jest Service Worker odpowiedzialny za obsługę strumieniowanego pobierania i przygotowanie końcowego obiektu do zapisania na dysku.
Następnie uruchamiany jest Shared Worker osadzony bezpośrednio w kodzie strony. To istotny szczegół, ponieważ źródło workera nie musi występować jako osobny zasób pobierany z sieci, co ogranicza liczbę jawnych artefaktów możliwych do przechwycenia przez klasyczne systemy monitoringu.
Kolejny etap obejmuje połączenie z endpointem konfiguracyjnym, który zwraca szablon budowy pliku, adres pobrania wtórnego runtime’u oraz parametry losowe przypisane do konkretnej sesji. Przeglądarka pobiera i dekompresuje legalny runtime Bun, który staje się bazą dla finalnego pliku wykonywalnego w systemie Windows.
Konfiguracja może zawierać także zakodowane fragmenty odpowiadające za strukturę PE, tablice sekcji oraz sekcję przenoszącą złośliwy bytecode. Następnie skrypt generuje pseudolosowy strumień bajtów i scala dane pochodzące z kilku źródeł.
- legalnego runtime’u,
- lokalnie wygenerowanego strumienia pseudolosowego,
- fragmentów kontrolowanych przez atakującego.
W efekcie finalny plik EXE nie istnieje wcześniej jako pojedynczy obiekt przesyłany przez sieć. Jest składany lokalnie po stronie przeglądarki ofiary. Zmienność parametrów sesji sprawia, że nawet logicznie podobny payload może otrzymać inny hash, co osłabia skuteczność prostych reguł opartych na skrótach.
Po złożeniu pliku dane są przekazywane do Service Workera jako strumień. Następnie ukryty iframe inicjuje pobranie z adresu działającego w tym samym originie, a worker zwraca wygenerowaną zawartość z nagłówkiem wymuszającym pobranie załącznika. Mechanizm nie wymaga wykorzystania luki w przeglądarce, lecz nadużywa legalnych funkcji środowiska webowego.
Konsekwencje / ryzyko
Największe ryzyko dotyczy organizacji, które nadal w dużym stopniu polegają na detekcji statycznej. Jeżeli ochrona opiera się głównie na hashach, reputacji pojedynczych domen, analizie gotowych próbek oraz prostym filtrowaniu plików wykonywalnych, skuteczność takiego modelu może zostać wyraźnie obniżona.
Dodatkowym problemem jest użycie legalnego runtime’u i natywnych funkcji przeglądarki. Z perspektywy narzędzi ochronnych granica między aktywnością dozwoloną a złośliwą staje się mniej oczywista, zwłaszcza gdy końcowy plik nie jest nigdy pobierany w gotowej postaci.
Szczególnie narażeni są użytkownicy szukający aplikacji tradingowych, walletów i narzędzi inwestycyjnych przez sponsorowane wyniki wyszukiwania lub reklamy. Z kolei dla SOC problemem jest rozproszenie śladów między reklamą, stroną lądowania, infrastrukturą konfiguracyjną, domeną hostującą komponenty pomocnicze i samym procesem pobrania.
Rekomendacje
Skuteczna obrona przed taką kampanią wymaga monitorowania pełnego łańcucha dostawy. Sama kontrola końcowego pliku nie wystarczy, gdy malware jest składane dynamicznie w sesji przeglądarkowej.
- analizować źródła ruchu reklamowego i strony lądowania,
- monitorować rejestrację oraz aktywność Service Workerów i Shared Workerów,
- wykrywać nietypowe żądania do endpointów konfiguracyjnych,
- śledzić pobieranie runtime’ów i komponentów binarnych z domen wtórnych,
- stosować sandboxing behawioralny dla pobieranych plików,
- korelować telemetrię z przeglądarki, proxy, DNS i EDR,
- ograniczać możliwość instalacji oprogramowania z niezweryfikowanych źródeł,
- szkolić użytkowników, aby pobierali aplikacje inwestycyjne wyłącznie z oficjalnych stron dostawców.
Dla zespołów DFIR i threat huntingu istotne będzie również śledzenie artefaktów pośrednich, takich jak odpowiedzi konfiguracyjne zawierające fragmenty struktur PE, nietypowe użycie Bun w kontekście webowym oraz wzorce strumieniowego generowania plików po stronie klienta.
Podsumowanie
Opisana kampania pokazuje, że współczesny malvertising przestaje być prostym przekierowaniem do gotowego malware. Atakujący coraz częściej dzielą ładunek na etapy, wykorzystują legalne komponenty i przenoszą część procesu budowy pliku do przeglądarki ofiary.
Dla obrońców oznacza to konieczność przejścia od statycznych IOC do szerszej analizy behawioralnej, korelacji telemetrii i monitorowania pełnego łańcucha dostawy. Bez takiego podejścia rośnie ryzyko, że końcowy malware pozostanie niewidoczny aż do momentu uruchomienia na stacji użytkownika.