Exemple de BEC : un incident Microsoft 365 fictif commenté

Scénario fictif. Tout, dans cet article, est inventé : l'entreprise Meridian Freight (meridianfreight.example), ses salariés, les adresses IP (plages de documentation RFC 5737), les sessions et les e-mails. Seuls les formats de journaux sont réels. C'est le jeu de données Essayer un exemple de M365 Forensics : vous pouvez l'ouvrir et suivre en parallèle.

En bref. Une pulvérisation de mots de passe depuis un VPS échoue. Le lendemain matin, une comptable fournisseurs se connecte à travers un proxy d'hameçonnage AiTM ; sept minutes plus tard, sa session est rejouée depuis un autre pays. En 90 minutes, l'attaquant enregistre une application Authenticator, crée deux règles de boîte de réception nommées « . » et « .. », configure un transfert de boîte vers l'extérieur, synchronise environ 450 messages, cherche « facture virement IBAN », consent à une application de messagerie, télécharge 64 factures et envoie un faux changement de RIB, qu'il supprime ensuite. L'outil rend le verdict Compromission probable avec 18 constats, dont trois critiques. Voici comment chaque étape apparaît dans les journaux, et où les constats demandent un regard humain.

Les données d'entrée

Quatre fichiers, dans les formats des vrais exports :

Couverture : 366 événements du 2026-09-14 07:02 au 2026-09-15 16:33 UTC, avec des enregistrements MailItemsAccessed. Le jeu contient aussi l'activité normale de huit utilisateurs (connexions au bureau, lectures de courrier, accès aux fichiers, une règle de boîte de réception légitime) : l'attaque doit être trouvée, pas seulement lue.

La chronologie (UTC)

Le constat de corrélation critique, « Actions effectuées depuis la session ou l'IP de l'attaquant », regroupe 103 événements : tout ce qui vient des deux IP de l'attaquant ou de la session rejouée, y compris les règles, le transfert, l'enregistrement MFA, le consentement, les lectures, les téléchargements, l'envoi et la suppression. Ce constat répond à lui seul à la question « c'est elle ou eux ? ».

Pourquoi le verdict est « Compromission probable »

La règle : au moins un constat critique, ou deux constats élevés différents sur un même compte. Ici, trois constats critiques (transfert externe par règle, transfert de boîte externe, session de l'attaquant) et huit constats élevés sur le compte de Claire. La rubrique Pourquoi, sous le verdict, renvoie vers eux.

Là où l'analyste doit encore réfléchir

Un vrai rapport ne se contente pas de coller les constats. Trois exemples tirés de ce jeu de données :

1. Le voyage impossible mêle connexions légitimes et malveillantes. Ses preuves listent les sauts « FR → NL · 694 km en 29 min » et « NL → US · 6245 km en 7 min ». Le premier saut part de la vraie connexion de Claire au bureau ; l'attaquant est du côté NL et US. Le constat désigne le bon compte, mais les preuves doivent être triées à la main. Le constat de session est le plus précis.
2. Les constats à seuil incluent l'activité propre de l'utilisatrice. Les constats de volume de boîte et de téléchargement massif listent tous les événements de leur fenêtre d'une heure, y compris les lectures Outlook de Claire et un fichier qu'elle a ouvert depuis le bureau (192.0.2.10). La part de l'attaquant est celle qui vient de 203.0.113.77, avec le client REST et l'agent utilisateur rclone.
3. Un constat moyen est un faux positif. Le 14/09 à 09:05, Sofia Garcia a enregistré des informations de sécurité depuis l'IP du bureau. C'est signalé comme nouvelle méthode MFA (moyen), comme l'enregistrement de l'attaquant. Rien d'autre ne le rattache à l'attaque : une vérification rapide auprès de Sofia suffit à le clore.

À l'inverse, la règle « Newsletters » de Thomas Becker (d'un expéditeur de lettres d'information vers un dossier Newsletters, créée depuis le bureau) ne produit aucun constat.

Délimiter l'impact

• Lu : les enregistrements MailItemsAccessed provenant de l'IP de l'attaquant utilisent le client REST et portent la session rejouée. La liste des InternetMessageId donne les messages à examiner (ce que prouve MailItemsAccessed).
• Transféré : tout ce qui vient du fournisseur après 08:33 (règle « .. ») et chaque message entrant après 08:36 (transfert de boîte), jusqu'à leur suppression.
• Téléchargé : 64 fichiers de sites/Finance/Shared Documents/Factures 2026.
• Envoyé : au moins un e-mail frauduleux à un client ; le suivi des messages montrerait les destinataires.
• Persistance à supprimer : l'Authenticator enregistré à 08:24, les règles « . » et « .. », le transfert de boîte, l'autorisation et le principal de service « Mail Sync Pro », et la session elle-même.

La liste de remédiation

L'outil ordonne les étapes à partir des constats : révoquer les sessions, réinitialiser les identifiants et réenregistrer la MFA, évaluer l'exposition des données, supprimer les règles, supprimer le transfert et bloquer le transfert externe automatique, bloquer les IP de l'attaquant, passer à une MFA résistante à l'hameçonnage, prévenir les contacts, vérifier les paiements, retirer l'application autorisée et restreindre le consentement des utilisateurs, revoir les méthodes MFA et les inscriptions d'applications. La première heure après un BEC explique cet ordre.

Ce que cet exemple ne montre pas

Les vrais incidents sont plus désordonnés : exports tronqués à 50 000 lignes, connexions déjà expirées, attaquants passant par des proxys résidentiels plutôt que par des hébergeurs, plusieurs victimes. Les limites sont listées dans rétention et journaux manquants. La méthode reste celle du guide d'enquête : trouver la connexion de l'attaquant, suivre la session, vérifier chaque mécanisme de persistance.

Pour aller plus loin

• Analyser le journal d'audit unifié dans votre navigateur
• Détection du phishing AiTM
• Glossaire : adversary-in-the-middle, règle de boîte de réception, octroi de consentement illicite