Combattre le feu par le feu : utiliser l'IA pour combattre l'IA

Les attaques d'applications ont fortement augmenté. 83 % en janvier 2025, contre 65 % auparavant. Un an auparavant, ce chiffre était déjà alarmant. Ce seul fait devrait donner à réfléchir à toute équipe de sécurité, mais la question cruciale est de savoir pourquoi la courbe s'infléchit si rapidement. La réponse n'est pas qu'il y a soudainement plus d'attaquants. C'est que chaque attaquant est plus compétent qu'auparavant, et l'écart entre un novice et un expert s'est considérablement réduit, ce qui devrait inquiéter tous ceux qui sont responsables de la distribution d'applications aux clients. 

Les grands modèles de langage ont accompli cela. Non pas progressivement, ni de manière marginale. Ils ont considérablement réduit les compétences et le temps nécessaires pour attaquer une application, de la même façon qu'ils ont réduit les compétences et le temps nécessaires pour la développer. Les outils (jadx, IDAPro, Ghidra, Frida) existaient déjà, et d'autres sont utilisés depuis des années. Ce qui a changé, c'est l'expertise requise pour les utiliser efficacement, et la rapidité avec laquelle un attaquant motivé peut passer de l'identification de la cible à son exploitation active. 

Un collègue, Cole Herzog, a publié une analyse technique détaillée de cette dynamique (Le piratage assisté par l'IA, ou : Comment apprendre à ne plus s'inquiéter et à aimer le LLMEt si vous ne l'avez pas encore fait, je vous recommande de lire l'article en entier. Cole y démontre, étape par étape, comment un attaquant utilise un LLM pour rétroconcevoir le binaire d'une application mobile, configurer un environnement d'instrumentation dynamique et énumérer les fonctions au sein d'une application en cours d'exécution. Aucune de ces étapes n'est nouvelle. La nouveauté réside dans le peu de compétences requises pour chacune d'elles. 

La conclusion est simple : la personne qui ne possédait pas les compétences nécessaires pour mener cette attaque il y a un an les possède probablement maintenant, ou a accès à un outil qui comble cette lacune. La démonstration de Cole utilisait un simple dump hexadécimal traité par un LLM public pour extraire les points de terminaison d'API d'un binaire non protégé en moins de deux minutes. Il ne s'agit pas d'une attaque sophistiquée. C'est un projet réalisable en un après-midi, et c'est la première étape d'une chaîne qui aboutit à vos systèmes back-end. 

La raison pour laquelle les applications côté client occupent une place unique dans ce paysage des menaces tient à… asymétrie fondamentale Aucun système de sécurité réseau ne peut résoudre ce problème. Vos serveurs sont protégés par des pare-feu, des couches d'authentification et des contrôles d'accès que vous possédez et gérez. Votre application mobile, quant à elle, s'exécute sur un appareil qui ne vous appartient pas, dans un environnement que vous ne contrôlez pas, et son code peut être téléchargé, décompressé et analysé par n'importe qui. Le code côté client est entièrement accessible et lisible par les personnes malveillantes. Il ne s'agit pas d'un problème de configuration ou d'une faille de sécurité. C'est inhérent à la technologie. 

Cette asymétrie a toujours existé. Prenons l'exemple d'une banque comptant deux millions d'utilisateurs actifs mensuels. Statistiquement, une partie de ces utilisateurs a toujours été curieuse de découvrir le contenu de l'application, et une plus petite partie d'entre eux a toujours été prête à passer à l'acte. Cette menace existait déjà en 2022, en 2021 et bien avant. Les LLM (Learning Linked Models) ont décuplé l'efficacité des attaquants, quel que soit leur profil. L'attaquant qui passait des semaines à décompiler un binaire en 2023 peut désormais accomplir la même chose en quelques heures. Quant à l'utilisateur curieux qui, face à une complexité technique insurmontable, aurait abandonné, il dispose maintenant d'un outil qui le guide pas à pas, rédige les scripts et explique le résultat, jusqu'à ce qu'un projet parallèle, initialement motivé par la curiosité, devienne une action plus délibérée. Le nombre de personnes capables de mener une attaque significative côté client vient de s'accroître considérablement. 

Voici ce qui rend les attaques côté client particulièrement difficiles à contrer : elles ne ressemblent pas à des attaques. Un attaquant qui analyse votre application, extrait une clé API valide et commence à interroger votre serveur génère un trafic indiscernable du trafic légitime. La clé est valide. L’authentification réussit. Les requêtes sont conformes aux modèles attendus. Aucune alarme, aucune anomalie, aucun signal évident d’un problème, car du point de vue de votre infrastructure, rien ne se passe. La session ressemble trait pour trait à celle de l’un de vos deux millions d’utilisateurs légitimes. 

C’est pourquoi le nombre de violations de données côté client documentées publiquement sous-estime la fréquence réelle des attaques de ce type. Seules les violations provoquant une panne, déclenchant une alerte à la fraude ou faisant l’objet d’un document réglementaire sont signalées. L’attaquant qui agit avec prudence, collecte les données progressivement et utilise des identifiants légitimes peut ne jamais apparaître dans un rapport d’incident. L’absence de preuve n’est pas une preuve d’absence, mais plutôt la preuve d’une lacune en matière de surveillance. 

surveillance des menaces en temps réel Cela comble cette lacune. Savoir qu'une application s'exécute dans un environnement compromis, que son code a été altéré ou que ses systèmes de protection sont sondés, est une information disponible dès l'incident, et non après que le mal soit fait. Mais la détection seule ne suffit pas. La capacité la plus puissante réside dans la réaction. des réponses codées directement dans le binaire de l'application qui se déclenchent automatiquement lorsque des conditions de menace spécifiques sont remplies.Une application bancaire qui détecte une tentative de falsification peut imposer une authentification renforcée avant que l'attaquant ne poursuive son intrusion. Une application exécutée dans un environnement compromis peut se fermer automatiquement. Un jeu mobile qui détecte un outil de triche peut réagir de manière plus originale : désactiver la gravité pour les unités du joueur, par exemple, afin que ses soldats flottent discrètement hors du champ de bataille sans que les joueurs légitimes ne s'en aperçoivent. L'attaquant est sanctionné. L'expérience de jeu reste intacte pour tous les autres. 

La réponse logique face à une menace qui s'accélère est d'accélérer la défense au même rythme. C'est plus facile à dire qu'à faire, car l'élaboration d'un plan de protection (la configuration qui détermine précisément le renforcement de la sécurité d'une application) exige des semaines d'échanges entre ingénieurs en sécurité, ingénieurs commerciaux et, parfois, les développeurs de l'application eux-mêmes. Pendant ce temps, l'application est soit mise sur le marché sans protection complète, soit son calendrier de publication est retardé. Aucune de ces situations n'est acceptable compte tenu de l'évolution rapide des menaces et du fait que tout retard de publication entraîne un retard de rentabilité. 

C’est là que l’IA appliquée à la défense entre en jeu – non pas comme un concept marketing, mais comme une réponse concrète à un véritable problème opérationnel. Agent Quick Protect v2 L'outil analyse le code de l'application, détermine les composants les plus vulnérables et génère automatiquement une première ébauche de plan de protection personnalisé. Ce qui nécessitait auparavant environ deux semaines de travail d'ingénierie collaboratif ne prend plus que deux heures. Cette compression est cruciale non seulement pour l'efficacité, mais aussi pour la sécurité : plus la protection est configurée et déployée rapidement, plus la période d'exposition de l'application est courte. 

Le message de Cole met en lumière un point important. Les experts en sécurité informatique (LLM) ne peuvent travailler qu'avec les informations dont ils disposent. Autrement dit, ils peuvent aider les attaquants à déchiffrer des outils dont l'implémentation est publique, mais ils peinent face aux protections pour lesquelles ils n'ont pas été formés. Le renforcement de la sécurité basé sur la adresse IP crée une faille que les outils open source ne présentent pas. Une défense réactive, appliquant une protection non accessible publiquement à un expert en sécurité informatique et capable de détecter et de contrer les attaques en temps réel, représente une cible bien plus difficile à atteindre qu'une défense moins performante. 

Un autre point important à considérer est qu'aucun outil de sécurité ne peut constituer une solution unique. Le paysage des menaces continuera d'évoluer. Tous les fournisseurs de solutions de sécurité dépendent des équipes de recherche sur les menaces pour rester à la pointe. Digital.ai Il en va de même pour notre équipe de recherche sur les menaces, répartie sur deux continents, qui veille à ce que le renforcement de nos applications continue d'évoluer au même rythme que les menaces. 

Les 2025 Application Security Rapport de menace Ce rapport documente une augmentation fulgurante du taux d'attaques, sans aucun signe de ralentissement. La dynamique sous-jacente à cette hausse est irréversible : les outils existent, ils s'améliorent et sont accessibles à quiconque est suffisamment motivé pour les utiliser. C'est dans ce contexte que vos applications évoluent aujourd'hui, et ce phénomène sera encore plus marqué d'ici un an. 

Rien de tout cela ne justifie la panique. Cela plaide plutôt pour une analyse honnête de la menace réelle, de son emplacement et des mesures nécessaires pour la contrer sérieusement. La surface d'attaque côté client ne disparaîtra pas simplement parce que vous avez corrigé vos serveurs ou renforcé le périmètre de votre réseau. L'attaquant qui a téléchargé votre application, injecté son binaire dans un LLM et commencé à cartographier vos chemins d'accès back-end n'a pas touché votre infrastructure. Il n'en avait pas besoin. 

La bonne nouvelle, c'est que la même technologie qui accélère l'attaque est disponible du côté de la défense, et les principes fondamentaux qui rendent une application difficile à attaquer restent inchangés : l'obfuscation à laquelle un LLM n'a pas été entraîné ; les protections en temps réel qui détectent et réagissent avant que des dommages ne soient causés ; un renforcement de la sécurité configuré spécifiquement pour l'application plutôt qu'appliqué de manière générique ; et une vitesse de déploiement adaptée à celle de la menace. Ces idées ne sont pas nouvelles. Ce qui est nouveau, c'est l'urgence de les appliquer correctement.