Flying Eagle RAT: ślady na 170 serwerach

29 lipca 2026 roku opublikowano wyniki badania infrastruktury związanej z Flying Eagle, zestawem do budowania i obsługi złośliwych aplikacji na Androida. Badacze Hunt.io oraz NetAskari odnaleźli charakterystyczne ślady na 170 serwerach dostępnych z internetu. Liczba jest istotna, ale wymaga precyzyjnej interpretacji: nie oznacza 170 ofiar, 170 aktywnych kampanii ani 170 niezależnych operatorów.

Raport Hunt.io i NetAskari opisuje 158 hostów zidentyfikowanych na podstawie elementów panelu, przekierowań i nagłówków oraz kolejnych 12 na podstawie domyślnego certyfikatu TLS. Badanie pokazuje możliwość wyszukiwania powtarzalnej infrastruktury, ale nie daje automatycznie pewności, czy każdy serwer był aktywnym C2, instalacją testową, porzuconym panelem czy systemem wystawionym przez badaczy.

Czym jest Flying Eagle

Flying Eagle to nie pojedyncza aplikacja podszywająca się pod konkretną markę. Materiały opisane przez badaczy tworzą pakiet operatorski obejmujący backend, panel zarządzania, komunikację czasu rzeczywistego, builder aplikacji Android i gotowe szablony socjotechniczne. Kod miał krążyć w przestępczych kanałach Telegram, co obniża próg wejścia dla wielu użytkowników narzędzia.

Przeanalizowane środowisko — archiwum nazywane przez badaczy „China Dragon” — miało około 388 MB i zawierało między innymi konfigurację Docker, nginx, PHP, MySQL, komponent Node.js/WebSocket, narzędzia Android oraz szablony. Taki zestaw pozwala osobie dysponującej infrastrukturą zbudować markowaną aplikację i obsługiwać zebrane urządzenia przez przeglądarkowy panel.

Złośliwa aplikacja może podszywać się pod oprogramowanie chińskich służb bezpieczeństwa publicznego. Według badania możliwości rodziny obejmują między innymi:

przechwytywanie wpisywanych danych i treści ekranu;
próby pozyskiwania haseł do płatności;
obserwowanie interakcji przez nadużycie usług ułatwień dostępu;
dostęp do aparatu i funkcji urządzenia po uzyskaniu uprawnień;
wyświetlanie szablonów phishingowych;
zdalne sterowanie z wykorzystaniem kanału komunikacyjnego backendu.

To katalog możliwości frameworka. Nie dowodzi, że każdy znaleziony serwer wykonał wszystkie funkcje ani że każda próbka miała identyczny zestaw modułów.

Skąd wzięła się liczba 170

Badacze wykorzystali cechy, które powtarzały się w instalacjach: wygląd i odpowiedzi panelu, łańcuch przekierowań, charakterystyczne nagłówki oraz domyślny certyfikat TLS dostarczony w zestawie. Wyszukiwanie takich fingerprintów w skali internetu ujawniło:

158 adresów powiązanych przez cechy usług WWW;
12 kolejnych adresów powiązanych przez domyślny certyfikat;
łącznie 170 hostów spełniających kryteria badania.

Certyfikat jest szczególnie wartościowym śladem, gdy operator wdraża gotowy pakiet bez zmiany ustawień. Jednocześnie nie jest niepodważalnym dowodem kontroli przez konkretną grupę: plik może zostać skopiowany, celowo użyty jako fałszywa flaga albo pozostać na nieaktywnym serwerze. Dobra analiza łączy więc certyfikat z treścią panelu, historią DNS, otwartymi portami, czasem aktywności i próbkami aplikacji.

Wniosek Breachroad: liczbę 170 należy czytać jako rozmiar zbioru infrastruktury z pasującymi śladami, a nie licznik poszkodowanych. Ta różnica jest ważna zarówno w komunikacji z zarządem, jak i w priorytetyzacji threat intelligence.

Jak builder utrudnia blokowanie po nazwie aplikacji

Raport opisuje mechanizmy pozwalające builderowi zmieniać identyfikatory pakietu i nazwy klas. Dwie aplikacje zbudowane przez różnych operatorów mogą zatem wyglądać w manifeście inaczej, mimo wspólnego pochodzenia. Poleganie na jednej nazwie APK, nazwie pakietu lub sumie kontrolnej daje krótkotrwałą ochronę.

Konfiguracja adresu C2 miała być osadzana z użyciem AES-128-CBC i dopełniania. Szyfrowanie konfiguracji nie jest dowodem wysokiego poziomu kryptograficznego całego systemu; ma utrudnić proste wyszukiwanie adresu tekstowego w próbce. Obrońca może nadal wykrywać zachowanie aplikacji, sposób użycia Accessibility, wzorzec odszyfrowania konfiguracji, certyfikat podpisujący lub protokół komunikacyjny.

Badacze wskazali też podobieństwa części próbek do SpyNote. Tę informację należy traktować jako kontekst rodzin narzędzi, nie automatyczne zrównanie każdego Flying Eagle ze wszystkimi wariantami SpyNote.

Nadużycie Accessibility jest kluczowym sygnałem

Android Accessibility Services mają legalny cel: pomagają osobom z niepełnosprawnościami korzystać z urządzenia. Złośliwa aplikacja może jednak przekonać użytkownika do nadania jej bardzo szerokiej widoczności interfejsu i możliwości wykonywania akcji. Po uzyskaniu zgody może odczytywać tekst wyświetlany przez inne aplikacje, obserwować zdarzenia, klikać elementy i utrudniać usunięcie.

Samo żądanie Accessibility nie oznacza malware. Istotne są kontekst i kombinacja zachowań:

aplikacja podszywa się pod urząd, bank lub pracodawcę;
została pobrana spoza oficjalnego sklepu;
instrukcja wywiera presję, aby włączyć „specjalne uprawnienia”;
deklarowana funkcja nie uzasadnia dostępu do całego ekranu;
aplikacja próbuje ukryć ikonę albo blokować ustawienia;
urządzenie łączy się z nieznanym serwerem bez biznesowej potrzeby.

Szkolenie użytkownika powinno uczyć rozpoznawania tej sekwencji, a polityka MDM — technicznie ograniczać sideloading i przyznawanie usług ułatwień dostępu niezatwierdzonym aplikacjom.

Kogo dotyczy zagrożenie

Kampanie wykorzystujące fałszywą aplikację chińskich służb są najbardziej wiarygodne wobec osób, dla których taki motyw językowy i instytucjonalny brzmi naturalnie. Ryzyko nie ogranicza się jednak do jednego kraju. Kod builderski, panel i szablony można przemalować, a aplikację rozpowszechniać przez komunikator, SMS, fałszywą pomoc techniczną, proces rekrutacyjny albo oszustwo inwestycyjne.

Organizacje powinny zwrócić uwagę na:

telefony służbowe dopuszczające instalację APK spoza zarządzanego sklepu;
urządzenia BYOD z dostępem do poczty, VPN i komunikatorów;
pracowników często kontaktujących się z klientami w komunikatorach;
zespoły finansowe i osoby zatwierdzające płatności;
użytkowników pracujących na rynkach, gdzie fałszywe aplikacje urzędowe są popularnym pretekstem.

Raport z 29 lipca wspomina także o ostrzeżeniu opublikowanym 18 czerwca przez chińskie władze. Potwierdza to zainteresowanie problemem, lecz publiczne materiały nie pozwalają przypisać wszystkich hostów jednej kampanii.

Detekcja na urządzeniu i w sieci

Skuteczne wykrywanie nie powinno zależeć wyłącznie od listy 170 adresów. Infrastruktura może zniknąć, zmienić adres lub zostać ponownie użyta. W telemetrii urządzenia warto korelować:

instalację APK spoza zarządzanego źródła;
przyznanie Accessibility, uprawnień do aparatu, ekranu lub nakładek;
aplikację o reputacji niezgodnej z nazwą instytucji;
nietypowy certyfikat podpisujący i zmiany identyfikatora pakietu;
długotrwałe połączenia WebSocket do nieznanej infrastruktury;
próby ukrywania komponentów albo utrzymywania działania w tle;
nakładki pojawiające się nad aplikacją płatniczą.

W sieci lista IOC nadal jest przydatna do historycznego przeszukania DNS, proxy i NetFlow. Wynik należy jednak wzbogacić o czas, proces źródłowy, właściciela urządzenia oraz kontekst biznesowy. Trafienie może pochodzić z badania bezpieczeństwa, hostingu współdzielonego albo serwera, który później zmienił właściciela.

Reakcja na podejrzaną aplikację

Jeżeli urządzenie służbowe może być zainfekowane:

odizoluj je od sieci firmowej bez kasowania dowodów;
zapisz godzinę, źródło instalacji, nazwę pliku i komunikację, która skłoniła użytkownika do działania;
zinwentaryzuj przyznane uprawnienia i konta zalogowane na urządzeniu;
unieważnij sesje pocztowe, VPN, SSO i komunikatorów z czystego urządzenia;
powiadom bank lub zespół finansowy, jeśli wpisywano hasła płatnicze;
przeprowadź analizę lub kontrolowane przywrócenie urządzenia zgodnie z procedurą MDM;
sprawdź konta pod kątem nowych metod MFA, reguł przekazywania i nietypowych logowań;
przeszukaj środowisko pod kątem tego samego źródła instalacji i wiadomości.

Odinstalowanie ikony nie zamyka incydentu. Jeżeli aplikacja widziała ekran, klawiaturę lub sesje, zakres obejmuje także tożsamość cyfrową i potencjalne transakcje.

Jak czytać komunikaty operatorów malware

Kanały przestępcze często reklamują funkcje, liczbę klientów lub skuteczność narzędzia. Takie deklaracje nie są źródłem o tej samej wiarygodności co przeanalizowany kod, serwer czy telemetria. W przypadku Flying Eagle potwierdzone są elementy znajdujące się w analizowanym archiwum i fingerprinty wykrytych usług. Reklamowe zapewnienia z Telegramu pozostają twierdzeniami sprzedawców.

W raporcie wewnętrznym warto oznaczać:

obserwację — element znaleziony w próbce lub logu;
ocenę — najbardziej prawdopodobne wyjaśnienie kilku obserwacji;
deklarację przeciwnika — informację, której nie udało się niezależnie potwierdzić.

Taka dyscyplina zapobiega zamianie marketingu cyberprzestępców w „potwierdzony fakt”.

Co warto zrobić dziś

zablokuj sideloading tam, gdzie nie ma biznesowego uzasadnienia;
ustaw alert na nowe, niezatwierdzone usługi Accessibility;
przeszukaj historyczne logi pod kątem IOC z raportu Hunt.io;
sprawdź WebSocket i ruch z urządzeń Android do nieznanych hostów;
przypomnij pracownikom, że urząd, bank ani rekruter nie powinien żądać instalacji APK z komunikatora;
przygotuj procedurę rotacji sesji i poświadczeń dla utraconego telefonu;
nie przedstawiaj 170 serwerów jako 170 potwierdzonych ofiar.

Największą wartość daje połączenie kontroli technicznych z zachowaniem użytkownika. Szkolenia z cyberbezpieczeństwa i phishingu pokazują zespołom, jak rozpoznawać fałszywe aplikacje, presję socjotechniczną i niebezpieczne prośby o uprawnienia. Dalszy kontekst znajdziesz w materiałach o phishingu oraz pentestach aplikacji mobilnych.

Jeśli organizacja zarządza flotą Android lub BYOD, audyt bezpieczeństwa IT może zweryfikować polityki MDM, źródła aplikacji, sygnały detekcyjne i proces reakcji. Lista IOC jest punktem startowym; trwałą ochronę zapewnia dopiero ograniczenie uprawnień, obserwowalność urządzeń i przećwiczony proces.

Jak wykorzystać mapę infrastruktury bez generowania fałszywych alarmów

Lista hostów jest najbardziej użyteczna jako materiał do przeszukania historycznego, nie wieczna lista blokowania. Każdy IOC powinien mieć źródło, datę obserwacji, typ śladu i termin ponownej oceny. Adres IP może po czasie trafić do innego klienta hostingu, a certyfikat może zostać skopiowany. Bez tych atrybutów zespół ryzykuje alarmowanie na legalny ruch wiele miesięcy po kampanii.

Proces może wyglądać następująco:

pobierz IOC z raportu i zachowaj wersję źródła;
przypisz poziom pewności do fingerprintu panelu, certyfikatu i samego adresu;
przeszukaj DNS, proxy, EDR i MDM w dokładnym przedziale czasu;
wzbogacaj trafienie o urządzenie, aplikację, użytkownika i przyznane uprawnienia;
eskaluj kombinację sygnałów, a pojedynczy stary adres pozostaw do analizy;
wygaszaj reguły, których infrastruktura utraciła znaczenie.

Taki cykl jest praktycznym zastosowaniem Cyber Threat Intelligence. Celem CTI nie jest gromadzenie jak najdłuższej listy, lecz skrócenie decyzji: izolować urządzenie, unieważniać sesje czy zamknąć fałszywe trafienie.

Test gotowości floty Android

Bez instalowania malware można wykonać bezpieczny przegląd ustawień. Administrator sprawdza, czy MDM wykrywa sideloading, nową usługę Accessibility, aplikację o nieznanym certyfikacie oraz utratę kontaktu z agentem. Zespół reakcji ćwiczy odwołanie sesji i zdalne ograniczenie dostępu, a helpdesk weryfikuje, czy umie zebrać źródło APK bez instruowania użytkownika do dalszego otwierania pliku.

Warto zmierzyć czas od alertu do identyfikacji właściciela, izolacji, unieważnienia sesji i decyzji o przywróceniu urządzenia. Akademia Breachroad może uzupełnić wspólny język między helpdeskiem, SOC i użytkownikiem. Dzięki temu komunikat „podejrzana aplikacja” zamienia się w powtarzalny proces obejmujący urządzenie, tożsamość i płatności.

Flying Eagle jest dobrym przypomnieniem, że widoczna ikona aplikacji to tylko fragment incydentu. Obrońca musi rozumieć kanał instalacji, uprawnienia, sesje oraz infrastrukturę i potrafić oddzielić mocny ślad badawczy od atrakcyjnej, lecz niepotwierdzonej liczby ofiar.