veilletech.frCe qui se passe
Microsoft a publié le 25 septembre l'analyse d'une attaque menée début juin contre le tenant Azure d'un de ses clients, qu'il suit sous le nom Storm-3168 et rattache au groupe JADEPUFFER. Ce groupe était apparu en juillet chez Sysdig, pour une attaque au rançongiciel conduite de bout en bout avec l'aide d'un LLM, entrée par la faille Langflow CVE-2025-3248.
L'origine de l'accès n'est pas établie. Mais Microsoft a constaté que l'ID client, le secret et l'ID de tenant d'un service principal avaient été collés en clair dans une issue GitHub publique par un employé. Le texte a été retiré ; l'ancienne version restait consultable dans l'historique d'édition, public lui aussi.
Le déroulé
Deux service principals du même tenant, chacun son rôle, sur environ 18 heures :
- Repérage, ~16 h : le premier lit machines virtuelles, abonnements, groupes de ressources, plus de 300 opérations de lecture. Le second fait sa propre reconnaissance 90 minutes plus tard, deux abonnements parcourus en cinq secondes.
- Recherche de secrets : le second service principal lit les magasins de configuration App Service.
- Destruction : plus de 150 opérations destructrices ou de collecte d'identifiants en 35 minutes, dont une séquence de sept minutes avec plus de 100 tentatives de suppression de comptes de stockage, plus un Key Vault, une Function App, un plan App Service et plusieurs bases Azure SQL.
La cible incluait les ressources de sauvegarde et de reprise : l'objectif ressemble à celui d'un rançongiciel, même si aucune demande de rançon ni exfiltration n'a été observée. Microsoft voit par ailleurs la même infrastructure sonder les App Services d'autres clients, sans doute de façon automatisée.
Ce qui a tenu
La plupart des comptes de stockage ont été supprimés. Quelques-uns ont résisté, protégés par un verrou de ressource ou par la protection contre la suppression du compte de stockage : des garde-fous qui tiennent même face à une identité aux droits d'administration étendus. Les bases SQL ont survécu, mais par hasard : l'attaquant utilisait une version d'API refusée pour ce type de ressource.
Comment s'y prendre
- Un secret publié se révoque, même retiré au bout d'une minute. GitHub permet de supprimer une révision de l'historique d'un commentaire, mais la copie a pu être faite avant.
# Remplace les identifiants de l'application (sans --append, les anciens sont retirés)
az ad app credential reset --id <appId>- Verrouiller ce qui ne doit pas disparaître, sauvegardes en premier :
az lock create --name ne-pas-supprimer --lock-type CanNotDelete --resource-group <groupe>- Retirer les rôles Owner aux identités d'automatisation : un verrou se supprime avec les droits adéquats. Préférer les identités managées ou la fédération d'identité aux secrets clients quand c'est possible.
Source : JADEPUFFER-Linked Attackers Used Compromised Service Principals to Delete Azure Resources, The Hacker News, 28 septembre 2026, d'après l'analyse de Microsoft (Yossi Weizman, Tushar Mudi) du 25 septembre.