Le malware Android RatHat utilise l’IA, mais la persistance via ADB constitue une menace plus grave

Le malware Android RatHat a introduit un contrôle de l’écran guidé par l’IA, mais sa menace la plus profonde provient d’une architecture en trois volets conçue pour survivre à sa suppression. Des chercheurs en sécurité ont dévoilé le malware le 16 septembre 2026, après avoir analysé sa navigation automatisée, son vol d’identifiants et ses mécanismes de persistance inhabituels. RatHat combinerait l’accès à Android Accessibility, le débogage sans fil local et deux agents natifs opérant au-delà de l’application malveillante principale.

Le composant IA aide RatHat à interpréter des interfaces changeantes plutôt que de s’appuyer entièrement sur des instructions fixes. Il offre ainsi aux opérateurs un moyen plus souple de repérer des boutons, lire des libellés et naviguer sur des appareils compromis. Toutefois, l’IA ne fournit pas l’accès initial. Les victimes doivent toujours installer un package Android en dehors de Google Play et accorder les autorisations nécessaires au lancement de l’attaque.

Le changement le plus conséquent réside dans la tentative de RatHat de conserver le contrôle après la disparition de l’application visible. Des malwares antérieurs assistés par IA, dont PromptSpy, avaient montré comment un modèle de langage pouvait naviguer dans des interfaces propres à certains constructeurs. RatHat associerait cette capacité d’adaptation à un accès de niveau shell, des superpositions visant à voler des identifiants, un enregistrement des frappes et un tunnel réseau persistant.

Le malware Android RatHat associe IA et contrôle persistant

RatHat transforme une application Android malveillante en point d’entrée d’un système de contrôle plus vaste, capable de survivre à l’application elle-même.

L’équipe zLabs de Zimperium a dévoilé RatHat après avoir examiné une chaîne d’infection en plusieurs étapes diffusée par smishing, malvertising, pages de phishing et forums tiers. Ces canaux orientent les utilisateurs vers des fichiers APK malveillants, qui sont des packages d’application Android installés en dehors du flux habituel du Play Store.

L’application malveillante cherche d’abord à obtenir les autorisations Accessibility. Les services Android Accessibility sont conçus pour aider les personnes à interagir avec leurs appareils, mais ils peuvent aussi exposer le contenu des interfaces et permettre des saisies automatisées. Les opérateurs de malwares abusent fréquemment de ces capacités pour lire des écrans, appuyer sur des boutons et approuver des actions sensibles.

RatHat utiliserait cet accès pour activer les Options pour les développeurs et le Débogage sans fil. Il extrait ensuite le code d’association à six chiffres nécessaire à une connexion locale Android Debug Bridge. ADB est l’interface de commande légitime d’Android destinée au développement, aux tests et à l’administration des appareils.

Selon l’analyse détaillée de RatHat, ce processus permet à un agent Go intégré d’exécuter des commandes de niveau shell sans ordinateur externe. L’agent est stocké sous le nom trompeur de bibliothèque liblocal-service.so.

Cet agent peut exécuter des commandes, obtenir des exemptions de gestion de la batterie, collecter des saisies et assurer la persistance. Zimperium indique qu’il peut également vérifier si l’application malveillante est toujours installée et la restaurer si nécessaire. L’application peut de même restaurer l’agent si ce composant disparaît.

Un second composant natif, nommé libmedia_codec.so, agit comme client Fast Reverse Proxy. Il crée un tunnel entre les services locaux du téléphone et l’infrastructure de l’attaquant. Ce canal offre aux opérateurs un accès qui ne dépend pas uniquement du canal de commande initial de l’application.

RatHat peut afficher des superpositions HTML imitant des applications bancaires, de paiement et de cryptomonnaies. Une superposition place une interface frauduleuse au-dessus d’une application légitime, encourageant les utilisateurs à saisir leurs identifiants dans des champs contrôlés par l’attaquant.

Les chercheurs ont également découvert des fonctions d’interception des SMS, des notifications et des mots de passe à usage unique. Le malware peut enregistrer les modifications de texte, examiner les barres d’adresse des navigateurs, capturer des écrans et collecter la liste des applications installées.

Son agent natif surveillerait aussi les saisies tactiles de bas niveau. Cette fonction peut aider à reconstituer les pressions sur l’écran, codes PIN, mots de passe et schémas de déverrouillage à partir des mouvements de l’utilisateur.

Ces capacités font du sous-système IA une seule composante de la menace. RatHat utilise l’IA pour rendre la navigation plus adaptable, tandis que l’accès ADB et les agents natifs constituent sa base opérationnelle durable.

Le moteur de navigation par IA élimine une étape manuelle coûteuse

L’IA de RatHat importe parce qu’elle transforme des écrans Android changeants en décisions de navigation structurées, sans exiger une intervention constante de l’opérateur.

L’automatisation mobile traditionnelle dépend largement de mises en page prévisibles, d’identifiants de ressources ou d’instructions soigneusement rédigées. Cette approche devient peu fiable lorsque les constructeurs modifient les menus, traduisent les libellés ou repensent les boîtes de dialogue système.

Une instruction qui fonctionne sur un Google Pixel peut échouer sur un appareil Samsung, Oppo ou Xiaomi. Même les différences courantes de taille d’écran, de version logicielle et de structure d’accessibilité peuvent rompre une séquence fixe.

RatHat répond à ce problème en sérialisant l’arbre Accessibility actuel en XML. Cet arbre décrit les éléments visibles de l’interface, les libellés textuels, les types d’éléments et les positions à l’écran. Le malware envoie cet instantané structuré à ce que Zimperium appelle un assistant d’IA générative populaire.

Les chercheurs n’ont pas identifié le service, le modèle, le compte ou l’hébergement utilisé. RatHat ne devrait donc pas être décrit comme utilisant un modèle commercial précis sans éléments de preuve supplémentaires.

Le composant IA répondrait à des questions ciblées sur l’interface. Il peut renvoyer les coordonnées centrales d’un élément nommé, déterminer le texte affiché d’un élément ou fournir des instructions telles que SCROLL_DOWN.

Il s’agit d’un rôle limité mais utile. Le modèle n’invente pas l’attaque de manière indépendante et n’accorde pas de nouvelles autorisations Android. Il sert d’interprète d’interface entre l’objectif d’un opérateur et l’écran actuel de l’appareil.

Cette distinction compte, car les descriptions sensationnalistes de malwares autonomes peuvent masquer les mécanismes sous-jacents. RatHat repose toujours sur l’ingénierie sociale, des autorisations dangereuses, l’accès au débogage, du code natif malveillant et une infrastructure contrôlée par l’attaquant.

Sa couche IA peut néanmoins réduire le travail nécessaire. Un opérateur n’a pas besoin d’observer chaque écran infecté ni de maintenir un script d’automatisation distinct pour chaque variante d’interface. Le modèle peut convertir des données d’interface en direct en action suivante.

Le rapport de BleepingComputer sur la navigation par IA indique que cette adaptabilité distingue RatHat des automatisations reposant entièrement sur des scripts statiques. Elle offre également aux opérateurs distants un autre moyen de naviguer sans interaction manuelle continue.

Cette technique rappelle la découverte antérieure de PromptSpy. Ce malware envoyait des données sur l’état de l’écran à Google Gemini et recevait des instructions pour s’épingler dans l’interface des applications récentes d’un appareil. Le comportement d’épinglage diffère selon les constructeurs Android, ce qui en fait un problème adapté à une navigation guidée par modèle.

ESET n’avait pas observé PromptSpy dans sa télémétrie lorsque les précédentes recherches ont été publiées. Son ampleur réelle restait donc incertaine. RatHat étend ce concept à une architecture plus vaste, bien que sa prévalence reste elle aussi inconnue.

Cette évolution est importante. L’IA générative passe d’une aide au développement d’attaques à la boucle d’exécution de certains malwares. Son avantage immédiat n’est pas un raisonnement surhumain. C’est sa tolérance aux variations d’interface.

La persistance, et non l’IA, crée le problème de sécurité le plus difficile

Le conflit central de RatHat oppose adaptabilité et confinement : l’application initie la compromission, tandis que des agents distincts tentent de la préserver.

Le bac à sable applicatif d’Android sépare normalement les applications des fonctions système sensibles et les unes des autres. RatHat utiliserait l’association ADB locale pour déplacer une partie de son activité vers un contexte de niveau shell offrant un accès élargi aux commandes.

Cela ne signifie pas que le malware reçoit des privilèges root illimités. L’accès shell et l’accès root sont différents. Toutefois, un shell ADB peut encore effectuer des actions inaccessibles à une application conventionnelle et prendre en charge une exécution persistante de commandes.

L’agent Go de RatHat expose un service HTTP sur l’interface loopback de l’appareil. Le composant de proxy inverse peut ensuite rendre ce service interne accessible via un tunnel contrôlé par l’attaquant. Cette disposition sépare l’accès distant de l’interface visible de l’application malveillante.

La conception qui en résulte comporte trois éléments coopérants. L’application Android obtient les autorisations et coordonne l’activité. L’agent Go exécute les commandes et gère la persistance. Le proxy maintient une route externe vers les services locaux.

Si une victime ne supprime que l’application, un autre composant peut apparemment la réinstaller. Si l’agent natif s’arrête, l’application peut restaurer cet agent. Cette récupération réciproque est plus préoccupante qu’une simple technique de persistance.

RatHat entrave aussi les tentatives ordinaires de suppression. Les chercheurs affirment qu’il surveille l’écran de confirmation de désinstallation d’Android, annule l’action et affiche une fausse erreur Google Play au-dessus de l’interface.

Des comportements anti-suppression similaires sont antérieurs à RatHat. Les malwares Android abusent depuis longtemps des services Accessibility pour appuyer sur des boutons de navigation ou recouvrir des contrôles de sécurité. RatHat associe cette technique connue à un canal indépendant d’accès au shell.

Les défenses anti-analyse du malware ajoutent une couche supplémentaire. Les chercheurs ont identifié une altération de conteneur, des attributs ZIP inhabituels, des chaînes chiffrées, de pseudo-instructions DEX invalides et des vérifications d’exécution visant les outils d’analyse.

Son manifeste Android pèserait 61 Mo, dont 99 % seraient composés de deux types de chunks non documentés. L’environnement d’exécution Android ignore ces chunks, tandis que certains outils d’analyse peuvent échouer ou épuiser leurs ressources en les traitant.

La bombe de manifeste ne vole pas directement d’identifiants et ne contrôle pas un téléphone. Son objectif est de ralentir l’inspection automatisée et de rendre le package plus difficile à classifier. Ce délai peut accorder davantage de temps à une campagne avant la diffusion de signatures et d’indicateurs.

RatHat vérifie aussi la présence de débogueurs, de reconditionnement, d’émulateurs, d’artefacts root, de Frida et de Xposed. Ces outils sont courants dans les environnements d’analyse de malwares. Les détecter permet au code malveillant de modifier son comportement ou de cesser de s’exécuter sous observation.

L’architecture combinée exerce une pression sur les défenseurs qui se concentrent uniquement sur les fichiers d’application. La suppression d’un APK, la correspondance avec un hash connu ou le blocage d’un serveur de commande peuvent ne pas éliminer tous les composants actifs.

Les signaux comportementaux deviennent plus importants. Les équipes de sécurité peuvent rechercher des autorisations Accessibility suspectes, une activité inattendue de Débogage sans fil, une association ADB locale, des démons natifs inhabituels et des tunnels inverses persistants.

Cela ne rend pas la détection par signature inutile. Les hash de packages connus, domaines, certificats et indicateurs réseau restent précieux. RatHat montre pourquoi ces signaux doivent être complétés par une surveillance de l’exécution et de l’état des appareils.

Les applications bancaires font face à un adversaire au niveau de l’interface

RatHat attaque l’interaction de confiance entre un utilisateur et une application financière, et pas seulement les données stockées dans cette application.

Une application bancaire peut chiffrer sa base de données locale et protéger le trafic vers le serveur tandis qu’un malware observe l’écran de l’utilisateur. Si un service Accessibility hostile peut lire le contenu de l’interface ou injecter des pressions, les protections au niveau de l’application font face à un problème différent.

RatHat afficherait de fausses interfaces HTML au-dessus d’applications bancaires et de cryptomonnaies ciblées. Une victime peut croire qu’une invite de connexion appartient au service authentique tout en saisissant ses informations dans une superposition malveillante.

Le malware peut ensuite intercepter les SMS ou le contenu des notifications contenant des codes de vérification. Il peut également collecter le texte saisi et surveiller les adresses du navigateur, donnant aux opérateurs du contexte autour des identifiants capturés.

Android a ajouté des défenses contre ces techniques. Android 15 limite l’exposition de certains mots de passe à usage unique lors du partage d’écran et aux services d’écoute des notifications. Android 16 a introduit un moyen pour les développeurs de marquer les éléments d’interface sensibles.

Le paramètre accessibilityDataSensitive peut empêcher les services d’accessibilité non vérifiés de lire des vues protégées ou d’interagir avec elles. Les recommandations d’Android 16 de Google le conseillent pour les mots de passe, les informations financières et d’autres champs sensibles.

Les développeurs peuvent également utiliser les signaux d’environnement de Play Integrity. Le verdict d’accès aux applications peut indiquer si une autre application dispose d’autorisations lui permettant de capturer l’écran, d’afficher des superpositions ou de contrôler l’appareil.

Ces défenses augmentent le coût opérationnel de RatHat, mais elles ne font pas disparaître le problème. La protection dépend de la version d’Android, de la configuration de l’appareil, de l’adoption par les développeurs et du fait que l’application malveillante ait déjà établi un autre canal de contrôle.

L’accessibilité présente également un compromis difficile pour la plateforme. Android doit prendre en charge des logiciels d’assistance légitimes qui lisent le contenu de l’interface et exécutent des actions pour les utilisateurs. Bloquer toute interaction automatisée nuirait à ces outils essentiels.

Google examine les outils d’accessibilité distribués via Play et met en garde contre les usages trompeurs. Ses recommandations Play Protect indiquent qu’un service suspect peut demander le contrôle complet de l’appareil et l’accès à des informations personnelles ou financières.

RatHat entrerait par des téléchargements d’APK en dehors de Google Play. Cela limite l’exposition directe via la boutique officielle, mais le chargement latéral reste possible via les navigateurs, les messages, les forums et les places de marché tierces.

Google a signalé en mars 2026 que les malwares apparaissaient plus de 90 fois plus souvent dans les sources de chargement latéral que sur Google Play. L’entreprise étend la vérification des développeurs, avec des exigences d’installation régionales dont l’entrée en vigueur est prévue le 30 septembre 2026.

Ce calendrier place RatHat dans le contexte d’une réponse plus large de la plateforme face à la distribution malveillante. La vérification des développeurs peut renforcer la responsabilité pour les logiciels installés hors de Play, bien que des voies d’installation avancées resteront disponibles.

Les institutions financières ont elles aussi du travail à accomplir. Les actions à haut risque ne devraient pas dépendre entièrement d’éléments affichés ou saisis sur un téléphone potentiellement compromis.

La confirmation des transactions peut intégrer une notation de risque côté serveur, l’historique des appareils de confiance, les changements de comportement et des limites pour les nouveaux bénéficiaires. Les banques peuvent également contester des sessions lorsque les signaux d’intégrité de l’appareil ou d’accès aux applications indiquent un risque accru.

Pour les équipes en entreprise, les appareils mobiles méritent la même profondeur de réponse aux incidents que les ordinateurs portables. Un téléphone contenant des applications d’authentification, des messages professionnels, des sessions cloud et un accès bancaire peut devenir un pont vers plusieurs systèmes.

La portée et l’attribution de RatHat restent floues

Les capacités du malware sont documentées en détail, mais son nombre de victimes, l’ampleur de la campagne et l’identité de ses opérateurs restent non résolus.

Zimperium relie RatHat à des acteurs qui semblent opérer depuis la Chine. Les éléments de preuve publics comprennent des invites en chinois trouvées dans le malware et l’infrastructure de campagne observée.

La langue ne constitue pas une attribution définitive. Les développeurs de malwares peuvent réutiliser du code, placer de fausses pistes, travailler au-delà des frontières ou vendre des outils à des opérateurs sans lien entre eux. Les rapports disponibles n’identifient ni groupe nommé ni commanditaire gouvernemental.

La recherche publique ne fournit pas non plus de nombre confirmé d’infections. Elle ne répertorie ni les pays touchés, ni les banques ciblées, ni la durée de la campagne, ni le nombre de serveurs de commande actifs.

Ces informations manquantes limitent les conclusions sur l’exposition immédiate. RatHat pourrait soutenir une campagne très ciblée, un service criminel en développement ou une opération plus vaste que les chercheurs n’ont observée que partiellement.

Le service d’IA non identifié crée une autre incertitude. Les enquêteurs n’ont pas expliqué publiquement comment le malware s’authentifie auprès de l’assistant, à quelle fréquence il envoie des requêtes ou ce qui se passe en cas d’échec de la connectivité.

Les requêtes d’IA basées dans le cloud peuvent générer une activité réseau détectable. Les fournisseurs peuvent également suspendre les comptes abusifs, filtrer les invites suspectes ou coopérer aux enquêtes. Les attaquants peuvent réagir en faisant tourner les comptes, en utilisant des services proxy ou en passant à des modèles hébergés localement.

La fiabilité des modèles mérite également un examen attentif. L’automatisation d’interface peut échouer lorsque les données XML sont incomplètes, que les libellés sont ambigus ou que les écrans contiennent des boîtes de dialogue inattendues. Une pression erronée peut exposer le malware, interrompre une attaque ou empêcher les opérateurs d’y accéder.

Ces limites ne neutralisent pas la menace. Elles montrent que les malwares assistés par IA dépendent toujours de l’infrastructure, des identifiants, de la connectivité et d’une logique de repli soigneusement conçue.

Le précédent cas PromptSpy offre un point de comparaison utile. Sa fonctionnalité assistée par modèle répondait à une tâche de persistance limitée, tandis qu’un module VNC distinct permettait le contrôle à distance. Les chercheurs n’ont pas pu confirmer si ses échantillons représentaient une campagne active ou une preuve de concept.

RatHat semble plus complet sur le plan opérationnel. Ses canaux de diffusion, ses superpositions de vol d’identifiants, son système de commande, ses services natifs et son composant de tunneling forment une chaîne d’attaque cohérente.

Toutefois, l’exhaustivité technique n’équivaut pas à un déploiement à grande échelle. Les lecteurs devraient éviter de considérer chaque capacité documentée comme la preuve qu’elle a touché une vaste population.

Zimperium vend également des produits de sécurité mobile et affirme que ses produits détectent RatHat. Ce contexte commercial n’invalide pas les conclusions techniques, mais une reproduction indépendante demeure précieuse.

Un second compte rendu technique de The Hacker News corrobore l’architecture sur la base de la divulgation de Zimperium. Il ne constitue pas une analyse indépendante du malware reposant sur des échantillons distincts.

La conclusion la plus solide à ce stade est plus restreinte. Des chercheurs ont analysé un malware qui combine l’interprétation d’interface guidée par IA avec des techniques éprouvées de prise de contrôle d’Android et une architecture inhabitulement persistante fondée sur ADB.

Trois signaux indiqueront si RatHat transforme les malwares mobiles

Le prochain test consistera à déterminer si les techniques de RatHat se répandent au-delà d’une seule famille signalée et imposent des changements mesurables aux défenseurs, aux applications financières et à Android.

Le premier signal est l’existence d’éléments indépendants attestant de campagnes. D’autres chercheurs devraient rechercher des échantillons correspondants, l’infrastructure de commande, les certificats de signature, les pages de diffusion et des infections dans la télémétrie des clients.

Une géographie confirmée des victimes permettrait de déterminer si RatHat cible certaines banques ou régions. Une hausse du nombre d’échantillons suggérerait un développement ou une diffusion active plutôt qu’une expérimentation technique isolée.

L’absence de télémétrie étendue affaiblirait les affirmations selon lesquelles RatHat représente une vague mondiale immédiate. Elle n’effacerait pas la leçon architecturale, mais elle en modifierait le degré d’urgence.

Le deuxième signal est la réutilisation de la chaîne de persistance ADB locale. Les auteurs de malwares copient fréquemment les techniques qui se révèlent fiables, particulièrement lorsque la recherche publique révèle suffisamment de détails d’implémentation pour inspirer l’imitation.

Les défenseurs devraient surveiller les nouvelles familles qui activent Wireless Debugging, récupèrent les codes d’appairage, déploient des agents au niveau du shell et préservent l’accès après la suppression de l’application. Une adoption répétée rendrait ce mécanisme plus conséquent que la marque RatHat elle-même.

Android et les fabricants d’appareils peuvent réagir en renforçant les transitions entre Accessibility, Developer Options, l’appairage sans fil et les processus shell en arrière-plan. De meilleurs avertissements destinés aux utilisateurs pourraient également révéler des combinaisons suspectes de ces actions.

Le troisième signal est l’extension de l’IA à l’exécution au-delà de la simple consultation d’interface. RatHat demanderait à un modèle des coordonnées, du texte visible et des commandes de navigation. De futurs échantillons pourraient utiliser des modèles pour classer les écrans financiers, adapter des invites frauduleuses ou sélectionner des actions à partir d’objectifs plus larges.

Cette évolution renforcerait l’argument en faveur de la surveillance du trafic vers les services d’IA dans le cadre des enquêtes sur les malwares. Elle pousserait également les fournisseurs de modèles à identifier les abus automatisés sans bloquer les flux de travail légitimes d’accessibilité et de test.

Si l’IA reste limitée à quelques tâches de navigation fragiles, RatHat apparaîtra comme une amélioration incrémentale de l’automatisation. Si plusieurs familles de malwares adoptent des boucles de décision, les défenseurs feront face à un comportement plus variable selon les appareils.

Les utilisateurs peuvent réduire le risque actuel sans attendre ces signaux. Évitez les fichiers APK diffusés via des messages non sollicités, des publicités ou des pages de téléchargement inconnues. Considérez les demandes d’Accessibility inattendues comme un avertissement sérieux, particulièrement lorsqu’elles proviennent d’applications sans rapport avec des fonctions d’assistance.

Gardez Play Protect activé et autorisez-le à analyser les applications inconnues. Vérifiez les services d’Accessibility activés, l’accès aux notifications, les applications administratrices de l’appareil, Developer Options et Wireless Debugging en cas de suspicion de compromission.

Un appareil qui empêche la désinstallation ou réinstalle une application supprimée nécessite davantage qu’une nouvelle tentative de suppression ordinaire. Déconnectez-le des comptes et réseaux sensibles, puis sollicitez une assistance qualifiée en réponse aux incidents.

Les organisations devraient révoquer les sessions actives, renouveler les identifiants exposés et examiner l’activité financière depuis un appareil de confiance distinct. Une réinitialisation d’usine peut devenir nécessaire, mais les intervenants devraient préserver les preuves lorsqu’une enquête est importante.

Le malware Android RatHat mérite l’attention car il combine une navigation adaptable avec un contrôle durable de l’appareil. La question décisive est de savoir si les défenseurs peuvent contenir chaque composant, et non si son IA peut appuyer sur le bouton suivant.