Rétrospective ShinyHunters : Savoir quelles applications doivent être protégées contre les attaques alimentées par l’IA

Il se pourrait qu'une clé appartenant à votre entreprise se trouve quelque part dans un groupe Telegram. Comment est-ce possible ? Grâce à l'IA. Et parce que de nombreuses personnes divulguent accidentellement des informations confidentielles dans des applications accessibles au public. 

Dans son rapport de veille sur les menaces de septembre 2026, Anthropic a documenté une opération de collecte d'identifiants menée par un opérateur francophone affilié à l'écosystème ShinyHunters. Le processus s'exécutait sur dix instances AWS EC2. Il téléchargeait en masse 1.8 million d'APK Android différents depuis plusieurs plateformes de téléchargement d'applications, les décompilait et analysait les fichiers obtenus avec TruffleHog à la recherche de secrets codés en dur : clés API, identifiants cloud et jetons d'accès. Les identifiants validés étaient acheminés en temps réel vers Telegram et organisés de manière à permettre à l'opérateur de prioriser ceux destinés aux systèmes de production. Un flux parallèle collectait les jetons d'accès personnels GitHub exposés. 

D'après Anthropic, ces deux flux ont « fourni les identifiants d'accès initiaux pour la majorité des violations confirmées » liées à l'opérateur. Et bien sûr, ils ne se sont pas arrêtés là ! Après avoir compromis un fournisseur SaaS, les opérateurs ont atteint environ 200 organisations clientes de cette entreprise, puis ont dérobé plus de 2 100 ensembles de jetons Azure AD à plus de 40 locataires d'entreprise en l'espace de 34 heures environ. Anthropic précise que des agents d'IA ont effectué la quasi-totalité du travail. Oups. 

Qu’ont fait les agents ? Ils ont téléchargé, décompilé et analysé le système. 

Aucun émulateur. Aucun appareil physique. Aucun téléphone rooté, aucun framework d'instrumentation, aucune exécution d'aucune sorte. En fait, l'application n'a jamais été lancée. Il s'agissait d'une analyse statique pure visant à rechercher rapidement des données visibles et pertinentes, près de deux millions de fois. 

Comprendre l'ampleur du problème

Cela a une implication gênante quant à la façon dont la plupart des équipes envisagent la sécurité des applications mobiles, et une implication honnête quant à la façon dont nous parlons de nos propres produits ici chez Digital.aiLes protections en temps réel telles que la détection de falsification, la détection de root et de jailbreak, la protection contre l'instrumentation et RASP sont certes précieuses, mais elles sont totalement hors sujet ici. Une défense qui se déclenche au lancement de l'application est inefficace contre une attaque qui n'implique jamais son exécution. Tout fournisseur qui prétend le contraire concernant cette campagne spécifique vous vend une solution qui n'aurait servi à rien dans ce cas précis. 

Cela explique aussi l'ampleur du phénomène. Lancer une application est coûteux : il faut un appareil ou un émulateur, un compte actif, (parfois) une connexion et un humain pour déterminer ce qui s'est passé. Lire un fichier est peu coûteux. En fait, l'IA a quasiment éliminé le coût de lecture et d'interprétation d'un fichier binaire, ce qui met fin à la question sur laquelle les équipes mobiles s'appuyaient discrètement depuis des années : « Notre application est-elle suffisamment intéressante pour que quelqu'un prenne la peine de l'essayer ? » Personne n'a jugé que ces applications valaient la peine d'être testées. Aucun effort n'a été fait pour allouer des ressources. Au contraire, l'attaquant s'est dit : « Si je ratisse large, je finirai bien par attraper quelque chose d'intéressant. »  

Nous le savions déjà : si une authentification privilégiée de longue durée est intégrée à votre application mobile, la solution consiste à la supprimer. Les authentifications privilégiées doivent être gérées côté serveur. L’application doit s’authentifier, puis émettre des jetons éphémères et limités dans le temps pour les opérations spécifiques dont le client a réellement besoin. Mettez en place des quotas d’utilisation, des restrictions d’application et un processus de rotation que vous avez testé vous-même, plutôt qu’un processus standard. 

Aucune protection côté client ne modifie cette recommandation. Une application que vous déployez sur un appareil que vous ne contrôlez pas est, par définition, entre les mains de la personne contre laquelle vous vous défendez. L'obfuscation ne rend pas un secret côté client architecturalement sûr. safe et Digital.ai ne prétend pas le faire. 

Commencez par en parler à votre équipe. Ensuite, ayez la deuxième conversation, celle qui est le véritable enjeu de cette campagne. 

Quels changements liés au durcissement : le coût de l’extraction 

La seconde discussion porte sur l'augmentation du coût d'extraction. Il est impossible de déplacer tous les secrets côté serveur du jour au lendemain, certaines informations révélées par un binaire ne constituent pas des identifiants, et la correction prend des mois alors qu'une analyse ne prend que quelques secondes. Par conséquent, lorsqu'il s'agit d'optimiser l'utilisation de ressources de sécurité limitées, la question pertinente n'est pas « mon application est-elle impénétrable ? » mais plutôt « mon application est-elle peu coûteuse à analyser ? ». 

Cette distinction constitue le mécanisme même de cette attaque. Un pipeline traitant 1.8 million de fichiers binaires est optimisé pour le débit. Il ne perd pas vingt minutes à contourner les protections de l'application numéro 395 423 ! Au contraire, il abandonne cette application et passe à l'une des 1.79 million autres, gratuites. Chaque protection transformant une simple lecture statique en une analyse dynamique par application vous retire de ce processus. On dit souvent en plaisantant qu'il n'est pas nécessaire d'être plus rapide que l'ours, mais simplement plus rapide que votre compagnon de randonnée. Dans ce cas précis, il suffit de ne pas se faire remarquer en étant une antilope malade ou faible en marge du troupeau.  

Capacités, leur fonctionnement et leur importance ici

String Encryption Guard — App Hardening for Mobile (DEX 6.9.1, Native ARM 16.6.0) remplace les chaînes de caractères littérales par un appel de déchiffrement à l'exécution, empêchant ainsi toute donnée lisible de survivre à une décompilation statique. Cette fonctionnalité neutralise directement l'analyse statique des chaînes automatisée par cet opérateur et impose une attaque dynamique par application, une méthode inadaptée à 1.8 million d'applications.

Cryptographie en boîte blanche — Agent 1.1.1 : Les identifiants sont stockés via `hideAndStore()` et récupérés via `fetchAndUnhide()` au lieu d'être stockés sous forme de constantes simples, liées à l'identité du package de l'application et au certificat de signature. Cette technologie est spécialement conçue pour protéger les clés API et les jetons OAuth. Sa robustesse s'étend au-delà de l'extraction statique et couvre les appareils rootés, jailbreakés et débogués, offrant ainsi une protection supérieure au simple chiffrement de chaînes de caractères.

Le chiffrement des chaînes de caractères est une configuration effectuée lors de la compilation. La cryptographie en boîte blanche est une intégration délibérée du développeur, et non une option à activer/désactiver ; cela représente un véritable effort, et vous pouvez en apprendre davantage ici. L'essentiel est de comprendre le champ des possibles : une authentification qui n'existe que sous la forme d'un objet chiffré lié à votre certificat de signature ne sera pas détectée par une simple commande grep, et un pipeline optimisé pour le débit ne l'ignorera pas. 

La dernière question à se poser est la suivante : quelqu’un dans votre équipe a-t-il décompilé votre version de production actuelle et lu ce qui en ressort ? 

Pour la plupart des organisations, la réponse est non, non par négligence, mais parce qu'aucun outil standard ne le révèle. L'analyse statique examine le code source, tandis que l'analyse de composition examine les dépendances. Aucune de ces méthodes ne présente l'artefact tel qu'un attaquant le reçoit, c'est-à-dire la seule forme de votre application qu'un pipeline de ce type puisse observer.

Découvrez ce que contient votre entonnoir de conversion. Ensuite, décidez de l'importance que vous souhaitez y accorder. 

Digital.ai App Protection aide les équipes à augmenter le coût du rétro-ingénierie et de la falsification assistés par l'IA pour les applications distribuées hors de leur contrôle. Si vous souhaitez obtenir de l'aide pour identifier les secrets contenus dans votre application, inscrivez-vous dès aujourd'hui ! évaluation gratuite de l'application — ou lisez-en plus sur Renforcement de la sécurité des applications mobiles et cryptographie en boîte blanche

Références

Anthropic, Détection et lutte contre les utilisations abusives de l'IA : septembre 2026* (groupe de menaces GTG-50014). Détails du produit : Digital.ai Guides d'utilisation de l'application Hardening for Mobile (DEX 6.9.1, Native ARM 16.6.0) et de White-Box Cryptography: Agent 1.1.1.