Forensique Microsoft 365 : Analyse du Unified Audit Log et Investigation

Introduction : Microsoft 365, cible numero un dans le cloud

Microsoft 365 est devenu le socle de collaboration de la majorite des entreprises dans le monde. Avec plus de 400 millions de licences commerciales actives, la suite regroupe la messagerie (Exchange Online), le stockage de fichiers (SharePoint, OneDrive), la communication (Teams), la gestion d'identite (Entra ID) et des dizaines d'applications metier. Cette centralisation fait de M365 la cible numero un des attaquants dans le cloud. En 2025, plus de 60 % des incidents de compromission cloud traites par les equipes DFIR impliquaient un tenant Microsoft 365.

Les techniques des attaquants evoluent rapidement : phishing par QR code, vol de tokens de session, abus de consentement OAuth, creation de regles de boite aux lettres malveillantes, enregistrement d'applications frauduleuses. Face a cette menace, l'analyste forensique doit maitriser les sources de logs specifiques a M365, comprendre les mecanismes de retention, et savoir exploiter des outils comme le Unified Audit Log (UAL), les sign-in logs Entra ID, le message trace Exchange, et les solutions eDiscovery.

Cet article constitue un guide complet pour mener une investigation forensique dans un environnement Microsoft 365. Il couvre l'activation et la configuration du Unified Audit Log, les techniques d'investigation de compromission de compte, l'analyse forensique Exchange Online, SharePoint, OneDrive et Teams, l'utilisation d'eDiscovery pour la collecte de preuves, et les outils specialises comme HAWK, Sparrow et CrowdStrike CRT. Que vous soyez analyste SOC, consultant DFIR ou RSSI, ce guide vous fournira une methodologie operationnelle pour repondre efficacement aux incidents M365.

L'investigation forensique M365 presente des defis uniques par rapport a la forensique traditionnelle sur endpoint. L'analyste n'a pas acces au systeme de fichiers, a la memoire vive ou aux artefacts systeme classiques. Tout repose sur les journaux d'audit fournis par Microsoft, dont la completude, la retention et l'accessibilite dependent du niveau de licence. Comprendre ces contraintes est la premiere etape d'une investigation reussie.

Le Unified Audit Log : pierre angulaire de la forensique M365

Activation et verification

Le Unified Audit Log (UAL) centralise les evenements de l'ensemble des services Microsoft 365 dans un journal unique. Contrairement a ce que beaucoup pensent, l'UAL n'est pas active par defaut sur tous les tenants. La premiere etape de toute investigation est de verifier son statut. Cette verification se fait via PowerShell en se connectant au module Exchange Online :

# Connexion a Exchange Online PowerShell
Connect-ExchangeOnline -UserPrincipalName admin@contoso.com

# Verifier le statut de l'audit
Get-AdminAuditLogConfig | Format-List UnifiedAuditLogIngestionEnabled

# Activer l'audit si necessaire
Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true

# Verifier l'audit par boite aux lettres (active par defaut depuis 2019)
Get-OrganizationConfig | Format-List AuditDisabled

Depuis janvier 2019, Microsoft a active l'audit des boites aux lettres par defaut (mailbox auditing on by default). Cependant, un administrateur malveillant ou un attaquant disposant de privileges suffisants peut desactiver cette fonctionnalite. Il est donc essentiel de verifier ce parametre systematiquement au debut de chaque investigation.

Types d'evenements audites

L'UAL enregistre des centaines de types d'evenements repartis dans plusieurs categories. Voici les plus pertinents pour l'investigation forensique :

Categorie	Evenements cles	Pertinence forensique
Entra ID	UserLoggedIn, UserLoginFailed, Add member to role	Compromission de compte, escalade de privileges
Exchange Online	New-InboxRule, Set-Mailbox, MailItemsAccessed	Regles malveillantes, acces aux emails
SharePoint/OneDrive	FileDownloaded, FileShared, SharingSet	Exfiltration de donnees
Teams	MemberAdded, ChannelAdded, MessageSent	Mouvement lateral, communication suspecte
Azure AD Apps	Add application, Consent to application, Add app role assignment	Persistence via applications OAuth
DLP	DlpRuleMatch, SensitiveFileDetected	Tentatives d'exfiltration de donnees sensibles
Power Platform	CreateFlow, UpdateFlow	Automatisation malveillante

Recherche dans l'UAL avec PowerShell

La cmdlet Search-UnifiedAuditLog est l'outil principal pour interroger l'UAL. Attention : elle retourne un maximum de 5 000 resultats par appel et necessite une pagination pour les recherches volumineuses. Voici les commandes essentielles :

# Recherche basique sur un utilisateur compromis
Search-UnifiedAuditLog -StartDate "2026-01-01" -EndDate "2026-02-15" `
    -UserIds "victim@contoso.com" -ResultSize 5000

# Recherche des connexions suspectes
Search-UnifiedAuditLog -StartDate "2026-01-15" -EndDate "2026-02-15" `
    -Operations "UserLoggedIn","UserLoginFailed" `
    -UserIds "victim@contoso.com" -ResultSize 5000

# Recherche des regles de boite aux lettres creees
Search-UnifiedAuditLog -StartDate "2026-01-01" -EndDate "2026-02-15" `
    -Operations "New-InboxRule","Set-InboxRule","Enable-InboxRule" `
    -ResultSize 5000

# Recherche des consentements OAuth
Search-UnifiedAuditLog -StartDate "2026-01-01" -EndDate "2026-02-15" `
    -Operations "Consent to application" -ResultSize 5000

# Recherche avec pagination pour des resultats volumineux
$results = @()
$sessionId = [Guid]::NewGuid().ToString()
do {
    $batch = Search-UnifiedAuditLog -StartDate "2026-01-01" `
        -EndDate "2026-02-15" -SessionId $sessionId `
        -SessionCommand ReturnLargeSet -ResultSize 5000
    $results += $batch
} while ($batch.Count -eq 5000)

# Export en CSV pour analyse
$results | Select-Object CreationDate, UserIds, Operations, AuditData |
    Export-Csv -Path "C:\Investigation\UAL_Export.csv" -NoTypeInformation

# Extraction des donnees JSON imbriquees
$results | ForEach-Object {
    $audit = $_.AuditData | ConvertFrom-Json
    [PSCustomObject]@{
        Timestamp   = $audit.CreationTime
        User        = $audit.UserId
        Operation   = $audit.Operation
        ClientIP    = $audit.ClientIP
        UserAgent   = $audit.ExtendedProperties |
                      Where-Object { $_.Name -eq "UserAgent" } |
                      Select-Object -ExpandProperty Value
        ResultStatus = $audit.ResultStatus
    }
} | Export-Csv -Path "C:\Investigation\UAL_Parsed.csv" -NoTypeInformation

Investigation de compromission de compte

La compromission de compte est le scenario d'investigation le plus frequent dans M365. L'attaquant obtient les credentials d'un utilisateur par phishing, brute force, password spraying ou vol de token, puis utilise le compte pour acceder aux donnees, etablir une persistance et eventuellement se deplacer lateralement dans le tenant. Voici la methodologie d'investigation structuree.

Analyse des Sign-in Logs Entra ID

Les sign-in logs Entra ID (anciennement Azure AD) constituent la premiere source a analyser. Ils contiennent des informations detaillees sur chaque tentative de connexion : adresse IP source, localisation geographique, user agent, application cliente, resultat de la politique d'acces conditionnel et statut MFA.

# Connexion a Microsoft Graph
Connect-MgGraph -Scopes "AuditLog.Read.All","Directory.Read.All"

# Recuperer les sign-in logs pour un utilisateur
$signIns = Get-MgAuditLogSignIn -Filter "userPrincipalName eq 'victim@contoso.com'" `
    -Top 500 -OrderBy "createdDateTime desc"

# Analyser les connexions par IP et localisation
$signIns | Group-Object -Property IpAddress | Sort-Object Count -Descending |
    Select-Object Name, Count | Format-Table

# Identifier les connexions depuis des pays inhabituels
$signIns | Select-Object CreatedDateTime, IpAddress,
    @{N='City';E={$_.Location.City}},
    @{N='Country';E={$_.Location.CountryOrRegion}},
    @{N='App';E={$_.AppDisplayName}},
    Status, ConditionalAccessStatus |
    Where-Object { $_.Country -notin @('FR','BE','CH') } |
    Format-Table -AutoSize

# Verifier les echecs de connexion (password spraying)
$signIns | Where-Object { $_.Status.ErrorCode -ne 0 } |
    Group-Object -Property @{E={$_.Status.ErrorCode}} |
    Sort-Object Count -Descending

Les indicateurs de compromission typiques dans les sign-in logs incluent : des connexions depuis des adresses IP dans des pays inhabituels, des connexions simultanees depuis des localisations geographiquement incompatibles (impossible travel), l'utilisation de user agents suspects (comme des outils d'automatisation Python, curl ou PowerShell), et des connexions reussies apres une serie d'echecs concentres dans le temps.

Detection des regles de boite aux lettres malveillantes

L'une des premieres actions d'un attaquant apres la compromission d'un compte Exchange est la creation de regles de boite aux lettres (inbox rules). Ces regles servent a masquer les emails de notification de securite, a rediriger les messages vers un dossier cache ou un compte externe, ou a supprimer automatiquement les alertes. C'est un mecanisme de persistance classique que l'on retrouve dans la quasi-totalite des compromissions BEC (Business Email Compromise).

# Lister toutes les regles de boite aux lettres
Get-InboxRule -Mailbox "victim@contoso.com" |
    Select-Object Name, Description, Enabled, Priority,
    DeleteMessage, MoveToFolder, ForwardTo, ForwardAsAttachmentTo,
    RedirectTo, MarkAsRead |
    Format-List

# Rechercher les regles qui redirigent ou suppriment
Get-InboxRule -Mailbox "victim@contoso.com" |
    Where-Object {
        $_.ForwardTo -or $_.ForwardAsAttachmentTo -or
        $_.RedirectTo -or $_.DeleteMessage -eq $true -or
        $_.MoveToFolder -match "RSS|Deleted"
    } | Format-List Name, ForwardTo, RedirectTo, DeleteMessage

# Rechercher dans l'UAL la creation de regles suspectes
Search-UnifiedAuditLog -StartDate "2026-01-01" -EndDate "2026-02-15" `
    -Operations "New-InboxRule","Set-InboxRule" `
    -UserIds "victim@contoso.com" | ForEach-Object {
        $data = $_.AuditData | ConvertFrom-Json
        [PSCustomObject]@{
            Date      = $data.CreationTime
            User      = $data.UserId
            RuleName  = ($data.Parameters | Where-Object {$_.Name -eq "Name"}).Value
            ForwardTo = ($data.Parameters | Where-Object {$_.Name -eq "ForwardTo"}).Value
            DeleteMsg = ($data.Parameters | Where-Object {$_.Name -eq "DeleteMessage"}).Value
            ClientIP  = $data.ClientIP
        }
    }

Analyse des consentements OAuth et applications enregistrees

Les attaquants utilisent de plus en plus les mecanismes de consentement OAuth pour etablir une persistance durable dans un tenant M365. En incitant un utilisateur a consentir a une application malveillante, l'attaquant obtient un acces API qui survit au changement de mot de passe et au reset MFA. C'est l'une des techniques de persistance les plus dangereuses car elle est souvent invisible pour l'utilisateur et les equipes IT. Pour une analyse approfondie de ces mecanismes, consultez notre article sur la securite des applications enregistrees dans Azure AD.

# Rechercher les consentements OAuth dans l'UAL
Search-UnifiedAuditLog -StartDate "2026-01-01" -EndDate "2026-02-15" `
    -Operations "Consent to application" -ResultSize 5000 |
    ForEach-Object {
        $data = $_.AuditData | ConvertFrom-Json
        [PSCustomObject]@{
            Date       = $data.CreationTime
            User       = $data.UserId
            AppName    = $data.Target[0].ID
            Permissions = ($data.ModifiedProperties |
                Where-Object {$_.Name -eq "ConsentContext.IsAdminConsent"}).NewValue
            ClientIP   = $data.ClientIP
        }
    }

# Lister les applications avec des permissions elevees
Get-MgServicePrincipal -All | ForEach-Object {
    $sp = $_
    $appRoles = Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $sp.Id
    if ($appRoles) {
        [PSCustomObject]@{
            AppName     = $sp.DisplayName
            AppId       = $sp.AppId
            Created     = $sp.AdditionalProperties.createdDateTime
            Permissions = ($appRoles | Select-Object -ExpandProperty AppRoleId) -join ", "
        }
    }
} | Where-Object { $_.AppName -notmatch "Microsoft|Office|Azure" }

Verification du mailbox forwarding

Outre les regles de boite aux lettres, les attaquants configurent souvent le forwarding SMTP au niveau de la boite aux lettres elle-meme. Ce forwarding est different des inbox rules : il est configure au niveau du transport Exchange et redirige tous les emails entrants vers une adresse externe sans laisser de copie dans la boite d'origine. C'est une technique furtive utilisee dans les attaques BEC pour intercepter les communications financieres.

# Verifier le forwarding configure sur une boite aux lettres
Get-Mailbox -Identity "victim@contoso.com" |
    Select-Object ForwardingAddress, ForwardingSmtpAddress,
    DeliverToMailboxAndForward

# Verifier le forwarding sur TOUTES les boites aux lettres du tenant
Get-Mailbox -ResultSize Unlimited |
    Where-Object { $_.ForwardingSmtpAddress -ne $null -or
                   $_.ForwardingAddress -ne $null } |
    Select-Object DisplayName, PrimarySmtpAddress,
    ForwardingSmtpAddress, ForwardingAddress,
    DeliverToMailboxAndForward | Export-Csv "C:\Investigation\Forwarding.csv"

# Rechercher les modifications de forwarding dans l'UAL
Search-UnifiedAuditLog -StartDate "2026-01-01" -EndDate "2026-02-15" `
    -Operations "Set-Mailbox" -ResultSize 5000 |
    ForEach-Object {
        $data = $_.AuditData | ConvertFrom-Json
        $fwd = $data.Parameters | Where-Object {
            $_.Name -match "ForwardingSmtpAddress|ForwardingAddress"
        }
        if ($fwd) {
            [PSCustomObject]@{
                Date     = $data.CreationTime
                User     = $data.UserId
                Mailbox  = $data.ObjectId
                Param    = $fwd.Name
                Value    = $fwd.Value
                ClientIP = $data.ClientIP
            }
        }
    }

Analyse des enregistrements d'applications

Les applications enregistrees dans Entra ID constituent un vecteur de persistance avance. Un attaquant avec des droits Global Admin ou Application Administrator peut enregistrer une application avec des permissions Graph API elevees, generer un secret client, et utiliser ces credentials pour maintenir un acces meme apres la remediation du compte initial. Les attaques sur les identity providers comme Entra ID exploitent frequemment ce mecanisme.

# Rechercher les enregistrements d'applications recents
Search-UnifiedAuditLog -StartDate "2026-01-01" -EndDate "2026-02-15" `
    -Operations "Add application","Add service principal",
    "Add app role assignment to service principal",
    "Add service principal credentials" -ResultSize 5000

# Lister les applications avec des secrets recemment crees
Get-MgApplication -All | ForEach-Object {
    $app = $_
    $secrets = $app.PasswordCredentials | Where-Object {
        $_.StartDateTime -gt (Get-Date).AddDays(-90)
    }
    if ($secrets) {
        [PSCustomObject]@{
            AppName   = $app.DisplayName
            AppId     = $app.AppId
            Created   = $secrets.StartDateTime
            Expires   = $secrets.EndDateTime
            KeyId     = $secrets.KeyId
        }
    }
}

Exchange Online Forensics

Message Trace

Le Message Trace est un outil complementaire a l'UAL specifique a Exchange Online. Il fournit des informations detaillees sur le flux des messages : expediteur, destinataire, sujet, statut de livraison, passage par les filtres anti-spam et anti-phishing. La retention standard est de 10 jours pour les donnees en temps reel et de 90 jours pour les rapports historiques.

# Message Trace pour un expediteur
Get-MessageTrace -SenderAddress "victim@contoso.com" `
    -StartDate (Get-Date).AddDays(-10) -EndDate (Get-Date)

# Message Trace pour les messages envoyes a des domaines externes
Get-MessageTrace -SenderAddress "victim@contoso.com" `
    -StartDate (Get-Date).AddDays(-10) -EndDate (Get-Date) |
    Where-Object { $_.RecipientAddress -notmatch "@contoso\.com$" } |
    Select-Object Received, SenderAddress, RecipientAddress, Subject, Status

# Rapport historique (jusqu'a 90 jours)
Start-HistoricalSearch -ReportTitle "Investigation Victim" `
    -StartDate "2026-01-01" -EndDate "2026-02-15" `
    -ReportType MessageTrace -SenderAddress "victim@contoso.com"

MailItemsAccessed : l'evenement forensique critique

L'evenement MailItemsAccessed est l'un des ajouts les plus importants pour la forensique Exchange. Disponible uniquement avec une licence E5/A5 ou le complement Audit (Premium), il enregistre chaque acces a un element de messagerie, que ce soit via un protocole de synchronisation (Sync) ou un acces direct (Bind). Cet evenement est essentiel pour determiner quels emails ont ete effectivement lus par un attaquant apres la compromission d'un compte.

# Rechercher les acces aux emails (E5 requis)
Search-UnifiedAuditLog -StartDate "2026-01-15" -EndDate "2026-02-15" `
    -Operations "MailItemsAccessed" `
    -UserIds "victim@contoso.com" -ResultSize 5000 |
    ForEach-Object {
        $data = $_.AuditData | ConvertFrom-Json
        [PSCustomObject]@{
            Timestamp    = $data.CreationTime
            MailboxOwner = $data.MailboxOwnerUPN
            AccessType   = $data.OperationProperties |
                          Where-Object {$_.Name -eq "MailAccessType"} |
                          Select-Object -ExpandProperty Value
            ClientIP     = $data.ClientIPAddress
            SessionId    = $data.SessionId
            ItemCount    = $data.OperationCount
        }
    } | Where-Object { $_.ClientIP -notmatch "^10\.|^192\.168\." }

Analyse de la quarantaine

La quarantaine Exchange Online Protection (EOP) contient les messages bloques par les filtres anti-phishing, anti-malware et anti-spam. L'examen de la quarantaine pendant la periode de compromission permet d'identifier les emails de phishing initiaux qui ont conduit a la compromission, ainsi que les tentatives de phishing envoyees depuis le compte compromis vers d'autres utilisateurs de l'organisation. L'attaquant utilise souvent des techniques de phishing sans piece jointe pour contourner les filtres de securite.

# Examiner les messages en quarantaine
Get-QuarantineMessage -StartReceivedDate "2026-01-01" `
    -EndReceivedDate "2026-02-15" -Direction Inbound |
    Where-Object { $_.RecipientAddress -match "victim@contoso.com" } |
    Select-Object ReceivedTime, SenderAddress, Subject,
    Type, PolicyName, QuarantineTypes

# Previsualiser un message en quarantaine (sans le liberer)
Get-QuarantineMessageHeader -Identity $messageId

SharePoint, OneDrive et Teams : forensique des donnees

Investigation des acces fichiers SharePoint et OneDrive

SharePoint Online et OneDrive for Business sont des cibles privilegiees pour l'exfiltration de donnees. L'UAL enregistre les operations sur les fichiers : consultation, telechargement, partage, modification des permissions. L'analyse de ces evenements permet de reconstituer la chronologie de l'acces aux donnees et d'identifier les fichiers potentiellement exfiltres.

# Rechercher les telechargements de fichiers
Search-UnifiedAuditLog -StartDate "2026-01-15" -EndDate "2026-02-15" `
    -Operations "FileDownloaded","FileSyncDownloadedFull" `
    -UserIds "victim@contoso.com" -ResultSize 5000 |
    ForEach-Object {
        $data = $_.AuditData | ConvertFrom-Json
        [PSCustomObject]@{
            Timestamp = $data.CreationTime
            FileName  = $data.ObjectId
            SiteUrl   = $data.SiteUrl
            ClientIP  = $data.ClientIP
            UserAgent = $data.UserAgent
        }
    } | Export-Csv "C:\Investigation\FileDownloads.csv" -NoTypeInformation

# Rechercher les partages externes
Search-UnifiedAuditLog -StartDate "2026-01-15" -EndDate "2026-02-15" `
    -Operations "SharingSet","AnonymousLinkCreated","CompanyLinkCreated",
    "SharingInvitationCreated" -UserIds "victim@contoso.com" -ResultSize 5000

# Rechercher les modifications de permissions
Search-UnifiedAuditLog -StartDate "2026-01-15" -EndDate "2026-02-15" `
    -Operations "SiteCollectionAdminAdded","PermissionLevelAdded",
    "MembersAdded" -ResultSize 5000

Forensique Microsoft Teams

Microsoft Teams est de plus en plus utilise comme vecteur d'attaque. Les attaquants envoient des messages de phishing via Teams, partagent des fichiers malveillants dans les canaux, et utilisent les reunions pour des attaques de social engineering. Les logs Teams dans l'UAL couvrent les operations sur les equipes, les canaux, les membres et les fichiers partages.

# Rechercher les activites Teams suspectes
Search-UnifiedAuditLog -StartDate "2026-01-15" -EndDate "2026-02-15" `
    -RecordType MicrosoftTeams -UserIds "victim@contoso.com" -ResultSize 5000

# Rechercher les ajouts de membres externes
Search-UnifiedAuditLog -StartDate "2026-01-15" -EndDate "2026-02-15" `
    -Operations "MemberAdded" -RecordType MicrosoftTeams -ResultSize 5000 |
    ForEach-Object {
        $data = $_.AuditData | ConvertFrom-Json
        [PSCustomObject]@{
            Timestamp = $data.CreationTime
            Team      = $data.TeamName
            AddedUser = $data.Members.UPN
            AddedBy   = $data.UserId
            Role      = $data.Members.Role
        }
    } | Where-Object { $_.AddedUser -notmatch "@contoso\.com$" }

# Activite DLP dans Teams
Search-UnifiedAuditLog -StartDate "2026-01-15" -EndDate "2026-02-15" `
    -Operations "DlpRuleMatch" -RecordType DLP -ResultSize 5000

eDiscovery : collecte de preuves et preservation

Content Search

L'outil Content Search du Microsoft Purview Compliance Center permet de rechercher du contenu dans toutes les boites aux lettres, sites SharePoint et OneDrive du tenant. En contexte forensique, il est utilise pour identifier les donnees auxquelles l'attaquant a potentiellement eu acces, retrouver les emails de phishing initiaux et collecter les preuves pour un eventuel depot de plainte.

# Connexion au module Compliance
Connect-IPPSSession -UserPrincipalName admin@contoso.com

# Creer une recherche de contenu
New-ComplianceSearch -Name "Investigation_Incident_2026-02" `
    -ExchangeLocation "victim@contoso.com" `
    -ContentMatchQuery '(from:attacker@evil.com) OR (subject:"urgent wire transfer")' `
    -Description "Recherche emails phishing incident fev 2026"

# Lancer la recherche
Start-ComplianceSearch -Identity "Investigation_Incident_2026-02"

# Verifier le statut
Get-ComplianceSearch -Identity "Investigation_Incident_2026-02" |
    Select-Object Name, Status, Items, Size

# Previsualiser les resultats
New-ComplianceSearchAction -SearchName "Investigation_Incident_2026-02" `
    -Preview

# Exporter les resultats
New-ComplianceSearchAction -SearchName "Investigation_Incident_2026-02" `
    -Export -Format FxStream -ExchangeArchiveFormat PerUserPst

Legal Hold et preservation des preuves

La mise en preservation legale (Legal Hold) est une etape critique de l'investigation forensique. Elle garantit que les donnees ne seront pas supprimees ou modifiees pendant l'enquete, meme si un utilisateur ou un administrateur tente de les effacer. En contexte M365, deux types de preservation sont disponibles : le Litigation Hold (au niveau de la boite aux lettres) et le eDiscovery Hold (au niveau du cas d'investigation).

# Activer le Litigation Hold sur une boite aux lettres
Set-Mailbox -Identity "victim@contoso.com" -LitigationHoldEnabled $true `
    -LitigationHoldDuration 365

# Creer un cas eDiscovery pour l'investigation
New-ComplianceCase -Name "Incident-BEC-2026-02" `
    -Description "Investigation BEC fevrier 2026"

# Creer un hold dans le cas eDiscovery
New-CaseHoldPolicy -Name "Hold-Victim-Mailbox" `
    -Case "Incident-BEC-2026-02" `
    -ExchangeLocation "victim@contoso.com" `
    -SharePointLocation "https://contoso.sharepoint.com/personal/victim_contoso_com"

New-CaseHoldRule -Name "Hold-All-Content" `
    -Policy "Hold-Victim-Mailbox" `
    -ContentMatchQuery "" # Vide = tout preserver

Outils specialises pour la forensique M365

HAWK : investigation automatisee

HAWK est un module PowerShell open source developpe par la communaute DFIR, specifiquement concu pour l'investigation de compromission dans Microsoft 365. Il automatise la collecte de nombreux artefacts : sign-in logs, inbox rules, forwarding, delegations, consentements OAuth, et genere un rapport structure.

# Installation de HAWK
Install-Module -Name HAWK -Force

# Initialiser HAWK (definit la periode et le dossier de sortie)
Initialize-HawkGlobalObject -DaysToLookBack 90 `
    -FilePath "C:\Investigation\HAWK"

# Investigation complete d'un utilisateur
Start-HawkUserInvestigation -UserPrincipalName "victim@contoso.com"

# Investigation du tenant complet
Start-HawkTenantInvestigation

# Les resultats sont exportes dans des fichiers CSV structures :
# - Mailbox_Forwarding.csv
# - Inbox_Rules.csv
# - Authentication_Logs.csv
# - Admin_Changes.csv
# - OAuth_Consent.csv

Sparrow : outil CISA pour la detection de compromission

Sparrow a ete developpe par la CISA (Cybersecurity and Infrastructure Security Agency) des Etats-Unis en reponse aux compromissions liees a l'attaque SolarWinds. Il se concentre sur la detection de techniques specifiques utilisees par les acteurs APT dans les environnements Azure AD et M365, notamment l'abus de federation SAML, les modifications de domaines et les consentements OAuth suspects.

# Installation de Sparrow
Install-Module -Name Sparrow -Force

# Execution de l'analyse
Invoke-Sparrow -Output "C:\Investigation\Sparrow"

# Sparrow verifie automatiquement :
# - Modifications des domaines federes
# - Ajouts de credentials sur les service principals
# - Consentements OAuth suspects
# - Modifications des politiques d'acces conditionnel
# - Ajouts de delegations sur les boites aux lettres

CrowdStrike CRT : Cloud Response Toolkit

Le CrowdStrike Reporting Tool for Azure (CRT) est un outil gratuit qui collecte et analyse les configurations Azure AD et M365 susceptibles d'indiquer une compromission. Il verifie les applications, les service principals, les delegations, les permissions et les configurations de federation.

# Cloner le repository CRT
git clone https://github.com/CrowdStrike/CRT.git

# Executer CRT
cd CRT
.\Get-CRTReport.ps1

# CRT genere un rapport couvrant :
# - Applications avec permissions Graph API elevees
# - Service principals avec credentials multiples
# - Delegations de boites aux lettres suspectes
# - Federation configurations modifiees
# - Politiques d'acces conditionnel faibles

Methodologie d'investigation M365

Une investigation forensique M365 efficace suit une methodologie structuree en sept phases. Cette approche garantit une couverture complete et une documentation rigoureuse de chaque etape. La collecte d'informations sur les infostealers et les campagnes de phishing en cours peut egalement orienter l'investigation.

Phase 1 : Triage et scope

Definir le perimetre de l'investigation : quels comptes sont suspectes d'etre compromis, quelle est la fenetre temporelle, quelles licences sont disponibles (E3 vs E5, Audit Premium). Verifier immediatement le statut de l'UAL et la retention configuree. Identifier les sources de logs disponibles (UAL natif, SIEM, logs Entra ID).

Phase 2 : Preservation

Activer le Legal Hold sur les boites aux lettres concernees. Exporter les logs UAL pour la periode d'investigation. Documenter l'etat initial du tenant (regles, forwarding, delegations). Ne pas encore remedier : toute modification prematuree pourrait detruire des artefacts.

Phase 3 : Analyse d'authentification

Analyser les sign-in logs Entra ID pour identifier les connexions suspectes. Cartographier les adresses IP, les localisations geographiques, les user agents et les applications clientes utilisees. Identifier le point d'entree initial : phishing, brute force, token theft ou autre vecteur.

Phase 4 : Analyse des actions post-compromission

Examiner les regles de boite aux lettres, le forwarding SMTP, les consentements OAuth, les applications enregistrees, les modifications de role et les delegations. Rechercher les indicateurs de persistance et de mouvement lateral. Verifier si d'autres comptes ont ete compromis a partir du compte initial.

Phase 5 : Evaluation de l'impact sur les donnees

Quantifier l'acces aux donnees : emails lus (MailItemsAccessed), fichiers telecharges (FileDownloaded), partages crees (SharingSet), donnees DLP detectees. Evaluer si des donnees sensibles, personnelles ou reglementees ont ete exposees. Cette evaluation determine les obligations de notification (RGPD, NIS2).

Phase 6 : Remediation

Apres la preservation et l'analyse, proceder a la remediation : reset des mots de passe, revocation des sessions et tokens de rafraichissement, suppression des regles malveillantes, revocation des consentements OAuth, suppression des applications frauduleuses, desactivation du forwarding, et verification des politiques d'acces conditionnel.

Phase 7 : Rapport et recommandations

Documenter l'ensemble de l'investigation : timeline de l'incident, indicateurs de compromission (IOCs), comptes impactes, donnees exposees, actions de remediation effectuees. Formuler des recommandations pour prevenir de futurs incidents : activation du MFA resistant au phishing (FIDO2), politiques d'acces conditionnel renforcees, restriction des consentements OAuth, monitoring continu.

Conclusion

La forensique Microsoft 365 est une competence devenue indispensable pour toute equipe de reponse a incident. La centralisation des services de collaboration dans le cloud M365 offre aux attaquants une surface d'attaque considerable, mais fournit egalement aux defenseurs des sources de logs riches et detaillees. Le Unified Audit Log, les sign-in logs Entra ID, le message trace Exchange et les outils eDiscovery constituent un arsenal complet pour mener des investigations approfondies.

La cle d'une investigation reussie reside dans la preparation en amont : activation de l'audit, configuration de la retention adequate, export continu vers un SIEM, et documentation des procedures d'investigation. Les outils comme HAWK, Sparrow et CRT automatisent une grande partie de la collecte, mais l'expertise de l'analyste reste essentielle pour interpreter les resultats, etablir les correlations et reconstruire la chronologie de l'incident.

Enfin, chaque investigation doit se conclure par des recommandations actionables : activation du MFA resistant au phishing (cles FIDO2, Windows Hello for Business), renforcement des politiques d'acces conditionnel, restriction des consentements OAuth aux applications approuvees, et mise en place d'un monitoring continu des indicateurs de compromission. La forensique n'est pas seulement reactive : elle alimente le cycle d'amelioration continue de la securite du tenant M365.