Comment le cheval de Troie Android Gustuff siphonne (fiat et crypto) vos comptes

Récemment, Group-IB a signalé une activité du cheval de Troie Android Gustuff. Il opère exclusivement sur les marchés internationaux, ciblant les clients des 100 plus grandes banques étrangères, les utilisateurs de 32 portefeuilles de cryptomonnaies, ainsi que de grandes plateformes e-commerce. Quant au développeur de Gustuff, il s'agit d'un cybercriminel russophone surnommé Bestoffer. Il y a peu, il faisait l'éloge de son cheval de Troie comme d'un « produit sérieux pour les personnes ayant des connaissances et de l'expérience ».

L'analyste de malwares chez Group-IB Ivan Pisariev explique en détail dans son étude comment fonctionne Gustuff et quels sont ses dangers.

Qui Gustuff cible

Gustuff appartient à une nouvelle génération de logiciels malveillants dotés de fonctions entièrement automatisées. Selon le développeur, le cheval de Troie est une version améliorée du logiciel malveillant AndyBot, qui attaque les téléphones sous Android depuis novembre 2017 et vole de l'argent via des formulaires Web de phishing, se déguisant en applications mobiles des banques internationales et des systèmes de paiement connus. Bestoffer a indiqué que le prix de location du « Gustuff Bot » était de 800 $ par mois.

L'analyse de l'échantillon de Gustuff a montré que le cheval de Troie cible potentiellement les clients utilisant des applications bancaires des plus grandes banques, telles que Bank of America, Bank of Scotland, J.P. Morgan, Wells Fargo, Capital One, TD Bank, PNC Bank, ainsi que des portefeuilles de cryptomonnaies comme Bitcoin Wallet, BitPay, Cryptopay, Coinbase, etc.

Initialement conçu comme un cheval de Troie bancaire classique, la version actuelle de Gustuff a considérablement élargi la liste des cibles potentielles. En plus des applications bancaires Android, des entreprises fintech et des services de cryptomonnaies, Gustuff s'attaque aux utilisateurs d'applications de marketplaces, de boutiques en ligne, de systèmes de paiement et de messageries. En particulier, PayPal, Western Union, eBay, Walmart, Skype, WhatsApp, Gett Taxi, Revolut et d'autres.

Point d'entrée : ciblage d'une infection massive

Gustuff se caractérise par un vecteur d'infection « classique » pour les smartphones Android via des SMS contenant des liens vers des APK. Lorsqu'un appareil Android est infecté par un cheval de Troie, Gustuff peut se propager davantage dans le carnet de contacts du téléphone infecté ou dans la base de données du serveur sous les ordres du serveur. Les fonctionnalités de Gustuff sont conçues pour une infection massive et une maximisation des profits de ses opérateurs – il y a une fonction unique « d'auto-injection » dans des applications bancaires mobiles légitimes et des portefeuilles de cryptomonnaies, ce qui permet d'accélérer et d'élargir le vol d'argent.

L'étude du cheval de Troie a montré que la fonction d'auto-injection est mise en œuvre grâce au Service d'accessibilité – un service pour les personnes handicapées. Gustuff n'est pas le premier cheval de Troie à contourner avec succès la protection contre l'interaction avec les éléments des fenêtres d'autres applications à l'aide de ce service Android. Cependant, l'utilisation du Service d'accessibilité en combinaison avec l'auto-injection reste encore un phénomène relativement rare.

Après son téléchargement sur le téléphone de la victime, Gustuff, en utilisant le Service d'accessibilité, obtient la possibilité d'interagir avec les éléments des fenêtres d'autres applications (bancaires, de cryptomonnaies, ainsi que des applications de commerce en ligne, de messagerie, etc.), exécutant les actions nécessaires pour les malfaiteurs. Par exemple, sous les ordres du serveur, le cheval de Troie peut cliquer sur des boutons et modifier les valeurs des champs de texte dans les applications bancaires. L'utilisation du mécanisme du Service d'accessibilité permet au cheval de Troie de contourner les mécanismes de protection utilisés par les banques contre les chevaux de Troie mobiles de génération précédente, ainsi que les modifications des politiques de sécurité mises en place par Google dans les nouvelles versions du système d'exploitation Android. Ainsi, Gustuff « sait » désactiver la protection Google Protect : selon l'auteur, cette fonction s'active dans 70 % des cas.

Gustuff peut également afficher de fausses notifications PUSH avec des icônes d'applications mobiles légitimes. L'utilisateur clique sur la notification PUSH et voit une fenêtre de phishing chargée depuis le serveur, où il entre lui-même les informations demandées de sa carte bancaire ou de son portefeuille cryptographique. Dans un autre scénario d'utilisation de Gustuff, l'application, au nom de laquelle la notification PUSH a été affichée, s'ouvre. Dans ce cas, le malware peut remplir les champs du formulaire bancaire pour une transaction frauduleuse à la demande du serveur via le service d'accessibilité.

Les fonctionnalités de Gustuff incluent également l'envoi d'informations sur l'appareil infecté au serveur, la possibilité de lire/envoi de SMS, l'envoi de requêtes USSD, le lancement d'un proxy SOCKS5, le suivi de liens, l'envoi de fichiers (y compris des scans de documents, des captures d'écran, des photos) au serveur, et la réinitialisation de l'appareil aux paramètres d'usine.

Analyse du malware

Avant l'installation de l'application malveillante, le système Android affiche une fenêtre contenant la liste des autorisations demandées par Gustuff :

L'installation de l'application ne se fera qu'après l'accord de l'utilisateur. Après le lancement de l'application, le cheval de Troie affichera une fenêtre à l'utilisateur :

Après quoi il supprimera son icône.

Gustuff est empaqueté, selon l'auteur, avec un empaqueteur de FTT. Après son lancement, l'application communique périodiquement avec le serveur CnC pour recevoir des commandes. Dans plusieurs fichiers que nous avons examinés, une adresse IP a été utilisée comme serveur de contrôle. 88.99.171[.]105 (nous l'appellerons ensuite <%CnC%>).

Après le lancement, le programme commence à envoyer des messages au serveur http:///api/v1/get.php.

En réponse, on s'attend à un JSON au format suivant :

{
    "results" : "OK",
    "command":{
        "id": "",
        "command":"",
        "timestamp":"",
        "params":{
		
        },
    },
}

À chaque demande, l'application envoie des informations sur l'appareil infecté. Le format du message est présenté ci-dessous. Il convient de noter que les champs full, extra, apps et permission sont optionnels et ne seront envoyés que si une commande de demande provient du CnC.

{
 "info":
 {
 "info":
 {
 "cell":,
 "country":,
 "imei":,
 "number":,
 "line1Number":,
 "advertisementId":
 },
 "state":
 {
 "admin":,
 "source":,
 "needPermissions":,
 "accesByName":,
 "accesByService":,
 "safetyNet":,
 "defaultSmsApp":,
 "isDefaultSmsApp":,
 "dateTime":,
 "batteryLevel":
 },
 "socks":
 {
 "id":,
 "enabled":,
 "active":
 },
 "version":
 {
 "versionName":,
 "versionCode":,
 "lastUpdateTime":,
 "tag":,
 "targetSdkVersion":,
 "buildConfigTimestamp":1541309066721
 },
 },
 "full":
 {
 "model":,
 "localeCountry":,
 "localeLang":,
 "accounts":,
 "lockType":
 },
 "extra":
 {
 "serial":,
 "board":,
 "brand":,
 "user":,
 "device":,
 "display":,
 "id":,
 "manufacturer":,
 "model":,
 "product":,
 "tags":,
 "type":,
 "imei":,
 "imsi":,
 "line1number":,
 "iccid":,
 "mcc":,
 "mnc":,
 "cellid":,
 "lac":,
 "androidid":,
 "ssid":
 },
 "apps":{},
 "permission":
} 

Stockage des données de configuration

Gustuff stocke des informations essentielles au fonctionnement dans un fichier de préférences. Le nom du fichier, tout comme les noms des paramètres qu'il contient, est le résultat du calcul d'une somme de contrôle MD5 d'une chaîne. 15413090667214.6.1, où <%name%> — nom-valeur d'origine. Interprétation Python de la fonction de génération de nom :

 nameGenerator(input):
    output = md5("15413090667214.6.1" + input) 

Nous désignerons plus tard comme nameGenerator(input).
Ainsi, le nom du premier fichier : nameGenerator("API_SERVER_LIST"), il contient des valeurs avec les noms suivants :

Module de traitement des commandes du serveur.

L'application stocke les adresses des serveurs CnC sous forme de tableau de chaînes codées en Base85 Les adresses CnC – serveurs peuvent être modifiées lors de la réception de la commande appropriée, dans ce cas, les adresses seront stockées dans le fichier de préférences.

En réponse à la demande, le serveur envoie à l'application une commande. Il convient de noter que les commandes et les paramètres sont présentés au format JSON. L'application peut traiter les commandes suivantes :

Format de la commande notification:

{
 "results" : "OK",
 "command":{
 "id": ,
 "command":"notification",
 "timestamp":,
 "params":{
 "openApp":,
 "array":[
 {"title":,
 "desc":,
 "app":}
 ]
 },
 },
}

La notification créée par le fichier examiné ressemble identiquement aux notifications créées par l'application indiquée dans le champ app. Si la valeur du champ openApp — True, lorsque la notification est ouverte, l'application spécifiée dans le champ sera lancée, app. Si la valeur du champ openApp — False, alors :

• une fenêtre d'hameçonnage s'ouvre, dont le contenu est téléchargé depuis le répertoire /hgps/
• une fenêtre d'hameçonnage s'ouvre, dont le contenu est téléchargé depuis le serveur ?id=&app=
• une fenêtre d'hameçonnage s'ouvre, déguisée en Google Play Card, permettant de saisir les données de la carte.

Le résultat de l'exécution de toute commande est envoyé par l'application à set_state.php sous la forme d'un objet JSON du format suivant :

{
    "command":
    {
        "command":,
        "id":,
        "state":
    }
    "id":
}

ActionsService
La liste des commandes que l'application traite comprend action. Lorsque la commande est reçue, le module de traitement des commandes se connecte à ce service pour exécuter la commande étendue. Le service prend un objet JSON comme paramètre. Le service peut exécuter les commandes suivantes :

1. PARAMS_ACTION — lorsque cette commande est reçue, le service obtient d'abord la valeur par clé Type à partir du paramètre JSON, qui peut être le suivant :

• serviceInfo – la sous-commande obtient la valeur par clé à partir du paramètre JSON includeNotImportant. Si le flag est égal à True, l'application définit le flag FLAG_ISOLATED_PROCESS sur le service utilisant Accessibility Service. Ainsi, le service sera exécuté dans un processus distinct.
• root — obtenir et envoyer au serveur des informations sur la fenêtre qui est actuellement au premier plan. L'application obtient les informations à l'aide de la classe AccessibilityNodeInfo.
• admin — demander des droits administratifs.
• delay — suspendre le fonctionnement d'ActionsService pendant le nombre de millisecondes spécifié dans le paramètre clé «data».
• windows — envoyer la liste des fenêtres visibles à l'utilisateur.
• install — installer l'application sur l'appareil infecté. Le nom du paquet — l'archive se trouve dans la clé «fileName». L'archive elle-même se trouve dans le répertoire Downloads.
• global – la sous-commande est destinée à effectuer une transition depuis la fenêtre actuelle :
  • vers le menu Quick Settings
  • retour
  • accueil
  • vers les notifications
  • vers la fenêtre des applications récemment ouvertes

• launch — lancer l'application. Le nom de l'application est transmis comme paramètre dans la clé data.
• sounds — changer le mode audio en silence.
• unlock — active la luminosité maximale de l'écran et du clavier. L'application effectue cette action à l'aide de WakeLock, en spécifiant la chaîne [Application lable]:INFO comme tag.
• permissionOverlay — fonction non implémentée (réponse à l'exécution de la commande — {«message»:«Not support»} ou {«message»:«low sdk»})
• gesture — fonction non implémentée (réponse à l'exécution de la commande — {«message»:«Not support»} ou {«message»:«Low API»})
• permissions — cette commande est nécessaire pour demander des permissions pour l'application. Cependant, la fonction de demande n'est pas implémentée, donc la commande n'a pas de sens. La liste des permissions demandées arrive sous forme de tableau JSON avec la clé «permissions». Liste standard :
  • android.permission.READ_PHONE_STATE
  • android.permission.READ_CONTACTS
  • android.permission.CALL_PHONE
  • android.permission.RECEIVE_SMS
  • android.permission.SEND_SMS
  • android.permission.READ_SMS
  • android.permission.READ_EXTERNAL_STORAGE
  • android.permission.WRITE_EXTERNAL_STORAGE

• open — afficher une fenêtre de phishing. Selon les paramètres reçus du serveur, l'application peut présenter les fenêtres de phishing suivantes :
  • Afficher la fenêtre de phishing, dont le contenu est défini dans le fichier dans le répertoire /hgps/. Le résultat de l'interaction de l'utilisateur avec la fenêtre sera envoyé à l'adresse /records.php
  • Afficher la fenêtre de phishing, dont le contenu est préalablement chargé depuis l'adresse ?id=&app=. Le résultat de l'interaction de l'utilisateur avec la fenêtre sera envoyé à l'adresse /records.php
  • Afficher la fenêtre de phishing déguisée en carte Google Play.

• interactive — la commande est destinée à interagir avec les éléments des fenêtres d'autres applications via AcessibilityService. Un service spécial a été mis en place pour l'interaction dans le programme. L'application explorée peut interagir avec les fenêtres :
  • Actives au moment présent. Dans ce cas, le paramètre contient l'id ou le texte (le nom) de l'objet avec lequel il faut interagir.
  • Visibles à l'utilisateur au moment de l'exécution de la commande. L'application sélectionne les fenêtres par id.

  Après avoir obtenu les objets AccessibilityNodeInfo pour les éléments d'intérêt de la fenêtre, l'application peut effectuer des actions en fonction des paramètres :

  • focus — mettre le focus sur l'objet.
  • click — cliquer sur l'objet.
  • actionId — exécuter l'action par ID.
  • setText — modifier le texte de l'objet. La modification du texte peut être effectuée de deux manières : en exécutant l'action ACTION_SET_TEXT si la version d'Android de l'appareil infecté est inférieure ou égale à LOLLIPOP), ou en plaçant la chaîne dans le presse-papiers et en la collant dans l'objet (pour les versions plus récentes). Cette commande peut être utilisée pour modifier des données dans une application bancaire.

2. PARAMS_ACTIONS — c'est la même chose que PARAMS_ACTION, sauf que cela arrive sous la forme d'un tableau JSON de commandes.

Il semble que beaucoup d'entre vous soient curieux de savoir à quoi ressemble la fonction d'interaction avec les éléments d'une fenêtre d'autre application. C'est ainsi que cette fonctionnalité a été mise en œuvre dans Gustuff :

boolean interactiveAction(List aiList, JSONObject action, JsonObject res) {
    int count = action.optInt("repeat", 1);
    Iterator aiListIterator = ((Iterable)aiList).iterator();
    int count = 0;
    while(aiListIterator.hasNext()) {
        Object ani = aiListIterator.next();
        if(1 <= count) {
            int index;
            for(index = 1; true; ++index) {
                if(action.has("focus")) {
                    if(((AccessibilityNodeInfo)ani).performAction(1)) {
                        ++count;
                    }
                }
                else if(action.has("click")) {
                    if(((AccessibilityNodeInfo)ani).performAction(16)) {
                        ++count;
                    }
                }
                else if(action.has("actionId")) {
                    if(((AccessibilityNodeInfo)ani).performAction(action.optInt("actionId"))) {
                        ++count;
                    }
                }
                else if(action.has("setText")) {
                    customHeader ch = CustomAccessibilityService.a;
                    Context context = this.getApplicationContext();
                    String text = action.optString("setText");
                    if(performSetTextAction(ch, context, ((AccessibilityNodeInfo)ani), text)) {
                        ++count;
                    }
                }
                if(index == count) {
                    break;
                }
            }
        }
        ((AccessibilityNodeInfo)ani).recycle();
    }
    res.addPropertyNumber("res", Integer.valueOf(count));
}

Fonction de remplacement de texte :

boolean performSetTextAction(Context context, AccessibilityNodeInfo ani, String text) {
    boolean result;
    if(Build$VERSION.SDK_INT >= 21) {
        Bundle b = new Bundle();
        b.putCharSequence("ACTION_ARGUMENT_SET_TEXT_CHARSEQUENCE", ((CharSequence)text));
        result = ani.performAction(0x200000, b);  // ACTION_SET_TEXT
    }
    else {
        Object clipboard = context.getSystemService("clipboard");
        if(clipboard != null) {
        ((ClipboardManager)clipboard).setPrimaryClip(ClipData.newPlainText("autofill_pm", ((CharSequence)text)));
        result = ani.performAction(0x8000);  // ACTION_PASTE
        }
        else {
            result = false;
        }
    }
    return result;
}

Ainsi, avec la configuration correcte du serveur de contrôle, Gustuff peut remplir les champs de texte dans une application bancaire et appuyer sur les boutons nécessaires pour effectuer des transactions. Le cheval de Troie n'a même pas besoin de passer par la procédure d'authentification dans l'application — il suffit d'envoyer un ordre pour afficher une notification PUSH, suivie de l'ouverture de l'application bancaire installée précédemment. L'utilisateur s'authentifiera lui-même, après quoi Gustuff pourra procéder à un remplissage automatique.

Module de traitement des messages SMS

L'application installe un gestionnaire d'événements pour la réception de messages SMS sur l'appareil infecté. L'application étudiée peut recevoir des commandes de l'opérateur qui arrivent dans le corps des messages SMS. Les commandes arrivent au format :

7!5=

L'application recherche dans tous les messages SMS entrants la chaîne 7!5=, lors de la détection de la chaîne – décode la chaîne en Base64 avec un décalage de 4 et exécute la commande. Les commandes sont similaires aux commandes avec CnC. Le résultat de l'exécution est envoyé au même numéro d'où la commande a été reçue. Format de la réponse :

7*5=

Optionnellement, l'application peut envoyer tous les messages reçus au numéro Root. Pour cela, le numéro Root doit être spécifié dans le fichier de préférences et le drapeau de redirection des messages doit être activé. Le SMS est envoyé au numéro de l'attaquant au format :

—

L'application peut également optionnellement envoyer des messages au CnC. Le SMS est envoyé au serveur au format JSON :

{
    "id":,
    "sms":
    {
        "text":,
        "number":,
        "date":
    }
}

Si le drapeau est activé nameGenerator(«DEFAULT_APP_SMS») – l'application arrête le traitement du SMS et vide la liste des messages entrants.

Module Proxy

L'application examinée comporte un module Backconnect Proxy (ci-après dénommé module Proxy), qui a une classe distincte contenant des champs statiques avec la configuration. Les données de configuration sont stockées en clair dans l'échantillon :

Toutes les actions effectuées par le module Proxy sont journalisées dans des fichiers. Pour cela, l'application crée un répertoire nommé «logs» dans le stockage externe (champ ProxyConfigClass.logsDir dans la classe de configuration), où sont stockés les fichiers de log. La journalisation se fait dans des fichiers nommés :

1. main.txt – ce fichier enregistre le fonctionnement de la classe nommée CommandServer. Plus tard, la journalisation de la chaîne str dans ce fichier sera désignée comme mainLog(str).
2. session-.txt — ce fichier enregistre les données de log liées à une session de proxy spécifique. Plus tard, la journalisation de la chaîne str dans ce fichier sera désignée comme sessionLog(str).
3. server.txt – ce fichier enregistre toutes les données écrites dans les fichiers décrits ci-dessus.

Format des données de log :

[Thread[], id[]]: log-string

Les exceptions survenant lors du fonctionnement du module Proxy sont également journalisées dans un fichier. Pour cela, l'application forme un objet JSON au format :

{
 "uncaughtException":
 "thread":
 "message":
 "trace": //Stack trace info
 [
 {
 "ClassName":
 "FileName":
 "LineNumber":
 "MethodName":
 },
 {
 "ClassName":
 "FileName":
 "LineNumber":
 "MethodName":
 }
 ]
}

Ensuite, il le convertit en une représentation sous forme de chaîne et le consigne.

Le module Proxy est lancé après réception de la commande appropriée. Lors de la réception de la commande de démarrage du module Proxy, l'application démarre le service appelé MainService, qui est responsable de la gestion des opérations du module Proxy - son démarrage et son arrêt.

Étapes de démarrage du service :

1. Démarre un minuteur qui se déclenche toutes les minutes et vérifie l'activité du module Proxy. Si le module n'est pas actif, il le lance.
Également, lors de l'activation de l'événement android.net.conn.CONNECTIVITY_CHANGE , le module Proxy est lancé.

2. L'application crée un wake-lock avec le paramètre PARTIAL_WAKE_LOCK et l'attrape. Ainsi, cela empêche le CPU de l'appareil de passer en mode veille.

3. Lance la classe de traitement des commandes du module Proxy, après avoir préalablement consigné la chaîne mainLog(«start server») et

Server::start() host[], commandPort[], proxyPort[]

où proxy_cnc, command_port et proxy_port sont des paramètres obtenus à partir de la configuration du serveur Proxy.

La classe de traitement des commandes s'appelle CommandConnection. Dès son lancement, elle exécute les actions suivantes :

4. Se connecte à ProxyConfigClass.host: ProxyConfigClass.commandPort et envoie les données de l'appareil infecté au format JSON :

{
    "id":,
    "imei":,
    "imsi":,
    "model":,
    "manufacturer":,
    "androidVersion":,
    "country":,
    "partnerId":,
    "packageName":,
    "networkType":,
    "hasGsmSupport":,
    "simReady":,
    "simCountry":,
    "networkOperator":,
    "simOperator":,
    "version":
}

Où :

• id – identifiant, essaie de récupérer la valeur du champ «id» du fichier Shared Preference nommé «x». Si cette valeur ne peut pas être obtenue, en génère une nouvelle. Ainsi, le module Proxy a son propre identifiant, généré de la même manière que le Bot ID.
• imei — IMEI de l'appareil. Si une erreur se produit lors de la récupération de la valeur, un message d'erreur sera inscrit à la place de ce champ.
• imsi — Identité d'abonné mobile internationale de l'appareil. En cas d'erreur lors de l'obtention de la valeur, un message d'erreur sera enregistré à la place de ce champ.
• model — Le nom visible de l'utilisateur final pour le produit final.
• manufacturer — Le fabricant du produit/matériel (Build.MANUFACTURER).
• androidVersion — une chaîne au format « (), »
• country — la localisation actuelle de l'appareil.
• partnerId – une chaîne vide.
• packageName – nom du package.
• networkType — le type de connexion réseau actuelle (exemple : «WIFI», «MOBILE»). En cas d'erreur, renvoie null.
• hasGsmSupport – true – si le téléphone prend en charge le GSM, sinon false.
• simReady – état de la carte SIM.
• simCountry — code ISO du pays (basé sur le fournisseur de carte SIM).
• networkOperator — nom de l'opérateur. En cas d'erreur lors de l'obtention de la valeur, un message d'erreur sera enregistré à la place de ce champ.
• simOperator — Le nom du fournisseur de services (SPN). En cas d'erreur lors de l'obtention de la valeur, un message d'erreur sera enregistré à la place de ce champ.
• version — ce champ est stocké dans la classe de configuration, pour les versions étudiées du bot, il était égal à «1.6».

5. Passe en mode d'attente des commandes du serveur. Les commandes du serveur arrivent au format :

• 0 offset – commande
• 1 offset – sessionId
• 2 offset – longueur
• 4 offset — données

Lors de la réception de la commande, l'application journalise :
mainLog("Header { sessionId], type[], length[] }")

Les commandes suivantes peuvent provenir du serveur :

Le message PONG est constitué de 4 octets et se présente comme suit : 0x04000000.

Lors de la réception de la commande connectionId (pour la création d'une nouvelle connexion) CommandConnection crée une instance de la classe ProxyConnection.

• Deux classes participent au proxy : ProxyConnection et end. Lors de la création de la classe ProxyConnection une connexion est établie à l'adresse ProxyConfigClass.host: ProxyConfigClass.proxyPort et un objet JSON est transmis :

 {
    "id":
}

En réponse, le serveur envoie un message SOCKS5, qui contient l'adresse du serveur distant avec lequel il faut établir une connexion. L'interaction avec ce serveur se fait via la classe end. De manière schématique, l'établissement de la connexion peut être représenté comme suit :

Interactions réseau

Pour prévenir l'analyse du trafic par des sniffers réseau, l'interaction entre le serveur CnC et l'application peut être protégée par le protocole SSL. Toutes les données transmises, tant du serveur que vers le serveur, sont présentées au format JSON. Pendant son fonctionnement, l'application effectue les requêtes suivantes :

• http:///api/v1/set_state.php — résultat de l'exécution de la commande.
• http:///api/v1/get.php — réception de la commande.
• http:///api/v1/load_sms.php — extraction des SMS du dispositif infecté.
• http:///api/v1/load_ab.php — extraction de la liste de contacts du dispositif infecté.
• http:///api/v1/aevents.php – la requête est effectuée lors de la mise à jour des paramètres dans le fichier de préférences.
• http:///api/v1/set_card.php — extraction des données obtenues via la fenêtre de phishing se faisant passer pour Google Play Market.
• http:///api/v1/logs.php – extraction des journaux de données.
• http:///api/v1/records.php – extraction des données obtenues via des fenêtres de phishing.
• http:///api/v1/set_error.php – notification d'une erreur survenue.

Recommandations

Pour protéger leurs clients contre la menace des chevaux de Troie mobiles, les entreprises doivent utiliser des solutions globales qui permettent de surveiller et de prévenir les activités malveillantes sans installer de logiciel supplémentaire sur les appareils des utilisateurs.

Pour cela, les méthodes de détection basées sur des signatures des chevaux de Troie mobiles doivent être renforcées par des technologies d'analyse comportementale tant du client que de l'application elle-même. La protection doit également inclure une fonction d'identification des appareils utilisant la technologie d'empreinte digitale, ce qui permettra de comprendre quand un compte est utilisé sur un dispositif atypique et est déjà tombé entre les mains d'un fraudeur.

Un point crucial est la disponibilité d'une analyse cross-canal, permettant aux entreprises de contrôler les risques apparaissant non seulement du côté d'Internet, mais aussi du canal mobile, par exemple, dans les applications de banque mobile, pour les transactions en cryptomonnaie, et dans d'autres domaines où des transactions financières peuvent avoir lieu.

Règles de sécurité pour les utilisateurs :

• ne pas installer d'applications pour dispositifs Android à partir de sources autres que Google Play, et faire particulièrement attention aux permissions demandées par l'application ;
• installer régulièrement les mises à jour du système Android.
• faire attention aux extensions des fichiers téléchargés;
• ne pas visiter des ressources suspectes;
• ne pas cliquer sur les liens reçus par SMS.

En participant Semena Rogatchev, spécialiste junior en recherche de logiciels malveillants au Laboratoire de criminalistique informatique de Group-IB.

Source : habr.com