Architecture des journaux Microsoft 365

En investigation forensique cloud, les erreurs d’analyse ne résultent presque jamais d’une pénurie de données brutes, mais d’une méconnaissance fondamentale de l’architecture de journalisation de la plateforme. Microsoft 365 ne constitue pas une application monolithique dotée d’un journal centralisé ; il s’agit d’une fédération distribuée de services SaaS autonomes (Exchange Online, SharePoint, Teams), d’une infrastructure de conformité (Purview), de moteurs de détection de menaces (Defender XDR) et d’un plan de contrôle d’identité (Entra ID).

Chaque sous-système génère des événements selon son propre bus interne, applique des critères de filtrage hétérogènes, retient ses enregistrements selon des calendriers discordants et expose ses données via des API spécialisées et distinctes. Cette fiche établit la cartographie architecturale définitive de la journalisation Microsoft 365 pour l’analyste DFIR.

---

Concept

L’architecture de journalisation de Microsoft 365 s’articule autour de quatre plans opérationnels distincts :

graph TD
    subgraph "1. Plan d'identité (Microsoft Entra ID)"
        ID_SIGNIN[Sign-in Logs<br/>Interactifs, Non-interactifs, Service Principal, Managed ID]
        ID_AUDIT[Directory Audit Logs<br/>Utilisateurs, Groupes, Rôles, Consentements]
        ID_PROV[Provisioning Logs<br/>SCIM, Inbound RH, Cloud Sync]
        ID_RISK[Identity Protection<br/>Détections de risque & Utilisateurs à risque]
    end

    subgraph "2. Plan de conformité & audit (Microsoft Purview)"
        PUR_UAL[Unified Audit Log - UAL<br/>Agrégation des événements de plus de 40 workloads]
        PUR_EDISC[Logs de recherche & exports eDiscovery]
        PUR_DLP[Alertes & événements Data Loss Prevention]
    end

    subgraph "3. Plan de diagnostic des charges de travail"
        EXO_TRACE[Exchange Message Trace<br/>Routage SMTP temps réel & historique]
        EXO_MBX[Exchange Mailbox Audit<br/>Actions Owner, Delegate, Admin]
        SPO_AUDIT[Audit de sites SharePoint / OneDrive]
        TEAMS_LOGS[Télémétrie de conformité & chat Teams]
    end

    subgraph "4. Plan de sécurité & Threat Hunting (Microsoft Defender XDR)"
        DEF_HUNT[Advanced Hunting - Tables brutes 30j<br/>CloudAppEvents, IdentityLogonEvents, EmailEvents]
        DEF_INC[API Incidents & Alertes Defender]
    end

    ID_SIGNIN -->|Graph API / Diagnostic Settings| SIEM[Log Analytics / Sentinel / SIEM]
    ID_AUDIT -->|Graph API / Diagnostic Settings| SIEM
    ID_PROV -->|Graph API / Diagnostic Settings| SIEM
    ID_RISK -->|Graph API / Diagnostic Settings| SIEM

    PUR_UAL -->|Management Activity API / Graph Purview| SIEM
    EXO_TRACE -->|PowerShell / Export EAC| SIEM
    DEF_HUNT -->|Advanced Hunting API / Event Hub| SIEM

Chaque plan répond à un objectif forensique spécifique :

1. Le plan d’identité : enregistre les cinématiques d’authentification, l’émission des jetons, l’évaluation de l’accès conditionnel et les mutations de l’annuaire (voir Fiche 02 — Microsoft Entra ID : Le plan d’identité).
2. Le plan de conformité : consolide l’activité opérationnelle des utilisateurs et administrateurs au sein du journal d’audit unifié Purview (voir Fiche 13 — Dissection du Unified Audit Log).
3. Le plan de diagnostic des services : conserve la télémétrie transactionnelle native (ex. sauts SMTP, synchronisation des dossiers de messagerie) trop volumineuse ou spécialisée pour l’UAL (voir Fiche 15 — Message Trace Forensique et Fiche 17 — Audit de Boîte Mail).
4. Le plan de sécurité : enrichit la télémétrie brute par des modèles comportementaux de Machine Learning et des corrélations multi-charges dans Defender XDR.

---

Pourquoi c’est important en DFIR

Lorsqu’un incident multi-étapes se produit (ex. phishing AiTM aboutissant à une fraude au président et à une exfiltration de données), un analyste qui n’explore qu’un seul plan de journalisation obtient une vision tronquée ou erronée de l’intrusion :

• L’angle mort d’entra ID : les logs de connexion prouvent l’authentification d’un compte, mais n’indiquent strictement rien quant à la lecture d’e-mails, au téléchargement de fichiers ou à la création d’une règle de boîte aux lettres.
• L’angle mort de l’UAL : le journal d’audit unifié enregistre les accès aux documents, mais ne conserve pas les traces de remise SMTP granulaires ni les détails d’évaluation de la politique d’accès conditionnel.
• Le piège de la latence : si l’attaquant a accédé à une boîte mail 10 minutes avant le début de l’investigation, les événements peuvent ne pas encore être ingérés dans l’UAL (délai pouvant atteindre 60 minutes sur Exchange et 24 heures sur Teams). Conclure à « l’absence d’accès illégitime » sur cette période constitue une faute forensique majeure.

---

Comment ça fonctionne : pipelines d’ingestion et latences

Chaque flux de logs traverse un pipeline d’ingestion dédié avant de devenir interrogeable :

Flux de logs	Service source	Mécanisme de collecte	Latence d’ingestion	Rétention native	Interface d’extraction
Connexions interactives entra ID	Entra STS (Security Token Service)	Pipeline de streaming direct	2 à 5 minutes	Free : 7j P1/P2 : 30j	Microsoft Graph (/auditLogs/signIns), Log Analytics
Connexions non interactives entra ID	Entra STS	Traitement par lots (batch)	5 à 15 minutes	P1/P2 : 30j (Free : Aucun)	Microsoft Graph, Log Analytics
Audits d’annuaire entra ID	Entra Directory Core Store	File de notifications de changement	2 à 5 minutes	Free : 7j P1/P2 : 30j	Microsoft Graph (/auditLogs/directoryAudits)
UAL purview (Exchange)	Exchange Mailbox Assistant	File de publication asynchrone	15 à 60 minutes	Standard : 180j Premium : 1 an - 10 ans	Search-UnifiedAuditLog, Office 365 Management API
UAL purview (SharePoint/OneDrive)	SharePoint Telemetry Processor	Pipeline temps réel	15 à 30 minutes	Standard : 180j Premium : 1 an - 10 ans	Search-UnifiedAuditLog, Office 365 Management API
UAL purview (teams)	Teams Service Bus	File d’agrégation d’arrière-plan	2 à 24 heures	Standard : 180j Premium : 1 an - 10 ans	Search-UnifiedAuditLog, Office 365 Management API
Suivi des messages Exchange (temps réel)	Pipeline de transport Exchange	Traçage mémoire des messages	< 1 minute	10 jours	Get-MessageTrace, EAC
Suivi des messages Exchange (historique)	Entrepôt BigData Exchange	Indexation asynchrone par lots	1 à 4 heures de génération	90 jours	Start-HistoricalSearch, Get-HistoricalSearch
Advanced hunting Defender XDR	Event Hub M365 Defender	Bus de télémétrie en continu	1 à 5 minutes	30 jours	Portail Defender (KQL), Advanced Hunting API
Logs d’activité Microsoft graph	Gateway HTTP Microsoft Graph	Pipeline de consignation des requêtes	5 à 15 minutes	Dépendant de l’export (Pas de stockage natif)	Azure Log Analytics (via Diagnostic Settings uniquement)

---

Ce qui est possible vs ce qui n’est pas possible

Ce qui est possible

• Corrélation multi-plans : relier l’adresse IP d’une connexion observée dans Entra ID aux téléchargements de fichiers dans l’UAL et aux acheminements d’e-mails dans Exchange.
• Export continu vers un SIEM : router en continu tous les flux Entra ID et l’UAL vers Azure Log Analytics, Microsoft Sentinel, Splunk ou Elastic via les Diagnostic Settings et l’API Office 365 Management Activity.
• Reconstitution historique sur 180 jours : interroger l’activité des utilisateurs et administrateurs sur 6 mois révolus sur l’ensemble du tenant (sous réserve que l’UAL n’ait pas été désactivé).
• Mise en évidence de l’utilisation de jetons non interactifs : suivre l’utilisation d’un jeton de rafraîchissement volé par un attaquant interrogeant l’API Graph sans MFA interactive (voir Fiche 09 — Analyse des Journaux de Connexion Entra).

Ce qui n’est pas possible

• Récupération rétroactive de flux non licenciés : si le tenant était sous licence Entra Free, les connexions non interactives ne peuvent être restituées. Si les utilisateurs n’avaient pas de licence Purview Audit (Premium), l’événement MailItemsAccessed n’a jamais été consigné.
• Capture réseau Brute de paquets (PCAP) : Microsoft 365 ne fournit pas d’accès aux flux TLS bruts de la couche transport SaaS. L’analyste examine des logs transactionnels, non des trames réseau.
• Recherche de suivi des messages au-delà de 90 jours : les logs de routage SMTP antérieurs à 90 jours sont irrévocablement purgés par Microsoft ; aucun ticket de support ne permet de les recouvrer.
• Restauration des logs sur un tenant où l’UAL était désactivé : si un administrateur a précédemment exécuté Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $false, aucun log d’activité n’existe pour cette période.

---

Conditions nécessaires et prérequis

Pour pouvoir collecter et investiguer l’ensemble des couches de journalisation, l’intervenant doit s’assurer des éléments suivants :

1. Socle de licences :
   • Entra ID P1 ou P2 (pour débloquer la rétention de 30 jours et les logs non interactifs / applicatifs).
   • Microsoft 365 E3 ou E5 (pour débloquer la rétention UAL de 180 jours, l’Audit Premium et les tables d’Advanced Hunting).
2. Rôles d’accès minimaux :
   • Security Reader (rôle d’annuaire Entra ID pour l’authentification et le risque).
   • Audit Reader ou View-Only Audit Logs (rôle Purview pour la recherche UAL).
   • View-Only Recipients + Compliance Management (rôles Exchange Online pour Message Trace).
3. Configurations du tenant :
   • Ingestion UAL active (UnifiedAuditLogIngestionEnabled = $true).
   • Audit de boîte aux lettres activé (AuditEnabled = $true sur les boîtes ciblées).
   • Paramètres de diagnostic configurés pour diffuser les logs vers un stockage pérenne (voir Fiche 04 — préparation d’un tenant pour le DFIR).

---

Artefacts et journaux : tableau de correspondance architecturale

Question d’investigation forensique	Source de logs principale	Source de corrélation secondaire	Champs clés de liaison
Comment l’attaquant s’est-il authentifié ?	Logs de connexion Entra (SignInLogs)	Defender IdentityLogonEvents	CorrelationId, IPAddress, UserAgent, ConditionalAccessStatus
Quels e-mails ont été expédiés ou reçus par l’attaquant ?	Suivi des messages Exchange (Message Trace)	UAL ExchangeItem (Send)	NetworkMessageId, MessageSubject, RecipientAddress, SenderAddress
L’attaquant a-t-il ouvert ou lu des e-mails précis ?	UAL Purview (MailItemsAccessed)	Exchange Mailbox Audit	MailboxOwnerUPN, FolderItems, InternetMessageId, LogonType
Quels fichiers ont été consultés ou exfiltrés de OneDrive/SharePoint ?	UAL Purview (FileDownloaded, FileAccessed)	Defender CloudAppEvents	SiteUrl, SourceFileName, SourceRelativeUrl, ClientIP
L’attaquant a-t-il créé une application ou un secret de persistance ?	Audits d’annuaire Entra (DirectoryAudits)	UAL Purview (ApplicationManagement)	ActivityDisplayName, TargetResources, InitiatedBy, ModifiedProperties
L’attaquant a-t-il altéré les règles de transfert ou de transport ?	UAL Purview (New-InboxRule, Set-Mailbox)	Exchange Admin Audit	Parameters, UserId, ObjectId, ClientIP

---

Méthodologie d’investigation : cartographier et vérifier les flux du tenant

Avant d’entamer l’analyse d’une intrusion, validez impérativement l’état de santé de l’infrastructure de journalisation.

Audit PowerShell des flux

# ==============================================================================
# Hermes Codex - Contrôle d'intégrité de la journalisation Microsoft 365
# Vérifie l'activation de l'UAL, l'audit de boîte et les paramètres de diagnostic
# ==============================================================================

Write-Host "[*] Audit des pipelines de journalisation Microsoft 365..." -ForegroundColor Cyan

# 1. Vérifier l'ingestion du Journal d'Audit Unifié (UAL)
Import-Module ExchangeOnlineManagement -ErrorAction Stop
Connect-ExchangeOnline -ShowBanner:$false

$adminAuditConfig = Get-AdminAuditLogConfig
if ($adminAuditConfig.UnifiedAuditLogIngestionEnabled) {
    Write-Host "[+] Ingestion du Journal d'Audit Unifié : ACTIVÉE (Conforme)" -ForegroundColor Green
} else {
    Write-Error "[-] CRITIQUE : L'ingestion du Journal d'Audit Unifié est DÉSACTIVÉE sur ce tenant !"
}

# 2. Vérifier l'activation par défaut de l'audit de boîte mail
$mailboxAuditConfig = Get-OrganizationConfig | Select-Object AuditDisabled
if (-not $mailboxAuditConfig.AuditDisabled) {
    Write-Host "[+] Audit des boîtes aux lettres au niveau tenant : ACTIVÉ (Défaut)" -ForegroundColor Green
} else {
    Write-Warning "[-] L'audit des boîtes aux lettres est DÉSACTIVÉ globalement !"
}

# 3. Vérifier les paramètres de diagnostic Entra ID via Microsoft Graph
Import-Module Microsoft.Graph.Authentication -ErrorAction Stop
Connect-MgGraph -Scopes "Reports.Read.All", "Directory.Read.All" -NoWelcome

$diagSettings = Invoke-MgGraphRequest -Method GET -Uri "https://graph.microsoft.com/v1.0/reports/diagnosticSettings" -ErrorAction SilentlyContinue

if ($diagSettings.value.Count -gt 0) {
    Write-Host "[+] Paramètres de diagnostic Entra actifs : $($diagSettings.value.Count) flux configuré(s)." -ForegroundColor Green
    foreach ($setting in $diagSettings.value) {
        Write-Host "    -> Destination : $($setting.name) (WorkspaceId : $($setting.workspaceId))" -ForegroundColor Gray
    }
} else {
    Write-Warning "[-] ATTENTION : Aucun paramètre de diagnostic configuré. Risque d'écrasement des logs !"
}

KQL : corrélation multi-plans

// ==============================================================================
// Microsoft Defender XDR - Corrélation multi-plans Identité et Cloud
// Relie une connexion suspecte aux actions fichiers et e-mails correspondantes
// ==============================================================================
let CompteCible = "victime@domaine.com";
let FenetreRecherche = 7d;

// 1. Identifier les connexions réussies pour le compte cible
let ConnexionsUtilisateur = IdentityLogonEvents
| where TimeGenerated >= ago(FenetreRecherche)
| where AccountUpn =~ CompteCible
| where ActionType == "LogonSuccess"
| project SignInTime = TimeGenerated, IPAddress, AccountUpn, Application, DeviceName;

// 2. Corréler avec CloudAppEvents (actions SharePoint, OneDrive, Exchange dans l'UAL)
CloudAppEvents
| where TimeGenerated >= ago(FenetreRecherche)
| where AccountId =~ CompteCible
| where ActionType in ("FileDownloaded", "FileAccessed", "MailItemsAccessed", "New-InboxRule")
| project ActionTime = TimeGenerated, ActionType, Application, IPAddress, ActivityType, RawEventData
| join kind=inner (ConnexionsUtilisateur) on IPAddress
| project ActionTime, AccountUpn, ActionType, Application, IPAddress, RawEventData
| order by ActionTime desc

---

Exemple d’investigation : reconstitution multi-plans

Contexte

La direction financière signale des ordres de virement frauduleux émis depuis la boîte aux lettres d’un contrôleur de gestion.

Reconstitution chronologique multi-plans

1. Plan d’identité (entra ID) : l’analyste interroge les logs de connexion (m365-09). Une connexion interactive est identifiée depuis l’adresse IP 198.51.100.42 (proxy résidentiel). Le MFA a été contourné via le vol du cookie de session (phishing AiTM).
2. Plan de transport (Exchange message trace) : l’analyste examine le suivi des messages (m365-15). Un e-mail malveillant à destination d’un établissement bancaire externe est identifié à 14h22 UTC avec le NetworkMessageId = "f67b28...".
3. Plan de conformité (purview UAL) : l’analyste interroge l’UAL (m365-13). À 14h15 UTC (7 minutes avant l’envoi), l’événement New-InboxRule est consigné : l’attaquant a créé une règle masquée nommée . supprimant automatiquement tous les e-mails entrants contenant les mots-clés virement, banque, ou fraude.
4. Plan de données (mailbox auditing) : l’analyste vérifie les événements MailItemsAccessed dans Purview Audit Premium (m365-17). Plus de 450 messages contenant des bilans comptables ont été consultés entre 14h02 et 14h20 UTC depuis la même IP.

Sans cette corrélation multi-plans, l’analyste n’aurait visualisé que l’e-mail frauduleux, sans identifier le cookie volé, la règle de persistance furtive, ni l’étendue de l’exfiltration de données financières.

---

Doctrine transversale : plans de journalisation vs preuve forensique

Disposer d’une architecture de logs ne garantit pas la certitude d’une preuve matérielle :

+-------------------------------------------------------------------------------+
|                      LES 7 NIVEAUX DE CERTITUDE FORENSIQUE                     |
|                                                                               |
|  1. Possible     -> L'architecture de la plateforme permet de tracer l'action.|
|  2. Configuré   -> L'ingestion UAL et l'audit de boîte sont activés.          |
|  3. Autorisé    -> Le compte disposait des rôles nécessaires pour agir.      |
|  4. Accessible  -> L'accès conditionnel et le réseau autorisaient l'action.  |
|  5. Utilisé     -> L'attaquant a déclenché des requêtes sur le service.      |
|  6. Observé     -> L'enregistrement apparaît dans Sign-in logs ou l'UAL.      |
|  7. Prouvé      -> La corrélation multi-plans valide le déroulement complet.  |
+-------------------------------------------------------------------------------+

Applications directes à l’architecture des logs

1. Possible != configuré : purview est architecturalement capable de journaliser MailItemsAccessed, mais cette fonctionnalité n’est pas configurée si les comptes ne disposent pas d’une licence Purview Audit (Premium).
2. Utilisé != observé : un attaquant a pu effectuer une recherche dans Outlook Web App, mais si l’événement est encore bloqué dans la file d’attente d’ingestion (ou pendant une dégradation de service Microsoft), l’action a été utilisée mais n’est pas encore observée.
3. Observé != prouvé : un enregistrement dans SignInLogs avec ResultType = 0 (Succès) atteste d’une authentification réussie. Prouver qu’une personne malveillante a pris le contrôle effectif de la boîte exige de corréler cette connexion avec les actions applicatives enregistrées dans CloudAppEvents ou l’UAL partageant la même adresse IP et le même User-Agent.

---

Pièges et confusions fréquentes

Piège	Cause technique	Conséquence pour l’enquête	Action corrective
Croire que l’UAL est instantané	Le pipeline d’ingestion traite les événements par files d’attente asynchrones.	Conclure à l’absence d’activité sur la dernière heure car l’UAL est vide.	Prendre systématiquement en compte la latence propre à chaque service (jusqu’à 1h sur Exchange, 24h sur Teams).
Se limiter aux logs de connexion	Les sign-in logs ne tracent que l’identité, pas l’accès aux ressources.	Incapacité à qualifier la fuite de données ou la modification de règles.	Pivoter systématiquement d’Entra ID vers l’UAL Purview et le Message Trace.
Confondre rétention par défaut et archivage	Entra Free n’enregistre que 7 jours ; Defender ne retient les tables brutes que 30 jours.	Perte définitive des preuves avant le démarrage de l’expertise.	Activer le streaming via Diagnostic Settings vers Log Analytics dès la création du tenant.
Ignorer les ruptures d’ingestion lors de migrations	Les migrations de boîtes ou de tenants interrompent parfois temporairement l’audit.	Trous inexpliqués dans la chronologie de l’incident.	Auditer AdminAuditLogConfig et vérifier la volumétrie des événements lors des périodes de transition.
Confondre admin audit et user audit dans Exchange	Les modifications administrateur (Set-Mailbox) et les accès utilisateur (MailItemsAccessed) utilisent des RecordTypes différents.	L’analyste applique un mauvais filtre dans l’UAL et croit que l’événement n’existe pas.	Maîtriser les filtres RecordType : ExchangeAdmin vs ExchangeItem.

---

État de la fonctionnalité en 2026

Changements récents

• Rétention UAL standard à 180 jours : la conservation par défaut des événements d’audit unifiés est de 180 jours sur l’ensemble des licences professionnelles.
• Alignement des schémas entra et log analytics : parité totale entre les objets d’audit exposés par Microsoft Graph et les tables SigninLogs et AADNonInteractiveUserSignInLogs de Log Analytics.
• Intégration de global Secure access (GSA) : les logs de connexion intègrent désormais le champ networkLocationDetails pour identifier les sessions transitant par le Security Service Edge (SSE) de Microsoft.

Fonctionnalités dépréciées

• API azure AD graph (graph.windows.net) : définitivement retirée. L’ensemble des requêtes d’annuaire doit utiliser Microsoft Graph (graph.microsoft.com/v1.0).
• Sessions distantes PowerShell Exchange V1/V2 : retirées. Les requêtes administratives doivent exploiter le module ExchangeOnlineManagement v3+ reposant sur REST.

Limitations actuelles

• Latence d’ingestion teams : teams conserve la latence la plus élevée de l’écosystème M365, avec des délais pouvant dépasser 12 heures en période de charge mondiale.
• Délai des diagnostic settings : bien que l’API Graph expose les connexions en 2 à 5 minutes, le streaming vers un SIEM externe via Event Hub peut introduire une latence tampon de 5 à 15 minutes.

---

Points clés à retenir

1. Microsoft 365 est un écosystème de journalisation distribué : maîtriser l’articulation entre le plan d’identité (Entra ID), le plan de conformité (Purview UAL), le plan de diagnostic (Message Trace) et le plan de sécurité (Defender XDR).
2. Intégrer les délais d’ingestion : ne jamais clore une phase de confinement sans intégrer la fenêtre de latence d’ingestion (1h à 24h).
3. Corréler entre les plans : une connexion dans Entra ID n’a de sens forensique que confrontée à l’activité dans l’UAL et au transit dans Exchange.
4. Mettre en place un archivage externe : la rétention native est insuffisante pour les investigations longues ; diffuser en continu vers un espace Log Analytics.
5. Appliquer la doctrine des 7 niveaux de certitude : ne jamais affirmer qu’une action est prouvée lorsque la télémétrie indique seulement qu’elle était possible ou autorisée.

---

Références

• Microsoft Learn : vue d’ensemble des solutions d’audit Purview
• Microsoft Entra ID : schéma des journaux de connexion
• Microsoft Learn : interroger le journal d’audit unifié
• Microsoft Learn : schéma des tables d’Advanced Hunting Defender XDR
• Référence du schéma de l’API Office 365 Management Activity