JadePuffer/Storm-3168 : un acteur agentique supprime le stockage d'un locataire Azure en une rafale destructive de 7 minutes

Microsoft Security Research a rapporté le 25 septembre 2026 qu'un acteur utilisant deux principaux de service compromis a opéré au sein d'un locataire Azure non nommé au début du mois de juin 2026, en commençant par plus de 15 heures de reconnaissance, puis, en quelque sept minutes, a tenté de supprimer plus de 100 comptes de stockage, y parvenant pour la plupart d'entre eux, et a supprimé un Azure Key Vault, une Function App et un plan App Service. Microsoft attribue l'intrusion à l'acteur qu'elle suit sous le nom de Storm-3168, que la société de sécurité Sysdig appelle JADEPUFFER et a documenté en juillet 2026 comme la première opération de rançongiciel menée de bout en bout par un grand modèle de langage. Microsoft a déclaré n'avoir trouvé aucune note de rançon et n'a pas confirmé que des données aient été exfiltrées. L'archive consigne cette campagne comme un incident de gravité élevée, avec une implication de l'IA confirmée et des dommages réels, et l'entrée complète dans l'Orca AI Incident Archive contient ses sources, sa note de gravité et son évaluation de confiance.

La victime n'est pas nommée. Le rapport de Microsoft décrit un unique locataire Azure, deux principaux de service compromis qui lui appartenaient, et une répartition des tâches entre eux : un principal a effectué de la reconnaissance pendant environ 15 heures et 30 minutes et a réalisé plus de 300 opérations de lecture réussies énumérant des machines virtuelles, des abonnements, des groupes de ressources et des ressources ; l'autre a effectué la découverte, les opérations destructrices et la collecte d'identifiants. Microsoft n'a pas précisé combien d'organisations ont été affectées et n'a pas pu établir comment les principaux de service avaient été compromis au départ.

Ce que la télémétrie montre, dans l'ordre

Le second principal a commencé environ 90 minutes après le début du premier, et a énuméré les machines virtuelles et les groupes de ressources de deux abonnements en cinq secondes environ, selon Microsoft. Les deux identités utilisaient une infrastructure que Microsoft associe à Storm-3168, partageaient la même empreinte réseau et présentaient le même agent utilisateur, python-requests/2.34.2. Microsoft a déclaré que le timing et la répartition du travail « indiquent fortement une exécution automatisée ou scriptée ».

Environ 16 heures plus tard, le deuxième principal a vérifié les magasins de configuration d’Azure App Service à la recherche d’identifiants exposés et a recherché, sans succès, Azure OpenSearch. Soixante-dix secondes plus tard, il a tenté une opération ListKey sur un compte de stockage qui n’existait pas. Moins d’une seconde après cet appel échoué, la destruction a commencé. Au cours des 35 minutes suivantes, Microsoft a compté plus de 150 opérations destructrices ou de collecte d’identifiants ; la phase destructrice principale a duré environ sept minutes.

Les sept minutes, et les contrôles qui ont tenu

Microsoft indique que la plupart des comptes de stockage ciblés par l’acteur ont été supprimés avec succès. L’acteur a également supprimé un Azure Key Vault, une Function App et un plan App Service qui se trouvaient dans le même groupe de ressources et semblaient prendre en charge la Function App. Le ciblage ne se limitait pas au stockage : Microsoft a enregistré plusieurs tentatives de suppression de verrous Azure Site Recovery et de verrous de protection Azure Backup, et a indiqué que ces tentatives ont échoué.

Microsoft affirme que toutes les suppressions n’ont pas fonctionné, et que les raisons diffèrent d’une manière qui compte pour les défenseurs. Quelques comptes de stockage ont survécu parce que des verrous de ressources Azure et une protection contre la suppression au niveau du compte de stockage ont bloqué l’opération. Les tentatives parallèles de suppression de bases de données Azure SQL ont échoué pour une autre raison : chacune utilisait une version d’API non prise en charge. La Cloud Security Alliance a qualifié cela d’erreur opérationnelle plutôt que d’action bloquée. Microsoft a résumé la combinaison de suppression de ressources, de tentatives d’entrave à la récupération et de collecte d’identifiants comme « cohérente avec des tactiques susceptibles de soutenir des opérations de rançongiciel et d’extorsion ».

Le compte de Microsoft décrit des attributions de rôles Azure ordinaires plutôt qu'une exploitation d'Azure lui-même. Il a constaté qu'un rôle Storage Account Contributor accordé à un groupe a permis la destruction du stockage, un rôle direct Contributor a permis la suppression des trois ressources applicatives et une autre récupération de clé, et un rôle direct SQL DB Contributor a permis les tentatives SQL infructueuses. Microsoft a observé cinq jetons uniques émis pour le second principal de service : quatre prenaient en charge la suppression et le cinquième gérait l'inventaire du stockage et la récupération de clés. Deux des jetons de suppression étaient actifs pendant la même période de 70 secondes. Le rapport note également que des comptes de stockage avec des noms terraform et backup thématiques figuraient parmi les cibles, potentiellement pour entraver la récupération.

Le retour pour les clés de stockage

Environ 30 minutes après la fin de la destruction, le même principal est revenu. Il a inventorié les comptes de stockage et effectué plus de 30 requêtes ListKeys réussies, y compris à l’encontre du stockage lié à Site Recovery. Un compte de stockage au nom similaire dans le même groupe de ressources avait été épargné pendant la phase de suppression, et ses clés ont ensuite été listées avec succès. Microsoft n’a pas observé de note de rançon et n’a pas confirmé d’exfiltration de données réussie, mais a indiqué que les clés collectées pourraient faciliter une exfiltration future.

Cette séquence change ce que signifie la reprise, selon Ross Filipek, directeur de la sécurité de l’information chez Corsica Technologies, qui s’est entretenu avec CSO Online au sujet de l’incident. Reconstruire les actifs supprimés ne suffit pas, a-t-il déclaré, car les demandes ultérieures de clés de stockage peuvent créer un autre chemin vers les données ; les équipes de réponse doivent déterminer quelles identités et quelles clés ont été concernées et examiner leur utilisation avant de faire confiance aux services restaurés. « Une fois que les attaquants détiennent une identité d’application, leur activité peut ressembler à une administration cloud ordinaire », a déclaré Filipek à CSO Online.

Comment les identifiants ont refait surface

Microsoft n'a pas pu confirmer le vecteur d'accès initial. Ce qu'elle a trouvé, en revanche, était une exposition : l'ID client, le secret client et l'ID de locataire de l'un des principaux de service étaient apparus en clair dans un ticket GitHub public, publié par un employé de l'organisation affectée. Le ticket a ensuite été modifié, mais Microsoft a indiqué que le secret restait accessible via l'historique public des modifications du ticket. Le rapport indique clairement que Microsoft n'a pas pu confirmer si ce secret était celui qui avait été utilisé.

L'avertissement joint à cette constatation constitue la partie pratique. Microsoft indique que les identifiants qui ont été exposés publiquement doivent être considérés comme compromis, révoqués ou renouvelés immédiatement, et faire l'objet d'une enquête pour utilisation antérieure ; supprimer ou masquer un secret exposé ne l'invalide pas, et les identifiants exposés publiquement restent utilisables jusqu'à leur révocation ou leur renouvellement.

Microsoft a également décrit un balayage plus étendu mené depuis le début de 2026 par l'infrastructure liée à Storm-3168 contre Azure App Services, ciblant l'administration WordPress, PHP-CGI, le point de terminaison Langflow /api/v1/validate/code, ainsi que des chemins de type webshell. Ces cibles ne chevauchaient pas les abonnements de la victime, et Microsoft n'a trouvé aucun chemin permettant de passer d'un App Service à des identifiants Azure Resource Manager. Le rapport répertorie trois indicateurs : 45.131.66[.]106 pour le balayage et les requêtes ARM malveillantes, et 34.153.223[.]102 et 64.20.53[.]230 pour le balayage d'App Service.

Le même acteur, une opération différente

Le rapport de Sysdig du 1er juillet 2026 est la raison pour laquelle le terme « agentique » est associé à cet acteur. Sysdig a décrit JADEPUFFER comme le premier cas documenté de rançongiciel agentique — « une opération d’extorsion complète menée de bout en bout par un grand modèle de langage » — et a indiqué que ses capacités provenaient d’un agent d’IA plutôt que d’une boîte à outils pilotée par un humain. Lors de cette intrusion, l’acteur a exploité CVE-2025-3248 dans une instance Langflow exposée à Internet, a chiffré 1 342 éléments de configuration Nacos à l’aide de la fonction native de MySQL AES_ENCRYPT(), a supprimé les tables d’origine et a laissé une README_RANSOM contenant une adresse Bitcoin et un contact Proton Mail. Sysdig a signalé plus de 600 charges utiles distinctes, du code auto-narratif et une charge utile corrective en plusieurs étapes intervenue dans les 31 secondes suivant un échec de connexion à Nacos. Sysdig a également indiqué qu’il n’avait pas de visibilité sur le prompt système ni sur la configuration de l’agent.

La campagne Azure est une opération distincte du même acteur, et non une répétition de l'intrusion de juillet : elle visait la suppression et la collecte de clés, et non le chiffrement, et Microsoft n'a trouvé aucune note de rançon. Le lien entre les deux repose en partie sur l'infrastructure. La Cloud Security Alliance a noté dans une note de recherche du 28 septembre que deux des adresses IP listées par Microsoft, 45.131.66[.]106 et 34.153.223[.]102, étaient apparues dans les rapports de Sysdig de juillet. La même note avertissait que la seule réutilisation d'IP ne permet pas d'exclure un hébergement tiers partagé.

Établi, évalué et toujours ouvert

Les mécanismes de l’intrusion Azure sont bien documentés. L’autonomie ne l’est pas au même niveau, et cet écart constitue la réserve la plus importante de ce dossier.

Établi par la télémétrie de Microsoft : deux principaux de service compromis dans un même locataire ; plus de 300 opérations de lecture réussies sur environ quinze heures et demie ; plus de 100 tentatives de suppression de comptes de stockage, dont la plupart ont réussi ; la suppression d’un Key Vault, d’une Function App et d’un plan App Service ; des suppressions de bases de données SQL qui ont toutes échoué en raison d’une version d’API non prise en charge ; des comptes de stockage sauvés par des verrous de ressources et une protection contre la suppression ; plus de 30 requêtes ListKeys réussies après la destruction ; des identifiants de principal de service en texte clair dans un ticket GitHub public et son historique de modifications ; aucune note de rançon observée ; et aucune exfiltration confirmée.

Selon l'évaluation de Microsoft : que l'activité appartient à Storm-3168 ; que la combinaison de suppression, d'interférence avec la récupération et de collecte de clés est cohérente avec une attaque par rançongiciel et extorsion ; que l'exécution était probablement automatisée ou scriptée ; et que les clés collectées pourraient faciliter une exfiltration future. Le rapport public de Microsoft ne décrit pas un agent autonome raisonnant sur les étapes spécifiques à Azure.

Ouvert : comment les principals de service ont été compromis pour la première fois ; l'identité de la victime et le nombre d'organisations touchées ; si des données ont quitté le tenant ; et si un agent IA, plutôt qu'un script, a lui-même dirigé les opérations Azure.

La Cloud Security Alliance a situé précisément cette lacune probante dans sa note du 28 septembre : la caractérisation « agentique », écrit-elle, repose actuellement « sur la précision, le tempo et la répartition du travail entre les identités », plutôt que sur des traces capturées du raisonnement de l’agent. Les preuves utilisées par Sysdig en juillet — des charges utiles qui se décrivent elles-mêmes et un cycle rapide de diagnostic et correction — sont absentes du dossier public de la campagne Azure. Nick Tausek, de la société de sécurité Swimlane, a déclaré à CSO Online que les preuves relatives à Azure montrent « une automatisation coordonnée plutôt que la démonstration que l’IA a dirigé chaque étape ».

La couverture de la divulgation a utilisé le cadrage plus fort. Le titre de BleepingComputer décrivait des « attaques d’IA agentiques » contre Azure, et celui de Dark Reading décrivait un « acteur IA » compromettant un locataire Azure ; le rapport de Microsoft lui-même indique que le moment et la répartition des tâches « indiquent fortement une exécution automatisée ou scriptée » et n’attribue pas les étapes Azure individuelles à un agent.

L’archive attribue à cette fiche une confiance A et ne la signale pas comme contestée. Le label « confirmé » d’implication de l’IA attribué à cette fiche repose sur l’attribution à JADEPUFFER, l’acteur que Sysdig a documenté comme piloté par un LLM ; il ne s’agit pas d’affirmer que Microsoft a capturé le raisonnement d’un agent lors des suppressions Azure. Le préjudice est établi, l’automatisation est établie, et l’autonomie est déduite.

Ce que Microsoft dit devoir changer

Les recommandations de Microsoft sont opérationnelles et découlent directement du mode de fonctionnement de cette intrusion. Elles demandent aux défenseurs d’activer les plans Microsoft Defender for Cloud appropriés pour Resource Manager, Storage, Key Vault, App Service et Bases de données ; de garder les informations d’identification du principal de service, les clés de stockage, les chaînes de connexion et autres secrets hors du code source, de la configuration, des dépôts et des tickets ; d’utiliser Microsoft Entra Workload ID au lieu de secrets de longue durée ; d’appliquer le principe du moindre privilège et de revoir les attributions Azure RBAC pour les identités de charge de travail ; et de restreindre et surveiller les ressources de sauvegarde et de récupération, y compris les tentatives de modification de leurs contrôles de protection.

Le rapport public de Microsoft ne précise pas si le locataire a restauré ses données, si la victime a été notifiée, ni si l’une des clés collectées a été utilisée par la suite. Ces résultats ne figurent pas dans le dossier. Ce que le dossier contient, en revanche, c’est un contraste mesurable : les verrous de ressources et la protection contre la suppression ont bloqué certaines suppressions, même face à des identités disposant de privilèges étendus, tandis que les bases de données SQL ont été sauvées par une erreur de version d’API plutôt que par la décision d’un défenseur. Le compte rendu de Microsoft ne dit pas ce que le locataire a fait ensuite. Il dit en revanche que l’acteur a passé plus de 15 heures à lire avant de passer sept minutes à supprimer.