Le malware Midnight Mimosa est intégré au micrologiciel de téléphones Android et touche plus de 150 pays

Un téléphone compromis avant son premier démarrage

Des milliers d’appareils Android dans plus de 150 pays ont été touchés par Midnight Mimosa, une campagne malveillante qui intègre des logiciels malveillants au micrologiciel des téléphones avant même que leurs acheteurs ne les allument. Bitdefender a identifié au moins 32 applications déguisées déployées dans le cadre de l’opération, ainsi que 13 applications du Google Play contenant le même code de fraude publicitaire et communiquant avec son infrastructure de contrôle.

Les résultats, publiés le 8 octobre 2026 et mis à jour le 9 octobre, décrivent une opération observée sur environ deux ans. Parmi les appareils concernés figurent des téléphones bon marché utilisant des plateformes MediaTek, des contrefaçons reprenant les noms de modèles Apple et Samsung, ainsi que des appareils s’identifiant comme Doogee S200 X et Cubot KINGKONG X.

Le principal constat du rapport technique de Bitdefender est que l’infection ne dépend pas du téléchargement d’une application suspecte par l’acheteur. Un composant système malveillant est livré avec l’appareil, dispose de puissantes autorisations du système d’exploitation et peut installer d’autres logiciels sans demander l’accord de son propriétaire.

Cette caractéristique rend la menace particulièrement difficile à éliminer. Supprimer une application météo indésirable ou un verrouilleur d’applications peut faire disparaître une partie visible de l’opération, tout en laissant intact le composant qui l’a installée. Les chercheurs ont constaté que des charges malveillantes apparaissaient et disparaissaient à plusieurs reprises sur les mêmes appareils.

L’enquête a également ses limites. Elle n’a pas permis d’identifier qui a inséré le logiciel malveillant dans le micrologiciel. Les chercheurs ont découvert du code capable de faire transiter du trafic par des téléphones infectés, mais leur appareil de test n’a reçu aucune instruction de relais. Les opérateurs disposaient d’autorisations sensibles, mais les chercheurs n’ont pas observé leur utilisation pendant l’analyse.

Le composant caché qui contrôle les installations

L’enquête a débuté lorsque la technologie de détection comportementale de Bitdefender a signalé com.android.system.lite. Son nom et son libellé générique « System » évoquaient un composant Android ordinaire, mais son comportement était différent : il installait et supprimait silencieusement des applications sans lien entre elles et activait à plusieurs reprises des accès sensibles.

Le composant n’avait pas d’icône visible dans le lanceur d’applications. Signé pour la plateforme Android, il s’exécutait avec les droits de l’utilisateur système et était configuré pour rester actif. Ses autorisations lui permettaient d’installer et de supprimer des paquets, d’accorder des autorisations à d’autres applications et de modifier des paramètres sécurisés. Ces pouvoirs dépassent largement ceux normalement accordés à une application téléchargée par le propriétaire d’un téléphone.

Les chercheurs ont ensuite découvert le même noyau malveillant sous d’autres noms, notamment com.android.sys.prot, com.android.sys.gmsprot et com.android.sys.bcprot. Un autre paquet signalé par des propriétaires de téléphones, com.android.non.szcz, a été identifié comme appartenant à la même famille. Les différentes versions utilisaient des noms différents et, dans certains cas, des certificats de signature différents.

C’est un élément important pour la détection et le nettoyage : un seul nom de paquet ne définit pas l’ensemble de la menace. Un téléphone dépourvu de com.android.system.lite peut tout de même contenir une autre version du même mécanisme. Le comportement commun et le code sous-jacent sont de meilleurs indicateurs que le nom affiché dans la liste des applications Android.

Comment le code à distance modifie le comportement du téléphone

Une grande partie de la logique malveillante était dissimulée dans une bibliothèque native appelée libeasy.so, plutôt que dans le code ordinaire de l’application système. Au démarrage, cette bibliothèque utilisait le chiffrement RC4 pour dissimuler puis récupérer un framework intégré d’environ 142 Ko.

Ce framework récupérait sa configuration auprès d’un serveur de commande et de contrôle, c’est-à-dire un service distant par lequel les opérateurs dirigent les appareils infectés. Il pouvait télécharger et charger des fichiers DEX et JAR, des formats servant à empaqueter du code exécutable Android et Java. Les opérateurs pouvaient ainsi modifier le comportement de l’appareil après sa vente.

Les chercheurs ont identifié trois familles de plug-ins. L’une, associée à com.wz.sdk.DxFactory, gérait les impressions et les clics publicitaires frauduleux. Les autres, associées à com.earnsdk.lib.DxFactory et com.gogo.third.lib.DxFactory, permettaient d’installer et de supprimer silencieusement d’autres applications ; la dernière intégrait également des fonctionnalités WebView.

Le composant système faisait donc office de contrôleur persistant, et non de simple logiciel publicitaire figé. Supprimer la charge malveillante du jour ne l’empêcherait pas d’en récupérer une autre le lendemain. Le chargement de code à distance et l’octroi d’autorisations privilégiées élargissaient également le champ des activités possibles au-delà de celles observées pendant l’enquête.

Des applications d’apparence ordinaire transforment de faux clics en revenus

L’objectif apparent de l’opération était principalement lucratif. Les chercheurs ont découvert au moins 32 applications malveillantes distinctes déguisées en outils météo, verrouilleurs d’applications, gestionnaires de fichiers, outils d’icônes, outils de reconnaissance de texte et éditeurs audio. Certaines proposaient des fonctionnalités, tandis que d’autres n’accomplissaient pas réellement la tâche suggérée par leur nom.

Par exemple, com.mobile.applock.wt se présentait comme un outil de verrouillage d’applications, mais ne disposait ni de l’interface ni du code nécessaires à cette fonction. L’application était masquée à l’utilisateur et servait de vecteur à d’autres logiciels malveillants, c’est-à-dire qu’elle les installait. Parmi les autres charges malveillantes identifiées figuraient com.dmstudio.weather, com.dl.guard.lock et picturetranslate.extractor.text.lite.

Les applications de couverture intégraient des kits de développement logiciel publicitaires légitimes, ou SDK. Ces outils permettent à une application d’afficher des publicités et de percevoir des revenus liés à leur diffusion. Leur présence fournissait au trafic frauduleux un identifiant d’application et de publicité auxquels les revenus pouvaient être attribués.

Les chercheurs en sécurité de Bitdefender Adrian Mihai Gozob et Alex Baciu ont décrit ainsi la répartition des rôles entre le composant système persistant et les applications de couverture :

L’application système elle-même n’enregistre pas les impressions et les clics frauduleux.

Le contrôleur fournissait les instructions et le calendrier des interactions artificielles, tandis que les identifiants publicitaires appartenaient aux applications de couverture. Les applications communiquaient par l’intermédiaire de services partagés et transmettaient le même identifiant d’appareil à une infrastructure comprenant un service de contrôle déguisé en API météo. Des utilitaires apparemment sans lien étaient ainsi réunis au sein d’une même opération publicitaire coordonnée.

L’analyse technique a révélé des clics automatiques sans intervention de l’utilisateur, des cibles publicitaires aléatoires, des limites quotidiennes et des intervalles entre les interactions fabriquées. Elle a également mis au jour le signalement automatique des conversions après un délai de 60 secondes. Ces mécanismes pouvaient cadencer l’activité frauduleuse au lieu de générer un flux ininterrompu d’événements identiques.

Google Play est à la fois une cible de contournement et un canal de diffusion

Avant de déployer une charge malveillante, le logiciel désactivait temporairement com.android.vending, l’application Google Play Store. Il la réactivait ensuite et prévoyait un mécanisme de restauration lorsque l’utilisateur était présent. Bitdefender estime qu’il s’agissait probablement d’une tentative d’échapper à la détection de Play Protect, mais cela ne prouve pas que toutes les installations ont échappé à l’analyse.

Certaines variantes modifiaient également les enregistrements d’installation d’Android, de sorte que les logiciels installés par le malware semblaient provenir de Google Play. Ce déguisement pouvait rendre une application inconnue moins suspecte lorsque son propriétaire vérifiait son origine.

Les mécanismes publicitaires utilisaient notamment des écrans ouverts sans intervention de l’utilisateur et des fenêtres superposées à d’autres applications. L’un des écrans publicitaires était marqué comme sécurisé, ce qui l’empêchait d’apparaître dans les captures d’écran ou les enregistrements vidéo. Le rapport décrit à la fois une activité publicitaire cachée et des affichages intrusifs : l’opération ne doit donc pas être considérée comme exclusivement invisible.

Google Play constituait également un canal de diffusion distinct. Les chercheurs ont identifié 13 applications publiées contenant le même code de fraude publicitaire et communiquant avec l’infrastructure de Midnight Mimosa. Elles utilisaient 13 certificats de signature distincts et au moins deux comptes de développeur, nommés fivedev et CPS Developer.

Ces applications du magasin ne disposaient pas des privilèges élevés des composants système préinstallés. La différence est importante : en télécharger une ne lui conférait pas automatiquement les mêmes pouvoirs d’installation silencieuse qu’à un composant de micrologiciel compromis. Elles pouvaient néanmoins afficher des publicités en dehors de leur propre interface, y compris lorsque le propriétaire n’utilisait pas activement le téléphone.

Au moment de la publication des articles consacrés à ces découvertes, certaines applications associées étaient toujours disponibles, et Google n’avait pas répondu immédiatement à une demande de commentaire. Aucun calendrier de suppression confirmé n’est établi ici. Les découvertes concernant le Play Store montrent que le risque ne se limitait pas aux appareils contrefaits ou aux téléphones déjà compromis à leur fabrication.

L’inscription au réseau proxy a été observée, pas le transfert actif de trafic

Une autre charge malveillante, com.mobile.applock.en, contenait un composant proxy TCP. Un proxy fait transiter le trafic internet pour le compte d’un tiers. Lorsque la connexion appartient au propriétaire ordinaire d’un téléphone, ce trafic peut sembler provenir de son adresse internet plutôt que de celle de la partie qui le dirige réellement.

Le composant inscrivait les appareils auprès d’un serveur distant et pouvait recevoir des instructions pour se connecter à des destinations précises et y transférer du trafic. Ces capacités pourraient servir à créer un réseau d’appareils contrôlés à distance, ou botnet, et générer des revenus supplémentaires grâce à la vente d’accès à ces connexions.

Bitdefender a confirmé que l’infrastructure proxy avait accepté l’inscription de son appareil de test. Celui-ci n’a toutefois reçu aucune cible de relais pendant les essais. L’enquête a donc démontré la capacité d’inscription et de transfert, mais pas un transfert effectivement réalisé lors de ce test.

La même prudence s’impose concernant les attaques par déni de service distribué, qui submergent une cible en lui envoyant du trafic depuis de nombreux appareils. Les chercheurs ont présenté la participation à un botnet et ce type d’attaque comme des utilisations possibles. Les résultats ne démontrent pas que des téléphones infectés par Midnight Mimosa ont mené une attaque précise, ni n’identifient des clients ayant acheté l’accès à leurs connexions.

Quels appareils et quels pays figurent dans les résultats ?

Le Mexique, la France et l’Italie arrivaient en tête de la répartition géographique, suivis des États-Unis, de l’Allemagne, du Brésil et de l’Espagne. Les chiffres couvraient des milliers d’appareils distincts sur environ deux ans, mais aucun total précis pour la campagne n’a été communiqué. Il s’agit de détections, et non d’un recensement de tous les téléphones infectés vendus.

Plus de 11 % des appareils compromis s’identifiaient comme des KINGKONG X, un nom de modèle associé à Cubot, tandis que plus de 4 % s’identifiaient comme des S200 X, associés à Doogee. Ces deux groupes de modèles représentaient ensemble plus de 15 % des détections. Le Cubot Kingkong 9 a également été mentionné dans les articles consacrés à l’enquête.

Les 15 principales marques de téléphones représentaient 35,8 % des appareils infectés. Environ 64 % étaient regroupés dans la catégorie « autres », un chiffre arrondi communiqué dans les résultats. Cette répartition suggère que le marché touché était fragmenté, plutôt que limité à une seule marque reconnaissable.

Parmi les noms de modèles contrefaits figuraient i17 Pro Max, i16_Pro_Max, 17_Pro_Max, S25 Ultra, S24 Ultra et Note 18 Ultra. Le nom d’une tablette iPadAirPro est également apparu. Ces identifiants provenaient d’appareils Android bon marché et ne doivent pas être considérés comme la preuve que des produits Apple ou Samsung authentiques étaient infectés.

Les identifiants de modèle ne constituent pas une preuve parfaite, car un logiciel peut falsifier l’identité d’un appareil. La détection sur certains modèles ne prouve pas non plus que toutes les unités vendues sous ces noms étaient infectées. Les résultats techniques concernent les appareils et les versions de micrologiciel touchés, et non l’ensemble des produits MediaTek ou tous les téléphones des marques citées.

Les certificats du micrologiciel ne permettent pas d’établir les responsabilités

Certains micrologiciels touchés étaient signés à l’aide de certificats portant le nom Shenzhen Zediel. Ces éléments sont importants, car ils relient le composant malveillant à un micrologiciel auquel l’appareil faisait confiance. À eux seuls, ils ne permettent pas d’établir qui a inséré le logiciel malveillant ni si le titulaire du certificat savait qu’il était présent.

Gozob et Baciu ont explicitement précisé les limites de ce que leur enquête permettait d’établir en matière d’attribution :

Nous pouvons seulement confirmer que des certificats portant le nom Shenzhen Zediel ont servi à signer le micrologiciel d’appareils touchés.

Les articles ont décrit de différentes manières l’activité liée à ce nom, notamment en la présentant comme un fabricant d’appareils Android ou comme une entreprise apparemment liée à un développeur de cartes mères. Ces descriptions ne permettent pas de trancher la question des responsabilités. Bitdefender a également trouvé des téléphones touchés dont le micrologiciel ne portait pas de certificats au nom de Zediel : cette signature ne constitue donc ni une explication complète ni un indicateur universel.

Le logiciel malveillant pourrait avoir été introduit par un fabricant de conception originale, un intégrateur de micrologiciels, un partenaire logistique ou un autre acteur de la distribution. Le rapport ne désigne aucun responsable. Le fait confirmé est que le logiciel malveillant était présent dans le micrologiciel avant la vente des téléphones concernés.

Les témoignages de propriétaires montrent pourquoi supprimer les applications ne suffit pas

Des propriétaires de téléphones Cubot et Doogee ont raconté que des applications suspectes se réinstallaient après leur suppression. Le propriétaire d’un Doogee Fire 3 Max a indiqué qu’une mise à jour officielle du micrologiciel avait introduit l’infection, que le retour à une version antérieure l’avait supprimée et que la réinstallation de la mise à jour l’avait fait réapparaître. Il s’agit de témoignages d’utilisateurs, et non d’un historique indépendamment confirmé pour chaque version de micrologiciel concernée.

Certains propriétaires ont déclaré que des mises à jour ultérieures du fabricant avaient résolu leurs problèmes. Les fabricants n’avaient pas expliqué publiquement comment le code malveillant s’était retrouvé dans le micrologiciel concerné. Pris ensemble, ces témoignages montrent qu’il faut tenir compte des versions du micrologiciel dans l’enquête et la réparation, au lieu de supposer que la suppression d’une application téléchargée règle le problème.

Les principales étapes établies par l’enquête et les articles publiés ensuite sont les suivantes :

• Sur environ deux ans, Bitdefender a observé des milliers d’appareils touchés dans plus de 150 pays.
• Le 8 octobre 2026, Bitdefender a publié son enquête sur Midnight Mimosa.
• Le 9 octobre 2026, le rapport technique a été mis à jour.
• Au moment de la publication des articles, le 12 octobre, la présence d’applications associées sur Google Play et la question des responsabilités concernant le micrologiciel touché restaient non résolues.

Selon Bitdefender, le nettoyage nécessite d’intervenir sur le micrologiciel ou de désactiver le composant malveillant à l’aide d’Android Debug Bridge, généralement appelé ADB. ADB est un outil qui permet à un ordinateur de communiquer avec un appareil Android à des fins de débogage et d’administration. Désactiver un composant ne revient pas à remplacer un micrologiciel compromis par une version vérifiée et saine.

Aucune commande de nettoyage universelle ni liste confirmée de micrologiciels sains n’a été établie. Les propriétaires devraient demander au vendeur ou au fabricant une solution vérifiée ou un remplacement, plutôt que de supposer qu’une mise à jour est sûre simplement parce qu’elle est présentée comme officielle. Tant que la situation de l’appareil n’est pas clarifiée, mieux vaut éviter de l’utiliser pour les opérations bancaires, l’authentification à des comptes sensibles ou le stockage d’informations importantes.

Le risque concerne aussi les accès sensibles dont les chercheurs n’ont pas observé l’utilisation. Les autorisations d’accessibilité et d’accès aux notifications ont été accordées puis révoquées à plusieurs reprises, et l’accès aux SMS était présent. Si du code fourni à distance les activait, ces capacités pourraient exposer le contenu de l’écran, les notifications ou les messages de vérification. Il s’agit d’un risque démontré, et non d’une preuve que Midnight Mimosa a dérobé ces informations pendant l’analyse.

Points clés

• Midnight Mimosa a été découvert intégré au micrologiciel Android avant que les appareils concernés ne parviennent aux acheteurs.
• Bitdefender a observé des milliers d’appareils touchés dans plus de 150 pays sur environ deux ans.
• L’opération a déployé au moins 32 applications malveillantes déguisées ; 13 applications du Google Play partageaient son code de fraude publicitaire et son infrastructure.
• Les privilèges système permettaient les installations silencieuses, l’octroi d’autorisations et le chargement de code à distance.
• L’inscription au réseau proxy a été confirmée, mais aucun transfert actif de trafic n’a été observé sur l’appareil de test.
• Les certificats de signature du micrologiciel n’ont pas permis d’établir qui avait inséré le logiciel malveillant ni si leurs titulaires étaient impliqués.
• Supprimer uniquement les applications de couverture ne règle pas le problème du composant persistant. Le nettoyage nécessite d’intervenir sur le micrologiciel ou de désactiver ce composant.