JADEPUFFER frappe Azure : 150 opérations destructives en 35 minutes, un secret en clair sur GitHub

> En bref : En juin 2026, l'activité suivie par Microsoft sous le nom Storm-3168 a compromis deux service principals Azure dans un même tenant. Le premier a exploré pendant environ 16 heures (300+ opérations de lecture). Le second a exécuté 150+ opérations destructives ou de collecte de credentials en 35 minutes, dont une séquence de 7 minutes avec 100+ tentatives de suppression de comptes de stockage. La cause racine : le client ID, le client secret et le tenant ID en clair dans une issue GitHub publique.

Deux service principals, deux rôles

La chronologie documentée par Microsoft Security Research (Yossi Weizman, Tushar Mudi) est étonnamment lisible :

Ce n'est pas un ransomware qui chiffre puis demande. C'est un acteur qui supprime — y compris les ressources liées aux sauvegardes et à la protection de la restauration. L'objectif est cohérent avec une logique de rançonnage, même si aucun mot de rançon n'a été observé dans cet incident, ni d'exfiltration.

Ce qui a résisté, ce qui n'a pas

La leçon technique : les verrous de ressource et la protection contre la suppression sont des contrôles Azure classiques, souvent activés par réflexe. Ici, ils ont fait la différence entre une perte et une catastrophe. Ce ne sont pas des contrôles « IA » : ce sont des contrôles de configuration, et ils ont fonctionné.

La cause racine : un secret en clair sur GitHub

Le client ID, le client secret et le tenant ID du service principal étaient exposés en clair dans une issue GitHub publique. L'issue a été supprimée par la suite — mais les secrets restaient visibles dans l'historique d'édition public du dépôt.

Supprimer une issue ne supprime pas l'historique git. Tant que le dépôt est public, tout commit contient les secrets qui y ont passé. Et un service principal compromis avec un accès tenant, c'est l'équivalent d'une clé maîtresse Azure.

Des probes répétées d'App Services Azure ont aussi été observées depuis des infrastructures liées à Storm-3168 — probablement automatisées ou scriptées, comme dans la plupart des campagnes de ce type.

Le contexte JADEPUFFER

JADEPUFFER a d'abord été documenté par Sysdig comme la première opération de rançonnage exécutée de bout en bout avec l'aide d'un LLM. L'attaque initiale exploite CVE-2025-3248 dans Langflow, récolte des credentials, chiffre des fichiers de configuration Nacos avec AES_ENCRYPT() de MySQL, supprime des tables de base de données et laisse un mot de rançon en Bitcoin.

La même instance Langflow a ensuite été touchée par ENCFORGE, un ransomware en Go ciblant l'infrastructure IA : environ 180 extensions de fichiers, checkpoints de modèles, bases vectorielles, datasets d'entraînement, indexes d'embeddings — jusqu'aux Keychains macOS, projets Xcode, fichiers Pages et Numbers.

L'incident Storm-3168 documenté par Microsoft montre le même groupe — ou un groupe du même cluster — opérer avec des identités Azure de premier ordre, sans LLM nécessaire dans la boucle. Le LLM est un accélérateur, pas un prérequis.

Ce qu'il faut vérifier maintenant

La leçon

150 opérations en 35 minutes, dont 100 suppressions en 7 minutes : c'est la vitesse d'un script, pas d'un humain. La détection ne gagnera pas à la vitesse — elle gagne à l'alerte sur l'action. Un service principal qui supprime en masse, c'est le signal le plus clair que l'on puisse attendre d'un environnement Azure. Et il part souvent d'un secret que quelqu'un a collé quelque part.