Storm-3168 détruit des ressources Azure en sept minutes avec deux principaux de service compromis

Début juin 2026. Dans un locataire Azure compromis, un premier principal de service consacre environ 15 h 30 à cartographier l’environnement — plus de 300 opérations de lecture. Septembre 2026. Microsoft publie l’analyse complète de l’intrusion, attribuée à l’acteur JADEPUFFER (suivi en interne sous le nom Storm-3168), et The Hacker News la relaie le 28 septembre 2026. Pourquoi c’est important : l’attaque n’a rien chiffré. Elle a supprimé — plus de cent tentatives d’effacement de comptes de stockage en sept minutes — et les seules choses qui ont tenu sont des garde-fous indépendants de l’identité compromise.

Un acteur agentique déjà connu, une première incursion Azure documentée

JADEPUFFER avait été découvert par Sysdig en juillet 2026, et présenté comme la première opération de ransomware agentique documentée. L’analyse de Microsoft étend ce dossier avec la première vue détaillée de son activité Azure, qui marque une évolution de ses méthodes. Le point d’entrée présumé est lui-même instructif : l’identifiant client, le secret et l’identifiant de locataire d’un principal de service avaient été exposés en clair dans un ticket GitHub public par un employé de l’organisation touchée. Le ticket a ensuite été modifié pour retirer le secret — mais l’historique public de modification conservait la valeur. Microsoft précise ne pas pouvoir confirmer que ce secret précis a servi, tout en rappelant la règle : supprimer une fuite ne révoque pas le secret.

Deux principaux de service, deux rôles distincts

L’attaque s’appuie sur deux principaux de service compromis du même locataire, qui se partagent le travail. Le premier a assuré la reconnaissance : énumération des machines virtuelles, des abonnements et des groupes de ressources, pendant près de 16 heures et plus de 300 lectures réussies. Le second s’est chargé de la découverte, de la destruction et de la collecte d’identifiants, en 35 minutes et plus de 150 opérations.

Le découpage temporel est précis. Environ 90 minutes après le début de l’énumération du premier, le second principal a énuméré des machines virtuelles et des groupes de ressources sur deux abonnements en cinq secondes. Seize heures plus tard, il a inventorié les configurations d’App Service, probablement à la recherche d’identifiants exposés, puis tenté — sans succès — de chercher des ressources OpenSearch. 70 secondes après ce dernier inventaire, il a tenté une opération ListKey contre un compte de stockage inexistant, puis, moins d’une seconde plus tard, la séquence destructive a commencé.

Sept minutes de destruction, bornées par les rôles

La séquence destructrice a duré environ sept minutes, avec plus de 100 tentatives de suppression de comptes de stockage. La plupart ont réussi. En parallèle, le même principal a tenté de supprimer plusieurs bases SQL Azure, mais toutes les tentatives ont échoué à cause d’une version d’API non prise en charge pour le type de ressource. Un Key Vault, une Function App et un plan App Service du même groupe de ressources ont en revanche été supprimés.

Ce qui borne l’ampleur des dégâts, c’est le rôle de l’identité. Les opérations ont suivi les attributions de rôles existantes du principal : un rôle Storage Account Contributor (hérité d’un groupe) a autorisé les suppressions de stockage, un rôle Contributor direct les suppressions d’applications et une récupération de clé, un rôle SQL DB Contributor direct les tentatives sur les bases. Autrement dit, l’attaquant n’a escaladé aucun privilège — il a exploité exactement les permissions que le locataire avait accordées.

Les seules suppressions bloquées l’ont été par des mécanismes indépendants de l’identité : des verrous de ressources Azure et la protection de suppression au niveau du compte de stockage. Microsoft y voit la démonstration de la valeur de ces garde-fous, qui restent efficaces même quand une identité compromise dispose de permissions administratives larges.

La collecte qui suit la destruction

Environ 30 minutes après la fin de la destruction, le même principal a réalisé un inventaire des comptes de stockage et envoyé plus de 30 requêtes ListKeys réussies, récupérant les clés d’accès de chaque compte — y compris celles liées à Azure Site Recovery. Microsoft a observé cinq jetons uniques émis pour ce principal : quatre dédiés à la suppression, un à l’inventaire et à la récupération de clés, deux d’entre eux actifs pendant la même fenêtre de 70 secondes.

L’objectif destructeur est cohérent avec un acteur historiquement aligné sur le ransomware — JADEPUFFER avait été relié à une chaîne d’exploitation via la faille CVE-2025-3248 de Langflow. Ici, la suppression massive de ressources, suivie d’une collecte de clés, correspond à une logique de destruction puis d’exfiltration, orchestrée de façon automatisée.

Une exécution coordonnée, signature d’un acteur agentique

Microsoft insiste sur la coordination entre les opérations : la division du travail entre deux principaux, les flux de jetons qui se chevauchent et la cadence quasi instantanée entre la fin de la reconnaissance et le début de la destruction — moins d’une seconde — indiquent une exécution automatisée ou scriptée. C’est précisément cette orchestration, plus rapide qu’un opérateur humain, qui a permis de faire tenir l’essentiel de la destruction en 35 minutes et la phase destructive en sept minutes.

Le point mérite d’être nommé : JADEPUFFER avait été décrit en juillet 2026 comme le premier acteur ransomware agentique, c’est-à-dire dont la chaîne d’attaque repose sur des agents IA plutôt que sur des scripts figés. L’incursion Azure documentée par Microsoft en est la confirmation opérationnelle : la vitesse et le parallélisme des opérations — deux principaux, cinq jetons, des suppressions simultanées de stockage et de SQL — correspondent au profil d’une attaque orchestrée par un agent, pas d’un opérateur qui enchaîne les commandes à la main.

Ce que ça change pour la défense cloud

Le fil conducteur de l’intrusion est l’identité de charge de travail. Les principaux de service — ces identités non humaines utilisées par l’automatisation — sont devenus le levier d’une attaque qui n’a eu besoin d’aucun malware sur les machines. Trois enseignements s’en dégagent.

D’abord, la hygiène des secrets : une valeur exposée dans un historique public reste utilisable tant qu’elle n’est ni révoquée ni rotée. La correction passe par la révocation, pas par l’effacement de la publication. Ensuite, le moindre privilège : les rôles ont défini précisément ce que l’attaquant pouvait détruire, ce qui plaide pour des rôles granulaires plutôt que des rôles Contributor fourre-tout. Enfin, les garde-fous indépendants — verrous de ressources, suppression réversible, sauvegardes immuables — ont été la seule barrière qui a tenu face à une identité pourtant très privilégiée. Côté détection, Microsoft recommande d’activer les protections Microsoft Defender for Cloud et de surveiller les suppressions ainsi que les demandes ListKeys anormales sur vos comptes de stockage.

Verdict

Si vous utilisez des principaux de service Azure, commencez par l’inventaire des secrets exposés — un scan des historiques publics de vos dépôts vaut mieux qu’un audit a posteriori — et révoquez puis rotez toute valeur déjà fuitée. Si vos identités portent des rôles larges, réduisez-les au moindre privilège et préférez des rôles granulaires par ressource plutôt qu’un Contributor global. Et pour vos ressources critiques, activez les verrous de ressources, la protection de suppression et la sauvegarde immuable : ce sont les seuls mécanismes qui ont réellement arrêté Storm-3168 pendant sa séquence de destruction, et ils ne dépendent pas de la bonne santé d’une identité.

Références

• Microsoft Security Blog — Storm-3168: Agentic-driven cloud attacks using compromised service principals (25 septembre 2026)
• The Hacker News — JADEPUFFER-Linked Attackers Used Compromised Service Principals to Delete Azure Resources (28 septembre 2026)
• Dark Reading — JadePuffer AI Actor Compromises Azure in Destructive Cloud Attack (septembre 2026)