Forensique Microsoft 365 : Analyse du Unified Audit Log

L'investigation forensique Microsoft 365 impose des contraintes très différentes de celles de la forensique traditionnelle sur endpoint. L'analyste ne dispose ni du système de fichiers, ni de la mémoire vive, ni des artefacts système classiques : aucune image disque, aucun dump mémoire à exploiter. L'ensemble de la démarche forensique Microsoft 365 Unified Audit repose donc sur les journaux d'audit produits par la plateforme, dont la complétude, la granularité, la durée de rétention et l'accessibilité varient selon le niveau de licence souscrit (E3, E5 ou modules complémentaires). Un événement non journalisé est un événement définitivement perdu, sans possibilité de reconstruction a posteriori. Maîtriser ces limites structurelles conditionne la qualité de l'investigation : elles déterminent la fenêtre temporelle exploitable, les hypothèses vérifiables et, in fine, la solidité des conclusions présentées dans le rapport d'incident.

Vos journaux d'événements sont-ils conservés suffisamment longtemps pour une investigation ?

# 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

# 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 différent 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, générer 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 mécanisme.

# 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
 }
 }
}

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.

Pour approfondir ce sujet, consultez notre outil open-source incident-response-toolkit qui facilite la réponse automatisée aux incidents de sécurité.

Recommandations post-investigation

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 sécurité du tenant M365.

Incident en cours ? Réponse d'urgence

Investigation numérique, forensics, réponse à incident — intervention rapide, rapport exploitable.

Contacter un expert forensics ayi@ayinedjimi-consultants.fr

Questions frequentes

Sources et références : SANS SIFT · MITRE ATT&CK

Conclusion

La forensique Microsoft 365 est une competence devenue indispensable pour toute équipe de réponse a incident. La centralisation des services de collaboration dans le cloud M365 offre aux attaquants une surface d'attaque considerable, mais fournit également 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.