Analyse du malware Android GodFather

L'analyse de malware m'a toujours fasciné. C'est un exercice qui démontre non seulement l'ingéniosité des pirates pour contourner les mécanismes de défense du système d'exploitation et des applications, mais aussi pour tromper l'utilisateur et lui dérober des données critiques.

Pour analyser un malware, il faut une grande tasse de café, un sens aigu de l'analyse et les bons outils de rétro-ingénierie pour déchiffrer les énigmes de l'application.

Cet article analyse le malware GodFather, qui continue d'apparaître sous différentes formes et cible principalement les applications bancaires et de cryptomonnaies.

Lorsque nous exécutons le malware GodFather sur l'appareil, il mène des actions malveillantes, comme transférer de l'argent et collecter des informations sur l'appareil : numéro de téléphone, liste des applications installées et état de la batterie. En outre, en exploitant les autorisations accordées sur l'appareil infecté, le malware peut intercepter les SMS, manipuler l'écran de l'appareil via VNC, rediriger les appels téléphoniques et ouvrir des URL à l'insu de l'utilisateur.

L'analyse s'appuiera principalement sur la plateforme Ostorlab, car elle nous permet de :

• Récupérer le code source et l'assembleur de l'APK.
• Convertir le Manifest et les ressources en un format texte lisible.
• Récupérer l'assembleur du code natif (fichiers .so de l'application).
• Obtenir l'arbre d'appels des fonctions, avec un étiquetage des fonctions selon leurs caractéristiques et leur risque.
• Intercepter le trafic sortant de l'application.

Vous pouvez accéder aux résultats et à l'environnement d'analyse du scan via ce lien.

Premières constatations :

Lorsque nous avons scanné l'application dans la plateforme, la première chose remarquée est l'icône de l'application, identique à celle des paramètres Android :

Dans la section de résumé, nous voyons que l'application demande 22 autorisations, dont 8 autorisations dangereuses :

• android.permission.RECORD_AUDIO
• android.permission.SEND_SMS
• android.permission.READ_CONTACTS
• android.permission.READ_SMS
• android.permission.READ_PHONE_STATE
• android.permission.RECEIVE_SMS
• android.permission.WRITE_EXTERNAL_STORAGE
• android.permission.CALL_PHONE
• android.permission.DISABLE_KEYGUARD

L'application exporte deux éléments (un service et un broadcast receiver) pour interagir avec les SMS.

Un rapide coup d'œil aux résultats montre que l'application vérifie si elle est exécutée sur un appareil rooté. Elle est en mode débogage et n'implémente aucun paramètre de configuration réseau.

Par ailleurs, le scanner signale deux résultats de sévérité moyenne liés à des problèmes cryptographiques :

• Utilisation d'une clé codée en dur :
• Utilisation d'un vecteur d'initialisation (IV) non aléatoire

La trace de taint montre que le chiffrement sert à chiffrer les données lors de l'envoi des SMS, les journaux de frappe et les journaux de l'appareil.

Utilisation de l'environnement d'analyse :

Grâce à l'environnement d'analyse d'Ostorlab, nous naviguons facilement dans l'application pour comprendre son comportement. Le premier fichier à examiner est l'AndroidManifest, où nous cherchons l'activité principale de l'application :

Le nom de l'activité principale est com.rduzmauwns.jieliysagr.aJtzcrQbcpuSYfz.

Nous utilisons donc la section statique pour analyser son code source :

Dans la méthode OnCreate, une série de vérifications précède le démarrage du comportement malveillant.

• La première vérification concerne le code pays/région de l'appareil. Le malware ne s'exécute pas si l'appareil provient de Russie ou du Tadjikistan.

• La seconde vérification concerne le contexte d'exécution. Le malware ne s'exécute pas s'il n'est pas lancé sur un véritable appareil.

J'aime toujours voir comment l'application vérifie qu'il s'agit d'un véritable appareil, car il existe de nombreux scripts et moyens de contourner ces vérifications.

Nous utilisons l'onglet call stack et recherchons isEmulator pour voir les dernières vérifications effectuées :

Dans ce cas, nous vérifions les paramètres intégrés de l'appareil par rapport à des valeurs connues : « generic », « Emulator », « Genymotion », etc.

Une fois démarré, le malware désactive son icône et s'exécute en arrière-plan.

Pour cela, l'application utilise la méthode setComponentEnabledSettings avec les paramètres 2, 1.

À ce stade, l'application malveillante s'exécute en arrière-plan !

Je suis prêt. C'est parti !

Le malware démarre un nouveau service nommé com.rduzmauwns.jieliysagr.vCdmvEHqFNkYwsB.

Le service implémente l'interface java.lang.Runnable et son code sera exécuté dans un thread séparé.

Dans ce thread, nous lançons l'une des méthodes d'espionnage, SendNewUser.

Cette méthode récupère les détails de l'appareil de la victime et les envoie par POST au serveur.

Le malware peut transférer de l'argent en effectuant des appels USSD (Unstructured Supplementary Service Data). Pour ceux qui ne savent pas ce qu'est l'USSD, il s'agit d'un protocole de communication utilisé par les téléphones cellulaires GSM pour communiquer avec les ordinateurs de l'opérateur. Il permet aux utilisateurs d'accéder à divers services, comme consulter le solde de leur compte, recharger du crédit, transférer des fonds et souscrire à divers services, entre autres.

Ce qui est bien (ou pas), c'est que le malware passe l'appel sans utiliser l'interface utilisateur du composeur.

Le malware :

• Utilise la méthode SmsSender() pour envoyer des SMS texte en plusieurs parties,
• Il vole les SMS présents sur l'appareil de la victime.
• Utilise la méthode callForward(), qui transfère les appels entrants de la victime vers un numéro fourni par le serveur.
• La méthode linkopen() donne au malware la capacité d'ouvrir des URL dans le navigateur de l'appareil sans intervention de l'utilisateur
• Il vole les journaux de l'application.
• Il utilise VNC Viewer pour voir et contrôler à distance l'écran d'un appareil infecté

Surface d'attaque :

Les endpoints pour envoyer les données et recevoir les commandes ne sont pas définis directement dans le malware. Il les reçoit depuis un canal Telegram, avec une adresse d'endpoint chiffrée dans la description (celle qui utilise le mode ECB, signalée plus tôt par le scanner).

Le malware dispose de trois endpoints principaux :

• henkormerise.com
• banerrokutepera.com
• heikenmorgan.com

Conclusion

Avec le temps, le risque de menaces bancaires augmente et celles-ci deviennent plus sophistiquées. Le malware GodFather en est une illustration parfaite. Cette version particulière du malware contient des capacités malveillantes qui lui permettent de collecter des données sensibles.

En conclusion, l'analyse de malware est un exercice fascinant qui exige de l'attention aux détails. Le malware GodFather n'est qu'un exemple des menaces en évolution qui pèsent sur les secteurs de la banque et des cryptomonnaies. En comprenant comment ce malware fonctionne et l'ampleur des dégâts qu'il peut causer, nous pouvons mieux nous protéger, ainsi que nos appareils, contre de telles attaques.