Defender for Endpoint : collecte personnalisée en KQL

Une activité visible sur un poste ne produit pas nécessairement une ligne exploitable dans Microsoft Defender XDR, anciennement Microsoft 365 Defender. Les règles de collecte personnalisée de Microsoft Defender for Endpoint permettent de renforcer la télémétrie sur un périmètre précis, à condition de maîtriser le ciblage, les coûts Microsoft Sentinel et la limite d’événements.

Pourquoi la télémétrie EDR standard laisse des angles morts

Le capteur de Microsoft Defender for Endpoint collecte nativement les créations de processus, connexions réseau, opérations sur les fichiers et autres comportements utiles à la détection. Cela ne signifie pas que chaque événement local est transmis tel quel au cloud ni qu’il apparaît individuellement dans Advanced Hunting.

Le traitement local peut agréger des observations similaires ou limiter certains volumes. Ce fonctionnement réduit la charge sur les appareils, le réseau et l’infrastructure cloud, mais il complique une investigation lorsque l’activité recherchée fait précisément partie des événements regroupés ou non remontés.

Une succession de 100 connexions produites par un processus ne garantit donc pas 100 lignes dans DeviceNetworkEvents. Pour l’ingénieur détection, la bonne question n’est pas seulement de savoir si le capteur observe une activité, mais si sa représentation dans le cloud possède la granularité nécessaire.

Les travaux de FalconForce sur les mécanismes de collecte de Microsoft Defender for Endpoint détaillent cette distinction entre l’activité locale et les événements finalement disponibles. Elle doit être intégrée à la conception des règles de chasse et de détection.

La collecte personnalisée ajoute un second flux vers Sentinel

Une règle personnalisée ne remplace pas la télémétrie EDR standard. Elle crée un flux parallèle et ciblé, pris en charge par le capteur Defender for Endpoint sans déployer Azure Monitor Agent ou un autre agent de collecte.

La différence essentielle concerne la destination. Les événements supplémentaires sont stockés dans Microsoft Sentinel, et non dans le jeu de données inclus de Defender XDR. Ils deviennent interrogeables avec KQL, mais leur ingestion suit la facturation du workspace Sentinel connecté.

La vue d’ensemble Microsoft Learn de la collecte personnalisée documente cinq correspondances de tables :

Cette capacité ne remplace donc ni Sysmon, ni Windows Event Forwarding, ni les protections antivirus et EDR. Elle est adaptée à une question d’investigation circonscrite, pas à l’aspiration indifférenciée de tous les événements du système.

Les prérequis déterminent le périmètre du lab

La fonctionnalité a été annoncée à Ignite en novembre 2025, initialement en préversion. Au 27 octobre 2026, Microsoft la présente comme une capacité intégrée au portail Defender, sous réserve que le tenant soit onboardé sur la Unified Security Operations Platform, ou USOP.

Vérifiez les exigences avant de créer la première règle :

Au 27 octobre 2026, la collecte personnalisée est limitée à un workspace Microsoft Sentinel par tenant. Même si un workspace est déjà relié à Defender, il doit être choisi dans l’écran de configuration de la collecte.

Les éléments vérifiés ne nomment pas de rôle RBAC minimal précis. N’attribuez pas un rôle étendu par défaut : faites valider le rôle le plus restrictif donnant accès à Settings > Endpoints > Custom Collection, à Asset Rule Management et au workspace de test.

Pour replacer ces flux dans l’architecture globale, consultez également notre guide des composants de Microsoft Defender XDR.

Lab : cibler cinq à dix appareils avec un tag dynamique

Microsoft recommande de démarrer avec 5 à 10 appareils, puis d’observer le volume et la qualité des données pendant 24 à 48 heures. Les tags dynamiques sont réévalués environ toutes les heures ; un tag manuel ou attribué par API n’est pas pris en charge pour ce ciblage.

Mise en œuvre : collecter les créations de PowerShell

Au 27 octobre 2026, aucune API officielle n’est fournie pour créer ces règles. La configuration s’effectue donc dans le portail ; il n’existe pas de cmdlet PowerShell officielle à proposer sans inventer une interface. Le projet communautaire TelemetryCollectionManager de FalconForce peut faciliter la gestion, mais doit être évalué et testé séparément avant un usage en production.

Dans Settings > Endpoints > Custom Collection, créez une règle de processus ciblant le tag du pilote. Utilisez la logique suivante :

1ActionType = ProcessCreated
2 
3AND
4 
5FileName IN (
6    "powershell.exe",
7    "pwsh.exe"
8)

powershell.exe couvre Windows PowerShell, tandis que pwsh.exe cible PowerShell 7 et les versions ultérieures. La règle doit recevoir un nom décrivant son objectif, son périmètre et, idéalement, son caractère temporaire.

Le portail propose aussi des catégories pour le réseau, les fichiers, les chargements d’images et les scripts. Des modèles préremplissent certaines conditions de collecte de fichiers.

Pour générer des événements de test, aucun module PowerShell n’est requis. Le script suivant ne demande pas d’élévation et produit une ligne de résultat par exécutable trouvé :

1$ErrorActionPreference = 'Stop'
2 
3# Exécutables ciblés par la règle de collecte du lab
4$Targets = @(
5    [pscustomobject]@{
6        Name   = 'powershell.exe'
7        Marker = 'MDE-CDC-LAB-WindowsPowerShell'
8    },
9    [pscustomobject]@{
10        Name   = 'pwsh.exe'
11        Marker = 'MDE-CDC-LAB-PowerShell7'
12    }
13)
14 
15# Chaque appel démarre un nouveau processus et doit produire un événement ProcessCreated
16$Results = foreach ($Target in $Targets) {
17    $Command = Get-Command -Name $Target.Name -ErrorAction SilentlyContinue
18 
19    if ($null -eq $Command) {
20        [pscustomobject]@{
21            Executable = $Target.Name
22            Status     = 'Non installé'
23            Marker     = $Target.Marker
24            Timestamp  = Get-Date -Format o
25        }
26        continue
27    }
28 
29    $Output = & $Command.Source -NoLogo -NoProfile -NonInteractive `
30        -Command "Write-Output '$($Target.Marker)'"
31 
32    [pscustomobject]@{
33        Executable = $Target.Name
34        Status     = 'Déclenché'
35        Marker     = $Output
36        Timestamp  = Get-Date -Format o
37    }
38}
39 
40$Results | Format-Table -AutoSize

La sortie attendue indique Déclenché pour chaque version installée. La règle créée ou modifiée met généralement 20 minutes à 1 heure à atteindre les appareils ciblés : ne concluez pas à un échec immédiatement après l’exécution du script.

Pour un scénario fichier, le même principe peut surveiller une arborescence sensible telle que C:\ProgramData\Contoso\SensitiveApp\. Les actions et la syntaxe exacte du filtre doivent alors être sélectionnées dans l’assistant, puis les résultats recherchés dans DeviceCustomFileEvents.

Valider la collecte, chasser et dépanner en KQL

Après le délai de propagation, ouvrez Advanced Hunting et recherchez les événements sur les cinq tables. Remplacez your_device_id aux deux emplacements par l’identifiant de l’appareil pilote :

1search in (DeviceCustomFileEvents, DeviceCustomScriptEvents, DeviceCustomNetworkEvents, DeviceCustomProcessEvents, DeviceCustomImageLoadEvents) "your_device_id"
2| where DeviceId == "your_device_id"
3| summarize EventCount = count() by RuleName, RuleLastModificationTime, $table
4| order by RuleLastModificationTime desc

Une validation réussie retourne le nom de la règle, sa dernière date de modification, la table alimentée et un compteur supérieur à zéro.

Cette seconde requête isole les créations de PowerShell collectées pendant les dernières 24 heures :

1DeviceCustomProcessEvents
2| where Timestamp > ago(24h)
3| where FileName in~ ("powershell.exe", "pwsh.exe")
4| summarize
5    EventCount = count(),
6    FirstEvent = min(Timestamp),
7    LastEvent = max(Timestamp)
8    by DeviceId, DeviceName, RuleName, FileName
9| order by LastEvent desc

Microsoft documente un plafond de 75 000 événements par règle, par appareil, sur une fenêtre glissante de 24 heures. Lorsque ce seuil est atteint, seule la règle concernée s’arrête temporairement ; les autres règles de l’appareil continuent.

Surveillez son utilisation avec cette estimation :

1union
2    DeviceCustomProcessEvents,
3    DeviceCustomNetworkEvents,
4    DeviceCustomFileEvents,
5    DeviceCustomImageLoadEvents,
6    DeviceCustomScriptEvents
7| where Timestamp > ago(24h)
8| summarize
9    EventCount = count(),
10    FirstEvent = min(Timestamp),
11    LastEvent = max(Timestamp)
12    by DeviceId, DeviceName, RuleName
13| extend LimitUtilization =
14    round(100.0 * EventCount / 75000, 2)
15| order by EventCount desc

Cette requête mesure les événements ingérés, pas les compteurs internes du capteur. Les délais de traitement et le caractère glissant de la fenêtre peuvent produire un écart ; préférez plusieurs règles étroites à une règle générale.

Symptômes fréquents après le déploiement

Un retour publié dans la communauté Microsoft décrit notamment une table personnalisée vide malgré des événements correspondants dans la table standard ; le test sur un autre endpoint avait permis d’isoler le problème.

Questions fréquentes

Microsoft Sentinel est-il obligatoire pour la collecte personnalisée ?

Oui. Les événements personnalisés sont stockés dans le workspace Microsoft Sentinel connecté et non dans le jeu de données Defender XDR inclus avec la licence Microsoft Defender for Endpoint Plan 2.

Peut-on cibler une règle avec un tag manuel ?

Non. Le ciblage repose sur les tags dynamiques configurés dans Asset Rule Management. Ils doivent avoir été évalués au moins une fois et leur actualisation intervient environ toutes les heures.

Combien de temps faut-il attendre avant de lancer la requête KQL ?

Une règle créée ou modifiée met généralement de 20 minutes à 1 heure à atteindre les appareils. Attendez ce délai, générez de nouveaux événements, puis interrogez les tables personnalisées.

La collecte personnalisée remplace-t-elle Sysmon ou Windows Event Forwarding ?

Non. Elle ne collecte que les catégories prises en charge par Microsoft Defender for Endpoint et reste soumise à des limites par règle. Utilisez-la pour répondre à un besoin ciblé de chasse ou d’investigation.

Déployer progressivement sans créer un nouveau bruit

Commencez par une seule règle de processus sur un groupe dynamique de 5 à 10 appareils. Si la requête KQL confirme des données utiles et un volume acceptable après 24 à 48 heures, élargissez le ciblage par étapes ; sinon, resserrez d’abord les conditions.

Pour une surveillance permanente, utilisez un tag stable et des conditions strictes. Pour une réponse à incident, un profil dynamique tel que HighSev-Verbose peut activer une collecte plus détaillée, puis son retrait ramène automatiquement l’appareil au niveau de base décrit par Microsoft.

Pour aller plus loin

• Custom data collection in Microsoft Defender for Endpoint — tables prises en charge, fonctionnement et limite d’événements.
• Create and manage custom data collection rules — procédure, stratégie de pilote et dépannage officiel.
• Elevate your telemetry using custom data collection — scénarios C2, DNS, persistance et collecte pilotée par tag.
• Devices in Microsoft Defender for Endpoint — fonctionnement du ciblage des appareils et des groupes.
• Defender for Endpoint et les mises à jour EDR via Microsoft Update — prérequis opérationnels pour maintenir les composants EDR.