RedHook : le RAT Android qui détourne l'ADB Wireless pour un shell

ADB Wireless, nouvel outil de prédilection d'un RAT Android furtif

Les chercheurs de Group-IB ont publié une analyse approfondie d'une version significativement améliorée de RedHook, un Remote Access Trojan (RAT) ciblant les appareils Android. Initialement documenté par les équipes de Cyble en juillet 2025, RedHook revient avec un mécanisme d'élévation de privilèges inédit dans l'écosystème des malwares mobiles : l'abus du débogage ADB (Android Debug Bridge) sans fil. Cette technique permet au malware d'obtenir des droits shell de niveau UID 2000 — bien supérieurs à ceux d'une application Android standard, mais sans nécessiter de root complet — en exploitant une fonctionnalité de développement intégrée à Android depuis la version 11.

ADB Wireless Debugging est une fonctionnalité officielle d'Android conçue pour permettre aux développeurs de déboguer leurs applications sans câble USB. Introduite avec Android 11 et accessible dans le menu Développeur des paramètres système, elle établit un serveur ADB écoutant sur le réseau local de l'appareil. RedHook a compris qu'en combinant cette fonctionnalité avec les Services d'Accessibilité d'Android — des permissions légitimes permettant à des applications d'interagir avec l'interface utilisateur d'autres apps — il pouvait déclencher et exploiter l'ADB sans fil localement, via la boucle de loopback réseau, sans aucune connexion physique ni accès root préalable.

La chaîne d'infection commence par l'ingénierie sociale. Les opérateurs de RedHook contactent leurs victimes par messages ou appels téléphoniques en se faisant passer pour des représentants d'agences gouvernementales — services fiscaux, organismes de protection sociale — ou d'institutions financières. Ces contacts fabriquent un prétexte urgent nécessitant l'installation d'une application officielle, et redirigent la victime vers un faux site imitant le Google Play Store depuis lequel le package APK malveillant est téléchargé. La page de téléchargement est conçue pour ressembler visuellement à une page d'application légitime, avec de faux avis et une notation artificielle.

Une fois installé et lancé, RedHook demande l'activation des Services d'Accessibilité en présentant à la victime un argumentaire plausible. Une fois cette permission critique accordée, le malware agit de manière entièrement autonome. Il navigue programmatiquement dans les Paramètres système, active les Options de développeur — en reproduisant la séquence habituelle consistant à tapoter sept fois sur le numéro de build — puis active spécifiquement le Débogage sans fil dans le sous-menu développeur. Ces interactions sont réalisées via l'API Accessibility d'Android, qui permet à une application tierce de simuler des tapotements et navigations dans n'importe quelle interface système, y compris les paramètres de l'OS lui-même.

L'étape critique survient au moment où Android affiche à l'écran le code d'appairage généré pour la session ADB Wireless. RedHook, grâce aux Services d'Accessibilité, lit ce code directement depuis l'affichage de l'écran sans que la victime ait à le saisir ou à l'approuver manuellement. Le malware s'appaire ensuite au service ADB en écoute sur l'interface de loopback (127.0.0.1), établissant une connexion shell locale avec les droits UID 2000. L'ensemble du processus — activation des options développeur, déclenchement du débogage ADB, lecture du code et connexion — s'effectue en arrière-plan en quelques secondes, sans que l'utilisateur voie autre chose que l'interface de l'application frauduleuse.

Une fois la connexion ADB établie, RedHook déploie le framework Shizuku en tant que serveur privilégié, implémenté comme bibliothèque libmx.so. Shizuku est un framework open source légitime permettant aux applications Android d'invoquer des API systèmes protégées via un serveur maintenu avec les droits UID 2000. Son détournement par RedHook permet d'accéder à des fonctions normalement hors de portée d'une application non-root : installation et désinstallation silencieuse d'autres applications, modification de paramètres système protégés, lecture et écriture de zones de stockage normalement restreintes, et accès aux interfaces de gestion des comptes système permettant d'extraire des tokens d'authentification sans connaître les mots de passe.

Les capacités offensives de RedHook une fois pleinement déployé sont particulièrement étendues. Selon l'analyse de Group-IB, le RAT peut voler des credentials stockés dans des applications tierces, capturer le contenu de l'écran en temps réel, simuler des interactions utilisateur à l'insu de la victime, prendre des photos avec les caméras frontale et arrière, verrouiller et déverrouiller l'appareil à distance, et le redémarrer selon les instructions de l'opérateur. L'accès aux API de gestion des comptes permet également d'exfiltrer les tokens d'authentification des applications connectées — messageries, applications bancaires, services email — sans avoir à connaître les mots de passe correspondants.

La persistance de RedHook est particulièrement élaborée et résiliente face aux tentatives de désinstallation. Le malware met en oeuvre plusieurs mécanismes enchevêtrés simultanément : une lecture audio silencieuse en continu pour augmenter la priorité système du processus, des WakeLocks pour empêcher le CPU de s'endormir, deux services Android qui se relancent mutuellement si l'un est arrêté, une alarme watchdog se déclenchant toutes les cinq minutes, un redémarrage automatique après le démarrage du téléphone, et un paramètre oom_score_adj réglé à -1000 — la valeur minimale — pour le rendre quasiment insupprimable par le gestionnaire de mémoire d'Android en cas de pression sur les ressources. La désinstallation manuelle est rendue extrêmement difficile sans le mode sans échec ou une réinitialisation aux paramètres usine.

Un détournement d'outil développeur qui redéfinit les risques sur Android

Le mécanisme d'exploitation de l'ADB Wireless par RedHook représente une innovation significative dans le paysage des malwares Android. Jusqu'ici, les RATs Android cherchaient généralement à exploiter des vulnérabilités systèmes pour obtenir le root, ou à abuser de permissions légitimes comme les Services d'Accessibilité pour des interactions de surface. RedHook franchit une nouvelle étape en combinant les Services d'Accessibilité comme vecteur d'initialisation avec ADB Wireless comme canal d'escalade de privilèges, obtenant des capacités quasi-root sans déclencher les alarmes habituellement associées aux tentatives de root classiques détectées par les solutions de sécurité mobile.

La surface d'attaque potentiellement concernée est colossale. Android représente plus de 70 % des smartphones en usage mondial, avec plus de trois milliards d'appareils actifs. Le débogage ADB Wireless est disponible sur tous les appareils Android 11 et supérieur — soit la très grande majorité du parc actif. Si la fonctionnalité n'est pas activée par défaut, la séquence d'activation est intégralement à la portée du malware dès l'instant où les Services d'Accessibilité lui ont été accordés. Les utilisateurs qui accordent ces permissions à des applications frauduleuses s'exposent à la totalité de la chaîne d'attaque sans s'en rendre compte et sans aucune alerte de sécurité visible de la part du système.

La connexion potentielle de RedHook avec des groupes comme ShinyHunters et BlackFile — identifiée par les chercheurs de ReliaQuest sur la base d'une adresse IP d'exfiltration dans le même système autonome AS 51852 que des infrastructures BlackFile confirmées — suggère que cette technique pourrait rapidement diffuser vers d'autres acteurs malveillants. La publication de l'analyse technique par Group-IB, bien que nécessaire pour alerter la communauté de sécurité et permettre le développement de signatures de détection, risque simultanément d'accélérer l'adoption de cette méthode par des groupes moins sophistiqués cherchant à répliquer l'approche.

Les équipes de sécurité mobile et les responsables MDM (Mobile Device Management) doivent adapter leur posture de défense à cette nouvelle menace. Sur les appareils gérés en entreprise, les politiques MDM doivent inclure l'interdiction d'activer les Options de développeur et le débogage ADB, et verrouiller les paramètres système correspondants. Les solutions de détection des menaces mobiles (MTD) doivent être mises à jour pour surveiller les tentatives d'interaction avec les paramètres développeur depuis des applications tierces, et détecter les connexions ADB inattendues sur l'interface de loopback. La sensibilisation des utilisateurs aux risques des Services d'Accessibilité accordés à des applications non vérifiées reste le premier et le plus efficace des remparts : aucune application gouvernementale ou bancaire légitime ne requiert cette permission particulière.

Ce qu'il faut retenir

• RedHook est le premier RAT Android documenté à détourner le débogage ADB Wireless pour obtenir des droits shell (UID 2000) sans root, via une chaîne entièrement automatisée : Services d'Accessibilité, activation des options développeur, lecture du code d'appairage, connexion loopback ADB.
• Les appareils Android 11+ ayant accordé les Services d'Accessibilité à des applications non vérifiées sont exposés à l'intégralité de la chaîne d'attaque ; les politiques MDM doivent interdire l'activation des options développeur sur les flottes professionnelles.
• La distribution par ingénierie sociale via de faux sites Google Play usurpant l'identité de services officiels impose une vigilance accrue sur toute application installée hors du Play Store officiel ou sollicitant des permissions d'Accessibilité inhabituelles.