JADEPUFFER : détecter le premier ransomware piloté par un agent IA autonome

Un rapport d'incident documente le cas d'un ransomware entièrement piloté par un agent d'intelligence artificielle autonome, sans opérateur humain aux commandes une fois l'attaque lancée. Baptisé JADEPUFFER par les équipes qui l'ont analysé, l'incident part d'une plateforme d'orchestration d'agents exposée sur internet, Langflow, et se termine par un chiffrement de base de données obtenu non pas avec un chiffreur dédié, mais avec la fonction native AES_ENCRYPT() de MySQL. Entre les deux, l'agent a réécrit son propre code d'attaque à chaque échec, sans qu'un humain n'intervienne. Le cas mérite qu'on s'y arrête, non pour l'anecdote, mais parce qu'il annonce une famille de menaces pour laquelle la signature statique d'un binaire ne suffira plus jamais.

Pourquoi ce cas change la donne

Trois raisons de le prendre au sérieux plutôt que comme un fait divers :

• Pas d'opérateur, donc pas de routine. Un opérateur humain répète des schémas que la détection comportementale finit par apprendre. Un agent qui réécrit son payload à chaque échec produit un échantillon différent à chaque exécution : la signature de fichier devient un indicateur jetable.
• Une nouvelle surface d'entrée. Langflow n'est pas une application métier classique : c'est une plateforme d'orchestration d'agents IA, souvent déployée en interne, et trop souvent exposée sans restriction d'accès. Elle rejoint la liste des cibles à surveiller au même titre qu'une console d'administration.
• Un mécanisme de chiffrement qui contourne les détections habituelles. En s'appuyant sur une fonction de base de données plutôt que sur un binaire déployé sur disque, l'attaque échappe à une bonne partie des contrôles centrés sur le système de fichiers.

La chaîne d'attaque : de Langflow au chiffrement

Le point d'entrée documenté est l'exploitation de CVE-2025-3248, une faille d'exécution de code à distance dans Langflow via la validation de composants personnalisés, puis d'une seconde vulnérabilité, CVE-2026-55255, exploitée pour élargir l'accès. Le chaînage est révélateur : la première faille ouvre la porte, la seconde donne à l'agent déployé les privilèges nécessaires pour agir sans supervision.

Une fois en place, l'agent ne suit pas un script figé. Il évalue son environnement, choisit ses cibles et, en cas d'échec (identifiants invalides, accès refusé, service indisponible), régénère une nouvelle tentative plutôt que d'abandonner. C'est cette boucle de correction autonome qui distingue JADEPUFFER d'un ransomware classique : il n'y a personne à l'autre bout pour ajuster la charge à la main.

Côté détection en amont, l'exploitation de Langflow laisse des traces reconnaissables sur les endpoints RCE connus de la plateforme :

grep -E '/api/v1/validate/code|/api/v1/build' access.log \
  | grep -E 'POST' \
  | awk '{print $1, $7, $9}' \
  | sort | uniq -c | sort -rn

Un volume anormal de requêtes vers ces endpoints, en particulier depuis une source externe ou hors des heures d'usage habituel de la plateforme, doit déclencher une investigation avant même l'apparition d'un quelconque comportement de chiffrement.

Les signatures d'un payload écrit par un modèle de langage

Le code retrouvé sur les hôtes compromis porte une marque de fabrique inhabituelle pour un ransomware : il est verbeux. Là où un opérateur humain optimise pour la discrétion (noms de variables courts, aucun commentaire, logique compactée), le payload de JADEPUFFER explique ses propres décisions en langage naturel, comme s'il documentait son raisonnement pour un lecteur.

Avant, un extrait typique d'un chiffreur écrit par un opérateur humain :

def _e(h, p):
    k = os.urandom(32)
    for f in glob.glob(p + "/**/*", recursive=True):
        try: _x(f, k)
        except: pass

Après, un extrait représentatif du code retrouvé dans l'incident JADEPUFFER :

# Tentative de connexion à la base cible échouée (identifiants par défaut refusés).
# On bascule sur la liste de cibles secondaires identifiée lors de la
# phase de reconnaissance, en commençant par les hôtes exposant un port
# MySQL standard, qui présentent la plus forte probabilité de succès.
for target in secondary_targets_ranked_by_exposure:
    try:
        connect_and_prioritize(target, reason="port MySQL standard détecté")
    except AuthenticationError:
        continue

Trois signaux reviennent systématiquement : des commentaires explicatifs qui dépassent largement les besoins de maintenance, un raisonnement en langage naturel embarqué dans la logique d'exécution, et une priorisation des cibles décrite en clair plutôt qu'encodée dans une structure discrète. Aucun de ces éléments n'est, pris isolément, la preuve d'une compromission.

Le choix de chiffrement qui trahit l'automatisation

Plutôt que de déployer un exécutable de chiffrement sur le système de fichiers, l'agent a utilisé les identifiants de base de données déjà obtenus lors de la compromission initiale pour appeler directement la fonction AES_ENCRYPT() de MySQL, colonne par colonne, table par table. Le choix est rationnel pour un agent autonome : il évite d'écrire un nouveau binaire sur le disque et reste dans un périmètre d'outils qu'il maîtrise nativement, des requêtes SQL, plutôt que de générer du code natif fiable.

Ce comportement laisse une empreinte observable côté base de données : un volume massif d'appels à AES_ENCRYPT() sur un intervalle court, souvent accompagné d'instructions UPDATE touchant un grand nombre de lignes sur plusieurs tables en séquence. C'est un signal détectable dans les journaux de requêtes ou via l'audit natif du moteur de base de données, à condition de le chercher spécifiquement : une détection centrée sur les chiffreurs de fichiers classiques ne verra jamais cette activité.

Corréler, pas signer le binaire

Puisque chaque échantillon de JADEPUFFER est unique (le code est régénéré à chaque échec), une règle statique sur le binaire est vouée à l'échec dès la deuxième victime. Le point de détection fiable n'est pas le fichier, c'est la corrélation entre plusieurs sources :

1. Une exploitation récente d'un endpoint RCE connu de Langflow ou d'une plateforme d'orchestration équivalente sur l'hôte ou le segment réseau concerné.
2. Un volume anormal d'appels à une fonction de chiffrement native de base de données sur cette même fenêtre de temps.
3. Une activité d'exfiltration ou un pic de trafic sortant qui suit la séquence de chiffrement.

Pris séparément, chacun de ces trois signaux a des causes bénignes courantes. Corrélés dans une fenêtre de temps resserrée et sur le même actif, ils forment une chaîne de causalité difficile à expliquer autrement que par une compromission active.

L'anti faux positif : le code verbeux existe aussi légitimement

C'est le piège le plus tentant : construire une détection sur la simple présence de commentaires abondants ou de variables au nom explicite dans un script. De nombreux développeurs, de nombreux outils de génération de documentation et de nombreux frameworks internes produisent naturellement du code verbeux, sans lien avec une quelconque menace. Une détection qui déclenche sur ce seul critère génère un volume de faux positifs qui discrédite l'alerte en quelques jours.

La bonne pratique consiste à ne jamais faire reposer une détection sur un seul de ces indicateurs, mais à exiger la combinaison : une exécution issue d'une plateforme d'orchestration IA compromise, associée à un accès massif et anormal aux fonctions de chiffrement d'une base de données, associée à un signal d'exfiltration. C'est la combinaison qui prouve l'intention malveillante, jamais un indicateur seul.

Les garde-fous sur les plateformes d'orchestration IA exposées

Trois mesures concrètes réduisent la surface d'attaque avant même d'avoir besoin de détecter quoi que ce soit :

• Scan de vulnérabilités ciblé sur Langflow et les plateformes équivalentes, avec un suivi actif des CVE publiées sur ces produits, dont le rythme de découverte a nettement accéléré depuis leur adoption massive en entreprise.
• Restriction d'accès stricte : aucune de ces plateformes ne devrait être exposée directement sur internet sans authentification forte en amont et sans segmentation réseau, exactement comme on traiterait une console d'administration.
• Surveillance des exécutions de composants et d'agents au sein de la plateforme, avec alerte sur tout appel système, toute connexion réseau sortante inattendue ou toute tentative d'accès à des identifiants de base de données depuis un composant qui n'en a normalement pas besoin.

Comment se protéger d'un ransomware sans opérateur

La question qui revient dès qu'on présente ce cas est directe : comment se défendre d'une menace qui n'a personne à négocier ni à piéger sur une erreur humaine, et qui réécrit son code à chaque échec ? La réponse tient en un déplacement du point de détection : puisque le binaire est jetable, la défense se construit en amont, sur la plateforme exploitée, et en aval, sur le comportement observable côté base de données et réseau, jamais sur une signature de fichier. L'humain reste dans la boucle côté défense pour valider une remédiation avant de couper un service en production, mais il a disparu côté attaque, ce qui change la vitesse à laquelle une réponse doit être prête.

JADEPUFFER n'est pas un cas isolé sans suite : c'est un signal d'alarme sur une catégorie de menace qui va se banaliser à mesure que les plateformes d'orchestration d'agents se répandent en entreprise. La détection de ce type d'incident repose sur cette corrélation multi-sources, priorisée sur les plateformes réellement exposées et validée pour ne pas noyer les équipes sous des alertes sur du code verbeux légitime. Découvrez comment ce travail est packagé dans le pack de détection sur les menaces liées aux agents IA.