Operacyjna analiza kanałów komunikacyjnych mobilnego RCS’a

cert.orange.pl 23 godzin temu

Analiza przedstawia próbkę mobilnego malware wykorzystywanego w działaniach ukierunkowanych, w których priorytetem nie jest skala infekcji, ale pełna, długotrwała kontrola nad jednym urządzeniem ofiary. Przedstawiony kod łączy w sobie cechy spyware klasy operatorskiej – rozbudowaną telemetrię, wysoką świadomość środowiska, komunikację C2 wykorzystującą chmurę – oraz komponent dostępu w czasie rzeczywistym, realizowany przez tunel Fast Reverse Proxy. W raporcie pokazano, jak pozornie zwykła aplikacja staje się nośnikiem trwałego kanału kontroli, działającego z wykorzystaniem infrastruktury Google i zwrotnych tuneli.

Aplikacja

Początkowy wektor ataku sprawia, iż wygląda on na powszechną kampanię, jakie są w tej chwili prowadzone. Adwersarz, poprzez socjotechnikę, zachęca wybraną ofiarę do pobrania i zainstalowania aplikacji mobilnej (podszywającej się pod inną zaufaną aplikację). Pobierana, w postaci pliku apk, aplikacja jest typowym dropperem. Dropper to rodzaj złośliwej aplikacji, której zadaniem jest dostarczenie i uruchomienie ukrytego w sobie lub na urządzeniu payloadu, zwykle w postaci jednorazowego rozpakowania lub rozkodowania wbudowanego malware. W tym przypadku ma on za zadnie uzyskać akceptacje niezbędnych uprawnień od użytkownika (poprzez zaprezentowanie ekranów z zaufanej aplikacji) po czym instaluje i uruchamia drugą aplikację (stage 2), pobieraną z lokalizacji \assets\apk\target.apk.

Zainstalowana aplikacja w istocie jest kolejnym dropperem. Analiza tej fazy ataku nie zdradza funkcjonalności tej aplikacji i na pozór nie widać w niej nic złośliwego. Na tym etapie następuje pobranie z zasobów aplikacji pliku o rozszerzeniu json (plik posiada entropię równą 7.99, co wskazuje na wysokie upakowanie lub zaszyfrowanie; w istocie jest on kontenerem zawierającym zaszyfrowaną bibliotekę dex dołączaną do adekwatnej aplikacji). Plik jest zaszyfrowany symetrycznym szyfrem strumieniowym RC4 (KSA/PRAGA). Klucz do odszyfrowania jest łatwy do zlokalizowania w zdeasemblowanym kodzie. Po odszyfrowaniu uruchamiane są funkcje ukryte uprzednio w tej bibliotece. A są to takie funkcjonalności jak:

Rejestrowanie i przekazywanie obrazu w czasie rzeczywistym (screen streaming)
Zdalne zarządzanie urządzeniem (VNC / RDP over Accessibility, real-time operator control)

Początkowo program był identyfikowany jako RAT, jednak analizując funkcjonalności i zarządzanie programem, można było dojść do wniosku, iż jest to złośliwa aplikacja będąca zaawansowanym spyware (RCS – Remote Control System).

W trakcie analizy zidentyfikowano wielowarstwową architekturę komunikacji typu command-and-control (C2), zaprojektowaną w sposób umożliwiający długotrwałe, skryte oraz manualnie sterowane utrzymanie dostępu do zainfekowanego urządzenia. Model komunikacji opiera się na rozdzieleniu funkcji sygnalizacji, orkiestracji zadań (zarządzania) od interaktywnego dostępu zdalnego, co pozwala na ograniczenie widoczności ruchu sieciowego oraz obejście klasycznych mechanizmów detekcji opartych na analizie beaconingu.

Dalsza część analizy skupia się na tym nieoczywistym sposobie komunikacji złośliwej aplikacji. Przedstawiono działanie komponentu komunikacyjnego, sposób inicjowania połączenia z serwerem kontrolującym oraz obserwowane artefakty świadczące o przygotowaniu do długotrwałej obecności na urządzeniu.

Command and Control

Centralnym elementem infrastruktury jest serwer Command and Control (C2) dostępny przez protokół HTTPS, pełniący funkcję rejestru urządzeń, repozytorium konfiguracji oraz punktu koordynacji zadań. C2 jest bezpośrednio obsługiwany przez operatora, który w ręczny sposób inicjuje działania oraz zarządza sesjami dostępowymi do poszczególnych urządzeń. Komunikacja pomiędzy operatorem a złośliwą aplikacją odbywa się przy użyciu standardowych interfejsów webowych lub API, co utrudnia jednoznaczną identyfikację złośliwej aktywności na poziomie ruchu sieciowego.

Po stronie zainfekowanego urządzenia, to klasa BackendApi zarządza pełną komunikacją urządzenia z serwerem C2 operatora. Moduł ten realizuje m.in.:

rejestrację urządzenia w panelu adwersarza,
heartbeat,
pobieranie (poolingiem) komend,
wysyłanie zdarzeń pojedynczych i wsadowych (batch),
upload list aplikacji,
pobieranie informacji o systemie,
wysyłanie identyfikatorów oraz całej telemetrii.

Widać tutaj implementację stabilnego identyfikatora urządzenia (generateStableDeviceId) – opartą na android_id. Metoda ta generuje stały tracking ID, który wykorzystywany jest przez cały czas w trakcie działania aplikacji. Na początku zbierane są dane środowiskowe, tj:

poziom i status ładowania baterii,
typ połączenia sieciowego,
aplikacje działające w tle (foreground application),
listy zainstalowanych aplikacji,
informacje o karcie SIM (karta, operator, numer telefonu – jeżeli możliwe),
informacje o pamięci urządzenia,
informacje o stanie ekranu,
IP zewnętrzne.

Jest to profilowanie urządzenia przed dalszą eksploitacją oraz wdrożeniem zdalnego zarządzania (RMM). Tak precyzyjne profilowanie ofiary jest typowe dla wąskiej grupy ataków, w której atakujący dokonuje dalszych etapów infekcji w zależności od tego kto jest ofiarą. Unika w ten sposób przypadkowych infekcji i zwiększa szansę na pozostanie w ukryciu.

W przypadku kontynuacji ataku, adwersarz z serwera C2 przekazuje konfigurację tunelu Fast Reverse Proxy (FRP), który następnie pozwala mu na dostęp do urządzenia. Parametry FRP (adres serwera, port, token) dostarczane są dynamicznie w czasie działania aplikacji (tzw. runtime) i nie są na stałe zapisane w aplikacji (hardcodowane). Mechanizmy polling i heartbeat umożliwiają operatorowi regularne wysyłanie poleceń oraz zbieranie informacji telemetrycznych o urządzeniu, w tym listę aplikacji, stan baterii, typ połączenia sieciowego, informacje o pamięci i SIM oraz aktualnie aktywnej aplikacji. Tunel FRP, natomiast, jest inicjowany wyłącznie po otrzymaniu konfiguracji z backendu złośliwej aplikacji i w konsekwencji pozwala na interakcję operatora z urządzeniem, przy czym serwer FRP znajduje się w infrastrukturze atakującego poza urządzeniem i kanałem HTTPS.

FCM – Firebase Cloud Messaging

Do realizacji kanału sygnalizacyjnego wykorzystywana jest usługa Firebase Cloud Messaging (FCM). Jest to usługa Google przeznaczona do asynchronicznego dostarczania komunikatów push do aplikacji mobilnych oraz klientów webowych. W legalnych zastosowaniach służy do wysyłania powiadomień, synchronizacji danych lub wyzwalania akcji aplikacji bez konieczności utrzymywania stałego połączenia sieciowego. Z technicznego punktu widzenia FCM działa jako broker komunikatów, w którym aplikacja po instalacji rejestruje się w infrastrukturze Google i otrzymuje unikalny token lub subskrybuje określony temat (topic). Serwer aplikacji wysyła komunikaty do Google, a Google dostarcza je do adekwatnych urządzeń, choćby jeżeli aplikacja nie jest aktywna, a telefon znajduje się w stanie uśpienia. Kluczową cechą FCM jest to, iż ruch sieciowy odbywa się wyłącznie pomiędzy urządzeniem a infrastrukturą Google, co powoduje, iż z perspektywy sieci i systemów bezpieczeństwa komunikacja wygląda jak w pełni legalny ruch systemowy Androida.

Dla funkcjonalności FCM, w klasie konfiguracyjnej (rys. 1), umieszczono najważniejszy parametr:

private static final String FCM_TOPIC = „device_commands”;

Oznacza to, iż aplikacja subskrybuje globalny temat FCM, a nie indywidualny token. Każde urządzenie, na którym aplikacja jest zainstalowana, dołącza do tego samego logicznego kanału komunikacji. W praktyce oznacza to, iż operator C2 może wysłać jedno polecenie, które zostanie dostarczone przez Google do dowolnej liczby zainfekowanych urządzeń, bez bezpośredniego łączenia się z nimi.

FCM w tym rozwiązaniu nie służy do przesyłania danych operacyjnych, ale do asynchronicznej sygnalizacji sterującej. Operator C2 wysyła push do urządzenia (poprzez usługę i infrastrukturę Google), który jest odbierany w onMessageReceived(), a otrzymany w push’u JSON jest zamieniany na wewnętrzny identyfikator polecenia. Następnie następuje mapowanie JSON → metoda executeXYZ(), czyli bezpośrednie przeniesienie kodu rozkazującego na konkretne moduły funkcjonalne malware. Każde z wywołań nie tylko uruchamia jednostkową akcję, ale również aktywuje lub rekonfiguruje podsystemy trwałości i nadzoru: inicjalizację FRPC, odświeżenie rejestracji klienta, konfigurację warstwy overlay, kanał WebSocket, uwierzytelnienie tunelu, screen-stream, heartbeat, system logowania zdarzeń. W efekcie FCM pełni rolę kanału sygnalizującego klasy „wake+task”, w którym push nie przenosi komendy operacyjnej, ale sygnalizuje konieczność pobrania jej z Backend API – to zapewnia oszczędność energii, redukuje ślad sieciowy, eliminuje cykliczne połączenia DNS/HTTP i znacząco podnosi poziom ukrycia (stealth mode).

Mając taki model, C2 dysponuje kategoriami komend sterowanych przez FCM, które dają pełne pokrycie funkcjonalne urządzenia. Komendy komunikacyjne (np. executeEnableWebSocket() czy executeDisableWebSocket()) pozwalają włączać i wyłączać WebSocket oraz tunel FRPC, a więc sterować kanałem zdalnego dostępu. Komendy dotyczące ciągłości łączności (heartbeat, polling) zapewniają fallback i utrzymywanie sesji bez telemetrii okresowej. Komendy instrumentacyjne inicjują żądania uprawnień, restart usług Accessibility lub MediaProjection oraz „wybudzenie” aplikacji na front UI. Segment screen-capture pozwala włączać/wyłączać usługę przechwytywania ekranu i obsługiwać overlay umożliwiający kliknięcia przestępcy. Event-logger to kolejna warstwa klasy operatorskiej – konfiguracja logowania, pobieranie liczników, flush zdarzeń – czyli przydatna telemetria. Wreszcie, polecenia statusowe (executePing(), updateCommandStatus()) utrzymują pętlę zgłaszania stanu, co stanowi dla operatora quasi-RTT (Round-Trip Time).

Jednym z kluczowych elementów jest uruchomienie klienta FRP (frpc – Fast Reverse Proxy Client), który zestawia połączenie wychodzące typu reverse tunnel do serwera pośredniczącego (frps – Fast Reverse Proxy Server) kontrolowanego przez operatora. Tunel ten umożliwia zdalny, interaktywny dostęp do funkcji urządzenia bez konieczności wystawiania jakichkolwiek portów po stronie ofiary. Całość komunikacji realizowana jest jako połączenie wychodzące z urządzenia, co pozwala ominąć zapory sieciowe oraz ograniczenia NAT.

To jest dokładnie ten model, który obserwujemy w zaawansowanych rodzajach malware mobilnego i narzędziach klasy komercyjnego spyware, gdzie push zastępuje stałe połączenia TCP i minimalizuje artefakty, logi oraz możliwość detekcji przez rozwiązania sieciowe.

FRP – Fast Reverse Proxy

Po otrzymaniu zdalnej komendy z FCM, aplikacja najpierw kontaktuje się z BackendAPI operatora, ponieważ to ono pełni funkcję kontrolną i rozdziela konfigurację sieciową dla kanałów zdalnego dostępu. W ramach tej komunikacji pobierany jest aktualny profil konfiguracyjny dla FRP, obejmujący adres serwera FRPS, porty, typ tunelu, klucze autoryzacyjne oraz ewentualne parametry dotyczące protokołu WebSocket wykorzystywanego do transmisji ekranu lub ruchu sterującego. Sam klient FRPC nie jest kompilowany w kodzie aplikacji – zostaje wydobyty z zasobów jako zakodowany plik binarny, po czym zostaje zdekodowany i zapisany jako wykonywalny plik, co pozwala uruchomić go poza cyklem życia aplikacji malware (rys. 2).

Gdy binarka klienta proxy jest już przygotowana, aplikacja uruchamia FRPC jako osobny proces systemowy – po to, by utrzymać stały tunel choćby wtedy, gdy Android zabije proces nadrzędny. Ten proces nawiązuje pierwotne połączenie do serwera FRPS zgodnie z otrzymanymi parametrami i natychmiast przekazuje operatorowi swój status uwierzytelnienia. W rezultacie dochodzi do rejestracji klienta po stronie serwera FRPS, co pozwala operatorowi widzieć infekcję jako dostępne urządzenie z unikalnym identyfikatorem. FRPC przechodzi następnie w stan idle / keep‑alive, czyli utrzymuje kanał sterujący, ale nie tworzy jeszcze aktywnego ruchu reverse‑proxy, dopóki operator nie zażąda sesji.

W tej fazie urządzenie oczekuje na zdalne zestawienie połączenia odwrotnego, a więc na sytuację, w której to serwer FRPS otworzy wejściowy port i poprowadzi ruch w dół tunelu wprost do telefonu. Gdy operator wyśle taką inicjację, FRPC zestawia konkretny tunel – TCP, WebSocket, RDP‑like, ADB-over‑TCP lub ekranowy streaming – i mapuje go na lokalny port w telefonie. Ponieważ tunel działa jak router portów, aplikacja nie musi mieć logicznych funkcji RAT – operator może podpiąć dowolne narzędzia, które działają lokalnie w systemie, np. WebDriver Accessibility, MediaProjection do obrazu ekranu, key‑overlay lub terminal.

W dalszym przebiegu tunel jest utrzymywany przez heartbeat FRP, co w praktyce oznacza ciągłe podtrzymywanie łącza bez konieczności beaconingu przez malware. o ile kanał ulegnie przerwaniu, binarka sama wykona reconnect, a jeżeli system zabije proces, aplikacja znów wystartuje go przez usługę rezydencyjną. To końcowo prowadzi do sytuacji, w której telefon pozostaje w pełni dostępny dla operatora jako zasób sieciowy, gotowy do manualnego sterowania.

Zestawiony tunel FRP stanowi główny kanał operacyjny, wykorzystywany do prowadzenia sesji zdalnych, w tym sterowania interfejsami systemowymi, przechwytywania obrazu ekranu, interakcji z aplikacjami oraz realizacji dalszych działań postkompromitacyjnych. Operator uzyskuje dostęp do urządzenia poprzez infrastrukturę FRP, a nie bezpośrednio, co dodatkowo utrudnia atrybucję oraz analizę topologii ataku. Wszystkie zidentyfikowane połączenia sieciowe inicjowane są wyłącznie z poziomu zainfekowanego urządzenia. Nie zaobserwowano mechanizmów nasłuchowych ani bezpośrednich połączeń przychodzących. Komunikacja z infrastrukturą Google (FCM), backendem C2 oraz serwerem FRP realizowana jest z użyciem powszechnie stosowanych protokołów i usług chmurowych, co pozwala na skuteczne maskowanie złośliwego ruchu w legalnym tle sieciowym.

Choć malware utrzymuje klasyczny kanał HTTPS z Backend API – wykorzystywany głównie do pobierania konfiguracji, potwierdzania komend, aktualizacji parametrów sesji i raportowania statusów – ten kanał nie jest warstwą transakcyjną dla zdalnego sterowania urządzeniem. Backend API pełni rolę sygnalizacyjną i administracyjną (kontrola, telemetria, rejestracja urządzenia), natomiast funkcję rezydencyjną i operacyjną przenosi dedykowany proces FRPC, uruchamiany jako osobny proces i utrzymujący stały kanał typu reverse‑proxy. W efekcie komunikacja dzieli się na trzy warstwy: FCM jako „asynchroniczny budzik”, BackendAPI jako panel administracyjny malware oraz FRP jako adekwatny kanał operacyjny, który materializuje dostęp zdalny do urządzenia.

Podsumowanie

Zastosowana architektura, obejmująca separację kanałów komunikacji, wykorzystanie zewnętrznej infrastruktury chmurowej do sygnalizacji oraz manualnie sterowany dostęp interaktywny, wskazuje na zaawansowany charakter operacji. Tego typu rozwiązania są typowe dla działań ukierunkowanych, prowadzonych z udziałem operatora, a nie dla masowych kampanii zautomatyzowanego złośliwego oprogramowania. W przypadku tego malware nie podjęto się przeprowadzenia atrybucji. Zidentyfikowana kampania charakteryzuje się cechami operacji o podwyższonym stopniu ukierunkowania i planowania, co uzasadnia klasyfikację zagrożenia jako APT-grade malware. W analizowanym przypadku operator nie opiera się na dystrybucji masowej, ale prowadzi działania wymagające precyzyjnej kontroli nad pojedynczym urządzeniem. Mechanizm komunikacji oparty o kanał zwrotny, dynamiczne pobieranie parametrów pracy oraz możliwość tunelowania FRP wskazują na operacyjną potrzebę utrzymywania długotrwałego, nieobserwowalnego dostępu, typowego dla tradecraftu grup APT lub zaawansowanych cyber-crime-as-a-service.

Na poziomie infrastrukturalnym obserwowana domena była aktywna jedynie przez ok. 10 dni, została zarejestrowana, stworzono dla niej certyfikat SSL i po zakończeniu fazy operacyjnej wyrejestrowana. Taka sekwencja – krótkie okno ekspozycji (eksploatacji), wymuszenie szyfrowania komunikacji, szybkie porzucenie zasobu – odpowiada modelowi szybkiej, jednorazowej infrastruktury typu „burn-after-use”, stosowanej w kampaniach, które zakładają ryzyko deanonimizacji operatora. Nie jest to charakterystyka działań typowych dla niskiego szczebla cyberprzestępczości, która wykorzystuje domeny (często tanie i długoletnie) i ją porzuca, panele gotowe lub rotację ograniczoną kosztowo. Tutaj widoczny jest koszt operacyjny i intencja zacierania śladów.

Wektor komunikacji dowodzi, iż oprogramowanie nie jest standardem trojana, ale stanowi mechanizm dostępowo-wywiadowczy. Aplikacja utrzymuje kontrolę operatorską poprzez FCM push do urządzenia, wykonuje telemetryczne heartbeat, pobiera konfigurację C2, a następnie aktywuje klienta Fast Reverse Proxy z parametrami dystrybuowanymi dynamicznie. Rezultatem jest dwukierunkowy kanał do wnętrza ekosystemu użytkownika, z możliwością ekspozycji usług lokalnych bez konieczności posiadania publicznego IP po stronie ofiary.

Próbki są generowane i modyfikowane per-install, konfiguracja FRP pobierana jest za każdym razem w modelu efemerycznym, a domeny i certyfikaty charakteryzują się krótką żywotnością. Cechy te uniemożliwiają budowanie tradycyjnych sygnatur detekcyjnych i dodatkowo sugerują aktora stosującego operational security, obliczoną rotację infrastruktury i minimalizację śladów wykrywalnych retrospektywnie. W konsekwencji analizowany kod nie jest klasycznym malware commodity, ale narzędziem zdolnym do precyzyjnego sterowania urządzeniem, ukrytej łączności i kontroli operatorskiej – parametry te lokują go w spektrum TTP wykorzystywanych przez grupy APT lub podmioty komercyjnie świadczące takie zdolności.

W kontekście atrybucji warto odnotować, iż próbka prezentuje dwa wyraźnie odmienne modele podejścia do zaciemniania kodu – i oba odbiegają od standardowych praktyk dla mobilnego malware. Po odszyfrowaniu głównego komponentu aplikacja zachowuje spójną i czytelną strukturę: utrzymano jawne nazwy klas, metod i zmiennych, nie widać śladów automatycznej obfuskacji, a część modułów implementuje lokalne mechanizmy logowania zdarzeń do plików, co jest rzadkością w kodzie pisanym z myślą o ukrywaniu aktywności. Taki profil sugeruje wysoki poziom kompetencji programistycznych oraz nawyki charakterystyczne raczej dla profesjonalnego wytwarzania systemu niż dla kodu pisanego wyłącznie pod dystrybucję malware. Jednocześnie inna warstwa aplikacji – obejmująca „silnik” operacyjny i zależności konstrukcyjne – jest już obfuscowana: klasy pozbawione są semantycznych nazw, występują struktury z automatycznie generowanymi identyfikatorami pól i mapowaniami (SparseIntArray → indeks → wartość), co utrudnia rekonstrukcję przepływu logicznego. Takie rozbieżności wskazują na proces rozwojowy, w którym część kodu mogła zostać przeniesiona z istniejącej, legalnej bazy wykonawczej (lub utrzymana przez doświadczonych programistów), a dopiero elementy operacyjne – odpowiedzialne za wiązania klas, parametry działania i logikę wywołań – zostały poddane automatycznemu zaciemnianiu. Nie można wykluczyć, iż implementacja była realizowana zespołowo, a część osób rozwijających kod mogła nie mieć pełnej świadomości operacyjnego przeznaczenia aplikacji.

Ze względu na powyższe nie wskazujemy wprost sygnatury badanej próbki oraz IoC sieciowych.

Idź do oryginalnego materiału