L'attaquant de 31 secondes : ce que la première attaque de ransomware autonome signifie pour la récupération

Quand l'attaquant n'a plus eu besoin d'un humain

Le 1er juillet 2026, la Sysdig Threat Research Team a publié son analyse d'une opération de ransomware qu'elle a baptisée JADEPUFFER. Selon les termes de Sysdig, il s'agit de "what we assess to be the first documented case of agentic ransomware: a complete extortion operation driven end-to-end by a large language model (LLM)." (ce que Sysdig estime être le premier cas documenté de ransomware agentique : une opération d'extorsion complète, menée de bout en bout par un grand modèle de langage, ou LLM).

Il ne s'agit pas d'une énième histoire d'e-mails de phishing rédigés par une IA ou d'appels vocaux truqués par deepfake. Dans les payloads capturés par Sysdig, l'agent a exploité une application exposée sur Internet, collecté des identifiants, rebondi vers un second serveur, pris le contrôle de son service de configuration, chiffré puis supprimé des données, et laissé une demande de rançon. Lorsqu'une étape échouait, il diagnostiquait l'échec et réessayait sans attendre d'instructions.

Chez BackupSec, nous pensons que JADEPUFFER compte moins en tant qu'incident isolé qu'en tant qu'avant-goût. C'est un premier point de données pour une question à laquelle toute architecture de sauvegarde et de récupération devra tôt ou tard répondre : que se passe-t-il lorsque la boucle de décision de l'adversaire passe de quelques heures à quelques secondes ?

Au cœur de la chaîne d'attaque JADEPUFFER

Dans ses grandes lignes, il s'agit d'une kill chain contre laquelle les équipes de sécurité se défendent depuis des années. Sysdig le dit elle-même : "None of the individual techniques were novel or sophisticated." (aucune des techniques prises isolément n'était nouvelle ni sophistiquée). La nouveauté tient à ce qui les a exécutées. La séquence ci-dessous suit le compte rendu de Sysdig :

1. Accès initial. L'agent a exploité la CVE-2025-3248 dans Langflow, un framework open source de création d'applications LLM. La NVD la décrit comme une injection de code dans l'endpoint /api/v1/validate/code qui permet à "a remote and unauthenticated attacker" (un attaquant distant et non authentifié) d'exécuter du code arbitraire, et lui attribue un score CVSS de 9,8. Le correctif a été livré dans Langflow 1.3.0 le 31 mars 2025, et la CISA a ajouté la faille à son catalogue Known Exploited Vulnerabilities le 5 mai 2025. Le correctif existait, il n'avait simplement pas été appliqué.
2. Collecte d'identifiants. Sur l'hôte Langflow, l'agent a énuméré le système et passé l'environnement au peigne fin à la recherche de clés d'API de fournisseurs de LLM, d'identifiants cloud, de portefeuilles de cryptomonnaie et d'identifiants de bases de données, puis a extrait la base Postgres de Langflow elle-même. Il a trouvé un stockage objet MinIO joignable depuis l'hôte, s'y est connecté avec les identifiants par défaut de MinIO (minioadmin:minioadmin) et a listé des buckets qui, selon Sysdig, comprenaient "application data, backups, ML artifacts, and a terraform-state bucket." (des données applicatives, des sauvegardes, des artefacts de ML et un bucket d'état Terraform). Dans l'un d'eux, il a récupéré un fichier credentials.json contenant une paire clé d'accès/secret.
3. Persistance. Il a installé sur l'hôte Langflow une entrée crontab qui contacte l'infrastructure de l'attaquant toutes les 30 minutes.
4. Passage à la véritable cible. D'après Sysdig, la véritable cible de l'opération était un serveur de production distinct, exposé sur Internet, qui faisait tourner MySQL et un service de configuration Alibaba Nacos. L'agent s'est connecté au port MySQL exposé en tant que root. Sysdig n'a pas observé la provenance de ces identifiants root : "Their origin is unknown." (leur origine est inconnue).
5. Prise de contrôle de Nacos. L'agent a attaqué Nacos par plusieurs voies à la fois : la famille de contournements d'authentification de la CVE-2021-29441 (d'après la NVD, dans les versions de Nacos antérieures à 1.4.1, le filtre d'authentification peut être contourné avec un en-tête user-agent usurpé), un JSON Web Token forgé avec la clé de signature par défaut de Nacos, documentée publiquement, et un compte administrateur dérobé écrit directement dans la base de données Nacos grâce à son accès root. La piste JWT a échoué ("custom secret in use", c'est-à-dire qu'un secret personnalisé était utilisé) et a été abandonnée. Le compte dérobé a fonctionné, après la correction en 31 secondes décrite plus bas.
6. Impact. L'agent a chiffré la totalité des 1 342 éléments de configuration Nacos avec la fonction AES_ENCRYPT() de MySQL, supprimé les tables de configuration et d'historique d'origine, puis supprimé des schémas de base de données entiers. La note de rançon affirme un chiffrement AES-256 ; Sysdig souligne que AES_ENCRYPT() utilise par défaut AES-128-ECB, sauf si le serveur a été reconfiguré. Le détail le plus important pour la récupération : la clé a été affichée une seule fois, sans jamais être stockée ni transmise, si bien que, selon les termes de Sysdig, "The victim cannot recover the encrypted configurations even with payment." (la victime ne peut pas récupérer les configurations chiffrées, même en payant). Seule une copie réalisée avant l'attaque, et conservée hors de portée de l'attaquant, pouvait restaurer ces données.
7. Extorsion. Il a créé une table README_RANSOM contenant la demande, une adresse Bitcoin et un contact Proton Mail.

La réserve qui s'impose

Nous tenons à être précis sur ce que signifie « autonome » ici, car l'exagérer affaiblirait l'argument que nous allons développer.

Sysdig cite deux choses qu'elle ne peut pas voir. Elle n'a pas observé comment l'agent a obtenu les identifiants root MySQL utilisés à l'étape quatre. Et elle n'a "no visibility into JADEPUFFER's system prompt or agent configuration" (aucune visibilité sur le prompt système ni sur la configuration de l'agent JADEPUFFER), si bien qu'elle ne peut pas dire quel objectif ni quelles ressources un humain a confiés à l'agent avant son exécution. Quelqu'un l'a construit, configuré et lancé.

Ce que Sysdig documente en revanche, c'est le comportement observé dans les sessions qu'elle a capturées : plus de 600 payloads distincts, du code qui commente son propre raisonnement, et des échecs diagnostiqués et corrigés en quelques secondes. Sur cette base, elle conclut que "the evidence points to an autonomous agent driving the operation rather than a human operator or a fixed toolkit." (les éléments recueillis désignent un agent autonome pilotant l'opération, plutôt qu'un opérateur humain ou une boîte à outils figée).

Cette distinction compte, et nous pensons qu'elle renforce l'argument au lieu de l'affaiblir. Même une chaîne dans laquelle un humain fixe l'objectif et l'agent se charge de l'exécution supprime la principale source de latence d'une opération de ransomware traditionnelle : le temps qu'un opérateur humain passe à réfléchir, à consulter un commanditaire et à décider quoi tenter ensuite.

Pourquoi 31 secondes, c'est plus grave qu'il n'y paraît

Les 31 secondes ne correspondent pas à la durée totale de l'attaque. Sysdig ne publie pas de durée de bout en bout pour la chaîne, et nous nous garderons délibérément d'en inventer une. Ce qu'elle publie, c'est une séquence horodatée tirée de la prise de contrôle de Nacos. L'agent a inséré son compte administrateur dérobé, a tenté de se connecter à 19:34:36 UTC et a échoué. Il a testé deux causes possibles en parallèle, puis à 19:35:07 a envoyé un payload correctif de 15 lignes qui a reconstruit le compte correctement. La connexion a réussi à 19:35:18. Selon les termes de Sysdig : "The window between the failed login and the correct multi-step fix is 31 seconds." (l'intervalle entre l'échec de connexion et la correction multi-étapes réussie est de 31 secondes). Sysdig rapporte le même schéma ailleurs dans la session. Quand une requête a renvoyé du XML au lieu de JSON, le payload suivant analysait du XML. Quand un DROP DATABASE a échoué sur une contrainte de clé étrangère, le suivant désactivait d'abord la vérification.

Comparez avec le comportement d'un opérateur humain lorsqu'une étape échoue. Il marque une pause. Il réévalue. Dans une opération structurée de ransomware-as-a-service, il peut envoyer un message à un commanditaire et attendre des consignes. Il réessaie dans un délai qui se compte en minutes ou en heures, parfois après un changement d'équipe. Cette latence, l'écart entre un échec et la tentative suivante, a toujours été l'un des rares éléments jouant en faveur des défenseurs. C'est ce qui permet qu'une alerte de 2 h du matin puisse encore être triée par un humain à 8 h sans que l'incident se soit forcément aggravé de façon spectaculaire entre-temps.

Un agent qui réduit cet écart à 31 secondes ne va pas seulement plus vite. Il fait tomber l'hypothèse inscrite dans presque tous les runbooks de réponse aux incidents : qu'il existe une fenêtre à l'échelle humaine entre la première tentative ratée d'un attaquant et la suivante, et qu'un processus de détection et de réponse fonctionnant à une échelle de temps humaine comparable peut raisonnablement espérer intervenir dans cette fenêtre.

Des chiffres déjà vrais avant l'arrivée de l'IA

L'infrastructure de sauvegarde n'est pas devenue une cible à cause de l'IA agentique. Elle l'était déjà, et les données sur le sujet précèdent JADEPUFFER de deux ans.

• Le 2024 Ransomware Trends Report de Veeam, une enquête menée auprès de 1 200 répondants issus d'organisations ayant subi au moins une attaque de ransomware en 2023, a établi que "backup repositories are targeted in 96% of attacks, with bad actors successfully affecting the backup repositories in 76% of cases." (les référentiels de sauvegarde sont ciblés dans 96 % des attaques, et les attaquants parviennent à les atteindre dans 76 % des cas). Veeam reprend le chiffre de 96 % sur son propre blog.
• L'étude de Sophos de 2024 sur les sauvegardes compromises, fondée sur 2 974 professionnels de l'IT et de la cybersécurité dont l'organisation avait été touchée par un ransomware au cours de l'année précédente, a établi que "The median overall ransomware recovery costs for organizations whose backups were compromised ($3M) came in eight times higher than that of organizations whose backups were not impacted ($375K)." (le coût global médian de récupération après ransomware des organisations dont les sauvegardes avaient été compromises, 3 M$, était huit fois supérieur à celui des organisations dont les sauvegardes n'avaient pas été touchées, 375 000 $).

Ces chiffres décrivent un monde d'attaquants humains qui avaient déjà compris que détruire ou chiffrer la couche de sauvegarde est le levier le plus puissant dont dispose une opération de ransomware une fois qu'elle a pris pied. L'IA agentique ne change rien à ce calcul. Ce qu'elle change, c'est qui, ou quoi, peut l'exécuter à grande échelle, jour et nuit, sans avoir besoin de dormir, de faire une pause entre deux équipes ou d'attendre l'accord d'un commanditaire avant d'essayer l'identifiant suivant.

L'IBM 2026 X-Force Threat Intelligence Index apporte la tendance. IBM X-Force a observé une hausse de 44 % des attaques ayant commencé par l'exploitation d'applications exposées publiquement, soit exactement le vecteur d'entrée utilisé par JADEPUFFER, et le nombre de groupes de ransomware et d'extorsion actifs a augmenté de 49 % sur un an. La surface d'attaque s'étendait déjà avant d'avoir besoin d'un opérateur autonome.

Des fenêtres de détection à la certitude de récupération

L'exploitation d'une vulnérabilité connue est déjà la porte d'entrée la plus courante. Le même rapport d'IBM indique que l'exploitation de vulnérabilités "became the leading cause of attacks, accounting for 40% of incidents observed by X-Force in 2025." (est devenue la première cause d'attaques, représentant 40 % des incidents observés par X-Force en 2025). L'écart entre les vulnérabilités connues et les vulnérabilités corrigées est trop grand, et se renouvelle trop continuellement, pour qu'une prévention parfaite soit réaliste. JADEPUFFER s'inscrit dans ce schéma : Sysdig note que l'attaque contre la véritable cible "leaned on years-old issues, a 2021 Nacos auth-bypass and an unchanged default signing key." (s'est appuyée sur des problèmes vieux de plusieurs années, un contournement d'authentification Nacos de 2021 et une clé de signature par défaut jamais modifiée). JADEPUFFER ne change pas cet argument. Il l'affûte.

Si l'hypothèse de travail du secteur a été qu'un processus de détection et de réponse au rythme humain peut raisonnablement espérer intercepter une intrusion quelque part entre l'accès initial et un impact irréversible, un agent qui se corrige en 31 secondes remet directement en cause cette hypothèse. La réponse ne peut pas être « détecter et répondre plus vite qu'une machine », car ce n'est pas une course que les défenseurs peuvent espérer gagner indéfiniment. La réponse doit être architecturale : rendre l'issue d'une intrusion rapide et adaptative survivable, quelle que soit l'accélération de l'attaquant.

Concrètement, les propriétés qui comptent pour l'infrastructure de sauvegarde et de récupération ne changent pas parce que l'attaquant est un agent d'IA plutôt qu'un humain. Elles deviennent non négociables au lieu d'être des aspirations :

• Une séparation des identifiants et des identités qui ne dépend pas d'un humain remarquant à temps une activité inhabituelle. Si les identifiants qui donnent accès à votre environnement de sauvegarde sont les mêmes qu'un agent peut récolter en quelques secondes sur un hôte compromis, l'isolation doit être structurelle, et non procédurale.
• Une immuabilité validée, et pas seulement configurée. Un verrou de rétention qu'un identifiant suffisamment privilégié peut désactiver discrètement est un contrôle qui suppose qu'un attaquant humain hésitera. Un agent, lui, n'hésitera pas.
• Des tests de récupération qui partent du principe que l'attaquant connaît déjà votre environnement. L'agent de JADEPUFFER s'est adapté en temps réel aux étapes ratées. Un plan de récupération qui n'a jamais été testé que face à un seul scénario de défaillance attendu est un plan conçu pour un adversaire plus lent et plus prévisible que celui dont on vient de démontrer l'existence possible.

Ce que cela signifie pour les responsables des risques en entreprise

JADEPUFFER est une campagne documentée, pas la preuve que toutes les opérations de ransomware sont désormais autonomes. Mais si l'évaluation de Sysdig se confirme, quelque chose qui relevait jusqu'ici de la théorie a désormais été observé : un agent LLM menant une véritable chaîne d'attaque contre une véritable cible, avec une boucle d'autocorrection qui se mesure en secondes.

Pour les responsables des risques, la question pratique n'est plus de savoir si le ransomware agentique va se répandre. Sysdig indique que les défenseurs "should expect the volume and breadth of such campaigns to rise as agentic tooling matures," (doivent s'attendre à ce que le volume et l'étendue de ces campagnes augmentent à mesure que l'outillage agentique mûrit), et IBM X-Force "expects adversaries to automate complex tasks like reconnaissance and advanced ransomware attacks." (s'attend à ce que les adversaires automatisent des tâches complexes comme la reconnaissance et les attaques de ransomware avancées). La question pratique est de savoir si les hypothèses de votre architecture de récupération ont été conçues pour un adversaire au rythme humain, ou pour un adversaire qui n'a plus besoin de l'être.

Où intervient BackupSec

Chez BackupSec, nous avons construit notre approche autour d'un principe que JADEPUFFER rend plus urgent : la prévention finira par échouer, et la couche qui décide de l'issue est celle qui est conçue pour survivre à cet échec, quelle que soit la vitesse de ce qui l'a provoqué.

• ZeroMON surveille Veeam Backup & Replication. Il se déploie sur site sous forme d'OVA, se connecte avec un compte en lecture seule et n'envoie rien à BackupSec ni à aucun tiers. Il suit l'état des tâches de sauvegarde, journalise les modifications de configuration dans Veeam (qui a changé quoi, et quand), affiche l'état d'immuabilité tel que le rapportent les paramètres des référentiels de Veeam lui-même, et garde en vue la checklist du Security Analyzer de Veeam. Ses règles d'alerte couvrent les actions qu'un intrus mène côté Veeam contre les sauvegardes, comme les modifications d'identifiants, les changements de rétention et de planification, les tâches désactivées et les sessions de suppression. Les alertes sont envoyées par e-mail et par notification dans l'application. ZeroMON surveille Veeam : il ne voit pas la collecte d'identifiants sur d'autres hôtes, et il lit les paramètres d'immuabilité de Veeam au lieu de vérifier les verrous sur le stockage lui-même.
• ZeroTAM met à la disposition de votre équipe un conseiller dédié à la sécurité des sauvegardes : revue d'architecture, planification de la récupération après ransomware, capacité, et support prioritaire en cas de crise. C'est là que vous pouvez mettre à l'épreuve la question de savoir si votre séparation des identités, votre immuabilité et votre isolation ont été conçues pour un attaquant au rythme humain.
• ZeroPEN est un test d'intrusion guidé par la menace, portant sur Veeam Backup & Replication, Veeam ONE et Enterprise Manager. Il simule une kill chain de ransomware en huit étapes alignées sur MITRE ATT&CK, de l'accès initial et de l'abus d'identifiants jusqu'à l'accès aux référentiels et à la neutralisation des sauvegardes, puis à une preuve de capacité de chiffrement. La mission inclut une vérification de l'intégrité des restaurations et de l'immuabilité, et fournit des preuves prêtes pour l'audit, avec un nouveau test pour les constats critiques. Elle est non destructive : ZeroPEN "never deletes real backups, performs real encryption, or stops production or backup services." (ne supprime jamais de vraies sauvegardes, n'effectue aucun chiffrement réel et n'arrête ni les services de production ni les services de sauvegarde).

La question que soulève JADEPUFFER n'est pas de savoir si vos défenses sont rapides. C'est de savoir si votre architecture de récupération a été conçue pour ne pas dépendre de leur rapidité.

Parlez à BackupSec de la validation de votre architecture de récupération →

Cette analyse s'appuie sur l'étude de Sysdig de juillet 2026 sur JADEPUFFER, sur l'IBM 2026 X-Force Threat Intelligence Index, sur le 2024 Ransomware Trends Report de Veeam et sur l'étude de Sophos de 2024 sur les sauvegardes compromises, avec des détails sur les vulnérabilités issus de la NVD et de la CISA. L'interprétation et le cadre présentés ici sont ceux de BackupSec. Pour voir comment cette analyse s'applique à votre environnement, contactez notre équipe →