RatHat déduit votre code PIN de vos gestes, et survit à sa propre désinstallation

Votre code PIN se déduit de l'endroit où vous posez le doigt

Le logiciel malveillant embarque un fichier qui recense la disposition des pavés numériques de toutes les grandes marques de téléphones. C'est là que tout se joue : il n'a nul besoin de lire ce que vous saisissez, il lui suffit de savoir où votre doigt s'est posé, puis de rapprocher cette coordonnée de la géométrie du clavier affiché. Un appui sur tel pixel d'un pavé Samsung, et le chiffre est identifié. La même méthode, appliquée à la grille de neuf points, restitue un schéma de déverrouillage.

Les chercheurs de Zimperium ont publié cette analyse le 16 septembre 2026, sous le nom de RatHat. Pour parvenir à lire ces coordonnées brutes, le programme doit d'abord sortir du bac à sable applicatif d'Android, et la façon dont il s'y prend mérite qu'on s'y arrête : elle n'exploite aucune faille.

Le déroulé, étape par étape

L'équipe zLabs attribue RatHat à des acteurs qui semblent opérer depuis la Chine, l'indice principal étant que les requêtes adressées par le programme à un modèle d'IA sont rédigées en mandarin. La diffusion, elle, n'a rien d'original : campagnes de smishing (hameçonnage par SMS), publicités malveillantes et forums tiers renvoient la victime vers de faux portails de téléchargement, où elle installe de sa propre main un APK (le format de paquet d'installation d'Android) récupéré en dehors du Google Play Store. Zimperium ne communique ni nombre de victimes ni montant de préjudice. Les cibles relevées sont les applications bancaires et de cryptomonnaies dans le monde entier, ainsi que WeChat et Alipay.

Tout commence par une autorisation unique, celle du service d'accessibilité, obtenue au moyen d'une fenêtre localisée qui invoque selon les pays des restrictions réseau ou une contrepartie financière. À partir de cet instant, le téléphone se pilote lui-même. Des appuis synthétiques parcourent les réglages, frappent sept fois le numéro de build pour déverrouiller les options de développeur, activent le débogage sans fil, puis relèvent à l'écran le code d'appairage à six chiffres et le port qu'Android vient d'afficher. Le téléphone s'appaire alors avec son propre démon ADB (Android Debug Bridge, l'outil qui permet d'ordinaire à un ordinateur relié par câble de prendre la main sur un mobile). RatHat se retrouve ainsi promu au compte système « shell », hors du bac à sable, sans qu'aucune machine externe n'intervienne. Il y dépose deux programmes écrits en Go et maquillés en bibliothèques système : le premier exécute des commandes privilégiées, le second est un proxy inverse du commerce qui maintient un tunnel permanent vers l'opérateur à travers n'importe quel pare-feu. Surtout, ce compte shell peut lire /dev/input, le flux brut des coordonnées tactiles produit par le noyau, auquel les applications ordinaires n'accèdent jamais. Ce flux ne contient aucun texte, seulement un X, un Y et un horodatage.

• Cette lecture géométrique contourne trois protections distinctes d'Android. L'indicateur FLAG_SECURE interdit les captures d'écran et la lecture par l'accessibilité, mais ne touche pas au pilote d'entrée. Un clavier personnalisé ne transmet jamais le texte au système, or les doigts, eux, touchent toujours la dalle. L'écran de verrouillage masque les chiffres du code, ce qui ne change rien aux coordonnées.
• Un autre composant sérialise en XML l'arbre d'accessibilité, la carte structurée de ce qui est affiché à l'écran, et l'envoie à un assistant d'IA générative grand public pour obtenir les coordonnées du centre d'un bouton désigné, le texte réel d'un élément, ou une instruction de navigation du type SCROLL_DOWN. Zimperium n'a pas nommé l'assistant en question.
• Désinstaller l'application ne la supprime pas. L'agent privilégié vit en dehors du cycle de vie de l'application, constate sa disparition et la réinstalle avec l'ensemble des permissions déjà accordées et l'accessibilité réactivée, sans la moindre fenêtre que l'utilisateur pourrait refuser.

Ce que cela change

Aucun bilan chiffré n'a été publié et Zimperium se garde d'en avancer un. Ce qui est établi tient au périmètre des identifiants collectés : accès bancaires saisis dans de fausses surcouches HTML, codes à usage unique interceptés dans les SMS et les notifications, codes de déverrouillage reconstitués par géométrie. Mis bout à bout, ces éléments suffisent à franchir les deux facteurs d'une connexion bancaire mobile classique. Pour une entreprise, la difficulté se loge dans une étape à laquelle personne ne pense, la remédiation. Demandez à votre support ce que prévoit la procédure lorsqu'un collaborateur signale un téléphone personnel compromis : elle indique presque toujours de désinstaller l'application et de lancer une analyse. Face à cette famille, la désinstallation déclenche précisément la réinstallation, et l'appareil doit être considéré comme entièrement compromis, avec rotation de tous les identifiants qui y ont été saisis. Si vos équipes utilisent le même terminal pour l'application bancaire et pour l'authentificateur, la question devient immédiate.

En arrière-plan, c'est une frontière qui cède. Le modèle de sécurité d'Android a longtemps supposé qu'un accès shell réclamait un câble et un ordinateur, autrement dit un attaquant ayant physiquement le téléphone entre les mains. Le débogage sans fil en a fait quelque chose qu'une application peut s'octroyer seule, moyennant une autorisation et la patience de parcourir un menu. Quant à la couche d'IA, elle occupe la place la plus discrète du dispositif, et la plus instructive. Le modèle n'écrit pas le code malveillant, il sert d'yeux à un opérateur qui ne regarde pas son écran. Chacune des requêtes qu'il reçoit paraît anodine prise isolément, car demander où se situe le bouton de confirmation dans un fragment de XML est une question parfaitement banale. D'où la difficulté, pour un fournisseur, de la refuser.

Les bons réflexes

1. Faites terminer votre procédure de compromission mobile par une réinitialisation d'usine, et non par une désinstallation. L'agent de persistance survit à l'application qui l'a introduit, si bien que tout ce qui reste en deçà de l'effacement complet laisse un shell entre les mains de l'opérateur.
2. Vérifiez que votre solution de gestion de flotte voit l'activation des options de développeur et du débogage sans fil, et qu'elle remonte une alerte. Un utilisateur qui les active volontairement demeure assez rare pour justifier une vérification, et ici c'est le téléphone qui s'en charge seul : l'un des rares moments observables de toute la chaîne.
3. Expliquez à vos équipes que la décision se joue à la demande d'accessibilité, non à l'installation. Toutes les capacités décrites plus haut découlent de cette seule autorisation, et le prétexte avancé est localisé et crédible, loin des messages grossiers d'autrefois.

À retenir

Le détail à garder en tête reste ce fichier de dispositions de claviers. Quelqu'un a pris le temps de cartographier l'emplacement des chiffres sur le pavé de chaque grande marque, pour qu'un flux de coordonnées dépourvu de sens devienne un code d'accès. Il ne s'agit pas d'une faille exploitée avec brio, mais d'un travail patient mené contre une surface que personne ne défendait, faute d'imaginer qu'une application puisse se tenir à l'extérieur du bac à sable et regarder à l'intérieur. Posez la question lors de votre prochaine revue sous cet angle : que voit d'autre ce compte shell sur un appareil où vos collaborateurs consultent aussi leurs comptes bancaires, et sauriez-vous dire si quelque chose s'y trouve déjà ?