TL;DR Executive

  • Les investigations M365 robustes reposent sur la corrélation de trois couches: Entra (identité), Unified Audit Log/Purview (actions inter-services), et logs workload spécifiques (ex. mailbox auditing Exchange). [1][4][5][6][7]
  • Purview Audit (Standard) fournit une base exploitable; Audit (Premium) améliore surtout la rétention et certaines capacités avancées (jusqu’à 1 an par défaut sur workloads clés, extensible via politiques). [2][6][8]
  • Les scénarios de compromission les plus fréquents en pratique: takeover de compte, abuse OAuth/service principal, exfiltration via SharePoint/OneDrive, et persistence par règles de boîte ou délégations. [3][4][7][9][12]
  • Le retard d’ingestion et l’agrégation (notamment via API d’activité) imposent une prudence temporelle: la timeline brute peut être non ordonnée et incomplète à court terme. [10]
  • Les artefacts techniques déterminants incluent ClientIP, Operation, Workload, CorrelationId, AppId, UserAgent/ClientInfoString, et propriétés détaillées exportées dans AuditData. [11][13]
  • Le risque probatoire principal n’est pas l’absence totale de logs, mais la mauvaise interprétation (licences/rétention, périmètre de recherche, faux négatifs temporels). [2][6][8][10]
  • Pour la défensibilité judiciaire, il faut documenter méthodiquement la chaîne: collecte (requêtes), export, normalisation, corrélation, limitations déclarées, et validation croisée avec TTP connus. [10][14][15]
  • Niveau de confiance global: élevé sur le cadre technique Microsoft/CISA; modéré sur la généralisation des playbooks à tous contextes de litige.

Problématique et objectifs

Question de recherche. Dans quelle mesure les logs M365 (Entra, Exchange, SharePoint/OneDrive via Purview) permettent-ils de reconstruire un scénario de compromission de manière techniquement fiable et probatoirement défendable?

Objectifs.

  1. Identifier les sources de logs pertinentes et leur valeur forensique.
  2. Structurer des scénarios de compromission typiques et les traces attendues.
  3. Évaluer limites, angles morts et risques d’interprétation.
  4. Proposer un cadre de corrélation compatible avec une exigence de chaîne de possession numérique.

Méthodologie

  • Stratégie de recherche: revue documentaire en 2 couches:
  • Couche A (sources primaires): Microsoft Learn/Purview/Entra/Exchange/API, CISA.
  • Couche B (sources secondaires crédibles): Microsoft Security Experts (retour d’incident), cadres externes (NIST, MITRE) pour aligner l’interprétation.
  • Critères d’inclusion: documentation officielle à jour, spécifications de champs/retention/capacités, guides d’investigation incident.
  • Critères d’exclusion: billets marketing non techniques, contenus sans auteur clair, sources sans date ou sans vérifiabilité.
  • Nombre d’URL analysées: 15/100.
  • Limites méthodologiques: hétérogénéité de profondeur entre pages Microsoft; certaines pages sont orientées opérations SI plutôt que preuve judiciaire; dépendance au niveau de licence et de configuration tenant.

Cadre conceptuel / technique / juridique

  • Le Unified Audit Log centralise des événements multi-workloads (Entra, Exchange, SharePoint/OneDrive, etc.) et sert de pivot transversal. [1][2][6]
  • Les logs Entra distinguent au moins les plans sign-ins (accès) et audit (changements d’objets/permissions/apps), essentiels pour qualifier une compromission identité. [4][5]
  • Exchange ajoute la couche mailbox auditing (dont MailItemsAccessed) utile pour estimer le périmètre d’exposition de contenu. [7][9]
  • Le cadre incident NIST rappelle que la valeur d’un artefact dépend du cycle complet (préparation, détection/analyse, containment, post-incident), pas d’un événement isolé. [14]
  • La cartographie MITRE (ex. Account Manipulation T1098) aide à lier observations logiques à hypothèses d’attaque reproductibles. [15]

Analyse critique des résultats

1) Scénario A — Compromission de compte utilisateur (Account Takeover)

Le schéma le plus robuste commence par les sign-ins Entra (type d’authentification, IP, client, statut), puis corrèle avec activités Purview et mailbox actions. [2][3][4][5]

« Entries in the sign-in logs are system generated and can’t be changed or deleted. » [4]

Cette propriété renforce la fiabilité de base des traces d’authentification, mais ne dispense pas d’une validation d’environnement (NAT, VPN, accès légitime partagé).

2) Scénario B — Persistence et exfiltration email (Exchange)

Mailbox auditing est activé par défaut, et MailItemsAccessed apporte une granularité forensique utile pour quantifier l’exposition potentielle, y compris agrégation bind/sync. [7][9]

« The goal of using this new auditing action is forensics defensibility to help assert that a specific piece of mail data wasn’t compromised. » [9]

Point critique: l’agrégation (fenêtres temporelles) impose une lecture prudente sur la granularité réelle d’accès.

3) Scénario C — Compromission d’application OAuth / service principal

Les changements d’applications/permissions apparaissent dans les activités d’administration applicative et peuvent être investigués via UAL + Entra sign-ins/audit. [1][5][12]

« A key to any investigation is what forensic data is logged, where that data is available, and how long is the retention of that data. » [12]

Ce scénario est particulièrement sensible aux gaps de rétention et à la qualité de l’export initial.

4) Scénario D — Exfiltration documentaire SharePoint/OneDrive

Purview et l’API d’activité Office 365 permettent de récupérer événements SharePoint/OneDrive à des fins de monitoring/investigation. [1][6][10] La contrainte majeure est l’ordre temporel: les blobs d’activité peuvent contenir des événements non strictement séquentiels. [10]

5) Valeur et limites probatoires transversales

  • Forces: centralisation, richesse des opérations, export CSV/JSON, API, rétention configurable selon licences. [2][6][8][10][11]
  • Faiblesses: dépendance au licensing utilisateur, priorités de politiques de rétention, délais d’apparition des données, mauvaise lecture des champs détaillés. [2][8][10][11][13]

Discussion

Pour un dossier civil/commercial, la meilleure posture est une approche « multi-journal corrélé »:

  1. Identité (Entra): qui s’est authentifié, comment, d’où. [4][5]
  2. Action transverse (Purview/UAL): quelles opérations et workloads. [1][2][6]
  3. Objet métier (Exchange/SharePoint): quels contenus potentiellement consultés/exfiltrés. [7][9][10]
  4. Contextualisation TTP: cohérence avec techniques connues (ex. manipulation de comptes). [15]
  5. Narratif incident conforme NIST: chronologie + décisions + limites. [14]

Cette méthode réduit les faux positifs (activité admin légitime) et les faux négatifs (absence apparente due à rétention/latence).

Limites et incertitudes

  • Les capacités observables dépendent fortement du niveau de licence et des politiques de rétention effectivement appliquées aux utilisateurs impliqués. [2][8]
  • La reconstruction fine peut être biaisée par l’agrégation/latence de certaines sources API. [10]
  • Certains artefacts restent contextuels (IP partagée, automation légitime), nécessitant corroboration externe (proxy, EDR, CASB/SIEM).

Conclusion

Les logs M365 (Entra, Exchange, SharePoint via Purview) permettent une reconstruction substantielle des scénarios de compromission, à condition d’appliquer une corrélation multi-sources et de documenter explicitement les limites de rétention et de temporalité. En contexte d’expertise, la défensibilité repose moins sur la quantité brute de logs que sur la rigueur méthodologique de collecte, la transparence des incertitudes, et la concordance des traces avec un modèle d’attaque documenté.

Références

  1. Audit log activities — Microsoft Learn, s.d — https://learn.microsoft.com/en-us/purview/audit-log-activities
  2. Search the audit log — Microsoft Learn, s.d — https://learn.microsoft.com/en-us/purview/audit-search
  3. Search the audit log to troubleshoot common scenarios — Microsoft Learn, s.d — https://learn.microsoft.com/en-us/purview/audit-troubleshooting-scenarios
  4. Sign-in logs in Microsoft Entra ID — Microsoft Learn, s.d — https://learn.microsoft.com/en-us/entra/identity/monitoring-health/concept-sign-ins
  5. Learn about the audit logs in Microsoft Entra ID — Microsoft Learn, s.d — https://learn.microsoft.com/en-us/entra/identity/monitoring-health/concept-audit-logs
  6. Learn about auditing solutions in Microsoft Purview — Microsoft Learn, s.d — https://learn.microsoft.com/en-us/purview/audit-solutions-overview
  7. Manage mailbox auditing — Microsoft Learn, s.d — https://learn.microsoft.com/en-us/purview/audit-mailboxes
  8. Manage audit log retention policies — Microsoft Learn, s.d — https://learn.microsoft.com/en-us/purview/audit-log-retention-policies
  9. Use MailItemsAccessed to investigate compromised accounts — Microsoft Learn, s.d — https://learn.microsoft.com/en-us/purview/audit-log-investigate-accounts
  10. Office 365 Management Activity API reference — Microsoft Learn, s.d — https://learn.microsoft.com/en-us/office/office-365-management-api/office-365-management-activity-api-reference
  11. Detailed activity properties in the audit log — Microsoft Learn, s.d — https://learn.microsoft.com/en-us/purview/audit-log-detailed-properties
  12. Investigating malicious OAuth applications using the Unified Audit Log — Microsoft Tech Community, 2023 — https://techcommunity.microsoft.com/blog/microsoftsecurityexperts/investigating-malicious-oauth-applications-using-the-unified-audit-log/4007172
  13. Office 365 Management Activity API schema — Microsoft Learn, s.d — https://learn.microsoft.com/en-us/office/office-365-management-api/office-365-management-activity-api-schema
  14. NIST SP 800-61 Rev.2 (Computer Security Incident Handling Guide) — NIST, 2012/ressource indexée — https://www.nist.gov/privacy-framework/nist-sp-800-61
  15. Account Manipulation (T1098) — MITRE ATT&CK, s.d — https://attack.mitre.org/techniques/T1098/

Articles qui pourraient vous intéresser