Fondamentaux & architecture DFIR de Microsoft 365
En matière d’investigation numérique et de réponse à incident (DFIR), Microsoft 365 ne doit pas être appréhendé comme un monolithe, mais comme une fédération de charges applicatives Software-as-a-Service (SaaS) multi-tenants interconnectées, unifiées par un plan d’identité centralisé : Microsoft Entra ID (anciennement Azure Active Directory).
Du point de vue forensique, un environnement Microsoft 365 d’entreprise s’articule autour de cinq couches fondamentales :
- Le conteneur de tenant : frontière d’isolation globale représentant l’organisation, identifiée de façon immuable par un
TenantId(GUID unique d’annuaire) et un espace de nommage primaire (ex.entreprise.onmicrosoft.com). - Le plan d’identité (Microsoft Entra ID) : administre les utilisateurs, les comptes invités, les identités de charge de travail (service principals), les appartenances aux groupes et évalue chaque requête d’accès via le Moteur d’Accès Conditionnel (Conditional Access).
- Le plan applicatif (workloads) : services cloud autonomes disposant de leurs propres magasins de données et de leurs propres API :
- Exchange online : messagerie d’entreprise, éléments de calendrier, règles de transport, boîtes aux lettres.
- SharePoint online & OneDrive for business : référentiels documentaires, moteurs de synchronisation de fichiers, liens de partage externe.
- Microsoft teams : canaux de messagerie instantanée, conversations éphémères, fils de fédération externe, enregistrements de réunions.
- Le plan de sécurité et de conformité :
- Microsoft purview : référentiel central du Unified Audit Log (UAL), gestion de la rétention et eDiscovery.
- Microsoft Defender XDR : moteur de détection et corrélation multi-domaines (Defender for Endpoint, Office 365, Identity, Cloud Apps).
- Le plan de contrôle & tissu programmable : L’API Microsoft Graph (
graph.microsoft.com), point d’entrée REST unifié par lequel administrateurs légitimes et acteurs malveillants automatisés interrogent ou altèrent l’état du tenant.
+---------------------------------------------------------------------------------------------------+| CONTENEUR DE TENANT MICROSOFT 365 || (TenantId immuable sous forme de GUID unique) || || +-------------------------------------------------------------------------------------------+ || | PLAN D'IDENTITÉ (MICROSOFT ENTRA ID) | || | Schéma d'annuaire | Identités membres | Invités (Guests) | Service Principals / Apps | || | Services d'authentification | Jetons OAuth 2.0 / OIDC | Politiques d'Accès Conditionnel | || +---------------------------------------------+---------------------------------------------+ || | (Jetons d'accès / PRT / Scopes) || +----------------------------+----------------------------+ || | | || v v || +----------------------------------+ +----------------------------------+ || | TISSU MESSAGERIE | | TISSU FICHIERS & DONNÉES | || | Exchange Online | | SharePoint Online / OneDrive | || | Boîtes aux lettres | Transport | | Bibliothèques | Synchronisation | || +-----------------+----------------+ +-----------------+----------------+ || | | || +---------------------------+----------------------------+ || | || v || +-------------------------------------------------------------------------------------------+ || | TISSU COLLABORATIF & TEMPS RÉEL (TEAMS) | || | Conversations de groupe | Chats 1:1 | Fichiers de canal (SharePoint) | Partage (OneDrive) | || +---------------------------------------------+---------------------------------------------+ || | || v || +-------------------------------------------------------------------------------------------+ || | TISSU D'AUDIT, DE CONFORMITÉ ET DE TÉLÉMÉTRIE | || | Microsoft Purview (Unified Audit Log) | Alertes & Requêtes Avancées Defender XDR (KQL) | || +-------------------------------------------------------------------------------------------+ |+---------------------------------------------------------------------------------------------------+Pourquoi c’est important en DFIR
Section intitulée « Pourquoi c’est important en DFIR »Lorsqu’une équipe de réponse à incident intervient sur une compromission Microsoft 365 — qu’il s’agisse d’une fraude au virement (BEC), d’un vol de session par proxy AiTM (Adversary-in-the-Middle) ou de l’installation d’une application OAuth malveillante — l’analyste fait face à des spécificités critiques :
- Découplage des charges applicatives : une authentification réussie dans Entra ID ne génère aucune entrée dans le journal d’audit d’Exchange Online tant que l’attaquant n’exécute pas explicitement une requête sur la boîte mail.
- Dispersion des journaux : les différentes actions sont archivées dans des canaux distincts, présentant des délais d’indexation, des structures de données et des durées de conservation dissemblables.
- Persistance silencieuse : les adversaires modernes contournent fréquemment les comptes utilisateurs en enregistrant des applications d’entreprise ou en ajoutant des secrets sur des applications existantes, échappant ainsi aux sondes EDR des postes de travail.
- La rupture probatoire : savoir si un attaquant a effectivement exfiltré le contenu d’une boîte mail ou s’il s’est contenté d’en lister les dossiers requiert de corréler l’émission du jeton Entra avec des événements applicatifs fins comme
MailItemsAccessed.
Maîtriser cette architecture globale est la condition absolue pour formuler les bonnes demandes au client, cibler les bons journaux et éviter les conclusions erronées.
Comment ça fonctionne
Section intitulée « Comment ça fonctionne »1. Authentification d’identité vs autorisation applicative
Section intitulée « 1. Authentification d’identité vs autorisation applicative »Microsoft 365 repose rigoureusement sur l’authentification moderne (OAuth 2.0 et OpenID Connect) :
- Authentification (AuthN) : le client (navigateur, client lourd Outlook, application mobile) s’authentifie auprès d’Entra ID (
login.microsoftonline.com). Si le MFA et les politiques d’accès conditionnel sont validés, Entra ID émet un Primary Refresh Token (PRT) ou un refresh token, ainsi qu’un Jeton d’Accès (Access Token, d’une durée de vie standard de 60 à 90 minutes) restreint à une ressource cible (ex.https://outlook.office365.com). - Autorisation (AuthZ) : le client présente son jeton d’accès à l’API du service cible. La charge applicative valide la signature cryptographique du jeton, son échéance et les rôles/scopes intégrés, de manière autonome sans solliciter Entra ID à chaque requête.
2. Cloisonnement et stockage des données
Section intitulée « 2. Cloisonnement et stockage des données »- Exchange online : stocke les messages, éléments de calendrier et métadonnées dans des bases Exchange EDB distribuées. L’accès aux boîtes est régi par le modèle RBAC d’Exchange.
- SharePoint online & OneDrive : reposent sur des bases Azure SQL et du stockage objet Azure Blob. OneDrive for Business est structurellement une collection de sites SharePoint personnelle (
/personal/prenom_nom_domaine_com) dédiée à un utilisateur. - Microsoft teams : teams ne possède pas de base de stockage autonome. Les messages de canal sont indexés dans les boîtes aux lettres de groupe Exchange pour la conformité ; les fichiers de canal résident dans le site SharePoint d’équipe ; les fichiers échangés en chat privé résident dans le OneDrive de l’expéditeur.
3. API d’administration et de contrôle
Section intitulée « 3. API d’administration et de contrôle »- Microsoft graph (
v1.0etbeta) : Point de terminaison REST unique permettant d’administrer l’annuaire, de requêter les utilisateurs et de lire la télémétrie. - Modules PowerShell modernes : les modules
Microsoft.Graph(v2+) etExchangeOnlineManagement(v3+) constituent le standard d’interaction avec le tenant.
Ce qui est possible
Section intitulée « Ce qui est possible »Dans le cadre d’une compromission, un acteur malveillant contrôlant une identité ou une application cloud peut techniquement :
- Consulter et exfiltrer la messagerie : lire les emails historiques, télécharger les pièces jointes sensibles, émettre des messages internes ou externes frauduleux (Fiche 49 : BEC).
- Établir des persistances silencieuses : créer des règles de boîte de réception dissimulées, des règles de transport Exchange, ou consentir à des applications OAuth dotées de privilèges d’application étendus (Fiche 26 : Persistance).
- Piller les espaces documentaires : télécharger ou synchroniser en masse des bibliothèques documentaires SharePoint ou des répertoires OneDrive (Fiche 34 : SharePoint et Fiche 35 : OneDrive).
- Élever ses privilèges : si un compte à privilèges est atteint, s’assigner des rôles d’annuaire (Global Administrator) ou dévoyer les activations PIM (Fiche 31 : Rôles Entra).
- Rebondir vers l’Active Directory on-premises : exploiter les serveurs de synchronisation hybrides (Entra Connect) pour compromettre le domaine interne (Fiche 43 : Chemins d’Attaque Hybrides).
Ce qui n’est pas possible
Section intitulée « Ce qui n’est pas possible »L’investigateur doit intégrer les limites structurelles de l’environnement SaaS :
- Absence de forensique disque OU mémoire bas-niveau : l’analyste ne peut pas acquérir la mémoire vive (RAM) des hyperviseurs Microsoft, monter des disques virtuels ou analyser une table MFT sur les charges SaaS hébergées.
- Rétroactivité impossible des événements non journalisés : si un niveau d’audit spécifique (comme Purview Audit Premium ou l’audit détaillé des boîtes) n’était pas actif au moment des faits, les événements manquants sont irrémédiablement perdus. Souscrire une licence supérieure après l’attaque ne recrée pas l’historique (Fiche 18 : Rétention d’Audit).
- Étanchéité inter-tenants : un attaquant ayant compromis un tenant ne peut pas inspecter directement l’infrastructure d’un autre tenant sans relations explicites de confiance B2B, de synchronisation ou de délégation de service.
Conditions nécessaires
Section intitulée « Conditions nécessaires »Pour conduire une investigation forensique rigoureuse au sein d’un tenant Microsoft 365, les prérequis suivants s’imposent :
- Comptes dédiés d’investigation : création de comptes nominatifs pour le CSIRT avec MFA strict (Fiche 04 : Préparation du Tenant).
- Rôles RBAC spécifiques : combinaison de rôles d’annuaire Entra ID (
Global Reader,Security Reader) et de rôles Purview de conformité (View-Only Audit Logs,Compliance Administrator) (Fiche 06 : Matrice d’Accès). - Activation de l’audit unifié : vérification préalable de l’activation du journal d’audit unifié (
Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true). - Environnement d’analyse sécurisé : postes d’analyse équipés de PowerShell 7 et des modules à jour
Microsoft.GraphetExchangeOnlineManagement.
Artefacts et journaux
Section intitulée « Artefacts et journaux »| Couche | Source Principale de Preuves | Stockage Natif | Interface d’Interrogation | Rétention Standard |
|---|---|---|---|---|
| Authentification | Sign-in Logs Entra ID (Interactifs, Non-Interactifs, Service Principals) | Monitoring Entra / Azure Monitor | Centre d’administration Entra, Graph API (/auditLogs/signIns) | 7 jours (Free), 30 jours (P1/P2) |
| Modifications d’annuaire | Audit Logs Entra ID (Utilisateurs, Groupes, Apps, Rôles) | Monitoring Entra | Centre d’administration Entra, Graph API (/auditLogs/directoryAudits) | 7 jours (Free), 30 jours (P1/P2) |
| Actions utilisateurs & admins | Unified Audit Log (UAL) | Conformité Microsoft Purview | Portail Purview, cmdlet Search-UnifiedAuditLog | 180 jours (Standard), 1 à 10 ans (Premium) |
| Flux et routage mail | Message Trace Exchange | Moteur de transport Exchange | Centre d’administration Exchange (EAC), Get-MessageTrace | 10 jours (Interactif), 90 jours (Rapport historique) |
| Accès aux boîtes mail | Mailbox Audit (MailItemsAccessed, SendAs, SoftDelete) | Exchange / Unified Audit Log | Recherche d’audit Purview, PowerShell Exchange | Aligné sur la rétention UAL |
| Terminaux & détections | Télémétrie Defender for Endpoint & Defender XDR | Centre de sécurité Microsoft Defender | security.microsoft.com, Chasse avancée KQL | 30 jours (standard), 180 jours (Advanced Hunting) |
Méthodologie d’investigation
Section intitulée « Méthodologie d’investigation »flowchart TD A[Étape 1 : Cadrage & Identification du Tenant] --> B[Étape 2 : Embarquement & Accès Sécurisés] B --> C[Étape 3 : Préservation Conservatoire des Logs] C --> D[Étape 4 : Triage d'Identité & Connexions] D --> E[Étape 5 : Analyse des Workloads & Persistances] E --> F[Étape 6 : Évaluation des Accès Données & Rayon d'Impact]
A ---|TenantId, Domaine primaire, Licences souscrites| A B ---|Attribution Global Reader + Purview Audit Reader| B C ---|Export Sign-ins, Audit Entra, UAL, Message Trace| C D ---|Analyse des Risky Users, Accès Conditionnel, Sessions| D E ---|Contrôle des règles de boîte, transport, OAuth| E F ---|Corrélation MailItemsAccessed, FileDownloaded, Partages| F-
Identification des métadonnées primaires du tenant : Récupérer le
TenantId(GUID) et le domaine initial (tenant.onmicrosoft.com). Auditer le niveau de licence souscrit (E3 vs E5, Entra Free vs P1/P2) pour déterminer les fenêtres de rétention disponibles. -
Établissement des accès d’investigation : Faire provisionner des comptes dédiés nominatifs avec authentification forte. Obtenir les rôles d’annuaire et de conformité en lecture seule (Fiche 05 : global Reader).
-
Préservation conservatoire immédiate : Exporter sans attendre les journaux de connexion et d’audit Entra si l’incident remonte à plus de 20 jours. Poser des verrous de rétention (Litigation Hold) sur les boîtes compromises (Fiche 07 : préservation des preuves).
-
Triage des connexions et événements d’identité : Analyser les journaux de connexion Entra ID pour identifier le vecteur d’accès initial (adresses IP, User-Agents suspects, contournement d’accès conditionnel, proxy AiTM).
-
Examen des opérations métier et vérification de persistance : Interroger l’Unified Audit Log (UAL) pour repérer la création de règles de boîte de réception, l’enregistrement d’applications tierces et les délégations de droits.
-
Détermination de l’exfiltration et du périmètre atteint : Déterminer si des données sensibles ont été lues ou exfiltrées via l’analyse des événements d’accès documentaires (
FileDownloaded) et de messagerie (MailItemsAccessed).
Exemple concret / cas d’école
Section intitulée « Exemple concret / cas d’école »Scénario : la compromission silencieuse d’un compte financier
Section intitulée « Scénario : la compromission silencieuse d’un compte financier »Un responsable de trésorerie voit son compte signalé par un partenaire externe après l’envoi de fausses coordonnées bancaires. L’équipe informatique interne inspecte le poste de travail de l’utilisateur avec l’antivirus et ne détecte aucune anomalie, concluant à un piratage extérieur sans impact sur le compte.
Déroulement de l’analyse forensique :
- Identification du tenant :
Connexion PowerShell :
Fenêtre de terminal Connect-MgGraph -Scopes "AuditLog.Read.All", "Directory.Read.All"(Get-MgOrganization).Id # Capture du TenantId - Triage des journaux de connexion :
L’examen des journaux Entra révèle une connexion interactive depuis une IP résidentielle étrangère (
198.51.100.24). L’authentification MFA est marquée comme validée avec unUserAgentidentique à celui de l’utilisateur légitime, mais localisée dans un pays non habituel (Fiche 21 : AiTM). - Recherche dans l’unified audit log (UAL) :
Interrogation ciblée avec
Search-UnifiedAuditLog:Découverte : une opérationFenêtre de terminal Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-3) -EndDate (Get-Date) `-FreeText "New-InboxRule" -UserIds "tresorier@entreprise.fr"New-InboxRulea créé une règle nommée"..."configurée pour marquer automatiquement comme lus tous les emails contenant les termesvirement,factureoubanque, et les déplacer silencieusement dans le dossierFlux RSS(Fiche 27 : règles de boîte). - Diagnostic forensique : L’attaquant a capturé le cookie de session via un proxy de phishing AiTM, s’est connecté sans déclencher d’alerte MFA, a configuré une persistance sur la messagerie pour surveiller les échanges financiers et exécuter son arnaque sans déposer aucun binaire sur le poste.
Pièges et confusions fréquentes
Section intitulée « Pièges et confusions fréquentes »| Piège Fréquent | Réalité Opérationnelle | Conséquence Forensique |
|---|---|---|
| ”Le global Reader voit tout” | Le rôle Global Reader ne donne aucun droit pour lancer des recherches dans l’Audit Unifié Purview. | L’analyste perd des heures sans pouvoir extraire l’UAL sans rôle Purview complémentaire. |
| ”Connexion réussie = vol de données” | Une session valide prouve un accès, mais n’établit pas la lecture ou le téléchargement effectif des documents. | Risque de déclaration erronée de fuite de données aux autorités réglementaires (CNIL/RGPD). |
| ”Souscription E5 le jour de l’incident” | Les modifications de licence ne s’appliquent pas rétroactivement aux données ayant déjà expiré. | Illusion de pouvoir récupérer des logs anciens définitivement purgés par le cycle de vie du tenant. |
| ”L’IP appartient à Microsoft donc c’est légitime” | De nombreuses connexions non-interactives proviennent des plages d’IP Microsoft (Power Automate, Graph). | Risque de confondre des automatisations légitimes avec des canaux d’exfiltration ou inversement. |
Points clés à retenir
Section intitulée « Points clés à retenir »- Microsoft 365 est un écosystème découplé : entra ID authentifie les identités, tandis que les services (Exchange, SharePoint, Teams) valident les autorisations et tracent les actions de manière autonome.
- L’unified audit log (UAL) est le pivot de l’enquête : il normalise les événements transversaux, mais dépend étroitement de son activation préalable et de la licence détenue.
- Les attaques ciblent le plan d’identité cloud : l’ingénierie sociale AiTM, le vol de jetons de session et les applications OAuth permettent aux acteurs malveillants d’agir sans trace sur les postes de travail.
- Respecter la chaîne de preuve : ne jamais présumer d’un vol de données sans artefacts formels attestant de l’accès aux éléments (
MailItemsAccessed,FileDownloaded).
État de la fonctionnalité en 2026
Section intitulée « État de la fonctionnalité en 2026 »Changements récents
Section intitulée « Changements récents »- Rétention standard de l’UAL à 180 jours : la conservation native des événements d’audit pour les licences standard est désormais de 180 jours (contre 90 jours historiquement).
- Suppression définitive des modules legacy : les modules
AzureADetMSOnlinesont définitivement désactivés. Toute collecte automatisée doit s’appuyer sur le SDK PowerShellMicrosoft.Graph(v2+) et les API REST directes. - Accès élargi aux événements de sécurité : des événements critiques comme
MailItemsAccessedetSearchQueryPerformedsont progressivement rendus visibles sur des périmètres de licences plus larges, bien que la rétention longue durée (1 an à 10 ans) demeure assujettie à Purview Audit Premium.
Fonctionnalités dépréciées
Section intitulée « Fonctionnalités dépréciées »- L’authentification basique (Basic Auth : POP3, IMAP4, MAPI basique) est totalement supprimée sur l’ensemble des tenants Exchange Online mondiaux.
- L’ancienne API Azure AD Graph (
graph.windows.net) est définitivement éteinte au profit de Microsoft Graph (graph.microsoft.com).
Limitations actuelles
Section intitulée « Limitations actuelles »- Latence d’ingestion de l’UAL : l’indexation des événements dans l’Unified Audit Log n’est pas instantanée ; elle varie de 15 minutes à parfois 24 heures selon la charge applicative concernée.
- Bridage API (throttling) : l’extraction de masse via
Search-UnifiedAuditLogou l’API Office 365 Management Activity est soumise à des quotas stricts (erreurs HTTP 429) sur les tenants volumineux.
Points à surveiller
Section intitulée « Points à surveiller »- Surveiller le déploiement généralisé de Token Protection (jetons liés cryptographiquement au matériel par Proof-of-Possession), qui neutralise à la racine les attaques de rejeu de cookies de session (Fiche 25 : token protection).
Références
Section intitulée « Références »- Microsoft Learn : architecture de référence Microsoft 365 pour les professionnels de l’IT
- Microsoft Learn : notions fondamentales d’identité Microsoft Entra
- Microsoft Learn : rechercher dans le journal d’audit Microsoft Purview
- Microsoft Learn : documentation officielle du SDK Microsoft Graph PowerShell
- Hermes Codex : pont d’architecture Active Directory vers Microsoft Entra ID