Cloud Azure : sept minutes pour tout effacer avec deux comptes techniques

Microsoft a décrit une attaque au cours de laquelle plus d’une centaine d’espaces de stockage ont été supprimés dans le cloud Azure d’une organisation, en sept minutes. Aucune faille logicielle n’a été utilisée : seulement deux comptes techniques aux droits trop larges, dont l’un avait vu ses identifiants publiés sur Internet.

Ce qui s’est passé

Le 25 septembre 2026, Microsoft a publié l’analyse d’une attaque menée début juin contre une organisation cliente d’Azure, son service de cloud. La victime n’est pas nommée. Microsoft suit l’attaquant sous le nom Storm-3168 et le rattache à JadePuffer, un groupe que la société Sysdig avait décrit en juillet comme l’un des premiers à automatiser ses attaques avec des agents d’intelligence artificielle.

L’intrusion a duré environ 18 heures selon The Hacker News, mais la phase de destruction n’a pris que sept minutes. Plus de 100 comptes de stockage (les espaces où sont rangés fichiers et sauvegardes) ont été visés, la plupart supprimés avec succès, ainsi qu’un coffre à secrets, des machines virtuelles et des applications. Microsoft n’a observé ni demande de rançon ni vol de données confirmé (BleepingComputer, 28 septembre 2026).

Comment l’attaque a fonctionné

Tout repose sur des « principaux de service » (service principals). Ce sont des comptes non humains : ils permettent à une application ou à un script de se connecter au cloud et d’agir sur les ressources. Ils n’ont pas de double authentification et disposent souvent de droits importants.

  1. Des identifiants qui traînaient. Microsoft n’a pas pu établir avec certitude comment l’attaquant a obtenu l’accès. Mais les identifiants de l’un des deux comptes avaient été publiés en clair par un salarié de la victime dans une discussion publique sur GitHub (une plateforme de partage de code). Le message avait été corrigé ensuite, mais le secret restait lisible dans l’historique des modifications et fonctionnait toujours.
  2. Le repérage. Pendant de longues heures, le premier compte a servi à dresser l’inventaire de l’environnement : machines, abonnements, ressources.
  3. La destruction. Le second compte a enchaîné les suppressions. Il a aussi tenté de retirer les protections qui servent à la reprise après sinistre, pour compliquer la restauration.
  4. La récupération de clés. Une trentaine de minutes plus tard, il a demandé, et obtenu, les clés d’accès de nombreux espaces de stockage.

Il n’y a pas eu de progression de poste en poste comme dans une attaque classique. L’attaquant a agi directement par les commandes d’administration du cloud, avec les droits des comptes volés. Chaque suppression n’est qu’une instruction, d’où la vitesse. Et comme ces comptes sont légitimes, rien ne distingue à première vue l’attaquant d’un script d’administration.

Tout n’a pas disparu pour autant. Des « verrous » posés sur certaines ressources et la protection contre la suppression des comptes de stockage ont bloqué une partie des effacements. Les bases de données ont survécu grâce à une erreur technique de l’attaquant. Des protections simples, souvent jugées secondaires, ont donc fait la différence.

Ce qu’on ne sait pas encore

On ne sait pas comment ni quand la victime a repéré l’attaque. La part réelle de l’intelligence artificielle ne peut pas être mesurée de l’extérieur : Microsoft estime seulement que l’enchaînement était probablement automatisé. Enfin, Microsoft ne peut pas affirmer que le secret publié sur GitHub est bien celui qui a été utilisé.

Ce que ça change pour une PME

Même une petite structure a des comptes techniques : la clé qui relie votre site à votre outil de facturation, le compte qui synchronise votre messagerie, le script de sauvegarde de votre prestataire.

  1. Faites l’inventaire des comptes non humains avec votre prestataire : à quoi sert chacun, qui en est responsable, quels droits il possède. Réduisez ces droits au strict nécessaire.
  2. Un secret publié est un secret à changer, pas seulement à effacer. Si un mot de passe ou une clé a été collé dans un ticket, un e-mail ou un dépôt de code, remplacez-le immédiatement.
  3. Protégez ce qui ne doit pas disparaître. Activez les protections contre la suppression proposées par votre fournisseur de cloud et gardez au moins une sauvegarde hors de portée des comptes d’administration habituels.

Cet article prolonge notre 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.