Microsoft a révélé une vaste activité malveillante au sein d’un environnement Azure, qu’elle a attribuée au groupe Storm-3168, également connu pour ses liens avec JADEPUFFER. L’attaque s’est appuyée sur deux identités de service (service principals) compromises pour effectuer une reconnaissance des ressources, supprimer des services cloud et tenter de collecter des identifiants susceptibles d’être utilisés pour accéder aux données ou de faciliter leur exfiltration ultérieure.
Microsoft affirme que l’enquête fournit la première description détaillée de l’activité de Storm-3168 dans Azure et élargit les connaissances disponibles sur JADEPUFFER, que Sysdig avait signalé en juillet 2026 comme étant la première opération de rançongiciel documentée reposant sur des agents. Microsoft n’a pas confirmé que l’incident avait impliqué une exfiltration réussie de données et n’a pas non plus détecté de demande de rançon.
Reconnaissance avant le sabotage
Début juin 2026, l’une des identités de service a consacré environ 15 heures et 30 minutes à l’énumération des machines virtuelles, des abonnements, des groupes de ressources et des ressources, avec plus de 300 opérations de lecture réussies. Environ 90 minutes plus tard, la seconde identité a énuméré les machines virtuelles et les groupes de ressources dans deux abonnements en seulement cinq secondes.
Les deux identités ont utilisé une infrastructure liée à Storm-3168, une même empreinte réseau et l’agent utilisateur python-requests/2.34.2. Seize heures plus tard, la seconde identité a analysé les magasins de configuration d’App Service, probablement à la recherche d’identifiants exposés, puis a tenté d’accéder à des ressources Azure OpenSearch sans succès, avant d’effectuer une tentative ListKey contre un compte de stockage inexistant.
Suppression de ressources et collecte de clés
Moins d’une seconde après l’échec de la tentative ListKey, la série d’actions malveillantes a commencé. La seconde identité a exécuté plus de 150 opérations liées à la suppression ou à la collecte d’identifiants en 35 minutes, tandis que la phase principale du sabotage a duré environ sept minutes.
Ces activités comprenaient plus de 100 tentatives de suppression de comptes Azure Storage, dont la plupart ont réussi, ainsi que la suppression d’Azure Key Vault, d’une Function App et d’un plan App Service. Des tentatives parallèles de suppression de bases de données Azure SQL ont également été menées, mais elles ont échoué en raison de l’utilisation d’une version non prise en charge de l’interface de programmation d’application. Les attaquants ont aussi tenté de supprimer des verrous associés à Azure Site Recovery et Azure Backup, des ressources destinées à protéger la restauration.
Environ 30 minutes après la dernière opération de sabotage, l’identité a exécuté plus de 30 requêtes ListKeys réussies, renvoyant des clés d’accès à des comptes de stockage, dont certains étaient associés à Azure Site Recovery.
Qu’est-ce que cela signifie pour les défenseurs ?
Microsoft estime que la combinaison de la suppression de ressources, du ciblage des contrôles de sauvegarde et de restauration et de la tentative d’obtention de clés de stockage correspond à des tactiques susceptibles de soutenir des opérations de rançongiciel et d’extorsion. Toutefois, la source ne prouve pas à elle seule que l’objectif final était d’extorquer la victime ou que les données ont effectivement été exfiltrées.
L’enquête souligne également l’importance de barrières indépendantes : les verrous de ressources et la protection contre la suppression au niveau de certains comptes de stockage ont empêché d’autres opérations de suppression, même si l’identité compromise disposait de vastes privilèges administratifs. En revanche, les rôles Azure RBAC attribués au groupe ou directement à l’identité de service ont permis d’exécuter les opérations de sabotage qui relevaient de leur périmètre d’autorisation.
Mesures de protection recommandées
- Faire immédiatement tourner ou révoquer tout identifiant exposé : supprimer le secret d’une publication publique ne le rend pas invalide, et il peut rester dans l’historique des modifications, la mémoire cache ou les archives.
- Appliquer le principe du moindre privilège aux identités de service et examiner les rôles Azure RBAC ainsi que les ressources auxquelles chaque identité peut accéder.
- Protéger les ressources de sauvegarde et de restauration et surveiller les tentatives de modification ou de suppression de leurs verrous.
- Activer les plans appropriés de Microsoft Defender for Cloud, notamment la protection de Resource Manager, Storage, Key Vault, App Service et des bases de données.
- Utiliser les capacités d’investigation et de réponse assistées par l’intelligence artificielle, telles que Project Perception, tout en sécurisant les applications d’intelligence artificielle et les systèmes agentiques.