Pendant des années, on a utilisé l’IA pour défendre, en effectuant:

  • Détection
  • Classification
  • Priorisation des alertes
  • Aide à l’investigation
  • Résumé d’incident
  • Génération de règles

Puis, progressivement, on l’a vue apparaître côté offensif:

  • Rédaction de phishing
  • Génération de scripts
  • Aide au développement de malware
  • Traduction de payloads
  • Automatisation de reconnaissance

Mais dans la plupart des cas, l’humain restait au centre: Il décidait, il corrigeait, il relançait et il choisissait la prochaine étape.

Puis Sysdig a publié son analyse sur JADEPUFFER.

Ma première réaction a été assez simple :

Encore un titre sensationnaliste sur l’IA…

Puis j’ai lu le rapport… Et ce qui m’a marqué, ce n’est pas vraiment l’attaque elle-même, ce qui m’a marqué, c’est ce qu’elle révèle.

Avant d’aller plus loin, une précision importante : dans cet article, je vais volontairement distinguer deux choses.

D’un côté, ce que l’on sait, sur la base des éléments publiés par Sysdig, NVD, CISA et d’autres sources techniques.

De l’autre, mon analyse, en tant que praticien SOC qui passe une bonne partie de son temps à travailler avec des SIEM, des règles de détection, des playbooks et des processus de réponse.

Parce que les faits sont déjà intéressants, mais les conséquences possibles le sont encore davantage.

1. Ce que l’on sait réellement

Selon Sysdig, JADEPUFFER est ce qu’ils évaluent comme le premier cas documenté de ransomware agentique : une opération d’extorsion conduite de bout en bout par un agent basé sur un LLM. Le point important est la nuance : Sysdig parle d’une évaluation basée sur leurs observations, pas d’une certitude absolue sur toute la configuration de l’agent ou sur l’absence totale d’un humain derrière.

L’attaque commence par l’exploitation d’une vulnérabilité connue dans Langflow, identifiée comme CVE-2025-3248. Cette faille affecte les versions de Langflow antérieures à 1.3.0 et permet à un attaquant distant non authentifié d’exécuter du code arbitraire via l’endpoint /api/v1/validate/code. La vulnérabilité est classée critique avec un score CVSS 9.8.

Langflow n’est pas un détail anodin ici. C’est un framework open source permettant de construire des applications et workflows autour de LLM. Autrement dit, on parle d’un outil conçu pour orchestrer des flux d’IA, souvent connecté à des clés API, des credentials cloud ou des services internes. Sysdig souligne justement que ces serveurs sont attractifs parce qu’ils sont “AI-adjacent” et peuvent contenir des secrets sensibles dans leur environnement.

Une fois l’accès obtenu, Sysdig décrit une chaîne d’attaque comprenant plusieurs phases :

Les payloads observés étaient livrés sous forme de Python encodé en Base64 via l’endpoint RCE de Langflow. Sysdig mentionne plus de 600 payloads distincts et intentionnels dans une fenêtre compressée, ce qui soutient leur hypothèse d’une opération pilotée par agent plutôt que par un humain au clavier ou un simple script figé.

Le détail le plus étrange concerne la clé de chiffrement.

L’agent aurait généré une clé aléatoire, l’aurait affichée une fois, puis ne l’aurait ni stockée ni envoyée. Résultat : les données chiffrées deviennent probablement irrécupérables, même si la victime paye. Sysdig précise également que l’affirmation d’exfiltration venait du commentaire généré dans le code de l’agent, mais n’a pas été vérifiée indépendamment.

En clair : ce n’est pas seulement un ransomware, c’est un ransomware qui, accidentellement, se comporte comme un wiper.

2. Ce que JADEPUFFER n’est pas

Il faut éviter de raconter n’importe quoi. JADEPUFFER n’est pas la preuve que “l’IA pense” comme un humain. Ce n’est pas non plus la preuve que les attaquants humains ont disparu. Ce n’est pas une attaque révolutionnaire par ses techniques individuelles.

Sysdig le dit explicitement :

Les techniques observées ne sont ni nouvelles ni particulièrement sophistiquées. Ce qui est nouveau, c’est qu’un modèle a été capable de les enchaîner dans une opération complète, contre une infrastructure négligée et exposée.

Et c’est précisément là que ça devient intéressant, parce que pendant très longtemps, on a évalué la sophistication d’une attaque à travers les techniques utilisées.

Est-ce que l’attaquant utilise un exploit zero-day ?
Est-ce qu’il utilise un malware custom ?
Est-ce qu’il contourne l’EDR ?
Est-ce qu’il fait du living-off-the-land avancé ?
Est-ce qu’il exfiltre discrètement sur plusieurs semaines ?

Ici, ce n’est pas vraiment ça. La nouveauté n’est pas dans la technique, elle est dans l’orchestration.

3. L’attaque ne change pas. Le rythme, oui.

Rien de tout cela n’est nouveau:

Conti faisait déjà ça.
LockBit faisait déjà ça.
BlackCat faisait déjà ça.
Des groupes humains très organisés le faisaient depuis des années.

Mais avant, même lorsqu’un groupe était très bon, il y avait une réalité physique derrière l’opération : des humains. Des humains qui travaillent, qui lisent les résultats, qui hésitent, qui changent de stratégie, des humains qui font des pauses.

Nos défenses se sont construites autour de cette réalité, même si on ne le dit pas toujours, une grande partie de notre modèle SOC repose sur une hypothèse implicite : L’attaquant est rapide, mais il reste humain.

Et c’est peut-être cette hypothèse qui commence à casser.

Dans JADEPUFFER, Sysdig observe une adaptation en temps réel. Dans une séquence, l’agent passe d’un login échoué à une correction fonctionnelle en 31 secondes. Ce n’est pas simplement “rapide”. C’est une boucle d’essai, d’erreur, d’analyse et de correction à une vitesse qui met en difficulté nos processus humains.

Et c’est là que le sujet devient beaucoup plus sérieux, parce que le problème n’est pas seulement : une IA peut attaquer, le problème est : une IA peut attaquer plus vite que nos processus humains de défense.

4. Le temps humain devient une vulnérabilité

Dans un SOC mature, une alerte critique suit souvent un processus raisonnable.

Une alerte arrive → Un analyste la qualifie → Il cherche le contexte → Il regarde l’asset → Il vérifie l’utilisateur → Il corrèle avec d’autres événements → Il escalade si nécessaire → Un senior ou un incident handler confirme → Quelqu’un décide du containment → Puis seulement l’action démarre.

Et honnêtement, c’est normal.

On ne veut pas isoler un serveur de production sur un faux positif.
On ne veut pas désactiver un compte critique sans validation.
On ne veut pas casser un service client parce qu’un signal est mal interprété.

Donc on met de l’humain dans la boucle: c’est prudent, professionnel et responsable, mais face à un agent autonome qui enchaîne reconnaissance, exploitation, recherche de secrets, pivot et chiffrement, cette prudence devient aussi une faiblesse.

Pas parce que les analystes sont mauvais ni parce que les processus sont inutiles, mais parce qu’ils ont été conçus pour un adversaire humain.
Une attaque automatisée ne respecte pas nos délais d’escalade, elle ne s’arrête pas pendant qu’on ouvre un ticket, elle ne ralentit pas parce qu’un manager n’est pas disponible, elle ne dort pas.

Et c’est peut-être ça, le vrai changement, ce n’est pas seulement que l’attaquant va plus vite, c’est que notre temps de réaction devient une surface d’attaque.

5. Les signatures ne disparaissent pas. Elles perdent de la valeur relative.

Il serait faux de dire que les IoC, les signatures, YARA ou les détections classiques deviennent inutiles.

Ils restent utiles.

Ils continueront à détecter une énorme partie des menaces.
Ils resteront indispensables pour la chasse, le triage, l’attribution partielle, le blocage réseau, l’enrichissement CTI.

Mais ils ne suffisent plus.

Dans un monde où un agent peut générer du code unique, adapter ses payloads, commenter ses propres actions et modifier sa stratégie selon les erreurs rencontrées, une défense centrée uniquement sur l’artefact arrive trop tard.

Un hash est publié après l’attaque.
Un IoC est utile après observation.
Une règle sur un outil connu fonctionne si l’outil est réutilisé.

Mais si le payload est généré à la volée, adapté à l’environnement, puis supprimé, la valeur de la signature baisse.

La question devient alors :

Est-ce que je détecte l’outil, ou est-ce que je détecte l’intention ?

Un processus qui énumère massivement les variables d’environnement.
Un service d’orchestration IA qui lit des secrets.
Un container qui tente d’accéder à MinIO avec des credentials par défaut.
Un workload exposé qui scanne soudainement l’espace interne.
Une application IA qui établit une persistence cron.
Un serveur applicatif qui touche des bases de production qu’il ne devrait jamais voir.

Ce changement implique aussi une évolution de notre manière de construire les détections. Pendant longtemps, nous avons cherché des outils ou des indicateurs de compromission.

Demain, il faudra surtout détecter des intentions.

Ne plus seulement chercher Mimikatz, mais toute tentative de Credential Access. Ne plus seulement détecter vssadmin delete shadows, mais toute tentative de destruction des mécanismes de restauration. Ne plus seulement bloquer une adresse IP connue, mais identifier un système qui agit soudainement en dehors de son rôle normal.

6. Ce que ça change pour Microsoft Sentinel, Splunk, EDR et SOAR

Dans mon équipe, on passe beaucoup de temps dans Microsoft Sentinel: Règles analytiques natives, Custom Analytics Rules, règles par client, hunting queries, playbooks, corrélations, workbooks, tuning etc…

Et ce que JADEPUFFER illustre très bien, c’est que le SOC ne peut plus se contenter d’empiler des règles isolées.

Une règle qui dit ProcessCommandLine has "procdump" peut être utile, mais elle ne suffit pas contre un agent qui peut écrire son propre code.

Le vrai enjeu est de corréler.

Par exemple :

  • Exploitation d’une application exposée
  • Exécution de Python anormale
  • Accès à des variables d’environnement
  • Lecture de fichiers .env, credentials.json, config.yaml
  • Connexion à des services internes depuis un host qui ne devrait pas y accéder
  • Création d’un cron ou d’une tâche persistante
  • Accès à une base de données sensible
  • Modification ou suppression massive de données

Pris isolément, chaque signal peut être faible, mais ensemble, ils racontent une histoire. Et c’est exactement ce que doit faire un SIEM moderne.

Sentinel, Splunk ou d’autres plateformes ne doivent pas seulement “détecter une commande”, ils doivent aider à reconstruire une intention et dans ce contexte, les règles les plus utiles ne sont pas forcément les plus spectaculaires, ce sont celles qui détectent les transitions anormales :

  • Un outil d’IA exposé qui devient point d’entrée
  • Un serveur applicatif qui devient outil de reconnaissance
  • Un compte technique qui devient acteur d’administration
  • Un container qui devient pivot réseau
  • Une application qui devient opérateur offensif

7. La réponse automatisée n’est plus un luxe

Si l’attaque se déroule à vitesse machine, la première réponse doit aussi pouvoir se déclencher à vitesse machine. Cela ne veut pas dire qu’il faut tout automatiser aveuglément, c’est même dangereux, mais cela veut dire qu’il faut distinguer deux niveaux.

D’un côté, les actions à faible risque : Enrichir une alerte, créer un ticket, notifier une équipe, capturer un snapshot, récupérer les processus actifs, collecter les connexions réseau, sauvegarder les logs volatils et augmenter la sévérité si plusieurs signaux convergent.

De l’autre, les actions à fort impact : Isoler un endpoint, désactiver un compte, révoquer une clé

  • Bloquer un flux réseau
  • Couper un service
  • Supprimer une session

Ces actions peuvent nécessiter validation humaine, mais dans certains scénarios, attendre est plus risqué qu’agir, c’est là que le SOAR devient stratégique. Pas comme gadget, pas comme “outil de confort”, mais comme mécanisme permettant de réduire le délai entre la détection et le containment.

La vraie question pour un CISO devient :

Quelles actions suis-je prêt à automatiser si l’attaque progresse plus vite que mon équipe ?

Ce n’est pas une question technique.
C’est une question de gouvernance.

8. Langflow est important. Mais Langflow n’est pas le sujet.

CVE-2025-3248 doit être patchée, les instances Langflow exposées doivent être inventoriées, les endpoints capables d’exécuter du code ne devraient pas être accessibles depuis Internet, les secrets ne devraient pas être présents en clair dans l’environnement d’un outil web exposé…

Tout cela est vrai, mais si on s’arrête à Langflow, on rate le message, car le vrai sujet est plus large :

Nous déployons de plus en plus de plateformes capables d’orchestrer du code, des données, des identités et des actions.

Langflow en est un exemple, mais on pourrait parler de n8n, d’Airflow, de GitHub Actions, de GitLab CI/CD, de Jenkins, de Kubernetes Operators, de MCP servers, l’agents IA internes, d’orchestrateurs cloud, de plateformes low-code, de notebooks partagés, d’outils d’automatisation IT, de pipelines de data ou de systèmes de déploiement.

Ces outils ont un point commun : ils sont puissants parce qu’ils automatisent, et c’est exactement pour cette raison qu’ils deviennent dangereux lorsqu’ils sont compromis.

Un outil d’orchestration, ce n’est pas “juste une application”, c’est souvent un point de concentration : de secrets, de permissions, de connecteurs, de chemins réseau, de logique métier et d’accès à la production.

Demain, ces plateformes pourraient devenir les nouveaux Domain Controllers, pas parce qu’elles remplacent Active Directory, mais parce qu’elles concentrent le pouvoir opérationnel. Et un attaquant agentique cherchera naturellement ces points de levier.

9. La souveraineté numérique : pas une garantie, mais une question de contrôle

Il y a aussi une dimension plus large: Langflow est open source.
Beaucoup d’outils critiques le sont: Kubernetes, Airflow, Terraform, TensorFlow, n8n, Jenkins et tant d’autres. L’open source est une force immense, mais l’open source ne signifie pas automatiquement “audité”, “sécurisé”, “gouverné”, “responsable”.

Une faille critique peut exister dans un outil largement utilisé, elle peut être corrigée puis rester exploitable pendant des mois sur des instances non patchées. C’est exactement ce que montre CVE-2025-3248 : la faille était connue, corrigée dans Langflow 1.3.0, ajoutée au catalogue KEV de CISA en mai 2025 et pourtant encore exploitable sur des systèmes négligés.

La souveraineté (on en parle un peu ces temps 🙂 ) ne veut pas dire “un outil suisse ou français n’aura jamais de faille”, ce serait faux.

La souveraineté, dans ce contexte, signifie plutôt :

  • Savoir quels outils critiques on utilise
  • Savoir qui les maintient
  • Savoir à quelle vitesse on peut patcher
  • Svoir si on peut auditer
  • Savoir si on peut forker
  • Savoir si on peut imposer des exigences contractuelles
  • Savoir si on peut survivre sans dépendre aveuglément d’un tiers

Ce n’est pas une question idéologique, c’est une question de contrôle opérationnel.

10. Ce que ça change pour les métiers de la sécurité

Si les attaques deviennent plus agentiques, les compétences nécessaires dans une équipe de sécurité évoluent, mais les fondamentaux restent nécessaires.

Il faudra toujours des gens qui comprennent les systèmes, les réseaux, les identités, les logs, les malwares, les vulnérabilités, mais certaines compétences vont prendre encore plus d’importance.

Analyse comportementale

Il ne suffira plus de savoir chercher un hash ou une commande, il faudra comprendre ce qui est normal pour un workload, un compte, un segment réseau, une application.

Un bon analyste devra être capable de dire :

Ce serveur peut techniquement faire ça, mais il n’a aucune raison métier de le faire.

C’est souvent là que se trouve le signal.

Architecture de segmentation

La segmentation ne peut plus être un dessin Visio, elle doit être testée. Si un serveur applicatif compromis peut joindre toutes les bases de données internes, alors la segmentation est théorique et face à un agent autonome, la segmentation théorique ne vaut rien.

Gestion des secrets

JADEPUFFER rappelle une vérité simple : les secrets sont la monnaie de l’attaque: Clés API, tokens cloud, credentials database, fichiers .env, secrets dans les variables d’environnement, credentials par défaut.

Tout ce qui traîne sera essayé et un agent ne se fatiguera pas.

Automatisation de réponse

Un SOC qui dépend uniquement d’une validation humaine pour chaque action critique risque d’être trop lent, il faudra savoir construire des playbooks sûrs, gradués, auditables, réversibles quand c’est possible.

Threat modeling des agents

On ne peut plus modéliser uniquement “un attaquant humain avec des outils”, il faut aussi se demander :

Qu’est-ce qu’un agent autonome ferait s’il avait accès à ce système ?

Il énumérerait quoi ?
Il testerait quels secrets ?
Il pivoterait vers quoi ?
Il prioriserait quelles données ?
Il automatiserait quelles actions ?

C’est une nouvelle manière de penser l’attaque.

11. Ce qu’il faut faire demain matin

Il ne sert à rien de terminer sur “faites de la défense en profondeur”, tout le monde le sait. La vraie question est : par quoi commencer ?

1. Inventorier les outils d’orchestration

Pas seulement Langflow, mais tous les outils capables de déclencher des actions :

  • CI/CD
  • Automation IT
  • Orchestrateurs IA
  • Pipelines data
  • Notebooks
  • Plateformes low-code
  • Outils internes
  • Consoles d’administration exposées

Question simple :

Quels systèmes peuvent exécuter du code ou déclencher des actions en production ?

Ce sont des assets critiques.

2. Vérifier l’exposition Internet

Un endpoint capable d’exécuter du code ne devrait pas être exposé publiquement sans contrôle strict, cela paraît évident. Mais dans la vraie vie, des outils temporaires deviennent permanents, des POC deviennent prod, des ports restent ouverts, des instances “de test” contiennent des secrets réels.

3. Traquer les secrets

Chercher tous les éléments cités plus haut et surtout : ne pas seulement les trouver, mais aussi les révoquer quand cela est nécessaire, les déplacer dans un vault, limiter leur portée, surveiller leur usage.

4. Tester la segmentation

Pas avec une réunion, mais avec un test.

Depuis un serveur applicatif compromis, que peut-on joindre ?
Depuis un container exposé, quelles bases répondent ?
Depuis un outil d’orchestration, quels secrets sont accessibles ?
Depuis un compte technique, quels privilèges réels existent ?

5. Créer des playbooks de réponse gradués

Ne pas commencer par “isoler toute la prod”, commencer par :

  • Enrichissement automatique
  • Collecte volatile
  • Elévation de sévérité
  • Notification
  • Ticketing
  • Blocage conditionnel
  • Révocation conditionnelle
  • Containment avec validation

Le but n’est pas de remplacer l’humain, le but est de gagner les premières minutes.

6. Détecter les comportements d’intention

Exemples de chaînes utiles :

  • Application exposée → exécution de code → lecture de secrets
  • Container → scan interne → accès à MinIO/Nacos/DB
  • Compte technique → actions admin inhabituelles
  • Serveur IA → connexion cloud inhabituelle
  • Création de persistence après exploitation web
  • Lecture massive de configurations suivie de suppression

Ce sont ces chaînes qui racontent une attaque.

12. POC ou rupture ?

JADEPUFFER est probablement les deux, c’est un proof-of-concept dans le sens où :

  • Les techniques ne sont pas nouvelles
  • L’opération a commis des erreurs
  • La clé de chiffrement a été perdue
  • Certaines affirmations, comme l’exfiltration, ne sont pas vérifiées indépendamment
  • On ne connaît pas toute la configuration de l’agent

Mais c’est aussi un signal de rupture, parce qu’il montre qu’un agent peut enchaîner des étapes offensives de manière cohérente, parce qu’il montre que des vulnérabilités anciennes et des mauvaises configurations peuvent être exploitées à vitesse machine, parce qu’il montre que le coût d’orchestration d’une attaque complexe pourrait baisser.

Et parce qu’il pose une question désagréable :

Si le skill floor de l’attaquant baisse, combien d’organisations restent défendables avec leurs processus actuels ?

13. La vraie question : sommes-nous encore en train de défendre contre des humains ?

Pendant vingt ans, nous avons construit des défenses pour répondre à des humains augmentés par des outils.

Des humains rapides.
Des humains organisés.
Des humains compétents.
Mais des humains quand même.

Aujourd’hui, nous commençons peut-être à voir autre chose.

Des agents capables d’exécuter, d’essayer, d’échouer, de corriger, de continuer, de le faire vite et de le faire à grande échelle.

Cela ne rend pas nos SIEM inutiles.
Cela ne rend pas nos EDR inutiles.
Cela ne rend pas nos analystes inutiles.

Au contraire, mais cela signifie que nos SOC doivent évoluer.

Moins de dépendance au signal isolé et plus de corrélation comportementale, moins d’attente passive et plus de réponse automatisée contrôlée, moins de confiance implicite dans les outils d’orchestration et plus de segmentation réelle, moins de secrets exposés et plus de contrôle opérationnel.

JADEPUFFER n’est probablement pas le ransomware qui va mettre Internet à genoux, mais c’est peut-être l’un des premiers signaux faibles d’un changement beaucoup plus profond. Pendant des années, nous avons construit des défenses capables de réagir plus vite que des humains. Maintenant, il va peut-être falloir construire des défenses capables de réagir plus vite que des agents.

Et ce n’est pas du tout le même problème.

Références:
https://www.sysdig.com/blog/jadepuffer-agentic-ransomware-for-automated-database-extortion
https://nvd.nist.gov/vuln/detail/CVE-2025-3248
https://www.cisa.gov/known-exploited-vulnerabilities-catalog
https://github.com/langflow-ai/langflow
https://attack.mitre.org/matrices/enterprise/
https://genai.owasp.org/