JadePuffer détruit des ressources Azure en sept minutes via une attaque par proxy

Vue d'ensemble de l'incident

En juin 2026, l’équipe de sécurité de Microsoft a publié, sur le Microsoft Security Blog, deux incidents distincts impliquant des attaques contre Azure utilisant des identités de service compromises. Les attaquants, désignés sous le nom de code JadePuffer et suivis en interne sous le numéro Storm‑3168, ont d’abord réussi à obtenir les informations d’authentification d’une identité de service. Une fois ces informations en main, ils ont agi en tant que proxy, c’est‑à‑dire qu’ils ont utilisé l’identité volée pour exécuter un grand nombre d’opérations de lecture, d’écriture et de destruction sur les ressources cloud ciblées. Les deux incidents se sont produits dans des locataires Azure différents, ce qui montre que la technique pouvait être répliquée de manière indépendante dans plusieurs environnements. Cette méthode d’abus d’identité de service souligne la nécessité pour les organisations de surveiller de près les permissions accordées aux identités automatisées et de mettre en place des contrôles de détection d’anomalies.

Méthodes d'attaque et chronologie

Dans le premier incident, l’identité de service compromise a été utilisée pendant environ quinze heures et trente minutes pour mener une phase de reconnaissance continue. Au cours de cette période, plus de trois cents requêtes de lecture ont été effectuées, ce qui indique un balayage intensif des ressources disponibles. Le second incident, en revanche, a été beaucoup plus rapide : en seulement trente‑cinq minutes, les attaquants ont lancé plus d’une centaine et demie d’actions de destruction ou de collecte d’informations d’identification. La séquence de destruction principale s’est concentrée sur une fenêtre d’environ sept minutes, pendant laquelle ils ont tenté de supprimer plus d’une centaine de comptes de stockage Azure. Le volume élevé de requêtes de lecture et de destruction indique que les attaquants disposaient d’un script automatisé capable de s’adapter rapidement aux réponses du système et de poursuivre l’opération tant que les privilèges le permettaient.

Durant ces sept minutes critiques, les assaillants ont d’abord procédé à l’énumération des ressources cibles, récupérant les identifiants et les métadonnées nécessaires pour préparer les actions de suppression. Ils ont ensuite invoqué l’API Delete afin de tenter de retirer les comptes de stockage ainsi que d’autres services associés. Bien que de nombreuses ressources aient été protégées au préalable par des verrous de ressources ou des mécanismes de protection contre la suppression, ces mesures ont seulement partiellement bloqué les requêtes de suppression. Malgré ces protections, un volume important de tentatives a été généré, ce qui montre que les scripts automatisés des attaquants étaient capables d’émettre des appels à grande fréquence, dépassant les limites normales d’utilisation. L’efficacité de leurs scripts a également été démontrée par la rapidité avec laquelle ils ont pu passer de la phase de découverte à la phase de suppression, exploitant ainsi le court laps de temps avant que les mécanismes de défense ne réagissent.

• Plus de 100 tentatives de suppression de comptes de stockage
• Plus de 150 opérations de destruction ou de collecte d’identifiants
• Plus de 300 requêtes de lecture de reconnaissance (premier incident)
• Plus de 30 appels ListKeys (environ 30 minutes plus tard)

Preuves et sources

Microsoft classe ce type d’attaque sous la désignation Storm‑3168 et indique que les acteurs malveillants ont exploité les informations d’identification de l’identité de service obtenues pour mener des opérations en mode proxy. Un article d’iThome a également signalé que certaines des informations d’identification compromises avaient été publiées dans un ticket public sur GitHub, bien que Microsoft n’ait pas confirmé que ces identifiants étaient directement à l’origine de l’intrusion. Cette situation met en évidence le risque que représentent les fuites de secrets dans les dépôts publics, même lorsqu’ils ne sont pas directement liés à une compromission confirmée.

Au cours de l’enquête, Microsoft n’a détecté aucun courriel de rançon et n’a trouvé aucune preuve claire d’une fuite de données. La seule activité supplémentaire observée a eu lieu environ trente minutes après les premières actions, lorsque les attaquants ont réussi à lancer plus de trente requêtes ListKeys, indiquant qu’ils poursuivaient leurs tentatives d’obtention de clés supplémentaires. L’absence de demande de rançon ou de fuite de données publique suggère que l’objectif principal des attaquants était probablement la perturbation ou la collecte d’informations d’identification pour des usages futurs.

Impact et efficacité des défenses

Les verrous de ressources (resource lock) et la protection contre la suppression (delete protection) ont joué un rôle de défense essentiel dans cet incident, empêchant la suppression effective de la majorité des comptes de stockage ciblés. En revanche, les tentatives de suppression visant les bases de données Azure SQL ont échoué parce que la version de l’API utilisée n’était pas prise en charge, ce qui a limité davantage les pertes potentielles. Ces résultats confirment que la combinaison de verrous de ressources et de protections de suppression constitue une première ligne de défense efficace, mais qu’elle doit être complétée par d’autres mesures de sécurité.

Bien que ces mécanismes de défense aient bloqué une partie des actions destructrices, les attaquants ont tout de même réussi à répertorier les ressources et à extraire des clés, ce qui montre que le simple recours aux verrous de ressources n’est pas suffisant pour empêcher complètement les intrusions de type proxy. Microsoft recommande aux locataires affectés de vérifier immédiatement l’utilisation de toutes les identités de service, d’activer l’accès conditionnel et d’appliquer le principe du moindre privilège afin de réduire la surface d’attaque. En outre, l’activation de l’audit des journaux d’accès aux identités de service et la mise en place de limites de taux pour les appels API peuvent aider à détecter et à limiter de telles activités malveillantes.

Parmi les évolutions prévues en matière de sécurité, Microsoft prévoit d’ajouter des alertes en temps réel sur les comportements anormaux des identités de service dans le service de surveillance Azure, ainsi que de renforcer les contrôles de compatibilité des versions d’API afin de réduire les vecteurs d’attaque qui reposent sur des API obsolètes. Les entreprises sont également invitées à faire tourner régulièrement les clés des identités de service et à étendre les politiques de protection contre la suppression aux ressources jugées sensibles, afin d’améliorer la résilience globale de leurs environnements cloud. Microsoft prévoit également d’intégrer des analyses comportementales basées sur l’intelligence artificielle afin d’identifier les modèles d’utilisation anormaux avant même qu’une compromission ne se produise.