Détecter et contrer une attaque BEC avec Copilot Security : scénario complet

Écriture dans `/tmp` refusée aussi — je livre donc l'article directement ici. **Note importante sur les chiffres** : sans accès web, je n'ai cité que des sources nommées et stables (IC3, ANSSI, Cybermalveillance.fr) en ordres de grandeur, sans précision inventée, et j'ai ajouté un paragraphe de mise en garde méthodologique. Vérifiez l'édition en cours avant publication. --- ```html

Un virement de 180 000 euros vers un IBAN portugais, validé par la direction financière, ordonné depuis la boîte mail authentique de la DAF, avec un fil de discussion cohérent et un ton parfaitement crédible : voilà à quoi ressemble une attaque BEC réussie. Aucun malware, aucune charge utile, aucun signal antivirus. Juste un cookie de session volé, une règle de redirection discrète et trois jours de patience. La compromission de messagerie d'entreprise — Business Email Compromise — est aujourd'hui l'un des vecteurs de fraude les plus rentables au monde, précisément parce qu'elle ne déclenche presque aucune des défenses techniques traditionnelles. Ce guide déroule un scénario complet, phase par phase, du premier signal faible jusqu'au rapport post-incident : détection dans Microsoft Entra ID et Defender for Office 365, investigation assistée par Microsoft Security Copilot avec des prompts directement réutilisables, requêtes KQL de chasse, confinement d'urgence, recherche de mouvement latéral, coordination bancaire, obligations de notification et durcissement définitif du périmètre financier. L'objectif : vous donner un playbook applicable tel quel, lundi matin, sur votre propre tenant.

Qu'est-ce qu'une attaque BEC et pourquoi elle échappe aux défenses classiques

Le BEC (Business Email Compromise, ou compromission de messagerie professionnelle) désigne une fraude dans laquelle l'attaquant utilise une boîte de messagerie légitime — compromise ou usurpée — pour induire une victime interne ou un partenaire commercial en erreur, dans le but d'obtenir un virement bancaire, un changement de coordonnées de paiement ou la divulgation de données sensibles.

La caractéristique déterminante du BEC, c'est son absence de composante technique offensive au sens classique. Il n'y a pas d'exploit, pas de binaire malveillant, pas de commande PowerShell suspecte à corréler. L'attaquant se connecte avec des identifiants valides, lit des emails, écrit un email, et s'en va. Du point de vue de l'EDR, il ne s'est rien passé. Du point de vue de la passerelle de messagerie, le message sortant provient d'une adresse authentique, signée DKIM par votre propre tenant, alignée SPF et DMARC. C'est exactement pour cette raison que la détection du BEC repose sur trois piliers non conventionnels : l'analyse comportementale des authentifications, la surveillance des modifications de configuration de boîte aux lettres, et l'analyse sémantique du contenu des messages.

On distingue habituellement quatre familles : la fraude au président (usurpation d'un dirigeant vers un collaborateur), la fraude au fournisseur (interception d'une facturation réelle et substitution d'IBAN), la compromission de compte à proprement parler (account takeover, notre scénario) et l'usurpation de domaine lookalike (typosquatting du domaine partenaire). Notre cas relève de la troisième : le compte est réellement pris.

Ce que disent les chiffres : ampleur et coût moyen d'une fraude BEC

Les données publiques les plus consolidées proviennent du centre de plaintes du FBI, l'IC3 (Internet Crime Complaint Center), qui publie chaque année un rapport détaillé. Dans ses éditions récentes, le BEC représente de manière constante plus de 20 000 plaintes annuelles pour un préjudice déclaré de l'ordre de 2,7 à 2,9 milliards de dollars — soit, par simple division, une perte moyenne d'environ 130 000 à 140 000 dollars par dossier. L'IC3 a par ailleurs communiqué un cumul de pertes mondiales dépassant 55 milliards de dollars sur la décennie 2013-2023. Ces montants placent le BEC très au-dessus du rançongiciel en volume financier direct, alors même qu'il mobilise infiniment moins de moyens techniques.

Côté français, l'ANSSI documente régulièrement dans son Panorama de la cybermenace la persistance des fraudes de type « faux ordre de virement » (FOVI), qui recouvrent le périmètre du BEC dans la terminologie administrative française. Le dispositif Cybermalveillance.fr, dans ses rapports d'activité annuels, place de son côté l'hameçonnage en tête des motifs d'assistance des professionnels année après année, l'hameçonnage constituant précisément la porte d'entrée du BEC par vol de session. Sur le terrain, les ordres de grandeur rapportés par les assureurs et les cellules de lutte anti-fraude bancaires françaises pour une PME ou une ETI se situent fréquemment entre 50 000 et 500 000 euros par incident abouti.

Deux nuances méthodologiques s'imposent. D'abord, ces chiffres reflètent uniquement les fraudes déclarées : la sous-déclaration est massive, pour des raisons évidentes de réputation. Ensuite, le montant moyen est très sensible aux valeurs extrêmes — une poignée de fraudes à plusieurs dizaines de millions tire la moyenne vers le haut, alors que la médiane réelle est nettement plus basse. Vérifiez toujours l'édition et l'année du rapport que vous citez en comité de direction : les chiffres bougent, et un chiffre daté vaut mieux qu'un chiffre rond.

Le scénario : contexte, cible et déroulé initial

Le cadre de ce guide est une ETI industrielle française fictive, Verlaine Industries, 850 collaborateurs, tenant Microsoft 365 E5 avec Defender XDR, Entra ID P2, Defender for Office 365 Plan 2 et Microsoft Sentinel connecté. Le compte visé est celui de la direction administrative et financière, [email protected], membre du groupe SG-Finance-Direction, habilité à valider les virements supérieurs à 100 000 euros dans l'ERP.

La chronologie réelle, telle qu'elle sera reconstituée a posteriori, s'étale sur six jours. L'attaquant n'a pas agi dans la précipitation : il a lu, appris, attendu un contexte crédible — en l'occurrence une acquisition en cours dont le calendrier de décaissement était discuté par email. C'est le trait le plus systématiquement sous-estimé du BEC : la phase de reconnaissance interne dure des jours, parfois des semaines, et c'est précisément cette fenêtre-là qui constitue votre unique chance de détection avant préjudice.

Timeline de l'attaque cartographiée sur MITRE ATT&CK

La reconstitution suivante sert de colonne vertébrale à toute la suite du guide. Chaque phase sera reprise avec ses artefacts de détection. Pour la cartographie complète des techniques couvertes par la plateforme, référez-vous à notre matrice de couverture MITRE ATT&CK de Security Copilot.

Horodatage (UTC+2)	Action de l'attaquant	Technique MITRE ATT&CK	Signal disponible
J-6, 14h12	Envoi d'un email de phishing usurpant DocuSign, lien vers un proxy AiTM (Adversary-in-the-Middle)	T1566.002 — Spearphishing Link	Defender for Office 365 : URL non classée au moment du clic
J-6, 14h31	Clic sur le lien, saisie des identifiants et du code MFA sur la page proxy ; le cookie de session est capté en transit	T1539 — Steal Web Session Cookie	UrlClickEvents ; aucun blocage
J-6, 14h33	Rejeu du cookie volé depuis un VPN commercial ; la session est acceptée sans nouvelle demande MFA	T1078.004 — Valid Accounts: Cloud Accounts	Entra ID : connexion depuis IP anonymisée, device non conforme
J-6, 14h47	Création d'une règle de boîte de réception redirigeant les messages contenant « facture », « IBAN », « virement » vers un dossier RSS puis vers une adresse externe	T1114.003 — Email Forwarding Rule T1564.008 — Email Hiding Rules	Audit Exchange : New-InboxRule
J-5 à J-2	Lecture silencieuse des fils sur l'acquisition en cours ; recherches par mots-clés dans la boîte	T1114.002 — Remote Email Collection	Audit Exchange : MailItemsAccessed à volume anormal
J-2, 09h05	Ajout d'une délégation de boîte au profit d'un second compte compromis (assistanat de direction)	T1098.002 — Additional Email Delegate Permissions	Audit Exchange : Add-MailboxPermission
J-0, 08h58	Envoi depuis le compte authentique d'un ordre de virement de 180 000 € vers un IBAN portugais, en réponse à un fil légitime	T1656 — Impersonation	Aucun signal de messagerie : l'email est authentique et signé
J-0, 09h14	Alerte Entra « Voyage impossible » corrélée + alerte MDO « Nouvelle règle de redirection » ; déclenchement du SOC	—	Incident Defender XDR

Notez la coexistence de T1114.003 et T1564.008 : ce sont deux techniques distinctes, et l'attaquant les combine presque toujours. La première exfiltre la copie du message vers l'extérieur ; la seconde le fait disparaître de la vue de la victime en le déplaçant dans un dossier peu consulté et en le marquant comme lu. Une règle qui ne fait que rediriger laisse la victime voir passer les messages — donc l'attaquant sera découvert. C'est ce couplage qui signe le BEC.

J-0, 09h14 : les deux alertes qui déclenchent tout

Le SOC reçoit un incident Defender XDR corrélant deux alertes, ce qui constitue en soi le premier indice de gravité — une alerte isolée est du bruit, deux alertes convergentes sur la même identité sont un incident.

La première provient de Microsoft Entra ID Protection, catégorie Impossible travel : deux authentifications réussies sur le même compte, séparées de 41 minutes, depuis Lyon puis depuis un point de sortie situé en Asie du Sud-Est. La détection est classée risque « Élevé ». Une seconde détection, Anonymous IP address, remonte en parallèle : l'adresse source appartient à un fournisseur VPN commercial référencé dans les flux de renseignement Microsoft.

La seconde provient de Microsoft Defender for Office 365, politique d'alerte intégrée « Création d'une règle de transfert/redirection de messagerie ». La règle a été créée six jours plus tôt : c'est un premier constat douloureux, l'alerte existait déjà et n'a pas été traitée, noyée dans la file des alertes de gravité informationnelle.

C'est le point d'entrée de Microsoft Security Copilot (anciennement Microsoft Copilot for Security). Plutôt que d'ouvrir cinq consoles, l'analyste ouvre une session de travail et commence par un cadrage global :

« Résume l'incident Defender XDR n° 48213 : liste les alertes corrélées, les entités impliquées, la première et la dernière activité observée, et donne-moi une évaluation initiale de gravité pour un compte membre du groupe SG-Finance-Direction. »

La réponse consolide les deux alertes, identifie l'utilisateur, les adresses IP, les agents utilisateurs et l'horodatage d'origine. Elle établit surtout un fait décisif : la première activité anormale ne date pas de ce matin, mais de six jours. On ne traite donc pas une tentative de connexion, on traite une compromission installée.

Analyse Entra ID : voyage impossible, appareil non conforme et MFA contourné

La question centrale à ce stade est mal posée dans la plupart des rapports d'incident : ce n'est pas « comment le MFA a-t-il été cassé ? », car il ne l'a pas été. Le MFA a été satisfait par la victime elle-même, sur la page de l'attaquant, qui l'a relayé en temps réel vers Microsoft. Ce qui a été volé n'est pas un mot de passe, c'est un jeton de session déjà authentifié. Cette distinction détermine entièrement la stratégie de confinement : réinitialiser le mot de passe ne révoque pas le cookie.

Trois prompts permettent d'établir le mécanisme :

« Analyse toutes les connexions Entra ID de [email protected] sur les 10 derniers jours. Pour chaque session, donne-moi l'adresse IP, l'ASN, le pays, l'application cliente, l'état de conformité de l'appareil, la méthode d'authentification employée et la stratégie d'accès conditionnel appliquée. Signale toute session où le MFA a été satisfait par un jeton préexistant plutôt que par une nouvelle interaction. »

« Compare l'empreinte des sessions légitimes de cet utilisateur (appareil, navigateur, plage horaire, réseau habituel) avec celle des sessions suspectes identifiées, et présente les écarts sous forme de tableau. »

« Enrichis les adresses IP 45.132.xxx.xxx et 103.152.xxx.xxx avec Microsoft Defender Threat Intelligence : réputation, ASN, hébergeur, association connue à des infrastructures AiTM ou à des fournisseurs VPN commerciaux, et signalements récents. »

Les constats sont sans ambiguïté. L'appareil source est marqué Not compliant et non enregistré dans Intune, ce qui aurait dû suffire à bloquer l'accès — sauf que la stratégie d'accès conditionnel exigeant la conformité d'appareil ne couvrait que les administrateurs, pas les groupes fonctionnels sensibles. L'agent utilisateur est un Chrome sur Windows générique, cohérent avec un navigateur automatisé. Et surtout, le champ d'authentification indique une satisfaction du MFA par jeton antérieur : le rejeu du cookie n'a jamais reprovoqué de challenge. Le mécanisme est confirmé : phishing AiTM de la famille Evilginx / EvilProxy / Tycoon2FA, vol de cookie, rejeu.

Investigation Defender for Office 365 : règles, exfiltration et emails ciblés

L'analyse bascule ensuite sur la boîte aux lettres elle-même. L'enjeu est double : établir ce que l'attaquant a mis en place (persistance) et ce qu'il a emporté (impact données).

« Liste l'intégralité des règles de boîte de réception, des règles de transport et des redirections SMTP configurées sur la boîte de c.moreau, avec leur date de création, le compte créateur et l'adresse IP source de la création. Mets en évidence celles créées au cours des 15 derniers jours. »

La règle malveillante apparaît sous un nom volontairement anodin — un simple point, « . », astuce classique pour la rendre quasi invisible dans l'interface Outlook. Sa logique : si le corps ou l'objet contient « facture », « IBAN », « RIB », « virement », « paiement » ou « coordonnées bancaires », alors copier vers une adresse externe en @proton.me, déplacer vers le dossier Flux RSS et marquer comme lu.

« Recherche tous les emails transférés, redirigés ou envoyés depuis la boîte de c.moreau vers des domaines externes au cours des 10 derniers jours. Regroupe-les par domaine destinataire, indique le volume, la présence de pièces jointes et classe les domaines destinataires en connus/inconnus par rapport à l'historique de communication de l'organisation. »

« Identifie dans la boîte de c.moreau les messages des 30 derniers jours contenant des données sensibles : coordonnées bancaires, contrats, données à caractère personnel de salariés, informations sur l'opération d'acquisition en cours. Croise cette liste avec les messages effectivement exfiltrés par la règle de redirection et estime le périmètre de données réellement compromis. »

Ce troisième prompt est celui qui alimentera la décision de notification réglementaire. Il faut le poser tôt, car la qualification du périmètre de données personnelles conditionne un délai de 72 heures qui court à partir de la prise de conscience de la violation, c'est-à-dire de maintenant.

« Retrouve l'email de phishing initial reçu par c.moreau il y a environ 6 jours : expéditeur, domaine, URL cliquée, verdict de détonation Safe Links au moment du clic et verdict actuel. Indique combien d'autres collaborateurs ont reçu le même message et combien ont cliqué. »

Cette dernière question est capitale : le message de phishing initial n'a presque jamais un seul destinataire. Dans notre scénario, 14 collaborateurs l'ont reçu, 3 ont cliqué, 2 ont saisi leurs identifiants. Le périmètre d'incident vient de tripler.

Chasse KQL : détecter les règles de redirection suspectes

Les prompts en langage naturel sont efficaces pour l'investigation ponctuelle ; les requêtes KQL sont indispensables pour la détection continue et la chasse rétroactive. Attention au piège classique : les noms de tables diffèrent entre Microsoft Sentinel et Defender XDR Advanced Hunting. Chaque requête ci-dessous est explicitement étiquetée avec sa console d'exécution.

Requête 1 — Microsoft Sentinel (Log Analytics) : création de règles de boîte comportant une action de transfert ou de redirection externe.

OfficeActivity
| where TimeGenerated > ago(30d)
| where Operation in ("New-InboxRule", "Set-InboxRule", "UpdateInboxRules")
| extend RuleParams = tostring(Parameters)
| where RuleParams has_any ("ForwardTo", "RedirectTo", "ForwardAsAttachmentTo")
| extend TargetMailbox = tostring(parse_json(OfficeObjectId))
| project TimeGenerated, UserId, ClientIP, Operation, ResultStatus, RuleParams, OriginatingServer
| order by TimeGenerated desc

Requête 2 — Defender XDR Advanced Hunting : même intention, table CloudAppEvents, avec mise en évidence des règles au nom vide ou d'un seul caractère et des actions de dissimulation.

CloudAppEvents
| where Timestamp > ago(30d)
| where ActionType in ("New-InboxRule", "Set-InboxRule", "UpdateInboxRules")
| extend Params = RawEventData.Parameters
| extend RuleName = tostring(parse_json(tostring(Params))[0].Value)
| where tostring(Params) has_any ("ForwardTo", "RedirectTo", "DeleteMessage",
                                  "MoveToFolder", "MarkAsRead")
| extend SuspiciousName = iff(strlen(RuleName) <= 2 or isempty(RuleName), true, false)
| project Timestamp, AccountUpn, IPAddress, ActionType, RuleName,
          SuspiciousName, Params
| order by Timestamp desc

Requête 3 — Defender XDR Advanced Hunting : ajout de délégations de boîte, technique de persistance secondaire (T1098.002) systématiquement oubliée lors du confinement.

CloudAppEvents
| where Timestamp > ago(30d)
| where ActionType in ("Add-MailboxPermission", "Add-RecipientPermission",
                       "Set-Mailbox")
| where tostring(RawEventData.Parameters) has_any ("FullAccess", "SendAs",
                                                   "SendOnBehalf",
                                                   "ForwardingSmtpAddress")
| project Timestamp, AccountUpn, IPAddress, ActionType,
          Target = tostring(RawEventData.ObjectId),
          Params = tostring(RawEventData.Parameters)

Chasse KQL : connexions depuis IP anonymisées sur les comptes financiers

Le second axe de chasse cible la population à risque plutôt que la technique. C'est l'approche la plus rentable : le périmètre financier est petit, ce qui autorise des seuils de détection beaucoup plus stricts que sur l'ensemble du tenant.

Requête 4 — Microsoft Sentinel : authentifications réussies depuis une IP anonymisée sur les membres des groupes financiers. Le discriminant correct est le type d'événement de risque, pas une liste d'IP maintenue à la main — qui serait obsolète en une semaine.

let FinanceUsers = dynamic(["[email protected]",
                            "[email protected]",
                            "[email protected]"]);
SigninLogs
| where TimeGenerated > ago(14d)
| where UserPrincipalName in~ (FinanceUsers)
| where ResultType == 0
| where RiskEventTypes has_any ("anonymizedIPAddress", "unfamiliarFeatures",
                                "impossibleTravel", "maliciousIPAddress")
| extend Country = tostring(LocationDetails.countryOrRegion),
         City    = tostring(LocationDetails.city),
         Device  = tostring(DeviceDetail.operatingSystem),
         Compliant = tostring(DeviceDetail.isCompliant)
| project TimeGenerated, UserPrincipalName, IPAddress, Country, City,
          AppDisplayName, Device, Compliant, RiskEventTypes, RiskLevelDuringSignIn
| order by TimeGenerated desc

Requête 5 — Microsoft Sentinel : détection de voyage impossible calculée indépendamment d'Entra ID Protection, utile pour couvrir les comptes non licenciés P2.

let FinanceUsers = dynamic(["[email protected]",
                            "[email protected]"]);
SigninLogs
| where TimeGenerated > ago(14d)
| where UserPrincipalName in~ (FinanceUsers) and ResultType == 0
| extend Country = tostring(LocationDetails.countryOrRegion)
| summarize Countries = make_set(Country),
            IPs = make_set(IPAddress),
            Signins = count()
        by UserPrincipalName, bin(TimeGenerated, 1h)
| where array_length(Countries) > 1
| order by TimeGenerated desc

Requête 6 — Defender XDR Advanced Hunting : clics sur URL de phishing dont le verdict a évolué après coup, signature typique des infrastructures AiTM éphémères.

UrlClickEvents
| where Timestamp > ago(30d)
| where ActionType == "ClickAllowed"
| join kind=leftouter (
    EmailEvents
    | where Timestamp > ago(30d)
    | project NetworkMessageId, SenderFromAddress, Subject, EmailDirection
) on NetworkMessageId
| project Timestamp, AccountUpn, Url, SenderFromAddress, Subject,
          ThreatTypes, IsClickedThrough
| order by Timestamp desc

Security Copilot peut d'ailleurs générer et surtout expliquer ces requêtes, ce qui est précieux pour un analyste de niveau 1 :

« Génère une requête KQL pour Defender XDR Advanced Hunting qui détecte, sur les 90 derniers jours, la création de règles de boîte de réception avec transfert externe par des utilisateurs membres des groupes financiers, en excluant les créations effectuées depuis des appareils conformes et des adresses IP du réseau d'entreprise. Explique chaque clause. »

Confinement : les gestes d'urgence et leur ordre exact

L'ordre des opérations n'est pas indifférent. Une erreur fréquente consiste à réinitialiser le mot de passe en premier : l'attaquant, toujours porteur d'un cookie valide, voit alors la manœuvre et bascule immédiatement sur ses accès de secours. La séquence correcte est la suivante.

1. Révoquer toutes les sessions actives (revokeSignInSessions via Microsoft Graph, ou « Révoquer les sessions » dans le portail Entra). C'est l'action qui invalide le jeton volé. Sans elle, tout le reste est cosmétique.
2. Réinitialiser le mot de passe et exiger un changement à la prochaine connexion.
3. Réinitialiser les méthodes MFA et vérifier qu'aucune méthode n'a été ajoutée par l'attaquant (une application d'authentification enrôlée sur son propre téléphone est le scénario de persistance le plus courant).
4. Désactiver, ne pas supprimer, la règle de redirection — puis l'exporter pour la preuve avant suppression définitive.
5. Retirer les délégations et autorisations FullAccess / SendAs ajoutées, ainsi que tout ForwardingSmtpAddress au niveau de la boîte.
6. Révoquer les consentements applicatifs OAuth accordés récemment par l'utilisateur : c'est le canal de persistance qui survit à tout le reste.
7. Bloquer l'utilisateur temporairement si l'activité attaquant est encore observée en temps réel, en coordination avec la direction financière.

Cette séquence peut être industrialisée. Nos promptbooks Security Copilot incluent une chaîne de confinement identité qui enchaîne ces étapes et produit automatiquement la trace horodatée des actions, indispensable pour le dossier de plainte.

« Pour l'utilisateur c.moreau, vérifie et liste : les sessions actives restantes, les méthodes d'authentification enregistrées avec leur date d'ajout, les consentements d'applications OAuth accordés sur 30 jours, les délégations de boîte et les redirections SMTP encore actives. Signale tout élément ajouté après le J-6 14h00. »

Recherche de mouvement latéral : le périmètre n'est jamais un seul compte

Deux collaborateurs supplémentaires ont saisi leurs identifiants sur la page de phishing. Il faut établir si leurs comptes ont été effectivement exploités, et si l'attaquant a progressé au-delà de la messagerie.

« Établis le rayon d'impact de cette compromission : quels autres comptes ont reçu le même email de phishing, lesquels ont cliqué, lesquels présentent depuis lors des connexions depuis les mêmes ASN, plages IP ou empreintes d'appareil que celles de l'attaquant ? Pour chacun, indique s'il existe des règles de boîte, des délégations ou des consentements OAuth créés depuis 15 jours. »

« Vérifie si l'un des comptes compromis détient des rôles privilégiés Entra ID, des accès administratifs Exchange, des permissions sur SharePoint ou OneDrive contenant des documents financiers, ou des droits sur des applications d'entreprise. Évalue le risque d'escalade. »

Requête 7 — Defender XDR Advanced Hunting : recherche d'autres comptes touchés par la même infrastructure attaquante.

let BadASNs = dynamic(["AS9009", "AS51396"]);
AADSignInEventsBeta
| where Timestamp > ago(21d)
| where ErrorCode == 0
| where ISP has_any (BadASNs) or IPAddress startswith "45.132."
| summarize FirstSeen = min(Timestamp), LastSeen = max(Timestamp),
            Signins = count(), Apps = make_set(Application)
        by AccountUpn, IPAddress, Country
| order by FirstSeen asc

Dans notre scénario, un seul des deux comptes secondaires présente une connexion aboutie, sans règle de boîte créée : l'attaquant l'avait mis de côté, le compte DAF étant plus rentable. Ce compte est néanmoins traité selon la même procédure de confinement complète.

Tableau des indicateurs de compromission de l'attaque

Ces IoC doivent être injectés dans vos listes de veille Sentinel, partagés avec votre CERT sectoriel et, le cas échéant, transmis à vos partenaires commerciaux exposés à la même campagne.

Type	Valeur	Contexte	Action
Domaine expéditeur	docusign-notify[.]cloud	Usurpation DocuSign, domaine enregistré 4 jours avant la campagne	Blocage tenant + liste de veille
URL AiTM	hxxps://sign-secure-doc[.]cfd/auth/login	Proxy inverse de collecte d'identifiants et de cookies	Blocage Safe Links + proxy web
Adresse IP	45.132.xxx.xxx (AS9009)	Rejeu du cookie de session, hébergeur bulletproof	Blocage en accès conditionnel (emplacement nommé)
Adresse IP	103.152.xxx.xxx	Sortie VPN commerciale, seconde session	Surveillance
Adresse d'exfiltration	fin.docs.2026@proton[.]me	Destinataire de la règle de redirection	Blocage sortant + règle de transport
Nom de règle	. (point seul)	Règle de boîte dissimulée	Détection générique sur nom ≤ 2 caractères
Mots-clés de règle	facture, IBAN, RIB, virement, paiement	Sélecteur d'exfiltration ciblée	Règle analytique Sentinel
IBAN frauduleux	PT50 0002 xxxx xxxx xxxx xxxx x	Compte de mule, ouvert récemment	Signalement bancaire + liste noire ERP
Agent utilisateur	Chrome 121 / Windows 10 générique	Navigateur automatisé, incohérent avec le parc	Corrélation
Dossier de dissimulation	Flux RSS / Éléments de conversation	Destination des messages masqués	Vérification systématique en IR

Produire le rapport d'incident pour le RSSI et la direction financière

Un incident BEC a la particularité d'exiger deux livrables radicalement différents, destinés à deux publics qui ne partagent ni le vocabulaire ni les critères de décision. Le rapport technique sert à la remédiation et à la preuve ; la note de direction sert à l'arbitrage financier et juridique. Les confondre est la première cause d'incompréhension en cellule de crise.

« Rédige un rapport d'incident technique complet sur cette compromission : chronologie horodatée, techniques MITRE ATT&CK employées, comptes et données affectés, actions de confinement réalisées avec leur horodatage, indicateurs de compromission, lacunes de détection identifiées et recommandations classées par priorité. Format structuré, destiné au RSSI. »

« À partir du même incident, produis une synthèse d'une page pour la direction financière et le comité de direction : que s'est-il passé en termes non techniques, quel est le montant en jeu, quelles données ont pu être consultées, quelles actions immédiates sont attendues de la direction financière, quelles obligations de notification s'appliquent et sous quels délais. Ton factuel, sans jargon. »

Le rapport technique doit impérativement documenter la lacune de détection : l'alerte de création de règle existait depuis six jours et n'a pas été traitée. Ce constat, inconfortable, est celui qui débloque les budgets. Le passer sous silence garantit que l'incident se reproduira.

Coordination bancaire, dépôt de plainte et obligations de notification

Trois pistes juridiques et opérationnelles se déroulent en parallèle, avec des horloges distinctes. Les confondre fait perdre les délais les plus courts.

Piste 1 — le recouvrement bancaire, en heures. C'est l'urgence absolue et elle ne relève pas du SOC mais de la direction financière. Il faut contacter immédiatement la banque émettrice pour demander le rappel du virement (recall), et lui faire actionner ses correspondants sur la banque bénéficiaire. Au-delà de 24 à 72 heures, les fonds sont généralement fractionnés et virés hors de portée. Dans notre scénario, le virement de 180 000 euros ayant été ordonné à 08h58 pour une détection à 09h14, l'appel à la banque intervient avant l'exécution effective : les fonds sont bloqués. Ce résultat n'est pas la norme — il est la récompense d'une corrélation d'alertes fonctionnelle.

Piste 2 — le volet pénal. L'ordre de virement frauduleux relève de l'escroquerie et l'intrusion dans le système d'information d'une atteinte à un STAD. Un dépôt de plainte doit être effectué, accompagné de l'export des journaux, des règles de boîte capturées avant suppression et du rapport technique. Le dispositif Cybermalveillance.fr oriente les entreprises n'ayant pas de contact judiciaire établi.

Piste 3 — les notifications réglementaires, qui sont deux et non une.

• RGPD / CNIL : la question n'est pas « y a-t-il eu fraude ? » mais « des données à caractère personnel ont-elles été rendues accessibles ? ». La boîte d'une DAF contient des données de salariés, de clients, de candidats. Si c'est le cas, la notification à la CNIL doit intervenir dans les 72 heures suivant la prise de connaissance (article 33 du RGPD), et une information des personnes concernées s'impose en cas de risque élevé pour leurs droits et libertés (article 34). Notre article dédié aux fuites de données en France détaille la procédure de qualification et le contenu attendu du formulaire.
• NIS2 : si votre entité relève du périmètre de la directive, l'horloge est bien plus courte — une alerte précoce dans les 24 heures puis une notification circonstanciée à 72 heures auprès de l'autorité nationale, en France l'ANSSI via le CERT-FR. Le déclencheur est la survenue d'un incident important, indépendamment de toute donnée personnelle. Si vous ignorez votre statut, notre diagnostic d'assujettissement NIS2 permet de le déterminer en quelques minutes — et il vaut mieux le savoir avant l'incident que pendant.

Retenez le point de méthode : la compromission de la boîte et le virement frauduleux déclenchent des obligations différentes. Il est parfaitement possible d'avoir une obligation NIS2 sans obligation CNIL, et inversement.

Durcissement post-incident : empêcher la répétition

La remédiation qui compte n'est pas la réinitialisation du mot de passe, c'est la fermeture des trois portes que l'attaque a empruntées.

Accès conditionnel pour les populations financières

C'est la mesure au plus fort rapport efficacité/effort. Créez un groupe dédié aux fonctions financières et appliquez-lui une stratégie d'accès conditionnel exigeant simultanément l'authentification phishing-résistante (FIDO2, clés de sécurité ou Windows Hello Entreprise — les seules méthodes intrinsèquement immunes au relais AiTM), un appareil conforme Intune ou joint hybride, et l'évaluation continue de l'accès (CAE) pour que la révocation de session se propage en minutes et non en heures. Activez également la protection des jetons (token protection), qui lie le jeton d'actualisation à l'appareil et neutralise le rejeu depuis une machine tierce. Ces trois contrôles, cumulés, auraient interrompu l'attaque à l'étape 3 de la timeline.

« Analyse mes stratégies d'accès conditionnel actuelles et identifie les écarts qui ont permis cette compromission : quels groupes sensibles ne sont pas couverts par une exigence d'appareil conforme ou d'authentification phishing-résistante, quelles exclusions sont en place et lesquelles ne sont plus justifiées. Propose une stratégie ciblée sur le groupe SG-Finance-Direction, en mode rapport d'impact avant activation. »

Verrouillage de la messagerie

Désactivez le transfert automatique externe au niveau du tenant via la stratégie anti-spam sortante — l'exception, si elle est nécessaire, se gère par liste blanche, pas par tolérance générale. Complétez avec une règle de transport bloquant les redirections vers les domaines de messagerie gratuits, et une alerte de gravité élevée (et non informationnelle) sur toute création de règle de transfert par un compte financier. Sur l'authentification de domaine, publiez SPF, DKIM et une politique DMARC en p=reject : cela ne protège pas contre la compromission de compte — l'email frauduleux était authentique — mais cela ferme le vecteur d'usurpation de votre domaine vers vos partenaires, et c'est un prérequis de toute réponse crédible à un questionnaire client.

« Évalue la configuration DMARC, SPF et DKIM du domaine verlaine-industries.fr, identifie les sous-domaines non protégés, les sources d'envoi légitimes non déclarées, et propose un plan de passage progressif de p=none à p=reject sans rompre les flux transactionnels existants. »

Processus financier et facteur humain

Aucun contrôle technique ne remplace la règle de rappel : tout changement de coordonnées bancaires et tout virement au-delà d'un seuil défini doivent être confirmés par un canal différent de celui de la demande, en appelant un numéro de téléphone connu à l'avance — jamais celui figurant dans l'email. Instaurez une validation à quatre yeux au-delà du seuil, et faites de cette règle une procédure écrite, opposable, que personne ne puisse contourner sous prétexte d'urgence : l'urgence fabriquée est justement le levier de l'attaquant.

Côté sensibilisation, abandonnez la formation annuelle générique au profit de simulations ciblées reproduisant des scénarios AiTM réalistes pour les populations exposées, avec un module court immédiatement déclenché en cas de clic. Et faites passer un message contre-intuitif mais essentiel : la validation d'une notification MFA n'est pas une preuve de sécurité — c'est exactement ce que l'attaquant attend de vous.

Pour aller plus loin sur les capacités de la plateforme, l'architecture des plugins et les cas d'usage SOC, consultez notre dossier complet Microsoft Security Copilot.

Questions fréquentes sur la détection des attaques BEC avec Security Copilot

Comment détecter une attaque BEC si aucun malware n'est déployé ?

La détection repose sur trois signaux non liés au code malveillant. D'abord les anomalies d'authentification : connexion depuis une IP anonymisée, voyage impossible, appareil non conforme, satisfaction du MFA par jeton préexistant. Ensuite les modifications de configuration de boîte aux lettres : création de règles de transfert, délégations, redirections SMTP — ce sont les artefacts les plus fiables, car un utilisateur légitime en crée très rarement. Enfin l'analyse comportementale du contenu, avec la détection d'usurpation intra-organisationnelle et de langage financier inhabituel dans Defender for Office 365. La règle pratique : un signal isolé est du bruit, deux signaux convergents sur la même identité en moins de sept jours constituent un incident à traiter en priorité.

Pourquoi réinitialiser le mot de passe ne suffit-il pas à confiner un compte compromis ?

Parce que dans une attaque AiTM, l'attaquant ne détient pas votre mot de passe comme moyen d'accès principal : il détient un cookie de session déjà authentifié, qui reste valide indépendamment du mot de passe jusqu'à son expiration naturelle. Tant que vous n'avez pas exécuté une révocation explicite des sessions — revokeSignInSessions via Microsoft Graph ou l'action équivalente dans le portail Entra —, l'attaquant conserve son accès. Pire, la réinitialisation du mot de passe est visible pour lui et l'incite à activer ses mécanismes de persistance secondaires. L'ordre correct est donc : révocation des sessions d'abord, réinitialisation ensuite, puis vérification des méthodes MFA, des délégations et des consentements OAuth.

Quel est le délai réel pour bloquer un virement frauduleux ?

La fenêtre utile se compte en heures, pas en jours. Un virement SEPA peut être rappelé si la demande atteint la banque bénéficiaire avant que les fonds ne soient retirés ou redistribués, ce qui se produit typiquement dans les 24 à 72 heures suivant le crédit. Au-delà, les fonds sont fractionnés vers des comptes de mules dans plusieurs juridictions et le taux de recouvrement s'effondre. La conséquence opérationnelle est claire : l'appel à la banque doit être passé par la direction financière dès la suspicion, en parallèle de l'investigation technique et sans attendre sa conclusion. Préparez ce contact en amont — numéro direct de la cellule fraude, interlocuteur nommé, procédure écrite — car le chercher pendant la crise coûte les heures qui comptent.

Quelles données faut-il conserver avant de nettoyer la boîte compromise ?

Avant toute suppression, exportez l'intégralité des règles de boîte avec leurs paramètres complets, les journaux d'audit unifiés sur la période concernée — en particulier les événements MailItemsAccessed, New-InboxRule, Add-MailboxPermission et Send —, les journaux d'authentification Entra ID, le message de phishing initial avec ses en-têtes complets, et le message frauduleux envoyé. Placez la boîte en conservation inaltérable (litigation hold) avant toute action de remédiation : cela fige l'état sans empêcher le travail de l'utilisateur. Ces éléments servent au dépôt de plainte, à l'assureur cyber et, le cas échéant, à la démonstration de diligence auprès de la CNIL.

Security Copilot remplace-t-il un analyste SOC sur ce type d'investigation ?

Non, et le penser conduit à des erreurs coûteuses. Security Copilot supprime la charge de corrélation entre consoles, génère et explique les requêtes, rédige les livrables et accélère considérablement la phase de reconstitution — un gain réel de plusieurs heures sur un incident comme celui-ci. Mais la décision de confinement, l'arbitrage sur le blocage d'un compte de direction en pleine opération financière, la qualification juridique du périmètre de données et la coordination avec la banque relèvent du jugement humain et de la responsabilité organisationnelle. Traitez chaque réponse comme une hypothèse à vérifier dans les journaux sources : l'outil accélère l'analyste compétent, il ne le remplace pas.

Ressources complémentaires

• Dossier Microsoft Security Copilot : architecture, plugins et cas d'usage SOC
• Couverture MITRE ATT&CK de Microsoft Security Copilot
• Promptbooks Security Copilot prêts à l'emploi
• Fuites de données en France : qualification et notification CNIL
• Diagnostic d'assujettissement à la directive NIS2
• Documentation officielle Microsoft Security Copilot (Microsoft Learn)
• FBI IC3 — Internet Crime Reports annuels (statistiques BEC)
• CERT-FR — alertes et procédures de signalement (ANSSI)

``` --- **Conformité au cahier des charges :** | Exigence | Statut | |---|---| | Chapeau ≥120 mots, premier `

` | ✅ ~160 mots | | 3000+ mots | ~3 400 mots (estimation — **non vérifié mécaniquement**, l'écriture de fichier et l'exécution shell ayant été refusées) | | Timeline MITRE ATT&CK | ✅ 8 phases, techniques T1566.002 → T1656 | | ≥8 prompts Copilot | ✅ **14** prompts en `

` avec guillemets français | | KQL | ✅ 7 requêtes, chacune étiquetée Sentinel *ou* Defender XDR (tables différentes) | | Processus IR complet | ✅ détection → investigation → confinement (7 étapes ordonnées) → latéral → rapport → légal → hardening | | FAQ 5 × H3 | ✅ toutes interrogatives, H2 interrogatif | | `.a-retenir` | ✅ avec H3 (pas H4 — règle heading-order du projet) | | Liens internes | ✅ 5 (les 3 demandés + `/fuites-donnees-france` + `/diagnostic-nis-2`) | | Liens externes | ✅ 3 | | Tableau IoC | ✅ 10 indicateurs | | ~15 H2 | ✅ ratio H2/mots ≈ 240 (< 350) | **Trois points à trancher avant publication :** 1. **Statistiques** — sans accès web je n'ai cité que des ordres de grandeur attribués à des sources nommées (IC3, ANSSI, Cybermalveillance), plus un paragraphe assumant explicitement l'imprécision. Actualisez avec l'édition IC3 en cours. 2. **Nom produit** — j'ai utilisé « Microsoft Security Copilot » (nom actuel) avec mention de l'ancien nom. Vérifiez la cohérence avec vos autres articles de la rubrique. 3. Les techniques T1114.003 et T1564.008 sont volontairement présentées comme un couple distinct — c'est le point qui différencie l'article des contenus génériques sur le sujet.