Une nouvelle menace a été mise en évidence dans l’écosystème des véhicules connectés : un malware Android voiture conçu pour s’introduire dans la mémoire logicielle des unités multimédias (head units) équipées d’Android. Contrairement à des campagnes classiques visant des applications isolées, l’attaque s’appuie sur des fonctions de mise à jour intégrées du firmware, ce qui facilite la propagation et la persistance.
Selon Kaspersky, la découverte remonte à juin 2026. Les chercheurs indiquent que la finalité est clairement orientée vers l’ad fraud (fraude publicitaire) et la mise en place d’un botnet proxy exploitable à distance. L’analyse décrit un enchaînement en plusieurs étapes, orchestré pour livrer ensuite un module malveillant fonctionnant en arrière-plan.
Des unités multimédias automobiles ciblées via des mises à jour
Une unité multimédia automobile agit comme un centre de commande pour les fonctions liées à l’infodivertissement, avec parfois une influence partielle sur certains éléments du véhicule. Ces appareils peuvent être installés en usine ou ajoutés sur des modèles plus anciens via des mises à niveau du marché secondaire.
Comme les head units Android gagnent en popularité, elles deviennent aussi une cible logique pour les acteurs malveillants. La raison tient notamment à leur capacité à accéder à Internet, notamment via un emplacement pour carte SIM et, plus largement, à la présence de mécanismes permettant l’installation d’applications et de mises à jour.
D’après Dmitry Kalinin, c’est la première affaire documentée présentant une chaîne d’infection spécifique à ce type de dispositif. Cette particularité augmente la portée de la menace : au lieu d’exploiter un simple défaut applicatif, l’attaque vise directement le canal de mise à jour du système.
Pourquoi l’abus d’un canal légitime est si efficace
Les chercheurs expliquent que les méthodes de livraison de logiciels malveillants deviennent de plus en plus variées : certaines s’appuient sur des backdoors préinstallées, d’autres sur des applications de télévision IPTV compromises. Dans ce cas précis, la campagne s’appuie sur un mode de distribution plus sophistiqué : l’exploitation de la mise à jour logicielle légitime d’une application système.
Le point de départ identifié est une application système appelée TWCore (package com.tw.core). Son rôle est de collecter des données analytiques et d’assurer la mise à jour de l’unité multimédia sous forme de fichiers APK. Pour fonctionner, elle s’appuie sur un courtier de messages MQTT hébergé sur un sous-domaine nommé cardoor[.]cn.
Concrètement, l’APK est récupéré puis déposé dans un répertoire externe, avant installation. La campagne malveillante détourne ce comportement : au lieu de délivrer une mise à jour attendue, elle peut charger des composants non documentés et déclencher l’exécution du reste de l’enchaînement.
Un premier lanceur : JarService et des variantes guidées par le numéro
Les acteurs derrière la campagne auraient armé ce canal de mise à jour afin de livrer un logiciel malveillant inédit. Le mécanisme mentionné inclut un lanceur baptisé JarService, dont la mission est d’initier le chargement d’une étape suivante tout en cherchant à réduire la visibilité de l’activité malveillante.
Le lanceur démarre ensuite un enchaînement qui comprend notamment l’envoi d’informations d’infection à un serveur contrôlé par l’attaquant via une requête HTTP POST. Le serveur répond ensuite par un lien permettant de télécharger le contenu de l’étape suivante.
Un détail notable ressort de l’analyse : le nom du fichier de charge utile inclut une référence à un numéro de version (par exemple dex3.68). Kaspersky indique que cette approche permet d’obtenir plusieurs variantes : en tentant d’autres numéros de version, il est possible de récupérer des itérations associées à différentes valeurs, dont une série remontant à 3.57.
Un module qui se comporte comme une application standard
Le dernier maillon de la chaîne déploie la présence du malware sous la forme d’une application utilisateur « normale ». Toutefois, l’analyse précise que cette application ne présente pas d’interface et opère discrètement en arrière-plan.
Par défaut, le composant configure des communications périodiques avec une adresse de commande et de contrôle (C2). L’envoi se fait toutes les 90 minutes, accompagné d’informations sur le terminal compromis et de sa version de configuration.
Le comportement du serveur C2 varie selon l’état de la configuration. Si une mise à jour de configuration est requise, le serveur retourne de nouvelles informations, incluant des adresses C2 supplémentaires et des chemins HTTP à utiliser. En revanche, si la configuration n’a pas besoin d’être actualisée, le serveur renvoie des identifiants de commande sous forme de valeurs entières, que les attaquants appellent productId.
Le malware associe ensuite ces identifiants à des descriptions de tâches. Il stocke ces données sous forme d’objet JSON sérialisé à l’aide de l’API SharedPreferences.
Neuf commandes pour piloter l’affichage et la fraude publicitaire
Le module malveillant supporte neuf commandes visant à déclencher des actions à distance. L’objectif est notamment de favoriser l’affichage d’annonces non désirées, d’exécuter de la fraude publicitaire et d’ouvrir la voie à des modules supplémentaires.
En parallèle, les attaquants peuvent récupérer des informations détaillées sur l’appareil, comme la résolution d’affichage, le modèle, le nom d’identifiant du réseau Wi‑Fi connecté et l’adresse MAC.
La liste des commandes décrites inclut notamment :
- return : renvoyer une valeur depuis SharedPreferences.
- copy : définir le contenu du presse-papiers.
- http : effectuer une requête POST/GET vers une ressource spécifiée.
- web : ouvrir un lien via WebView et exécuter du JavaScript.
- loadlib : non entièrement implémenté.
- loadlib2 : télécharger et exécuter du code depuis une URL.
- loadlib3 : non entièrement implémenté.
- deeplink : ouvrir une URL dans le navigateur.
- traceroute : vérifier la disponibilité de ressources via un ping ICMP.
Parmi ces capacités, l’analyse souligne un usage particulier des commandes loadlib2 et http pour télécharger zhima, un module de type reverse proxy documenté précédemment par l’équipe Nokia Deepfield Emergency Response Team. Le texte source indique aussi que zhima peut être livré de manière sélective via des applications IPTV installées sur de petites box Android peu coûteuses.
Attribution : MoYu Group et contexte BADBOX
Les activités auraient été attribuées avec un niveau de confiance élevé au MoYu Group. Cette attribution s’appuie sur des travaux menés par l’équipe HUMAN Satori Threat Intelligence and Research, qui avait déjà mis en cause ce groupe l’année précédente dans le cadre d’un dispositif plus vaste associé à la fraude publicitaire et à un système de proxies résidentiels, baptisé BADBOX.
En juillet 2025, Google aurait déposé une action en justice visant 25 personnes ou entités non nommées en Chine, accusées d’opérer le botnet BADBOX et l’infrastructure associée.
Dans le même temps, les chercheurs estiment que malgré les efforts de la communauté et des autorités pour interrompre l’infrastructure du botnet, des acteurs liés poursuivent encore des activités malveillantes, continuant d’infecter des appareils à l’échelle mondiale.
Un avertissement pour la sécurité des plateformes automobiles
Cette affaire est présentée comme un signal d’alarme : pour la première fois, un logiciel malveillant ciblant les unités multimédias automobiles disposerait d’une chaîne d’infection explicitement conçue pour ce type d’appareil. En exploitant un mécanisme de mise à jour légitime, l’attaque transforme un élément de maintenance en vecteur de compromission.
Kalinin souligne que les plateformes automobiles modernes nécessitent des protections plus robustes contre les logiciels malveillants. Le fait que des composants puissent se déployer à partir d’applications système, puis orchestrer des actions à distance, montre que les mécanismes de sécurité doivent couvrir tout le cycle de mise à jour et d’exécution des services.
Ce que cela implique pour les utilisateurs et les industriels
Même si l’article se concentre sur la technique et l’attribution, l’impact est concret. Pour les propriétaires de véhicules équipés de telles unités, la capacité à recevoir des mises à jour devient un levier essentiel : encore faut-il que ces mises à jour soient sécurisées et vérifiées.
Du côté des fabricants et des intégrateurs, la leçon principale est claire : il faut durcir les canaux qui distribuent des fichiers APK via des fonctions natives, et réduire les possibilités pour un acteur malveillant de détourner un flux de mise à jour. La surveillance des comportements réseau, la validation des sources et la protection des composants système doivent faire partie des priorités.
Au final, cette découverte illustre une réalité : les véhicules connectés ne sont plus seulement des objets mécaniques, mais aussi des systèmes logiciels, et donc des cibles. Le malware Android voiture décrit ici rappelle que la sécurité doit être pensée dès la conception des plateformes.
Source: https://thehackernews.com/2026/08/android-car-malware-spreads-through.html
