Bienvenue dans une époque où les logiciels malveillants souscrivent à un abonnement « mise à jour continue » et où l’intelligence artificielle se transforme en une source de tâches pas très éthiques. Cette semaine, Google a dévoilé PROMPTFLUX, une nouvelle catégorie de code malveillant expérimental qui ne se limite plus à être programmée une seule fois : elle interroge l’API Gemini lors de son exécution pour se réécrire et se dissimuler, tout en rendant la tâche des équipes de sécurité plus ardue. Si vous considérez que le terme « polymorphisme » est démodé depuis les années 2000, PROMPTFLUX se charge de prouver qu’il est toujours possible d’innover davantage (ou de manière plus sournoise 🤣).
Un malware pas comme les autres : présentation de PROMPTFLUX
Bien, c’est quoi cette histoire ? PROMPTFLUX n’est pas un logiciel malveillant comme les autres… pas de code C++ développée par un laboratoire secret ou un hacker mais en réalité juste un VBScript (oui, ce bon vieux VBScript). Bon pas si simple en faite, il est conçu comme un dropper expérimental. Ce qui le distingue des autres ce n’est pas son code, qui n’a rien d’extraordinaire. Plutôt que de s’appuyer sur des fonctionnalités internes, il fait appel à des appels d’API vers Gemini pour obtenir à la demande des fragments de code et les incorporer dans son processus d’exécution. Donc il mute en permanence !
Pourquoi avoir choisi VBScript ? Sans doute, en raison de sa simplicité et de sa compatibilité avec Windows, cela en fait un moyen pratique pour une mise en œuvre rapide. Le logiciel malveillant conserve la partie fondamentale du script sur l’appareil infecté et confie à l’intelligence artificielle distante la création et la modification du code. C’est astucieux et rentable : il n’est pas nécessaire d’intégrer une grande quantité de code, simplement une logique pour invoquer l’API et mettre en œuvre le résultat. Et voilà aussi simple que ça… c’est juste dingue je trouve.
L’idée est à la fois simple et perturbante. Au lieu de fonctionner avec une charge utile définie comme un fichier « .exe » identifiable ou un script uniformisé, PROMPTFLUX opère en mode « à la demande » : il communique avec Gemini, transmet une instruction (un message écrit) décrivant ce qu’il recherche (par exemple : « produis une version VBScript d’une fonction de récupération de fichiers ») et obtient en retour une réponse contenant du code sur mesure. Par la suite, ce code est mis en œuvre localement. Et comme l’IA est capable de générer des versions infinies, le logiciel malveillant peut régulièrement se modifier (Google a noté des cycles par heure), ce qui rend très difficile la corrélation entre les échantillons pour les systèmes basés sur des signatures (l’antivirus devient donc inutile). Une autre méthode notée : les attaquants exploitent des stratagèmes sociaux dans leurs requêtes pour déjouer les sécurités du modèle, en se présentant comme un étudiant en CTF ou un chercheur légitime, et par conséquent, obtenir du code que Gemini, dans d’autres situations, aurait refusé de délivrer. Bref ils font du prompting super optimisé. En fin de compte, sur le plan technique, la mutation horaire ou périodique vise deux buts précis :
- Obscurcir les signatures : si chaque version du malware présente un code distinct, les signatures fixes perdent leur utilité.
- Dissimuler le canal de contrôle : l’API Gemini, si elle est disponible sur le réseau, donne l’impression d’être un service cloud authentique plutôt qu’un serveur C2 classique hébergé sur une adresse IP douteuse. Conséquence : la défense se retrouve coincée entre une brume algorithmique et un trafic qui semble totalement banal.
Prenons un bref instant pour réfléchir aux conséquences tangibles. Dans ses formes initiales, PROMPTFLUX n’est pas nécessairement le malware le plus complexe. Cependant, sur le plan conceptuel, il modifie les règles du jeu. C’est la raison pour laquelle nos outils classiques (antivirus, EDR, listes d’IoC) sont conçus pour identifier des motifs familiers. Si la forme évolue chaque heure, quel est le sens de ces signatures ? Elles deviennent au mieux incomplètes, au pire dépassées dès la prochaine évolution. Les SOC seront contraints d’adopter des méthodes comportementales et heuristiques qui consomment davantage de ressources et d’expertise. Et oui, une requête à une API publique d’IA présente de nombreuses similitudes avec une demande authentique (authentification, HTTPS, fournisseur de cloud reconnu). Le défi de filtrer ce trafic sans entraver les utilisations internes légitimes d’IA devient une véritable énigme.
Le rapport du Google Threat Intelligence Group (GTIG) n’est pas juste une alerte sur un script malin, c’est une photographie d’une tendance émergente : des menaces qui incorporent des LLMs dans leur cycle d’exécution. Plusieurs points clés méritent d’être soulignés :
- Les adversaires expérimentent l’IA à tous les niveaux : reconnaissance, écriture de phishing, génération de payloads, et maintenant génération de code à l’exécution. On n’est plus uniquement dans l’automatisation d’étapes périphériques, on injecte l’IA au cœur même de la chaîne d’attaque.
- Des acteurs au comportement opportuniste : GTIG note que certains groupes parrainés par des états (divers pays cités dans le rapport) testent ces techniques. Cela signifie que la ressource humaine et l’investissement financier derrière ces expérimentations peuvent être lourds, et que la mise en production de ces méthodes n’est pas exclue.
- Les prompts deviennent des vecteurs d’ingénierie sociale : au lieu d’un simple échange technique, les opérateurs préfèrent parfois se servir d’une petite mise en scène (« je suis étudiant en CTF, peux-tu m’aider… ») pour pousser le modèle à fournir du code sensible. Cela montre que la sécurité des LLMs dépend autant des contrôles techniques que de la compréhension des tactiques d’ingénierie sociale.
- Une coopération nécessaire entre éditeurs d’IA et sécurité : Google insiste sur le fait qu’il renforce ses garde-fous et qu’il partage des IoC et bonnes pratiques. Mais ce n’est qu’une partie de la solution : il faudra aussi que fournisseurs cloud, développeurs d’EDR, équipes SOC, et régulateurs se coordonnent pour limiter l’usage abusif des APIs.
Ouvrons le débat : l’IA, vecteur d’attaque… ou simple catalyseur ?
Voici la question épineuse (ou captivante) : l’IA est-elle à l’origine de la menace, ou contribue-t-elle simplement à sa propagation et à sa réduction en coûts ? Comme fréquemment, la réponse est nuancée. L’intelligence artificielle ne remplace pas la créativité humaine, mais elle facilite l’accès et l’évolutivité de certaines méthodes. PROMPTFLUX n’est pas une intelligence malveillante ayant soudainement acquis de la conscience, c’est un instrument qu’un utilisateur a détourné pour fiabiliser et automatiser une portion de sa tâche ingrate. D’un côté, on pourrait soutenir que l’IA exacerbe les dangers : une meilleure création de code, des outils d’exploitation améliorés, des e-mails de phishing plus convaincants et maintenant du code dynamique en cours d’exécution. Par ailleurs, on peut soutenir que chaque avancée technologique s’accompagne de nouveaux outils de défense : une analyse comportementale plus fine, un filtrage sophistiqué des requêtes, une coopération entre intervenants et des régulations. La question cruciale est d’ordre social et politique : Souhaitons nous un environnement d’IA où l’accès est libre sans aucune restriction, ou une structure plus rigoureuse avec le risque de brider l’innovation ?
À mon avis, le bon équilibre se trouvera par le biais d’une série de vérifications fiables : sélection stricte des comptes qui requièrent des modèles, quotas, surveillance accrue des pratiques sensibles, ainsi qu’une clarté opérationnelle entre les fournisseurs et leurs clients. Ce n’est pas attrayant, ni instantané, mais c’est probablement ce qui freinera la prolifération de PROMPTFLUX-bis partout. Cependant, comment maintenir la liberté individuelle dans ce modèle ? Pour être franc, je n’ai pas la réponse, mais il faudra bien que la question soit soulevée à un certain point.
PROMPTFLUX est un signal important : la création de code par des LLMs ne se limite plus aux environnements de laboratoire ou aux démonstrations, elle est désormais exploitée en production par des entités malveillantes, parfois appuyées par des moyens considérables. Ce n’est pas nécessairement une question de danger immédiat pour tout le monde, mais cela nécessite une analyse stratégique : il faut que nos outils et nos politiques soient en constante évolution. L’évolution de la cybersécurité dépendra en partie de la façon dont nous régulerons l’utilisation des IA, afin d’éviter qu’elles ne se transforment, précisément, en un nouveau moyen d’attaque.
Et pour terminer sur une note un peu plus légère : si votre script vous demande maintenant un abonnement à Gemini avant d’exécuter une tâche, ne vous inquiétez pas, c’est (souvent) un signe que votre code a essayé de se débrouiller tout seul. À moins que ce ne soit PROMPTFLUX en visite. Dans ce cas, appelez votre SOC.
Si l’article vous a plu et si vous aimez mon travail, vous pouvez faire un don en suivant ce lien :
