Abonnement Azure compromis ? Guide de réponse à incident

En bref. Traitez la question « notre abonnement Azure est-il compromis ? » comme trois questions : quelle identité a agi, ce qu'elle a fait sur le plan de contrôle (Activity Log) et quelles données elle a touchées (Key Vault, Storage, flow logs). Exportez tout avant que la rétention ne frappe : l'Activity Log est conservé 90 jours. Cherchez d'abord une courte liste d'opérations : roleAssignments/write, elevateAccess/action, runCommand/action, listAccountSas/action, accessPolicies/write, diagnosticSettings/delete. Si vous ne devez faire qu'une chose aujourd'hui, exportez l'Activity Log de chaque abonnement concerné et déposez-le dans l'analyseur Azure Forensics, qui s'exécute dans votre navigateur.

La plupart des incidents Azure que je traite commencent de la même façon : quelqu'un remarque un pic de coûts, une alerte Defender for Cloud ou une attribution de rôle que personne ne se rappelle avoir créée. La tentation est d'ouvrir le portail et de cliquer partout. Résistez dix minutes. Cliquer ne préserve aucune preuve, et les vues du portail sont filtrées par défaut. Ce guide décrit l'ordre des opérations que j'applique.

Ce que « compromis » veut dire dans Azure

Un abonnement Azure a deux plans, et les attaquants utilisent les deux.

Microsoft Learn est explicite sur cette séparation : l'Activity Log enregistre les opérations du plan de contrôle, tandis que les logs de ressources capturent le plan de données et ne sont pas collectés par défaut. Si la journalisation Key Vault n'a jamais été activée, personne ne pourra vous dire quels secrets ont été lus. C'est la première limite honnête de toute investigation Azure ; l'article sur les limites va plus loin.

Étape 1 : préserver avant d'enquêter

Deux choses détruisent les preuves dans Azure : le temps et l'attaquant.

• Le temps. Azure conserve les événements de l'Activity Log 90 jours, puis les supprime. Si l'intrusion a commencé il y a 80 jours, il vous en reste dix.
• L'attaquant. Supprimer un paramètre de diagnostic empêche une ressource d'envoyer ses logs à partir de ce moment. C'est l'un des premiers gestes d'un intrus prudent (évasion de défense dans Azure).

Donc, avant toute chose :

1. Exportez l'Activity Log de chaque abonnement concerné pour la période suspectée plus au moins une semaine avant. Cette semaine sert de référence pour distinguer le normal de l'anormal.
2. Copiez les conteneurs de compte de stockage alimentés par les paramètres de diagnostic : insights-activity-logs, insights-logs-auditevent, insights-logs-storageread, insights-logs-networksecuritygroupflowevent, insights-logs-flowlogflowevent.
3. Exportez les tables Log Analytics si elles existent : AzureActivity, AzureDiagnostics (Key Vault), StorageBlobLogs.
4. Exportez aussi le log de niveau tenant (Directory Activity) : elevateAccess y atterrit, pas dans le log de l'abonnement.

Les commandes exactes, y compris la valeur par défaut de az monitor activity-log list qui ne renvoie silencieusement que 50 événements, sont dans exporter l'Activity Log Azure et les logs de ressources.

Étape 2 : trouver les opérations qui comptent

L'Activity Log d'un abonnement actif, ce sont surtout des déploiements et des écritures de tags. L'activité malveillante se cache dans une poignée de noms d'opérations. Voici celles sur lesquelles s'appuient les règles de l'analyseur, regroupées par objectif de l'attaquant :

Aucune n'est malveillante en soi. Une équipe plateforme attribue des rôles chaque semaine. Ce qui les rend suspectes, c'est qui (un principal de service qui déploie habituellement une application web), d'où (une IP jamais vue pendant la période de référence), quand (02:14 UTC un dimanche) et ce qui suit (un Run Command trois minutes plus tard).

Rien de théorique là-dedans. L'analyse par Microsoft du ransomware cloud de Storm-0501 cite elevateAccess/action, roleAssignments/write, listkeys/action et locks/delete parmi les opérations utilisées avant l'exfiltration des données et la suppression des ressources.

Étape 3 : pivoter sur l'identité

Chaque événement de l'Activity Log porte l'appelant et, dans les exports JSON, les claims du jeton : object ID, application ID et, pour une identité managée, une claim xms_mirid pointant vers la VM ou l'application à laquelle elle appartient. Dès qu'un événement suspect est trouvé, pivotez :

• Tous les événements du même appelant, sur tous les abonnements, sur toute la fenêtre de rétention. La première apparition compte plus que l'événement le plus bruyant.
• Tous les événements de la même adresse IP, quel que soit l'appelant. Les attaquants réutilisent leur infrastructure d'une identité volée à l'autre.
• La même identité dans les logs Key Vault et Storage, où elle apparaît sous forme d'object ID ou, pour un accès SAS, de hash de jeton.
• La même IP dans les flow logs, où une VM compromise la recontacte.

L'identité elle-même (comment le secret d'un principal de service a fuité, qui a consenti à quoi) relève d'Entra ID. Cette investigation se fait avec l'outil voisin m365forensics.com, qui couvre connexions, journaux d'audit et identifiants d'application.

Étape 4 : contenir dans le bon ordre

Dans Azure, le confinement est surtout un travail sur les identités. La checklist de remédiation de l'analyseur l'ordonne à peu près ainsi :

1. Identifiants. Faites tourner les secrets et certificats des principaux de service impliqués ; révoquez les sessions des utilisateurs. Un secret renouvelé n'invalide pas un jeton d'accès déjà émis : attendez-vous à une courte traîne d'activité.
2. Attributions de rôles. Supprimez toutes celles créées pendant l'incident, ainsi que l'attribution User Access Administrator à la racine (/) si elevateAccess a été utilisé.
3. VM. Isolez-les avec un NSG qui bloque tout, prenez des snapshots des disques pour l'analyse, puis reconstruisez à partir d'une image saine. Supprimer le script ne « nettoie » pas une VM qui a exécuté le code d'un attaquant.
4. Secrets et clés. Faites tourner tout ce qui a été lu dans les coffres touchés, ainsi que les deux clés des comptes de stockage (ce qui invalide les SAS de compte et de service).
5. Journalisation. Rétablissez les paramètres de diagnostic et plans Defender supprimés, puis protégez-les par un verrou ou Azure Policy.

La vue d'ensemble de la réponse aux incidents pour Azure de Microsoft est la référence officielle pour le processus global.

Étape 5 : obtenir vite un premier verdict

Un premier tri doit prendre quelques minutes, pas une semaine de KQL. L'analyseur Azure Forensics lit les exports de l'Activity Log (CSV du portail, JSON az CLI / REST, Log Analytics, export vers un compte de stockage), Key Vault AuditEvent, StorageBlobLogs, les flow logs NSG et VNet et les alertes Defender for Cloud. Il applique 35 règles documentées et rend un verdict :

• Compromis : au moins deux constats de sévérité haute, ou un critique.
• Suspect : au moins un constat moyen ou haut.
• Sain : rien au-dessus de « faible », ce qui signifie seulement que rien n'a correspondu dans les logs fournis.

Tout s'exécute en WebAssembly dans un Web Worker : aucun envoi. Le guide pas à pas montre comment lire les constats, la chronologie et le pivot par entité, et le cas fictif décortiqué montre une chaîne complète sur des données synthétiques.

FAQ

Que faire en premier quand un abonnement Azure est compromis ?

Préserver les logs avant qu'ils n'expirent (l'Activity Log est conservé 90 jours), puis contenir : faire tourner les identifiants des principaux impliqués, supprimer les attributions de rôles qu'ils ont créées et isoler les VM touchées. L'investigation se mène en parallèle, pas après.

L'Activity Log montre-t-il qui a lu mes secrets Key Vault ou mes blobs ?

Non. L'Activity Log enregistre les opérations du plan de contrôle passant par Azure Resource Manager. La lecture d'un secret ou le téléchargement d'un blob sont des opérations du plan de données, enregistrées uniquement dans les logs de ressources Key Vault et Storage, et seulement si un paramètre de diagnostic était actif avant l'incident.

Où enquêter sur la façon dont l'attaquant a obtenu les identifiants ?

Dans Microsoft Entra ID : journaux de connexion, journaux d'audit, nouveaux secrets d'application et consentements. Les logs de ressources Azure montrent ce que l'identité a fait de ses accès, pas comment elle a été obtenue.

Pour aller plus loin

• Journal d'activité dans Azure Monitor : rétention, export, événements de niveau tenant.
• Vue d'ensemble de la réponse aux incidents pour Azure : le processus selon Microsoft.
• Azure Threat Research Matrix : le catalogue Microsoft des techniques d'attaque Azure.
• Storm-0501's evolving techniques lead to cloud-based ransomware : Microsoft Threat Intelligence (en anglais).

Articles liés

• Exporter l'Activity Log Azure et les logs de ressources
• Analyser l'Activity Log Azure pas à pas, dans le navigateur
• Une compromission Azure décortiquée (cas fictif)