SpyNote: kompleksowa analiza złośliwego oprogramowania RAT dla systemu Android

Niniejszy raport przedstawia kompleksową analizę rodziny złośliwego oprogramowania SpyNote, stanowiącej jedno z najbardziej dojrzałych i funkcjonalnych narzędzi typu Remote Access Trojan (RAT) dla systemu Android.
Opracowanie obejmuje charakterystykę ekosystemu SpyNote, jego architekturę operacyjną, model dystrybucji oraz zaplecze operatorskie, ze szczególnym uwzględnieniem panelu administracyjnego i mechanizmu budowania spersonalizowanych plików APK.
Kontekst zagrożenia i ewolucja SpyNote
W ostatnich latach obserwuje się systematyczny wzrost zagrożeń wymierzonych w urządzenia mobilne, w szczególności w ekosystem Android. Smartfony, będące nośnikiem zarówno danych prywatnych, jak i służbowych, stały się atrakcyjnym celem dla cyberprzestępców oraz aktorów prowadzących operacje szpiegowskie. Jednym z przykładów długotrwałego i ewoluującego zagrożenia w tym obszarze jest malware SpyNote, znany również pod nazwami pochodnymi, takimi jak CypherRat czy SpyMax.
SpyNote jest rodziną złośliwego oprogramowania typu RAT, która od lat funkcjonuje w ekosystemie zagrożeń mobilnych. Pomimo publicznej dostępności kreatora oraz relatywnie długiej historii, SpyNote pozostaje aktywnie wykorzystywany w bieżących kampaniach, zarówno o charakterze masowym jak i ukierunkowanym. W ostatnim okresie zaobserwowano również jego użycie w operacjach przypisywanych grupom APT, co znacząco podnosi poziom ryzyka związanego z tą rodziną malware.
Celem niniejszego raportu jest przedstawienie ogólnej charakterystyki SpyNote, jego modelu operacyjnego oraz sposobów dystrybucji, a następnie przejście do analizy technicznej wybranych, najnowszych próbek wykorzystywanych w aktualnych kampaniach.
Charakterystyka SpyNote jako Android RAT
Złośliwe oprogramowanie klasy RAT stanowi jedno z najbardziej rozpowszechnionych i trwałych zagrożeń dla urządzeń mobilnych. W szczególności platforma Android – ze względu na swoją powszechność oraz otwartą architekturę dystrybucji aplikacji – jest celem licznych kampanii złośliwego oprogramowania, których celem jest kradzież danych, kontrola urządzeń końcowych oraz nadużycia finansowe. Wśród aktywnych rodzin złośliwego oprogramowania mobilnego szczególną pozycję zajmuje SpyNote – znany od kilku lat Android RAT, który stał się fundamentem dla kolejnych publicznie dostępnych narzędzi typu RAT oraz ich modyfikacji.
SpyNote (nazywany także w środowisku underground Spymax lub SpyNote/Spymax RAT) pojawił się pierwotnie jako komercyjny lub półkomercyjny Android RAT, oferujący pełną zdalną kontrolę nad zainfekowanym urządzeniem. Charakterystycznym momentem w historii tego oprogramowania był wyciek kodu źródłowego wersji 6.4 w 2020 roku, co spowodowało szerokie rozpowszechnienie narzędzia i umożliwiło tworzenie licznych pochodnych (tzw. forków) oraz wariantów przez różne grupy cyberprzestępcze i osoby trzecie. Dzięki temu kod SpyNote stał się punktem wyjścia dla szeregu nowszych narzędzi RAT budowanych przez społeczność hackerską, które następnie były dystrybuowane w modelu Malware-as-a-Service (MaaS) przez niezależnych operatorów.
W literaturze technicznej oraz raportach threat intelligence istnieją także odniesienia łączące SpyNote z innymi narzędziami o podobnym sposobie działania. Przykładem jest Craxs RAT, który w analizach branżowych [2], jest opisywany jako pochodna lub wariant SpyNote/SpyMax – wykorzystujący jego kod bazowy i rozbudowany o dodatkowe funkcje oraz mechanizmy sterowania. W tym przypadku kod SpyNote został użyty i rozbudowany przez autora o pseudonimie EVLF, który od 2022 roku rozwijał i dystrybuował Craxs RAT za pośrednictwem kanałów takich jak Telegram, reklamując funkcje rozbudowanego Android RAT o własnych możliwościach sterowania i kontroli urządzenia.
Z punktu widzenia zagrożeń SpyNote nie jest jednorodnym narzędziem o stałym zestawie możliwości. Znane są różne warianty tego RAT, oznaczane literowo i generacyjne (np. SpyNote.A, SpyNote.B, SpyNote.C), które w zależności od kampanii przyjmują odmienne taktyki działania i maskowania. Ich cechą wspólną jest szeroki zakres funkcji inwigilacyjnych i zdalnej kontroli, co czyni SpyNote poważnym narzędziem w arsenale operatorów malware.
Należy podkreślić, że użycie SpyNote i jego pochodnych nie ogranicza się wyłącznie do szeroko rozumianej cyberprzestępczości finansowej. Chociaż wiele kampanii związanych z tymi narzędziami ma charakter masowy i jest ukierunkowanych na kradzież danych, oszustwa finansowe lub phishing aplikacyjny, jego funkcjonalność pozwala na wykorzystywanie narzędzia do bardziej ukierunkowanych operacji inwigilacyjnych. Oznacza to, że zarówno grupy cyberprzestępcze, jak i potencjalnie threat aktorzy typu APT (Advanced Persistent Threat) lub inne grupy o motywacjach szpiegowskich mogą adaptować to oprogramowanie do własnych celów, rozszerzając jego moduły lub łącząc go z innymi komponentami malware w ramach bardziej złożonych kampanii. Z raportów threat intelligence wynika, że grupy takie jak OilRig (APT34), APT-C-37 (Pat-Bear) czy Kimsuky w swoim portfolio narzędziowym miały SpyNote w kampaniach przeciwko ważnym celom (tzw. High Value Asset).
Model dystrybucji i wykorzystanie operacyjne (MaaS)
Dystrybucja SpyNote oraz jego pochodnych (w tym Craxs RAT) opiera się w przeważającej mierze na modelu MaaS, który od lat stanowi jeden z kluczowych mechanizmów skalowania cyberprzestępczości. Model ten zakłada oddzielenie roli autora narzędzia od roli operatora kampanii – twórcy dostarczają gotowe oprogramowanie, buildery oraz infrastrukturę sterującą, natomiast użytkownicy końcowi odpowiadają za jego faktyczne wykorzystanie i dystrybucję.
Wspomniany już wcześniej wyciek kodów źródłowych umożliwił jego swobodną modyfikację, rozwój własnych forków oraz integrację z innymi komponentami złośliwego oprogramowania. W praktyce doprowadziło to do fragmentacji ekosystemu SpyNote, w którym funkcjonuje wiele wariantów różniących się detalami implementacyjnymi, lecz zachowujących wspólną architekturę i zestaw funkcji charakterystycznych dla tej rodziny RAT.
Narzędzie to było aktywnie promowane w zamkniętych i półotwartych kanałach komunikacyjnych, głównie w serwisach takich jak Telegram. Autorzy oferowali nie tylko sam malware ale również pełne zaplecze operatorskie, obejmujące kreator złośliwych aplikacji, panel administracyjny oraz instrukcje dotyczące omijania zabezpieczeń systemu Android. Takie podejście znacząco obniżało barierę wejścia dla nowych operatorów i umożliwiało szybkie uruchamianie kampanii infekcyjnych bez konieczności posiadania zaawansowanych kompetencji technicznych.
Z perspektywy technicznej dystrybucja złośliwych aplikacji opiera się głównie na trojanizowanych plikach APK (pakiet instalacyjny aplikacji dla systemu Android), które podszywają się pod legalne aplikacje mobilne. Najczęściej są to przeglądarki internetowe, aplikacje bankowe, kurierskie, komunikatory, narzędzia VPN lub aplikacje powiązane z aktualnymi wydarzeniami społecznymi i ekonomicznymi. Pliki te są rozpowszechniane poza oficjalnym sklepem Google Play, m.in. za pośrednictwem stron phishingowych, bezpośrednich linków do pobrania, fałszywych reklam oraz wiadomości SMS i e-mail zawierających odnośniki do instalatorów.
Istotnym elementem modelu dystrybucji jest wykorzystanie socjotechniki do nakłonienia użytkownika do ręcznego zainstalowania aplikacji oraz nadania jej szerokich uprawnień systemowych. Mechanizm ten jest kluczowy, ponieważ SpyNote nie posiada wektorów infekcji wykorzystujących exploity ani zdalne wykonanie kodu (RCE). Operatorzy kampanii często instruują ofiary, aby wyłączyły mechanizmy ochronne Androida, takie jak Google Play Protect, lub zezwoliły na instalację aplikacji z nieznanych źródeł. W niektórych kampaniach stosowane są również techniki bardziej zaawansowane, takie jak przekierowywanie do odpowiedniego pliku w zależności od typu urządzenia, ukrywanie linków z wykorzystaniem kodów QR czy wykorzystanie aplikacji-loaderów, które dopiero w drugim etapie pobierają lub odszyfrowują właściwy payload SpyNote.
Model MaaS sprzyja również decentralizacji infrastruktury sterującej. Każdy operator może wykorzystywać własne serwery C2, często hostowane u różnych dostawców lub ukryte za usługami dynamicznego DNS. Niektóre warianty wspierają również fallback C2 oraz dynamiczną zmianę adresów za pomocą DNS-over-HTTPS. W efekcie powstaje rozproszony ekosystem kampanii, które mogą wydawać się niezależne, mimo że korzystają z tego samego lub bardzo zbliżonego kodu malware. Taka fragmentacja znacząco utrudnia blokowanie zagrożenia na poziomie infrastruktury oraz przypisywanie aktywności do konkretnych aktorów.
Zaplecze operatorskie: panel administracyjny i builder
Integralnym elementem ekosystemu SpyNote jest publicznie dostępny panel administracyjny (C2 panel), oferowany za pośrednictwem oficjalnej strony projektu. Panel ten stanowi centralny punkt zarządzania zainfekowanymi urządzeniami i odgrywa kluczową rolę w operacyjnym wykorzystaniu tego narzędzia. Z perspektywy technicznej i funkcjonalnej jest to klasyczny interfejs C2, udostępniający operatorowi pełen wgląd w aktywność ofiar oraz możliwość wykonywania poleceń w czasie rzeczywistym.
Zacznijmy od witryny projektu. Panel administracyjny SpyNote prezentowany jest jako „zaawansowane narzędzie do zdalnej administracji Androida”, jednak zakres oferowanych funkcji jednoznacznie odpowiada charakterystyce złośliwego oprogramowania typu RAT. Deklarowanie narzędzia jako „remote admin tool” to standardowa technika marketingowa pomniejszająca potencjalne konsekwencje prawne dla autorów. Interfejs umożliwia operatorowi monitorowanie i kontrolę urządzeń z systemem Android w szerokim zakresie, obejmującym zarówno pasywne pozyskiwanie danych jak i aktywne oddziaływanie na system ofiary. Funkcje są dostępne z poziomu jednej konsoli zarządzającej i nie wymagają bezpośredniego dostępu fizycznego do urządzenia.

Rys. 1. Serwis „projektu SpyNote” – notka informacyjna.
Do kluczowych możliwości panelu administracyjnego należy zdalny podgląd ekranu urządzenia w czasie rzeczywistym, wraz z możliwością interakcji i sterowania interfejsem systemu. Funkcja ta pozwala operatorowi obserwować bieżącą aktywność użytkownika: w tym uruchamiane aplikacje, wprowadzane dane oraz wyświetlane treści. Panel umożliwia również zdalne odblokowanie ekranu urządzenia, co w praktyce pozwala na przejęcie kontroli nad telefonem nawet w sytuacji, gdy jest on zabezpieczony mechanizmami blokady (odblokowanie ekranu możliwe jest wyłącznie dzięki nadaniu uprawnień Accessibility Service, a nie przez przełamanie mechanizmu blokady).
Istotnym elementem funkcjonalnym jest zdalny dostęp do sensorów urządzenia, w tym mikrofonu i kamery. Panel umożliwia uruchamianie nagrywania dźwięku oraz obrazu bez wiedzy użytkownika, a także podgląd obrazu z kamery w czasie rzeczywistym. Funkcje te w połączeniu z mechanizmami ukrywania aktywności malware pozwalają na prowadzenie długotrwałej i dyskretnej inwigilacji.
Panel administracyjny oferuje również rozbudowane narzędzia do zarządzania danymi przechowywanymi na urządzeniu. Operator ma dostęp do eksploratora plików umożliwiającego przeglądanie, pobieranie oraz usuwanie danych, a także do modułów pozwalających na odczyt wiadomości SMS, historii połączeń, list kontaktów oraz zapisanych kont i haseł. Dodatkowo dostępny jest moduł keyloggera, umożliwiajcy przechwytywanie wprowadzanych danych, w tym potencjalnie danych uwierzytelniających do aplikacji bankowych i korporacyjnych.

Rys. 2. Serwis „projektu SpyNote” – funkcjonalności narzędzia
Jednym z bardziej zaawansowanych komponentów panelu administracyjnego jest moduł lokalizacji, oferujący śledzenie położenia urządzenia w czasie rzeczywistym z wykorzystaniem danych GPS. Funkcja ta prezentowana jest w formie interaktywnej mapy z trójwymiarową wizualizacją, umożliwiającą dokładne monitorowanie przemieszczania się ofiary. W połączeniu z innymi modułami pozwala to na korelację aktywności użytkownika z jego fizyczną lokalizacją. Stałe śledzenie urządzenia jest możliwe dzięki połączeniu uprawnień do lokalizacji oraz usługi działającej w tle, co oznacza, że użytkownik otrzymuje minimalne alerty systemowe lub nie otrzymuje żadnych.
Panel SpyNote zawiera również funkcje typowe dla narzędzi administracyjnych o charakterze ofensywnym, takie jak dostęp do terminala systemowego. Moduł ten umożliwia wykonywanie poleceń na zainfekowanym urządzeniu, uzyskiwanie informacji o konfiguracji systemu oraz potencjalne wdrażanie dodatkowych komponentów. Tego typu funkcjonalność znacząco zwiększa elastyczność operacyjną narzędzia i pozwala operatorowi na dynamiczne dostosowywanie działań do konkretnej ofiary.
Z punktu widzenia modelu biznesowego panel administracyjny SpyNote jest oferowany w ramach płatnych licencji czasowych oraz dożywotnich. Dostępne są pakiety obejmujące kilkumiesięczne licencje testowe, średnioterminowe oraz jednorazowy zakup zapewniający stały dostęp do narzędzia. Charakterystycznym elementem jest akceptowanie płatności wyłącznie w kryptowalutach, takich jak Bitcoin, Ethereum czy USDT, co jest typowym rozwiązaniem stosowanym w środowisku narzędzi o podwyższonym ryzyku prawnym i operacyjnym.

Rys. 3. Serwis „projektu SpyNote” – cennik
Operatorzy SpyNote deklarują możliwość sprzedaży niestandardowych wersji narzędzia, w tym modyfikacji kodu źródłowego oraz świadczenia „usług specjalnych” na żądanie klienta. Z perspektywy analitycznej wskazuje to na wysoki poziom elastyczności oraz gotowość do dostosowywania narzędzia do konkretnych scenariuszy użycia, w tym potencjalnie do operacji ukierunkowanych.
C2 oraz Builder
Opisany powyżej panel stanowi centralny element całego ekosystemu tego malware i odpowiada za zarządzanie cyklem życia infekcji, od generowania złośliwej aplikacji po bieżącą kontrolę nad zainfekowanymi urządzeniami. W zależności od wersji SpyNote oraz jego licznych forków interfejs panelu może różnić się wizualnie oraz funkcjonalnie. Jednak we wszystkich obserwowanych wariantach zachowany jest wspólny zestaw podstawowych mechanizmów operacyjnych. Różnice wynikają z faktu, iż narzędzie było wielokrotnie modyfikowane i adaptowane przez różne grupy hakerskie.

Rys. 4. Panel administracyjny SpyNote – zarządzanie infekcjami
Niezależnie od wariantu kluczowym komponentem panelu administracyjnego jest moduł buildera, który umożliwia generowanie dopasowanych i unikalnych próbek malware w postaci plików APK. Builder pozwala operatorowi zdefiniować podstawowe parametry złośliwej aplikacji, w tym nazwę wyświetlaną użytkownikowi, nazwę pakietu oraz identyfikatory komponentów, co umożliwia maskowanie malware jako legalnego oprogramowania. Na tym etapie określana jest również nazwa procesu oraz dane infrastruktury sterującej. W szczególności adres IP lub domena serwera C2 oraz port komunikacyjny, z którym aplikacja będzie się łączyć po uruchomieniu na urządzeniu ofiary. Niektóre wersje buildera wspierają generowanie wielu wariantów tej samej próbki (polimorfizm), co znacząco utrudnia klasyczne wykrywanie sygnaturowe.

Rys. 5. Panel administracyjny SpyNote – builder-konfiguracja
Istotnym elementem procesu budowania aplikacji jest możliwość wyboru funkcjonalności włączanych w wygenerowanej próbce. Panel udostępnia operatorowi zestaw przełączników odpowiadających poszczególnym modułom operacyjnym, takim jak dostęp do kamery, mikrofonu, lokalizacji, wiadomości SMS, kontaktów czy plików. Dodatkowo możliwe jest wymuszenie żądania uprawnień specjalnych, w tym uprawnień do wyświetlania nakładek ekranowych, ignorowania optymalizacji baterii oraz blokowania powiadomień systemowych. Szczególnie istotną opcją jest możliwość automatycznego uzyskiwania dodatkowych uprawnień po aktywacji usługi Accessibility, co w praktyce umożliwia dalszą eskalację kontroli nad systemem bez bezpośredniego udziału użytkownika.

Rys. 6. Panel administracyjny SpyNote – builder-konfiguracja
Z perspektywy technicznej panel administracyjny SpyNote jest aplikacją desktopową napisaną w technologii .NET. Do procesu budowy plików APK wykorzystywane są narzędzia zewnętrzne, w szczególności apktool, który służy do dekompilacji, modyfikacji oraz ponownej kompilacji pakietów Android. Integracja buildera z apktool pozwala operatorom generować nowe warianty bez znajomości programowania, automatyzując wstrzyknięcie konfiguracji oraz ukrycie kodu RAT.

Rys. 7. Panel administracyjny SpyNote – kompilacja pliku apk.
Po uruchomieniu panel administracyjny otwiera port nasłuchowy i oczekuje na połączenia przychodzące od zainfekowanych urządzeń. W momencie, gdy wygenerowana aplikacja zostanie zainstalowana na urządzeniu ofiary i uruchomiona, nawiązuje ona połączenie z serwerem C2 zdefiniowanym w procesie budowania. Po zestawieniu połączenia urządzenie jest rejestrowane w panelu jako nowa ofiara, a operator uzyskuje pełny wgląd w jej stan oraz możliwość zdalnego zarządzania jej funkcjonalnościami.
Panel umożliwia dynamiczne aktywowanie poszczególnych modułów malware w odpowiedzi na bieżące potrzeby operatora. Obejmuje to między innymi uruchamianie podglądu ekranu, przechwytywanie obrazu z kamery, nagrywanie dźwięku, śledzenie lokalizacji, przeglądanie plików oraz monitorowanie komunikacji. Funkcje te mogą być aktywowane w czasie rzeczywistym, co pozwala na elastyczne prowadzenie działań inwigilacyjnych oraz dostosowywanie ich do zachowania ofiary.
Analiza wygenerowanych aplikacji APK wskazuje, że proces budowania nie polega wyłącznie na prostym osadzeniu adresu C2. Obejmuje również selektywne włączanie lub wyłączanie komponentów manifestu oraz usług działających w tle. W rezultacie różne próbki SpyNote mogą znacząco różnić się zakresem żądanych uprawnień oraz zachowaniem w systemie, mimo że zostały wygenerowane z tego samego panelu administracyjnego. Mechanizm ten utrudnia detekcję sygnaturową oraz sprzyja powstawaniu dużej liczby wariantów tego samego malware.

Rys. 8. Panel administracyjny SpyNote – obsługa zainfekowanego urządzenia.
Z perspektywy operacyjnej panel administracyjny SpyNote pełni jednocześnie rolę narzędzia do generowania malware, serwera sterującego oraz konsoli operatorskiej. Taka konsolidacja funkcji w połączeniu z prostotą obsługi i szerokimi możliwościami konfiguracji czyni SpyNote narzędziem atrakcyjnym zarówno dla cyberprzestępców jak i dla aktorów prowadzących bardziej ukierunkowane operacje, w tym działania o charakterze szpiegowskim.
Analiza techniczna próbek SpyNote
Analiza techniczna została przeprowadzona na wybranych próbkach SpyNote pozyskanych w ramach bieżących kampanii oraz z publicznie dostępnych repozytoriów próbek złośliwego oprogramowania. Jej celem było określenie aktualnych mechanizmów infekcji, trwałości, komunikacji z infrastrukturą C2 oraz zakresu funkcji realizowanych na zainfekowanych urządzeniach z systemem Android.
Proces działania SpyNote rozpoczyna się na etapie instalacji aplikacji w postaci pakietu instalacyjnego APK. Już na tym etapie w pliku AndroidManifest.xml deklarowany jest szeroki zakres uprawnień, jednak ich faktyczne przyznanie i aktywacja następują stopniowo w trakcie dalszych faz infekcji, zgodnie z obowiązującym w systemie Android modelem runtime permissions.
Pierwsze uruchomienie aplikacji powoduje start głównej aktywności, odpowiedzialnej za przygotowanie środowiska operacyjnego malware. W ramach tego etapu inicjalizowane są komponenty zbierające kluczowe informacje o urządzeniu: wersja systemu Android, model sprzętu, identyfikatory systemowe oraz poziom zabezpieczeń. Informacje te stanowią podstawę doboru dalszych technik eskalacji uprawnień.

Rys. 9. Przykład ekranu – akceptacja Accessibility Service (na przykładzie aplikacji Roblox Modded.apk)
Kolejnym etapem działania malware jest stopniowa eskalacja uprawnień, realizowana poprzez sekwencję dedykowanych aktywności mających na celu skłonienie użytkownika do nadania aplikacji kolejnych uprawnień o krytycznym znaczeniu. Mechanizm ten opiera się na socjotechnice oraz wykorzystaniu systemowych okien typu overlay. W pierwszej kolejności użytkownik nakłaniany jest do przyznania dostępu do usług ułatwień dostępu (Accessibility Service), co stanowi punkt przełomowy w schemacie działania SpyNote. Uzyskanie tego uprawnienia umożliwia malware monitorowanie interakcji użytkownika z systemem oraz symulowanie zdarzeń wejścia, prowadząc do dalszej automatyzacji eskalacji uprawnień.
Posiadając już uprawnienia Accessibility Service SpyNote inicjuje kolejne etapy przejmowania kontroli nad systemem. W sposób półautomatyczny wymuszane jest nadanie uprawnień administratora urządzenia (Device Administrator), aktywacja własnej klawiatury systemowej (technika keyloggerów mobilnych) oraz zgoda na wykonywanie operacji w tle bez ograniczeń mechanizmów oszczędzania energii. W niektórych wariantach obserwuje się również próby uzyskania zgody na instalowanie oraz usuwanie pakietów aplikacji, co umożliwia dalszą rozbudowę funkcjonalności malware lub instalację dodatkowych komponentów.
Równolegle do procesu eskalacji uruchamiane są mechanizmy trwałości. SpyNote rejestruje komponenty typu BroadcastReceiver, skonfigurowane do obsługi wybranych zdarzeń systemowych: restart urządzenia (BOOT_COMPLETED), zmiana stanu ekranu, podłączenie zasilania oraz zdarzenie USER_PRESENT (sygnalizujące odblokowanie urządzenia przez użytkownika). Dzięki temu złośliwe usługi są automatycznie wznawiane po restarcie systemu lub aktywowane w momencie interakcji użytkownika z urządzeniem, co zwiększa niezawodność działania malware i ogranicza jego widoczność operacyjną.
Po uzyskaniu kluczowych uprawnień następuje inicjalizacja pełnego zestawu funkcji operacyjnych. Uruchamiane są usługi odpowiedzialne za monitorowanie lokalizacji, przechwytywanie dźwięku i obrazu, rejestrowanie wprowadzanych danych oraz zbieranie informacji o aktywności aplikacji. W zależności od konfiguracji malware część tych funkcji działa w trybie pasywnym, oczekując na polecenia z serwera sterującego, inne natomiast mogą być aktywowane automatycznie w odpowiedzi na określone zdarzenia systemowe.

Rys. 10. Zdekompilowana i zdekodowana klasa SpyNote – konfiguracja sieciowa
Ostatnim etapem schematu działania jest nawiązanie komunikacji z infrastrukturą C2 operatora kampanii. SpyNote inicjuje połączenie sieciowe z serwerem C2, przekazując wcześniej zgromadzone informacje identyfikujące urządzenie oraz potwierdzając gotowość do odbioru poleceń. Komunikacja realizowana jest cyklicznie lub zdarzeniowo, w zależności od konfiguracji, i służy zarówno do przesyłania danych wykradzionych z urządzenia jak i do odbierania instrukcji sterujących dalszym działaniem malware (wspólny kanał danych oraz zarządzania). W zaawansowanych wariantach komunikacja może być dodatkowo ukrywana poprzez mechanizmy szyfrowania lub wykorzystanie tunelu VPN, co utrudnia jej wykrywanie w warstwie sieciowej.
Całość schematu działania SpyNote wskazuje na przemyślaną, wieloetapową architekturę, której celem jest stopniowe przejmowanie kontroli nad urządzeniem ofiary przy jednoczesnym minimalizowaniu ryzyka wykrycia. Połączenie socjotechnik, nadużyć mechanizmów systemowych Androida oraz centralnego sterowania z poziomu C2 czyni SpyNote narzędziem zdolnym do długotrwałej i dyskretnej inwigilacji.
Komunikacja C2
Przeanalizowany komponent <package_name>.run.Socket odpowiada za pełną obsługę komunikacji sieciowej między zainfekowanym urządzeniem a serwerem sterującym SpyNote. Implementacja ta stanowi centralny element architektury komunikacji z C2 i została zaprojektowana w sposób umożliwiający stabilną, długotrwałą dwukierunkową komunikację przy jednoczesnym zachowaniu elastyczności w zakresie przesyłanych poleceń i danych. Długotrwałe utrzymywanie połączenia TCP odróżnia SpyNote od większości mobilnych RAT, które korzystają z krótkich połączeń typu “pull”.
Po stronie klienta komunikacja realizowana jest przy użyciu asynchronicznych kanałów sieciowych (AsyncChannel) opartych o Java NIO (Non-blocking IO), z wykorzystaniem gniazd TCP. Podczas inicjalizacji połączenia malware konfiguruje kluczowe opcje gniazd sieciowych, takie jak TCP_NODELAY oraz SO_KEEPALIVE, co wskazuje na dążenie do minimalizacji opóźnień oraz utrzymania sesji przez dłuższy czas. Adres serwera C2 oraz port pobierane są dynamicznie z klasy Support.SocketInfo, co potwierdza, że wartości te są wstrzykiwane na etapie budowania próbki przez panel administracyjny.
Proces zestawiania połączenia realizowany jest w klasie Client.Connect, która podejmuje wielokrotne próby połączenia, uwzględniając obsługę wyjątków sieciowych. W przypadku niepowodzenia malware wprowadza opóźnienie i podejmuje kolejne próby, co pozwala na przetrwanie czasowych problemów z dostępnością infrastruktury C2 lub sieci ofiary. Po pomyślnym zestawieniu połączenia zapisywany jest znacznik czasu, wykorzystywany następnie do monitorowania stanu sesji.
Bezpośrednio po połączeniu, klient wysyła do serwera pakiet inicjalizacyjny zawierający rozbudowany zestaw informacji identyfikacyjnych i telemetrycznych. Dane te obejmują unikalny identyfikator urządzenia, wersję malware, nazwę pakietu aplikacji, nazwy kluczowych klas, informacje o stanie baterii, lokalizacji, blokadzie ekranu oraz szczegóły dotyczące systemu operacyjnego i interfejsu producenta. Pakiet ten rejestruje nową ofiarę w panelu administracyjnym oraz umożliwia operatorowi natychmiastową ocenę wartości przejmowanego urządzenia.
Odbiór danych z serwera realizowany jest w klasie ReceiveData, która implementuje własny, niestandardowy protokół komunikacyjny. Dane przesyłane są w postaci strumienia bajtów, w którym długości poszczególnych segmentów oddzielane są bajtem zerowym. Po odebraniu pełnej ramki dane są dekodowane, opcjonalnie dekompresowane przy użyciu mechanizmu GZIP oraz przekazywane do dalszego przetwarzania. Zdekodowane pakiety trafiają do współdzielonej kolejki Socket.packets, co umożliwia ich asynchroniczną obsługę przez inne wątki. Przetwarzanie poleceń z serwera realizowane jest w klasie IncomingPackets, która cyklicznie pobiera pakiety z kolejki i przekazuje je do metody Client.Data. W tym miejscu następuje interpretacja poleceń na podstawie kluczy logicznych.
Istotnym elementem architektury jest obsługa operacji. SpyNote wykorzystuje równoległe zadania do przeszukiwania systemu plików, pobierania zawartości katalogów oraz wykonywania operacji na plikach multimedialnych, takich jak zrzuty ekranu o zadanych parametrach. Zastosowanie puli wątków umożliwia efektywne wykorzystanie zasobów urządzenia, a jednocześnie pozwala operatorowi na wykonywanie tych operacji w tle bez wyraźnych oznak aktywności dla użytkownika.
Komunikacja z serwerem C2 jest utrzymywana przez dedykowany mechanizm kontroli stanu połączenia zaimplementowany w klasie CheckConnection. Komponent ten cyklicznie wysyła pakiety typu „ping” oraz monitoruje czas bezczynności sesji. W przypadku braku odpowiedzi lub wykrycia problemów z dostępem do internetu malware samodzielnie inicjuje procedurę rozłączenia i ponownego zestawienia połączenia. Mechanizm ten umożliwia utrzymanie ciągłości kampanii nawet w warunkach niestabilnej sieci mobilnej. Dodatkowo okresowo przekazywane są aktualne informacje o stanie baterii, ładowaniu, lokalizacji oraz blokadzie ekranu, co umożliwia operatorowi bieżące monitorowanie kontekstu operacyjnego ofiary. Dane te mogą także służyć jako wyzwalacze operacyjne – np. aktywacja nagrywania po podłączeniu zasilania, co minimalizuje ryzyko wzrostu zużycia baterii i wykrycia przez użytkownika.
Całość logiki sterującej pracą poszczególnych komponentów komunikacyjnych została skupiona w klasie Controller, która koordynuje uruchamianie, zatrzymywanie oraz ponowne inicjalizowanie zadań odpowiedzialnych za połączenie, odbiór danych, przetwarzanie poleceń i kontrolę sesji. Mechanizm ten zapewnia wysoką odporność na błędy oraz pozwala na automatyczne odzyskiwanie połączenia w przypadku zakłóceń, co jest charakterystyczne dla dojrzałych rodzin złośliwego oprogramowania. W niektórych wariantach zaobserwowano dodatkowe mechanizmy ukrywania komunikacji, takie jak niestandardowe nagłówki, zaciemnione identyfikatory sesji lub wykorzystanie tunelowania przez HTTPS, co znacząco utrudnia monitoring ruchu sieciowego oraz korelację zdarzeń.
Analiza komponentu odpowiedzialnego za komunikację jednoznacznie wskazuje, że SpyNote wykorzystuje własny protokół C2 oparty o długotrwałe sesje TCP, z obsługą kompresji, dynamicznego kodu oraz wielowątkowego przetwarzania poleceń. Architektura ta została zaprojektowana z myślą o długotrwałej kontroli nad zainfekowanym urządzeniem, elastycznym rozszerzaniu funkcjonalności oraz minimalizowaniu ryzyka utraty sesji.
Techniki obfuskacji
SpyNote stosuje szereg wyrafinowanych technik obfuskacji i ochrony kodu, które ewoluowały od prostych metod do zaawansowanych mechanizmów mających na celu ominięcie nowoczesnych systemów zabezpieczeń. Podczas gdy najwcześniejsze wersje i publicznie dostępne kreatory (buildery) często nie posiadały żadnych zabezpieczeń, współczesne warianty (takie jak SpyNote.C czy V7) są wysoce skomplikowane.

Rys. 11. Konfiguracja widoczna w zdekompilowanym pliku (wersja kodowana)
Niektóre warianty działają jako droppery, gdzie pierwszy plik APK służy jedynie do zainstalowania drugiego payloadu ukrytego w pliku DEX wewnątrz zasobów aplikacji. Parametry połączenia z serwerem są często zaszyte wewnątrz plików DEX, co stanowi kolejną warstwę ukrycia. Przykładami stosowania takich technik są kampanie grup APT (np. grupy APT43), gdzie właściwy kod SpyNote ukryto w folderze /assets pod niepozornymi nazwami plików, jak security.dat czy search.db. Do jego odszyfrowania służy dedykowana biblioteka natywna SILENTKEY (np. libnative-lib.so), która zawiera funkcję decryptFile. Przejście z prostego szyfrowania XOR w języku Java na deszyfrowanie w bibliotece natywnej znacząco ogranicza skuteczność analizy statycznej z wykorzystaniem standardowych narzędzi do dekompilacji DEX.
Malware powszechnie wykorzystuje kodowanie do ukrywania kluczowych informacji konfiguracyjnych, w tym adresów IP serwerów C2, numerów portów oraz kluczy komunikacyjnych. Również dane wykradzione od ofiary (np. przechwycone znaki z klawiatury) są zapisywane i przesyłane w formie zakodowanej, a czasem zaszyfrowanej. W nowszych wariantach spotykane są wielopoziomowe łańcuchy dekodowania, gdzie stringi są deszyfrowane dopiero w momencie użycia. Utrudnia to statyczne mapowanie funkcji.
Najnowsze wersje SpyNote korzystają z komercyjnych pakerów oraz zaawansowanego zaciemniania ciągów znaków. Sprawia to, że kod aplikacji jest nieczytelny dla standardowych dekompilatorów, co utrudnia identyfikację złośliwych funkcji. Często używane są obfuskowane nazw klas i usług (np. klasy o nazwach C71 czy C38), by ukryć złośliwe procesy wśród legalnych usług systemowych. W wielu próbkach obserwuje się także sztuczne wypełniacze kodu (dead code), fałszywe klasy oraz zagnieżdżone bloki try/catch, które utrudniają analizę algorytmów.

Rys. 12. Drzewo klas i metod SpyNote – wersja bez obfuskacji
W zaawansowanych przypadkach kod malware jest deszyfrowany dopiero w momencie uruchomienia i ładowany bezpośrednio do pamięci urządzenia (in-memory execution). Dzięki temu złośliwe moduły nie są widoczne podczas zwykłego skanowania plików na dysku, co pozwala skutecznie omijać mechanizmy takie jak Google Play Protect. Tego typu technika jest stosowana głównie w wariantach wykorzystywanych w ukierunkowanych kampaniach lub tworzonych przez zaawansowanych operatorów – nie jest to funkcja standardowego buildera SpyNote dostępnego publicznie.
Zastosowanie powyższych technik znacząco utrudnia zarówno analizę statyczną, jak i detekcję behawioralną SpyNote.
Podsumowanie
SpyNote stanowi dojrzałe, wielokomponentowe złośliwe oprogramowanie klasy Android RAT. Zostało ono zaprojektowane jako spójny ekosystem obejmujący infrastrukturę C2, panel operatorski, mechanizm generowania spersonalizowanych próbek oraz modularną architekturę po stronie klienta. Taka konstrukcja umożliwia centralne zarządzanie kampaniami oraz precyzyjne dostosowanie zachowania poszczególnych instancji do założeń operacyjnych.
Z perspektywy funkcjonalnej SpyNote łączy mechanizmy pasywnej inwigilacji z aktywnym sterowaniem urządzeniem. Zakres jego możliwości obejmuje m.in. pozyskiwanie danych uwierzytelniających, monitorowanie aktywności użytkownika, dostęp do zasobów systemowych oraz wykonywanie zdalnych poleceń. Kluczowym elementem architektury jest systematyczne nadużywanie usług Accessibility, co umożliwia eskalację uprawnień logicznych oraz automatyzację interakcji z interfejsem systemu bez konieczności uzyskiwania uprawnień root. W praktyce czyni to SpyNote szczególnie efektywnym na współczesnych wersjach Androida, ponieważ omija on większość ograniczeń bezpieczeństwa dotyczących aplikacji bez dostępu do uprawnień systemowych. Cechą charakterystyczną jest również zdolność do utrzymywania stałych sesji TCP, co odróżnia SpyNote od większości mobilnych RAT i komplikuje analizę ruchu.
Model operacyjny SpyNote zakłada przeniesienie logiki konfiguracji na etap budowania próbki. Parametry komunikacji, zakres funkcjonalny oraz zachowanie aplikacji po instalacji definiowane są po stronie panelu operatorskiego, co skutkuje powstawaniem wariantów różniących się zachowaniem i artefaktami technicznymi. Takie podejście znacząco ogranicza skuteczność detekcji sygnaturowej i sprzyja długotrwałemu utrzymaniu dostępu do zainfekowanych urządzeń.
Z punktu widzenia detekcji i reagowania SpyNote reprezentuje klasę zagrożeń charakteryzującą się wysoką integracją z mechanizmami systemowymi Androida, odpornością na restart urządzenia oraz zdolnością do działania w tle w oparciu o zdarzenia systemowe. Zastosowanie własnego protokołu C2 oraz dynamicznego przetwarzania poleceń dodatkowo utrudnia identyfikację infrastruktury i blokowanie komunikacji na poziomie sieciowym.
W konsekwencji SpyNote należy traktować nie jako pojedynczą rodzinę malware w wąskim sensie, lecz elastyczne narzędzie operatorskie, zdolne do adaptacji i do zmian w modelu bezpieczeństwa platformy Android. Współcześnie termin SpyNote obejmuje de facto szeroką rodzinę forków i wariantów o różnym stopniu zaawansowania, z których część znacząco odbiega od oryginalnej wersji 6.4. Ma to istotne znaczenie dla analizy oraz atrybucji kampanii. Jego obecność w krajobrazie zagrożeń powinna być analizowana w kategoriach długofalowych, z naciskiem na detekcję behawioralną, korelację zdarzeń oraz monitorowanie nadużyć mechanizmów systemowych.
Indicators of Compromise (IoC)
Analizowane próbki
sonapk.apk
SHA-256 3cf8bd9828f8fe52867fcb09f3caa59f5ce0aa76ff20cf644807ae76b57c2c86
C2: tcp://103.61.224[.]102:2323
Gmail.apk
SHA-256 8f09663836bef9fad23b34560dbcb0848e99d66e40787c37d498e7647792d5b6
C2 tcp://103.61.224[.]102:2323
inpost.apk
SHA-256 40d31617f45e8317e9d8fa6e42e67d587bdc546b50fd2197b26ac27b51d037de
C2: tcp://103.61.224[.]102:3333
Roblox Modded.apk
SHA-256 acf2d29c8c65ee2fe57445e672fbee01fa240b0039b66ea507f110468c6c8210
C2: tcp://144.31.30[.]235:7771
Pozostałe (najnowsze) próbki
SHA-256 6fd37bbd31b52c6312a0c7972d7fe7242dade45f3d8faa2fc548bef2e3400ecd
C2 tcp://20.82.176[.]195:7771
SHA256 231b21251d16d17e564a2014765d1de553eb821abd92781b18c94889650a3bf7
C2: tcp://91.92.251[.]105:12004
SHA256 b29b8bd2d47254de3d7bf21d7610209d3cc4db49cd3e7ba2fd1ea040f49cb6db
C2: tcp://185.87.254[.]82:2305
SHA256 d9c47a7d7e42402c3ce2dd191ea09e9f7e29b1ee8d78d9aec0a47ed7b4bcdb80
C2: tcp://mm-includes.gl.at.ply[.]gg:33004
SHA256 5d4aa3800788f80d2a0b0460574ee3d3403c642b19e294941cd9e59b37aebae5
C2: tcp://193.161.193[.]99:40920
SHA256 d14fb879a81e6c415146092d2aab8f8c69991828dbebc0ec27363248f9b260c0
C2: tcp://83.217.209[.]142:1333
SHA256 e21f8722ab3d3557e7b0dda0faca39c517bbf0afd84bf4bbdc92687c9bd58aae
C2: tcp://tcp.cloudpub[.]ru:48683
Źródła i materiały referencyjne:
- https://www.mobile-hacker.com/2025/06/05/analysis-of-spyware-that-helped-to-compromise-a-syrian-army-from-within/
- https://www.group-ib.com/blog/craxs-rat-malware/
- https://malpedia.caad.fkie.fraunhofer.de/details/apk.spynote
- https://hunt.io/malware-families/spynote
- ThreatLabz 2025 Mobile, IoT & OT Threat Report
- https://app.apkdetect.com/search/?malware=SpyNote
