Compte Microsoft 365 compromis : guide de première intervention

Un compte compromis est un incident, pas seulement un mot de passe à changer

Un attaquant peut conserver plusieurs chemins d'accès après avoir obtenu un mot de passe : jetons déjà émis, méthode MFA ajoutée, règle de boîte cachée, transfert externe, consentement OAuth ou session dans une application tierce. La réponse doit donc contenir l'accès, préserver les preuves, retirer la persistance et valider la récupération.

Ce guide décrit une première intervention structurée. Il ne remplace pas une investigation forensique complète, surtout si le compte est privilégié, si des données sensibles ont pu être consultées, si plusieurs identités sont touchées ou si l'origine reste inconnue.

• Microsoft — Répondre à un compte de messagerie compromis ↗

Les 15 premières minutes : contenir sans détruire les preuves

La collecte ne doit pas retarder un confinement urgent. Prenez une capture minimale et horodatée, puis bloquez l'accès. Conservez les exports dans un emplacement protégé avec contrôle d'accès, hachage ou traçabilité appropriée à votre processus d'incident.

• Ouvrir un incident, travailler en UTC et consigner heure, déclencheur, utilisateur, administrateur et chaque action.
• Capturer les alertes Defender XDR, les connexions Entra récentes, les méthodes d'authentification, les appareils, les rôles et les applications visibles.
• Bloquer les nouvelles connexions du compte. Pour une identité hybride, désactiver aussi la source d'autorité locale et accélérer la synchronisation lorsque le processus le permet.
• Révoquer les sessions et jetons actualisables, puis comprendre que certains jetons d'accès ou cookies applicatifs peuvent demeurer valides jusqu'à leur expiration.
• Isoler l'appareil suspect avec l'équipe poste de travail ou Defender for Endpoint; ne pas laisser l'utilisateur reprendre immédiatement sur un appareil possiblement compromis.
• Si le compte est privilégié, vérifier les changements de rôles, politiques, applications, domaines, connecteurs et transport avant de restaurer l'accès.

1. Bloquer les connexions et révoquer les sessions

Dans Microsoft Entra, désactivez le compte pour empêcher l'obtention de nouveaux jetons, puis utilisez Revoke sessions. La révocation invalide les jetons d'actualisation et demande une nouvelle authentification, mais elle n'efface pas instantanément tous les jetons d'accès déjà délivrés. Une application avec son propre cookie de session ou un compte local distinct peut aussi continuer jusqu'à expiration ou désapprovisionnement.

Conditional Access protège la prochaine évaluation de connexion; il ne constitue pas à lui seul un bouton de déconnexion universel. Pour les applications SaaS fédérées ou provisionnées, retirez également l'affectation, désactivez le compte dans l'application ou utilisez son mécanisme de révocation lorsqu'il existe.

$Upn = 'utilisateur@contoso.com'
Connect-MgGraph -Scopes 'User.ReadWrite.All','UserAuthenticationMethod.Read.All' -NoWelcome

$user = Get-MgUser -UserId $Upn -Property Id,DisplayName,UserPrincipalName,AccountEnabled
$user | Select-Object Id,DisplayName,UserPrincipalName,AccountEnabled

# Action de confinement : bloque les nouvelles connexions
Update-MgUser -UserId $user.Id -AccountEnabled:$false

# Invalide les jetons d'actualisation et sessions révoquables
Revoke-MgUserSignInSession -UserId $user.Id

• Microsoft — Révoquer les accès utilisateur en urgence ↗

2. Sécuriser le secret et les méthodes d'authentification

Réinitialisez le mot de passe vers une valeur aléatoire selon un canal administratif approuvé, sans le transmettre dans le billet ou par courriel. En environnement hybride, effectuez la réinitialisation à la source appropriée. Ne remettez un secret temporaire à l'utilisateur qu'après validation de son identité et depuis un appareil sain.

Inventoriez les méthodes MFA, clés FIDO2/passkeys, Microsoft Authenticator, numéros de téléphone, Temporary Access Pass et méthodes logicielles. Supprimez seulement les méthodes ajoutées ou contrôlées par l'attaquant; une suppression massive sans preuve peut bloquer l'utilisateur et compliquer l'attribution. Exigez ensuite un nouvel enregistrement lorsque le risque le justifie.

$methods = Get-MgUserAuthenticationMethod -UserId $user.Id
$methods | ForEach-Object {
  [pscustomobject]@{
    Id = $_.Id
    Type = $_.AdditionalProperties['@odata.type']
    Details = ($_.AdditionalProperties | ConvertTo-Json -Compress -Depth 4)
  }
} | Format-Table -AutoSize

• Microsoft — Méthodes d'authentification d'un utilisateur ↗

3. Examiner la boîte avant de nettoyer

Les attaquants utilisent des règles pour transférer, supprimer ou déplacer les réponses vers un dossier discret. Vérifiez les règles visibles et cachées, le transfert de la boîte, les délégations, Send As, Send on Behalf, les réponses automatiques et les applications ayant accès à Exchange.

Exportez d'abord les résultats et les heures de modification lorsque disponibles. Supprimez ensuite les règles ou transferts malveillants de façon ciblée. Une boîte compromise peut aussi avoir été placée dans Restricted entities après un envoi de pourriel; ne la retirez de cette liste qu'après avoir repris le contrôle du compte.

$Mailbox = 'utilisateur@contoso.com'
Connect-ExchangeOnline -ShowBanner:$false

Get-Mailbox -Identity $Mailbox |
  Format-List ForwardingAddress,ForwardingSmtpAddress,DeliverToMailboxAndForward

Get-InboxRule -Mailbox $Mailbox -IncludeHidden |
  Select-Object Name,Enabled,Priority,ForwardTo,ForwardAsAttachmentTo,RedirectTo,`
    DeleteMessage,MoveToFolder,Description

Get-MailboxPermission -Identity $Mailbox |
  Where-Object { -not $_.IsInherited -and $_.User -notlike 'NT AUTHORITY\SELF' }

Get-RecipientPermission -Identity $Mailbox |
  Where-Object { $_.Trustee -ne 'NT AUTHORITY\SELF' }

• Microsoft — Examiner les règles et transferts suspects ↗
• Microsoft — Utilisateurs et entités restreints ↗

4. Chercher les consentements OAuth et la persistance applicative

Un changement de mot de passe n'annule pas automatiquement un consentement OAuth accordé à une application. Dans Entra ID, examinez les applications d'entreprise, les consentements utilisateur et administrateur, les permissions déléguées, les connexions du principal de service, ses propriétaires et ses justificatifs.

Ne supprimez pas une application parce que son nom semble étrange. Confirmez l'éditeur, l'AppId, le ServicePrincipalId, la portée, l'utilisateur ayant consenti et l'activité. Retirez le grant ou l'affectation compromis, désactivez l'application si nécessaire, et cherchez d'autres utilisateurs touchés. Pour une permission applicative ou un consentement administrateur, élargissez immédiatement l'incident au locataire.

• Article — Auditer les applications OAuth et permissions Graph →
• Microsoft — Applications compromises et malveillantes ↗

5. Construire la chronologie à partir des journaux

Définissez une fenêtre qui commence avant le premier signal connu. Conservez les heures en UTC, les identifiants d'événement et les exports originaux. Ne concluez pas qu'une adresse IP est malveillante uniquement parce qu'elle est nouvelle : VPN, réseau mobile, proxy et voyage peuvent modifier la géolocalisation.

MailItemsAccessed aide à évaluer l'exposition des messages lorsque la licence et l'audit le permettent. L'absence d'un événement ne prouve pas l'absence d'accès; documentez la couverture, la rétention et les lacunes.

• Microsoft — Utiliser MailItemsAccessed pour une enquête ↗
• Microsoft — Rechercher dans le journal d'audit ↗

6. Déterminer l'étendue réelle

Si le compte possède un rôle privilégié, s'il a consenti à une permission Graph à forte portée, ou si l'attaquant a modifié des contrôles de sécurité, ne limitez pas l'analyse à la boîte de l'utilisateur. Passez à une investigation de locataire et faites intervenir les responsables sécurité, juridique, confidentialité et assurance selon le plan d'incident.

• Courriels envoyés, supprimés, consultés ou transférés; destinataires internes ayant cliqué ou répondu.
• Fichiers OneDrive et SharePoint consultés, téléchargés, partagés ou supprimés.
• Conversations Teams, réunions, applications, onglets et fichiers accessibles au compte.
• Groupes, rôles, boîtes partagées et délégations qui augmentent la portée du compte.
• Applications OAuth, appareils inscrits, méthodes MFA et secrets ajoutés pendant la fenêtre.
• Actions administratives, politiques Conditional Access, connecteurs Exchange, règles de transport ou domaines modifiés.
• Autres comptes présentant les mêmes IP, campagne de hameçonnage, application ou appareil compromis.

7. Récupérer le compte sans rouvrir la porte

Pour un compte synchronisé, évitez une course entre Active Directory local et Entra ID. Documentez où sont gérés le mot de passe, l'état du compte, les groupes et les méthodes afin que la prochaine synchronisation ne réintroduise pas une configuration indésirable.

• Confirmer que l'appareil d'origine a été analysé, isolé ou réinitialisé selon le verdict.
• Supprimer les méthodes d'authentification, règles, transferts, délégations et grants OAuth confirmés malveillants.
• Réinitialiser le mot de passe à la bonne source et faire enregistrer une méthode résistante à l'hameçonnage lorsque possible.
• Réactiver le compte seulement après critères de sortie documentés et validation par une deuxième personne.
• Réappliquer les accès nécessaires au moindre privilège; ne restaurez pas automatiquement une permission inconnue.
• Tester Outlook, Teams, OneDrive et les applications métier depuis un appareil sain.
• Informer l'utilisateur des messages frauduleux envoyés en son nom et donner un canal de signalement aux destinataires.

8. Surveiller après la remise en service

La durée de surveillance dépend du scénario, de la rétention des journaux et du risque. Utilisez des alertes Defender XDR, Entra ID Protection et Purview lorsque les licences les rendent disponibles, mais gardez un suivi manuel pour les preuves ou signaux non couverts.

Un rapport de première intervention qui aide la suite

Séparez clairement les faits, les hypothèses et les éléments inconnus. Une première intervention vise à stopper l'accès et à préparer une enquête fiable; elle ne doit pas produire une certitude artificielle sur les données consultées ou exfiltrées.

Quand escalader vers une investigation complète

Une investigation complète corrèle identité, courriel, appareils, applications et données, puis évalue les obligations de notification. Elle nécessite une chaîne de conservation, une portée approuvée et des personnes autorisées à traiter les données.

• Compte privilégié, rôle activé ou politique de sécurité modifiée.
• Consentement administrateur, permission applicative ou application multiutilisateur suspecte.
• Accès possible à des renseignements personnels, financiers, de santé ou réglementés.
• Plusieurs comptes, appareil compromis, hameçonnage interne ou mouvement latéral.
• Journaux incomplets, origine inconnue, persistance qui revient ou actions après la révocation.
• Obligation potentielle de notification, conservation légale ou demande d'un assureur.

• Service — Audit de sécurité Microsoft 365 et Entra ID →
• Article — Pourquoi la MFA ne suffit pas contre le vol de jetons →
• Article — Passer Conditional Access de Report-only à Enforced →