Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
RedHook to złośliwe oprogramowanie typu RAT dla systemu Android, które w najnowszej odsłonie rozszerzyło swoje możliwości o nadużycie mechanizmu Wireless ADB. Oznacza to, że malware może uzyskać uprawnienia powłoki systemowej bez podłączania smartfona do komputera i bez rootowania urządzenia. To istotna zmiana jakościowa, ponieważ łączy klasyczne techniki socjotechniczne, nadużycie usług dostępności oraz funkcje zwykle przeznaczone dla programistów.
W skrócie
Aktualna wersja RedHook wykorzystuje Wireless Debugging dostępny w Androidzie 11 i nowszych do ustanowienia lokalnego połączenia ADB bezpośrednio na urządzeniu. Atak rozpoczyna się od nakłonienia ofiary do przyznania uprawnień Accessibility, po czym malware automatyzuje aktywację opcji programistycznych i debugowania bezprzewodowego. Następnie odczytuje kod parowania, łączy się z lokalnym interfejsem ADB i uruchamia komponent oparty o Shizuku, uzyskując dostęp do konta shell UID 2000.
- nadużycie usług Accessibility do sterowania interfejsem systemu,
- lokalne parowanie Wireless ADB bez użycia komputera,
- wykorzystanie Shizuku do wykonywania uprzywilejowanych operacji,
- możliwość realizacji dziesiątek komend z serwera C2,
- wielowarstwowe mechanizmy utrwalania obecności na urządzeniu.
Kontekst / historia
RedHook był wcześniej opisywany jako mobilny trojan zdalnego dostępu skoncentrowany na kradzieży danych, przechwytywaniu ekranu oraz automatyzacji interakcji z interfejsem użytkownika. Najnowsze analizy wskazują jednak na wyraźną ewolucję zagrożenia. Operatorzy malware przeszli od standardowego zestawu uprawnień aplikacyjnych do modelu, w którym legalne funkcje systemu Android są wykorzystywane jako narzędzia eskalacji możliwości operacyjnych.
Wireless Debugging został oficjalnie wprowadzony w Androidzie 11 jako funkcja zdalnego debugowania przez sieć Wi‑Fi. W przypadku RedHook ta legalna funkcjonalność została przekształcona w wektor uzyskania podwyższonych uprawnień działania. Kampanie dystrybucyjne nadal opierają się na socjotechnice, w tym podszywaniu się pod instytucje publiczne lub finansowe oraz kierowaniu użytkowników do fałszywych stron imitujących zaufane źródła pobierania aplikacji.
Analiza techniczna
Łańcuch ataku rozpoczyna się od instalacji złośliwego pakietu APK i przekonania użytkownika do aktywacji usługi Accessibility. To kluczowy etap, ponieważ właśnie te uprawnienia umożliwiają malware automatyczne sterowanie interfejsem systemu, poruszanie się po ustawieniach i wykonywanie działań, które w normalnych warunkach wymagałyby ręcznej interakcji użytkownika.
Po uzyskaniu dostępu do usług dostępności RedHook przechodzi do ustawień systemowych, aktywuje opcje programistyczne, włącza Wireless Debugging i inicjuje proces parowania. Najważniejszym elementem nowej techniki jest to, że złośliwa aplikacja nie potrzebuje zewnętrznego hosta ADB. Zamiast komputera z klientem adb wykorzystuje osadzony komponent kliencki i komunikuje się z lokalnym demonem ADB przez interfejs loopback 127.0.0.1.
Po udanym parowaniu malware uzyskuje dostęp do powłoki z uprawnieniami UID 2000, czyli konta shell wykorzystywanego przez Android do bardziej uprzywilejowanych operacji niż te dostępne dla zwykłych aplikacji. W dalszym etapie RedHook wykorzystuje framework Shizuku jako warstwę pośrednią do realizacji uprzywilejowanych wywołań API oraz poleceń powłoki. Dzięki temu może wykonywać działania, które zazwyczaj wymagałyby ADB albo roota, mimo że formalnie pełnych uprawnień roota nie uzyskuje.
Analiza wskazuje również na rozbudowany zestaw funkcji operacyjnych. Aktualna wersja RedHook obsługuje 53 komendy otrzymywane z serwera C2. Obejmują one między innymi:
- streaming ekranu i wykonywanie zrzutów,
- symulowanie dotknięć, gestów i interakcji z interfejsem,
- blokowanie oraz odblokowywanie urządzenia,
- instalację i usuwanie aplikacji,
- zbieranie kontaktów, wiadomości SMS i listy aplikacji,
- tworzenie nakładek phishingowych,
- aktywację kamery,
- restart urządzenia.
Na uwagę zasługują również mechanizmy persistence. RedHook wykorzystuje odtwarzanie cichego dźwięku do podnoszenia priorytetu procesu, WakeLock do zapobiegania uśpieniu CPU, wzajemnie odtwarzające się usługi w osobnych procesach, watchdog uruchamiany cyklicznie oraz automatyczny start po restarcie systemu. Badacze opisują także manipulację parametrem oom_score_adj, co ma zmniejszyć ryzyko zakończenia procesu pod presją pamięci. W praktyce oznacza to wielowarstwowy model utrzymania obecności zaprojektowany z myślą o długotrwałej infekcji.
Konsekwencje / ryzyko
Najważniejszym skutkiem tej techniki jest zwiększenie skuteczności mobilnego malware bez konieczności użycia klasycznego exploita lokalnego lub roota. RedHook nie przejmuje pełnej kontroli administracyjnej nad systemem, ale poziom shell UID 2000 i integracja z Shizuku dają wystarczająco szeroki zakres możliwości, aby znacząco zwiększyć kontrolę nad urządzeniem i utrudnić wykrycie incydentu.
Dla użytkowników końcowych oznacza to wysokie ryzyko kradzieży danych uwierzytelniających, przejęcia aktywnych sesji, podszywania się pod ofiarę oraz prowadzenia dalszych oszustw finansowych. Dla organizacji zagrożenie obejmuje kompromitację urządzeń używanych do dostępu do poczty, bankowości, komunikatorów, aplikacji biznesowych oraz środowisk zarządzanych w modelu BYOD lub COPE.
Szczególnie niebezpieczne jest to, że technika opiera się na legalnych funkcjach systemu i nie wymaga roota. Utrudnia to wykrywanie zarówno samym użytkownikom, jak i części narzędzi ochronnych bazujących wyłącznie na prostych wskaźnikach kompromitacji. Możliwość cichej instalacji lub usuwania aplikacji oraz modyfikowania ustawień bez widocznych komunikatów dodatkowo zwiększa skalę ryzyka.
Rekomendacje
Organizacje powinny traktować nadużycie Accessibility i Wireless Debugging jako powiązany scenariusz zagrożenia mobilnego. W praktyce oznacza to potrzebę monitorowania nietypowego włączania opcji programistycznych, aktywacji debugowania bezprzewodowego oraz nadawania uprawnień usługom dostępności aplikacjom pochodzącym spoza zaufanych źródeł.
- ograniczyć możliwość instalacji aplikacji spoza oficjalnych sklepów,
- wymuszać polityki MDM blokujące lub raportujące aktywne opcje programistyczne,
- monitorować nadane uprawnienia Accessibility oraz zmiany w ustawieniach secure i global,
- utrzymywać aktywną ochronę Google Play Protect,
- szkolić użytkowników pod kątem fałszywych stron dystrybucji APK i kampanii podszywających się pod instytucje,
- wdrożyć rozwiązania MTD lub mobilne EDR analizujące zachowanie aplikacji, a nie tylko sygnatury.
W przypadku podejrzenia infekcji zalecane jest natychmiastowe odizolowanie urządzenia, przegląd listy zainstalowanych aplikacji, analiza aktywnych usług dostępności, weryfikacja ustawień programistycznych oraz debugowania, a następnie reset i odtworzenie środowiska z zaufanego źródła. W wielu przypadkach konieczna będzie również zmiana haseł oraz unieważnienie aktywnych sesji usług używanych na zainfekowanym urządzeniu.
Podsumowanie
RedHook pokazuje, że współczesne malware na Androida coraz częściej nie ogranicza się do prostego phishingu czy klasycznych funkcji trojanów bankowych. W tej kampanii operatorzy połączyli socjotechnikę, nadużycie Accessibility, lokalne parowanie Wireless ADB i legalny framework Shizuku, aby uzyskać trwały oraz uprzywilejowany dostęp do urządzenia bez roota i bez fizycznego połączenia z komputerem.
To ważny sygnał dla zespołów bezpieczeństwa mobilnego. Funkcje deweloperskie i administracyjne Androida stają się realnym elementem powierzchni ataku, dlatego skuteczna obrona wymaga nie tylko blokowania złośliwych aplikacji, ale również monitorowania zmian konfiguracji systemu, uprawnień wysokiego ryzyka oraz zachowań wskazujących na automatyzację działań na urządzeniu.
Źródła
- BleepingComputer – RedHook Android malware now uses Wireless ADB for shell access — https://www.bleepingcomputer.com/news/security/redhook-android-malware-now-uses-wireless-adb-for-shell-access/
- Group-IB Blog – RedHook Returns with a Dangerous Upgrade — https://www.group-ib.com/blog/redhook-android-rat-upgraded/
- Android Developers – Android Debug Bridge (adb) — https://developer.android.com/tools/adb
- Android Developers – Features and APIs Overview: Android 11 — https://developer.android.com/about/versions/11/features
- Android Developers – Run apps on a hardware device — https://developer.android.com/studio/run/device.html