Un utilisateur appelle le support.

Il explique qu’un client a reçu un email étrange depuis sa boîte.

Vous vérifiez.

Une connexion inhabituelle apparaît.

Le mot de passe est changé.

Le MFA est activé.

Et quelqu’un dit :

« C’est bon, le compte est sécurisé. »

Pas forcément.

C’est probablement l’une des erreurs les plus fréquentes après une compromission Microsoft 365.

Changer le mot de passe coupe une partie du problème. Mais un attaquant peut avoir déjà créé d’autres moyens de revenir ou d’exploiter le compte : session encore valide, méthode MFA ajoutée, application OAuth autorisée, redirection de messagerie, règle Inbox cachée ou accès à des données qui doit encore être évalué.

Microsoft recommande justement, après une compromission, de ne pas s’arrêter au mot de passe : il faut révoquer les sessions, vérifier les méthodes MFA, les applications consenties, les rôles, les transferts de courrier et les journaux. Microsoft Learn

1. Commencez par contenir, pas par enquêter pendant une heure

Si la compromission est confirmée, le compte doit d’abord être empêché de continuer à agir.

Microsoft recommande de désactiver temporairement le compte pendant l’investigation lorsque cela est possible. Si ce n’est pas possible, la réinitialisation du mot de passe devient la mesure minimale immédiate. Microsoft Learn

Dans Microsoft Graph, par exemple :

Connect-MgGraph -Scopes "User.ReadWrite.All"

$user = Get-MgUser `
-Search UserPrincipalName:'user@entreprise.fr' `
-ConsistencyLevel Eventual

Update-MgUser -UserId $user.Id -AccountEnabled $false

Le but n’est pas de punir l’utilisateur.

Le but est de figer la situation.

Plus un compte reste utilisable pendant l’investigation, plus vous risquez de découvrir que l’attaquant a continué à lire, envoyer, modifier ou autoriser des accès pendant que vous regardiez les logs.

2. Révoquez réellement les sessions actives

Un changement de mot de passe ne doit pas être confondu avec une révocation complète des sessions.

Microsoft fournit une action dédiée pour invalider les sessions actives et les refresh tokens associés au compte. Microsoft Learn

Connect-MgGraph -Scopes User.RevokeSessions.All

Revoke-MgUserSignInSession -UserId user@entreprise.fr

Cette action force les applications et sessions concernées à se réauthentifier.

C’est particulièrement important lorsqu’un attaquant possède déjà un token de session.

La bonne question n’est donc pas :

« Avons-nous changé le mot de passe ? »

Mais :

« Avons-nous invalidé les sessions déjà établies ? »

3. Vérifiez les méthodes MFA avant de faire confiance au MFA

Voir « MFA activé » dans le portail n’est pas suffisant.

Un attaquant qui a eu accès au compte peut avoir essayé d’ajouter sa propre méthode d’authentification.

Microsoft recommande, après compromission, de vérifier les appareils et méthodes MFA enregistrés et de supprimer tout élément non reconnu. Microsoft Learn

Dans Entra Admin Center :

Entra ID → Users → utilisateur → Authentication methods

Il faut contrôler les numéros de téléphone, applications Authenticator, passkeys, clés de sécurité et autres méthodes disponibles.

Si vous n’avez aucune certitude sur les méthodes existantes, la voie la plus propre peut être de demander une réinscription MFA complète.

Microsoft indique que l’option Require re-register MFA supprime plusieurs méthodes enregistrées et oblige l’utilisateur à les configurer à nouveau. Microsoft Learn

C’est une différence importante :

avoir du MFA n’est pas la même chose que faire confiance aux méthodes MFA actuellement enregistrées.

4. Analysez les connexions Entra ID

Maintenant seulement, commence l’investigation.

Les logs de connexion Microsoft Entra permettent notamment d’examiner :

qui s’est connecté,

avec quelle application,

vers quelle ressource,

depuis quelle IP,

à quel moment,

et avec quel résultat.

Microsoft décrit cette lecture comme le triptyque Who / How / What : identité, client utilisé et ressource ciblée. Microsoft Learn

Ne cherchez pas seulement « un pays bizarre ».

Regardez la chronologie.

Par exemple :

08:14 — connexion habituelle depuis Toulouse.

08:37 — connexion depuis une nouvelle IP.

08:41 — consentement d’application.

08:45 — modification d’une règle Inbox.

09:02 — envoi de plusieurs messages externes.

Pris séparément, chaque événement peut sembler peu impressionnant.

Ensemble, ils racontent l’incident.

Et c’est cette chronologie qui doit guider le reste de l’analyse.

5. Vérifiez les règles Inbox, y compris les règles cachées

C’est un classique.

Un attaquant compromet une boîte et crée une règle qui :

redirige certains messages,

supprime les réponses,

déplace les alertes dans un dossier discret,

ou transmet les conversations vers une adresse externe.

Microsoft recommande explicitement de vérifier les règles de boîte de réception, y compris les règles cachées. Microsoft Learn

Après connexion à Exchange Online :

Get-InboxRule `
-Mailbox user@entreprise.fr `
-IncludeHidden |
Format-List Name,Enabled,RedirectTo,Forward*,Identity

Une règle doit attirer votre attention si elle contient :

une adresse externe inconnue,

un RedirectTo,

un ForwardTo,

un ForwardAsAttachmentTo,

ou une logique étrange autour de mots comme invoice, payment, bank, security ou Microsoft.

Mais ne supprimez pas aveuglément.

Une entreprise peut avoir des règles légitimes.

L’objectif est de comprendre qui a créé quoi et quand.

Microsoft documente également les opérations d’audit New-InboxRule, Set-InboxRule et Remove-InboxRule. Microsoft Learn

Exemple :

Search-UnifiedAuditLog `
-StartDate "2026-09-20" `
-EndDate "2026-09-23" `
-UserIds user@entreprise.fr `
-Operations New-InboxRule,Set-InboxRule,Remove-InboxRule

C’est beaucoup plus utile que de simplement regarder l’état actuel.

Parce qu’un attaquant peut aussi avoir supprimé sa règle avant votre investigation.

6. Vérifiez le transfert global de la boîte

Les règles Inbox ne sont pas le seul moyen de transférer des emails.

Une boîte Exchange Online peut aussi avoir un transfert configuré directement au niveau de la mailbox.

Microsoft recommande la vérification suivante : Microsoft Learn

Get-Mailbox -Identity user@entreprise.fr |
Format-List Forwarding*Address,DeliverTo*

Vous devez notamment regarder :

ForwardingAddress

ForwardingSmtpAddress

DeliverToMailboxAndForward

Une adresse externe inconnue dans ForwardingSmtpAddress doit immédiatement être expliquée.

C’est un mécanisme particulièrement dangereux, car la victime peut continuer à recevoir ses emails normalement pendant qu’une copie est également envoyée ailleurs.

Il n’y a alors aucun symptôme évident côté utilisateur.

7. Vérifiez les applications OAuth consenties

C’est le point que beaucoup d’équipes oublient.

Un attaquant n’a pas toujours besoin de conserver le mot de passe.

Il peut convaincre l’utilisateur d’autoriser une application OAuth.

Microsoft explique qu’un consentement malveillant peut permettre à une application d’accéder, selon les permissions accordées, aux emails, fichiers, contacts et autres ressources au nom de l’utilisateur. Ces permissions peuvent devenir un mécanisme de persistance. Microsoft Learn

Il faut donc vérifier les applications associées au compte et les consentements accordés.

Dans Entra, examinez les applications de l’utilisateur et cherchez :

une application inconnue,

un nom ressemblant à Microsoft mais qui n’est pas Microsoft,

des permissions excessives,

un consentement accordé au moment de l’incident.

Microsoft recommande de supprimer ou révoquer les applications non autorisées après une compromission. Microsoft Learn

C’est également la raison pour laquelle :

changer le mot de passe sans vérifier OAuth peut laisser le problème actif.

8. Vérifiez les rôles et privilèges

Si l’utilisateur compromis est administrateur, l’incident change immédiatement de niveau.

Microsoft recommande de vérifier les rôles administratifs attribués au compte et de supprimer toute attribution anormale. Microsoft Learn

Mais il faut aller plus loin dans le raisonnement.

Si un compte privilégié a été compromis, il ne faut plus analyser uniquement ce compte.

Il faut se demander :

qu’a-t-il créé ?

qu’a-t-il modifié ?

quels autres comptes a-t-il touchés ?

quelles applications a-t-il autorisées ?

quelles politiques a-t-il changées ?

Une compromission d’utilisateur standard et une compromission de Global Administrator ne sont pas le même incident.

Le périmètre de recherche doit suivre le niveau de privilège réellement disponible pendant la période de compromission.

9. Cherchez ce que l’attaquant a réellement fait

À ce stade, sécuriser le compte ne suffit toujours pas.

Il faut savoir ce qui s’est passé.

Microsoft recommande d’examiner les logs Entra, les journaux d’audit et les messages envoyés pendant la période suspecte. Microsoft Learn

C’est là que l’investigation devient intéressante.

Un compte compromis peut avoir été utilisé pour :

envoyer du phishing interne,

envoyer du phishing aux clients,

chercher des factures,

chercher des IBAN,

lire les échanges avec la direction,

accéder à SharePoint ou OneDrive,

modifier des règles,

accorder un consentement OAuth.

La question n’est donc plus seulement :

« Comment l’attaquant est-il entré ? »

Mais :

« Jusqu’où est-il allé ? »

Sans cette réponse, vous ne connaissez pas réellement l’impact.

10. Ne clôturez l’incident qu’après validation

Un incident Microsoft 365 ne doit pas être fermé parce que :

le mot de passe a été changé,

le téléphone de l’utilisateur fonctionne à nouveau,

et aucun nouvel email frauduleux n’est visible.

Avant de considérer la remédiation terminée, nous voulons au minimum pouvoir répondre clairement aux points suivants :

• sessions révoquées ;
• mot de passe réinitialisé proprement ;
• méthodes MFA vérifiées ou réenregistrées ;
• connexions suspectes identifiées ;
• règles Inbox contrôlées ;
• forwarding Exchange contrôlé ;
• consentements OAuth contrôlés ;
• rôles vérifiés ;
• actions de l’attaquant recherchées ;
• période et impact de compromission documentés.

Microsoft recommande précisément une investigation allant des sessions et MFA jusqu’aux redirecteurs, applications, rôles et journaux avant de considérer le traitement terminé. Microsoft Learn

Ce que nous cherchons réellement pendant un incident

Le but n’est pas de lancer dix commandes pour pouvoir dire qu’une checklist est terminée.

Le but est de reconstruire une histoire.

À quelle heure l’accès initial a-t-il eu lieu ?

Quel moyen d’authentification a été utilisé ?

Quelle session a été créée ?

Qu’est-ce que cette identité pouvait voir ?

Qu’est-ce qui a changé après la connexion ?

Qu’est-ce qui est sorti de l’environnement ?

Quelle persistance éventuelle a été installée ?

Et à quel moment avons-nous réellement repris le contrôle ?

C’est cette chronologie qui transforme une simple remise à zéro de mot de passe en véritable réponse à incident.

Le piège : corriger avant de préserver les traces

Il faut aussi éviter une erreur opérationnelle classique.

Dans l’urgence, les équipes veulent immédiatement nettoyer.

Supprimer la règle.

Supprimer l’application.

Désactiver l’utilisateur.

Réinitialiser les méthodes.

C’est parfois indispensable pour contenir l’incident.

Mais lorsque la situation le permet, il faut conserver suffisamment d’éléments pour comprendre ce qui s’est produit.

Microsoft recommande justement d’examiner les journaux sur une période commençant avant l’activité suspecte et d’éviter de trop filtrer la recherche initiale. Microsoft Learn

Autrement dit :

contenez vite, mais ne rendez pas l’investigation impossible.

Ce que Cyberhack surveille dans ce type de scénario

Dans une approche SOC, ce type d’incident ne devrait pas dépendre uniquement du moment où un utilisateur appelle le support.

Nous cherchons à corréler plusieurs signaux :

connexion inhabituelle,

nouvelle méthode MFA,

modification de règle Inbox,

transfert externe,

consentement OAuth,

élévation de privilège,

comportement anormal de messagerie.

Un événement isolé produit parfois beaucoup de bruit.

Plusieurs événements cohérents racontent une attaque.

C’est précisément la différence entre collecter des logs et détecter un incident.

Conclusion

Quand un compte Microsoft 365 est compromis, le mot de passe est seulement une partie de l’histoire.

Un attaquant peut déjà disposer d’une session.

Il peut avoir ajouté une méthode MFA.

Il peut avoir créé une règle de messagerie.

Il peut avoir configuré un transfert.

Il peut avoir obtenu un consentement OAuth.

Et il peut avoir accédé à beaucoup plus de données que ce que l’utilisateur voit dans Outlook.

La bonne question n’est donc pas :

« Avons-nous récupéré le compte ? »

La vraie question est :

« Sommes-nous certains d’avoir supprimé tous les accès de l’attaquant et compris ce qu’il a fait avant de perdre cet accès ? »

C’est seulement à ce moment-là que l’incident commence réellement à être terminé.