Le 25 septembre 2026, Microsoft a publié un rapport qui marque un tournant pour la sécurité du cloud. Son équipe Defender for Cloud y décrit une campagne baptisée Storm-3168, liée à un acteur déjà repéré en juillet par la société de sécurité cloud Sysdig sous le nom de JadePuffer. En quelques heures, cet attaquant a supprimé plus de 100 comptes de stockage Azure, en ciblant bases de données, coffres-forts de secrets et machines virtuelles. Selon Microsoft, une partie de l’opération a été pilotée par un agent IA capable d’enchaîner seul reconnaissance, vol d’identifiants et destruction. C’est, à ce jour, le cas documenté le plus abouti de ransomware agentique appliqué directement à une infrastructure cloud publique.
L’affaire intéresse directement les entreprises françaises et européennes qui hébergent tout ou partie de leurs données sur Azure. Elle touche aussi au débat plus large sur la sécurité des identités non humaines dans le cloud, un sujet que la plupart des audits de conformité traitent encore comme secondaire. Voici ce que l’on sait précisément, ce qui reste flou, et ce que cette attaque change pour la sécurité du cloud en 2026.
Qu’est-ce que JadePuffer, l’acteur derrière Storm-3168 ?
JadePuffer n’est pas né sur Azure. Selon The Hacker News, les chercheurs de Sysdig ont découvert ce groupe en juillet 2026 lors d’une première campagne de ransomware classique. Le point d’entrée initial était une faille dans Langflow, référencée CVE-2025-3248. Une fois à l’intérieur, l’attaquant volait des identifiants, se déplaçait latéralement, chiffrait des fichiers de configuration Nacos, supprimait des tables de bases de données, puis laissait une note de rançon exigeant un paiement en bitcoin.
Ce qui distingue JadePuffer de la masse des groupes de ransomware, c’est la manière dont cette chaîne d’actions a été exécutée. Sysdig décrit l’opération comme pilotée de bout en bout par un grand modèle de langage, un agent qui choisit lui-même les étapes suivantes plutôt que de suivre un script figé écrit à l’avance. Microsoft reprend cette qualification et parle d’attaques pilotées par l’IA (agentic-driven) dans le titre même de son rapport du 25 septembre. Le nom Storm-3168 est la convention interne que Microsoft utilise pour désigner cet acteur tant qu’il n’a pas de nom public définitif, une pratique courante chez l’éditeur pour cataloguer les menaces émergentes avant attribution complète.
L’attaque Azure du mois de juin, reconstituée par Microsoft
Le rapport de Microsoft, signé par les chercheurs Yossi Weizman et Tushar Mudi de Microsoft Defender for Cloud, reconstitue une attaque survenue début juin 2026 et qui a duré environ seize heures. Le point de départ : deux identités de type service principal compromises. Ces identités non humaines servent normalement à authentifier des applications, des automatisations ou des pipelines face aux API Azure, sans intervention d’un utilisateur humain. Une fois ces deux comptes sous contrôle, l’attaquant a cartographié l’environnement Azure de la victime, collecté des clés d’accès à des comptes de stockage, puis déclenché une phase destructrice.
Le chiffre qui a le plus marqué les lecteurs du rapport est celui-ci : plus de 100 comptes de stockage Azure supprimés en environ sept minutes, selon les détails rapportés par Tech Times. L’attaque ne s’est pas arrêtée au stockage. Microsoft liste également des bases SQL, des coffres Key Vault, des Function Apps, des machines virtuelles, des App Services et les verrous de protection de récupération (resource locks) comme cibles ou composantes touchées par la campagne. Seuls les comptes déjà protégés par un verrou de suppression préconfiguré ont résisté à l’effacement, un détail que Microsoft met en avant comme la principale leçon pratique de l’incident.
Comment les identités Azure ont-elles été volées ?
C’est le point le plus incertain du dossier, et il faut le dire clairement plutôt que de combler le vide par des suppositions. Microsoft confirme la compromission de deux service principals et la collecte de clés d’accès aux comptes de stockage, mais le rapport public ne précise pas le vecteur initial exact utilisé pour voler ces identités dans l’environnement Azure visé. Le mécanisme d’accès initial documenté avec précision reste celui de la première affaire révélée par Sysdig en juillet, via la faille Langflow CVE-2025-3248, sans qu’on sache si c’est la même porte d’entrée qui a servi pour l’épisode Azure de juin.
Cette zone grise compte double pour les équipes de sécurité. D’un côté, elle empêche de dresser une liste simple de correctifs à appliquer. De l’autre, elle rappelle une réalité structurelle du cloud public : les service principals, contrairement aux comptes utilisateurs, échappent souvent à l’authentification multifacteur, à la surveillance comportementale classique et aux revues d’accès périodiques. Un rapport paru la même semaine sur BleepingComputer décrit une campagne distincte de scan massif visant des serveurs de développement Vite exposés sur Internet, avec tentative de vol de configurations AWS et Azure. Ce n’est pas la même opération que JadePuffer, mais le contexte montre que le vol d’identifiants cloud par scan automatisé est redevenu une activité quotidienne pour plusieurs groupes distincts en septembre 2026.
Chronologie complète de l’affaire JadePuffer / Storm-3168
Reconstituer la séquence exacte aide à comprendre pourquoi cette histoire a mis près de trois mois à sortir publiquement sous sa forme complète. Voici les dates confirmées par les sources citées plus haut.
| Date | Événement |
|---|---|
| Début juin 2026 | Attaque destructrice contre un environnement Azure, durée estimée à 16 heures, plus de 100 comptes de stockage supprimés en 7 minutes |
| Juillet 2026 | Sysdig documente publiquement JadePuffer comme premier cas connu de ransomware piloté de bout en bout par un agent IA, via la faille Langflow CVE-2025-3248 |
| 25 septembre 2026 | Microsoft publie son rapport Storm-3168 et relie officiellement l’acteur à JadePuffer |
| 28 septembre 2026 | The Register, The Hacker News et Security Affairs relaient l’analyse Microsoft en détail |
| 29-30 septembre 2026 | Tech Times, BleepingComputer et d’autres médias spécialisés publient leurs propres analyses de l’incident |
Ce décalage de trois mois entre l’attaque et sa publication complète n’a rien d’inhabituel. Les éditeurs cloud mènent généralement une investigation approfondie avant de publier, le temps de confirmer l’attribution, de corriger les angles morts de détection et de coordonner la communication avec les chercheurs tiers, ici Sysdig.
Combien de victimes, et quel coût financier ?
Sur ce terrain, la prudence s’impose. Ni Microsoft ni les médias qui ont couvert l’affaire n’ont publié de liste de victimes, de décompte précis d’organisations touchées, ni de montant de rançon payée ou réclamée pour l’épisode Azure. Le chiffre de 100 comptes de stockage supprimés concerne des ressources techniques, pas nécessairement 100 entreprises distinctes puisqu’une seule organisation peut détenir des dizaines de comptes de stockage dans un même abonnement Azure.
Aucune victime française ou européenne n’a été nommée publiquement à ce stade. Cela ne garantit en rien l’absence d’exposition sur le Vieux Continent : les entreprises concernées par ce type d’incident communiquent rarement avant d’y être obligées par une régulation locale. En France et dans l’Union européenne, la directive NIS2 impose déjà des délais de notification resserrés aux opérateurs de services essentiels en cas d’incident significatif, ce qui inclut potentiellement une perte de disponibilité de cette ampleur si elle touchait une entité régulée.
JadePuffer face à l’histoire : du wiper NotPetya au ransomware agentique
Comparer JadePuffer à NotPetya, l’attaque destructrice qui a paralysé des multinationales en 2017, aide à cerner ce qui change vraiment et ce qui reste identique. NotPetya se propageait via un logiciel de comptabilité ukrainien compromis, puis détruisait des disques entiers sur des réseaux d’entreprise classiques. JadePuffer opère à un autre niveau : celui du plan de contrôle cloud et de la couche d’identité, là où une poignée d’appels API suffit à effacer des téraoctets de données sans jamais toucher un disque physique.
| Critère | JadePuffer / Storm-3168 (2026) | NotPetya (2017) |
|---|---|---|
| Environnement ciblé | Ressources cloud Azure (stockage, bases, secrets) | Réseaux et postes d’entreprise classiques |
| Mécanisme d’entrée | Identités compromises, service principals | Mise à jour logicielle piégée (supply chain) |
| Rôle de l’IA | Agent IA orchestrant seul la chaîne d’attaque, selon Sysdig | Aucun |
| Méthode de destruction | Appels API légitimes pour supprimer des ressources | Écrasement du secteur de démarrage des disques |
| Vitesse de la phase destructrice | Plus de 100 comptes de stockage en environ 7 minutes | Propagation à l’échelle mondiale en quelques heures |
| Ampleur confirmée publiquement | Non chiffrée, pas de liste de victimes publiée | Des milliards de dollars de dégâts cumulés chez Maersk, Merck et d’autres |
Il serait prématuré de présenter JadePuffer comme l’équivalent cloud de NotPetya en termes d’ampleur. Les preuves publiques actuelles décrivent une technique significative, pas encore un sinistre mondial comparable. Mais le parallèle tient sur un point précis : dans les deux cas, l’objectif n’était pas seulement de chiffrer pour monnayer une clé de déchiffrement, mais de rendre la donnée irrécupérable, y compris via les mécanismes de récupération eux-mêmes, ici les resource locks.
Pourquoi l’IA agentique change la donne pour les équipes de sécurité
Le terme agentique ne décrit pas un logiciel qui génère simplement du texte ou du code suggéré à un humain. Il désigne un système capable d’enchaîner lui-même plusieurs actions successives, reconnaissance, vol d’identifiants, déplacement latéral, persistance puis destruction, à partir d’un point d’entrée initial, sans qu’un opérateur humain valide chaque étape. Sysdig a documenté ce comportement de bout en bout sur le cas de juillet. Pour l’épisode Azure de juin, le rapport Microsoft ne prouve pas que chaque suppression de ressource a été décidée sans supervision humaine, mais il confirme que l’ensemble s’inscrit dans l’évolution de tactiques d’un acteur déjà qualifié d’agentique.
Cette automatisation change concrètement le calcul défensif. Un opérateur humain qui attaque une infrastructure cloud doit explorer, hésiter, parfois se tromper d’identifiant ou de région. Un agent qui exécute une chaîne d’actions pré-entraînée sur des milliers de scénarios similaires peut comprimer cette phase d’exploration à quelques minutes. La fenêtre de détection et de réaction, déjà courte dans le cloud, se réduit encore. C’est cette compression du temps qui explique pourquoi 100 comptes de stockage ont pu disparaître en 7 minutes plutôt qu’en plusieurs heures.
Le marché du cloud sous tension : Azure, AWS et Google Cloud
Cet incident tombe à un moment sensible pour Microsoft sur le plan commercial. Selon Synergy Research Group, les dépenses mondiales en infrastructure cloud ont atteint 143,4 milliards de dollars au deuxième trimestre 2026, en hausse de 43 % sur un an, la plus forte progression trimestrielle enregistrée depuis huit ans. Dans ce marché en pleine expansion, AWS reste en tête avec 28 % de part de marché, en recul par rapport à environ 30 % un an plus tôt. Azure reste stable autour de 20 %. Google Cloud atteint 15 %, son plus haut niveau historique selon Synergy, porté par une croissance de revenus de 82 % sur un an.
| Fournisseur | Part de marché T2 2025 | Part de marché T2 2026 | Croissance annuelle des revenus |
|---|---|---|---|
| AWS | ~30 % | 28 % | ~37 % |
| Microsoft Azure | 20 % | 20 % | ~43 % |
| Google Cloud | 13 % | 15 % | ~82 % |
Un incident de cette nature n’entame pas forcément la part de marché d’Azure à court terme, les migrations cloud se décident sur des cycles de plusieurs années et non après un seul article de presse. Mais il alimente un argumentaire que les concurrents d’Azure ne manqueront pas d’utiliser dans leurs appels d’offres, en particulier sur la gestion des identités non humaines, un sujet où AWS et Google Cloud communiquent déjà activement sur leurs propres modèles de permissions par défaut.
Le moment est d’autant plus délicat que, selon le statut officiel d’Azure Status History, une panne distincte a touché Azure OpenAI Service, Foundry Agent Service, Foundry Models et Cognitive Services dans la région Sweden Central le 29 septembre 2026, entre 10h03 et 15h58 UTC, avec des échecs intermittents et des erreurs HTTP 5XX. Rien ne relie techniquement cette panne à la campagne JadePuffer, mais la concomitance des deux informations dans la même semaine pèse sur la perception de fiabilité d’Azure chez les décideurs IT qui suivent l’actualité de près.
La sécurité des identités non humaines, angle mort des audits cloud
Les service principals, rôles managés et comptes de service existent dans toutes les plateformes cloud majeures. Ils permettent à une application de parler à une API sans mot de passe humain à saisir. Le problème, documenté depuis plusieurs années par les spécialistes de la gestion des identités cloud (CIEM), c’est que ces comptes accumulent souvent des permissions excessives, restent actifs bien après la fin du projet qui les a créés, et échappent aux contrôles pensés pour des utilisateurs humains comme l’authentification multifacteur.
L’affaire JadePuffer illustre ce point avec une netteté rare. Deux identités compromises ont suffi à cartographier un environnement entier, collecter des clés de stockage, puis déclencher une destruction massive. Pour une équipe de sécurité, la question centrale devient : combien de service principals dormants, sur-privilégiés ou mal surveillés existent aujourd’hui dans mon propre tenant Azure, AWS ou Google Cloud, et seraient-ils capables de produire les mêmes dégâts s’ils étaient compromis demain ?
Les recommandations de Microsoft, et leurs limites
Microsoft a accompagné son rapport de recommandations pratiques pour les administrateurs Azure : activer les protections de charge de travail cloud, rechercher des secrets exposés dans les dépôts publics, revoir les permissions RBAC, appliquer le principe du moindre privilège, et surtout préconfigurer des verrous de ressources et des protections de récupération avant qu’un incident ne survienne. Ce dernier point n’est pas théorique : dans l’épisode de juin, ce sont précisément les comptes déjà verrouillés qui ont survécu à la vague de suppressions.
- Activer des verrous de suppression (delete locks) sur tous les comptes de stockage et bases critiques, avant tout incident
- Inventorier systématiquement les service principals actifs et désactiver ceux qui ne servent plus à rien
- Appliquer le principe du moindre privilège aux identités non humaines, pas seulement aux comptes utilisateurs
- Mettre en place une détection comportementale spécifique aux appels API inhabituels de suppression en masse
- Maintenir des sauvegardes immuables, stockées hors du même tenant que les ressources de production
Ces mesures ne sont pas nouvelles, et c’est bien le problème qu’elles révèlent. Elles figurent depuis des années dans les guides de bonnes pratiques Azure. Leur rappel après un incident de cette ampleur montre que la théorie de la sécurité cloud reste souvent plus avancée que son application réelle sur le terrain, faute de temps, de budget ou simplement de visibilité sur l’ensemble des identités déployées.
Ce que cela signifie pour les entreprises françaises et européennes
Pour une direction des systèmes d’information en France, l’enseignement le plus direct ne porte pas sur Azure en particulier, mais sur la gouvernance des identités machine à machine, quel que soit le fournisseur cloud retenu. Les entités soumises à NIS2, de plus en plus nombreuses depuis la transposition progressive de la directive, doivent déjà documenter leurs dépendances cloud critiques et leurs procédures de notification d’incident. Un scénario de suppression massive de ressources de stockage, s’il touchait une entité régulée, entrerait très probablement dans le périmètre des incidents à signaler sous 24 à 72 heures selon la gravité retenue.
Les assureurs cyber commencent par ailleurs à intégrer des questionnaires plus précis sur la gestion des identités non humaines dans leurs grilles de souscription, un mouvement qui va probablement s’accélérer après la publicité donnée à cet incident. Les entreprises qui ne peuvent pas répondre précisément à la question du nombre de service principals actifs sur leurs abonnements cloud risquent de voir leurs primes augmenter, indépendamment de toute compromission réelle.
Cinq prédictions pour la suite de la menace agentique dans le cloud
Ces projections relèvent de l’analyse éditoriale de la rédaction, construite à partir des tendances observées depuis juillet 2026, et non de déclarations officielles de Microsoft, Sysdig ou d’un autre acteur cité dans cet article.
- D’autres groupes de ransomware vont copier le schéma agentique de JadePuffer plutôt que d’inventer une approche totalement nouvelle, la méthode ayant déjà prouvé son efficacité en conditions réelles
- Les fournisseurs cloud vont pousser des verrous de suppression activés par défaut sur les ressources critiques, au lieu de laisser cette protection à la discrétion du client
- Le marché de la détection d’identités non humaines (CIEM, ITDR) va capter une part croissante des budgets de sécurité cloud en 2027
- Les régulateurs européens vont progressivement exiger une cartographie des identités machine dans les audits NIS2 et CRA, au-delà des seuls comptes humains
- D’autres rapports d’attribution attribueront à des agents IA des campagnes jusqu’ici classées comme attaques manuelles, une fois les équipes de threat intelligence équipées pour détecter cette signature
Ce qui reste à confirmer dans les prochaines semaines
Plusieurs zones d’ombre entourent encore ce dossier début octobre 2026. Le vecteur d’accès initial précis de l’épisode Azure de juin n’a pas été publié. Aucun décompte officiel de victimes ni montant de rançon n’a filtré. Et la part exacte d’autonomie de l’agent IA dans la phase destructrice Azure, par opposition à une supervision humaine partielle, reste décrite par Microsoft en termes généraux plutôt que techniques détaillés. Ces zones grises devraient se préciser à mesure que d’autres chercheurs, notamment chez Sysdig, publieront leurs propres analyses complémentaires du même acteur.
Foire aux questions
Qu’est-ce que JadePuffer ?
JadePuffer est le nom donné par la société Sysdig à un acteur de ransomware découvert en juillet 2026, décrit comme le premier cas documenté d’une attaque menée de bout en bout par un agent piloté par un grand modèle de langage.
Qu’est-ce que Storm-3168 ?
Storm-3168 est le nom de suivi interne utilisé par Microsoft pour désigner l’acteur que son équipe Defender for Cloud relie à JadePuffer dans son rapport du 25 septembre 2026 sur les attaques destructrices visant Azure.
Combien de comptes Azure ont été touchés ?
Microsoft indique que plus de 100 comptes de stockage ont été supprimés en environ sept minutes lors de la phase destructrice de l’attaque de juin 2026, en plus de bases SQL, coffres Key Vault, Function Apps, machines virtuelles et App Services ciblés ou touchés.
Des entreprises françaises ont-elles été touchées ?
Aucune victime française ou européenne n’a été nommée publiquement à ce stade par Microsoft ou par les médias ayant couvert l’affaire.
Comment les identités Azure ont-elles été compromises ?
Le rapport confirme la compromission de deux service principals et la collecte de clés d’accès au stockage, sans préciser publiquement le vecteur initial exact utilisé pour cet épisode Azure spécifique.
JadePuffer est-il comparable à NotPetya ?
Les deux visent la destruction plutôt que le seul gain financier, mais les mécanismes diffèrent fortement : NotPetya se propageait via une mise à jour logicielle piégée sur des réseaux d’entreprise, tandis que JadePuffer opère via des identités cloud compromises et des appels API légitimes.
Comment se protéger contre ce type d’attaque ?
Microsoft recommande d’activer des verrous de suppression sur les ressources critiques, d’inventorier et de limiter les permissions des service principals, d’appliquer le moindre privilège et de maintenir des sauvegardes immuables séparées du tenant de production.
Cette attaque concerne-t-elle uniquement Azure ?
L’épisode documenté par Microsoft porte sur Azure, mais le problème structurel des identités non humaines sur-privilégiées concerne l’ensemble des fournisseurs cloud, y compris AWS et Google Cloud.
