Storm‑0501 : l’attaque par ransomware sans ransomware qui inquiète Microsoft

Pas de binaire suspect, mais des données chiffrées et des sauvegardes détruites. Microsoft met en garde contre une nouvelle méthode d’extorsion dans le cloud, où tout se joue depuis l’intérieur de l’infrastructure, sans déploiement de ransomware.

Le 27 août, Microsoft a publié un rapport inquiétant sur l’évolution des tactiques de Storm‑0501, un groupe de cybercriminels actif depuis 2021. Longtemps spécialisé dans le déploiement de ransomwares comme Sabbath, Hive, BlackCat ou Embargo, le gang privilégie désormais une approche plus discrète et beaucoup plus directe. Car plutôt que d’infecter les machines, les attaquants prennent le contrôle des environnements Azure et Entra ID, utilisent les outils natifs du cloud pour verrouiller l’accès aux données, détruisent les sauvegardes, puis déclenchent la phase d’extorsion. Une méthode qui s’appuie exclusivement sur les capacités offertes par l’infrastructure cible, sans injection de charge utile, et qui redéfinit les contours des attaques par ransomware dans le cloud.

Chiffrement, effacement, extorsion : quand le cloud se retourne contre lui-même

Jusqu’en 2024, Storm‑0501 menait des attaques classiques avec ransomware, en ciblant des environnements hybrides. Le groupe commençait par compromettre des équipements Active Directory exposés, prenait la main sur le système, puis déployait un ransomware pour chiffrer les postes et serveurs. Mais d’après les observations de Microsoft, ses campagnes ont progressivement évolué vers une approche plus discrète, délaissant les charges malveillantes au profit d’un contrôle direct de l’infrastructure cloud. En prenant la main sur les identités et les ressources Azure, les attaquants pilotent désormais leurs extorsions sans installer de binaire suspect.

Dans l’attaque décrite par Microsoft, les assaillants prennent d’abord le contrôle d’un serveur Active Directory mal sécurisé, déjà doté de privilèges élevés. Ils s’en servent ensuite comme point d’accès pour explorer le réseau interne et identifier les postes et serveurs non protégés par Microsoft Defender, en quête d’un serveur Entra Connect, chargé de synchroniser les identités entre l’annuaire local et Azure. Une fois le serveur infiltré, ils y récupèrent le compte de synchronisation, sésame qui leur permet ensuite de cartographier les utilisateurs, les rôles et les ressources dans le cloud. Objectif : repérer un compte Entra ID très privilégié mais mal sécurisé, qui leur donnerait un accès complet à l’environnement cloud.

C’est ce qu’ils finissent par trouver : un compte non humain, synchronisé automatiquement, possédant les droits d’administrateur global sur Entra ID… et surtout, sans authentification multifacteur. Il leur suffit alors de réinitialiser son mot de passe dans l’annuaire local pour que la modification soit automatiquement synchronisée dans le cloud.

Dès lors, les portes sont grandes ouvertes. Les attaquants peuvent se connecter directement à l’environnement cloud avec ce compte ultra-privilégié comme s’ils étaient l’utilisateur légitime, en respectant au passage les règles d’accès internes imposées par l’entreprise, enregistrer leur propre méthode MFA, puis élever leurs droits pour s’attribuer le contrôle des ressources Azure et exfiltrer les données sensibles vers leur propre infrastructure. Ils ajoutent aussi une porte dérobée via un domaine fédéré frauduleux, qui leur permet de revenir plus tard et d’usurper presque n’importe quel compte même après des changements de mots de passe.

S’ensuit une vague de suppressions massives – snapshots, sauvegardes, comptes de stockage… tout y passe – pour empêcher toute tentative de récupération, suivie du chiffrement des ressources impossibles à effacer à l’aide de clés générées et appliquées via les fonctions natives d’Azure. Évidemment, ces clés sont ensuite supprimées à leur tour, de manière à verrouiller l’accès aux données restantes (action toutefois réversible grâce au soft-delete d’Azure Key Vault activée par défaut pendant 90 jours).

Et voilà comment les pirates de Storm-0501 ont réussi à mener une attaque par ransomware sans ransomware, à la mano, en s’appuyant uniquement sur des outils légitimes et les bons privilèges. Ne leur restait plus qu’à passer à la phase d’extorsion, en contactant leurs victimes via Microsoft Teams – toujours dans le thème – depuis les comptes compromis.

Comment limiter les dégâts et protéger les environnements cloud

Dans toute cette affaire, Storm‑0501 n’a finalement eu qu’à dérouler. Tout s’est joué sur des fonctions natives, des droits mal configurés et des comptes mal protégés. Une attaque presque trop simple, qui, selon Microsoft, marque un tournant.

Il est donc impératif d’adopter un changement de posture : moins de réflexes antivirus, plus de contrôle sur les identités, les droits, et les mécanismes de synchronisation entre le local et le cloud. Priorité absolue doit être donnée à la protection des comptes admin – activer l’authentification multifacteur partout, privilégier les clés matérielles FIDO2 et vérifier régulièrement les rôles Owner et Global Administrator pour repérer les attributions anormales.

Il est tout aussi primordial de surveiller les journaux d’activité, notamment les accès aux Key Vaults, les modifications de stratégies de sauvegarde et les tentatives de suppression de ressources. N’oubliez pas non plus de segmenter les environnements cloud, d’activer les fonctions avancées de Defender for Cloud et de configurer Defender XDR pour détecter les comportements suspects.

Enfin, les procédures de restauration doivent être testées régulièrement. Les sauvegardes doivent être isolées de l’environnement de production et protégées contre toute tentative de suppression ou de chiffrement via le cloud.

Source : Microsoft Threat Intelligence