Malwares Android par superposition et accessibilité : Crocodilus, Anatsa et DroidLock
Le modèle de permissions Android permet aux utilisateurs de déléguer des capacités étroites aux applications. Deux capacités sont particulièrement dangereuses combinées : dessiner au-dessus d'autres applications (SYSTEM_ALERT_WINDOW) et le framework des services d'accessibilité. La première permet des superpositions de phishing pixel-perfect ; la seconde donne un accès programmatique à l'écran et la simulation d'actions utilisateur. En 2025, trois familles — Crocodilus, Anatsa et DroidLock — ont montré la maturité de cet abus. Aucune ne repose sur une exploitation du noyau. Toutes reposent sur l'ingénierie sociale et sur des permissions accordées volontairement.
1. Le modèle de permissions et ses angles morts
Android distingue permissions normales, permissions dangereuses à l'exécution et permissions spéciales. La superposition et l'accessibilité sont spéciales car elles ne relèvent pas d'un accès ordinaire aux données ; elles modifient l'interaction de l'utilisateur avec l'appareil. Google impose un parcours de réglages explicite, et Android 13+ ajoute les « Restricted settings » pour les applications sideloadées, qui bloquent l'activation de l'accessibilité jusqu'à autorisation explicite.
La protection est réelle mais incomplète :
- Les utilisateurs sont entraînés à appuyer sur « Autoriser ». Un faux écran « activez l'accessibilité pour continuer » ressemble à une étape d'intégration légitime.
- L'accessibilité a été conçue pour les technologies d'assistance. Elle peut lire le texte, cliquer, faire défiler et revenir en arrière — exactement les primitives nécessaires pour piloter une application bancaire.
- Les superpositions peuvent être transparentes. La victime voit la vraie application en dessous pendant que le malware capture les touches ou dessine une demande d'identifiants au-dessus.
- Les droppers diffusent la charge utile plus tard. L'application installée est bénigne lors de la revue et télécharge le composant malveillant ultérieurement, contournant l'analyse du store.
2. Crocodilus : superposition et contrôle à distance
Crocodilus a été documenté par ThreatFabric en mars 2025. Il ciblait les utilisateurs Android en Espagne et en Turquie avant de s'étendre, et sa caractéristique principale était la combinaison de superpositions avec un contrôle à distance via l'accessibilité. Le malware affichait de faux écrans de connexion au-dessus d'applications bancaires et de portefeuilles de cryptomonnaies, puis utilisait l'accessibilité pour lire les notifications, intercepter les codes à usage unique et effectuer des taps à la place de la victime.
La chaîne d'infection commençait généralement par un APK sideloadé livré via une page de phishing ou un message. Une fois installé, l'application demandait l'accès à l'accessibilité et, dans certaines variantes, tentait de désactiver des fonctions de sécurité ou de masquer son icône. Crocodilus est remarquable car il n'avait pas besoin d'une exploitation sophistiquée : la victime accordait les deux permissions qui rendaient l'attaque possible.
La leçon est architecturale. Si une application peut lire l'écran et simuler des touches, elle peut piloter toute autre application que l'utilisateur peut piloter. C'est une capacité d'accès à distance, pas une fonction de confort.
3. Anatsa : le dropper qui vit dans le store
Anatsa, aussi suivi sous le nom TeaBot, est un cheval de Troie bancaire Android distribué via des applications droppers sur Google Play déguisées en lecteurs PDF, scanners de documents et utilitaires. L'application publiée ne contient pas de charge utile bancaire évidente. Après installation, elle télécharge un APK de second étage depuis un serveur distant et demande à l'utilisateur de « mettre à jour » ou « activer » l'application. Le second étage demande l'accessibilité, puis superpose les applications bancaires.
Le schéma compte pour les défenseurs car il invalide le contrôle simpliste « est-ce dans le Play Store ? ». La revue du store est une évaluation ponctuelle ; un dropper peut changer de comportement après approbation. Les campagnes Anatsa ont ciblé des centaines d'applications financières en Europe et aux États-Unis, en adaptant les superpositions à chaque flux de connexion.
Pourquoi l'accessibilité est la clé
<!-- Un service malveillant déclare la capacité d'accessibilité -->
<service
android:name=".AccessibilityHandler"
android:exported="true"
android:permission="android.permission.BIND_ACCESSIBILITY_SERVICE">
<intent-filter>
<action android:name="android.accessibilityservice.AccessibilityService" />
</intent-filter>
<meta-data
android:name="android.accessibilityservice"
android:resource="@xml/accessibility_config" />
</service>
Le fichier de configuration détermine ce que le service peut observer. Une application malveillante demande les types d'événements et capacités les plus larges, dont canRetrieveWindowContent, canPerformGestures et l'observation des notifications. Une fois activé, il reçoit des événements de chaque application ouverte.
4. DroidLock : quand la charge utile est un ransomware
En décembre 2025, Zimperium a publié des recherches sur DroidLock, une famille de ransomware Android ciblant les utilisateurs hispanophones. DroidLock était distribué via des applications sideloadées et abusait de l'accessibilité et des droits d'administrateur d'appareil pour verrouiller l'écran, modifier le code PIN et afficher des messages d'extorsion. Contrairement aux chevaux de Troie bancaires qui préfèrent la discrétion, le ransomware veut être remarqué.
La progression technique est familière : installation par ingénierie sociale, demande de permissions élevées, puis abus de ces permissions pour retirer le contrôle à l'utilisateur. L'implication défensive est la même : un appareil qui accorde l'accessibilité et les droits d'administrateur à une application inconnue n'est plus sous le contrôle exclusif de son propriétaire.
5. Détection et chasse sur l'appareil
Les équipes peuvent auditer les appareils gérés avec les indicateurs suivants. Sur un appareil de test, utilisez adb et le gestionnaire de paquets :
# Lister les services déclarant la capacité d'accessibilité
adb shell dumpsys accessibility | sed -n '1,120p'
# Lister les administrateurs d'appareil
adb shell dumpsys device_policy | grep -i -A3 'admin'
# Lister les applications avec permission de superposition
adb shell appops query-op SYSTEM_ALERT_WINDOW allow
# Inspecter les paquets récemment installés et leurs installateurs
adb shell pm list packages -3 -i
Cherchez des applications aux noms anodins (« PDF Reader », « Cleaner », « Wallet Update ») qui demandent l'accessibilité, n'ont aucun rapport avec l'assistance, ou ont été installées par un navigateur ou une messagerie plutôt qu'un store. Vérifiez si l'application masque son icône, demande des droits d'administrateur ou télécharge un APK après installation.
6. Contrôles défensifs
- Restreindre le sideloading. Sur les appareils gérés, désactivez l'installation de sources inconnues et imposez managed Google Play. Sur les appareils personnels, traitez tout APK reçu par messagerie comme hostile jusqu'à preuve du contraire.
- Imposer des listes d'autorisation d'accessibilité. L'EMM peut restreindre les paquets autorisés à lier un service d'accessibilité. Pour les utilisateurs à haut risque, révisez mensuellement les services activés.
- Bloquer la permission de superposition par politique. La plupart des applications de productivité n'ont pas besoin de
SYSTEM_ALERT_WINDOW. Refusez par défaut et exigez une exception. - Protéger les OTP. Ne dépendez pas des codes SMS comme seul second facteur. Utilisez une authentification résistante au phishing comme les passkeys ou des clés matérielles.
- Surveiller le comportement des droppers. Alertez sur les applications qui installent d'autres APK, demandent l'accessibilité peu après le lancement ou affichent un écran demandant d'« activer » un réglage de sécurité.
- Corrigez l'OS. Maintenez les mises à jour Android. Les restricted settings et les avertissements d'accessibilité réduisent la surface sans l'éliminer.
7. Conclusion
Crocodilus, Anatsa et DroidLock sont des charges utiles différentes bâties sur la même fondation : des permissions spéciales accordées par l'utilisateur. Le malware ne casse pas le modèle de sécurité Android ; il persuade l'utilisateur de l'élargir. Les défenseurs doivent traiter l'accessibilité et la superposition comme des capacités à haut risque, les auditer en continu et concevoir une authentification qui reste sûre même lorsque l'écran est lu par une autre application. Le contrôle le plus efficace n'est pas une signature — c'est une politique de permissions qui suppose que l'utilisateur finira par appuyer sur « Autoriser ».