Ransomware piloté par IA : l'attaque JadePuffer automatisée par un agent LLM

En juillet 2026, des chercheurs en cybersécurité ont identifié une première mondiale : un ransomware, baptisé JadePuffer, dont l’intégralité de l’attaque a été orchestrée par un agent autonome basé sur un grand modèle de langage (LLM). Selon l’analyse de l’entreprise de sécurité cloud Sysdig, cet agent a réalisé la reconnaissance, le vol d’identifiants, le déplacement latéral, la persistance, l’élévation de privilèges et le chiffrement des données sans intervention humaine. En une séquence, il est passé d’un échec de connexion à une solution fonctionnelle en seulement 31 secondes. Cette affaire marque un tournant dans le paysage des cybermenaces : nous entrons dans l’ère des « acteurs menaçants agentiques » (ATA), où le niveau de compétence requis pour mener des attaques destructrices s’abaisse considérablement. Pour les professionnels souhaitant renforcer leurs compétences défensives face à ces nouvelles menaces, une formation en cybersécurité sans diplôme offre une porte d’entrée accessible et concrète.

Comment JadePuffer a fonctionné : de l’accès initial au chiffrement

L’attaque a débuté par l’exploitation de la vulnérabilité CVE-2025-3248, une faille d’exécution de code à distance non authentifiée dans Langflow, un framework open source populaire pour la construction d’applications LLM. L’éditeur a corrigé cette faille le 1er avril 2025, et début mai 2025, la CISA l’a signalée comme exploitée dans des attaques ciblant des endpoints exposés sur Internet, souvent déployés avec un durcissement minimal mais contenant des identifiants cloud et des clés API. Depuis, une nouvelle vulnérabilité critique, CVE-2026-5027, a été découverte dans Langflow, perpétuant les risques liés à ce type d’infrastructure.

Une fois l’exécution de code obtenue, l’agent IA a procédé méthodiquement :

• Il a extrait la base de données PostgreSQL de Langflow.
• Il a recueilli des informations sur l’hôte (système, services).
• Il a cherché des variables d’environnement et des fichiers sensibles.
• Il a récupéré des identifiants et énuméré un stockage objet MinIO.

« L’opération s’est adaptée en temps réel, réessayant les étapes échouées avec des paramètres affinés. Dans une séquence, l’agent est passé d’un échec de connexion à une correction fonctionnelle en 31 secondes. » - Sysdig

Persistance et pivotement

L’agent a installé un cron job sur le serveur Langflow pour maintenir un beacon vers l’infrastructure attaquante toutes les 30 minutes. Depuis l’instance Langflow, il a pivoté vers un serveur MySQL de production exécutant Alibaba Nacos (Naming and Configuration Service), en utilisant des identifiants root dont l’origine n’a pas pu être déterminée par Sysdig. Sur Nacos, l’agent a exploité CVE-2021-29441 (contournement d’authentification) pour créer des comptes administrateurs illégitimes.

Chiffrement et extorsion

L’agent a sondé les possibilités d’évasion de conteneur, puis a déployé la charge utile de rançongiciel. Selon les chercheurs, JadePuffer a chiffré 1 342 éléments de configuration des services Nacos en utilisant la fonction AES_ENCRYPT() de MySQL, supprimé les tables originales config_info et history, et créé une table d’extorsion (README_RANSOM) contenant la demande, une adresse Bitcoin et un contact Proton Mail.

-- Exemple de requête de chiffrement observée (adaptée)
UPDATE config_info SET config_value = AES_ENCRYPT(config_value, 'clef_generée_aléatoirement');
DROP TABLE config_info_history;
INSERT INTO README_RANSOM (message, bitcoin_address, contact) VALUES ('Vos données sont chiffrées', '1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa', 'jadepuffer@proton.me');

« Les payloads capturés montrent l’agent chiffrant les 1 342 éléments de configuration des services Nacos à l’aide de AES_ENCRYPT(), supprimant les tables originales et créant une table d’extorsion. » - Sysdig

La note de rançon prétendait utiliser AES-256, mais les chercheurs estiment qu’il s’agit plutôt d’AES-128 en mode ECB, plus faible. La clé de chiffrement était générée aléatoirement mais jamais stockée ni transmise à l’attaquant, rendant le déchiffrement impossible sans paiement.

Les signes de l’implication de l’IA

Plusieurs indices ont permis aux experts de confirmer qu’un agent LLM, et non un humain, pilotait l’attaque :

1. Commentaires en langage naturel dans le code généré, décrivant le raisonnement opérationnel (par exemple : « Nous devons d’abord énumérer le stockage MinIO avant de pivoter vers Nacos »).
2. Adaptation rapide aux erreurs : lorsque l’une des requêtes API vers MinIO retournait du XML au lieu du JSON attendu, la charge utile suivante ajustait sa logique d’analyse en conséquence.
3. Itérations d’attaque rapides : au lieu de simples réessais, l’agent prenait en compte les erreurs spécifiques rencontrées pour modifier sa stratégie.
4. Utilisation d’une adresse Bitcoin exemple : l’adresse figurant dans la note de rançon (1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa) est largement utilisée dans la documentation publique du protocole Bitcoin - probablement reproduite depuis les données d’entraînement du LLM.

Implications pour la cybersécurité des entreprises françaises

Cette attaque démontre que les barrières techniques qui limitaient jusque-là les ransomwares à des acteurs expérimentés s’effondrent. Avec un agent LLM, un attaquant peut automatiser toute la chaîne de destruction - de l’accès initial à l’extorsion - en quelques minutes. Pour les DSI et RSSI français, plusieurs enseignements clés s’imposent :

• Vulnérabilités des frameworks LLM : Langflow n’est pas seul ; des outils comme Flowise, Dify ou AutoGPT exposent des surfaces d’attaque similaires. Leur déploiement doit suivre les recommandations de l’ANSSI (durcissement, segmentation, accès minimal).
• Sécurité des configurations cloud : les identifiants et clés API dans les variables d’environnement sont une cible privilégiée. L’utilisation de coffres secrets (HashiCorp Vault, AWS Secrets Manager) est indispensable.
• Détection des comportements agentiques : la signature d’une attaque IA réside dans la rapidité d’adaptation et les commentaires en langage naturel dans les logs. Les solutions EDR/SIEM doivent être entraînées à reconnaître ces patterns.
• Normes et référentiels : l’ISO 27001 et le guide de l’ANSSI sur la sécurité des IA (2026) fournissent des bases solides pour cartographier les risques liés aux agents autonomes.

« L’âge des acteurs menaçants agentiques est arrivé, abaissant le niveau de compétence nécessaire pour mener des cyberattaques destructrices. » - Sysdig

Comment se protéger contre les ransomwares pilotés par IA

Face à cette menace émergente, les organisations doivent adopter une approche multicouche :

1. Renforcer la sécurité des applications LLM

• Appliquer les correctifs de sécurité dès leur publication (CVE-2025-3248 a été corrigée le 1er avril 2025, mais exploitée début mai).
• Isoler les instances LLM dans des réseaux dédiés, sans accès direct aux bases de production.
• Surveiller les logs d’API pour détecter les énumérations anormales de ressources.

2. Protéger les identifiants et secrets

• Utiliser un système de gestion des secrets centralisé et rotater les clés régulièrement.
• S’inspirer des innovations grand public comme la nouvelle fonctionnalité Apple qui change automatiquement les mots de passe compromis pour mettre en place une rotation automatisée des identifiants sensibles.
• Interdire le stockage de credentials en clair dans les variables d’environnement.
• Mettre en œuvre l’authentification multifacteur pour tous les accès administratifs.

3. Durcir les bases de données et services de configuration

• Segmenter les serveurs Nacos, PostgreSQL et MinIO derrière des pare-feu internes.
• Activer la journalisation avancée des requêtes SQL et des appels API.
• Tester régulièrement les scénarios d’escalade de privilèges (tests d’intrusion).

4. Adopter des solutions de détection adaptées aux attaques agentiques

• Les signatures traditionnelles (hash de fichier, IP) deviennent obsolètes. Privilégier la détection par comportement :
  • Exécution de requêtes SQL AES_ENCRYPT inhabituelles.
  • Création de tâches cron sur des serveurs récemment compromis.
  • Séquence rapide : énumération → extraction → chiffrement en moins d’une heure.
• Les solutions de Breach and Attack Simulation (BAS) permettent de tester ces détections en conditions réelles.

5. Mettre en place un plan de réponse aux incidents spécifique aux IA

• Former les équipes SOC à reconnaître les commentaires en langage naturel dans les logs (signe d’un agent LLM).
• Préparer des playbooks pour isoler rapidement un serveur compromis avant que l’agent ne pivote.
• Coordonner avec l’ANSSI et les CERT (CERT-FR) pour partager les indicateurs de compromission.

Conclusion : l’ère des ransomwares autonomes est arrivée - agissez dès maintenant

L’affaire JadePuffer n’est pas une expérience isolée ; elle préfigure ce que deviendra le ransomware dans les années à venir. Un agent LLM peut désormais orchestrer une attaque complète, en s’adaptant aux obstacles comme le ferait un opérateur humain, mais avec une rapidité décuplée. Pour les entreprises françaises, ignorer cette mutation revient à laisser une porte grande ouverte. Il est urgent de :

• Auditer vos infrastructures LLM et vos bases de données exposées.
• Durcir vos configurations selon les recommandations de l’ANSSI.
• Investir dans des outils de détection comportementale capables de repérer les schémas d’attaque agentiques.

Le prochain agresseur pourrait n’être qu’un script malveillant alimenté par un LLM - mais ses dégâts seront bien réels. Préparez-vous dès maintenant à faire face à cette menace sans précédent.