Microsoft a décrit deux attaques destructrices menées par JadePuffer dans des environnements Azure, sans faille logicielle, uniquement avec des identités non humaines compromises. Cette analyse s’adresse aux auditeurs, RSSI et responsables sécurité : mode opératoire, correspondance avec MITRE ATT&CK, difficultés de détection, questions d’audit ISO 27001 et pistes de sensibilisation. Le billet de Microsoft n’a pas pu être consulté directement : tout ce qui suit vient du compte rendu de BleepingComputer du 28 septembre 2026, et la victime n’est pas nommée.
Pour une lecture orientée dirigeant, voir notre décryptage « Cloud Azure : sept minutes pour tout effacer avec deux comptes techniques ».
Contexte
- Acteur : JadePuffer, suivi par Microsoft sous le nom Storm-3168. Décrit par Sysdig comme un opérateur de rançongiciel qui utilise des agents IA pour automatiser la chaîne d’attaque (reconnaissance, vol d’identifiants, mouvement latéral, persistance, chiffrement). Sysdig a aussi signalé un intérêt pour les actifs IA (jeux d’entraînement, bases vectorielles) via un outil nommé EncForge.
- Victime : non publique. Un tenant Azure, secteur non précisé.
- Date : deux attaques observées en juin 2026 selon Microsoft ; publication Microsoft le 25 septembre 2026.
- Type : attaque destructrice dans le cloud (effacement de ressources), avec collecte d’identifiants. Microsoft n’a pas signalé de demande de rançon ni confirmé de vol de données dans les cas observés.
- Point à éclaircir : BleepingComputer indique que les deux attaques observées par Microsoft datent de juin, tout en écrivant que le logiciel malveillant est « apparu en juillet » (selon Sysdig). Nous relevons cette incohérence apparente sans pouvoir la trancher.
Mode opératoire : ce qui est documenté et ce qui ne l’est pas
| Étape | Ce qui est rapporté | Correspondance MITRE ATT&CK (notre lecture) |
|---|---|---|
| Accès initial | Microsoft n’a pas pu déterminer l’accès initial. Indice fort : les identifiants d’un des service principals figuraient dans une issue GitHub publique avant l’attaque. | T1078.004 Valid Accounts : Cloud Accounts ; T1552 Unsecured Credentials (secrets exposés publiquement) |
| Reconnaissance | Un premier service principal sert à cartographier les ressources du tenant. | T1580 Cloud Infrastructure Discovery ; T1526 Cloud Service Discovery |
| Collecte de secrets | Récupération des clés de comptes de stockage ; plus de 30 nouvelles demandes de clés environ 30 minutes après la destruction, la plupart réussies. | T1552 Unsecured Credentials (niveau technique ; nous n’avons pas identifié de sous-technique qui corresponde exactement à la lecture des clés via l’API de gestion Azure) |
| Affaiblissement de la reprise | Tentative de retrait des verrous d’Azure Site Recovery et des protections de reprise (échec partiel). | T1490 Inhibit System Recovery |
| Destruction | En 7 minutes : plus de 100 comptes de stockage ciblés, ainsi que des Key Vaults, Function Apps, VM et App Services. Tentative de suppression des bases Azure SQL (échec : version d’API non supportée). | T1485 Data Destruction |
La colonne MITRE est une lecture de notre part, à partir des faits décrits. Ce n’est pas une classification publiée par Microsoft.
Faits techniques à retenir
- Pas de mouvement latéral classique. L’attaquant ne passe pas de poste en poste. Il agit directement sur le plan de contrôle (API de gestion Azure) avec les droits des identités compromises. C’est ce qui explique la vitesse : chaque suppression est un simple appel d’API.
- Ce qui a limité l’impact : les verrous de ressources, les protections natives des comptes de stockage, et une erreur de l’attaquant sur l’API Azure SQL.
Ce qu’on ne sait pas
- Exfiltration et chiffrement : non confirmés dans les cas décrits. La collecte de clés après la destruction laisse penser à une volonté de garder un accès ou de récupérer des données, mais ce n’est pas établi publiquement.
- Accès initial : non déterminé par Microsoft, malgré l’indice de l’issue GitHub publique.
- Victime et secteur : non publiés.
Détection : pourquoi c’est difficile à voir à temps
Les éléments publics ne disent pas comment ni quand la victime a détecté l’attaque. Ce qu’on sait :
- Microsoft a pu reconstituer une chronologie précise : les journaux d’activité Azure existaient et ont été exploitables après coup.
- Ce qui a limité l’impact, ce n’est pas la détection, mais la prévention (verrous, protections natives, erreur de l’attaquant).
- Les actions sont faites par des identités légitimes du tenant, via des API normales. Sans règle d’alerte sur des suppressions en masse ou des demandes de clés inhabituelles, rien ne distingue à première vue un script d’administration d’un attaquant. Et 7 minutes, c’est souvent moins que le délai de prise en compte d’une alerte par un SOC (analyse de notre part).
Microsoft recommande notamment d’activer les protections de charges de travail cloud, de rechercher les secrets dans les dépôts publics et de revoir les permissions RBAC selon le moindre privilège (selon BleepingComputer, 28 septembre 2026).
Questions d’audit ISO 27001:2022
- A.5.16, A.5.18 et A.8.2 (gestion des identités, droits d’accès, droits d’accès privilégiés) : « Pouvez-vous me montrer l’inventaire à jour de vos service principals, comptes de service et identités applicatives cloud, avec pour chacun un propriétaire, les rôles attribués et la date de dernière revue ? Combien disposent d’un rôle de type Contributor ou Owner au niveau abonnement ? »
- A.5.17 et A.8.12 (informations d’authentification, prévention de la fuite de données) : « Quel dispositif détecte la présence de secrets (clés, mots de passe, jetons) dans vos dépôts de code, tickets et outils collaboratifs, y compris publics ? Quelle est la procédure et le délai de rotation quand un secret est trouvé ? Montrez-moi le dernier cas traité. »
- A.8.13 et A.5.30 (sauvegarde des informations, préparation des TIC à la continuité) : « Les ressources critiques sont-elles protégées par des verrous de suppression et une suppression différée (soft delete) ? Les sauvegardes sont-elles hors de portée des identités qui administrent la production (tenant ou compte séparé, immutabilité) ? Quand avez-vous testé une restauration après suppression d’une ressource cloud ? »
- A.8.15 et A.8.16 (journalisation, activités de surveillance) : « Quelles règles d’alerte existent sur les opérations de suppression en masse ou les demandes répétées de clés de stockage dans le plan de contrôle cloud ? Quel est le délai entre l’événement et la prise en charge par une personne ? »
Pistes de sensibilisation
- Atelier « Un secret dans un ticket » (équipes dev et ops) : partir d’une issue GitHub fictive contenant un secret d’application, et dérouler en 10 minutes ce qu’un attaquant peut en faire (lister les ressources, supprimer, récupérer des clés). Objectif : faire comprendre qu’un identifiant technique collé « pour déboguer » vaut une clé d’administration.
- Exercice de crise « 7 minutes » (management et SOC) : scénario de suppression massive de ressources cloud, avec la question « qui décide de couper quoi, et en combien de temps ? ». Utile pour confronter le délai réel de réponse à la vitesse d’une attaque automatisée.
À lire aussi : notre décryptage pour les dirigeants, « Cloud Azure : sept minutes pour tout effacer avec deux comptes techniques », et le bulletin de veille du 29 septembre 2026.
Analyse préparée avec l’aide d’une intelligence artificielle à partir de sources publiques, sous la responsabilité de KyNeo. Malgré nos contrôles, des erreurs peuvent subsister : en cas de doute, référez-vous aux sources citées. Les informations non confirmées sont signalées comme telles.