Aller au contenu
Hermes Codex

Message trace vs mailbox audit vs unified audit log

Lors de l’investigation d’incidents ciblant la messagerie — qu’il s’agisse d’une compromission de compte (BEC), d’une attaque par reverse proxy AiTM ou d’une fuite massive de données —, l’équipe DFIR est confrontée à trois sources de télémétrie distinctes : le Message Trace d’Exchange, l’Audit de Boîte Mail (Mailbox Auditing) et le Unified Audit Log (UAL) de Microsoft Purview.

Chacun de ces systèmes répond à une question forensique fondamentalement différente :

  • Le Message Trace répond à : Le message a-t-il transité par le réseau et a-t-il été distribué ?
  • L’Audit de Boîte Mail répond à : Que s’est-il passé à l’intérieur de la boîte et le courriel a-t-il été lu ou supprimé ?
  • L’Unified Audit Log répond à : Qui a réalisé ces actions à l’échelle du tenant, depuis quelle adresse IP et dans quel contexte de session globale ?

Négliger la corrélation entre ces trois sources expose l’investigation à des conclusions erronées. L’erreur la plus fréquente consiste à affirmer qu’un courriel a été « lu » sur la seule base d’un statut Deliver dans le Message Trace, ou à ignorer la création d’une règle de boîte pirate parce que l’analyste n’a cherché que des traces d’envoi.

1. Le modèle forensique triangulaire

Section intitulée « 1. Le modèle forensique triangulaire »

L’investigation rigoureuse de la messagerie dans Microsoft 365 repose sur le Modèle de Corrélation Triangulaire, reliant transport, stockage en boîte et conformité d’annuaire :

graph TD
    subgraph "1. Plan de Transport (Exchange Message Trace)"
        MT_RECV[Événement Receive<br/>OriginalClientIpAddress]
        MT_EOP[Filtrage EOP & Authentification<br/>SPF / DKIM / DMARC]
        MT_DELIV[Distribution Store Driver<br/>Statut : Deliver]
    end


    subgraph "2. Plan de Stockage & Accès (Mailbox Auditing)"
        MA_ACCESS[MailItemsAccessed<br/>Accès Bind vs Sync]
        MA_RULES[Règles de Boîte Réception<br/>New-InboxRule / Move]
        MA_DELETE[Cycle de Vie des Éléments<br/>SoftDelete / HardDelete]
    end


    subgraph "3. Plan de Conformité Entreprise (Purview UAL)"
        UAL_SESSION[Contexte de Session Attaquant<br/>ClientIP, UserAgent, SessionId]
        UAL_IDENTITY[Vérification d'Identité<br/>UserKey, Jeton Entra ID]
        UAL_CROSS[Corrélation Transverse<br/>Téléchargements SharePoint, Consentements OAuth]
    end


    MT_DELIV -->|Message Distribué| MA_ACCESS
    MA_ACCESS -->|Événements Éléments| UAL_SESSION
    MA_RULES -->|Création de Règles| UAL_SESSION
    MT_RECV -.->|Lien NetworkMessageId| UAL_CROSS

2. Matrice comparative des trois plans de journalisation

Section intitulée « 2. Matrice comparative des trois plans de journalisation »
Dimension forensiqueExchange Message TraceMailbox AuditingPurview Unified Audit Log
Plan systèmeTransport & Routage de messagerie (MTA)Magasin de données Exchange (MDB)Sécurité & Conformité transverse
Question clé« Le message a-t-il transité par EOP ? »« Le message a-t-il été lu, déplacé ou supprimé ? »« Quelle était la session globale de l’attaquant ? »
Unité d’enregistrementTransaction SMTP / Métadonnées enveloppeÉlément de boîte / DossierEnregistrement JSON normalisé multi-tenant
Identifiant d’autoritéNetworkMessageId / MessageIdInternetMessageId / FolderIdNetworkMessageId / Id / SessionId
Rétention par défautStrictement 90 jours (Aucune extension)Héritée par l’UAL (180j à 1 an+)Standard : 180 jours
Premium : 1 an à 10 ans
Latence d’ingestionTemps réel (0 à 5 secondes)Immédiate dans la boîteAsynchrone : 15 à 60 minutes
Visibilité du contenuEnveloppe seule (Émetteur, Destinataire, Objet)Objets, identifiants de messages, dossiersJSON polymorphe riche (AuditData)
Preuve de lectureNe peut pas prouver la lectureProuve la lecture via MailItemsAccessedProuve la lecture + attribue l’IP et le user-agent

3. La question classique : « l’utilisateur a-t-il ouvert le mail de phishing ? »

Section intitulée « 3. La question classique : « l’utilisateur a-t-il ouvert le mail de phishing ? » »

Lors d’une crise cyber, la direction et le service juridique exigent immédiatement de savoir : « La victime a-t-elle ouvert le message et cliqué sur le lien frauduleux ? »

Ce que le message trace prouve réellement

Section intitulée « Ce que le message trace prouve réellement »

Lorsque le Message Trace affiche :

Status: Deliver
Detail: The message was successfully delivered to the folder: Inbox

Ce statut atteste uniquement que le module de remise (Store Driver) a déposé le courriel dans le dossier de boîte de réception. Il n’apporte aucune preuve que l’utilisateur s’est connecté, a prévisualisé le message ou a cliqué sur un lien.

Ce que l’audit de boîte et l’UAL permettent de prouver

Section intitulée « Ce que l’audit de boîte et l’UAL permettent de prouver »

Pour prouver l’interaction humaine ou la consultation malveillante, l’investigateur doit pivoter sur l’événement MailItemsAccessed dans l’UAL :

sequenceDiagram
    autonumber
    actor User as Collaborateur / Attaquant
    participant App as Client Outlook Web (OWA)
    participant Store as Magasin de Boîte Exchange
    participant UAL as Purview Unified Audit Log


    User->>App: Clic sur le message dans la boîte (Lecture)
    App->>Store: Requête REST: GetItem(MessageId)
    Store->>Store: Évaluation de la politique d'audit de boîte
    Store->>UAL: Émission de "MailItemsAccessed" (MailAccessType: Bind)
    Note over UAL: Consigne InternetMessageId, ClientIP, UserAgent
    Note over UAL: Preuve formelle de consultation du message !
  • Accès de type bind : prouve formellement que le courriel spécifique a été ouvert ou prévisualisé dans une session interactive (OWA ou Outlook).
  • Accès de type sync : prouve qu’un client de synchronisation (ActiveSync mobile ou script automatisé via Graph/IMAP) a téléchargé le dossier complet.

4. Scénario de corrélation de bout en bout : fraude BEC

Section intitulée « 4. Scénario de corrélation de bout en bout : fraude BEC »

Considérons une attaque BEC typique où un pirate compromet un compte de direction, intercepte une facture fournisseur, modifie le RIB et pose une règle de redirection furtive :

=================================================================================================
CHRONOLOGIE FORENSIQUE RECONSTITUÉE SUR LES TROIS SYSTÈMES
=================================================================================================


1. [08:14:02 UTC] PLAN DE TRANSPORT (Message Trace) :
   - Événement : Receive -> Deliver
   - Expéditeur : facturation@fournisseur-legitime.com
   - Destinataire : cfo@defense-corp.org
   - Objet : "Facture #9812 révisée avec nouvelles coordonnées"
   - NetworkMessageId : 4d12f890-341a-4f89-91a1-987120adfe01
   - Statut : Deliver (Remis en boîte de réception)


2. [08:32:15 UTC] PLAN DE STOCKAGE & ACCÈS (Mailbox Auditing / UAL RecordType 2) :
   - Opération : MailItemsAccessed
   - Type d'accès : Bind
   - InternetMessageId : <FOURNISSEUR-FACT-9812@fournisseur-legitime.com>
   - MailboxOwnerUPN : cfo@defense-corp.org
   - PREUVE : L'attaquant a ouvert et lu le contenu exact de la facture !


3. [08:35:40 UTC] PLAN DE CONFORMITÉ TRANSVERSE (Purview UAL RecordType 1) :
   - Opération : New-InboxRule
   - Utilisateur : cfo@defense-corp.org
   - IP_Client : 185.220.101.42 (Nœud de sortie Tor)
   - Paramètres : MoveToFolder="Flux RSS", DeleteMessage="True"
   - PREUVE : L'attaquant a créé une règle pour masquer les alertes de la comptabilité !


4. [08:42:10 UTC] PLAN DE TRANSPORT (Message Trace) :
   - Événement : Submit -> Send
   - Expéditeur : cfo@defense-corp.org
   - Destinataire : comptabilite@defense-corp.org
   - Objet : "URGENT : Règlement facture #9812 sur nouveau compte"
   - NetworkMessageId : e12a4b89-1234-4567-890a-bcdef0123456
   - PREUVE : Le courriel frauduleux d'ordre de virement a été émis depuis la boîte légitime !
=================================================================================================

5. Scripts de corrélation multi-sources

Section intitulée « 5. Scripts de corrélation multi-sources »
Fenêtre de terminal
Connect-ExchangeOnline -UserPrincipalName dfir@defense-corp.org


$cible = "cfo@defense-corp.org"
$debut = (Get-Date).AddDays(-2).ToUniversalTime()
$fin   = (Get-Date).ToUniversalTime()


# 1. Plan de transport : messages livrés à la victime
Write-Host "[-] Phase 1 : Extraction du Message Trace..." -ForegroundColor Cyan
$mailsLivres = Get-MessageTrace -RecipientAddress $cible -StartDate $debut -EndDate $fin -Status Deliver


# 2. Plan de boîte : événements MailItemsAccessed
Write-Host "[-] Phase 2 : Extraction des lectures de boîte (UAL)..." -ForegroundColor Cyan
$lecturesBoite = Search-UnifiedAuditLog `
    -StartDate $debut `
    -EndDate $fin `
    -RecordType ExchangeItem `
    -Operations "MailItemsAccessed" `
    -FreeText $cible `
    -ResultSize 5000 `
    -Formatted


# 3. Corrélation entre livraison et lecture effective
$idsMessagesLus = foreach ($rec in $lecturesBoite) {
    $audit = $rec.AuditData | ConvertFrom-Json
    if ($audit.Folder.FolderItems) {
        $audit.Folder.FolderItems.InternetMessageId
    }
}


$resultats = foreach ($mail in $mailsLivres) {
    $estLu = if ($idsMessagesLus -contains $mail.MessageId) { $true } else { $false }
    [PSCustomObject]@{
        DateReception    = $mail.Received
        NetworkMessageId = $mail.NetworkMessageId
        Expediteur       = $mail.SenderAddress
        Objet            = $mail.Subject
        LivreEnBoite     = $true
        LectureVerifiee  = $estLu
    }
}


$resultats | Format-Table -AutoSize

6. Pièges & discordances d’interprétation

Section intitulée « 6. Pièges & discordances d’interprétation »

7. Maillage documentaire & liens transverses

Section intitulée « 7. Maillage documentaire & liens transverses »