Enquête BEC Microsoft 365 : le guide pratique
Enquêter sur un BEC Microsoft 365 : quels journaux exporter, quoi chercher dans chacun, et comment relier chaque action à la session de l'attaquant.
En bref. Une compromission de messagerie professionnelle (BEC, business email compromise) dans Microsoft 365 s'instruit à partir de trois exports : le journal d'audit unifié de Purview (ce qui a été fait dans la boîte et les fichiers), les journaux de connexion Entra ID, interactives et non interactives (qui s'est connecté, d'où, avec quelle session), et les journaux d'audit Entra ID (méthodes MFA, consentements d'applications, rôles). La méthode ne change pas : trouver la connexion de l'attaquant, pivoter sur son IP, son Session ID et son jeton, lister toutes les actions qui portent ces identifiants, puis vérifier chaque mécanisme de persistance qu'il a pu laisser. Une réinitialisation de mot de passe seule ne règle rien de tout cela.
Le BEC n'a rien d'un problème marginal. Le rapport 2024 de l'IC3 du FBI recense 21 442 plaintes pour BEC et environ 2,77 milliards de dollars de pertes déclarées sur cette seule année. Dans les tenants Microsoft 365, le scénario que je rencontre le plus souvent n'a rien de spectaculaire : un utilisateur saisit son mot de passe sur une page de connexion convaincante, quelques minutes plus tard une règle nommée « . » commence à déplacer les factures vers le dossier RSS Feeds, et une semaine après, le RIB d'un fournisseur « change ». Tout ce qu'il faut pour reconstituer cette chaîne se trouve dans des journaux que le tenant possède déjà, à condition de les exporter avant la fin de leur rétention.
À quoi ressemble un BEC dans les journaux
| Étape | Ce que fait l'attaquant | Où cela apparaît | Champs / opérations clés |
|---|---|---|---|
| Accès initial | Pulvérisation de mots de passe, hameçonnage adversary-in-the-middle, hameçonnage par code d'appareil | Journaux de connexion Entra | Adresse IP, ASN, Authentication Protocol, codes d'erreur 50126 / 50074 |
| Vol de session | Rejoue le cookie ou le jeton d'actualisation volé depuis son propre réseau | Connexions Entra non interactives | Même Session ID, nouvelle IP / nouveau pays |
| Persistance | Enregistre une méthode MFA, consent à une appli OAuth, ajoute des secrets d'application | Audit Entra (aussi dans l'UAL, charge de travail AzureActiveDirectory) | User registered security info, Consent to application, Add service principal credentials |
| Dissimulation | Règles qui suppriment ou déplacent les réponses, transfert de boîte | Journal d'audit unifié | New-InboxRule, Set-InboxRule, UpdateInboxRules, Set-Mailbox |
| Collecte | Lit et synchronise le courrier, cherche « facture », télécharge des fichiers | Journal d'audit unifié | MailItemsAccessed, SearchQueryInitiatedExchange, FileDownloaded |
| Fraude et nettoyage | Envoie le faux changement de RIB, puis l'efface | Journal d'audit unifié | Send, SoftDelete, HardDelete, MoveToDeletedItems |
MITRE ATT&CK nomme la plupart de ces techniques : Email Hiding Rules (T1564.008), Email Forwarding Rule (T1114.003), Web Session Cookie (T1550.004), Steal Application Access Token (T1528).
Étape 1 : collecter avant que la rétention n'efface les preuves
La rétention est la première contrainte, pas la dernière. Entra ID conserve les journaux de connexion et d'audit 7 jours en version gratuite et 30 jours avec P1/P2. Le journal d'audit unifié conserve 180 jours par défaut avec Audit (Standard). Si l'incident a été signalé avec trois semaines de retard, les connexions qui l'expliquent ont peut-être déjà disparu sur un petit tenant.
Exportez, dès le premier jour :
- Le journal d'audit unifié de tout le tenant (pas seulement de la victime), à partir d'au moins 30 jours avant le premier e-mail suspect.
- Les connexions utilisateur interactives et non interactives depuis le centre d'administration Entra. Le rejeu de jeton n'apparaît que dans le fichier non interactif.
- Le journal d'audit Entra, en JSON si possible : le CSV ne conserve qu'un nombre limité de cibles et de propriétés modifiées.
La procédure pas à pas, avec les limites de lignes et la pagination PowerShell, est dans comment exporter le journal d'audit unifié et les journaux de connexion Entra. Ne modifiez jamais les fichiers originaux et calculez leur empreinte : on vous demandera ce que vous avez analysé.
Étape 2 : trouver la connexion de l'attaquant
Partez de ce que vous savez (un e-mail signalé, un paiement frauduleux, un utilisateur qui « n'a pas fait ça ») et remontez jusqu'à la connexion. Dans les journaux de connexion, cherchez :
- Des connexions réussies depuis des réseaux d'hébergeurs ou de VPN (fournisseurs cloud, VPS). Les kits AiTM et les attaquants opèrent rarement depuis un FAI résidentiel.
- Un même Session ID vu depuis deux réseaux. La connexion interactive provient du proxy d'hameçonnage, puis les connexions non interactives de la même session arrivent d'ailleurs. C'est l'indicateur de rejeu le plus fiable ; voir détection du phishing AiTM et du rejeu de jeton.
- Des rafales d'échecs : pulvérisation de mots de passe (une IP, beaucoup de comptes, erreur 50126) ou invites MFA refusées à répétition suivies d'un succès.
- Des connexions par code d'appareil ou par protocole hérité pour des utilisateurs qui n'en utilisent jamais.
- Le voyage impossible, avec prudence : VPN et réseaux mobiles produisent beaucoup de faux positifs. L'article analyse des journaux de connexion Entra ID explique comment faire le tri.
Notez, pour chaque connexion suspecte : l'heure (UTC), l'IP, l'ASN, le pays, l'agent utilisateur, l'application, le Session ID et le Unique token identifier.
Étape 3 : pivoter de la session vers les actions
C'est ici qu'une enquête BEC passe du soupçon à la preuve. Microsoft reporte les identifiants de la connexion dans les journaux des charges de travail : dans le journal d'audit unifié, les enregistrements Exchange et SharePoint contiennent AppAccessContext.AADSessionId et AppAccessContext.UniqueTokenId (Exchange a aussi SessionId). Microsoft les appelle des identifiants liables et documente la correspondance sur Microsoft Learn.
Filtrez l'UAL sur ces valeurs et sur les IP de l'attaquant : vous obtenez les actions de l'attaquant lui-même, séparées de l'activité normale de l'utilisateur sur la même boîte. Lisez-les ensuite dans l'ordre : règles de boîte de réception, transfert, changements MFA, consentements, recherches, lectures, téléchargements, envois, suppressions. L'article enquête sur le journal d'audit unifié liste les opérations et les champs AuditData à lire pour chacune.
Deux réserves. Tous les enregistrements ne portent pas d'identifiant de session (certains enregistrements agrégés ou d'arrière-plan n'en ont pas) : gardez le pivot par IP en secours. Et un pivot par IP seul peut tromper quand l'attaquant utilise une sortie VPN partagée qu'un utilisateur légitime emprunte aussi ; la correspondance de session est plus solide.
Étape 4 : vérifier chaque mécanisme de persistance
Les attaquants s'attendent à une réinitialisation du mot de passe. Ce qui y survit :
| Persistance | Trace | Pourquoi une réinitialisation n'y change rien |
|---|---|---|
| Session / jeton d'actualisation volé | Connexions non interactives depuis l'IP de l'attaquant après la réinitialisation | Les jetons restent valides jusqu'à révocation ou expiration |
| Règle de boîte de réception qui transfère à l'extérieur | New-InboxRule avec ForwardTo / RedirectTo | Le courrier continue de sortir, sans connexion |
| Transfert de boîte | Set-Mailbox avec ForwardingSmtpAddress | Idem |
| Consentement OAuth | Consent to application, Add delegated permission grant | L'application détient ses propres jetons (consentement illicite) |
| Méthode MFA de l'attaquant | User registered security info | L'attaquant passe la MFA avec son propre appareil |
| Délégation de boîte | Add-MailboxPermission, Add-RecipientPermission | Accès via un autre compte |
| Rôle privilégié, secret d'application, fédération | Add member to role, Add service principal credentials, Set domain authentication | Accès au niveau du tenant, indépendant de l'utilisateur |
L'article règles de boîte de réception malveillantes et transferts approfondit la plus courante.
Étape 5 : établir ce qui a été lu et envoyé
La direction posera deux questions : qu'ont-ils lu et à qui ont-ils écrit. La première trouve sa réponse dans MailItemsAccessed : les enregistrements Bind listent les messages un par un par InternetMessageId ; les enregistrements Sync signifient qu'un client a téléchargé tout un dossier, qu'il faut alors considérer comme exposé. La seconde se trouve dans les enregistrements Send issus de la session de l'attaquant, le suivi des messages, les Éléments envoyés et les Éléments récupérables de la victime. Les recherches par mot-clé (SearchQueryInitiatedExchange) montrent ce que l'attaquant cherchait, mais seulement si cette journalisation est activée, ce qui n'est pas le cas par défaut selon le guide de la CISA sur la journalisation étendue.
Étape 6 : construire la chronologie et le verdict
Un bon rapport BEC contient une chronologie unique en UTC, de la première connexion de l'attaquant jusqu'au confinement, chaque ligne citant son enregistrement. Il énonce le verdict avec ses raisons (« compromis : règle de transfert vers l'extérieur créée depuis une session rejouée depuis un autre pays »), ce qui a été exposé, et ce qui n'a pas pu être vérifié. Les lacunes comptent autant que les constats : pas de connexions non interactives, pas de MailItemsAccessed, rétention des connexions de 7 jours. L'article rétention et journaux manquants recense les cas habituels.
Le faire sans SIEM
Beaucoup d'enquêtes BEC concernent de petits tenants sans espace de travail Sentinel ni budget, sur des exports trop gros pour un tableur. M365 Forensics exécute les étapes ci-dessus dans le navigateur : déposez le CSV de l'UAL et les exports Entra, et l'outil analyse les deux couches de l'UAL (colonnes CSV et JSON AuditData), relie les actions sur la boîte aux sessions de connexion suspectes, et rend un verdict Aucun signe de compromission, Activité suspecte ou Compromission probable avec les lignes de preuve, une chronologie de l'incident et une liste de remédiation. Rien n'est envoyé : l'analyseur est du WebAssembly qui tourne sur votre machine. Le pas-à-pas montre chaque écran, et l'incident fictif commenté montre à quoi ressemble un résultat réaliste.
L'outil ne remplace pas le jugement. Les heuristiques orientent, elles ne prouvent pas : une connexion depuis un hébergeur peut être votre propre VPN, et une règle de transfert peut être légitime. Confirmez avec le titulaire du compte.
Après l'enquête
Quand le verdict est « compromis », le confinement passe en premier : révoquer les sessions, supprimer la persistance, bloquer les paiements. L'ordre compte ; il est détaillé dans la première heure après un BEC. Les recommandations de Microsoft se trouvent dans Répondre à un compte de messagerie compromis et dans les guides de réponse aux incidents.
Questions fréquentes
Quels journaux faut-il pour enquêter sur un BEC dans Microsoft 365 ?
Trois sources : le journal d'audit unifié de Purview pour les actions sur les boîtes, les fichiers et l'administration ; les journaux de connexion Entra ID (interactives et non interactives) pour savoir qui s'est connecté et d'où ; et les journaux d'audit Entra ID pour les méthodes MFA, les consentements d'applications, les rôles et la fédération.
Réinitialiser le mot de passe suffit-il à mettre fin à un BEC ?
Non. Les cookies de session et jetons d'actualisation volés, les consentements OAuth, les règles de boîte de réception, le transfert de boîte et les méthodes MFA ajoutées par l'attaquant survivent tous à un changement de mot de passe. Il faut révoquer les sessions et supprimer chaque élément de persistance.
Jusqu'où faut-il remonter dans le temps ?
Au moins 30 jours avant le premier e-mail suspect, et plus si les journaux le permettent. Les attaquants se connectent souvent des jours ou des semaines avant d'agir, et l'hameçonnage qui a volé la session précède généralement la fraude de loin.
Pour aller plus loin
- Microsoft Learn : Répondre à un compte de messagerie compromis
- Blog sécurité de Microsoft : From cookie theft to BEC (en anglais)
- Glossaire : compromission de messagerie professionnelle, journal d'audit unifié, rejeu de jeton
- La même démarche pour d'autres fournisseurs d'identité : forensique des journaux Google Workspace et Okta.