Analyser l'Activity Log Azure pas à pas, dans le navigateur

En bref. Exportez l'Activity Log (plus Key Vault, Storage et flow logs si vous les avez), ouvrez l'analyseur Azure Forensics, déposez les fichiers ou un ZIP, et lisez dans cet ordre : couverture → verdict → constats → chronologie → entités → remédiation. Tout s'exécute localement en WebAssembly dans un Web Worker ; rien ne quitte le navigateur. Comptez 30 minutes pour un premier passage sur un abonnement typique.

C'est la procédure que je suis quand on me tend un dossier d'exports Azure en demandant « est-ce qu'on s'est fait pirater ? ». L'outil donne une première réponse rapide ; les étapes ci-dessous servent à lire cette réponse avec un œil critique.

Avant de commencer : quoi charger

L'analyseur lit ces sources et reconnaît chaque format automatiquement :

Fichiers isolés, dossiers entiers (les arborescences resourceId=/…/PT1H.json), ZIP et fichiers .gz fonctionnent tels quels. Si vous n'avez pas encore d'exports, exporter l'Activity Log Azure et les logs de ressources liste les commandes.

Incluez au moins une semaine avant le début présumé. Plusieurs règles sont des règles de « première apparition » qui apprennent ce qui est normal pendant les 72 premières heures de données ; sans cet historique, elles ne peuvent pas s'exécuter.

Étape 1 : charger les fichiers

Ouvrez l'analyseur. Déposez les fichiers sur la zone prévue, ou utilisez Choisir des fichiers / Choisir un dossier. Les ZIP sont décompressés dans le navigateur. Chaque fichier est lu par blocs de 4 Mo et transmis en flux à l'analyseur Rust : un export de plusieurs gigaoctets n'a pas besoin de tenir deux fois en mémoire.

Pour voir d'abord à quoi ressemble un résultat, cliquez sur Essayer un exemple. Cela charge un export synthétique d'une entreprise fictive (Kestrel Freight), signalé comme tel à l'écran. Le cas fictif décortiqué explique cet exemple constat par constat.

Étape 2 : vérifier la couverture avant le verdict

Le bloc Couverture est l'élément le plus important de la page, et le plus souvent ignoré. Il liste, par source (Activity Log, Key Vault, Storage, flow logs NSG / VNet, Defender for Cloud), le nombre d'événements et la période couverte, ou « non fourni ».

En dessous, l'outil liste les détections qui n'ont pas pu s'exécuter, avec la raison :

• source de logs non fournie : par exemple toutes les règles Key Vault quand aucun log AuditEvent n'a été chargé ;
• nécessite plus de 72 h d'historique : les règles de première apparition sur un export trop court.

Un verdict « Sain » avec Key Vault et Storage marqués « non fourni » veut dire « le plan de contrôle semble sain » ; il ne dit rien des accès aux données. L'article sur les limites approfondit ce point.

Regardez aussi l'onglet Fichiers : chaque fichier ignoré est expliqué (vide, pas un log, Avro, Parquet, UTF-16, ZIP illisible), et les doublons entre exports sont comptés et fusionnés.

Étape 3 : lire le verdict et les constats

Le verdict est volontairement simple et documenté :

Pourquoi liste les identifiants de règles à l'origine du verdict. Chaque constat affiche ensuite :

• le titre et la sévérité de la règle, et un identifiant stable (AZ-RBAC-003, AZ-VM-001…) que vous pouvez citer dans un rapport ;
• le nombre d'actions distinctes correspondantes, première et dernière apparition ;
• les principaux, IP et ressources impliqués ;
• les groupes pour les règles à seuil (par exemple un appelant qui lit 12 secrets distincts en moins d'une heure) ;
• les flux réseau pour les règles de flux ;
• les techniques MITRE ATT&CK, avec lien.

Lisez les preuves de chaque constat haut. Une règle est une heuristique : une équipe plateforme qui attribue Owner, ou une sauvegarde qui lit des centaines de blobs, peut correspondre. Le tableau des détections de la page de l'outil liste toutes les règles, et le fichier de règles documente les faux positifs connus de chacune.

Étape 4 : parcourir la chronologie

L'onglet Chronologie liste chaque événement lié à un constat moyen, haut ou critique, dans l'ordre chronologique. C'est là qu'une chaîne d'attaque devient lisible : attribution de rôle, puis Run Command, puis jeton d'identité managée utilisé depuis l'extérieur, puis secrets lus, puis SAS généré, puis journalisation supprimée.

Cliquez sur un événement pour voir les champs normalisés (opération, appelant, type d'appelant, application ID, object ID, IP, ressource, user agent, correlation ID, fichier source) et l'enregistrement d'origine tel qu'exporté. Basculez entre UTC et Local ; rédigez vos rapports en UTC.

Le correlationId compte : l'Activity Log écrit plusieurs événements pour une même opération (Started, Accepted, Succeeded). L'analyseur compte les actions distinctes, mais quand vous citez un événement dans un rapport, citez aussi son correlation ID.

Étape 5 : pivoter sur les principaux, IP et ressources

L'onglet Entités est le tableau croisé de l'investigation :

• Principaux : utilisateurs, principaux de service, identités managées, jetons SAS (identifiés par un hash) et accès anonymes, avec première et dernière apparition et nombre de constats.
• Adresses IP : publiques ou privées, avec les totaux envoyés et reçus quand des flow logs ont été chargés.
• Ressources : filtrables par Key Vault, comptes de stockage, VM et réseau.
• Abonnements.

Cliquez sur n'importe quelle ligne pour filtrer le tableau Événements. La question à poser à une IP d'attaquant : « qu'a-t-elle fait d'autre ? ». La question à poser à une identité compromise : « quand a-t-elle commencé à se comporter différemment ? ».

Le tableau des événements permet aussi un filtrage en texte libre (opération, principal, IP, ressource, règle), des filtres par source et résultat, et un interrupteur Signalés uniquement.

Étape 6 : remédiation et export

L'onglet Remédiation transforme les constats en checklist ordonnée : faire tourner les identifiants, supprimer les attributions de rôles, isoler les VM, faire tourner les secrets Key Vault et les clés de stockage, rétablir la journalisation et les plans Defender, bloquer les IP, enquêter côté identité dans Entra ID. Les cases cochées ne sont conservées que dans la page.

Pour le dossier :

• CSV exporte le tableau des événements (avec une protection contre l'injection de formules dans les tableurs) ;
• Rapport JSON exporte le résultat complet : verdict, constats, chronologie, entités, couverture.

Ce que l'outil ne fera pas à votre place

• Il ne voit rien de ce que vous n'avez pas exporté. Aucun appel d'API, aucun accès à votre tenant.
• Il n'analyse pas les connexions Entra ID ni les identifiants d'application ; c'est le rôle de l'outil voisin m365forensics.com.
• Il ne prouve pas l'absence. Un attaquant prudent peut rester sous un seuil.

Pour le processus autour de l'outil (quoi préserver d'abord, comment contenir), partez du guide de réponse à incident.

Articles liés

• Exporter l'Activity Log Azure et les logs de ressources
• Une compromission Azure décortiquée (cas fictif)
• Limites de la forensique des logs Azure : rétention, trous