Malware dans les autoradios Android : les mises à jour deviennent un vecteur de fraude publicitaire et de botnet proxy

Une nouvelle chaîne d’infection ciblant les head units DoFun

Les chercheurs de Kaspersky ont identifié en juin 2026 une famille de malwares conçue pour cibler le firmware des head units Android développées par DoFun. Selon l’analyse publiée, il s’agit du premier cas documenté d’une chaîne d’infection spécialement conçue pour les systèmes multimédias automobiles.

L’objectif n’est pas de contrôler directement les fonctions de conduite, mais de transformer l’unité Android en plateforme de fraude publicitaire et d’activités proxy. Une fois l’appareil compromis, les attaquants peuvent installer des modules supplémentaires, afficher des contenus indésirables, exécuter du code à distance et utiliser la connexion du véhicule pour relayer du trafic.

Cette menace concerne un domaine souvent considéré comme relevant uniquement de l’infodivertissement. Les head units sont pourtant des ordinateurs Android dotés d’une connectivité, d’applications, d’un stockage persistant et, dans de nombreux cas, d’un accès à Internet via une carte SIM intégrée.

Le point faible réside dans l’application de mise à jour

Le composant au cœur de l’attaque est TWCore, une application système dont le package est com.tw.core. Ce logiciel remplit des fonctions légitimes : il collecte des données analytiques et met à jour la head unit en téléchargeant des fichiers APK.

Les opérateurs de MoYu ont précisément exploité ce mécanisme pour distribuer un programme malveillant directement sur les unités. La communication avec l’infrastructure de mise à jour s’effectue via MQTT, en utilisant le sous-domaine cardoor[.]cn. Les paquets APK sont enregistrés dans le répertoire :

<TWCore external cache dir>/push/apk/

L’abus a été signalé de manière responsable et le problème permettant de distribuer des logiciels non autorisés a été corrigé. Les versions exactes contenant le correctif ainsi qu’une procédure publique complète permettant de vérifier tous les modèles concernés ne sont toutefois pas connues.

Le risque est accru par le fait que les head units Android peuvent être installées directement par les constructeurs ou ajoutées ultérieurement en tant que systèmes aftermarket. La même surface d’attaque peut donc concerner aussi bien des véhicules neufs que des voitures plus anciennes équipées de composants retrofit.

JarService lance un downloader en plusieurs étapes

Le premier malware identifié dans la chaîne est un dropper appelé JarService. Sa fonction consiste à contourner les contrôles initiaux et à lancer un loader chargé de récupérer le payload suivant.

La séquence observée par les chercheurs se déroule comme suit :

1. le loader collecte des informations sur la head unit compromise ;
2. il envoie ces données à un serveur distant via une requête HTTP POST ;
3. il reçoit un lien vers le composant suivant ;
4. il télécharge le payload depuis l’adresse 144.217.243[.]201/vr34der34/dex3.68.png.

L’extension .png n’indique pas nécessairement qu’il s’agit d’une image. Le fichier sert de conteneur au code à installer. La référence dex3.68 identifie une version du payload : en modifiant le numéro dans l’URL, Kaspersky a récupéré sept variantes, dont certaines remontant à 3.57.

À la fin de la chaîne, le malware est installé comme une application utilisateur ordinaire. Il n’affiche aucune fenêtre ni interface visible et continue de fonctionner en arrière-plan, ce qui réduit les chances que le propriétaire du véhicule remarque l’infection.

Une infrastructure C2 mise à jour à distance

Le composant installé contacte régulièrement l’infrastructure de commande et de contrôle. Par défaut, il envoie toutes les 90 minutes une requête POST vers le endpoint /cpc/api/task.

La communication contient des données sur l’appareil et sur la version de la configuration locale. Si cette configuration est obsolète, le serveur fournit de nouvelles adresses C2 et de nouveaux chemins HTTP. Dans le cas contraire, la réponse contient des identifiants numériques de commandes que les opérateurs appellent productId.

Le trojan associe chaque identifiant aux paramètres nécessaires et conserve ces informations au format JSON sérialisé via SharedPreferences, le mécanisme Android habituellement utilisé pour stocker les préférences des applications.

Cette architecture permet aux opérateurs de modifier rapidement les serveurs, les chemins et les instructions sans devoir réinstaller le composant principal à chaque changement. La compromission ne dépend donc pas d’une infrastructure fixe et facilement bloquable.

Neuf commandes pour la publicité, le téléchargement et le contrôle à distance

Le malware implémente neuf fonctions opérationnelles :

• return, pour lire et renvoyer les valeurs présentes dans SharedPreferences ;
• copy, pour modifier le contenu du presse-papiers ;
• http, pour envoyer des requêtes HTTP GET ou POST ;
• web, pour ouvrir des contenus dans une WebView et exécuter du JavaScript ;
• loadlib, prévu pour charger des bibliothèques, mais pas entièrement implémenté ;
• loadlib2, pour télécharger et exécuter du code depuis une URL ;
• loadlib3, une seconde fonction de chargement inachevée ;
• deeplink, pour ouvrir des adresses dans le navigateur ;
• traceroute, pour vérifier l’accessibilité d’une ressource via un ping ICMP.

Ces capacités suffisent à afficher des publicités sans consentement, à générer du trafic publicitaire frauduleux et à installer des modules supplémentaires. L’exécution de JavaScript dans une WebView étend encore le contrôle exercé sur les contenus chargés.

Le malware collecte également des informations techniques sur l’environnement, notamment la résolution de l’écran, le modèle de la head unit, l’identifiant du réseau Wi-Fi et l’adresse MAC. Ces données peuvent aider les opérateurs à classer les appareils et à diffuser des commandes ciblées.

De la fraude publicitaire au réseau proxy

L’un des aspects les plus importants est l’utilisation des commandes loadlib2 et http pour installer zhima, un module de reverse proxy déjà associé à des campagnes menées via des applications IPTV présentes sur des Android TV box bon marché.

Une head unit compromise peut ainsi devenir un nœud servant à relayer le trafic de tiers. La connexion mobile ou Wi-Fi du véhicule est exploitée comme si elle appartenait à un utilisateur légitime, tandis que l’opérateur conserve le contrôle du flux.

L’infection poursuit donc deux objectifs liés : monétiser l’appareil par la fraude publicitaire et l’intégrer à une infrastructure proxy. Le propriétaire peut constater une consommation inhabituelle de données, des ralentissements ou un trafic réseau inattendu, mais le malware ne présente aucun signe visible et fiable.

MoYu et le contexte de BADBOX

Kaspersky attribue la campagne avec un niveau de confiance élevé à MoYu, un groupe associé au dispositif BADBOX. Les activités du groupe avaient déjà été rendues publiques par l’équipe HUMAN Satori Threat Intelligence and Research.

En juillet 2025, Google a engagé des poursuites contre 25 personnes ou entités non nommées en Chine, les accusant d’exploiter le botnet BADBOX et son infrastructure associée. Le cas des head units montre que l’opération ne se limite pas aux appareils Android bon marché vendus comme TV box.

On ignore si cette campagne spécifique a touché un nombre précis de véhicules ou quels marchés ont été les plus affectés. Aucun identifiant CVE n’a par ailleurs été communiqué pour la vulnérabilité exploitée. Selon les informations disponibles, rien n’indique non plus que la faille figure dans le catalogue KEV de la CISA.

Points à vérifier sur les unités concernées

Le problème affectant le canal de mise à jour a été corrigé, mais les versions exactes contenant le correctif ne sont pas connues. Les gestionnaires de véhicules équipés d’une head unit DoFun devraient donc vérifier l’intégrité du firmware et des applications système, et installer uniquement des mises à jour provenant du constructeur ou d’un revendeur agréé.

Du point de vue de la surveillance, les indicateurs suivants sont utiles :

• trafic vers cardoor[.]cn ;
• connexions à 144.217.243[.]201 ;
• requêtes périodiques vers /cpc/api/task ;
• APK ou fichiers faisant référence à des versions comprises entre dex3.57 et dex3.68 ;
• applications sans interface graphique actives en arrière-plan ;
• utilisation inhabituelle de WebView ou téléchargement de code via loadlib2 ;
• trafic compatible avec un reverse proxy.

La présence de l’un de ces indicateurs ne suffit pas, à elle seule, à prouver une infection. Elle peut toutefois justifier une analyse forensique du firmware et des applications installées. La procédure détaillée de remédiation n’ayant pas été publiée, la réinstallation du logiciel doit être effectuée uniquement à partir d’images officielles et selon les procédures du constructeur.