Aller au contenu

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 :

  1. 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).
  2. 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).
  3. 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.
  4. 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).
  5. 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) | |
| +-------------------------------------------------------------------------------------------+ |
+---------------------------------------------------------------------------------------------------+

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.


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) :

  1. 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).
  2. 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.
  • 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.
  • Microsoft graph (v1.0 et beta) : 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+) et ExchangeOnlineManagement (v3+) constituent le standard d’interaction avec le tenant.

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).

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.

Pour conduire une investigation forensique rigoureuse au sein d’un tenant Microsoft 365, les prérequis suivants s’imposent :

  1. Comptes dédiés d’investigation : création de comptes nominatifs pour le CSIRT avec MFA strict (Fiche 04 : Préparation du Tenant).
  2. 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).
  3. Activation de l’audit unifié : vérification préalable de l’activation du journal d’audit unifié (Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true).
  4. Environnement d’analyse sécurisé : postes d’analyse équipés de PowerShell 7 et des modules à jour Microsoft.Graph et ExchangeOnlineManagement.

CoucheSource Principale de PreuvesStockage NatifInterface d’InterrogationRétention Standard
AuthentificationSign-in Logs Entra ID (Interactifs, Non-Interactifs, Service Principals)Monitoring Entra / Azure MonitorCentre d’administration Entra, Graph API (/auditLogs/signIns)7 jours (Free), 30 jours (P1/P2)
Modifications d’annuaireAudit Logs Entra ID (Utilisateurs, Groupes, Apps, Rôles)Monitoring EntraCentre d’administration Entra, Graph API (/auditLogs/directoryAudits)7 jours (Free), 30 jours (P1/P2)
Actions utilisateurs & adminsUnified Audit Log (UAL)Conformité Microsoft PurviewPortail Purview, cmdlet Search-UnifiedAuditLog180 jours (Standard), 1 à 10 ans (Premium)
Flux et routage mailMessage Trace ExchangeMoteur de transport ExchangeCentre d’administration Exchange (EAC), Get-MessageTrace10 jours (Interactif), 90 jours (Rapport historique)
Accès aux boîtes mailMailbox Audit (MailItemsAccessed, SendAs, SoftDelete)Exchange / Unified Audit LogRecherche d’audit Purview, PowerShell ExchangeAligné sur la rétention UAL
Terminaux & détectionsTélémétrie Defender for Endpoint & Defender XDRCentre de sécurité Microsoft Defendersecurity.microsoft.com, Chasse avancée KQL30 jours (standard), 180 jours (Advanced Hunting)

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
  1. 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.

  2. É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).

  3. 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).

  4. 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).

  5. 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.

  6. 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).


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 :

  1. Identification du tenant : Connexion PowerShell :
    Fenêtre de terminal
    Connect-MgGraph -Scopes "AuditLog.Read.All", "Directory.Read.All"
    (Get-MgOrganization).Id # Capture du TenantId
  2. 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 un UserAgent identique à celui de l’utilisateur légitime, mais localisée dans un pays non habituel (Fiche 21 : AiTM).
  3. Recherche dans l’unified audit log (UAL) : Interrogation ciblée avec Search-UnifiedAuditLog :
    Fenêtre de terminal
    Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-3) -EndDate (Get-Date) `
    -FreeText "New-InboxRule" -UserIds "tresorier@entreprise.fr"
    Découverte : une opération New-InboxRule a créé une règle nommée "..." configurée pour marquer automatiquement comme lus tous les emails contenant les termes virement, facture ou banque, et les déplacer silencieusement dans le dossier Flux RSS (Fiche 27 : règles de boîte).
  4. 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ège FréquentRéalité OpérationnelleConsé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.

  1. 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.
  2. 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.
  3. 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.
  4. 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).

  • 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 AzureAD et MSOnline sont définitivement désactivés. Toute collecte automatisée doit s’appuyer sur le SDK PowerShell Microsoft.Graph (v2+) et les API REST directes.
  • Accès élargi aux événements de sécurité : des événements critiques comme MailItemsAccessed et SearchQueryPerformed sont 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.
  • 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).
  • 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-UnifiedAuditLog ou l’API Office 365 Management Activity est soumise à des quotas stricts (erreurs HTTP 429) sur les tenants volumineux.
  • 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).