Détecter un logiciel espion sur un mobile : ce que deux outils montrent et ce qu'ils ne prouvent pas

La question revient à chaque déplacement sensible et après chaque incident : ce téléphone est-il compromis ? Elle est posée par des directions générales, des équipes sûreté, parfois des journalistes ou des avocats, et elle appelle presque toujours une réponse plus nuancée que celle attendue. Deux outils libres occupent aujourd'hui le terrain de la vérification technique, avec des approches opposées et une limite commune que leurs auteurs posent eux-mêmes.

L'intérêt de les examiner ensemble n'est pas de désigner le meilleur. C'est de comprendre ce que chacun regarde, donc ce qu'il est capable de manquer, et d'en tirer une règle de lecture des résultats qui protège l'organisation d'une double erreur : croire qu'un appareil est propre parce qu'un outil n'a rien vu, ou déclencher une crise interne parce qu'un indicateur a levé une alerte.

Cet article décrit les deux approches, la façon dont elles se complètent, la limite qui les concerne toutes les deux, puis le cadre de préparation, juridique autant que technique, sans lequel une analyse de terminal produit un résultat inexploitable.

Deux approches opposées : observer le réseau ou lire le système

ZATAZ décrit deux outils qui n'attaquent pas le problème par le même bout. SpyGuard, dans sa version 2, observe les communications réseau via le Wi-Fi pour identifier des comportements suspects, des indicateurs de compromission et des anomalies, en s'appuyant sur le moteur Suricata, et ne se limite pas aux smartphones. Son auteur, Felix Aimé, a repris son développement après deux ans afin de l'adapter aux évolutions de Suricata.

Mobile Verification Toolkit, connu sous le sigle MVT, procède autrement. Développé par le laboratoire de sécurité d'Amnesty International et publié en juillet 2021, il automatise la collecte de traces forensiques sur Android et iOS. Il ne regarde pas ce que l'appareil envoie pendant l'examen : il lit ce que l'appareil a conservé, dans ses sauvegardes, ses journaux, ses bases de données internes et ses artefacts système.

L'opposition est donc entre l'observation d'un flux et la lecture d'une trace. Le flux existe seulement pendant qu'on regarde, la trace subsiste après coup mais seulement si le système l'a écrite et ne l'a pas effacée. Les deux méthodes se recouvrent peu et se complètent bien : ce que l'une manque par nature, l'autre le voit parfois, et réciproquement.

Ce que l'analyse réseau rend visible, et son angle mort

Placer un terminal derrière un point d'accès contrôlé et regarder ce qu'il tente de joindre est une méthode simple et puissante. Un implant finit presque toujours par communiquer : il doit remonter les données collectées et recevoir des instructions. Les contacts avec une infrastructure connue, les motifs de trafic inhabituels, les volumes sortants sans rapport avec l'usage, les résolutions de noms de domaine incohérentes avec les applications installées constituent autant de signaux exploitables.

L'angle mort est structurel : cette méthode ne voit que ce qui se produit pendant la fenêtre d'observation. Un implant qui reste silencieux, parce qu'il attend un déclencheur, parce qu'il applique un rythme de contact espacé, ou parce qu'il détecte un environnement d'analyse, n'apparaît pas. Une session d'observation de trente minutes qui ne relève rien ne dit strictement rien sur les vingt-trois heures et demie restantes.

Un second angle mort tient au chiffrement généralisé. Le contenu des échanges reste inaccessible, l'analyse porte donc sur les métadonnées de connexion : destinations, horaires, volumes, périodicité. C'est suffisant pour lever un doute, rarement pour caractériser une charge. Cela oriente vers une investigation approfondie, cela ne la remplace pas.

Ce que la collecte de traces forensiques établit, et ses conditions

Lire les artefacts d'un système répond à une question différente : que s'est-il passé sur cet appareil avant aujourd'hui ? Une sauvegarde chiffrée d'un terminal contient un historique de messages, d'installations, de redémarrages, de processus et d'accès à des noms de domaine. Confronter cet historique à une liste d'indicateurs de compromission connus permet parfois de dater une infection avec une précision qu'aucune observation en direct ne donnerait.

Cette approche a ses propres conditions. Elle dépend de ce que le système d'exploitation a bien voulu journaliser et conserver, périmètre qui varie selon les versions et se réduit à mesure que les fabricants restreignent l'accès aux données internes. Elle dépend aussi de la qualité et de la fraîcheur des indicateurs utilisés : un implant récent, ou une variante non publiée, ne figure dans aucune liste et ne déclenche donc aucune correspondance.

Elle impose enfin une discipline de manipulation. La collecte se fait sur une copie, jamais sur l'appareil vivant, et la copie doit être empreintée puis conservée telle quelle. Une analyse conduite directement sur le terminal modifie l'objet examiné et rend contestable toute conclusion ultérieure. Cette exigence de chaîne de garde n'est pas une formalité : c'est ce qui distingue un constat opposable d'une impression technique.

Un résultat négatif n'établit pas qu'un appareil est sain. Il établit qu'avec cette méthode, cette liste d'indicateurs et cette fenêtre d'observation, rien n'a été vu.

La limite commune, et comment la formuler dans un rapport interne

La limite est explicitement posée par l'article de ZATAZ, et elle vaut pour les deux outils : aucune analyse fondée uniquement sur des indicateurs publics ne peut garantir qu'un appareil est sain, et un logiciel malveillant qui ne communique pas pendant l'analyse échappe à la détection. Cette phrase mérite d'être reprise telle quelle dans les documents internes, parce qu'elle empêche la dérive la plus courante, celle du certificat de bonne santé délivré par erreur.

La formulation correcte d'un résultat tient en une phrase de type : l'analyse conduite le tant, avec tel outil, telle version des indicateurs et telle durée d'observation, n'a pas relevé de correspondance connue. Elle nomme la méthode, la date, la couverture et le résultat, sans généraliser. Une direction générale comprend très bien cette nuance quand on la lui présente ainsi, et l'accepte mal quand elle la découvre après un incident.

Le corollaire opérationnel est qu'on ne fonde pas une décision sur un examen unique. Quand le doute repose sur un contexte sérieux, on répète l'observation réseau sur plusieurs jours et dans plusieurs contextes d'usage, on collecte les traces à intervalles, et on considère le renouvellement du terminal comme une option de traitement à part entière plutôt que comme un aveu d'échec de l'analyse.

Le cadre juridique et organisationnel à poser avant l'examen

Analyser un téléphone qui ne vous appartient pas engage l'organisation. Sur un terminal professionnel, la sauvegarde contient des données personnelles, des correspondances privées et parfois des informations relevant du secret médical ou de la vie familiale. L'examen suppose donc une base légale identifiée, une information préalable de la personne, un périmètre de collecte restreint à ce qui est nécessaire, et une durée de conservation définie pour la copie produite.

Sur un terminal personnel, y compris utilisé dans un cadre professionnel, l'analyse relève du consentement libre de la personne, et ce consentement doit rester révocable. Le cas des dirigeants et des personnes exposées se prépare en amont : décider à froid qui déclenche un examen, qui manipule la copie, qui la conserve et qui accède au rapport évite d'improviser au pire moment, quand un déplacement sensible vient de se terminer.

Le volet veille, enfin, précède le volet technique. Une compromission de terminal est presque toujours annoncée par une phase d'approche visible en sources ouvertes : profils de contact récents, sollicitations sur des messageries, campagnes de hameçonnage ciblées, réutilisation d'une adresse apparue dans une fuite. Les travaux publiés par l'Observatoire de l'Intelligence Économique situent à plusieurs semaines le délai moyen entre l'apparition de ces signaux et leur détection par l'organisation visée, écart qui laisse tout le temps nécessaire à un attaquant. NewsCore (www.newscore.fr) couvre en continu des millions de sources, détecte les mentions liées aux dirigeants et aux domaines de l'organisation et raccourcit ce délai en ramenant chaque alerte à sa source d'origine.

Questions fréquentes

Comment savoir si un téléphone est infecté par un logiciel espion ?

On combine deux examens plutôt qu'un. L'observation du trafic réseau sur un point d'accès contrôlé révèle les contacts avec une infrastructure connue et les anomalies de volume ; la collecte de traces forensiques à partir d'une sauvegarde révèle les événements passés. Aucun des deux ne délivre de certitude d'absence. Les signes d'usage souvent cités, chauffe, batterie, lenteurs, ne constituent pas des indices exploitables, car ils s'expliquent presque toujours autrement.

MVT et SpyGuard sont-ils utilisables sans compétence forensique ?

L'installation et l'exécution restent à portée d'un profil technique, l'interprétation ne l'est pas. La difficulté n'est pas de produire un rapport, elle est de savoir ce qu'une correspondance signifie, ce qu'une absence de correspondance ne signifie pas, et quels faux positifs sont attendus dans un environnement donné. Une équipe qui découvre ces outils au moment d'une suspicion sérieuse gagne à faire intervenir un tiers qualifié.

Que faire quand l'analyse ne trouve rien mais que le doute persiste ?

On documente précisément ce qui a été fait, on conserve la copie empreintée, et on traite le doute par des mesures qui ne dépendent pas du diagnostic : terminal neuf pour les déplacements sensibles, renouvellement des identifiants depuis un autre appareil, cloisonnement des échanges critiques. Le raisonnement est le même qu'en sécurité des locaux : quand la vérification ne peut pas conclure, on réduit l'exposition plutôt que d'attendre une preuve.