Objectif
Confinement et remise en service contrôlée d’un compte Microsoft 365 suspecté compromis, tout en préservant les éléments utiles à l’investigation. La procédure coupe l’accès de l’attaquant, révoque les sessions, restaure des facteurs d’authentification fiables, recherche les mécanismes de persistance dans Exchange et les applications, puis surveille le compte avant réactivation.
Prérequis
- Un second compte administrateur sain capable d’effectuer les actions.
- Accès aux sign-in logs Entra et journaux/audits Exchange selon les licences disponibles.
- Canal alternatif pour vérifier l’identité de l’utilisateur.
- Poste d’administration de confiance pour le reset du secret.
- Processus d’incident permettant de conserver les preuves et d’escalader si un impact plus large est découvert.
Procédure pas à pas
Qualifier le signal et conserver la chronologie
Relevez l’alerte initiale : connexion impossible, MFA inattendu, envois de spam, règles inconnues, consentement OAuth ou connexion depuis un pays inhabituel. Exportez ou capturez les sign-in logs autour de l’événement et notez les adresses IP, applications, méthodes d’authentification et Conditional Access. Distinguez un simple échec de connexion d’un succès réellement suspect.
- L’heure de début, le compte, les événements suspects et leur niveau de certitude sont documentés.
Bloquer immédiatement les nouvelles connexions
Si la compromission est plausible, bloquez le compte avant de poursuivre l’analyse détaillée. Via Graph, définissez AccountEnabled=false. Pour un compte synchronisé, appliquez également la mesure à la source d’autorité. L’objectif est d’empêcher l’attaquant d’obtenir de nouveaux tokens pendant que vous révoquez l’existant.
Connect-MgGraph -Scopes "User.ReadWrite.All"$params = @{ accountEnabled = $false }
Update-MgUser -UserId "<UPN>" -BodyParameter $params- Le compte est bloqué dans Entra.
Révoquer toutes les sessions actives
Utilisez Revoke-MgUserSignInSession pour invalider les refresh tokens et cookies de session du compte. Microsoft recommande cette action dans sa réponse aux comptes de messagerie compromis. Elle force les applications à demander une nouvelle authentification, qui échouera tant que le compte reste bloqué.
Connect-MgGraph -Scopes "User.RevokeSessions.All"Revoke-MgUserSignInSession -UserId "<UPN>"- Les sessions existantes ne doivent plus permettre un accès durable.
Réinitialiser le mot de passe depuis un poste sûr
Après confinement, attribuez un secret fort et unique depuis une machine de confiance. Si l’identité est synchronisée depuis AD
- Le nouveau secret n’est connu que par l’utilisateur vérifié et les canaux administratifs prévus.
Examiner et nettoyer les méthodes MFA
Ouvrez les Authentication methods de l’utilisateur et comparez téléphone, Authenticator, clés FIDO2/passkeys et autres méthodes aux informations validées avec lui. Supprimez toute méthode inconnue. Ne réenregistrez pas simplement MFA sans vérifier qu’un facteur ajouté par l’attaquant n’est pas resté présent.
- Chaque méthode d’authentification restante a été confirmée légitime.
Rechercher les règles Inbox et forwarding
Les comptes compromis créent souvent une règle qui supprime, masque ou transfère certains messages. Dans Exchange Online PowerShell, listez les règles Inbox et les paramètres de forwarding de la mailbox. Supprimez uniquement les règles identifiées comme malveillantes et conservez une trace de leur contenu dans le rapport d’incident.
Get-InboxRule -Mailbox "<UPN>" | Format-Table Name,Enabled,Priority,ForwardTo,RedirectTo,DeleteMessageGet-Mailbox -Identity "<UPN>" | Select ForwardingAddress,ForwardingSmtpAddress,DeliverToMailboxAndForwardRemove-InboxRule -Mailbox "<UPN>" -Identity "<RULE-NAME>" -Confirm:$false- Aucune règle ou redirection inconnue ne persiste dans la mailbox.
Examiner les applications consenties et accès persistants
Vérifiez les applications auxquelles l’utilisateur a donné un consentement et les enterprise applications impliquées dans les sign-in logs. Révoquez les consentements non reconnus conformément aux procédures Entra. Un mot de passe neuf n’annule pas nécessairement toutes les autorisations d’une application malveillante ; traitez ce vecteur comme une persistance distincte.
- Aucune application consentie suspecte ne conserve d’accès au compte ou aux données.
Rechercher l’impact messagerie et les envois frauduleux
Utilisez Message Trace et l’audit pour identifier les messages envoyés pendant la fenêtre de compromission, les destinataires et les éventuels changements. Si des messages de phishing sont partis du compte, déclenchez la procédure de communication et de purge adaptée à votre tenant. Vérifiez également les éléments supprimés et les brouillons inhabituels.
- L’étendue des messages frauduleux et des destinataires touchés est connue.
Vérifier les rôles, groupes et modifications de tenant
Pour un utilisateur privilégié ou un compte ayant accès à des applications sensibles, examinez les changements de rôles, groupes, Conditional Access, applications, secrets et méthodes d’authentification effectués pendant la période. Une compromission d’administrateur ne se limite pas à la mailbox et doit être escaladée comme incident de tenant.
- Aucun changement de privilège ou de configuration critique non autorisé n’est laissé en place.
Réactiver seulement après assainissement et surveiller
Une fois secret, MFA, règles, consentements et impact vérifiés, réactivez le compte. Forcez l’utilisateur à se reconnecter sur un poste de confiance et surveillez les sign-in logs, l’envoi de mails et les alertes pendant les jours suivants. Si un nouveau succès suspect apparaît, rebloquez le compte et élargissez l’analyse au terminal utilisateur.
$params = @{ accountEnabled = $true }
Update-MgUser -UserId "<UPN>" -BodyParameter $paramsGet-MgUser -UserId "<UPN>" -Property AccountEnabled | Select AccountEnabled- Le compte est réactivé uniquement après validation et aucune nouvelle activité suspecte n’est observée.
Validation
La procédure est validée lorsque :
- Le compte a été bloqué et les sessions actives révoquées pendant le confinement.
- Le mot de passe et toutes les méthodes MFA ont été assainis.
- Les règles Inbox, forwarding et applications consenties ont été vérifiés.
- L’impact des messages et modifications de tenant a été évalué.
- La réactivation est suivie par une période de surveillance renforcée.
Retour arrière
- Si un nouveau signal suspect apparaît après réactivation, rebloquer immédiatement le compte et révoquer de nouveau les sessions.
- Ne restaurez jamais une méthode MFA ou une application simplement parce que l’utilisateur la reconnaît vaguement ; validez son origine et sa nécessité.
- Si la cause est un poste compromis, maintenir le compte bloqué jusqu’à assainissement ou remplacement du terminal.
- Pour un administrateur compromis, activer le plan de récupération du tenant et utiliser des comptes d’urgence sains plutôt qu’un rollback limité au mot de passe.
Dépannage / erreurs fréquentes
- Spam continue après reset : vérifier sessions, règles Inbox, forwarding, applications consenties et terminaux compromis.
- Utilisateur ne peut plus se connecter après nettoyage MFA : utiliser le processus de réenregistrement des méthodes depuis une identité vérifiée.
- Une règle Inbox réapparaît : rechercher un accès actif, une application ou un client compromis qui la recrée.
- Connexions depuis IP inconnues mais Conditional Access Success : vérifier si l’adresse appartient à un proxy/VPN légitime avant conclusion.
- Compte admin compromis : élargir immédiatement aux audit logs, rôles, apps et secrets au lieu de traiter l’incident comme une simple mailbox.