Le signal le plus intéressant du dernier rapport du Google Threat Intelligence Group n’est pas que des attaquants utilisent l’intelligence artificielle, ce qui est documenté depuis longtemps. Il est beaucoup plus précis. Le maliciel DUSTMAKER, employé par un acteur motivé par l’argent suivi sous le nom UNC6780, aussi appelé TeamPCP, place en tête de ses fichiers JavaScript des prompts rédigés en commentaires, au contenu volontairement extrême, évoquant notamment des armes biologiques et nucléaires. L’objectif décrit est de provoquer les mécanismes de sécurité d’un scanner fondé sur un modèle de langage, afin qu’il échoue ou saute l’analyse du code malveillant situé en dessous. Autrement dit, l’attaquant ne cherche plus à convaincre la machine que son code est inoffensif. Il se sert de sa prudence pour la rendre aveugle.
La technique, exactement
Le procédé mérite d’être décrit avec précision, parce que c’est sa mécanique qui fait le signal. Les prompts sont insérés comme commentaires au début des scripts de chargement, les fichiers nommés _index.js dans les échantillons analysés. Le texte y est délibérément inacceptable, de façon à déclencher un refus de politique ou de sécurité. Si le scanner refuse de traiter le fichier ou interrompt son analyse, le code malveillant qui suit n’est pas examiné. Google indique que ces activités ont effectivement déclenché les réponses de sécurité de Gemini, et que l’entreprise a pris des mesures plus larges pour perturber les campagnes de ces acteurs. Le refus, ici, n’est pas un échec du modèle : c’est exactement le comportement attendu, provoqué au mauvais endroit et au mauvais moment.
Les 2 autres couches de confiance attaquées
Le même maliciel s’en prend à 2 autres points d’appui propres au développement assisté par l’IA. D’abord les répertoires de configuration cachés que lisent automatiquement les assistants de code et les environnements de développement, dont .claude, .vscode et .cursor. DUSTMAKER y dépose ou y modifie des fichiers, avec 2 effets distincts : créer des commandes de démarrage ou de compilation automatiques, pour que le maliciel s’exécute dès l’ouverture de l’espace de travail, et glisser des instructions qui font exécuter à l’assistant des commandes ou des scripts lors d’interactions ordinaires du développeur. Ensuite la provenance logicielle. Quand il détecte un environnement d’intégration et de livraison continues, le maliciel extrait des jetons d’identité de la mémoire des runners GitHub Actions, s’autorise avec eux comme éditeur de confiance, et publie des versions compromises de paquets accompagnées d’attestations cryptographiquement valides. Google précise que des paquets publiés avec des jetons valides passent les contrôles de confiance automatisés des agents de codage.
L’inversion de confiance
C’est le mécanisme à retenir, et nous le décrivons comme label d’analyse et non comme concept déposé. Dans les 3 cas, rien n’est cassé. Le modèle refuse bien un contenu dangereux, c’est sa fonction. Le répertoire de configuration est bien lu par l’assistant, c’est sa fonction. La signature de provenance est bien valide, c’est sa fonction. L’attaquant n’a pas vaincu la protection : il s’est déplacé en amont pour que le fonctionnement normal de la protection produise son avantage. Il faut insister sur la subtilité de la provenance, car elle se prête au contresens : l’attestation n’est pas falsifiée. L’attaquant dispose d’une identité d’intégration continue légitime, volée, et obtient donc une provenance authentique pour un paquet compromis. La signature dit la vérité sur qui a publié, elle ne dit rien sur ce qui a été publié. Nous l’avions déjà observé à propos du transfert des techniques nées dans la sécurité de l’IA vers le cyber classique : le terrain se déplace plus vite que les catégories qui servent à le décrire.
Ce qu’il ne faut pas conclure
La mesure s’impose, car le sujet mêle IA, chaîne logicielle et institutions, 3 registres qui appellent les raccourcis. L’acteur est présenté comme motivé par l’argent : il n’y a ici ni attribution étatique, ni opération d’ingérence, et rien n’autorise à en fabriquer une. Le refus d’un modèle n’est pas la preuve d’une défaillance de ce modèle, et Google indique avoir perturbé les campagnes concernées. Enfin, un cas documenté sur des échantillons n’établit pas une pratique généralisée : la technique est réelle, son ampleur reste à mesurer. Ce sont ces distinctions qui séparent une veille utile d’un récit d’anxiété.
Ce qu’ELMARQ retient
Pour une direction technique ou une direction des risques, 2 hypothèses de sécurité deviennent fragiles en même temps : l’IA refuse les contenus dangereux donc elle est prudente, et la provenance est cryptographiquement valide donc le logiciel est digne de confiance. Les 2 restent vraies techniquement, et c’est précisément pourquoi elles rassurent à tort. 3 réflexes en découlent. D’abord, traiter le refus d’un scanner comme un événement à journaliser et à examiner, jamais comme un quitus : un fichier non analysé n’est pas un fichier sain. Ensuite, considérer les répertoires de configuration des assistants comme une surface exécutable à part entière, revue et versionnée au même titre que le code, puisqu’un fichier caché y vaut une instruction. Enfin, distinguer provenance et intégrité : une attestation prouve une identité de publication, pas l’innocuité du contenu publié, ce que nous observions déjà sur la requalification tardive d’un incident de chaîne logicielle. La prochaine génération d’attaques contre les agents ne cherchera pas toujours à casser leurs protections. Elle cherchera parfois à les faire fonctionner exactement comme prévu, au mauvais moment.
Marc Lugand-Sacy, président d’ELMARQ.
