Microsoft Copilot Security dans Defender XDR : reconstruction des chaînes d'attaque multi-domaines

En 2026, un incident de type Business Email Compromise correctement instrumenté dans Microsoft Defender XDR ne produit plus une alerte, mais une constellation : détection de session anormale côté Entra ID, création d'une règle de boîte de réception côté Exchange Online, connexion depuis un ASN résidentiel côté Defender for Cloud Apps, parfois un binaire signé exécuté sur un poste côté Defender for Endpoint. Sur les déploiements que nous observons en clientèle, la fenêtre entre le vol du jeton de session et la première tentative de virement frauduleux est passée sous la barre des quatre-vingt-dix minutes, là où le temps médian de qualification manuelle d'un incident multi-produits reste supérieur à deux heures dans un SOC de niveau 1 correctement doté. C'est exactement l'écart que Microsoft Security Copilot prétend combler en reconstruisant automatiquement la chaîne d'attaque, en langage naturel, à partir du graphe d'incident. Cet article démonte la mécanique réelle de cette reconstruction, ce qu'elle voit, ce qu'elle infère, et surtout ce qu'un analyste doit continuer à vérifier lui-même avant d'engager une action de confinement irréversible sur un compte de direction.

Defender XDR et Copilot Security : l'intégration technique expliquée

La confusion la plus fréquente en avant-vente consiste à traiter Security Copilot comme une fonctionnalité de Defender XDR. Ce n'est pas le cas. Il s'agit d'un service distinct, avec son propre plan de facturation, sa propre gouvernance d'accès et son propre portail, qui expose ses capacités à l'intérieur du portail Defender via ce que Microsoft appelle l'embedded experience. Comprendre cette séparation change la façon dont on conçoit les runbooks du SOC. La documentation de référence sur l'architecture du produit est disponible sur le portail Microsoft Learn dédié à Security Copilot.

Le modèle de plugins et la surface de données réellement accessible

Security Copilot n'interroge aucune donnée directement. Il passe par des plugins, chacun encapsulant un ensemble de « skills » qui traduisent une intention en appel d'API sur un produit cible. Les plugins Microsoft de première partie couvrent Defender XDR, Microsoft Sentinel, Entra ID, Intune, Purview, Defender Threat Intelligence, Defender External Attack Surface Management et Defender for Cloud. Le détail des plugins disponibles et de leur mode d'activation est décrit dans la présentation officielle des plugins Security Copilot.

Conséquence opérationnelle majeure, souvent découverte trop tard : la profondeur d'analyse de Copilot est strictement bornée par les plugins activés et par les permissions du compte de l'analyste. Un analyste disposant du rôle Security Reader sur Defender XDR mais dépourvu de rôle de lecture sur Entra ID obtiendra une Attack Story amputée de tout le volet identité, sans que l'interface signale explicitement l'angle mort. Copilot opère en double contrôle d'accès : le contexte utilisateur est propagé aux API sous-jacentes, ce qui est une excellente propriété de sécurité mais une source récurrente de faux négatifs perçus. Le premier réflexe de diagnostic, quand une Attack Story paraît pauvre, consiste donc à vérifier les rôles de l'appelant, pas la qualité du prompt.

SCU : un modèle de consommation qui conditionne l'usage SOC

La capacité de calcul se provisionne en Security Compute Units (SCU), unités allouées à l'heure et facturées sur l'heure entamée qu'elles soient consommées ou non, avec possibilité de définir des unités d'overage pour absorber les pics. Le tarif public annoncé est de l'ordre de quatre dollars par SCU et par heure, mais ce chiffre doit être confronté à votre contrat EA ou CSP avant tout dimensionnement budgétaire. Le point structurant n'est pas le prix unitaire, c'est le modèle : une capacité provisionnée en continu pour un usage par nature intermittent.

En pratique, une équipe de dix analystes en 8×5 sature rarement plus de deux à trois SCU en pointe, mais paie vingt-quatre heures sur vingt-quatre si la capacité reste provisionnée en permanence. Les organisations matures pilotent le provisionnement par automatisation — réduction nocturne, remontée sur déclenchement d'incident de sévérité haute via un Logic App. Le second piège est comportemental : les promptbooks lourds exécutés en boucle sur des incidents de faible sévérité consomment autant qu'une investigation critique. Restreindre les promptbooks coûteux aux incidents de sévérité High et au-dessus est la mesure d'optimisation la plus rentable que nous déployons systématiquement.

Prompts, promptbooks et Query Assistant : la mécanique opérationnelle

Trois modes d'interaction coexistent, et les confondre produit des résultats médiocres. Le prompt libre convient à l'exploration, mais son caractère non reproductible le disqualifie pour un processus d'investigation formalisé. Le promptbook — séquence ordonnée de prompts paramétrés par une entité d'entrée — est le seul artefact réellement industrialisable : il fige la méthodologie, garantit qu'un analyste de niveau 1 exécute la même séquence qu'un niveau 3, et produit une sortie de structure stable qui peut alimenter un rapport d'incident.

Construire un promptbook BEC exploitable

Un promptbook de qualification BEC prend en entrée un AccountUpn et un IncidentId, puis enchaîne : synthèse de l'incident, résumé du profil identité et de l'historique d'authentification, énumération des règles de boîte de réception créées ou modifiées sur la fenêtre d'intérêt, inventaire des consentements OAuth accordés, évaluation de l'exposition documentaire SharePoint et OneDrive, et enfin proposition de plan de remédiation. Chaque étape hérite du contexte des précédentes, ce qui constitue à la fois la force du mécanisme et sa principale fragilité : une erreur d'interprétation à l'étape deux se propage silencieusement jusqu'au plan de remédiation.

Query Assistant : la traduction langage naturel vers KQL

Le Query Assistant intégré à l'Advanced Hunting génère du KQL à partir d'une description en français ou en anglais. Sa valeur réelle n'est pas de dispenser de connaître KQL, mais d'accélérer la découverte des schémas de tables : il connaît les noms de colonnes de CloudAppEvents, IdentityDirectoryEvents ou EmailPostDeliveryEvents mieux que la majorité des analystes. En revanche, il produit régulièrement des requêtes syntaxiquement valides mais sémantiquement fausses — filtrage sur AccountName là où AccountUpn était nécessaire, ou omission de la déserialisation de RawEventData. Toute requête générée doit être relue avant d'être utilisée comme élément de preuve. Cette discipline rejoint les pratiques décrites dans notre analyse du threat hunting avec les prompts MITRE, où la traçabilité de la requête compte autant que son résultat.

Attack Story automatique : comment Copilot corrèle identité, endpoint et messagerie

L'Attack Story n'est pas produite par le modèle de langage. Elle est produite par le moteur de corrélation de Defender XDR, qui agrège alertes et signaux comportementaux en un graphe d'incident ; Copilot en fournit la narration. Cette distinction est fondamentale pour interpréter correctement les erreurs : quand la chaîne d'attaque est fausse, la cause est presque toujours une corrélation XDR discutable, pas une hallucination du modèle.

Du graphe d'incident au récit

Le graphe repose sur les entités partagées : un compte, un appareil, une adresse IP, un fichier, une URL, une application OAuth. Defender XDR fusionne deux alertes dans un même incident lorsqu'elles partagent une entité forte dans une fenêtre temporelle contrainte. Copilot consomme ensuite le contenu des tables AlertInfo et AlertEvidence, enrichi des signaux BehaviorInfo et BehaviorEntities lorsque la fonctionnalité de détection comportementale est active, pour construire une chronologie causale.

Le résultat typique est une synthèse en cinq à huit paragraphes structurée par phases : accès initial, persistance, découverte, mouvement latéral, impact. La qualité de cette synthèse dépend directement de la richesse de l'evidence. Sur un incident où seules deux alertes ont été corrélées, la narration reste descriptive. Sur un incident à trente alertes couvrant trois produits, elle apporte une valeur réelle en hiérarchisant ce qui relève de la cause racine et ce qui relève de la conséquence.

Vérifier ce que la narration a réellement consommé

Avant d'accorder du crédit à une Attack Story, il faut savoir sur quelles preuves elle s'appuie. La requête de contrôle tient en une ligne : AlertEvidence | where Timestamp > ago(14d) | where AlertId in ((AlertInfo | where IncidentId == 12345 | project AlertId)) | summarize Alertes = dcount(AlertId), Entites = make_set(EntityType) by EvidenceRole. Si le résultat ne fait apparaître aucune entité de type MailMessage alors que la narration décrit une compromission par phishing, la synthèse extrapole à partir du titre des alertes plutôt qu'à partir de preuves de messagerie.

Investigation d'un incident BEC étape par étape

Prenons un cas représentatif : une alerte Entra ID « Anomalous Token » sur le compte d'un directeur financier, suivie quarante minutes plus tard d'une alerte Defender for Cloud Apps sur la création d'une règle de boîte de réception. Defender XDR fusionne les deux en un incident unique de sévérité haute.

Phase 1 — Qualification de l'accès initial

La détection « Anomalous Token » signale une anomalie de durée de vie ou d'emplacement d'utilisation d'un jeton, signature classique d'un vol de session par proxy adverse. Les kits de type AiTM restent le vecteur dominant sur ce type d'incident. Le prompt utile n'est pas « résume l'incident » mais une demande ciblée sur le contexte d'authentification. La validation manuelle passe par : AADSignInEventsBeta | where TimeGenerated > ago(3d) | where AccountUpn == "[email protected]" | project TimeGenerated, IPAddress, Country, DeviceTrustType, AuthenticationRequirement, ConditionalAccessStatus, SessionId, UserAgent. Le marqueur décisif est la coexistence, sur un même SessionId, de deux IPAddress appartenant à des ASN distincts : la session a été rejouée depuis l'infrastructure de l'attaquant.

Phase 2 — Reconstruction de la persistance

La persistance en BEC est rarement un implant, presque toujours une manipulation de configuration. Trois mécanismes concentrent l'essentiel des cas : la règle de boîte de réception qui déplace les fils de discussion sensibles vers un dossier peu consulté, l'ajout d'une adresse de transfert au niveau de la boîte, et l'enregistrement d'une méthode d'authentification forte supplémentaire contrôlée par l'attaquant. Ce dernier point est le plus grave et le plus souvent manqué : il survit à la réinitialisation du mot de passe.

La requête de contrôle : CloudAppEvents | where Timestamp > ago(7d) | where ActionType in ("New-InboxRule","Set-InboxRule","UpdateInboxRules","Set-Mailbox","Add-MailboxPermission") | extend Params = tostring(parse_json(RawEventData).Parameters) | project Timestamp, AccountDisplayName, ActionType, IPAddress, Params. Pour les méthodes MFA, on croise avec IdentityDirectoryEvents et les opérations d'enregistrement d'informations de sécurité côté Entra. La méthodologie complète de ce volet est développée dans notre article sur l'investigation des identités compromises avec Entra.

Phase 3 — Mesure de l'exposition

C'est la phase où Copilot apporte le plus de valeur mesurable, car elle exige d'agréger des sources hétérogènes. La question à poser est celle de la portée : quels messages ont été lus, quels documents téléchargés, quels destinataires externes contactés depuis le compte. L'opération MailItemsAccessed du journal d'audit unifié est la source de vérité pour la lecture de courrier, à condition que l'audit avancé soit activé — prérequis qu'un nombre significatif d'organisations découvre au pire moment. Copilot synthétise, mais la quantification exacte destinée au DPO doit provenir d'une extraction Purview eDiscovery, pas d'une estimation en langage naturel.

Analyse des mouvements latéraux : de l'endpoint compromis au contrôleur de domaine

Le scénario hybride reste le plus exigeant : un poste compromis, une élévation de privilèges locale, puis une progression vers l'annuaire on-premises. Ici la corrélation Copilot doit couvrir Defender for Endpoint et Defender for Identity simultanément.

Ce que Defender for Identity remonte réellement

Les détections structurantes sont connues : Suspected Kerberoasting, Suspected DCSync attack (replication of directory services), Suspected Golden Ticket usage, Suspected overpass-the-hash attack, Suspicious additions to sensitive groups. Copilot les narre correctement dans la majorité des cas, mais commet une erreur d'attribution récurrente : il désigne comme point de départ le premier appareil apparu chronologiquement dans l'incident, qui est fréquemment un poste d'administration ayant simplement observé l'activité, et non le patient zéro.

Requêtes de validation sur la chaîne de privilèges

Pour établir la reconnaissance d'annuaire : IdentityQueryEvents | where Timestamp > ago(2d) | where QueryType in ("AllGroups","AllMembers","SAMName") | summarize Volume = count(), Cibles = dcount(QueryTarget) by AccountUpn, DeviceName, bin(Timestamp, 15m) | where Volume > 50. Un pic soudain sur un compte sans historique de requêtes LDAP massives constitue un indicateur d'énumération plus fiable que l'alerte générique.

Pour la validation DCSync, la preuve reste l'événement Windows 4662 portant sur les GUID d'extension de contrôle 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2 et 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2, déclenché par un principal qui n'est ni un contrôleur de domaine ni un compte de synchronisation légitime. Copilot signale l'alerte ; il ne vérifie pas l'exclusion des comptes légitimes. Cette vérification incombe à l'analyste, et suppose une connaissance de l'annuaire que seule une cartographie préalable fournit — c'est précisément ce que produit un pentest Active Directory mené en amont, dont les livrables servent ensuite de référentiel de comparaison lors des investigations.

Corrélation cloud : Entra ID, SharePoint et Teams dans le graphe d'incident

Le volet cloud est celui où la corrélation automatique atteint sa meilleure densité, parce que la télémétrie converge dans une table unique.

CloudAppEvents comme colonne vertébrale

Cette table centralise les événements SharePoint Online, OneDrive, Teams et Exchange Online. Elle permet de mesurer l'exfiltration documentaire en une requête : CloudAppEvents | where Timestamp > ago(5d) | where Application in ("Microsoft SharePoint Online","Microsoft OneDrive for Business") | where ActionType in ("FileDownloaded","FileSyncDownloadedFull","AnonymousLinkCreated","SharingInvitationCreated") | where AccountObjectId == "..." | summarize Fichiers = dcount(ObjectName), Actions = count() by ActionType, IPAddress, bin(Timestamp, 1h). Le pattern à repérer est la bascule d'un profil de consultation ponctuelle vers une synchronisation complète de bibliothèque.

Le cas des consentements OAuth

Le consentement applicatif est la persistance cloud la plus durable et la moins visible. Une application tierce ayant obtenu Mail.Read ou Files.Read.All conserve son accès après réinitialisation du mot de passe, révocation des sessions et réinscription MFA. Les opérations à surveiller sont Consent to application, Add OAuth2PermissionGrant et Add app role assignment grant to user. Copilot identifie correctement l'application et énumère les permissions accordées, mais son évaluation de criticité mérite d'être requalifiée : il tend à classer en risque modéré des portées de lecture globale sur les fichiers de l'organisation. Sur les incidents où la messagerie et la collaboration sont toutes deux impliquées, l'articulation avec les règles de corrélation personnalisées reste utile, comme détaillé dans notre méthodologie d'investigation Sentinel.

Limites de l'IA sur les incidents complexes : ce qu'il faut valider manuellement

Section décisive : un analyste qui accorde à l'Attack Story le statut de conclusion d'enquête produit des rapports d'incident faux avec une grande assurance.

Causalité inférée contre causalité prouvée

Le mode de défaillance le plus concret est l'agrégation par entité faible. Cas typique observé : un incident regroupant une compromission réelle et l'activité légitime d'un administrateur, parce que les deux flux sortaient de la même passerelle NAT et partageaient donc une IPAddress publique. La narration Copilot a décrit une progression cohérente — accès initial via phishing, puis élévation de privilèges par l'administrateur — alors que les deux séquences étaient indépendantes. Second cas fréquent : deux incidents distincts collapsés parce qu'un compte de service applicatif apparaît dans les deux, ce compte n'étant qu'un dénominateur commun d'infrastructure.

La falsification est mécanique. On extrait les entités portant la fusion : AlertEvidence | where AlertId in ("...","...") | summarize Alertes = make_set(AlertId) by EntityType, RemoteIP, AccountObjectId, DeviceId | where array_length(Alertes) > 1. Si le seul lien est une adresse IP publique partagée ou un compte de service d'infrastructure, la chaîne narrée doit être considérée comme non établie. On vérifie ensuite l'appartenance de cette IP au plan d'adressage de sortie de l'entreprise avant toute conclusion.

Non-déterminisme et exigence de reproductibilité

Deux exécutions du même prompt sur le même incident produisent des synthèses qui diffèrent en formulation, en ordre de priorité et occasionnellement en conclusion. Pour un usage exploratoire, c'est sans conséquence. Pour un rapport destiné à une autorité de contrôle ou à un assureur, c'est disqualifiant. La règle que nous imposons : toute affirmation factuelle reprise dans un rapport doit être adossée à une requête KQL citée et rejouable, la sortie Copilot n'ayant valeur que de synthèse rédactionnelle.

Angles morts de télémétrie

Copilot ne voit que ce que les plugins exposent. Un pare-feu tiers, un VPN non intégré, une solution de messagerie sécurisée externe, un environnement OT segmenté : rien de tout cela n'entre dans le raisonnement, sauf ingestion préalable dans Microsoft Sentinel. Sur les architectures hybrides réelles, une part significative de la chaîne d'attaque se déroule hors du champ de vision du produit. La synthèse reste alors cohérente et incomplète — combinaison particulièrement trompeuse, car rien dans la sortie ne signale l'absence de données. L'analyste doit donc tenir mentalement une carte de ce qui est instrumenté et de ce qui ne l'est pas.

Automatisation des actions de remédiation depuis Copilot Security

Copilot propose des actions ; il ne les exécute pas de sa propre initiative, et cette frontière doit rester explicite dans les procédures.

Actions natives et Guided Response

Depuis l'expérience intégrée au portail Defender, la fonctionnalité Guided Response propose les actions pertinentes au contexte : isolation d'appareil, suspension de compte, révocation des sessions Entra, suppression de messages de toutes les boîtes concernées, blocage d'indicateurs. Chaque action reste soumise aux permissions de l'analyste et à une confirmation explicite. Le gain est cognitif — il n'y a plus à se souvenir qu'une révocation de session doit précéder la réinitialisation du mot de passe, sous peine de laisser un jeton de rafraîchissement valide entre les mains de l'attaquant.

Attack disruption et orchestration par Logic Apps

À distinguer nettement de Copilot : la perturbation automatique des attaques de Defender XDR agit sans intervention humaine sur des scénarios à très haute confiance — fraude BEC, ransomware, AiTM — en désactivant le compte ou en isolant l'appareil. Elle repose sur des modèles dédiés, pas sur Copilot. Les deux se complètent : la perturbation contient, Copilot explique ce qui a été contenu et pourquoi.

Pour l'orchestration, le connecteur Security Copilot pour Logic Apps permet d'exécuter un promptbook sur déclenchement d'incident et de publier la synthèse dans un canal Teams ou un ticket ServiceNow. Le schéma que nous recommandons : déclenchement sur incident de sévérité haute, exécution du promptbook de qualification, publication de la synthèse assortie d'une mention explicite du caractère non validé de l'analyse, puis attente d'une action humaine. Automatiser jusqu'au confinement sur la seule foi d'une sortie générative est un choix que nous déconseillons sur les périmètres à forte criticité métier.

Gouvernance, RBAC et traçabilité des sessions Copilot

Un point systématiquement sous-traité en phase projet : Copilot est lui-même un actif à auditer. Les sessions, les prompts saisis et les plugins invoqués sont journalisés, et ces journaux doivent entrer dans le périmètre de supervision au même titre que les autres. Un prompt d'analyste contient fréquemment des données à caractère personnel — adresses, noms de dirigeants, contenus de messages — et transite par un service dont la localisation de traitement doit être documentée dans le registre des traitements.

Côté RBAC, le modèle propre à Copilot distingue propriétaires et contributeurs de l'espace de travail, et se superpose aux rôles Entra ID et Defender XDR. Le principe de conception à retenir est celui du privilège minimal effectif : l'accès à Copilot n'étend jamais les droits de l'analyste sur les produits sous-jacents, mais il abaisse considérablement la barrière technique pour exploiter ces droits. Un profil junior disposant de permissions larges héritées d'une migration mal nettoyée devient soudainement capable d'extractions massives qu'il n'aurait pas su écrire en KQL. La revue des rôles doit précéder le déploiement, pas le suivre.

Mesurer le gain réel : métriques SOC et pièges de mesure

La question posée par toute direction financière après six mois est celle du retour sur investissement. Les métriques pertinentes sont le temps moyen de qualification d'un incident multi-produits, le taux de réattribution de sévérité après analyse, et le taux d'incidents clôturés à tort en faux positif — cette dernière étant la plus révélatrice et la moins suivie.

Le piège de mesure principal est l'effet de substitution : le temps de qualification baisse effectivement, mais une partie du travail se déplace vers la vérification des affirmations de Copilot, activité rarement instrumentée dans l'outil de ticketing. Sur les déploiements suivis, le gain net sur les incidents de complexité moyenne se situe dans une fourchette de vingt-cinq à quarante pour cent de temps analyste, tandis qu'il devient marginal, voire nul, sur les incidents à très forte complexité où la vérification manuelle reste intégrale. Dimensionner les attentes en conséquence évite la déception à douze mois. Le second effet, plus difficile à chiffrer mais régulièrement rapporté, est la montée en compétence accélérée des profils juniors, qui voient explicitées des chaînes de raisonnement qu'ils auraient mis des mois à acquérir autrement.

Questions fréquentes

Quelles licences sont nécessaires pour utiliser Copilot Security avec Defender XDR ?

Security Copilot est un service facturé indépendamment, provisionné en SCU, et ne fait partie d'aucune licence Microsoft 365 E5. L'expérience intégrée au portail Defender exige en revanche que les produits sources soient licenciés séparément : Defender for Endpoint P2, Defender for Identity et Defender for Office 365 P2 pour couvrir les trois domaines évoqués dans cet article. Sans Defender for Identity, aucune corrélation vers l'annuaire on-premises n'est possible, quel que soit le nombre de SCU provisionnés.

Combien de SCU faut-il provisionner pour un SOC de dix analystes ?

Le point de départ raisonnable se situe entre deux et trois SCU pour un fonctionnement en 8×5, avec des unités d'overage pour absorber les pics d'incident majeur. La consommation dépend beaucoup plus du nombre de promptbooks exécutés que du nombre d'analystes connectés. Il est préférable de démarrer bas, de mesurer sur trente jours via le tableau de bord d'utilisation, puis d'ajuster, plutôt que de surprovisionner par prudence — la capacité inutilisée est facturée intégralement.

Pourquoi l'Attack Story affiche-t-elle parfois une chaîne incomplète ?

Trois causes dominent, par ordre de fréquence : des permissions insuffisantes du compte appelant sur l'un des produits sources, un plugin désactivé dans l'espace de travail, ou une absence réelle de télémétrie sur un segment non instrumenté. Le diagnostic commence toujours par la vérification des rôles, ensuite seulement par celle de la couverture de télémétrie. Une reformulation du prompt ne corrige jamais un problème de permissions.

Faut-il automatiser les actions de remédiation proposées par Copilot ?

Pas sur les périmètres critiques. La recommandation opérationnelle est d'automatiser l'enrichissement, la synthèse et la notification, mais de maintenir une validation humaine sur toute action de confinement irréversible, en particulier la suspension de comptes de direction ou l'isolation de serveurs de production. La perturbation automatique native de Defender XDR, qui repose sur des modèles déterministes à très haute confiance, est un mécanisme distinct et peut être activée avec un niveau de confiance supérieur.

Comment garantir la reproductibilité d'une investigation menée avec Copilot ?

En imposant que toute affirmation factuelle intégrée à un rapport soit adossée à une requête KQL citée, horodatée et rejouable. Les promptbooks apportent la reproductibilité de la méthode, jamais celle du résultat textuel, qui varie d'une exécution à l'autre. La sortie Copilot doit être archivée comme pièce de contexte, et non comme élément de preuve opposable.