Rechercher

Rétro-ingénierie de l’application malveillante Anubis

Anubis est un malware Android. Nous pouvons le trouver dans diverses applications au sein du Google Play Store. Cette application malveillante est connue pour extorquer les identifiants bancaires et permettre d’espionner l’utilisateur du smartphone.

Introduction : architecture d’Anubis

Dans un premier temps, le malware se manifeste dans l’application via un downloader qui ne contient pas de code malveillant. C’est ce qui explique pourquoi l’application n’est pas détectée par Google comme un malware. L’application se met à jour d’elle-même et se transforme en malware Anubis.

Afin de montrer le fonctionnement d’Anubis, nous avons récupéré plusieurs applications sur le Play Store.

Etape #1 : reverse engineering

En utilisant les outils internes de reverse engineering d’Orange Cyberdefense, nous avons pu décompiler l’application et étudier son code java.

Pendant la première étape, l’application semble tout à fait légitime, mais contient des permissions étranges comme « Request_install_packages ».

Cette permission va permettre à l’application de télécharger sa mise à jour en arrière-plan à partir d’un site inconnu.

Puis, l’application se met à jour d’elle-même avec le package reçu sans qu’une permission supplémentaire ne soit demandée à l’utilisateur.

Une fois l’application mise à jour, elle lance une nouvelle « Activité » (étape 2).

Pour récupérer l’APK mis à jour, nous le lançons dans l’émulateur de Google. Grâce à ADB (Android Debug Bridge), nous pouvons le télécharger depuis le smartphone.

Etape #2 : analyse dynamique de la mise à jour

Une fois décompilée, nous constatons que l’APK contient plus de 50 classes et des centaines de fonctions. Le code étant très offusqué, beaucoup de classes/variables ont le même nom et rendent l’analyse statique du code très longue et pénible.

Nous commençons donc par regarder le manifeste Android pour savoir quelle classe est lancée au démarrage de l’application.

Nous nous apercevons plus tard que cette classe n’existe pas dès le lancement de l’application. Nous supposons donc que l’application crée un second fichier .dex (Dalvik Virtual Machine, code compilé d’un APK) contenant les classes et fonctions manquantes.

Un fichier .dex fait référence à toutes les classes ou méthodes utilisées dans une application, ce qui signifie que nous ne pouvons pas faire une analyse statique d’un APK sans lui.

Nous cherchons donc où et quand le 2nd ficher .dex est créé. L’émulateur fournit les journaux des applications lancées. L’application malveillante pourrait utiliser ce système de journalisation lors de son développement par les créateurs du malware.

Nous pouvons ainsi voir qu’un fichier est créé dans le répertoire « app_files ».

Nous essayons de le récupérer via ADB mais le répertoire est absent sur le téléphone. L’application doit supprimer ce répertoire ainsi que ses fichiers.

Nous essayons donc de voir quelle fonction est appelée pour effacer ce répertoire afin d’y placer un hook  pour pouvoir empêcher la suppression de celui-ci.

Nous lançons strace (outil permettant de suivre les appels système) dans un shell ADB sur le processus zygote (processus père de toutes les autres applications sur Android) afin de pouvoir récupérer la trace de l’exécution de notre application.

Dans un deuxième terminal, nous installons et lançons l’application.

Nous trouvons dans la trace d’exécution de notre application la fonction « unlink » qui est appelée pour effacer notre fichier.

Le but est maintenant de « hooker » cette fonction afin d’empêcher le malware de supprimer ce fichier. Si plusieurs méthodes sont possibles, nous utilisons l’outil Frida (https://github.com/frida).

Une fois le hook installé grâce à Frida, nous pouvons télécharger notre deuxième fichier .dex via ADB directement sur le smartphone.

A noter : Si vous faîtes cela sur un émulateur qui exécute une version d’Android plus ancienne que la 25, vous obtiendrez un fichier .odex et .vdex au lieu d’un fichier .dex.

Etape #2 – alternative #1 : analyse statique

Il est possible d’obtenir le deuxième fichier .dex via une analyse statique. Nous pouvons voir qu’un fichier de données chiffrées se trouve dans l’APK. C’est peut-être le fichier .dex que nous recherchons. Pour trouver la fonction cryptographique utilisée nous utilisons la commande grep pour rechercher les caractères « 255 » ou « ^ » dans toutes les classes java. Trois résultats semblent très intéressants et se trouvent tous dans la même classe.

Une fonction contient ^ et 255.

Nous pouvons voir que la fonction effectue un XOR et un modulo 255. Cela ressemble à la fonction de cryptographie RC4 (l’algorithme de génération pseudo-aléatoire pour être exact).

Nous recherchons donc l’algorithme de génération des clés afin de trouver la clé de chiffrement (celle-ci se doit d’être dans le code, le malware s’exécutant sans effectuer de communication via internet).

Dans la même classe, nous trouvons cette fonction.

En cherchant où cette fonction est appelée :

Et voici la clé. Nous pouvons maintenant déchiffrer le fichier data contenu dans l’application pour obtenir le second fichier .dex.

Nous faisons un script python pour reconstruire la clé en binaire depuis le code source :

Nous n’avons plus qu’à décoder avec la fonction rc4.decrypt et nous obtenons notre deuxième fichier .dex.

Etape #2 – alternative #2 : automatisation

Nous avons pu récupérer 7 applications appartenant à la famille Anubis ainsi que 3 appartenant à une autre famille ; elles ont toutes la même architecture. Nous avons donc décidé de faire un script python qui prend en entrée une application et donne en sortie le fichier .dex.

Pour cela nous décompressons le fichier APK et le décompilons (transforme les .class compilés en .java textuels grâce à l’outil jadx) puis nous recherchons la clé.

Nous savons que la clé doit ressembler à ce qui suit :

Nous faisons donc une expression régulière pour « matcher » toutes les clés possibles :

Ensuite, nous appliquons cette clé à tous les fichiers data présents dans l’APK décompressé. Pour reconnaître le fichier .dex celui-ci aura un « header » (‘PK’).

Etape #3 : analyse de la charge utile

L’étape 3 est l’analyse de la charge utile, le malware Anubis. Quand celui-ci est lancé, il ouvre directement le menu « Accessibility » et nous demande d’activer l’accès à « Google Play Protect ». Evidemment, il s’agit là d’un piège et non du véritable Google Play Protect et ce afin qu’un utilisateur puisse être facilement leurré et donne au malware les dernières permissions dont il a besoin. Il pourra alors observer toutes les actions de l’utilisateur du téléphone et lire le contenu de n’importe quelle application.

A ce stade, le code est également offusqué mais il n’y a pas de code inutile, ce qui le rend un peu plus lisible.

C’est la dernière étape du malware : avant de trouver ses fonctionnalités nous allons chercher comment il communique.

Communication avec le C&C

Nous essayons de chercher naïvement dans le code les mots HTTP HTTPS PHP :

Dans un premier temps nous avons pensé que ce Twitter servait de C&C. Mais après une analyse des communications nous nous sommes rendus compte que ce Twitter servait uniquement d’intermédiaire afin de récupérer l’adresse du C&C ou mettre à jour celle-ci.

L’adresse du C&C récupérée du compte Twitter est encodée en Base64 avec une fonction personnalisée ; nous devons donc la trouver. Pour cela nous cherchons le mot base64 dans le code. Nous avons donc trouvé cette fonction :

L’adresse du serveur est ensuite stockée dans le dossier « shared preference » du smartphone (ce dossier permet de garder une variable en mémoire même quand l’utilisateur ferme l’application).

Bien sûr, les variables sont stockées chiffrées, nous recherchons donc la fonction qui les chiffrent.

Après avoir réimplémenté le code et la fonction de décodage :

Lors du premier échange avec le C&C, le malware envoie la liste des applications installées sur le téléphone pour savoir si des applications intéressantes sont installées sur l’appareil (des applications bancaires par exemple) ou pour préparer un plan d’ingénierie sociale plus complexe.

Persistance d’Anubis

Le malware peut se lancer dès le démarrage du téléphone grâce aux autorisations que nous lui avons données (android.permission RECEIVE_BOOT_COMPLETED) sans aucune action de l’utilisateur.

De plus, nous ne pouvons pas supprimer l’application. Lorsque nous essayons, le message suivant apparaît : « Les applications système ne peuvent pas être supprimées ».

Nous ne pouvons plus activer l’authentique Google Play Protect.

Ou réinitialiser le système.

Tout cela est rendu possible parce que le logiciel malveillant est capable de suivre les activités de l’utilisateur. S’il détecte que nous tentons l’une des trois actions ci-dessus, il lancera une nouvelle activité qui fera apparaître un pop-up sur l’écran d’accueil avant que l’utilisateur ne puisse faire quoi que ce soit.

Dans la version SDK > 23, Android éliminera les applications qui tournent trop longtemps en arrière-plan pour optimiser la batterie. Les logiciels malveillants contournent ce problème en ignorant cette optimisation pour l’application.

Injection dans d’autres applications (Overlay)

Le malware cherche dans les applications installées sur le smartphone si des applications spécifiques sont installées parmi une centaine d’applications (principalement des applications bancaires ou des porte-monnaie de crypto-monnaie)

Si une application spécifique est présente sur le téléphone, le malware attendra que l’utilisateur la lance.

Une fois l’application lancée, le malware va faire apparaître une fenêtre qui correspond à celle-ci sans que l’utilisateur s’en rende compte et va ainsi piéger celui-ci pour qu’il donne ses informations de connexion.

La fenêtre correspondante est envoyée par le serveur malveillant et l’application peut obtenir toutes les applications en cours d’exécution sur le smartphone grâce aux autorisations PACKAGE_USAGE_STATS que nous lui avons données.

Ici, à gauche, le véritable menu d’identification de l’application Ebay, à droite le faux.

Keylogger

Le keylogger suit trois événements différents : Clicked, Focused et Text dans toutes les applications présentes sur le téléphone.

  • TYPE_VIEW_CLICKED (eventType=1)
    Cet évènement est déclenché dès que l’utilisateur va cliquer sur un bouton
  • 8 : TYPE_VIEW_FOCUSED (eventType=8)
    Cet évènement est déclenché dès qu’un utilisateur va changer de fenêtre.
  • 16 : TYPE_VIEW_TEXT_CHANGED (eventType=16)
    Cet évènement est déclenché lorsque l’utilisateur va rentrer un texte.

Le keylogger est désactivé par défaut mais peut être activé sur commande.

Chiffrer ou déchiffrer un fichier

Le malware peut trouver un fichier spécifique (ou simplement prendre un répertoire entier) afin de l’encoder avec l’algorithme RC4, l’envoyer au C&C ou simplement savoir si le fichier existe.

Comme nous pouvons le voir, le malware va regarder dans tous les espaces mémoires possibles.

Intercepter un SMS ou un appel téléphonique

Grâce au keylogger, le malware peut déjà lire les sms mais il peut demander à être l’application SMS par défaut.

Le malware peut également effectuer un renvoi d’appels et de sms.

Obtenir l’annuaire téléphonique

Le logiciel malveillant peut obtenir tous les contacts de l’annuaire téléphonique Android avec le champ « CONTENT_URI ».

Envoyer des sms à tous les contacts

Après avoir obtenu l’annuaire téléphonique, le logiciel malveillant peut envoyer un sms à tous les contacts ou à un contact spécifique.

Le texte du message est reçu du C&C.

Afin d’éviter un numéro inhabituel ou un numéro de sécurité, le logiciel malveillant envoie un message texte à tous les numéros qui respectent la condition suivante :

Autres commandes (liste non exhaustive)

Cela conclut l’analyse du malware bancaire Anubis. Nous avons pu identifier les différentes étapes d’infection, automatiser la récupération de la charge finale. L’examen de cette charge nous a permis de contacter le C&C et de récupérer ses différents modes d’actions. Tous ces éléments nous permettront d’informer nos clients sur ces menaces, de les aider à se protéger eux-mêmes tout comme leurs clients.