Rapport CTI technique du 2 octobre 2026
Résumé exécutif
Microsoft a publié le 25 septembre 2026 la première analyse détaillée de Storm-3168, l'acteur que Sysdig suit sous le nom JADEPUFFER et qu'il décrit comme la première opération de rançongiciel pilotée par agent autonome. L'intrusion étudiée ne repose sur aucune faille logicielle : elle part de deux service principals Azure légitimes du même tenant, dont les secrets avaient été exposés. Un identifiant a été publié en clair dans une issue GitHub publique par un employé de l'organisation victime, puis retiré, mais resté accessible via l'historique d'édition de l'issue.
Une fois ces identités non humaines détenues, l'acteur a agi à une vitesse qui trahit l'automatisation. Reconnaissance de deux souscriptions en cinq secondes, puis en 35 minutes plus de 150 opérations destructrices ou de vol de clés, dont une phase de destruction d'environ sept minutes. Plus de cent comptes de stockage visés, un Key Vault, une Function App et un App Service plan supprimés. Ce qui a sauvé une partie des données ne tient pas à la détection mais à des contrôles indépendants : verrous de ressources Azure et protection contre la suppression, actifs même quand l'identité compromise dispose de droits d'administration larges.
Chronologie
| Date | Événement |
|---|---|
| Juillet 2026 | Sysdig documente JADEPUFFER, qualifié de première opération de rançongiciel pilotée par agent |
| Début juin 2026 | Première identité : ~15 h 30 de reconnaissance, plus de 300 lectures réussies |
| +90 minutes | Seconde identité : énumération de VM et groupes de ressources sur deux souscriptions en 5 secondes |
| +16 heures | Seconde identité : lecture des magasins de configuration App Service, recherche de credentials exposés |
| Peu après | 35 minutes d'opérations destructrices et de vol de clés, dont ~7 minutes de destruction effective |
| 25 septembre 2026 | Publication du rapport Microsoft sur Storm-3168 |
Fiche acteur / campagne
Storm-3168 | Alias : JADEPUFFER (Sysdig) | Cible : identités cloud Azure (service principals)
Mode opératoire. L'acteur n'exploite pas de vulnérabilité pour l'accès initial dans ce cas : il réutilise des secrets de service principals exposés publiquement. Microsoft n'a pas pu confirmer avec certitude le vecteur exact, mais a retrouvé le client ID, le client secret et le tenant ID publiés en clair dans l'historique d'une issue GitHub de la victime. Deux identités compromises du même tenant se répartissent les rôles : l'une pour la reconnaissance, l'autre pour la découverte, la destruction et le vol de clés.
Signature technique. Même infrastructure réseau, même empreinte, même user agent python-requests/2.34.2 pour les deux identités. Jetons multiples utilisés en parallèle (jusqu'à deux jetons de suppression actifs simultanément pendant 70 secondes). Le minutage, la division du travail et les flux de jetons superposés indiquent une exécution scriptée ou agentique.
Droits utilisés. Aucune élévation de privilèges. Les suppressions de stockage s'appuient sur un rôle Storage Account Contributor hérité d'un groupe. Les suppressions d'App Service, Key Vault et Function App, ainsi qu'une récupération de clé, s'appuient sur un accès Contributor direct. Les tentatives sur Azure SQL utilisaient un accès SQL DB Contributor direct. L'accès était déjà en place.
Classement. Microsoft décrit un schéma cohérent avec un rançongiciel ou une extorsion, mais sans note de rançon observée ni exfiltration de données confirmée dans ce cas précis. Ce qui est établi : destruction, entrave à la restauration, collecte de clés.
Diagramme de la chaîne d'attaque
Vue radiale de la campagne : secret exposé, identités compromises, actions sur les ressources Azure, contrôles ayant résisté. Sources : Microsoft, Sysdig.
Analyse technique
Étape 1 : secret exposé, puis « retiré »
Le point de départ est un secret de service principal publié en clair dans une issue GitHub publique. L'issue a ensuite été éditée pour retirer le secret, mais l'historique d'édition public a continué de l'exposer. C'est la leçon centrale : retirer un secret d'un emplacement public ne l'invalide pas. Tout identifiant exposé, même brièvement, doit être considéré comme compromis et révoqué ou renouvelé.
Étape 2 : reconnaissance à deux identités
La première identité passe environ quinze heures et demie à lister VM, souscriptions, groupes de ressources, avec plus de 300 lectures réussies. Quatre vingt dix minutes plus tard, la seconde identité couvre deux souscriptions en cinq secondes. Seize heures après, elle inspecte les magasins de configuration App Service à la recherche de credentials, puis sonde sans succès des ressources OpenSearch. La différence de rythme entre une identité « humaine » et une identité scriptée est en soi un signal de détection.
Étape 3 : destruction et entrave à la restauration
Soixante dix secondes après une tentative de ListKey sur un compte de stockage inexistant, la destruction démarre. En 35 minutes, plus de 150 opérations destructrices ou liées aux clés. L'identité tente de supprimer plus de cent comptes de stockage et réussit sur la plupart, supprime un Key Vault, une Function App et un App Service plan du même groupe de ressources. Elle vise aussi les systèmes de sauvegarde : tentatives de retrait des verrous Azure Site Recovery et Azure Backup, ciblage de comptes de stockage dont les noms évoquent Terraform et les sauvegardes, pour compliquer la reprise.
Étape 4 : ce qui a tenu
Les verrous de ressources Azure et la protection contre la suppression des comptes de stockage ont bloqué plusieurs suppressions, malgré des droits d'administration larges sur l'identité compromise. Les suppressions de bases Azure SQL ont toutes échoué parce que le script utilisait une version d'API non supportée pour ce type de ressource. Une erreur technique côté attaquant a ainsi neutralisé une partie de l'attaque. Enseignement opérationnel : des contrôles indépendants de l'identité restent efficaces là où l'IAM seul échoue.
Étape 5 : collecte de clés pour plus tard
Une demi-heure après la dernière suppression, l'identité revient pour les clés. Elle inventorie les comptes de stockage et envoie plus de 30 requêtes ListKeys réussies, dont certaines sur des comptes liés à Azure Site Recovery. Un compte de stockage épargné lors de la destruction est ensuite visé par une récupération de clé réussie. La collecte de clés, même sans exfiltration confirmée, ouvre la porte à un vol de données ultérieur.
Indicateurs de compromission
| Type | Valeur |
|---|---|
| User agent | python-requests/2.34.2 |
| IPv4 (sondage/requêtes) | 45.131.66[.]106 |
| IPv4 (sondage/requêtes) | 34.153.223[.]102 |
| IPv4 (sondage/requêtes) | 64.20.53[.]230 |
| Chemins sondés | /wp-admin, PHP-CGI, /api/v1/validate/code (LangFlow) |
| Comportement | Énumération de deux souscriptions en ~5 secondes |
| Comportement | Jetons de suppression multiples actifs en parallèle (70 s) |
| Comportement | ListKeys massif post-destruction (>30 requêtes) |
MITRE ATT&CK
Microsoft n'a pas publié de matrice formelle. Cartographie technique proposée à partir du rapport.
| Tactique | Technique | ID | Justification |
|---|---|---|---|
| Initial Access | Valid Accounts: Cloud Accounts | T1078.004 | Service principals compromis via secret exposé |
| Credential Access | Unsecured Credentials in Repositories | T1552.004 | Secret publié dans une issue GitHub publique |
| Discovery | Cloud Infrastructure Discovery | T1580 | Énumération VM, souscriptions, groupes de ressources |
| Credential Access | Credentials from Configuration Stores | T1552 | Lecture des magasins de configuration App Service |
| Credential Access | Steal Application Access Token | T1528 | Requêtes ListKeys massives sur les comptes de stockage |
| Impact | Data Destruction | T1485 | Suppression de >100 comptes de stockage et ressources |
| Impact | Inhibit System Recovery | T1490 | Ciblage des verrous Azure Site Recovery et Backup |
Remédiation : checklist opérationnelle
- Traiter tout identifiant exposé sur Internet, même retiré depuis, comme compromis : révoquer ou renouveler, et vérifier son historique d'utilisation, y compris l'historique d'édition des issues et commits.
- Interdire les secrets dans le code, les fichiers de configuration, les dépôts et les tickets. Mettre en place un scan de secrets côté dépôt et une détection de secrets exposés.
- Appliquer le moindre privilège aux service principals : n'accorder que les permissions dont l'application a besoin, auditer les rôles hérités de groupes.
- Activer les plans Defender for Cloud pertinents : Resource Manager, Storage, Key Vault, App Service, Databases.
- Protéger les ressources de sauvegarde et de reprise : verrous de ressources, protection contre la suppression, surveillance des tentatives de modification de ces protections.
- Alerter sur les signaux d'automatisation : volume d'opérations anormal en quelques secondes, user agent python-requests, jetons multiples en parallèle depuis un même service principal.
- Bloquer et chasser le trafic depuis 45.131.66[.]106, 34.153.223[.]102 et 64.20.53[.]230.
- Alerter sur les pics de ListKeys et les suppressions en masse de comptes de stockage et de Key Vaults.
Sources
- Microsoft Security Blog, Storm-3168 agentic-driven cloud attacks using compromised service principals
- Security Affairs, Storm-3168, Linked to JADEPUFFER, Abused Stolen Azure Identities
- Security Affairs, JADEPUFFER: first end-to-end AI-driven ransomware operation
- MITRE ATT&CK T1078.004
- MITRE ATT&CK T1552.004
- MITRE ATT&CK T1485
