150 opérations destructrices en 35 minutes
Microsoft a publié une analyse d’une intrusion dans le cloud au cours de laquelle un attaquant qu’elle suit sous le nom de Storm-3168 a tenté plus de 150 opérations destructrices ou de collecte d’identifiants dans un locataire Azure en 35 minutes. La phase de suppression elle-même a duré environ sept minutes et a compté plus de 100 tentatives de suppression de comptes de stockage.
Sysdig, qui a documenté le groupe pour la première fois en juillet, le suit sous le nom de JADEPUFFER et le décrit comme la première opération de rançongiciel documentée pilotée par un grand modèle de langage.
Les cibles étaient des comptes de stockage Azure, où la plupart des suppressions ont abouti; des coffres de clés; des bases SQL, où les tentatives ont échoué faute de versions d’API prises en charge; des Function Apps et des plans App Service; et les verrous de protection d’Azure Site Recovery et d’Azure Backup — c’est-à-dire les contrôles qui rendent la restauration possible.
L’entrée était un ticket GitHub public
Le point d’entrée est ce que les défenseurs devraient lire deux fois. Microsoft indique que les attaquants ont utilisé deux principaux de service compromis dans le même locataire — ces identités non humaines qui permettent aux applications et aux outils automatisés de s’authentifier auprès d’Azure.
Leurs identifiants, écrit Microsoft, « avaient précédemment été exposés en clair dans un ticket GitHub public ». Le secret a ensuite été retiré, mais il « restait accessible via l’historique public des modifications du ticket ».
Rien de tout cela n’exige d’IA. Ce qui suggère une orchestration, c’est la vitesse: la chronologie de Microsoft montre le premier principal de service énumérant des ressources pendant 15,5 heures, le second démarrant 90 minutes plus tard, un balayage de configuration App Service au bout de 16 heures, puis la phase de destruction de sept minutes et une collecte d’identifiants 30 minutes après.
Pas de demande de rançon
Le détail inhabituel est ce qui n’a pas eu lieu. Microsoft l’écrit sans détour: « Nous n’avons pas observé de demande de rançon ni confirmé d’exfiltration réussie de données dans l’activité décrite ici. »
Pourtant l’attaquant a d’abord supprimé les verrous de sauvegarde et de restauration, ce que fait précisément une opération d’extorsion pour que payer devienne la seule issue. Soit la demande est passée par un canal que Microsoft n’a pas vu, soit la destruction était le but.
Microsoft présente le cas comme un exemple d’« attaques orchestrées par l’IA, où des acteurs malveillants peuvent coordonner des opérations complexes après compromission dans des environnements cloud, avec plus de vitesse et d’ampleur ». Son propre billet ne précise pas quel système d’agents Storm-3168 a employé, et la distinction mérite d’être notée: la vitesse est documentée, l’attribution de cette vitesse à un modèle relève de la caractérisation du groupe par Sysdig et non d’une démonstration de Microsoft dans ce billet.
Quoi faire
Les parades de Microsoft sont peu spectaculaires et pour l’essentiel antérieures aux agents: activer Defender for Cloud, garder les identifiants hors des dépôts et des fils de tickets, faire tourner immédiatement les identifiants exposés, appliquer le moindre privilège aux principaux de service et protéger l’infrastructure de sauvegarde. L’entreprise recommande aussi ses propres outils de défense à base d’agents.
La leçon transposable est plus étroite. Un secret collé dans un ticket GitHub il y a deux ans a toujours été un risque. Ce qui a changé, c’est le peu de temps dont dispose désormais un défenseur entre le moment où l’identifiant est trouvé et celui où les comptes de stockage ont disparu.
