Quand l’IA agentique s’attaque aux applications mobiles

NNoor

D’après Clubic, Zimperium décrit des frameworks agentiques comme OpenClaw ou Hermes, capables d’enchaîner différentes étapes d’une attaque à partir d’instructions en langage courant. L’idée importante, ce n’est pas seulement qu’un agent propose une piste : il pourrait recevoir un objectif, agir dans une application, examiner le résultat, puis adapter les étapes suivantes. Dans le scénario présenté, l’objectif est de repérer les faiblesses d’une application mobile et de tenter de les exploiter, plutôt que de s’en tenir à une réponse écrite ou à une suggestion de code. L’agent peut conduire une suite d’actions : il observe l’interface, effectue une manipulation, puis utilise ce qu’il constate pour décider de la suite. Cette capacité à coordonner plusieurs étapes est au cœur de la démonstration. Elle rapproche l’agent d’un opérateur qui exécute une procédure, tout en laissant à l’outil le soin de choisir certaines actions au fil de l’opération. La consigne peut être formulée simplement, mais cela ne signifie pas que l’opération soit simple pour l’agent, ni qu’elle aboutisse à chaque fois. Zimperium met en avant une automatisation possible, pas la preuve que n’importe quelle application peut être compromise par une demande ordinaire. Il faut donc distinguer la facilité apparente de la consigne, la complexité réelle des tâches et le résultat final : la démonstration porte sur des capacités, pas sur une réussite universelle.

NNoor

Alors, une première étape consiste à utiliser l’application à travers son écran, comme le ferait une personne. L’agent peut combiner des captures d’écran et la reconnaissance de texte pour repérer les éléments de l’interface, puis remplir des formulaires, valider des autorisations ou avancer dans une procédure. Les fonctions d’accessibilité peuvent lui permettre d’interagir avec l’écran, et l’action vise l’application telle qu’elle est utilisée, sans passer par ses serveurs. Ensuite, l’agent peut analyser le code et observer le fonctionnement du programme afin de chercher comment celui-ci réagit. Ces deux approches ne donnent pas la même information : l’analyse du code permet d’examiner sa structure, tandis que l’observation en fonctionnement montre ce qui se passe pendant l’exécution. Des outils d’instrumentation comme Frida peuvent servir à examiner l’application et à intercepter certaines fonctions. Les méthodes peuvent varier selon les protections rencontrées : l’agent pourrait modifier l’application, puis la réinstaller sur un appareil qui n’a pas lui-même été modifié. Cela ne signifie pas qu’il contourne automatiquement toutes les défenses. Il s’agit plutôt d’une succession d’observations et d’essais, où les résultats peuvent orienter l’étape suivante. Une application faiblement protégée et une application conçue pour détecter ces manipulations ne présentent donc pas nécessairement le même parcours à l’agent. La démonstration décrit une méthode adaptative, pas une recette qui fonctionnerait à l’identique sur chaque téléphone.

NNoor

Le recours à des instructions en langage courant pourrait abaisser une partie de la barrière technique : l’opérateur n’aurait pas nécessairement à conduire lui-même chaque manipulation. Cela ne supprime pas les difficultés, et les éléments disponibles ne disent pas qui utilise déjà ces outils ni à quelle fréquence. Le changement d’échelle envisagé vient surtout de la réutilisation : Zimperium indique qu’une attaque automatisée peut être convertie en script, puis lancée en parallèle sur plusieurs émulateurs. Brief IA précise que lorsqu’une faille est repérée, cette procédure pourrait être rejouée, et que relancer l’opération après une mise à jour pourrait coûter peu à l’agent. Il faut garder le conditionnel : ce coût n’est pas chiffré ici, et une nouvelle tentative ne garantit pas que les mêmes étapes fonctionneront. La possibilité de réutiliser un script change néanmoins la logique de l’opération. Une méthode qui aurait été appliquée à une cible peut être répétée sur plusieurs environnements, sans que chaque manipulation soit nécessairement recréée manuellement. Cela pourrait faciliter une fraude à grande échelle si les conditions sont réunies. Mais la fiche ne donne ni le nombre de cibles effectivement visées, ni le taux de réussite, ni le volume des fraudes qui en résulteraient. Il s’agit donc d’un scénario de multiplication des tentatives, et non d’un bilan établi de campagnes déjà déployées. L’accessibilité accrue concerne certaines étapes de l’attaque, pas la garantie d’obtenir un résultat.

NNoor

Il faut distinguer la capacité technique décrite et son déploiement réel. Brief IA affirme que Zimperium a observé de l’automatisation sur le terrain et cite RatHat, un malware bancaire pour Android qui interpréterait l’écran afin de voler des identifiants. Mais les éléments disponibles ne permettent pas d’établir le lien exact entre cet exemple et les attaques agentiques décrites. RatHat ne suffit donc pas à prouver qu’un agent a conduit de bout en bout une attaque de grande ampleur contre une application mobile. L’exemple montre qu’un logiciel malveillant peut exploiter l’interprétation de l’écran, mais il ne permet pas à lui seul de conclure que le processus présenté par Zimperium est déjà couramment utilisé. On ne dispose pas ici d’un taux de réussite, d’un nombre de victimes, ni d’une mesure de la fréquence de ces attaques. La démonstration décrit des étapes possibles, comme l’interaction avec l’écran, l’analyse de l’application et la réutilisation d’un script, mais elle ne donne pas le résultat de ces méthodes face à chaque type de protection. Il faut également séparer l’observation d’une automatisation sur le terrain de la preuve d’une fraude à grande échelle menée par un agent. Les informations disponibles ne précisent pas l’ampleur de l’exemple cité ni son rapport exact avec les frameworks agentiques. Il est donc juste de parler d’un risque émergent et d’une automatisation présentée par Zimperium, sans transformer ces éléments en preuve d’une menace déjà couramment déployée.

NNoor

Il faut retenir que l’agent pourrait relier plusieurs opérations : utiliser l’interface, examiner le fonctionnement de l’application et adapter ses méthodes aux protections rencontrées. Le risque vient de cette combinaison, et non d’une simple lecture d’écran prise isolément. L’agent ne se limite pas à identifier un bouton : dans la démonstration, il peut poursuivre une action, observer ce qui se passe, puis essayer une autre méthode en fonction des obstacles. Si une faiblesse est trouvée, la procédure pourrait devenir un script réutilisable et être lancée en parallèle sur plusieurs émulateurs. Cette répétition rend plausible une amplification de l’attaque, mais elle ne dit pas combien d’opérations aboutiraient ni combien de personnes seraient touchées. Une mise à jour peut modifier la situation et conduire à une nouvelle tentative ; la relance à faible coût est une possibilité rapportée, pas la preuve que les défenses seraient sans effet. De même, l’exemple de RatHat doit rester distinct de la démonstration tant que leur lien précis n’est pas établi. Pour les utilisateurs, cela ne justifie pas de conclure que leur téléphone est déjà visé par ce type d’attaque. La conclusion est donc mesurée : les agents peuvent rendre certaines étapes d’attaque plus automatisables et potentiellement plus faciles à répéter, tandis que l’ampleur actuelle de leur usage reste incertaine. C’est cette différence entre capacité démontrée et fréquence réelle qu’il faut garder en tête.