Points clés à retenir
- « JadePuffer » est le nom que les chercheurs en sécurité de Sysdig ont donné à ce qu’ils ont identifié comme la première opération de type « ransomware » documentée, menée de bout en bout par un agent IA autonome, et non par un humain utilisant une boîte à outils.
- Les techniques utilisées n’étaient pas nouvelles. Ce qui a changé, c’est la rapidité d’exécution : l’agent a enchaîné les phases de reconnaissance, de vol d’identifiants, de déplacement latéral et de chiffrement destructeur, parvenant à corriger une tentative de connexion infructueuse en 31 secondes.
- L’agent a généré sa propre clé de chiffrement, qu’il n’a ensuite ni stockée ni transmise. Le paiement de la rançon n’aurait pas permis de récupérer les données.
- Les dommages réels ont porté sur l’état de configuration et les systèmes du plan de contrôle, et pas seulement sur les fichiers, ce qui correspond précisément à la couche que la plupart des plans de reprise ne couvrent pas.
- Se remettre d’une attaque de ce type implique de démontrer que l’entreprise est en mesure de reprendre ses activités en toute sécurité, et pas seulement de restaurer une sauvegarde.
Que s’est-il passé ?
Au milieu de l’année 2026, des chercheurs en sécurité de Sysdig ont mis au jour une campagne de chantage qu’ils estiment être la première du genre : une opération de « ransomware » menée de bout en bout par un agent basé sur un grand modèle linguistique, avec une intervention humaine minimale au clavier. Ils l’ont baptisée « JadePuffer ».
Le point d’entrée était bien connu. L’attaquant a exploité la vulnérabilité CVE-2025-3248, une faille permettant l’exécution de code à distance sans authentification dans Langflow, un framework open source destiné à la création de workflows d’agents d’IA, dont la version était antérieure à la 1.3.0. À partir de là, l’agent a procédé à l’énumération de l’hôte, a recherché des identifiants auprès de fournisseurs de cloud, de fournisseurs de modèles d’IA et de bases de données, puis a discrètement copié la base de données interne de la plateforme.
Ce qui s’est passé ensuite mérite particulièrement notre attention. L’agent a analysé le réseau interne, a trouvé un magasin d’objets exposé et a extrait les fichiers d’état et de configuration de Terraform. Il a mis en place une tâche planifiée pour communiquer avec son serveur de commande toutes les 30 minutes. Il s’est ensuite tourné vers un système de production distinct exécutant MySQL et Alibaba Nacos, une plateforme de configuration et de découverte de services couramment utilisée dans les architectures de microservices.
Une fois à l’intérieur, l’agent a tenté de créer un compte administrateur dans Nacos. L’opération a échoué. Trente et une secondes plus tard, il avait identifié la cause de l’échec et réussi à atteindre son objectif en adoptant une approche différente. Il a ensuite utilisé les fonctions de gestion de fichiers de MySQL pour vérifier s’il pouvait aller plus loin, avant de chiffrer plus de 1 300 enregistrements de configuration, de supprimer les tables d’origine et de laisser une demande de rançon.
La clé de chiffrement a été générée à la volée, affichée une seule fois, et n’a jamais été stockée à un endroit où l’attaquant aurait pu la récupérer. Que cela ait été intentionnel ou non, le résultat pour la victime est le même : il n’y avait aucun moyen de revenir en arrière via l’attaquant ou une clé de déchiffrement, que la rançon ait été payée ou non. La restauration dépendrait de sauvegardes intactes, d’une reconstruction du système ou de points de restauration validés.
Pourquoi les chercheurs qualifient-ils cela d’« agentique » ?
Aucune des techniques décrites ici n’est nouvelle. Exploiter une vulnérabilité CVE non corrigée, collecter des identifiants, rechercher des possibilités de déplacement latéral, chiffrer des données à des fins d’extorsion : les équipes de sécurité ont déjà rencontré chacune de ces techniques. Ce qui a conduit Sysdig à classer cet opérateur comme un « agent » plutôt que comme un attaquant classique, c’est la manière dont ces différentes étapes s’articulent entre elles.
L’agent ne suivait pas de scénario prédéfini. Il analysait les résultats et s’adaptait en conséquence. Lorsqu’il s’attendait à recevoir une réponse au format JSON et qu’il obtenait du XML à la place, il modifiait son approche et poursuivait son exécution. Lorsque sa première tentative de création d’un compte administrateur a échoué, il a identifié la cause précise de l’échec et a essayé une autre approche, le tout en moins d’une minute.
Les chercheurs ont également découvert des commentaires intégrés dans les charges utiles, expliquant les cibles et les étapes suivantes dans un langage simple, un schéma qui correspond davantage au raisonnement d’un modèle de langage à grande échelle (LLM) effectuant une tâche qu’à celui d’un humain copiant-collant un kit d’exploitation connu. Les informations rendues publiques n’ont pas permis de confirmer quel modèle ou quelle « plateforme » était à l’origine de l’attaque. Ce qui est confirmé, c’est son comportement : une entité a raisonné, agi, s’est heurtée à un obstacle et a corrigé sa trajectoire plus rapidement que ne le permettent la plupart des interventions humaines en cas d’incident.
Le problème de la restauration que trop de cadres de référence négligent encore
La plupart des guides de gestion des incidents liés aux ransomwares reposent sur une hypothèse précise : vos fichiers ont été chiffrés, et la question est de savoir si vous pouvez restaurer une sauvegarde intacte ou si vous devez négocier une clé de déchiffrement.
JadePuffer remet en cause cette hypothèse de deux manières. Premièrement, il n’y avait aucune clé de déchiffrement à négocier. Deuxièmement, les dégâts ne se limitaient pas aux données. Ils concernaient également la couche de configuration et de contrôle sous-jacente aux données : la plateforme de découverte de services, les secrets qu’elle contenait, l’état Terraform décrivant l’architecture de l’infrastructure, ainsi que les identifiants dispersés sur tous les systèmes que l’agent a touchés en chemin.
Il s’agit d’un problème de restauration plus complexe qu’une simple « restauration de la base de données ». Une restauration « propre » des fichiers dans un environnement où les identifiants ont été renouvelés mais n’ont pas été vérifiés, où les dérives de configuration n’ont pas été examinées et où la couche d’identité n’a fait l’objet d’aucun nouvel audit ne constitue pas vraiment une restauration « propre ». Il s’agit simplement d’une nouvelle copie des données stockée dans un système qui ne peut toujours pas être considéré comme fiable.
Ce que cela implique pour votre stratégie de résilience
JadePuffer offre un aperçu de la question à laquelle tout plan de reprise devra tôt ou tard répondre : est-il possible de reprendre ses activités lorsqu’un attaquant a compromis non seulement vos données, mais aussi les systèmes d’identité, de configuration et de contrôle dont ces données dépendent ?
Quelques pistes pour commencer :
Considérez les systèmes de configuration et de contrôle comme essentiels à la Recovery, et pas seulement les applications. Les plateformes de découverte de services, les référentiels de secrets et l’état de l’infrastructure en tant que code sont tout aussi critiques pour l’entreprise que les bases de données qu’ils configurent. S’ils ne figurent pas encore dans votre plan de Recovery, c’est la première lacune à combler.
Intégrez la gestion des identifiants dès la phase de restauration, et non après. La restauration d’une charge de travail qui réintroduit des identifiants compromis ne met pas fin à l’incident ; elle remet le compteur à zéro. C’est cette même approche que Commvault applique aujourd’hui à l’infrastructure d’identité : une évaluation des vulnérabilités pour détecter les failles avant qu’un attaquant ne le fasse, un audit en temps réel pour repérer les modifications au fur et à mesure qu’elles se produisent, et une restauration en arrière pour annuler les modifications non autorisées sans avoir à tout reconstruire à partir de zéro.
Validez avant la restauration, pas après. Un point de restauration n’est utile que si vous êtes certain qu’il est « propre ». C’est le principe sur lequel repose Commvault Cleanroom™ : tester et valider les données dans un environnement isolé avant qu’elles ne rejoignent à nouveau l’environnement de production, plutôt que de s’en rendre compte après une réinfection.
Préparez-vous à une compromission du plan de contrôle, et pas seulement à un simple cas de chiffrement de fichiers. Une feuille de route de reprise conçue uniquement pour le scénario « fichiers chiffrés, restauration à partir d’une sauvegarde » ne tiendra pas la route face à un incident de ce type. La question la plus pertinente, et celle qui est au cœur des ResOps (opérations de résilience) en tant que discipline opérationnelle, est de savoir ce qu’il faut pour atteindre un niveau minimal de fonctionnement viable lorsque ce sont les systèmes sous-jacents à vos applications qui ont été touchés.
Rien de tout cela n’implique de considérer l’IA agentique comme une menace sans précédent qui nécessiterait de repartir de zéro. Il s’agit plutôt d’étendre la même approche axée sur la résilience, qui s’applique déjà à l’identité et aux données, jusqu’à la couche de configuration et de contrôle que les attaques agentiques ciblent désormais directement. Découvrez comment Commvault aborde la résilience des identités et la validation d’une restauration propre.
FAQ
Q : Qu’est-ce que JadePuffer ? R : « JadePuffer » est le nom donné par Sysdig à ce qu’elle a identifié comme la première campagne de rançongiciel documentée, menée de bout en bout par un agent d’IA autonome, plutôt que par un attaquant humain utilisant manuellement une boîte à outils.
Q : Les pirates ont-ils utilisé un modèle d’IA spécifique, comme ChatGPT ou Claude ? R : Les informations rendues publiques n’ont pas permis de confirmer quel modèle ou quelle « plateforme » a été utilisé(e). L’agent a recherché des clés API provenant de plusieurs fournisseurs d’IA, ce qui témoigne d’un intérêt pour ce type d’accès, mais ne permet pas d’identifier ce qui a servi de base à l’attaque elle-même. Q : Comment l’attaque a-t-elle commencé ?
R : La vulnérabilité CVE-2025-3248, qui permet l’exécution de code à distance sans authentification dans Langflow, un framework open source d’agents d’IA, affecte les versions antérieures à la version 1.3.0. Q : La victime aurait-elle pu payer la rançon pour récupérer ses données ? R : Non. La clé de chiffrement a été générée à la volée et n’a jamais été stockée ni transmise ; il n’y avait donc aucune clé à récupérer, quel que soit le montant du paiement.
Q : En quoi cela diffère-t-il d’un « ransomware » classique ? R : Les techniques utilisées n’étaient pas nouvelles. Ce qui a retenu l’attention, c’est la rapidité et la capacité d’adaptation : l’agent a détecté une tentative de connexion infructueuse et l’a corrigée en 31 secondes, un rythme plus proche de celui d’une machine que du comportement habituel d’un attaquant agissant à un rythme humain. Q : Quels enseignements les équipes chargées de la sécurité et de la reprise après sinistre doivent-elles en tirer ?
R : Cette planification de la reprise doit aller au-delà des données applicatives pour englober les référentiels de configuration, les plateformes de découverte de services, les secrets et les systèmes d’identité, c’est-à-dire la couche que JadePuffer a précisément ciblée pour causer un maximum de dégâts. Chris Bevil est responsable principal du marketing de portefeuille chez Commvault.