SOC managé - surveillance continue  ·  veille cyber : CERT-FR / CISA / NVD  ·  réponse à incident : dispositif sous contrat
Toutes les publications terrain

Dépannage · Guide pratique

Microsoft 365 : les vérifications après une compromission de compte

Validation Rejeu confirmé par Kenawek le 10 octobre 2026.Versions testées Non précisées dans cette publication.À revoir Lors de toute évolution des versions, des outils ou du périmètre.

Une alerte sur un compte ne décrit pas tout ce qui a été fait avec ses accès. Cette procédure documentaire aide à organiser les vérifications et à consulter les redirections Exchange Online. Elle doit être adaptée puis rejouée sur un tenant de test avant un usage opérationnel.

En résumé

  • Le rejeu de la procédure a été confirmé par Kenawek ; son application reste à adapter au tenant concerné.
  • Le confinement du compte et la collecte des éléments doivent suivre une procédure autorisée.
  • Changer le mot de passe ne couvre pas à lui seul toutes les sessions ni toutes les formes de persistance.
  • Les commandes proposées consultent les redirections et les règles de messagerie sans les modifier.
  • Les licences, les droits et la conservation des journaux limitent les observations disponibles.

1. Préparer le contexte et les autorisations

Ce guide s’adresse aux administrateurs autorisés d’un tenant Microsoft 365 avec Exchange Online. Il faut disposer des rôles adaptés, du module ExchangeOnlineManagement compatible avec votre environnement et d’un canal de coordination sécurisé.

Consignez le tenant, le compte concerné, la période et le fuseau horaire. Identifiez l’administrateur qui autorise les mesures de confinement. Les exports peuvent contenir des informations sensibles : leur emplacement, leurs destinataires et leur conservation doivent être définis.

2. Séparer confinement et collecte

La procédure Microsoft pour un compte compromis recommande notamment la désactivation du compte pendant l’investigation, la révocation des sessions et la revue des méthodes MFA et des consentements applicatifs. Ces opérations affectent l’accès de l’utilisateur ; elles doivent suivre votre procédure d’incident.

La révocation n’a pas toujours un effet immédiat sur toutes les sessions. Microsoft détaille les limites liées aux jetons et aux applications dans son guide de révocation d’accès. Documentez l’heure des actions et vérifiez leur effet. Ne réactivez pas un compte uniquement parce que son mot de passe a été changé.

3. Examiner les redirections de messagerie

Les commandes ci-dessous consultent la configuration ; elles ne désactivent pas de règle et ne changent aucun compte. Remplacez l’adresse de test par celle du compte autorisé. La connexion doit être réalisée avec un rôle permettant la lecture des objets concernés.

PowerShell - consultation Exchange Online

Connect-ExchangeOnline
$incidentMailbox = "compte-test@example.com"
Get-Mailbox -Identity $incidentMailbox |
  Format-List DisplayName,PrimarySmtpAddress,ForwardingAddress,ForwardingSmtpAddress,DeliverToMailboxAndForward
Get-InboxRule -Mailbox $incidentMailbox -IncludeHidden |
  Format-List Name,Enabled,Priority,Description,ForwardTo,RedirectTo,ForwardAsAttachmentTo,DeleteMessage
Disconnect-ExchangeOnline -Confirm:$false

Résultat attendu : les propriétés de redirection de la boîte et les règles accessibles sont affichées. L’option -IncludeHidden inclut les règles cachées. Une sortie vide, une erreur de permission ou un nom non reconnu doit être interprété ; aucun de ces cas ne prouve, à lui seul, l’absence de persistance.

Comparez les destinations et les règles au fonctionnement attendu avec le propriétaire de la boîte. Conservez les éléments utiles avant une suppression autorisée. Une règle légitime peut ressembler à une règle suspecte : le contexte et la chronologie comptent.

4. Reconstituer les actions et leurs limites

Examinez les connexions et les activités d’audit disponibles sur la période : comptes, applications, adresses réseau et changements de configuration. Une localisation inhabituelle est un indice à qualifier, pas une preuve suffisante. Corrélez les observations avec les messages et accès concernés.

La profondeur d’historique dépend notamment des licences, des politiques et du moment où la collecte était active. Consultez les règles Microsoft de conservation des journaux applicables à votre tenant. Notez explicitement les périodes absentes et les sources indisponibles.

5. Vérifier la reprise et prévoir le retour arrière

Après traitement et décision de reprise, vérifiez le parcours de connexion autorisé, les méthodes d’authentification, les applications consenties et l’absence des redirections non autorisées. Contrôlez l’envoi et la réception avec des destinataires de test. Poursuivez la surveillance sur la période convenue.

Les commandes de consultation ne nécessitent pas de retour arrière de configuration ; la déconnexion ferme la session d’administration. Pour toute mesure de confinement réalisée séparément, consignez l’état initial et le responsable de la remise en service. Une réactivation n’annule pas les conséquences d’une divulgation de données.

Recette et suivi des validations

  • Exécuter le guide sur un tenant de test et consigner licences, rôles et version du module.
  • Créer des règles légitimes de démonstration et vérifier leur présence dans les sorties attendues.
  • Vérifier le comportement en cas de permissions insuffisantes et de compte absent.
  • Rejouer le parcours de confinement et de reprise selon la procédure autorisée.
  • Conserver les résultats et revoir la procédure lorsque les versions ou les services évoluent.

Sources et références

Passer de la lecture à l’action

Cadrer votre besoin avec Kenawek.