RatHat transforme les outils de débogage natifs d’Android et l’IA générative en canal de contrôle persistant

Une nouvelle famille de logiciels malveillants Android baptisée RatHat combine l’exploitation abusive des services d’accessibilité, l’appairage ADB autonome, des superpositions destinées à voler les identifiants, des services natifs en arrière-plan et la navigation de l’interface pilotée par l’IA. Des chercheurs ont signalé ce malware le 17 septembre 2026 et attribuent ses opérations à des acteurs malveillants basés en Chine.

RatHat atteint ses victimes par le biais de publicités malveillantes, de campagnes de phishing par SMS, de pages de téléchargement trompeuses, de portails tiers et de forums. Ces campagnes incitent les utilisateurs à installer des paquets APK hébergés en dehors de Google Play.

Une fois installé et après obtention des autorisations d’accessibilité, RatHat peut activer le débogage sans fil, s’appairer avec le service Android Debug Bridge local de l’appareil et obtenir une exécution au niveau du shell. Ses composants peuvent ensuite préserver l’accès même si la victime supprime l’application Android visible.

Des APK installés en dehors du store ouvrent la voie à l’exploitation des services d’accessibilité

L’APK initial sert de dropper pour la charge utile principale de RatHat. Il intègre également des protections destinées à perturber l’inspection automatisée, le débogage et la rétro-ingénierie.

L’infection repose largement sur l’ingénierie sociale. Les utilisateurs d’Android doivent installer le paquet en dehors de Google Play, puis accorder des autorisations qui confèrent à l’application un contrôle étendu de l’interface.

Les services d’accessibilité jouent un rôle central dans l’attaque. Conçus pour aider les utilisateurs à interagir avec les appareils, ils peuvent également permettre à une application d’observer les éléments de l’interface et d’effectuer des actions simulées lorsqu’ils sont détournés.

Après avoir obtenu cet accès, RatHat peut parcourir les paramètres Android, activer les Options pour les développeurs, activer le débogage sans fil et récupérer le code à six chiffres utilisé pour l’appairage ADB. Il peut ainsi établir une connexion de débogage locale sans qu’un ordinateur contrôlé par l’attaquant soit physiquement connecté.

Cette technique d’auto-appairage donne à RatHat accès à un shell ADB et à des capacités qui dépassent celles implémentées directement dans l’application malveillante. Des mécanismes similaires ont déjà été observés dans les familles de logiciels malveillants Android ToxicPanda et RedHook.

Les versions d’Android concernées n’ont pas été communiquées. Aucun nom de paquet malveillant, hash, domaine, adresse IP ou autre indicateur propre à la campagne n’est actuellement disponible.

Trois composants assurent une persistance redondante

RatHat utilise trois couches coopérantes au lieu de s’appuyer sur un seul paquet Android.

La première est l’application malveillante elle-même. Elle gère l’accès aux services d’accessibilité, active les fonctions de débogage, déploie d’autres composants, affiche des superpositions de phishing, intercepte les communications, enregistre l’écran et empêche sa suppression.

Le deuxième composant est un agent local basé sur Go, déguisé ou empaqueté sous le nom liblocal-service.so. Exécuté avec les accès obtenus par l’intermédiaire du démon ADB local, l’agent peut exécuter des commandes fournies par l’attaquant, demander des exemptions de gestion de la batterie, assurer la persistance et collecter les frappes ou les pressions à l’écran.

L’agent vérifie également si le malware Android est toujours installé. Si l’application a été supprimée, il peut la réinstaller.

La troisième couche est un client proxy inverse FRP. Un rapport consacré à l’architecture de RatHat identifie sa bibliothèque sous le nom libmedia_codec.so. Le composant reçoit la configuration du tunnel par l’intermédiaire de l’agent Go et crée une connexion inverse persistante avec l’infrastructure de commande et de contrôle.

Ce tunnel fournit aux opérateurs un accès polyvalent au démon ADB de l’appareil, indépendamment des commandes intégrées à RatHat. Il peut maintenir l’accès même lorsque certaines fonctions du malware sont neutralisées.

La persistance fonctionne dans les deux sens. L’application Android peut restaurer l’agent local si celui-ci s’arrête ou disparaît, tandis que l’agent peut réinstaller l’application. La simple suppression de l’icône de l’application ou du paquet visible peut donc laisser l’appareil compromis.

RatHat perturbe également activement la désinstallation. Il annule le processus de confirmation d’Android et affiche un faux écran d’erreur reprenant l’apparence de Google Play, afin de faire croire à la victime que la suppression a échoué pour une raison légitime liée au système.

L’IA générative interprète les écrans Android en temps réel

La particularité de RatHat réside dans un mécanisme de contrôle assisté par l’IA qui interprète l’interface utilisateur affichée au lieu de dépendre entièrement de coordonnées fixes et de scripts prédéfinis.

Le malware sérialise la hiérarchie d’accessibilité Android en XML. Il envoie ensuite cette représentation à un assistant d’IA générative largement utilisé, dont le nom n’a pas été communiqué.

Le système d’IA serait utilisé pour trois tâches :

• Rechercher un élément d’interface nommé et renvoyer ses coordonnées centrales au format JSON.
• Extraire le texte actuellement affiché par un élément sélectionné.
• Générer des instructions de navigation telles que SCROLL_DOWN.

Ce dispositif crée une boucle de décision dynamique. Si la position d’un bouton change, si une application affiche un texte différent ou si un écran nécessite un défilement, l’IA peut interpréter l’arborescence d’accessibilité mise à jour et suggérer l’action suivante.

L’automatisation rigide échoue souvent lorsque les applications modifient leur mise en page, leur langue ou leur état d’interface. L’approche de RatHat permet au contraire aux opérateurs de décrire un élément cible et de déléguer une partie du processus de navigation au service d’IA.

L’identité de l’assistant est inconnue. Les chercheurs n’ont pas indiqué quel modèle ou fournisseur étaient utilisés, ni le protocole de communication, le mode de gestion du compte ou la question de savoir si le service était accessible directement ou par l’intermédiaire d’une infrastructure contrôlée par les attaquants.

Cette fonctionnalité ne rend pas le malware autonome à tous points de vue. RatHat repose toujours sur une architecture de contrôle étendue, des instructions de commande et de contrôle, un accès aux services d’accessibilité et une exécution locale via ADB. Toutefois, l’IA réduit le besoin, pour les opérateurs, de parcourir manuellement chaque écran ou de maintenir des scripts pour chaque variante d’interface.

Le vol bancaire ne représente qu’une partie de la menace

RatHat peut placer des superpositions HTML sur les applications bancaires et de cryptomonnaie afin de capturer les identifiants de compte. Il peut également intercepter les SMS et les notifications, ce qui peut exposer les mots de passe à usage unique utilisés lors de l’authentification.

Ses capacités de surveillance s’étendent à l’ensemble de l’appareil. Elles comprennent notamment :

• La capture des codes PIN, mots de passe et schémas de déverrouillage de l’écran.
• L’enregistrement des identifiants saisis dans les applications.
• La surveillance des événements de modification de texte et des frappes.
• La collecte des URL saisies dans les barres d’adresse des navigateurs.
• L’enregistrement des pressions à l’écran par l’intermédiaire de l’agent Go.
• La création de captures d’écran et d’enregistrements à l’aide de l’API MediaProjection d’Android.
• La collecte de fichiers et de l’inventaire des applications installées.
• La navigation à distance dans les applications et les paramètres système.
• L’exécution de commandes arbitraires par l’intermédiaire du shell ADB.

Le tunnel inverse accroît l’impact de la menace, car il fournit un accès continu qui dépasse l’éventail défini des fonctions du malware. Un opérateur disposant d’un accès au démon ADB peut utiliser les fonctions au niveau du shell exposées par l’appareil compromis.

RatHat représente donc une menace pour les comptes bancaires, les services de cryptomonnaie, les messages privés, les fichiers stockés, les codes d’authentification et les secrets de déverrouillage de l’appareil. L’enregistrement de l’écran et la surveillance des interactions tactiles peuvent également révéler des informations que les superpositions classiques de vol d’identifiants ne permettraient pas de capturer.

Cette campagne s’inscrit dans une tendance plus large de menaces Android utilisant des paquets installés en dehors du store pour mener des opérations de surveillance intrusive. Autre exemple récent, le malware Mantax Otax a lui aussi été distribué au moyen d’APK hébergés en dehors de Google Play, même si ses capacités et son architecture diffèrent de celles de RatHat.

Des structures APK malformées compliquent l’inspection

Les développeurs de RatHat utilisent plusieurs techniques anti-analyse afin de produire des comportements différents dans les propres analyseurs d’Android et dans les outils courants de rétro-ingénierie.

Certains fichiers sont déclarés comme des répertoires ou marqués à l’aide de l’indicateur de chiffrement à usage général de ZIP. La bibliothèque libziparchive d’Android peut ignorer ces entrées, tandis que des utilitaires tels que unzip et apktool les traitent différemment.

Le fichier AndroidManifest.xml contient des en-têtes de bloc non documentés 0x9999. L’environnement d’exécution natif d’Android ignore ces structures, mais les systèmes d’analyse automatisée peuvent planter, expirer ou échouer à analyser le paquet. Il a également été indiqué que le manifeste atteignait 61 Mo, une taille anormale qui alourdit encore les chaînes d’analyse.

RatHat insère en outre des pseudo-instructions DEX invalides dotées d’un attribut element_width incorrect, ce qui peut perturber les désassembleurs. Un mécanisme à double protection des chaînes identifié sous le nom StringCrypto: Base64 complique davantage l’examen statique.

Ces défenses ne donnent pas directement le contrôle de l’appareil. Elles visent à retarder la classification, à produire des résultats incohérents selon les outils et à réduire la fiabilité des flux automatisés d’analyse des malwares.

Les chercheurs estiment que RatHat est exploité par des acteurs basés en Chine. Des invites en chinois envoyées au sous-système d’IA étayent cette évaluation, mais aucun groupe malveillant n’a été officiellement identifié. L’attribution reste provisoire.

La détection doit aller au-delà de l’application visible

Les utilisateurs doivent éviter les APK promus par des SMS non sollicités, des publicités, des forums, des pages de phishing ou des portails de téléchargement inconnus. Une application ne doit pas bénéficier d’un accès aux services d’accessibilité, sauf si sa fonction légitime l’exige clairement.

L’activation inattendue des Options pour les développeurs ou du débogage sans fil constitue un signal d’alerte important. Les utilisateurs doivent également rechercher d’éventuelles invites d’appairage ADB inexpliquées, des demandes d’exemption de batterie, des autorisations suspectes d’enregistrement de l’écran et des applications affichant des erreurs inspirées de Google Play lors de leur suppression.

Les analyses effectuées par Google Play Protect peuvent aider à identifier les applications malveillantes, mais les services indépendants de RatHat rendent la réponse plus complexe que la simple suppression d’un APK.

Les équipes chargées de la sécurité des entreprises et des terminaux mobiles doivent rechercher :

• Des services d’accessibilité non autorisés.
• Une activation inattendue du débogage sans fil.
• Des événements d’appairage ADB local non reconnus.
• Des bibliothèques natives nommées liblocal-service.so ou libmedia_codec.so.
• Un trafic inhabituel associé à un proxy inverse FRP.
• Des processus persistants qui survivent à la suppression de l’application.
• La réinstallation répétée d’un paquet précédemment supprimé.
• De faux écrans d’échec de désinstallation reprenant l’apparence de Google Play.

Les seuls noms de bibliothèques ne suffisent pas à prouver une infection et doivent être analysés avec les activités liées aux processus, aux paquets, au réseau et à ADB.

Aucune procédure complète de remédiation proposée par un éditeur n’a été publiée. Comme l’agent Go de RatHat peut survivre à la suppression de l’application principale et la réinstaller par la suite, les intervenants doivent vérifier que le service accessible via ADB et le tunnel inverse ont eux aussi disparu. Dans le cas contraire, une suppression en apparence réussie peut n’éliminer que la partie la plus visible de la compromission.