Un malware préinstallé Android peut compromettre un smartphone avant même sa première utilisation. Intégré au firmware, c’est-à -dire au logiciel système fourni avec l’appareil, il peut disposer de privilèges élevés et résister à une désinstallation classique. Pour une entreprise, le prix d’achat ne suffit donc pas à évaluer un terminal : sa provenance, son suivi logiciel et son contrôle par MDM doivent aussi peser dans la décision.
Comment un malware peut-il être installé avant l’achat du téléphone ?
Un malware préinstallé Android peut être ajouté au firmware pendant la fabrication, la personnalisation ou la distribution du terminal. Le programme malveillant devient alors une application système, parfois signée avec une clé de la plateforme. L’utilisateur reçoit un appareil déjà compromis, sans avoir téléchargé de fichier ni accordé lui-même d’autorisation.
Le firmware est l’ensemble des composants logiciels qui permettent au téléphone de démarrer et de faire fonctionner Android avec son matériel. Il comprend notamment le système d’exploitation, les pilotes et les adaptations du fabricant. Une application présente dans cette couche ne bénéficie pas des mêmes restrictions qu’une application téléchargée depuis Google Play.
Le cas Midnight Mimosa illustre ce risque. Selon l’enquête publiée par Bitdefender le 8 octobre 2026, l’activité observée entre 2024 et 2025 concernait des appareils Android d’entrée de gamme de plusieurs marques, fondés sur des plateformes MediaTek. Le composant malveillant était incorporé au firmware avant la première utilisation.
Bitdefender indique avoir observé des milliers d’appareils uniques dans plus de 150 pays entre 2024 et 2025, notamment en France. Cette télémétrie n’a toutefois pas été confirmée par un jeu de données indépendant publié. La responsabilité de la modification et l’étape exacte de la chaîne d’approvisionnement restent inconnues en octobre 2026.
Pourquoi une désinstallation ne supprime-t-elle pas la menace ?
La désinstallation d’une application visible ne suffit pas lorsque le malware préinstallé Android réside dans une partition système protégée. Le composant persistant peut réinstaller des charges malveillantes, leur accorder des permissions ou charger du code distant. Une réinitialisation d’usine peut également restaurer le firmware compromis au lieu de l’assainir.
Dans Midnight Mimosa, le composant principal était une application système persistante signée par la plateforme. Selon Bitdefender en 2026, elle pouvait installer ou supprimer des paquets logiciels, accorder des autorisations et charger du code distant sans intervention de l’utilisateur. Au moins 32 applications de charge utile déguisées ont été identifiées pour la période 2024-2025.
Les fonctions observées incluaient la publicité cachée, la fraude au clic et l’utilisation du téléphone comme proxy résidentiel. Un proxy résidentiel fait transiter le trafic d’un tiers par la connexion internet du téléphone, qui apparaît alors comme une adresse légitime auprès des services visités. Cela peut consommer de la batterie et des données, mais surtout associer l’entreprise à du trafic qu’elle n’a pas initié.
Des noms tels que com.android.system.lite, com.android.sys.prot, com.android.sys.gmsprot et com.android.sys.bcprot ont été observés entre 2024 et 2025. Ces indicateurs ne constituent pas une méthode de détection suffisante : les noms variaient selon les versions du firmware. C’est un piège fréquent. L’absence d’un nom connu ne prouve pas que l’appareil est sain.
Ce mécanisme diffère d’un malware Android téléchargé qui contourne les protections bancaires. Dans ce second scénario, le retrait de l’application et la correction du vecteur d’installation peuvent suffire. Avec un implant système, il faut remettre en cause l’image logicielle complète.
Android Verified Boot protège-t-il contre un firmware compromis ?
Android Verified Boot contrôle en 2026 l’intégrité des composants de démarrage et des partitions protégées grâce à une chaîne de confiance ancrée dans le matériel. Cette protection détecte une modification non autorisée, mais elle ne garantit pas qu’un firmware correctement signé par le fournisseur ne contient aucun composant malveillant dès l’origine.
L’attestation Android peut transmettre la clé de démarrage, l’état de verrouillage du terminal, l’état du démarrage vérifié et l’empreinte du système contrôlé. Le résultat répond à une question précise : l’appareil exécute-t-il l’image attendue et signée ? Il ne répond pas nécessairement à une autre question : cette image était-elle saine lors de sa création ?
Un paquet malveillant intégré à un firmware fournisseur correctement signé peut donc apparaître comme un élément de confiance. C’est le cas où la solution évidente, vérifier simplement que le bootloader est verrouillé, devient insuffisante. Il faut croiser l’attestation avec le modèle, la provenance, le niveau de correctif et la politique de mise à jour du constructeur.
Google Play Integrity apporte un signal complémentaire. Selon la documentation Google de 2026, le verdict MEETS_STRONG_INTEGRITY exige un appareil authentique et certifié. Sur Android 13 ou version ultérieure, il exige aussi que les correctifs de sécurité du système et de la partition fournisseur datent de moins d’un an.
Aucun de ces contrôles n’est une garantie absolue contre un malware préinstallé Android. Leur intérêt tient à l’accumulation des signaux et au blocage automatique des appareils hors politique, comme pour le pilotage des mises à jour logicielles en entreprise.
Comment choisir des smartphones Android pour une entreprise ?
Une politique d’achat défendable en 2026 limite le parc à des modèles explicitement approuvés, achetés auprès de revendeurs documentés et assortis d’une date de fin de mises à jour connue. Chaque appareil doit être inscrit dans un outil MDM avant usage, puis refusé s’il échoue aux règles d’intégrité ou de correctifs.
Le MDM, pour Mobile Device Management, est un service d’administration centralisée des smartphones et tablettes. Android Enterprise permet en 2026 d’inventorier le matériel et les logiciels, d’imposer Google Play Protect, de contrôler l’intégrité, de restreindre les sources d’applications et de verrouiller ou effacer un appareil à distance.
Le tableau suivant compare les contrôles les plus utiles lors d’un achat professionnel.
| Contrôle | Risque couvert | Limite à connaître | Décision recommandée |
|---|---|---|---|
| Revendeur documenté | Chaîne d’approvisionnement opaque | Ne prouve pas seul l’intégrité du firmware | Refuser les vendeurs sans traçabilité |
| Date de fin des correctifs | Vulnérabilités non corrigées | Une promesse doit être suivie dans le temps | Inscrire l’échéance dans l’inventaire MDM |
| Android Verified Boot | Modification non signée du système | Accepte une image fournisseur correctement signée | Exiger un démarrage verrouillé et vérifié |
| Google Play Integrity | Appareil non certifié ou trop ancien | Ne réalise pas une analyse exhaustive du firmware | Bloquer les appareils hors politique |
| Gestion Android Enterprise | Applications et réglages non maîtrisés | Nécessite un enrôlement avant utilisation | Inscrire le terminal dès sa préparation |
Honnêtement, un smartphone très bon marché ne se justifie pas pour un usage professionnel sensible si son constructeur ne publie pas clairement la durée de support. L’économie initiale peut être absorbée par la préparation manuelle, les incidents, le remplacement anticipé et l’impossibilité d’accéder aux outils métier.
Sur les projets que nous menons, nous voyons souvent l’équipe choisir d’abord le modèle, puis chercher comment l’administrer. L’ordre devrait être inverse : définir les exigences MDM, d’intégrité et de durée de support, puis retenir les appareils qui y répondent. La même logique vaut pour la protection des données et fonctions sensibles d’une application mobile.
Une politique exploitable tient en cinq règles vérifiables :
- autoriser uniquement une liste courte de modèles et de versions approuvés en 2026 ;
- acheter auprès de revendeurs identifiés et conserver les références de commande ;
- enregistrer la date promise de fin des mises à jour du firmware ;
- enrôler chaque appareil dans le MDM avant de remettre le terminal au collaborateur ;
- bloquer automatiquement l’accès professionnel en cas d’échec d’intégrité ou de niveau de correctif insuffisant.
Que faire lorsqu’un smartphone professionnel paraît compromis ?
Un smartphone soupçonné de contenir un malware préinstallé Android doit être isolé sans délai des données et services professionnels. L’entreprise peut ensuite collecter les journaux disponibles, produire un rapport de diagnostic distant, puis verrouiller ou effacer le terminal. En cas de doute sur le firmware, supprimer l’application visible n’est pas une remédiation suffisante.
La priorité est de révoquer les sessions, certificats et jetons d’accès utilisés par l’appareil. Il faut aussi rechercher si le même modèle, la même version logicielle ou le même lot existe ailleurs dans le parc. Côté agence, le réflexe est de préserver les informations utiles à l’analyse avant un effacement, sans laisser le terminal continuer à communiquer avec les systèmes métier.
Selon la documentation Android Management de Google en 2026, les mesures prises en charge comprennent le blocage d’accès, la collecte de données de sécurité ou d’un rapport de bogue distant, ainsi que le verrouillage et l’effacement. Si le firmware est suspect, trois issues sont plus sûres : retour au fournisseur, réinstallation d’une image propre obtenue auprès d’une source fiable, ou retrait définitif.
Une réinstallation n’est raisonnable que si l’image utilisée est distincte de l’image compromise et si sa provenance peut être établie. Des témoignages publics rapportés en 2026 indiquaient que certains paquets suspects réapparaissaient après suppression, voire après une mise à jour officielle dans un cas. Aucune explication publique correspondante du fabricant n’avait alors été trouvée.
La prudence reste nécessaire autour de Midnight Mimosa. La confirmation technique indépendante demeure rare en octobre 2026 et l’essentiel des informations disponibles provient de l’enquête de Bitdefender. Les indicateurs sont assez sérieux pour justifier des contrôles, mais pas pour accuser sans preuve une marque, un sous-traitant ou un modèle entier.
Cadrer l’achat, l’enrôlement et le retrait des terminaux en amont évite la plupart des décisions improvisées après un incident. Un regard extérieur peut aussi aider à relier les règles Android Enterprise aux accès de l’application mobile et aux contraintes réelles des équipes.
FAQ sur les malwares préinstallés sur Android
Une réinitialisation d’usine supprime-t-elle un virus Android ?
Une réinitialisation d’usine supprime généralement les applications et données de l’utilisateur, mais elle peut restaurer un malware présent dans le firmware. En cas de compromission système, une image propre vérifiée ou le retrait du téléphone est nécessaire.
Comment savoir si un téléphone Android est certifié par Google ?
La certification peut être contrôlée dans les informations de Google Play Protect, tandis que Google Play Integrity permet à un service de vérifier l’intégrité d’un appareil en 2026. La certification ne constitue toutefois pas une analyse complète du contenu du firmware.
Google Play Protect détecte-t-il les applications système malveillantes ?
Google Play Protect analyse les applications et peut signaler des comportements dangereux, mais une application système privilégiée et correctement signée peut être plus difficile à neutraliser. Une entreprise doit compléter Play Protect par l’attestation, le MDM et une politique de modèles approuvés.
Quels signes peuvent révéler un téléphone utilisé comme proxy résidentiel ?
Une consommation inexpliquée de données, de batterie ou de ressources réseau peut justifier une analyse, sans constituer une preuve. Les journaux réseau, l’inventaire des paquets et les données de sécurité collectées par le MDM fournissent des indices plus exploitables.