Des identités d’application Azure dérobées ont permis à JadePuffer de détruire des ressources dans le cloud

Microsoft attribue à JadePuffer des activités destructrices au sein de tenants Azure. L’entreprise suit cet acteur sous le nom de Storm-3168. Lors d’un incident documenté en détail, l’attaquant a pris le contrôle de deux principaux de service. Il s’en est servi pour découvrir des ressources, récupérer des identifiants, supprimer des services cloud et entraver les mécanismes de protection et de restauration.

Microsoft a publié son compte rendu le 25 septembre 2026 et décrit des activités remontant au début du mois de juin. Selon d’autres informations, Microsoft aurait observé deux attaques en juin, même si le compte rendu détaillé porte principalement sur une seule séquence.

L’opération a causé des dégâts considérables sans exploiter de vulnérabilité logicielle divulguée. JadePuffer a plutôt agi au moyen d’identités d’application compromises, dont les autorisations permettaient d’effectuer des opérations pouvant passer pour de l’administration cloud légitime.

Deux principaux de service se sont réparti les tâches

Les principaux de service Azure sont des identités d’application utilisées par des logiciels et des processus automatisés pour s’authentifier et accéder aux ressources. Ils peuvent recevoir des autorisations de contrôle d’accès en fonction du rôle (RBAC) Azure, sans qu’un compte utilisateur interactif soit nécessaire.

JadePuffer a compromis deux de ces identités au sein d’un même tenant. La première a principalement servi à cartographier l’environnement pendant environ 15,5 heures. Elle a effectué avec succès plus de 300 opérations de lecture sur des machines virtuelles, des abonnements, des groupes de ressources et d’autres ressources Azure.

La seconde identité a agi bien plus rapidement. Environ 90 minutes après le début de la reconnaissance à plus grande échelle, elle a recensé des machines virtuelles et des groupes de ressources dans deux abonnements, en seulement cinq secondes.

Cette répartition évoque un processus organisé : une identité a dressé un inventaire général, tandis que l’autre a mené des opérations de reconnaissance ciblées et des actions destructrices. Les éléments disponibles ne permettent toutefois pas de déterminer si cette répartition était pilotée par l’IA, par une automatisation classique ou par des instructions directes d’un opérateur.

Les chercheurs de Microsoft Yossi Weizman et Tushar Mudi ont indiqué qu’un tel niveau de reconnaissance pouvait donner à un attaquant une visibilité sur l’ensemble de l’environnement Azure d’une victime. L’opération ne se limitait donc pas à repérer des charges de travail isolées.

Le second principal de service a également interrogé les magasins de configuration d’Azure App Service, potentiellement à la recherche d’identifiants intégrés aux paramètres des applications. Il a tenté, sans succès, de trouver des ressources Azure OpenSearch, ainsi que d’exécuter une opération ListKey sur un compte de stockage qui n’existait pas.

Moins d’une seconde après l’échec de cette requête, les suppressions ont commencé.

Des comptes de stockage et des services associés ont été supprimés en quelques minutes

L’attaquant a tenté de supprimer plus de 100 comptes Azure Storage, et la plupart de ces opérations ont abouti. Un Azure Key Vault, une Function App et un App Service plan du même groupe de ressources ont également été supprimés.

Selon les informations publiées sur les attaques Azure observées, la phase destructrice a duré environ sept minutes. Elle a visé des machines virtuelles et des App Services, ainsi que des comptes de stockage, des Key Vaults et des Function Apps. La description plus détaillée de Microsoft fait état de la découverte de machines virtuelles, mais ne signale aucune suppression confirmée de ces dernières.

JadePuffer a aussi tenté de supprimer plusieurs bases de données Azure SQL. Ces tentatives ont échoué parce que l’acteur avait indiqué une version d’API non prise en charge. Même une séquence automatisée très rapide peut donc échouer si les requêtes ne sont pas adaptées au service ciblé.

L’opération s’est ensuite de nouveau concentrée sur le stockage. Environ 30 minutes après la phase de suppression, le principal de service compromis a demandé un inventaire des comptes Azure Storage, notamment ceux associés à Azure Site Recovery.

Il a ensuite effectué avec succès plus de 30 requêtes ListKeys, qui lui ont permis d’obtenir des clés d’accès aux comptes de stockage. Selon leur configuration, ces clés peuvent donner un accès direct aux comptes, indépendamment des autorisations RBAC Azure initialement attribuées au principal de service.

L’attaquant a également tenté d’affaiblir les mesures de sauvegarde et de restauration. Ses tentatives de suppression des verrous Azure Site Recovery ont échoué, tandis que les verrous de ressources et les protections appliquées au niveau des comptes de stockage ont empêché la suppression de certains comptes ciblés.

Ces protections ont eu un effet concret : elles n’ont pas stoppé l’opération, mais en ont limité la portée.

Un secret GitHub pourrait expliquer l’accès, mais l’attribution reste incertaine

Microsoft n’a pas pu déterminer précisément comment les deux principaux de service avaient été compromis. L’entreprise a toutefois découvert une exposition potentielle importante concernant l’une des identités.

Un employé de l’organisation touchée avait publié en clair l’identifiant client, le secret client et l’identifiant du tenant du principal de service dans un ticket GitHub public. Le ticket a ensuite été modifié pour supprimer le secret, mais sa valeur d’origine restait accessible dans l’historique public des modifications.

Microsoft n’a pas pu confirmer que JadePuffer avait obtenu ou utilisé cet identifiant exposé. Il s’agit donc d’une voie d’accès plausible, et non d’un accès initial avéré.

Cette distinction est importante : supprimer un secret de la version actuelle d’une publication ne suffit pas à effacer les copies, le contenu mis en cache, l’historique du dépôt ou les traces de modification conservées par la plateforme. Dès qu’un identifiant a été publié sur un système public, les équipes de défense doivent le considérer comme compromis et le renouveler, plutôt que de compter sur la suppression du contenu.

Comme l’a fait remarquer Ross Filipek, RSSI de Corsica Technologies, les opérations réalisées au moyen d’une identité d’application peuvent aussi ressembler à de l’administration cloud normale. La détection peut s’en trouver compliquée si la surveillance se concentre sur les échecs de connexion ou les sessions humaines suspectes, plutôt que sur les comportements inhabituels des identités de charges de travail au niveau des API.

Depuis le début de l’année, Microsoft a également observé des infrastructures liées à JadePuffer sonder des Azure App Services chez plusieurs clients. Parmi les chemins testés figuraient des chemins d’administration WordPress, PHP-CGI, le point de terminaison de validation de code de LangFlow à l’adresse /api/v1/validate/code, ainsi que des chemins évoquant des emplacements de web shells.

On ignore si ces sondes ont conduit à la compromission décrite ici.

Le mode opératoire évoque un rançongiciel, mais le recours à l’IA est moins certain

Microsoft a estimé que ces activités correspondaient à des tactiques de rançongiciel ou d’extorsion. La suppression de ressources de production, les tentatives d’obtention de clés de stockage et les efforts visant à entraver la restauration s’inscrivent dans une stratégie de pression destructrice.

Les enquêteurs n’ont toutefois trouvé aucune note de rançon, n’ont confirmé aucune demande financière et n’ont pas établi qu’une exfiltration de données avait abouti. Qualifier l’incident d’attaque par rançongiciel décrit donc le mode opératoire apparent, et non une extorsion menée à son terme et vérifiée.

En juillet, Sysdig a présenté JadePuffer comme la première opération de rançongiciel documentée à être pilotée par un grand modèle de langage, selon les articles consacrés aux conclusions de Microsoft et aux activités antérieures de l’acteur. Son analyse décrivait des agents d’IA automatisant plusieurs étapes, dont la reconnaissance, le vol d’identifiants, les déplacements latéraux, la persistance et le chiffrement.

JadePuffer aurait ensuite élargi ses cibles aux ressources d’IA, aux jeux de données d’entraînement et aux bases de données vectorielles, en utilisant un outil appelé EncForge.

L’incident Azure témoigne bien d’une automatisation hautement coordonnée. Il ne prouve pas, à lui seul, qu’un agent d’IA a choisi ou dirigé chaque appel d’API.

Nick Tausek, architecte principal de l’automatisation de la sécurité chez Swimlane, a établi cette distinction tout en approuvant la mise en garde générale de Microsoft : l’IA agentique pourrait permettre aux attaquants d’agir plus vite et sur davantage de ressources, mais une coordination rapide ne prouve pas que l’IA a piloté l’ensemble de la séquence.

Pour les équipes de défense, le risque concret est similaire dans les deux cas. Les identités cloud peuvent effectuer des centaines de requêtes de reconnaissance et de suppression bien plus vite qu’une équipe de réponse humaine ne peut les examiner manuellement.

Les équipes de défense doivent renouveler les identifiants exposés et limiter les droits des identités d’application

Les organisations qui utilisent Azure devraient commencer par recenser les principaux de service disposant de droits étendus sur le stockage, les systèmes de restauration, les Key Vaults, les configurations d’applications et les opérations de suppression de ressources. Les attributions RBAC Azure doivent être vérifiées au regard du principe du moindre privilège, en particulier lorsqu’une même identité peut agir sur plusieurs abonnements.

Microsoft recommande plusieurs mesures :

• Activer les offres Microsoft Defender for Cloud adaptées aux charges de travail Azure critiques.
• Vérifier en continu si des identifiants d’application et des secrets ont été exposés.
• Renouveler immédiatement tout identifiant publié ou dont la compromission est suspectée.
• Mettre en place des contrôles couvrant la création, le stockage, l’expiration et la révocation des secrets.
• Limiter les autorisations des principaux de service et des identités de charge de travail au strict nécessaire.
• Examiner les dépôts publics, les tickets, les commentaires et l’historique des révisions pour repérer les identifiants exposés.

Des verrous de ressources et des protections des comptes de stockage devraient également être mis en place lorsque cela est compatible avec les besoins opérationnels. Lors de cet incident, ils ont directement fait échouer certaines tentatives de suppression, notamment celles visant des ressources de stockage et de restauration protégées.

La surveillance doit prendre en compte les enchaînements d’événements, et pas seulement les événements isolés. Parmi les signaux d’alerte utiles figurent le recensement rapide de ressources sur l’ensemble des abonnements, l’accès aux magasins de configuration d’App Service, une rafale de requêtes ListKeys sur Azure Storage et un grand nombre d’opérations de suppression effectuées par un principal de service.

Microsoft a cité Project Perception et MDASH, des initiatives destinées à aider les équipes de défense à enquêter et à intervenir dans de grands environnements à l’aide de processus assistés par l’IA. Quelle que soit la technologie utilisée, le défi immédiat est clair : les identités d’application doivent être surveillées comme des acteurs privilégiés, et non considérées comme de simples processus d’arrière-plan fiables.